Re: cvs commit: src/sys/i386/isa apic_vector.s clock.c src/sys/kern kern_intr.c kern_sig.c kern_slaballoc.c kern_switch.c kern_systimer.c kern_upcall.c lwkt_msgport.c lwkt_thread.c lwkt_token.c src/sys/sys slaballoc.h

[YONETANI Tomokazu <qhwt+dragonfly-bugs@xxxxxxxxxx>]

Hi,

On Thu, Feb 19, 2004 at 09:49:26AM -0500, Robin P. Blanchard wrote:
> > On Wed, Feb 18, 2004 at 03:34:46PM -0800, Matthew Dillon wrote:
> > > 
> > > :I'm sorry to have spammed the commits@ list, moving to 
> > bugs@. :I've 
> > > found the path to the panic: :mi_startup
> > > :-> scmeminit
> > > :   -> sc_alloc_scr_buffer
> > > :      -> sc_vtb_copy
> > > :         -> sc_vtb_init, malloc failed because of M_NOWAIT flag
> > > :         -> bcopy to null pointer and panic
> > > :
> > > :I'm still not sure why it failed only when the kernel is 
> > compiled with gcc2.
> > > 
> > >     All right.  Try the patch below.
> > > 
> > >     I will have to spend a day fixing all the misuses of 
> > M_NOWAIT in the
> > >     kernel that were inherited from FreeBSD-4.  FreeBSD-5 
> > has the same 
> > >     problem, actually. The difference between FreeBSD and 
> > DragonFly is 
> > >     that in DragonFly M_NOWAIT really means "don't wait, 
> > and be prepared
> > >     to handle a NULL return value", whereas in FreeBSD it 
> > means "I don't
> > >     want you to wait but I also sorta hope you won't ever return 
> > > NULL".
> > 
> > While your explanation on malloc flags appears reasonable, 
> > and I've seen such discussions on freebsd-current ML, I 
> > really don't understand why the kernel compiled with gcc2 
> > suddenly stopped working when the one with gcc3 is fine.
> > 
> > > Index: syscons.c
> > [patch]
> > 
> > No luck. 
> > 
> >   Copyr\M-ight (c) 2003-2004 The DragonFly Project.
> >   Copyright (c) 1992-2003 The FreeBSD Project.
> >   Copyright (c) 1979, 1980, 1983, 1986, 1989, 1989, 1991, 
> > 1992, 1993, 1994
> > 	  The Regents of the University of California. All 
> > rights reserved.
> >   acpi_alloc_wakeup_handler: unable to create wake tag
> >   panic: devbuf: malloc"limit exceeded
> >   Uptime: 0s
> > 
> > malloc seems to have started to fail at 
> > acpi_alloc_wakeup_handler, which is called a few entries 
> > earlier than the call to scmeminit.
> > 
> > 
> 
> 
> Interestingly enough, on my dfly test box, recent kernels built with gcc2
> along with CPUTYPE=i686 set in make.conf yield broken kernels almost
> identical to what you are describing. Removing CPUTYPE from make.conf yields
> working kernel with gcc2. Is this reproducible on your end ?

Yes, that did it.