Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: Can we kill f inb_p, outb_p and other random I/O on port 0x80, in 2.6? | From | (Eric W. Biederman) | Date | 22 Sep 2003 12:58:04 -0600 |
| |
Arjan van de Ven <arjanv@redhat.com> writes:
> On Mon, 2003-09-22 at 18:33, Alan Cox wrote: > \ > > > I've also seen much DOS code that didn't have extra delays for > > > keyboard I/Os. What sort of breakage did you observe with the > > > keyboard? > > > > DEC laptops hang is the well known example of that one. > > > > I'm *for* making this change to udelay, it just has to start up with a > > suitably pessimal udelay assumption until calibrated. > > or we make udelay() do the port 80 access in the uncalibrated case.... > > The first person to complain about the extra branch miss in udelay for > this will get laughed at by me ;)
Sounds like a solution. I will see what I can do in that direction. Maintaining a suitably pessimistic udelay with multi gigahertz chips sounds like a challenge, so using outb to port 0x80 may be a reasonable solution there.
Alan, can you describe a little more what the original delay is needed for? I don't see it documented in my 8254 data sheet. The better I can understand the problem the better I can write the comments on this magic bit of code as I fix it.
The oldest machine I have is a 386 MCA system. Any chance of the bug showing up there? I'd love to have a test case.
Another reason for fixing this is we are killing who knows how much I/O bandwidth with this stream of failing writes to port 0x80.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |