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

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

[Robert Hancock]

David P. Reed wrote:
> PS: If I have time, I may try to build Rene's port 80 test for Windows 
> and run it under WinXP on this machine (I still have a crappy little 
> partition that boots it).   If it freezes the same way, it's almost 
> certain a design "feature", and if it doesn't freeze, we might suspect 
> that there is compensating logic in either Windows ACPI code or some way 
> that windows "sets up" the machine.

You'd have to replace the iopl call to an equivalent one for Windows 
(seems like NtSetInformationProcess(ProcessUserModeIOPL) might do what 
you need).

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

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

[Pavel Machek]

On Sun 2007-12-16 15:34:58, H. Peter Anvin wrote:
> Pavel Machek wrote:
>> Hi!
>>> 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.
>> Can you freeze it by catting /dev/rtc, too? That may be significant,
>> because that is readable for group audio (at least on some
>> systems)... which would smell like "small security hole" to me.
>
> Heck, on my system (Fedora 7), it's mode 644...

Ok, time to CC security team, I'd say.

Problem is, that some AMD64x2 nVidia laptops crash on port 0x80
access... which is easily user-triggerable by using /dev/rtc. If it is
644 on Fedora, I guess we have a problem.

Otoh, it is "only" a denial of service, and it can probably be
attributed to "buggy hardware". Is that still relevant for security team?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Avi Kivity]

David P. Reed wrote:
> Avi Kivity wrote:
>> kvm will forward a virtual machine's writes to port 0x80 to the real 
>> port.  The reason is that the write is much faster than exiting and 
>> emulating it; the difference is measurable when compiling kernels.
>>
>> Now if the cause is simply writing to port 0x80, then we must stop 
>> doing that.  But if the reason is the back-to-back writes, when we 
>> can keep it, since the other writes will be trapped by kvm and 
>> emulated.  Do you which is the case?
>>
> As for kvm, I don't have enough info to know anything about that.  Is 
> there a test you'd like me to try?
>

I have a test, but I see that it is broken for mainline.  I'll update it 
eventually, but...

> I think you are also asking if the crash on these laptops is caused 
> only by back-to-back writes.  Actually, it doesn't seem to matter if 
> they are back to back.  I can cause the crash if the writes to 80 are 
> very much spread out in time - it seems only to matter how many of 
> them get executed - almost as if there is a buffer overflow.  (And of 
> course if you do back to back writes to other ports that are 
> apparently fully unused, such as 0xED on my machine, no crash occurs).
>
> I believe (though no one seems to have confirming documentation from 
> the chipset or motherboard vendor) that port 80 is actually functional 
> for some unknown function on these machines.   (They do respond to 
> "in" instructions faster than a bus cycle abort does - more evidence).

That seems to be sufficient evidence for me to remove port 0x80 
pass-through from kvm and emulate it instead.  Given that port 80 writes 
take 1 microsecond, and that an in-kernel exit handler takes a similar 
amount of time, there won't be any significant performance loss.

-- 
error compiling committee.c: too many arguments to function

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

[Lennart Sorensen]

On Tue, Dec 18, 2007 at 12:06:08AM +0000, Alan Cox wrote:
> 300MHz 486 -> Nat Semi Geode.
> 
> NextGen as you say are 386 - 586 depending on the BIOS hypercode but I
> believe lack WP even in > 386 mode.

Geode identifies itself as family 5 though.  It may prefer 486 code but
it's still family 5.  Well Geode GX, SCx200 and LX that is.  I imagine
the Geode NX would be family 6.

--
Len Sorensen

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

[Alan Cox]

> > By the way, you have a 300 MHz 486? I believe 3 -> 40, 4 -> 133, 5 -> 233 
> > would be good? And I'm not really sure about the etc. P6 has a large range 
> > again...
> 
> Some nexgen 5x86 boxes were pretty fast, still could not do 486... so
> family 3 iirc.

300MHz 486 -> Nat Semi Geode.

NextGen as you say are 386 - 586 depending on the BIOS hypercode but I
believe lack WP even in > 386 mode.

Alan

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

[Pavel Machek]

On Mon 2007-12-17 22:04:19, Rene Herman wrote:
> On 15-12-07 00:29, Alan Cox wrote:
>
>>>> ?? Just initialize bogomips to 6GHz equivalent... and we are fine
>>>> until 6GHz cpus come out.
>>> How long will that take to boot on a 386?
>> Well the dumb approach to fix that would seem to be to initialise it to
>> 	cpu->family   3 -> 50MHz 4 -> 300Mhz 5-> etc...
>
> By the way, you have a 300 MHz 486? I believe 3 -> 40, 4 -> 133, 5 -> 233 
> would be good? And I'm not really sure about the etc. P6 has a large range 
> again...

Some nexgen 5x86 boxes were pretty fast, still could not do 486... so
family 3 iirc.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[H. Peter Anvin]

Jan Engelhardt wrote:
> On Dec 15 2007 17:46, Alan Cox wrote:
>>> My understanding is that the linux starts in real mode, and uses the 
>>> BIOS for such things as reading the very first image.   
>> Not always. We may enter from 32bit in some cases, and we may also not
>> have a PC BIOS in the first place.
> 
> Computers without a PC BIOS (I'm trying to think of something, e.g.
> the typical SUN sparc64 box) should have other means of accessing a
> clocksource, no?

We were talking about x86 here, though.

Even on x86 we sometimes run from the 32-bit entrypoint.

	-hpa

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

[Jan Engelhardt]

On Dec 15 2007 17:46, Alan Cox wrote:
>
>> My understanding is that the linux starts in real mode, and uses the 
>> BIOS for such things as reading the very first image.   
>
>Not always. We may enter from 32bit in some cases, and we may also not
>have a PC BIOS in the first place.

Computers without a PC BIOS (I'm trying to think of something, e.g.
the typical SUN sparc64 box) should have other means of accessing a
clocksource, no?

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

[Jan Engelhardt]

On Dec 14 2007 14:13, H. Peter Anvin wrote:
>> 
>> ?? Just initialize bogomips to 6GHz equivalent... and we are fine
>> until 6GHz cpus come out.
>
> How long will that take to boot on a 386?
>
Load it up in bochs and have look at the wallclock. I think that is a
good estimate when you have no real 386 nearby.

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

[Rene Herman]

On 15-12-07 00:29, Alan Cox wrote:

>>> ?? Just initialize bogomips to 6GHz equivalent... and we are fine
>>> until 6GHz cpus come out.
>> How long will that take to boot on a 386?
> 
> Well the dumb approach to fix that would seem to be to initialise it to
> 
> 	cpu->family   3 -> 50MHz 4 -> 300Mhz 5-> etc...

By the way, you have a 300 MHz 486? I believe 3 -> 40, 4 -> 133, 5 -> 233 
would be good? And I'm not really sure about the etc. P6 has a large range 
again...

Rene.

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

[Rene Herman]

On 17-12-07 19:14, linux-os (Dick Johnson) wrote:

> Attached is a patch that changes the outs to ins on port 0x80.

No, that isn't useful. Only a write is "guaranteed" to make ISA/LPC meaning 
the timing for a read varies wildly. See the in/out cycles results posted 
earlier. Was also reading the Intel PIIX(3) chiset datasheet today which 
specifically mentions that only writes flow through to ISA, reads do not.

Rene.

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

[linux-os (Dick Johnson)]

[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]


On Fri, 14 Dec 2007, David P. Reed wrote:

> Avi Kivity wrote:
>> kvm will forward a virtual machine's writes to port 0x80 to the real
>> port.  The reason is that the write is much faster than exiting and
>> emulating it; the difference is measurable when compiling kernels.
>>
>> Now if the cause is simply writing to port 0x80, then we must stop
>> doing that.  But if the reason is the back-to-back writes, when we can
>> keep it, since the other writes will be trapped by kvm and emulated.
>> Do you which is the case?
>>
> As for kvm, I don't have enough info to know anything about that.  Is
> there a test you'd like me to try?
>
> I think you are also asking if the crash on these laptops is caused only
> by back-to-back writes.  Actually, it doesn't seem to matter if they are
> back to back.  I can cause the crash if the writes to 80 are very much
> spread out in time - it seems only to matter how many of them get
> executed - almost as if there is a buffer overflow.  (And of course if
> you do back to back writes to other ports that are apparently fully
> unused, such as 0xED on my machine, no crash occurs).
>
> I believe (though no one seems to have confirming documentation from the
> chipset or motherboard vendor) that port 80 is actually functional for
> some unknown function on these machines.   (They do respond to "in"
> instructions faster than a bus cycle abort does - more evidence).
>
> I searched the DSDT to see if there is any evidence of an ACPI use for
> this port, but found nothing.
>
>

Attached is a patch that changes the outs to ins on port 0x80.
I did NOT let gcc decide what to do about modified registers.
Instead, the code saves/restores EAX itself so that all of the
times (whatever they are) are the same.

The code works and is running here. I also patched a very early
version (2.4.26) running on  a 400 MHz i486 with an real ISA
bus (Adaptec AHA1453). It works too.

David, will you please try it on your machine. Maybe reading
from the port is less harmful than writing.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.27 BogoMips).
My book : http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

[-- Attachment #2: io.h.patch --]
[-- Type: TEXT/PLAIN, Size: 429 bytes --]

--- linux-2.6.22.1/include/asm-i386/io.h.orig	2007-07-10 14:56:30.000000000 -0400
+++ linux-2.6.22.1/include/asm-i386/io.h	2007-12-17 12:06:10.000000000 -0500
@@ -252,7 +252,10 @@
 
 static inline void native_io_delay(void)
 {
-	asm volatile("outb %%al,$0x80" : : : "memory");
+	asm volatile(	"pushl %%eax\n\t"
+			"inb $0x80, %%al\n\t"
+			"popl %%eax\n\t"
+			 : : : "memory");
 }
 
 #if defined(CONFIG_PARAVIRT)

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

[Ingo Molnar]

* Robert Hancock <hancockr@shaw.ca> wrote:

>> 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.
>
> Are there any such examples known of such drivers? It doesn't seem to 
> make much sense.. PCI IO writes are not posted on any known system 
> (the spec allows them to be posted in the host bus bridge, but if they 
> were they could only be flushed by a read, not a write) and PCI MMIO 
> writes are only guaranteed to flush by doing a read from that device, 
> not by other random port accesses. I suppose using the _p versions of 
> port accesses might happen to mask such problems on certain machines..

yeah, that's the fear - that timing sensitivities or outright races are 
hidden via _p() uses. It's a bit like the BKL - nobody really knows why 
it's still needed in some places but there's "fear" that "stuff might 
break" so removal is very slow. So we should get rid of all _p() uses, 
by either removing them (concluding that the _p() was not needed), or by 
adding in an udelay(2) (documenting that the device indeed relies on the 
delay from the host side) or by adding whatever posting/flushing is 
needed. That will gradually reduce the amount of code that uses _p() 
methods, and will improve the quality of the kernel.

	Ingo

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

[Rene Herman]

On 16-12-07 22:43, H. Peter Anvin wrote:

> 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.

I've not much opinion on the schedule as I've not the problem but yes, it's 
intended as the low risk option.

Rene.

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

[Robert Hancock]

Ingo Molnar wrote:
> * H. Peter Anvin <hpa@zytor.com> 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)
> 
> 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.

Are there any such examples known of such drivers? It doesn't seem to 
make much sense.. PCI IO writes are not posted on any known system (the 
spec allows them to be posted in the host bus bridge, but if they were 
they could only be flushed by a read, not a write) and PCI MMIO writes 
are only guaranteed to flush by doing a read from that device, not by 
other random port accesses. I suppose using the _p versions of port 
accesses might happen to mask such problems on certain machines..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

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

