UML - Console should handle spurious IRQS

The previous DEBUG_SHIRQ patch missed one case. The console doesn't set its host descriptors non-blocking.

--

 arch/um/drivers/chan_kern.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Index: linux-2.6.21-mm/arch/um/drivers/chan_kern.c
===================================================================
@@ -157,7 +157,7 @@ static void tty_receive_char(struct tty_
 
 static int open_one_chan(struct chan *chan)
 {
-	int fd;
+	int fd, err;
 
 	if(chan->opened)
 		return 0;

@@ -168,6 +168,13 @@ static int open_one_chan(struct chan *ch
 				     chan->data, &chan->dev);
 	if(fd < 0)
 		return fd;
+
+	err = os_set_fd_block(fd, 0);
+	if (err) {
+		(*chan->ops->close)(fd, chan->data);
+		return err;
+	}
+
 	chan->fd = fd;
 
 	chan->opened = 1;

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

*This message was transferred with a trial version of CommuniGate(r) Pro*

Sorry, things looked okay when I tested on my UML environment (Puppy Linux). Some xterms popped around (because I was using "con=xterm") and the system was usable, so it gave me no indication something was wrong.

I thought of adding an extra debugging option to warn us when a blocking
I/O operation is issued for a socket/fd, but UML-specific code is not
consistent regarding glibc functions. That is, most of the time it calls os_*(), but sometimes it calls functions like recvfrom() directly. I'll grep the source code for such calls and send a patch to clean it up a bit.

There might still be such cases, I haven't tested all channel types yet.

NP, I was just cc-ing you because you had an interest in the problem, having already fixed most of it.

Jeff

Work email - jdike at linux dot intel dot com