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.
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
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:
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
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
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
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
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
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
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/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
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
http://bugs.freedesktop.org/show_bug.cgi?id=10477
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment
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
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
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
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
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
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 )
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
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://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
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
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
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
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:
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
http://bugs.freedesktop.org/show_bug.cgi?id=10576
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
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
http://bugs.freedesktop.org/show_bug.cgi?id=10561
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment
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
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
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
34 matches
Mail list logo
