Re: i1915drmkms system crash in NetBSD 7.0

[christos%astron.com@localhost (Christos Zoulas)]

In article <4d546a8d-e4d7-4e57-f4b1-9be638cbf3be%libero.it@localhost>,
Riccardo Mottola  <riccardo.mottola%libero.it@localhost> wrote:
>-=-=-=-=-=-
>
>I understand and share your rant! X drivers are quite an issue. At least 
>here with Intel they should work without any further nuiseance, at 
>least, so it is on Linux. For ATI or nVidia you need proprietary stuff 
>to have decent performance or rely on clang. One or the other way a 
>nightmare. Gone are the easy days of NeoMagic :)
>
>Stopping the rant... I think the kernel side seems to have an issue. If 
>there is a lock problem in the kernel and then I have issues in X11 
>itself, I thought those warnings could be of interest. If they are 
>meaningful  they should be solved.
>
>So I share your rant, but don't know what your point is !
>


Riccardo,

Your issue (the locking problem) is that the error path of the driver
tries to allocate buffers to store the error and somehow, even though
those allocations are supposed to be NOWAIT, a mutex is taken somewhere.
It should be simple enough to fix.

First look at the last locked address in your crash
0xffffffff807c33a3, and initialized 0xffffffff007f9a6a with addr2line
These should identify the mutex and where it was last locked. From
a cursory look it seems that the mutex_enter() from:

	i915_gem_object_get_page()

is the culprit. Perhaps we should provide an unlocked version of the
get_page call to be called on error. Try commenting out the mutex_lock
and mutex_unlock in that function (i915_drv.h) and see if you get further.

christos