Bug 17111 - parport_probe confuses HP DeskJet 340
parport_probe confuses HP DeskJet 340
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-30 14:05 EDT by Jón Fairbairn
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-31 16:20:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
You might also want to try this debugging patch to see where the handshake is going wrong. (885 bytes, patch)
2000-08-31 07:15 EDT, Tim Waugh
no flags Details | Diff

  None (edit)
Description Jón Fairbairn 2000-08-30 14:05:59 EDT
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@porky.devel.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
Comment 1 Tim Waugh 2000-08-31 07:14:43 EDT
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'.
Comment 2 Tim Waugh 2000-08-31 07:15:50 EDT
Created attachment 3118 [details]
You might also want to try this debugging patch to see where the handshake is going wrong.
Comment 3 Jón Fairbairn 2000-08-31 12:03:04 EDT
# 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.
Comment 4 Jón Fairbairn 2000-08-31 12:14:55 EDT
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)
Comment 5 Tim Waugh 2000-08-31 13:04:11 EDT
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.
Comment 6 Jón Fairbairn 2000-08-31 13:58:01 EDT
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.


Comment 7 Tim Waugh 2000-08-31 16:19:02 EDT
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.
Comment 8 Tim Waugh 2000-08-31 16:20:54 EDT
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.
Comment 9 Tim Waugh 2000-10-09 10:20:41 EDT
I'm closing this, as it looks to be a problem at the printer end.

Note You need to log in before you can comment on or make changes to this bug.