[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070414143719.GA5203@fi.muni.cz>
Date: Sat, 14 Apr 2007 16:37:19 +0200
From: Jan Yenya Kasprzak <kas@...muni.cz>
To: Jiri Slaby <jirislaby@...il.com>
Cc: linux-kernel@...r.kernel.org, osv@...ad.com
Subject: Re: [RFC 1/1] Char: mxser_new, fix recursive locking
Jiri Slaby wrote:
: I would rather incline to the second variant as it is the original approach
: from moxa driver and I have no idea, what might happen if we drop the lock
: before calling all involved mxser_ routines.
:
: Could you both (if possible) test the attached patch and drop a message,
: please?
Works for me, altough it spits tons of (bogus, in this case)
warnings about possibly uninitialized variable "flags".
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 :-)
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.
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ |
> I will never go to meetings again because I think face to face meetings <
> are the biggest waste of time you can ever have. --Linus Torvalds <
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists