Date: Wed, 26 May 2010 11:56:46 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: Alan Cox <alc@cs.rice.edu> Cc: Kostik Belousov <kostikbel@gmail.com>, alc@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and Message-ID: <AANLkTinb2paAVMVXjXQBn7AseC5Iwydl7vs_HTCt4vWM@mail.gmail.com> In-Reply-To: <4BFD5D5F.8090106@cs.rice.edu> References: <AANLkTil33IEVGXxsjV1oqfBgKQq-aIJ9Ur1U0Gn8Gplt@mail.gmail.com> <4BFD4AE6.5040105@cs.rice.edu> <20100526165141.GF83316@deviant.kiev.zoral.com.ua> <4BFD5D5F.8090106@cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 26, 2010 at 10:41 AM, Alan Cox <alc@cs.rice.edu> wrote: > Kostik Belousov wrote: >> >> On Wed, May 26, 2010 at 11:23:02AM -0500, Alan Cox wrote: >> >>> >>> Garrett Cooper wrote: >>> >>>> >>>> =A0 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. >>>> =A0 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. =A0The Nvidia driver directly accesses low-level vir= tual >>> memory structures on which the synchronization rules have changed. =A0(= In >>> contrast, the Xorg dri drivers in our source tree are using higher-leve= l >>> interfaces that have remained stable.) >>> >>> I don't think that a binary search is needed. =A0The lock assertion >>> failures should indicate most if not all of the changes that are needed= in >>> the driver. =A0When Kip got this process started, he bumped FreeBSD_ver= sion, >>> 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. =A0Should the corresponding allocatio= n be > using kmem_alloc_attr()? I'm by no means an expert in this area, but isn't removing the locking on free a bad thing? Thanks, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinb2paAVMVXjXQBn7AseC5Iwydl7vs_HTCt4vWM>