Broken Firewire 400/SCSI on ppc Powerbook5,8

Hi All

Short version first:

The SCSI/FW routines seem to work like a charm with a LSILogic Model/ SYM13FW500-Disk on my old Macintosh titanium-IV laptop, with exactly the same relatively fresh git-kernel that does not work on the PowerBook5,8. That is I compiled the kernel on the Apple Powerbook5,8 and installed it on both machines.

SCSI/FW didn't work ever on the new PowerBook5,8.

I'll give you first some error messages for the failing FW disk, and at the end of this mail you'll find links to technical documentation for the 2 failng machines (Powerbook5,8 and FW board/disk)

First I load the drivers with this little script:

------------------------------------------
#!/bin/sh -x
/bin/sh -n /home/shorty/scripts/scsi.start.sh && \

modprobe raw1394 && \
modprobe ieee1394 disable_irm=0 disable_nodemgr=1 && \
modprobe ohci1394 && \
modprobe eth1394 && \
modprobe sbp2 max_speed=3 workarounds=0x1 serialize_io=0 && \
sleep 4 && \
chown root.shorty /dev/raw1394
-------------------------------------------

After doing the latter:

-------------------------------

$ sh kernel-factory/git.08102006/linux-2.6/scripts/ver_linux 
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux debby1-6 2.6.18-rc4-060811-dirty #1 Fri Aug 11 00:16:22 CEST 2006 ppc GNU/ Linux

Gnu C                  4.1.2
Gnu make               3.81
binutils               2.17
util-linux             2.12r
mount                  2.12r
module-init-tools      3.2.2
e2fsprogs              1.39
pcmcia-cs              3.2.8
Linux C Library        2.3.6
Dynamic linker (ldd)   2.3.6
Procps                 3.2.7
Net-tools              1.60
Console-tools          0.2.3
Sh-utils               5.97
udev                   093
Modules Loaded         sbp2 eth1394 ohci1394 raw1394 ieee1394 bluetooth radeon d

rm nfs nfsd exportfs lockd nfs_acl sunrpc ipv6 therm_adt746x sr_mod cpufreq_powe rsave cpufreq_performance scsi_mod apm_emu joydev usblp appletouch usbhid snd_ao a_codec_onyx snd_aoa_fabric_layout snd_aoa pcmcia firmware_class evdev snd_aoa_i 2sbus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd ide_cd ohci _hcd yenta_socket sungem sungem_phy cdrom ehci_hcd usbcore rsrc_nonstatic pcmcia _core pmac_zilog serial_core soundcore snd_aoa_soundbus uninorth_agp agpgart i2c _powermac
------------------------------

After loading the drivers above the failing kernel says this about the via FW attached disk:

-----------------------------------

Aug 18 00:24:03 debby1-6 kernel: [38907.611119] ieee1394: Initialized config rom entry `ip1394'
Aug 18 00:24:03 debby1-6 kernel: [38907.628475] ieee1394: raw1394: /dev/raw1394 device initialized
Aug 18 00:24:03 debby1-6 kernel: [38907.692766] PM: Adding info for ieee1394:fw-host0
Aug 18 00:24:03 debby1-6 kernel: [38907.764726] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[40]  MMIO=[f5000000-f50007ff]  Max Packet=[4096]  IR/IT contexts=[8/8]
Aug 18 00:24:03 debby1-6 kernel: [38907.912614] eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Aug 18 00:24:04 debby1-6 kernel: [38909.170610] ieee1394: The root node is not cycle master capable; selecting a new root node and resetting...
Aug 18 00:24:05 debby1-6 kernel: [38910.425599] ieee1394: Error parsing configrom for node 0-00:1023
Aug 18 00:24:05 debby1-6 kernel: [38910.425992] PM: Adding info for ieee1394:001451fffe3148be
Aug 18 00:24:05 debby1-6 kernel: [38910.426064] ieee1394: Host added: ID:BUS[0-02:1023]  GUID[001451fffe3148be]
Aug 18 00:24:05 debby1-6 kernel: [38910.426209] PM: Adding info for ieee1394:001451fffe3148be-0

-----------------------------------

And gscanbus says this for:
"Unknown
Linux - ohci1394":

--------------------------
SelfID Info
-----------
Physical ID: 2
Link active: Yes
Gap Count: 63
PHY Speed: Unknown
PHY Delay: <=144ns
IRM Capable: Yes
Power Class: -1W
Port 0: Not connected
Port 1: Connected to child node
Port 2: Not connected
Init. reset: Yes

CSR ROM Info
------------
GUID: 0x001451FFFE3148BE
Node Capabilities: 0x000083C0
Vendor ID: 0x00001451
Unit Spec ID: 0x0000005E
Unit SW Version: 0x00000001
Model ID: 0x00000000
Nr. Textual Leafes: 1

Vendor: Unknown
Textual Leafes:
Linux - ohci1394

AV/C Subunits
-------------
N/A

-------------------------

And this for "S400 unknown":

---------------------------------
SelfID Info
-----------
Physical ID: 1
Link active: No
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: No
Power Class: -1W
Port 0: Connected to parent node
Port 1: Not connected
Port 2: Connected to child node
Init. reset: No

CSR ROM Info
------------
GUID: 0x0000000000000000
Node Capabilities: 0x00000000
Vendor ID: 0x00000000
Unit Spec ID: 0x00000000
Unit SW Version: 0x00000000
Model ID: 0x00000000
Nr. Textual Leafes: 0

Vendor: (null)
Textual Leafes:

AV/C Subunits
-------------
N/A

-----------------------------------

I haven't enabled for the current kernel IEEE1394_VERBOSEDEBUG. I could recompile it and enable this option if necessary, to provide more verbose kernel logs.

As to the documentation for the 2 machines, where all this is happening, first the computer, then the FW board/disk:

*** 1:

The computer:

$ cat /proc/cpuinfo 
processor       : 0
cpu             : 7447A, altivec supported
clock           : 1666.666000MHz
revision        : 0.5 (pvr 8003 0105)
bogomips        : 33.15
timebase        : 8320000
platform        : PowerMac
machine         : PowerBook5,8
motherboard     : PowerBook5,8 MacRISC3 Power Macintosh 
detected as     : 287 (PowerBook G4 15")
pmac flags      : 00000019
L2 cache        : 512K unified
pmac-generation : NewWorld

Some Apple technical documentation for the Firewire 400/800 ports is here:
http://developer.apple.com/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G4/15inchPowerBookG4/3Input-Output/chapter_4_section_3.html#//apple_ref/doc/uid/TP40003165-CH207-TPXREF105

Start page - if the link above is only a temporary one - seems being here:

http://developer.apple.com/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G4/15inchPowerBookG4/index.html

*** 2:

The Firewire disk/board:

I don't have reasonable technical docs for the FW board. Here's a picture of the package for the disk enclosure, with some technical data:
http://www.geocities.com/wolfgangpfeiffer/scsi.case.specs.jpg

This seems to be the board for the disk, inside the enclosure:
Vendor: LSILogic Model: SYM13FW500-Disk Rev: 1.00

I have pictures for the board here:

Disk on the board, top side:
http://wolfgangpfeiffer.com/scsi.top.jpg

Bottomside, with wirings:
http://wolfgangpfeiffer.com/scsi.focussed.flash.jpg
[444 KB]

Similar:
http://www.wolfgangpfeiffer.com/scsi.disk.2.scaled.jpg
[276 KB]

Wirings side again:
http://www.wolfgangpfeiffer.com/scsi.focussed.flash.jpg
[444 KB]

Please let me know if you need more information

Thanks for your time.

Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Hi Wolfgang,

I don't know if it matters for you (haven't tried Firewire yet on a PowerBook), but on my desktop PowerMac systems, I need a "sleep 2" before the modprobe for sbp2, to get my Firewire disks to work properly.

-Hope this helps

-Bill

Hi Bill

Thanks for responding

No, that doesn't help: I made several changes to the script now, with a shorter or longer sleep delay, changing driver options - still no /dev/sdX/:

-------------------------------------
#!/bin/sh -x
/bin/sh -n /home/shorty/scripts/scsi.start.sh ; \

modprobe raw1394; \
modprobe ieee1394 disable_irm=1 disable_nodemgr=0; \
modprobe ohci1394; \
modprobe eth1394; \
sleep 4; \
#modprobe sbp2 max_speed=3 workarounds=0x1 serialize_io=0; \
#modprobe sbp2 max_speed=3 serialize_io=0; \
modprobe sbp2; \
sleep 4; \
chown root.shorty /dev/raw1394

--------------------------------------

What I got today is this:

-----------------------------

Aug 18 11:57:46 debby1-6 kernel: [ 2113.770420] ieee1394: Initialized config rom entry `ip1394'
Aug 18 11:57:46 debby1-6 kernel: [ 2113.777915] ieee1394: raw1394: /dev/raw1394 device initialized
Aug 18 11:57:46 debby1-6 kernel: [ 2113.848894] PM: Adding info for ieee1394:fw-host0
Aug 18 11:57:46 debby1-6 kernel: [ 2113.901455] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[40]  MMIO=[f5000000-f50007ff]  Max Packet=[4096]  IR/IT contexts=[8/8]
Aug 18 11:57:46 debby1-6 kernel: [ 2113.961215] eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Aug 18 11:57:47 debby1-6 kernel: [ 2115.219661] ieee1394: The root node is not cycle master capable; selecting a new root node and resetting...
Aug 18 11:57:48 debby1-6 kernel: [ 2116.448637] ieee1394: Error parsing configrom for node 0-00:1023
Aug 18 11:57:48 debby1-6 kernel: [ 2116.449037] PM: Adding info for ieee1394:001451fffe3148be
Aug 18 11:57:48 debby1-6 kernel: [ 2116.449126] ieee1394: Host added: ID:BUS[0-02:1023]  GUID[001451fffe3148be]
Aug 18 11:57:48 debby1-6 kernel: [ 2116.449281] PM: Adding info for ieee1394:001451fffe3148be-0
Aug 18 11:57:50 debby1-6 kernel: [ 2118.041601] ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
Aug 18 11:57:50 debby1-6 kernel: [ 2118.041634] ieee1394: sbp2: Try serialize_io=0 for better performance

