Bug 67911

Summary: Venue 8 Pro (valleyview): warn_slowpath_common while processing ACPI tables (I think)
Product: EFI Reporter: Adam Williamson (adamw)
Component: VideoAssignee: EFI Virtual User (efi)
Status: RESOLVED CODE_FIX    
Severity: normal CC: aaron.lu, bugzilla, finaglesghost, jacek.m.danecki, matt
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.13.0-0.rc5.git0.1.fc21 Subsystem:
Regression: No Bisected commit-id:
Attachments: full journal from a boot on the affected system, including traceback
acpidump from affected system

Description Adam Williamson 2013-12-30 00:43:22 UTC
I've been attempting to get Fedora working on the Dell Venue 8 Pro (a baytrail / valleyview-based 8" tablet) for a while now. One of the outstanding issues I have at present is this.

I'm currently using a kernel versioned 3.13.0-0.rc5.git0.1.2.fc21 . This is a slightly modified version of the current Fedora Rawhide kernel 3.13.0-0.rc5.git0.1.fc21 with some patches applied, all but the ath6kl hack pulled from various maintainer trees:

add-baytrail-soc-gpio.patch - https://github.com/rjwysocki/linux-pm/commit/b2a51a6d0f96308251cfa41b793c43d0316e3b16
ath6kl_v8p.patch - just adds the SDIO ID of the system's wireless adapter to the ath6kl driver
use-correct-gmch-register.patch - http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=a885b3ccc74d8e38074e1c43a47c354c5ea0b01e
rapl-add-valleyview.patch - https://github.com/rjwysocki/linux-pm/commit/ed93b71492da3464b4798613aa8a99bed914251b
baytrail-lock-irqs-when-starting.patch - http://www.gossamer-threads.com/lists/engine?do=post_view_printable;post=1829558;list=linux

I don't believe any of these patches are implied in the issue.

Very early in boot, there is a warn_slowpath_common which looks like it comes while processing ACPI tables:

Dec 29 11:11:33 localhost kernel: ACPI: Core revision 20131115
Dec 29 11:11:33 localhost kernel: ACPI: All ACPI Tables successfully acquired
Dec 29 11:11:33 localhost kernel: ------------[ cut here ]------------
Dec 29 11:11:33 localhost kernel: WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x2ad/0x2c0()
Dec 29 11:11:33 localhost kernel: Modules linked in:
Dec 29 11:11:33 localhost kernel: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-0.rc5.git0.1.2.fc21.i686 #1
Dec 29 11:11:33 localhost kernel: Hardware name: DellInc. Venue 8 Pro 5830/09RP78, BIOS A02 10/17/2013
Dec 29 11:11:33 localhost kernel:  00000000 00000000 c0c0df08 c09a5196 00000000 c0c0df38 c0448c1e c0b41310
Dec 29 11:11:33 localhost kernel:  00000000 00000000 c0b37bc1 00000066 c043bbfd c043bbfd 00e7dfe0 00073eff
Dec 29 11:11:33 localhost kernel:  00073eff c0c0df48 c0448ce2 00000009 00000000 c0c0df9c c043bbfd 00078d88
Dec 29 11:11:33 localhost kernel: Call Trace:
Dec 29 11:11:33 localhost kernel:  [<c09a5196>] dump_stack+0x41/0x52
Dec 29 11:11:33 localhost kernel:  [<c0448c1e>] warn_slowpath_common+0x7e/0xa0
Dec 29 11:11:33 localhost kernel:  [<c043bbfd>] ? __ioremap_caller+0x2ad/0x2c0
Dec 29 11:11:33 localhost kernel:  [<c043bbfd>] ? __ioremap_caller+0x2ad/0x2c0
Dec 29 11:11:33 localhost kernel:  [<c0448ce2>] warn_slowpath_null+0x22/0x30
Dec 29 11:11:33 localhost kernel:  [<c043bbfd>] __ioremap_caller+0x2ad/0x2c0
Dec 29 11:11:33 localhost kernel:  [<c0718f92>] ? acpi_tb_verify_table+0x1c/0x43
Dec 29 11:11:33 localhost kernel:  [<c0719c78>] ? acpi_get_table_with_size+0x63/0xb5
Dec 29 11:11:33 localhost kernel:  [<c087cd5e>] ? efi_lookup_mapped_addr+0xe/0xf0
Dec 29 11:11:33 localhost kernel:  [<c043bc2b>] ioremap_nocache+0x1b/0x20
Dec 29 11:11:33 localhost kernel:  [<c0cb01c8>] ? efi_bgrt_init+0x83/0x10c
Dec 29 11:11:33 localhost kernel:  [<c0cb01c8>] efi_bgrt_init+0x83/0x10c
Dec 29 11:11:33 localhost kernel:  [<c0cafd82>] efi_late_init+0x8/0xa
Dec 29 11:11:33 localhost kernel:  [<c0c9bab2>] start_kernel+0x3ae/0x3c3
Dec 29 11:11:33 localhost kernel:  [<c0c9b53b>] ? repair_env_string+0x51/0x51
Dec 29 11:11:33 localhost kernel:  [<c0c9b378>] i386_start_kernel+0x12e/0x131
Dec 29 11:11:33 localhost kernel: ---[ end trace 22c53e93c5894587 ]---
Dec 29 11:11:33 localhost kernel: ftrace: allocating 24920 entries in 49 pages
Dec 29 11:11:33 localhost kernel: Enabling APIC mode:  Flat.  Using 1 I/O APICs
Dec 29 11:11:33 localhost kernel: ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
Dec 29 11:11:33 localhost kernel: ..MP-BIOS bug: 8254 timer not connected to IO-APIC

