Re: [BK PATCH] SCSI update for 2.6.3

Re: [BK PATCH] SCSI update for 2.6.3

[Kai Makisara]

On Tue, 24 Feb 2004, Linus Torvalds wrote:
>On Mon, 23 Feb 2004, James Bottomley wrote:
>>
>> Kai Mäkisara:
>> o Sysfs class support for SCSI tapes
>
>Has this been checked for correctness, or will Al flame me to a crisp for
>accepting it? Pls verify..

It is using the class_simple interface Greg KH said can be used without
changes to driver's lifetime rules. If this is not true, then I have to
rework the patch. The code was posted to linux-scsi on Feb 5 but I would
not count on any serious review being done there.

	Kai

Re: [BK PATCH] SCSI update for 2.6.3

[Greg KH]

On Tue, Feb 24, 2004 at 09:30:01AM +0200, Kai Makisara wrote:
> On Tue, 24 Feb 2004, Linus Torvalds wrote:
> >On Mon, 23 Feb 2004, James Bottomley wrote:
> >>
> >> Kai Mäkisara:
> >> o Sysfs class support for SCSI tapes
> >
> >Has this been checked for correctness, or will Al flame me to a crisp for
> >accepting it? Pls verify..
> 
> It is using the class_simple interface Greg KH said can be used without
> changes to driver's lifetime rules. If this is not true, then I have to
> rework the patch. The code was posted to linux-scsi on Feb 5 but I would
> not count on any serious review being done there.

Can you post it here so we can review it?

And yes, using class_simple should relieve you of Al flamage :)

thanks,

greg k-h

Re: [BK PATCH] SCSI update for 2.6.3

[James Bottomley]

On Tue, 2004-02-24 at 11:04, Greg KH wrote:
> Can you post it here so we can review it?
> 
> And yes, using class_simple should relieve you of Al flamage :)

The one in the tree is attached.  I did verify it myself, and tried it
out on some old QIC tapes I had lying around.

James

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1574  -> 1.1575 
#	Documentation/scsi/st.txt	1.12    -> 1.13   
#	   drivers/scsi/st.c	1.77    -> 1.78   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 04/02/22	Kai.Makisara@kolumbus.fi	1.1575
# [PATCH] Sysfs class support for SCSI tapes
# 
# This is a new version of the patch I sent two weeks ago. The code is the
# same but now diffed against 2.6.3. Some documentation has been added.
# Creation and removal of the st device files has been tested with
# udev-018.
# 
# The patch adds support for /sys/class/scsi_tape. It also removes the links
# to/from the st files in /sys/cdev/major.
# 
# A file is created for each mode and rewind/non-rewind device for each
# tape drive. Here is an example for one drive:
# > ls /sys/class/scsi_tape/
# st0m0  st0m0n  st0m1  st0m1n  st0m2  st0m2n  st0m3  st0m3n
# 
# In addition to the automatic links (dev, driver), each directory contains
# files that export some of the mode parameters:
# > ls /sys/class/scsi_tape/st0m0
# default_blksize      default_density  dev     driver
# default_compression  defined          device
# 
# A link is made from the SCSI device directory back to the mode 0
# auto-rewind class file:
# > ls -l
# /sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.1/host1/1:0:5:0/tape
# lrwxrwxrwx    1 root     root           39 2004-02-05 23:14
# /sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.1/host1/1:0:5:0/tape ->
# ../../../../../../class/scsi_tape/st0m0
# --------------------------------------------
#
diff -Nru a/Documentation/scsi/st.txt b/Documentation/scsi/st.txt
--- a/Documentation/scsi/st.txt	Tue Feb 24 11:07:42 2004
+++ b/Documentation/scsi/st.txt	Tue Feb 24 11:07:42 2004
@@ -2,7 +2,7 @@
 The driver is currently maintained by Kai Mäkisara (email
 Kai.Makisara@kolumbus.fi)
 
-Last modified: Sun Nov  9 22:36:02 2003 by makisara
+Last modified: Thu Feb 19 21:57:30 2004 by makisara
 

 BASICS
@@ -113,6 +113,26 @@
 only 8 bits wide.
 

+SYSFS SUPPORT
+
+The driver creates the directory /sys/class/scsi_tape and populates it with
+directories corresponding to the existing tape devices. There are autorewind
+and non-rewind entries for each mode. The names are stxmy and stxmyn, where x
+is the tape number and y is the mode. For example, the directories for the
+first tape device are (assuming four modes): st0m0  st0m0n  st0m1  st0m1n
+st0m2  st0m2n  st0m3  st0m3n.
+
+Each directory contains the entries: default_blksize  default_compression
+default_density  defined  dev  device  driver. The file 'defined' contains 1
+if the mode is defined and zero if not defined. The files 'default_*' contain
+the defaults set by the user. The value -1 means the default is not set. The
+file 'dev' contains the device numbers corresponding to this device. The links
+'device' and 'driver' point to the SCSI device and driver entries.
+
+A link named 'tape' is made from the SCSI device directory to the class
+directory corresponding to the mode 0 auto-rewind device (e.g., st0m0). 
+
+
 BSD AND SYS V SEMANTICS
 
 The user can choose between these two behaviours of the tape driver by
@@ -126,7 +146,7 @@
 
 BUFFERING
 
-The driver tries to do tranfers directly to/from user space. If this
+The driver tries to do transfers directly to/from user space. If this
 is not possible, a driver buffer allocated at run-time is used. If
 direct i/o is not possible for the whole transfer, the driver buffer
 is used (i.e., bounce buffers for individual pages are not
@@ -147,6 +167,12 @@
 size). Because of this the actual buffer size may be larger than the
 minimum allowable buffer size.
 
+NOTE that if direct i/o is used, the small writes are not buffered. This may
+cause a surprise when moving from 2.4. There small writes (e.g., tar without
+-b option) may have had good throughput but this is not true any more with
+2.6. Direct i/o can be turned off to solve this problem but a better solution
+is to use bigger write() byte counts (e.g., tar -b 64).
+
 Asynchronous writing. Writing the buffer contents to the tape is
 started and the write call returns immediately. The status is checked
 at the next tape operation. Asynchronous writes are not done with
@@ -453,7 +479,7 @@
 
 To enable debugging messages, edit st.c and #define DEBUG 1. As seen
 above, debugging can be switched off with an ioctl if debugging is
-compiled into the driver. The debugging output is not voluminuous.
+compiled into the driver. The debugging output is not voluminous.
 
 If the tape seems to hang, I would be very interested to hear where
 the driver is waiting. With the command 'ps -l' you can see the state
diff -Nru a/drivers/scsi/st.c b/drivers/scsi/st.c
--- a/drivers/scsi/st.c	Tue Feb 24 11:07:42 2004
+++ b/drivers/scsi/st.c	Tue Feb 24 11:07:42 2004
@@ -17,7 +17,7 @@
    Last modified: 18-JAN-1998 Richard Gooch <rgooch@atnf.csiro.au> Devfs support
  */
 
-static char *verstr = "20040122";
+static char *verstr = "20040213";
 
 #include <linux/module.h>
 
@@ -77,6 +77,8 @@
 static int st_dev_max;
 static int st_nr_dev;
 
+static struct class_simple *st_sysfs_class;
+
 MODULE_AUTHOR("Kai Makisara");
 MODULE_DESCRIPTION("SCSI Tape Driver");
 MODULE_LICENSE("GPL");
@@ -183,7 +185,7 @@
 
 static void do_create_driverfs_files(void);
 static void do_remove_driverfs_files(void);
-
+static void do_create_class_files(Scsi_Tape *, int, int);
 
 static struct scsi_driver st_template = {
 	.owner			= THIS_MODULE,
@@ -3902,20 +3904,8 @@
 			}
 			STm->cdevs[j] = cdev;
 
