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

On Sat, Sep 02, 2006 at 09:18:07PM +0200, Stefan Richter wrote:

Wolfgang Pfeiffer wrote on 2006-08-24:

quoted

On Wed, Aug 23, 2006 at 02:28:01AM +0200, Wolfgang Pfeiffer wrote:

quoted

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