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.
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.
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.
Created attachment 10352 [details] radeondump - cold boot radeondump after cold-booting the system.
Created attachment 10353 [details] radeondump - fglrx, 1600x1200 radeondump of fglrx after starting X in 1600x1200 resolution.
Created attachment 10354 [details] radeondump - fglrx, 1280x1024 radeondump of fglrx after switching to 1280x1024 resolution.
Created attachment 10355 [details] radeondump - fglrx, 1024x768 radeondump of fglrx after switching to 1024x768 resolution.
Created attachment 10356 [details] radeondump - fglrx, vtswitch to console radeondump of fglrx after switching to console.
Created attachment 10357 [details] radeondump - fglrx, vtswitch back to X radeondump of fglrx when switching from console back to X.
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.
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
I think commit a6d08ad97fede2cd89d1b793aad71421c8e158e3 should fix your problem please test with lastest git and report.
I tested the M56GL with the latest git version of avivo, and it still fails with the same problem.
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).
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.)
Please attach your xorg.conf
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.
Please comment out displaysize line in your monitor section and try again.
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.
Which avivo version are you using ? Please try lastest one i think, it should work fine on your card.
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).
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).
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.