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.
My log says:
...
Sep 13 09:30:29 rakefet kernel: Failed initialization of WD-7000 SCSI card!
Sep 13 09:30:29 rakefet kernel: ppa: Version 1.42
Sep 13 09:30:29 rakefet kernel: ppa: Probing port 03bc
Sep 13 09:30:29 rakefet kernel: ppa: Probing port 0378
Sep 13 09:30:29 rakefet kernel: ppa: SPP port present
Sep 13 09:30:29 rakefet kernel: ppa: PS/2 bidirectional port present
Sep 13 09:30:29 rakefet kernel: ppa: Probing port 0278
Sep 13 09:30:29 rakefet kernel: scsi : 0 hosts.
...
And I don't recall the same stuff on my previous (2.0.29) kernel. Or am I
wrong ?
Also, I believe that SPP, EPP and friends are the names of the parallel port
advanced extensions. And if there is an SPP detection then I think it is
reasonable to expect that other extensions might be detected and handled as
well. However, it is all based on the above lines. I didn't read it anywhere
and, coming to think about it, I might be completely wrong. Am I ?
>
> 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?
My understanding + knowledge is much less then yours :(.
Reply to: