Olaf Hering wrote:
> 1:mon> d c0000000024cacc8
> c0000000024cacc8 00000000dead4ead ffffffff00000000 |......N.........|
> c0000000024cacd8 ffffffffffffffff c0000000024cace0 |.............L..|
> c0000000024cace8 c0000000024cace0 c000000000614f68 |.....L.......aOh|
> c0000000024cacf8 c000000000614f38 0000000000000000 |.....aO8........|
> c0000000024cad08 0000000000000000 0000000000000000 |................|
> c0000000024cad18 0000000000000000 0000000000000000 |................|
> c0000000024cad28 0000000000000000 0000000000000000 |................|
> c0000000024cad38 0000000000000000 0000000000000000 |................|
> c0000000024cad48 0000000000000000 0000000000000000 |................|
> c0000000024cad58 0000000000000000 0000000000000000 |................|
> c0000000024cad68 0000000000000000 0000000000000000 |................|
> c0000000024cad78 0000000000000000 0000000000000000 |................|
> c0000000024cad88 0000000000000000 0000000000000000 |................|
> c0000000024cad98 0000000000000000 0000000000000000 |................|
> c0000000024cada8 0000000000000000 0000000000000000 |................|
> c0000000024cadb8 0000000000000000 0000000000000000 |................|
> c0000000024cadc8 0000000000000000 0000000000000000 |................|
> c0000000024cadd8 0000000000000000 0000000000000000 |................|
I've now seen a couple recreates of this problem on various systems in
our labs, and there are always a bunch of zeroes in the struct device
in the same place as above. I wonder if perhaps the call to device_add
is failing in scsi_alloc_target. Failure of this call is not being handled
today. Can you give the attached patch a try?
> c0000000024cade8 0000000000000000 c00000000303a1a8 |................|
> c0000000024cadf8 c0000000024cae00 746172676574303a |.....L..target0:|
> c0000000024cae08 3235353a31303000 0000000000000006 |255:100.........|
> c0000000024cae18 c0000000024cae18 c0000000024cae18 |.....L.......L..|
> c0000000024cae28 c00000000303a2d8 c000000000500c88 |.............P..|
> c0000000024cae38 0000000000000000 0000000000000000 |................|
> c0000000024cae48 746172676574303a 3235353a31303000 |target0:255:100.|
> c0000000024cae58 0000000000000000 0000000000000000 |................|
> c0000000024cae68 0000000000000000 0000000000000000 |................|
> c0000000024cae78 0000000000000000 0000000000000000 |................|
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
Signed-off-by: Brian King <brking@xxxxxxxxxx>
---
linux-2.6-bjking1/drivers/scsi/scsi_scan.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff -puN drivers/scsi/scsi_scan.c~scsi_alloc_target_device_add_failure drivers/scsi/scsi_scan.c
--- linux-2.6/drivers/scsi/scsi_scan.c~scsi_alloc_target_device_add_failure 2006-02-20 14:55:13.000000000 -0600
+++ linux-2.6-bjking1/drivers/scsi/scsi_scan.c 2006-02-20 16:51:15.000000000 -0600
@@ -361,7 +361,15 @@ static struct scsi_target *scsi_alloc_ta
spin_unlock_irqrestore(shost->host_lock, flags);
/* allocate and add */
transport_setup_device(dev);
- device_add(dev);
+ if (device_add(dev)) {
+ spin_lock_irqsave(shost->host_lock, flags);
+ list_del_init(&starget->siblings);
+ spin_unlock_irqrestore(shost->host_lock, flags);
+ transport_destroy_device(dev);
+ put_device(parent);
+ kfree(starget);
+ return NULL;
+ }
transport_add_device(dev);
if (shost->hostt->target_alloc) {
int error = shost->hostt->target_alloc(starget);
@@ -403,7 +411,6 @@ static void scsi_target_reap_usercontext
transport_destroy_device(&starget->dev);
put_device(&starget->dev);
return;
-
}
spin_unlock_irqrestore(shost->host_lock, flags);
_
