Hello All,Sorry for possible offtopic, but I have a question related to Radeon 9250 card lockups. I am doing an experimental research project on graphics engine resource management based on the r200 driver. I have modified the drm implementation so that all the commands sent to the ring on behalf
On 1/26/06, Michael Bautin [EMAIL PROTECTED] wrote:
Hello All,
Sorry for possible offtopic, but I have a question related to Radeon 9250
card lockups. I am doing an experimental research project on graphics engine
resource management based on the r200 driver. I have modified the drm
Michael Bautin wrote:
The lockups I am experiencing are real hardware lockups, because I
debugged ring head tail position and it does not change. Is it possible
to detect hardware lockup and reset hardware automatically, by the way?
I've read that Longhorn display drivers for existing hardware
On Thu, 17 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
On Wed, 2005-03-16 at 17:46 -0500, Vladimir Dergachev wrote:
So can we be sure that one can do arbitrary INREG() on Radeons without
fear of lockup ?
I think so, in general.
Great - thank you !
Vladimir Dergachev
--
On Wed, 16 Mar 2005, Michel [ISO-8859-1] Dänzer wrote:
Disclaimer: I don't pretend to understand 100% how all this stuff works
either, but I think my understanding has improved a little recently. :)
Michel, I think we are misunderstanding each other.
I am not talking about synchronization of
On Wed, 2005-03-16 at 15:35 -0500, Vladimir Dergachev wrote:
On Wed, 16 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
Disclaimer: I don't pretend to understand 100% how all this stuff works
either, but I think my understanding has improved a little recently. :)
Michel, I think we are
Vladimir Dergachev wrote:
Well, I thought I'd also point out that this solves the lockups I
was experiecing with the r300 driver, too :-)
Really ? And you can move cursor freely on r300 without lockups ?
I played almost a full game of neverputt... That hasn't happened
with the r300 driver in
I am quite certain, that, at least on mach64 hardware, an attempt to
access framebuffer by CPU while the GUI engine is active will result in a
hard lockup.
If this was true with Radeons, you'd get a lockup every time the
hardware cursor shape changes. I guess the memory controller has
improved...
I backed out the RadeonWaitForIdleMMIO() out of radeon_mergedfb.c.
Also, I am no longer able to observe the lockup on my hardware that I saw
earlier, perhaps something else got fixed.
I am still curious to know what are the rules for accessing Radeon
registers, perhaps, when I have more spare
On Wed, 2005-03-16 at 17:46 -0500, Vladimir Dergachev wrote:
So can we be sure that one can do arbitrary INREG() on Radeons without
fear of lockup ?
I think so, in general.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast|
Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we
should not be reading from registers with engine busy.
Something may be
Well, I thought I'd also point out that this solves the lockups I was
experiecing with the r300 driver, too :-)
Really ? And you can move cursor freely on r300 without lockups ?
I played almost a full game of neverputt... That hasn't happened with the
r300 driver in a very long time :-)
Vladimir Dergachev wrote:
Well, I thought I'd also point out that this solves the lockups I
was experiecing with the r300 driver, too :-)
Really ? And you can move cursor freely on r300 without lockups ?
I played almost a full game of neverputt... That hasn't happened with
the r300 driver in
On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Michel Dänzer wrote:
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we
On Tue, 2005-03-15 at 09:53 -0500, Alex Deucher wrote:
On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
This would mean that on r300 this fix is not needed, but rv350 locks up
without it.
In that case perhaps it makes sense to only wait for idle on
On Tue, 15 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
On Tue, 2005-03-15 at 09:53 -0500, Alex Deucher wrote:
On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
This would mean that on r300 this fix is not needed, but rv350 locks up
without it.
In that case
On Tue, 15 Mar 2005, Vladimir Dergachev wrote:
On Tue, 15 Mar 2005, Michel [ISO-8859-1] Dänzer wrote:
On Tue, 2005-03-15 at 09:53 -0500, Alex Deucher wrote:
On Mon, 14 Mar 2005 22:14:25 -0500 (EST), Vladimir Dergachev
[EMAIL PROTECTED] wrote:
This would mean that on r300 this fix is not needed,
Disclaimer: I don't pretend to understand 100% how all this stuff works
either, but I think my understanding has improved a little recently. :)
On Tue, 2005-03-15 at 20:07 -0500, Vladimir Dergachev wrote:
On Tue, 15 Mar 2005, Vladimir Dergachev wrote:
My understanding was that for
On Sunday 13 March 2005 23:46, Adam K Kirchhoff wrote:
Adam K Kirchhoff wrote:
I really am confused. This was all working (with my 9200) prior to
reinstalling Debian on my system on Friday. Thankfully it still works
(with drm 1.15.0) on my FreeBSD installation. Not really sure if that
Vladimir Dergachev wrote:
Alright... So drm from both February 14th and January 1st are
locking up as well... Which is odd since I never had any of these
problem till this weekend. I'll start rolling back changes to the
Mesa dri driver... Perhaps this isn't directly related to the drm.
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
Alright... So drm from both February 14th and January 1st are locking up
as well... Which is odd since I never had any of these problem till this
weekend. I'll start rolling back changes to the Mesa dri driver...
Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
Alright... So drm from both February 14th and January 1st are
locking up as well... Which is odd since I never had any of these
problem till this weekend. I'll start rolling back changes to the
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir
added to RADEONChooseCursorCRTC() on February 18th. I think this
function will be
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir
added to RADEONChooseCursorCRTC() on February 18th. I think
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir
Michel Dnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the
On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by
Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we should
not be reading from registers with engine busy.
Something may be needed, but probably not a wait for idle (which may
never succeed on an SMP system). Other
Michel Dnzer wrote:
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we should
not be reading from registers with engine busy.
Something may be needed, but probably not a wait for idle (which may
never succeed on an
[[[
I am also cross posting to xorg mailing list.
The e-mail below discusses a RADEONWaitForIdleMMIO() call I put in
radeon_mergedfb.c before OUTREGP() calls in cursor functions.
The call was needed as OUTREGP() calls INREG() implicitly.
However, it turns out that this call breaks on SMP systems
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we should
not be reading from registers with engine busy.
Something may be needed, but probably not a wait
On Sunday 13 March 2005 03:10, Adam K Kirchhoff wrote:
Was it always shared with the USB controller? Can you try changing that?
Some more info for both of you...
I remarked, in an earlier e-mail, that glxgears wouldn't cause the
lockups. That's not true. For whatever reason, it doesn't
Nicolai Haehnle wrote:
On Sunday 13 March 2005 03:10, Adam K Kirchhoff wrote:
Was it always shared with the USB controller? Can you try changing that?
Some more info for both of you...
I remarked, in an earlier e-mail, that glxgears wouldn't cause the
lockups. That's not true. For
On Sun, 2005-03-13 at 07:43 -0500, Adam K Kirchhoff wrote:
Nicolai Haehnle wrote:
On Sunday 13 March 2005 03:10, Adam K Kirchhoff wrote:
Was it always shared with the USB controller? Can you try changing that?
Some more info for both of you...
I remarked, in an earlier
On Sat, 2005-03-12 at 21:10 -0500, Adam K Kirchhoff wrote:
[snip]
[drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
held 0 owner ec8fce80 f7669180
[drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held,
held -2147483648 owner ec8fce80 f7669180
irq 16:
Jan Gukelberger wrote:
On Sat, 2005-03-12 at 21:10 -0500, Adam K Kirchhoff wrote:
[snip]
[drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
held 0 owner ec8fce80 f7669180
[drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held,
held -2147483648 owner
Vladimir Dergachev wrote:
don't recall ever seeing message from the kernel about nobody caring
about irq 16, or about radeon_cp_reset... With my 9800, I was getting
radeon_cp_dispatch_swap errors.
I do know, however, that my 9200 was working just last week or the week
before. Hmmm... I think my
Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
don't recall ever seeing message from the kernel about nobody caring
about irq 16, or about radeon_cp_reset... With my 9800, I was getting
radeon_cp_dispatch_swap errors.
I do know, however, that my 9200 was working just last week or the
week
Alright... So drm from both February 14th and January 1st are locking up as
well... Which is odd since I never had any of these problem till this
weekend. I'll start rolling back changes to the Mesa dri driver... Perhaps
this isn't directly related to the drm.
Oh, I've also flashed my
On Friday I finally decided to reinstall debian on my box.. I started
with a fresh install, and then upgraded to Xorg cvs... I grabbed the
latest Mesa from cvs, as well as the latest drm.
[drm] Initialized drm 1.0.0 20040925
[drm] Initialized radeon 1.15.0 20050208 on minor 0: ATI Technologies
Odd. This is now happening, as well, with the drm from the 2.6.11
kernel. The card works fine with the drivers from XiG, however, so it
doesn't appear to be a hardware problem.
Adam
Adam K Kirchhoff wrote:
On Friday I finally decided to reinstall debian on my box.. I started
with a fresh
On Sat, 2005-03-12 at 14:30 -0500, Adam K Kirchhoff wrote:
When trying neverputt:
[drm] Loading R200 Microcode
[drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
held 0
owner da0fcd80 d2809b80
Weird, does this only happen when running a 3D client, or also without?
Sounds like there could be problems with Paul's texture upload changes.
Paul patch doesn't make its way to 2.6.11 ? Because Adam says he
gots the same prob with 2.6.11 right ?
Jerome Glisse
---
SF email is sponsored by - The IT Product Guide
Odd. This is now happening, as well, with the drm from the 2.6.11 kernel.
The card works fine with the drivers from XiG, however, so it doesn't appear
to be a hardware problem.
wierd.. can you boot without X, and modprobe drm debug=1 then modprobe
radeon then start X? and send me on the
On Sat, 2005-03-12 at 23:52 +0100, Jerome Glisse wrote:
Sounds like there could be problems with Paul's texture upload changes.
Paul patch doesn't make its way to 2.6.11 ? Because Adam says he
gots the same prob with 2.6.11 right ?
You removed the context this was referring to:
[...] I
Michel Dnzer wrote:
On Sat, 2005-03-12 at 14:30 -0500, Adam K Kirchhoff wrote:
When trying neverputt:
[drm] Loading R200 Microcode
[drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
held 0
owner da0fcd80 d2809b80
Weird, does this only happen when running a 3D client,
Dave Airlie wrote:
Odd. This is now happening, as well, with the drm from the 2.6.11 kernel.
The card works fine with the drivers from XiG, however, so it doesn't appear
to be a hardware problem.
wierd.. can you boot without X, and modprobe drm debug=1 then modprobe
radeon then start X? and
Hi all,
I'm using a 3D prophet Radeon 8500LE and the lastest DRI drivers from
CVS + S3TC patch .
I've noticed that I can't play to ArmyOps , because after few time
I've started the game the game image simply freeze . I can hear the
sound of the game, but I can't do anything. CTRL + ALT +
49 matches
Mail list logo
