Date: Mon, 22 Dec 2008 02:36:00 -0600 From: Richard Todd <rmtodd@servalan.servalan.com> To: freebsd-current@freebsd.org Cc: rnoland@freebsd.org Subject: Getting 'vm_thread_new: kstack allocation failed' errors after latest drm updates. Message-ID: <x7wsdsk3nz.fsf@ichotolot.servalan.com>
next in thread | raw e-mail | index | archive | help
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 URL: http://svn.freebsd.org/changeset/base/186295 Log: 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 Modified: head/sys/dev/drm/drmP.h head/sys/dev/drm/drm_scatter.c ------------------------------------------------ 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 problems. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?x7wsdsk3nz.fsf>