-			error = sysfs_create_link(&STm->cdevs[j]->kobj, &SDp->sdev_gendev.kobj,
-						  "device");
-			if (error) {
-				printk(KERN_ERR
-				       "st%d: Can't create sysfs link from SCSI device.\n",
-				       dev_num);
-			}
 		}
-	}
-	error = sysfs_create_link(&SDp->sdev_gendev.kobj, &tpnt->modes[0].cdevs[0]->kobj,
-				  "tape");
-	if (error) {
-		printk(KERN_ERR "st%d: Can't create sysfs link from SCSI device.\n",
-		       dev_num);
+		do_create_class_files(tpnt, dev_num, mode);
 	}
 
 	for (mode = 0; mode < ST_NBR_MODES; ++mode) {
@@ -3941,11 +3931,14 @@
 out_free_tape:
 	for (mode=0; mode < ST_NBR_MODES; mode++) {
 		STm = &(tpnt->modes[mode]);
+		sysfs_remove_link(&tpnt->device->sdev_gendev.kobj,
+				  "tape");
 		for (j=0; j < 2; j++) {
 			if (STm->cdevs[j]) {
 				if (cdev == STm->cdevs[j])
 					cdev = NULL;
-				sysfs_remove_link(&STm->cdevs[j]->kobj, "device");
+				class_simple_device_remove(MKDEV(SCSI_TAPE_MAJOR,
+								 TAPE_MINOR(i, mode, j)));
 				cdev_del(STm->cdevs[j]);
 			}
 		}
@@ -3981,13 +3974,14 @@
 			st_nr_dev--;
 			write_unlock(&st_dev_arr_lock);
 			devfs_unregister_tape(tpnt->disk->number);
-			sysfs_remove_link(&SDp->sdev_gendev.kobj, "tape");
+			sysfs_remove_link(&tpnt->device->sdev_gendev.kobj,
+					  "tape");
 			for (mode = 0; mode < ST_NBR_MODES; ++mode) {
 				devfs_remove("%s/mt%s", SDp->devfs_name, st_formats[mode]);
 				devfs_remove("%s/mt%sn", SDp->devfs_name, st_formats[mode]);
 				for (j=0; j < 2; j++) {
-					sysfs_remove_link(&tpnt->modes[mode].cdevs[j]->kobj,
-							  "device");
+					class_simple_device_remove(MKDEV(SCSI_TAPE_MAJOR,
+									 TAPE_MINOR(i, mode, j)));
 					cdev_del(tpnt->modes[mode].cdevs[j]);
 					tpnt->modes[mode].cdevs[j] = NULL;
 				}
@@ -4052,13 +4046,23 @@
 		"st: Version %s, fixed bufsize %d, s/g segs %d\n",
 		verstr, st_fixed_buffer_size, st_max_sg_segs);
 
+	st_sysfs_class = class_simple_create(THIS_MODULE, "scsi_tape");
+	if (IS_ERR(st_sysfs_class)) {
+		st_sysfs_class = NULL;
+		printk(KERN_ERR "Unable create sysfs class for SCSI tapes\n");
+		return 1;
+	}
+
 	if (!register_chrdev_region(MKDEV(SCSI_TAPE_MAJOR, 0),
 				    ST_MAX_TAPE_ENTRIES, "st")) {
 		if (scsi_register_driver(&st_template.gendrv) == 0) {
 			do_create_driverfs_files();
 			return 0;
 		}
+		if (st_sysfs_class)
+			class_simple_destroy(st_sysfs_class);		
 		unregister_chrdev_region(MKDEV(SCSI_TAPE_MAJOR, 0),
+
 					 ST_MAX_TAPE_ENTRIES);
 	}
 
@@ -4068,6 +4072,9 @@
 
 static void __exit exit_st(void)
 {
+	if (st_sysfs_class)
+		class_simple_destroy(st_sysfs_class);
+	st_sysfs_class = NULL;
 	do_remove_driverfs_files();
 	scsi_unregister_driver(&st_template.gendrv);
 	unregister_chrdev_region(MKDEV(SCSI_TAPE_MAJOR, 0),
@@ -4080,7 +4087,7 @@
 module_exit(exit_st);
 

-/* The sysfs interface. Read-only at the moment */
+/* The sysfs driver interface. Read-only at the moment */
 static ssize_t st_try_direct_io_show(struct device_driver *ddp, char *buf)
 {
 	return snprintf(buf, PAGE_SIZE, "%d\n", try_direct_io);
@@ -4123,6 +4130,99 @@
 	driver_remove_file(driverfs, &driver_attr_max_sg_segs);
 	driver_remove_file(driverfs, &driver_attr_fixed_buffer_size);
 	driver_remove_file(driverfs, &driver_attr_try_direct_io);
+}
+
+
+/* The sysfs simple class interface */
+static ssize_t st_defined_show(struct class_device *class_dev, char *buf)
+{
+	ST_mode *STm = (ST_mode *)class_get_devdata(class_dev);
+	ssize_t l = 0;
+
+	l = snprintf(buf, PAGE_SIZE, "%d\n", STm->defined);
+	return l;
+}
+
+CLASS_DEVICE_ATTR(defined, S_IRUGO, st_defined_show, NULL);
+
+static ssize_t st_defblk_show(struct class_device *class_dev, char *buf)
+{
+	ST_mode *STm = (ST_mode *)class_get_devdata(class_dev);
+	ssize_t l = 0;
+
+	l = snprintf(buf, PAGE_SIZE, "%d\n", STm->default_blksize);
+	return l;
+}
+
+CLASS_DEVICE_ATTR(default_blksize, S_IRUGO, st_defblk_show, NULL);
+
+static ssize_t st_defdensity_show(struct class_device *class_dev, char *buf)
+{
+	ST_mode *STm = (ST_mode *)class_get_devdata(class_dev);
+	ssize_t l = 0;
+	char *fmt;
+
+	fmt = STm->default_density >= 0 ? "0x%02x\n" : "%d\n";
+	l = snprintf(buf, PAGE_SIZE, fmt, STm->default_density);
+	return l;
+}
+
+CLASS_DEVICE_ATTR(default_density, S_IRUGO, st_defdensity_show, NULL);
+
+static ssize_t st_defcompression_show(struct class_device *class_dev, char *buf)
+{
+	ST_mode *STm = (ST_mode *)class_get_devdata(class_dev);
+	ssize_t l = 0;
+
+	l = snprintf(buf, PAGE_SIZE, "%d\n", STm->default_compression - 1);
+	return l;
+}
+
+CLASS_DEVICE_ATTR(default_compression, S_IRUGO, st_defcompression_show, NULL);
+
+static void do_create_class_files(Scsi_Tape *STp, int dev_num, int mode)
+{
+	int rew, error;
+	struct class_device *st_class_member;
+
+	if (!st_sysfs_class)
+		return;
+
+	for (rew=0; rew < 2; rew++) {
+		st_class_member =
+			class_simple_device_add(st_sysfs_class,
+						MKDEV(SCSI_TAPE_MAJOR,
+						      TAPE_MINOR(dev_num, mode, rew)),
+						&STp->device->sdev_gendev, "%s",
+						STp->modes[mode].cdevs[rew]->kobj.name);
+		if (!st_class_member) {
+			printk(KERN_WARNING "st%d: class_simple_device_add failed\n",
+			       dev_num);
+			goto out;
+		}
+		class_set_devdata(st_class_member, &STp->modes[mode]);
+
+		class_device_create_file(st_class_member,
+					 &class_device_attr_defined);
+		class_device_create_file(st_class_member,
+					 &class_device_attr_default_blksize);
+		class_device_create_file(st_class_member,
+					 &class_device_attr_default_density);
+		class_device_create_file(st_class_member,
+					 &class_device_attr_default_compression);
+		if (mode == 0 && rew == 0) {
+			error = sysfs_create_link(&STp->device->sdev_gendev.kobj,
+						  &st_class_member->kobj,
+						  "tape");
+			if (error) {
+				printk(KERN_ERR
+				       "st%d: Can't create sysfs link from SCSI device.\n",
+				       dev_num);
+			}
+		}
+	}
+ out:
+	return;
 }
 

Re: [BK PATCH] SCSI update for 2.6.3

[Greg KH]

On Tue, Feb 24, 2004 at 11:08:48AM -0600, James Bottomley wrote:
> On Tue, 2004-02-24 at 11:04, Greg KH wrote:
> > Can you post it here so we can review it?
> > 
> > And yes, using class_simple should relieve you of Al flamage :)
> 
> The one in the tree is attached.  I did verify it myself, and tried it
> out on some old QIC tapes I had lying around.

Can you print out the sysfs tree this patch creates?

What's that "tape" symlink for?  Does it go from the scsi device in
/sys/devices/... to the class device?  Or the other way around?

Other than that question, the patch looks sane to me.

thanks,

greg k-h

Re: [BK PATCH] SCSI update for 2.6.3

[Linus Torvalds]

On Tue, 24 Feb 2004, Greg KH wrote:
> 
> Other than that question, the patch looks sane to me.

Ok, I'll pull the thing.

		Linus

Re: [BK PATCH] SCSI update for 2.6.3

[Kai Makisara]

On Tue, 24 Feb 2004, Greg KH wrote:

> On Tue, Feb 24, 2004 at 11:08:48AM -0600, James Bottomley wrote:
> > On Tue, 2004-02-24 at 11:04, Greg KH wrote:
> > > Can you post it here so we can review it?
> > > 
> > > And yes, using class_simple should relieve you of Al flamage :)
> > 
> > The one in the tree is attached.  I did verify it myself, and tried it
> > out on some old QIC tapes I had lying around.
> 
> Can you print out the sysfs tree this patch creates?
> 
Here is a partial tree for the first tree (nearly identical entries from 
the middle trimmed):

/sys/class/scsi_tape/
|-- st0m0
|   |-- default_blksize
|   |-- default_compression
|   |-- default_density
|   |-- defined
|   |-- dev
|   |-- device -> 
../../../devices/pci0000:00/0000:00:1e.0/0000:02:01.1/host1/1:0:5:0
|   `-- driver -> ../../../bus/scsi/drivers/st
|-- st0m0n
|   |-- default_blksize
|   |-- default_compression
|   |-- default_density
|   |-- defined
|   |-- dev
|   |-- device -> 
../../../devices/pci0000:00/0000:00:1e.0/0000:02:01.1/host1/1:0:5:0
|   `-- driver -> ../../../bus/scsi/drivers/st
.
.
.
`-- st0m3n
    |-- default_blksize
    |-- default_compression
    |-- default_density
    |-- defined
    |-- dev
    |-- device -> 
../../../devices/pci0000:00/0000:00:1e.0/0000:02:01.1/host1/1:0:5:0
    `-- driver -> ../../../bus/scsi/drivers/st

> What's that "tape" symlink for?  Does it go from the scsi device in
> /sys/devices/... to the class device?  Or the other way around?
> 

The link is from the SCSI device to one of the scsi_tape directories:

/sys/devices/pci0000:00/0000:00:1e.0/0000:02:01.1/host1/1:0:5:0
|-- delete
|-- detach_state
|-- device_blocked
|-- generic -> ../../../../../../class/scsi_generic/sg1
|-- model
|-- online
|-- power
|   `-- state
|-- queue_depth
|-- rescan
|-- rev
|-- scsi_level
|-- tape -> ../../../../../../class/scsi_tape/st0m0
|-- type
`-- vendor

The idea is to be able to follow the links from a generic scsi device to 
the tape device. The link 'generic' created by sg enables associating a 
tape with the corresponding sg device.

> Other than that question, the patch looks sane to me.
> 
Thanks for the review.

-- 
Kai

Re: [BK PATCH] SCSI update for 2.6.3

[Greg KH]

On Tue, Feb 24, 2004 at 07:51:42PM +0200, Kai Makisara wrote:
> On Tue, 24 Feb 2004, Greg KH wrote:
> 
> > On Tue, Feb 24, 2004 at 11:08:48AM -0600, James Bottomley wrote:
> > > On Tue, 2004-02-24 at 11:04, Greg KH wrote:
> > > > Can you post it here so we can review it?
> > > > 
> > > > And yes, using class_simple should relieve you of Al flamage :)
> > > 
> > > The one in the tree is attached.  I did verify it myself, and tried it
> > > out on some old QIC tapes I had lying around.
> > 
> > Can you print out the sysfs tree this patch creates?
> > 
> Here is a partial tree for the first tree (nearly identical entries from 
> the middle trimmed):

<snip>

Ah, very nice.  And thanks for adding those symlinks back to the class
entries, that should be helpful for people.

Looks good.

greg k-h

Re: [BK PATCH] SCSI update for 2.6.3

[Patrick Mansfield]

On Tue, Feb 24, 2004 at 09:16:29AM -0800, Greg KH wrote:

> 
> Can you print out the sysfs tree this patch creates?
> 
> What's that "tape" symlink for?  Does it go from the scsi device in
> /sys/devices/... to the class device?  Or the other way around?
> 
> Other than that question, the patch looks sane to me.

Current 2.6 kernel default names are of the form: st[0-9]m[0-3][n]

Current /dev naming is of the form: [n]st[0-9][alm]

Should the st kernel names be changed to map to current /dev names?

For udev, even with that we need differing pre and postfix values wrapped
around a peristent name.

Here's /dev and /udev (for a dlt tape drive):

[elm3a49 Documentation]$ ls -l /udev/*st0* | sort -k 5
crw-------    1 root     root       9,   0 Feb 24 17:47 /udev/st0m0
crw-------    1 root     root       9,  32 Feb 24 17:47 /udev/st0m1
crw-------    1 root     root       9,  64 Feb 24 17:47 /udev/st0m2
crw-------    1 root     root       9,  96 Feb 24 17:47 /udev/st0m3
crw-------    1 root     root       9, 128 Feb 24 17:47 /udev/st0m0n
crw-------    1 root     root       9, 160 Feb 24 17:47 /udev/st0m1n
crw-------    1 root     root       9, 192 Feb 24 17:47 /udev/st0m2n
crw-------    1 root     root       9, 224 Feb 24 17:47 /udev/st0m3n
[elm3a49 Documentation]$ ls -l /dev/*st0* | sort -k 5
crw-rw----    1 root     tape       9,   0 Nov 14 14:34 /dev/st0
crw-rw----    1 root     tape       9,  32 Nov 14 14:34 /dev/st0l
crw-rw----    1 root     tape       9,  64 Nov 14 14:34 /dev/st0m
crw-rw----    1 root     tape       9,  96 Nov 14 14:34 /dev/st0a
crw-rw----    1 root     tape       9, 128 Nov 14 14:34 /dev/nst0
crw-rw----    1 root     tape       9, 160 Nov 14 14:34 /dev/nst0l
crw-rw----    1 root     tape       9, 192 Nov 14 14:34 /dev/nst0m
crw-rw----    1 root     tape       9, 224 Nov 14 14:34 /dev/nst0a

-- Patrick Mansfield

Re: [BK PATCH] SCSI update for 2.6.3

[Greg KH]

On Tue, Feb 24, 2004 at 10:15:12AM -0800, Patrick Mansfield wrote:
> On Tue, Feb 24, 2004 at 09:16:29AM -0800, Greg KH wrote:
> 
> > 
> > Can you print out the sysfs tree this patch creates?
> > 
> > What's that "tape" symlink for?  Does it go from the scsi device in
> > /sys/devices/... to the class device?  Or the other way around?
> > 
> > Other than that question, the patch looks sane to me.
> 
> Current 2.6 kernel default names are of the form: st[0-9]m[0-3][n]
> 
> Current /dev naming is of the form: [n]st[0-9][alm]
> 
> Should the st kernel names be changed to map to current /dev names?

Yes, to make it easier for everyone, they should.  Any reason why the
kernel names are currently different from what we have in
Documentation/devices.txt?  I really feel we should follow the standard
here :)

thanks,

greg k-h

Re: [BK PATCH] SCSI update for 2.6.3

[Kai Makisara]

On Tue, 24 Feb 2004, Patrick Mansfield wrote:

...
> Current 2.6 kernel default names are of the form: st[0-9]m[0-3][n]
> 
Actually more like  st[0-9]*m[0-9]*[n]

> Current /dev naming is of the form: [n]st[0-9][alm]
> 
Depends on who's /dev you are looking at.

> Should the st kernel names be changed to map to current /dev names?
> 
I don't think we should go back to the old names. The intention with the 
"new" names was to make them easier to parse and handle than the old ones. 
The number of modes is not always four. Anyone can compile st with more or 
less modes. Using a number for the mode is naturally extensible. The 
characters at the end of the old names had interpretations that may not be 
correct in all cases (a=alternate, l=low density, m=medium density).

n has been put at the end of the name because now the tape names are 
grouped together in a listing. I know this is a weak justification ;-)

> For udev, even with that we need differing pre and postfix values wrapped
> around a peristent name.
> 
If I read udev correctly, it can now parse one number at the end of the 
name. Something like st%md%n and nst%md%n could be used with eight rules 
(where %m is the mode number and %n is the device number). Not very 
convenient. Parsing the st names should really be able to extract at 
least two fields. With an external program, anything can be done. Maybe 
udev can some day do this internally.

-- 
Kai

Re: [BK PATCH] SCSI update for 2.6.3

[Greg KH]

On Tue, Feb 24, 2004 at 11:48:32PM +0200, Kai Makisara wrote:
> On Tue, 24 Feb 2004, Patrick Mansfield wrote:
> 
> ...
> > Current 2.6 kernel default names are of the form: st[0-9]m[0-3][n]
> > 
> Actually more like  st[0-9]*m[0-9]*[n]
> 
> > Current /dev naming is of the form: [n]st[0-9][alm]
> > 
> Depends on who's /dev you are looking at.

How about everyone look at devices.txt as that is the LSB standard.

> > Should the st kernel names be changed to map to current /dev names?
> > 
> I don't think we should go back to the old names. The intention with the 
> "new" names was to make them easier to parse and handle than the old ones. 
> The number of modes is not always four. Anyone can compile st with more or 
> less modes. Using a number for the mode is naturally extensible. The 
> characters at the end of the old names had interpretations that may not be 
> correct in all cases (a=alternate, l=low density, m=medium density).
> 
> n has been put at the end of the name because now the tape names are 
> grouped together in a listing. I know this is a weak justification ;-)
> 
> > For udev, even with that we need differing pre and postfix values wrapped
> > around a peristent name.
> > 
> If I read udev correctly, it can now parse one number at the end of the 
> name. Something like st%md%n and nst%md%n could be used with eight rules 
> (where %m is the mode number and %n is the device number). Not very 
> convenient. Parsing the st names should really be able to extract at 
> least two fields. With an external program, anything can be done. Maybe 
> udev can some day do this internally.

Well, udev didn't think that anyone would do such a looney thing in
nameing devices :)

But yes, I'll be glad to fix up udev if you all fix up the tape sysfs
names to match device.txt.

thanks,

greg k-h

Re: [BK PATCH] SCSI update for 2.6.3

[Kai Makisara]

On Tue, 24 Feb 2004, Greg KH wrote:

> On Tue, Feb 24, 2004 at 11:48:32PM +0200, Kai Makisara wrote:
...
> > convenient. Parsing the st names should really be able to extract at 
> > least two fields. With an external program, anything can be done. Maybe 
> > udev can some day do this internally.
> 
> Well, udev didn't think that anyone would do such a looney thing in
> nameing devices :)
> 
However the SCSI tape names are formed, there are three variables. But 
I see your smiley :-)

> But yes, I'll be glad to fix up udev if you all fix up the tape sysfs
> names to match device.txt.
> 
OK. Unless anyone provides strong arguments for the "new" naming or 
some other naming, I will make tomorrow (or actually later today) a patch 
that changes the sysfs file naming to the one in device.txt.

-- 
Kai

RE: [BK PATCH] SCSI update for 2.6.3

[Moore, Eric Dean]

I don't see the banner displayed by the driver
which would contain the FwRev, Ports, MaxQ, IRQ.
I suspect hw/fw issues with the card itself.

What happens when you attach drives to the card;
e.g. does the driver load then?

Can you upgrade your firmware to the latest.
http://www.lsilogic.com/downloads/selectDownload.do

Eric


On Wednesday, February 25, 2004 7:29 AM, Joe Korty wrote:
> 
> On Tue, Feb 24, 2004 at 07:23:32PM -0500, Moore, Eric Dean wrote:
> > Please try the attached patch.
> > Apply against the 2.6.3 kernel, which
> > comes with mpt fusion 3.00.02 driver.
> > 
> > I expect the same results from mptbase, however
> > mptscsih driver should load without the panic
> > in mptscsih_init.  Please send dmesg if there
> > still are issues.
> 
> Hi Eric,
>  My failing Opteron system (IDE disk, no SCSI disk) now boots 
> with your
> 2.6.3 Fusion patch in place.  My good Opteron system (SCSI 
> disk, no IDE
> disk) also continues to boot with this patch in place.
> 
> Thanks!
> Joe
> 
> PS: Although booting, the boot messages from the once-failing system
> indicate some rather unnerving failures.  Should I be concerned?
> 
> 
> Fusion MPT base driver 3.00.04
> Copyright (c) 1999-2003 LSI Logic Corporation
> mptbase: Initiating ioc0 bringup
> mptbase: ioc0: ERROR - Doorbell ACK timeout(2)!
> mptbase: ioc0: ERROR - Diagnostic reset FAILED! (102h)
> mptbase: ioc0 NOT READY WARNING!
> mptbase: WARNING - ioc0 did not initialize properly! (-1)
> mptbase: probe of 0000:02:0a.0 failed with error -1
> mptbase: Initiating ioc0 bringup
> mptbase: ioc0: ERROR - Doorbell ACK timeout(2)!
> mptbase: ioc0: ERROR - Diagnostic reset FAILED! (102h)
> mptbase: ioc0 NOT READY WARNING!
> mptbase: WARNING - ioc0 did not initialize properly! (-1)
> mptbase: probe of 0000:02:0a.1 failed with error -1
> Fusion MPT SCSI Host driver 3.00.04
> 

Re: [BK PATCH] SCSI update for 2.6.3

[Joe Korty]

On Wed, Feb 25, 2004 at 11:46:00AM -0500, Moore, Eric Dean wrote:
> I don't see the banner displayed by the driver
> which would contain the FwRev, Ports, MaxQ, IRQ.
> I suspect hw/fw issues with the card itself.
> 
> What happens when you attach drives to the card;
> e.g. does the driver load then?
> 
> Can you upgrade your firmware to the latest.
> http://www.lsilogic.com/downloads/selectDownload.do


Hi Eric,
Problem solved.

The Fusion chip is soldered onto the motherboard.  I went into
the BIOS and discovered a little selection called (paraphrased)
'Execute LSI firmware' which was disabled.  When I enabled it,
all the boottime Fusion errors and warning went away.

This is a dual Opteron system branded 'Celsius' and made by
Fujitsu/Siemens.

It would be great if the driver could detect this and print
a 'is the LSI Fusion firmware enabled?' message in the log.

Regards, and thank you for looking into this,
Joe

RE: [BK PATCH] SCSI update for 2.6.3

[Moore, Eric Dean]

[-- Attachment #1: Type: text/plain, Size: 5099 bytes --]

Please try the attached patch.
Apply against the 2.6.3 kernel, which
comes with mpt fusion 3.00.02 driver.

I expect the same results from mptbase, however
mptscsih driver should load without the panic
in mptscsih_init.  Please send dmesg if there
still are issues.


Regards,
Eric Moore
Staff Engineer
Standard Storage Products Division
LSI Logic Corporation
4420 Arrowswest Drive
Colorado Springs, CO 80907
Email: emoore@lsil.com
Web: http://www.lsilogic.com/





On Tuesday, February 24, 2004 9:05 AM, Joe Korty wrote:
> 
> On Tue, Feb 24, 2004 at 09:34:25AM -0600, James Bottomley wrote:
> > On Tue, 2004-02-24 at 09:24, Joe Korty wrote:
> > >  I am getting a panic out of the 2.6.3 Fusion driver when 
> no devices
> > > are attached to it.  Does the above update fix it?  If so, I would
> > > like to get a copy of the above in patch form.  If not, I can send
> > > you a copy of my boot log.
> > 
> > Well, without a bug report I don't really have any idea.
> > 
> > The patch is here:
> > 
> > http://marc.theaimsgroup.com/?l=linux-scsi&m=107670916906716&w=2
> 
> 
> Hi James,
> Tried the patch, no luck.  The panic is on an Opteron board which has
> an IDE rather than a SCSI disk.  I have another system, 
> identical to the
> above, that has a SCSI rather than IDE disk, and it boots.  
> 2.6.1 boots
> on both systems.
> 
> Regards,
> Joe
> 
> 
> 
> ...
> Using anticipatory io scheduler
> FDC 0 is a post-1991 82077
> loop: loaded (max 8 devices)
> Intel(R) PRO/1000 Network Driver - version 5.2.30.1-k1
> Copyright (c) 1999-2004 Intel Corporation.
> tg3.c:v2.6 (February 3, 2004)
> eth0: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] 
> (PCI:33MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:51:d8:fd
> eth1: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] 
> (PCI:33MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:51:d8:fe
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override 
> with idebus=xx
> AMD8111: IDE controller at PCI slot 0000:00:07.1
> AMD8111: chipset revision 3
> AMD8111: not 100% native mode: will probe irqs later
> ide: Assuming 33MHz system bus speed for PIO modes; override 
> with idebus=xx
> AMD8111: 0000:00:07.1 (rev 03) UDMA133 controller
>     ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
>     ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
> hda: ST380011A, ATA DISK drive
> isa bounce pool size: 16 pages
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> hdc: CD-950E/TKU, ATAPI CD/DVD-ROM drive
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: max request size: 1024KiB
> hda: 156301488 sectors (80026 MB) w/2048KiB Cache, 
> CHS=16383/255/63, UDMA(100)
>  /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 >
> hdc: ATAPI 52X CD-ROM drive, 128kB Cache, DMA
> Uniform CD-ROM driver Revision: 3.20
> Red Hat/Adaptec aacraid driver (1.1.2-lk1 Feb 24 2004)
> Fusion MPT base driver 3.00.03
> Copyright (c) 1999-2003 LSI Logic Corporation
> mptbase: Initiating ioc0 bringup
> mptbase: ioc0: ERROR - Doorbell ACK timeout(2)!
> mptbase: ioc0: ERROR - Diagnostic reset FAILED! (102h)
> mptbase: ioc0 NOT READY WARNING!
> mptbase: WARNING - ioc0 did not initialize properly! (-1)
> mptbase: probe of 0000:02:0a.0 failed with error -1
> mptbase: Initiating ioc1 bringup
> mptbase: ioc1: ERROR - Doorbell ACK timeout(2)!
> mptbase: ioc1: ERROR - Diagnostic reset FAILED! (102h)
> mptbase: ioc1 NOT READY WARNING!
> mptbase: WARNING - ioc1 did not initialize properly! (-1)
> mptbase: probe of 0000:02:0a.1 failed with error -1
> Fusion MPT SCSI Host driver 3.00.03
> Unable to handle kernel NULL pointer dereference at 
> 0000000000000018 RIP: 
> <ffffffff80823a1f>{mptscsih_init+175}PML4 0 
> Oops: 0000 [1]
> CPU 0 
> Pid: 1, comm: swapper Not tainted
> RIP: 0010:[<ffffffff80823a1f>] <ffffffff80823a1f>{mptscsih_init+175}
> RSP: 0000:000001007afe1f18  EFLAGS: 00010202
> RAX: 0000000000000000 RBX: 00000100089a4d20 RCX: 000000000000000c
> RDX: 00000100089a4d20 RSI: ffffffff804546b0 RDI: 000001017fe1f398
> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
> R10: 000001017fdfa160 R11: 00000000000000c0 R12: 0000000000000000
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> FS:  0000000000000000(0000) GS:ffffffff807fa540(0000) 
> knlGS:0000000000000000
> CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000018 CR3: 0000000000101000 CR4: 00000000000006a0
> Process swapper (pid: 1, stackpage=10008898500)
> Stack: ffffffff8082fb70 ffffffff8080788d 0000000000000246 
> 0000000000000000 
>        0000000000000000 ffffffff8010b16e 0000000000000000 
> ffffffff8010fec7 
>        0000000000000000 0000000000000000 
> Call Trace:<ffffffff8080788d>{do_initcalls+77} 
> <ffffffff8010b16e>{init+110} 
>        <ffffffff8010fec7>{child_rip+8} <ffffffff8010b100>{init+0} 
>        <ffffffff8010febf>{child_rip+0} 
> 
> Code: 48 8b 70 18 e8 68 d4 c2 ff 48 89 df e8 50 66 c2 ff 48 85 c0 
> RIP <ffffffff80823a1f>{mptscsih_init+175} RSP <000001007afe1f18>
> CR2: 0000000000000018
>  <0>Kernel panic: Attempted to kill init!
> 


[-- Attachment #2: mptlinux-3.00.04.patch --]
[-- Type: application/octet-stream, Size: 11411 bytes --]

diff -uarN linux-2.6.3-ref/drivers/message/fusion/Kconfig linux-2.6.3/drivers/message/fusion/Kconfig
--- linux-2.6.3-ref/drivers/message/fusion/Kconfig	2004-02-17 20:59:59.000000000 -0700
+++ linux-2.6.3/drivers/message/fusion/Kconfig	2004-02-24 17:19:50.000000000 -0700
@@ -3,7 +3,6 @@
 
 config FUSION
 	tristate "Fusion MPT (base + ScsiHost) drivers"
-	depends on BLK_DEV_SD
 	---help---
 	  LSI Logic Fusion(TM) Message Passing Technology (MPT) device support
 	  provides high performance SCSI host initiator, and LAN [1] interface
@@ -14,41 +13,6 @@
 
 	  [1] LAN is not supported on parallel SCSI medium.
 
-	  These drivers require a Fusion MPT compatible PCI adapter installed
-	  in the host system.  MPT adapters contain specialized I/O processors
-	  to handle I/O workload, and more importantly to offload this work
-	  from the host CPU(s).
-
-	  If you have Fusion MPT hardware and want to use it, you can say
-	  Y or M here to add MPT (base + ScsiHost) drivers.
-	  <Y> = build lib (fusion), and link [static] into the kernel [2]
-	  proper
-	  <M> = compiled as [dynamic] modules [3] named: (mptbase,
-	  mptscsih)
-
-	  [2] In order enable capability to boot the linux kernel
-	  natively from a Fusion MPT target device, you MUST
-	  answer Y here! (currently requires CONFIG_BLK_DEV_SD)
-	  [3] To compile this support as modules, choose M here.
-
-	  If unsure, say N.
-
-	  If you say Y or M here you will get a choice of these
-	  additional protocol and support module options:         Module Name:
-	  <M>   Enhanced SCSI error reporting                     (isense)
-	  <M>   Fusion MPT misc device (ioctl) driver             (mptctl)
-	  <M>   Fusion MPT LAN driver                             (mptlan)
-
-	  ---
-	  Fusion MPT is trademark of LSI Logic Corporation, and its
-	  architecture is based on LSI Logic's Message Passing Interface (MPI)
-	  specification.
-
-config FUSION_BOOT
-	bool
-	depends on FUSION=y
-	default y
-
 config FUSION_MAX_SGE
 	int "Maximum number of scatter gather entries"
 	depends on FUSION
@@ -62,7 +26,6 @@
 	  necessary (or recommended) unless the user will be running 
 	  large I/O's via the raw interface.
 
-#  How can we force these options to module or nothing?
 config FUSION_ISENSE
 	tristate "Enhanced SCSI error reporting"
 	depends on MODULES && FUSION && m
@@ -132,17 +95,4 @@
 
 	  If unsure whether you really want or need this, say N.
 
-	  NOTES: This feature is NOT available nor supported for linux-2.2.x
-	  kernels.  You must be building a linux-2.3.x or linux-2.4.x kernel
-	  in order to configure this option.
-	  Support for building this feature into the linux kernel is not
-	  yet available.
-
-#  if [ "$CONFIG_FUSION_LAN" != "n" ]; then
-#    define_bool CONFIG_NET_FC y
-#  fi
-# These <should> be define_tristate, but we leave them define_bool
-# for backward compatibility with pre-linux-2.2.15 kernels.
-# (Bugzilla:fibrebugs, #384)
 endmenu
-
diff -uarN linux-2.6.3-ref/drivers/message/fusion/mptbase.c linux-2.6.3/drivers/message/fusion/mptbase.c
--- linux-2.6.3-ref/drivers/message/fusion/mptbase.c	2004-02-17 20:57:20.000000000 -0700
+++ linux-2.6.3/drivers/message/fusion/mptbase.c	2004-02-24 17:17:53.000000000 -0700
@@ -714,6 +714,7 @@
 			MptCallbacks[i] = cbfunc;
 			MptDriverClass[i] = dclass;
 			MptEvHandlers[i] = NULL;
+			MptDeviceDriverHandlers[i] = NULL;
 			last_drv_idx = i;
 			if (cbfunc != mpt_base_reply) {
 				mpt_inc_use_count();
@@ -838,11 +839,28 @@
 int
 mpt_device_driver_register(struct mpt_pci_driver * dd_cbfunc, int cb_idx)
 {
-	if (cb_idx < 1 || cb_idx >= MPT_MAX_PROTOCOL_DRIVERS)
-		return -1;
+	MPT_ADAPTER	*ioc;
+	int 		error=0;
+
+	if (cb_idx < 1 || cb_idx >= MPT_MAX_PROTOCOL_DRIVERS) {
+		error= -EINVAL;
+		return error;
+	}
 
 	MptDeviceDriverHandlers[cb_idx] = dd_cbfunc;
-	return 0;
+
+	/* call per pci device probe entry point */
+	for(ioc = mpt_adapter_find_first(); ioc != NULL;
+	  ioc = mpt_adapter_find_next(ioc)) {
+		if(dd_cbfunc->probe) {
+			error = dd_cbfunc->probe(ioc->pcidev,
+			  ioc->pcidev->driver->id_table);
+			if(error != 0)
+				return error;
+  		}
+	 }
+
+	return error;
 }
 
 /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