[H. Peter Anvin]

Pavel Machek wrote:
> Hi!
> 
>> 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.
> 
> Can you freeze it by catting /dev/rtc, too? That may be significant,
> because that is readable for group audio (at least on some
> systems)... which would smell like "small security hole" to me.
> 									Pavel

Heck, on my system (Fedora 7), it's mode 644...

	-hpa

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

[Pavel Machek]

Hi!

> 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.

Can you freeze it by catting /dev/rtc, too? That may be significant,
because that is readable for group audio (at least on some
systems)... which would smell like "small security hole" to me.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on 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@zytor.com> 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
>

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

[H. Peter Anvin]

Ingo Molnar wrote:
> * H. Peter Anvin <hpa@zytor.com> 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

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

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> 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)

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.

	Ingo

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

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> Paul Rolland wrote:
>> Just an idea : from what I've read, the problem (port 80 hanging) only occurs
>> on 'modern' machines...
>
> It happens on *one single* "modern" machine...
>
> Let's keep that in perspective.

two or three i think (and an unknown of others where "random, 
unexplained freezes" were thought to be hw borkage), but yeah, it's 
still a very low proportion.

	Ingo

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

[H. Peter Anvin]

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.

If this should be done at all it should be done in the most careful 
manner possible.  2.6.25 would be an aggressive schedule.

	-hpa

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

[Pavel Machek]

On Fri 2007-12-14 14:15:03, Ingo Molnar wrote:
> 
> * David P. Reed <dpreed@reed.com> wrote:
> 
> > Replace use of outb to "unused" diagnostic port 0x80 for time delay 
> > with udelay based time delay on x86_64 architecture machines.  Fix for 
> > bugs 9511 and 6307 in bugzilla, plus bugs reported in 
> > bugzilla.redhat.com.
> >
> > Derived from suggestion (that didn't compile) by Pavel Machek, and 
> > tested, also based on measurements of typical timings of out's 
> > collated by Rene Herman from many in the community.
> >
> > This patch fixes a number of bugs known to cause problems on HP
> > Pavilion dv9000z and dv6000z laptops - in the form of solid freezes
> > when hwclock is used to show or set the time.  Also, it potentially
> > improves bus utilization on SMP machines, by using a waiting process
> > that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds.
> >
> > i386 family fixes (completely parallel) were not included, considering 
> > that such machines might involve more risk of problems on legacy 
> > machines.
> 
> wow, cool fix! (I remember that there were other systems as well that 
> are affected by port 0x80 muckery - i thought we had removed port 0x80 
> accesses long ago.)
> 
> how about the simpler fix below, as a first-level approach? We can then 
> remove the _p in/out sequences after this.
> 
> 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.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Pavel Machek]

On Fri 2007-12-14 15:23:55, Ingo Molnar wrote:
> 
> * Rene Herman <rene.herman@gmail.com> wrote:
> 
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -229,10 +229,9 @@ static int __init obsolete_checksetup(char *line)
> >  }
> >
> >  /*
> > - * This should be approx 2 Bo*oMips to start (note initial shift), and will
> > - * still work even if initially too large, it will just take slightly longer
> > + * Initial value roughly corresponds to a 1 GHz CPU
> >   */
> > -unsigned long loops_per_jiffy = (1<<12);
> > +unsigned long loops_per_jiffy = 1000000000 / HZ;
> >
> >  EXPORT_SYMBOL(loops_per_jiffy);
> 
> this is a factor of ~2400 increase - this will take an eternity to boot 
> on any older CPU.

I don't think we are using outb_p before loops_per_jiffy are
initialized -- I believe I'd see oopsen if we did. Factor 2400
increase is bad, but if it only converts 10x 1usec delay into 10x
24msec delay, it is not _that_ bad.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Pavel Machek]

On Sat 2007-12-15 12:26:26, H. Peter Anvin wrote:
> Paul Rolland wrote:
>> Just an idea : from what I've read, the problem (port 80 hanging) only 
>> occurs
>> on 'modern' machines...
>
> It happens on *one single* "modern" machine...
>
> Let's keep that in perspective.

it hurts on other machines (like debug leds being useless), and it may
be incorrect as soon as you insert leds-on-port-0x80-on-PCI card.

No, it is not critical but yes, I'd like to see it fixed.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[H. Peter Anvin]

Rene Herman wrote:
> 
> Yes, just posted a Patch-For-Comments that switches on the availability 
> of a TSC (tsc_init sets tsc_disable also for !cpu_has_tsc) which would 
> mean that only really old stuff would be using the outb still. A TSC is 
> really all we need to have a sensible udelay().
> 

Uhm, no.  You have no clue what the speed of the TSC is until you have 
been able to calibrate it against a fixed timesource - like the PIT.

	-hpa

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

[H. Peter Anvin]

Paul Rolland wrote:
> Just an idea : from what I've read, the problem (port 80 hanging) only occurs
> on 'modern' machines...

It happens on *one single* "modern" machine...

Let's keep that in perspective.
	
	-hpa

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

[H. Peter Anvin]

Rene Herman wrote:
> 
> It's really going to have to be a known _un_used register and (the write 
> direction of) port 0x80 is used exactly for that reason. Port 0xed is a 
> known "alternate diagnostic port" used by Phoenix BIOSes at least but 
> Peter Anvin reported trouble with that one -- probably for the outb 
> direction but assuming that means something was in fact responding, we'd 
> have the same timing problem.
> 

Yes, for the outbound direction.

> I believe we have two "good" options:
> 
> 1) port 0xed was tested by the current reporter and found to be safe 
> (and provide slow enough timing). If DMI  based quirk hacks are 
> available soon enough we can switch 0x80 to 0xed based on it. Are they?

DMI is just a data structure parked in memory, so it should at least be 
theoretically possible to get to it.

	-hpa

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

[Alan Cox]

> a minor concern, but I did also point out that using an unused port 
> causes the bus to be tied up for a microsecond or two, which matters on 
> a fast SMP machine.

And I did point out I'd found locking cases that may be relying upon this

> I also note that curent machines like the problem machine have ACPI, and 
> maybe those would be the ones that vendors might start to define port 80 
> to mean something. As I noted, it /seems/ to be only when ACPI is turned 

Port 0x80 means debug. You appear to have a laptop with some kind of
buggy firmware that wants a BIOS update. Everyone use 0x80 for debug -
its in the chipset hardware quite often.

> My belief is that my machine has some device that is responding to port 
> 80 by doing something.  And that something requires some other program 
> to "service" port 80 in some way.  But it sure would be nice to know.   
> I can't personally sand off the top of the chipset to put probes into it 
> - so my normal approach of putting a logic analyzer on the bus doesn't work.

Almost certainly a SMI trap.

> PS: If I have time, I may try to build Rene's port 80 test for Windows 
> and run it under WinXP on this machine 

That would be very interesting.

Alan

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

[Alan Cox]

> My understanding is that the linux starts in real mode, and uses the 
> BIOS for such things as reading the very first image.   

Not always. We may enter from 32bit in some cases, and we may also not
have a PC BIOS in the first place.

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

[David P. Reed]

H. Peter Anvin wrote:
> David P. Reed wrote:
>> Just a thought for a way to fix the "very early" timing needed to set 
>> up udelay to work in a way that works on all machines.  Perhaps we 
>> haven't exploited the BIOS enough:  The PC BIOS since the PC AT 
>> (286)  has always had a standard "countdown timer" way to delay for n 
>> microseconds, which as far as I know still works.   This can be used 
>> to measure the speed of a delay loop, without using ANY in/out 
>> instructions directly (the ones in the BIOS are presumably correctly 
>> delayed...).
>
> If we enter from the 32-bit entrypoint, we already don't have access 
> to the BIOS, though.
>
My understanding is that the linux starts in real mode, and uses the 
BIOS for such things as reading the very first image.   
arch/x86/boot/main.c seems to use BIOS calls, and one can do what I 
wrote in C or asm.  Good place to measure the appropriate delay timing, 
and pass it on forward.  That's what I was suggesting, which is why I 
copied the ASM routine from my old code listing as I did.

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

[Mark Lord]

This change seems rather unlikely for 2.6.24 at this point (high risk),
but could be good for 2.6.25.

One thing it should probably have for the early going,
is a simple way to turn it on/off at boot time,
so that we don't have people "stuck" unable to run
the test kernels should something weird happen.

Alan / David / Ingo,

What do you think of the idea of a *temporary* boot flag for this,
something like port80=on/off (pick a suitable name) ?

Cheers

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

[David P. Reed]

I understand the risks of such a fundamental change, and it may be only 
a minor concern, but I did also point out that using an unused port 
causes the bus to be tied up for a microsecond or two, which matters on 
a fast SMP machine.

Of course all the other concerns you guys are worrying about are really 
important.  I don't want to break anybody's running systems...  I'd like 
to see my machine run smoothly, and all the other machines that may or 
may not have this problem (google "hwclock freeze" to see that I'm far 
from alone - I just have persevered in "bisecting" this problem with 
kernel tweaks for months, whereas the others did not or did not know how).

By the way, this laptop is really nice for Linux in lots of ways.  Dual 
drives, so I set it up with software RAID for reliability, dual 64-bit 
processors, fast 3D graphics, etc.  Great battery life.  Just one last 
kernel issue.

I also note that curent machines like the problem machine have ACPI, and 
maybe those would be the ones that vendors might start to define port 80 
to mean something. As I noted, it /seems/ to be only when ACPI is turned 
on that this problem happens on my machine - that's when the OS starts 
to be involved in servicing various things, so it suggests that maybe 
things change about port 80's unknown function on these machines when 
ACPI is servicing the system management code (that's not something I 
have been able to verify).

My belief is that my machine has some device that is responding to port 
80 by doing something.  And that something requires some other program 
to "service" port 80 in some way.  But it sure would be nice to know.   
I can't personally sand off the top of the chipset to put probes into it 
- so my normal approach of putting a logic analyzer on the bus doesn't work.

PS: If I have time, I may try to build Rene's port 80 test for Windows 
and run it under WinXP on this machine (I still have a crappy little 
partition that boots it).   If it freezes the same way, it's almost 
certain a design "feature", and if it doesn't freeze, we might suspect 
that there is compensating logic in either Windows ACPI code or some way 
that windows "sets up" the machine.

Alan Cox wrote:
> On Sat, 15 Dec 2007 14:27:25 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
>
>   
>> * Rene Herman <rene.herman@gmail.com> wrote:
>>
>>     
>>> The issue is -- how do you safely replace the outb pre-loops_per_jiffy 
>>> calibration? I'm currently running with the attached hack (not 
>>> submitted, only for 32-bit and discussion) the idea of which might be 
>>> the best we can do?
>>>       
>> how about doing a known-NOP chipset cycle? For example:
>>
>>   inb(PIC_SLAVE_IMR)
>>     
>
> It needs tobe a different chip to the main one (or macrocell anyway) - so
> PIC for PIT and vice versa. However since we know 0x80 works for
> everything on the planet but this one specifies of laptop which seems to
> need a firmware update its a very high risk approach.
>
> Alan
>
>   

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

[Alan Cox]

On Sat, 15 Dec 2007 14:27:25 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Rene Herman <rene.herman@gmail.com> wrote:
> 
> > The issue is -- how do you safely replace the outb pre-loops_per_jiffy 
> > calibration? I'm currently running with the attached hack (not 
> > submitted, only for 32-bit and discussion) the idea of which might be 
> > the best we can do?
> 
> how about doing a known-NOP chipset cycle? For example:
> 
>   inb(PIC_SLAVE_IMR)

It needs tobe a different chip to the main one (or macrocell anyway) - so
PIC for PIT and vice versa. However since we know 0x80 works for
everything on the planet but this one specifies of laptop which seems to
need a firmware update its a very high risk approach.

