On Wed, Jul 14, 2010 at 03:33:08PM +0100, Pedro Ribeiro wrote:
> Please consider this patch. Let me know if you would like me to change
> anything or if you don't agree with it. It applies cleanly to 2.6.35-rc5.
>
> The Lenovo T400 and T500 have an annoying 9 second delay when
> rebooting, unless reboot=pci is passed to the kernel command line.
> This delay happens from at least kernel 2.6.20.
>
> Make this change permanent by hardcoding the Tx00 on the
> arch/kernel/reboot.c pci quirks table.
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.
2) We're doing something wrong in our shutdown sequence which then
triggers this problem as a result.
Either way, I think this patch is wrong.
--
Matthew Garrett | [email protected]
On 14 July 2010 15:36, Matthew Garrett <[email protected]> wrote:
> On Wed, Jul 14, 2010 at 03:33:08PM +0100, Pedro Ribeiro wrote:
>> ?Please consider this patch. Let me know if you would like me to change
>> ?anything or if you don't agree with it. It applies cleanly to 2.6.35-rc5.
>>
>> ?The Lenovo T400 and T500 have an annoying 9 second delay when
>> ?rebooting, unless reboot=pci is passed to the kernel command line.
>> ?This delay happens from at least kernel 2.6.20.
>>
>> ?Make this change permanent by hardcoding the Tx00 on the
>> ?arch/kernel/reboot.c pci quirks table.
>
> 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.
>
> 2) We're doing something wrong in our shutdown sequence which then
> triggers this problem as a result.
>
> Either way, I think this patch is wrong.
>
> --
> Matthew Garrett | [email protected]
>
Hi Matthew,
by acpi reboot vector you mean using reboot=acpi?
I tried it and does not solve the problem.
Check here http://marc.info/?l=linux-kernel&m=127590255224570&w=2
Can you please tell me how to debug this?
Thanks,
Pedro
On 15:36 Wed 14 Jul , Matthew Garrett wrote:
> On Wed, Jul 14, 2010 at 03:33:08PM +0100, Pedro Ribeiro wrote:
> > The Lenovo T400 and T500 have an annoying 9 second delay when
> > rebooting, unless reboot=pci is passed to the kernel command line.
> > This delay happens from at least kernel 2.6.20.
[...]
> 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.
While it may be true that the firmware is buggy, reboot=acpi does not
solve the problem; reboot=pci does.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
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
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.
--
Matthew Garrett | [email protected]
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
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.
--
Matthew Garrett | [email protected]
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
On 16 July 2010 00:08, Matthew Garrett <[email protected]> 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.
>
> --
> Matthew Garrett | [email protected]
>
I'm available to try and test whatever you want on my machine .
Regards,
Pedro
Ok.
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.
--
Matthew Garrett | [email protected]
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
On Fri, Jul 16, 2010 at 10:23:04PM -0300, Henrique de Moraes Holschuh wrote:
> 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...
The PCI one, since it's a function of the chipset. The ACPI one would
act instantly (it's the PCI one, in this case) but it's marked as
unsupported. However, the PCI one is poorly standardised - Windows never
uses it, different chips have subtly different requirements and so on.
--
Matthew Garrett | [email protected]
On 17 July 2010 02:27, Matthew Garrett <[email protected]> wrote:
> On Fri, Jul 16, 2010 at 10:23:04PM -0300, Henrique de Moraes Holschuh wrote:
>
>> 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...
>
> The PCI one, since it's a function of the chipset. The ACPI one would
> act instantly (it's the PCI one, in this case) but it's marked as
> unsupported. However, the PCI one is poorly standardised - Windows never
> uses it, different chips have subtly different requirements and so on.
>
> --
> Matthew Garrett | [email protected]
>
So what should be done then? This is not the most annoying of bugs,
but still a bug.
Regards,
Pedro