Bug 15788 - parport_probe hangs HP DeskJet 640C
Summary: parport_probe hangs HP DeskJet 640C
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 6.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-08-09 08:29 UTC by Jón Fairbairn
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-09 15:52:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jón Fairbairn 2000-08-09 08:29:48 UTC
When lp loads for the first time it runs parport_probe, which reports the
correct info to the log. The printer then goes into a sulk; print jobs are
accepted but disappear from the queue without getting printed.

Power-cycling the printer after the probe corrects the situation;
subsequent print jobs work fine (though I suspect that if I were to wait
long enough for the modules to get cleaned it might happen again).

The following make no difference:
BIOS settings: I tried normal, EPP and ECP.
parport_pc module options: tried explicitly setting ioport and irq
polling/interrupt driven are the same.

Recompiling the kernel with parport probing turned off solves the problem,
but if there's a lighter-weight way of turning off probing I couldn't find
it in the docs.

(using Kernel 2.2.16-3)

Comment 1 Michael K. Johnson 2000-08-09 15:12:14 UTC
Tim, any ideas?

Comment 2 Tim Waugh 2000-08-09 15:27:37 UTC
Put 'alias parport_probe off' in /etc/conf.modules.

I don't know why that particular printer gets upset with the probe though.  Is
there any other peripheral in between it and the computer?  Is the cable
exceptionally long?

Comment 3 Jón Fairbairn 2000-08-09 15:52:15 UTC
Thanks 'alias parport_probe off' does the trick and means I can use the rpm
kernel.  Presumably that's documented in general stuff about modules, rather
than being parport[_probe] specific?

The printer is the only peripheral attached to the port, and it's a bog standard
length cable. Are there any tests you would like me to run?  I'll have the
machine for a while yet.

Comment 4 Tim Waugh 2000-08-29 15:02:11 UTC
If you have tunelp around, you could try messing with the -C option, which puts
the kernel into or out of 'careful' mode.

I'll close this issue for now, since the issue was with parport_probe
unconditionally loading.  If you can't get tunelp to fix things for when
parport_probe _does_ load, that probably should be a separate bugzilla bug I
think.

Comment 5 Jón Fairbairn 2000-08-30 17:40:46 UTC
OK, but it'll have a very similar name...


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