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 at
Thu Feb 19 06:30:33 PST 2004

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 at .
> :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

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.

More information about the Bugs mailing list