-----------------------------------

Following a log excerpt from a few days ago, when I got /dev/sda at least, tho still no disk partition (Please don't ask me how I got that
far: that time I must have played around with the FW drivers, un- and reloading them again .... and at one moment I had at least the following ):

--------------------------------

Aug 11 23:53:16 debby1-6 kernel: [11154.413116] ieee1394: Node changed: 0-02:102
3 -> 0-00:1023
Aug 11 23:53:21 debby1-6 kernel: [11160.079353] PM: Adding info for ieee1394:003
0ffa046010cd5
Aug 11 23:53:21 debby1-6 kernel: [11160.079456] ieee1394: Node added: ID:BUS[0-0
0:1023]  GUID[0030ffa046010cd5]
Aug 11 23:53:21 debby1-6 kernel: [11160.079626] ieee1394: Node changed: 0-00:102
3 -> 0-02:1023
Aug 11 23:53:21 debby1-6 kernel: [11160.081535] PM: Adding info for ieee1394:003
0ffa046010cd5-0
Aug 11 23:53:21 debby1-6 kernel: [11160.190054] ieee1394: sbp2: Driver forced to
 serialize I/O (serialize_io=1)
Aug 11 23:53:21 debby1-6 kernel: [11160.190070] ieee1394: sbp2: Try serialize_io
=0 for better performance
Aug 11 23:53:21 debby1-6 kernel: [11160.191555] scsi2 : SBP-2 IEEE-1394
Aug 11 23:53:21 debby1-6 kernel: [11160.191815] PM: Adding info for No Bus:host2
Aug 11 23:53:23 debby1-6 kernel: [11161.295090] ieee1394: sbp2: Logged into SBP-
2 device
Aug 11 23:53:23 debby1-6 kernel: [11161.295728] ieee1394: Node 0-00:1023: Max sp
eed [S400] - Max payload [2048]
Aug 11 23:53:23 debby1-6 kernel: [11161.295932] PM: Adding info for No Bus:targe
t2:0:0
Aug 11 23:53:23 debby1-6 kernel: [11161.301996]   Vendor: LSILogic  Model: SYM13
FW500-Disk   Rev: 1.00
Aug 11 23:53:23 debby1-6 kernel: [11161.302026]   Type:   Direct-Access
             ANSI SCSI revision: 00
Aug 11 23:53:23 debby1-6 kernel: [11161.302323] PM: Adding info for scsi:2:0:0:0
Aug 11 23:53:26 debby1-6 udevd-event[5667]: wait_for_sysfs: waiting for '/sys/de
vices/pci0002:24/0002:24:0e.0/fw-host0/0030ffa046010cd5/0030ffa046010cd5-0/host2
/target2:0:0/2:0:0:0/ioerr_cnt' failed
Aug 11 23:53:53 debby1-6 kernel: [11191.302896] ieee1394: sbp2: aborting sbp2 command
Aug 11 23:53:53 debby1-6 kernel: [11191.302912] sd 2:0:0:0:
Aug 11 23:53:53 debby1-6 kernel: [11191.302915]         command: Test Unit Ready: 00 00 00 00 00 00
Aug 11 23:54:03 debby1-6 kernel: [11201.302892] ieee1394: sbp2: aborting sbp2 command
Aug 11 23:54:03 debby1-6 kernel: [11201.302909] sd 2:0:0:0:
Aug 11 23:54:03 debby1-6 kernel: [11201.302913]         command: Test Unit Ready: 00 00 00 00 00 00
Aug 11 23:54:03 debby1-6 kernel: [11201.302957] ieee1394: sbp2: reset requested
Aug 11 23:54:03 debby1-6 kernel: [11201.302962] ieee1394: sbp2: Generating sbp2 fetch agent reset
Aug 11 23:54:13 debby1-6 kernel: [11211.302892] ieee1394: sbp2: aborting sbp2 command
Aug 11 23:54:13 debby1-6 kernel: [11211.302907] sd 2:0:0:0:
Aug 11 23:54:13 debby1-6 kernel: [11211.302910]         command: Test Unit Ready: 00 00 00 00 00 00
Aug 11 23:54:13 debby1-6 kernel: [11211.302955] sd 2:0:0:0: scsi: Device offlined - not ready after error recovery
Aug 11 23:54:13 debby1-6 kernel: [11211.303150] sd 2:0:0:0: rejecting I/O to offline device
Aug 11 23:54:13 debby1-6 kernel: [11211.303199] sd 2:0:0:0: rejecting I/O to offline device
Aug 11 23:54:13 debby1-6 kernel: [11211.303237] sd 2:0:0:0: rejecting I/O to offline device
Aug 11 23:54:13 debby1-6 kernel: [11211.303272] sda : READ CAPACITY failed.
Aug 11 23:54:13 debby1-6 kernel: [11211.303276] sda : status=0, message=00, host=1, driver=00
Aug 11 23:54:13 debby1-6 kernel: [11211.303282] sda : sense not available.
Aug 11 23:54:13 debby1-6 kernel: [11211.303349] sd 2:0:0:0: rejecting I/O to offline device
Aug 11 23:54:13 debby1-6 kernel: [11211.303384] sda: Write Protect is off
Aug 11 23:54:13 debby1-6 kernel: [11211.303390] sda: Mode Sense: 00 00 00 00
Aug 11 23:54:13 debby1-6 kernel: [11211.303423] sd 2:0:0:0: rejecting I/O to offline device
Aug 11 23:54:13 debby1-6 kernel: [11211.303432] sda: asking for cache data failed
Aug 11 23:54:13 debby1-6 kernel: [11211.303436] sda: assuming drive cache: write through
Aug 11 23:54:13 debby1-6 kernel: [11211.304555] sd 2:0:0:0: Attached scsi disk sda
Aug 11 23:54:13 debby1-6 kernel: [11211.304657] sd 2:0:0:0: Attached scsi generic sg0 type 0

-----------------------------

Thanks again, and
Best Regards
Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Bill Fink wrote:
...

What happens if you don't put the pause in there? What disks do you have and what bridge chips are built in? (Please apologize if you reported this before and we didn't come to a solution then.)

Stefan Richter
-=====-=-==- =--- =--==
http://arcgraph.de/sr/

