|Summary:||desktop freezes shortly after boot with NV11 [GeForce2 MX/MX 400]|
|Component:||Driver/nouveau||Assignee:||Nouveau Project <nouveau>|
|Status:||RESOLVED MOVED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
Description anonymissimus 2015-06-20 12:38:09 UTC
Created attachment 116615 [details] dmesg > kernel_log.txt from ctrl+alt+F1 console after UI hangs in debian as described Using same computer/OS/packages as in https://bugs.freedesktop.org/show_bug.cgi?id=91025 I plugged in my other problematic card: 01:00.0 VGA compatible controller : NVIDIA Corporation NV11 [GeForce2 MX/MX 400] [10de:0110] (rev b2) (prog-if 00 [VGA controller]) Subsystem: PROLINK Microsystems Corp MVGA-NVG11AM(400) [1554:1081] Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 Memory at ee000000 (32-bit, non-prefetchable) [size=16M] Memory at f0000000 (32-bit, prefetchable) [size=128M] Expansion ROM at efff0000 [disabled] [size=64K] Capabilities:  Power Management version 2 Capabilities:  AGP version 2.0 Kernel driver in use: nouveau symptoms: Clicking a little around (opening/closing some windows from lxde's menu or launcher) makes the UI hang quickly, usually after 10 seconds or less. After a while (maybe 20 or 30 secs) the system reacts to me having pressed or pressing ctrl+alt+F1 and I create log from that console. In case that I haven't pressed that shortcut yet, the display is almost unusable, the menu is hardly displayed when I try to open it, so there's nothing else left to do. Problem also happened booting systemrescuecd-x86-4.5.3 (live CD) in very similar way.
Comment 1 anonymissimus 2015-06-20 12:40:36 UTC
Created attachment 116616 [details] video bios from this card, using dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64
Comment 2 anonymissimus 2015-06-20 12:46:08 UTC
Created attachment 116617 [details] dmesg > kernel_log.txt from ctrl+alt+F2 console after UI hangs after startx command with systemrescuecd-x86-4.5.3 takes a little more window opening/closing until freeze
Comment 3 anonymissimus 2015-06-20 14:20:58 UTC
I tried to "momentarily fix" the problem by stopping/restarting X /etc/init.d/lightdm stop /etc/init.d/lightdm start under debian; this only works for as long as the hang hasn't happened yet. Trying it afterwards takes me to a black screen when starting X. However, ctrl+alt+F1 did (I think) always work, with delay at least. Therefore, the hang level according to http://nouveau.freedesktop.org/wiki/HangDiagnosis/ is 2. Attaching the log from this session as well, supposedly the most useful one.
Comment 4 anonymissimus 2015-06-20 14:25:44 UTC
Created attachment 116619 [details] dmesg > log.txt attempt to "fix" it under debian by stopping and restarting X
Comment 5 Ilia Mirkin 2015-06-20 18:37:15 UTC
Your GPU is hanging... what sort of desktop environment is this? I'd recommend staying away from anachronistic setups which use 2015 features on hardware from 2002... e.g. stay away from GL compositors :)
Comment 6 anonymissimus 2015-06-20 21:13:28 UTC
Well, this is LXDE http://lxde.org/ a modern, but lightweight desktop that should be designed for such hardware... Are you suggesting I should try another lightweight desktop ? Xfce would be an option.
Comment 7 Ilia Mirkin 2015-06-20 21:36:34 UTC
(In reply to anonymissimus from comment #6) > Well, this is LXDE http://lxde.org/ a modern, but lightweight desktop that > should be designed for such hardware... > Are you suggesting I should try another lightweight desktop ? Xfce would be > an option. Nope, that should largely be fine. I was mainly warning you away from things like gnome and kde which have very heavy things turned on by default. So..... it looks like we're doing *something* which hangs the GPU, but we do it without triggering any errors from the card, it just stops processing commands. That's nice. I've never tried nouveau with a NV11, but I have used it with a NV17, and it was fine, when using WindowMaker. NV17 introduces some 3D functionality on top of what NV11 has, but we tend to be pretty good about detecting that (and if we were calling it, we'd have seen errors about unknown methods). Unfortunately I'm not sure how to debug this hang. Ben, thoughts on providing a way to see what was in the last-submitted exec request [pushbuf, relocs, etc] before the hang (i.e. the one whose fence never gets reached)? Seems like that should be moderately easy, no?
Comment 8 anonymissimus 2015-06-22 15:56:50 UTC
It's clear to me that this machine wouldn't run with kde or gnome. As I need to keep this hardware/OS combination available in an unusable state to be able to generate the data you need to fix this I'd like to do that quickly so that I can plug out the card again in favor of a better working one, assuming there won't be a quick fix or workaround. If it helps, I have the impression the hang happens when maximizing some window onto the whole desktop. I have run applications under gdb on command line in the past, if that's what I might have to do.
Comment 9 Martin Peres 2019-12-04 09:01:00 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/198.