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).
Created attachment 120211 [details] full journal from a boot on the affected system, including traceback
Created attachment 120221 [details] acpidump from affected system
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.
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?
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?
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.
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.
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!
c71f6889a9e1 was merged in rc2, but 3c259a2a11fa was not, by the looks of it.
Ping...3c259a2a11fa is still not merged upstream. Is it going to be sent? Is it now unneeded?
This should be resolved since v3.14-rc2. And yeah, 3c259a2a11fa is unneeded.