@@ -1497,14 +1515,20 @@
 			|| (ioc->chip_type == C1035) || (ioc->chip_type == FC929X))
 		mpt_detect_bound_ports(ioc, pdev);
 
-	if ((r = mpt_do_ioc_recovery(ioc, MPT_HOSTEVENT_IOC_BRINGUP, CAN_SLEEP)) != 0) {
-		printk(KERN_WARNING MYNAM ": WARNING - %s did not initialize properly! (%d)\n",
-				ioc->name, r);
-	}
-
-	if(r != 0 )
+	if ((r = mpt_do_ioc_recovery(ioc,
+	  MPT_HOSTEVENT_IOC_BRINGUP, CAN_SLEEP)) != 0) {
+		printk(KERN_WARNING MYNAM
+		  ": WARNING - %s did not initialize properly! (%d)\n",
+		  ioc->name, r);
+
+		Q_DEL_ITEM(ioc);
+		mpt_adapters[ioc->id] = NULL;
+		free_irq(ioc->pci_irq, ioc);
+		iounmap(mem);
+		kfree(ioc);
+		pci_set_drvdata(pdev, NULL);
 		return r;
-
+	}
 
 	/* call per device driver probe entry point */
 	for(ii=0; ii<MPT_MAX_PROTOCOL_DRIVERS; ii++) {
diff -uarN linux-2.6.3-ref/drivers/message/fusion/mptbase.h linux-2.6.3/drivers/message/fusion/mptbase.h
--- linux-2.6.3-ref/drivers/message/fusion/mptbase.h	2004-02-17 20:57:17.000000000 -0700
+++ linux-2.6.3/drivers/message/fusion/mptbase.h	2004-02-24 16:42:19.000000000 -0700
@@ -80,8 +80,8 @@
 #define COPYRIGHT	"Copyright (c) 1999-2003 " MODULEAUTHOR
 #endif
 
-#define MPT_LINUX_VERSION_COMMON	"3.00.02"
-#define MPT_LINUX_PACKAGE_NAME		"@(#)mptlinux-3.00.02"
+#define MPT_LINUX_VERSION_COMMON	"3.00.04"
+#define MPT_LINUX_PACKAGE_NAME		"@(#)mptlinux-3.00.04"
 #define WHAT_MAGIC_STRING		"@" "(" "#" ")"
 
 #define show_mptmod_ver(s,ver)  \
diff -uarN linux-2.6.3-ref/drivers/message/fusion/mptlan.c linux-2.6.3/drivers/message/fusion/mptlan.c
--- linux-2.6.3-ref/drivers/message/fusion/mptlan.c	2004-02-17 20:57:57.000000000 -0700
+++ linux-2.6.3/drivers/message/fusion/mptlan.c	2004-02-24 16:46:29.000000000 -0700
@@ -1437,7 +1437,7 @@
 	SET_MODULE_OWNER(dev);
 
 	if (register_netdev(dev) != 0) {
-		kfree(dev);
+		free_netdev(dev);
 		dev = NULL;
 	}
 	return dev;
diff -uarN linux-2.6.3-ref/drivers/message/fusion/mptscsih.c linux-2.6.3/drivers/message/fusion/mptscsih.c
--- linux-2.6.3-ref/drivers/message/fusion/mptscsih.c	2004-02-17 20:57:30.000000000 -0700
+++ linux-2.6.3/drivers/message/fusion/mptscsih.c	2004-02-24 16:40:51.000000000 -0700
@@ -197,11 +197,11 @@
 static int	mptscsih_setup(char *str);
 
 /* module entry point */
-static int  __init    mptscsih_init  (void);
-static void    mptscsih_exit  (void);
+static int  __init   mptscsih_init  (void);
+static void __exit   mptscsih_exit  (void);
 
-static int  __devinit mptscsih_probe (struct pci_dev *, const struct pci_device_id *);
-static void __devexit mptscsih_remove(struct pci_dev *);
+static int  mptscsih_probe (struct pci_dev *, const struct pci_device_id *);
+static void mptscsih_remove(struct pci_dev *);
 static void mptscsih_shutdown(struct device *);
 #ifdef CONFIG_PM
 static int mptscsih_suspend(struct pci_dev *pdev, u32 state);
@@ -1405,7 +1405,7 @@
  *
  */
 
-static int  __devinit
+static int
 mptscsih_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
 	struct Scsi_Host	*sh = NULL;
@@ -1418,6 +1418,7 @@
 	int			 numSGE = 0;
 	int			 scale;
 	u8			*mem;
+	int			error=0;
 
 	for (portnum=0; portnum < ioc->facts.NumberOfPorts; portnum++) {
 
@@ -1542,8 +1543,10 @@
 			 */
 			sz = hd->ioc->req_depth * sizeof(void *);
 			mem = kmalloc(sz, GFP_ATOMIC);
-			if (mem == NULL)
+			if (mem == NULL) {
+				error = -ENOMEM;
 				goto mptscsih_probe_failed;
+			}
 
 			memset(mem, 0, sz);
 			hd->ScsiLookup = (struct scsi_cmnd **) mem;
@@ -1551,15 +1554,19 @@
 			dprintk((MYIOC_s_INFO_FMT "ScsiLookup @ %p, sz=%d\n",
 				 ioc->name, hd->ScsiLookup, sz));
 
-			if (mptscsih_initChainBuffers(hd, 1) < 0)
+			if (mptscsih_initChainBuffers(hd, 1) < 0) {
+				error = -EINVAL;
 				goto mptscsih_probe_failed;
+			}
 
 			/* Allocate memory for free and doneQ's
 			 */
 			sz = sh->can_queue * sizeof(MPT_DONE_Q);
 			mem = kmalloc(sz, GFP_ATOMIC);
-			if (mem == NULL)
+			if (mem == NULL) {
+				error = -ENOMEM;
 				goto mptscsih_probe_failed;
+			}
 
 			memset(mem, 0xFF, sz);
 			hd->memQ = mem;
@@ -1591,8 +1598,10 @@
 			 */
 			sz = sh->max_id * sizeof(void *);
 			mem = kmalloc(sz, GFP_ATOMIC);
-			if (mem == NULL)
+			if (mem == NULL) {
+				error = -ENOMEM;
 				goto mptscsih_probe_failed;
+			}
 
 			memset(mem, 0, sz);
 			hd->Targets = (VirtDevice **) mem;
@@ -1683,7 +1692,8 @@
 
 			mpt_scsi_hosts++;
 
-			if(scsi_add_host (sh, &ioc->pcidev->dev)) {
+			error = scsi_add_host (sh, &ioc->pcidev->dev);
+			if(error) {
 				dprintk((KERN_ERR MYNAM,
 				  "scsi_add_host failed\n"));
 				goto mptscsih_probe_failed;
@@ -1691,7 +1701,6 @@
 
 			scsi_scan_host(sh);
 			return 0;
-
 		} /* scsi_host_alloc */
 
 	} /* for each adapter port */
@@ -1699,8 +1708,7 @@
 mptscsih_probe_failed:
 
 	mptscsih_remove(pdev);
-	return -ENODEV;
-
+	return error;
 }
 
 /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
@@ -1710,7 +1718,7 @@
  *
  *
  */
-static void __devexit
+static void
 mptscsih_remove(struct pci_dev *pdev)
 {
 	MPT_ADAPTER 		*ioc = pci_get_drvdata(pdev);
@@ -1828,6 +1836,7 @@
 	}
 
 	scsi_host_put(host);
+	mpt_scsi_hosts--;
 
 }
 
