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
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 <[email protected]>
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 <[email protected]>
Acked-by: Toshi Kani <[email protected]>
Acked-by: Yinghai Lu <[email protected]>
Acked-by: Yasuaki Ishimatsu <[email protected]>
: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
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 <[email protected]>
> 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 <[email protected]>
> Acked-by: Toshi Kani <[email protected]>
> Acked-by: Yinghai Lu <[email protected]>
> Acked-by: Yasuaki Ishimatsu <[email protected]>
>
> :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
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 <[email protected]>
> 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 <[email protected]>
> Acked-by: Toshi Kani <[email protected]>
> Acked-by: Yinghai Lu <[email protected]>
> Acked-by: Yasuaki Ishimatsu <[email protected]>
>
> :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.
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
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
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 <[email protected]>
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 <[email protected]>
Acked-by: Toshi Kani <[email protected]>
: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
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 <[email protected]>
> 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.
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 <[email protected]>
>> 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
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 <[email protected]>
> >> 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.
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 <[email protected]>
>>>> 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
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 <[email protected]>
> >>>> 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.
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