Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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.wyso...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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.wyso...@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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 > >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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.wyso...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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.wyso...@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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 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 Acked-by: Toshi Kani :04 04 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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.wyso...@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.wyso...@intel.com Acked-by: Toshi Kani toshi.k...@hp.com :04 04 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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.wyso...@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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 > 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 > Acked-by: Toshi Kani > Acked-by: Yinghai Lu > Acked-by: Yasuaki Ishimatsu > > :04 04 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 > 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 > Acked-by: Toshi Kani > Acked-by: Yinghai Lu > Acked-by: Yasuaki Ishimatsu > > :04 04 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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 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 Acked-by: Toshi Kani Acked-by: Yinghai Lu Acked-by: Yasuaki Ishimatsu :04 04 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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.wyso...@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.wyso...@intel.com Acked-by: Toshi Kani toshi.k...@hp.com Acked-by: Yinghai Lu ying...@kernel.org Acked-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com :04 04 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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.wyso...@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.wyso...@intel.com Acked-by: Toshi Kani toshi.k...@hp.com Acked-by: Yinghai Lu ying...@kernel.org Acked-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com :04 04 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: Fixing recursive fault but reboot is needed at boot on HP 6730B - bisected
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.wyso...@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.wyso...@intel.com Acked-by: Toshi Kani toshi.k...@hp.com Acked-by: Yinghai Lu ying...@kernel.org Acked-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com :04 04 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
