Date: Sat, 20 Sep 2003 02:17:21 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Kris Kennaway <kris@obsecurity.org> Cc: w@dream.vg Subject: Re: ATAng still problematic Message-ID: <20030920021721.F52973@newtrinity.zeist.de> In-Reply-To: <20030919233632.GB32858@rot13.obsecurity.org>; from kris@obsecurity.org on Fri, Sep 19, 2003 at 04:36:32PM -0700 References: <20030918134850.GA22643@student.agh.edu.pl> <200309181354.h8IDsa0F023908@spider.deepcore.dk> <20030918155125.GC22643@student.agh.edu.pl> <20030919182152.A98528@newtrinity.zeist.de> <20030919233632.GB32858@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 19, 2003 at 04:36:32PM -0700, Kris Kennaway wrote: > On Fri, Sep 19, 2003 at 06:21:52PM +0200, Marius Strobl wrote: > > On Thu, Sep 18, 2003 at 05:51:25PM +0200, Jan Srzednicki wrote: > > > > > > Anyway, here's backtrace for atapicam panic I've mentioned. It's > > > triggered by: > > > > > > cdrecord dev=1,1,0 /some/track > > > > > > > This panic isn't ATAPICAM related. Could you try the patch below? It's > > against the cdrtools-devel port but should also work with the cdrtools > > port. > > Isn't it still a kernel bug if a user process can trigger a panic? > Yes, it seems to be a bug in the mlockall(2) implementation. Backing it out or hindering cdrecord to use it avoids the panic. I already wrote an email to bms@ who commited the mlockall(2) and munlockall(2) support regarding this issue. The patch for the cdrtools ports is only a workaround until the real cause is fixed. I also was not sure if it would work for Bryan as I originally didn't get the same panic as he did.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030920021721.F52973>