Date: Fri, 19 Jun 2009 09:38:03 +0400 From: pluknet <pluknet@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-stable@freebsd.org, Ed Maste <emaste@freebsd.org> Subject: Re: 6.2 sporadically locks up Message-ID: <a31046fc0906182238g55d8e0c6s2bc497e664379e2d@mail.gmail.com> In-Reply-To: <d763ac660906182202i1478b812u93965a2a98e92310@mail.gmail.com> References: <a31046fc0906160323s3e4ec60bxb585bb29f9f3a02a@mail.gmail.com> <200906160830.29721.jhb@freebsd.org> <a31046fc0906160803n284604bcs741e6b038079ed12@mail.gmail.com> <20090617142952.GA73887@sandvine.com> <a31046fc0906170745i51583493kf8b0d9a8bdd6b631@mail.gmail.com> <d763ac660906182202i1478b812u93965a2a98e92310@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/6/19 Adrian Chadd <adrian@freebsd.org>: > Just modify the driver slightly to hijack a different device prefix :) > Hi, Adrian. That's where I just go if I should have to. - .d_name =3D "aac", + .d_name =3D "aacu", (or vise versa) While here, I'd like to give some summary about locking up with "irq17:bce1 aacu0" vs arcconf scenario. Abstract: we have a number of boxes with IBM ServeRAID 8k on 6.2. That scenario takes place only with aacu b15753, and not with b15411 (at least not noticed). We take a decision some time ago to move some boxes to 6.4 (and leave vendor aacu b15753 there as it's) to see how it goes. Until now (2 or 3 weeks) there were no lockup. I hope it will so farther.. > > > Adrian > > 2009/6/17 pluknet <pluknet@gmail.com>: >> 2009/6/17 Ed Maste <emaste@freebsd.org>: >>> On Tue, Jun 16, 2009 at 07:03:34PM +0400, pluknet wrote: >>> >>>> As for allpcpu, I often see the picture, when one CPU runs the "irq17: >>>> bce1 aacu0" thread >>>> and another one runs arcconf. I wonder if that might be a source of >>>> bad locking or races, or.. >>>> The arcconf utility uses ioctl that goes into aac/aacu(4) internals. >>> >>> Do you see the same result w/ the in-tree aac(4) driver as opposed to >>> Adaptec's version? >>> >>> -Ed >>> >> >> [It's quite hard to move back to aac(4) as that requires fstab update >> [ aacdu0 -> aacd0] >> =A0and instant reboot, because we use quotas and quotacheck looks into /= etc/fstab. >> Such preparations as fstab update and commenting out load_aacu=3D"YES" w= ill give >> discrepancy between fstab and actual mount points.] >> >> I will try anyway. Thank you for your help. >> --=20 wbr, pluknet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a31046fc0906182238g55d8e0c6s2bc497e664379e2d>