Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B

Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B

[Roberto Oppedisano]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

Hello
     I'm observing this kind of boot failure when my laptop
is not docked; I didn't notice before because I seldom reboot
it when it's not connected to a docking station.

The failure is reproducible at 80-90%, meaning that one boot
over 8-10 will complete also with the laptop undocked; it seems
that being attached to a power supply (via jack, not docking) or
on batteries makes no difference WRT this failure.
Here:

http://62.196.71.254/kernel/

I've uploaded 3 png files containing a shoot of the error (the
3 shoot, taken via a video camera, don't capture all of the
boot output; I'll try to setup a serial console if needed).

The bug is not reproducible on ubuntu kernel 3.5.0-25.39 and
I think it was not there in 3.6.11-stable.

It is present on a post 3.8 kernel (i did compile from Linus
master tree about ten days ago) and is present on current git:

Linux poppero4 3.9.0-rc2 #18 SMP PREEMPT Mon Mar 11 07:05:52 CET 2013 
x86_64 x86_64 x86_64 GNU/Linux

Attached dmesg and config.

Let me know if you need more info.

Kind regards
R


[-- Attachment #2: dmesg.txt.gz --]
[-- Type: application/gzip, Size: 15970 bytes --]

[-- Attachment #3: config-3.9.0-rc2.gz --]
[-- Type: application/gzip, Size: 22281 bytes --]

Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected

[Roberto Oppedisano]

Hi

Il 11/03/2013 09:00, Roberto Oppedisano ha scritto:
> Hello
>     I'm observing this kind of boot failure when my laptop
> is not docked; I didn't notice before because I seldom reboot
> it when it's not connected to a docking station.
>
> The failure is reproducible at 80-90%, meaning that one boot
> over 8-10 will complete also with the laptop undocked; it seems
> that being attached to a power supply (via jack, not docking) or
> on batteries makes no difference WRT this failure.

following the results of a bisection:

b17b537ac1429a609addb55bf985f5ebfcf4ae7b is the first bad commit
commit b17b537ac1429a609addb55bf985f5ebfcf4ae7b
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Tue Jan 15 13:23:44 2013 +0100

     ACPI / scan: Drop the second argument of acpi_device_unregister()

     Drop the second argument of acpi_device_unregister(), type, which is
     not used by that function.

     Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
     Acked-by: Toshi Kani <toshi.kani@hp.com>
     Acked-by: Yinghai Lu <yinghai@kernel.org>
     Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>

:040000 040000 13aeb8bccbd062e65bc3710bb426fe8ac7d0cad5 
17d4603977ea57133d149814dc34e274ca0c2deb M      drivers

Trying to revert this commit on current master gave me an error.

Let me know if you need more info or testing.

R

Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected

[Toshi Kani]

On Thu, 2013-03-14 at 09:20 +0100, Roberto Oppedisano wrote:
> Hi
> 
> Il 11/03/2013 09:00, Roberto Oppedisano ha scritto:
> > Hello
> >     I'm observing this kind of boot failure when my laptop
> > is not docked; I didn't notice before because I seldom reboot
> > it when it's not connected to a docking station.
> >
> > The failure is reproducible at 80-90%, meaning that one boot
> > over 8-10 will complete also with the laptop undocked; it seems
> > that being attached to a power supply (via jack, not docking) or
> > on batteries makes no difference WRT this failure.

By the boot failure, are you referring the one that is partially
captured in screeshot3.png?  If so, we need full error messages (i.e.
the top of the stack trace) to see what happened. 

> following the results of a bisection:
> 
> b17b537ac1429a609addb55bf985f5ebfcf4ae7b is the first bad commit
> commit b17b537ac1429a609addb55bf985f5ebfcf4ae7b
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Tue Jan 15 13:23:44 2013 +0100
> 
>      ACPI / scan: Drop the second argument of acpi_device_unregister()
> 
>      Drop the second argument of acpi_device_unregister(), type, which is
>      not used by that function.
> 
>      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>      Acked-by: Toshi Kani <toshi.kani@hp.com>
>      Acked-by: Yinghai Lu <yinghai@kernel.org>
>      Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> 
> :040000 040000 13aeb8bccbd062e65bc3710bb426fe8ac7d0cad5 
> 17d4603977ea57133d149814dc34e274ca0c2deb M      drivers
> 
> Trying to revert this commit on current master gave me an error.
> 
> Let me know if you need more info or testing.

The above patch is just a cleanup, and should have no functional
changes.  There are quite a bit of changes made around that day, so it
might be the case that other patch around that day is causing your
problem...  In any case, can you capture the full error message and send
it to us?

Thanks,
-Toshi

Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected

[Roberto Oppedisano]

Il 14/03/2013 15:37, Toshi Kani ha scritto:
> By the boot failure, are you referring the one that is partially
> captured in screeshot3.png?

yes

> If so, we need full error messages (i.e.
> the top of the stack trace) to see what happened.

I'll try to get it, but it could take some time (I hope
to be able to work on it during next week end).

Kind regards
R

Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected

[Rafael J. Wysocki]

On Thursday, March 14, 2013 09:20:51 AM Roberto Oppedisano wrote:
> Hi
> 
> Il 11/03/2013 09:00, Roberto Oppedisano ha scritto:
> > Hello
> >     I'm observing this kind of boot failure when my laptop
> > is not docked; I didn't notice before because I seldom reboot
> > it when it's not connected to a docking station.
> >
> > The failure is reproducible at 80-90%, meaning that one boot
> > over 8-10 will complete also with the laptop undocked; it seems
> > that being attached to a power supply (via jack, not docking) or
> > on batteries makes no difference WRT this failure.
> 
> following the results of a bisection:
> 
> b17b537ac1429a609addb55bf985f5ebfcf4ae7b is the first bad commit
> commit b17b537ac1429a609addb55bf985f5ebfcf4ae7b
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Tue Jan 15 13:23:44 2013 +0100
> 
>      ACPI / scan: Drop the second argument of acpi_device_unregister()
> 
>      Drop the second argument of acpi_device_unregister(), type, which is
>      not used by that function.
> 
>      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>      Acked-by: Toshi Kani <toshi.kani@hp.com>
>      Acked-by: Yinghai Lu <yinghai@kernel.org>
>      Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> 
> :040000 040000 13aeb8bccbd062e65bc3710bb426fe8ac7d0cad5 
> 17d4603977ea57133d149814dc34e274ca0c2deb M      drivers
> 
> Trying to revert this commit on current master gave me an error.
> 
> Let me know if you need more info or testing.

As Toshi said, this particular commit doesn't make any functional changes.

Can you please verify if the immediately preceding commit
6af9a803f4d2e4137d9f74a8fc9af4857fbda001 works for you?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected

[Roberto Oppedisano]

Il 14/03/2013 18:27, Rafael J. Wysocki ha scritto:
> On Thursday, March 14, 2013 09:20:51 AM Roberto Oppedisano wrote:
> As Toshi said, this particular commit doesn't make any functional 
> changes. Can you please verify if the immediately preceding commit 
> 6af9a803f4d2e4137d9f74a8fc9af4857fbda001 works for you? Rafael 

I have checked out this commit and it is NOT working.

BTW I did find the same commit in my bisection log, and probably
it was a false negative (I tried a couple of boot for each working kernel
during bisectrion, probably it was not not enough).
I'm going to replay the bisection today; will report back ASAP, to see
if it ends in something which makes sense to you.

For reference the current bisect log.

it bisect start
# good: [19f949f52599ba7c3f67a5897ac6be14bfcb1200] Linux 3.8
git bisect good 19f949f52599ba7c3f67a5897ac6be14bfcb1200
# bad: [6dbe51c251a327e012439c4772097a13df43c5b8] Linux 3.9-rc1
git bisect bad 6dbe51c251a327e012439c4772097a13df43c5b8
# bad: [b274776c54c320763bc12eb035c0e244f76ccb43] Merge tag 'cleanup' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad b274776c54c320763bc12eb035c0e244f76ccb43
# bad: [a0b1c42951dd06ec83cc1bc2c9788131d9fefcd8] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect bad a0b1c42951dd06ec83cc1bc2c9788131d9fefcd8
# good: [98d5fac2330779e6eea6431a90b44c7476260dcc] Merge branch 'master' 
of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next 
into for-davem
git bisect good 98d5fac2330779e6eea6431a90b44c7476260dcc
# good: [8a3a11f91def34424b1995cb54ccd658efde8568] Merge tag 
'pinctrl-for-v3.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
git bisect good 8a3a11f91def34424b1995cb54ccd658efde8568
# bad: [10baf04e95fbf7eb6089410220a547211dd2ffa7] Merge branch 'release' 
of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux
git bisect bad 10baf04e95fbf7eb6089410220a547211dd2ffa7
# bad: [3757b94802fb65d8f696597a74053cf21738da0b] ACPI / hotplug: Fix 
concurrency issues and memory leaks
git bisect bad 3757b94802fb65d8f696597a74053cf21738da0b
# bad: [64e94e7e0ffb20ee11a596aa04fcdeefb33e000d] Merge branch 
'acpi-scan' into acpi-cleanup
git bisect bad 64e94e7e0ffb20ee11a596aa04fcdeefb33e000d
# bad: [993cbe595dda731471a07f4f65575fadedc570dc] ACPI / PM: Take order 
attribute of wakeup power resources into account
git bisect bad 993cbe595dda731471a07f4f65575fadedc570dc
# good: [e0ebda2ee12c261fb2f2d7abf21489b93d9caa4e] ACPI: Remove unused 
struct acpi_pci_root.id member
git bisect good e0ebda2ee12c261fb2f2d7abf21489b93d9caa4e
# bad: [05404d8f7b5c831e1a2c24bb782f0fe8ea02354c] ACPI / scan: Add 
second pass to acpi_bus_trim()
git bisect bad 05404d8f7b5c831e1a2c24bb782f0fe8ea02354c
# good: [6af9a803f4d2e4137d9f74a8fc9af4857fbda001] ACPI: Remove the ops 
field from struct acpi_device <---- BAD
git bisect good 6af9a803f4d2e4137d9f74a8fc9af4857fbda001
# bad: [ae281795ec92d35dd1631401829124acab965b1f] ACPI / scan: Drop the 
second argument of acpi_bus_trim()
git bisect bad ae281795ec92d35dd1631401829124acab965b1f
# bad: [b17b537ac1429a609addb55bf985f5ebfcf4ae7b] ACPI / scan: Drop the 
second argument of acpi_device_unregister()
git bisect bad b17b537ac1429a609addb55bf985f5ebfcf4ae7b

Kind regards
R

Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected

[Roberto Oppedisano]

Hi!

Il 15/03/2013 10:42, Roberto Oppedisano ha scritto:
> Il 14/03/2013 18:27, Rafael J. Wysocki ha scritto:
>> On Thursday, March 14, 2013 09:20:51 AM Roberto Oppedisano wrote:
>> As Toshi said, this particular commit doesn't make any functional 
>> changes. Can you please verify if the immediately preceding commit 
>> 6af9a803f4d2e4137d9f74a8fc9af4857fbda001 works for you? Rafael 
>
> I have checked out this commit and it is NOT working.
>
> BTW I did find the same commit in my bisection log, and probably
> it was a false negative (I tried a couple of boot for each working kernel
> during bisectrion, probably it was not not enough).
> I'm going to replay the bisection today; will report back ASAP, to see
> if it ends in something which makes sense to you. 

Here's the new suspect:

f95988de06ea62ef5bd861f06e9ef56cea405ed1 is the first bad commit
commit f95988de06ea62ef5bd861f06e9ef56cea405ed1
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Mon Jan 7 21:17:02 2013 +0100

     ACPI / scan: Treat power resources in a special way

     Commit 805d410 (ACPI: Separate adding ACPI device objects from
     probing ACPI drivers) introduced an ACPI power resources management
     regression, because it didn't ensure that the power resources
     driver bind to the struct acpi_device objects corresponding
     to power resources as soon as they were created.  As a result,
     ACPI power management routines may attempt to access power resource
     objects before they are ready to use.

     To fix this problem, tell the acpi_add_single_object() in
     acpi_bus_check_add() to probe the driver for objects of type
     ACPI_BUS_TYPE_POWER.  This fix has been verified to work on
     HP nx6325 where the problem was first observed.

     Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
     Acked-by: Toshi Kani <toshi.kani@hp.com>

:040000 040000 08e5a8e11fcedcc29ce23883f8362c33d0ea8b3e 
fb5193b97b2000b40eea39cef794d81aac1367b8 M      drivers

Trying to revert this commit on current Linus master gave me an error.
For reference here's the bisection log.

git bisect start
# good: [19f949f52599ba7c3f67a5897ac6be14bfcb1200] Linux 3.8
git bisect good 19f949f52599ba7c3f67a5897ac6be14bfcb1200
# bad: [6dbe51c251a327e012439c4772097a13df43c5b8] Linux 3.9-rc1
git bisect bad 6dbe51c251a327e012439c4772097a13df43c5b8
# bad: [b274776c54c320763bc12eb035c0e244f76ccb43] Merge tag 'cleanup' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad b274776c54c320763bc12eb035c0e244f76ccb43
# bad: [a0b1c42951dd06ec83cc1bc2c9788131d9fefcd8] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect bad a0b1c42951dd06ec83cc1bc2c9788131d9fefcd8
# good: [98d5fac2330779e6eea6431a90b44c7476260dcc] Merge branch 'master' 
of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next 
into for-davem
git bisect good 98d5fac2330779e6eea6431a90b44c7476260dcc
# good: [8a3a11f91def34424b1995cb54ccd658efde8568] Merge tag 
'pinctrl-for-v3.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
git bisect good 8a3a11f91def34424b1995cb54ccd658efde8568
# bad: [10baf04e95fbf7eb6089410220a547211dd2ffa7] Merge branch 'release' 
of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux
git bisect bad 10baf04e95fbf7eb6089410220a547211dd2ffa7
# bad: [3757b94802fb65d8f696597a74053cf21738da0b] ACPI / hotplug: Fix 
concurrency issues and memory leaks
git bisect bad 3757b94802fb65d8f696597a74053cf21738da0b
# bad: [64e94e7e0ffb20ee11a596aa04fcdeefb33e000d] Merge branch 
'acpi-scan' into acpi-cleanup
git bisect bad 64e94e7e0ffb20ee11a596aa04fcdeefb33e000d
# bad: [993cbe595dda731471a07f4f65575fadedc570dc] ACPI / PM: Take order 
attribute of wakeup power resources into account
git bisect bad 993cbe595dda731471a07f4f65575fadedc570dc
# good: [e0ebda2ee12c261fb2f2d7abf21489b93d9caa4e] ACPI: Remove unused 
struct acpi_pci_root.id member
git bisect good e0ebda2ee12c261fb2f2d7abf21489b93d9caa4e
# bad: [05404d8f7b5c831e1a2c24bb782f0fe8ea02354c] ACPI / scan: Add 
second pass to acpi_bus_trim()
git bisect bad 05404d8f7b5c831e1a2c24bb782f0fe8ea02354c
# bad: [6af9a803f4d2e4137d9f74a8fc9af4857fbda001] ACPI: Remove the ops 
field from struct acpi_device
git bisect bad 6af9a803f4d2e4137d9f74a8fc9af4857fbda001
# bad: [abe99210e0f624cea39f1dc375ba818b201c0d7f] ACPI / scan: Fix check 
of device_attach() return value.
git bisect bad abe99210e0f624cea39f1dc375ba818b201c0d7f
# bad: [f95988de06ea62ef5bd861f06e9ef56cea405ed1] ACPI / scan: Treat 
power resources in a special way
git bisect bad f95988de06ea62ef5bd861f06e9ef56cea405ed1

Hope it's useful.
R

Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected

[Rafael J. Wysocki]

On Friday, March 15, 2013 02:10:24 PM Roberto Oppedisano wrote:
> Hi!
> 
> Il 15/03/2013 10:42, Roberto Oppedisano ha scritto:
> > Il 14/03/2013 18:27, Rafael J. Wysocki ha scritto:
> >> On Thursday, March 14, 2013 09:20:51 AM Roberto Oppedisano wrote:
> >> As Toshi said, this particular commit doesn't make any functional 
> >> changes. Can you please verify if the immediately preceding commit 
> >> 6af9a803f4d2e4137d9f74a8fc9af4857fbda001 works for you? Rafael 
> >
> > I have checked out this commit and it is NOT working.
> >
> > BTW I did find the same commit in my bisection log, and probably
> > it was a false negative (I tried a couple of boot for each working kernel
> > during bisectrion, probably it was not not enough).
> > I'm going to replay the bisection today; will report back ASAP, to see
> > if it ends in something which makes sense to you. 
> 
> Here's the new suspect:
> 
> f95988de06ea62ef5bd861f06e9ef56cea405ed1 is the first bad commit
> commit f95988de06ea62ef5bd861f06e9ef56cea405ed1
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Mon Jan 7 21:17:02 2013 +0100
> 
>      ACPI / scan: Treat power resources in a special way

In that case, please try to comment out the following two lines:

	device_set_wakeup_capable(dev, true);
	acpi_pci_sleep_wake(pci_dev, false);

in pci_acpi_setup() in drivers/pci/pci-acpi.c and see if that improves things
for you.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected

[Roberto Oppedisano]

Il 15/03/2013 18:13, Rafael J. Wysocki ha scritto:
>> Here's the new suspect:
>>
>> f95988de06ea62ef5bd861f06e9ef56cea405ed1 is the first bad commit
>> commit f95988de06ea62ef5bd861f06e9ef56cea405ed1
>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> Date:   Mon Jan 7 21:17:02 2013 +0100
>>
>>       ACPI / scan: Treat power resources in a special way
> In that case, please try to comment out the following two lines:
>
> 	device_set_wakeup_capable(dev, true);
> 	acpi_pci_sleep_wake(pci_dev, false);
>
> in pci_acpi_setup() in drivers/pci/pci-acpi.c and see if that improves things
> for you.

Current git still hangs with those two lines commented out.

Kind regards
R

Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected

[Rafael J. Wysocki]

On Saturday, March 16, 2013 08:10:11 AM Roberto Oppedisano wrote:
> Il 15/03/2013 18:13, Rafael J. Wysocki ha scritto:
> >> Here's the new suspect:
> >>
> >> f95988de06ea62ef5bd861f06e9ef56cea405ed1 is the first bad commit
> >> commit f95988de06ea62ef5bd861f06e9ef56cea405ed1
> >> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >> Date:   Mon Jan 7 21:17:02 2013 +0100
> >>
> >>       ACPI / scan: Treat power resources in a special way
> > In that case, please try to comment out the following two lines:
> >
> > 	device_set_wakeup_capable(dev, true);
> > 	acpi_pci_sleep_wake(pci_dev, false);
> >
> > in pci_acpi_setup() in drivers/pci/pci-acpi.c and see if that improves things
> > for you.
> 
> Current git still hangs with those two lines commented out.

What about commenting out the entire contents of pci_acpi_setup(), then?

Also, please send the output of acpidump from the affected machine.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected

[Roberto Oppedisano]

Il 17/03/2013 01:59, Rafael J. Wysocki ha scritto:
> On Saturday, March 16, 2013 08:10:11 AM Roberto Oppedisano wrote:
>> Il 15/03/2013 18:13, Rafael J. Wysocki ha scritto:
>>>> Here's the new suspect:
>>>>
>>>> f95988de06ea62ef5bd861f06e9ef56cea405ed1 is the first bad commit
>>>> commit f95988de06ea62ef5bd861f06e9ef56cea405ed1
>>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>> Date:   Mon Jan 7 21:17:02 2013 +0100
>>>>
>>>>        ACPI / scan: Treat power resources in a special way
>>> In that case, please try to comment out the following two lines:
>>>
>>> 	device_set_wakeup_capable(dev, true);
>>> 	acpi_pci_sleep_wake(pci_dev, false);
>>>
>>> in pci_acpi_setup() in drivers/pci/pci-acpi.c and see if that improves things
>>> for you.
>> Current git still hangs with those two lines commented out.
> What about commenting out the entire contents of pci_acpi_setup(), then?

Still no luck, still hangs at boot.

> Also, please send the output of acpidump from the affected machine.

You can find acpidump and dmesg at:

http://62.196.71.254/kernel/acpidump.gz
http://62.196.71.254/kernel/dmesg.txt.gz

I noticed that booting with serial console enabled succeeds also with 
failing kernels;
I've to do more testing to see if it's a 100% success ratio.

dmesg is relative to vanilla current git kernel, booted without docking 
station and with serial
console enabled. Inside it you can find some acpi related error; I don't 
know if they're relevant.

Kind regards
R

Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected

[Rafael J. Wysocki]

On Sunday, March 17, 2013 09:32:31 AM Roberto Oppedisano wrote:
> Il 17/03/2013 01:59, Rafael J. Wysocki ha scritto:
> > On Saturday, March 16, 2013 08:10:11 AM Roberto Oppedisano wrote:
> >> Il 15/03/2013 18:13, Rafael J. Wysocki ha scritto:
> >>>> Here's the new suspect:
> >>>>
> >>>> f95988de06ea62ef5bd861f06e9ef56cea405ed1 is the first bad commit
> >>>> commit f95988de06ea62ef5bd861f06e9ef56cea405ed1
> >>>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >>>> Date:   Mon Jan 7 21:17:02 2013 +0100
> >>>>
> >>>>        ACPI / scan: Treat power resources in a special way
> >>> In that case, please try to comment out the following two lines:
> >>>
> >>> 	device_set_wakeup_capable(dev, true);
> >>> 	acpi_pci_sleep_wake(pci_dev, false);
> >>>
> >>> in pci_acpi_setup() in drivers/pci/pci-acpi.c and see if that improves things
> >>> for you.
> >> Current git still hangs with those two lines commented out.
> > What about commenting out the entire contents of pci_acpi_setup(), then?
> 
> Still no luck, still hangs at boot.
> 
> > Also, please send the output of acpidump from the affected machine.
> 
> You can find acpidump and dmesg at:
> 
> http://62.196.71.254/kernel/acpidump.gz
> http://62.196.71.254/kernel/dmesg.txt.gz
> 
> I noticed that booting with serial console enabled succeeds also with 
> failing kernels;
> I've to do more testing to see if it's a 100% success ratio.
> 
> dmesg is relative to vanilla current git kernel, booted without docking 
> station and with serial
> console enabled. Inside it you can find some acpi related error; I don't 
> know if they're relevant.

Thanks for the files.

Please try to boot with initcall_debug in the kernel command line and see
if that works around the problem and if not, whether or not it provides a
clue about the point where boot is stuck (and if that point is always the
same).

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected

[Roberto Oppedisano]

Il 18/03/2013 00:27, Rafael J. Wysocki ha scritto:
>
> Please try to boot with initcall_debug in the kernel command line and see
> if that works around the problem and if not, whether or not it provides a
> clue about the point where boot is stuck (and if that point is always the
> same).

initcall_debug makes no difference.
Going back to console=ttyS0 it seems that enabling serial console
gives a 100% boot success ratio. Unfortunately this means that I
can't capture the error with a serial console. This evening I'll
try with a 60 fps camera to see if I can get more info.

Regarding the point of failure I see that sometimes the boot is
stuck with an empty screen, sometimes it outputs the attended
stack trace (always booting with the same kernel command line
obviously).

Kind regards
R