First of all this was on a somewhat older 2.6.11.8 kernel without any hotplug (I'll probably be trying this again soon with a newer 2.6.15-rc5 kernel). And I was actually booting off this Firewire disk. Without the pause I would get:

Loading sb2.ko module
sb2: $rev 1219 ...
Creating block devices
Creating root device
Mkrootdev: label fw1-root not found

Then it wouldn't be able to mount the root filesystem, which would be followed shortly by a kernel panic.

If I put the "sleep 2" before the "modprobe sbp2" then everything works. There's a message about initializing SCSI emulation for SBP-2, followed by the discovery of the Firewire disk and the creation of the sda device, which then allows the successful mounting of the root filesystem.

Here's the full linuxrc nash script from the initrd for the working case:

#!/bin/nash

mount -t proc /proc /proc
setquiet
echo Mounted /proc filesystem
echo Mounting sysfs
mount -t sysfs none /sys
echo "Loading ieee1394.ko module"
insmod /lib/ieee1394.ko
echo "Loading ohci1394.ko module"
insmod /lib/ohci1394.ko
sleep 2
echo "Loading raw1394.ko module"
insmod /lib/raw1394.ko
echo "Loading sbp2.ko module"
insmod /lib/sbp2.ko
echo Creating block devices
mkdevices /dev
echo Creating root device
mkrootdev /dev/root
umount /sys
echo 0x0100 > /proc/sys/kernel/real-root-dev
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
pivot_root /sysroot /sysroot/initrd
umount /initrd/proc

The disk is an 80 GB LaCie Firewire disk, reported by the kernel as:

Aug 19 19:48:01 gwiz kernel: ieee1394: sbp2: Logged into SBP-2 device
Aug 19 19:48:01 gwiz kernel:   Vendor: ST380021  Model: A                 Rev: 3.05
Aug 19 19:48:01 gwiz kernel:   Type:   Direct-Access-RBC                  ANSI SCSI revision: 04
Aug 19 19:48:01 gwiz kernel: SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Aug 19 19:48:01 gwiz kernel: sda: asking for cache data failed
Aug 19 19:48:01 gwiz kernel: sda: assuming drive cache: write through
Aug 19 19:48:01 gwiz kernel: SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Aug 19 19:48:01 gwiz kernel: sda: asking for cache data failed
Aug 19 19:48:01 gwiz kernel: sda: assuming drive cache: write through
Aug 19 19:48:01 gwiz kernel:  sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11
Aug 19 19:48:01 gwiz kernel: sd 1:0:0:0: Attached scsi disk sda
Aug 19 19:48:01 gwiz kernel: sd 1:0:0:0: Attached scsi generic sg0 type 14

The above messages are actually from booting (non-Firewire) the newer 2.6.15-rc5 kernel.

-Bill

[...]

[...]

[...]

OK. Mounting the root FS from a FireWire disk is a somewhat different matter from normal hotplug. I can see why you need the few seconds pause between when ohci1394 is loaded and when sbp2 is loaded. With this pause, it is very likely that ieee1394 was able to discover and scan the disk's node before sbp2 is loaded. AFAIU, "insmod sbp2" will therefore not only load the sbp2 code but will also execute sbp2's device probe routine (i.e. SBP-2 login, creation of the SCSI device, SCSI inquiry, and attachment of the sd driver to it) before "insmod sbp2" exits.

Another approach would be to put a basically complete hotplug userland into the initrd and then wait for the disk with the root FS to appear. (The disk is e.g. known by its FireWire GUID.) Then you wouldn't need the hardcoded pause to wait until after the SBP-2 disk made its configuration ROM available and ieee1394 scanned it.

BTW, a few improvements WRT device recognition went into nearly each of the Linux releases since 2.6.11. I think they are not relevant to most or all LaCie disks though.

Discovery of SBP-2 devices will always remain an asynchronous non-deterministic process anyway. But this is true for all SCSI transports and interconnects. It's just that most other SCSI interconnect drivers' initialization routines hold off until they fully scanned their bus --- which makes sense at least for SCSI interconnects which are not hotplug capable.

Recently there were patches sent to the Linux SCSI mailinglist that add optional asynchronous and parallelized bus scanning to all of these traditional drivers too. Emphasis lies on parallelized since this is primarily meant to speed up the boot process of systems with many SCSI buses. There is also a callback to notify the system when all buses are done with scanning in order to know when to proceed with mounting of filesystems. I have not yet looked into if this can sensibly used in sbp2. I also didn't watch the merge status of these SCSI patches.

Stefan Richter
-=====-=-==- =--- =-==-
http://arcgraph.de/sr/

[ ... ]

In the meantime I suspect a hardware problem.

Here's why:

I connected the FW disk I was reporting about in previous postings to both an older Apple titanium Powerbook and to the newer Apple alubook 5,8.

In both instances I rebooted the machines with the accompanying different Apple OS X install CD's. Both CD's have a so-called "Disk Utility" tool with them, a tool that generally detects and repairs disks. The tool clearly detected the FW disk attached to my old titanium. And the same tool didn't detect the same FW disk on the newer alubook 5,8 ... :)

In both instances I connected the FW disk to the FW 400 connector of the machines.

So unless there are differing FW 400 versions available on both machines I'd suspect a hardware prob with the 5,8.

[Note: Do there actually exist different Firewire 400 versions?]

I'll make this issue clear next week with a trip to the shop where I bought the alubook.

And I'll be back as soon as I know more ...

Thanks. And sorry the idea with the check via OSX didn't come to my mind earlier ...

Until then, and a nice week-end to everyone

Regards
Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Yes, there are, but they should be fully interoperable --- with one exception that doesn't apply to Powerbooks.

A) There are old IEEE 1394-1995 only compliant PHYs. Such PHYs have not been used by manufacturers anymore since long ago.

B) There are IEEE 1394a-2000 compliant PHYs. IEEE 1394a added, among else, enhanced asynchronous arbitration, but AFAIU this is fully interoperable with 1394-1995 PHYs. The bridge board of your enclosure has a 1394a-2000 PHY (the TSB41LV03A). The SYM13FW501 appears to be only a 1394-1995 compliant link layer controller (probably with integrated PHY) but this shouldn't matter.

C) IEEE 1394b-2002 compliant PHYs with monolingual S400A port(s). They behave exactly like 1394a-2000 PHYs.

D) IEEE 1394b-2002 compliant PHYs with monolingual S400B port(s). These are not interoperable with neither of A, B, C. Therefore such ports need to have a 9-pin socket whose formfactor is coded as a monolingual port. Therefore it is physically impossible to connect such a port with ports of type A, B, or C. I don't know if there are actual products with monolingual S400B ports.

IEEE 1394b-2002 compliant PHYs may have
- bilingual ports,
- Beta-only ports (Beta mode is a new signaling mode introduced by
1394b which is not interoperable with 1394-1995 and 1394a),
- and/or ports that are forced to only use legacy signaling, i.e. the
same as of IEEE 1394a PHYs.
The S800 9-pin port of the AlBook is a bilingual port; the S400 6-pin port should be a 1394b port which is forced to use only legacy signaling.

BTW, I have a portable CD-RW which I suspect to have a similar or the same bridge chip as your HDD. This is because it also shows two nodes instead of one node and because it suffered the same problem related to the BROADCAST_CHANNEL register as the Datafab HDD. I cannot open the CD-RW without damaging it therefore I cannot confirm the actual chips in there. This CD-RW works fine on a bilingual 1394b PCI adapter with 9-pin to 6-pin cable.

If you have got the TiBook around, you could connect it with the AlBook and look what gscanbus or OS X's system profiler have to say about it. If possible, also try the TiBook in target disk mode and see if it appears as a disk for Linux' sbp2 or under OS X.

The fact that Linux on the AlBook gets at least as far as "ieee1394: Error parsing configrom for node 0-00:1023" indicates that not all hope is lost. If you have got the time, compile the 1394 drivers for verbose logging and send the log. Don't crosspost the log if it gets too big.

Stefan Richter
-=====-=-==- =--- =--==
http://arcgraph.de/sr/

Hi Stefan

Thanks a lot for your very detailed explanations of the 1394 et al. drivers. It helps me a lot ...

On Sat, Aug 19, 2006 at 11:13:24AM +0200, Stefan Richter wrote:

                        [ ... ]

I tested this, not on OSX, but Linux:
Target disk mode works excellent on the new Powerbook5,8 (alubook): I booted the old TitaniumIV (tibook) -- connected via the FW cable to the alubook -- in target disk mode. Very quickly after the tibook started I was asked by KDE on the alubook what to do with the newly detected disks. And some news icons appeared on the KDE desktop, 2 of them correctly representing the 2 main partitions on the tibook.

Here's /var/log/kern.log on the alubook, at about the time when I started the tibook in target disk mode

------------------------------------

