[Bug 28402] random radeon/kms/drm related freezes with kernel 2.6.34

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #69 from Da Fox <da_fox at mad.scientist.com> 2010-09-16 07:10:38 PDT ---
(In reply to comment #68)
> I have two questions:
> 
> 1) Now since we established that the vmembase at zero patch fixes or works
> around the problem - while the patch to align vram from comment #47 does not,
> and now that I bisected the range of commits down to about 10 and as far as I
> understand Da Fox and Lukas even bisected down to exact one commit: What next?
> Is the vmembase at zero patch the proper fix? Actually to me it seems more like
> a work-around. Is there another fix you propose? I would love to see a fix in
> time for 2.6.36, although I still have to figure out on how to get a kernel
> after 2.6.33 that does either userspace software suspend or TuxOnIce stably on
> my ThinkPad T42 (see bug #18162 regarding userspace software suspend and
> tuxonice-devel mailing list for TuxOnIce related stuff).
> 
We are currently testing a variation on this patch as suggested by Dave Airlie
on IRC. It involves trying to put vram on memory addresses other than 0, but
with some restriction on alignment and overlap with the GTT. Interesting values
to test would be 0x10000000, 0x18000000 and 0xf0000000, provided that they
don't cause overlap with the GTT area. 
You can see where your GTT area lives by looking at dmesg after boot:
---8<---------
$ dmesg | grep GTT
radeon 0000:01:00.0: GTT: 256M 0xD0000000 - 0xDFFFFFFF
[drm] radeon: 256M of GTT memory ready.
--->8---------
This shows that gtt_start=0xD0000000 and gtt_end=0xDFFFFFFF.You should make
sure that either 'base + "size of your vram" <= gtt_start' or that 'gtt_end <
base', where base is one of 0x10000000, 0x18000000 or 0xf0000000.

I have tested placing vram at 0x10000000, which worked for me for two days
without a freeze. I am currently testing vram at 0xf0000000, which thus has not
caused a freeze either.
Please post your results here too.

> 2) Re Comment #65:
> 
> "The AGPMode xorg option isn't used with kms (the AGP mode is set before X
> starts when the drm loads).  To force a particular AGP mode with kms, use the
> agpmode module parameter: radeon.agpmode=x where x=-1,1,2,4,8.  -1 disables AGP
> and uses the on-chip gart mechanism instead."
> 
> Is it necessary? How do I find out with AGP mode is used. I'd prefer when it
> used best AGP mode (that should be 4x on my ThinkPad T42) automatically.
Again you can get this info by looking at your dmesg output:

---8<---------
$ dmesg | grep -i AGP
Linux agpgart interface v0.103
agpgart-intel 0000:00:00.0: Intel 855PM Chipset
agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
[drm] AGP mode requested: 4
agpgart-intel 0000:00:00.0: AGP 2.0 bridge
agpgart-intel 0000:00:00.0: putting AGP V2 device into 4x mode
radeon 0000:01:00.0: putting AGP V2 device into 4x mode
--->8---------
So currently I am running with AGP mode 4x.
As for is it necessary, I don't know, but I can't imagine it making a
difference really.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.