Re: [r300] overflow(?) with ut2004 demo
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 height=1024 >> blit width=1024 height=128 data=0xa6246200 >> >> It is random when in the game this happens. I've even managed to play some CTF before it happened(lots of colors =). >> >> The strange thing is DRM_RADEON_TEXTURE(radeon_cp_texture) returns -EINVAL(-22) when tex.image in NULL which it isn't before or after the call. > > > > radeon_cp_dispatch_texture() also returns EINVAL in a number of other > cases. Is there anything apropos in the kernel output? you are right (I managed to look at the wrong log). [drm:radeon_cp_dispatch_texture] *ERROR* Invalid destination offset So, possibly stating the obvious, there's basically two possibilities: Either the 3D driver indeed uses an invalid offset, or the DRM doesn't check correctly. Please provide some more information about your setup, in particular the exact versions of all the components (X, DDX driver, DRM, 3D driver, kernel, ...) and at least the log file of the X server. linux-2.6.10-rc3-bk2 Mesa CVS & r300_driver CVS - May 24 Xorg CVS - May 5 Rune Petersen Xorg.0.log.gz Description: Binary data
Re: r300 radeon 9800 lockup
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 funnies --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id135&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] the_perfect_frag snapshot
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.conf (**) RADEON(0): Option "SilkenMouse" "0" (**) RADEON(0): Silken mouse disabled One more thing - I have DynamicClocks enabled in my xorg.conf - it would be interesting if this has any effect. Tried either enabled/disabled. glxgears, same lockups. Sorry :( -- Laera Dario Undergraduate student at Computer Science University of Bologna ICQ# 203250303 /==/ http://laera.web.cs.unibo.it Mail to: laera_at_cs.unibo.it dario_at_astec.ms --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [OOPS] MGA DRI in CVS 21-May-2005
--- 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
___
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.comMay 25 20:59:18 hypercube kernel: [drm] Initialized drm 1.0.0 20040925
May 25 20:59:18 hypercube kernel: [drm:mga_driver_preinit] *ERROR* dev =
c833d000, dev_private = d2674b80
May 25 20:59:18 hypercube kernel: [drm] Initialized mga 3.1.2 20050520 on minor
0:
May 25 20:59:18 hypercube kernel: [drm] Used old pci detect: framebuffer loaded
May 25 20:59:18 hypercube kernel: agpgart: Found an AGP 1.0 compliant device at
:00:00.0.
May 25 20:59:18 hypercube kernel: agpgart: Putting AGP V2 device at
:00:00.0 into 2x mode
May 25 20:59:18 hypercube kernel: agpgart: Putting AGP V2 device at
:01:00.0 into 2x mode
May 25 20:59:20 hypercube kernel: [drm:mga_dma_init] *ERROR* dev = c833d000,
dev_private = d2674b80
May 25 20:59:29 hypercube gdm(pam_unix)[21387]: session opened for user chris
by (uid=0)
May 25 20:59:29 hypercube gconfd (chris-21562): starting (version 2.8.1), pid
21562 user 'chris'
May 25 20:59:29 hypercube gconfd (chris-21562): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration
source at position 0
May 25 20:59:29 hypercube gconfd (chris-21562): Resolved address
"xml:readwrite:/home/chris/.gconf" to a writable configuration source at
position 1
May 25 20:59:29 hypercube gconfd (chris-21562): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration
source at position 2
May 25 20:59:38 hypercube gconfd (chris-21562): Resolved address
"xml:readwrite:/home/chris/.gconf" to a writable configuration source at
position 0
May 25 21:00:32 hypercube gconfd (chris-21562): Exiting
May 25 21:00:32 hypercube gdm(pam_unix)[21387]: session closed for user chris
May 25 21:00:37 hypercube kernel: [drm:mga_dma_init] *ERROR* dev = c833d000,
dev_private = d2674b80
May 25 21:00:37 hypercube kernel: agpgart: Found an AGP 1.0 compliant device at
:00:00.0.
May 25 21:00:37 hypercube kernel: agpgart: Putting AGP V2 device at
:00:00.0 into 2x mode
May 25 21:00:37 hypercube kernel: agpgart: Putting AGP V2 device at
:01:00.0 into 2x mode
May 25 21:00:37 hypercube kernel: [drm:mga_dma_init] *ERROR* dev = c833d000,
dev_private =
May 25 21:00:37 hypercube kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0080
May 25 21:00:37 hypercube kernel: printing eip:
May 25 21:00:37 hypercube kernel: dab28c05
May 25 21:00:37 hypercube kernel: *pde = 0ea30067
May 25 21:00:37 hypercube kernel: *pte =
May 25 21:00:37 hypercube kernel: Oops: 0002 [#1]
May 25 21:00:37 hypercube kernel: Modules linked in: mga drm loop intel_agp
agpgart deflate zlib_deflate zlib_inflate twofish serpent aes_i586 blowfish des
sha256 sha1 crypto_null af_key ip_nat_ftp ip_conntrack_ftp snd_rtctimer evdev
eeprom i2c_sensor pcspkr parport_pc lp parport autofs4 i2c_piix4 i2c_dev
i2c_core sunrpc ipv6 ipt_mac ipt_LOG ipt_state iptable_filter ipt_MASQUERADE
iptable_nat ip_conntrack ipt_TOS iptable_mangle ip_tables binfmt_misc
nls_iso8859_1 nls_cp437 vfat fat dm_mod pwc videodev video button uhci_hcd
ohci_hcd ehci_hcd snd_usb_audio snd_usb_lib snd_ens1370 snd_rawmidi
snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc
gameport snd_ak4531_codec snd soundcore prism2_usb p80211 ne 8390 floppy ide_cd
cdrom ext3 jbd
May 25 21:00:37 hypercube kernel: CPU:0
May 25 21:00:37 hypercube kernel: EIP:0060:[]Not tainted VLI
May 25 21:00:37 hypercube kernel: EFLAGS: 00213246 (2.6.11.10)
May 25 21:00:37 hypercube kernel: EIP is at mga_do_init_dma+0x35/0x8b0 [mga]
May 25 21:00:37 hypercube kernel: eax: c00c7814 ebx: d170eed4 ecx:
edx:
May 25 21:00:37 hypercube gdm[21387]: gdm_slave_xioerror_handler: Fatal X error
- Restarting :0
May 25 21:00:37 hypercube kernel: esi: d170eed4 edi: ebp: dab29890
esp: d170ee6c
May 25 21:00:37 hypercube kernel: ds: 007b es: 007b ss: 0068
May 25 21:00:37 hypercube kernel: Process X (pid: 21392, threadinfo=d170e000
task=d7e0b5a0)
May 25 21:00:37 hypercube kernel: Stack: d170ee84 00203286
00203292 ffbb dab29890 00203246
May 25 21:00:37 hypercube kernel: 0001 b870 d170eed4
c01a211a d170eed4 c833d000 c833d000
May 25 21:00:37 hypercube kernel:d170eed4 c6711520 dab29890 dab29963
dab2d00c dab2caf9 c833d000
May 25 21:00:37 hypercube kernel: Call Trace:
May 25 21:00:37 hypercube kernel: [] mga_dma_init+0x0/0xe0 [mga]
May 25 21:00:37 hypercube kernel: [] __copy_f
Re: r300 radeon 9800 lockup
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 > >>> case, anyway) > >> > >> No there are no R300 specific modifications as far as I know. > >> > >> But could it be that a malformed command at the very end of the buffer > >> would cause CP engine to spin ? For example what if a command spans WPTR ? > > > > You mean that you think you've written a complete (set of) command(s), > > but the CP interprets it differently? That would be possible I think, > > but again, do you emit any r300 specific commands to the ring? > > What do you mean by r300 specific ? Anything that isn't used for pre-R300 chips as well, as those don't seem to suffer from the same kind of lockups. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id135&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
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. But could it be that a malformed command at the very end of the buffer would cause CP engine to spin ? For example what if a command spans WPTR ? You mean that you think you've written a complete (set of) command(s), but the CP interprets it differently? That would be possible I think, but again, do you emit any r300 specific commands to the ring? What do you mean by r300 specific ? We access registers that are r300 specific and use *_2 versions of 3d commands (the ones one field shorter) but that's it. best Vladimir Dergachev -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: r300 radeon 9800 lockup
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 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 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. > > But could it be that a malformed command at the very end of the buffer > would cause CP engine to spin ? For example what if a command spans WPTR ? You mean that you think you've written a complete (set of) command(s), but the CP interprets it differently? That would be possible I think, but again, do you emit any r300 specific commands to the ring? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id135&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
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 start and end pointers are different. 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. But could it be that a malformed command at the very end of the buffer would cause CP engine to spin ? For example what if a command spans WPTR ? thank you Vladimir Dergachev -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: r300 radeon 9800 lockup
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 physical memory. We, on the other hand, always submit >>commands into the ring buffer, which is not linear (because it wraps >>around). Also, fglrx likes to emit NOPs into the command stream sometimes, >>though I haven't been able to find an exact pattern in those NOPs. We never >>emit NOPs (or do we?). >> >>So the fact is: We just don't know whether alignment/wraparound can cause >>trouble. The emission of NOPs by fglrx is IMO significant evidence that >>there *are* issues in this area, at least on some chipsets, but it could >>just be some weird artifact of the fglrx codebase. >> >> > >The NOPs in the ring buffer are there for alignment/performance reasons, >they shouldn't affect lockups either way. > I do not know much about ATI processors, but could they be there to prevent unprotected pipeline stalls/conflicts which could cause lockups ? Would adding 3/4 NOPs after a command to clear the pipeline prevent the lockup ? Cheers, Jonathan signature.asc Description: OpenPGP digital signature
Re: r300 radeon 9800 lockup
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 other hand, always submit > commands into the ring buffer, which is not linear (because it wraps > around). Also, fglrx likes to emit NOPs into the command stream sometimes, > though I haven't been able to find an exact pattern in those NOPs. We never > emit NOPs (or do we?). > > So the fact is: We just don't know whether alignment/wraparound can cause > trouble. The emission of NOPs by fglrx is IMO significant evidence that > there *are* issues in this area, at least on some chipsets, but it could > just be some weird artifact of the fglrx codebase. The NOPs in the ring buffer are there for alignment/performance reasons, they shouldn't affect lockups either way. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id135&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
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 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) -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id135&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
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 submitting the same > command to 3d engine, without fetching it and just increases the read > pointer all the time. > > It might help to dump not only read pointer but also the register showing > the last command executed. > > > > >> One way to try to make sure this does not happen is to put code in the DRM > >> driver to control the active size of the ring buffer. > > > > That could be useful for debugging, but that's about it. The thing is, we > > *want* to have the ring buffer full. If we didn't want that, we could just > > make the ring buffer smaller. But that doesn't really *solve* the problem > > either because even very small commands can take an insane amount of time > > to finish. > > 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. > > > > > In any case, it would be interesting to know how fast the RPTR still moves > > and if it becomes unstuck at some point. You also need to watch out for > > when the X server finally decides to reset the CP. I believe there's a bug > > where the X server waits much longer than intended to do this, but the > > reset could still mess with results if you're waiting for too long. > > Yep. > IIRC RTPTR change slowly, after one minute, or something like that, of spinning around wait for the 3d engine to end there is a substantial increase in RTPTR. I haven't access to my log where i am right now. I will try to let a small empty space (maybe feeded with nop) at the end of ring buffer. Jerome Glisse --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id135&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
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 lockup from the driver point of view is when the 3d engine busy bit is constantly on. The read pointer is updated by the CP engine, not the 3d engine. It could be that something would cause the CP engine to loop around sending commands to 3d engine forever. This would keep the 3d engine bit on, update the read pointer and appear to be a lockup to the driver. What you're saying is, some command that we sent could be misinterpreted by the 3D engine (or we sent something that we didn't intend to send, considering lack of docs etc.) as a command that takes insanely long to complete. 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 submitting the same command to 3d engine, without fetching it and just increases the read pointer all the time. It might help to dump not only read pointer but also the register showing the last command executed. One way to try to make sure this does not happen is to put code in the DRM driver to control the active size of the ring buffer. That could be useful for debugging, but that's about it. The thing is, we *want* to have the ring buffer full. If we didn't want that, we could just make the ring buffer smaller. But that doesn't really *solve* the problem either because even very small commands can take an insane amount of time to finish. 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. In any case, it would be interesting to know how fast the RPTR still moves and if it becomes unstuck at some point. You also need to watch out for when the X server finally decides to reset the CP. I believe there's a bug where the X server waits much longer than intended to do this, but the reset could still mess with results if you're waiting for too long. Yep. best Vladimir Dergachev --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] overflow(?) with ut2004 demo
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 height=1024 > >> blit width=1024 height=128 data=0xa6246200 > >> > >> It is random when in the game this happens. I've even managed to > play some CTF before it happened(lots of colors =). > >> > >> The strange thing is DRM_RADEON_TEXTURE(radeon_cp_texture) returns > -EINVAL(-22) when tex.image in NULL which it isn't before or after the call. > > > > > > > > radeon_cp_dispatch_texture() also returns EINVAL in a number of other > > cases. Is there anything apropos in the kernel output? > > > you are right (I managed to look at the wrong log). > > [drm:radeon_cp_dispatch_texture] *ERROR* Invalid destination offset So, possibly stating the obvious, there's basically two possibilities: Either the 3D driver indeed uses an invalid offset, or the DRM doesn't check correctly. Please provide some more information about your setup, in particular the exact versions of all the components (X, DDX driver, DRM, 3D driver, kernel, ...) and at least the log file of the X server. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id135&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
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 is when the 3d engine busy bit is constantly on. > > The read pointer is updated by the CP engine, not the 3d engine. It could > be that something would cause the CP engine to loop around sending > commands to 3d engine forever. This would keep the 3d engine bit on, > update the read pointer and appear to be a lockup to the driver. What you're saying is, some command that we sent could be misinterpreted by the 3D engine (or we sent something that we didn't intend to send, considering lack of docs etc.) as a command that takes insanely long to complete. > One way to try to make sure this does not happen is to put code in the DRM > driver to control the active size of the ring buffer. That could be useful for debugging, but that's about it. The thing is, we *want* to have the ring buffer full. If we didn't want that, we could just make the ring buffer smaller. But that doesn't really *solve* the problem either because even very small commands can take an insane amount of time to finish. In any case, it would be interesting to know how fast the RPTR still moves and if it becomes unstuck at some point. You also need to watch out for when the X server finally decides to reset the CP. I believe there's a bug where the X server waits much longer than intended to do this, but the reset could still mess with results if you're waiting for too long. > Also, there might be an issue where the CP engine expects the ring buffer > to be padded with NOPs in a certain way (say to have pointers always on > 256 bit boundaries) - I don't think we are doing this. Yes, that's what I mentioned in an earlier mail. cu, Nicolai pgpIU9yrssrmU.pgp Description: PGP signature
Re: r300 radeon 9800 lockup
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 updated by the CP engine, not the 3d engine. It could be that something would cause the CP engine to loop around sending commands to 3d engine forever. This would keep the 3d engine bit on, update the read pointer and appear to be a lockup to the driver. One way to try to make sure this does not happen is to put code in the DRM driver to control the active size of the ring buffer. Also, there might be an issue where the CP engine expects the ring buffer to be padded with NOPs in a certain way (say to have pointers always on 256 bit boundaries) - I don't think we are doing this. Michel - any chance you could comment ? Thank you ! best Vladimir Dergachev --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 radeon 9800 lockup
> 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 state. > > Are you sure the read pointer is still moving 2mins after the lockup? That > would be rather surprising, to say the least. Yes, i saw it in two differents lockup but it takes sometimes before happening. It may have happen in my other lockup if i let them more time. Jerome Glisse --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Removing install.sh dependancy on ed
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 --- install.sh 2005-05-17 15:54:24.0 +0100 +++ install.sh.new 2005-05-25 13:27:25.010423504 +0100 @@ -64,13 +64,13 @@ # # Determine driver to be installed - DRV_NAME=`echo "1 p" | ed -s pkginfo` - DRV_DESC=`echo "2 p" | ed -s pkginfo` - DRV_ARCH=`echo "3 p" | ed -s pkginfo` - DRV_DATE=`echo "4 p" | ed -s pkginfo` - DRV_MODULE=`echo "5 p" | ed -s pkginfo` - DRV_VERSION=`echo "6 p" | ed -s pkginfo` - DRV_BUILD_DESC=`echo "7 p" | ed -s pkginfo` + DRV_NAME=`sed -n '1p' pkginfo` + DRV_DESC=`sed -n '2p' pkginfo` + DRV_ARCH=`sed -n '3p' pkginfo` + DRV_DATE=`sed -n '4p' pkginfo` + DRV_MODULE=`sed -n '5p' pkginfo` + DRV_VERSION=`sed -n '6p' pkginfo` + DRV_BUILD_DESC=`sed -n '7p' pkginfo` # Determine directories from default or user values XF86_DRI_DIR="$XF86_DIR/lib/modules/dri" @@ -432,13 +432,6 @@ exit 127; fi -# Check if ed is installed -which ed &> /dev/null -if [ "$?" != "0" ]; then - echo "Could not located 'ed' editor. Aborting." - exit 127; -fi - ### FIXME: We should check for matching architectures here!!! ### # Figure out if we should restore files signature.asc Description: This is a digitally signed message part
Re: r300 radeon 9800 lockup
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 ring buffer, but the ring buffer is just some > > memory area without any magic of its own. > > > > Only a call to COMMIT_RING will tell the hardware that new commands are > > waiting in the ring buffer, and the only thing we do know is that > > *something* in the ring buffer before the last COMMIT_RING causes the chip > > to hang. > > > > So another possible way to investigate this could be: > > - Call radeon_do_wait_for_idle() at the end of the COMMIT_RING macro, and > > define RADEON_FIFO_DEBUG (this will print out additional information when > > wait_for_idle fails) > > - Increasingly add COMMIT_RING macros into r300_cmdbuf.c to pinpoint the > > exact location of the problem, if at all possible. > > > > It would be very helpful if you could single out one command we send using > > this procedure. > > > > Note that in the worst case (depending on the actual nature of the lockup in > > hardware), those debugging changes could actually *remove* the lockup (e.g. > > because they remove a race condition that caused the lockup in the first > > place). > > > > Below a sample of what i get when a lockup occur. There is something > that seems strange to me, i saw CP_RB_RTPR change while i am in a > lockup and CP_RB_WTPR increase 6 by 6, I haven't let the things live > for too much time (about 2mins before reboot) but i looks like it > still process ring buffer but slowly. 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 state. Are you sure the read pointer is still moving 2mins after the lockup? That would be rather surprising, to say the least. > Anyway i must misunderstood this > i have to dig up more this drm code to understand it a little more. > > By the way why radeon_cp_flush is disactivated ? The only thing that calls radeon_cp_flush is radeon_cp_stop, which is never called during normal 3D operation and COMMIT_RING should take care of posting the write pointer. I don't know the meaning of bit 31 of WPTR. cu, Nicolai > May 24 21:33:25 localhost kernel: [drm:radeon_do_wait_for_idle] *ERROR* failed! > May 24 21:33:25 localhost kernel: radeon_status: > May 24 21:33:25 localhost kernel: RBBM_STATUS = 0x80010140 > May 24 21:33:25 localhost kernel: CP_RB_RTPR = 0x0003fdf0 > May 24 21:33:25 localhost kernel: CP_RB_WTPR = 0x0d95 > May 24 21:33:25 localhost kernel: AIC_CNTL = 0x > May 24 21:33:25 localhost kernel: AIC_STAT = 0x0004 > May 24 21:33:25 localhost kernel: AIC_PT_BASE = 0x > May 24 21:33:25 localhost kernel: TLB_ADDR = 0x > May 24 21:33:25 localhost kernel: TLB_DATA = 0x 2 pgpt4F03RhI60.pgp Description: PGP signature
