Date: Wed, 26 May 2010 12:41:51 -0500 From: Alan Cox <alc@cs.rice.edu> To: Kostik Belousov <kostikbel@gmail.com> Cc: alc@freebsd.org, Garrett Cooper <yanefbsd@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and Message-ID: <4BFD5D5F.8090106@cs.rice.edu> In-Reply-To: <20100526165141.GF83316@deviant.kiev.zoral.com.ua> References: <AANLkTil33IEVGXxsjV1oqfBgKQq-aIJ9Ur1U0Gn8Gplt@mail.gmail.com> <4BFD4AE6.5040105@cs.rice.edu> <20100526165141.GF83316@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Kostik Belousov wrote: > On Wed, May 26, 2010 at 11:23:02AM -0500, Alan Cox wrote: > >> Garrett Cooper wrote: >> >>> Just reporting the fact that nvidia-driver 195.22 is horribly >>> broken between r206173 and r208486 (my machine consistency livelocks >>> at X11 startup); the latest driver is still broken as well with the >>> same symptoms. I realize that's a huge revision difference, and I'll >>> definitely try and track down the root cause via a binary search, but >>> I wanted to make sure that other folks knew of the issue and don't >>> upgrade and their systems break horribly as well. >>> I suspect that the locking changes are causing the issue, but I >>> don't have any hard data to backup my claim at this time. >>> >>> >> I'm sure they are. The Nvidia driver directly accesses low-level >> virtual memory structures on which the synchronization rules have >> changed. (In contrast, the Xorg dri drivers in our source tree are >> using higher-level interfaces that have remained stable.) >> >> I don't think that a binary search is needed. The lock assertion >> failures should indicate most if not all of the changes that are needed >> in the driver. When Kip got this process started, he bumped >> FreeBSD_version, so it should be possible to condition the locking >> changes in the driver. >> >> Good luck! >> > > I did a quick glance over the driver, try this: > http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch > I did not even compiled the patched driver. > The second snippet looks weird to me, specifically, seeing an explicit unwiring before a kmem_free() call. Should the corresponding allocation be using kmem_alloc_attr()? Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BFD5D5F.8090106>