Hi,
I saw this reported on the acpi list too [1], so I thought I would post
it here hoping it's the right place to send it.
Using the radeon driver from recent X.org CVS (on Linux 2.6.11.10), my
CPU never enters C3 while under X. This causes me to lose about 30
minutes of battery life.
Aapo Tahkola wrote:
atlantis -root -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps
Changed this for atlantis and it gave me 23fps instead of 3, thanks.
I get 120 fps with color tiling on pretty much same hw as you and 1280x1024
resolution.
Youll need to use xorg cvs and
Peter Zubaj wrote:
Some of r300 driver lockups are card dependant (and for now I have
only these card dependand lockups). Cards which will lock (soon or
later) are 9500 Pro (maybe 9500 too), 9700, 9800. What card do you have ?
According to lspci, it's an ATI Technologies Inc RV350 [Mobility
Nicolai Haehnle wrote:
According to lspci, it's an ATI Technologies Inc RV350 [Mobility Radeon
9600 M10]
That chip is actually known to work fine. Have you tried to run ordinary
OpenGL applications within the normal X.Org server (e.g. Glean, TuxRacer,
Cube, ...)? Are you seeing lockups
Hi,
every now and then I try to run Xglx with the DRI r300 driver. It
doesn't really work at all, but you never know, maybe soon r300 will be
complete enough to get it working properly, so I try.
However, every time I run metacity under Xglx, X locks up immediately. I
was wondering if this
Jon Smirl wrote:
When I first boot it's fine, but when the laptop comes back from S3,
even if everything else works, the serial console just prints a couple
of characters of garbage and then dies. :(
You do get the nice serial console printout at boot right, it's only
not working on resume?
Jon Smirl wrote:
When I first boot it's fine, but when the laptop comes back from S3,
even if everything else works, the serial console just prints a couple
of characters of garbage and then dies. :(
The serial line is probably coming back at the default baud rate and
you were setting it
Jon Smirl wrote:
The only way I can think to debug this is to put bunches of
printks into drivers/video/aty/radeon_pm.c and then hook a serial
console up to the laptop. [...]
Hmm. I could try that (though not in the next couple of weeks because I
won't have access to another machine), will the
Jon Smirl wrote:
Can everyone please try this patch out and see if loading radeonfb
causes any problems on your system. Having radeonfb loaded on x86 is
not a normal case. Radeon Xegl is going to depend on having both
radeon and radeonfb loaded so I need to know if this will cause
problems.
If
Jon Smirl wrote:
My patch will do nothing for the S3 resume problem. There must be some
bug in the radeonfb power management code. The only way I can think to
debug this is to put bunches of printks into
drivers/video/aty/radeon_pm.c and then hook a serial console up to the
laptop. [...]
Hmm.
Hi,
I recently updated my x.org, mesa and r300 trees to current code, but
the machine would lock up if I moved the mouse when a 3d app was
running. This used to happen a while ago too, but then Vladimir fixed it
by calling RADEONWaitForIdleMMIO() in RADEONChooseCursorCRTC():
Dave Airlie wrote:
I reapplied Vladimir's fix and the machine doesn't lock up any more. Maybe the
fix should be checked in to CVS again?
http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_mergedfb.c?rev=1.9view=log
v 1.7 backs it out because it is buggy...
I know, I
Hi,
due to kernel interface changes between 2.6.10 and 2.6.11, the version
of DRM included in the r300_driver CVS tree won't compile on my
2.6.11-rc4 kernel.
The attached patch fixes the problem for me (it compiles and seems to
work too). Could it be merged into CVS so r300_driver
13 matches
Mail list logo
