Is this a known problem on 2.5.42 ? Happens all the time with rmmod.
- Badari
kernel BUG at drivers/base/core.c:251!
invalid operand: 0000
qla2200
CPU: 0
EIP: 0060:[<c023eb24>] Not tainted
EFLAGS: 00010202
EIP is at put_device+0x64/0x90
eax: 00000000 ebx: f8a08028 ecx: f8a080c4 edx: 00000001
esi: c3aded54 edi: f8a08000 ebp: 00000003 esp: cb007ee4
ds: 0068 es: 0068 ss: 0068
Process rmmod (pid: 4803, threadinfo=cb006000 task=f62c98c0)
Stack: f8a08028 c0477a40 c02ce533 f8a08028 f8a08028 c0477b5c f8a08028 c0477b6c
00000000 40153f6d 00000286 f68fc000 c0477a40 c3adec00 f4df0000 c02a7a9a
c3adec00 cb007f30 00000002 00030002 00000001 08071002 c041685c 08070ffd
Call Trace:
[<c02ce533>] sg_detach+0x1e3/0x210
[<c02a7a9a>] scsi_unregister_host+0x26a/0x5d0
[<c01f4736>] __generic_copy_to_user+0x56/0x80
[<c013e4e8>] __alloc_pages+0x98/0x270
[<f89e7cba>] exit_this_scsi_driver+0xa/0x10 [qla2200]
[<f8a00360>] driver_template+0x0/0x74 [qla2200]
[<c011ea0e>] free_module+0x1e/0x130
[<c011dc94>] sys_delete_module+0x1b4/0x410
[<c01075e3>] syscall_call+0x7/0xb
Code: 0f 0b fb 00 6c 3e 3c c0 8b 83 d4 00 00 00 85 c0 74 04 53 ff
--
Badari Pulavarty
[email protected]
IBM Linux Technology Center - Kernel Team
On Tue, Oct 15, 2002 at 10:24:18AM -0700, Badari Pulavarty wrote:
> Is this a known problem on 2.5.42 ? Happens all the time with rmmod.
>
> - Badari
I hit a similiar bug for the put_device(&shpnt->host_driverfs_dev) of the
Scsi_Host, here's a patch for the scsi changes, I can't fully test it
since my devices seen via insmod aren't showing up properly right now, but
rmmod works, and the scsi remove-single-device also works without BUG-ing
or doing other bad things by leaving a dev model reference around:
--- linux-2.5.42/drivers/scsi/st.c Fri Oct 11 21:22:11 2002
+++ linux-2.5.42-scsi-unreg/drivers/scsi/st.c Tue Oct 15 10:49:14 2002
@@ -3909,12 +3909,12 @@
&dev_attr_type);
device_remove_file(&tpnt->driverfs_dev_r[mode],
&dev_attr_kdev);
- put_device(&tpnt->driverfs_dev_r[mode]);
+ device_unregister(&tpnt->driverfs_dev_r[mode]);
device_remove_file(&tpnt->driverfs_dev_n[mode],
&dev_attr_type);
device_remove_file(&tpnt->driverfs_dev_n[mode],
&dev_attr_kdev);
- put_device(&tpnt->driverfs_dev_n[mode]);
+ device_unregister(&tpnt->driverfs_dev_n[mode]);
}
if (tpnt->buffer) {
tpnt->buffer->orig_frp_segs = 0;
--- linux-2.5.42/drivers/scsi/sg.c Fri Oct 11 21:22:07 2002
+++ linux-2.5.42-scsi-unreg/drivers/scsi/sg.c Tue Oct 15 10:49:29 2002
@@ -1611,7 +1611,7 @@
sdp->de = NULL;
device_remove_file(&sdp->sg_driverfs_dev, &dev_attr_type);
device_remove_file(&sdp->sg_driverfs_dev, &dev_attr_kdev);
- put_device(&sdp->sg_driverfs_dev);
+ device_unregister(&sdp->sg_driverfs_dev);
if (NULL == sdp->headfp)
vfree((char *) sdp);
}
--- linux-2.5.42/drivers/scsi/scsi.c Fri Oct 11 21:22:08 2002
+++ linux-2.5.42-scsi-unreg/drivers/scsi/scsi.c Tue Oct 15 10:49:51 2002
@@ -1965,6 +1965,7 @@
if (HBA_ptr->hostt->slave_detach)
(*HBA_ptr->hostt->slave_detach) (scd);
devfs_unregister (scd->de);
+ device_unregister(&scd->sdev_driverfs_dev);
scsi_release_commandblocks(scd);
/* Now we can remove the device structure */
@@ -2254,7 +2255,7 @@
if (shpnt->hostt->slave_detach)
(*shpnt->hostt->slave_detach) (SDpnt);
devfs_unregister (SDpnt->de);
- put_device(&SDpnt->sdev_driverfs_dev);
+ device_unregister(&SDpnt->sdev_driverfs_dev);
}
}
@@ -2305,7 +2306,7 @@
/* Remove the /proc/scsi directory entry */
sprintf(name,"%d",shpnt->host_no);
remove_proc_entry(name, tpnt->proc_dir);
- put_device(&shpnt->host_driverfs_dev);
+ device_unregister(&shpnt->host_driverfs_dev);
if (tpnt->release)
(*tpnt->release) (shpnt);
else {
Hi. Sorry about the delay; I'm slowly wading through the last week's
email.
> kernel BUG at drivers/base/core.c:251!
> invalid operand: 0000
> qla2200
> CPU: 0
> EIP: 0060:[<c023eb24>] Not tainted
> EFLAGS: 00010202
> EIP is at put_device+0x64/0x90
> eax: 00000000 ebx: f8a08028 ecx: f8a080c4 edx: 00000001
> esi: c3aded54 edi: f8a08000 ebp: 00000003 esp: cb007ee4
> ds: 0068 es: 0068 ss: 0068
> Process rmmod (pid: 4803, threadinfo=cb006000 task=f62c98c0)
> Stack: f8a08028 c0477a40 c02ce533 f8a08028 f8a08028 c0477b5c f8a08028 c0477b6c
> 00000000 40153f6d 00000286 f68fc000 c0477a40 c3adec00 f4df0000 c02a7a9a
> c3adec00 cb007f30 00000002 00030002 00000001 08071002 c041685c 08070ffd
> Call Trace:
> [<c02ce533>] sg_detach+0x1e3/0x210
put_device() as a means to unregister a device should not be used any
longer. There is a now a device_unregister() function that marks the
device as !present, then decrements the reference count. Once the refcount
hits 0, the device is cleaned up as before.
The BUG() was added to catch people still using the wrong call. The SCSI
patch that Mike Anderson posted last night should have this fixed in it.
-pat
Patrick Mochel [[email protected]] wrote:
> The BUG() was added to catch people still using the wrong call. The SCSI
> patch that Mike Anderson posted last night should have this fixed in it.
I removed the scsi mid layer ones in my patch.
Patrick Mansfield re-posted a patch yesterday to cover the sg and other
scsi upper level drivers not alreay corrected. Here is a pointer to
Patrick's mail.
http://marc.theaimsgroup.com/?l=linux-kernel&m=103479992624108&w=2
-andmike
--
Michael Anderson
[email protected]