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()? AlanReceived on Wed May 26 2010 - 15:42:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC