Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80on some AMD64x2 laptops, etc.

[David P. Reed]

The process of safely making delicate changes here is beyond my 
responsibility as just a user - believe me, I'm not suggesting that a 
risky fix be put in .24.   I can patch my own kernels, and I can even 
share an unofficial patch with others for now, or suggest that Fedora 
and Ubuntu add it to their downstream.

May I make a small suggestion, though.   If the decision is a DMI-keyed 
switch from out-80 to udelay(2)  gets put in, perhaps there should also 
be a way for people to test their own configuration for the underlying 
problem made available as a script.   Though it is a "hack", all you 
need to freeze a problem system is to run a loop doing about 1000 "cat 
/dev/nvram > /dev/null"  commands.  If that leads to a freeze, one might 
ask to have the motherboard added to the DMI-key list.

H. Peter Anvin wrote:
> Ingo Molnar wrote:
> > * H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> >
> > > Pavel Machek wrote:
> > > > > this is also something for v2.6.24 merging.
> > > > As much as I like this patch, I do not think it is suitable for
> > > > .24. Too risky, I'd say.
> > > No kidding!  We're talking about removing a hack that has been 
> > > successful on thousands of pieces of hardware over 15 years because it 
> >                                                              ^----[*]
> > > breaks ONE machine.
> >
> > [*] "- none of which needs it anymore -"
> >
> > there, fixed it for you ;-)
> >
> > So lets keep this in perspective: this is a hack that only helps on a 
> > very low number of systems. (the PIT of one PII era chipset is known 
> > to be affected)
>
> Yes, but the status quo has been *tested* on thousands of systems and 
> is known to work.  Thus, changing it puts things into unknown 
> territory, even if only a small number of machines actually need the 
> current configuration.
>
> Heck, there are only a small number of 386/486 machines still in 
> operation and being actively updated.
>
> > unfortunately this hack's side-effects are mis-used by an unknown 
> > number of drivers to mask PCI posting bugs. We want to figure out 
> > those bugs (safely and carefully) and we want to remove this hack 
> > from modern machines that dont need it. Doing anything else would be 
> > superstition.
> >
> > anyway, we likely wont be doing anything about this in .24.
>
> Again, 24 is "right out".  25 is a "maybe", IMO.  Rene's fix could be 
> an exception, since it is a DMI-keyed workaround for a specific 
> machine and doesn't change behaviour in general.
>
>     -hpa
--
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/