Hello,
Sorry for keeping you waiting.
> Well. I have been experimenting and a Firewire CD-R/W is found and
> accessible. However, a 80 Gb Maxtor hard disk is not. I had to
> copy from an RS-232C screen because the resounding crash(es) repeat
> forever until I hit the reset switch. <EOL> == "end of line with
> data missing after".
>
>
> ohci1394: $Revision: 1.80 $ Ben Collins <[email protected]>
Gulp, you should really be using a more recent copy of that driver. I'm
running 1.91 from the CVS and I remember having had problems with the
1.80 driver series too. I don't know why the ieee1394 tree is not pushed
into the mainline kernel ...
Download the subversion client [1] and then follow the rest of the
procedure on that page. Could you try and checkout the newest tree and
simply replace the ieee1394 tree with the CVS one. You should probably
also switch to a more recent 2.4.x tree since IIRC the .19 series has
some changes to the scsi (emulation) subsystem.
> ohci1394_0: OHCI-1394 1.0 (PCI): IRQ=[9] MMIO=[febfd000-febfe000] Max
> Packet=[ <EOL>
> ieee1394: Device added: Node 0:1023, GUID 00063a0245003973
> ieee1394: sbp2: Driver forced to serialize I/O (serialize_io = 1)
> ieee1394: sbp2: Node 0:1023: Max speed [S400] - Max payload [1024]
> scsi2 : IEEE-1394 SBP-2 protocol driver
> scsi: unknown type 24
> Vendor: GHIJKLMN Model: OPQRSTUVWXYZ Rev: "Unprintable junk"
> Type: Unknown ANSI SCSI revision: 03
> resize_dma_pool: unknown device type 24
>
>
> Startup messages continue without further references to either SCSI
> or IEEE1394. The crash occurs when my SCSI root-file system is first
> referenced after initrd completes (pivot_root).
>
> When this 80 Gb drive is used under W$, on the same machine, I see
> no evidence of "GHIJKLMN" or "OPQRSTUVWXYZ" although the device-manager
> doesn't let you read physical device info like it does with SCSI.
>
> Number 24, shown above, is ^X, not part of the obvious
> "ABCDEFGHIJKLMNOPQRSTUVWXYZ" string that we see parts of above. So
> it doesn't look like a read from the wrong offset during the device-
> inquiry.
>
>
> I'm using Linux-2.4.18. Maybe there is a more "mature" version
> of sbp2 I should be using??
Could you try with the latest 2.4.19preX tree and also replace the
../drivers/ieee1394 with the CVS one?
[1] http://linux1394.sourceforge.net/svn.html
Best regards,
Roberto Nibali, ratz
p.s.: You have to hurry up, since I'm not online very often the next few
weeks. Of course you could also show up at OLS with the disk ;).
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
On Mon, 17 Jun 2002, Roberto Nibali wrote:
[SNIPPED...]
>
> Could you try with the latest 2.4.19preX tree and also replace the
> ../drivers/ieee1394 with the CVS one?
>
> [1] http://linux1394.sourceforge.net/svn.html
>
> Best regards,
> Roberto Nibali, ratz
>
> p.s.: You have to hurry up, since I'm not online very often the next few
> weeks. Of course you could also show up at OLS with the disk ;).
Okay. I did that now. However, `depmod -ae` shows some unresolved
symbols:
depmod: *** Unresolved symbols in /lib/modules/2.4.18/kernel/drivers
/ieee1394/pcilynx.o
depmod: i2c_transfer
depmod: i2c_bit_del_bus
depmod: i2c_bit_add_bus
Since I don't use this module, maybe I am "home-free" I need to try
this on my system at home since my firewire stuff is there.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
On Mon, 17 Jun 2002, Richard B. Johnson wrote:
> On Mon, 17 Jun 2002, Roberto Nibali wrote:
> [SNIPPED...]
>
> >
> > Could you try with the latest 2.4.19preX tree and also replace the
> > ../drivers/ieee1394 with the CVS one?
> >
> > [1] http://linux1394.sourceforge.net/svn.html
> >
> > Best regards,
> > Roberto Nibali, ratz
> >
> > p.s.: You have to hurry up, since I'm not online very often the next few
> > weeks. Of course you could also show up at OLS with the disk ;).
>
> Okay. I did that now. However, `depmod -ae` shows some unresolved
> symbols:
>
[SNIPPED...]
Okay. I tried the ieee1394-508.tar.gz tar-ball at home, replacing
../linux/drivers/ieee1394 directory contents of Linux version 2.4.18.
I have sbp2.o inserted by initrd. It initializes, but doesn't find
any devices. If, once the machine is up, I remove the module and then
re-install it, it finds the two devices that I have on the Firewire.
I have been able to make an e2fs file-system on the 80 Gb drive.
I can also create a large file on the drive. But... The following
will lock up... `cp /dev/sdd /dev/null`, the raw device being /dev/sdd.
The disk drive light comes on, then stays on forever. I get error
messages about "resetting the drive", and I can't get control from
any terminal. If I power off the drive, then power it back on, the
process reading from the drive, enters the 'D' state (forever), but
I can get control from another virtual terminal and reboot the machine.
There is something, probably in SCSI, that won't allow the root file-
system to be unmounted so there is a long fsck upon reboot.
Anyway. I have a setup at home that can be used to test anything.
I think the hangup comes from the raw-read length being greater
than the "payload", but I'm not sure.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.