On Wed, 8 Apr 2009 10:09:15 +0100 Chris Webb <chris@xxxxxxxxxxxx> wrote: > 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? tgt's iSCSI code runs in user space (that is, doesn't need tgt's kernel module). In your case, one of tgt's two processes crashed due to segmentation fault, I guess. I'm in San Francisco for Linux conferences. So it's hard to debug the problem. I'll do next week. Thanks, -- 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
