Re: 2.6.35-rc6 to 2.6.32.16: JuJu firewire issues

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Martin Mokrejs wrote at LKML:
> Hi Jay,
>   I removed the old firewire modules from kernel .config and recompiled&reinstalled
> the kernel file and modules on compiuter A, and disabled the firewire_sbp2 on host B.
>   I have power problems with the drive when on firewire, though. It seems the desktop
> PC (ASUS P5K WS 1.0004) is not able to feed the WD 1.0TB 2.5 5200rpm" drive.

Although it should, unless if the ASUS motherboard is miswired.  A
standards compliant bus power provider must be able to supply at least
1.5 A.  Most PCs wire their FireWir ports up to 12 Volts, which gives
you at least 18 Watts.  You can driver several of these WD drives off that.

> I tried
> the firewire ports on the front of the box as well those from the motherboard.

Front panel connectors may be unreliable.  Often the connections from
mortherboard to front panel are cheap and outside the IEEE 1394
electrical specification.

> Even,
> plugged in the USB power "jack", no luck. If I use the USB port + USB power it works
> fine. I just unplugged the device after not being able to even run "fdisk /dev/sdh".
>   At the moment I have screwed superblock on the filesystem and will have to re-start
> from scratch. The attached dmesg talks about "Device offlined - not ready after error
> recovery" but I hope this is a temporary issue, and I just disconnected the device
> at the very end.
>   BTW, some driver is not ACPI compliant according to dmesg.
> 
>   The chip in the external IcyBox IB-250StUE-B is JMicron JMB 353 doing the USB+FireWire+SATA
> work for the 2.5" WD drive.
> Martin

Oh, I haven't heard of that chip before.  So far I was only aware of
PCIe--FireWire chips from JMicron.  PCIe--FireWire chips are of course
entirely different beasts than SATA--FireWire chips, but those other
FireWire offerings from JMicron do not inspire confidence.

Your dmesg shows multiple bus resets and one of the three nodes
disappearing from the bus from time to time.  This points to a probelm
at the physical layer (i.e. highly unreliable hardware) which
fundamentally cannot be solved by software.
-- 
Stefan Richter
-=====-==-=- -=== =-===
http://arcgraph.de/sr/