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? Thanks, -GarrettReceived on Wed May 26 2010 - 16:56:54 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC