Re: Firewire Woes.

Florian Idelberger wrote:
> AFAIK this failure was discussed here for number of times, I myself are
> searching a resolution atm. So far I know of no working one.

Kyle's system seem to fail earlier than yours.

> On Apr 3, 2005 9:20 AM, Kyle Schmitt <azephrahel@yahoo.com> wrote:
>
>>I'm trying to access my firewire hard drive in linux
>>and I'm not sure what stage its failing at.
>>
>>I have scsi support built in, and the ieee1394 drivers
>>as modules, but no matter what I can't get the system
>>to see the hard drive.
>>
>>Basic info:
>>uname -a
>>Linux zombie 2.6.11.5-gcc4 #4 SMP
>>lspci|grep 1394
>>02:06.0 FireWire (IEEE 1394): Lucent Microelectronics
>>FW323 (rev 61)
>>
>>I'm on a box with internal scsi hard drives, so scsi
>>is built into the kernel. Whether the ieee1394 drivers
>>are built into the kernel or built as modules, no host
>>device shows up for them in /dev/scsi/ or /proc/scsi/
>>Is that normal?

The sbp2 host(s) and devices show only up in dev and sysfs (maybe also
still in procfs) after the ieee1394 driver properly recognized the
device, handed it over to sbp2, and sbp2 logged in into it.

>>gscanbus shows the external device fine, but of course
>>I can't do anything using gscanbus, just see that its
>>there.

Does gscanbus show it with a disk pictogram or with a question mark
(unknown device type)?

>>In dmesg I get a whole slew of errors and warnings (I
>>turned on verbose reporting in case something
>>interesting/helpful for fixing this would crop up)
>>Here's a sample after I modprobed the appropriate
>>modules
>>ieee1394: Node added: ID:BUS[0-00:1023] GUID[0030e00e00000000]
...
>>ieee1394: Host added: ID:BUS[0-01:1023] GUID[00000100000e0436]

So it was at least able to add the external node while keeping the host
adapter as root node (highest ID on the bus) and even managed to read
the external device's GUID.

...
>>ohci1394: fw-host0: Packet sent to node 63 tcode=0x0
>>tLabel=0x00 ack=0x11 spd=0 data=0x1F0000C0 ctx=0

(A usual broadcast write.)

...
>>ohci1394: fw-host0: Inserting packet for node
>>0-00:0000, tlabel=0, tcode=0x0, speed=0

Quadlet write request to node 0. I rather expected a read request here,
since nodemgr should begin to fetch the config ROM from the device. I am
not aware of any write transactions that the drivers would attempt just
after a node was added. Or am I missing something? And...

...
>>ohci1394: fw-host0: Packet received from node 0
>>ack=0x11 spd=2 tcode=0x6 length=20 ctx=0 tlabel=18
>>ieee1394: received packet: ffc16160 ffc00000 00000000
>>00000000
>>ieee1394: unsolicited response packet received - no
>>tlabel match

...a quadlet _read_ response with a wrong transaction label? (The tlabel
of each response have to match that of a request of the same type, e.g.
quadlet read/ quadlet read, block write/ block write and so forth.)

...
>>ohci1394: fw-host0: Packet sent to node 0 tcode=0xE
>>tLabel=0x00 ack=0x11 spd=0 data=0x00000000 ctx=0

This looks as if it belonged to the "Inserting packet for node 0-00..."
above. Although I am not sure how the tcode became 0xE here (phy
packet). It's all very strange.

And after that, nothing? Especially from nodemgr or sbp2?

Also, have a look into /var/log/{messages,syslog,kern.log} or wherever
/etc/syslog.conf says the kernel messages are going to. These logs have
the benefit over dmesg that there are time stamps in them.

-- 
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