> According to <[EMAIL PROTECTED]>: > > > According to <[EMAIL PROTECTED]>: > > > > 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 :(.