Created attachment 44389 [details] [review] Xorg log containing crash and backtrace. My card (Radeon HD 3650 AGP 512MB) makes my monitor rapidly flash (black screen for just a moment) with kernel modesetting in 2.6.37 (tried 2.6.38 too). Moreover, from time to time, especially watching flash videos or using 3D effects, Xorg goes in loop and lock the computer. Only from time to time I'm able to get to VT. # uname -a Linux myhost 2.6.37-ARCH #1 SMP PREEMPT Tue Mar 8 08:08:06 UTC 2011 i686 AMD Athlon(TM) XP 1800+ AuthenticAMD GNU/LinuxLinux myhost 2.6.37-ARCH #1 SMP PREEMPT Tue Mar 8 08:08:06 UTC 2011 i686 AMD Athlon(TM) XP 1800+ AuthenticAMD GNU/Linux # lspci | grep VGA 01:00.0 VGA compatible controller: ATI Technologies Inc RV635 PRO AGP [Radeon HD 3650] Distro: Arch Linux Xorg version: 7.6 Xserver version: 1.9.4 Ati video driver version: 6.14 Mesa: 7.10.1 (Gallium)
Created attachment 44390 [details] dmesg (general, not related to the crash)
Don't know if it's relevant: I use a DVI to VGA adapter to attach my CRT monitor.
Does booting with radeon.agpmode=-1 on the kernel command line in grub help?
(In reply to comment #3) > Does booting with radeon.agpmode=-1 on the kernel command line in grub help? It doesn't happen always, so I should live for some time with that option. I've lived for some time with "radeon.new_pll=0" to workaround the flickering and I've never had the crash anymore since then. Flickering bug report: https://bugzilla.redhat.com/show_bug.cgi?id=677813 I'll try "radeon.agpmode=-1" and let you know ...
radeon.new_pll=0 is not a valid parameter with either 2.6.37 or 2.6.38. If you are setting that option, the drm is not loading and you are probably getting UMS with sw rendering.
(In reply to comment #5) > radeon.new_pll=0 is not a valid parameter with either 2.6.37 or 2.6.38. If you > are setting that option, the drm is not loading and you are probably getting > UMS with sw rendering. Exactly, radeon.new_pll=0 makes the system run with UMS and no 3D, so there's no flashing with UMS. Turning to the specific problem, I've noticed some improvements using radeon.agpmode=-1: - I've had several problems with KWin effects in KDE with elements of the panel disappearing and several strangenesses before specifying agpmode=-1, but now 3D seems to work perfectly; - I've not experienced the crash anymore, but we're talking of only a couple of hours of usage 'till now; - the flicker is still here.
(In reply to comment #3) > Does booting with radeon.agpmode=-1 on the kernel command line in grub help? Confirmed: after a week of usage no problem so far. Just the flash keeps going, but that's a separate (DRM) issue, right? So, I should put radeon.agpmode=-1 on grub,right? Thanks for the help provided!
(In reply to comment #7) > (In reply to comment #3) > > Does booting with radeon.agpmode=-1 on the kernel command line in grub help? > > Confirmed: after a week of usage no problem so far. Just the flash keeps going, > but that's a separate (DRM) issue, right? Does the flash happen at regular intervals (like every 30 seconds or so)? upowerd and one of the kde daemons poll the monitors at regular intervals to check if they are connected which can cause flickering. > > So, I should put radeon.agpmode=-1 on grub,right? Yes. On the kernel command line in grub.
(In reply to comment #8) > Does the flash happen at regular intervals (like every 30 seconds or so)? > upowerd and one of the kde daemons poll the monitors at regular intervals to > check if they are connected which can cause flickering. > Yes, it more ore less quite regular... is there some test I could perform to see if it's upowerd / kded doing the polling? For instance: should it be present in kdm if it's what you're thinking of?
Does the screen blink if you boot to runlevel 3 (or whatever the non-X runlevel is on your distro), i.e., boot to the kms console? You can also try stopping upowerd or keventd (I think).
(In reply to comment #10) > Does the screen blink if you boot to runlevel 3 (or whatever the non-X runlevel > is on your distro), i.e., boot to the kms console? You can also try stopping > upowerd or keventd (I think). I confirm that the screen doesn't flicker in runlevel 3 (non-X).
Screen flickering now happens almost only on KDE startup and not after, however I'll keep this report for the crash problem. With "agpmode=-1" I experience no crash at all, but I should keep it even with kernel 2.6.39 because the crash still happens without the option. Would it make sense to disable AGP mode by default for all the cards same as mine?
(In reply to comment #12) > With "agpmode=-1" I experience no crash at all, but I should keep it even with > kernel 2.6.39 because the crash still happens without the option. How about agpmode=1 or 2? > Would it make sense to disable AGP mode by default for all the cards same as > mine? I think it's worth considering disabling AGP by default for all cards with a PCIe GART (as opposed to the old PCI GART). It should be an overall win for stability, the main question is how it would impact performance on systems where AGP is stable.
(In reply to comment #13) > (In reply to comment #12) > > With "agpmode=-1" I experience no crash at all, but I should keep it even with > > kernel 2.6.39 because the crash still happens without the option. > > How about agpmode=1 or 2? I'll double check, but if I remeber correctly it was as bad as with no "agpmode" option. > > Would it make sense to disable AGP mode by default for all the cards same as > > mine? > > I think it's worth considering disabling AGP by default for all cards with a > PCIe GART (as opposed to the old PCI GART). It should be an overall win for > stability, the main question is how it would impact performance on systems > where AGP is stable. If I'd have to choose between stability over performance for default settings I'd go for stability. Another option would be a blacklist for "bad" cards (as mine) or whitelist for "good" cards. Moreover AGP cards are quite outdated, I woundn't expect people to use them for high performance applications with open driver.
Wow, great news! I've tried again with the last Arch Linux updates and everything works fine! I get no more problems without "agpmode=-1", and, as dmesg says, AGP is in 4x mode! core/kernel26 2.6.39.3-1 extra/xorg-server 1.10.3-2 extra/xf86-video-ati 6.14.2-1 extra/mesa 7.11-1 extra/ati-dri 7.11-1 I'm closing this bug, as it's fixed for me. Thanks for the great work, even if we don't know exactly we're the fix.
Created attachment 49987 [details] dmesg with AGP 4x working correctly
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.