[uml-devel] [PATCH] UML - Console should handle spurious IRQS

[uml-devel] [PATCH] UML - Console should handle spurious IRQS

[Jeff Dike]

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

Signed-off-by: Jeff Dike <jdike@linux.intel.com>
--
 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
===================================================================
--- linux-2.6.21-mm.orig/arch/um/drivers/chan_kern.c	2007-07-27 10:52:02.000000000 -0400
+++ linux-2.6.21-mm/arch/um/drivers/chan_kern.c	2007-07-27 11:09:12.000000000 -0400
@@ -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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[PATCH] UML - Console should handle spurious IRQS

[Jeff Dike]

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

Signed-off-by: Jeff Dike <jdike@linux.intel.com>
--
 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
===================================================================
--- linux-2.6.21-mm.orig/arch/um/drivers/chan_kern.c	2007-07-27 10:52:02.000000000 -0400
+++ linux-2.6.21-mm/arch/um/drivers/chan_kern.c	2007-07-27 11:09:12.000000000 -0400
@@ -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;

Re: [PATCH] UML - Console should handle spurious IRQS

[Eduard-Gabriel Munteanu]

*This message was transferred with a trial version of CommuniGate(r) Pro*
Jeff Dike wrote:
> The previous DEBUG_SHIRQ patch missed one case.  The console doesn't
> set its host descriptors non-blocking.

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.

Re: [PATCH] UML - Console should handle spurious IRQS

[Jeff Dike]

On Sun, Jul 29, 2007 at 03:50:59AM +0300, Eduard-Gabriel Munteanu wrote:
> Jeff Dike wrote:
> >The previous DEBUG_SHIRQ patch missed one case.  The console doesn't
> >set its host descriptors non-blocking.
> 
> 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.

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