DragonFly bugs List (threaded) for 2004-02
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
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.