[Needs AGPMode quirk] Freeze with ati driver during boot on 8.10

Please attach your lspci --nnvv output.

Sorry, scrap that, I didn't see you already had provided all the info.

Thanks, all necessary info is provided.

Sounds good.

By the way, I will note that the hardware specs actually specify that the system should be capable of running on agp4x (both the motherboard and the video card support 4x), so i'm not really sure why it only works on 1x.

This bug was fixed in the package xserver-xorg-video-ati - 1:6.9.0+git20081003.f9826a56-0ubuntu4

---------------
xserver-xorg-video-ati (1:6.9.0+git20081003.f9826a56-0ubuntu4) jaunty; urgency=low

  * 100_quirk_system.patch: Add three more quirks for AGPMode issues
    (LP: #296617, #141551)

 -- Bryce Harrington <email address hidden> Mon, 24 Nov 2008 20:32:11 -0800

There's a few other quirks for graphics cards with the 82855 model motherboard to use 1x; possibly it's some hardware bug that 4x doesn't work compatibly.

Update:
I was able to get things to work with agp at 4x, with the following config:

###########
Section "Device"
 Identifier "Configured Video Device"
 Driver "ati"
 Option "AccelMethod" "XAA"
 Option "AGPMode" "4"
 Option "AGPFastWrite" "yes"
 Option "EnablePageFlip" "on"
 Option "RenderAccel" "on"
 Option "DynamicClocks" "on"
 Option "BIOSHotkeys" "on"
EndSection

Section "DRI"
 Mode 0666
EndSection

Section "Extensions"
 Option "Composite" "Enable"
EndSection
###########

Which, by the way, produces a much snappier experience than the default setup which only works with agp1x.

Not sure which of those are the key settings that enable things to work with agp 4x, i don't really have the time to play around and try taking them out one at a time...

note also that i'm running on plain metacity, rather than compiz... but should work just as well...

Hope this info comes handy.

Looking at the options you use:
RenderAccel is on by default anyway.
DynamicClocks is not a valid option any longer.
BIOSHotkeys is not an option any longer (the functionality is always active).
EnablePageFlip should increase performance but may reduce stability.
AGPFastWrite might increase performance but often wrecks stability.
So I think "AccelMethod" "XAA" is the only one that can help for stability.

Whether you try this out or not, it would be nice if you can attach your Xorg.0.log for completeness.

Hi Tormod
Thanks for your quick response

Attaching my Xorg.0.log for your review.

as far trying things - so i should try taking out everything but the XAA?

Oh and by the way, any comments on sections DRI and Extensions? I added those first, separately, before I got around to trying the stuff in the Device section, and those two showed a marked improvement in responsiveness all by themselves...

Before seeing your log I didn't know that you are still on Intrepid, for instance DynamicClocks might still be valid in that version, although it should not add stability anyway. Yes, please try with only XAA.

In Jaunty and later the driver will recognize your card and default to AGPMode 1, but you can still override it.

The DRI and Extensions sections should not be necessary. Are you not getting DRI and Composite without them?

If you have the possibility to try Karmic it would be great, because we would like to make sure it works optimally, and many things have changed since Intrepid.

> Yes, please try with only XAA.

ok, will do, and post here if it still works with agpmode4

> The DRI and Extensions sections should not be necessary. Are you not getting DRI and Composite without them?

what exactly do i look for in xorg log or elsewhere, to know whether they are enabled without these settings?

> If you have the possibility to try Karmic it would be great, because we would like to make sure it works optimally, and many things have changed since Intrepid.

I can try it with the latest alpha livecd, i suppose, and see how things look, and whether apgmode4 works by default, or needs other settings. and whether dri and composite do as well.

Look for "Direct rendering enabled" and "Initializing built-in extension COMPOSITE".

Which I just did in your old log:
(EE) RADEON(0): Static buffer allocation failed. Disabling DRI.
(EE) RADEON(0): At least 66000 kB of video memory needed at this resolution and depth.
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0): MC_FB_LOCATION : 0xebffe800 0x1fff0000
(II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0
(==) RADEON(0): Backing store disabled
(WW) RADEON(0): Direct rendering disabled

So that is why it is stable, DRI is disabled... But compiz and all 3D applications will suck without DRI.

yea, i'm running plain metacity, no compiz...

well, i'll try with just the XAA, under intrepid, and let you know if i can use agpmode4, and will also play with karmic and see what happens there.

will let you know any results. :)

The driver allocates memory for a big combined dual screen (it detects both a VGA and an LCD at 1600x1200):
(II) RADEON(0): Memory manager initialized to (0,0) (3520,4766)
(II) RADEON(0): Reserved area from (0,1600) to (3520,1602)
(II) RADEON(0): Largest offscreen area available: 3520 x 3164

and therefore have no VRAM left for DRI. If you are not using all that screen space, you can configure xorg.conf with a "Virtual" size, see https://wiki.ubuntu.com/X/Config/Resolution

Only DRI will use AGP transfers, so if DRI is disabled is does not matter what AGPMode you are setting. DRI is used for 2 things, 3D hardware acceleration (mesa libraries) and EXA 2D acceleration (in driver). Without DRI, 3D graphics will be software rendered, and EXA will be terribly slow. In Karmic, the driver will switch to XAA if there is no DRI.

I would be curious to see if the memory allocation is different in Karmic. Do you have two monitors connected, and a virtual desktop spanning both?

Hi
indeed, I have two screens on this comp, the built-in lcd at 1600x1200, and an external monitor at 1920x1200, sitting side by side, for a total desktop size of 3520x1200.

I have "virtual" set to "3520 1600".

But, i notice in those lines you pasted out of my xorg, it appears to reserve a much larger screen space? 3520x4766, and 3520x3164... is that normal?

hrm, well, i guess your explanation about DRI and XAA/EXA explains a lot. :)

I am not sure about each of these numbers, but we can hope the memory allocation will be more efficient and dynamic once the kernel memory manager is used. This comes with KMS and DRI2, and it is possible to try it out in Karmic already.