Firewire Disks. (fwd)

Firewire Disks. (fwd)

[Richard B. Johnson]

---------- Forwarded message ----------
From: "Richard B. Johnson" <root@chaos.analogic.com>
Subject: Firewire Disks.

I know there is support for "firewire" in the kernel. Is there
support for "firewire" disks? If so, how do I enable it?

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Firewire Disks. (fwd)

[Ben Collins]

On Mon, Jun 10, 2002 at 02:11:21PM -0400, Richard B. Johnson wrote:
> 
> 
> ---------- Forwarded message ----------
> From: "Richard B. Johnson" <root@chaos.analogic.com>
> Subject: Firewire Disks.
> 
> I know there is support for "firewire" in the kernel. Is there
> support for "firewire" disks? If so, how do I enable it?
> 
> Cheers,
> Dick Johnson

Compile and/or install the sbp2 module.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: Firewire Disks. (fwd)

[Richard B. Johnson]

On Mon, 10 Jun 2002, Ben Collins wrote:

> On Mon, Jun 10, 2002 at 02:11:21PM -0400, Richard B. Johnson wrote:
> > 
> > 
> > ---------- Forwarded message ----------
> > From: "Richard B. Johnson" <root@chaos.analogic.com>
> > Subject: Firewire Disks.
> > 
> > I know there is support for "firewire" in the kernel. Is there
> > support for "firewire" disks? If so, how do I enable it?
> > 
> > Cheers,
> > Dick Johnson
> 
> Compile and/or install the sbp2 module.
> 

Okay, thanks.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Firewire Disks. (fwd)

[Richard B. Johnson]

On Mon, 10 Jun 2002, Ben Collins wrote:

> On Mon, Jun 10, 2002 at 02:11:21PM -0400, Richard B. Johnson wrote:
> > 
> > 
> > ---------- Forwarded message ----------
> > From: "Richard B. Johnson" <root@chaos.analogic.com>
> > Subject: Firewire Disks.
> > 
> > I know there is support for "firewire" in the kernel. Is there
> > support for "firewire" disks? If so, how do I enable it?
> > 
> > Cheers,
> > Dick Johnson
> 
> Compile and/or install the sbp2 module.
> 

Okay. I did that. It doesn't work as for a 80 Gb hard disk, but
it works for a CD-R/W.


More follows..........

On Mon, 10 Jun 2002, Roberto Nibali wrote:

> Hi,
> 
> > I know there is support for "firewire" in the kernel. Is there
> > support for "firewire" disks? If so, how do I enable it?
> 
> Yes, there is and it is attached to the SCSI layer via the sbp2 driver. 
> You need following set of modules to get it working:
> 
> scsi_mod, sd_mod, ohci1394, raw1394, ieee1394, sbp2
> 
> I know that you will find out which options you need to enable in the 
> kernel config ;).
> 
> You might want to check out the CVS version of the ieee1394 drivers but 
> I don't think it is necessary. It works perfectly back here with a 
> Maxtor 160GB. Funny enough I had 158GB with the VFAT on it and 152GB 
> with ext2/ext3.
> 
> The speed results were also quite interessing:
> 
> VFAT writing     : 12.8 Mbyte/s
> ext2/ext3 writing: 19.2 Mbyte/s
> 
> I simply like that disk and it's a nice extension for a laptop :).
> 
> Cheers,
> Roberto Nibali, ratz


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 <bcollins@debian.org>
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??


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Firewire Disks. (fwd)

[Ben Collins]

On Mon, Jun 17, 2002 at 12:46:00PM -0400, Richard B. Johnson wrote:
> On Mon, 10 Jun 2002, Ben Collins wrote:
> 
> > On Mon, Jun 10, 2002 at 02:11:21PM -0400, Richard B. Johnson wrote:
> > > 
> > > 
> > > ---------- Forwarded message ----------
> > > From: "Richard B. Johnson" <root@chaos.analogic.com>
> > > Subject: Firewire Disks.
> > > 
> > > I know there is support for "firewire" in the kernel. Is there
> > > support for "firewire" disks? If so, how do I enable it?
> > > 
> > > Cheers,
> > > Dick Johnson
> > 
> > Compile and/or install the sbp2 module.
> > 
> 
> Okay. I did that. It doesn't work as for a 80 Gb hard disk, but
> it works for a CD-R/W.

You are using old drivers. The oddities with the newer SBP-2 drives has
been fixed in later 2.4.19-pre kernels, aswell as the source from our
subversion repository. You can get a tarball of the repo from here:

http://svn.debian.org/linux1394/tarballs/

