lkml.org 
[lkml]   [2004]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[BUG] usblp_write spins forever after an error
I recently cancelled a print job with the printer's cancel function, and the 
CUPS backend got stuck in usblp_write (using 100% CPU and not responding to
signals).

The printer is a Kyocera Mita FS-1900 (which has some other problems with the
linux USB code: usblp_check_status often times out, even though the printer is
bidirectional -- but that's a whole different issue).

It looks like the problem is that the write failed, so wcomplete got set
to 1 and the status is nonzero. This case appears to be mishandled in usblp.c:

while (writecount < count) {
if (!usblp->wcomplete) {
[... not reaching this code]
}

down (&usblp->sem);
if (!usblp->present) {
up (&usblp->sem);
return -ENODEV;
}
if (usblp->writeurb->status != 0) {

[ check status? ]

schedule ();
continue; <-- problem
}

After the write fails, the current code keeps checking the same status, and
never checks for signals or fails. I'm not sure what the right fix is, but it
might be something like this:

--- ./usblp.c.orig 2004-02-15 06:27:29.176169752 -0800
+++ ./usblp.c 2004-02-15 06:29:40.137260640 -0800
@@ -645,13 +645,11 @@
err = usblp->writeurb->status;
} else
err = usblp_check_status(usblp, err);
- up (&usblp->sem);

- /* if the fault was due to disconnect, let khubd's
- * call to usblp_disconnect() grab usblp->sem ...
- */
- schedule ();
- continue;
+ writecount += usblp->writeurb->transfer_buffer_length;
+ up (&usblp->sem);
+ count = writecount ? writecount : err;
+ break;
}

writecount += usblp->writeurb->transfer_buffer_length;

--Andy

Please CC me -- I'm not subscribed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:00    [W:0.089 / U:0.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site