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