* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-08-19 9:13 ` Stefan Richter
@ 2006-08-20 1:31 ` Wolfgang Pfeiffer
2006-08-21 7:56 ` Stefan Richter
2006-08-21 0:29 ` Wolfgang Pfeiffer
2006-08-23 0:28 ` Wolfgang Pfeiffer
2 siblings, 1 reply; 24+ messages in thread
From: Wolfgang Pfeiffer @ 2006-08-20 1:31 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux1394-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-08-20 1:31 ` Wolfgang Pfeiffer
@ 2006-08-21 7:56 ` Stefan Richter
0 siblings, 0 replies; 24+ messages in thread
From: Stefan Richter @ 2006-08-21 7:56 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, linux1394-devel
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/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-08-19 9:13 ` Stefan Richter
2006-08-20 1:31 ` Wolfgang Pfeiffer
@ 2006-08-21 0:29 ` Wolfgang Pfeiffer
2006-08-21 0:40 ` Wolfgang Pfeiffer
2006-08-23 0:28 ` Wolfgang Pfeiffer
2 siblings, 1 reply; 24+ messages in thread
From: Wolfgang Pfeiffer @ 2006-08-21 0:29 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux1394-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-08-21 0:29 ` Wolfgang Pfeiffer
@ 2006-08-21 0:40 ` Wolfgang Pfeiffer
0 siblings, 0 replies; 24+ messages in thread
From: Wolfgang Pfeiffer @ 2006-08-21 0:40 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux1394-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-08-19 9:13 ` Stefan Richter
2006-08-20 1:31 ` Wolfgang Pfeiffer
2006-08-21 0:29 ` Wolfgang Pfeiffer
@ 2006-08-23 0:28 ` Wolfgang Pfeiffer
2006-08-23 0:36 ` Wolfgang Pfeiffer
2006-08-24 19:22 ` Wolfgang Pfeiffer
2 siblings, 2 replies; 24+ messages in thread
From: Wolfgang Pfeiffer @ 2006-08-23 0:28 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-08-23 0:28 ` Wolfgang Pfeiffer
@ 2006-08-23 0:36 ` Wolfgang Pfeiffer
2006-08-23 1:50 ` [Correction #2] " Wolfgang Pfeiffer
2006-08-24 19:22 ` Wolfgang Pfeiffer
1 sibling, 1 reply; 24+ messages in thread
From: Wolfgang Pfeiffer @ 2006-08-23 0:36 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Correction #2] Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-08-23 0:36 ` Wolfgang Pfeiffer
@ 2006-08-23 1:50 ` Wolfgang Pfeiffer
0 siblings, 0 replies; 24+ messages in thread
From: Wolfgang Pfeiffer @ 2006-08-23 1:50 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-08-23 0:28 ` Wolfgang Pfeiffer
2006-08-23 0:36 ` Wolfgang Pfeiffer
@ 2006-08-24 19:22 ` Wolfgang Pfeiffer
2006-08-24 19:43 ` Stefan Richter
2006-09-02 19:18 ` Stefan Richter
1 sibling, 2 replies; 24+ messages in thread
From: Wolfgang Pfeiffer @ 2006-08-24 19:22 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-08-24 19:22 ` Wolfgang Pfeiffer
@ 2006-08-24 19:43 ` Stefan Richter
2006-08-24 22:56 ` Wolfgang Pfeiffer
2006-09-02 19:18 ` Stefan Richter
1 sibling, 1 reply; 24+ messages in thread
From: Stefan Richter @ 2006-08-24 19:43 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, billfink, linux1394-devel
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/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-08-24 19:43 ` Stefan Richter
@ 2006-08-24 22:56 ` Wolfgang Pfeiffer
0 siblings, 0 replies; 24+ messages in thread
From: Wolfgang Pfeiffer @ 2006-08-24 22:56 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-08-24 19:22 ` Wolfgang Pfeiffer
2006-08-24 19:43 ` Stefan Richter
@ 2006-09-02 19:18 ` Stefan Richter
2006-09-02 23:08 ` Wolfgang Pfeiffer
2006-09-02 23:26 ` Wolfgang Pfeiffer
1 sibling, 2 replies; 24+ messages in thread
From: Stefan Richter @ 2006-09-02 19:18 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, billfink, linux1394-devel
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/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-09-02 19:18 ` Stefan Richter
@ 2006-09-02 23:08 ` Wolfgang Pfeiffer
2006-09-02 23:28 ` Stefan Richter
2006-09-02 23:26 ` Wolfgang Pfeiffer
1 sibling, 1 reply; 24+ messages in thread
From: Wolfgang Pfeiffer @ 2006-09-02 23:08 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-09-02 23:08 ` Wolfgang Pfeiffer
@ 2006-09-02 23:28 ` Stefan Richter
0 siblings, 0 replies; 24+ messages in thread
From: Stefan Richter @ 2006-09-02 23:28 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, billfink, linux1394-devel
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/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-09-02 19:18 ` Stefan Richter
2006-09-02 23:08 ` Wolfgang Pfeiffer
@ 2006-09-02 23:26 ` Wolfgang Pfeiffer
2006-09-04 16:58 ` Stefan Richter
1 sibling, 1 reply; 24+ messages in thread
From: Wolfgang Pfeiffer @ 2006-09-02 23:26 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
2006-09-02 23:26 ` Wolfgang Pfeiffer
@ 2006-09-04 16:58 ` Stefan Richter
0 siblings, 0 replies; 24+ messages in thread
From: Stefan Richter @ 2006-09-04 16:58 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, billfink, linux1394-devel
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/
^ permalink raw reply [flat|nested] 24+ messages in thread