On Thu, 17 Mar 2005, Michel [ISO-8859-1] Dänzer 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
--
Eart
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 DÃnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http:
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 ti
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...
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 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
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 drawi
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 MMI
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,
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, but rv350 locks up
without it.
In that case per
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 f
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
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 a
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 :-)
Almos
Vladimir Dergachev 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
should not be reading from registers with engine busy.
Something may be needed
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 should
not be reading from registers with engine busy.
Something may be needed, but probably not a wait
[[[
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
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 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
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 t
Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dïnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel DÃnzer 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.
On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dänzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel DÃnzer 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
Michel DÃnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel DÃnzer 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 RADEO
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
> Michel DÃnzer 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
Michel DÃnzer 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 thi
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 ca
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, 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...
Perhaps
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.
Oh,
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
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 BIOS
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
befo
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
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 laptop still has the same
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 ec8fc
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
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...
> >>
> >>
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 what
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 do
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 seem to
cause the lockups if I load the drm module with de
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 s
Michel DÃnzer 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,
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:
> > [..
>
> 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 th
> 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
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 wit
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 ins
46 matches
Mail list logo
