nvidia-driver 195.22 use horribly broken on amd64 between
r206173 and
Alan Cox
alc at cs.rice.edu
Wed May 26 17:42:00 UTC 2010
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
More information about the freebsd-current
mailing list