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