@@ -1911,7 +1920,7 @@
 
 static struct mpt_pci_driver mptscsih_driver = {
 	.probe		= mptscsih_probe,
-	.remove		= __devexit_p(mptscsih_remove),
+	.remove		= mptscsih_remove,
 	.shutdown	= mptscsih_shutdown,
 #ifdef CONFIG_PM
 	.suspend	= mptscsih_suspend,
@@ -1928,10 +1937,9 @@
  *
  *	Returns 0 for success, non-zero for failure.
  */
-static int
-__init mptscsih_init(void)
+static int __init
+mptscsih_init(void)
 {
-	MPT_ADAPTER		*ioc;
 
 	show_mptmod_ver(my_NAME, my_VERSION);
 
@@ -1939,12 +1947,6 @@
 	ScsiTaskCtx = mpt_register(mptscsih_taskmgmt_complete, MPTSCSIH_DRIVER);
 	ScsiScanDvCtx = mpt_register(mptscsih_scandv_complete, MPTSCSIH_DRIVER);
 
-	if(mpt_device_driver_register(&mptscsih_driver,
-	  MPTSCSIH_DRIVER) != 0 ) {
-		dprintk((KERN_INFO MYNAM
-		": failed to register dd callbacks\n"));
-	}
-
 	if (mpt_event_register(ScsiDoneCtx, mptscsih_event_process) == 0) {
 		dprintk((KERN_INFO MYNAM
 		  ": Registered for IOC event notifications\n"));
@@ -1961,20 +1963,13 @@
 		mptscsih_setup(mptscsih);
 #endif
 
-	/* probing for devices */
-	for(ioc = mpt_adapter_find_first(); ioc != NULL;
-	  ioc = mpt_adapter_find_next(ioc)) {
-		if(mptscsih_probe(ioc->pcidev, ioc->pcidev->driver->id_table)) {
-			dprintk((KERN_INFO MYNAM ": probe failed\n"));
-			return -ENODEV;
-		}
+	if(mpt_device_driver_register(&mptscsih_driver,
+	  MPTSCSIH_DRIVER) != 0 ) {
+		dprintk((KERN_INFO MYNAM
+		": failed to register dd callbacks\n"));
 	}
 
-	if (mpt_scsi_hosts > 0)
-		return 0;
-
-	mptscsih_exit();
-	return -ENODEV;
+	return 0;
 
 }
 
@@ -1984,7 +1979,7 @@
  *	mptscsih_exit - Unregisters MPT adapter(s)
  *
  */
-static void
+static void __exit
 mptscsih_exit(void)
 {
 	MPT_ADAPTER	*ioc;

Re: [BK PATCH] SCSI update for 2.6.3

[Joe Korty]

On Tue, Feb 24, 2004 at 07:23:32PM -0500, Moore, Eric Dean wrote:
> Please try the attached patch.
> Apply against the 2.6.3 kernel, which
> comes with mpt fusion 3.00.02 driver.
> 
> I expect the same results from mptbase, however
> mptscsih driver should load without the panic
> in mptscsih_init.  Please send dmesg if there
> still are issues.

Hi Eric,
 My failing Opteron system (IDE disk, no SCSI disk) now boots with your
2.6.3 Fusion patch in place.  My good Opteron system (SCSI disk, no IDE
disk) also continues to boot with this patch in place.

Thanks!
Joe

PS: Although booting, the boot messages from the once-failing system
indicate some rather unnerving failures.  Should I be concerned?


Fusion MPT base driver 3.00.04
Copyright (c) 1999-2003 LSI Logic Corporation
mptbase: Initiating ioc0 bringup
mptbase: ioc0: ERROR - Doorbell ACK timeout(2)!
mptbase: ioc0: ERROR - Diagnostic reset FAILED! (102h)
mptbase: ioc0 NOT READY WARNING!
mptbase: WARNING - ioc0 did not initialize properly! (-1)
mptbase: probe of 0000:02:0a.0 failed with error -1
mptbase: Initiating ioc0 bringup
mptbase: ioc0: ERROR - Doorbell ACK timeout(2)!
mptbase: ioc0: ERROR - Diagnostic reset FAILED! (102h)
mptbase: ioc0 NOT READY WARNING!
mptbase: WARNING - ioc0 did not initialize properly! (-1)
mptbase: probe of 0000:02:0a.1 failed with error -1
Fusion MPT SCSI Host driver 3.00.04

[BK PATCH] SCSI update for 2.6.3

[James Bottomley]

The current crop of accumulated patches are mainly driver updates and
bug fixes.

It is available at

bk://linux-scsi.bkbits.net/scsi-for-linus

The short changelog is:

<brking:us.ibm.com>:
  o SCSI: Make retries obey host_self_blocked flag

Andrew Vasquez:
  o qla2xxx -- FCP_RSP IU check during command completion
  o qla2xxx -- Properly schedule mailbox command timeouts

Christoph Hellwig:
  o move remaining definitions from drivers/scsi/scsi.h to include/scsi
  o fix up NCR5380 private data
  o fix up ini9100 interrupt handling
  o Remove CONFIG_SCSI_DC390T_NOGENSUPP
  o remove flush_cache_all() from qla1280

David S. Miller:
  o qla2xxx: remove flush_cache_all

Geert Uytterhoeven:
  o Sun-3x ESP SCSI clean up
  o NCR53C9x slave_{alloc,destroy}()

James Bottomley:
  o SCSI: 53c700: reduce default tag depth to 4
  o MPT Fusion driver 3.00.03 update

Kai Mäkisara:
  o Sysfs class support for SCSI tapes

Mark Haverkamp:
  o aacraid reset handler
  o add card types to aacraid driver

Patrick Mansfield:
  o have CONFIG_SCSI_PROC_FS depend on CONFIG_PROC_FS

James

Re: [BK PATCH] SCSI update for 2.6.3

[Linus Torvalds]

On Mon, 23 Feb 2004, James Bottomley wrote:
>
> Kai Mäkisara:
>   o Sysfs class support for SCSI tapes

Has this been checked for correctness, or will Al flame me to a crisp for 
accepting it? Pls verify..

		Linus

Re: [BK PATCH] SCSI update for 2.6.3

[Joe Korty]

On Mon, Feb 23, 2004 at 10:24:27PM -0600, James Bottomley wrote:
> The current crop of accumulated patches are mainly driver updates and
> bug fixes.
> 
> It is available at
> 
> bk://linux-scsi.bkbits.net/scsi-for-linus
> 
> The short changelog is:
> 
> James Bottomley:
>   o MPT Fusion driver 3.00.03 update

Hi James,
 I am getting a panic out of the 2.6.3 Fusion driver when no devices
are attached to it.  Does the above update fix it?  If so, I would
like to get a copy of the above in patch form.  If not, I can send
you a copy of my boot log.

Regards,
Joe

Re: [BK PATCH] SCSI update for 2.6.3

[James Bottomley]

On Tue, 2004-02-24 at 09:24, Joe Korty wrote:
>  I am getting a panic out of the 2.6.3 Fusion driver when no devices
> are attached to it.  Does the above update fix it?  If so, I would
> like to get a copy of the above in patch form.  If not, I can send
> you a copy of my boot log.

Well, without a bug report I don't really have any idea.

The patch is here:

http://marc.theaimsgroup.com/?l=linux-scsi&m=107670916906716&w=2

James

Re: [BK PATCH] SCSI update for 2.6.3

[Joe Korty]

On Tue, Feb 24, 2004 at 09:34:25AM -0600, James Bottomley wrote:
> On Tue, 2004-02-24 at 09:24, Joe Korty wrote:
> >  I am getting a panic out of the 2.6.3 Fusion driver when no devices
> > are attached to it.  Does the above update fix it?  If so, I would
> > like to get a copy of the above in patch form.  If not, I can send
> > you a copy of my boot log.
> 
> Well, without a bug report I don't really have any idea.
> 
> The patch is here:
> 
> http://marc.theaimsgroup.com/?l=linux-scsi&m=107670916906716&w=2


Hi James,
Tried the patch, no luck.  The panic is on an Opteron board which has
an IDE rather than a SCSI disk.  I have another system, identical to the
above, that has a SCSI rather than IDE disk, and it boots.  2.6.1 boots
on both systems.

Regards,
Joe



...
Using anticipatory io scheduler
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 5.2.30.1-k1
Copyright (c) 1999-2004 Intel Corporation.
tg3.c:v2.6 (February 3, 2004)
eth0: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:51:d8:fd
eth1: Tigon3 [partno(BCM95704A7) rev 2003 PHY(5704)] (PCI:33MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:51:d8:fe
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD8111: IDE controller at PCI slot 0000:00:07.1
AMD8111: chipset revision 3
AMD8111: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD8111: 0000:00:07.1 (rev 03) UDMA133 controller
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: ST380011A, ATA DISK drive
isa bounce pool size: 16 pages
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: CD-950E/TKU, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 1024KiB
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 >
hdc: ATAPI 52X CD-ROM drive, 128kB Cache, DMA
Uniform CD-ROM driver Revision: 3.20
Red Hat/Adaptec aacraid driver (1.1.2-lk1 Feb 24 2004)
Fusion MPT base driver 3.00.03
Copyright (c) 1999-2003 LSI Logic Corporation
mptbase: Initiating ioc0 bringup
mptbase: ioc0: ERROR - Doorbell ACK timeout(2)!
mptbase: ioc0: ERROR - Diagnostic reset FAILED! (102h)
mptbase: ioc0 NOT READY WARNING!
mptbase: WARNING - ioc0 did not initialize properly! (-1)
mptbase: probe of 0000:02:0a.0 failed with error -1
mptbase: Initiating ioc1 bringup
mptbase: ioc1: ERROR - Doorbell ACK timeout(2)!
mptbase: ioc1: ERROR - Diagnostic reset FAILED! (102h)
mptbase: ioc1 NOT READY WARNING!
mptbase: WARNING - ioc1 did not initialize properly! (-1)
mptbase: probe of 0000:02:0a.1 failed with error -1
Fusion MPT SCSI Host driver 3.00.03
Unable to handle kernel NULL pointer dereference at 0000000000000018 RIP: 
<ffffffff80823a1f>{mptscsih_init+175}PML4 0 
Oops: 0000 [1]
CPU 0 
Pid: 1, comm: swapper Not tainted
RIP: 0010:[<ffffffff80823a1f>] <ffffffff80823a1f>{mptscsih_init+175}
RSP: 0000:000001007afe1f18  EFLAGS: 00010202
RAX: 0000000000000000 RBX: 00000100089a4d20 RCX: 000000000000000c
RDX: 00000100089a4d20 RSI: ffffffff804546b0 RDI: 000001017fe1f398
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: 000001017fdfa160 R11: 00000000000000c0 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffffff807fa540(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000018 CR3: 0000000000101000 CR4: 00000000000006a0
Process swapper (pid: 1, stackpage=10008898500)
Stack: ffffffff8082fb70 ffffffff8080788d 0000000000000246 0000000000000000 
       0000000000000000 ffffffff8010b16e 0000000000000000 ffffffff8010fec7 
       0000000000000000 0000000000000000 
Call Trace:<ffffffff8080788d>{do_initcalls+77} <ffffffff8010b16e>{init+110} 
       <ffffffff8010fec7>{child_rip+8} <ffffffff8010b100>{init+0} 
       <ffffffff8010febf>{child_rip+0} 

Code: 48 8b 70 18 e8 68 d4 c2 ff 48 89 df e8 50 66 c2 ff 48 85 c0 
RIP <ffffffff80823a1f>{mptscsih_init+175} RSP <000001007afe1f18>
CR2: 0000000000000018
 <0>Kernel panic: Attempted to kill init!