Getting 'vm_thread_new: kstack allocation failed' errors after latest drm updates.

Richard Todd rmtodd at
Mon Dec 22 08:45:11 UTC 2008

I recently updated my system to the latest -CURRENT, and noticed that
shortly after the system booted off the new kernel and went multiuser,
lots of attempts by programs to create new threads or fork() failed with
the kernel giving the error message "vm_thread_new: kstack allocation
failed".  After spending the weekend doing binary searches to try and isolate
which recent kernel change was responsible, I finally discovered that the
culprit appears to be the following change:
Author: rnoland
Date: Thu Dec 18 21:04:50 2008
New Revision: 186295

  rework drm_scatter.c which allocates scatter / gather pages for use by
  ati pci gart to use bus_dma to handle the allocations.  This fixes
  a garbled screen issue on at least some radeons (X1400 tested).  It is
  also likely that this is the correct fix for PR# 119324, though that
  is not confirmed yet.
  Reviewed by:	jhb@ (mentor, prior version)
  Approved by:	kib@
  MFC after:	2 weeks


Yeah, it's not immediately clear to me either why this change should have this
effect, but on my system, testing gave the following results consistently:

1) Kernels built from source from just before this commit boot and run without

2) Kernels built from source from just *after* this commit show the 
"vm_thread_new: kstack allocation failed" problem.

3) If I disable xdm so the X server doesn't start, kernels including the 
   aforementioned commit do not show the problem, so the problem does seem
   connected to the drm module.

It's not clear what exactly this commit is doing that causes the problem; it
doesn't seem to be a simple kernel memory leak, as vmstat -m from the suspect
kernels doesn't seem to show anything obviously leaking.  Any suggestions?

Other information on my system that might be relevant: it's a Core 2 Duo system
with 4G of memory, running FreeBSD-CURRENT in i386 mode.  The video card is
an ATI X300.  vm.kmem_size is set fairly high, 1536M, so there should be
plenty of kernel memory space available, even with ZFS wanting 600M of that 
for its ARC.  

More information about the freebsd-current mailing list