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
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.
Created attachment 116616 [details]
video bios from this card, using dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64
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
I tried to "momentarily fix" the problem by stopping/restarting X
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.
Created attachment 116619 [details]
dmesg > log.txt attempt to "fix" it under debian by stopping and restarting X
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 :)
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.
(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?
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.
-- 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.