Re: PROBLEM: 2.4.4 oops, will not boot

From: Gordon Sadler (gbsadler1@lcisp.com)
Date: Thu May 03 2001 - 12:41:41 EST


On Thu, May 03, 2001 at 09:14:13PM +1000, Andrew Morton wrote:
> From: Andrew Morton <andrewm@uow.edu.au>
> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-ac13 i686)
> To: Gordon Sadler <gbsadler1@lcisp.com>
> Subject: Re: PROBLEM: 2.4.4 oops, will not boot
>
> Gordon Sadler wrote:
> >
> > On Thu, May 03, 2001 at 04:34:32PM +1000, Andrew Morton wrote:
> > > Gordon Sadler wrote:
> > > >
> > > > On Wed, May 02, 2001 at 09:51:39PM +1000, Andrew Morton wrote:
> > > > > Gordon Sadler wrote:
> > > > > >
> > > > > > Please CC on replies.
> > > > > > Attached is REPORTING-BUGS template from source, and a hand copied oops
> > > > > > that I ran through ksymoops. I really hope this is resolved, anything
> > > > > > further needed, just ask.
> > > > >
> > > > > Unfortunately the ksymoops output doesn't show the call trace.
> > > > > Can you please try again? A reproducable oops is, err, rather
> > > > > important. The syntax to feed into ksymoops is
> > > > >
> > > > > Call Trace: [<c0111234>] [<c0123456>] ...
> > > > >
> > > > > Thanks.
> > > > >
> > > > Right, I see the problem now.. s/Calltrace/Call Trace/
> > > >
> > > > Reran oops through ksymoops with change to Call Trace, output attached.
> > >
> > > Ugh. Something seems to have corrupted your slab cache
> > > data structures, so this will be real hard to pin down.
> > >
> > > You could try setting DEBUG to 1 in mm/slab.c, see if
> > > that catches the culprit.
> > >
> > As requested.. changed config in one way, removed nvidia
> > framebuffer/replaced with vesa fb. After changeing DEBUG -> 1 in
> > mm/slab.c it produced 3 EIPs. I rebooted to 2.2.19, copied by hand, and
> > ran through ksymoops. The attached tar is the .config, hand copy of 3
> > EIPs, and the ouput from ksymoops.
> >
>
> Thanks for all the hard work :)
>
> Something funny is happening at your end. It's
> dying when it's trying to return a memory mapping
> control structure back to the memory management
> pool. This code hasn't changed in a while, and
> if it was wrong, we'd be hearing it from lots of people.
>
> Have you done a full rebuild? `make clean'?
>
This last build of 2.4.4 with mod to mm/slab.c was a fresh unpack from a
src tarball from www.kernel.org. From what little I have gleaned from
this list, it appears a few others are having similar problems..
specifically I hear AMD CPU + Epox 8kta3 m/b will not boot with 3dnow
enabled? Some others have reported minor sucess with :
CONFIG_MK7=y
CONFIG_X86_USE_3DNOW=n

or they just compile with :
CONFIG_M686=y

I haven't seen any other ksymoops results from those individuals
however, and Alan Cox made a tentative analysis, it only happens with
VIA chipset -> VIA chipset bug.

I'm at a loss... I tried 2.4.4ac[23] both of them freeze during boot as
well, hmm... small idea: My BIOS allows FSB of 100/133 auto or manual
setting. I'm using pc100 SDRAM and the BIOS id's it as such at boot, any
chance the kernel is somehow trying to set something as though it were
133 FSB?

Gordon Sadler

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon May 07 2001 - 21:00:17 EST