Date: Wed, 15 Oct 2008 20:54:53 +0300 From: Panagiotis Christias <p.christias@noc.ntua.gr> To: Oleg Sharoiko <os@rsu.ru> Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD 7-STABLE, isp(4), QLE2462: panic & deadlocks Message-ID: <20081015175453.GA3260@noc.ntua.gr> In-Reply-To: <1224049455.1277.44.camel@brain.cc.rsu.ru> References: <20081014222343.GA8706@noc.ntua.gr> <1224049455.1277.44.camel@brain.cc.rsu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 15, 2008 at 09:44:15AM +0400, Oleg Sharoiko wrote: > Hi! > > On Wed, 2008-10-15 at 01:23 +0300, Panagiotis Christias wrote: > > > However, when we connect them to the CX3-40, create and mount a new > > partition and then do something as simple as "tar -C /san -xf ports.tgz" > > the system panics and deadlocks. We have tried several FreeBSD versions > > (6.3 i386/adm64, 7.0 i386/adm64, 7.1 i386/adm64 and lastly 7-STABLE i386 > > - we also tried the latest 8-CURRENT snapshot but it panicked too soon). > > The result is always the same; panic and deadlock. > > Try reducing the number of "tagged openings" with 'camcontrol tags' down > to 46. If it doesn't work try reducing it further to 2. Also be advised > that I've seen panics with geom_multipath in FreeBSD-7, unfortunately I > had no time to test it in -current. Hm.. that would probably explain the fact that I was unable to panic the system when I had set the hint.isp.0.debug="0x1F" in /boot/device.hints. Currently I am stress testing the server with the tagged openings set to 44 (first value tested). Until now there is no panic or deadlock. I am trying concurrent tar extractions and rsync copies. The filesystem looks ok till now according to fsck. I will let it write/copy/delete overnight and tomorrow I will try different tagged opening values. Thank you for the hint! I am wondering what is the performance penalty with decreased tagged openings. Also, is there anything else I could try in order to get more useful debug output? I have at least three servers that I could use for any kind of tests and I am willing to spend as much time I can get to help solving the problem. Finally, the only output in the logs is: Expensive timeout(9) function: 0xc06f4210(0xc67e1200) 0.059422635 s Expensive timeout(9) function: 0xc08d4fd0(0) 0.060676147 s I suppose that is related to the CAMDEBUG kernel config options. Regards, Panagiotis -- Panagiotis J. Christias Network Management Center P.Christias@noc.ntua.gr National Technical Univ. of Athens, GREECE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081015175453.GA3260>