Re: Help making sense of firewire disk enclosure dilema

On Sun, 22 Aug 2004, George Hartzell wrote:

> The enclosure is smeared across the kitchen table at the moment (see
> below), so I can't give it's exact reaction to suggestion, but I have
> some representative output.
>
> In the course of mucking around, I've tried various combinations of
> 'fwcontrol -r' and 'camcontrol rescan all'.  I'm not sure which caused
> which part of the dmesg output below, but it might be interesting:
>
>   sbp0:0:0 request timeout(cmd orb:0x163ca634) ... agent reset
>   sbp0:0:0 request timeout(cmd orb:0x163ca76c) ... target reset
>   fwohci0: BUS reset
>   fwohci0: node_id=0xc800ffc0, gen=6, CYCLEMASTER mode
>   firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
>   firewire0: bus manager 0 (me)
>   sbp0:0:0 request timeout(cmd orb:0x163ca9dc) ... reset start
>   fwohci0: txd err= 3 miss Ack err
>   sbp0:0:0 sbp_reset_start failed: resp=22
>   firewire0: split transaction timeout dst=0xffc0 tl=0x30 state=4
>   sbp0:0:0 sbp_reset_start failed: resp=60

I've seen this before, if one of the nodes locks up during negotiation. My
Athlon box with APIC enabled has a tendnecy to do that when the machine it
was cabled to for debugging would reboot.

> I figured out how to ask fwcontrol to tell me more about the device
> inside the enclosure, and discovered that it's a Prolific PL-3507.  A
> little googling about suggests that it's a well known PITA device, e.g.
>
>   http://forum.rpc1.org/viewtopic.php?t=25140&postdays=0&postorder=asc&&start=0&sid=0a359d410cfd87df72f2543365922421
>
> So, I'm left to decide whether to muck with the firmware or just chuck
> it.....

I'd give up now. :)

> Are there "quirks" for firewire devices like there used to be (are?)
> for usb devices?

Not that I'm aware of, but I don't know if firewire supports device/vendor
IDs like USB that can be used to match the quirk.

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite_at_gumbysoft.com          |  www.FreeBSD.org