USB lp Problems
Have a HP LaserJet 1012 USB printer that am having some problems with.
It works, but only if it is powered on when the system boots. If I turn
it off, and then turn it back on or turn it on after the system boots it
is not recognised at all.
So did some digging/searching in logs and on the net and came across a
couple of things regarding USB. Its an Intel D865PERL motherboard
running the latest BIOS (P21). On startup with the printer off, these
are the following messages (obtained via dmesg):
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 169
uhci_hcd 0000:00:1d.0: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 169, io base 0000cc00
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 177
uhci_hcd 0000:00:1d.1: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: irq 177, io base 0000d000
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 185
uhci_hcd 0000:00:1d.2: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 185, io base 0000d400
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.3[A] -> GSI 16 (level, low) -> IRQ 169
uhci_hcd 0000:00:1d.3: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: irq 169, io base 0000d800
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 193
ehci_hcd 0000:00:1d.7: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI
Controller
ehci_hcd 0000:00:1d.7: BIOS handoff failed (104, 1010001)
ehci_hcd 0000:00:1d.7: can't reset
ehci_hcd 0000:00:1d.7: init 0000:00:1d.7 fail, -95
ehci_hcd: probe of 0000:00:1d.7 failed with error -95
This last bit is of interest. From what I can tell its a BIOS bug of
sorts which appears to be fixed by either changing BIOS or changing
kernel. (Currently running sarge with a Debian 2.6.8-3-686 kernel which
is I believe the latest in sarge.) Is there any advantage in upgrading
to the etch kernel (2.6.15??) to over come this error? Is this error
related to my printer problems? (As an aside, another problem I have
with kernels is that I would love to get the smp kernel running, but it
seems to lock the system up on boot in the ACPI area I think. Not sure
if this is a BIOS issue, and if so what in the BIOS needs to be changed.)
And to top off these strange things, when running lsusb, the output is:
Unknown line at line 5942
Unknown line at line 5943
Unknown line at line 5944
Unknown line at line 5945
Unknown line at line 5946
Unknown line at line 5947
Unknown line at line 5948
Unknown line at line 5949
Unknown line at line 5950
Unknown line at line 5951
Unknown line at line 5952
Unknown line at line 5953
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
The other problem with this printer is when I turn it on while the
system is running. My understanding is that hotplug should kick in and
try and "bring up" the /dev/usb/lp0 device. I am not seeing hotplug
running at all... Is this related to the above BIOS handoff error, or
is there another issue lurking here? (Note that I am not running udev
on this system, but I don't think this should be a problem.) Turning
the printer on does not produce any messages in the dmesg output or in
kernel.log, so this one has me stumped.
Mark P.
Reply to: