class_device_add error in SCSI with 2.6.17-rc2-g52824b6b

class_device_add error in SCSI with 2.6.17-rc2-g52824b6b

[Mathieu Chouquet-Stringer]

	Hello James,

While booting 2.6.17-rc2-g52824b6b on an alpha (a 164LX clone), I get
the following error messages for every sd devices that get registered:

sd 0:0:0:0: Attached scsi disk sda
kobject_add failed for 0:0: with -EEXIST, don't try to register things with the same name in the same directory.
fffffc0000e4bc88 0000000000100100 fffffc000045c398 fffffc0000ec9910 
       fffffc0000ec9910 0000000000000000 fffffc0000688080 0000000000100100 
       fffffc0000488b84 fffffc0000ec9910 fffffc0000ec9500 fffffc0000ec9900 
       fffffc0000ec1800 0000000000000000 fffffc0000ec18e8 fffffc0000ec1a18 
       0000000000000000 ffffffffffffffea fffffc000045ac8c fffffc0000ec18e8 
       0000000000000000 fffffc0000687f50 fffffc0000683d48 0000000000000000 
Trace:
[<fffffc000045c398>] class_device_add+0xb4/0x388
[<fffffc0000488b84>] sd_probe+0x154/0x4cc
[<fffffc000045ac8c>] driver_probe_device+0x6c/0xf0
[<fffffc000045ae90>] __driver_attach+0x9c/0x11c
[<fffffc0000459bac>] bus_for_each_dev+0x5c/0xb0
[<fffffc000045adf4>] __driver_attach+0x0/0x11c
[<fffffc000045af3c>] driver_attach+0x2c/0x40
[<fffffc000045a390>] bus_add_driver+0xa8/0x1d4
[<fffffc000045b644>] driver_register+0xa8/0xc0
[<fffffc0000476018>] scsi_register_driver+0x24/0x38
[<fffffc0000310200>] init+0x11c/0x360
[<fffffc0000311598>] kernel_thread+0x28/0x90
[<fffffc0000311580>] kernel_thread+0x10/0x90


Looking at 'git whatchanged' for drivers/scsi/sd.c, I guess (just a wild
guess, I'll bisect tomorrow if needed) this patch probably broke the
whole thing:

diff-tree 6bdaa1f17dd32ec62345c7b57842f53e6278a2fa (from
5baba830e93732e802dc7e0a362eb730e1917f58)
Author: James Bottomley <James.Bottomley@steeleye.com>
Date:   Sat Mar 18 14:14:21 2006 -0600

    [SCSI] allow displaying and setting of cache type via sysfs

    I think I promised to do this two years ago

    This patch adds a scsi_disk class with the cache type and FUA
    parameters, so user land application can easily obtain them without
    having to parse dmesg.  It also allows setting the cache type (use with
    care...)

    This patch is a bit dangerous because I've replaced the disk kref with a
    class device reference ...

    Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>


Looking at the backtrace, this portion of the patch appears to be
failing:

@@ -1566,7 +1642,16 @@ static int sd_probe(struct device *dev)
        if (error)
                goto out_put;

+       class_device_initialize(&sdkp->cdev);
+       sdkp->cdev.dev = &sdp->sdev_gendev;
+       sdkp->cdev.class = &sd_disk_class;
+       strncpy(sdkp->cdev.class_id, sdp->sdev_gendev.bus_id, BUS_ID_SIZE);
+
+       if (class_device_add(&sdkp->cdev))
+               goto out_put;
+
        get_device(&sdp->sdev_gendev);
+
        sdkp->device = sdp;
        sdkp->driver = &sd_template;
        sdkp->disk = gd;


I'll look some more at the whole thing tomorrow as I'm not familiar at
all with kobject/sysfs...

Cheers,

-- 
Mathieu Chouquet-Stringer                         mchouque@free.fr

Re: class_device_add error in SCSI with 2.6.17-rc2-g52824b6b

[Bob Tracy]

Mathieu Chouquet-Stringer wrote:
> While booting 2.6.17-rc2-g52824b6b on an alpha (a 164LX clone), I get
> the following error messages for every sd devices that get registered:
> 
> sd 0:0:0:0: Attached scsi disk sda
> kobject_add failed for 0:0: with -EEXIST, don't try to register things with the same name in the same directory.

Similar error previously reported by me for 2.6.17-rc1, except sda got
added fine: error occurred when attempting to add/register sdb. 
Thankfully, you were able to append a trace...

I'll be trying the just-released 2.6.17-rc2 this evening.  Report to
follow, and if there's a problem, I'll attempt to provide the trace
(will have to be transcribed by hand, as system won't come up far
enough for syslog to capture anything).

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: class_device_add error in SCSI with 2.6.17-rc2-g52824b6b

[Mathieu Chouquet-Stringer]

On Wed, Apr 19, 2006 at 04:58:03PM -0500, Bob Tracy wrote:
> Similar error previously reported by me for 2.6.17-rc1, except sda got
> added fine: error occurred when attempting to add/register sdb. 

Actually you're right. I'm rereading the logs and the first device on a
scsi bus is always registered correctly. The sh*t hits the fan when you
have more than one sd device per bus. (I've got 2 devices on one, and 3
on the other and only the first one on each got registered correctly).

> Thankfully, you were able to append a trace...

I used the serial console.

> I'll be trying the just-released 2.6.17-rc2 this evening.  Report to
> follow, and if there's a problem, I'll attempt to provide the trace
> (will have to be transcribed by hand, as system won't come up far
> enough for syslog to capture anything).

If syslog doesn't come up and depending on the state of your system you
could redirect dmesg output to a file.
-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr

Re: class_device_add error in SCSI with 2.6.17-rc2-g52824b6b

[Mathieu Chouquet-Stringer]

On Wed, Apr 19, 2006 at 04:58:03PM -0500, Bob Tracy wrote:
> Similar error previously reported by me for 2.6.17-rc1, except sda got
> added fine: error occurred when attempting to add/register sdb. 
> Thankfully, you were able to append a trace...

In my case, I was able to solve the problem by replacing this call at
line 1648 in drivers/scsi/sd.c (patch attached):
strncpy(sdkp->cdev.class_id, sdp->sdev_gendev.bus_id, BUS_ID_SIZE);

by

snprintf(sdkp->cdev.class_id, BUS_ID_SIZE, "%s", sdp->sdev_gendev.bus_id);

Then it works.

While debugging the whole thing, I was printk'ing the value of
sdkp->cdev.class_id right after the strncpy call and here's what I
getting (basically only the first 4 chars + final \0): 
"0:0:"

So I guess the strncpy routine on alpha is fscked up or gcc is doing
something crazy. The function is under arch/alpha/lib/strncpy.S, time to
learn assembly.


--- linux-2.6/drivers/scsi/sd.c	2006-03-28 13:28:24.000000000 +0200
+++ linux-2.6-mat/drivers/scsi/sd.c	2006-04-20 12:12:36.000000000 +0200
@@ -1645,7 +1645,8 @@
 	class_device_initialize(&sdkp->cdev);
 	sdkp->cdev.dev = &sdp->sdev_gendev;
 	sdkp->cdev.class = &sd_disk_class;
-	strncpy(sdkp->cdev.class_id, sdp->sdev_gendev.bus_id, BUS_ID_SIZE);
+	snprintf(sdkp->cdev.class_id, BUS_ID_SIZE, "%s",
+		sdp->sdev_gendev.bus_id);
 
 	if (class_device_add(&sdkp->cdev))
 		goto out_put;


-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr
    "Le disparu, si l'on vénère sa mémoire, est plus présent et
                 plus puissant que le vivant".
           -- Antoine de Saint-Exupéry, Citadelle --

-
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: class_device_add error in SCSI with 2.6.17-rc2-g52824b6b

[Mathieu Chouquet-Stringer]

On Thu, Apr 20, 2006 at 12:14:48PM +0200, Mathieu Chouquet-Stringer wrote:
> So I guess the strncpy routine on alpha is fscked up or gcc is doing
> something crazy. The function is under arch/alpha/lib/strncpy.S, time to
> learn assembly.

Replying to myself here, i've created the following test program and
redefined strncpy to mystrncpy (I used strncpy.S and stxncpy.S from
arch/alpha/lib):

=============================================================================
#include <stdio.h>
#include <string.h>
#define FOO 50

extern char *mystrncpy(char *dest, const char *src, size_t count);

int main(int argc, char **argv)
{

	char src[FOO] = "";
	char dest[FOO];
	char letter[] = "a";
	int i;

	for (i = 0; i < FOO - 1; i++) {
		size_t beflen, aftlen;

		letter[0] = 'a' + i;
		strncat(src, letter, FOO);
		beflen = strlen(src);

		mystrncpy(dest, src, FOO);
		aftlen = strlen(dest);
		if (beflen != aftlen)
			printf("fails for strlen = %ld (copied %ld)\n",
				beflen, aftlen);
	}


	return 0;
}
=============================================================================

And here's the output using gcc version 3.4.4 (Gentoo 3.4.4-r1,
ssp-3.4.4-1.0, pie-8.7.8), note i didn't use flag except -Wall:

fails for strlen = 3 (copied 2)
fails for strlen = 4 (copied 2)
fails for strlen = 5 (copied 2)
fails for strlen = 6 (copied 2)
fails for strlen = 7 (copied 2)
fails for strlen = 11 (copied 10)
fails for strlen = 12 (copied 10)
fails for strlen = 13 (copied 10)
fails for strlen = 14 (copied 10)
fails for strlen = 15 (copied 10)
fails for strlen = 19 (copied 18)
fails for strlen = 20 (copied 18)
fails for strlen = 21 (copied 18)
fails for strlen = 22 (copied 18)
fails for strlen = 23 (copied 18)
fails for strlen = 27 (copied 26)
fails for strlen = 28 (copied 26)
fails for strlen = 29 (copied 26)
fails for strlen = 30 (copied 26)
fails for strlen = 31 (copied 26)
fails for strlen = 35 (copied 34)
fails for strlen = 36 (copied 34)
fails for strlen = 37 (copied 34)
fails for strlen = 38 (copied 34)
fails for strlen = 39 (copied 34)
fails for strlen = 43 (copied 42)
fails for strlen = 44 (copied 42)
fails for strlen = 45 (copied 42)
fails for strlen = 46 (copied 42)
fails for strlen = 47 (copied 42)


So much for this function...  I'll look at the assembly to see if I can
understand what's going on: it always copy a multiple of 8 + 2 bytes (as
in 8x + 2).
-- 
Mathieu Chouquet-Stringer                           mchouque@free.fr