I am now running 2.5.70-bk15, and with slab debugging turned off SBP2
mostly works. However, I just had an interesting glitch show up.
I plugged in a 120 GB drive which had two VFAT partitions, mounted them,
copied some data to them, unmounted them, and unplugged the drive.
That worked perfectly. (This was the first use of SBP2 after booting.)
Then I plugged in a 250 GB drive with a single reiserfs partition. The
SBP2 driver detected the drive correctly, but the kernel's idea of what
partitions are available was not updated.
/proc/partitions still has the old, stale data from the 120 GB drive and
looks like this: (skipping my hda partitions)
major minor #blocks name
8 0 117187500 sda
8 1 80011701 sda1
8 2 37174410 sda2
fdisk /dev/sda believes the drive is only 120 GB but has a single 250 GB
partition:
[root@torrey mnt]# fdisk /dev/sda
The number of cylinders for this disk is set to 14589.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/sda: 120.0 GB, 120000000000 bytes
255 heads, 63 sectors/track, 14589 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 30515 245111706 83 Linux
Attempting to mount the partition fails and produces lots of errors,
which is not surprising. A snippet of the system log:
Jun 12 12:10:12 torrey kernel: found reiserfs format "3.6" with standard journal
Jun 12 12:10:15 torrey kernel: limit=160023402
Jun 12 12:10:15 torrey kernel: attempt to access beyond end of device
Jun 12 12:10:15 torrey kernel: sda1: rw=0, want=394002440, limit=160023402
Jun 12 12:10:15 torrey kernel: attempt to access beyond end of device
Here is the system log of the 250 GB drive being plugged in and
correctly detected:
Jun 12 12:09:45 torrey /etc/hotplug/ieee1394.agent: Setup sbp2 for IEEE1394 product 0x000000/0x00609e/0x010483
Jun 12 12:09:45 torrey kernel: ieee1394: sbp2: Logged into SBP-2 device
Jun 12 12:09:45 torrey kernel: ieee1394: sbp2: Node[00:1023]: Max speed [S400] - Max payload [2048]Jun 12 12:09:45 torrey kernel: Vendor: Maxtor 4 Model: A250J8 Rev:
Jun 12 12:09:45 torrey kernel: Type: Direct-Access ANSI SCSI revision: 06
Jun 12 12:09:45 torrey kernel: error 1
Jun 12 12:09:46 torrey devlabel: devlabel service started/restarted
Thanks for your development efforts!
Torrey Hoffman
On Thu Jun 12, 2003 at 12:28:00PM -0700, Torrey Hoffman wrote:
> I am now running 2.5.70-bk15, and with slab debugging turned off SBP2
> mostly works. However, I just had an interesting glitch show up.
>
> I plugged in a 120 GB drive which had two VFAT partitions, mounted them,
> copied some data to them, unmounted them, and unplugged the drive.
> That worked perfectly. (This was the first use of SBP2 after booting.)
>
> Then I plugged in a 250 GB drive with a single reiserfs partition. The
> SBP2 driver detected the drive correctly, but the kernel's idea of what
> partitions are available was not updated.
>
> /proc/partitions still has the old, stale data from the 120 GB drive and
> looks like this: (skipping my hda partitions)
>
> major minor #blocks name
>
> 8 0 117187500 sda
> 8 1 80011701 sda1
> 8 2 37174410 sda2
>
> fdisk /dev/sda believes the drive is only 120 GB but has a single 250 GB
> partition:
I strongly suspect your 1394 to IDE bridge is an ATA5 device, and
is therefore limited to supporting drives less than 128 GB. That
is the case for my firewire drives, so I keep them populated with
120 GB drives and I put my 200 GB drives elsewhere....
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Thu, 2003-06-12 at 12:52, Erik Andersen wrote:
...
> > fdisk /dev/sda believes the drive is only 120 GB but has a single 250 GB
> > partition:
>
> I strongly suspect your 1394 to IDE bridge is an ATA5 device, and
> is therefore limited to supporting drives less than 128 GB. That
> is the case for my firewire drives, so I keep them populated with
> 120 GB drives and I put my 200 GB drives elsewhere....
Thanks for the tip, but no, the enclosure with the 250 GB drive does
support ATA 6. However, the other enclosure with the 120 GB drive is
ATA 5 only.
After rebooting, I am able to mount the 250 GB reiserfs partition,
and I'm pretty sure that reiserfs accesses data past the 120 GB boundary
during the mount process. (I only have 8 GB of data on the partition at
the moment though...)
More bug reports on sbp2 coming in a second :-)
Torrey
This is perhaps a related problem: I just noticed that if I have a
firewire drive plugged in at boot, the SBP2 driver detects it during
boot:
ohci1394_0: OHCI-1394 1.0 (PCI): IRQ=[10] MMIO=[e8201000-e82017ff] Max Packet=[2048]
scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: sbp2: Node[00:1023]: Max speed [S400] - Max payload [2048]
Vendor: Maxtor 4 Model: A250J8 Rev:
Type: Direct-Access ANSI SCSI revision: 06
ieee1394: Node added: ID:BUS[0-00:1023] GUID[0004830000002cb3]
ieee1394: Host added: ID:BUS[0-01:1023] GUID[0040630000001c47]
But, the drive itself (/dev/sda) and any partitions on it don't show up
in /proc/partitions until I mount one of them or perform some sort of
other access to the drive, like running fdisk on it.
To me, this seems to be a bug. Or is it actually by design?
--
Torrey Hoffman <[email protected]>
On Thu, Jun 12, 2003 at 12:28:00PM -0700, Torrey Hoffman wrote:
> I am now running 2.5.70-bk15, and with slab debugging turned off SBP2
> mostly works. However, I just had an interesting glitch show up.
>
> I plugged in a 120 GB drive which had two VFAT partitions, mounted them,
> copied some data to them, unmounted them, and unplugged the drive.
> That worked perfectly. (This was the first use of SBP2 after booting.)
>
> Then I plugged in a 250 GB drive with a single reiserfs partition. The
> SBP2 driver detected the drive correctly, but the kernel's idea of what
> partitions are available was not updated.
>
> /proc/partitions still has the old, stale data from the 120 GB drive and
> looks like this: (skipping my hda partitions)
Sounds like the scsi layer is keeping stale info. I'd say this is
suspiciously similar to what's causing your oops in your later email.
Track down where the stale info comes from, and I think you'll find the
cause of both your problems.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
On Thu, Jun 12, 2003 at 03:52:43PM -0400, Ben Collins wrote:
> On Thu, Jun 12, 2003 at 12:28:00PM -0700, Torrey Hoffman wrote:
> > I am now running 2.5.70-bk15, and with slab debugging turned off SBP2
> > mostly works. However, I just had an interesting glitch show up.
> >
> > I plugged in a 120 GB drive which had two VFAT partitions, mounted them,
> > copied some data to them, unmounted them, and unplugged the drive.
> > That worked perfectly. (This was the first use of SBP2 after booting.)
> >
> > Then I plugged in a 250 GB drive with a single reiserfs partition. The
> > SBP2 driver detected the drive correctly, but the kernel's idea of what
> > partitions are available was not updated.
> >
> > /proc/partitions still has the old, stale data from the 120 GB drive and
> > looks like this: (skipping my hda partitions)
>
> Sounds like the scsi layer is keeping stale info. I'd say this is
> suspiciously similar to what's causing your oops in your later email.
> Track down where the stale info comes from, and I think you'll find the
> cause of both your problems.
scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Query logins to SBP-2 device successful
ieee1394: sbp2: Maximum concurrent logins supported: 1
ieee1394: sbp2: Number of active logins: 0
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: sbp2: Node[02:1023]: Max speed [S400] - Max payload [2048]
Vendor: FireWire Model: 1394 Disk Drive Rev: G603
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: cache data unavailable
sda: assuming drive cache: write through
sda: unknown partition table
devfs_mk_dir: invalid argument.<5>Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Note, the "unknown partition table" is ok for me, because I am using a
whole-disk filesystem. However, the devfs_mk_dir() error is suspicious.
Note, I use devfs. 2.5.69+bk (just before 2.6.70) things worked fine.
Now, /dev/sda is not being created. Nothing in /dev/scsi/ either, but:
hopper:~# cat /proc/scsi/sbp2/0
Host scsi0 : SBP-2 IEEE-1394 (ohci1394)
Driver version : $Rev: 942 $ Ben Collins <[email protected]>
Module options :
max_speed : S400
max_sectors : 255
serialize_io : no
exclusive_login : no
Attached devices :
[Channel: 00, Id: 00, Lun: 00] Direct-Access FireWire 1394 Disk Drive
Also, /sys/bus/scsi/devices/0:0:0:0 exists, with a block link to sda.
I suspect this is a problem where scsi_add_device() is not doing all the
stuff it needs to (does anything besides ieee1394 use scsi_add_device
and scsi_remove_device?).
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
> scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
> ieee1394: sbp2: Query logins to SBP-2 device successful
> ieee1394: sbp2: Maximum concurrent logins supported: 1
> ieee1394: sbp2: Number of active logins: 0
> ieee1394: sbp2: Logged into SBP-2 device
> ieee1394: sbp2: Node[02:1023]: Max speed [S400] - Max payload [2048]
> Vendor: FireWire Model: 1394 Disk Drive Rev: G603
> Type: Direct-Access ANSI SCSI revision: 02
> SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
> sda: cache data unavailable
> sda: assuming drive cache: write through
> sda: unknown partition table
> devfs_mk_dir: invalid argument.<5>Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Here's the scenario. scsi_add_lun doesn't set sdp->devfs_name before
calling scsi_register_device(). Since scsi_register_device calls down to
things like sd_probe, which do try to use sdp->devfs_name, things fail.
Just an easy change, moving the sdp->devfs_name creation before calling
scsi_register_device(). Patch fixes this.
Index: linux-2.5/drivers/scsi/scsi_scan.c
===================================================================
--- linux-2.5/drivers/scsi/scsi_scan.c (revision 10937)
+++ linux-2.5/drivers/scsi/scsi_scan.c (working copy)
@@ -619,12 +619,12 @@
if (inq_result[7] & 0x10)
sdev->sdtr = 1;
- scsi_device_register(sdev);
-
sprintf(sdev->devfs_name, "scsi/host%d/bus%d/target%d/lun%d",
sdev->host->host_no, sdev->channel,
sdev->id, sdev->lun);
+ scsi_device_register(sdev);
+
/*
* End driverfs/devfs code.
*/
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
On Fri, Jun 13, 2003 at 12:08:12PM -0400, Ben Collins wrote:
> Here's the scenario. scsi_add_lun doesn't set sdp->devfs_name before
> calling scsi_register_device(). Since scsi_register_device calls down to
> things like sd_probe, which do try to use sdp->devfs_name, things fail.
>
> Just an easy change, moving the sdp->devfs_name creation before calling
> scsi_register_device(). Patch fixes this.
It really needs to move into the caller of scsi_add_lun, so we setup all
the other fields, and possibly call scsi_unlock_floptical before
registering.
And the return value should be checked - then on failure just set res (in
scsi_probe_and_add_lun) so it is cleaned up.
-- Patrick Mansfield