The laptop won't reboot, just hanging on Restarting system. machine reboot. Poweroff works as expected. Is there any chance to debug it without bisecting? Rc3 was the first .39 kernel I've tried, so the problem is likely also present in rc1.
Created attachment 54442 [details] Kernel config
Created attachment 54452 [details] dmesg
Created attachment 54462 [details] dmidecode
*** Bug 33442 has been marked as a duplicate of this bug. ***
Same behaviour on HP/Compaq nx6310
Created attachment 54602 [details] dmesg from nx6310
Please check if reverting any of these commits helps: commit 6734fe57a07b2dd23ef1ef2ac1f790747e53eefc Author: Matthew Garrett <mjg@redhat.com> Date: Fri Mar 11 16:12:19 2011 -0500 ACPI: Bug compatibility for Windows on the ACPI reboot vector commit f17d9cbf20c4734c4199caa6dee87047f2f8278f Author: Matthew Garrett <mjg@redhat.com> Date: Fri Mar 11 16:12:18 2011 -0500 ACPICA: Fix access width for reset vector
does booting with "reboot=kbd" help?
How are you using ACPI for rebooting? dmesg doesn't show you requesting it, the patch to make it default isn't upstream yet and your machine is DMI quirked to jump to the BIOS for reboot.
re dmesg for nx7300 in comment #2 > HP Compaq Laptop series board detected. Selecting BIOS-method for reboots. Matthew speaks the truth. This box is quirked to not use ACPI for reboot at all... re: dmesg for nx6310 in comment #6 same situation: > HP Compaq Laptop series board detected. Selecting BIOS-method for reboots. indeed the quirk to use BIOS reboot is dangerously vague: { /* Handle problems with rebooting on HP laptops */ .callback = set_bios_reboot, .ident = "HP Compaq Laptop", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq"), }, }
curiously, reboot=bios is #ifdef CONFIG_X86_32 I wonder if 64-bit kernels have a similar regression on these boxes.
1. 2.6.39-rc5 + revert 6734fe57a07b2dd23ef1ef2ac1f790747e53eefc doesn't help. 2. 2.6.39-rc5 + revert f17d9cbf20c4734c4199caa6dee87047f2f8278f doesn't help. 3. reboot=kbd doesn't help. Regards
Hey, sorry for the pause. Maciej: Thanks for testing! Len: This thing only supports Intel Core, not Core2, so no x86_64. Yeah, it turns out, it's not really ACPI-related, but I guess there is no point moving it now, right? Anyway, it seems I'll have to start bisecting now.
And it did not take long at all, -rc5 worked after reverting ee1b06ea6aed979da3b4e6b6ffea98ad55a3c5c1 x86, reboot: Fix the use of passed arguments in 32-bit BIOS reboot 3d35ac346e981162eeba391e496faceed4753e7b x86, reboot: Move the real-mode reboot code to an assembly file
Ok, I've got an other symptom. After applying the patches, the display resumed to power off on idle. So it's not the reboot code that broke. The only thing I see is that now you are placing the reboot code in .section ".x86_trampoline","a".
s/applying/reverting/, of course.
First-Bad-Commit : 3d35ac346e981162eeba391e496faceed4753e7b
Created attachment 56022 [details] Proposed fix Alexey: please try the attached patch.
Negative.
On 05/01/2011 03:47 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=33302 > > > > > > --- Comment #19 from Alexey Zaytsev <alexey.zaytsev@gmail.com> 2011-05-01 > 10:47:28 --- > Negative. > "Negative" meaning what? -hpa
It did not help. Sorry for being ambiguous.
> It did not help. Sorry for being ambiguous. Uck. I was able to reproduce the problem on one test rig, and there this patch did work as intended. This now means I am at a bit of a loss how to attempt to address the residual problem... -hpa
Double-checking.
Yes/no/maybe?
The bugzilla timed out the last few times I tried to post. ;) Shame on me, it worked. Thanks a lot for fixing!
Handled-By : H. Peter Anvin <hpa@zytor.com> Patch : https://bugzilla.kernel.org/attachment.cgi?id=56022
Fixed by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7806a49ab625ebeb1709e5e87299b64932b807a7