Date: Tue, 27 Sep 2005 16:28:20 -0600 (MDT) From: Scott <scottl@pooker.samsco.org> To: Pawel Worach <pawel.worach@gmail.com> Cc: current@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: [releng_6] mpt(4) Memory modified after free panic Message-ID: <20050927162641.N5371@pooker.samsco.org> In-Reply-To: <d227e09e05092714314174d7c7@mail.gmail.com> References: <d227e09e0509261455347a9aca@mail.gmail.com> <20050927003401.GE72460@xor.obsecurity.org> <d227e09e05092714314174d7c7@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Sep 2005, Pawel Worach wrote: > On 9/27/05, Kris Kennaway <kris@obsecurity.org> wrote: >> On Mon, Sep 26, 2005 at 11:55:53PM +0200, Pawel Worach wrote: >>> Trying to use a mpt controller with only one disk attached so it's not >>> possible to configure a RAID-1 volume. >>> Trying to boot 6.0-BETA1 install cd results in this panic. Should it >>> possible to use a single disk behind an mpt(4) with the updated driver? This >>> configuration works fine on 5.4. >> >> You should retry with 6.0-BETA5 - dozens of bugs have been fixed since >> then. If it persists, you should set up DEBUG_MEMGUARD to watch the >> M_BUS malloc type..this requires some minor source file editing and a >> kernel recompile (you can build it on e.g. 5.4). > > False alarm, BETA5 with WITNESS and INVARIANTS re-enabled works just fine. > BETA1 was the only thing I had handy the first time and since mpt(4) > was unchanged I thought it would still be broken, I'll try to think > less next time :) > For future reference, how do I get hold of the M_BUS malloc type in > kern_malloc.c ? > > -- > Pawel > mpt likely is not the problem. It's the one that catches the misbehavior. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050927162641.N5371>