On 12/14/15 03:22, Ger van Dijck wrote: > Op Mon, 14 Dec 2015 04:23:47 +0100 schreef Geoffrey Leach > <geoff@xxxxxxxxxx>: > >> 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@xxxxxxxxxxx cummings@xxxxxxxxxxxxxxxxxx cummings@xxxxxxxxxxxxxxxxxxxxxxx Registered Linux User #1232 (http://www.linuxcounter.net/) -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
