[Linux-parport] Ping - bug report with fix... printer hangs on parallel port

Tue Feb 26 03:21:52 EST 2008

Hi.

I did not see any parallel port maintainer in the MAINTAINERS file.

Since this is orphaned, I think you are best off if you read carefully the
Documentation/SubmittingPatches and send this directly to the release
manager (owner) of the branch you want it in. The owners can be seen in
git.kernel.org.

I have done this a few times. They are very kind nerds, so don't be afraid.

Marko

On Thu, Feb 21, 2008 at 2:45 AM, tim <tej at melbpc.org.au> wrote:

> Hi,
>
> See below for my original note from some years ago (2003!). The fix
> never got installed, so printers will still be hanging. The problem
> affects printers with slow response times back to the parallel port eg
> HP1100 and causes them to appear to hand in the middle of a page.
>
> I heard there is a new maintainer for the parallel port drivers so I
> thought I would have another go at getting this fixed.
>
> The original bug report with fix is at
> http://cyberelk.net/tim/parport/archive/current/5486.html
>
> Tim Waugh also suggested a different version of the patch - his version
> is also in the thread. I tested Tim W's version and it worked OK too.
>
> Regards,
> Tim Josling
>
> Original Note
> *************
> [PARPORT] [PATCH] to drivers/parport/ieee1284_ops.c to fix timing
> dependent printer hang
> From: Tim Josling (tej at melbpc.org.au)
> Date: Thu Mar 20 2003 - 14:32:16 EST
>
>  * Next message: Tim Josling: "[PARPORT] Re: [PATCH] to
>    drivers/parport/ieee1284_ops.c to fix timing dependent hang"
>      * Previous message: Z F: "Re: [PARPORT] [Fwd: LS-120 drive]"
>      * Next in thread: Tim Waugh: "Re: [PARPORT] [PATCH] to
>        drivers/parport/ieee1284_ops.c to fix timing dependent printer
>        hang"
>      * Reply: Tim Waugh: "Re: [PARPORT] [PATCH] to
>        drivers/parport/ieee1284_ops.c to fix timing dependent printer
>        hang"
>      * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>
> ________________________________________________________________________
>
> Hopefully I have at last foudn the right place to post this...
>
>
> I have an HP1100 printer and since I upgraded to a faster CPU the
> printer has started hanging. The problem persisteed across 2.0 2.2 and
> 2.4 kernel versions. I am running Red Hat Linux 8.0 on a Compaq Armada
> E500.
>
>
> The problem occurs intermittently. The symptom is that the 'buffer
> contains data' light stays on on the printer, but data transfer stops.
>
>
> I traced the problem to drivers/parport/ieee1284_ops.c function
> parport_ieee1284_write_compat. The problem occurs when the parallel
> port
> is not using interrupts. If the printer takes a while to respond the
> routine parport_wait_event gets called, if count == 0. However this
> routine generally waits almost no time, as shown in my traces, if the
> port does not have interrupts enabled. Looking at that code, it seems
> that parport_wait_event is only meant to be called when interrupts are
> available on the port.
>
>
> Anyway, if 32 repeats of this occur e.g. for a complex document where
> the printer is slow, 'wait' ends up as a negative number from repeated
> doublings due to the way twos complement arithmetic works in C. In this
> case the routine never returns, or at least waits for a very long time
> i.e. hours. So no more data gets sent to the printer.
>
>
> Originally I fixed the problem by adding code to ensure that 'wait'
> never got set to anything above 10 seconds (10 * HZ). However the patch
> I have sent you does something different, it just ensures that
> parport_wait_event never gets called for printer without interrupt. I
> have tested this on documents which reproduce the problem and the hangs
> go away.
>
>
> Clearly I am not an expert on the parport code, so my patch may be
> incorrect. I have traces using extra printks I put in the code, showing
> the wait variable being doubled to negative value, available on
> request.
>
>
> Definitely my patch does fix a real problem on my system.
>
>
> As far as I can tell from browsing the patches since 2.4.18, there has
> not been any other fix for this problem to date.
>
>
> Regards,
> Tim Josling
>
>
> --- ChangeLog.original 2003-03-16 09:18:07.000000000 +1100
> +++ ChangeLog 2003-03-16 09:20:35.000000000 +1100
> @@ -1,3 +1,9 @@
> +2003-03-16 Tim Josling <tej at melbpc.org.au>
> +
> + * ieee1284_ops.c (parport_ieee1284_write_compat): Avoid calling
> + parport_wait_event if interrupts are not enabled for device, avoid
> + output hang.
> +
>   2002-04-25 Tim Waugh <twaugh at redhat.com>
>
>
>       * parport_serial.c, parport_pc.c: Move some SIIG cards around.
>
>
> --- ieee1284_ops.c.original 2003-03-16 08:27:33.000000000 +1100
> +++ ieee1284_ops.c 2003-03-16 09:17:23.000000000 +1100
> @@ -93,7 +93,7 @@
>                              first time around the loop, don't let go
> of
>                              the port. This way, we find out if we
> have
>                              our interrupt handler called. */
> - if (count && no_irq) {
> + if (count || no_irq) {
>                   parport_release (dev);
>                   __set_current_state (TASK_INTERRUPTIBLE);
>                   schedule_timeout (wait);
>
>
>
> _______________________________________________
> Linux-parport mailing list
> Linux-parport at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-parport
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.infradead.org/pipermail/linux-parport/attachments/20080226/94eab1d3/attachment.html 