Date: Wed, 12 Dec 2007 12:54:46 -0800 From: Sean Bruno <sbruno@miralink.com> To: Nate Lawson <nate@root.org> Cc: Hidetoshi Shimokawa <simokawa@FreeBSD.ORG>, freebsd-firewire@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: scsi_target witness lock error Message-ID: <47604A96.6020401@miralink.com> In-Reply-To: <4760446D.2060102@root.org> References: <1197420795.2738.6.camel@iago.office.miralink.com> <86sl28snpe.wl%simokawa@FreeBSD.ORG> <1197425759.14437.0.camel@home-desk> <626eb4530712111837y4608e919w845461d36a18118f@mail.gmail.com> <475F5669.1010800@miralink.com> <476034FE.7080003@miralink.com> <4760446D.2060102@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Lawson wrote: > Sean Bruno wrote: > >> Alrighty, a little cleaner patch to allow sbp_targ.c to acutally work >> under RELENG_6. http://www.consultcsg.com/RELENG_6.diff >> >> Also and update with the witness error. And the kernel config I am using: >> http://www.consultcsg.com/scsitarget_witness.txt >> http://www.consultcsg.com/FIREWIRE_TGT >> >> Is scsi_target the only application that is making this kern env witness >> error appear? I find it hard to believe that nothing else in the code >> base hits this type of problem? >> > > Apparently scsi_target wasn't fully tested when the CAM locking went in. > It was written before there was a design for CAM locking so it may need > some reworking. For example, it assumes that it should acquire/drop > locks multiple times in its start method if there are multiple CCBs > queued. That may not be the fastest way, depending on contention for > the SIM lock. > > Hmmm...I just applied(ripped off!) a RELENG_7 modifed version of kern_environment.c that uses non-sleepable mutex's and the witness went away. http://www.consultcsg.com/kern_env.diff It appears that you are on to something Nate with regard to the CAM locking. scsi_target appears to be blocking on a call to cam_periph_lock(): http://www.consultcsg.com/cam_periph_lock.txt Hidetoshi suggested a patch that I will now apply and retest: http://consultcsg.com/scsi_target.c.diff I do however, get a kernel panic when trying to exit from scsi_target via ctrl-c http://www.consultcsg.com/knlist_lock.txt Sean P.S. Is the URL based logging working better than a cut/paste into the email for everyone?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47604A96.6020401>