Aug 20 02:04:18 debby1-6 kernel: [ 8644.941230] ieee1394: Node changed: 0-01:1023 -> 0-00:1023
Aug 20 02:04:18 debby1-6 kernel: [ 8644.941295] ieee1394: Node suspended: ID:BUS[0-00:1023]  GUID[000393fffecde4c4]
Aug 20 02:04:27 debby1-6 kernel: [ 8653.484415] ieee1394: Node resumed: ID:BUS[0-00:1023]  GUID[000393fffecde4c4]
Aug 20 02:04:27 debby1-6 kernel: [ 8653.484580] ieee1394: Node changed: 0-00:1023 -> 0-01:1023
Aug 20 02:05:53 debby1-6 kernel: [ 8740.212617] PM: Removing info for ieee1394:000393fffecde4c4-0
Aug 20 02:06:00 debby1-6 kernel: [ 8746.315023] PM: Adding info for ieee1394:000393fffecde4c4-0
Aug 20 02:06:00 debby1-6 kernel: [ 8746.315180] scsi1 : SBP-2 IEEE-1394
Aug 20 02:06:00 debby1-6 kernel: [ 8746.315199] PM: Adding info for No Bus:host1
Aug 20 02:06:01 debby1-6 kernel: [ 8747.416987] ieee1394: sbp2: Logged into SBP-2 device
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417194] ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417232] PM: Adding info for No Bus:target1:0:0
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417738]   Vendor: AAPL      Model: FireWire Target   Rev: 0000
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417767]   Type:   Direct-Access-RBC                  ANSI SCSI revision: 03
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417791] PM: Adding info for scsi:1:0:0:0
Aug 20 02:06:01 debby1-6 kernel: [ 8747.485838] SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB)
Aug 20 02:06:01 debby1-6 kernel: [ 8747.486345] sda: Write Protect is off
Aug 20 02:06:01 debby1-6 kernel: [ 8747.486354] sda: Mode Sense: 00 00 00 00
Aug 20 02:06:01 debby1-6 kernel: [ 8747.486774] sda: asking for cache data failed
Aug 20 02:06:01 debby1-6 kernel: [ 8747.486781] sda: assuming drive cache: write through
Aug 20 02:06:01 debby1-6 kernel: [ 8747.487400] SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB)
Aug 20 02:06:01 debby1-6 kernel: [ 8747.487721] sda: Write Protect is off
Aug 20 02:06:01 debby1-6 kernel: [ 8747.487728] sda: Mode Sense: 00 00 00 00
Aug 20 02:06:01 debby1-6 kernel: [ 8747.488150] sda: asking for cache data failed
Aug 20 02:06:01 debby1-6 kernel: [ 8747.488156] sda: assuming drive cache: write through
Aug 20 02:06:01 debby1-6 kernel: [ 8747.488437]  sda: [mac] sda1 sda2 sda3 sda4 sda5
Aug 20 02:06:01 debby1-6 kernel: [ 8747.492435] sd 1:0:0:0: Attached scsi disk sda

--------------------------------------

So at least it looks now as if the Firewire 400 Hardware on the alubook is not broken. Correct? Would be a great relief as I hate it to have it away at the repair service.

I could mount the 2 tibook partitions easily on the alubook.

On the alubook:
-----------------------------------------

# mount
/dev/hda7 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda6 on /home type ext3 (rw)
/dev/hda5 on /var type ext3 (rw)
tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)
nfsd on /proc/fs/nfsd type nfsd (rw)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/sda4 on /media/usbdisk type ext3 (rw,noexec,nosuid,nodev)
/dev/sda5 on /media/usbdisk-1 type ext3 (rw,noexec,nosuid,nodev)
-------------------------------- 

sd4/sda5 must be the 2 main partitions on the tibook ..

I mounted them, and a few seconds after unmounting them this must have been the corresponding kern.log:

-------------------------------------------

Aug 20 03:05:20 debby1-6 kernel: [12306.976988] ieee1394: sbp2: Error logging into SBP-2 device - login timed-out
Aug 20 03:05:20 debby1-6 kernel: [12306.977004] ieee1394: sbp2: Failed to reconnect to sbp2 device!
Aug 20 03:05:20 debby1-6 kernel: [12306.977410] PM: Removing info for scsi:1:0:0:0
Aug 20 03:05:20 debby1-6 kernel: [12306.977482] PM: Removing info for No Bus:target1:0:0
Aug 20 03:05:20 debby1-6 kernel: [12306.977558] PM: Removing info for No Bus:host1
Aug 20 03:05:20 debby1-6 kernel: [12307.233256] ieee1394: Node changed: 0-01:1023 -> 0-00:1023
Aug 20 03:05:20 debby1-6 kernel: [12307.233324] ieee1394: Node suspended: ID:BUS[0-00:1023]  GUID[000393fffecde4c4]

--------------------------------------------

OTOH: Connecting the alubook and tibook with Linux up and running on both machines did not create a working (FW) connection between them .. I'll try the latter later again -- even perhaps with OSX on the alubook and Linux on the tibook ...

I'll compile a fresh git kernel next week, Tuesday or Wednesday, with verbose logging for the 1394 drivers. And I'll put the corresponding logs for the 1394 tests on my homepage instead of sending them via email anywhere, only the URL's for the logs will be sent in my messages. Please let me know if you disagree ...

BTW: Do you know how to switch off verbose logging for the 1394 drivers once they're compiled into the kernel, via some echo "<some-value>" to /sys/*/* ?
I didn't find any entry there until now for that purpose ...

Until then, and thanks a lot for your time.

Best Regards
Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Wolfgang Pfeiffer wrote:
[...]

Yes, the port is certainly working correctly.

Of course they won't export SBP-2 targets then. But they should be visible in Linux' sysfs or gscanbus or OS X' system profiler as external nodes. It is also possible to establish an IPv4 connection over FireWire between them, using eth1394 on Linux and OS X' network preferences panel.

[...]

It can only be configured at compile time.

Stefan Richter
-=====-=-==- =--- =-=-=
http://arcgraph.de/sr/

I sent the test results of the target disk mode last night.

Now this evening I tried to connect the alubook to the titanium via the FW 400 ports with both machines fully booted.

First the alubook with OSX connected to the titanium with Linux on it, and then both computers connected to each other with Linux running on both of them.

The alubook is a dual-boot machine (OSX/Linux), while the titanium only has Linux on it.

_____________________________________________________________________________
PART I

Connecting the alubook (with OSX running) to the tibook (with Linux running)
---------------------------------------------------------------------------

Status on the titanium, with a kernel 2.6.14-1, IEEE1394_VERBOSEDEBUG is enabled there.

After modprobing raw1394 the connected AluBook (OSX running) is seen via gscanbus, but /dev/sda is not created. sbp2 was not started at that time. modprobing sbp2 does not help to change this.

gscanbus tho:

clicking
S400 Linux - ohci 1394:

------------------------
SelfID Info
-----------
Physical ID: 1
Link active: Yes
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: Yes
Power Class: None
Port 0: Connected to child node
Init. reset: Yes

CSR ROM Info
------------
GUID: 0x000393FFFECDE4C4
Node Capabilities: 0x000083C0
Vendor ID: 0x00000393
Unit Spec ID: 0x0000005E
Unit SW Version: 0x00000001
Model ID: 0x00000000
Nr. Textual Leafes: 1

Vendor: Apple Computer, Inc.
Textual Leafes:
Linux - ohci1394

AV/C Subunits
-------------
N/A

---------------------

clicking
"Unknown
Apple Computer, Inc." results in:

---------------------
SelfID Info
-----------
Physical ID: 0
Link active: Yes
Gap Count: 63
PHY Speed: Unknown
PHY Delay: <=144ns
IRM Capable: Yes
Power Class: -1W
Port 0: Not connected
Port 1: Connected to parent node
Port 2: Not connected
Init. reset: No

CSR ROM Info
------------
GUID: 0x001451FFFE3148BE
Node Capabilities: 0x000083C0
Vendor ID: 0x00000A27
Unit Spec ID: 0x0000005E
Unit SW Version: 0x00000002
Model ID: 0x00000000
Nr. Textual Leafes: 2

Vendor: Apple Computer, Inc.
Textual Leafes:
Apple Computer, Inc.
Macintosh

AV/C Subunits
-------------
N/A

--------------------

Im getting in /var/log/kern.log messages like this:

---------------------------------

