Re: Issues w/ FW hard drive in enclosure

Tony Karakashian wrote:
>>Could you disable SMP support in the kernel? And/or is there a way to
>>disable one processor in the BIOS? The problem was also reported from
>>single processor machines though.
>
>
> Sure, I'll give that a try tonight. Unfortunately, my BIOS doesn't
> support disabling the second processor, so I gotta pull one, but that's
> ok....the fan on one's been noisy and I need to tweak it anyway. :)

Also, try a uniprocessor kernel. Even on a UP machine, an SMP kernel
behaves a bit differently from a UP kernel. However I believe the
problem at hand was also seen by people with UP kernel + machine.

>>>ohci1394: fw-host0: Unexpected PCI resource length of 1000!
...
> Just out of curiosity, what is that line referencing?

It is the address space within which the host controller's registers are
mapped. The specification says it is 2048 bytes. Some chips report a
different number for whatever reason. The bogus length value should not
be a problem because the offset of each standard register from the
beginning of the address space is fixed per specification.

Maybe the card in question counts some vendor specific registers too
which are irrelevant for ohci1394. (The reported length is 0x1000, not
decimal 1000 like the log line suggests. Thus it's bigger than the
standard 0x800.)

> I've never really
> dealt with anything this low-level before. Also, if anyone has any
> suggestions, I'm not married to this card. I'm actually looking to
> upgrade it to a USB2.0/firewire card, so if anyone has any suggestions
> for one that's known to work just spiffy with a dual-proc
> system...I've done a little bit of shopping around for one, and have
> found a number based on an "Ali" chipset, are these supported?

Basically all cards work the same. There are some chips as well as some
motherboards that needed workarounds in ohci1394, and very rarely cards
which just would not work, but in general you could take any card. At
least that is what my impression is from reading here over the last
years; I have only two different cards myself, not hundreds. :-)

>>The "no tlabel match" is the first bad sign. I have 5 different SBP-2
>>devices, all work well under Linux 2.6, and a transaction label mismatch
>>is never logged here. I suspect there is an old bug hidden in Linux
>>2.6's ieee1394 packet handling.
>
> Would that also be present in the trunk drivers from the LinueIEEE1394
> site, too? I've tried using both vanilla kernel and the trunk and
> received the same error.

There was one bugfix related to erroneous tlabel mismatches, but it
obviously did not fix the typical 'aborting command' problems with sbp2.

-- 
Stefan Richter
-=====-=-=-= --== ===--
http://arcgraph.de/sr/
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
mailing list Linux1394-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-user