Re: Can we kill f inb_p, outb_p and other random I/O on port 0x80, in 2.6?

[ebiederm@xmission.com (Eric W. Biederman)]

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