Aug 20 23:48:27 debby kernel: [ 2389.161336] raw1394:read_request called
Aug 20 23:48:27 debby kernel: [ 2389.161357] ieee1394: send packet local: ffc1a540 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.161369] ieee1394: received packet: ffc1a540 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.161386] ieee1394: send packet local: ffc1a560 ffc10000 00000000 7a2367e9
Aug 20 23:48:27 debby kernel: [ 2389.161400] ieee1394: received packet: ffc1a560 ffc10000 00000000 7a2367e9
Aug 20 23:48:27 debby kernel: [ 2389.261335] raw1394:read_request called
Aug 20 23:48:27 debby kernel: [ 2389.261356] ieee1394: send packet local: ffc1a940 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.261369] ieee1394: received packet: ffc1a940 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.261386] ieee1394: send packet local: ffc1a960 ffc10000 00000000 7a5567ff
Aug 20 23:48:27 debby kernel: [ 2389.261400] ieee1394: received packet: ffc1a960 ffc10000 00000000 7a5567ff
Aug 20 23:48:27 debby kernel: [ 2389.361334] raw1394:read_request called
Aug 20 23:48:27 debby kernel: [ 2389.361356] ieee1394: send packet local: ffc1ad40 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.361369] ieee1394: received packet: ffc1ad40 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.361386] ieee1394: send packet local: ffc1ad60 ffc10000 00000000 7a876814
Aug 20 23:48:27 debby kernel: [ 2389.361401] ieee1394: received packet: ffc1ad60 ffc10000 00000000 7a876814
Aug 20 23:48:27 debby kernel: [ 2389.461326] raw1394:read_request called
Aug 20 23:48:27 debby kernel: [ 2389.461348] ieee1394: send packet local: ffc1b140 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.461361] ieee1394: received packet: ffc1b140 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.461378] ieee1394: send packet local: ffc1b160 ffc10000 00000000 7ab96750
Aug 20 23:48:27 debby kernel: [ 2389.461392] ieee1394: received packet: ffc1b160 ffc10000 00000000 7ab96750
Aug 20 23:48:27 debby kernel: [ 2389.561323] raw1394:read_request called
Aug 20 23:48:27 debby kernel: [ 2389.561346] ieee1394: send packet local: ffc1b540 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.561359] ieee1394: received packet: ffc1b540 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.561377] ieee1394: send packet local: ffc1b560 ffc10000 00000000 7aeb675c
Aug 20 23:48:27 debby kernel: [ 2389.561392] ieee1394: received packet: ffc1b560 ffc10000 00000000 7aeb675c
Aug 20 23:48:27 debby kernel: [ 2389.661317] raw1394:read_request called
Aug 20 23:48:27 debby kernel: [ 2389.661338] ieee1394: send packet local: ffc1b940 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.661351] ieee1394: received packet: ffc1b940 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.661367] ieee1394: send packet local: ffc1b960 ffc10000 00000000 7b1d668a
Aug 20 23:48:27 debby kernel: [ 2389.661382] ieee1394: received packet: ffc1b960 ffc10000 00000000 7b1d668a
Aug 20 23:48:27 debby kernel: [ 2389.761314] raw1394:read_request called
Aug 20 23:48:27 debby kernel: [ 2389.761335] ieee1394: send packet local: ffc1bd40 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.761348] ieee1394: received packet: ffc1bd40 ffc1ffff f0000200
Aug 20 23:48:27 debby kernel: [ 2389.761366] ieee1394: send packet local: ffc1bd60 ffc10000 00000000 7b4f6677
Aug 20 23:48:27 debby kernel: [ 2389.761381] ieee1394: received packet: ffc1bd60 ffc10000 00000000 7b4f6677
Aug 20 23:48:28 debby kernel: [ 2389.862296] raw1394:read_request called
Aug 20 23:48:28 debby kernel: [ 2389.862316] ieee1394: send packet local: ffc1c140 ffc1ffff f0000200
Aug 20 23:48:28 debby kernel: [ 2389.862329] ieee1394: received packet: ffc1c140 ffc1ffff f0000200
Aug 20 23:48:28 debby kernel: [ 2389.862347] ieee1394: send packet local: ffc1c160 ffc10000 00000000 7b81e4b4
Aug 20 23:48:28 debby kernel: [ 2389.862362] ieee1394: received packet: ffc1c160 ffc10000 00000000 7b81e4b4

---------------------------

This is what OSX (on the alubook) says:
---------------------

.. about the titanium with Linux running: No pasting possible of the values I saw: I wrote it down what I saw on the OSX screen:

Network status in OS X System Preferences reports something like this:

"Built in Firewire"

"Cable for built-in Firewire is connected, but your computer does not have an IP address and cannot connect to the Internet"

I didn't even try (never will) to reconfigure this - I don't trust OSX enough to let it come closer than 500 meters to my Linux partitions.

The Apple System Profiler, as it seems about the Titanium:

---------------------
Firewire Bus:
Unknown device

Manufacturer: Linux - ohci1394
Model: unknown device
GUID: 0x393FFFECDE4C4
Maximum Speed: Up to 400 Mb/Sec
Connection Speed: Up to 400 Mb/Sec

Unknown Unit:
Unit Software version: 0x1
Unit Spec ID: 0x5E
-----------------------------

-----------------------------------------------------------------------------------
PART II

Connecting the alubook to the titanium, with both machines running Linux on them:
---------------------------------------------------------------------------------

Status on the titanium:

----------------------------------------------

$ /sbin/lsmod | grep -i sbp
sbp2                   24932  0 
scsi_mod              160836  2 sbp2,sg
ieee1394              425552  4 sbp2,raw1394,eth1394,ohci1394
[shorty@ 00:58:55]$ /sbin/lsmod | grep 1394  
raw1394                35064  2 
eth1394                20552  0 
ohci1394               44980  0 
ieee1394              425552  4 sbp2,raw1394,eth1394,ohci1394
--------------------------------------------------------

No /dev/sda on the titanium.

gscanbus:

2 icons on the gscanbus window:

#1:
" <some Penguin picture>
S400
Linux - ohci1394"

Clicking it:

------------------------------
SelfID Info
-----------
Physical ID: 1
Link active: Yes
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: Yes
Power Class: None
Port 0: Connected to child node
Init. reset: Yes

CSR ROM Info
------------
GUID: 0x000393FFFECDE4C4
Node Capabilities: 0x000083C0
Vendor ID: 0x00000393
Unit Spec ID: 0x0000005E
Unit SW Version: 0x00000001
Model ID: 0x00000000
Nr. Textual Leafes: 1

Vendor: Apple Computer, Inc.
Textual Leafes:
Linux - ohci1394

AV/C Subunits
-------------
N/A

------------------------------

#2:

"<Question mark>
Unknown
Linux - ohci1394"

Clicking it:

----------------------------
SelfID Info
-----------
Physical ID: 0
Link active: Yes
Gap Count: 63
PHY Speed: Unknown
PHY Delay: <=144ns
IRM Capable: Yes
Power Class: -1W
Port 0: Not connected
Port 1: Connected to parent node
Port 2: Not connected
Init. reset: No

CSR ROM Info
------------
GUID: 0x001451FFFE3148BE
Node Capabilities: 0x000083C0
Vendor ID: 0x00001451
Unit Spec ID: 0x0000005E
Unit SW Version: 0x00000001
Model ID: 0x00000000
Nr. Textual Leafes: 1

Vendor: Unknown
Textual Leafes:
Linux - ohci1394

AV/C Subunits
-------------
N/A

-----------------------------

---------------------------
Status on the alubook:
---------------------------

$ /sbin/lsmod | grep -i sbp
sbp2                   23528  0 
scsi_mod              154128  2 sr_mod,sbp2
ieee1394              417744  4 raw1394,sbp2,eth1394,ohci1394
[shorty@ 01:46:06]$ /sbin/lsmod | grep 1394
raw1394                28128  2 
eth1394                18628  0 
ohci1394               37392  0 
ieee1394              417744  4 raw1394,sbp2,eth1394,ohci1394

kernel is 2.6.18-rc4

$ zgrep IEEE1394_VERBOSEDEBUG /proc/config.gz
# CONFIG_IEEE1394_VERBOSEDEBUG is not set

gscanbus says this, after a "Force bus reset":

2 icons:

#1

"<Monitor with an Apple logo picture>
S400
Linux - ohci1394"

clicking it:

-------------------------
SelfID Info
-----------
Physical ID: 1
Link active: Yes
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: Yes
Power Class: None
Port 0: Connected to child node
Init. reset: No

CSR ROM Info
------------
GUID: 0x000393FFFECDE4C4
Node Capabilities: 0x000083C0
Vendor ID: 0x00000393
Unit Spec ID: 0x0000005E
Unit SW Version: 0x00000001
Model ID: 0x00000000
Nr. Textual Leafes: 1

Vendor: Apple Computer, Inc.
Textual Leafes:
Linux - ohci1394

AV/C Subunits
-------------
N/A

---------------------------

#2:

"<Monitor with a penguin picture>
Unknown
Linux - ohci1394"

clicking the picture:

-------------------------
SelfID Info
-----------
Physical ID: 0
Link active: Yes
Gap Count: 63
PHY Speed: Unknown
PHY Delay: <=144ns
IRM Capable: Yes
Power Class: -1W
Port 0: Not connected
Port 1: Connected to parent node
Port 2: Not connected
Init. reset: Yes

