Re: printing takes hours in HAMM
According to <beitamos@inter.net.il>:
> > According to <beitamos@inter.net.il>:
> > > After upgrading to Hamm, (actually, after upgrading to 2.0.34) I noticed
> > > that the advanced extensions to the parallel port (SPP and such) can be
> > > recognized. Perhaps these extensions are the source of your problem ?
> >
> > Ah, that sounds like a very good idea! I will experiment with the
> > lp settings in the BIOS tonight and see whether that makes a difference.
> > How did you find out about that difference?
>
> How did I find out about that difference?
> Some time ago, while I was still running bo, I experimented with my BIOS
> settings and noticed that the printer behavior is different when the BIOS
> enables the parallel port extensions. The only thing I remember is that either
> the printer didn't work at all, or that it was very slow or that it began the
> printing and then stoped. It didn't took me much time to reset the BIOS to the
> simple parallel port definition.
Oops, sorry, I meant to ask:
How did you find out that 2.0.34 knows about the advanced extensions of the
parallel port? I didn't see anything in the changelog.
Well, I solved my problem in the meantime. I rebooted with my old 2.0.34
kernel and found that everything works alright. Then I looked at the
source diffs of patch 2.0.35 and saw that there are the following
changes in the file drivers/char/lp.c:
diff -u --recursive --new-file v2.0.34/linux/drivers/char/lp.c linux/drivers/char/lp.c
@@ -89,7 +89,14 @@
while(wait != LP_WAIT(minor)) wait++;
/* control port takes strobe high */
outb_p(( LP_PSELECP | LP_PINITP | LP_PSTROBE ), ( LP_C( minor )));
- while(wait) wait--;
+ /* Wait until NBUSY line goes high */
+ count = 0;
+ do {
+ status = LP_S(minor);
+ count++;
+ if (need_resched)
+ schedule();
+ } while (LP_READY(minor, status) && (count<LP_CHAR(minor)));
/* take strobe low */
outb_p(( LP_PSELECP | LP_PINITP ), ( LP_C( minor )));
/* update waittime statistics */
I undid the patch, recompiled the module lp.o and voila! it works again.
This is not a satisfying solution, but I don't understand enough about
kernel programming to find the bug(?) myself.
Maybe this NBUSY line rarely goes high?
Anybody have an idea what to do?
Bye,
Andy.
--
Andy Spiegl, University of Technology, Muenchen, Germany
E-Mail: Andy@spiegl.de URL: http://www.spiegl.de
Finger pgp.andy@spiegl.de for my PGP key
o _ _ _
--------- __o __o /\_ _ \\o (_)\__/o (_)
------- _`\<,_ _`\<,_ _>(_) (_)/<_ \_| \ _|/' \/
------ (_)/ (_) (_)/ (_) (_) (_) (_) (_)' _\o_
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reply to: