[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #7 from [EMAIL PROTECTED] 2007-04-09 01:03 PST --- (In reply to comment #6) Since gdb is unworkable, I chose another route and analyzed strace output. That's rarely very useful for this kind of problem unfortunately. Now the question is: how's can radeon_freelist() return NULL? It means there are currently no indirect buffers available. This can happen intermittently during normal operation, but when it persists that probably means the card has locked up. Unfortunately, the symptoms of a lockup don't really say anything about its cause. Can you still kill the secondlife process and get X back working? And another good question is: why does the client need to retry allocating a texture in an infinite polling loop? That's not quite what happens. The ioctl transfers texture data from userspace memory to video RAM using indirect buffers. As an indirect buffer is only 64KB, it usually has to split up the data across several buffers, and when all of them are in use, it returns to userspace so it can later pick up where it left off. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561
--- Comment #8 from [EMAIL PROTECTED] 2007-04-09 01:35 PST ---
(In reply to comment #7)
Can you still kill the secondlife process and get X back working?
Yes, I need to use kill -9. The process does not even react to
SIGSTOP/SIGCONT (^Z in the shell).
That's not quite what happens. The ioctl transfers texture data from userspace
memory to video RAM using indirect buffers. As an indirect buffer is only
64KB,
it usually has to split up the data across several buffers, and when all of
them are in use, it returns to userspace so it can later pick up where it left
off.
But there's that 1ms pause between calls to ioctl(). And the arguments
are always the same. Doesn't it mean it's a retry loop?
ioctl(13, 0xc018644e, 0xffed9a90) = -1 EAGAIN (Resource temporarily
unavailable)
nanosleep({0, 1000}, NULL) = 0
ioctl(13, 0xc018644e, 0xffed9a90) = -1 EAGAIN (Resource temporarily
unavailable)
nanosleep({0, 1000}, NULL) = 0
ioctl(13, 0xc018644e, 0xffed9a90) = -1 EAGAIN (Resource temporarily
unavailable)
nanosleep({0, 1000}, NULL) = 0
...
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10547] nouveau: __ucmpdi2 unresolved on ppc32
http://bugs.freedesktop.org/show_bug.cgi?id=10547 --- Comment #2 from [EMAIL PROTECTED] 2007-04-09 01:43 PST --- More precisely, this should be fixed in gcc 4.2 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561
--- Comment #9 from [EMAIL PROTECTED] 2007-04-09 01:47 PST ---
It means there are currently no indirect buffers available. This can happen
intermittently during normal operation, but when it persists that probably
means the card has locked up. Unfortunately, the symptoms of a lockup don't
really say anything about its cause.
The last DRM commands I see in the strace output are:
ioctl(13, 0x4008642a, 0xffeda0b4) = 0
gettimeofday({1176052195, 567600}, NULL) = 0
ioctl(13, 0x40106450, 0xffeda04c) = 0
ioctl(13, 0xc0086451, 0xffeda06c) = 0
ioctl(13, 0xc010643a, 0xffeda06c) = 0
ioctl(13, 0x6447, 0)= 0(In reply to comment #7)
Which translates to:
DRM_IOCTL_LOCK
DRM_RADEON_CMDBUF
DRM_RADEON_GETPARAM
DRM_IOCTL_WAIT_VBLANK
DRM_RADEON_SWAP
There's no UNLOCK! Is it implicit in the swap operation?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #10 from [EMAIL PROTECTED] 2007-04-09 01:58 PST --- First of all, does this also happen with a 32 bit kernel? (In reply to comment #8) Can you still kill the secondlife process and get X back working? Yes, I need to use kill -9. The process does not even react to SIGSTOP/SIGCONT (^Z in the shell). Probably because it's holding the hardware lock. But there's that 1ms pause between calls to ioctl(). That's up to the Mesa driver. I'm not sure the sleep is really useful, I think it should at least drop the hardware lock in addition to sleeping, if not instead of it. I can whip up a patch for that. And the arguments are always the same. Doesn't it mean it's a retry loop? Sure, didn't (mean to) say it isn't. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #11 from [EMAIL PROTECTED] 2007-04-09 01:59 PST --- Created an attachment (id=9520) -- (http://bugs.freedesktop.org/attachment.cgi?id=9520action=view) Don't sleep between texture upload ioctls, drop hardware lock instead Does this patch help for interrupting the process, attaching gdb to it, or possibly even the hang? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #12 from [EMAIL PROTECTED] 2007-04-09 02:06 PST --- (In reply to comment #9) There's no UNLOCK! Is it implicit in the swap operation? The locking fastpaths work without ioctls; the ioctls are only needed when a client is trying to grab the lock while another one is holding it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8174] Store back-buffer/depth-buffer in AGP memory (rather than video RAM)
http://bugs.freedesktop.org/show_bug.cgi?id=8174 --- Comment #1 from [EMAIL PROTECTED] 2007-04-09 02:43 PST --- There's another archive of this discussion here: http://thread.gmane.org/gmane.comp.video.dri.user/5979/ (sourceforge's forums are down at the moment) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
rs480 + r300 driver fun..
Okay the GART is working fine on the rs480 from my branch, however the r300 driver causes a chip lockup, I've loaded fglrx and from what I can see it disables the Vertex Shaders in hw and does that bit of the pipeline in sw.. at least on the system I have... If anyone else has an xpress 200 or 200m, perhaps they could try fglrx and run a GL app and find out what the value in reg 0x2140 is, the latest version of radeontool from my git repo will do it..[1] radeontool regmatch SE_CNTL_STATUS I think the bit that turns on/off the Vertex stuff is the same bit that used to turn on/off the TCL engine.. I'm not sure how we can handle this in r300, we probably need to use a swtcl path for these chips Dave. [1] git://people.freedesktop.org/~airlied/radeontool -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10490] Beryl works only after reboot from Windows XP
http://bugs.freedesktop.org/show_bug.cgi?id=10490 --- Comment #8 from [EMAIL PROTECTED] 2007-04-09 04:01 PST --- Created an attachment (id=9521) -- (http://bugs.freedesktop.org/attachment.cgi?id=9521action=view) Xorg.0.log when booted directly -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10490] Beryl works only after reboot from Windows XP
http://bugs.freedesktop.org/show_bug.cgi?id=10490 --- Comment #9 from [EMAIL PROTECTED] 2007-04-09 04:01 PST --- The Xorg.0.log after direct boot appears truncated; can you log into the machine remotely after this happens, or is the machine at least pingable? Can you get at the X server's stderr output and/or the kernel output? Sorry for the delayed answer. Here's another Xorg.0.log, but I think it is truncated again. How can I get the complete file? Yes, the machine is pingable after the screen is gone black, but I can't establish a ssl or ftp connection to the machine. How can I get X server's stderr output or kernel output? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10490] Beryl works only after reboot from Windows XP
http://bugs.freedesktop.org/show_bug.cgi?id=10490 --- Comment #10 from [EMAIL PROTECTED] 2007-04-09 04:42 PST --- (In reply to comment #9) Sorry for the delayed answer. Here's another Xorg.0.log, but I think it is truncated again. How can I get the complete file? Maybe I should add how I came to the (truncated) Xorg.0.log file: I booted with the parameter knoppix 2 which starts the system in runlevel 2. Then I entered X -probeonly which generates the log file and returns to the console from where I can copy the file. I chose runlevel 2 because I didn't see another possibility to get the log file; When I boot with knoppix 3d I can't do anything after the screen goes black: no CTRL+ALT+BACKSPACE nor CTRL+ALT+F1/F2 to switch to the console. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10477] [PATCH] mga not updating drawable state after window moves
http://bugs.freedesktop.org/show_bug.cgi?id=10477 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #5 from [EMAIL PROTECTED] 2007-04-09 05:14 PST --- *** Bug 9210 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: rs480 + r300 driver fun..
Dave Airlie wrote: Okay the GART is working fine on the rs480 from my branch, however the r300 driver causes a chip lockup, I've loaded fglrx and from what I can see it disables the Vertex Shaders in hw and does that bit of the pipeline in sw.. at least on the system I have... If anyone else has an xpress 200 or 200m, perhaps they could try fglrx and run a GL app and find out what the value in reg 0x2140 is, the latest version of radeontool from my git repo will do it..[1] radeontool regmatch SE_CNTL_STATUS I think the bit that turns on/off the Vertex stuff is the same bit that used to turn on/off the TCL engine.. I'm not sure how we can handle this in r300, we probably need to use a swtcl path for these chips Dave. I thought the r300 driver could already handle tcl fallbacks. It's not news that the xpress chips don't have any hw tcl/vertex shaders, that has been known forever and is afaik officially confirmed (the screen code doesn't set the RADEON_CHIPSET_TCL bit for these chips for a reason). The same is still true for rs690, btw. Roland - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #13 from [EMAIL PROTECTED] 2007-04-09 05:24 PST --- I'm not sure it's relevant: there are no other GL clients running at the same time. But the SecondLife client spawns multiple threads. Maybe it's hitting a multithreading bug in libGL. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #14 from [EMAIL PROTECTED] 2007-04-09 05:47 PST --- (In reply to comment #11) Created an attachment (id=9520) -- (http://bugs.freedesktop.org/attachment.cgi?id=9520action=view) [details] Don't sleep between texture upload ioctls, drop hardware lock instead Does this patch help for interrupting the process, attaching gdb to it, or possibly even the hang? I still need to kill it with -9, but: I can now attach gdb and the X server doesn't hang anymore! I enabled the diagnostic output and I see an infinite succession of DRM_RADEON_TEXTURE: again!. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561
--- Comment #15 from [EMAIL PROTECTED] 2007-04-09 05:51 PST ---
(In reply to comment #13)
But the SecondLife client spawns multiple threads.
Maybe it's hitting a multithreading bug in libGL.
And this is the strace output with threads included (-f):
[pid 29333] write(3, 2007-04-09T12:35:05Z INFO: login..., 55) = 55
[pid 29333] gettimeofday({1176122105, 902851}, NULL) = 0
[pid 29333] gettimeofday({1176122105, 902888}, NULL) = 0
[pid 29333] brk(0xcc51000) = 0xcc51000
[pid 29333] brk(0xcc75000) = 0xcc75000
[pid 29333] futex(0x9b29a38, FUTEX_WAKE, 2147483647) = 0
[pid 29333] ioctl(13, 0x4008642a, 0xff94ab24) = 0
[pid 29333] ioctl(13, 0x40106450, 0xff94a4fc) = 0
[pid 29333] ioctl(13, 0xc018644e unfinished ...
[pid 29340] ... nanosleep resumed NULL) = 0
[pid 29340] gettimeofday({1176122105, 913238}, NULL) = 0
[pid 29340] gettimeofday({1176122105, 913269}, NULL) = 0
[pid 29340] nanosleep({0, 0}, NULL) = 0
[pid 29340] futex(0xc80b140, FUTEX_WAKE, 1) = 0
[pid 29340] nanosleep({0, 1000}, unfinished ...
[pid 29333] ... ioctl resumed , 0xff94a500) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 29333] write(2, DRM_RADEON_TEXTURE: again!\n, 28DRM_RADEON_TEXTURE:
again!
As you can see, two threads are fiddling with GL at the same time.
Is this supposed to work?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #16 from [EMAIL PROTECTED] 2007-04-09 06:08 PST --- (In reply to comment #15) As you can see, two threads are fiddling with GL at the same time. Actually, I only see one thread dealing with the DRM file descriptor. Am I missing something? A couple of random ideas to try and find out more about what's going on: * Try returning 0 instead of -EAGAIN or even immediately in radeon_cp_dispatch_texture(). This will cause textures to be corrupted, but does it avoid the hang? * Try adding debugging output in the DRM and/or Mesa code to see how it's (not) advancing on the texture upload. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #17 from [EMAIL PROTECTED] 2007-04-09 06:18 PST --- I enabled RADEON_DEBUG=allmsg and this are the last lines of the output before hanging: r300Enable( GL_TEXTURE_2D = GL_TRUE ) r300Enable( GL_COLOR_MATERIAL = GL_TRUE ) r300Enable( GL_DITHER = GL_FALSE ) r300Enable( GL_DEPTH_TEST = GL_TRUE ) r300Clear Reemit state after flush (from r300EmitClearState) r300EmitState Begin reemit state Begin dirty state r300ClearBuffer: back buffer (4,52 800x600) r300Enable( GL_BLEND = GL_TRUE ) r300Enable( GL_ALPHA_TEST = GL_TRUE ) r300Enable( GL_DEPTH_TEST = GL_FALSE ) r300Enable( GL_TEXTURE_2D = GL_FALSE ) r300_run_tcl_render r300_run_vb_render r300IsGartMemory( 0xb352140 ) : 0 emit_vector count 4 size 2 stride 8 r300AllocDmaRegion 32 emit_vec8 count 4 stride 8 r300IsGartMemory( 0xb3198f8 ) : 0 emit_vector count 4 size 4 stride 0 r300AllocDmaRegion 16 emit_vec16 count 1 stride 0 mtu=8 TX_ENABLE: last_hw_tmu=-1 r300EmitState Begin dirty state r300EmitAOS: nr=2, ofs=0x r300ReleaseDmaRegion from r300ReleaseArrays r300ReleaseDmaRegion from r300ReleaseArrays r300ReleaseDmaRegion from r300ReleaseArrays r300Enable( GL_TEXTURE_2D = GL_TRUE ) r300BindTexture( 0xca4e808 ) unit=0 r300_run_tcl_render pc=3* Mesa program: - # Fragment Program/Shader 0: TXP TEMP[0] (cond???..), INPUT[4], texture[0], 2D; 1: MUL OUTPUT[0].xyz (cond???..), TEMP[0], INPUT[1]; 2: MOV OUTPUT[0].w (cond???..), INPUT[1]; 3: END Hardware program NODE 0: alu_offset: 0, tex_offset: 0, alu_end: 0, tex_end: 0 TEX: TXP t2, t0, texture[0] (00018080) 0: xyz: t2 t1 c0 - o0.xyz (1c020042) w: t1 c0 c0 - o0.w (01020801) xyz: t2.xyz t1.xyz 0.0op: 00050200 w: t1.w 1.0 0.0op: 00040889 r300_run_vb_render r300IsGartMemory( 0xb352140 ) : 0 emit_vector count 4 size 2 stride 16 r300AllocDmaRegion 32 emit_vec8 count 4 stride 16 r300IsGartMemory( 0xb3198f8 ) : 0 emit_vector count 4 size 4 stride 0 r300AllocDmaRegion 16 emit_vec16 count 1 stride 0 r300IsGartMemory( 0xb352148 ) : 0 emit_vector count 4 size 2 stride 16 r300AllocDmaRegion 32 emit_vec8 count 4 stride 16 r300Flush r300FlushCmdBufLocked from r300Flush - 1 cliprects r300UploadTexImages( 0xb318be0, 0xca4e808 ) sz=4096 lvls=0-0 uploadSubImage( 0xc9328c0, 0xca4e808 ) level/width/height/face = 0/32/32/0 uploadSubImage: image data is in normal memory upload image: 32,32 at 0,0 upload blit: 32,32 at 0,0 blit ofs: 0xe3866000 level: 0/0 mtu=8 Activating texture unit 0 TX_ENABLE: 0001 last_hw_tmu=0 Reemit state after flush (from r300_run_vb_render) r300EmitState Begin reemit state Begin dirty state r300EmitState r300EmitAOS: nr=3, ofs=0x r300ReleaseDmaRegion from r300ReleaseArrays r300ReleaseDmaRegion from r300ReleaseArrays r300ReleaseDmaRegion from r300ReleaseArrays r300ReleaseDmaRegion from r300ReleaseArrays r300Enable( GL_ALPHA_TEST = GL_FALSE ) r300BindTexture( 0xc591c78 ) unit=0 r300_run_tcl_render r300_run_vb_render r300IsGartMemory( 0xb352140 ) : 0 emit_vector count 4 size 2 stride 16 r300AllocDmaRegion 32 emit_vec8 count 4 stride 16 r300IsGartMemory( 0xb3198f8 ) : 0 emit_vector count 4 size 4 stride 0 r300AllocDmaRegion 16 emit_vec16 count 1 stride 0 r300IsGartMemory( 0xb352148 ) : 0 emit_vector count 4 size 2 stride 16 r300AllocDmaRegion 32 emit_vec8 count 4 stride 16 r300Flush r300FlushCmdBufLocked from r300Flush - 1 cliprects r300UploadTexImages( 0xb318be0, 0xc591c78 ) sz=4194304 lvls=0-0 uploadSubImage( 0xc6d5be8, 0xc591c78 ) level/width/height/face = 0/1024/1024/0 uploadSubImage: image data is in normal memory upload image: 1024,1024 at 0,0 upload blit: 1024,1024 at 0,0 blit ofs: 0xe3867000 level: 0/0 DRM_RADEON_TEXTURE: again! DRM_RADEON_TEXTURE: again! DRM_RADEON_TEXTURE: again! [...] -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #18 from [EMAIL PROTECTED] 2007-04-09 06:28 PST --- (In reply to comment #16) (In reply to comment #15) As you can see, two threads are fiddling with GL at the same time. Actually, I only see one thread dealing with the DRM file descriptor. Am I missing something? No, you're right... I'm not sure I've seen it for real now... will try harder. * Try returning 0 instead of -EAGAIN or even immediately in radeon_cp_dispatch_texture(). This will cause textures to be corrupted, but does it avoid the hang? I added a retry count in the while loop, and now the client exits with an error. The log looks like this: uploadSubImage( 0xdfb09828, 0xdb1b2808 ) level/width/height/face = 0/1024/1024/0 uploadSubImage: image data is in normal memory upload image: 1024,1024 at 0,0 upload blit: 1024,1024 at 0,0 blit ofs: 0xe3866000 level: 0/0 DRM_RADEON_TEXTURE: again! DRM_RADEON_TEXTURE: again! DRM_RADEON_TEXTURE: again! DRM_RADEON_TEXTURE: return = -11 offset=0xe3866000 image width=1024 height=1024 blit width=1024 height=1024 data=0xd9fff200 BTW, isn't 1024x1024 too big for a texture??? * Try adding debugging output in the DRM and/or Mesa code to see how it's (not) advancing on the texture upload. Is the log attached to the previous comment useful? Or do you need me to add a printf in a more specific place? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #19 from [EMAIL PROTECTED] 2007-04-09 06:31 PST --- By the way, can anybody try running the SecondLife client on their systems to see if the bug can be reproduced? It's here: http://secondlife.com/community/linux-alpha.php -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #20 from [EMAIL PROTECTED] 2007-04-09 06:40 PST --- (In reply to comment #18) I added a retry count in the while loop, and now the client exits with an error. Not what I asked for... BTW, isn't 1024x1024 too big for a texture??? No, see glxinfo -l|grep MAX_TEXTURE_SIZE . Does the Mesa texdown demo also hang with 1024x1024? Is the log attached to the previous comment useful? Not really. Or do you need me to add a printf in a more specific place? Indeed. E.g., do the DRM and client side have a consistent view of the ioctl arguments over the repeated calls? Does the DRM side return -EAGAIN immediately in the end or does it process some buffers before? Does it make any progress before returning -EAGAIN for the first time? ... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #21 from [EMAIL PROTECTED] 2007-04-09 06:41 PST --- (In reply to comment #19) By the way, can anybody try running the SecondLife client on their systems to see if the bug can be reproduced? I can't reproduce it on my PowerBook. Can you try a 32 bit kernel? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #22 from [EMAIL PROTECTED] 2007-04-09 07:09 PST --- (In reply to comment #21) I can't reproduce it on my PowerBook. Can you try a 32 bit kernel? Sorry, I can't. The userland is 64bit. Any other difference? Do you have any fancy option in xorg.conf? Is your card AGP or PCI-E? Mine is PCI-E. I'm using today's versions of dri, mesa and xserver. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: rs480 + r300 driver fun..
Dave Roland, On 4/9/07, Roland Scheidegger [EMAIL PROTECTED] wrote: Dave Airlie wrote: Okay the GART is working fine on the rs480 from my branch, Congratulations on getting it to work. I've tested your DRM branch on my HP laptop with a 200M, and it works. (128M of video RAM, 0 sideport RAM.) X starts up with a nice stipple pattern, and gears hangs in the same way you described in your blog. (Damn. I was so close, I had 4 or 5 proper startups with my hacked/reverse engineered code, but I couldn't figure out how to make it happen reliably. I didn't read RADEON_IGPGART_UNK_38 before I wrote it.. Maybe that was the problem.) BTW. Base on the back traces I gathered when running kmmio, I think that the following defines should be renamed: RADEON_IGPGART_UNK_2E - RADEON_IGPGART_FLUSH RADEON_IGPGART_UNK_38 - RADEON_IGPGART_ENABLE (More details at: http://dri.freedesktop.org/wiki/Radeon200M) however the r300 driver causes a chip lockup, I've loaded fglrx and from what I can see it disables the Vertex Shaders in hw and does that bit of the pipeline in sw.. at least on the system I have... If anyone else has an xpress 200 or 200m, perhaps they could try fglrx and run a GL app and find out what the value in reg 0x2140 is, the latest version of radeontool from my git repo will do it..[1] radeontool regmatch SE_CNTL_STATUS I'll check out that register tonight. I think the bit that turns on/off the Vertex stuff is the same bit that used to turn on/off the TCL engine.. I'm not sure how we can handle this in r300, we probably need to use a swtcl path for these chips Dave. I thought the r300 driver could already handle tcl fallbacks. It's not news that the xpress chips don't have any hw tcl/vertex shaders, that has been known forever and is afaik officially confirmed (the screen code doesn't set the RADEON_CHIPSET_TCL bit for these chips for a reason). The same is still true for rs690, btw. Roland What has to be done now? Where can look to start hacking Mesa to support it? (I've spent all of my time so far in DRM.. (radeon_cp.c) ) Cheers, --Phil - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10576] New: drm modules won't compile with 2.6.21-rc6 (m_insert_pfn clash)
http://bugs.freedesktop.org/show_bug.cgi?id=10576 Summary: drm modules won't compile with 2.6.21-rc6 (m_insert_pfn clash) Product: DRI Version: DRI CVS Platform: All OS/Version: All Status: NEW Severity: normal Priority: highest Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] It looks like that latest (as of writing [EMAIL PROTECTED]) kernel contains function named vm_insert_pfn in /mm/memory.c and /mm/mm.h (see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e0dc0d8f4a327d033bfb63d43f113d5f31d11b3c for specific check-in). Unfortunately vm_insert_pfn is also used in drm_compat.c thus resulting in naming clash. At a first glance they both differ in code very much. The result of make is /home/michal/nouveau/drm/linux-core/drm_compat.c:190: error: static declaration of ‘vm_insert_pfn’ follows non-static declaration include/linux/mm.h:1126: error: previous declaration of ‘vm_insert_pfn’ was here The bug was found on Ubuntu Feisty with latest kernel packages installed (which apparently is 2.6.20. uname -r gives 2.6.20-14-generic) 2.6.20 from gentoo does not have this problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10576] drm modules won't compile with 2.6.21-rc6 (vm_insert_pfn names clash)
http://bugs.freedesktop.org/show_bug.cgi?id=10576 [EMAIL PROTECTED] changed: What|Removed |Added Summary|drm modules won't compile |drm modules won't compile |with 2.6.21-rc6 |with 2.6.21-rc6 |(m_insert_pfn clash)|(vm_insert_pfn names clash) --- Comment #1 from [EMAIL PROTECTED] 2007-04-09 11:09 PST --- Links to drm and kernels git's that have introduced incompatibility: http://gitweb.freedesktop.org/?p=mesa/drm.git;a=commitdiff;h=f2db76e2f206d2017f710eaddc4b33add4498898 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e0dc0d8f4a327d033bfb63d43f113d5f31d11b3c Someone has to change the name but who? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10576] drm modules won't compile with 2.6.21-rc6 (vm_insert_pfn names clash)
http://bugs.freedesktop.org/show_bug.cgi?id=10576 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #2 from [EMAIL PROTECTED] 2007-04-09 11:27 PST --- (In reply to comment #1) Links to drm and kernels git's that have introduced incompatibility: http://gitweb.freedesktop.org/?p=mesa/drm.git;a=commitdiff;h=f2db76e2f206d2017f710eaddc4b33add4498898 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e0dc0d8f4a327d033bfb63d43f113d5f31d11b3c Someone has to change the name but who? vm_insert_pfn first appears in the kernel in the 2.6.21-rc series. In drm_compat.c it is not included if the kernel version = 2.6.21, when the symbol DRM_FULL_MM_COMPAT is defined. The semantics of the two functions, although they are looking very different are the same. The one in the mainstream kernel should be used if there is a clash. I'm not sure why it appears in Ubuntu 2.6.20. I think you need to ask the Ubuntu guys. /Thomas -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: rs480 + r300 driver fun..
What has to be done now? Where can look to start hacking Mesa to support it? (I've spent all of my time so far in DRM.. (radeon_cp.c) ) Does setting tcl_mode=0 in .drirc make it work? --AWJ-- _ Dont waste time standing in linetry shopping online. Visit Sympatico / MSN Shopping today! http://shopping.sympatico.msn.ca - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: rs480 + r300 driver fun..
Hi,
Dave Airlie írta:
Okay the GART is working fine on the rs480 from my branch, however the
Congrats!
r300 driver causes a chip lockup, I've loaded fglrx and from what I can
see it disables the Vertex Shaders in hw and does that bit of the pipeline
in sw.. at least on the system I have...
If anyone else has an xpress 200 or 200m, perhaps they could try fglrx and
run a GL app and find out what the value in reg 0x2140 is, the latest
version of radeontool from my git repo will do it..[1]
radeontool regmatch SE_CNTL_STATUS
Before running glxgears, it gives 0x.
During and after: 0x0100.
I had to patch your radeontool a bit to get it working,
the notebook has all sort of ATI Technology integrated
stuff, starting with a bridge. So, line 811 should read:
if(strstr(line,Radeon) strstr(line,ATI Tech)) { ...
instead of
if(strstr(line,Radeon) || strstr(line,ATI Tech)) { ...
to read the correct entry. lspci and glxinfo attached.
I think the bit that turns on/off the Vertex stuff is the same bit that
used to turn on/off the TCL engine..
I'm not sure how we can handle this in r300, we probably need to use a
swtcl path for these chips
Dave.
[1] git://people.freedesktop.org/~airlied/radeontool
00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 10)
Subsystem: Acer Incorporated [ALI] Unknown device 009f
Flags: bus master, 66MHz, medium devsel, latency 64
00:01.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 9000-9fff
Memory behind bridge: d010-d01f
Prefetchable memory behind bridge: d400-d7f0
Capabilities: access denied
00:04.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=03, sec-latency=0
Capabilities: access denied
00:05.0 PCI bridge: ATI Technologies Inc Unknown device 5a37 (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=04, subordinate=05, sec-latency=0
Capabilities: access denied
00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (rev 80) (prog-if 10 [OHCI])
Subsystem: Acer Incorporated [ALI] Unknown device 009f
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
Memory at d0004000 (32-bit, non-prefetchable) [size=4K]
Capabilities: access denied
00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (rev 80) (prog-if 10 [OHCI])
Subsystem: Acer Incorporated [ALI] Unknown device 009f
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
Memory at d0005000 (32-bit, non-prefetchable) [size=4K]
Capabilities: access denied
00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller (rev 80) (prog-if 20 [EHCI])
Subsystem: Acer Incorporated [ALI] Unknown device 009f
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
Memory at d0006000 (32-bit, non-prefetchable) [size=4K]
Capabilities: access denied
00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 83)
Subsystem: Acer Incorporated [ALI] Unknown device 009f
Flags: 66MHz, medium devsel
I/O ports at 8400 [size=16]
Memory at fed0 (32-bit, non-prefetchable) [size=1K]
Capabilities: access denied
00:14.1 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE Controller ATI (rev 80) (prog-if 82 [Master PriP])
Subsystem: Acer Incorporated [ALI] Unknown device 009f
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 16
I/O ports at 01f0 [size=8]
I/O ports at 03f4 [size=1]
I/O ports at 0170 [size=8]
I/O ports at 0374 [size=1]
I/O ports at 8410 [size=16]
Capabilities: access denied
00:14.2 Audio device: ATI Technologies Inc SB450 HDA Audio (rev 01)
Subsystem: Acer Incorporated [ALI] Unknown device 009f
Flags: bus master, slow devsel, latency 64, IRQ 16
Memory at d000 (64-bit, non-prefetchable) [size=16K]
Capabilities: access denied
00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80)
Subsystem: Acer Incorporated [ALI] Unknown device 009f
Flags: bus master, 66MHz, medium devsel, latency 0
00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge (rev 80) (prog-if 01 [Subtractive decode])
Flags: bus master, 66MHz, medium devsel, latency 64
Bus: primary=00, secondary=06, subordinate=08, sec-latency=64
I/O behind bridge: a000-afff
Memory behind bridge: d020-d02f
Prefetchable memory behind bridge: 3000-33ff
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
Flags: fast devsel
Capabilities: access denied
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
Flags: fast devsel
00:18.2 Host bridge: Advanced Micro Devices
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #23 from [EMAIL PROTECTED] 2007-04-09 15:01 PST --- I can get lockups with R300 and my own code, too. It seems to be similar to your lockup, but it's just when the buffers run out. I think the no-usleep patch should be committed as it helps to get gdb working. I also wonder if it's worth looking for places where we can get into an infinite loop and adding a timeout of X iterations... At least Second Life can reliably reproduce the lockup; my code doesn't seem to reproduce it 100% of the time. It does seem to happen quicker at higher resolutions though; probably because the card must work (much) harder then. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10523] glActiveStencilFaceEXT causes noop dispatch on R300
http://bugs.freedesktop.org/show_bug.cgi?id=10523 --- Comment #4 from [EMAIL PROTECTED] 2007-04-09 19:13 PST --- Has anyone got any ideas about this? I think that R300 is the only DRI driver to support this extension, so maybe something is broken in the code related to this extension? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
A Study on Free/Open Source Software Defect Management
Dear Sir/Madam, I am really thankful to Free/Open Source Software development community for their overwhelming response to the survey on practices and problems of defect management in Free/Open Source Software projects. If you have not participated ealier, you may spend a few minutes now too. The Online Questionnaire is available at: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey I hope you have found all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. The results of study will soon be communicated to you. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #24 from [EMAIL PROTECTED] 2007-04-09 22:58 PST --- (In reply to comment #23) I think the no-usleep patch should be committed as it helps to get gdb working. Unfortunately, I realized in the meantime it doesn't work in general. The world can literally change between dropping the lock and taking it again - in particular, the video RAM reserved for the texture being uploaded can be reclaimed by another client. It's really just a bug that a texture can't be uploaded in finite time. Now, if we could get answers to the remaining open questions... I also wonder if it's worth looking for places where we can get into an infinite loop and adding a timeout of X iterations... Maybe, but note that as killing the process resumes normal operation, this is not really a lockup but more like a deadlock. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
