Prev: [PATCH] Drivers: net: 8139cp: Fixed 28 style errors, and 119 warnings.
Next: any value in running my kernel scanning scripts before release?
From: Matthew Garrett on 15 Jul 2010 19:00
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 | mjg59(a)srcf.ucam.org
--
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: Matthew Garrett on 15 Jul 2010 19:10
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 | mjg59(a)srcf.ucam.org
--
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: Matthew Garrett on 16 Jul 2010 16:10
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 | mjg59(a)srcf.ucam.org
--
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: Matthew Garrett on 16 Jul 2010 21:30
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 | mjg59(a)srcf.ucam.org
--
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/
 | 
Pages: 1
Prev: [PATCH] Drivers: net: 8139cp: Fixed 28 style errors, and 119 warnings.
Next: any value in running my kernel scanning scripts before release?