Hello. I'm getting an annoying bug I fixed by downgrading to intel driver 2.21.12. When I try to shutdown my laptop (a Toshiba Satellite L300-2CZ with an intel GMA 4500 GPU), my computer doesn't stop. As I said, downgrading to previous driver version (2.21.12) fixes this behaviour. I'm using a fully up-to-date Archlinux with testing repository enabled. So, I have linux kernel 3.10.4, Xorg 1.14.2 and of course intel driver 2.21.12. I open a bug on archlinux bugtracker : https://bugs.archlinux.org/task/36317 Feel free to ask me any info you need to fix this bug.
Xorg.0.log and dmesg please.
Created attachment 83218 [details] Xorg.0.log with 2.21.13 driver
Created attachment 83219 [details] dmesg with intel driver 2.21.13
Whereabouts does it hang during shutdown? Is the machine still accessible by the network at that point? Can you login/switch to a VT, and see what's hung?
(In reply to comment #4) > Whereabouts does it hang during shutdown? Is the machine still accessible by > the network at that point? Can you login/switch to a VT, and see what's hung? Just after gdm is stopped. And I cannot login or switch to another tty.
It is sounding like a kernel oops, and I can't identify any likely culprit between .12 and .13. Would you be able to bisect this?
I can try, just tell me how to do this :)
(You may need to download some dependencies.) $ git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-intel $ cd xf86-video-intel $ ./autogen --prefix=/usr $ make && sudo make install # confirm everything boots fine and you can reproduce the bug $ git checkout 2.21.12 $ make && sudo make install # confirm it works $ git bisect start $ git bisect good $ git bisect bad # git will select a commit halfway between the two endpoints $ make && sudo make install # test $ git bisect good # if it shuts down cleanly, or $ git bisect bad Then repeat the make, install, test, git bisect (good|bad) until git pronounces a winner.
(In reply to comment #8) > (You may need to download some dependencies.) > > $ git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-intel > $ cd xf86-video-intel > $ ./autogen --prefix=/usr > $ make && sudo make install > > # confirm everything boots fine and you can reproduce the bug Ok, worked. > > $ git checkout 2.21.12 > $ make && sudo make install > > # confirm it works > Worked too. > $ git bisect start > $ git bisect good > $ git bisect bad > # git will select a commit halfway between the two endpoints > $ make && sudo make install Nothing happened here :( git did not grab anything :( A step is missing here, or did I missed something ? > > # test > $ git bisect good # if it shuts down cleanly, or > $ git bisect bad > > Then repeat the make, install, test, git bisect (good|bad) until git > pronounces a winner. I hope I can help more !
(In reply to comment #9) > (In reply to comment #8) > > $ git bisect start > > $ git bisect good > > $ git bisect bad > > # git will select a commit halfway between the two endpoints > > $ make && sudo make install > > Nothing happened here :( > > git did not grab anything :( > > A step is missing here, or did I missed something ?] No, I missed something. That should have been: $ git bisect start $ git bisect good $ git bisect bad master In order to restart, you will want to first do a "git bisect reset"
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > $ git bisect start > > > $ git bisect good > > > $ git bisect bad > > > # git will select a commit halfway between the two endpoints > > > $ make && sudo make install > > > > Nothing happened here :( > > > > git did not grab anything :( > > > > A step is missing here, or did I missed something ?] > > No, I missed something. > > That should have been: > $ git bisect start > $ git bisect good > $ git bisect bad master > > In order to restart, you will want to first do a "git bisect reset" Ok. Thanks for the info. Don't have time tonight. Will report early tomorrow morning. Sorry for the delay. Real life...
Do not understand. Try this morning, and git version is working. No more shutdown hang. Looked at git log, and did this commit the answer to my problem ?! http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=d7465ece29c9ae665a5a9f5bdac764a19062786e Or this one ? http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=5751b9f1f5beb943db8cb5d260379ae39eb18db4 Will try to verify with this AUR package and report : https://aur.archlinux.org/packages/xf86-video-intel-git/
Verified again. Less than 12 hours ago, shutdown wasn't working on git. Now, with the new commits, shutdown is ok. So, one of the commits fixed the hanging shutdown bug. But which one ?
You are not using SNA, which is why this is quite strange. You have two choices, either do a normal bisect looking for the commit that introduced the hang, or a "reversed" bisect that looks for the commit that fixes the hang. In a reversed bisect, you would treat as any hang as good, and any working commit as bad: $ git bisect start good 2.21.13 # broken $ git bisect bad master # works $ make && sudo make install # test $ git bisect bad # if it works (shuts down without a hang) $ git bisect good # if it hangs and repeat make / git bisect (bad|good). I suspect that both bisects will be useful to understanding this mystery.
Well, I will try. But I still do not understand why hang disappeared. Will try to broke shutdown again today, on my spare time.
Starting get bissecting now, but one more info : I'm using --enable-dri options in configure step. Don't know if it is matters or not.
--enable-dri is the default, so it should be fine.
I'm speechless. All is working now, even driver 2.21.13 !!!! I noticed libx11 was upgraded. Related or not ?!
Unlikely, it all doesn't make a lot of sense. My suspicion is something went wrong in the packaging and shutdown scripts...
I have to add this in /etc/X11/xorg.conf.d/20-intel.conf: Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "uxa" EndSection Sna seems to be buggy with my laptop GPU.
See above. Very, very unlikely to be the reason.
So explain me why I do not use 20-intel.conf with official driver, shutdown is hanging. I'm only reporting what is happening !
As a userspace process, X is killable just like any other. The only times it cannot are if the kernel is broken - that is the i915.ko oops whilst holding its mutex is often enough to wedge the system. Until you can pinpoint where it actually dies, probably requiring remote logging, you're not going to be able to solve this other than using a bisect. Note in the original bug report, the issue occurred with UXA. And a broken package is a far more likely explanation.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.