USB curosity

[Kevin Cummings]

On 12/14/15 03:22, Ger van Dijck wrote:
> Op Mon, 14 Dec 2015 04:23:47 +0100 schreef Geoffrey Leach
> <geoff at 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 at verizon.net
cummings at kjchome.homeip.net
cummings at kjc386.framingham.ma.us
Registered Linux User #1232 (http://www.linuxcounter.net/)