Distribution: Debian Sarge Hardware Environment: VIA KT 333 chipset, Athlon XP 2000, Matrox G450 dualhead Software Environment: XFree 4.3 (mga driver without FBDev) Problem Description: Kernel hard lock (Magic SysRq does not work) when switching console from-to X Steps to reproduce: 1) Run kernel with matroxfb 2) Use graphic console 3) Run X 4) Switch console from-to X SEVERAL times 5) After ~ 10-20 switching the kernel dies This is very easy to reproduce for me.
Created attachment 6598 [details] kernel config
Created attachment 6599 [details] Call WaitTillIdle() in set_par What do you mean when the kernel died? Did it print out any messages in your log? What was X doing when you switched to a vc, was it rendering something? Can you try this patch and see if it helps?
Kernel dies without any log. It is not not important what X does. Lock is reproducible when X does not do 3D rendering, but 3D rendering is enabled. OK, I will try the patch.
The patch is definitely helps very much: now it is very difficult to reproduce system lock. But it is still possible, at least I succeeded once.
Okay. You can also try adding this... mga_fifo(32); ...just before WaitTillIdle(); in drivers/video/matrox/matroxfb_base.c Note that this bug can be the fault of X/DRI if it keeps on touching the hardware even if it shouldn't. If the above does not fix your problem, or introduce new problems, you might have to send a bug report to the Xorg guys (that X and/or DRI is not totally quiescent when switched to a text console).
OK, I will try and answer tomorrow.
> mga_fifo(32); > > ...just before WaitTillIdle(); in drivers/video/matrox/matroxfb_base.c Good patch :). When loading, the kernel switches video mode to the graphic one, screen becomes black and there is no any activity, no log, only the black screen. Perhaps we need to add something more to the driver code?
Oh well, I guess waiting for fifo space is not possible until the hardware is fully initialized. Anyway, as Petr said (the matroxfb maintainer), this is a bug in X which keeps on touching the hardware even if it doesn't already own the console. You can try inserting a delaying loop before the WaitTillIdle(); in the hope that X would be finished before the delay expires, ie: for (int i = 10000; i--;) udelay(1);
FIFO depth is depending on model 31 or 15 or 7, so doing mga_fifo(32) is going to loop endlessly... When accelerator is reported to be idle, it is guaranteed that FIFO is empty, accelerator can be idle only if there is no pending command.
I did detailed investigation of the problem. First, I added loop with udelay to the kernel code and recompiled the kernel. Then I wrote the script #!/bin/sh chvt 1; chvt 7 chvt 1; chvt 7 ... 100 times Then I run this script from 1st console. I did not succeed to obtain lockup. Then I run this script from 7th console (from X). The lockup happened very soon. I tried this several times, these are reproducible facts. Then I disabled DRI in X, and retried the test. No lockup any more. Finally, I have recompiled the kernel with vesafb but without matroxfb. Then I performed the tests with DRI enabled. No lockup Therefore lockup happens only with matroxfb and DRI enabled. I do not understand why I cannot obtain lockup when start the script being at non-X console, but this is reproducible fact
Yes, the culprit is usually DRI. This bug also happens with other chipsets. (vesafb does not get affected because it does not touch the hardware anymore after booting).
Perhaps the bug should be reassigned to mga kernel driver?
No, user apps must respect KD_GRAPHICS and KD_TEXT. It seems that the mga DRI is not respecting that. The framebuffer does not touch the hardware when it is in KD_GRAPHICS mode, and user apps must not touch the graphics hardware if it is in KD_TEXT mode.
Can you try using the latest rc or mm kernel, then edit drivers/video/matrox/matroxfb_base.c and look for this particular lines: ACCESS_FBINFO(fbcon.flags) |= FBINFO_PARTIAL_PAN_OK | /* Prefer panning for scroll under MC viewer/edit */ FBINFO_HWACCEL_COPYAREA | /* We have hw-assisted bmove */ FBINFO_HWACCEL_FILLRECT | /* And fillrect */ FBINFO_HWACCEL_IMAGEBLIT | /* And imageblit */ FBINFO_HWACCEL_XPAN | /* And we support both horizontal */ FBINFO_HWACCEL_YPAN; /* And vertical panning */ Try adding FBINFO_MISC_ALWAYS_SETPAR and see if it helps.
Closing this bug. The problem is most likely DRI.