CSR ROM Info
------------
GUID: 0x001451FFFE3148BE
Node Capabilities: 0x000083C0
Vendor ID: 0x00001451
Unit Spec ID: 0x0000005E
Unit SW Version: 0x00000001
Model ID: 0x00000000
Nr. Textual Leafes: 1

Vendor: Unknown
Textual Leafes:
Linux - ohci1394

AV/C Subunits
-------------
N/A

----------------------------

No kern.log messages that I saw after the bus reset via gscanbus. No /dev/sda on the alubook.

As I already wrote: Tuesday or Wednesday I'll have the git kernel compiled, if all goes well. With CONFIG_IEEE1394_VERBOSEDEBUG enabled.

Note: About 2 days ago I had, IIRC, ext2fsx
(http://sourceforge.net/project/showfiles.php?group_id=64713) shortly installed on OSX - I quickly uninstalled it afterwards, and at the time of the tests today on OSX nothing *should* have been installed of that software anymore .. let's hope :)

I do not know too much on OS X, that's why I keep my hands off Linux via OSX.

Until then

Best Regards
Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

wrong: I had ext2fsx_dev installed, IIRC.

Sorry
Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Hi Stefan,
Hi All

On Sat, Aug 19, 2006 at 11:13:24AM +0200, Stefan Richter wrote:

          [ ... ]

Some tests on the Alubook:

I compiled a fresh git kernel now with verbose ieee logging turned on.

$ uname -r
2.6.18-rc4-ieeeverbose-gef7d1b24-dirty

$ zgrep 4_VERBOS /proc/config.gz 
CONFIG_IEEE1394_VERBOSEDEBUG=y

Before starting the FW disk I removed all ieee drivers I thought could be relevant, with this little script:

-------------------------
#!/bin/sh -x
/bin/sh -n /home/shorty/scripts/scsi.stop.sh; \
rmmod raw1394; \
rmmod eth1394;
rmmod ohci1394; \
rmmod sbp2; \
rmmod ieee1394
---------------------------------------

Then, with the FW disk connected to the alubook, but *not yet* powered on by the latter via a switch at the enclosure which obviously, when switched on, feeds the current to the firewire disk, thus switching it on:

-----------------------------------
#!/bin/sh -x
/bin/sh -n /home/shorty/scripts/scsi.start.sh ; \

modprobe ieee1394 disable_irm=0; \
sleep 2; \
modprobe ohci1394; \
sleep 2; \
modprobe sbp2; \
sleep 2; \
modprobe raw1394; \
sleep 2
chown root.shorty /dev/raw1394
sleep 4; \
ls /dev/sda

-------------------------------

Only after running the latter script, I switch on the FW disk. The log for these moments covering about 60 seconds is here:

wolfgangpfeiffer.com/kern.log.when.fw.disk.is.switched.on.txt

Then, some time later on with no /dev/sda available, I run gscanbus, forcing a bus reset. The log, again covering about 60 seconds is here:

wolfgangpfeiffer.com/kern.log.with.gscanbus.after.failed.fw.connection.txt

Again a bit later I click the 3 icons on the gscanbus window:

Clicking
"Unknown
Linux - ohci1394"

------------------------------------------------------
SelfID Info
-----------
Physical ID: 2
Link active: Yes
Gap Count: 63
PHY Speed: Unknown
PHY Delay: <=144ns
IRM Capable: Yes
Power Class: -1W
Port 0: Not connected
Port 1: Connected to child node
Port 2: Not connected
Init. reset: Yes

CSR ROM Info
------------
GUID: 0x001451FFFE3148BE
Node Capabilities: 0x000083C0
Vendor ID: 0x00001451
Unit Spec ID: 0x0000005E
Unit SW Version: 0x00000001
Model ID: 0x00000000
Nr. Textual Leafes: 1

Vendor: Unknown
Textual Leafes:
Linux - ohci1394

AV/C Subunits
-------------
N/A
-------------------------------------------------

Clicking

" <question mark>
S400 Unknown":

------------------------------------------
SelfID Info
-----------
Physical ID: 1
Link active: No
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: No
Power Class: -1W
Port 0: Not connected
Port 1: Connected to parent node
Port 2: Connected to child node
Init. reset: No

CSR ROM Info
------------
GUID: 0x0000000000000000
Node Capabilities: 0x00000000
Vendor ID: 0x00000000
Unit Spec ID: 0x00000000
Unit SW Version: 0x00000000
Model ID: 0x00000000
Nr. Textual Leafes: 0

Vendor: (null)
Textual Leafes:

AV/C Subunits
-------------
N/A

-------------------------------------------------------------

Clicking a second

" <question mark>
S400 Unknown":

----------------------------------------------------
SelfID Info
-----------
Physical ID: 0
Link active: Yes
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: No
Power Class: None
Port 0: Connected to parent node
Port 1: Not connected
Port 2: Not connected
Init. reset: No

CSR ROM Info
------------
GUID: 0x0000000000000000
Node Capabilities: 0x00000000
Vendor ID: 0x00000000
Unit Spec ID: 0x00000000
Unit SW Version: 0x00000000
Model ID: 0x00000000
Nr. Textual Leafes: 0

Vendor: (null)
Textual Leafes:

AV/C Subunits
-------------
N/A

---------------------------------------------------

Please, if you think it might help, let me know if want to change the scripts to load the ieee drivers ... (Note the disable_irm=0 in one of the scripts above .. )

Til then

Best Regards
Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Sorry, forgot that: After running gscanbus above, and a few minutes after sending the quoted message: still no /dev/sda

Regards
Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

More precise, IIRC, it should have said:

"Minutes after running gscanbus, that is a few minutes after sending the quoted message: still no /dev/sda"

Sorry for the overhead
Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

.. but this time with "modprobe ieee1394 disable_irm=1". 2 logs were be created:
www.wolfgangpfeiffer.com/disable-irm.kern.log.when.fw.disk.is.switched.on.txt www.wolfgangpfeiffer.com/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt

Because i hate to burden my lousy memory with what I did to produce the logs above, I scrambled together my admittedly marginal bash knowledge and ran the tests with 4 scripts to produce the logs.

All the following below is to give you control on how these logs were created. I'll try to be as verbose as possible. This because, as I already made clear, I'm anything else but a bash expert. And because I want to make sure the logs are not spoiled.

And please:

If you think the following is not necessary and instead only burdens everyone else's mail box with KB that are not needed please let me know ... :)

###########################################################
*** How
disable-irm.kern.log.when.fw.disk.is.switched.on.txt was made
###########################################################

First the main script I run to get disable-irm.kern.log.when.fw.disk.is.switched.on.txt

/home/shorty/scripts/ieee.test.sh:
------------------------------------------------
#!/bin/sh -x
/bin/sh -nv /home/shorty/scripts/ieee.test.sh; \
/home/shorty/scripts/scsi.stop.sh; \
/home/shorty/scripts/scsi.start.sh; \

sleep 2; \
/home/shorty/kernel-factory/git.060822/linux-2.6/scripts/ver_linux; \

cat /dev/null > /var/log/kern.log; \
echo "===> NOW SWITCH ON THE FW DISK <===="; \
sleep 70; \
ls /dev/sda*; \

if [ -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt ]; then
rm -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
else
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
fi

-------------------------------------------------

As you can see above 2 more scripts are (hopefully :) executed inside the latter script:

#1: /home/shorty/scripts/scsi.stop.sh:
-----------------------------------
#!/bin/sh -x
/bin/sh -n /home/shorty/scripts/scsi.stop.sh; \
rmmod raw1394; \
rmmod eth1394;
rmmod ohci1394; \
rmmod sbp2; \
rmmod ieee1394

---------------------------------------

and #2: /home/shorty/scripts/scsi.start.sh:
------------------------------------------
#!/bin/sh -x
/bin/sh -n /home/shorty/scripts/scsi.start.sh; \

modprobe ieee1394 disable_irm=1; \
sleep 2; \
modprobe ohci1394; \
sleep 2; \
modprobe sbp2; \
sleep 2; \
modprobe raw1394; \
sleep 2
chown root.shorty /dev/raw1394

--------------------------------------------

This is what the shell was saying when running ieee.test.sh:
-----------------------------------------------------------
[root@ 20:39:50]# /home/shorty/scripts/ieee.test.sh
+ /bin/sh -nv /home/shorty/scripts/ieee.test.sh #!/bin/sh -x
/bin/sh -nv /home/shorty/scripts/ieee.test.sh; \
/home/shorty/scripts/scsi.stop.sh; \
/home/shorty/scripts/scsi.start.sh; \

sleep 2; \
/home/shorty/kernel-factory/git.060822/linux-2.6/scripts/ver_linux; \

cat /dev/null > /var/log/kern.log; \
echo "===> NOW SWITCH ON THE FW DISK <===="; \
sleep 70; \
ls /dev/sda*; \

if [ -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt ]; t
hen
rm -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switc
hed.on.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switch
ed.on.txt
else
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switc
hed.on.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switc
hed.on.txt
fi

+ /home/shorty/scripts/scsi.stop.sh
+ /bin/sh -n /home/shorty/scripts/scsi.stop.sh
+ rmmod raw1394
ERROR: Module raw1394 does not exist in /proc/modules
+ rmmod eth1394
+ rmmod ohci1394
+ rmmod sbp2
+ rmmod ieee1394
+ /home/shorty/scripts/scsi.start.sh
+ /bin/sh -n /home/shorty/scripts/scsi.start.sh
+ modprobe ieee1394 disable_irm=1
+ sleep 2
+ modprobe ohci1394
+ sleep 2
+ modprobe sbp2
+ sleep 2
+ modprobe raw1394
+ sleep 2
+ chown root.shorty /dev/raw1394
+ sleep 2
+ /home/shorty/kernel-factory/git.060822/linux-2.6/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes.

Linux debby1-6 2.6.18-rc4-ieeeverbose-gef7d1b24-dirty #1 Tue Aug 22 22:18:50 CES T 2006 ppc GNU/Linux

Gnu C                  4.1.2
Gnu make               3.81
binutils               2.17
util-linux             2.12r
mount                  2.12r
module-init-tools      3.2.2
e2fsprogs              1.39
pcmcia-cs              3.2.8
Linux C Library        2.3.6
Dynamic linker (ldd)   2.3.6
Procps                 3.2.7
Net-tools              1.60
Console-tools          0.2.3
Sh-utils               5.97
udev                   097
Modules Loaded         raw1394 sbp2 eth1394 ohci1394 ieee1394 bluetooth radeon d

rm nfs nfsd exportfs lockd nfs_acl sunrpc ipv6 therm_adt746x sr_mod cpufreq_powe rsave cpufreq_performance scsi_mod apm_emu joydev appletouch snd_aoa_codec_onyx usbhid snd_aoa_fabric_layout snd_aoa pcmcia firmware_class snd_aoa_i2sbus snd_pc m_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc sungem sungem_phy pmac_zilo g serial_core snd ehci_hcd ide_cd evdev uninorth_agp agpgart i2c_powermac ohci_h cd yenta_socket rsrc_nonstatic pcmcia_core cdrom soundcore snd_aoa_soundbus usbc ore
+ cat /dev/null
+ echo '===> NOW SWITCH ON THE FW DISK <===='
===> NOW SWITCH ON THE FW DISK <====
+ sleep 70
+ ls '/dev/sda*'
ls: /dev/sda*: No such file or directory
+ '[' -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt ']'
+ rm -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
+ cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switche d.on.txt
+ chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched .on.txt
[root@ 20:42:36]#
------------------------------------------------------------

########################################################################
*** How
disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt was made
########################################################################

disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt covers one of at least 2 instances when I started gscanbus a few minutes after failing to connect the firewire disk to the alubook with the very first script, i.e. ieee.test.sh.
I turned on a bus reset from within gscanbus.

/home/shorty/scripts/ieee.test.with.gscanbus.sh:
-----------------------------------------------------
#!/bin/sh -x
/bin/sh -nv /home/shorty/scripts/ieee.test.with.gscanbus.sh; \

echo "====> NOW RUN gscanbus ... <====="; \
cat /dev/null > /var/log/kern.log; \
sleep 120; \
ls /dev/sda*; \

if [ -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt ]; then
rm -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
else
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
fi

---------------------------

Shell output when running ieee.test.with.gscanbus.sh:
-----------------------------------------

# /home/shorty/scripts/ieee.test.with.gscanbus.sh
+ /bin/sh -nv /home/shorty/scripts/ieee.test.with.gscanbus.sh
#!/bin/sh -x
/bin/sh -nv /home/shorty/scripts/ieee.test.with.gscanbus.sh; \

echo "====> NOW RUN gscanbus ... <====="; \
cat /dev/null > /var/log/kern.log; \
sleep 120; \
ls /dev/sda*; \

if [ -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connecti on.txt ]; then
rm -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connec
tion.txt
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.f
ailed.fw.connection.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.f
ailed.fw.connection.txt
else
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.f
ailed.fw.connection.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.f
ailed.fw.connection.txt
fi

+ echo '====> NOW RUN gscanbus ... <====='
====> NOW RUN gscanbus ... <=====
+ cat /dev/null
+ sleep 120
+ ls '/dev/sda*'
ls: /dev/sda*: No such file or directory
+ '[' -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connect ion.txt ']'
+ rm -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connecti on.txt
+ cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.fai led.fw.connection.txt
+ chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.fail ed.fw.connection.txt
[root@ 20:52:04]#
------------------------------------------

3 nodes inside the gscanbus window:

#1:
--------------------------
SelfID Info
-----------
Physical ID: 0
Link active: Yes
Gap Count: 63
PHY Speed: Unknown
PHY Delay: <=144ns
IRM Capable: No
Power Class: -1W
Port 0: Not connected
Port 1: Connected to parent node
Port 2: Not connected
Init. reset: Yes

CSR ROM Info
------------
GUID: 0x001451FFFE3148BE
Node Capabilities: 0x000083C0
Vendor ID: 0x00001451
Unit Spec ID: 0x0000005E
Unit SW Version: 0x00000001
Model ID: 0x00000000
Nr. Textual Leafes: 1

Vendor: Unknown
Textual Leafes:
Linux - ohci1394

AV/C Subunits
-------------
N/A

-------------------------

#2:
---------------------
SelfID Info
-----------
Physical ID: 1
Link active: Yes
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: No
Power Class: None
Port 0: Connected to parent node
Port 1: Not connected
Port 2: Not connected
Init. reset: No

CSR ROM Info
------------
GUID: 0x0000000000000000
Node Capabilities: 0x00000000
Vendor ID: 0x00000000
Unit Spec ID: 0x00000000
Unit SW Version: 0x00000000
Model ID: 0x00000000
Nr. Textual Leafes: 0

Vendor: (null)
Textual Leafes:

AV/C Subunits
-------------
N/A

-------------------------

#3
-----------------------------
SelfID Info
-----------
Physical ID: 2
Link active: No
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: No
Power Class: -1W
Port 0: Not connected
Port 1: Connected to child node
Port 2: Connected to child node
Init. reset: No

CSR ROM Info
------------
GUID: 0x0000000000000000
Node Capabilities: 0x00000000
Vendor ID: 0x00000000
Unit Spec ID: 0x00000000
Unit SW Version: 0x00000000
Model ID: 0x00000000
Nr. Textual Leafes: 0

Vendor: (null)
Textual Leafes:

AV/C Subunits
-------------
N/A

--------------------------------

And this was what the xterm was telling from where I ran gscanbus:
------------------------------------------

$ gscanbus
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000494: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000428: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff000042c: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000464: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
--------------------------------------------

HTH

Best Regards
Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Wolfgang Pfeiffer wrote:
...

...

Thanks, I will look at them as soon as I have my lookup table for the hex codes and the mental capacity available. :-) BTW, a convenient way to annotate the syslog is the command "logger". E.g.

