Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Mon 2007-12-17 15:42:51, Ingo Molnar wrote: > > * Pavel Machek <[EMAIL PROTECTED]> wrote: > > > > > > ./char/epca.c > > > > > ./char/sonypi.c > > > > > ./scsi/megaraid.c > > > > > ./ide/pci/serverworks.c > > > > > ./ide/pci/cmd640.c > > > > > ./input/mouse/pc110pad.c > > > > > > You are missing some watchdogs at least ? > > > > I snipped them, I only wanted to comment that pc110pad.c looks like > > legitimate use of outb_p(). > > since this code seems to run late during bootup (a mouse driver), could > we replace this with udelay(2), and get rid of that outb_p()? I.e. via > the patch below? Yes, that should work. But I do not have pc110 to verify it. > > Ingo > > -> > Subject: x86: replace outb_p() with udelay(2) in > drivers/input/mouse/pc110pad.c > From: Ingo Molnar <[EMAIL PROTECTED]> > > replace outb_p() with udelay(2). This is a real ISA device so it likely > needs this particular delay. > > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> ACK. > int value = inb_p(pc110pad_io); > int handshake = inb_p(pc110pad_io + 2); > > - outb_p(handshake | 1, pc110pad_io + 2); > - outb_p(handshake & ~1, pc110pad_io + 2); > + outb(handshake | 1, pc110pad_io + 2); > + udelay(2); > + outb(handshake & ~1, pc110pad_io + 2); > + udelay(2); > inb_p(0x64); > > pc110pad_data[pc110pad_count++] = value; > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Mon 2007-12-17 15:42:51, Ingo Molnar wrote: * Pavel Machek [EMAIL PROTECTED] wrote: ./char/epca.c ./char/sonypi.c ./scsi/megaraid.c ./ide/pci/serverworks.c ./ide/pci/cmd640.c ./input/mouse/pc110pad.c You are missing some watchdogs at least ? I snipped them, I only wanted to comment that pc110pad.c looks like legitimate use of outb_p(). since this code seems to run late during bootup (a mouse driver), could we replace this with udelay(2), and get rid of that outb_p()? I.e. via the patch below? Yes, that should work. But I do not have pc110 to verify it. Ingo - Subject: x86: replace outb_p() with udelay(2) in drivers/input/mouse/pc110pad.c From: Ingo Molnar [EMAIL PROTECTED] replace outb_p() with udelay(2). This is a real ISA device so it likely needs this particular delay. Signed-off-by: Ingo Molnar [EMAIL PROTECTED] ACK. int value = inb_p(pc110pad_io); int handshake = inb_p(pc110pad_io + 2); - outb_p(handshake | 1, pc110pad_io + 2); - outb_p(handshake ~1, pc110pad_io + 2); + outb(handshake | 1, pc110pad_io + 2); + udelay(2); + outb(handshake ~1, pc110pad_io + 2); + udelay(2); inb_p(0x64); pc110pad_data[pc110pad_count++] = value; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
* Pavel Machek <[EMAIL PROTECTED]> wrote: > > > > ./char/epca.c > > > > ./char/sonypi.c > > > > ./scsi/megaraid.c > > > > ./ide/pci/serverworks.c > > > > ./ide/pci/cmd640.c > > > > ./input/mouse/pc110pad.c > > > > You are missing some watchdogs at least ? > > I snipped them, I only wanted to comment that pc110pad.c looks like > legitimate use of outb_p(). since this code seems to run late during bootup (a mouse driver), could we replace this with udelay(2), and get rid of that outb_p()? I.e. via the patch below? Ingo -> Subject: x86: replace outb_p() with udelay(2) in drivers/input/mouse/pc110pad.c From: Ingo Molnar <[EMAIL PROTECTED]> replace outb_p() with udelay(2). This is a real ISA device so it likely needs this particular delay. Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- drivers/input/mouse/pc110pad.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) Index: linux-x86.q/drivers/input/mouse/pc110pad.c === --- linux-x86.q.orig/drivers/input/mouse/pc110pad.c +++ linux-x86.q/drivers/input/mouse/pc110pad.c @@ -39,6 +39,7 @@ #include #include #include +#include #include #include @@ -62,8 +63,10 @@ static irqreturn_t pc110pad_interrupt(in int value = inb_p(pc110pad_io); int handshake = inb_p(pc110pad_io + 2); - outb_p(handshake | 1, pc110pad_io + 2); - outb_p(handshake & ~1, pc110pad_io + 2); + outb(handshake | 1, pc110pad_io + 2); + udelay(2); + outb(handshake & ~1, pc110pad_io + 2); + udelay(2); inb_p(0x64); pc110pad_data[pc110pad_count++] = value; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
* Pavel Machek [EMAIL PROTECTED] wrote: ./char/epca.c ./char/sonypi.c ./scsi/megaraid.c ./ide/pci/serverworks.c ./ide/pci/cmd640.c ./input/mouse/pc110pad.c You are missing some watchdogs at least ? I snipped them, I only wanted to comment that pc110pad.c looks like legitimate use of outb_p(). since this code seems to run late during bootup (a mouse driver), could we replace this with udelay(2), and get rid of that outb_p()? I.e. via the patch below? Ingo - Subject: x86: replace outb_p() with udelay(2) in drivers/input/mouse/pc110pad.c From: Ingo Molnar [EMAIL PROTECTED] replace outb_p() with udelay(2). This is a real ISA device so it likely needs this particular delay. Signed-off-by: Ingo Molnar [EMAIL PROTECTED] --- drivers/input/mouse/pc110pad.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) Index: linux-x86.q/drivers/input/mouse/pc110pad.c === --- linux-x86.q.orig/drivers/input/mouse/pc110pad.c +++ linux-x86.q/drivers/input/mouse/pc110pad.c @@ -39,6 +39,7 @@ #include linux/init.h #include linux/interrupt.h #include linux/pci.h +#include linux/delay.h #include asm/io.h #include asm/irq.h @@ -62,8 +63,10 @@ static irqreturn_t pc110pad_interrupt(in int value = inb_p(pc110pad_io); int handshake = inb_p(pc110pad_io + 2); - outb_p(handshake | 1, pc110pad_io + 2); - outb_p(handshake ~1, pc110pad_io + 2); + outb(handshake | 1, pc110pad_io + 2); + udelay(2); + outb(handshake ~1, pc110pad_io + 2); + udelay(2); inb_p(0x64); pc110pad_data[pc110pad_count++] = value; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Mon 2007-12-17 00:03:01, Alan Cox wrote: > On Sun, 16 Dec 2007 22:26:33 +0100 > Pavel Machek <[EMAIL PROTECTED]> wrote: > > > On Fri 2007-12-14 15:33:28, Ingo Molnar wrote: > > > > > > * Alan Cox <[EMAIL PROTECTED]> wrote: > > > > > > > There is another reason we can't just do a dumb changeover - two > > > > actually > > > > > > > > #1: Some drivers are using inb_p/outb_p in PCI cases which are going > > > > #to cause PCI posting changes. Most are probably just wrong in the > > > > #first place but they need hand checking > > > > > > hm, any intelligent way to force PCI posting? I guess not. > > > > > > here's a list of candidate drivers (match the out*_p() pattern and do > > > pci) > > > > > > ./char/epca.c > > > ./char/sonypi.c > > > ./scsi/megaraid.c > > > ./ide/pci/serverworks.c > > > ./ide/pci/cmd640.c > > > ./input/mouse/pc110pad.c > > You are missing some watchdogs at least ? I snipped them, I only wanted to comment that pc110pad.c looks like legitimate use of outb_p(). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
> /* > * We try to avoid enabling the hardware if it's not > * there, but we don't know how to test. But we do know > * that the PC110 is not a PCI system. So if we find any > * PCI devices in the machine, we don't have a PC110. > */ The pc110 pad device is ISA. Its an ISA bus 486 box Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Sun, 16 Dec 2007 22:26:33 +0100 Pavel Machek <[EMAIL PROTECTED]> wrote: > On Fri 2007-12-14 15:33:28, Ingo Molnar wrote: > > > > * Alan Cox <[EMAIL PROTECTED]> wrote: > > > > > There is another reason we can't just do a dumb changeover - two > > > actually > > > > > > #1: Some drivers are using inb_p/outb_p in PCI cases which are going > > > #to cause PCI posting changes. Most are probably just wrong in the > > > #first place but they need hand checking > > > > hm, any intelligent way to force PCI posting? I guess not. > > > > here's a list of candidate drivers (match the out*_p() pattern and do > > pci) > > > > ./char/epca.c > > ./char/sonypi.c > > ./scsi/megaraid.c > > ./ide/pci/serverworks.c > > ./ide/pci/cmd640.c > > ./input/mouse/pc110pad.c You are missing some watchdogs at least ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Fri 2007-12-14 15:33:28, Ingo Molnar wrote: > > * Alan Cox <[EMAIL PROTECTED]> wrote: > > > There is another reason we can't just do a dumb changeover - two > > actually > > > > #1: Some drivers are using inb_p/outb_p in PCI cases which are going > > #to cause PCI posting changes. Most are probably just wrong in the > > #first place but they need hand checking > > hm, any intelligent way to force PCI posting? I guess not. > > here's a list of candidate drivers (match the out*_p() pattern and do > pci) > > ./char/epca.c > ./char/sonypi.c > ./scsi/megaraid.c > ./ide/pci/serverworks.c > ./ide/pci/cmd640.c > ./input/mouse/pc110pad.c /* * We try to avoid enabling the hardware if it's not * there, but we don't know how to test. But we do know * that the PC110 is not a PCI system. So if we find any * PCI devices in the machine, we don't have a PC110. */ ...so pc110 _may_ be okay. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
/* * We try to avoid enabling the hardware if it's not * there, but we don't know how to test. But we do know * that the PC110 is not a PCI system. So if we find any * PCI devices in the machine, we don't have a PC110. */ The pc110 pad device is ISA. Its an ISA bus 486 box Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Sun, 16 Dec 2007 22:26:33 +0100 Pavel Machek [EMAIL PROTECTED] wrote: On Fri 2007-12-14 15:33:28, Ingo Molnar wrote: * Alan Cox [EMAIL PROTECTED] wrote: There is another reason we can't just do a dumb changeover - two actually #1: Some drivers are using inb_p/outb_p in PCI cases which are going #to cause PCI posting changes. Most are probably just wrong in the #first place but they need hand checking hm, any intelligent way to force PCI posting? I guess not. here's a list of candidate drivers (match the out*_p() pattern and do pci) ./char/epca.c ./char/sonypi.c ./scsi/megaraid.c ./ide/pci/serverworks.c ./ide/pci/cmd640.c ./input/mouse/pc110pad.c You are missing some watchdogs at least ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Mon 2007-12-17 00:03:01, Alan Cox wrote: On Sun, 16 Dec 2007 22:26:33 +0100 Pavel Machek [EMAIL PROTECTED] wrote: On Fri 2007-12-14 15:33:28, Ingo Molnar wrote: * Alan Cox [EMAIL PROTECTED] wrote: There is another reason we can't just do a dumb changeover - two actually #1: Some drivers are using inb_p/outb_p in PCI cases which are going #to cause PCI posting changes. Most are probably just wrong in the #first place but they need hand checking hm, any intelligent way to force PCI posting? I guess not. here's a list of candidate drivers (match the out*_p() pattern and do pci) ./char/epca.c ./char/sonypi.c ./scsi/megaraid.c ./ide/pci/serverworks.c ./ide/pci/cmd640.c ./input/mouse/pc110pad.c You are missing some watchdogs at least ? I snipped them, I only wanted to comment that pc110pad.c looks like legitimate use of outb_p(). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Fri 2007-12-14 15:33:28, Ingo Molnar wrote: * Alan Cox [EMAIL PROTECTED] wrote: There is another reason we can't just do a dumb changeover - two actually #1: Some drivers are using inb_p/outb_p in PCI cases which are going #to cause PCI posting changes. Most are probably just wrong in the #first place but they need hand checking hm, any intelligent way to force PCI posting? I guess not. here's a list of candidate drivers (match the out*_p() pattern and do pci) ./char/epca.c ./char/sonypi.c ./scsi/megaraid.c ./ide/pci/serverworks.c ./ide/pci/cmd640.c ./input/mouse/pc110pad.c /* * We try to avoid enabling the hardware if it's not * there, but we don't know how to test. But we do know * that the PC110 is not a PCI system. So if we find any * PCI devices in the machine, we don't have a PC110. */ ...so pc110 _may_ be okay. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Thu, 13 Dec 2007 20:50:33 -0500 "David P. Reed" <[EMAIL PROTECTED]> wrote: > Simulating 1 microsecond delays (assuming LPC meets that goal for 0x80) > is "absolutely correct" for devices provided on PCI-X running on 3 GHz > or greater machines? Yes - the LPC bus clock doesn't change for the CPU clock. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
* Alan Cox <[EMAIL PROTECTED]> wrote: > There is another reason we can't just do a dumb changeover - two > actually > > #1: Some drivers are using inb_p/outb_p in PCI cases which are going > #to cause PCI posting changes. Most are probably just wrong in the > #first place but they need hand checking hm, any intelligent way to force PCI posting? I guess not. here's a list of candidate drivers (match the out*_p() pattern and do pci) ./char/epca.c ./char/sonypi.c ./scsi/megaraid.c ./ide/pci/serverworks.c ./ide/pci/cmd640.c ./input/mouse/pc110pad.c ./i2c/busses/i2c-amd756.c ./i2c/busses/i2c-ali15x3.c ./i2c/busses/i2c-ali1563.c ./i2c/busses/i2c-ali1535.c ./i2c/busses/i2c-viapro.c ./i2c/busses/i2c-nforce2.c ./i2c/busses/i2c-i801.c ./i2c/busses/i2c-piix4.c ./hwmon/vt8231.c ./hwmon/via686a.c ./hwmon/sis5595.c ./telephony/ixj.c ./net/irda/donauboe.c ./watchdog/pcwd_pci.c ./watchdog/wdt_pci.c > #2: We've got SMP cases that only 'work' because the odds of splitting > the outb and the following port 0x80 cycle, which locks the bus, are tiny. > > That is we've got > > CPU1CPU2 > main path irq path > outb > outb > > inb 0x80 > inb 0x80 > > races in one or two spots. which seems to suggest we are better off not doing the port 0x80 trick at all. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Why is TSC significant? udelay() based on bogomips seems to be good
> > enough...?
>
> Maybe I'm not sure how accurate it really is on non TSC system. On the
> other hand it is unclear that the port 80 IO is always the same time
> so it's probably ok to vary a bit. So most likely going to udelay()
> unconditionally is fine.
yep, agreed, and have queued up the patch below. I've killed the
misc_*.c outb_p() uses because they happen before there's an udelay()
available - but that should be perfectly fine anyway: i dont remember
any video hardware that needed pauses for cursor updates, i think those
_p()'s just came in accidentally. (there's hardware that needed _p() for
other aspects of video such as mode switching - but cursor updates ...)
Ingo
-->
Subject: x86: fix in/out_p delays
From: Ingo Molnar <[EMAIL PROTECTED]>
Debugged by David P. Reed <[EMAIL PROTECTED]>.
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 <[EMAIL PROTECTED]>
---
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
#include
+#include
#include
+/*
+ * 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
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 <[EMAIL PROTECTED]>
*/
-static inline void native_io_delay(void)
-{
- asm volatile("outb %%al,$0x80" : : : "memory");
-}
+extern void native_io_delay(void);
#if defined(CONFIG_PARAVIRT)
#include
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
* Alan Cox [EMAIL PROTECTED] wrote: There is another reason we can't just do a dumb changeover - two actually #1: Some drivers are using inb_p/outb_p in PCI cases which are going #to cause PCI posting changes. Most are probably just wrong in the #first place but they need hand checking hm, any intelligent way to force PCI posting? I guess not. here's a list of candidate drivers (match the out*_p() pattern and do pci) ./char/epca.c ./char/sonypi.c ./scsi/megaraid.c ./ide/pci/serverworks.c ./ide/pci/cmd640.c ./input/mouse/pc110pad.c ./i2c/busses/i2c-amd756.c ./i2c/busses/i2c-ali15x3.c ./i2c/busses/i2c-ali1563.c ./i2c/busses/i2c-ali1535.c ./i2c/busses/i2c-viapro.c ./i2c/busses/i2c-nforce2.c ./i2c/busses/i2c-i801.c ./i2c/busses/i2c-piix4.c ./hwmon/vt8231.c ./hwmon/via686a.c ./hwmon/sis5595.c ./telephony/ixj.c ./net/irda/donauboe.c ./watchdog/pcwd_pci.c ./watchdog/wdt_pci.c #2: We've got SMP cases that only 'work' because the odds of splitting the outb and the following port 0x80 cycle, which locks the bus, are tiny. That is we've got CPU1CPU2 main path irq path outb outb inb 0x80 inb 0x80 races in one or two spots. which seems to suggest we are better off not doing the port 0x80 trick at all. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
* Andi Kleen [EMAIL PROTECTED] wrote:
Why is TSC significant? udelay() based on bogomips seems to be good
enough...?
Maybe I'm not sure how accurate it really is on non TSC system. On the
other hand it is unclear that the port 80 IO is always the same time
so it's probably ok to vary a bit. So most likely going to udelay()
unconditionally is fine.
yep, agreed, and have queued up the patch below. I've killed the
misc_*.c outb_p() uses because they happen before there's an udelay()
available - but that should be perfectly fine anyway: i dont remember
any video hardware that needed pauses for cursor updates, i think those
_p()'s just came in accidentally. (there's hardware that needed _p() for
other aspects of video such as mode switching - but cursor updates ...)
Ingo
--
Subject: x86: fix in/out_p delays
From: Ingo Molnar [EMAIL PROTECTED]
Debugged by David P. Reed [EMAIL PROTECTED].
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 [EMAIL PROTECTED]
---
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 [EMAIL PROTECTED]
*/
-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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Thu, 13 Dec 2007 20:50:33 -0500 David P. Reed [EMAIL PROTECTED] wrote: Simulating 1 microsecond delays (assuming LPC meets that goal for 0x80) is absolutely correct for devices provided on PCI-X running on 3 GHz or greater machines? Yes - the LPC bus clock doesn't change for the CPU clock. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Simulating 1 microsecond delays (assuming LPC meets that goal for 0x80) is "absolutely correct" for devices provided on PCI-X running on 3 GHz or greater machines? Well, you are entitled to your opinion. Seems likely that reading the timing specs of such a chipset might be correct, and delaying for a time proportional to CPU speed, rather than assuming running 3000 3GHz clock cycles is needed on a very fast emulation of an old device that probably runs at the fastest bus speed provided in the chipset. Every device has different timing constraints. In the real world that I live in. Alan Cox wrote: On Thu, 13 Dec 2007 08:13:29 -0500 "David P. Reed" <[EMAIL PROTECTED]> wrote: Perhaps what was meant is that ISA-tuned timings make little sense on devices that are part of the chipset or on the PCI or PCI-X buses? No. ISA as LPC bus is alive and well inside and outside chipsets. Welcome to planet earth and the reality of 'its cheaper to reuse cells than design a new one'. For the chipset logic like DMA controllers the _p is absolutely correct. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Thu, 13 Dec 2007 08:13:29 -0500 "David P. Reed" <[EMAIL PROTECTED]> wrote: > Perhaps what was meant is that ISA-tuned timings make little sense on > devices that are part of the chipset or on the PCI or PCI-X buses? No. ISA as LPC bus is alive and well inside and outside chipsets. Welcome to planet earth and the reality of 'its cheaper to reuse cells than design a new one'. For the chipset logic like DMA controllers the _p is absolutely correct. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Perhaps what was meant is that ISA-tuned timings make little sense on devices that are part of the chipset or on the PCI or PCI-X buses? On the other hand, since we don't know in many cases whether the "_p" was supposed to mean "the time it takes to execute an "out al,80h" on whatever bus structure happens to be on whatever machine, the problem is unsolvable. Ranting about whether ISA/LPC is on what machines seems to be of little value in contributing to a constructive solution. It seems to me that in the long term, driver writers would do well to think more clearly about the timings their devices require, when that is possible. They are probably implementation dependent - depending on the clock speed of the particular clock that is driving the particular i/o device. Then there's the social problem of a community development project - which is to get people to tune their code but preserve its ability to run on older and variant machines. Alan Cox wrote: Yes, it's now clear that all of this is so. Regrettably, it's used in dozens of drivers, most having nothing to do with an ISA/LPC bus. If it really is specific to the ISA architecture, then it should only be used in architecture specific code. ISA/LPC is not architecture specific. In fact ISA/LPC bus components get everywhere because the PC market drives the cost per unit for those components down to nearly nothing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Perhaps what was meant is that ISA-tuned timings make little sense on devices that are part of the chipset or on the PCI or PCI-X buses? On the other hand, since we don't know in many cases whether the _p was supposed to mean the time it takes to execute an out al,80h on whatever bus structure happens to be on whatever machine, the problem is unsolvable. Ranting about whether ISA/LPC is on what machines seems to be of little value in contributing to a constructive solution. It seems to me that in the long term, driver writers would do well to think more clearly about the timings their devices require, when that is possible. They are probably implementation dependent - depending on the clock speed of the particular clock that is driving the particular i/o device. Then there's the social problem of a community development project - which is to get people to tune their code but preserve its ability to run on older and variant machines. Alan Cox wrote: Yes, it's now clear that all of this is so. Regrettably, it's used in dozens of drivers, most having nothing to do with an ISA/LPC bus. If it really is specific to the ISA architecture, then it should only be used in architecture specific code. ISA/LPC is not architecture specific. In fact ISA/LPC bus components get everywhere because the PC market drives the cost per unit for those components down to nearly nothing. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Thu, 13 Dec 2007 08:13:29 -0500 David P. Reed [EMAIL PROTECTED] wrote: Perhaps what was meant is that ISA-tuned timings make little sense on devices that are part of the chipset or on the PCI or PCI-X buses? No. ISA as LPC bus is alive and well inside and outside chipsets. Welcome to planet earth and the reality of 'its cheaper to reuse cells than design a new one'. For the chipset logic like DMA controllers the _p is absolutely correct. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Simulating 1 microsecond delays (assuming LPC meets that goal for 0x80) is absolutely correct for devices provided on PCI-X running on 3 GHz or greater machines? Well, you are entitled to your opinion. Seems likely that reading the timing specs of such a chipset might be correct, and delaying for a time proportional to CPU speed, rather than assuming running 3000 3GHz clock cycles is needed on a very fast emulation of an old device that probably runs at the fastest bus speed provided in the chipset. Every device has different timing constraints. In the real world that I live in. Alan Cox wrote: On Thu, 13 Dec 2007 08:13:29 -0500 David P. Reed [EMAIL PROTECTED] wrote: Perhaps what was meant is that ISA-tuned timings make little sense on devices that are part of the chipset or on the PCI or PCI-X buses? No. ISA as LPC bus is alive and well inside and outside chipsets. Welcome to planet earth and the reality of 'its cheaper to reuse cells than design a new one'. For the chipset logic like DMA controllers the _p is absolutely correct. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
> Yes, it's now clear that all of this is so. Regrettably, it's used in > dozens of drivers, most having nothing to do with an ISA/LPC bus. > > If it really is specific to the ISA architecture, then it should only be > used in architecture specific code. ISA/LPC is not architecture specific. In fact ISA/LPC bus components get everywhere because the PC market drives the cost per unit for those components down to nearly nothing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Alan Cox wrote: without need. Not surprising since it has such a vague specific meaning. One could say, Linux on i386 is liberally sprinkled with "vague specific" ? sorry don't follow you. The _p variants are a universal fixture, defined as ending with a pause, but without specifying the duration. (The duration is architecture specific, mostly zero.) It really isn't a form that should be used in generic code. I really prefer accurate code, but I'm also pragmatic and realise that it's far too much work to fix this any time soon. But if it were to be fixed, then perhaps _p would take an additional parameter, measured in cycles of delay. measured in what, against what, for which bus. inb_p/outb_p are really only meaningful for ISA/LPC bus devices. In those cases it is precisely defined. Its use for PCI devices is a bit suspect and as a general rule probably wrong. Yes, it's now clear that all of this is so. Regrettably, it's used in dozens of drivers, most having nothing to do with an ISA/LPC bus. If it really is specific to the ISA architecture, then it should only be used in architecture specific code. I think the solution is to remove it. Replace all _p calls with the non-_p variant, and add an explicit udelay. Udelay can initially be set conservatively until it's been properly calibrated, allowing it to be used during early boot. The good news is that it's only used in a few dozen drivers, so that actually might be doable. And then, who knows, maybe Microsoft might have to scratch their corporate heads, trying to find out how to compete with a suddenly much faster Linux! :-p -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
There is another reason we can't just do a dumb changeover - two actually #1: Some drivers are using inb_p/outb_p in PCI cases which are going to cause PCI posting changes. Most are probably just wrong in the first place but they need hand checking #2: We've got SMP cases that only 'work' because the odds of splitting the outb and the following port 0x80 cycle, which locks the bus, are tiny. That is we've got CPU1CPU2 main path irq path outb outb inb 0x80 inb 0x80 races in one or two spots. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, 11 Dec 2007, David P. Reed wrote: > 1) I found in a book, the Undocumented PC, that I have lying around that > the "pause" recommended for some old adapter chips on the ISA bus was 1 > usec. The book carefully points out on various models of PCs how many > short jumps are required to implement 1 usec, and suggests that for > faster machines, 1 usec loops be calibrated. That seems like a good > heuristic. > > 2) Also, Dick, you got me interested in doing more historical research > into electrical specs and circuit diagrams (which did come with the IBM > 5150). The bus in the original IBM PC had no problem with "bus capacity > being charged" as you put it. Perhaps you don't remember that the I/O > bus had the same electrical characteristics as the memory bus. Thus > there is no issue with the bus being "charged". The issue of delays > between i/o instructions was entirely a problem of whether the adapter > card could clock data into its buffers and handle the clocked in data in > time for another bus cycle. This had nothing to do with "charging" - > buses in those days happily handled edges that were much faster than 1 usec. Wrong: the bus is not a clocked bus. Read a book. There is a "clock" trace provided, but it has nothing to do with the bus or its timing. The bus is not impedance-controlled, nor is it clocked. It relies upon certain established states. Look in the back of the IBM/PC book or read about the bus in http://www.techfest.com/hardware/nis/isa.htm and observe the bus-timing with no clock involved at all. > > We at Software Arts did what we did based on direct measurements and > testing. We found that the early BIOS listings were usually fine, but > in fact were misleading. After all, the guys who built the machine and > wrote the BIOS were in a hurry. There were errata. > Yep. We are all wrong. You come out of nowhere and claim to be right. Goodbye. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 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 [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, 11 Dec 2007, David P. Reed wrote: 1) I found in a book, the Undocumented PC, that I have lying around that the pause recommended for some old adapter chips on the ISA bus was 1 usec. The book carefully points out on various models of PCs how many short jumps are required to implement 1 usec, and suggests that for faster machines, 1 usec loops be calibrated. That seems like a good heuristic. 2) Also, Dick, you got me interested in doing more historical research into electrical specs and circuit diagrams (which did come with the IBM 5150). The bus in the original IBM PC had no problem with bus capacity being charged as you put it. Perhaps you don't remember that the I/O bus had the same electrical characteristics as the memory bus. Thus there is no issue with the bus being charged. The issue of delays between i/o instructions was entirely a problem of whether the adapter card could clock data into its buffers and handle the clocked in data in time for another bus cycle. This had nothing to do with charging - buses in those days happily handled edges that were much faster than 1 usec. Wrong: the bus is not a clocked bus. Read a book. There is a clock trace provided, but it has nothing to do with the bus or its timing. The bus is not impedance-controlled, nor is it clocked. It relies upon certain established states. Look in the back of the IBM/PC book or read about the bus in http://www.techfest.com/hardware/nis/isa.htm and observe the bus-timing with no clock involved at all. We at Software Arts did what we did based on direct measurements and testing. We found that the early BIOS listings were usually fine, but in fact were misleading. After all, the guys who built the machine and wrote the BIOS were in a hurry. There were errata. Yep. We are all wrong. You come out of nowhere and claim to be right. Goodbye. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.30 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 [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
There is another reason we can't just do a dumb changeover - two actually #1: Some drivers are using inb_p/outb_p in PCI cases which are going to cause PCI posting changes. Most are probably just wrong in the first place but they need hand checking #2: We've got SMP cases that only 'work' because the odds of splitting the outb and the following port 0x80 cycle, which locks the bus, are tiny. That is we've got CPU1CPU2 main path irq path outb outb inb 0x80 inb 0x80 races in one or two spots. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Alan Cox wrote: without need. Not surprising since it has such a vague specific meaning. One could say, Linux on i386 is liberally sprinkled with vague specific ? sorry don't follow you. The _p variants are a universal fixture, defined as ending with a pause, but without specifying the duration. (The duration is architecture specific, mostly zero.) It really isn't a form that should be used in generic code. I really prefer accurate code, but I'm also pragmatic and realise that it's far too much work to fix this any time soon. But if it were to be fixed, then perhaps _p would take an additional parameter, measured in cycles of delay. measured in what, against what, for which bus. inb_p/outb_p are really only meaningful for ISA/LPC bus devices. In those cases it is precisely defined. Its use for PCI devices is a bit suspect and as a general rule probably wrong. Yes, it's now clear that all of this is so. Regrettably, it's used in dozens of drivers, most having nothing to do with an ISA/LPC bus. If it really is specific to the ISA architecture, then it should only be used in architecture specific code. I think the solution is to remove it. Replace all _p calls with the non-_p variant, and add an explicit udelay. Udelay can initially be set conservatively until it's been properly calibrated, allowing it to be used during early boot. The good news is that it's only used in a few dozen drivers, so that actually might be doable. And then, who knows, maybe Microsoft might have to scratch their corporate heads, trying to find out how to compete with a suddenly much faster Linux! :-p -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Yes, it's now clear that all of this is so. Regrettably, it's used in dozens of drivers, most having nothing to do with an ISA/LPC bus. If it really is specific to the ISA architecture, then it should only be used in architecture specific code. ISA/LPC is not architecture specific. In fact ISA/LPC bus components get everywhere because the PC market drives the cost per unit for those components down to nearly nothing. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
1) I found in a book, the Undocumented PC, that I have lying around that the "pause" recommended for some old adapter chips on the ISA bus was 1 usec. The book carefully points out on various models of PCs how many short jumps are required to implement 1 usec, and suggests that for faster machines, 1 usec loops be calibrated. That seems like a good heuristic. 2) Also, Dick, you got me interested in doing more historical research into electrical specs and circuit diagrams (which did come with the IBM 5150). The bus in the original IBM PC had no problem with "bus capacity being charged" as you put it. Perhaps you don't remember that the I/O bus had the same electrical characteristics as the memory bus. Thus there is no issue with the bus being "charged". The issue of delays between i/o instructions was entirely a problem of whether the adapter card could clock data into its buffers and handle the clocked in data in time for another bus cycle. This had nothing to do with "charging" - buses in those days happily handled edges that were much faster than 1 usec. We at Software Arts did what we did based on direct measurements and testing. We found that the early BIOS listings were usually fine, but in fact were misleading. After all, the guys who built the machine and wrote the BIOS were in a hurry. There were errata. linux-os (Dick Johnson) wrote: You do remember that the X86 can do back-to-back port instructions faster than the ISA bus capacity can be charged, don't you? You do remember the admonishment about: intel asm mov dx, port; One of two adjacent ports mov al,ffh ; All bits set out dx,al ; Output to port, bits start charging bus inc al ; Al becomes 0 inc dx ; Next port out dx,al ; Write 0 there, data bits discharged When the port at 'port' gets its data, it will likely be 0, not 0xff, because the intervening instructions can execute faster than a heavily-loaded ISA bus. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Dick - I didn't work for Don in Boca. I did know him, having met with him several times when he was still alive. I worked from 1979-1985 as a consultant and eventually VP R, at Software Arts in Cambridge, MA, and there was a machine we developed the first IBM Visicalc for, in a locked room which required NDA sign-in, with a list of authorized employees and consultants. The machine was a plywood board. It was not a 5150, yet. Note that I did not say I worked in Boca. Funny thing to twist my comments into that assertion. Note: I am not trying to say that I know everything about the history of PC-compatibles, nor am I trying to prove some kind of macho thing. But I do happen to have a lot of practical experience in this space. In particular, I am trying to contribute to Linux to make it better. Largely because I think you guys are doing a great thing, and as a user of it, I think it's a good thing to give back. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 21:27, linux-os (Dick Johnson) wrote: I didn't know you worked in Boca Raton for Don Estrage on the IBM 5150. I must have missed you --somehow. Frankly, if there ever was a good reason for _not_ merging i386 and x86-64 it would've been having an escape from these kinds of discussions... Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, 11 Dec 2007, David P. Reed wrote: > > > Alan Cox wrote: >> >> The vga driver is somewhat misnamed. In console mode we handle everything >> back to MDA/HGA and some HGA adapters do need delays. >> >> > No they don't. I really, really, really know this for a fact. I wrote > ASM drivers for every early video adapter and ran them all through Lotus > QA and Software Arts QA. Personally. The only delay needed is caused > by not having dual-ported video frame buffers on the original CGA in > high res character mode. This caused "snow" when a memory write was done > concurrently with the read being done by the scanline character > generator. And that delay was done by waiting for a bit in the I/O port > space to change. There was NO reason to do waits between I/O > instructions. Produce a spec sheet, or even better a machine. I may > have an original PC-XT still lying around in the attic, don't know if I > can fire it up, but it had such graphics cards. I also have several > early high-speed clones that were "overclocked". > >>> I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS - >>> other ports have been used in the history of the IBM PC family by some >>> vendors, and some machines have used it for DMA port mapping!! And >>> >> >> All do -thats why it is suitable. >> > Not true. Again, I can produce machines that don't use 0x80. Perhaps > that is because I am many years older than you are, and have been > writing code for PC compatibles since 1981. (not a typo - this was > before the first IBM PC was released to the public). Hmmm, I didn't know you worked in Boca Raton for Don Estrage on the IBM 5150. I must have missed you --somehow. [Snipped...] You do remember that the X86 can do back-to-back port instructions faster than the ISA bus capacity can be charged, don't you? You do remember the admonishment about: intel asm mov dx, port; One of two adjacent ports mov al,ffh ; All bits set out dx,al ; Output to port, bits start charging bus inc al ; Al becomes 0 inc dx ; Next port out dx,al ; Write 0 there, data bits discharged When the port at 'port' gets its data, it will likely be 0, not 0xff, because the intervening instructions can execute faster than a heavily-loaded ISA bus. So, with a true ISA/EISA bus, not an emulated one off a bridge, you have to worry about this. In the IBM/PC BIOS listing, supplied with every early real PC, it was called "bus settle time." Remember? If not, you never wrote code for that platform. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 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 [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
>> And if you choose to be such an insulting Fine. I won't bother submitting patches to fix this because I don't seem to care any more. The only person who is suffering seems to have an attitude problem and the only people I work for with attitude problems are customers of my employer. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 20:16, Pavel Machek wrote: Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or "to be safe" perhaps 2. http://lkml.org/lkml/2007/12/9/131 2 at least; that's how long outb(0x80) takes on one of my machines. Actually, ISA can go down to 4MHz, so maybe we should be using 4 usec but I guess I'm paranoid here. 4 isn't sensible. There have been machines capable both of running Linux and their ISA bus at less than 8 MHz (if only for example by picking a 5 divisor on a system that was capable of hosting a 40 Mhz 386/486 but using a slower CPU) but not by much. And machines doing that and running Linux, even more so "today": 0. My posted test program (although there seems to be something wrong with it since it's influenced by compiler optimisation) is showing more than 1 but note that on the vast majority of machines, 0 would in fact do. 1 will on all, 2 will as well. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 20:16, Pavel Machek wrote: Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or "to be safe" perhaps 2. http://lkml.org/lkml/2007/12/9/131 2 at least; that's how long outb(0x80) takes on one of my machines. Actually, ISA can go down to 4MHz, so maybe we should be using 4 usec but I guess I'm paranoid here. 4 isn't sensible. There have been machines capable both of running Linux and their ISA bus at less than 8 MHz (if only for example by picking a 5 divisor on a system that was capable of hosting a 40 Mhz 386/486 but using a slower CPU) but not by much. And machines doing that and running Linux, even more so "today": 0. My posted test program (although there seems to be something wrong with it since it's influenced by compiler optimisation) is showing more than 1 but note that on the vast majority of machines, 0 would in fact do. 1 will on all, 2 will as well. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 20:16, Pavel Machek wrote: Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or "to be safe" perhaps 2. http://lkml.org/lkml/2007/12/9/131 2 at least; that's how long outb(0x80) takes on one of my machines. Actually, ISA can go down to 4MHz, so maybe we should be using 4 usec but I guess I'm paranoid here. 4 isn't sensible. There have been machines capable both of running Linux and their ISA bus at less than 8 MHz (if only for example by picking a 5 divisor on a system that was capable of hosting a 40 Mhz 386/486 but using a slower CPU) but not by much. And machines doing that and running Linux, even more so "today": 0. My posted test program (although there seems to be something wrong with it since it's influenced by compiler optimisation) is showing more than 1 but note that on the vast majority of machines, 0 would in fact do. 1 will on all, 2 will as well. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 20:16, Pavel Machek wrote: Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or "to be safe" perhaps 2. http://lkml.org/lkml/2007/12/9/131 2 at least; that's how long outb(0x80) takes on one of my machines. Actually, ISA can go down to 4MHz, so maybe we should be using 4 usec but I guess I'm paranoid here. 4 isn't sensible. There have been machines capable both of running Linux and their ISA bus at less than 8 MHz (if only for example by picking a 5 divisor on a system that was capable of hosting a 40 Mhz 386/486 but using a slower CPU) but not by much. And machines doing that and running Linux, even more so "today": 0. My posted test program (although there seems to be something wrong with it since it's influenced by compiler optimisation) is showing more than 1 but note that on the vast majority of machines, 0 would in fact do. 1 will on all, 2 will as well. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Hi! > a spec sheet, or even better a machine. I may have an original PC-XT > still lying around in the attic, don't know if I can fire it up, but it had > such graphics cards. I also have several early high-speed clones that were > "overclocked". PC-XT does not count ... it needs to be 386 capable to count... Hmm.. but we have ucLinux now, so maybe PC-XT does count. >> Which requires care. Have you verified all the main chipset vendors ? >> >> > I obviously have not. Clearly the guys who want this port 80 hack so > desperately have not either. That's why we are in this pickle. Noone _wants_ this port 0x80 hack. We already have it, had it for 10+ years, and now we are trying to get rid of it -- _safely_. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Alan Cox wrote: The vga driver is somewhat misnamed. In console mode we handle everything back to MDA/HGA and some HGA adapters do need delays. No they don't. I really, really, really know this for a fact. I wrote ASM drivers for every early video adapter and ran them all through Lotus QA and Software Arts QA. Personally. The only delay needed is caused by not having dual-ported video frame buffers on the original CGA in high res character mode. This caused "snow" when a memory write was done concurrently with the read being done by the scanline character generator. And that delay was done by waiting for a bit in the I/O port space to change. There was NO reason to do waits between I/O instructions. Produce a spec sheet, or even better a machine. I may have an original PC-XT still lying around in the attic, don't know if I can fire it up, but it had such graphics cards. I also have several early high-speed clones that were "overclocked". I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS - other ports have been used in the history of the IBM PC family by some vendors, and some machines have used it for DMA port mapping!! And All do -thats why it is suitable. Not true. Again, I can produce machines that don't use 0x80. Perhaps that is because I am many years older than you are, and have been writing code for PC compatibles since 1981. (not a typo - this was before the first IBM PC was released to the public). Windows XP does NOT use it at all. Therefore it may not be supported by Older Windows does. Don't know about XP although DOS apps in XP will but they may virtualise the port. Show me one line of Windows code written by Microsoft that uses port 80. I don't know what app hackers might have done - there was no protection, and someone might have copied the BIOS for some reason. I have a simple patch that fixes my primary concern - just change the CMOS_READ and CMOS_WRITE, 64-bit versions of I/O and bootcode vga accesses (first group below) to use the straight inb and outb code. Which requires care. Have you verified all the main chipset vendors ? I obviously have not. Clearly the guys who want this port 80 hack so desperately have not either. That's why we are in this pickle. (well, we only to the extent that I am accepted as having useful input. I'm happy to go if I'm not perceived as being helpful). I may submit it so that the many others who share my pain will be made All .. none of them ? There is a long standing set of reports of "hwclock" not working on HP dv.000v laptops, where the . stands for 2, 4, 6, and 9. These are all nvidia MCP51 chipset AMD64's. And if you choose to be such an insulting , I may just stop trying to be helpful. I presume that others in the community find my comments helpful. I can do some of these off the top of my head drivers/net/8390.h Needed for some 8390 devices on ISA bus drivers/net/de600.c drivers/net/de600.h Uses the parallel port which isnt guaranteed to be full ISA speed. drivers/scsi/ppa.h Parallel port drivers/serial/8250.c Some PC's need delays for certain ops. drivers/watchdog/wdt_pci.c That one is a mistake I believe, I'll dig out the docs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue 2007-12-11 18:04:32, Rene Herman wrote: > On 11-12-07 18:00, David P. Reed wrote: > >> Which port do you want me to test? > > Oh, thought your previous reply was already responding to this. The "other > diagnostic port", 0xed. The point is not so much that it's going to be a > good alternate solution but to exclude it being a possible solution. Try replacing port 0x80 in include/asm-x86/io_*.h with 0xed... and see if it makes your machine stable. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Hi! >> Anyways it looks like the discussion here is going in a >> a loop. I had hoped David would post his test results with >> another port so that we know for sure that the bus aborts (and not port >> 80) is the problem on his box. But it looks like >> he doesn't want to do this. Still removing the bus aborts >> is probably the correct way to go forward. > > Yes, I do also still want to know that. David (Reed)? > >> Only needs a patch now. If nobody beats me to it i'll >> add one later to my tree. > > Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or "to > be safe" perhaps 2. > > http://lkml.org/lkml/2007/12/9/131 2 at least; that's how long outb(0x80) takes on one of my machines. Actually, ISA can go down to 4MHz, so maybe we should be using 4 usec but I guess I'm paranoid here. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
> below, from a list of those I needed to patch to eliminate refs to _b > calls) or arch specific code (also listed below), who might know why the > _p macros are actually needed (for any platform)? Because the controllers were historically slower than the CPU and thus clocked at half bus speed. Various chipsets simply shrank the logic without fixing this. > Note that many of the devices are not on the ISA/LPC bus now, even if > they were, and the vga has never needed a bus-level pause since the > original IBM PC existed. (it did need a sync with retrace, but that's > another story). Sync with retrace is MDA memory updates. The vga driver is somewhat misnamed. In console mode we handle everything back to MDA/HGA and some HGA adapters do need delays. > 2) Why are opterons and so forth so slow on out's to x80 as the > measurements show? That seems to me like there is a hidden bus timeout Because the LPC bus cycles are run at ISA speed. > I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS - > other ports have been used in the history of the IBM PC family by some > vendors, and some machines have used it for DMA port mapping!! And All do -thats why it is suitable. > Windows XP does NOT use it at all. Therefore it may not be supported by Older Windows does. Don't know about XP although DOS apps in XP will but they may virtualise the port. > I have a simple patch that fixes my primary concern - just change the > CMOS_READ and CMOS_WRITE, 64-bit versions of I/O and bootcode vga > accesses (first group below) to use the straight inb and outb code. Which requires care. Have you verified all the main chipset vendors ? > I may submit it so that the many others who share my pain will be made All .. none of them ? I can do some of these off the top of my head > drivers/net/8390.h Needed for some 8390 devices on ISA bus > drivers/net/de600.c > drivers/net/de600.h Uses the parallel port which isnt guaranteed to be full ISA speed. > drivers/scsi/ppa.h Parallel port > drivers/serial/8250.c Some PC's need delays for certain ops. > drivers/watchdog/wdt_pci.c That one is a mistake I believe, I'll dig out the docs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 18:04, Rene Herman wrote: On 11-12-07 18:00, David P. Reed wrote: Which port do you want me to test? Oh, thought your previous reply was already responding to this. The "other diagnostic port", 0xed. The point is not so much that it's going to be a good alternate solution but to exclude it being a possible solution. Also, I can run the timing test on my machine if you share the source code so I can build it. Thanks, would be interesting. This one: Okay, this needs to be junked. I don't get it, but I get different results from an -O2 and an -O0 compile on this one. Anyone? Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
David P. Reed wrote: I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS - other ports have been used in the history of the IBM PC family by some vendors, and some machines have used it for DMA port mapping!! Correction: ALL machines use it for DMA port mapping. The port is assigned to the legacy DMA controller, but performs no operation. That's what makes it safe to write (NOT read!) -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 18:00, David P. Reed wrote:
Which port do you want me to test?
Oh, thought your previous reply was already responding to this. The "other
diagnostic port", 0xed. The point is not so much that it's going to be a
good alternate solution but to exclude it being a possible solution.
Also, I can run the timing test on my machine if you share the source
code so I can build it.
Thanks, would be interesting. This one:
Rene.
#include
#include
#include
#define LOOPS 1000
unsigned long cycles[LOOPS];
int main(void)
{
unsigned long overhead;
unsigned long total;
int i;
if (iopl(3) < 0) {
perror("iopl");
return EXIT_FAILURE;
}
/* pull it in */
for (i = 0; i < LOOPS; i++)
cycles[i] = 0;
asm volatile ("cli");
for (i = 0; i < LOOPS; i++)
asm (
"xor%%eax, %%eax\n\t"
"cpuid \n\t"
"rdtsc \n\t"
"movl %%eax, %%esi\n\t"
"xor%%eax, %%eax\n\t"
"cpuid \n\t"
"rdtsc \n\t"
"subl %%esi, %%eax\n\t"
: "=a" (cycles[i]) : : "ecx", "edx", "ebx", "esi");
asm volatile ("sti");
overhead = 0;
for (i = 0; i < LOOPS; i++)
overhead += cycles[i];
asm volatile ("cli");
for (i = 0; i < LOOPS; i++)
asm (
"xor%%eax, %%eax\n\t"
"cpuid \n\t"
"rdtsc \n\t"
"movl %%eax, %%esi\n\t"
"outb %%al, $0x80 \n\t"
"xor%%eax, %%eax\n\t"
"cpuid \n\t"
"rdtsc \n\t"
"subl %%esi, %%eax\n\t"
: "=a" (cycles[i]) : : "ecx", "edx", "ebx", "esi");
asm volatile ("sti");
total = 0;
for (i = 0; i < LOOPS; i++)
total += cycles[i];
total -= overhead;
printf("out: %lu\n", total / LOOPS);
asm volatile ("cli");
for (i = 0; i < LOOPS; i++)
asm (
"xor%%eax, %%eax\n\t"
"cpuid \n\t"
"rdtsc \n\t"
"movl %%eax, %%esi\n\t"
"inb$0x80, %%al \n\t"
"xor%%eax, %%eax\n\t"
"cpuid \n\t"
"rdtsc \n\t"
"subl %%esi, %%eax\n\t"
: "=a" (cycles[i]) : : "ecx", "edx", "ebx", "esi");
asm volatile ("sti");
total = 0;
for (i = 0; i < LOOPS; i++)
total += cycles[i];
total -= overhead;
printf("in : %lu\n", total / LOOPS);
return EXIT_SUCCESS;
}
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Rene Herman wrote: On 11-12-07 02:25, H. Peter Anvin wrote: David Newall wrote: Where did the 8us delay come from? The documentation and source is careful not to say how long the delay is. Would changing it to, say 1us, be technically wrong? Is code that requires 8us correct? I think a single ISA bus transaction is 1 µs, so two of them back to back should be 2 µs, not 8 µs... Sigh. And now where do these _two_ transactions come from? (and yes, see Alan's folowups, a transaction on a spec bus is 1 us). Stale memory, sorry. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 17:58, David P. Reed wrote: I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS There's lots of things concerning the PC that is documented nowhere and is still true. Did you test 0xed? Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Which port do you want me to test? Also, I can run the timing test on my machine if you share the source code so I can build it. Rene Herman wrote: On 11-12-07 17:30, Andi Kleen wrote: Anyways it looks like the discussion here is going in a a loop. I had hoped David would post his test results with another port so that we know for sure that the bus aborts (and not port 80) is the problem on his box. But it looks like he doesn't want to do this. Still removing the bus aborts is probably the correct way to go forward. Yes, I do also still want to know that. David (Reed)? Only needs a patch now. If nobody beats me to it i'll add one later to my tree. Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or "to be safe" perhaps 2. http://lkml.org/lkml/2007/12/9/131 Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
As the person who started this thread, I'm still puzzled by two things: 1) is there anyone out there who wrote one of these drivers (most listed below, from a list of those I needed to patch to eliminate refs to _b calls) or arch specific code (also listed below), who might know why the _p macros are actually needed (for any platform)? Note that many of the devices are not on the ISA/LPC bus now, even if they were, and the vga has never needed a bus-level pause since the original IBM PC existed. (it did need a sync with retrace, but that's another story). 2) Why are opterons and so forth so slow on out's to x80 as the measurements show? That seems to me like there is a hidden bus timeout going on. I'm still trying to figure out what is happening on my machine which hangs when not in legacy mode (i.e. in ACPI mode) after a lot of out's to x80. Perhaps the bus timeout handling is the issue. I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS - other ports have been used in the history of the IBM PC family by some vendors, and some machines have used it for DMA port mapping!! And Windows XP does NOT use it at all. Therefore it may not be supported by vendors, and may in fact be used for other purposes, since it can if the BIOS doesn't use it. I have a simple patch that fixes my primary concern - just change the CMOS_READ and CMOS_WRITE, 64-bit versions of I/O and bootcode vga accesses (first group below) to use the straight inb and outb code. I may submit it so that the many others who share my pain will be made happy - at least on modern _64 x86 machines those instructions don't need the _p feature. The rest of the drivers and code are just lurking disasters, which I hope can be resolved somehow by the community figuring out what the timing delays were put there for... - arch/x86/boot/compressed/misc_64.c arch/x86/kernel/i8259_64.c arch/x86/pci/irq.c include/asm/floppy.h include/asm/io_64.h include/asm/mc146818rtc_64.h include/asm/vga.h include/video/vga.h drivers/video/console/vgacon.c drivers/video/vesafb.c drivers/video/vga16fb.c drivers/acpi/processor_idle.c drivers/bluetooth/bluecard_cs.c drivers/char/pc8736x_gpio.c drivers/char/rocket_int.h drivers/hwmon/abituguru.c drivers/hwmon/abituguru3.c drivers/hwmon/it87.c drivers/hwmon/lm78.c drivers/hwmon/pc87360.c drivers/hwmon/sis5595.c drivers/hwmon/smsc47b397.c drivers/hwmon/smsc47m1.c drivers/hwmon/via686a.c drivers/hwmon/vt8231.c drivers/hwmon/w83627ehf.c drivers/hwmon/w83627hf.c drivers/hwmon/w83781d.c drivers/i2c/busses/i2c-amd756.c drivers/i2c/busses/i2c-i801.c drivers/i2c/busses/i2c-nforce2.c drivers/i2c/busses/i2c-viapro.c drivers/input/misc/pcspkr.c drivers/isdn/hisax/elsa_ser.c drivers/isdn/hisax/s0box.c drivers/misc/sony-laptop.c drivers/net/8390.h drivers/net/de600.c drivers/net/de600.h drivers/net/irda/nsc-ircc.c drivers/net/irda/w83977af_ir.c drivers/net/pcmcia/axnet_cs.c drivers/net/pcmcia/pcnet_cs.c drivers/net/wireless/wl3501_cs.c drivers/scsi/megaraid.c drivers/scsi/megaraid.h drivers/scsi/ppa.h drivers/serial/8250.c drivers/video/console/vgacon.c drivers/video/vesafb.c drivers/video/vga16fb.c drivers/watchdog/pcwd_pci.c drivers/watchdog/w83627hf_wdt.c drivers/watchdog/w83697hf_wdt.c drivers/watchdog/w83877f_wdt.c drivers/watchdog/w83977f_wdt.c drivers/watchdog/wdt_pci.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 17:30, Andi Kleen wrote: Anyways it looks like the discussion here is going in a a loop. I had hoped David would post his test results with another port so that we know for sure that the bus aborts (and not port 80) is the problem on his box. But it looks like he doesn't want to do this. Still removing the bus aborts is probably the correct way to go forward. Yes, I do also still want to know that. David (Reed)? Only needs a patch now. If nobody beats me to it i'll add one later to my tree. Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or "to be safe" perhaps 2. http://lkml.org/lkml/2007/12/9/131 Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 17:32, John Stoffel wrote: Here's my results on a PIII Xeon, 550mhz, 440GX chipset, and an ISA slot, which until recently was actually used with an 8 port serial card: jfsnew:~/src> sudo ./port80 out: 729 in : 348 jfsnew:~/src> sudo ./port80 out: 729 in : 354 jfsnew:~/src> sudo ./port80 out: 729 in : 350 jfsnew:~/src> sudo ./port80 out: 728 in : 346 jfsnew:~/src> sudo ./port80 out: 730 in : 340 Thank you. That's a little odd. The "in" time should be close to the "out" time really. Well, err, I guess. For now noone's contemplating replacing the out with an in anyways :-) Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Here's my results on a PIII Xeon, 550mhz, 440GX chipset, and an ISA slot, which until recently was actually used with an 8 port serial card: jfsnew:~/src> sudo ./port80 out: 729 in : 348 jfsnew:~/src> sudo ./port80 out: 729 in : 354 jfsnew:~/src> sudo ./port80 out: 729 in : 350 jfsnew:~/src> sudo ./port80 out: 728 in : 346 jfsnew:~/src> sudo ./port80 out: 730 in : 340 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
> Most, probably most-all, of the delays to port operations > on modern ix86 machines are not needed at all. Certainly We know this. The problem is that there is no good known way to figure out which machines need it. Also it is typically slow hardware anyways -- the most time critical is probably the 8259, but nobody who cares about performance still uses it except as a fail safe fallback and for those it is better to be conservative. > machines that use bridges to expand port I/O to the ISA > bus do need any such delays. There are exactly two (and It has been observed to be required talking to some older PCI based northbridges too. > (2) I/O operations that have two ports, one an index > port and the other a data port, like the CMOS RTC. Once and PIT etc. Anyways it looks like the discussion here is going in a a loop. I had hoped David would post his test results with another port so that we know for sure that the bus aborts (and not port 80) is the problem on his box. But it looks like he doesn't want to do this. Still removing the bus aborts is probably the correct way to go forward. Only needs a patch now. If nobody beats me to it i'll add one later to my tree. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 16:37, Paul Rolland wrote: Great, thanks for the quick replies. That last one below especially is quite a bit more than 1. As said before, most hardware isn't in fact going to need anything but I suppose udelay(2) might be the "safer" replacement for the outb then... On Tue, 11 Dec 2007 16:28:56 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: On 11-12-07 15:15, Rene Herman wrote: On 11-12-07 14:32, Paul Rolland wrote: This might be a bit more constant, I suppose. This serialises with cpuid. Don't see a difference locally, but perhaps you do. Well, yes, at least on the PIII and the Opteron... Core2 is still changing a lot... On a Duron 1300 with an actual ISA bus, "out" is between 1300 and 1600 for me and "in" between 1200 and 1500 with a few flukes above that which will I suppose be caused by the bus (ISA _or_ PCI) being momentarily busy or some such... The results : Core 2Duo 1.73 GHz : [EMAIL PROTECTED] tmp]# ./in2 out: 2777 in : 2519 [EMAIL PROTECTED] tmp]# ./in2 out: 2440 in : 2391 [EMAIL PROTECTED] tmp]# ./in2 out: 2460 in : 2388 Okayish I guess, especially when subsequent runs stay near those values. 2500/1730 = 1.45 us Pentium III : [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 747 [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 747 [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 745 746/600 ~= 1.24 us AMD Opteron 150 : -bash-3.1# ./in2 out: 4846 in : 4845 -bash-3.1# ./in2 out: 4846 in : 4846 -bash-3.1# ./in2 out: 4846 in : 4845 4846 / 2400 = 2.02 us Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, 11 Dec 2007, David Newall wrote: > Rene Herman wrote: >> This particular discussion isn't about anything in general but solely >> about the delay an outb_p gives you on x86 since what is under >> discussion is not using an output to port 0x80 on that platform to >> generate it. > > That could be true if outb_p were used only in architecture dependent > code, but it's not. It's used in drivers that are supposed to run on > all sorts of platforms. Why does a megaraid controller need delays on > i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most > platforms, or just unnecessarily slow on Intel? > >>> is needed, wouldn't you use a real delay; one that says how long it >>> should be? >> Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay >> >> Because any possible outb_p delay should be synced to the bus-clock, >> not to any wall-clock. > > You misunderstand. A delay can be counted in bus cycles. > >> In the real world, driver authors aren't perfect and will have used >> outb_p as a wall-clock delay which they have gotten away with since >> it's a nicely specified delay in terms of the ISA/LPC clock and the >> ISA/LPC clock being fairly (old) to very (new) constant. > > It's most commonly a zero delay. Only in the minority of architectures > is it otherwise. If a delay is needed, then put one in, but don't put > in a paper promise that's more likely to be ignored than observed. > > Plenty of doubt has been expressed as to whether _p is widely used > without need. Not surprising since it has such a vague specific > meaning. One could say, Linux on i386 is liberally sprinkled with > needless delays. I suppose it has the advantage that Microsoft will be > hard pressed to catch up when finally we remove them. :-) > > I really prefer accurate code, but I'm also pragmatic and realise that > it's far too much work to fix this any time soon. But if it were to be > fixed, then perhaps _p would take an additional parameter, measured in > cycles of delay. > -- Most, probably most-all, of the delays to port operations on modern ix86 machines are not needed at all. Certainly machines that use bridges to expand port I/O to the ISA bus do need any such delays. There are exactly two (and only two) problems with removing the delays. (1) Older machines which have an actual ISA bus with its attendent capacity that needs to be charged long enough for the data to become valid --before being overwritten by new data. (2) I/O operations that have two ports, one an index port and the other a data port, like the CMOS RTC. Once you set the index port, it takes about 300 ns for it to propigate to the hardware, so there needs to be some delay between the back-to-back CPU operations which can occur much faster than that. On this machine, I have changed all the _p macros so they don't do anything. Since it is a modern machine with N/S bridges, which provide their own delays, everything works. Such would not be the case if I was using a machine that had an actual ISA (or PC-104) bus. Those are not terminated busses, but open-ended capacitors made up of connectors and PC traces. It takes about 300 ns to charge one of those (so 1us is a good dalay). BYW, there are no "transactions" on the ISA or EISA bus. It works by using a sequence of operations with minimum setup and hold times. It's very primative. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 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 [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Hello, On Tue, 11 Dec 2007 16:28:56 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > On 11-12-07 15:15, Rene Herman wrote: > > > On 11-12-07 14:32, Paul Rolland wrote: > > > This might be a bit more constant, I suppose. This serialises with cpuid. > Don't see a difference locally, but perhaps you do. Well, yes, at least on the PIII and the Opteron... Core2 is still changing a lot... > On a Duron 1300 with an actual ISA bus, "out" is between 1300 and 1600 for > me and "in" between 1200 and 1500 with a few flukes above that which will I > suppose be caused by the bus (ISA _or_ PCI) being momentarily busy or some > such... The results : Core 2Duo 1.73 GHz : [EMAIL PROTECTED] tmp]# ./in2 out: 2777 in : 2519 [EMAIL PROTECTED] tmp]# ./in2 out: 2440 in : 2391 [EMAIL PROTECTED] tmp]# ./in2 out: 2460 in : 2388 Pentium III : [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 747 [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 747 [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 745 AMD Opteron 150 : -bash-3.1# ./in2 out: 4846 in : 4845 -bash-3.1# ./in2 out: 4846 in : 4846 -bash-3.1# ./in2 out: 4846 in : 4845 Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 15:15, Rene Herman wrote:
On 11-12-07 14:32, Paul Rolland wrote:
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
(*) some local testing shows it to be almost exactly that for both
out and in on my own PC -- a little over. If anyone cares, see
attached little test program. The "little over" I don't worry about.
0 us delay is also fine for me and if any code was _that_ fragile it
would have broken long ago.
Some results :
Okay, these vary to wildly for you and might I suppose be a serialising
artifact or some such. Give me a bit and I'll try to improve it...
This might be a bit more constant, I suppose. This serialises with cpuid.
Don't see a difference locally, but perhaps you do.
On a Duron 1300 with an actual ISA bus, "out" is between 1300 and 1600 for
me and "in" between 1200 and 1500 with a few flukes above that which will I
suppose be caused by the bus (ISA _or_ PCI) being momentarily busy or some
such...
Rene.
#include
#include
#include
#define LOOPS 1000
unsigned long cycles[LOOPS];
int main(void)
{
unsigned long overhead;
unsigned long total;
int i;
if (iopl(3) < 0) {
perror("iopl");
return EXIT_FAILURE;
}
/* pull it in */
for (i = 0; i < LOOPS; i++)
cycles[i] = 0;
asm volatile ("cli");
for (i = 0; i < LOOPS; i++)
asm (
"xor%%eax, %%eax\n\t"
"cpuid \n\t"
"rdtsc \n\t"
"movl %%eax, %%esi\n\t"
"xor%%eax, %%eax\n\t"
"cpuid \n\t"
"rdtsc \n\t"
"subl %%esi, %%eax\n\t"
: "=a" (cycles[i]) : : "ecx", "edx", "ebx", "esi");
asm volatile ("sti");
overhead = 0;
for (i = 0; i < LOOPS; i++)
overhead += cycles[i];
asm volatile ("cli");
for (i = 0; i < LOOPS; i++)
asm (
"xor%%eax, %%eax\n\t"
"cpuid \n\t"
"rdtsc \n\t"
"movl %%eax, %%esi\n\t"
"outb %%al, $0x80 \n\t"
"xor%%eax, %%eax\n\t"
"cpuid \n\t"
"rdtsc \n\t"
"subl %%esi, %%eax\n\t"
: "=a" (cycles[i]) : : "ecx", "edx", "ebx", "esi");
asm volatile ("sti");
total = 0;
for (i = 0; i < LOOPS; i++)
total += cycles[i];
total -= overhead;
printf("out: %lu\n", total / LOOPS);
asm volatile ("cli");
for (i = 0; i < LOOPS; i++)
asm (
"xor%%eax, %%eax\n\t"
"cpuid \n\t"
"rdtsc \n\t"
"movl %%eax, %%esi\n\t"
"inb$0x80, %%al \n\t"
"xor%%eax, %%eax\n\t"
"cpuid \n\t"
"rdtsc \n\t"
"subl %%esi, %%eax\n\t"
: "=a" (cycles[i]) : : "ecx", "edx", "ebx", "esi");
asm volatile ("sti");
total = 0;
for (i = 0; i < LOOPS; i++)
total += cycles[i];
total -= overhead;
printf("in : %lu\n", total / LOOPS);
return EXIT_SUCCESS;
}
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Sat, Dec 08, 2007 at 02:25:02PM -0500, David P. Reed wrote: > In any case, my machine does not have an ISA bus. Why should it? It's > a laptop! Really? Are you sure? How does the CPU talk to the BIOS? How about the parallel port if you have one? (I will assume you have no serial ports since almost no laptop does anymore). Just because you don't see such a bus doesn't mean you don't have one. Even PCMCIA uses the ISA bus, although many new laptops are starting to have expresscard slots instead which elliminates that problem. LPC (which is ISA in a different form factor) is still around on most if not all x86 systems. -- Len Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
> That could be true if outb_p were used only in architecture dependent > code, but it's not. It's used in drivers that are supposed to run on > all sorts of platforms. Why does a megaraid controller need delays on > i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most > platforms, or just unnecessarily slow on Intel? Each platform provides its own versions of the various _p functions which work as required for that platform. As to megaraid, I don't have the docs so I couldn't specifically tell you but the use in that driver looks dubious as its not an ISA/LPC device. > It's most commonly a zero delay. Only in the minority of architectures > is it otherwise. If a delay is needed, then put one in, but don't put > in a paper promise that's more likely to be ignored than observed. Most of those platforms have hardware that was designed not to need those delays and they know that their CMOS clock etc are not clocked at half the LPC bus clock. Thus they don't need _p. > without need. Not surprising since it has such a vague specific > meaning. One could say, Linux on i386 is liberally sprinkled with "vague specific" ? sorry don't follow you. Its an ISA bus delay on systems that need it (or an LPC bus delay on newer ones). > I really prefer accurate code, but I'm also pragmatic and realise that > it's far too much work to fix this any time soon. But if it were to be > fixed, then perhaps _p would take an additional parameter, measured in > cycles of delay. measured in what, against what, for which bus. inb_p/outb_p are really only meaningful for ISA/LPC bus devices. In those cases it is precisely defined. Its use for PCI devices is a bit suspect and as a general rule probably wrong. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 14:32, Paul Rolland wrote: On 11-12-07 13:08, David Newall wrote: Rene Herman wrote: (*) some local testing shows it to be almost exactly that for both out and in on my own PC -- a little over. If anyone cares, see attached little test program. The "little over" I don't worry about. 0 us delay is also fine for me and if any code was _that_ fragile it would have broken long ago. Some results : Okay, these vary to wildly for you and might I suppose be a serialising artifact or some such. Give me a bit and I'll try to improve it... Rene -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 14:50, David Newall wrote: Rene Herman wrote: This particular discussion isn't about anything in general but solely about the delay an outb_p gives you on x86 since what is under discussion is not using an output to port 0x80 on that platform to generate it. That could be true if outb_p were used only in architecture dependent It not only could be, it _is_ true. Not using an output to port 0x80 is what this discussion is about. code, but it's not. It's used in drivers that are supposed to run on all sorts of platforms. Why does a megaraid controller need delays on i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most platforms, or just unnecessarily slow on Intel? The latter probably and I don't bleedin' well care. In a discussion about removing the out to 0x80 the only thing that is relevant is what it should be replaced with. Usually, "nothing" will do but generally, udelay(1) will. is needed, wouldn't you use a real delay; one that says how long it should be? Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay Because any possible outb_p delay should be synced to the bus-clock, not to any wall-clock. You misunderstand. A delay can be counted in bus cycles. No damnit, you misunderstand. I'm saying that an outb_p _should_ be defined in terms of the bus clock since if you want a wall-clock delay you should be using just that. The _hardware_ is synced to the bus clock and therefore, having a delay available that is synced to the bus clock as well makes some sense. And again again again again not withstanding that, a udelay will still be an okay replacement in practice. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Rene Herman wrote: This particular discussion isn't about anything in general but solely about the delay an outb_p gives you on x86 since what is under discussion is not using an output to port 0x80 on that platform to generate it. That could be true if outb_p were used only in architecture dependent code, but it's not. It's used in drivers that are supposed to run on all sorts of platforms. Why does a megaraid controller need delays on i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most platforms, or just unnecessarily slow on Intel? is needed, wouldn't you use a real delay; one that says how long it should be? Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay Because any possible outb_p delay should be synced to the bus-clock, not to any wall-clock. You misunderstand. A delay can be counted in bus cycles. In the real world, driver authors aren't perfect and will have used outb_p as a wall-clock delay which they have gotten away with since it's a nicely specified delay in terms of the ISA/LPC clock and the ISA/LPC clock being fairly (old) to very (new) constant. It's most commonly a zero delay. Only in the minority of architectures is it otherwise. If a delay is needed, then put one in, but don't put in a paper promise that's more likely to be ignored than observed. Plenty of doubt has been expressed as to whether _p is widely used without need. Not surprising since it has such a vague specific meaning. One could say, Linux on i386 is liberally sprinkled with needless delays. I suppose it has the advantage that Microsoft will be hard pressed to catch up when finally we remove them. :-) I really prefer accurate code, but I'm also pragmatic and realise that it's far too much work to fix this any time soon. But if it were to be fixed, then perhaps _p would take an additional parameter, measured in cycles of delay. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, Dec 11, 2007 at 02:47:25PM +0100, Pavel Machek wrote: > On Tue 2007-12-11 14:32:49, Andi Kleen wrote: > > > The LPC bus behaviour is absolutely and precisely defined. The timing of > > > the inb is defined in bus clocks which is perfect as the devices needing > > > delay are running at a fraction of busclock usually busclock/2. > > > > > > Older processors did not have a high precision timer so you couldn't > > > calibrate loop based delays for 1uS. > > > > For newer CPUs udelay() would be probably fine though. We seem > > to have several documented examples now where the bus aborts > > trigger hardware bugs, and it is always better to avoid such situations. > > > > I still think the best strategy would be to switch based on TSC > > availability. Perhaps move out*_p out of line to avoid code bloat. > > Why is TSC significant? udelay() based on bogomips seems to be good > enough...? Maybe I'm not sure how accurate it really is on non TSC system. On the other hand it is unclear that the port 80 IO is always the same time so it's probably ok to vary a bit. So most likely going to udelay() unconditionally is fine. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue 2007-12-11 14:32:49, Andi Kleen wrote: > > The LPC bus behaviour is absolutely and precisely defined. The timing of > > the inb is defined in bus clocks which is perfect as the devices needing > > delay are running at a fraction of busclock usually busclock/2. > > > > Older processors did not have a high precision timer so you couldn't > > calibrate loop based delays for 1uS. > > For newer CPUs udelay() would be probably fine though. We seem > to have several documented examples now where the bus aborts > trigger hardware bugs, and it is always better to avoid such situations. > > I still think the best strategy would be to switch based on TSC > availability. Perhaps move out*_p out of line to avoid code bloat. Why is TSC significant? udelay() based on bogomips seems to be good enough...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Hello, On Tue, 11 Dec 2007 14:16:01 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > On 11-12-07 13:08, David Newall wrote: > > > Rene Herman wrote: > (*) some local testing shows it to be almost exactly that for both out and > in on my own PC -- a little over. If anyone cares, see attached little test > program. The "little over" I don't worry about. 0 us delay is also fine for > me and if any code was _that_ fragile it would have broken long ago. Some results : Core 2Duo 1.73GHz : [EMAIL PROTECTED] tmp]# ./in out = 2366 in = 2496 [EMAIL PROTECTED] tmp]# ./in out = 3094 in = 2379 Plain old PIII 600 MHz: [EMAIL PROTECTED] /tmp]# ./in out = 314 in = 543 [EMAIL PROTECTED] /tmp]# ./in out = 319 in = 538 [EMAIL PROTECTED] /tmp]# ./in out = 319 in = 550 [EMAIL PROTECTED] /tmp]# ./in out = 329 in = 531 Opteron 150 2.4GHz : -bash-3.1# ./in out = 4801 in = 4863 -bash-3.1# ./in out = 5041 in = 4909 -bash-3.1# ./in out = 4829 in = 4886 Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
> The LPC bus behaviour is absolutely and precisely defined. The timing of > the inb is defined in bus clocks which is perfect as the devices needing > delay are running at a fraction of busclock usually busclock/2. > > Older processors did not have a high precision timer so you couldn't > calibrate loop based delays for 1uS. For newer CPUs udelay() would be probably fine though. We seem to have several documented examples now where the bus aborts trigger hardware bugs, and it is always better to avoid such situations. I still think the best strategy would be to switch based on TSC availability. Perhaps move out*_p out of line to avoid code bloat. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
> I really *hate* the idea that access to non-present hardware is used to > generate a delay. That sucks so badly. It's worthy of a school-aged > hacker, not of a world-leading operating system. It's so not > best-practice that it's worst-practice. Actually its very good practice. The LPC bus behaviour is absolutely and precisely defined. The timing of the inb is defined in bus clocks which is perfect as the devices needing delay are running at a fraction of busclock usually busclock/2. Older processors did not have a high precision timer so you couldn't calibrate loop based delays for 1uS. Port 0x80 is used all over the place for this, not just in Linux but in a large number of DOS programs and other PC OS's. It's even got specific hardware support in many of the chipsets so that you can make the latched last 0x80 write appear on the parallel port for debugging. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port
0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
That would be the delay on the i386 (sic) architecture. In general,
though, the delay is:
This particular discussion isn't about anything in general but solely about
the delay an outb_p gives you on x86 since what is under discussion is not
using an output to port 0x80 on that platform to generate it.
Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay
is needed, wouldn't you use a real delay; one that says how long it
should be?
Because any possible outb_p delay should be synced to the bus-clock, not to
any wall-clock. Drivers that want to sync to wall-clock need to use an outb,
delay pair as you'd expect.
In the real world, driver authors aren't perfect and will have used outb_p
as a wall-clock delay which they have gotten away with since it's a nicely
specified delay in terms of the ISA/LPC clock and the ISA/LPC clock being
fairly (old) to very (new) constant.
The delay it gives is very close to 1 us on a spec ISA/LPC bus (*) and as
such, even though it may not be the right thing to do from an theoretical
standpoint, generally a udelay(1) is going to be a fine replacement from a
practical one -- as soon as we _can_ use udelay(), as I also wrote.
Rene.
(*) some local testing shows it to be almost exactly that for both out and
in on my own PC -- a little over. If anyone cares, see attached little test
program. The "little over" I don't worry about. 0 us delay is also fine for
me and if any code was _that_ fragile it would have broken long ago.
#include
#include
#include
int main(void)
{
unsigned long cycles;
if (iopl(3) < 0) {
perror("iopl");
return EXIT_FAILURE;
}
asm ( "cli\n\t"
"rdtsc \n\t"
"movl %%eax, %%ecx\n\t"
"outb %%al, $0x80 \n\t"
"rdtsc \n\t"
"subl %%ecx, %%eax\n\t"
"sti"
: "=a" (cycles) : : "ecx", "edx");
printf("out = %lu\n", cycles);
asm ( "cli\n\t"
"rdtsc \n\t"
"movl %%eax, %%ecx\n\t"
"inb$0x80, %%al \n\t"
"rdtsc \n\t"
"subl %%ecx, %%eax\n\t"
"sti"
: "=a" (cycles) : : "ecx", "edx");
printf("in = %lu\n", cycles);
return EXIT_FAILURE;
}
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Rene Herman wrote: On 11-12-07 08:40, Paul Rolland wrote: Well, if the delay is so much unspecified, what about _reading_ port 0x80 ? Will the delay be shorter ? The delay is completely and fully specified in terms of the ISA/LPC clock That would be the delay on the i386 (sic) architecture. In general, though, the delay is: "Some devices require that accesses to their ports are slowed down. This functionality is provided by appending a _p to the end of the function." -- Documentation/DocBook/deviceiobook.tmpl (I've not seen any other formal definition.) Most architectures (Alpha, Arm, Arm2, Blackfin, FRV, h8300, IA64, PA-RISC, PowerPC, Sparc, Sparc64, V850 and Xtensa) do no pause. M68k does no pause except in one configuration, when it's the same as i386. On m32r it's a push and a pop. On SuperH it's similar to i386, only using 16-bit input. X86-64 is the same as i386! Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay is needed, wouldn't you use a real delay; one that says how long it should be? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 08:40, Paul Rolland wrote: Well, if the delay is so much unspecified, what about _reading_ port 0x80 ? Will the delay be shorter ? The delay is completely and fully specified in terms of the ISA/LPC clock which certainly for anything modern means a fixed, unchanging value (something very close to 1 us) and even on older PCs that allow some tweaking just means a delay synced to the actual bus clock which is what the _p variants should normally want to accomplish. Yes, as far as I'm aware, an inb() means the same delay but clobbers register al meaning you need a bloating save/restore sequence around it. And if so, what about reading port 0x80 and writing the value back ? inb al,0x80 outb 0x80,al See? Moreover, this also only makes sense if there's in fact something responding to reads at 0x80 and with port 0x80 being a well-known legacy PC port, a POST monitor would be just about that and writing to _that_ would seem unlikely to have any ill effects other than turning your POST board LED display into a christmas tree. The problem more likely is some piece of hardware getting upset at LPC bus aborts and your suggestion wouldn't fix that. In earlier incarnations of this thread it's been reported that various implementations of the legacy PC timer, DMA controller and PIC needed the delay but just replacing the outb with a udelay(1) would seem very likely to have the desired effect also for those. The only problem with _that_ is that you need a calibrated timing loop first which means not-very-early boot (ie, not while you try to program the timer to calibrate the loop for example). Pavel Machek already posted a patch, although with an overly pessimistic delay value. The problem here is with an x86-64 machine that very likely does not need any delay at all in fact. One thing to do would be to make _any_ delay dependent on 32-bit but given that 64-bit machines can run 32-bit kernels this doesn't fix things fully, although it probably does in practice. Keying of DMI for any delay could be possible. But if the simple udelay(1) just works, all the better. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 08:40, Paul Rolland wrote: Well, if the delay is so much unspecified, what about _reading_ port 0x80 ? Will the delay be shorter ? The delay is completely and fully specified in terms of the ISA/LPC clock which certainly for anything modern means a fixed, unchanging value (something very close to 1 us) and even on older PCs that allow some tweaking just means a delay synced to the actual bus clock which is what the _p variants should normally want to accomplish. Yes, as far as I'm aware, an inb() means the same delay but clobbers register al meaning you need a bloating save/restore sequence around it. And if so, what about reading port 0x80 and writing the value back ? inb al,0x80 outb 0x80,al See? Moreover, this also only makes sense if there's in fact something responding to reads at 0x80 and with port 0x80 being a well-known legacy PC port, a POST monitor would be just about that and writing to _that_ would seem unlikely to have any ill effects other than turning your POST board LED display into a christmas tree. The problem more likely is some piece of hardware getting upset at LPC bus aborts and your suggestion wouldn't fix that. In earlier incarnations of this thread it's been reported that various implementations of the legacy PC timer, DMA controller and PIC needed the delay but just replacing the outb with a udelay(1) would seem very likely to have the desired effect also for those. The only problem with _that_ is that you need a calibrated timing loop first which means not-very-early boot (ie, not while you try to program the timer to calibrate the loop for example). Pavel Machek already posted a patch, although with an overly pessimistic delay value. The problem here is with an x86-64 machine that very likely does not need any delay at all in fact. One thing to do would be to make _any_ delay dependent on 32-bit but given that 64-bit machines can run 32-bit kernels this doesn't fix things fully, although it probably does in practice. Keying of DMI for any delay could be possible. But if the simple udelay(1) just works, all the better. Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Rene Herman wrote: On 11-12-07 08:40, Paul Rolland wrote: Well, if the delay is so much unspecified, what about _reading_ port 0x80 ? Will the delay be shorter ? The delay is completely and fully specified in terms of the ISA/LPC clock That would be the delay on the i386 (sic) architecture. In general, though, the delay is: Some devices require that accesses to their ports are slowed down. This functionality is provided by appending a _p to the end of the function. -- Documentation/DocBook/deviceiobook.tmpl (I've not seen any other formal definition.) Most architectures (Alpha, Arm, Arm2, Blackfin, FRV, h8300, IA64, PA-RISC, PowerPC, Sparc, Sparc64, V850 and Xtensa) do no pause. M68k does no pause except in one configuration, when it's the same as i386. On m32r it's a push and a pop. On SuperH it's similar to i386, only using 16-bit input. X86-64 is the same as i386! Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay is needed, wouldn't you use a real delay; one that says how long it should be? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port
0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
That would be the delay on the i386 (sic) architecture. In general,
though, the delay is:
This particular discussion isn't about anything in general but solely about
the delay an outb_p gives you on x86 since what is under discussion is not
using an output to port 0x80 on that platform to generate it.
Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay
is needed, wouldn't you use a real delay; one that says how long it
should be?
Because any possible outb_p delay should be synced to the bus-clock, not to
any wall-clock. Drivers that want to sync to wall-clock need to use an outb,
delay pair as you'd expect.
In the real world, driver authors aren't perfect and will have used outb_p
as a wall-clock delay which they have gotten away with since it's a nicely
specified delay in terms of the ISA/LPC clock and the ISA/LPC clock being
fairly (old) to very (new) constant.
The delay it gives is very close to 1 us on a spec ISA/LPC bus (*) and as
such, even though it may not be the right thing to do from an theoretical
standpoint, generally a udelay(1) is going to be a fine replacement from a
practical one -- as soon as we _can_ use udelay(), as I also wrote.
Rene.
(*) some local testing shows it to be almost exactly that for both out and
in on my own PC -- a little over. If anyone cares, see attached little test
program. The little over I don't worry about. 0 us delay is also fine for
me and if any code was _that_ fragile it would have broken long ago.
#include stdlib.h
#include stdio.h
#include sys/io.h
int main(void)
{
unsigned long cycles;
if (iopl(3) 0) {
perror(iopl);
return EXIT_FAILURE;
}
asm ( cli\n\t
rdtsc \n\t
movl %%eax, %%ecx\n\t
outb %%al, $0x80 \n\t
rdtsc \n\t
subl %%ecx, %%eax\n\t
sti
: =a (cycles) : : ecx, edx);
printf(out = %lu\n, cycles);
asm ( cli\n\t
rdtsc \n\t
movl %%eax, %%ecx\n\t
inb$0x80, %%al \n\t
rdtsc \n\t
subl %%ecx, %%eax\n\t
sti
: =a (cycles) : : ecx, edx);
printf(in = %lu\n, cycles);
return EXIT_FAILURE;
}
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
The LPC bus behaviour is absolutely and precisely defined. The timing of the inb is defined in bus clocks which is perfect as the devices needing delay are running at a fraction of busclock usually busclock/2. Older processors did not have a high precision timer so you couldn't calibrate loop based delays for 1uS. For newer CPUs udelay() would be probably fine though. We seem to have several documented examples now where the bus aborts trigger hardware bugs, and it is always better to avoid such situations. I still think the best strategy would be to switch based on TSC availability. Perhaps move out*_p out of line to avoid code bloat. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Hello, On Tue, 11 Dec 2007 14:16:01 +0100 Rene Herman [EMAIL PROTECTED] wrote: On 11-12-07 13:08, David Newall wrote: Rene Herman wrote: (*) some local testing shows it to be almost exactly that for both out and in on my own PC -- a little over. If anyone cares, see attached little test program. The little over I don't worry about. 0 us delay is also fine for me and if any code was _that_ fragile it would have broken long ago. Some results : Core 2Duo 1.73GHz : [EMAIL PROTECTED] tmp]# ./in out = 2366 in = 2496 [EMAIL PROTECTED] tmp]# ./in out = 3094 in = 2379 Plain old PIII 600 MHz: [EMAIL PROTECTED] /tmp]# ./in out = 314 in = 543 [EMAIL PROTECTED] /tmp]# ./in out = 319 in = 538 [EMAIL PROTECTED] /tmp]# ./in out = 319 in = 550 [EMAIL PROTECTED] /tmp]# ./in out = 329 in = 531 Opteron 150 2.4GHz : -bash-3.1# ./in out = 4801 in = 4863 -bash-3.1# ./in out = 5041 in = 4909 -bash-3.1# ./in out = 4829 in = 4886 Paul -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
I really *hate* the idea that access to non-present hardware is used to generate a delay. That sucks so badly. It's worthy of a school-aged hacker, not of a world-leading operating system. It's so not best-practice that it's worst-practice. Actually its very good practice. The LPC bus behaviour is absolutely and precisely defined. The timing of the inb is defined in bus clocks which is perfect as the devices needing delay are running at a fraction of busclock usually busclock/2. Older processors did not have a high precision timer so you couldn't calibrate loop based delays for 1uS. Port 0x80 is used all over the place for this, not just in Linux but in a large number of DOS programs and other PC OS's. It's even got specific hardware support in many of the chipsets so that you can make the latched last 0x80 write appear on the parallel port for debugging. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, Dec 11, 2007 at 02:47:25PM +0100, Pavel Machek wrote: On Tue 2007-12-11 14:32:49, Andi Kleen wrote: The LPC bus behaviour is absolutely and precisely defined. The timing of the inb is defined in bus clocks which is perfect as the devices needing delay are running at a fraction of busclock usually busclock/2. Older processors did not have a high precision timer so you couldn't calibrate loop based delays for 1uS. For newer CPUs udelay() would be probably fine though. We seem to have several documented examples now where the bus aborts trigger hardware bugs, and it is always better to avoid such situations. I still think the best strategy would be to switch based on TSC availability. Perhaps move out*_p out of line to avoid code bloat. Why is TSC significant? udelay() based on bogomips seems to be good enough...? Maybe I'm not sure how accurate it really is on non TSC system. On the other hand it is unclear that the port 80 IO is always the same time so it's probably ok to vary a bit. So most likely going to udelay() unconditionally is fine. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Rene Herman wrote: This particular discussion isn't about anything in general but solely about the delay an outb_p gives you on x86 since what is under discussion is not using an output to port 0x80 on that platform to generate it. That could be true if outb_p were used only in architecture dependent code, but it's not. It's used in drivers that are supposed to run on all sorts of platforms. Why does a megaraid controller need delays on i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most platforms, or just unnecessarily slow on Intel? is needed, wouldn't you use a real delay; one that says how long it should be? Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay Because any possible outb_p delay should be synced to the bus-clock, not to any wall-clock. You misunderstand. A delay can be counted in bus cycles. In the real world, driver authors aren't perfect and will have used outb_p as a wall-clock delay which they have gotten away with since it's a nicely specified delay in terms of the ISA/LPC clock and the ISA/LPC clock being fairly (old) to very (new) constant. It's most commonly a zero delay. Only in the minority of architectures is it otherwise. If a delay is needed, then put one in, but don't put in a paper promise that's more likely to be ignored than observed. Plenty of doubt has been expressed as to whether _p is widely used without need. Not surprising since it has such a vague specific meaning. One could say, Linux on i386 is liberally sprinkled with needless delays. I suppose it has the advantage that Microsoft will be hard pressed to catch up when finally we remove them. :-) I really prefer accurate code, but I'm also pragmatic and realise that it's far too much work to fix this any time soon. But if it were to be fixed, then perhaps _p would take an additional parameter, measured in cycles of delay. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue 2007-12-11 14:32:49, Andi Kleen wrote: The LPC bus behaviour is absolutely and precisely defined. The timing of the inb is defined in bus clocks which is perfect as the devices needing delay are running at a fraction of busclock usually busclock/2. Older processors did not have a high precision timer so you couldn't calibrate loop based delays for 1uS. For newer CPUs udelay() would be probably fine though. We seem to have several documented examples now where the bus aborts trigger hardware bugs, and it is always better to avoid such situations. I still think the best strategy would be to switch based on TSC availability. Perhaps move out*_p out of line to avoid code bloat. Why is TSC significant? udelay() based on bogomips seems to be good enough...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 14:50, David Newall wrote: Rene Herman wrote: This particular discussion isn't about anything in general but solely about the delay an outb_p gives you on x86 since what is under discussion is not using an output to port 0x80 on that platform to generate it. That could be true if outb_p were used only in architecture dependent It not only could be, it _is_ true. Not using an output to port 0x80 is what this discussion is about. code, but it's not. It's used in drivers that are supposed to run on all sorts of platforms. Why does a megaraid controller need delays on i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most platforms, or just unnecessarily slow on Intel? The latter probably and I don't bleedin' well care. In a discussion about removing the out to 0x80 the only thing that is relevant is what it should be replaced with. Usually, nothing will do but generally, udelay(1) will. is needed, wouldn't you use a real delay; one that says how long it should be? Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay Because any possible outb_p delay should be synced to the bus-clock, not to any wall-clock. You misunderstand. A delay can be counted in bus cycles. No damnit, you misunderstand. I'm saying that an outb_p _should_ be defined in terms of the bus clock since if you want a wall-clock delay you should be using just that. The _hardware_ is synced to the bus clock and therefore, having a delay available that is synced to the bus clock as well makes some sense. And again again again again not withstanding that, a udelay will still be an okay replacement in practice. Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 14:32, Paul Rolland wrote: On 11-12-07 13:08, David Newall wrote: Rene Herman wrote: (*) some local testing shows it to be almost exactly that for both out and in on my own PC -- a little over. If anyone cares, see attached little test program. The little over I don't worry about. 0 us delay is also fine for me and if any code was _that_ fragile it would have broken long ago. Some results : Okay, these vary to wildly for you and might I suppose be a serialising artifact or some such. Give me a bit and I'll try to improve it... Rene -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
That could be true if outb_p were used only in architecture dependent code, but it's not. It's used in drivers that are supposed to run on all sorts of platforms. Why does a megaraid controller need delays on i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most platforms, or just unnecessarily slow on Intel? Each platform provides its own versions of the various _p functions which work as required for that platform. As to megaraid, I don't have the docs so I couldn't specifically tell you but the use in that driver looks dubious as its not an ISA/LPC device. It's most commonly a zero delay. Only in the minority of architectures is it otherwise. If a delay is needed, then put one in, but don't put in a paper promise that's more likely to be ignored than observed. Most of those platforms have hardware that was designed not to need those delays and they know that their CMOS clock etc are not clocked at half the LPC bus clock. Thus they don't need _p. without need. Not surprising since it has such a vague specific meaning. One could say, Linux on i386 is liberally sprinkled with vague specific ? sorry don't follow you. Its an ISA bus delay on systems that need it (or an LPC bus delay on newer ones). I really prefer accurate code, but I'm also pragmatic and realise that it's far too much work to fix this any time soon. But if it were to be fixed, then perhaps _p would take an additional parameter, measured in cycles of delay. measured in what, against what, for which bus. inb_p/outb_p are really only meaningful for ISA/LPC bus devices. In those cases it is precisely defined. Its use for PCI devices is a bit suspect and as a general rule probably wrong. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Sat, Dec 08, 2007 at 02:25:02PM -0500, David P. Reed wrote: In any case, my machine does not have an ISA bus. Why should it? It's a laptop! Really? Are you sure? How does the CPU talk to the BIOS? How about the parallel port if you have one? (I will assume you have no serial ports since almost no laptop does anymore). Just because you don't see such a bus doesn't mean you don't have one. Even PCMCIA uses the ISA bus, although many new laptops are starting to have expresscard slots instead which elliminates that problem. LPC (which is ISA in a different form factor) is still around on most if not all x86 systems. -- Len Sorensen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 15:15, Rene Herman wrote:
On 11-12-07 14:32, Paul Rolland wrote:
On 11-12-07 13:08, David Newall wrote:
Rene Herman wrote:
(*) some local testing shows it to be almost exactly that for both
out and in on my own PC -- a little over. If anyone cares, see
attached little test program. The little over I don't worry about.
0 us delay is also fine for me and if any code was _that_ fragile it
would have broken long ago.
Some results :
Okay, these vary to wildly for you and might I suppose be a serialising
artifact or some such. Give me a bit and I'll try to improve it...
This might be a bit more constant, I suppose. This serialises with cpuid.
Don't see a difference locally, but perhaps you do.
On a Duron 1300 with an actual ISA bus, out is between 1300 and 1600 for
me and in between 1200 and 1500 with a few flukes above that which will I
suppose be caused by the bus (ISA _or_ PCI) being momentarily busy or some
such...
Rene.
#include stdlib.h
#include stdio.h
#include sys/io.h
#define LOOPS 1000
unsigned long cycles[LOOPS];
int main(void)
{
unsigned long overhead;
unsigned long total;
int i;
if (iopl(3) 0) {
perror(iopl);
return EXIT_FAILURE;
}
/* pull it in */
for (i = 0; i LOOPS; i++)
cycles[i] = 0;
asm volatile (cli);
for (i = 0; i LOOPS; i++)
asm (
xor%%eax, %%eax\n\t
cpuid \n\t
rdtsc \n\t
movl %%eax, %%esi\n\t
xor%%eax, %%eax\n\t
cpuid \n\t
rdtsc \n\t
subl %%esi, %%eax\n\t
: =a (cycles[i]) : : ecx, edx, ebx, esi);
asm volatile (sti);
overhead = 0;
for (i = 0; i LOOPS; i++)
overhead += cycles[i];
asm volatile (cli);
for (i = 0; i LOOPS; i++)
asm (
xor%%eax, %%eax\n\t
cpuid \n\t
rdtsc \n\t
movl %%eax, %%esi\n\t
outb %%al, $0x80 \n\t
xor%%eax, %%eax\n\t
cpuid \n\t
rdtsc \n\t
subl %%esi, %%eax\n\t
: =a (cycles[i]) : : ecx, edx, ebx, esi);
asm volatile (sti);
total = 0;
for (i = 0; i LOOPS; i++)
total += cycles[i];
total -= overhead;
printf(out: %lu\n, total / LOOPS);
asm volatile (cli);
for (i = 0; i LOOPS; i++)
asm (
xor%%eax, %%eax\n\t
cpuid \n\t
rdtsc \n\t
movl %%eax, %%esi\n\t
inb$0x80, %%al \n\t
xor%%eax, %%eax\n\t
cpuid \n\t
rdtsc \n\t
subl %%esi, %%eax\n\t
: =a (cycles[i]) : : ecx, edx, ebx, esi);
asm volatile (sti);
total = 0;
for (i = 0; i LOOPS; i++)
total += cycles[i];
total -= overhead;
printf(in : %lu\n, total / LOOPS);
return EXIT_SUCCESS;
}
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Hello, On Tue, 11 Dec 2007 16:28:56 +0100 Rene Herman [EMAIL PROTECTED] wrote: On 11-12-07 15:15, Rene Herman wrote: On 11-12-07 14:32, Paul Rolland wrote: This might be a bit more constant, I suppose. This serialises with cpuid. Don't see a difference locally, but perhaps you do. Well, yes, at least on the PIII and the Opteron... Core2 is still changing a lot... On a Duron 1300 with an actual ISA bus, out is between 1300 and 1600 for me and in between 1200 and 1500 with a few flukes above that which will I suppose be caused by the bus (ISA _or_ PCI) being momentarily busy or some such... The results : Core 2Duo 1.73 GHz : [EMAIL PROTECTED] tmp]# ./in2 out: 2777 in : 2519 [EMAIL PROTECTED] tmp]# ./in2 out: 2440 in : 2391 [EMAIL PROTECTED] tmp]# ./in2 out: 2460 in : 2388 Pentium III : [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 747 [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 747 [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 745 AMD Opteron 150 : -bash-3.1# ./in2 out: 4846 in : 4845 -bash-3.1# ./in2 out: 4846 in : 4846 -bash-3.1# ./in2 out: 4846 in : 4845 Paul -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On Tue, 11 Dec 2007, David Newall wrote: Rene Herman wrote: This particular discussion isn't about anything in general but solely about the delay an outb_p gives you on x86 since what is under discussion is not using an output to port 0x80 on that platform to generate it. That could be true if outb_p were used only in architecture dependent code, but it's not. It's used in drivers that are supposed to run on all sorts of platforms. Why does a megaraid controller need delays on i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most platforms, or just unnecessarily slow on Intel? is needed, wouldn't you use a real delay; one that says how long it should be? Thinking that _p gives a pause is perhaps too PC-centric. Why, if a delay Because any possible outb_p delay should be synced to the bus-clock, not to any wall-clock. You misunderstand. A delay can be counted in bus cycles. In the real world, driver authors aren't perfect and will have used outb_p as a wall-clock delay which they have gotten away with since it's a nicely specified delay in terms of the ISA/LPC clock and the ISA/LPC clock being fairly (old) to very (new) constant. It's most commonly a zero delay. Only in the minority of architectures is it otherwise. If a delay is needed, then put one in, but don't put in a paper promise that's more likely to be ignored than observed. Plenty of doubt has been expressed as to whether _p is widely used without need. Not surprising since it has such a vague specific meaning. One could say, Linux on i386 is liberally sprinkled with needless delays. I suppose it has the advantage that Microsoft will be hard pressed to catch up when finally we remove them. :-) I really prefer accurate code, but I'm also pragmatic and realise that it's far too much work to fix this any time soon. But if it were to be fixed, then perhaps _p would take an additional parameter, measured in cycles of delay. -- Most, probably most-all, of the delays to port operations on modern ix86 machines are not needed at all. Certainly machines that use bridges to expand port I/O to the ISA bus do need any such delays. There are exactly two (and only two) problems with removing the delays. (1) Older machines which have an actual ISA bus with its attendent capacity that needs to be charged long enough for the data to become valid --before being overwritten by new data. (2) I/O operations that have two ports, one an index port and the other a data port, like the CMOS RTC. Once you set the index port, it takes about 300 ns for it to propigate to the hardware, so there needs to be some delay between the back-to-back CPU operations which can occur much faster than that. On this machine, I have changed all the _p macros so they don't do anything. Since it is a modern machine with N/S bridges, which provide their own delays, everything works. Such would not be the case if I was using a machine that had an actual ISA (or PC-104) bus. Those are not terminated busses, but open-ended capacitors made up of connectors and PC traces. It takes about 300 ns to charge one of those (so 1us is a good dalay). BYW, there are no transactions on the ISA or EISA bus. It works by using a sequence of operations with minimum setup and hold times. It's very primative. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 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 [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 16:37, Paul Rolland wrote: Great, thanks for the quick replies. That last one below especially is quite a bit more than 1. As said before, most hardware isn't in fact going to need anything but I suppose udelay(2) might be the safer replacement for the outb then... On Tue, 11 Dec 2007 16:28:56 +0100 Rene Herman [EMAIL PROTECTED] wrote: On 11-12-07 15:15, Rene Herman wrote: On 11-12-07 14:32, Paul Rolland wrote: This might be a bit more constant, I suppose. This serialises with cpuid. Don't see a difference locally, but perhaps you do. Well, yes, at least on the PIII and the Opteron... Core2 is still changing a lot... On a Duron 1300 with an actual ISA bus, out is between 1300 and 1600 for me and in between 1200 and 1500 with a few flukes above that which will I suppose be caused by the bus (ISA _or_ PCI) being momentarily busy or some such... The results : Core 2Duo 1.73 GHz : [EMAIL PROTECTED] tmp]# ./in2 out: 2777 in : 2519 [EMAIL PROTECTED] tmp]# ./in2 out: 2440 in : 2391 [EMAIL PROTECTED] tmp]# ./in2 out: 2460 in : 2388 Okayish I guess, especially when subsequent runs stay near those values. 2500/1730 = 1.45 us Pentium III : [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 747 [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 747 [EMAIL PROTECTED] /tmp]# ./in2 out: 746 in : 745 746/600 ~= 1.24 us AMD Opteron 150 : -bash-3.1# ./in2 out: 4846 in : 4845 -bash-3.1# ./in2 out: 4846 in : 4846 -bash-3.1# ./in2 out: 4846 in : 4845 4846 / 2400 = 2.02 us Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Most, probably most-all, of the delays to port operations on modern ix86 machines are not needed at all. Certainly We know this. The problem is that there is no good known way to figure out which machines need it. Also it is typically slow hardware anyways -- the most time critical is probably the 8259, but nobody who cares about performance still uses it except as a fail safe fallback and for those it is better to be conservative. machines that use bridges to expand port I/O to the ISA bus do need any such delays. There are exactly two (and It has been observed to be required talking to some older PCI based northbridges too. (2) I/O operations that have two ports, one an index port and the other a data port, like the CMOS RTC. Once and PIT etc. Anyways it looks like the discussion here is going in a a loop. I had hoped David would post his test results with another port so that we know for sure that the bus aborts (and not port 80) is the problem on his box. But it looks like he doesn't want to do this. Still removing the bus aborts is probably the correct way to go forward. Only needs a patch now. If nobody beats me to it i'll add one later to my tree. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Here's my results on a PIII Xeon, 550mhz, 440GX chipset, and an ISA slot, which until recently was actually used with an 8 port serial card: jfsnew:~/src sudo ./port80 out: 729 in : 348 jfsnew:~/src sudo ./port80 out: 729 in : 354 jfsnew:~/src sudo ./port80 out: 729 in : 350 jfsnew:~/src sudo ./port80 out: 728 in : 346 jfsnew:~/src sudo ./port80 out: 730 in : 340 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 17:32, John Stoffel wrote: Here's my results on a PIII Xeon, 550mhz, 440GX chipset, and an ISA slot, which until recently was actually used with an 8 port serial card: jfsnew:~/src sudo ./port80 out: 729 in : 348 jfsnew:~/src sudo ./port80 out: 729 in : 354 jfsnew:~/src sudo ./port80 out: 729 in : 350 jfsnew:~/src sudo ./port80 out: 728 in : 346 jfsnew:~/src sudo ./port80 out: 730 in : 340 Thank you. That's a little odd. The in time should be close to the out time really. Well, err, shrug I guess. For now noone's contemplating replacing the out with an in anyways :-) Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 17:30, Andi Kleen wrote: Anyways it looks like the discussion here is going in a a loop. I had hoped David would post his test results with another port so that we know for sure that the bus aborts (and not port 80) is the problem on his box. But it looks like he doesn't want to do this. Still removing the bus aborts is probably the correct way to go forward. Yes, I do also still want to know that. David (Reed)? Only needs a patch now. If nobody beats me to it i'll add one later to my tree. Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or to be safe perhaps 2. http://lkml.org/lkml/2007/12/9/131 Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
As the person who started this thread, I'm still puzzled by two things: 1) is there anyone out there who wrote one of these drivers (most listed below, from a list of those I needed to patch to eliminate refs to _b calls) or arch specific code (also listed below), who might know why the _p macros are actually needed (for any platform)? Note that many of the devices are not on the ISA/LPC bus now, even if they were, and the vga has never needed a bus-level pause since the original IBM PC existed. (it did need a sync with retrace, but that's another story). 2) Why are opterons and so forth so slow on out's to x80 as the measurements show? That seems to me like there is a hidden bus timeout going on. I'm still trying to figure out what is happening on my machine which hangs when not in legacy mode (i.e. in ACPI mode) after a lot of out's to x80. Perhaps the bus timeout handling is the issue. I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS - other ports have been used in the history of the IBM PC family by some vendors, and some machines have used it for DMA port mapping!! And Windows XP does NOT use it at all. Therefore it may not be supported by vendors, and may in fact be used for other purposes, since it can if the BIOS doesn't use it. I have a simple patch that fixes my primary concern - just change the CMOS_READ and CMOS_WRITE, 64-bit versions of I/O and bootcode vga accesses (first group below) to use the straight inb and outb code. I may submit it so that the many others who share my pain will be made happy - at least on modern _64 x86 machines those instructions don't need the _p feature. The rest of the drivers and code are just lurking disasters, which I hope can be resolved somehow by the community figuring out what the timing delays were put there for... - arch/x86/boot/compressed/misc_64.c arch/x86/kernel/i8259_64.c arch/x86/pci/irq.c include/asm/floppy.h include/asm/io_64.h include/asm/mc146818rtc_64.h include/asm/vga.h include/video/vga.h drivers/video/console/vgacon.c drivers/video/vesafb.c drivers/video/vga16fb.c drivers/acpi/processor_idle.c drivers/bluetooth/bluecard_cs.c drivers/char/pc8736x_gpio.c drivers/char/rocket_int.h drivers/hwmon/abituguru.c drivers/hwmon/abituguru3.c drivers/hwmon/it87.c drivers/hwmon/lm78.c drivers/hwmon/pc87360.c drivers/hwmon/sis5595.c drivers/hwmon/smsc47b397.c drivers/hwmon/smsc47m1.c drivers/hwmon/via686a.c drivers/hwmon/vt8231.c drivers/hwmon/w83627ehf.c drivers/hwmon/w83627hf.c drivers/hwmon/w83781d.c drivers/i2c/busses/i2c-amd756.c drivers/i2c/busses/i2c-i801.c drivers/i2c/busses/i2c-nforce2.c drivers/i2c/busses/i2c-viapro.c drivers/input/misc/pcspkr.c drivers/isdn/hisax/elsa_ser.c drivers/isdn/hisax/s0box.c drivers/misc/sony-laptop.c drivers/net/8390.h drivers/net/de600.c drivers/net/de600.h drivers/net/irda/nsc-ircc.c drivers/net/irda/w83977af_ir.c drivers/net/pcmcia/axnet_cs.c drivers/net/pcmcia/pcnet_cs.c drivers/net/wireless/wl3501_cs.c drivers/scsi/megaraid.c drivers/scsi/megaraid.h drivers/scsi/ppa.h drivers/serial/8250.c drivers/video/console/vgacon.c drivers/video/vesafb.c drivers/video/vga16fb.c drivers/watchdog/pcwd_pci.c drivers/watchdog/w83627hf_wdt.c drivers/watchdog/w83697hf_wdt.c drivers/watchdog/w83877f_wdt.c drivers/watchdog/w83977f_wdt.c drivers/watchdog/wdt_pci.c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Which port do you want me to test? Also, I can run the timing test on my machine if you share the source code so I can build it. Rene Herman wrote: On 11-12-07 17:30, Andi Kleen wrote: Anyways it looks like the discussion here is going in a a loop. I had hoped David would post his test results with another port so that we know for sure that the bus aborts (and not port 80) is the problem on his box. But it looks like he doesn't want to do this. Still removing the bus aborts is probably the correct way to go forward. Yes, I do also still want to know that. David (Reed)? Only needs a patch now. If nobody beats me to it i'll add one later to my tree. Pavel Machek already posted one. His udelay(8) wants to be less -- 1 or to be safe perhaps 2. http://lkml.org/lkml/2007/12/9/131 Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
Rene Herman wrote: On 11-12-07 02:25, H. Peter Anvin wrote: David Newall wrote: Where did the 8us delay come from? The documentation and source is careful not to say how long the delay is. Would changing it to, say 1us, be technically wrong? Is code that requires 8us correct? I think a single ISA bus transaction is 1 µs, so two of them back to back should be 2 µs, not 8 µs... Sigh. And now where do these _two_ transactions come from? (and yes, see Alan's folowups, a transaction on a spec bus is 1 us). Stale memory, sorry. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 11-12-07 17:58, David P. Reed wrote: I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS There's lots of things concerning the PC that is documented nowhere and is still true. Did you test 0xed? Rene. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
David P. Reed wrote: I do remind all that 0x80 is a BIOS-specific standard, and is per BIOS - other ports have been used in the history of the IBM PC family by some vendors, and some machines have used it for DMA port mapping!! Correction: ALL machines use it for DMA port mapping. The port is assigned to the legacy DMA controller, but performs no operation. That's what makes it safe to write (NOT read!) -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
