Re: [GIT PULL] x86 fixes

[Ingo Molnar]

* H. Peter Anvin <hpa@xxxxxxxxx> wrote:

> On 10/12/2013 11:05 AM, Linus Torvalds wrote:
> > On Sat, Oct 12, 2013 at 10:15 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> >>
> >> Ville Syrjälä (1):
> >>       x86/reboot: Add reboot quirk for Dell Latitude E5410
> > 
> > So we have a number of these quirks, and Dell seems to be one of the
> > more common factors.

I raised this with hpa when the latest round of Dell quirks were added, 
but I agree that the quirk frequency sucks (for every quirk there's likely 
5 times as many boxes still out there that we haven't applied a quirk for 
yet ...) and I agree that this needs to be discussed more widely.

> > Now, I'd suggest we just trigger it automatically for Dell, but the 
> > thing is, Dell tends to be the *least* differentiating PC maker out 
> > there, so I'm wondering if it is our default reboot order that is just 
> > plain wrong.
> > 
> > We start off trying to reboot using ACPI. Is that really sane? Is 
> > there any reason to not make the default case be to use the PCI 
> > reboot?
> 
> We tried it, it broke too many systems.  However, I'm seriously 
> considering it for the case of Dell specificall.
> 
> The problem with Dell is that they are using something unusual like the 
> KBC to reboot, *and* apparently it is broken when VT-d is enabled.  This 
> may becase the versions of Windows they're testing on aren't using it, 
> or because they "expect" the OS to disable VT-d before shutdown.

If Windows doesn't use and enable VT-d then we probably should not use it 
either, or we should _at minimum_ disable VT-d again when we shut down.

I.e. if possible we should leave the hardware roughly in the state we got 
it from the firmware, that leads probably to the least amount of 
surprises.

So I'd be tempted to just not use IRQ remapping until this is cleared up 
and fixed properly. I.e. don't quirk the reboot method, quirk VT-d ...

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/