Alan

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

[Rene Herman]

On 15-12-07 14:27, Ingo Molnar wrote:

> * Rene Herman <rene.herman@gmail.com> wrote:
> 
>> The issue is -- how do you safely replace the outb pre-loops_per_jiffy 
>> calibration? I'm currently running with the attached hack (not 
>> submitted, only for 32-bit and discussion) the idea of which might be 
>> the best we can do?
> 
> how about doing a known-NOP chipset cycle? For example:
> 
>   inb(PIC_SLAVE_IMR)

An inb is annoying in that it clobbers register al (well, with an inline 
native_io_delay it is at least) and more importantly -- the timing of this 
is going to vary wildly. We really want a register that is effectively 
guaranteed to be unused so that it dies on ISA/LPC or we might get _much_ 
faster PCI only decodes. Even reading port 0x80 itself varies wildly:

http://lkml.org/lkml/2007/12/12/309

> ? I.e. instead of trying to find an unused port, lets try to find a 
> known-used platform register that has no side-effects if read. Use it 
> unconditionally during early bootup and change it to an udelay after 
> calibration. (or use it after early bootup too if a boot parameter has 
> been specified) Or something like this.

It's really going to have to be a known _un_used register and (the write 
direction of) port 0x80 is used exactly for that reason. Port 0xed is a 
known "alternate diagnostic port" used by Phoenix BIOSes at least but Peter 
Anvin reported trouble with that one -- probably for the outb direction but 
assuming that means something was in fact responding, we'd have the same 
timing problem.

I believe we have two "good" options:

1) port 0xed was tested by the current reporter and found to be safe (and 
provide slow enough timing). If DMI  based quirk hacks are available soon 
enough we can switch 0x80 to 0xed based on it. Are they?

2) the thing I posted in the message replied to where immediately after 
tsc_init() (which is before the PIT init) we switch to udelay() if we have a 
TSC which is ofcourse anything modern.

Rene.

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

[Ingo Molnar]

* Rene Herman <rene.herman@gmail.com> wrote:

> The issue is -- how do you safely replace the outb pre-loops_per_jiffy 
> calibration? I'm currently running with the attached hack (not 
> submitted, only for 32-bit and discussion) the idea of which might be 
> the best we can do?

how about doing a known-NOP chipset cycle? For example:

  inb(PIC_SLAVE_IMR)

? I.e. instead of trying to find an unused port, lets try to find a 
known-used platform register that has no side-effects if read. Use it 
unconditionally during early bootup and change it to an udelay after 
calibration. (or use it after early bootup too if a boot parameter has 
been specified) Or something like this.

	Ingo

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

[Rene Herman]

On 15-12-07 09:08, Paul Rolland wrote:
> Hello,
> 
> On Fri, 14 Dec 2007 23:29:55 +0000
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
>> On Fri, 14 Dec 2007 14:13:46 -0800
>> "H. Peter Anvin" <hpa@zytor.com> wrote:
>>
>>> Pavel Machek wrote:
>>>> On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote:
>>> How long will that take to boot on a 386?
>> Well the dumb approach to fix that would seem to be to initialise it to
>>
>> 	cpu->family   3 -> 50MHz 4 -> 300Mhz 5-> etc...
> 
> Just an idea : from what I've read, the problem (port 80 hanging) only occurs
> on 'modern' machines... So why not :
>  - use port 80 for old CPUs (PII, PIII) where it has never really been
>    a problem,
>  - use the cpu->family to do a best match for CPU freq
> thus we could avoid increasing boot time too much...

Yes, just posted a Patch-For-Comments that switches on the availability of a 
TSC (tsc_init sets tsc_disable also for !cpu_has_tsc) which would mean that 
only really old stuff would be using the outb still. A TSC is really all we 
need to have a sensible udelay().

Rene.

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

[Paul Rolland]

Hello,

On Fri, 14 Dec 2007 23:29:55 +0000
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Fri, 14 Dec 2007 14:13:46 -0800
> "H. Peter Anvin" <hpa@zytor.com> wrote:
> 
> > Pavel Machek wrote:
> > > On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote:
> > 
> > How long will that take to boot on a 386?
> 
> Well the dumb approach to fix that would seem to be to initialise it to
> 
> 	cpu->family   3 -> 50MHz 4 -> 300Mhz 5-> etc...

Just an idea : from what I've read, the problem (port 80 hanging) only occurs
on 'modern' machines... So why not :
 - use port 80 for old CPUs (PII, PIII) where it has never really been
   a problem,
 - use the cpu->family to do a best match for CPU freq
thus we could avoid increasing boot time too much...

Paul

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

[Rene Herman]

[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]

On 15-12-07 08:43, Ingo Molnar wrote:

> * H. Peter Anvin <hpa@zytor.com> wrote:
> 
>> I believe this will suffer from the issue that was raised: this will 
>> use udelay() long before loop calibration (and no, we can't just "be 
>> conservative" since there is no "conservative" value we can use.)
>>
>> Worse, I suspect that at least the PIT, which may need to be used for 
>> udelay calibration, is one of the devices that may be affected.  I 
>> have seen the Verilog for a contemporary chipset, and it can only 
>> access the PIT once per microsecond -- this actually has to do with 
>> the definition of the PIT; some of the PIT operations are ill-defined 
>> if allowed at a higher frequency than the PIT clock.
> 
> i think the native_io_delay() in quirks.c signals the obvious solution: 
> a DMI (or otherwise) driven quirk that activates a port 0x80 based delay 
> on such boards. Combined with an iodelay=port80 boot option as well 
> perhaps, just in case someone hits a system that is not blacklisted yet. 
> This way such crazy broken hardware can be mapped correctly - like we 
> map such quirks in every other case. Perhaps even do this workaround on 
> the PIT driver level. Instead of perpetuating the superstition of port 
> 80 forever.

The issue is -- how do you safely replace the outb pre-loops_per_jiffy 
calibration? I'm currently running with the attached hack (not submitted, 
only for 32-bit and discussion) the idea of which might be the best we can do?

