On Fri, 23 Dec 2005, James Bottomley wrote:
> On Fri, 2005-12-23 at 12:05 -0800, Andrew Vasquez wrote:
> > EIP is at sysfs_hash_and_remove+0x31/0x11f
> > eax: 00000000 ebx: 6b6b6b6b ecx: 00000000 edx: ee6aac68
> > esi: 6b6b6b6b edi: f8839d44 ebp: f8839cc0 esp: c1af7e98
> > ds: 007b es: 007b ss: 0068
> > Process events/2 (pid: 16, threadinfo=c1af7000 task=c1aef030)
> > Stack: c03998d2 00000063 eb6a0e2c eb6a0e24 f8839d44 f8839cc0 c025877b e640aac0
> > ee000f5c ee000f5c 00000000 f8839cc0 f332e178 eb6a0e24 c025ab08 c025ab39
> > eb6a0e24 c0370606 eb6a0e00 f332e178 c1af7f00 e5a872dc c025a722 f332e178
> > Call Trace:
> > [<c025877b>] class_device_del+0x138/0x163
> > [<c025ab08>] transport_remove_classdev+0x0/0x68
>
> This one is the signal for class devices being deleted *after* the
> underlying device has been deleted, so the class device delete oopses
> trying to remove the symlink from the real device to the class device.
>
> Strange it should show up now, since that particular piece of code
> hasn't been altered, just moved into a work queue.
Yes, that does seem odd..
> See if the attached fixes it (if it does, I'm mystified as to why you
> haven't always seen this).
>
> James
>
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -418,8 +418,9 @@ static void scsi_target_reap_work(void *
> if (--starget->reap_ref == 0 && list_empty(&starget->devices)) {
> list_del_init(&starget->siblings);
> spin_unlock_irqrestore(shost->host_lock, flags);
> + transport_remove_device(&starget->dev);
> device_del(&starget->dev);
> - transport_unregister_device(&starget->dev);
> + transport_destroy_device(&starget->dev);
> put_device(&starget->dev);
> return;
This fixes the OOPS during unload problem... Now the interesting
question... why...
--
av
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
