[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwiO2kcNF4=ph9UWhPB7Vd6sRZ5B6g7qFV2yAwKBLP+2Q@mail.gmail.com>
Date: Fri, 4 Apr 2014 09:09:32 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Matthew Garrett <mjg59@...f.ucam.org>
Cc: "Li, Aubrey" <aubrey.li@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [BUG] x86: reboot doesn't reboot
On Fri, Apr 4, 2014 at 8:45 AM, Matthew Garrett <mjg59@...f.ucam.org> wrote:
>
> Which is almost certainly because the other reboot methods are trapping
> into SMI and hitting some hardware that we've left in a different state
> to Windows.
Why are you making up these completely invalid arguments? Because you
are making them up.
Our default reboot type is REBOOT_ACPI. That's the one we try *first*.
There are no "other reboot methods" playing games.
And it fails on tons of machines. It shouldn't be failing, but it is.
We are doing something sufficiently different from Windows that it
doesn't work. At some point there was some talk about having enabled
VT-d at boot but not disabled it before reboot, but that's just one
theory.
And given this *fact*, your denial that "PCI reboot should never be
used" is counterfactual. It may be true in some theoretical "this is
how the world should work" universe, but in the real world it is just
BS.
Why are you so deep in denial about this?
I'd love to fix whatever environment issue it is that causes this.
Last time people came up with situations, I offered to test patches,
because I have access to one of the failing Dell machines. Crickets.
Linus
--
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