Bug 11299

Summary: M56GL (Mobility FireGL V5200) not working
Product: xorg Reporter: David Korth <gerbilsoft>
Component: Driver/avivoAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: lool
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
xf86-video-avivo log (cold boot)
none
xf86-video-avivo log (after loading fglrx)
none
radeondump - cold boot
none
radeondump - fglrx, 1600x1200
none
radeondump - fglrx, 1280x1024
none
radeondump - fglrx, 1024x768
none
radeondump - fglrx, vtswitch to console
none
radeondump - fglrx, vtswitch back to X
none
radeondump - avivo after running fglrx
none
X.org log after testing latest git
none
xorg.conf for avivo
none
radeondump of "working" avivo none

Description David Korth 2007-06-17 22:52:05 UTC
I have a ThinkPad T60p, model 2623-DDU, with an ATI Mobility FireGL V5200 (M56GL) video chip. It's similar to the X1600, so I replaced the 71C5 PCI ID in the Avivo driver with the M56GL's PCI ID (71C4). Unfortunately, it didn't work. I will attach X.org logs from the avivo driver as well as fglrx card dumps from Jerome Glisse's version of radeondump.
Comment 1 David Korth 2007-06-17 22:53:36 UTC
Created attachment 10349 [details]
xf86-video-avivo log (cold boot)

X.org log when starting the avivo driver from a cold boot. The driver doesn't start successfully, and the system returns to text mode.
Comment 2 David Korth 2007-06-17 22:55:33 UTC
Created attachment 10350 [details]
xf86-video-avivo log (after loading fglrx)

X.org log when starting the avivo driver after initially loading fglrx. The result is a screen filled with garbage. The system isn't hard-locked, and the screen state can be restored via ssh by killing X and reloading it with fglrx.
Comment 3 David Korth 2007-06-17 22:56:59 UTC
Created attachment 10352 [details]
radeondump - cold boot

radeondump after cold-booting the system.
Comment 4 David Korth 2007-06-17 22:57:47 UTC
Created attachment 10353 [details]
radeondump - fglrx, 1600x1200

radeondump of fglrx after starting X in 1600x1200 resolution.
Comment 5 David Korth 2007-06-17 22:59:25 UTC
Created attachment 10354 [details]
radeondump - fglrx, 1280x1024

radeondump of fglrx after switching to 1280x1024 resolution.
Comment 6 David Korth 2007-06-17 23:00:01 UTC
Created attachment 10355 [details]
radeondump - fglrx, 1024x768

radeondump of fglrx after switching to 1024x768 resolution.
Comment 7 David Korth 2007-06-17 23:00:38 UTC
Created attachment 10356 [details]
radeondump - fglrx, vtswitch to console

radeondump of fglrx after switching to console.
Comment 8 David Korth 2007-06-17 23:01:27 UTC
Created attachment 10357 [details]
radeondump - fglrx, vtswitch back to X

radeondump of fglrx when switching from console back to X.
Comment 9 David Korth 2007-06-17 23:02:31 UTC
Created attachment 10358 [details]
radeondump - avivo after running fglrx

radeondump of the avivo driver after running fglrx. The screen was filled with garbage at the time.
Comment 10 David Korth 2007-06-17 23:06:43 UTC
lspci listing of the video card: (PCI ID: 1002:71c4)

01:00.0 VGA compatible controller: ATI Technologies Inc M56GL [Mobility FireGL V5200] (prog-if 00 [VGA])
        Subsystem: Lenovo ThinkPad T60p
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at d0000000 (32-bit, prefetchable) [size=256M]
        Region 1: I/O ports at 2000 [size=256]
        Region 2: Memory at ee100000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at ee120000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express Legacy Endpoint IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
                Device: Latency L0s <4us, L1 unlimited
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
                Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0
                Link: Latency L0s <64ns, L1 <1us
                Link: ASPM L0s L1 Enabled RCB 64 bytes CommClk+ ExtSynch-
                Link: Speed 2.5Gb/s, Width x16
        Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
Comment 11 Jerome Glisse 2007-06-18 08:22:47 UTC
I think commit a6d08ad97fede2cd89d1b793aad71421c8e158e3 should fix
your problem please test with lastest git and report.
Comment 12 David Korth 2007-06-18 08:32:33 UTC
I tested the M56GL with the latest git version of avivo, and it still fails with the same problem.
Comment 13 Jerome Glisse 2007-06-18 09:44:32 UTC
So driver still SIGFPE (signal 8) and you see this at bottom of xorg log
with backtrace information ? (please attach new xorg log with avivo).
Comment 14 David Korth 2007-06-19 14:01:05 UTC
Created attachment 10378 [details]
X.org log after testing latest git

I tested the latest git version of avivo, and it still SIGFPE's, regardless of whether fglrx was used before or not. (If fglrx was not loaded before, it will return to text-mode; if it was loaded before, it fills the screen with garbage.)
Comment 15 Jerome Glisse 2007-06-19 15:06:10 UTC
Please attach your xorg.conf
Comment 16 David Korth 2007-06-19 15:22:07 UTC
Created attachment 10379 [details]
xorg.conf for avivo

Here's my xorg.conf for the avivo driver. It's the same as my fglrx config, except with a different Device section.
Comment 17 Jerome Glisse 2007-06-20 00:19:57 UTC
Please comment out displaysize line in your monitor section and try again.
Comment 18 David Korth 2007-06-20 06:07:41 UTC
Created attachment 10386 [details]
radeondump of "working" avivo

Ok, I commented out the DisplaySize line and the avivo driver started up, though it isn't exactly "working". The image had a weird "double-vision" glitch where columns were repeated every so often. VT switching was not reliable (sometimes it worked, sometimes it didn't), and switching to a resolution other than 1600x1200 resulted in a black screen. The attached radeondump is from avivo showing the "double-vision" glitch. (fglrx was previously used.)

The same thing happens whether or not fglrx has been used before avivo.
Comment 19 Jerome Glisse 2007-06-21 02:51:21 UTC
Which avivo version are you using ? Please try lastest one i think,
it should work fine on your card.
Comment 20 David Korth 2007-06-23 10:38:07 UTC
I did some more testing with the latest git version, and here's the results.

Display: ThinkPad T60p 1600x1200 LCD (LVDS)
1600x1200: Columns glitch.
1280x1024: The display is still set to 1600x1200 resolution, but the upper-left 1280x1024 shows up correctly. The rest of the screen seems to be mirrored copies of portions of the 1280x1024.
1024x768 and lower: Black screen.

VT switching is completely broken, and sometimes I can't even fix things by reloading fglrx (I have to reboot).
Comment 21 David Korth 2007-06-28 12:13:28 UTC
Quick status update: The last update to the PLL timings fixed the columns glitch on the internal LCD in 1600x1200 mode. 1280x1024 still has the weird wraparound, and 1024x768 and lower don't work at all.

I tested VGA output, and got some weird results. xrandr said the output was 1600x1200 at 75 Hz, but the monitor reported a sync rate of 87 kHz / 69 Hz. The image was all wobbly. Attempting to change the refresh rate in xrandr resulted in no difference. Resolutions lower than 1600x1200 didn't work at all, though 1920x1440 did work (but with the same wobbly problem).
Comment 22 Jerome Glisse 2007-06-28 15:07:43 UTC
I am closing this one, xrandr problems are coming from somethings else
try xrandr --verbose to see that list proposed by randr are not from
your edid (which should appear in xorg log if server launch with enough
verbosity).

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.