On 12/14/15 03:22, Ger van Dijck wrote:
Op Mon, 14 Dec 2015 04:23:47 +0100 schreef Geoffrey Leach
<geoff(a)hughes.net>:
> I have a LaserJet 1300 printer that connects via a Belkin parallel
> port-to-USB connector. When I send a document to the printer, half the
> time it prints without hesitation; other times it stalls until I
> disconnect and re-connect the USB cable. When I do that, here's what
> dmesg reports:
>
> [80924.737154] usb 4-1.1: USB disconnect, device number 4
> [80924.737587] usblp0: removed
> [80926.381095] usb 4-1.1: new full-speed USB device number 5 using
> ehci-pci
> [80926.472738] usb 4-1.1: New USB device found, idVendor=050d,
> idProduct=0002
> [80926.472749] usb 4-1.1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [80926.472755] usb 4-1.1: Product: IEEE-1284 Controller
> [80926.472759] usb 4-1.1: Manufacturer: Belk USB Printing Support
> [80926.497804] usblp 4-1.1:1.0: usblp0: USB Bidirectional printer dev
> 5 if 0 alt 1 proto 2 vid 0x050D pid 0x0002
>
> CUPS discovers the printer without any problems. However, when I send
> the test document from CUPS, no amount of fiddling with the USB cable
> will cause it to print.
>
> Any insights will be greatly appreciated.
>
> Firefox 23; kernel 4.2.6-301.fc23.x86_64 #1 SMP, everything up to date.
I once did have the same problem with a HP4620 Officejet : You won't
believe it : After some weeks of investigation and discus with HP the
USB cable was to long ! Instead of 1,5 meter 2,5 meter.
Cables can be a problem. Once upon a time I worked for a major
super-minicomputer manufacturer here in New England. We were adding
X-Terminals to our office equipment. They all ran on ethernet that was
then called "thick-net". Most ran well, but, a select few had cabling
problems. Most of the failures could be fixed by adding or removing 1
meter segments of the ethernet cabling. Drove us nuts. We finally got
the thicknet repeater manufacturer together with the X-terminal
manufacturer together. Each blamed the other. Turns out both were at
fault. While the specification allows a 10% signal variance, both
implemented a +/- 5% from their own signal variance. The result was
that one manufacturer was -6% off the base frequency and the other was
+6% off. That resulted in a 12% variance, which sometimes changed
depending on how many cables were used between the devices. What a pain
in the butt! We were able to convince both of them to change their
implementations so that their equipment would inter-operate, regardless
of how many drop cables were used.
Maybe this can help , although it seems rediculous.
Ridiculous or not, its a reality in the hardware world.
--
Kevin J. Cummings
kjchome(a)verizon.net
cummings(a)kjchome.homeip.net
cummings(a)kjc386.framingham.ma.us
Registered Linux User #1232 (
http://www.linuxcounter.net/)