Will attach the full log and acpidump. Note that I'm doing a *32-bit* UEFI boot, which is quite unusual (all baytrail systems appear to have 32-bit UEFI firmwares, so I hacked up Fedora's live image creator a bit to build images capable of 32-bit UEFI booting).
Comment 1 Adam Williamson 2013-12-30 00:44:52 UTC
Created attachment 120211 [details]
full journal from a boot on the affected system, including traceback
Comment 2 Adam Williamson 2013-12-30 00:45:04 UTC
Created attachment 120221 [details]
acpidump from affected system
Comment 3 Matt Fleming 2014-01-02 11:36:54 UTC
This WARNING is triggered because the BGRT image is contained within System RAM. It's a legitimate warning, because by the time the pages are accessed in efi_bgrt_init() it's likely that they've been reused and so could contain any random data.

This seems to not be a problem on x86-64 because most UEFI systems put the BGRT in EFI_BOOT_SERVICES_DATA regions, which we go to great lengths to mark as reserved until we've extracted the BGRT image.

Really, the only sensible solution is to bring the ACPI table parsing code online much earlier in boot, before the pages containing the BGRT image get released for general allocation.
Comment 4 Matt Fleming 2014-01-14 15:32:13 UTC
OK, ignore what I said previously.

The BGRT data on your machine is also likely to be stored in EfiBootServicesData regions, but we don't map those on x86-32 because they're marked as E820_RAM in the e820 table, and as you've seen, ioremap()'ing E820_RAM causes a WARNING.

Can you try the 'bgrt-for-i386' branch at,

  git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git

and see if that solves your issues?
Comment 5 Adam Williamson 2014-01-14 17:06:33 UTC
It's easier for me to apply patches to the Fedora kernel build than build an entire separate tree...would a very recent 3.13 build with the most recent two or four patches on that branch applied to it be sufficient for testing, or is the earlier stuff still relevant (i.e. not in mainline 3.13 yet) too?
Comment 6 Matt Fleming 2014-01-14 17:18:32 UTC
Yeah, you should be able to pull the top three patches from that branch,

c71f6889a9e1 x86/efi: Allow mapping BGRT on x86-32
3c259a2a11fa x86/efi: Delete efi_late_init() and simplify EFI initialization
60e2fafd6a9f ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()

and build a kernel that should solve your issue.
Comment 7 Adam Williamson 2014-01-14 21:17:32 UTC
Yeah, that does seem to do the trick. I still have the ACPI init bug from https://bugzilla.kernel.org/show_bug.cgi?id=67861 , but the warn_slowpath_common is gone.
Comment 8 Adam Williamson 2014-01-29 03:00:15 UTC
What's the status of these patches wrt upstream / 3.14? On Fedora's current 3.14 kernel it looks like 60e2fafd6a9f is no longer relevant (it's been moved even *earlier* upstream). c71f6889a9e1 and 3c259a2a11fa still apply cleanly to 3.14, but I can't find any trace of an upstream submission for them, which makes me slightly nervous. thanks!
Comment 9 Adam Williamson 2014-02-11 02:59:06 UTC
c71f6889a9e1 was merged in rc2, but 3c259a2a11fa was not, by the looks of it.
Comment 10 Adam Williamson 2014-02-20 01:32:02 UTC
Ping...3c259a2a11fa is still not merged upstream. Is it going to be sent? Is it now unneeded?
Comment 11 Matt Fleming 2014-03-11 20:33:43 UTC
This should be resolved since v3.14-rc2. And yeah, 3c259a2a11fa is unneeded.