Bug 100581
| Summary: | Boot hangs after "Booting the kernel." message on eCAFE EC-800-H20G/S netbook since commit b9a5e5e18fbf223502c0b2264c15024e393da928. | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | g5983969 |
| Component: | Other | Assignee: | Rafael J. Wysocki (rjw) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | rui.zhang |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 4.0.5+ | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
Messages with debug enabled.
/proc/ioports /proc/iomem dmesg ACPI: Reorder acpi_reserve_resources() after the initnal namespace scan ACPI: Reorder acpi_reserve_resources() after the initnal namespace scan v2 ACPI: Reorder acpi_reserve_resources() after the initnal namespace scan v3 lspci ACPI / init: Reserve ACPI fixed hardware resources earlier |
||
Can you please check if this patch helps: https://patchwork.kernel.org/patch/6628061/ (In reply to Rafael J. Wysocki from comment #1) > Can you please check if this patch helps: > > https://patchwork.kernel.org/patch/6628061/ Applying this patch to linux kernel 4.0.5 doesn't help. I do get a couple of "Hunk #x succeeded" messages after "patching file include/linux/acpi.h" though. Could there be a change in that file that prevents this patch from working correctly ? So the patch applies, although not cleanly, but the kernel still doesn't boot after building with this patch applied. Is that correct? If so, please attach /proc/ioports and /proc/iomem from a kernel with commit b9a5e5e18fbf223502c reverted. Also pleas attach the output of dmesg from the same kernel on the affected system. Created attachment 181571 [details]
/proc/ioports
Created attachment 181581 [details]
/proc/iomem
Created attachment 181591 [details]
dmesg
(In reply to Rafael J. Wysocki from comment #3) > So the patch applies, although not cleanly, but the kernel still doesn't > boot after building with this patch applied. Is that correct? That's correct. > If so, please attach /proc/ioports and /proc/iomem from a kernel with commit > b9a5e5e18fbf223502c reverted. > Also pleas attach the output of dmesg from the same kernel on the affected > system. I have attached /proc/ioports, /proc/iomem and dmesg from linux kernel 4.0.5 with commit b9a5e5e18fbf223502c0b2264c15024e393da928 reverted. Thanks. Created attachment 181601 [details]
ACPI: Reorder acpi_reserve_resources() after the initnal namespace scan
Thanks.
Can you please test this patch, then?
The previous one should not be necessary for that, but it also shouldn't hurt.
(In reply to Rafael J. Wysocki from comment #9) > Created attachment 181601 [details] > ACPI: Reorder acpi_reserve_resources() after the initnal namespace scan > > Thanks. > > Can you please test this patch, then? > > The previous one should not be necessary for that, but it also shouldn't > hurt. If I understand correctly I should apply : - commit b9a5e5e18fbf223502c0b2264c15024e393da928 - https://patchwork.kernel.org/patch/6628061/ (optional) - attachment 181601 [details] in that order. Is that correct ? Thanks. That's correct. Unfortunately the kernel still doesn't boot with the patch from attachment 181601 [details] applied. I tried with and without the patch from https://patchwork.kernel.org/patch/6628061/ to see if that would make a difference but it doesn't. PS : The patch from attachment 181601 [details] applies but not cleanly
Created attachment 181671 [details]
ACPI: Reorder acpi_reserve_resources() after the initnal namespace scan v2
Well, this starts to be annoying.
What about this one (may not apply cleanly)?
Regardless of whether or not the patch helps, please attach the output of lspci from that system. In addition to that, if the system doesn't boot, are you able to get any debug information from it? When applying the new patch I get the message : "Hunk #1 FAILED at 153." after "patching file include/linux/acpi.h" I assume there's no point in building the kernel after this. Should I use a specific kernel version when calling lspci ? or will any version do ? (In reply to Rafael J. Wysocki from comment #16) > In addition to that, if the system doesn't boot, are you able to get any > debug information from it? The photo I attached along with the initial bug report shows the messages displayed on the screen with "debug" appended to the kernel line. Is this of any help ? https://bugzilla.kernel.org/attachment.cgi?id=181071 (In reply to g5983969 from comment #17) > When applying the new patch I get the message : > "Hunk #1 FAILED at 153." after "patching file include/linux/acpi.h" > I assume there's no point in building the kernel after this. Correct. I'll attach a new version shortly. > Should I use a specific kernel version when calling lspci ? or will any > version do ? No, any version should be fine. Created attachment 181681 [details]
ACPI: Reorder acpi_reserve_resources() after the initnal namespace scan v3
This one should apply, please test it.
Created attachment 181691 [details]
lspci
Thanks! The device that conflicts with the PCI resources is an ISA bridge, so there shouldn't be any problems with it due to the conflict, so at this point it is a mystery to me why the boot hangs. It seems to hang before or during the fs_initcall_sync stage. Can you please try to boot the hanging kernel with initcall_debug in the command line and take a photo of the screen when it hangs? Also please test the patch from comment #20. Created attachment 181721 [details]
ACPI / init: Reserve ACPI fixed hardware resources earlier
One more thing to try.
Please revert commit b9a5e5e18fbf223502c0b2264c15024e393da928.as you did, apply this patch instead of it and check if the kernel boots on your machine then.
Actually, please start with the thing from comment #24 and report back. If that patch works for you, I may just decide to revert commit b9a5e5e18fbf223502c0b2264c15024e393da928 plus fixes on top of it and apply this one instead. I tested the patch from comment #20 (ACPI: Reorder acpi_reserve_resources() after the initnal namespace scan v3) before seeing your other comments and the kernel boots with it :) Would you still like to see the messages with the hanging kernel and initcall_debug or should I test the thing from comment #24 first ? (In reply to g5983969 from comment #26) > I tested the patch from comment #20 (ACPI: Reorder acpi_reserve_resources() > after the initnal namespace scan v3) before seeing your other comments and > the kernel boots with it :) OK, thanks! > Would you still like to see the messages with the hanging kernel and > initcall_debug or should I test the thing from comment #24 first ? Please test the patch from comment #24 (with commit b9a5e5e18fbf223502c0b2264c15024e393da928 reverted). It should work if the previous one does, but let's verify that just in case. The kernel boots with the patch from comment #24 (with commit b9a5e5e18fbf223502c0b2264c15024e393da928 reverted) :) OK, thanks! Mainline patch posted: https://patchwork.kernel.org/patch/6717221/ I'll push it to Linus next week if all goes well. OK, thanks again. Fixed by commit 0294112ee313 (ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage) |
Created attachment 181071 [details] Messages with debug enabled. Boot hangs with linux kernel 4.0.5+ after "Booting the kernel." message on the eCAFE EC-800-H20G/S netbook. With "debug" appended to the kernel line the last message displayed is "random: nonblocking pool is initialized". Booting with "acpi=off" allows the netbook to boot (but with limited functionality of course). Reverting commit b9a5e5e18fbf223502c0b2264c15024e393da928 "ACPI / init: Fix the ordering of acpi_reserve_resources()" solves the problem. I have attached a photo of the netbook's screen showing more of the messages with "debug" enabled. Please ask for more information if necessary. Thanks in advance.