Date: Wed, 26 May 2010 11:23:02 -0500 From: Alan Cox <alc@cs.rice.edu> To: Garrett Cooper <yanefbsd@gmail.com> Cc: alc@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, Konstantin Belousov <kib@freebsd.org> Subject: Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and Message-ID: <4BFD4AE6.5040105@cs.rice.edu> In-Reply-To: <AANLkTil33IEVGXxsjV1oqfBgKQq-aIJ9Ur1U0Gn8Gplt@mail.gmail.com> References: <AANLkTil33IEVGXxsjV1oqfBgKQq-aIJ9Ur1U0Gn8Gplt@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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! Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BFD4AE6.5040105>