$ logger "hello world"
$ ./hello_world 2>&1 | logger -t hi_world

Stefan Richter
-=====-=-==- =--- ==---
http://arcgraph.de/sr/

I'll keep that on my radar for the next time I could use 'logger' ... But after reading the - how do I say that without becoming offensive,
- err .. possibly slightly esoteric explanations in "man logger" I'm not that much enthusiastic to use the tool ... but let's see .. :)

Note: Please ignore most of the ugly explanations on how I created the logs for ieee1394 in my previous mail. Some should be nothing more than a reference if (and only if) the ieee logs I put on my home page don't help to debug the FW issue ...

Thanks

Best regards
Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Wolfgang Pfeiffer wrote on 2006-08-24:

Thanks for all the logs, and sorry for the delay.

What happens is that the ieee1394 base driver or gscanbus via raw1394 are able to read from the beginning of the ROM, but the disk's bridge does not send response packets anymore at some random point. In the first log, it happens at ROM offset ffff f000 0448, in the second at ffff f000 0414, in the third at ffff f000 042c, in the fourth at ffff f000 0494. The bridge still ack'ed the last attempted read requests with "ack_pending" like each previous successful read request, but suddenly it does not follow up with a response.

Unfortunately I cannot see how to cure the problem. There is no indication at all why the disk stops to respond at random points after the first chunks of the ROM were transferred OK. It is not extremely surprising; after all the Datafab's bridge is a pretty old one from before IEEE 1394a-2000. Nevertheless it should work OK with the 1394b-2002 PowerBook since the enclosure even has a 1394a-2000 PHY. I think I already mentioned that I have a similar pre-1394a CD-RW which works well on a 1394b card.

