M6 LY is corrupt/crashes after suspend/resume, need AGPMode 2

Forwarding bug report from a Ubuntu user:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/248438

On the mobility M6 LY, after doing a suspend/resume, graphical errors start accumulating, and eventually locks up.

Specifying Option "AGPMode" "2" makes the problems go away.

Original Report:
"A recent (last month or two) driver update causes the M6 LY to behave weirdly when suspending/resuming.

On resume, graphical errors pop up. Horizontal regions (I'd say 10-20 pixels long and 1 pixel high) begin to appear when regions are redrawn (text in consoles scrolling/windows resizing). Additionally, regions appear in some windows where (moving left to right and top to bottom) the first 100 or so pixels are scrambled followed by a black region. Resizing the windows makes the affected regions disappear, but they are replaced by new glitches. It also seems like hardware mouse acceleration is effected. The mouse moves with a .5sec refresh rate after restarting.

Eventually, the glitches get more and more common until the machine locks hard (no ctrl+alt+backspace, caps lock key is unresponsive).

Xorg.log doesn't have any errors, so I'm at a loss to figure out where to look. Looking at lspci -vv, it seems like there might be a problem with the memory detection routines? There is only 16MB of video ram on this machine, and 128MB is reported (region 0). If it was including AGP memory, it would be in powers-of two and 116MB isn't.

Any suggestions? The attached log shows me booting, suspending/resuming and switching to/from a VT. When I switched to the VT, nothing came up. I tried upgrading my ati driver with a version from https://launchpad.net/~tormodvolden/+archive , to no effect.

$ lspci -vv
1:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA controller])
"

Created an attachment (id=18585)
Xorg.0.log.old

What happens if Option "AGPMode" isn't specified at all?

Specifying no value results in the errors and lockup.

I believe the user also tested AGPMode 1 and 4 (default), and only found 2 to work for this hardware.

Unfortunately, this is one of the problems with AGP. Certain chip/bridge combinations only only work reliably at certain speeds. Most AGP bridges are busted in one way or another. We've been through this several times in the radeon driver (what to pick for default AGP mode).

Hi Alex,

Could we set up quirks for handling it?

How does fglrx deal with this? Quirks?

Dunno how -fglrx handles it, but there are situations sort of akin to this in -intel that are handled by quirks, implemented in xf86-video-intel/src/i830_quirks.c. There is a 'quirk_flag' added to the pI830 structure, and then quirks are applied on a per-PCIID basis in the i830_quirk_list[] structure.

This approach is nice from the distro standpoint because as we run across new hardware requiring that particular tweak, we can add support for that HW with one line of (non-executable) code - which is also easy to justify to folks for backporting as well.

Created an attachment (id=18620)
Example quirk system adapted from -intel

Here's a rough sketch of what I'm thinking about (borrowed from the -intel source). A few defines would also need added to radeon.h, and of course at the point where the AGPMode default is selected, it'd need to test for the quirk. If this looks like something that might be acceptable, let me know and I can clean it up into a proper patch... Or maybe there's a better approach I've missed?

Created an attachment (id=18623)
Add quirk system for AGPMode

Here's a stab at adding a list 'o quirks to radeon_dri.c.

I decided to check against subsys as well as the chip and hostbridge since it sounds like these bugs are extraordinarily hardware specific.

The user can still override whatever we select as a default. So if they want to fiddle with AGP Mode settings in BIOS or whatever, they can still force it to whatever they desire in xorg.conf.

Let me know what you think of this.

If we're going there, here's what I found in Debian bugs:
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467460
  Mobility 9600 M10 RV350 needs AGPMode 1
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462590
  ATI Technologies Inc M18 JN [Radeon Mobility 9800] needs AGPMode 4
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467235
  ATI Technologies Inc Radeon Mobility M6 LY needs AGPMode 1
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461144
  R200 QM [Radeon 9100, 1002,514d] needs AGPMode 4

Here's what we'd add to the driver's quirks table:

    /* Intel 82852/82855 host bridge / Mobility 9600 M10 RV350 Needs AGPMode 1 (deb #467460) */
    { PCI_VENDOR_INTEL,0x3580, PCI_VENDOR_ATI,0x4e50, PCI_VENDOR_ACER,0x0061, 1 },

    /* Intel 82865G/PE/P DRAM Controller/Host-Hub / Radeon Mobility 9800 Needs AGPMode 4 (deb #462590) */
    { PCI_VENDOR_INTEL,0x2570, PCI_VENDOR_ATI,0x4a4e, PCI_VENDOR_DELL,0x5106, 4 },

    /* VIA VT8377 Host Bridge / R200 QM [Radeon 9100] Needs AGPMode 4 (deb #461144) */
    { 0x1106,0x3189, PCI_VENDOR_ATI,0x514d, 0x174b,0x7149, 4 },

Debian #467235 didn't have lspci output or an Xorg.0.log attached, so I dunno what the host bridge is in that case.

<email address hidden> wrote:
> --- Comment #11 from Bryce Harrington <email address hidden> 2008-09-02 14:43:54 PST ---
>
> Debian #467235 didn't have lspci output or an Xorg.0.log attached, so I dunno
> what the host bridge is in that case.
>

Should be
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=32;filename=Xorg.0.log;att=1;bug=467235

Brice

Created an attachment (id=18681)
Update to include a couple more systems

committed: 937b7ac2a259cf504a19dcf62a58b1db1afb8eb9

Thanks!