Created attachment 15870 [details] glxinfo output Yesterday, I've extracted everything related to nouveau from git repositories. That is: 1) drm 2) xf86-video-nouveau 3) mesa (in a second step, see below) Build everything, made the drm, and nouveau module auto load at startup, then changed my xorg.conf (attached). Immediately, I did see huge 2D performance improvement, but noticed running glxgears that 3D was not there. Confirmed by the message in Xorg.log.0 about AIGLX. I then started to add Section "ServerFlags" Option "AIGLX" "on" EndSection But when restarting X, the machine hang for quite a long time. It is not dead, as I can ping it or event ssh to it. But you do not have any keyboard input (even caps lock led). I then decided to be adventurous and try the 3D. And managed to install it. I now have some basic 3D acceleration except that if I magnify Glxgears, it gets a sigsegv. But the "not fatal" hang for 6 min at shutdown remains. The last message I see, before it really starts printing garbled init 0 message again is the "failed to idle channel 1 before destroy. Prepare for strangeness.
Created attachment 15871 [details] xorg.conf
Created attachment 15872 [details] Xorg.log
Created attachment 15873 [details] dmesg output for drm driver
Created attachment 15874 [details] trying to run compiz error message
The hang does happen even when I have no error message from drm driver.
I update drm and nouveau Xord driver from git yesterday and the roblem has vansihed.
The hang when shuting down is back and solid. The system hangs again for 5 min a shutdown.
Created attachment 25980 [details] Updated glxinfo
Created attachment 25981 [details] Updated Xorg log
Created attachment 25982 [details] updated drm module message
Tried ssh+gdb to figure what exactly it's blocking on? And perhaps modprobe drm debug=1 to get some more verbosity on that side. I'm away from my dev machine so i can't really help, just wanted to give some hints.
Not even sure I still have network. The keyboard is frozen even if I'm back to fb console. The last thing is see is a message about destroying fifo 0. Even the caps lock led does not work. Will see if network is still up when the lock occur (hang is during shutdown but I guess it is before the network stop script). Will try to see if I can still log into the machine and report.
I did a ssh session before ending a kde4 session. Ending the kde4 session itself worked. I been back to kdm prompt. Then I did login to tty console from kdm mennu and I got the hang. I have been able to do some ps and some command for a while (< 1mn) and then the ssh was stuck. Ping did continue to work. Part of dmesg after hang is added. NB: the console get back after the 6 mins but the charcater displayed are totally garbled. If I restart kdm, then I got a normal screen.
Created attachment 26079 [details] dmesg containing eveidence of the hang and a strange "DMA Get Lockup" If only there was a real in kernle debugger...
./drivers/video/nvidia/nv_accel.c:137: printk("DMA Get lockup\n"); in function NVDmaWait() So apparently nouveau and the in kernel nv frame buffer are doing incompatible things with video registers.
Disable nvidiafb and retry. Nouveau and nvidiafb can *not* work together.
Why the hell? If I use nouveau I cannot use a framebuffer. What is supposed to happend when KMS will be generalized? Will do the test but still...
You can't reliably have two drivers thinking they have direct control of the hw, nvidiafb will blindly destroy a lot of setup nouveau does to the card, it can't possibly work. The binary driver will flat-out refuse to load if nvidiafb is running, nv only works by sheer accident (a combination of the very basic way it and nvidiafb use the hw, and because they use the card almost identically). If everything works fine without nvidiafb, I'll close this as NOTABUG. You can use vesafb if you really want a framebuffer console.. With KMS, nouveau provides the console, so there isn't an issue.
I say that because it basically works. I can switch from X11 to vt back and forth without problem. I only hangs when I exit X. As soon as nouveau use KMS, and provide a framebuffer console, I would be happy.
Works without nvidia framebuffer. But I cannot stand having 80x25 tty on a 1600x1050 23 inch display...
There's vesafb if you really must have a framebuffer console. Until KMS (probably soon, it'll be there once the nouveau kernel tree is sorted out, the code's basically written), that's your only option.
I get KMS working on my C51 and Go 7300. My work is available in my drm tree[1] at f.d.o. It may be unstable then upstream master, if you're brave enough, you can try it:) [1] git://anongit.freedesktop.org/~jinghua/drm modesetting-gem branch
The bug happened yesterday with vesa framebuffer. So we only chnaged the bug frequency using vesa. Sorry for this annoying reopen...
Is this still an issue with recent nouveau, or could we close this bug?
Should work fine now. Closing as RESOLVED FIXED.
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.