Move drivers/ieee1394/ out of the way, and unpack that (still requires a
2.4.19-pre kernel though).

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: Firewire Disks. (fwd)

[Roberto Nibali]

Hi,

> I know there is support for "firewire" in the kernel. Is there
> support for "firewire" disks? If so, how do I enable it?

Yes, there is and it is attached to the SCSI layer via the sbp2 driver. 
You need following set of modules to get it working:

scsi_mod, sd_mod, ohci1394, raw1394, ieee1394, sbp2

I know that you will find out which options you need to enable in the 
kernel config ;).

You might want to check out the CVS version of the ieee1394 drivers but 
I don't think it is necessary. It works perfectly back here with a 
Maxtor 160GB. Funny enough I had 158GB with the VFAT on it and 152GB 
with ext2/ext3.

The speed results were also quite interessing:

VFAT writing     : 12.8 Mbyte/s
ext2/ext3 writing: 19.2 Mbyte/s

I simply like that disk and it's a nice extension for a laptop :).

Cheers,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

Re: Firewire Disks. (fwd)

[Andre Bonin]

Roberto Nibali wrote:
> Hi,
> 
>> I know there is support for "firewire" in the kernel. Is there
>> support for "firewire" disks? If so, how do I enable it?
> 
> 
> Yes, there is and it is attached to the SCSI layer via the sbp2 driver. 
> You need following set of modules to get it working:
> 
> scsi_mod, sd_mod, ohci1394, raw1394, ieee1394, sbp2

A lot of caddies that wrap hd's have started coming out and, as you may 
know, USB 2.0 supports 480mbps x-fer rate (ideal).  So it's pretty 
intreguing.

Does the SCSI layer via sbp2 provide functionality for USB 2.0 (EHCI) 
disks?

Re: Firewire Disks. (fwd)

[Erik Andersen]

On Mon Jun 10, 2002 at 02:59:16PM -0400, Andre Bonin wrote:
> A lot of caddies that wrap hd's have started coming out and, as you may 
> know, USB 2.0 supports 480mbps x-fer rate (ideal).  So it's pretty 
> intreguing.

The 480mbps ideal is more like 240 in practice....

> Does the SCSI layer via sbp2 provide functionality for USB 2.0 (EHCI) 
> disks?

USB 2.0 mass storage devices are a horse of an entirely 
different color....

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Firewire Disks. (fwd)

[Greg KH]

On Mon, Jun 10, 2002 at 02:59:16PM -0400, Andre Bonin wrote:
> 
> Does the SCSI layer via sbp2 provide functionality for USB 2.0 (EHCI) 
> disks?

Yes, but it's supported by the usb-storage driver, not the ieee1394
driver :)

greg k-h

Re: Firewire Disks. (fwd)

[Roberto Nibali]

Hello,

> A lot of caddies that wrap hd's have started coming out and, as you may 
> know, USB 2.0 supports 480mbps x-fer rate (ideal).  So it's pretty 
> intreguing.

Yeah, I know but ieee1394 with 400Mbps is fast enough for my laptop and 
honestly I doubt that either one, be it USB2.0 or ieee1394, can really 
sustain this high transfer rate for a reasonable amount of time. And for 
most applications it is simply not needed. Maybe if you do TCP/IP over 
those technologies. But YMMV and I accept that. For me it was the 
cheapest alternative (450 bucks) to buying another harddisk for my laptop.

> Does the SCSI layer via sbp2 provide functionality for USB 2.0 (EHCI) 
> disks?

Please read the first 150 lines of [1]. If you want USB2.0 (wrapped) 
devices support you need to check out [2]. It's a 'glue' with the SCSI 
subsystem, but Greg KH can tell you much more about it.

