nouveau driver freeze -- can anyone else reproduce this?

[poma]

On 06.05.2015 21:05, poma wrote:
> On 28.04.2015 20:03, poma wrote:
>> On 27.04.2015 11:51, Joerg Lechner wrote:
>>> Hi,
>>> the reason why I ask again, if really the nouveau driver is active, when using Geeqie, is a look into  /var/log/Xorg.0.log,
>>> where in my case (hybrid grafics intel/nvidia) I don't find the nouveau driver, which would explain, why I don't have
>>> the error described in this thread.
>>>
>>> see part of  /var/log/Xorg.0.log:
>>>    148.883]    Module class: X.Org Video Driver
>>> [   148.883]    ABI class: X.Org Video Driver, version 19.0
>>> [   148.883] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
>>>         i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
>>>         915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
>>>         Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
>>>         GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
>>> [   148.884] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000
>>> [   148.884] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100
>>> [   148.884] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 6200, P6300
>>>
>>> Therefore my question in case of Matthews Lenovo, is it really the nouveau driver or another video driver, 
>>> which causes the Geeqie error?
>>> Kind Regards
>>>
>>>
>>>
>>> -----Ursprüngliche Mitteilung----- 
>>> Von: Matthew Miller <mattdm at fedoraproject.org>
>>> An: For testing and quality assurance of Fedora releases <test at lists.fedoraproject.org>
>>> Verschickt: So, 26 Apr 2015 9:25 pm
>>> Betreff: Re: nouveau driver freeze -- can anyone else reproduce this?
>>>
>>>
>>> On Sun, Apr 26, 2015 at 08:54:48PM +0200, drago01 wrote:
>>>>>> What kind of menu
>>> is that? How big is it (height / width in pixels) ?
>>>>> It's the right-click
>>> context menu you get when clicking on a filename
>>>>> in geeqie. It's nothing
>>> special -- 14 items in three groups, with "View
>>>>> in new window" being the
>>> longest item. 150x300 pixels, maybe?
>>>> OK so nothing "special" about it ...
>>> odd.
>>>
>>> Yeah. I did get what seemed like the same behavior with a context menu
>>> in
>>> Gimp *once*, but can't reproduce there. However, geeqie seems to
>>> very reliably
>>> trigger it. And it seems to be only _that_ right-click
>>> menu, in the filelist,
>>> not others in the app. I guess I can go around
>>> right-clicking in other programs
>>> to see if it happens.
>>>
>>> One thing that occurs to me is that the placement of this
>>> menu means
>>> that when it comes up, it almost always comes up on top of a
>>> scrollbar
>>> and into another panel. *Maybe* that interaction causes some
>>> rendering
>>> need which triggers the bug? Seems like a longshot, and I really
>>> don't
>>> know what I'm talking about here. :)
>>>
>>>
>>
>>
>> If I understood Ilia,
>> https://bugs.freedesktop.org/show_bug.cgi?id=89842#c5
>>
>> the problem is somewhere in between:
>> libdrm-2.4.60
>> http://cgit.freedesktop.org/mesa/drm/commit/?id=5f7b672
>> &
>> libdrm-2.4.59
>> http://cgit.freedesktop.org/mesa/drm/commit/?id=d2e0f55 
>>
>> i.e.
>> 74 commitas
>>
>> What are you waiting for? :)
>>
>> man 1 git-bisect
>>
>>
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=89842#c10
> 
> 

Thus you can quickly test whether Skeggs's commit really works:

$ cd ~/rpmbuild/SOURCES/

$ git clone git://pkgs.fedoraproject.org/libdrm.git .

$ sed -i 's/#define gitdate 20130117/%define gitdate 20150506/' libdrm.spec
$ sed -i 's/: 1/: 100/' libdrm.spec
$ sed -i 's/%patch5/#%patch5/' libdrm.spec
$ sed -i '/dr[im]stat\|get[csv]\|name_from_fd\|openclose\|setversion\|updatedraw\|bindir}\/exynos/d' libdrm.spec
$ sed -i '/kmstest/ a\%{_bindir}/proptest' libdrm.spec

$ ./make-git-snapshot.sh

$ pkexec yum-builddep libdrm

$ rpmbuild -ba libdrm.spec