Does this patch (following my signature) fix the printer hangs?
(It does for me.)
BTW, it's also an attachment on OSDL bugzilla #2221:
http://bugme.osdl.org/show_bug.cgi?id=2221
-Barry K. Nathan <[email protected]>
diff -ruN linux-2.6.3-bk2/drivers/usb/class/usblp.c linux-2.6.3-bk2-bkn1/drivers/usb/class/usblp.c
--- linux-2.6.3-bk2/drivers/usb/class/usblp.c 2004-02-29 23:18:26.000000000 -0800
+++ linux-2.6.3-bk2-bkn1/drivers/usb/class/usblp.c 2004-02-29 23:17:24.000000000 -0800
@@ -603,7 +603,7 @@
{
DECLARE_WAITQUEUE(wait, current);
struct usblp *usblp = file->private_data;
- int timeout, err = 0, transfer_length;
+ int timeout, err = 0, transfer_length = 0;
size_t writecount = 0;
while (writecount < count) {
@@ -654,6 +654,16 @@
continue;
}
+ /* We must increment writecount here, and not at the
+ * end of the loop. Otherwise, the final loop iteration may
+ * be skipped, leading to incomplete printer output.
+ */
+ writecount += transfer_length;
+ if (writecount == count) {
+ up (&usblp->sem);
+ break;
+ }
+
transfer_length=(count - writecount);
if (transfer_length > USBLP_BUF_SIZE)
transfer_length = USBLP_BUF_SIZE;
@@ -677,8 +687,6 @@
break;
}
up (&usblp->sem);
-
- writecount += transfer_length;
}
return count;
On Sun, Feb 29 2004, Barry K. Nathan wrote:
> Does this patch (following my signature) fix the printer hangs?
> (It does for me.)
>
> BTW, it's also an attachment on OSDL bugzilla #2221:
> http://bugme.osdl.org/show_bug.cgi?id=2221
Works for me, thanks (applied on top of 2.6.4-rc1-mm1)
--
Jens Axboe
On Sun, 29 Feb 2004 23:43:48 -0800, Barry K. Nathan wrote:
> Does this patch (following my signature) fix the printer hangs? (It does
> for me.)
>
> BTW, it's also an attachment on OSDL bugzilla #2221:
> http://bugme.osdl.org/show_bug.cgi?id=2221
>
> -Barry K. Nathan <[email protected]>
>
> diff -ruN linux-2.6.3-bk2/drivers/usb/class/usblp.c
> linux-2.6.3-bk2-bkn1/drivers/usb/class/usblp.c ---
> linux-2.6.3-bk2/drivers/usb/class/usblp.c 2004-02-29 23:18:26.000000000
> -0800 +++ linux-2.6.3-bk2-bkn1/drivers/usb/class/usblp.c 2004-02-29
> 23:17:24.000000000 -0800 @@ -603,7 +603,7 @@
> {
> DECLARE_WAITQUEUE(wait, current);
> struct usblp *usblp = file->private_data;
> - int timeout, err = 0, transfer_length; + int timeout, err = 0,
> transfer_length = 0;
> size_t writecount = 0;
>
> while (writecount < count) {
> @@ -654,6 +654,16 @@
> continue;
> }
>
> + /* We must increment writecount here, and not at the + * end of the
> loop. Otherwise, the final loop iteration may + * be skipped, leading
> to incomplete printer output. + */
> + writecount += transfer_length;
> + if (writecount == count) {
> + up (&usblp->sem);
> + break;
> + }
> +
> transfer_length=(count - writecount); if (transfer_length >
> USBLP_BUF_SIZE)
> transfer_length = USBLP_BUF_SIZE;
> @@ -677,8 +687,6 @@
> break;
> }
> up (&usblp->sem);
> -
> - writecount += transfer_length;
> }
>
> return count;
I also applied this patch to 2.6.4-rc1-mm1 and my printer problem seems to
be solved. This is the first time in two weeks that printing has worked
properly for me. Thx :)
Barry K. Nathan wrote:
>
> + /* We must increment writecount here, and not at the
> + * end of the loop. Otherwise, the final loop iteration may
> + * be skipped, leading to incomplete printer output.
> + */
You are correct.
I'm affraid this is my fault, for correcting a bug and letting another one take
its place :(
It seems that this patch squashes them both. It should go in ASAP.
--
Paulo Marques - http://www.grupopie.com
"In a world without walls and fences who needs windows and gates?"
On Tue, 2004-03-02 at 06:09, Paulo Marques wrote:
> Barry K. Nathan wrote:
>
> >
> > + /* We must increment writecount here, and not at the
> > + * end of the loop. Otherwise, the final loop iteration may
> > + * be skipped, leading to incomplete printer output.
> > + */
>
> I'm affraid this is my fault, for correcting a bug and letting another one take
> its place :(
>
> It seems that this patch squashes them both. It should go in ASAP.
Sorry I have been unable to test the fix; Gentoo Linux 2004.0 just got
released and I just became... err... ultra-busy? But it does look like
others who experienced the exact problem I was having now have
functional USB, so I'd expect it to work for me too.
I'm now experiencing kernel problems (apparently this isn't a new thing)
related to how Linux maps a CD-ROM to a block device -- problems using
dd to verify a burnt CD, where the kernel spits back random IO error
messages as it nears the end of the burned area.
If anyone is interested, you can learn more about the problems in the
following thread (I am experiencing the exact problems of the original
poster.) The posts from Joerg Schilling are probably most helpful in
finding a kernel solution to this problem:
http://lists.debian.org/cdwrite/2003/cdwrite-200310/threads.html#00009
zisofs makes a filesystem-based verify of a CD quite a time-consuming
and inefficient process (due to seeking,) so it would be nice if a "dd"
or "readcd"-based linear CD verify worked reliably under Linux.
Regards,
Daniel
On Tue, Mar 02, 2004 at 01:09:45PM +0000, Paulo Marques wrote:
> Barry K. Nathan wrote:
>
> >
> >+ /* We must increment writecount here, and not at the
> >+ * end of the loop. Otherwise, the final loop iteration may
> >+ * be skipped, leading to incomplete printer output.
> >+ */
>
>
> You are correct.
>
>
> I'm affraid this is my fault, for correcting a bug and letting another one
> take its place :(
>
> It seems that this patch squashes them both. It should go in ASAP.
This patch is already in Linus's tree.
thanks,
greg k-h