[1] ../linux/drivers/ieee1394/sbp2.c
[2] ../linux/drivers/usb/storage/*, specially transport.c

Best regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

Re: Firewire Disks. (fwd)

[Richard B. Johnson]

On Mon, 10 Jun 2002, Roberto Nibali wrote:

> Hi,
> 
> > I know there is support for "firewire" in the kernel. Is there
> > support for "firewire" disks? If so, how do I enable it?
> 
> Yes, there is and it is attached to the SCSI layer via the sbp2 driver. 
> You need following set of modules to get it working:
> 
> scsi_mod, sd_mod, ohci1394, raw1394, ieee1394, sbp2
> 
> I know that you will find out which options you need to enable in the 
> kernel config ;).
> 
> You might want to check out the CVS version of the ieee1394 drivers but 
> I don't think it is necessary. It works perfectly back here with a 
> Maxtor 160GB. Funny enough I had 158GB with the VFAT on it and 152GB 
> with ext2/ext3.
> 
> The speed results were also quite interessing:
> 
> VFAT writing     : 12.8 Mbyte/s
> ext2/ext3 writing: 19.2 Mbyte/s
> 
> I simply like that disk and it's a nice extension for a laptop :).
> 
> Cheers,
> Roberto Nibali, ratz
> -- 

The firewire stuff apparently doesn't work too well on linux-2.4.18
I have 3 SCSI disks plus a SCSI CD-R/W. The Adaptec Firewire controller
has a 80 gig disk plus another CD-R/W attached. Both of these run fine
(but slow) in W$.


When I `insmod sbp2.o`, I get a signon message showing two CD-R/W drives,
and no Disk. I can't find any 'devices' to access or mount. I thought,
maybe, that the CD-R/W should show up as the next SCSI CD-R/W, i.e.,
/dev/scd1. If I do `od -x /dev/sdc1` (to see if its readable), the
machine panics. The panic isn't anything that can be copied as it scrolls
for about 10 seconds and end up with:

	code : : : : : : : : :

	(not too useful).  Nothing gets written to the root file-system,
not even the signon-message when I inserted the module.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Firewire Disks. (fwd)

[Gerald Britton]

On Thu, Jun 13, 2002 at 08:48:53AM -0400, Richard B. Johnson wrote:
> The firewire stuff apparently doesn't work too well on linux-2.4.18
> I have 3 SCSI disks plus a SCSI CD-R/W. The Adaptec Firewire controller
> has a 80 gig disk plus another CD-R/W attached. Both of these run fine
> (but slow) in W$.

The version in the kernel always crashed on me.  I've been having very good
success with the CVS versions at linux1394.sf.net though.  Only problems I've
been having are with leaving the kernel modules loaded (no 1394 hardware left
installed though) during a laptop suspend.. keyboard wasn't working on resume.
The disk and dvd+rw drive i have have worked flawlessly with the sbp2 driver
though.  And they do appear as normal scsi devices (they're announced when
the sbp2 driver loads, if you insert something later or remove something, you
have to do the scsi-add-single-device trick to rescan devices).

				-- Gerald

Re: Firewire Disks. (fwd)

[Richard B. Johnson]

On Mon, 10 Jun 2002, Roberto Nibali wrote:

> Hi,
> 
> > I know there is support for "firewire" in the kernel. Is there
> > support for "firewire" disks? If so, how do I enable it?
> 
> Yes, there is and it is attached to the SCSI layer via the sbp2 driver. 
> You need following set of modules to get it working:
> 
> scsi_mod, sd_mod, ohci1394, raw1394, ieee1394, sbp2
> 
> I know that you will find out which options you need to enable in the 
> kernel config ;).
> 
> You might want to check out the CVS version of the ieee1394 drivers but 
> I don't think it is necessary. It works perfectly back here with a 
> Maxtor 160GB. Funny enough I had 158GB with the VFAT on it and 152GB 
> with ext2/ext3.
> 
> The speed results were also quite interessing:
> 
> VFAT writing     : 12.8 Mbyte/s
> ext2/ext3 writing: 19.2 Mbyte/s
> 
> I simply like that disk and it's a nice extension for a laptop :).
> 
> Cheers,
> Roberto Nibali, ratz

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 <bcollins@debian.org>
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??


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Firewire Disks. (fwd)

[Roberto Nibali]

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 <bcollins@debian.org>

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

Re: Firewire Disks. (fwd)

[Richard B. Johnson]

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.

Re: Firewire Disks. (fwd)

[Richard B. Johnson]

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.

Re: Firewire Disks. (fwd)

[Roberto Nibali]

Hi,

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

Ever tried to find the attached devices with rescan-scsi-bus.sh [1]?

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

Could you try with the latest 2.4.19pre tree, please? I remember some 
scsi related fixes from Alan and some other which went into that tree. 
Besides that the 2.4.18 is _really_ old with regard to certain subsystems.

> 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

I reckon some sbp2 problem together with the currect scsi interface. If 
you can, you should try it with a 2.4.19pre tree even if it is simply to 
show people that something is still heavily broken and to have a decent 
starting point for debugging purposes.

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

Always enable SysRq for such test cases, so you can at least emergency 
sync and remount,ro.

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

I don't know either, we might also need an ieee1394 specialist to solve 
that problem, but only after you tested it with a more recent kernel 
tree ;).

[1] http://www.garloff.de/kurt/linux/rescan-scsi-bus.sh

Best regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

Re: Firewire Disks. (fwd)

[Richard B. Johnson]

On Wed, 19 Jun 2002, Roberto Nibali wrote:

> Hi,
> 
> > 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.
> 
> Ever tried to find the attached devices with rescan-scsi-bus.sh [1]?
> 

No because I don't have such a script at home and it didn't come
with the distribution.


> > 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.
> 
> Could you try with the latest 2.4.19pre tree, please? I remember some 
> scsi related fixes from Alan and some other which went into that tree. 
> Besides that the 2.4.18 is _really_ old with regard to certain subsystems.
> 

I will try 2.4.19pre, but I have had many problems with kernels later
than 2.4.18 and sort of "gave up". Changes have been made that prevented
even booting SMP Pentium II machines. Maybe things have been fixed.

> > 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
> 
> I reckon some sbp2 problem together with the currect scsi interface. If 
> you can, you should try it with a 2.4.19pre tree even if it is simply to 
> show people that something is still heavily broken and to have a decent 
> starting point for debugging purposes.

Okay. I will try to build a later kernel today. What I have to do
is download a tarball, put it on a CD-ROM, then extract it at home.
Telco removed ISDN capability at home so I'm back to 56kb unless I
want to buy an expensive cable-modem service. That's what happens
when the 'phone company' is the cable company.

> 
> > 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.
> 
> Always enable SysRq for such test cases, so you can at least emergency 
> sync and remount,ro.

It is enabled, but it requires interrupts to work. Something was spinning
inside some spin-lock somewhere or had gone off into hyper-space with
the keyboard interrupt disabled. Also, if SCSI won't allow writes to
the disks, it's beyond me how you can complete a dismount if you
can't write to the disk(s).

> 
> > 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.
> 
> I don't know either, we might also need an ieee1394 specialist to solve 
> that problem, but only after you tested it with a more recent kernel 
> tree ;).
> 
> [1] http://www.garloff.de/kurt/linux/rescan-scsi-bus.sh
> 

I will grab this.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Firewire Disks. (fwd)

[Douglas Gilbert]

Andre Bonin wrote:
>Roberto Nibali wrote:
>>> I know there is support for "firewire" in the kernel. Is there
>>> support for "firewire" disks? If so, how do I enable it?
>> 
>> 
>> Yes, there is and it is attached to the SCSI layer via the sbp2 driver. 
>> You need following set of modules to get it working:
>> 
>> scsi_mod, sd_mod, ohci1394, raw1394, ieee1394, sbp2
>
>A lot of caddies that wrap hd's have started coming out and, as you may 
>know, USB 2.0 supports 480mbps x-fer rate (ideal).  So it's pretty 
>intreguing.
>
>Does the SCSI layer via sbp2 provide functionality for USB 2.0 (EHCI) 
>disks?

Yes, disks using USB (2.0 or 1.x) and ieee1394 protocols appear
as scsi disks in linux. Prompted by your question, I decided
to check that both are functioning in lk 2.5.21. [ide-scsi is
broken in lk 2.5.21 (worked in 2.5.20) and Martin says a fix is 
coming.]

Here are 3 "scsi" disks on my system:
$ cat /proc/scsi/scsi
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: SEAGATE  Model: ST318451LW       Rev: 0003
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi3 Channel: 00 Id: 00 Lun: 00
  Vendor: QUANTUM  Model: FIREBALL ST3.2A  Rev:     
  Type:   Direct-Access                    ANSI SCSI revision: 06
Host: scsi4 Channel: 00 Id: 00 Lun: 00
  Vendor: MAXTOR 6 Model: L040J2           Rev: AR1.
  Type:   Direct-Access                    ANSI SCSI revision: 02

The Seagate disk is "real" scsi, the Quantum is an old IDE disk
in a ieee1394 enclosure, while the Maxtor is recent ATA disk
in a USB 2.0 enclosure. Here are the modules loaded:
$ lsmod
Module                  Size  Used by
usb-storage            69776   0 
ehci-hcd               23600   0  (unused)
sbp2                   15536   0  (unused)
ohci1394               18608   0  (unused)
ieee1394               30704   0  [sbp2 ohci1394]
usbcore                65920   1  [usb-storage ehci-hcd]

Both sd_mod and scsi_mod are built into the kernel in my system.

If I use the Maxtor in either enclosure, the streaming bandwidth
is 14 MB/sec which should be more than sufficient for most 
purposes.


One interesting development in the lk 2.5 series is driverfs.
It may give us a consistent way to show what is going on here
under the covers. It will also allow user space code to use
various hotplug alerts to load up the required modules without
user intervention. Mike Sullivan's persistent naming patch could
then place the partitions at known device names.

Doug Gilbert