Broken Firewire 400/SCSI on ppc Powerbook5,8

Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Bill Fink]

Hi Wolfgang,

On Fri, 18 Aug 2006, Wolfgang Pfeiffer wrote:

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

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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

Hi Bill

Thanks for responding

On Fri, Aug 18, 2006 at 01:28:24AM -0400, Bill Fink wrote:
> Hi Wolfgang,
> 
> On Fri, 18 Aug 2006, Wolfgang Pfeiffer wrote:
> 
> [ ... ]
> > 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
> > -------------------------------------------
> 
> 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.


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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

On Fri, Aug 18, 2006 at 01:03:47AM +0200, Wolfgang Pfeiffer wrote:
> 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.
> 

   [ ... ]

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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Stefan Richter]

Wolfgang Pfeiffer wrote:
> 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.

[...]
> #!/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

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

[...]
> 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

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

> 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

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

> 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

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.

[...]
> And gscanbus says this for:
> "Unknown
> Linux - ohci1394":
> 
> --------------------------
> SelfID Info
> -----------
> Physical ID: 2
[...]
> And this for "S400 unknown":
> 
> ---------------------------------
> SelfID Info
> -----------
> Physical ID: 1
> Link active: No

This is the TSB41LV03A.

> 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
[...]

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/

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Stefan Richter]

Wolfgang Pfeiffer wrote:
>> 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.
>    [ ... ]
> 
> 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?]

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.

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

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/

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Stefan Richter]

Bill Fink wrote:
...
> on my desktop PowerMac systems, I need a "sleep 2"
> before the modprobe for sbp2, to get my Firewire disks to work
> properly.

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/

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Bill Fink]

On Sat, 19 Aug 2006, Stefan Richter wrote:

> Bill Fink wrote:
> ...
> > on my desktop PowerMac systems, I need a "sleep 2"
> > before the modprobe for sbp2, to get my Firewire disks to work
> > properly.
> 
> 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.)

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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

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:


                        [ ... ]
> 
> 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.

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

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

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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

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

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

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.


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

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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

On Mon, Aug 21, 2006 at 02:29:21AM +0200, Wolfgang Pfeiffer wrote:

> Note: About 2 days ago I had, IIRC, ext2fsx

wrong: I had ext2fsx_dev installed, IIRC.

> (http://sourceforge.net/project/showfiles.php?group_id=64713) shortly
> installed on OSX - I quickly uninstalled it afterwards, [ ... ]


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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Stefan Richter]

Wolfgang Pfeiffer wrote:
[...]
> 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.

Yes, the port is certainly working correctly.

> OTOH: Connecting the alubook and tibook with Linux up and running on
> both machines did not create a working (FW) connection between them ..

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.

[...]
> 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 ...

It can only be configured at compile time.
-- 
Stefan Richter
-=====-=-==- =--- =-=-=
http://arcgraph.de/sr/

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Stefan Richter]

Bill Fink wrote:
>> > on my desktop PowerMac systems, I need a "sleep 2"
>> > before the modprobe for sbp2, to get my Firewire disks to work
>> > properly.
[...]
> 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:
[...]
> 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:
[...]

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/

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

Hi Stefan,
Hi All

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

          [ ... ]

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

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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

On Wed, Aug 23, 2006 at 02:28:01AM +0200, Wolfgang Pfeiffer 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 
> 
>   [ ..... ]
> 
> 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


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

[Correction #2] Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

On Wed, Aug 23, 2006 at 02:36:38AM +0200, Wolfgang Pfeiffer wrote:
> On Wed, Aug 23, 2006 at 02:28:01AM +0200, Wolfgang Pfeiffer wrote:
> 
> > [ ... ]
> 
> > Some tests on the Alubook:
> > 
> > I compiled a fresh git kernel now with verbose ieee logging turned on.

> > 
> >   [ ..... ]
> > 
> > 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
> 
> 
> Sorry, forgot that: After running gscanbus above, and a few minutes after
> sending the quoted message: still no /dev/sda


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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

On Wed, Aug 23, 2006 at 02:28:01AM +0200, Wolfgang Pfeiffer wrote:
> 
> Hi Stefan,
> Hi All
> 
> On Sat, Aug 19, 2006 at 11:13:24AM +0200, Stefan Richter wrote:
> 
>           [ ... ]
> 
> > 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.
> 
> Some tests on the Alubook:


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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Stefan Richter]

Wolfgang Pfeiffer wrote:
...
> 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.
...

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/

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

On Thu, Aug 24, 2006 at 09:43:47PM +0200, Stefan Richter wrote:
> Wolfgang Pfeiffer wrote:
> ...
> >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.
> ...
> 
> 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

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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Stefan Richter]

Wolfgang Pfeiffer wrote on 2006-08-24:
> On Wed, Aug 23, 2006 at 02:28:01AM +0200, Wolfgang Pfeiffer wrote:
>> Some tests on the Alubook:
> 
> 
> .. 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

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/

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

On Sat, Sep 02, 2006 at 09:18:07PM +0200, Stefan Richter wrote:
> Wolfgang Pfeiffer wrote on 2006-08-24:
> >On Wed, Aug 23, 2006 at 02:28:01AM +0200, Wolfgang Pfeiffer wrote:
> >>Some tests on the Alubook:
> >
> >
> >.. 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
> 
> 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. 

Sorry to hear that .. 

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

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

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

> 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. :-) 

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 .. :)


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


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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Wolfgang Pfeiffer]

On Sat, Sep 02, 2006 at 09:18:07PM +0200, Stefan Richter wrote:
> 
> 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.

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

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Stefan Richter]

Wolfgang Pfeiffer wrote:
> On Sat, Sep 02, 2006 at 09:18:07PM +0200, Stefan Richter wrote:
[...]
>> 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. 
> 
> I do not have to mount /dev/sda for the test. Correct? 

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

[...]
> 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 ..

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

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

Thanks, I will Cc you.
-- 
Stefan Richter
-=====-=-==- =--= ---==
http://arcgraph.de/sr/

Re: Broken Firewire 400/SCSI on ppc Powerbook5,8

[Stefan Richter]

Wolfgang Pfeiffer wrote on :
...
> # /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
...
>  Timing buffered disk reads:   34 MB in  3.04 seconds =  11.17 MB/sec
...
>  Timing buffered disk reads:   36 MB in  3.07 seconds =  11.72 MB/sec
...

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/