Michel Dänzer wrote:
On Tue, 2005-05-24 at 23:26 +0200, Rune Petersen wrote:
Michel Dänzer wrote:
> On Tue, 2005-05-24 at 21:44 +0200, Rune Petersen wrote:
>
>> Hi,
>> When experimenting with UT2004 demo I get:
>> DRM_RADEON_TEXTURE: return = -22
>>offset=0x04823000
>>image width=32 he
On Mer, 2005-05-25 at 21:42, Michel Dänzer wrote:
> Anything that isn't used for pre-R300 chips as well, as those don't seem
> to suffer from the same kind of lockups.
Assuming alignment is just performance could be erroneous if there are
chip bugs like interlocking errors however, or end of ring
Vladimir Dergachev wrote:
1. Are you using merged framebuffer ? Try turning it off.
I'm not sure I understand what are you talking about, btw:
(WW) RADEON(0): Failed to detect secondary monitor, MergedFB/Clone mode
disabled
2. Try turning of SilkenMouse - it is one of the options in xorg.
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Could you add this line to the
> end of mga_driver_preinit *and* to the beginning of mga_dma_init:
>
> DRM_ERROR("dev = %p, dev_private = %p\n", dev, dev->dev_private);
>
> That should shed some light on things.
Here you go.
Cheers,
Chris
On Wed, 2005-05-25 at 16:11 -0400, Vladimir Dergachev wrote:
> >>> WPTR == RPTR means the ring is empty, if you mean that. The DRM handles
> >>> that though, unless you made r300 specific changes to the ring handling.
> >>> (I don't think that RBBM_STATUS would indicate the CP being busy in that
>
WPTR == RPTR means the ring is empty, if you mean that. The DRM handles
that though, unless you made r300 specific changes to the ring handling.
(I don't think that RBBM_STATUS would indicate the CP being busy in that
case, anyway)
No there are no R300 specific modifications as far as I know.
B
On Wed, 2005-05-25 at 15:06 -0400, Vladimir Dergachev wrote:
>
> On Wed, 25 May 2005, Michel [ISO-8859-1] Dnzer wrote:
>
> > On Wed, 2005-05-25 at 11:58 -0400, Vladimir Dergachev wrote:
> >>
> >> I am thinking that there might be a bug where CP engine does something
> >> funny when the ring buffe
On Wed, 25 May 2005, Michel [ISO-8859-1] D�er wrote:
On Wed, 2005-05-25 at 11:58 -0400, Vladimir Dergachev wrote:
I am thinking that there might be a bug where CP engine does something
funny when the ring buffer is completely full. Maybe we need to keep a
small chunk of space open so that st
Michel Dänzer wrote:
>On Mon, 2005-05-23 at 18:45 +0200, Nicolai Haehnle wrote:
>
>
>>It is equally likely that the lockup is caused by, say, alignment or
>>wraparound issues of the ring buffer.
>>Note that fglrx always submits commands in indirect buffers, which are
>>stored linearly in physi
On Mon, 2005-05-23 at 18:45 +0200, Nicolai Haehnle wrote:
>
> It is equally likely that the lockup is caused by, say, alignment or
> wraparound issues of the ring buffer.
> Note that fglrx always submits commands in indirect buffers, which are
> stored linearly in physical memory. We, on the oth
On Wed, 2005-05-25 at 11:58 -0400, Vladimir Dergachev wrote:
>
> I am thinking that there might be a bug where CP engine does something
> funny when the ring buffer is completely full. Maybe we need to keep a
> small chunk of space open so that start and end pointers are different.
WPTR == RPTR
On 5/25/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> No - because then the read pointer would be stationary. The CP engine
> should not submit commands until the 3d engine busy is 0. (but it reacts
> faster than we can catch this).
>
> My interpretation was that CP engine just keeps submitt
On Wed, 25 May 2005, Nicolai Haehnle wrote:
On Wednesday 25 May 2005 17:01, Vladimir Dergachev wrote:
Are you sure the read pointer is still moving 2mins after the lockup?
That
would be rather surprising, to say the least.
I think I can imagine how this might be happenning. You see a loc
On Tue, 2005-05-24 at 23:26 +0200, Rune Petersen wrote:
> Michel Dänzer wrote:
>
> > On Tue, 2005-05-24 at 21:44 +0200, Rune Petersen wrote:
> >
> >> Hi,
> >> When experimenting with UT2004 demo I get:
> >> DRM_RADEON_TEXTURE: return = -22
> >>offset=0x04823000
> >>image width=32 he
On Wednesday 25 May 2005 17:01, Vladimir Dergachev wrote:
> > Are you sure the read pointer is still moving 2mins after the lockup?
That
> > would be rather surprising, to say the least.
> >
>
> I think I can imagine how this might be happenning. You see a lockup from
> the driver point of view i
Are you sure the read pointer is still moving 2mins after the lockup? That
would be rather surprising, to say the least.
I think I can imagine how this might be happenning. You see a lockup from
the driver point of view is when the 3d engine busy bit is constantly on.
The read pointer is upda
> The increases of the write pointer is easily by 6 dwords is easily explained
> by radeon_do_cp_idle: This function always emits a series of 6 dwords
> (cache flushes and stuff) before calling wait_for_idle. My understanding is
> that these commands make sure the chip is in a completely clean stat
Hi!
ed was recently removed from Gentoo's default profile - and dripkg's
install.sh requires ed.
install.sh also uses sed, so why not just remove the ed dependancy from
install.sh?
Here's a patch which does just that.
Thanks
--
Roy Marples <[EMAIL PROTECTED]>
Gentoo Linux Developer
--- instal
On Tuesday 24 May 2005 22:54, Jerome Glisse wrote:
> On 5/24/05, Nicolai Haehnle <[EMAIL PROTECTED]> wrote:
> > Unfortunately, I don't think so. The thing is, all those OUT_RING and
> > ADVANCE_RING commands do not really call into the hardware immediately;
all
> > they do is write stuff to the ri
19 matches
Mail list logo
