Thus spake Theodore Y. Ts'o (tytso@MIT.EDU):
> 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.
Alright, well hows this: The info struct won't have a pgrp or
session set until after an open has completed (they are set right at the end
of rs_open, and info is memset to zero by get_async_struct).
So on line 1316, if you do:
1316c1316
< if (retval) {
---
> if (retval && !info->session) {
1324a1325,1326
> else if (retval)
> goto errout;
That should fix the problem of not being able to open the device, right?
It still won't handle your second point, but I'm thinking maybe the user
should recieve some notification right away when they try to set the device to
an in use IRQ, rather than when try to use the port.
Sorry for all the trouble about this small point, but it just irked me if
setserial allows me to set serial port is on IRQ 1 or whatever with no error
messages until I try to use the port. Oh well, I see the wisdom in your method
now. Whatever you want to do is fine.
> 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.
Alright, it looks like I'm just going to have to chalk this one up to me being
an idiot again. I can reproduce what I'm talking about only with my driver
now, so I'm guessing all along it must have been something I introduced with
the auto_irq flag. The way it happens (with my driver) is to
setserial /dev/ttyS0 irq 0
setserial /dev/ttyS0 autoconfig auto_irq
Oh well, 2 out of 4 ain't bad. ;)
--
Mike Perry
http://got.fscked.org?
-
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