If I permit lp to load parport_probe, the printer hangs as in bug 15788. Investigation using tunelp gives the following: with -C off, print jobs are lost with -C on, they accumulate in the queue and don't print With no parport modules loaded and parport_probe disabled, # tunelp /dev/lp0 -s causes the relevant modules (excluding parport_probe) to be loaded: Aug 30 18:36:52 cryptogramme kernel: parport0: PC-style at 0x378, irq 7 [SPP,PS2,EPP] Aug 30 18:36:52 cryptogramme kernel: lp0: using parport0 (interrupt-driven). and reports: /dev/lp0 status is 216, on-line lpr works fine. If I change /etc/conf/modules and unload the parport modules, then # tunelp /dev/lp0 -s causes parport_probe to be loaded with the other modules: Aug 30 18:39:44 cryptogramme kernel: parport0: PC-style at 0x378, irq 7 [SPP,PS2,EPP] Aug 30 18:39:46 cryptogramme kernel: parport0: Printer, HEWLETT-PACKARD DESKJET 640C Aug 30 18:39:46 cryptogramme kernel: lp0: using parport0 (interrupt-driven). and reports /dev/lp0 status is 248, out of paper, on-line which is false (the printer has plenty of paper, and it's tell-tale light says so). Now printing fails as described above, but power-cycling the printer makes it work (unless parport_probe gets loaded again). # cat /proc/version Linux version 2.2.16-3 (root.redhat.com) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Jun 19 18:10:14 EDT 2000 # rpm -qf $(which tunelp) util-linux-2.10f-7
You could try using a program called deviceid, which does basically the same thing as parport_probe but with different source code. If deviceid works but parport_probe doesn't, the bug is with parport_probe; otherwise it's probably with the printer itself. <URL:ftp://people.redhat.com/twaugh/parport/deviceid-0.2.tar.gz> You'll need to run it as root like 'deviceid --base 0x378'.
Created attachment 3118 [details] You might also want to try this debugging patch to see where the handshake is going wrong.
# deviceid --base 0x378 Advertised length: -118; actual length: 138 MFG:HEWLETT-PACKARD;MDL:DESKJET 640C;CMD:MLC,PCL,PML;CLASS:PRINTER;DESCRIPTION:Hewlett-Packard DeskJet 640C;VSTATUS:$CB0$RC0,ff,DN,IDLE; (the thing about the advertised length seems suggestive) and output sent to the printer disappears (and) # tunelp /dev/lp0 -s /dev/lp0 status is 248, out of paper, on-line A second call does the following: # deviceid --base 0x378 status was 0xf8 Couldn't go to nibble mode Which might be another clue.
Using the patched version of parport_probe, I get the following log messages when it loads: Aug 31 17:13:00 cryptogramme kernel: parport0: PC-style at 0x378, irq 7 [SPP,PS2,EPP] Aug 31 17:13:02 cryptogramme kernel: Status before termination is 0xf8 Aug 31 17:13:02 cryptogramme kernel: Timeout at 23 Aug 31 17:13:02 cryptogramme kernel: parport0: Printer, HEWLETT-PACKARD DESKJET 640C Aug 31 17:13:02 cryptogramme kernel: lp0: using parport0 (interrupt-driven). (there's that 0xf8 status again)
The -118 thing is a red herring (a bug in deviceid, which should be fixed by 0.3). The 'Timeout at 23' thing is basically saying that the printer is doing the wrong thing. If I were you I'd tell HP that their printer is not correctly responding to IEEE 1284 event 22. Looks like yet another non-compliant printer.
Groan. If I were me, at this point I'd give up and ignore probing, or hope that you might come up with a write-around :-) I haven't enough knowledge of the problem to send a convincing report to HP, and for that matter, unlike RedHat, HP don't make it easy to send fault reports, so I'm not at all sure what I'd say or to whom I would say it.
The only work-around that I can think of is brute force. Try 'rmmod lp; insmod lp reset=1' and see if you can print after that.
Incidentally, just to be extra sure, you might want to try a 2.4 kernel (if you're brave enough) to see if that has the same behaviour. In 2.4 parport_probe is linked in with parport. I guess it needs a command line parameter to disable the IEEE probe. I'll make a note.
I'm closing this, as it looks to be a problem at the printer end.