[PATCH] Remove 9 second reboot delay on Lenovo T400/T500
in [Kernel]
|
Prev: [PATCH 2/3] tracing: Remove ksym tracer
Next: [PATCH] x86,setup: add serial_console_port_base in boot_params
From: Henrique de Moraes Holschuh on 15 Jul 2010 18:40 On Wed, 14 Jul 2010, Matthew Garrett wrote: > There's two possibilities here: > > 1) Lenovo's firmware is broken and the 9-second delay is always going to > be there. In that case we should try to use the ACPI reboot vector > first. Or maybe we should key into whatever OSI() the ACPI firmware asked, and try first whatever shutdown path the highest version of Windows asked for by the firmware would. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Henrique de Moraes Holschuh on 15 Jul 2010 19:10 On Thu, 15 Jul 2010, Matthew Garrett wrote: > On Thu, Jul 15, 2010 at 07:31:49PM -0300, Henrique de Moraes Holschuh wrote: > > Or maybe we should key into whatever OSI() the ACPI firmware asked, and try > > first whatever shutdown path the highest version of Windows asked for by the > > firmware would. > > I've been tracing how Windows implements reboots (XP, Vista and 7). It > appears to use the ACPI reboot vector, the keyboard controller, the ACPI > reboot vector again, the keyboard controller again and then hangs. I'll > try implementing equivalent behaviour in Linux and see whether it makes > any difference. Icky. It doesn't happen always, but this time it does looks like we will NOT be better off doing whatever Windows is doing. Do you want to escalate this to Lenovo? I need a clear and consise description of the problem and the boxes we know to be affected. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Henrique de Moraes Holschuh on 15 Jul 2010 23:10 On Fri, 16 Jul 2010, Matthew Garrett wrote: > On Thu, Jul 15, 2010 at 08:00:23PM -0300, Henrique de Moraes Holschuh wrote: > > Do you want to escalate this to Lenovo? I need a clear and consise > > description of the problem and the boxes we know to be affected. > > Well, right now we're not doing precisely what Windows does. The other > possibility is that when the keyboard controller write triggers some SMM > code, it makes an assumption about some piece of hardware state that > isn't true and loops for a while to see if it changes. If we knew what > that was then we could ensure that we're performing the same state > change on our way down to reboot. > > One thing that would be worth checking is whether performing the > keyboard controller writes from userspace with a minimal kernel and > init=/bin/bash shows the 9-second pause or not - and then, ideally, see > whether the same is also true under DOS. I can't help much there, as the only hardware I have is a ThinkPad T43. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Henrique de Moraes Holschuh on 16 Jul 2010 21:30
On Fri, 16 Jul 2010, Matthew Garrett wrote: > 1) The ACPI reboot vector reboots these machines instantly, but the flag > that indicates we should use it isn't set. > 2) Windows takes 9 seconds to reboot on the same hardware. > > It just sounds like broken firmware. I'm confused. Is it the PCI reboot vector, or the ACPI reboot vector that acts instantly? The bug reporters say that they use reboot=pci to have instant reboot, in this thread... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |