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

[Alan Cox]

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