[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: