Re: [Dri-users] X hangs when starting glxgears on r350
On Friday 29 July 2005 23:16, Jerome Glisse wrote: Btw if i understand correctly during POST of a card you ask the video BIOS to initialize the card ? Does it do other things (i suppose vga initialisation too...) googling give me a tons of wrong result... Well, IIRC, the BIOS scans 'some' memory range for any ROM presence (like network, video cards), and, if found, runs them. Also, I think the video card is responsible for the int 10h. Possibly you can have a look at linuxbios and their freevga implementation[1], or the vbe standard[2]. Obviously, I may be totally wrong. 8) Nicolas [1] http://wiki.linuxbios.org/data/vgabios/ [2] http://www.vesa.org/public/VBE/vbe3.pdf --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Wednesday 27 July 2005 22:15, Jerome Glisse wrote: Btw can you try if vbetool vbestate save work on your computer (do this from text console with no X running). It seems that launching fglrx then do a repost of the card (with vbetool repost) then use r300 and the lockup appear again (no lockup with no repost). The same here... Thus maybe fglrx initialize the card better than the bios do, and i fear that looking at reg dump won't show me the magic... H... Indeed... It's time to have a smart idea... N. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On 7/29/05, Bellido Nicolas [EMAIL PROTECTED] wrote: On Wednesday 27 July 2005 22:15, Jerome Glisse wrote: Btw can you try if vbetool vbestate save work on your computer (do this from text console with no X running). It seems that launching fglrx then do a repost of the card (with vbetool repost) then use r300 and the lockup appear again (no lockup with no repost). The same here... Thus maybe fglrx initialize the card better than the bios do, and i fear that looking at reg dump won't show me the magic... H... Indeed... It's time to have a smart idea... I am not smart enought ;) Btw if i understand correctly during POST of a card you ask the video BIOS to initialize the card ? Does it do other things (i suppose vga initialisation too...) googling give me a tons of wrong result... Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Tue, 26 Jul 2005 14:18:10 +0200
Bellido Nicolas [EMAIL PROTECTED] wrote:
On Monday 25 July 2005 16:22, Aapo Tahkola wrote:
On Mon, 25 Jul 2005 08:59:53 +0200
[drm:drm_ioctl] pid=9733, cmd=0x40106450, nr=0x50, dev 0xe200, auth=1
[drm:radeon_cp_cmdbuf] RADEON_CMD_SCALARS2
[drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at e08fa024
r300_do_cp_cmdbuf doesnt get called...
That's indeed strange. From radeon_cp_cmdbuf in shared-core/radeon_state.c:
if(dev_priv-microcode_version == UCODE_R300) {
int temp;
temp=r300_do_cp_cmdbuf(dev, filp, filp_priv, cmdbuf);
if (orig_bufsz != 0)
drm_free(kbuf, orig_bufsz, DRM_MEM_DRIVER);
return temp;
}
Although dmesg says:
[drm] Loading R300 Microcode
So in the function radeon_cp_load_microcode in shared-core/radon_cp.c:
if (dev_priv-microcode_version==UCODE_R200) {
[snip]
} else if (dev_priv-microcode_version==UCODE_R300) {
DRM_INFO(Loading R300 Microcode\n);
for ( i = 0 ; i 256 ; i++ ) {
RADEON_WRITE( RADEON_CP_ME_RAM_DATAH,
R300_cp_microcode[i][1] );
RADEON_WRITE( RADEON_CP_ME_RAM_DATAL,
R300_cp_microcode[i][0] );
}
} else {
[snip]
The test against the microcode_version succeeds...
And, from the logs, I don't see the DRM_IOCTL_RADEON_CP_INIT ioctl called
twice...
Ideas ?
You dont have two cards hooked up by any chance? :)
Does Xorg.0.log get the card right?
You probably want to check if microcode_version actually has any sane value at
radeon_cp_cmdbuf.
Try something like:
printk(microcode_version %d\n, dev_priv-microcode_version);
return DRM_ERR(EINVAL);
--
Aapo Tahkola
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Tuesday 26 July 2005 11:06, Jerome Glisse wrote: In fact, i use xfree86 (from debian testing) for fglrx, You mean xfree86 4.3.0 + ati.patch from r300 cvs ? No the original xfree86 from debian with fglrx, and i have installed elsewhere Xorg with r300 (in fact my rep /usr/X11R6 is link to xfree86 or to xorg and i point it to which one i want to run). I guess you can have an older xorg with gentoo and use this one with fglrx and use xorg cvs for r300 stuff. OK, I have now xorg-6.8.2-r2 (from gentoo) + fglrx, and xorg-cvs + r300. And guess what: X does not hang anymore when I start glxgears... Neither does it when I let glxgears run for a minute or so (around 2400 fps). Possible causes: . I did something terribly wrong in my previous install . Some incompatibilities caused by gentoo patches to xorg . I was previously running kde. Now, I have nothing else than X's default WM (twm ??) . Solar wind . Bacterias attacking my PC (heu. no, that's the wrong movie) . Something else Anyway, let's see what hwscript has to tell. BTW, do you have any scenario where you are sure X will hang ?? Nicolas. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On 7/27/05, Bellido Nicolas [EMAIL PROTECTED] wrote: On Tuesday 26 July 2005 11:06, Jerome Glisse wrote: In fact, i use xfree86 (from debian testing) for fglrx, You mean xfree86 4.3.0 + ati.patch from r300 cvs ? No the original xfree86 from debian with fglrx, and i have installed elsewhere Xorg with r300 (in fact my rep /usr/X11R6 is link to xfree86 or to xorg and i point it to which one i want to run). I guess you can have an older xorg with gentoo and use this one with fglrx and use xorg cvs for r300 stuff. OK, I have now xorg-6.8.2-r2 (from gentoo) + fglrx, and xorg-cvs + r300. And guess what: X does not hang anymore when I start glxgears... Neither does it when I let glxgears run for a minute or so (around 2400 fps). Possible causes: . I did something terribly wrong in my previous install . Some incompatibilities caused by gentoo patches to xorg . I was previously running kde. Now, I have nothing else than X's default WM (twm ??) . Solar wind . Bacterias attacking my PC (heu. no, that's the wrong movie) . Something else Anyway, let's see what hwscript has to tell. BTW, do you have any scenario where you are sure X will hang ?? Launch ut2003 or 2004 (don't remember which one) demos then start a game (quick launch) and it will lockup during level loading or few second after the intro begin...Other opengl apps do the same a flight simulator which i didn't remember the name will lockup in the menu after few secs.. Btw if i try to resize or move glxgears i have a lockup, less often but some times... Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Wednesday 27 July 2005 08:44, Aapo Tahkola wrote: On Tue, 26 Jul 2005 14:18:10 +0200 You dont have two cards hooked up by any chance? :) No, no handmade mobo with 2 agp slots :) Does Xorg.0.log get the card right? Apparently yes, it does. You probably want to check if microcode_version actually has any sane value at radeon_cp_cmdbuf. Try something like: printk(microcode_version %d\n, dev_priv-microcode_version); return DRM_ERR(EINVAL); Yeah, I was planning to do smthg like that. But, how do you explain: [drm:drm_ioctl] pid=9733, cmd=0x40106450, nr=0x50, dev 0xe200, auth=1 [drm:radeon_cp_cmdbuf] RADEON_CMD_SCALARS2 [drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at e08fa024 Looking at the code, I think it is not possible, except if two ioctl were called concurently... Nicolas --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Wed, 27 Jul 2005 12:25:27 +0200 Bellido Nicolas [EMAIL PROTECTED] wrote: On Wednesday 27 July 2005 08:44, Aapo Tahkola wrote: On Tue, 26 Jul 2005 14:18:10 +0200 You dont have two cards hooked up by any chance? :) No, no handmade mobo with 2 agp slots :) Does Xorg.0.log get the card right? Apparently yes, it does. You probably want to check if microcode_version actually has any sane value at radeon_cp_cmdbuf. Try something like: printk(microcode_version %d\n, dev_priv-microcode_version); return DRM_ERR(EINVAL); Yeah, I was planning to do smthg like that. But, how do you explain: [drm:drm_ioctl] pid=9733, cmd=0x40106450, nr=0x50, dev 0xe200, auth=1 DRM_COMMAND_BASE + DRM_RADEON_CMDBUF == 0x50 [drm:radeon_cp_cmdbuf] RADEON_CMD_SCALARS2 cmd type 7 equals to R300_CMD_WAIT(from r300DoEmitState) [drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at e08fa024 This is random bits of memory already as cmd length of previous wasnt right. -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Wednesday 27 July 2005 19:04, Aapo Tahkola wrote: On Wed, 27 Jul 2005 12:25:27 +0200 Bellido Nicolas [EMAIL PROTECTED] wrote: On Wednesday 27 July 2005 08:44, Aapo Tahkola wrote: On Tue, 26 Jul 2005 14:18:10 +0200 You dont have two cards hooked up by any chance? :) No, no handmade mobo with 2 agp slots :) Does Xorg.0.log get the card right? RADEON_PARAM_GART_BUFFER_OFFSET Apparently yes, it does. You probably want to check if microcode_version actually has any sane value at radeon_cp_cmdbuf. Try something like: printk(microcode_version %d\n, dev_priv-microcode_version); return DRM_ERR(EINVAL); Yeah, I was planning to do smthg like that. But, how do you explain: [drm:drm_ioctl] pid=9733, cmd=0x40106450, nr=0x50, dev 0xe200, auth=1 DRM_COMMAND_BASE + DRM_RADEON_CMDBUF == 0x50 [drm:radeon_cp_cmdbuf] RADEON_CMD_SCALARS2 cmd type 7 equals to R300_CMD_WAIT(from r300DoEmitState) [drm:rRADEON_PARAM_GART_BUFFER_OFFSETadeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at e08fa024 This is random bits of memory already as cmd length of previous wasnt right. I meant I don't understand why there is a RADEON_CMD_SCALAR2 followed by the *ERROR* message, without a drm_ioctl notice in between... Possibly because the PID is different than for the other calls ? --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Wednesday 27 July 2005 10:13, Jerome Glisse wrote: On 7/27/05, Bellido Nicolas [EMAIL PROTECTED] wrote: BTW, do you have any scenario where you are sure X will hang ?? Launch ut2003 or 2004 (don't remember which one) demos then start a game (quick launch) and it will lockup during level loading or few second after the intro begin...Other opengl apps do the same a flight simulator which i didn't remember the name will lockup in the menu after few secs.. Btw if i try to resize or move glxgears i have a lockup, less often but some times... ut2k4 did the trick... I get lockups during the mission breafing or shortly after beginning of intro. Modprobing drm with debug=1, shows two cases: . ut2004-bin does an DRM_IOCTL_DMA ioctl, but radeon_freelist_get, called by radeon_cp_buffers returns NULL; . ut2004-bin does an radeon_cp_getparam ioctl, with RADEON_PARAM_LAST_FRAME as parameter, but the value returned does not change anymore. The later is the most common, though. The result is that ut2004-bin keeps on issuing the same ioctl, thus the lock up. Do you experience the same ? (Just to be sure that we talk about the same thing) As the getparam lockup has already been discussed here [1], I'll post the logs I have as replies to this mail, in case people are interested. Note that they are quite large (compressed ~50k, uncompressed ~10M). -- Hopefully they won't be rejected by any mail size limit on the list -- Nicolas. [1] http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg23051.html --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On 7/27/05, Bellido Nicolas [EMAIL PROTECTED] wrote: On Wednesday 27 July 2005 10:13, Jerome Glisse wrote: On 7/27/05, Bellido Nicolas [EMAIL PROTECTED] wrote: BTW, do you have any scenario where you are sure X will hang ?? Launch ut2003 or 2004 (don't remember which one) demos then start a game (quick launch) and it will lockup during level loading or few second after the intro begin...Other opengl apps do the same a flight simulator which i didn't remember the name will lockup in the menu after few secs.. Btw if i try to resize or move glxgears i have a lockup, less often but some times... ut2k4 did the trick... I get lockups during the mission breafing or shortly after beginning of intro. Modprobing drm with debug=1, shows two cases: . ut2004-bin does an DRM_IOCTL_DMA ioctl, but radeon_freelist_get, called by radeon_cp_buffers returns NULL; . ut2004-bin does an radeon_cp_getparam ioctl, with RADEON_PARAM_LAST_FRAME as parameter, but the value returned does not change anymore. The later is the most common, though. The result is that ut2004-bin keeps on issuing the same ioctl, thus the lock up. Do you experience the same ? (Just to be sure that we talk about the same thing) Long time i haven't been looking to my log :) But as far my memory is good i was experiencing this two kinds two. I will check that once again. As the getparam lockup has already been discussed here [1], I'll post the logs I have as replies to this mail, in case people are interested. Note that they are quite large (compressed ~50k, uncompressed ~10M). [1] http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg23051.html Hhhmmm the thread on that end with no conclusion, what is the status of that for radeon ? Btw can you try if vbetool vbestate save work on your computer (do this from text console with no X running). It seems that launching fglrx then do a repost of the card (with vbetool repost) then use r300 and the lockup appear again (no lockup with no repost). Thus maybe fglrx initialize the card better than the bios do, and i fear that looking at reg dump won't show me the magic... Jerome Glisse --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Wed, 27 Jul 2005 21:53:14 +0200
Bellido Nicolas [EMAIL PROTECTED] wrote:
On Wednesday 27 July 2005 19:04, Aapo Tahkola wrote:
On Wed, 27 Jul 2005 12:25:27 +0200
Bellido Nicolas [EMAIL PROTECTED] wrote:
On Wednesday 27 July 2005 08:44, Aapo Tahkola wrote:
On Tue, 26 Jul 2005 14:18:10 +0200
You dont have two cards hooked up by any chance? :)
No, no handmade mobo with 2 agp slots :)
Does Xorg.0.log get the card right?
RADEON_PARAM_GART_BUFFER_OFFSET
Apparently yes, it does.
You probably want to check if microcode_version actually has any sane
value at radeon_cp_cmdbuf. Try something like:
printk(microcode_version %d\n, dev_priv-microcode_version);
return DRM_ERR(EINVAL);
Yeah, I was planning to do smthg like that.
But, how do you explain:
[drm:drm_ioctl] pid=9733, cmd=0x40106450, nr=0x50, dev 0xe200, auth=1
DRM_COMMAND_BASE + DRM_RADEON_CMDBUF == 0x50
[drm:radeon_cp_cmdbuf] RADEON_CMD_SCALARS2
cmd type 7 equals to R300_CMD_WAIT(from r300DoEmitState)
[drm:rRADEON_PARAM_GART_BUFFER_OFFSETadeon_cp_cmdbuf] *ERROR* bad
cmd_type 0 at e08fa024
This is random bits of memory already as cmd length of previous wasnt
right.
I meant I don't understand why there is a RADEON_CMD_SCALAR2 followed by the
*ERROR* message, without a drm_ioctl notice in between...
Possibly because the PID is different than for the other calls ?
Because it processes multiple packets:
while (cmdbuf.bufsz = sizeof(header)) {
header.i = *(int *)cmdbuf.buf;
cmdbuf.buf += sizeof(header);
cmdbuf.bufsz -= sizeof(header);
switch (header.header.cmd_type) {
--
Aapo Tahkola
---
SF.Net email is Sponsored by the Better Software Conference EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Wed, 27 Jul 2005 23:38:57 +0200
Bellido Nicolas [EMAIL PROTECTED] wrote:
On Wednesday 27 July 2005 10:13, Jerome Glisse wrote:
On 7/27/05, Bellido Nicolas [EMAIL PROTECTED] wrote:
BTW, do you have any scenario where you are sure X will hang ??
Launch ut2003 or 2004 (don't remember which one) demos then start a game
(quick launch) and it will lockup during level loading or few second after
the intro begin...Other opengl apps do the same a flight simulator which
i didn't remember the name will lockup in the menu after few secs..
Btw if i try to resize or move glxgears i have a lockup, less often but
some times...
ut2k4 did the trick...
I get lockups during the mission breafing or shortly after beginning of intro.
Modprobing drm with debug=1, shows two cases:
. ut2004-bin does an DRM_IOCTL_DMA ioctl, but radeon_freelist_get, called by
radeon_cp_buffers returns NULL;
last_dispatch gets wrong value if buffer has more than one dma discard: (could
someone check this change in?)
Index: r300_cmdbuf.c
===
RCS file: /cvs/dri/drm/shared-core/r300_cmdbuf.c,v
retrieving revision 1.1
diff -u -b -B -u -r1.1 r300_cmdbuf.c
--- r300_cmdbuf.c 20 Jul 2005 21:17:47 - 1.1
+++ r300_cmdbuf.c 27 Jul 2005 20:43:50 -
@@ -623,7 +623,7 @@
drm_radeon_private_t *dev_priv = dev-dev_private;
drm_radeon_buf_priv_t *buf_priv = buf-dev_private;
- buf_priv-age = dev_priv-sarea_priv-last_dispatch+1;
+ buf_priv-age = ++dev_priv-sarea_priv-last_dispatch;
buf-pending = 1;
buf-used = 0;
}
@@ -788,8 +788,6 @@
if (emit_dispatch_age) {
RING_LOCALS;
- dev_priv-sarea_priv-last_dispatch++;
-
/* Emit the vertex buffer age */
BEGIN_RING(2);
RADEON_DISPATCH_AGE(dev_priv-sarea_priv-last_dispatch);
--
Aapo Tahkola
---
SF.Net email is Sponsored by the Better Software Conference EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Monday 25 July 2005 21:53, Jerome Glisse wrote: On 7/25/05, Bellido Nicolas [EMAIL PROTECTED] wrote: On Monday 25 July 2005 10:18, Jerome Glisse wrote: radeon 9800 card still lockup with r300 driver. If you first run an X server with fglrx, then leave and launch xorg with r300 driver you shouldn't have any lockup. A quick question: which version of X and fglrx are you using ? I've been struggling to get fglrx to work with Xorg CVS HEAD, without any success so far... Since X has moved to dlloader, while fglrx still is shipped as elf, this causes a lot of undefined symbols when X is starting. I tried to make a .so version of the fglrx_drv.o file, but now X complains about libfglrxdrm... In fact, i use xfree86 (from debian testing) for fglrx, You mean xfree86 4.3.0 + ati.patch from r300 cvs ? i don't think you could make lastest fglrx work with xorg head, have to wait for next ati release... Yes, indeed. I managed to get X starting (thanks Pedro), but fglrx is complaining about the version of DRI. Nicolas. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
In fact, i use xfree86 (from debian testing) for fglrx, You mean xfree86 4.3.0 + ati.patch from r300 cvs ? No the original xfree86 from debian with fglrx, and i have installed elsewhere Xorg with r300 (in fact my rep /usr/X11R6 is link to xfree86 or to xorg and i point it to which one i want to run). I guess you can have an older xorg with gentoo and use this one with fglrx and use xorg cvs for r300 stuff. Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Monday 25 July 2005 16:22, Aapo Tahkola wrote:
On Mon, 25 Jul 2005 08:59:53 +0200
[drm:drm_ioctl] pid=9733, cmd=0x40106450, nr=0x50, dev 0xe200, auth=1
[drm:radeon_cp_cmdbuf] RADEON_CMD_SCALARS2
[drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at e08fa024
r300_do_cp_cmdbuf doesnt get called...
That's indeed strange. From radeon_cp_cmdbuf in shared-core/radeon_state.c:
if(dev_priv-microcode_version == UCODE_R300) {
int temp;
temp=r300_do_cp_cmdbuf(dev, filp, filp_priv, cmdbuf);
if (orig_bufsz != 0)
drm_free(kbuf, orig_bufsz, DRM_MEM_DRIVER);
return temp;
}
Although dmesg says:
[drm] Loading R300 Microcode
So in the function radeon_cp_load_microcode in shared-core/radon_cp.c:
if (dev_priv-microcode_version==UCODE_R200) {
[snip]
} else if (dev_priv-microcode_version==UCODE_R300) {
DRM_INFO(Loading R300 Microcode\n);
for ( i = 0 ; i 256 ; i++ ) {
RADEON_WRITE( RADEON_CP_ME_RAM_DATAH,
R300_cp_microcode[i][1] );
RADEON_WRITE( RADEON_CP_ME_RAM_DATAL,
R300_cp_microcode[i][0] );
}
} else {
[snip]
The test against the microcode_version succeeds...
And, from the logs, I don't see the DRM_IOCTL_RADEON_CP_INIT ioctl called
twice...
Ideas ?
Nicolas.
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
radeon 9800 card still lockup with r300 driver. If you first run an X server with fglrx, then leave and launch xorg with r300 driver you shouldn't have any lockup. I am still looking at what fglrx does and i have a couple of guilty reg but so far after ten thousand reboot dump i haven't found the magic incantation. Help on this is more than welcome :) Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Monday 25 July 2005 10:18, Jerome Glisse wrote: radeon 9800 card still lockup with r300 driver. If you first run an X server with fglrx, then leave and launch xorg with r300 driver you shouldn't have any lockup. I see. Will try that this evening. I am still looking at what fglrx does and i have a couple of guilty reg but so far after ten thousand reboot dump i haven't found the magic incantation. You beat me by far: I just did tens of reboots :) Help on this is more than welcome :) Sure. What could I do with my (very limited) knowledge of drm ?? Nicolas. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On 7/25/05, Bellido Nicolas [EMAIL PROTECTED] wrote: On Monday 25 July 2005 10:18, Jerome Glisse wrote: radeon 9800 card still lockup with r300 driver. If you first run an X server with fglrx, then leave and launch xorg with r300 driver you shouldn't have any lockup. I see. Will try that this evening. I am still looking at what fglrx does and i have a couple of guilty reg but so far after ten thousand reboot dump i haven't found the magic incantation. You beat me by far: I just did tens of reboots :) Help on this is more than welcome :) Sure. What could I do with my (very limited) knowledge of drm ?? First make sure you know how to dump reg, i use a tools from Vladimir: http://volodya-project.sourceforge.net/hw_script.php Then i will send you latter(when i access the computer on which they are) my script which use hw_script to dump reg. Basicly i dump all reg before starting anythings (after boot), then i start xserver with fglrx and i dump all reg, then i start x with r300 and i dump all reg. I have done this several time, running different apps each time thus i have some change in dump (maybe i am wrong doing so). Then i look at what reg are always the same in some fglrx dump and same in r300 dump (after fglrx) and different in r300 dump (r300 dump without previously run fglrx). With that i get a list of reg that fglrx always set in the same way (and that are preserved) and r300 doesn't. But some of them are status reg and finding which register(s) are needed to set a particular status is painfull and boring, you have to write in other regs hoping to no lock the card (which often lock) and now i am dealing with all this regs (as i already tested all non-status reg, and i think i haven't missed one, i hope :)) If anyone have a better procedure to track differences btw radeon/r300 2d driver from xorg and fglrx (2d driver) ? Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Monday 25 July 2005 11:33, Jerome Glisse wrote: If anyone have a better procedure to track differences btw radeon/r300 2d driver from xorg and fglrx (2d driver) ? I'm not used at all to work on x86 processors, nor am I with PCI or AGP, so what follows may be complete nonsense... Isn't it also important to know the exact stream of commands sent to the core ? I mean, as it is apparently known where the registers are, or what the commands to send to the gpu are, isn't it possible to put some watchpoints at specific locations, and see whet fglrx is doing ? Now, I'm not sure if x86 supports watchpoint on iomem... Nicolas --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On 7/25/05, Bellido Nicolas [EMAIL PROTECTED] wrote: On Monday 25 July 2005 11:33, Jerome Glisse wrote: If anyone have a better procedure to track differences btw radeon/r300 2d driver from xorg and fglrx (2d driver) ? I'm not used at all to work on x86 processors, nor am I with PCI or AGP, so what follows may be complete nonsense... Isn't it also important to know the exact stream of commands sent to the core ? I mean, as it is apparently known where the registers are, or what the commands to send to the gpu are, isn't it possible to put some watchpoints at specific locations, and see whet fglrx is doing ? Now, I'm not sure if x86 supports watchpoint on iomem... I don't think neither that you can put watchpoint or even capture what is written to the reg but this would help a lot as the key is there :) Anyone with more knowledge on this ? A modified X server ? Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Mon, 25 Jul 2005 08:59:53 +0200 Bellido Nicolas [EMAIL PROTECTED] wrote: On Monday 25 July 2005 00:47, Roland Scheidegger wrote: Bellido Nicolas wrote: When the radeon module is loaded, i get in the kernel logs: Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA KT880 chipset agpgart: AGP aperture is 128M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt :01:00.0[A] - GSI 16 (level, low) - IRQ 16 [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro] This is just a shot in the dark, have you built the drm module too? The r300 driver needs a new version too. I don't know what would happen if you don't build it however, but it certainly wouldn't work. That's the version string I have in radeon_drv.c: $ grep 20050311 linux-core/radeon_drv.h #define DRIVER_DATE 20050311 Checked out yesterday from drm cvs on freedesktop.org. In case it helps, i just insmoded the drm module with debug=1. Here are the last lines ok kmsg. [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 236 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=13 s=0 e=88 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=13 s=0x0 e=0x58 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=13 s=88 e=104 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=13 s=0x58 e=0x68 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 237 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=14 s=0 e=176 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=14 s=0x0 e=0xb0 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=14 s=176 e=192 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=14 s=0xb0 e=0xc0 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 238 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=15 s=0 e=124 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=15 s=0x0 e=0x7c [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=15 s=128 e=144 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=15 s=0x80 e=0x90 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 239 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=16 s=0 e=108 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=16 s=0x0 e=0x6c [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=16 s=112 e=128 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=16 s=0x70 e=0x80 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9733, cmd=0x4008642a, nr=0x2a, dev 0xe200, auth=1 [drm:drm_lock] 3 (pid 9733) requests lock (0x0001), flags = 0x [drm:drm_lock] 3 has lock [drm:drm_ioctl] pid=9733, cmd=0x40106450, nr=0x50, dev 0xe200, auth=1 [drm:radeon_cp_cmdbuf] RADEON_CMD_SCALARS2 [drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at e08fa024 r300_do_cp_cmdbuf doesnt get called... -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Monday 25 July 2005 10:18, Jerome Glisse wrote: radeon 9800 card still lockup with r300 driver. If you first run an X server with fglrx, then leave and launch xorg with r300 driver you shouldn't have any lockup. A quick question: which version of X and fglrx are you using ? I've been struggling to get fglrx to work with Xorg CVS HEAD, without any success so far... Since X has moved to dlloader, while fglrx still is shipped as elf, this causes a lot of undefined symbols when X is starting. I tried to make a .so version of the fglrx_drv.o file, but now X complains about libfglrxdrm... Nicolas --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On 7/25/05, Bellido Nicolas [EMAIL PROTECTED] wrote: On Monday 25 July 2005 10:18, Jerome Glisse wrote: radeon 9800 card still lockup with r300 driver. If you first run an X server with fglrx, then leave and launch xorg with r300 driver you shouldn't have any lockup. A quick question: which version of X and fglrx are you using ? I've been struggling to get fglrx to work with Xorg CVS HEAD, without any success so far... Since X has moved to dlloader, while fglrx still is shipped as elf, this causes a lot of undefined symbols when X is starting. I tried to make a .so version of the fglrx_drv.o file, but now X complains about libfglrxdrm... In fact, i use xfree86 (from debian testing) for fglrx, i don't think you could make lastest fglrx work with xorg head, have to wait for next ati release... Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
Jerome Glisse wrote: On 7/25/05, Bellido Nicolas [EMAIL PROTECTED] wrote: On Monday 25 July 2005 10:18, Jerome Glisse wrote: radeon 9800 card still lockup with r300 driver. If you first run an X server with fglrx, then leave and launch xorg with r300 driver you shouldn't have any lockup. A quick question: which version of X and fglrx are you using ? I've been struggling to get fglrx to work with Xorg CVS HEAD, without any success so far... Since X has moved to dlloader, while fglrx still is shipped as elf, this causes a lot of undefined symbols when X is starting. I tried to make a .so version of the fglrx_drv.o file, but now X complains about libfglrxdrm... In fact, i use xfree86 (from debian testing) for fglrx, i don't think you could make lastest fglrx work with xorg head, have to wait for next ati release... Jerome Glisse I made xorg cvs work with fglrx but it doesn't work with DRI (it says DRM version is not what it expects). I don't remember the exact URL form where i got the instructions but i did something similar to this: http://lists.freedesktop.org/pipermail/xorg/2005-February/006049.html and this: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg21846.html and i added this to my Section Module: # fglrx xorg cvs hack Loadfglrxdrm Loadxaa Loadramdac Loadfbdevhw Loadvgahw Loadvbe Loadi2c Loadint10 Loadfb Loadddc which solves the undefined symbol messages. -- Pedro Ramalhais --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
Bellido Nicolas wrote: Hi all, I have a Radeon 9800Pro that I'm trying to get working with the R300 tree on my Gentoo box. I'm running a 2.6.12-gentoo-r4 kernel with the X11 6.8.99.15 ebuild. As I saw a post recently on the dri-devel list, I built DRI and Mesa from CVS. When the radeon module is loaded, i get in the kernel logs: Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA KT880 chipset agpgart: AGP aperture is 128M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt :01:00.0[A] - GSI 16 (level, low) - IRQ 16 [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro] This is just a shot in the dark, have you built the drm module too? The r300 driver needs a new version too. I don't know what would happen if you don't build it however, but it certainly wouldn't work. CC to dri-devel as the r300 driver doesn't check correctly for the drm version as far as I can see. The version should have been bumped in the drm when support for r300 driver was added I guess (along with the date and version comments in radeon_drv.h). Roland --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] X hangs when starting glxgears on r350
On Monday 25 July 2005 00:47, Roland Scheidegger wrote: Bellido Nicolas wrote: When the radeon module is loaded, i get in the kernel logs: Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA KT880 chipset agpgart: AGP aperture is 128M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt :01:00.0[A] - GSI 16 (level, low) - IRQ 16 [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro] This is just a shot in the dark, have you built the drm module too? The r300 driver needs a new version too. I don't know what would happen if you don't build it however, but it certainly wouldn't work. That's the version string I have in radeon_drv.c: $ grep 20050311 linux-core/radeon_drv.h #define DRIVER_DATE 20050311 Checked out yesterday from drm cvs on freedesktop.org. In case it helps, i just insmoded the drm module with debug=1. Here are the last lines ok kmsg. [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 236 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=13 s=0 e=88 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=13 s=0x0 e=0x58 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=13 s=88 e=104 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=13 s=0x58 e=0x68 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 237 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=14 s=0 e=176 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=14 s=0x0 e=0xb0 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=14 s=176 e=192 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=14 s=0xb0 e=0xc0 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 238 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=15 s=0 e=124 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=15 s=0x0 e=0x7c [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=15 s=128 e=144 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=15 s=0x80 e=0x90 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 239 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=16 s=0 e=108 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=16 s=0x0 e=0x6c [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=16 s=112 e=128 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=16 s=0x70 e=0x80 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] pid=9733, cmd=0x4008642a, nr=0x2a, dev 0xe200, auth=1 [drm:drm_lock] 3 (pid 9733) requests lock (0x0001), flags = 0x [drm:drm_lock] 3 has lock [drm:drm_ioctl] pid=9733, cmd=0x40106450, nr=0x50, dev 0xe200, auth=1 [drm:radeon_cp_cmdbuf] RADEON_CMD_SCALARS2 [drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 at e08fa024 [drm:drm_ioctl] ret = ffea [drm:drm_ioctl] pid=9684, cmd=0x4008642a, nr=0x2a, dev 0xe200, auth=1 [drm:drm_lock] 1 (pid 9684) requests lock (0x0003), flags = 0x [drm:drm_lock] 1 has lock [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] ret = fff0 [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 240 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=17 s=0 e=544 d=0 [drm:radeon_cp_dispatch_indirect] indirect: buf=17 s=0x0 e=0x220 [drm:drm_ioctl] pid=9684, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 [drm:radeon_cp_indirect] indirect: idx=17 s=544 e=560 d=1 [drm:radeon_cp_dispatch_indirect] indirect: buf=17 s=0x220 e=0x230 [drm:drm_ioctl] pid=9684, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 [drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:drm_ioctl] ret = fff0 [drm:drm_ioctl] pid=9684, cmd=0xc0286429, nr=0x29, dev 0xe200, auth=1 [drm:radeon_freelist_get] done_age = 240 [drm:drm_ioctl] pid=9684,
