[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <533ED247.9040602@zytor.com>
Date: Fri, 04 Apr 2014 08:39:51 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Matthew Garrett <mjg59@...f.ucam.org>
CC: "Li, Aubrey" <aubrey.li@...ux.intel.com>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [BUG] x86: reboot doesn't reboot
On 04/04/2014 08:36 AM, Matthew Garrett wrote:
> On Fri, Apr 04, 2014 at 08:13:48AM -0700, H. Peter Anvin wrote:
>> On 04/04/2014 08:12 AM, Matthew Garrett wrote:
>>> On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
>>>
>>>> The current situation is,
>>>> - we have one(do we know more?) preproduction machine hangs by CF9.
>>>> - We have more than one(could be thousand known) production machine
>>>> works by CF9.
>>>
>>> Production hardware should never require CF9.
>>>
>>
>> There are a lot of things that shouldn't be.
>
> Windows doesn't hit CF9, and production hardware is always tested with
> Windows, so. Adding CF9 may make things work in some situations but it
> clearly breaks them in others - we'd be better off spending our time
> figuring out why systems that appear to need CF9 won't otherwise work.
>
There are several platforms where the default boot method invokes an SMM
handler which blithly assumes that the hardware is in whatever state
Windows leaves it in, and hangs otherwise. This seems to include nearly
all Dell systems. So it isn't really quite that simple...
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists