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>
index | next in thread | previous in thread | raw e-mail
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: >>> >>>> >>>> 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()? I'm by no means an expert in this area, but isn't removing the locking on free a bad thing? Thanks, -Garretthelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinb2paAVMVXjXQBn7AseC5Iwydl7vs_HTCt4vWM>