After upgrading from Xorg 7.0 to 7.1 (thus from Gentoo x11-drivers/xf86-video-mga-1.2.1.3 to x11-drivers/xf86-video-mga-1.4.1-r1 and later also x11-drivers/xf86-video-mga-1.4.2), running `glxinfo` reliably locks the screen (monitor, keyboard LEDs, Ctrl+Alt+Backspace, mouse movements) up. Rest of the system is usable (ssh access works). After killing X and calling `chvt 1`, the screen remains unusable (2.6.16-gentoo-r3 and 2.6.18-gentoo kernels, no framebuffer), the only solution is reboot. /var/log/Xorg.0.log contains a lot of lines like this one: (EE) MGA(0): [dri] Idle timed out, resetting engine... I've tried some workarounds (Option "ForcePciDma" "yes", Option "OldDmaInit" "yes" and also both of them), yet the result is the same. As a temporary solution, I've downgraded my mga driver to 1.2.1.3. Now even `glxinfo` stops, but it can be killed by Ctrl+C and no X lockup occurs. My mesa version is media-libs/mesa-6.5.1-r1, upgraded from media-libs/mesa-6.4.2-r2. Please note that I haven't had any troubles for last year or so when running older Xorg versions, *including* 7.0. Let me know if I can help in any way.
you need a newer mga driver (1.4.2 or 1.4.3) or the mga driver from git head. The locking was broken on mga with AIGLX on 7.1.
As I've already stated in the original report, it hangs up with 1.4.2 as well. Now I've tried 1.4.3 and the behavior is the same. Using 1.2.1.3 causes DRI not to work, but at least it doesn't crash when some application tries to use it. Reopening.
I had thought that I was seeing bug #473. However, after some more experimentation, I believe that I'm actually seeing this bug. Jan, what sort of system are you on? I'm seeing this on an AGP G400 in an Athlon64 box.
(In reply to comment #3) > Jan, what sort of system are you on? x86 Athlon Thunderbird, Matrox G400 (AGP model with 32 MB of video RAM), motherboard is an ECS K7VZA, iirc. If you're interested in kernel and/or Xorg configs, let me know.
I've bisected this down to commit 07373669514b104a11fb1b4ed5214f3764c83a2f as the first bad change. This was when ajax added support for the G200SE. I reviewed this change when he committed it, and I don't believe that it should have had any impact on G400 class chips. I'll continue to investigate.
(In reply to comment #5) > I've bisected this down to commit 07373669514b104a11fb1b4ed5214f3764c83a2f as > the first bad change. This was when ajax added support for the G200SE. I > reviewed this change when he committed it, and I don't believe that it should > have had any impact on G400 class chips. > > I'll continue to investigate. I've tracked the problem down to the following change. I have no idea why this would have any impact what so ever. If I take 07373669514b104a11fb1b4ed5214f3764c83a2f and revert this change, and this change *only*, it starts working properly. I've stared at it quite a bit, and it feels like one of those PC-lint mind benders. Ugh. :( --- a/src/mga_dacG.c +++ b/src/mga_dacG.c @@ -688,6 +760,10 @@ MGA_NOT_HAL( ((i == 0x2c) || (i == 0x2d) || (i == 0x2e) || (i == 0x4c) || (i == 0x4d) || (i == 0x4e)))) continue; + if (((pMga->Chipset == PCI_CHIP_MGAG200_SE_A_PCI) || + (pMga->Chipset == PCI_CHIP_MGAG200_SE_B_PCI)) && + (i == 0x2C) || (i == 0x2D) || (i == 0x2E)) + continue; outMGAdac(i, mgaReg->DacRegs[i]); }
Fixed. && takes precedence over ||. I'll push a new release, 1.4.3.1, tomorrow.
Yup, 1.4.4 fixes my problem. Thanks a lot for your effort, it's really appreciated.
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.