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: OtherAssignee: 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

Description g5983969 2015-06-27 14:39:46 UTC
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.
Comment 1 Rafael J. Wysocki 2015-06-30 14:27:07 UTC
Can you please check if this patch helps:

https://patchwork.kernel.org/patch/6628061/
Comment 2 g5983969 2015-07-01 11:11:47 UTC
(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 ?
Comment 3 Rafael J. Wysocki 2015-07-01 14:00:23 UTC
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.
Comment 4 Rafael J. Wysocki 2015-07-01 14:05:27 UTC
Also pleas attach the output of dmesg from the same kernel on the affected system.
Comment 5 g5983969 2015-07-01 21:23:01 UTC
Created attachment 181571 [details]
/proc/ioports
Comment 6 g5983969 2015-07-01 21:24:04 UTC
Created attachment 181581 [details]
/proc/iomem
Comment 7 g5983969 2015-07-01 21:24:42 UTC
Created attachment 181591 [details]
dmesg
Comment 8 g5983969 2015-07-01 21:30:37 UTC
(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.
Comment 9 Rafael J. Wysocki 2015-07-01 22:00:16 UTC
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.
Comment 10 g5983969 2015-07-01 22:17:07 UTC
(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.
Comment 11 Rafael J. Wysocki 2015-07-01 22:42:18 UTC
That's correct.
Comment 12 g5983969 2015-07-02 17:37:59 UTC
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.
Comment 13 g5983969 2015-07-02 17:41:53 UTC
PS : The patch from attachment 181601 [details] applies but not cleanly
Comment 14 Rafael J. Wysocki 2015-07-02 19:49:08 UTC
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)?
Comment 15 Rafael J. Wysocki 2015-07-02 19:51:33 UTC
Regardless of whether or not the patch helps, please attach the output of lspci from that system.
Comment 16 Rafael J. Wysocki 2015-07-02 20:27:19 UTC
In addition to that, if the system doesn't boot, are you able to get any debug information from it?
Comment 17 g5983969 2015-07-02 20:33:36 UTC
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 ?
Comment 18 g5983969 2015-07-02 20:37:17 UTC
(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
Comment 19 Rafael J. Wysocki 2015-07-02 20:53:53 UTC
(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.
Comment 20 Rafael J. Wysocki 2015-07-02 20:57:27 UTC
Created attachment 181681 [details]
ACPI: Reorder acpi_reserve_resources() after the initnal namespace scan v3

This one should apply, please test it.
Comment 21 g5983969 2015-07-02 21:01:37 UTC
Created attachment 181691 [details]
lspci
Comment 22 Rafael J. Wysocki 2015-07-02 21:09:15 UTC
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.
Comment 23 Rafael J. Wysocki 2015-07-02 21:14:12 UTC
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.
Comment 24 Rafael J. Wysocki 2015-07-02 22:10:00 UTC
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.
Comment 25 Rafael J. Wysocki 2015-07-03 00:10:44 UTC
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.
Comment 26 g5983969 2015-07-03 13:16:08 UTC
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 ?
Comment 27 Rafael J. Wysocki 2015-07-03 13:51:35 UTC
(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.
Comment 28 g5983969 2015-07-03 19:04:43 UTC
The kernel boots with the patch from comment #24 (with commit b9a5e5e18fbf223502c0b2264c15024e393da928 reverted) :)
Comment 29 Rafael J. Wysocki 2015-07-04 00:44:03 UTC
OK, thanks!

Mainline patch posted:

https://patchwork.kernel.org/patch/6717221/

I'll push it to Linus next week if all goes well.
Comment 30 g5983969 2015-07-04 13:24:18 UTC
OK, thanks again.
Comment 31 Rafael J. Wysocki 2015-07-14 19:01:02 UTC
Fixed by commit 0294112ee313 (ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage)