* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
[not found] ` <fa.jU9nntHcOIpTOJuwui+u+/gya4Y@ifi.uio.no>
@ 2007-12-17 0:57 ` Robert Hancock
2007-12-17 15:27 ` Ingo Molnar
0 siblings, 1 reply; 70+ messages in thread
From: Robert Hancock @ 2007-12-17 0:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: H. Peter Anvin, Pavel Machek, David P. Reed, Thomas Gleixner,
linux-kernel, Ingo Molnar, Rene Herman
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/
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-17 0:57 ` [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc Robert Hancock
@ 2007-12-17 15:27 ` Ingo Molnar
0 siblings, 0 replies; 70+ messages in thread
From: Ingo Molnar @ 2007-12-17 15:27 UTC (permalink / raw)
To: Robert Hancock
Cc: H. Peter Anvin, Pavel Machek, David P. Reed, Thomas Gleixner,
linux-kernel, Ingo Molnar, Rene Herman
* 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-16 23:34 ` H. Peter Anvin
@ 2007-12-26 20:49 ` Pavel Machek
0 siblings, 0 replies; 70+ messages in thread
From: Pavel Machek @ 2007-12-26 20:49 UTC (permalink / raw)
To: H. Peter Anvin, security
Cc: David P. Reed, Ingo Molnar, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 2:13 ` David P. Reed
2007-12-15 2:20 ` H. Peter Anvin
2007-12-17 18:14 ` linux-os (Dick Johnson)
@ 2007-12-19 15:03 ` Avi Kivity
2 siblings, 0 replies; 70+ messages in thread
From: Avi Kivity @ 2007-12-19 15:03 UTC (permalink / raw)
To: David P. Reed
Cc: Thomas Gleixner, linux-kernel, Ingo Molnar, H. Peter Anvin,
Rene Herman, Pavel Machek, kvm-devel
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-18 0:06 ` Alan Cox
@ 2007-12-18 15:49 ` Lennart Sorensen
0 siblings, 0 replies; 70+ messages in thread
From: Lennart Sorensen @ 2007-12-18 15:49 UTC (permalink / raw)
To: Alan Cox
Cc: Pavel Machek, Rene Herman, H. Peter Anvin, Ingo Molnar,
David P. Reed, Thomas Gleixner, linux-kernel, Ingo Molnar
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-17 23:20 ` Pavel Machek
@ 2007-12-18 0:06 ` Alan Cox
2007-12-18 15:49 ` Lennart Sorensen
0 siblings, 1 reply; 70+ messages in thread
From: Alan Cox @ 2007-12-18 0:06 UTC (permalink / raw)
To: Pavel Machek
Cc: Rene Herman, H. Peter Anvin, Ingo Molnar, David P. Reed,
Thomas Gleixner, linux-kernel, Ingo Molnar
> > 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-17 21:04 ` Rene Herman
@ 2007-12-17 23:20 ` Pavel Machek
2007-12-18 0:06 ` Alan Cox
0 siblings, 1 reply; 70+ messages in thread
From: Pavel Machek @ 2007-12-17 23:20 UTC (permalink / raw)
To: Rene Herman
Cc: Alan Cox, H. Peter Anvin, Ingo Molnar, David P. Reed,
Thomas Gleixner, linux-kernel, Ingo Molnar
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-17 22:50 ` Jan Engelhardt
@ 2007-12-17 22:52 ` H. Peter Anvin
0 siblings, 0 replies; 70+ messages in thread
From: H. Peter Anvin @ 2007-12-17 22:52 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Alan Cox, David P. Reed, Pavel Machek, Ingo Molnar,
Thomas Gleixner, linux-kernel, Ingo Molnar, Rene Herman
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 17:46 ` Alan Cox
@ 2007-12-17 22:50 ` Jan Engelhardt
2007-12-17 22:52 ` H. Peter Anvin
0 siblings, 1 reply; 70+ messages in thread
From: Jan Engelhardt @ 2007-12-17 22:50 UTC (permalink / raw)
To: Alan Cox
Cc: David P. Reed, H. Peter Anvin, Pavel Machek, Ingo Molnar,
Thomas Gleixner, linux-kernel, Ingo Molnar, Rene Herman
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?
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 22:13 ` H. Peter Anvin
2007-12-14 23:29 ` Alan Cox
@ 2007-12-17 22:46 ` Jan Engelhardt
1 sibling, 0 replies; 70+ messages in thread
From: Jan Engelhardt @ 2007-12-17 22:46 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Pavel Machek, Ingo Molnar, David P. Reed, Thomas Gleixner,
linux-kernel, Ingo Molnar, Rene Herman
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 23:29 ` Alan Cox
2007-12-15 3:04 ` David P. Reed
2007-12-15 8:08 ` Paul Rolland
@ 2007-12-17 21:04 ` Rene Herman
2007-12-17 23:20 ` Pavel Machek
2 siblings, 1 reply; 70+ messages in thread
From: Rene Herman @ 2007-12-17 21:04 UTC (permalink / raw)
To: Alan Cox
Cc: H. Peter Anvin, Pavel Machek, Ingo Molnar, David P. Reed,
Thomas Gleixner, linux-kernel, Ingo Molnar
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-17 18:14 ` linux-os (Dick Johnson)
@ 2007-12-17 18:54 ` Rene Herman
0 siblings, 0 replies; 70+ messages in thread
From: Rene Herman @ 2007-12-17 18:54 UTC (permalink / raw)
To: linux-os (Dick Johnson)
Cc: David P. Reed, Avi Kivity, Thomas Gleixner, Linux kernel,
Ingo Molnar, H. Peter Anvin, Pavel Machek, kvm-devel
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 2:13 ` David P. Reed
2007-12-15 2:20 ` H. Peter Anvin
@ 2007-12-17 18:14 ` linux-os (Dick Johnson)
2007-12-17 18:54 ` Rene Herman
2007-12-19 15:03 ` Avi Kivity
2 siblings, 1 reply; 70+ messages in thread
From: linux-os (Dick Johnson) @ 2007-12-17 18:14 UTC (permalink / raw)
To: David P. Reed
Cc: Avi Kivity, Thomas Gleixner, Linux kernel, Ingo Molnar,
H. Peter Anvin, Rene Herman, Pavel Machek, kvm-devel
[-- 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)
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-16 21:43 ` H. Peter Anvin
2007-12-16 23:06 ` David P. Reed
@ 2007-12-17 1:51 ` Rene Herman
1 sibling, 0 replies; 70+ messages in thread
From: Rene Herman @ 2007-12-17 1:51 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, Pavel Machek, David P. Reed, Thomas Gleixner,
linux-kernel, Ingo Molnar
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
[not found] ` <fa.RR732o3u5kvPHNspJA9tM1WHlKI@ifi.uio.no>
@ 2007-12-17 0:53 ` Robert Hancock
0 siblings, 0 replies; 70+ messages in thread
From: Robert Hancock @ 2007-12-17 0:53 UTC (permalink / raw)
To: David P. Reed
Cc: Alan Cox, Ingo Molnar, Rene Herman, H. Peter Anvin,
Thomas Gleixner, linux-kernel, Ingo Molnar, Rene Herman,
Pavel Machek
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/
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-16 23:23 ` Pavel Machek
@ 2007-12-16 23:34 ` H. Peter Anvin
2007-12-26 20:49 ` Pavel Machek
0 siblings, 1 reply; 70+ messages in thread
From: H. Peter Anvin @ 2007-12-16 23:34 UTC (permalink / raw)
To: Pavel Machek
Cc: David P. Reed, Ingo Molnar, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-16 23:06 ` David P. Reed
@ 2007-12-16 23:23 ` Pavel Machek
2007-12-16 23:34 ` H. Peter Anvin
0 siblings, 1 reply; 70+ messages in thread
From: Pavel Machek @ 2007-12-16 23:23 UTC (permalink / raw)
To: David P. Reed
Cc: H. Peter Anvin, Ingo Molnar, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-16 21:43 ` H. Peter Anvin
@ 2007-12-16 23:06 ` David P. Reed
2007-12-16 23:23 ` Pavel Machek
2007-12-17 1:51 ` Rene Herman
1 sibling, 1 reply; 70+ messages in thread
From: David P. Reed @ 2007-12-16 23:06 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, Pavel Machek, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman
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
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-16 9:40 ` Ingo Molnar
@ 2007-12-16 21:43 ` H. Peter Anvin
2007-12-16 23:06 ` David P. Reed
2007-12-17 1:51 ` Rene Herman
0 siblings, 2 replies; 70+ messages in thread
From: H. Peter Anvin @ 2007-12-16 21:43 UTC (permalink / raw)
To: Ingo Molnar
Cc: Pavel Machek, David P. Reed, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 23:04 ` H. Peter Anvin
@ 2007-12-16 9:40 ` Ingo Molnar
2007-12-16 21:43 ` H. Peter Anvin
0 siblings, 1 reply; 70+ messages in thread
From: Ingo Molnar @ 2007-12-16 9:40 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Pavel Machek, David P. Reed, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman
* 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 20:26 ` H. Peter Anvin
2007-12-15 22:55 ` Pavel Machek
@ 2007-12-16 9:27 ` Ingo Molnar
1 sibling, 0 replies; 70+ messages in thread
From: Ingo Molnar @ 2007-12-16 9:27 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Paul Rolland, Alan Cox, Pavel Machek, David P. Reed,
Thomas Gleixner, linux-kernel, Ingo Molnar, Rene Herman, rol
* 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 23:00 ` Pavel Machek
@ 2007-12-15 23:04 ` H. Peter Anvin
2007-12-16 9:40 ` Ingo Molnar
0 siblings, 1 reply; 70+ messages in thread
From: H. Peter Anvin @ 2007-12-15 23:04 UTC (permalink / raw)
To: Pavel Machek
Cc: Ingo Molnar, David P. Reed, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 13:15 ` Ingo Molnar
` (2 preceding siblings ...)
2007-12-14 18:02 ` H. Peter Anvin
@ 2007-12-15 23:00 ` Pavel Machek
2007-12-15 23:04 ` H. Peter Anvin
3 siblings, 1 reply; 70+ messages in thread
From: Pavel Machek @ 2007-12-15 23:00 UTC (permalink / raw)
To: Ingo Molnar
Cc: David P. Reed, Thomas Gleixner, linux-kernel, Ingo Molnar,
H. Peter Anvin, Rene Herman
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 14:23 ` Ingo Molnar
2007-12-14 14:36 ` Rene Herman
@ 2007-12-15 22:59 ` Pavel Machek
1 sibling, 0 replies; 70+ messages in thread
From: Pavel Machek @ 2007-12-15 22:59 UTC (permalink / raw)
To: Ingo Molnar
Cc: Rene Herman, David P. Reed, Alan Cox, Thomas Gleixner,
linux-kernel, Ingo Molnar, H. Peter Anvin
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 20:26 ` H. Peter Anvin
@ 2007-12-15 22:55 ` Pavel Machek
2007-12-16 9:27 ` Ingo Molnar
1 sibling, 0 replies; 70+ messages in thread
From: Pavel Machek @ 2007-12-15 22:55 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Paul Rolland, Alan Cox, Ingo Molnar, David P. Reed,
Thomas Gleixner, linux-kernel, Ingo Molnar, Rene Herman, rol
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 8:13 ` Rene Herman
@ 2007-12-15 20:27 ` H. Peter Anvin
0 siblings, 0 replies; 70+ messages in thread
From: H. Peter Anvin @ 2007-12-15 20:27 UTC (permalink / raw)
To: Rene Herman
Cc: Paul Rolland, Alan Cox, Pavel Machek, Ingo Molnar, David P. Reed,
Thomas Gleixner, linux-kernel, Ingo Molnar, Rene Herman, rol
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 8:08 ` Paul Rolland
2007-12-15 8:13 ` Rene Herman
@ 2007-12-15 20:26 ` H. Peter Anvin
2007-12-15 22:55 ` Pavel Machek
2007-12-16 9:27 ` Ingo Molnar
1 sibling, 2 replies; 70+ messages in thread
From: H. Peter Anvin @ 2007-12-15 20:26 UTC (permalink / raw)
To: Paul Rolland
Cc: Alan Cox, Pavel Machek, Ingo Molnar, David P. Reed,
Thomas Gleixner, linux-kernel, Ingo Molnar, Rene Herman, rol
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 14:01 ` Rene Herman
@ 2007-12-15 20:25 ` H. Peter Anvin
0 siblings, 0 replies; 70+ messages in thread
From: H. Peter Anvin @ 2007-12-15 20:25 UTC (permalink / raw)
To: Rene Herman
Cc: Ingo Molnar, David P. Reed, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman, Pavel Machek, Alan Cox
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 16:19 ` David P. Reed
2007-12-15 16:48 ` Mark Lord
@ 2007-12-15 17:51 ` Alan Cox
1 sibling, 0 replies; 70+ messages in thread
From: Alan Cox @ 2007-12-15 17:51 UTC (permalink / raw)
To: David P. Reed
Cc: Ingo Molnar, Rene Herman, H. Peter Anvin, Thomas Gleixner,
linux-kernel, Ingo Molnar, Rene Herman, Pavel Machek
> 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 17:17 ` David P. Reed
@ 2007-12-15 17:46 ` Alan Cox
2007-12-17 22:50 ` Jan Engelhardt
0 siblings, 1 reply; 70+ messages in thread
From: Alan Cox @ 2007-12-15 17:46 UTC (permalink / raw)
To: David P. Reed
Cc: H. Peter Anvin, Pavel Machek, Ingo Molnar, Thomas Gleixner,
linux-kernel, Ingo Molnar, Rene Herman
> 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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 5:45 ` H. Peter Anvin
@ 2007-12-15 17:17 ` David P. Reed
2007-12-15 17:46 ` Alan Cox
0 siblings, 1 reply; 70+ messages in thread
From: David P. Reed @ 2007-12-15 17:17 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Alan Cox, Pavel Machek, Ingo Molnar, Thomas Gleixner,
linux-kernel, Ingo Molnar, Rene Herman
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 16:19 ` David P. Reed
@ 2007-12-15 16:48 ` Mark Lord
2007-12-15 17:51 ` Alan Cox
1 sibling, 0 replies; 70+ messages in thread
From: Mark Lord @ 2007-12-15 16:48 UTC (permalink / raw)
To: David P. Reed
Cc: Alan Cox, Ingo Molnar, Rene Herman, H. Peter Anvin,
Thomas Gleixner, linux-kernel, Ingo Molnar, Rene Herman,
Pavel Machek
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 14:29 ` Alan Cox
@ 2007-12-15 16:19 ` David P. Reed
2007-12-15 16:48 ` Mark Lord
2007-12-15 17:51 ` Alan Cox
0 siblings, 2 replies; 70+ messages in thread
From: David P. Reed @ 2007-12-15 16:19 UTC (permalink / raw)
To: Alan Cox
Cc: Ingo Molnar, Rene Herman, H. Peter Anvin, Thomas Gleixner,
linux-kernel, Ingo Molnar, Rene Herman, Pavel Machek
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
>
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 13:27 ` Ingo Molnar
2007-12-15 14:01 ` Rene Herman
@ 2007-12-15 14:29 ` Alan Cox
2007-12-15 16:19 ` David P. Reed
1 sibling, 1 reply; 70+ messages in thread
From: Alan Cox @ 2007-12-15 14:29 UTC (permalink / raw)
To: Ingo Molnar
Cc: Rene Herman, H. Peter Anvin, David P. Reed, Thomas Gleixner,
linux-kernel, Ingo Molnar, Rene Herman, Pavel Machek
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 13:27 ` Ingo Molnar
@ 2007-12-15 14:01 ` Rene Herman
2007-12-15 20:25 ` H. Peter Anvin
2007-12-15 14:29 ` Alan Cox
1 sibling, 1 reply; 70+ messages in thread
From: Rene Herman @ 2007-12-15 14:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: H. Peter Anvin, David P. Reed, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman, Pavel Machek, Alan Cox
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 7:58 ` Rene Herman
@ 2007-12-15 13:27 ` Ingo Molnar
2007-12-15 14:01 ` Rene Herman
2007-12-15 14:29 ` Alan Cox
0 siblings, 2 replies; 70+ messages in thread
From: Ingo Molnar @ 2007-12-15 13:27 UTC (permalink / raw)
To: Rene Herman
Cc: H. Peter Anvin, David P. Reed, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman, Pavel Machek, Alan Cox
* 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 8:08 ` Paul Rolland
@ 2007-12-15 8:13 ` Rene Herman
2007-12-15 20:27 ` H. Peter Anvin
2007-12-15 20:26 ` H. Peter Anvin
1 sibling, 1 reply; 70+ messages in thread
From: Rene Herman @ 2007-12-15 8:13 UTC (permalink / raw)
To: Paul Rolland
Cc: Alan Cox, H. Peter Anvin, Pavel Machek, Ingo Molnar,
David P. Reed, Thomas Gleixner, linux-kernel, Ingo Molnar,
Rene Herman, rol
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 23:29 ` Alan Cox
2007-12-15 3:04 ` David P. Reed
@ 2007-12-15 8:08 ` Paul Rolland
2007-12-15 8:13 ` Rene Herman
2007-12-15 20:26 ` H. Peter Anvin
2007-12-17 21:04 ` Rene Herman
2 siblings, 2 replies; 70+ messages in thread
From: Paul Rolland @ 2007-12-15 8:08 UTC (permalink / raw)
To: Alan Cox
Cc: H. Peter Anvin, Pavel Machek, Ingo Molnar, David P. Reed,
Thomas Gleixner, linux-kernel, Ingo Molnar, Rene Herman, rol
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 7:43 ` Ingo Molnar
@ 2007-12-15 7:58 ` Rene Herman
2007-12-15 13:27 ` Ingo Molnar
0 siblings, 1 reply; 70+ messages in thread
From: Rene Herman @ 2007-12-15 7:58 UTC (permalink / raw)
To: Ingo Molnar
Cc: H. Peter Anvin, David P. Reed, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman, Pavel Machek, Alan Cox
[-- 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>
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 18:02 ` H. Peter Anvin
2007-12-14 18:23 ` Rene Herman
2007-12-14 21:06 ` Pavel Machek
@ 2007-12-15 7:43 ` Ingo Molnar
2007-12-15 7:58 ` Rene Herman
2 siblings, 1 reply; 70+ messages in thread
From: Ingo Molnar @ 2007-12-15 7:43 UTC (permalink / raw)
To: H. Peter Anvin
Cc: David P. Reed, Thomas Gleixner, linux-kernel, Ingo Molnar,
Rene Herman, Pavel Machek
* 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 3:04 ` David P. Reed
@ 2007-12-15 5:45 ` H. Peter Anvin
2007-12-15 17:17 ` David P. Reed
0 siblings, 1 reply; 70+ messages in thread
From: H. Peter Anvin @ 2007-12-15 5:45 UTC (permalink / raw)
To: David P. Reed
Cc: Alan Cox, Pavel Machek, Ingo Molnar, Thomas Gleixner,
linux-kernel, Ingo Molnar, Rene Herman
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 23:29 ` Alan Cox
@ 2007-12-15 3:04 ` David P. Reed
2007-12-15 5:45 ` H. Peter Anvin
2007-12-15 8:08 ` Paul Rolland
2007-12-17 21:04 ` Rene Herman
2 siblings, 1 reply; 70+ messages in thread
From: David P. Reed @ 2007-12-15 3:04 UTC (permalink / raw)
To: Alan Cox
Cc: H. Peter Anvin, Pavel Machek, Ingo Molnar, Thomas Gleixner,
linux-kernel, Ingo Molnar, Rene Herman
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
>
>
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-15 2:13 ` David P. Reed
@ 2007-12-15 2:20 ` H. Peter Anvin
2007-12-17 18:14 ` linux-os (Dick Johnson)
2007-12-19 15:03 ` Avi Kivity
2 siblings, 0 replies; 70+ messages in thread
From: H. Peter Anvin @ 2007-12-15 2:20 UTC (permalink / raw)
To: David P. Reed
Cc: Avi Kivity, Thomas Gleixner, linux-kernel, Ingo Molnar,
Rene Herman, Pavel Machek, kvm-devel
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 16:08 ` Avi Kivity
@ 2007-12-15 2:13 ` David P. Reed
2007-12-15 2:20 ` H. Peter Anvin
` (2 more replies)
0 siblings, 3 replies; 70+ messages in thread
From: David P. Reed @ 2007-12-15 2:13 UTC (permalink / raw)
To: Avi Kivity
Cc: Thomas Gleixner, linux-kernel, Ingo Molnar, H. Peter Anvin,
Rene Herman, Pavel Machek, kvm-devel
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 22:13 ` H. Peter Anvin
@ 2007-12-14 23:29 ` Alan Cox
2007-12-15 3:04 ` David P. Reed
` (2 more replies)
2007-12-17 22:46 ` Jan Engelhardt
1 sibling, 3 replies; 70+ messages in thread
From: Alan Cox @ 2007-12-14 23:29 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Pavel Machek, Ingo Molnar, David P. Reed, Thomas Gleixner,
linux-kernel, Ingo Molnar, Rene Herman
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 21:06 ` Pavel Machek
@ 2007-12-14 22:13 ` H. Peter Anvin
2007-12-14 23:29 ` Alan Cox
2007-12-17 22:46 ` Jan Engelhardt
0 siblings, 2 replies; 70+ messages in thread
From: H. Peter Anvin @ 2007-12-14 22:13 UTC (permalink / raw)
To: Pavel Machek
Cc: Ingo Molnar, David P. Reed, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 18:02 ` H. Peter Anvin
2007-12-14 18:23 ` Rene Herman
@ 2007-12-14 21:06 ` Pavel Machek
2007-12-14 22:13 ` H. Peter Anvin
2007-12-15 7:43 ` Ingo Molnar
2 siblings, 1 reply; 70+ messages in thread
From: Pavel Machek @ 2007-12-14 21:06 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, David P. Reed, Thomas Gleixner, linux-kernel,
Ingo Molnar, Rene Herman
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 18:36 ` Alan Cox
2007-12-14 18:48 ` H. Peter Anvin
@ 2007-12-14 21:05 ` Pavel Machek
1 sibling, 0 replies; 70+ messages in thread
From: Pavel Machek @ 2007-12-14 21:05 UTC (permalink / raw)
To: Alan Cox
Cc: Rene Herman, Ingo Molnar, David P. Reed, Thomas Gleixner,
linux-kernel, Ingo Molnar, H. Peter Anvin
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 18:36 ` Alan Cox
@ 2007-12-14 18:48 ` H. Peter Anvin
2007-12-14 21:05 ` Pavel Machek
1 sibling, 0 replies; 70+ messages in thread
From: H. Peter Anvin @ 2007-12-14 18:48 UTC (permalink / raw)
To: Alan Cox
Cc: Rene Herman, Ingo Molnar, David P. Reed, Thomas Gleixner,
linux-kernel, Ingo Molnar, Pavel Machek
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 14:56 ` Rene Herman
@ 2007-12-14 18:36 ` Alan Cox
2007-12-14 18:48 ` H. Peter Anvin
2007-12-14 21:05 ` Pavel Machek
0 siblings, 2 replies; 70+ messages in thread
From: Alan Cox @ 2007-12-14 18:36 UTC (permalink / raw)
To: Rene Herman
Cc: Ingo Molnar, Rene Herman, David P. Reed, Thomas Gleixner,
linux-kernel, Ingo Molnar, H. Peter Anvin, Pavel Machek
> > 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 18:02 ` H. Peter Anvin
@ 2007-12-14 18:23 ` Rene Herman
2007-12-14 21:06 ` Pavel Machek
2007-12-15 7:43 ` Ingo Molnar
2 siblings, 0 replies; 70+ messages in thread
From: Rene Herman @ 2007-12-14 18:23 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, David P. Reed, Thomas Gleixner, linux-kernel,
Ingo Molnar, Pavel Machek
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 13:15 ` Ingo Molnar
2007-12-14 13:24 ` Ingo Molnar
2007-12-14 13:42 ` Rene Herman
@ 2007-12-14 18:02 ` H. Peter Anvin
2007-12-14 18:23 ` Rene Herman
` (2 more replies)
2007-12-15 23:00 ` Pavel Machek
3 siblings, 3 replies; 70+ messages in thread
From: H. Peter Anvin @ 2007-12-14 18:02 UTC (permalink / raw)
To: Ingo Molnar
Cc: David P. Reed, Thomas Gleixner, linux-kernel, Ingo Molnar,
Rene Herman, Pavel Machek
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 2:59 ` David P. Reed
` (3 preceding siblings ...)
2007-12-14 13:15 ` Ingo Molnar
@ 2007-12-14 16:08 ` Avi Kivity
2007-12-15 2:13 ` David P. Reed
4 siblings, 1 reply; 70+ messages in thread
From: Avi Kivity @ 2007-12-14 16:08 UTC (permalink / raw)
To: David P. Reed
Cc: Thomas Gleixner, linux-kernel, Ingo Molnar, H. Peter Anvin,
Rene Herman, Pavel Machek, kvm-devel
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 14:46 ` Ingo Molnar
@ 2007-12-14 14:56 ` Rene Herman
2007-12-14 18:36 ` Alan Cox
0 siblings, 1 reply; 70+ messages in thread
From: Rene Herman @ 2007-12-14 14:56 UTC (permalink / raw)
To: Ingo Molnar
Cc: Rene Herman, David P. Reed, Alan Cox, Thomas Gleixner,
linux-kernel, Ingo Molnar, H. Peter Anvin, Pavel Machek
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 14:36 ` Rene Herman
@ 2007-12-14 14:46 ` Ingo Molnar
2007-12-14 14:56 ` Rene Herman
0 siblings, 1 reply; 70+ messages in thread
From: Ingo Molnar @ 2007-12-14 14:46 UTC (permalink / raw)
To: Rene Herman
Cc: David P. Reed, Alan Cox, Thomas Gleixner, linux-kernel,
Ingo Molnar, H. Peter Anvin, Pavel Machek
* 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 13:47 ` Ingo Molnar
@ 2007-12-14 14:41 ` Ingo Molnar
0 siblings, 0 replies; 70+ messages in thread
From: Ingo Molnar @ 2007-12-14 14:41 UTC (permalink / raw)
To: David P. Reed
Cc: Thomas Gleixner, linux-kernel, Ingo Molnar, H. Peter Anvin,
Rene Herman, Pavel Machek
> > 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) \
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 14:23 ` Ingo Molnar
@ 2007-12-14 14:36 ` Rene Herman
2007-12-14 14:46 ` Ingo Molnar
2007-12-15 22:59 ` Pavel Machek
1 sibling, 1 reply; 70+ messages in thread
From: Rene Herman @ 2007-12-14 14:36 UTC (permalink / raw)
To: Ingo Molnar
Cc: Rene Herman, David P. Reed, Alan Cox, Thomas Gleixner,
linux-kernel, Ingo Molnar, H. Peter Anvin, Pavel Machek
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 9:45 ` Rene Herman
@ 2007-12-14 14:23 ` Ingo Molnar
2007-12-14 14:36 ` Rene Herman
2007-12-15 22:59 ` Pavel Machek
0 siblings, 2 replies; 70+ messages in thread
From: Ingo Molnar @ 2007-12-14 14:23 UTC (permalink / raw)
To: Rene Herman
Cc: David P. Reed, Alan Cox, Thomas Gleixner, linux-kernel,
Ingo Molnar, H. Peter Anvin, Pavel Machek
* 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 14:10 ` Rene Herman
@ 2007-12-14 14:21 ` Ingo Molnar
0 siblings, 0 replies; 70+ messages in thread
From: Ingo Molnar @ 2007-12-14 14:21 UTC (permalink / raw)
To: Rene Herman
Cc: David P. Reed, Thomas Gleixner, linux-kernel, Ingo Molnar,
H. Peter Anvin, Pavel Machek, Alan Cox
* 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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 14:03 ` Ingo Molnar
@ 2007-12-14 14:10 ` Rene Herman
2007-12-14 14:21 ` Ingo Molnar
0 siblings, 1 reply; 70+ messages in thread
From: Rene Herman @ 2007-12-14 14:10 UTC (permalink / raw)
To: Ingo Molnar
Cc: David P. Reed, Thomas Gleixner, linux-kernel, Ingo Molnar,
H. Peter Anvin, Pavel Machek, Alan Cox
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 13:42 ` Rene Herman
@ 2007-12-14 14:03 ` Ingo Molnar
2007-12-14 14:10 ` Rene Herman
0 siblings, 1 reply; 70+ messages in thread
From: Ingo Molnar @ 2007-12-14 14:03 UTC (permalink / raw)
To: Rene Herman
Cc: David P. Reed, Thomas Gleixner, linux-kernel, Ingo Molnar,
H. Peter Anvin, Pavel Machek, Alan Cox
* 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) \
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 13:24 ` Ingo Molnar
@ 2007-12-14 13:47 ` Ingo Molnar
2007-12-14 14:41 ` Ingo Molnar
0 siblings, 1 reply; 70+ messages in thread
From: Ingo Molnar @ 2007-12-14 13:47 UTC (permalink / raw)
To: David P. Reed
Cc: Thomas Gleixner, linux-kernel, Ingo Molnar, H. Peter Anvin,
Rene Herman, Pavel Machek
* 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) \
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 13:15 ` Ingo Molnar
2007-12-14 13:24 ` Ingo Molnar
@ 2007-12-14 13:42 ` Rene Herman
2007-12-14 14:03 ` Ingo Molnar
2007-12-14 18:02 ` H. Peter Anvin
2007-12-15 23:00 ` Pavel Machek
3 siblings, 1 reply; 70+ messages in thread
From: Rene Herman @ 2007-12-14 13:42 UTC (permalink / raw)
To: Ingo Molnar
Cc: David P. Reed, Thomas Gleixner, linux-kernel, Ingo Molnar,
H. Peter Anvin, Pavel Machek, Alan Cox
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.
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 13:15 ` Ingo Molnar
@ 2007-12-14 13:24 ` Ingo Molnar
2007-12-14 13:47 ` Ingo Molnar
2007-12-14 13:42 ` Rene Herman
` (2 subsequent siblings)
3 siblings, 1 reply; 70+ messages in thread
From: Ingo Molnar @ 2007-12-14 13:24 UTC (permalink / raw)
To: David P. Reed
Cc: Thomas Gleixner, linux-kernel, Ingo Molnar, H. Peter Anvin,
Rene Herman, Pavel Machek
* 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>
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 2:59 ` David P. Reed
` (2 preceding siblings ...)
2007-12-14 10:51 ` Andi Kleen
@ 2007-12-14 13:15 ` Ingo Molnar
2007-12-14 13:24 ` Ingo Molnar
` (3 more replies)
2007-12-14 16:08 ` Avi Kivity
4 siblings, 4 replies; 70+ messages in thread
From: Ingo Molnar @ 2007-12-14 13:15 UTC (permalink / raw)
To: David P. Reed
Cc: Thomas Gleixner, linux-kernel, Ingo Molnar, H. Peter Anvin,
Rene Herman, Pavel Machek
* 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>
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 10:51 ` Andi Kleen
@ 2007-12-14 11:11 ` David P. Reed
0 siblings, 0 replies; 70+ messages in thread
From: David P. Reed @ 2007-12-14 11:11 UTC (permalink / raw)
To: Andi Kleen
Cc: Thomas Gleixner, linux-kernel, Ingo Molnar, H. Peter Anvin,
Rene Herman, Pavel Machek
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?
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 2:59 ` David P. Reed
2007-12-14 7:49 ` Yinghai Lu
2007-12-14 9:45 ` Rene Herman
@ 2007-12-14 10:51 ` Andi Kleen
2007-12-14 11:11 ` David P. Reed
2007-12-14 13:15 ` Ingo Molnar
2007-12-14 16:08 ` Avi Kivity
4 siblings, 1 reply; 70+ messages in thread
From: Andi Kleen @ 2007-12-14 10:51 UTC (permalink / raw)
To: David P. Reed
Cc: Thomas Gleixner, linux-kernel, Ingo Molnar, H. Peter Anvin,
Rene Herman, Pavel Machek
"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
^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 2:59 ` David P. Reed
2007-12-14 7:49 ` Yinghai Lu
@ 2007-12-14 9:45 ` Rene Herman
2007-12-14 14:23 ` Ingo Molnar
2007-12-14 10:51 ` Andi Kleen
` (2 subsequent siblings)
4 siblings, 1 reply; 70+ messages in thread
From: Rene Herman @ 2007-12-14 9:45 UTC (permalink / raw)
To: David P. Reed, Alan Cox
Cc: Thomas Gleixner, linux-kernel, Ingo Molnar, H. Peter Anvin, Pavel Machek
[-- 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)
^ permalink raw reply related [flat|nested] 70+ messages in thread
* Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
2007-12-14 2:59 ` David P. Reed
@ 2007-12-14 7:49 ` Yinghai Lu
2007-12-14 9:45 ` Rene Herman
` (3 subsequent siblings)
4 siblings, 0 replies; 70+ messages in thread
From: Yinghai Lu @ 2007-12-14 7:49 UTC (permalink / raw)
To: David P. Reed
Cc: Thomas Gleixner, linux-kernel, Ingo Molnar, H. Peter Anvin,
Rene Herman, Pavel Machek
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
^ permalink raw reply [flat|nested] 70+ messages in thread
* [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
[not found] ` <1184274754.12353.254.camel@chaos>
@ 2007-12-14 2:59 ` David P. Reed
2007-12-14 7:49 ` Yinghai Lu
` (4 more replies)
0 siblings, 5 replies; 70+ messages in thread
From: David P. Reed @ 2007-12-14 2:59 UTC (permalink / raw)
To: Thomas Gleixner, linux-kernel, Ingo Molnar, H. Peter Anvin
Cc: Rene Herman, Pavel Machek
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) \
^ permalink raw reply [flat|nested] 70+ messages in thread
end of thread, other threads:[~2007-12-26 20:49 UTC | newest]
Thread overview: 70+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <fa.F/CPALGk5eBe3QDRN7pjalMH5m4@ifi.uio.no>
[not found] ` <fa.56LRmmk2ZdofP2s+juNK5l0iREQ@ifi.uio.no>
[not found] ` <fa.FRcgZwrZusfLF5d88S6yPr2bvYo@ifi.uio.no>
[not found] ` <fa.eZe9IlwlTeEF/5eA+8kKfNUncS4@ifi.uio.no>
[not found] ` <fa.EBJleK5JYl+P/h3+2m6zPq3PzDc@ifi.uio.no>
[not found] ` <fa.jU9nntHcOIpTOJuwui+u+/gya4Y@ifi.uio.no>
2007-12-17 0:57 ` [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc Robert Hancock
2007-12-17 15:27 ` Ingo Molnar
[not found] <fa.SxdP/X04a85FM81xaEZMBrrv9i4@ifi.uio.no>
[not found] ` <fa.tplCM7jT7JqanJcCtGK76o+Mdsw@ifi.uio.no>
[not found] ` <fa.lWVoQaFEkNNX7F+8WUJpMQjIODE@ifi.uio.no>
[not found] ` <fa.ng4A2MLKS/VR9lS0zt0LDJIDwi0@ifi.uio.no>
[not found] ` <fa.yZlGBJmYGGt3AQuIiiu7uMT3W9w@ifi.uio.no>
[not found] ` <fa.RR732o3u5kvPHNspJA9tM1WHlKI@ifi.uio.no>
2007-12-17 0:53 ` Robert Hancock
[not found] <466F0941.9060201@reed.com>
[not found] ` <1181682498.8176.224.camel@chaos>
[not found] ` <469578CD.3080609@reed.com>
[not found] ` <1184216528.12353.203.camel@chaos>
[not found] ` <1184218962.12353.209.camel@chaos>
[not found] ` <46964352.7040301@reed.com>
[not found] ` <1184253339.12353.223.camel@chaos>
[not found] ` <469697C6.50903@reed.com>
[not found] ` <1184274754.12353.254.camel@chaos>
2007-12-14 2:59 ` David P. Reed
2007-12-14 7:49 ` Yinghai Lu
2007-12-14 9:45 ` Rene Herman
2007-12-14 14:23 ` Ingo Molnar
2007-12-14 14:36 ` Rene Herman
2007-12-14 14:46 ` Ingo Molnar
2007-12-14 14:56 ` Rene Herman
2007-12-14 18:36 ` Alan Cox
2007-12-14 18:48 ` H. Peter Anvin
2007-12-14 21:05 ` Pavel Machek
2007-12-15 22:59 ` Pavel Machek
2007-12-14 10:51 ` Andi Kleen
2007-12-14 11:11 ` David P. Reed
2007-12-14 13:15 ` Ingo Molnar
2007-12-14 13:24 ` Ingo Molnar
2007-12-14 13:47 ` Ingo Molnar
2007-12-14 14:41 ` Ingo Molnar
2007-12-14 13:42 ` Rene Herman
2007-12-14 14:03 ` Ingo Molnar
2007-12-14 14:10 ` Rene Herman
2007-12-14 14:21 ` Ingo Molnar
2007-12-14 18:02 ` H. Peter Anvin
2007-12-14 18:23 ` Rene Herman
2007-12-14 21:06 ` Pavel Machek
2007-12-14 22:13 ` H. Peter Anvin
2007-12-14 23:29 ` Alan Cox
2007-12-15 3:04 ` David P. Reed
2007-12-15 5:45 ` H. Peter Anvin
2007-12-15 17:17 ` David P. Reed
2007-12-15 17:46 ` Alan Cox
2007-12-17 22:50 ` Jan Engelhardt
2007-12-17 22:52 ` H. Peter Anvin
2007-12-15 8:08 ` Paul Rolland
2007-12-15 8:13 ` Rene Herman
2007-12-15 20:27 ` H. Peter Anvin
2007-12-15 20:26 ` H. Peter Anvin
2007-12-15 22:55 ` Pavel Machek
2007-12-16 9:27 ` Ingo Molnar
2007-12-17 21:04 ` Rene Herman
2007-12-17 23:20 ` Pavel Machek
2007-12-18 0:06 ` Alan Cox
2007-12-18 15:49 ` Lennart Sorensen
2007-12-17 22:46 ` Jan Engelhardt
2007-12-15 7:43 ` Ingo Molnar
2007-12-15 7:58 ` Rene Herman
2007-12-15 13:27 ` Ingo Molnar
2007-12-15 14:01 ` Rene Herman
2007-12-15 20:25 ` H. Peter Anvin
2007-12-15 14:29 ` Alan Cox
2007-12-15 16:19 ` David P. Reed
2007-12-15 16:48 ` Mark Lord
2007-12-15 17:51 ` Alan Cox
2007-12-15 23:00 ` Pavel Machek
2007-12-15 23:04 ` H. Peter Anvin
2007-12-16 9:40 ` Ingo Molnar
2007-12-16 21:43 ` H. Peter Anvin
2007-12-16 23:06 ` David P. Reed
2007-12-16 23:23 ` Pavel Machek
2007-12-16 23:34 ` H. Peter Anvin
2007-12-26 20:49 ` Pavel Machek
2007-12-17 1:51 ` Rene Herman
2007-12-14 16:08 ` Avi Kivity
2007-12-15 2:13 ` David P. Reed
2007-12-15 2:20 ` H. Peter Anvin
2007-12-17 18:14 ` linux-os (Dick Johnson)
2007-12-17 18:54 ` Rene Herman
2007-12-19 15:03 ` Avi Kivity
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).