Bug 67911
| Summary: | Venue 8 Pro (valleyview): warn_slowpath_common while processing ACPI tables (I think) | ||
|---|---|---|---|
| Product: | EFI | Reporter: | Adam Williamson (adamw) |
| Component: | Video | Assignee: | 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
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. |