Alas I am out of ideas. Perhaps you should purchase a new enclosure. Before you do that, you could test the AluBook running Linux and TiBook in target disk mode again to exclude the possibility of problems at the AluBook's side. Use "hdparm -tT /dev/sda" to try a few actual block read operations. This should show about 20 MByte/s. It is a read-only test and therefore safe.

BTW, I saw one thing in your logs which you are certainly not interested in at all. :-) We seem to have an endianess bug in ohci1394.c::dma_rcv_tasklet's DBGMSG. My attempt to fix the printout of tlabels last year didn't get it completely right. http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dfe547ab872951949a1a2fcc5cedbedad27a2fe5
I think the cond_le32_to_cpu has to be omitted there.

Stefan Richter
-=====-=-==- =--= ---=-
http://arcgraph.de/sr/

Sorry to hear that ..

I'll be very careful before doing that: Yesterday I was at a computer shop downtown for a little test whether the FW 800 port could detect the enclosure. The service guy was really helpful, perhaps even interested when I explained the FW problem we have with this alubook. So we connected via a 9:6 (?) pin cable the enclosure to the FW800 of the alubook. To no avail.

He then proposed to connect the disk instead via the FW enclosure via a USB case. Didn't work, too. And this although any USB device (USB stick, a camera, mouse) I connected to the USB ports was detected correctly.

I do not have to mount /dev/sda for the test. Correct?

Not quite true :) ... The only frustrating thing for me is my lacking knowledge when it comes to understand code like the one on the kernel.org page below .. but I hope I find a way to change that situation .. :)

Please let me know if I can help with tests if you want to patch ohci1394.

And thanks for all your efforts; for your explanations, too, for my scsi.start.sh script in your email from Aug 19. It helped me a lot ...

Nice week-end

Best Regards
Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

[...]

That's right. This works on the block IO level, not via filesystem. It is not even necessary to detect any partitions to run this test. On the other hand, it is not very thorough because only about 50...100 MB will be read. (You could also read from sda with dd or the like.)

[...]

That's because it's extremely ugly code. Guess why it's buggy. :-) It's just a debug printk though.

[...]

Thanks, I will Cc you.

Stefan Richter
-=====-=-==- =--= ---==
http://arcgraph.de/sr/

OK, I did this test with the unmounted Tibook /dev/sda (target mode). So I executed the one-liners below on the alubook. /dev/sda should be the hard disk on the tibook:

####################################################

# /sbin/hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 1244 MB in 2.00 seconds = 620.49 MB/sec
Timing buffered disk reads: 34 MB in 3.02 seconds = 11.24 MB/sec
[root@ 01:21:02]# /sbin/hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 1232 MB in 2.00 seconds = 615.19 MB/sec
Timing buffered disk reads: 34 MB in 3.04 seconds = 11.17 MB/sec
[root@ 01:21:20]# /sbin/hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 1260 MB in 2.00 seconds = 628.93 MB/sec
Timing buffered disk reads: 36 MB in 3.07 seconds = 11.72 MB/sec
[root@ 01:21:35]#

##############################################################

Looks good, doesn't it?

Thanks again

Best Regards
Wolfgang

Wolfgang Pfeiffer: /ICQ: 286585973/ + + +  /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer

Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on

Wolfgang Pfeiffer wrote on :
...

...

...

...

Looks quite slow. I get 18 MB/s from a 20GB 2.5" HDD in an 1394a enclosure, on an 1394a adapter or same on an 1394b adapter. The HDD was actually taken out of a TiBook some time ago.

But I have no reference values of PowerBooks in target disk mode. This mode is probably not optimized for performance.

Stefan Richter
-=====-=-==- =--= --=--
http://arcgraph.de/sr/

[...]

This script doesn't work as you may expect.

"modprobe raw1394" pulls ieee1394 in. Therefore all the parameters you give to ieee1394 in the next line are ignored. If you want to run ieee1394 with non-default parameters, load it first before any other 1394 driver or put the parameters into /etc/modprobe.d/xyz or /etc/modprobe.conf.

"disable_nodemgr=1" will also enforce disable_irm=0 because some of the IRMs functionality requires the nodemgr kernel daemon.

The nodemgr is also the bridge between the 1394 bus and Linux' driver core. Some of the IEEE 1394 high-level drivers, including sbp2, don't find devices on their own but work on top of the driver core's device representations created by nodemgr. IOW sbp2 won't work with disable_nodemgr=1.

"modprobe eth1394" is not necessary if you have hotplug scripts. ieee1394 is, according to your log, configured to always adds an IP-over-1394 ROM entry to the local node's configuration ROM (it's actually RAM but works like ROM for other 1394 nodes), and there will be hotplug events generated for this entry as soon as the local node (driven by ohci1394) became operational.

(Similarly, sbp2 is usually loaded by hotplug scripts when an SBP-2 device was detected. But if you rely on hotplug, you would have of course to supply any non-default module parameters to sbp2 via /etc/modprobe.d/xyz or /etc/modprobe.conf.)

"max_speed=3" i.e. S800 is the default and will stay so for the time being. It doesn't seem like S1600 hardware (standardized by IEEE 1394b) or even S3200 hardware (not standardized yet) will ever become available.

"workarounds=1" or 0x1 isn't precisely the default. But there is also sbp2's parameter max_sectors whose default value of 255 means exactly the same as the bit 1 in the workarounds bit field. The bit 1 exists in the workarounds parameter only to fully reflect what can be stuffed into sbp2's hardcoded blacklist (or "whitelist" depending on the point of view).

"serialize_io=0" has always been --- and still is --- unsafe. I recently started work to make it safe but am not done yet. serialize_io=0 does work with many devices though (by fortunate circumstances rather than by principle) and gains a measurable but hardly noticeable throughput advantage with some devices, AFAIK especially with S800 devices.

However all my comments to your script do not relate to the problem you are seeing with

[...]

Here you are seeing proof for my comment on "modprobe raw1394": ieee1394 is up earlier than raw1394...

...and you are using it with irm and nodemgr enabled.

AFAIK:
Node 0-00:1023 is the enclosure's SYM13FW501 which seems to be a link layer controller with integrated minimal PHY. (Node IDs are associated with PHYs, not links.) Node 0-01:1023 is an extra PHY in the enclosure, the PHY that actually drives the cable port (ports?). This is the TSB41LV03A on the bridge board. To take up two nodes, i.e. show the presence of two daisy-chained PHYs to the bus instead of one PHY, is apparently a property of some or all bridge boards with the old Symbios SBP-2 controller.

Node 0-02:1023 is of course the fw-host0.

"Error parsing configrom" often means that ieee1394 was unable to read anything from a devices ROM in the first place. This is often a normal condition for SBP-2 devices until their attached drive is fully operational. They then send a bus reset and publish a proper ROM, ieee1394 reads it, and Linux' driver core attaches the sbp2 driver as the matching protocol driver to it.

What if you force a bus reset about 5 seconds or more later, using gscanbus or 1394commander? Would ieee1349 detect the disk's SBP-2 capability?

What if you load ieee1394 with disable_irm=1? (Before raw1394 of course.) Nodemgr takes care to run the IRM code in a very non-intrusive manner in newer Linux releases, but there is still the "selecting a new root node and resetting" routine which can't be avoided by an IRM that wants to be fully compliant to the specs.

These two "Adding info for..." are of course related to the host adapter. The first one is the fw-host0 itself and the second one the ip1394 a.k.a. RFC 2734 unit that ieee1394 added to it (and eth1394 was bound to). 0x001451 is Apple's OUI.

[...]

[...]

This is the TSB41LV03A.

[...]

There should be a third node, i.e. the node with physical ID 0 == the child node of the TSB41LV03A's node. Doesn't show gscanbus anything about that node? I expect that you at least see an icon and SelfID info. CSR ROM info might be missing; although the fact that ieee1394 failed to read the ROM doesn't mean that gscanbus will be unable to do so.

Stefan Richter
-=====-=-==- =--- =--==
http://arcgraph.de/sr/