(And the broken is the hardware that can't take writes to port 0x80, not the 
other way around. It's a well-known legacy PC thing).

Rene.


[-- Attachment #2: native_io_delay-switch.diff --]
[-- Type: text/plain, Size: 1912 bytes --]

diff --git a/arch/x86/boot/compressed/misc_32.c b/arch/x86/boot/compressed/misc_32.c
index b74d60d..288e162 100644
--- a/arch/x86/boot/compressed/misc_32.c
+++ b/arch/x86/boot/compressed/misc_32.c
@@ -276,10 +276,10 @@ static void putstr(const char *s)
 	RM_SCREEN_INFO.orig_y = y;
 
 	pos = (x + cols * y) * 2;	/* Update cursor position */
-	outb_p(14, vidport);
-	outb_p(0xff & (pos >> 9), vidport+1);
-	outb_p(15, vidport);
-	outb_p(0xff & (pos >> 1), vidport+1);
+	outb(14, vidport);
+	outb(0xff & (pos >> 9), vidport+1);
+	outb(15, vidport);
+	outb(0xff & (pos >> 1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
diff --git a/arch/x86/kernel/time_32.c b/arch/x86/kernel/time_32.c
index 8a322c9..c95d313 100644
--- a/arch/x86/kernel/time_32.c
+++ b/arch/x86/kernel/time_32.c
@@ -222,6 +222,19 @@ void __init hpet_time_init(void)
 	time_init_hook();
 }
 
+static void port_io_delay(void)
+{
+	asm volatile ("outb %%al, $0x80": : : "memory");
+}
+
+static void udelay_io_delay(void)
+{
+	udelay(2);
+}
+
+void (*native_io_delay)(void) = port_io_delay;
+EXPORT_SYMBOL(native_io_delay);
+
 /*
  * This is called directly from init code; we must delay timer setup in the
  * HPET case as we can't make the decision to turn on HPET this early in the
@@ -233,5 +246,7 @@ void __init hpet_time_init(void)
 void __init time_init(void)
 {
 	tsc_init();
+	if (!tsc_disable)
+		native_io_delay = udelay_io_delay;
 	late_time_init = choose_time_init();
 }
diff --git a/include/asm-x86/io_32.h b/include/asm-x86/io_32.h
index fe881cd..1b73f49 100644
--- a/include/asm-x86/io_32.h
+++ b/include/asm-x86/io_32.h
@@ -250,10 +250,7 @@ static inline void flush_write_buffers(void)
 
 #endif /* __KERNEL__ */
 
-static inline void native_io_delay(void)
-{
-	asm volatile("outb %%al,$0x80" : : : "memory");
-}
+extern void (*native_io_delay)(void);
 
 #if defined(CONFIG_PARAVIRT)
 #include <asm/paravirt.h>

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

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> I believe this will suffer from the issue that was raised: this will 
> use udelay() long before loop calibration (and no, we can't just "be 
> conservative" since there is no "conservative" value we can use.)
>
> Worse, I suspect that at least the PIT, which may need to be used for 
> udelay calibration, is one of the devices that may be affected.  I 
> have seen the Verilog for a contemporary chipset, and it can only 
> access the PIT once per microsecond -- this actually has to do with 
> the definition of the PIT; some of the PIT operations are ill-defined 
> if allowed at a higher frequency than the PIT clock.

i think the native_io_delay() in quirks.c signals the obvious solution: 
a DMI (or otherwise) driven quirk that activates a port 0x80 based delay 
on such boards. Combined with an iodelay=port80 boot option as well 
perhaps, just in case someone hits a system that is not blacklisted yet. 
This way such crazy broken hardware can be mapped correctly - like we 
map such quirks in every other case. Perhaps even do this workaround on 
the PIT driver level. Instead of perpetuating the superstition of port 
80 forever.

	Ingo

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

[H. Peter Anvin]

David P. Reed wrote:
> Just a thought for a way to fix the "very early" timing needed to set up 
> udelay to work in a way that works on all machines.  Perhaps we haven't 
> exploited the BIOS enough:  The PC BIOS since the PC AT (286)  has 
> always had a standard "countdown timer" way to delay for n microseconds, 
> which as far as I know still works.   This can be used to measure the 
> speed of a delay loop, without using ANY in/out instructions directly 
> (the ones in the BIOS are presumably correctly delayed...).

If we enter from the 32-bit entrypoint, we already don't have access to 
the BIOS, though.

	-hpa

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

[David P. Reed]

Just a thought for a way to fix the "very early" timing needed to set up 
udelay to work in a way that works on all machines.  Perhaps we haven't 
exploited the BIOS enough:  The PC BIOS since the PC AT (286)  has 
always had a standard "countdown timer" way to delay for n microseconds, 
which as far as I know still works.   This can be used to measure the 
speed of a delay loop, without using ANY in/out instructions directly 
(the ones in the BIOS are presumably correctly delayed...).

So first thing in the boot sequence, one can calibrate a timing loop 
using this technique, and save the value to be used for all the "early" 
stuff.

Here's skeleton code from old ASM code I found lying around in my 
archives to use BIOS to measure how many unrolled short jumps can 
execute in 10 msec.  Note that it can run without knowing anything 
whatsoever about port timing.

haltbyte db 0

calibrate:
    les bx,haltbyte ; address of halt flag into es:bx
    mov ax,8300h
    sub cx,cx
    mov dx,10000 ; 10 msec. in cx:dx
    int 15h
    jc bad
    sub dx,dx
    sub cx,cx ; decrement counter in dx:cx
tloop:
    jmp short $+2 ; 10 short jmps
    jmp short $+2
    jmp short $+2
    jmp short $+2
    jmp short $+2
    jmp short $+2
    jmp short $+2
    jmp short $+2
    jmp short $+2
    test haltbyte
    loopz tloop
    jnz done
    dec dx
    jnz tloop

" overflowed 32 bits ... never happens, cancel BIOS event wait.
    mov ax,8301h
    int 15h
    jmp error
 
done:
    mov ax,cx
    negl
" here dx:ax contains 32 bit loop count corresponding to 10 msec.
    ret ; return 32-bit value


Doc on function 83h of int 15h should be available online.
   

Alan Cox wrote:
> On Fri, 14 Dec 2007 14:13:46 -0800
> "H. Peter Anvin" <hpa@zytor.com> wrote:
>
>   
>> Pavel Machek wrote:
>>     
>>> On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote:
>>>       
>>>> Ingo Molnar wrote:
>>>>         
>>>>> wow, cool fix! (I remember that there were other systems as well that are 
>>>>> affected by port 0x80 muckery - i thought we had removed port 0x80 
>>>>> accesses long ago.)
>>>>> how about the simpler fix below, as a first-level approach? We can then 
>>>>> remove the _p in/out sequences after this.
>>>>>           
>>>> I believe this will suffer from the issue that was raised: this will use 
>>>> udelay() long before loop calibration (and no, we can't just "be 
>>>> conservative" since there is no "conservative" value we can use.)
>>>>         
>>> ?? Just initialize bogomips to 6GHz equivalent... and we are fine
>>> until 6GHz cpus come out.
>>>       
>> How long will that take to boot on a 386?
>>     
>
> Well the dumb approach to fix that would seem to be to initialise it to
>
> 	cpu->family   3 -> 50MHz 4 -> 300Mhz 5-> etc...
>
> Alan
>
>   

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

[H. Peter Anvin]

David P. Reed wrote:
> 
> I believe (though no one seems to have confirming documentation from the 
> chipset or motherboard vendor) that port 80 is actually functional for 
> some unknown function on these machines.   (They do respond to "in" 
> instructions faster than a bus cycle abort does - more evidence).
> 

This is normal.  IN from port 0x80 is used by the DMA address map chip.

As far as I understand, there are other laptops with the same chipset 
which don't have this problem, so it's likely either a motherboard or 
firmware issue.  My guess is that they probably let debugging code out 
in the field (trap port 0x80 in SMM, and then try to output it on some 
debugging bus.)

	-hpa

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

[David P. Reed]

Avi Kivity wrote:
> kvm will forward a virtual machine's writes to port 0x80 to the real 
> port.  The reason is that the write is much faster than exiting and 
> emulating it; the difference is measurable when compiling kernels.
>
> Now if the cause is simply writing to port 0x80, then we must stop 
> doing that.  But if the reason is the back-to-back writes, when we can 
> keep it, since the other writes will be trapped by kvm and emulated.  
> Do you which is the case?
>
As for kvm, I don't have enough info to know anything about that.  Is 
there a test you'd like me to try?

I think you are also asking if the crash on these laptops is caused only 
by back-to-back writes.  Actually, it doesn't seem to matter if they are 
back to back.  I can cause the crash if the writes to 80 are very much 
spread out in time - it seems only to matter how many of them get 
executed - almost as if there is a buffer overflow.  (And of course if 
you do back to back writes to other ports that are apparently fully 
unused, such as 0xED on my machine, no crash occurs).

I believe (though no one seems to have confirming documentation from the 
chipset or motherboard vendor) that port 80 is actually functional for 
some unknown function on these machines.   (They do respond to "in" 
instructions faster than a bus cycle abort does - more evidence).

I searched the DSDT to see if there is any evidence of an ACPI use for 
this port, but found nothing.

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

[Alan Cox]

On Fri, 14 Dec 2007 14:13:46 -0800
"H. Peter Anvin" <hpa@zytor.com> wrote:

> Pavel Machek wrote:
> > On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote:
> >> Ingo Molnar wrote:
> >>> wow, cool fix! (I remember that there were other systems as well that are 
> >>> affected by port 0x80 muckery - i thought we had removed port 0x80 
> >>> accesses long ago.)
> >>> how about the simpler fix below, as a first-level approach? We can then 
> >>> remove the _p in/out sequences after this.
> >> I believe this will suffer from the issue that was raised: this will use 
> >> udelay() long before loop calibration (and no, we can't just "be 
> >> conservative" since there is no "conservative" value we can use.)
> > 
> > ?? Just initialize bogomips to 6GHz equivalent... and we are fine
> > until 6GHz cpus come out.
> 
> How long will that take to boot on a 386?

Well the dumb approach to fix that would seem to be to initialise it to

	cpu->family   3 -> 50MHz 4 -> 300Mhz 5-> etc...

Alan

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

[H. Peter Anvin]

Pavel Machek wrote:
> On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote:
>> Ingo Molnar wrote:
>>> wow, cool fix! (I remember that there were other systems as well that are 
>>> affected by port 0x80 muckery - i thought we had removed port 0x80 
>>> accesses long ago.)
>>> how about the simpler fix below, as a first-level approach? We can then 
>>> remove the _p in/out sequences after this.
>> I believe this will suffer from the issue that was raised: this will use 
>> udelay() long before loop calibration (and no, we can't just "be 
>> conservative" since there is no "conservative" value we can use.)
> 
> ?? Just initialize bogomips to 6GHz equivalent... and we are fine
> until 6GHz cpus come out.

How long will that take to boot on a 386?

	-hpa

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

[Pavel Machek]

On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote:
> Ingo Molnar wrote:
>> wow, cool fix! (I remember that there were other systems as well that are 
>> affected by port 0x80 muckery - i thought we had removed port 0x80 
>> accesses long ago.)
>> how about the simpler fix below, as a first-level approach? We can then 
>> remove the _p in/out sequences after this.
>
> I believe this will suffer from the issue that was raised: this will use 
> udelay() long before loop calibration (and no, we can't just "be 
> conservative" since there is no "conservative" value we can use.)

?? Just initialize bogomips to 6GHz equivalent... and we are fine
until 6GHz cpus come out.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Pavel Machek]

On Fri 2007-12-14 18:36:26, Alan Cox wrote:
> > > i dont think this should matter: old systems that truly _need_ the ISA 
> > > delay will be slow enough to not trip up. (nor are they really affected 
> > > by these early delays - the delays were more for crappy ISA devices that 
> > > get initialized later down, when the delay loop is already calibrated)
> > 
> > 8253 (DMAC) and 8254 (PIT) have been reported in earlier versions of the 
> > thread. By Alan, I believe.
> 
> They've been seen to be problems up to PII era machines. I'm not aware of
> any newer than that with this problem. We also don't need to touch the
> DMAC that early anyway that I can see - just the PIT.
> 
> In fact if we have a fast processor we have a TSC and APIC so we don't
> need the PIT ?

It is still good to be able to disable APIC/TSC. Neither are
particulary reliable time sources.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[H. Peter Anvin]

Alan Cox wrote:
>>> i dont think this should matter: old systems that truly _need_ the ISA 
>>> delay will be slow enough to not trip up. (nor are they really affected 
>>> by these early delays - the delays were more for crappy ISA devices that 
>>> get initialized later down, when the delay loop is already calibrated)
>> 8253 (DMAC) and 8254 (PIT) have been reported in earlier versions of the 
>> thread. By Alan, I believe.
> 
> They've been seen to be problems up to PII era machines. I'm not aware of
> any newer than that with this problem. We also don't need to touch the
> DMAC that early anyway that I can see - just the PIT.
> 
> In fact if we have a fast processor we have a TSC and APIC so we don't
> need the PIT ?

Well, the TSC may be unstable and the APIC may be disabled.

	-hpa

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

[Alan Cox]

> > i dont think this should matter: old systems that truly _need_ the ISA 
> > delay will be slow enough to not trip up. (nor are they really affected 
> > by these early delays - the delays were more for crappy ISA devices that 
> > get initialized later down, when the delay loop is already calibrated)
> 
> 8253 (DMAC) and 8254 (PIT) have been reported in earlier versions of the 
> thread. By Alan, I believe.

They've been seen to be problems up to PII era machines. I'm not aware of
any newer than that with this problem. We also don't need to touch the
DMAC that early anyway that I can see - just the PIT.

In fact if we have a fast processor we have a TSC and APIC so we don't
need the PIT ?

Alan

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

[Rene Herman]

On 14-12-07 19:02, H. Peter Anvin wrote:

> I believe this will suffer from the issue that was raised: this will use
> udelay() long before loop calibration (and no, we can't just "be 
> conservative" since there is no "conservative" value we can use.)
> 
> Worse, I suspect that at least the PIT, which may need to be used for 
> udelay calibration, is one of the devices that may be affected.  I have 
> seen the Verilog for a contemporary chipset, and it can only access the 
> PIT once per microsecond -- this actually has to do with the definition 
> of the PIT; some of the PIT operations are ill-defined if allowed at a 
> higher frequency than the PIT clock.

Was reported before indeed:

http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-09/5764.html

Rene.

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

[H. Peter Anvin]

Ingo Molnar wrote:
> 
> wow, cool fix! (I remember that there were other systems as well that 
> are affected by port 0x80 muckery - i thought we had removed port 0x80 
> accesses long ago.)
> 
> how about the simpler fix below, as a first-level approach? We can then 
> remove the _p in/out sequences after this.
> 

I believe this will suffer from the issue that was raised: this will use 
udelay() long before loop calibration (and no, we can't just "be 
conservative" since there is no "conservative" value we can use.)

Worse, I suspect that at least the PIT, which may need to be used for 
udelay calibration, is one of the devices that may be affected.  I have 
seen the Verilog for a contemporary chipset, and it can only access the 
PIT once per microsecond -- this actually has to do with the definition 
of the PIT; some of the PIT operations are ill-defined if allowed at a 
higher frequency than the PIT clock.

	-hpa

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

[Avi Kivity]

David P. Reed wrote:
> Replace use of outb to "unused" diagnostic port 0x80 for time delay
> with udelay based time delay on x86_64 architecture machines.  Fix for
> bugs 9511 and 6307 in bugzilla, plus bugs reported in
> bugzilla.redhat.com.
>
> Derived from suggestion (that didn't compile) by Pavel Machek, and
> tested, also based on measurements of typical timings of out's
> collated by Rene Herman from many in the community.
>
> This patch fixes a number of bugs known to cause problems on HP
> Pavilion dv9000z and dv6000z laptops - in the form of solid freezes
> when hwclock is used to show or set the time.  Also, it potentially
> improves bus utilization on SMP machines, by using a waiting process
> that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds.
>

kvm will forward a virtual machine's writes to port 0x80 to the real 
port.  The reason is that the write is much faster than exiting and 
emulating it; the difference is measurable when compiling kernels.

Now if the cause is simply writing to port 0x80, then we must stop doing 
that.  But if the reason is the back-to-back writes, when we can keep 
it, since the other writes will be trapped by kvm and emulated.  Do you 
which is the case?

-- 
Any sufficiently difficult bug is indistinguishable from a feature.

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

[Rene Herman]

On 14-12-07 15:46, Ingo Molnar wrote:

> * Rene Herman <rene.herman@gmail.com> wrote:
> 
>>>>  /*
>>>> - * This should be approx 2 Bo*oMips to start (note initial shift), and will
>>>> - * still work even if initially too large, it will just take slightly longer
>>>> + * Initial value roughly corresponds to a 1 GHz CPU
>>>>   */
>>>> -unsigned long loops_per_jiffy = (1<<12);
>>>> +unsigned long loops_per_jiffy = 1000000000 / HZ;
>>>>
>>>>  EXPORT_SYMBOL(loops_per_jiffy);
>>> this is a factor of ~2400 increase - this will take an eternity to boot on 
>>> any older CPU.
>> Only any outb_p's used before loops_per_jiffy is calibrated are 
>> affected.
> 
> yes - but there are a couple of early udelays, which would thus be 
> affected.

True. At the moment though they're just always not delaying anywhere close 
the intended amount (on anything with more than 2 bogomips). Pre-calibration 
all this stuff is just broken it seems.

>> This pre-calibation thing is what's historically held this change back 
>> (it's been discussed dozens of times before). At 4096, not any machine 
>> is going to have an appreciable delay before calibration when 
>> switching from the outb to 0x80.
> 
> i dont think this should matter: old systems that truly _need_ the ISA 
> delay will be slow enough to not trip up. (nor are they really affected 
> by these early delays - the delays were more for crappy ISA devices that 
> get initialized later down, when the delay loop is already calibrated)

8253 (DMAC) and 8254 (PIT) have been reported in earlier versions of the 
thread. By Alan, I believe.

Rene.

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

[Ingo Molnar]

* Rene Herman <rene.herman@gmail.com> wrote:

>>>  /*
>>> - * This should be approx 2 Bo*oMips to start (note initial shift), and will
>>> - * still work even if initially too large, it will just take slightly longer
>>> + * Initial value roughly corresponds to a 1 GHz CPU
>>>   */
>>> -unsigned long loops_per_jiffy = (1<<12);
>>> +unsigned long loops_per_jiffy = 1000000000 / HZ;
>>>
>>>  EXPORT_SYMBOL(loops_per_jiffy);
>>
>> this is a factor of ~2400 increase - this will take an eternity to boot on 
>> any older CPU.
>
> Only any outb_p's used before loops_per_jiffy is calibrated are 
> affected.

yes - but there are a couple of early udelays, which would thus be 
affected.

> This pre-calibation thing is what's historically held this change back 
> (it's been discussed dozens of times before). At 4096, not any machine 
> is going to have an appreciable delay before calibration when 
> switching from the outb to 0x80.

i dont think this should matter: old systems that truly _need_ the ISA 
delay will be slow enough to not trip up. (nor are they really affected 
by these early delays - the delays were more for crappy ISA devices that 
get initialized later down, when the delay loop is already calibrated)

modern systems learned to depend on the PCI write posting side-effects 
of port 0x80 activities - those wont be helped by this initialization 
change either. That is a far more serious concern.

	Ingo

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

[Ingo Molnar]

> > updated patch attached. (from the MakeItBuild'n'Stuff dept)
> 
> the one below is against current upstream. (previous ones were against 
> x86.git)

the last version is the one below. Pending further discussion and 
testing. And David, i nominate your fix as the coolest Linux kernel fix 
of 2007 :-)

	Ingo

-------------------------------->

Subject: x86: fix in_p/out_p crashes
From: David P. Reed <dpreed@reed.com>

Do not use port 0x80, it can cause crashes, see:

 http://bugzilla.kernel.org/show_bug.cgi?id=6307
 http://bugzilla.kernel.org/show_bug.cgi?id=9511

Replace use of outb to "unused" diagnostic port 0x80 for time delay
with udelay based time delay on x86_64 architecture machines.  Fix for
bugs 9511 and 6307 in bugzilla, plus bugs reported in
bugzilla.redhat.com.

Derived from suggestion (that didn't compile) by Pavel Machek, and
tested, also based on measurements of typical timings of out's
collated by Rene Herman from many in the community.

This patch fixes a number of bugs known to cause problems on HP
Pavilion dv9000z and dv6000z laptops - in the form of solid freezes
when hwclock is used to show or set the time.  Also, it potentially
improves bus utilization on SMP machines, by using a waiting process
that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds.

[ mingo@elte.hu: minor restructuring, 32-bit support. ]

Signed-off-by: David P. Reed <dpreed@reed.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/boot/compressed/misc_32.c |    8 ++++----
 arch/x86/boot/compressed/misc_64.c |    8 ++++----
 arch/x86/kernel/quirks.c           |   10 ++++++++++
 include/asm-x86/io_32.h            |    5 +----
 include/asm-x86/io_64.h            |   14 +++++---------
 5 files changed, 24 insertions(+), 21 deletions(-)

Index: linux-x86.q/arch/x86/boot/compressed/misc_32.c
===================================================================
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_32.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_32.c
@@ -276,10 +276,10 @@ static void putstr(const char *s)
 	RM_SCREEN_INFO.orig_y = y;
 
 	pos = (x + cols * y) * 2;	/* Update cursor position */
-	outb_p(14, vidport);
-	outb_p(0xff & (pos >> 9), vidport+1);
-	outb_p(15, vidport);
-	outb_p(0xff & (pos >> 1), vidport+1);
+	outb(14, vidport);
+	outb(0xff & (pos >> 9), vidport+1);
+	outb(15, vidport);
+	outb(0xff & (pos >> 1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/boot/compressed/misc_64.c
===================================================================
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_64.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_64.c
@@ -269,10 +269,10 @@ static void putstr(const char *s)
 	RM_SCREEN_INFO.orig_y = y;
 
 	pos = (x + cols * y) * 2;	/* Update cursor position */
-	outb_p(14, vidport);
-	outb_p(0xff & (pos >> 9), vidport+1);
-	outb_p(15, vidport);
-	outb_p(0xff & (pos >> 1), vidport+1);
+	outb(14, vidport);
+	outb(0xff & (pos >> 9), vidport+1);
+	outb(15, vidport);
+	outb(0xff & (pos >> 1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/kernel/quirks.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/quirks.c
+++ linux-x86.q/arch/x86/kernel/quirks.c
@@ -3,9 +3,19 @@
  */
 #include <linux/pci.h>
 #include <linux/irq.h>
+#include <linux/delay.h>
 
 #include <asm/hpet.h>
 
+/*
+ * Some legacy devices need delays for IN/OUT sequences. Most are
+ * probably not needed but it's the safest to just do this short delay:
+ */
+void native_io_delay(void)
+{
+	udelay(2);
+}
+
 #if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)
 
 static void __devinit quirk_intel_irqbalance(struct pci_dev *dev)
Index: linux-x86.q/include/asm-x86/io_32.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/io_32.h
+++ linux-x86.q/include/asm-x86/io_32.h
@@ -250,10 +250,7 @@ static inline void flush_write_buffers(v
 
 #endif /* __KERNEL__ */
 
-static inline void native_io_delay(void)
-{
-	asm volatile("outb %%al,$0x80" : : : "memory");
-}
+extern void native_io_delay(void);
 
 #if defined(CONFIG_PARAVIRT)
 #include <asm/paravirt.h>
Index: linux-x86.q/include/asm-x86/io_64.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/io_64.h
+++ linux-x86.q/include/asm-x86/io_64.h
@@ -35,13 +35,7 @@
   *  - Arnaldo Carvalho de Melo <acme@conectiva.com.br>
   */
 
-#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
-
-#ifdef REALLY_SLOW_IO
-#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO
-#else
-#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO
-#endif
+extern void native_io_delay(void);
 
 /*
  * Talk about misusing macros..
@@ -54,7 +48,8 @@ __asm__ __volatile__ ("out" #s " %" s1 "
 
 #define __OUT(s,s1,x) \
 __OUT1(s,x) __OUT2(s,s1,"w") : : "a" (value), "Nd" (port)); } \
-__OUT1(s##_p,x) __OUT2(s,s1,"w") __FULL_SLOW_DOWN_IO : : "a" (value), "Nd" (port));} \
+__OUT1(s##_p,x) __OUT2(s,s1,"w") : : "a" (value), "Nd" (port)); \
+native_io_delay(); } \
 
 #define __IN1(s) \
 static inline RETURN_TYPE in##s(unsigned short port) { RETURN_TYPE _v;
@@ -64,7 +59,8 @@ __asm__ __volatile__ ("in" #s " %" s2 "1
 
 #define __IN(s,s1,i...) \
 __IN1(s) __IN2(s,s1,"w") : "=a" (_v) : "Nd" (port) ,##i ); return _v; } \
-__IN1(s##_p) __IN2(s,s1,"w") __FULL_SLOW_DOWN_IO : "=a" (_v) : "Nd" (port) ,##i ); return _v; } \
+__IN1(s##_p) __IN2(s,s1,"w") : "=a" (_v) : "Nd" (port) ,##i ); return _v; \
+native_io_delay(); } \
 
 #define __INS(s) \
 static inline void ins##s(unsigned short port, void * addr, unsigned long count) \

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

[Rene Herman]

On 14-12-07 15:23, Ingo Molnar wrote:

> * Rene Herman <rene.herman@gmail.com> wrote:
> 
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -229,10 +229,9 @@ static int __init obsolete_checksetup(char *line)
>>  }
>>
>>  /*
>> - * This should be approx 2 Bo*oMips to start (note initial shift), and will
>> - * still work even if initially too large, it will just take slightly longer
>> + * Initial value roughly corresponds to a 1 GHz CPU
>>   */
>> -unsigned long loops_per_jiffy = (1<<12);
>> +unsigned long loops_per_jiffy = 1000000000 / HZ;
>>
>>  EXPORT_SYMBOL(loops_per_jiffy);
> 
> this is a factor of ~2400 increase - this will take an eternity to boot 
> on any older CPU.

Only any outb_p's used before loops_per_jiffy is calibrated are affected.

This pre-calibation thing is what's historically held this change back (it's 
been discussed dozens of times before). At 4096, not any machine is going to 
have an appreciable delay before calibration when switching from the outb to 
  0x80.

Rene.

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

[Ingo Molnar]

* Rene Herman <rene.herman@gmail.com> wrote:

> --- a/init/main.c
> +++ b/init/main.c
> @@ -229,10 +229,9 @@ static int __init obsolete_checksetup(char *line)
>  }
>
>  /*
> - * This should be approx 2 Bo*oMips to start (note initial shift), and will
> - * still work even if initially too large, it will just take slightly longer
> + * Initial value roughly corresponds to a 1 GHz CPU
>   */
> -unsigned long loops_per_jiffy = (1<<12);
> +unsigned long loops_per_jiffy = 1000000000 / HZ;
>
>  EXPORT_SYMBOL(loops_per_jiffy);

this is a factor of ~2400 increase - this will take an eternity to boot 
on any older CPU.

	Ingo

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

[Ingo Molnar]

* Rene Herman <rene.herman@gmail.com> wrote:

> And as to testing -- good luck finding a machine that cares at all ;-)

actually, there's a whole lot more testing angle to a change like this 
than ancient boxes.

	Ingo

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

[Rene Herman]

On 14-12-07 15:03, Ingo Molnar wrote:

> yep, i have updated the delay to 2 usecs. The latest patch is below, as 
> queued up in x86.git. (not yet queued up for .24 - it's pending testing 
> and more feedback, etc.)

Yes, I'd like feedback on the initial value thing:

http://lkml.org/lkml/2007/12/14/72

and Alan's comments here:

http://lkml.org/lkml/2007/12/12/221

And as to testing -- good luck finding a machine that cares at all ;-)

Rene.

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

[Ingo Molnar]

* Rene Herman <rene.herman@gmail.com> wrote:

> On 14-12-07 14:15, Ingo Molnar wrote:
>
>> wow, cool fix! (I remember that there were other systems as well that are 
>> affected by port 0x80 muckery - i thought we had removed port 0x80 
>> accesses long ago.)
>>
>> how about the simpler fix below, as a first-level approach? We can 
>> then remove the _p in/out sequences after this.
>
> Your version does the same thing that the version from Pavel/David 
> does for 32-bit at least.

well, if you carefully look at the code it's not the "same" but a 
similar but cleaner thing - it moves this quirk out of a common include 
file. I take back the "simpler" characterisation - my patch indeed ended 
up being almost the same as David's.

>> +/*
>> + * Some legacy devices need delays for IN/OUT sequences. Most are
>> + * probably not needed but it's the safest to just do this short delay:
>> + */
>> +void native_io_delay(void)
>> +{
>> +	udelay(1);
>> +}
>
> Also note the thread(s) on LKML where 2 us was decided to be a nicely 
> conservative value:

yep, i have updated the delay to 2 usecs. The latest patch is below, as 
queued up in x86.git. (not yet queued up for .24 - it's pending testing 
and more feedback, etc.)

	Ingo

----------------->
Subject: x86: fix in_p/out_p crashes
From: David P. Reed <dpreed@reed.com>

Do not use port 0x80, it can cause crashes, see:

 http://bugzilla.kernel.org/show_bug.cgi?id=6307
 http://bugzilla.kernel.org/show_bug.cgi?id=9511

Replace use of outb to "unused" diagnostic port 0x80 for time delay
with udelay based time delay on x86_64 architecture machines.  Fix for
bugs 9511 and 6307 in bugzilla, plus bugs reported in
bugzilla.redhat.com.

Derived from suggestion (that didn't compile) by Pavel Machek, and
tested, also based on measurements of typical timings of out's
collated by Rene Herman from many in the community.

This patch fixes a number of bugs known to cause problems on HP
Pavilion dv9000z and dv6000z laptops - in the form of solid freezes
when hwclock is used to show or set the time.  Also, it potentially
improves bus utilization on SMP machines, by using a waiting process
that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds.

[ mingo@elte.hu: minor restructuring, 32-bit support. ]

Signed-off-by: David P. Reed <dpreed@reed.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/boot/compressed/misc_32.c |    8 ++++----
 arch/x86/boot/compressed/misc_64.c |    8 ++++----
 arch/x86/kernel/quirks.c           |   10 ++++++++++
 include/asm-x86/io_32.h            |    5 +----
 include/asm-x86/io_64.h            |   14 +++++---------
 5 files changed, 24 insertions(+), 21 deletions(-)

Index: linux-x86.q/arch/x86/boot/compressed/misc_32.c
===================================================================
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_32.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_32.c
@@ -276,10 +276,10 @@ static void putstr(const char *s)
 	RM_SCREEN_INFO.orig_y = y;
 
 	pos = (x + cols * y) * 2;	/* Update cursor position */
-	outb_p(14, vidport);
-	outb_p(0xff & (pos >> 9), vidport+1);
-	outb_p(15, vidport);
-	outb_p(0xff & (pos >> 1), vidport+1);
+	outb(14, vidport);
+	outb(0xff & (pos >> 9), vidport+1);
+	outb(15, vidport);
+	outb(0xff & (pos >> 1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/boot/compressed/misc_64.c
===================================================================
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_64.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_64.c
@@ -269,10 +269,10 @@ static void putstr(const char *s)
 	RM_SCREEN_INFO.orig_y = y;
 
 	pos = (x + cols * y) * 2;	/* Update cursor position */
-	outb_p(14, vidport);
-	outb_p(0xff & (pos >> 9), vidport+1);
-	outb_p(15, vidport);
-	outb_p(0xff & (pos >> 1), vidport+1);
+	outb(14, vidport);
+	outb(0xff & (pos >> 9), vidport+1);
+	outb(15, vidport);
+	outb(0xff & (pos >> 1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/kernel/quirks.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/quirks.c
+++ linux-x86.q/arch/x86/kernel/quirks.c
@@ -3,9 +3,19 @@
  */
 #include <linux/pci.h>
 #include <linux/irq.h>
+#include <linux/delay.h>
 
 #include <asm/hpet.h>
 
+/*
+ * Some legacy devices need delays for IN/OUT sequences. Most are
+ * probably not needed but it's the safest to just do this short delay:
+ */
+void native_io_delay(void)
+{
+	udelay(2);
+}
+
 #if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)
 
 static void __devinit quirk_intel_irqbalance(struct pci_dev *dev)
Index: linux-x86.q/include/asm-x86/io_32.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/io_32.h
+++ linux-x86.q/include/asm-x86/io_32.h
@@ -250,10 +250,7 @@ static inline void flush_write_buffers(v
 
 #endif /* __KERNEL__ */
 
-static inline void native_io_delay(void)
-{
-	asm volatile("outb %%al,$0x80" : : : "memory");
-}
+extern void native_io_delay(void);
 
 #if defined(CONFIG_PARAVIRT)
 #include <asm/paravirt.h>
Index: linux-x86.q/include/asm-x86/io_64.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/io_64.h
+++ linux-x86.q/include/asm-x86/io_64.h
@@ -35,13 +35,7 @@
   *  - Arnaldo Carvalho de Melo <acme@conectiva.com.br>
   */
 
-#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
-
-#ifdef REALLY_SLOW_IO
-#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO
-#else
-#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO
-#endif
+extern void native_io_delay(void);
 
 /*
  * Talk about misusing macros..
@@ -54,7 +48,8 @@ __asm__ __volatile__ ("out" #s " %" s1 "
 
 #define __OUT(s,s1,x) \
 __OUT1(s,x) __OUT2(s,s1,"w") : : "a" (value), "Nd" (port)); } \
-__OUT1(s##_p,x) __OUT2(s,s1,"w") __FULL_SLOW_DOWN_IO : : "a" (value), "Nd" (port));} \
+__OUT1(s##_p,x) __OUT2(s,s1,"w") : : "a" (value), "Nd" (port)); \
+native_io_delay(); } \
 
 #define __IN1(s) \
 static inline RETURN_TYPE in##s(unsigned short port) { RETURN_TYPE _v;
@@ -64,7 +59,8 @@ __asm__ __volatile__ ("in" #s " %" s2 "1
 
 #define __IN(s,s1,i...) \
 __IN1(s) __IN2(s,s1,"w") : "=a" (_v) : "Nd" (port) ,##i ); return _v; } \
-__IN1(s##_p) __IN2(s,s1,"w") __FULL_SLOW_DOWN_IO : "=a" (_v) : "Nd" (port) ,##i ); return _v; } \
+__IN1(s##_p) __IN2(s,s1,"w") : "=a" (_v) : "Nd" (port) ,##i ); return _v; \
+native_io_delay(); } \
 
 #define __INS(s) \
 static inline void ins##s(unsigned short port, void * addr, unsigned long count) \

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

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> updated patch attached. (from the MakeItBuild'n'Stuff dept)

the one below is against current upstream. (previous ones were against 
x86.git)

	Ingo

------------------->
Subject: x86: fix in/out_p delays
From: Ingo Molnar <mingo@elte.hu>

Debugged by David P. Reed <dpreed@reed.com>.

Do not use port 0x80, it can cause crashes, see:

 http://bugzilla.kernel.org/show_bug.cgi?id=6307
 http://bugzilla.kernel.org/show_bug.cgi?id=9511

instead of just removing _p postfixes en masse, lets just first
remove the 0x80 port usage, then remove any unnecessary _p io ops
gradually. It's more debuggable this way.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/boot/compressed/misc_32.c |    8 ++++----
 arch/x86/boot/compressed/misc_64.c |    8 ++++----
 arch/x86/kernel/quirks.c           |   10 ++++++++++
 include/asm-x86/io_32.h            |    5 +----
 include/asm-x86/io_64.h            |   14 +++++---------
 5 files changed, 24 insertions(+), 21 deletions(-)

Index: linux-x86.q/arch/x86/boot/compressed/misc_32.c
===================================================================
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_32.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_32.c
@@ -276,10 +276,10 @@ static void putstr(const char *s)
 	RM_SCREEN_INFO.orig_y = y;
 
 	pos = (x + cols * y) * 2;	/* Update cursor position */
-	outb_p(14, vidport);
-	outb_p(0xff & (pos >> 9), vidport+1);
-	outb_p(15, vidport);
-	outb_p(0xff & (pos >> 1), vidport+1);
+	outb(14, vidport);
+	outb(0xff & (pos >> 9), vidport+1);
+	outb(15, vidport);
+	outb(0xff & (pos >> 1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/boot/compressed/misc_64.c
===================================================================
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_64.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_64.c
@@ -269,10 +269,10 @@ static void putstr(const char *s)
 	RM_SCREEN_INFO.orig_y = y;
 
 	pos = (x + cols * y) * 2;	/* Update cursor position */
-	outb_p(14, vidport);
-	outb_p(0xff & (pos >> 9), vidport+1);
-	outb_p(15, vidport);
-	outb_p(0xff & (pos >> 1), vidport+1);
+	outb(14, vidport);
+	outb(0xff & (pos >> 9), vidport+1);
+	outb(15, vidport);
+	outb(0xff & (pos >> 1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/kernel/quirks.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/quirks.c
+++ linux-x86.q/arch/x86/kernel/quirks.c
@@ -3,9 +3,19 @@
  */
 #include <linux/pci.h>
 #include <linux/irq.h>
+#include <linux/delay.h>
 
 #include <asm/hpet.h>
 
+/*
+ * Some legacy devices need delays for IN/OUT sequences. Most are
+ * probably not needed but it's the safest to just do this short delay:
+ */
+void native_io_delay(void)
+{
+	udelay(1);
+}
+
 #if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)
 
 static void __devinit quirk_intel_irqbalance(struct pci_dev *dev)
Index: linux-x86.q/include/asm-x86/io_32.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/io_32.h
+++ linux-x86.q/include/asm-x86/io_32.h
@@ -250,10 +250,7 @@ static inline void flush_write_buffers(v
 
 #endif /* __KERNEL__ */
 
-static inline void native_io_delay(void)
-{
-	asm volatile("outb %%al,$0x80" : : : "memory");
-}
+extern void native_io_delay(void);
 
 #if defined(CONFIG_PARAVIRT)
 #include <asm/paravirt.h>
Index: linux-x86.q/include/asm-x86/io_64.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/io_64.h
+++ linux-x86.q/include/asm-x86/io_64.h
@@ -35,13 +35,7 @@
   *  - Arnaldo Carvalho de Melo <acme@conectiva.com.br>
   */
 
-#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
-
-#ifdef REALLY_SLOW_IO
-#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO
-#else
-#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO
-#endif
+extern void native_io_delay(void);
 
 /*
  * Talk about misusing macros..
@@ -54,7 +48,8 @@ __asm__ __volatile__ ("out" #s " %" s1 "
 
 #define __OUT(s,s1,x) \
 __OUT1(s,x) __OUT2(s,s1,"w") : : "a" (value), "Nd" (port)); } \
-__OUT1(s##_p,x) __OUT2(s,s1,"w") __FULL_SLOW_DOWN_IO : : "a" (value), "Nd" (port));} \
+__OUT1(s##_p,x) __OUT2(s,s1,"w") : : "a" (value), "Nd" (port)); \
+native_io_delay(); } \
 
 #define __IN1(s) \
 static inline RETURN_TYPE in##s(unsigned short port) { RETURN_TYPE _v;
@@ -64,7 +59,8 @@ __asm__ __volatile__ ("in" #s " %" s2 "1
 
 #define __IN(s,s1,i...) \
 __IN1(s) __IN2(s,s1,"w") : "=a" (_v) : "Nd" (port) ,##i ); return _v; } \
-__IN1(s##_p) __IN2(s,s1,"w") __FULL_SLOW_DOWN_IO : "=a" (_v) : "Nd" (port) ,##i ); return _v; } \
+__IN1(s##_p) __IN2(s,s1,"w") : "=a" (_v) : "Nd" (port) ,##i ); return _v; \
+native_io_delay(); } \
 
 #define __INS(s) \
 static inline void ins##s(unsigned short port, void * addr, unsigned long count) \

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

[Rene Herman]

On 14-12-07 14:15, Ingo Molnar wrote:

> wow, cool fix! (I remember that there were other systems as well that 
> are affected by port 0x80 muckery - i thought we had removed port 0x80 
> accesses long ago.)
> 
> how about the simpler fix below, as a first-level approach? We can then 
> remove the _p in/out sequences after this.

Your version does the same thing that the version from Pavel/David does for 
32-bit at least.

> +/*
> + * Some legacy devices need delays for IN/OUT sequences. Most are
> + * probably not needed but it's the safest to just do this short delay:
> + */
> +void native_io_delay(void)
> +{
> +	udelay(1);
> +}

Also note the thread(s) on LKML where 2 us was decided to be a nicely 
conservative value:

http://lkml.org/lkml/2007/12/12/309

Also see: http://lkml.org/lkml/2007/12/14/72

And also: http://lkml.org/lkml/2007/12/12/221

As such, please wait a bit for a fuller resolution. We're still discussing this.

Rene.

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

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> wow, cool fix! (I remember that there were other systems as well that 
> are affected by port 0x80 muckery - i thought we had removed port 0x80 
> accesses long ago.)
> 
> how about the simpler fix below, as a first-level approach? We can 
> then remove the _p in/out sequences after this.
> 
> this is also something for v2.6.24 merging.

updated patch attached. (from the MakeItBuild'n'Stuff dept)

	Ingo

-------------->
Subject: x86: fix in/out_p delays
From: Ingo Molnar <mingo@elte.hu>

Debugged by David P. Reed <dpreed@reed.com>.

Do not use port 0x80, it can cause crashes, see:

 http://bugzilla.kernel.org/show_bug.cgi?id=6307
 http://bugzilla.kernel.org/show_bug.cgi?id=9511

instead of just removing _p postfixes en masse, lets just first
remove the 0x80 port usage, then remove any unnecessary _p io ops
gradually. It's more debuggable this way.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/boot/compressed/misc_32.c |    8 ++++----
 arch/x86/boot/compressed/misc_64.c |    8 ++++----
 arch/x86/kernel/quirks.c           |   10 ++++++++++
 include/asm-x86/io_32.h            |    5 +----
 include/asm-x86/io_64.h            |    5 +----
 5 files changed, 20 insertions(+), 16 deletions(-)

Index: linux-x86.q/arch/x86/boot/compressed/misc_32.c
===================================================================
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_32.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_32.c
@@ -276,10 +276,10 @@ static void putstr(const char *s)
 	RM_SCREEN_INFO.orig_y = y;
 
 	pos = (x + cols * y) * 2;	/* Update cursor position */
-	outb_p(14, vidport);
-	outb_p(0xff & (pos >> 9), vidport+1);
-	outb_p(15, vidport);
-	outb_p(0xff & (pos >> 1), vidport+1);
+	outb(14, vidport);
+	outb(0xff & (pos >> 9), vidport+1);
+	outb(15, vidport);
+	outb(0xff & (pos >> 1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/boot/compressed/misc_64.c
===================================================================
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_64.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_64.c
@@ -275,10 +275,10 @@ static void putstr(const char *s)
 	RM_SCREEN_INFO.orig_y = y;
 
 	pos = (x + cols * y) * 2;	/* Update cursor position */
-	outb_p(14, vidport);
-	outb_p(0xff & (pos >> 9), vidport+1);
-	outb_p(15, vidport);
-	outb_p(0xff & (pos >> 1), vidport+1);
+	outb(14, vidport);
+	outb(0xff & (pos >> 9), vidport+1);
+	outb(15, vidport);
+	outb(0xff & (pos >> 1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/kernel/quirks.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/quirks.c
+++ linux-x86.q/arch/x86/kernel/quirks.c
@@ -3,9 +3,19 @@
  */
 #include <linux/pci.h>
 #include <linux/irq.h>
+#include <linux/delay.h>
 
 #include <asm/hpet.h>
 
+/*
+ * Some legacy devices need delays for IN/OUT sequences. Most are
+ * probably not needed but it's the safest to just do this short delay:
+ */
+void native_io_delay(void)
+{
+	udelay(1);
+}
+
 #if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)
 
 static void __devinit quirk_intel_irqbalance(struct pci_dev *dev)
Index: linux-x86.q/include/asm-x86/io_32.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/io_32.h
+++ linux-x86.q/include/asm-x86/io_32.h
@@ -250,10 +250,7 @@ static inline void flush_write_buffers(v
 
 #endif /* __KERNEL__ */
 
-static inline void native_io_delay(void)
-{
-	asm volatile("outb %%al,$0x80" : : : "memory");
-}
+extern void native_io_delay(void);
 
 #if defined(CONFIG_PARAVIRT)
 #include <asm/paravirt.h>
Index: linux-x86.q/include/asm-x86/io_64.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/io_64.h
+++ linux-x86.q/include/asm-x86/io_64.h
@@ -35,10 +35,7 @@
   *  - Arnaldo Carvalho de Melo <acme@conectiva.com.br>
   */
 
-static inline void native_io_delay(void)
-{
-	asm volatile("outb %%al,$0x80" : : : "memory");
-}
+extern void native_io_delay(void);
 
 #if defined(CONFIG_PARAVIRT)
 #include <asm/paravirt.h>

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

[Ingo Molnar]

* David P. Reed <dpreed@reed.com> wrote:

> Replace use of outb to "unused" diagnostic port 0x80 for time delay 
> with udelay based time delay on x86_64 architecture machines.  Fix for 
> bugs 9511 and 6307 in bugzilla, plus bugs reported in 
> bugzilla.redhat.com.
>
> Derived from suggestion (that didn't compile) by Pavel Machek, and 
> tested, also based on measurements of typical timings of out's 
> collated by Rene Herman from many in the community.
>
> This patch fixes a number of bugs known to cause problems on HP
> Pavilion dv9000z and dv6000z laptops - in the form of solid freezes
> when hwclock is used to show or set the time.  Also, it potentially
> improves bus utilization on SMP machines, by using a waiting process
> that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds.
>
> i386 family fixes (completely parallel) were not included, considering 
> that such machines might involve more risk of problems on legacy 
> machines.

wow, cool fix! (I remember that there were other systems as well that 
are affected by port 0x80 muckery - i thought we had removed port 0x80 
accesses long ago.)

how about the simpler fix below, as a first-level approach? We can then 
remove the _p in/out sequences after this.

this is also something for v2.6.24 merging.

	Ingo

----------------------------->
Subject: x86: fix in/out_p delays
From: Ingo Molnar <mingo@elte.hu>

Debugged by David P. Reed <dpreed@reed.com>.

Do not use port 0x80, it can cause crashes, see:

 http://bugzilla.kernel.org/show_bug.cgi?id=6307
 http://bugzilla.kernel.org/show_bug.cgi?id=9511

instead of just removing _p postfixes en masse, lets just first
remove the 0x80 port usage, then remove any unnecessary _p io ops
gradually. It's more debuggable this way.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/boot/compressed/misc_32.c |    8 ++++----
 arch/x86/boot/compressed/misc_64.c |    8 ++++----
 arch/x86/kernel/quirks.c           |    9 +++++++++
 include/asm-x86/io_32.h            |    5 +----
 include/asm-x86/io_64.h            |    5 +----
 5 files changed, 19 insertions(+), 16 deletions(-)

Index: linux-x86.q/arch/x86/boot/compressed/misc_32.c
===================================================================
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_32.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_32.c
@@ -276,10 +276,10 @@ static void putstr(const char *s)
 	RM_SCREEN_INFO.orig_y = y;
 
 	pos = (x + cols * y) * 2;	/* Update cursor position */
-	outb_p(14, vidport);
-	outb_p(0xff & (pos >> 9), vidport+1);
-	outb_p(15, vidport);
-	outb_p(0xff & (pos >> 1), vidport+1);
+	outb(14, vidport);
+	outb(0xff & (pos >> 9), vidport+1);
+	outb(15, vidport);
+	outb(0xff & (pos >> 1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/boot/compressed/misc_64.c
===================================================================
--- linux-x86.q.orig/arch/x86/boot/compressed/misc_64.c
+++ linux-x86.q/arch/x86/boot/compressed/misc_64.c
@@ -275,10 +275,10 @@ static void putstr(const char *s)
 	RM_SCREEN_INFO.orig_y = y;
 
 	pos = (x + cols * y) * 2;	/* Update cursor position */
-	outb_p(14, vidport);
-	outb_p(0xff & (pos >> 9), vidport+1);
-	outb_p(15, vidport);
-	outb_p(0xff & (pos >> 1), vidport+1);
+	outb(14, vidport);
+	outb(0xff & (pos >> 9), vidport+1);
+	outb(15, vidport);
+	outb(0xff & (pos >> 1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
Index: linux-x86.q/arch/x86/kernel/quirks.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/quirks.c
+++ linux-x86.q/arch/x86/kernel/quirks.c
@@ -6,6 +6,15 @@
 
 #include <asm/hpet.h>
 
+/*
+ * Some legacy devices need delays for IN/OUT sequences. Most are
+ * probably not needed but it's the safest to just do this short delay:
+ */
+void native_io_delay(void)
+{
+	udelay(1);
+}
+
 #if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)
 
 static void __devinit quirk_intel_irqbalance(struct pci_dev *dev)
Index: linux-x86.q/include/asm-x86/io_32.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/io_32.h
+++ linux-x86.q/include/asm-x86/io_32.h
@@ -250,10 +250,7 @@ static inline void flush_write_buffers(v
 
 #endif /* __KERNEL__ */
 
-static inline void native_io_delay(void)
-{
-	asm volatile("outb %%al,$0x80" : : : "memory");
-}
+extern void native_io_delay(void);
 
 #if defined(CONFIG_PARAVIRT)
 #include <asm/paravirt.h>
Index: linux-x86.q/include/asm-x86/io_64.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/io_64.h
+++ linux-x86.q/include/asm-x86/io_64.h
@@ -35,10 +35,7 @@
   *  - Arnaldo Carvalho de Melo <acme@conectiva.com.br>
   */
 
-static inline void native_io_delay(void)
-{
-	asm volatile("outb %%al,$0x80" : : : "memory");
-}
+extern void native_io_delay(void);
 
 #if defined(CONFIG_PARAVIRT)
 #include <asm/paravirt.h>

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

[David P. Reed]

Andi Kleen wrote:
> "
> With the additional call this should be completely out of line now to save 
> code size. Similar for the in variant.
>
>
>   
Sure.  Want me to make a new patch with the _p croutines out-of-line?

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

[Andi Kleen]

"David P. Reed" <dpreed@reed.com> writes:
>
> i386 family fixes (completely parallel) were not included, considering
> that such machines might involve more risk of problems on legacy machines.

They're needed because lots of people fomr some reason still boot 32bit kernels
on 64bit machines.
> +#define __OUT(s, s1, x) \

> +__OUT1(s, x) __OUT2(s, s1, "w") } \
> + __OUT1(s##_p, x) __OUT2(s, s1, "w") udelay(_IOPORT_PAUSE_DELAY); } \

With the additional call this should be completely out of line now to save 
code size. Similar for the in variant.

-Andi

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

[Rene Herman]

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

On 14-12-07 03:59, David P. Reed wrote:

> Replace use of outb to "unused" diagnostic port 0x80 for time delay
> with udelay based time delay on x86_64 architecture machines.  Fix for
> bugs 9511 and 6307 in bugzilla, plus bugs reported in
> bugzilla.redhat.com.
> 
> Derived from suggestion (that didn't compile) by Pavel Machek, and
> tested, also based on measurements of typical timings of out's
> collated by Rene Herman from many in the community.
> 
> This patch fixes a number of bugs known to cause problems on HP
> Pavilion dv9000z and dv6000z laptops - in the form of solid freezes
> when hwclock is used to show or set the time.  Also, it potentially
> improves bus utilization on SMP machines, by using a waiting process
> that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds.
> 
> i386 family fixes (completely parallel) were not included, considering
> that such machines might involve more risk of problems on legacy machines.

Here's the corresponding 32-bit patch. Applies fine to (and works on) 
v2.6.23.x as well after un-uniting the paths...

I do believe it would be better to do both; x86-64 machines can run 32-bit 
kernels fine and might certainly in the form of generic (installer) kernels 
and the like so if it's a fix lets fix it across the board -- the 2 us delay 
is going to be enough for everything out there, certainly given that _0_ is 
normally enough. With the arches just merged, minimising diferences should 
be a goal in itself I guess.

One thing though -- I believe we want to adjust the loops_per_jiffy default 
to make sure this works, or would work, pre-calibration as well? Not really 
sure how needed it is, but bogomips is defined as

	bogomips = loops_per_jiffy / (500000 / HZ)
			<=>
	loops_per_jiffy = bogomips * (500000 / HZ)

which with assuming any machine above 1G isn't affected by any of this and 
bogomips coming out to 2 * MHz on anything I myself have run linux on might 
suggest that

	loops_per_jiffy = 2 * 1000 * (500000 / HZ) = 1000000000 / HZ

could possibly be a sane if very large default? Alan?

diff --git a/init/main.c b/init/main.c
index 9def935..6d41771 100644
--- a/init/main.c
+++ b/init/main.c
@@ -229,10 +229,9 @@ static int __init obsolete_checksetup(char *line)
  }

  /*
- * This should be approx 2 Bo*oMips to start (note initial shift), and will
- * still work even if initially too large, it will just take slightly longer
+ * Initial value roughly corresponds to a 1 GHz CPU
   */
-unsigned long loops_per_jiffy = (1<<12);
+unsigned long loops_per_jiffy = 1000000000 / HZ;

  EXPORT_SYMBOL(loops_per_jiffy);

[-- Attachment #2: v24-port80.diff --]
[-- Type: text/plain, Size: 1783 bytes --]

From: Pavel Machek <pavel@ucw.cz>

32-bit part of the port 0x80 delay replacement.

diff --git a/arch/x86/boot/compressed/misc_32.c b/arch/x86/boot/compressed/misc_32.c
index b74d60d..288e162 100644
--- a/arch/x86/boot/compressed/misc_32.c
+++ b/arch/x86/boot/compressed/misc_32.c
@@ -276,10 +276,10 @@ static void putstr(const char *s)
 	RM_SCREEN_INFO.orig_y = y;
 
 	pos = (x + cols * y) * 2;	/* Update cursor position */
-	outb_p(14, vidport);
-	outb_p(0xff & (pos >> 9), vidport+1);
-	outb_p(15, vidport);
-	outb_p(0xff & (pos >> 1), vidport+1);
+	outb(14, vidport);
+	outb(0xff & (pos >> 9), vidport+1);
+	outb(15, vidport);
+	outb(0xff & (pos >> 1), vidport+1);
 }
 
 static void* memset(void* s, int c, unsigned n)
diff --git a/include/asm-x86/io_32.h b/include/asm-x86/io_32.h
index fe881cd..9abc215 100644
--- a/include/asm-x86/io_32.h
+++ b/include/asm-x86/io_32.h
@@ -3,6 +3,7 @@
 
 #include <linux/string.h>
 #include <linux/compiler.h>
+#include <linux/delay.h>
 
 /*
  * This file contains the definitions for the x86 IO instructions
@@ -17,17 +18,6 @@
  * mistake somewhere.
  */
 
-/*
- * Thanks to James van Artsdalen for a better timing-fix than
- * the two short jumps: using outb's to a nonexistent port seems
- * to guarantee better timings even on fast machines.
- *
- * On the other hand, I'd like to be sure of a non-existent port:
- * I feel a bit unsafe about using 0x80 (should be safe, though)
- *
- *		Linus
- */
-
  /*
   *  Bit simplified and optimized by Jan Hubicka
   *  Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999.
@@ -252,7 +242,7 @@ static inline void flush_write_buffers(void)
 
 static inline void native_io_delay(void)
 {
-	asm volatile("outb %%al,$0x80" : : : "memory");
+	udelay(2);
 }
 
 #if defined(CONFIG_PARAVIRT)

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

[Yinghai Lu]

On Dec 13, 2007 6:59 PM, David P. Reed <dpreed@reed.com> wrote:
> Replace use of outb to "unused" diagnostic port 0x80 for time delay
> with udelay based time delay on x86_64 architecture machines.  Fix for
> bugs 9511 and 6307 in bugzilla, plus bugs reported in
> bugzilla.redhat.com.
>
> Derived from suggestion (that didn't compile) by Pavel Machek, and
> tested, also based on measurements of typical timings of out's
> collated by Rene Herman from many in the community.
>
> This patch fixes a number of bugs known to cause problems on HP
> Pavilion dv9000z and dv6000z laptops - in the form of solid freezes
> when hwclock is used to show or set the time.  Also, it potentially
> improves bus utilization on SMP machines, by using a waiting process
> that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds.
>
> i386 family fixes (completely parallel) were not included, considering
> that such machines might involve more risk of problems on legacy machines.
>
> Signed-off-by: David P. Reed <dpreed@reed.com>
>
> Index: linux-2.6/arch/x86/boot/compressed/misc_64.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/boot/compressed/misc_64.c
> +++ linux-2.6/arch/x86/boot/compressed/misc_64.c
> @@ -269,10 +269,10 @@ static void putstr(const char *s)
>          RM_SCREEN_INFO.orig_y = y;
>
>          pos = (x + cols * y) * 2;       /* Update cursor position */
> -       outb_p(14, vidport);
> -       outb_p(0xff & (pos >> 9), vidport+1);
> -       outb_p(15, vidport);
> -       outb_p(0xff & (pos >> 1), vidport+1);
> +       outb(14, vidport);
> +       outb(0xff & (pos >> 9), vidport+1);
> +       outb(15, vidport);
> +       outb(0xff & (pos >> 1), vidport+1);
>   }
>
>   static void* memset(void* s, int c, unsigned n)
> Index: linux-2.6/include/asm/io_64.h
> ===================================================================
> --- linux-2.6.orig/include/asm/io_64.h
> +++ linux-2.6/include/asm/io_64.h

include/asm-x64/io_64.h ?

YH

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

[David P. Reed]

Replace use of outb to "unused" diagnostic port 0x80 for time delay
with udelay based time delay on x86_64 architecture machines.  Fix for
bugs 9511 and 6307 in bugzilla, plus bugs reported in
bugzilla.redhat.com.

Derived from suggestion (that didn't compile) by Pavel Machek, and
tested, also based on measurements of typical timings of out's
collated by Rene Herman from many in the community.

This patch fixes a number of bugs known to cause problems on HP
Pavilion dv9000z and dv6000z laptops - in the form of solid freezes
when hwclock is used to show or set the time.  Also, it potentially
improves bus utilization on SMP machines, by using a waiting process
that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds.

i386 family fixes (completely parallel) were not included, considering
that such machines might involve more risk of problems on legacy machines.

Signed-off-by: David P. Reed <dpreed@reed.com>

Index: linux-2.6/arch/x86/boot/compressed/misc_64.c
===================================================================
--- linux-2.6.orig/arch/x86/boot/compressed/misc_64.c
+++ linux-2.6/arch/x86/boot/compressed/misc_64.c
@@ -269,10 +269,10 @@ static void putstr(const char *s)
         RM_SCREEN_INFO.orig_y = y;

         pos = (x + cols * y) * 2;       /* Update cursor position */
-       outb_p(14, vidport);
-       outb_p(0xff & (pos >> 9), vidport+1);
-       outb_p(15, vidport);
-       outb_p(0xff & (pos >> 1), vidport+1);
+       outb(14, vidport);
+       outb(0xff & (pos >> 9), vidport+1);
+       outb(15, vidport);
+       outb(0xff & (pos >> 1), vidport+1);
  }

  static void* memset(void* s, int c, unsigned n)
Index: linux-2.6/include/asm/io_64.h
===================================================================
--- linux-2.6.orig/include/asm/io_64.h
+++ linux-2.6/include/asm/io_64.h
@@ -1,6 +1,7 @@
  #ifndef _ASM_IO_H
  #define _ASM_IO_H

+#include <linux/delay.h>

  /*
   * This file contains the definitions for the x86 IO instructions
@@ -15,19 +16,7 @@
   * mistake somewhere.
   */

-/*
- * Thanks to James van Artsdalen for a better timing-fix than
- * the two short jumps: using outb's to a nonexistent port seems
- * to guarantee better timings even on fast machines.
- *
- * On the other hand, I'd like to be sure of a non-existent port:
- * I feel a bit unsafe about using 0x80 (should be safe, though)
- *
- *             Linus
- */
-
- /*
-  *  Bit simplified and optimized by Jan Hubicka
+/*   Bit simplified and optimized by Jan Hubicka
    *  Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999.
    *
    *  isa_memset_io, isa_memcpy_fromio, isa_memcpy_toio added,
@@ -35,36 +24,36 @@
    *  - Arnaldo Carvalho de Melo <acme@conectiva.com.br>
    */

-#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
-
+/* the following delays are really conservative, at least for modern 
machines */
  #ifdef REALLY_SLOW_IO
-#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO __SLOW_DOWN_IO 
__SLOW_DOWN_IO __SLOW_DOWN_IO
+#define _IOPORT_PAUSE_DELAY 10
  #else
-#define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO
+#define _IOPORT_PAUSE_DELAY 2
  #endif

  /*
   * Talk about misusing macros..
   */
-#define __OUT1(s,x) \
+#define __OUT1(s, x) \
  static inline void out##s(unsigned x value, unsigned short port) {

-#define __OUT2(s,s1,s2) \
-__asm__ __volatile__ ("out" #s " %" s1 "0,%" s2 "1"
-
-#define __OUT(s,s1,x) \
-__OUT1(s,x) __OUT2(s,s1,"w") : : "a" (value), "Nd" (port)); } \
-__OUT1(s##_p,x) __OUT2(s,s1,"w") __FULL_SLOW_DOWN_IO : : "a" (value), 
"Nd" (port));} \
+#define __OUT2(s, s1, s2) \
+  __asm__ __volatile__ ("out" #s " %" s1 "0,%" s2 "1" : : "a" (value), 
"Nd" \
+(port));
+
+#define __OUT(s, s1, x) \
+__OUT1(s, x) __OUT2(s, s1, "w") } \
+ __OUT1(s##_p, x) __OUT2(s, s1, "w") udelay(_IOPORT_PAUSE_DELAY); } \

  #define __IN1(s) \
  static inline RETURN_TYPE in##s(unsigned short port) { RETURN_TYPE _v;

-#define __IN2(s,s1,s2) \
-__asm__ __volatile__ ("in" #s " %" s2 "1,%" s1 "0"
+#define __IN2(s, s1, s2) \
+__asm__ __volatile__ ("in" #s " %" s2 "1,%" s1 "0" : "=a" (_v) : "Nd" 
(port));

-#define __IN(s,s1,i...) \
-__IN1(s) __IN2(s,s1,"w") : "=a" (_v) : "Nd" (port) ,##i ); return _v; } \
-__IN1(s##_p) __IN2(s,s1,"w") __FULL_SLOW_DOWN_IO : "=a" (_v) : "Nd" 
(port) ,##i ); return _v; } \
+#define __IN(s, s1) \
+__IN1(s) __IN2(s, s1, "w") return _v; } \
+ __IN1(s##_p) __IN2(s, s1, "w") udelay(_IOPORT_PAUSE_DELAY); return _v; } \

  #define __INS(s) \
  static inline void ins##s(unsigned short port, void * addr, unsigned 
long count) \