I have settled down the issue caused by the uninitialized the struct work_struct before getting invoked. Actually I use the worker queue mechanism to implement the hot remove and hot plug function, not the scsi_queue_work(). Is adopting the scsi_queue_work() preferable to my RAID driver? Thank you for the response. -----Original Message----- From: James Bottomley [mailto:James.Bottomley@xxxxxxxxxxxxxxxxxxxxx] Sent: Wednesday, May 28, 2008 10:25 PM To: nick.cheng@xxxxxxxxxxxx Subject: RE: The issue for scsi device hotplug and hot-remove On Sat, 2008-05-24 at 14:45 +0800, nickcheng wrote: > Hi James, > Sorry to bother you again. You'd get a faster turn around on this if you mailed the scsi list, since I've been away for a week. > I study a kernel book and it says it is not allowed create new kernel thread > by kernel org fellows. > I am not sure whether it is just a groundless talk. > Because I would like to implement the discovery of scsi device hot remove > and insert, I try to use the event worker thread in default but get the core > dump as the attachment. > I am not very sure what is the root cause but because it says "kernel BUG at > kernel/workqueue.c:104", I guess it could be the conflict with some modules > in the kernel code, but just a wild guess. > If you like, please throw me some light. Without the traces, it's generally pretty impossible to do that. There's no bar on using kernel threads per se. However, we do already have an existing hotplug system for the adding and removing of SCSI devices. For instance, the SAS library does all of this (hotplug add and remove) using scsi_queue_work rather than using a separate thread (although technically this does cause SCSI to spawn a separate workqueue thread per host). James -- To unsubscribe from this list: 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
