Re: [RFC 1/1] Char: mxser_new, fix recursive locking

From: Jiri Slaby
Date: Sat Apr 14 2007 - 12:52:23 EST


On 4/14/07, Jan Yenya Kasprzak <kas@xxxxxxxxxx> wrote:
Works for me, altough it spits tons of (bogus, in this case)
warnings about possibly uninitialized variable "flags".

This is a gcc problem. I has been thinking about flags = 0
initialization, but developers dislike this shutting gcc up.

Additionally, I think it is overzealous to wrap _all_
spin_lock_irqsave/irqrestore() with if (!in_interrupt()). Some of them are
never called from the interrupt context (mxser_block_till_ready(), for example
- it can block, so if it is ever called from the interrupt context, we have
a different, an order of magnitude worse problem here :-)

Yes, I had a patch, which changed only some of locks, but there were
only 2 or 3 spin_locks remaining. It's not a problem to test it
everywhere for little overhead, but maybe yes, I'll remove it from
open, close and block_til_whatever for the final patch.

I have another problem with the driver - it probably sometimes
drops DCD signal on the serial line or something like that:
when the traffic on the serial console is heavy, it sometimes disconnects
me from the remote shell, and cu(1) displays the login prompt from the new
instance of mgetty of the remote machine. However, it does so both with
mxser.o and mxser_new.o (in 2.6.21-rc6, I think it worked in 2.6.19,
but I have to retest it). So this is another problem, different from
the one we are trying to solve now.

There were some changes, however nothing significant in mxser.c, maybe
some of tty or ldisc layer changes (but there is only termios ->
ktermios switch + some other things), this would probably be hard to
find without bisecting if 2.6.19 is really OK for you.

The only idea I have right now is to nohup process, which will
int fd = open("/dev/ttyMIXX", O_RDONLY | O_NONBLOCK);
while (1) {
ioctl(fd, TIOCMIWAIT, TIOCM_CD);
ioctl(fd, TIOCMGET, &ret);
printf("%ld: carrier has changed: %u\n", time(NULL), !!(ret & TIOCM_CD));
}
to prove, if the carrier really becomes low.

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/