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. 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: [EMAIL PROTECTED] URL: http://www.spiegl.de Finger [EMAIL PROTECTED] for my PGP key o _ _ _ --------- __o __o /\_ _ \\o (_)\__/o (_) ------- _`\<,_ _`\<,_ _>(_) (_)/<_ \_| \ _|/' \/ ------ (_)/ (_) (_)/ (_) (_) (_) (_) (_)' _\o_ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~