Another must-fix: sbp2 and firewire hard disk crashes hard.

Another must-fix: sbp2 and firewire hard disk crashes hard.

[Torrey Hoffman]

This must be something about my particular hardware/software
configuration or more people would be reporting it.   

I will try to nail down the problem, but as soon as the SBP2 driver in
2.5.(recent) sees my firewire drive, either during kernel boot or later
if I turn on / plug in the drive, the system crashes and dumps a
seemingly endless stack trace.  It doesn't make it to the system log, so
I don't have much more than that yet.

Many more details available on request.  And more information coming
regardless.   

Unfortunately for me, 2.4 is extremely flaky for sbp2 as well. (sigh). 
Red Hat kernels oops a few seconds after the drive is plugged in, but
the system keeps running so I have some decoded oops for those at
least.  I'll try to get one from a stock 2.4.recent...

-- 
Torrey Hoffman <thoffman@arnor.net>

Re: Another must-fix: sbp2 and firewire hard disk crashes hard.

[Andrew Morton]

Torrey Hoffman wrote:
> 
> as soon as the SBP2 driver in
> 2.5.(recent) sees my firewire drive, either during kernel boot or later
> if I turn on / plug in the drive, the system crashes and dumps a
> seemingly endless stack trace.

Please apply the below patch, which should prevent the info
from scrolling away.  Then send a full report to
linux1394-devel@lists.sourceforge.net


diff -puN arch/i386/kernel/traps.c~stop-trace arch/i386/kernel/traps.c
--- 25/arch/i386/kernel/traps.c~stop-trace	Wed Jun  4 16:48:41 2003
+++ 25-akpm/arch/i386/kernel/traps.c	Wed Jun  4 16:50:13 2003
@@ -96,6 +96,7 @@ void show_trace(unsigned long * stack)
 {
 	int i;
 	unsigned long addr;
+	int count = 0;
 
 	if (!stack)
 		stack = (unsigned long*)&stack;
@@ -111,6 +112,8 @@ void show_trace(unsigned long * stack)
 			printk(" [<%08lx>] ", addr);
 			print_symbol("%s\n", addr);
 		}
+		if (count++ > 12)
+			break;
 	}
 	printk("\n");
 }
@@ -146,6 +149,8 @@ void show_stack(unsigned long * esp)
 	}
 	printk("\n");
 	show_trace(esp);
+	for ( ; ; )
+		;
 }
 
 /*

_

SBP2 hotplug doesn't update /proc/partitions

[Torrey Hoffman]

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

Re: SBP2 hotplug doesn't update /proc/partitions

[Erik Andersen]

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

Re: SBP2 hotplug doesn't update /proc/partitions

[Torrey Hoffman]

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

Re: SBP2 hotplug doesn't update /proc/partitions

[Ben Collins]

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/

scsi_add_device() broken? (was Re: SBP2 hotplug doesn't update /proc/partitions)

[Ben Collins]

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

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/

[PATCH] Re: scsi_add_device() broken? (was Re: SBP2 hotplug doesn't update /proc/partitions)

[Ben Collins]

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

Re: [PATCH] Re: scsi_add_device() broken? (was Re: SBP2 hotplug doesn't update /proc/partitions)

[Patrick Mansfield]

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

Re: SBP2 hotplug doesn't update /proc/partitions

[Torrey Hoffman]

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 <thoffman@arnor.net>

Re: Another must-fix: sbp2 and firewire hard disk crashes hard.

[Benjamin Herrenschmidt]

On Thu, 2003-06-05 at 01:48, Torrey Hoffman wrote:
> This must be something about my particular hardware/software
> configuration or more people would be reporting it.   
> 
> I will try to nail down the problem, but as soon as the SBP2 driver in
> 2.5.(recent) sees my firewire drive, either during kernel boot or later
> if I turn on / plug in the drive, the system crashes and dumps a
> seemingly endless stack trace.  It doesn't make it to the system log, so
> I don't have much more than that yet.
> 
> Many more details available on request.  And more information coming
> regardless.   
> 
> Unfortunately for me, 2.4 is extremely flaky for sbp2 as well. (sigh). 
> Red Hat kernels oops a few seconds after the drive is plugged in, but
> the system keeps running so I have some decoded oops for those at
> least.  I'll try to get one from a stock 2.4.recent...

>From experience, sbp2 with a recent ieee1394 linux_2_4 SVN branch
snapshot works quite well. I updated the one in my tree about
3 weeks ago and have been successfull playing with an iPod, burning
CDs, etc...

Ben.