Date: Wed, 26 Jul 2000 13:51:45 -0500
From: Mike Perry <mikepery@fscked.org>
In my fix, I would restore the old settings if the new IRQ (or any
other setting) were invalid (line 2178). With this fix, I can change
the IRQ all day long with setserial to any available IRQ, and it
returns Device Or Resource Busy when you set it to an IRQ that's
already in use (and not shareable). The IRQ on the serial device then
remains unchanged, and afterwards, I can continue to change it all
day long to any other available IRQ.
This doesn't handle the case where an IRQ wasn't in use when it was
originally set and some other device driver gets loaded which then grabs
the IRQ. Now when you open the serial port to change the IRQ, you find
you can't open it because open() returns with an error, so you can never
call the ioctl() to fix the irq.
This can also happen when the default serial IRQ is 3 or 4 on the COM
1/2/3/4 ports, and some other device driver has grabed IRQ 3 or 4
exclusively. So merely saying that you check the IRQ number when at the
time when it is being set by setserial is not sufficient.
On top of this, like I said, I noticed sporadic cold system hangs when the
serial driver thought its IRQ was one already in use (especially when it
thought the IRQ was 0). I didn't feel like tracking this problem down, so I
fixed it that way.
This sounds confused. If the IRQ is 0, then it will never fail; it will
simply using the timing method. This isn't a case of "IRQ is already in
use". If the IRQ is in use, then the serial port is never initialized,
and the TTY_IO_ERROR flag is set. This prohibits most normal tty
operations, and only allows ioctl operations so you can set the IRQ or
port information to new values.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:22 EST