nvidia-driver 195.22 use horribly broken on amd64 between r206173 and

Garrett Cooper yanefbsd at gmail.com
Wed May 26 18:56:54 UTC 2010

On Wed, May 26, 2010 at 10:41 AM, Alan Cox <alc at 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?

More information about the freebsd-current mailing list