This morning I had a couple of segfaults on a tgtd 0.9.5 (plus sendtargets discovery patch from http://markmail.org/message/73qqira2iu2vx5bw) that I've just started using in earnest. It ran fine under load for a while, but then 2009 Apr 8 02:58:03 kernel@1 tgtd[11738] general protection ip:408fef sp:7f790e054f40 error:0 in tgtd[400000+da000] and later 2009 Apr 8 07:32:30 kernel@1 tgtd[23022] trap stack segment ip:40c646 sp:7fff22787b20 error:0 In each case, one tgtd was left out of the normal pair of processes with tgtadm hanging for (e.g.) -o show -m target. A kill -9 of tgtd followed by a restart and re-export fixed the problem. Whilst examining the machine, I noticed that I'd accidentally started a tgtd without the scsi_tgt kernel module, which wasn't in /proc/modules. However, tgtd had been working despite this, which baffled me a bit---I assumed that scsi_tgt was the kernel component of tgtd? Does tgtd run completely in userspace in the absence of scsi_tgt? If so, is there a way to tell whether or not a particular tgtd is using the kernel module? Are the segfaults likely to be related to running tgtd without the kernel module? If not, I imagine they could potentially be connected to the issue reported yesterday in http://markmail.org/thread/6qcocaxrlya6iwm5 as I'm using the tgtd as part of a storage migration, the backend devices are also RAID in my case (behind a couple of layers of device mapper), and are they are prone to run slowly or even hang briefly under high IO load. Cheers, Chris. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
