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
qhwt+dragonfly-bugs at les.ath.cx
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:
> :-> 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
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
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