but... heres something that shows info about the error from yesterday:
(please also see attached file, this is only an extract:)
Nov 23 20:18:13 buche kernel: [drm:radeon_irq_emit] *ERROR*
radeon_irq_emit called without lock held
Nov 23 20:18:13 buche kernel: [drm:radeon_lock_take] *ERROR* 6
Michel Dänzer wrote:
On Son, 2002-11-24 at 18:39, Andreas Stenglein wrote:
Nov 23 20:18:13 buche kernel: [drm:radeon_irq_emit] *ERROR*
radeon_irq_emit called without lock held
Nov 23 20:18:13 buche kernel: [drm:radeon_lock_take] *ERROR* 6 holds
heavyweight lock
A friend of mine reported
This branch still has textures not showing up properly. For me tribes 2 triggers this.
Screenshot http://chronoworx.dnsalias.org/~greisky/mesa-4-1-branch/texturebad.png.
The inventory station doesn't show up properly from far away but as you get closer it
looks right as in
I think I found the problem. usleep() gets defined as a macro to xf86usleep()
in xf86_ansi.h (via radeon_regs.h) and needs to be #undefined.
Do we know why xf86_ansi.h is getting included in the client-side module?
It's only intended for X server modules. It'd be better to not include
it in
Latest CVS pull (12 hrs ago)
Radeon r100 64MB vivo @ AGP 4x
2.4.19 SMP kernel
via chipset (asus cuv4x-d)
2x Intel p3 933
1GB ram
w/o himem, it works fine--q3a plays, etc.
w/ himem, q3a hangs the machine completely, no ping, no vt switching,
nothing.
Nick
On Mon, Nov 25, 2002 at 09:44:46AM +, Keith Whitwell wrote:
I think I found the problem. usleep() gets defined as a macro to xf86usleep()
in xf86_ansi.h (via radeon_regs.h) and needs to be #undefined.
Do we know why xf86_ansi.h is getting included in the client-side module?
It's only
You can build a PROFITABLE H~me Based Business.Leverage the Internet!Highlights - International ATM Card (US Bank!) - Worldwide Market - No Limits! - Daily Payout via 7,000,000~ ATMs - Simple Concept - No sales work. - Worldclass Tools and Support - Low Entry Cost - No monthly fees. Real
Roman Stepanov wrote:
On 24 Nov 2002 18:19, you wrote:
The meaning of this post, just a simple bug report.
Sure it could be a leocad bug, but since the r200 drivers are highly in
development i figured this is the place that's mostly interested.
The r200 driver is basically done; it's not
David Dawes wrote:
On Mon, Nov 25, 2002 at 09:44:46AM +, Keith Whitwell wrote:
I think I found the problem. usleep() gets defined as a macro to xf86usleep()
in xf86_ansi.h (via radeon_regs.h) and needs to be #undefined.
Do we know why xf86_ansi.h is getting included in the client-side
Roman Stepanov wrote:
I suggest using Loki's Rune demo for testing r200 driver. I have
serious perfomance problems with Rune demo while playing Quake 3 is
very smooth. My system is Athlon XP 1800+, 256 Mb RAM, XFree 4.2 +
r200-20021117 driver, SuSE kernel 2.4.19-4G, glxgears shows
Title: drmOpen coding is incomplete
drmOpen tries opening the drm device two times,
but on second try it does trash that file handle
in the case of success. the below patch does
add the missing return statment for this case.
-Alex.
PS: the patch should nicely apply to current
XF86 and
Alexander Stohr wrote:
drmOpen tries opening the drm device two times,
but on second try it does trash that file handle
in the case of success. the below patch does
add the missing return statment for this case.
-Alex.
PS: the patch should nicely apply to current
XF86 and DRI CVS code
I'm trying to decide when to merge the mesa-41 branch into the trunk.
People have reported a number of problems, but for the most part, they
seem to be present in the trunk as well.
At this time, the only differences between the trunk and branch server
code is in the indirect GLX rendering
On Mon, 2002-11-25 at 10:51, Nicholas Leippe wrote:
Latest CVS pull (12 hrs ago)
Radeon r100 64MB vivo @ AGP 4x
2.4.19 SMP kernel
via chipset (asus cuv4x-d)
2x Intel p3 933
1GB ram
w/o himem, it works fine--q3a plays, etc.
w/ himem, q3a hangs the machine completely, no ping, no vt
On Mon, Nov 25, 2002 at 09:15:59AM -0700, Brian Paul wrote:
It might make sense to merge to the trunk soon so that there's one code
base to focus on.
That seems like a very good call. I'd also like to get mesa-41 merged so
that I can bring it into the texmem branch.
Everyone seems to want
On Mon, 2002-11-25 at 17:15, Brian Paul wrote:
I'm trying to decide when to merge the mesa-41 branch into the trunk.
People have reported a number of problems, but for the most part, they
seem to be present in the trunk as well.
At this time, the only differences between the trunk and
hi
after install dri r200 and extra-4.2.99.2 glx and dri ok
but if call gtk-demo crash imediatly
if not call gtk-demo after quit wmaker
wmaker warning: internal X error: BadAccess (attempt to access private
resource
denied)
Request code: 28 X_GrabButton
Request minor code: 0
On one of my machines, I have a radeon 7500 (32MB DDR actually), and a
couple of days ago I tried the current dri-trunk debian packages on it.
But trying to run a 3D game through WineX causes a crash. So, I got the
source, got a backtrace, and tracked the problem to the current
implementation of
On Mon, Nov 25, 2002 at 05:44:42PM +0100, Ove Kaaven wrote:
On one of my machines, I have a radeon 7500 (32MB DDR actually), and a
couple of days ago I tried the current dri-trunk debian packages on it.
But trying to run a 3D game through WineX causes a crash. So, I got the
source, got a
Michel Dänzer wrote:
On Mon, 2002-11-25 at 17:15, Brian Paul wrote:
I'm trying to decide when to merge the mesa-41 branch into the trunk.
People have reported a number of problems, but for the most part, they
seem to be present in the trunk as well.
At this time, the only differences between
Brian Paul wrote:
Michel Dänzer wrote:
On Mon, 2002-11-25 at 17:15, Brian Paul wrote:
I'm trying to decide when to merge the mesa-41 branch into the trunk.
People have reported a number of problems, but for the most part, they
seem to be present in the trunk as well.
At this time, the only
Hello!
Im using xmms-1.2.5-65.rpm from suse. build date: 24 Sep 2001
do a
xmms
then select a song, press play
press the O for Options,
select Einstellungen (settings),
then select the tab for visual-plugins,
select OpenGL LAVA Plugin 0.7, press use plugin
- a window with some floating lava pops
Keith Whitwell wrote:
Michel Dänzer wrote:
On Son, 2002-11-24 at 18:39, Andreas Stenglein wrote:
Nov 23 20:18:13 buche kernel: [drm:radeon_irq_emit] *ERROR*
radeon_irq_emit called without lock held
Nov 23 20:18:13 buche kernel: [drm:radeon_lock_take] *ERROR* 6 holds
heavyweight lock
A
To reply to the questions from various people:
1) DMA on hda is on
hdparm -Tt /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.48 seconds =266.67 MB/sec
Timing buffered disk reads: 64 MB in 2.12 seconds = 30.19 MB/sec
2) I see no error messages in any of the logs (so no reports
On Mon, Nov 25, 2002 at 06:55:20PM +0100, Andreas Stenglein wrote:
setting RADEON_NO_VTXFMT=1 helped: no crashes
setting RADEON_TCL_FORCE_DISABLE=1 helped, too
using trunk: helped NOT
using latest radeon.o from 2002-11-24 dri: helped NOT
This makes me wonder if it /might/ be releated to the
On Mon, 25 Nov 2002, Brian Paul wrote:
It might make sense to merge to the trunk soon so that there's one code
base to focus on. Everyone seems to want the mesa-41 work to get into
XFree86 4.3.
What do people think?
I say go for it.
If we can get it into the trunk then it will be
I'll be checking in the merge soon. I'm just doing a second build to
double-check everything. Testing is going good so far.
-Brian
---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power Color in a compact
Hello!
I dont think that would help, as a
strings liblava.so | grep EXT
or
strings libogl_spectrum.so | grep EXT
shows nothing.
but strings libxyz.so | grep gl
shows the gl...-calls.
but I'm going to try it out..
regards,
Andreas
Am 2002.11.25 19:26:20 +0100 schrieb(en) Ian Romanick:
On Mon,
hello!
GL_EXT_secondary_color doesnt matter,
just got a Xserver lockup, with the patch,
where the music keeps playing.
I tried it... and got a Xserver freeze.
1st: I had to kill the Xserver, maybe I waited to long
and after killall -KILL X, init 3, init 5, login,
playing around a bit:
2nd time:
Brian Paul wrote:
I'll be checking in the merge soon. I'm just doing a second build to
double-check everything. Testing is going good so far.
OK, the merge is done.
-Brian
---
This SF.net email is sponsored by: Get the new Palm
This is just a friendly reminder that the weeking dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.openprojects.net at 2100 UTC (or
4:00PM EST or 1:00PST, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Here is a backtrace from gdb, its almost the same for the
app is dieing and xserver freezes.
when running xmms in gdb, the xserver doesnt freeze, only
the app. If you continue, one thread is dead, the other
keeps going!
But I had another thing: after restoring the xserver
with killall -KILL X and
Andreas Stenglein wrote:
Here is a backtrace from gdb, its almost the same for the
app is dieing and xserver freezes.
when running xmms in gdb, the xserver doesnt freeze, only
the app. If you continue, one thread is dead, the other
keeps going!
But I had another thing: after restoring the
On Monday 25 November 2002 09:11 am, Michel Dänzer wrote:
On Mon, 2002-11-25 at 10:51, Nicholas Leippe wrote:
Latest CVS pull (12 hrs ago)
Radeon r100 64MB vivo @ AGP 4x
2.4.19 SMP kernel
via chipset (asus cuv4x-d)
2x Intel p3 933
1GB ram
w/o himem, it works fine--q3a plays, etc.
There are two places in radeon_ioctl.c where the INREG() macro is used to
read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG).
It looks like these have been superceeded by drmCommandWriteRead() calls
(since the 11 July check-in of Tim Smith's changes). INREG is probably
only
On Mon, 2002-11-25 at 23:21, Brian Paul wrote:
There are two places in radeon_ioctl.c where the INREG() macro is used to
read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG).
It looks like these have been superceeded by drmCommandWriteRead() calls
(since the 11 July
Michel Dänzer wrote:
On Mon, 2002-11-25 at 23:21, Brian Paul wrote:
There are two places in radeon_ioctl.c where the INREG() macro is used to
read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG).
It looks like these have been superceeded by drmCommandWriteRead() calls
(since
Am Montag, 25. November 2002 23:00 schrieb Nicholas Leippe:
On Monday 25 November 2002 09:11 am, Michel Dänzer wrote:
On Mon, 2002-11-25 at 10:51, Nicholas Leippe wrote:
Latest CVS pull (12 hrs ago)
Radeon r100 64MB vivo @ AGP 4x
2.4.19 SMP kernel
via chipset (asus cuv4x-d)
2x
On Mon, Nov 25, 2002 at 04:02:49PM -0700, Brian Paul wrote:
Michel Dänzer wrote:
On Mon, 2002-11-25 at 23:21, Brian Paul wrote:
There are two places in radeon_ioctl.c where the INREG() macro is used to
read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG).
It looks like these
Am Montag, 25. November 2002 00:09 schrieb Felix Kühling:
On Sun, 24 Nov 2002 22:20:26 +
[EMAIL PROTECTED] wrote:
In the past few months I've been noticing 2 problems with my A7M266-D
(dual athlon) computer (2 processors installed) with its ATI Radeon
7500 gfx card:
1) Whenever I
On Die, 2002-11-26 at 00:02, Brian Paul wrote:
Michel Dänzer wrote:
On Mon, 2002-11-25 at 23:21, Brian Paul wrote:
There are two places in radeon_ioctl.c where the INREG() macro is used to
read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG).
It looks like these have
Am Sonntag, 24. November 2002 12:52 schrieb Simon Cahuk:
Hi,
I have SuSE 8.1 and a banshee card. Glxgears is very slow, 60 FPS only.
But when I play Q3A, everything is normal, so DRI works. I recompiled
glxgears from XFree's CVS and the result is still the same.
Try MesaLib-5.0 and
On Monday 25 November 2002 04:16 pm, Dieter Nützel wrote:
Am Montag, 25. November 2002 23:00 schrieb Nicholas Leippe:
On Monday 25 November 2002 09:11 am, Michel Dänzer wrote:
On Mon, 2002-11-25 at 10:51, Nicholas Leippe wrote:
Latest CVS pull (12 hrs ago)
Radeon r100 64MB vivo @ AGP
Brian Paul wrote:
Andreas Stenglein wrote:
Here is a backtrace from gdb, its almost the same for the
app is dieing and xserver freezes.
when running xmms in gdb, the xserver doesnt freeze, only
the app. If you continue, one thread is dead, the other
keeps going!
But I had another thing: after
Brian Paul wrote:
Michel Dänzer wrote:
On Mon, 2002-11-25 at 23:21, Brian Paul wrote:
There are two places in radeon_ioctl.c where the INREG() macro is
used to
read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG).
It looks like these have been superceeded by
Michel Dänzer wrote:
On Mon, 2002-11-25 at 23:21, Brian Paul wrote:
There are two places in radeon_ioctl.c where the INREG() macro is used to
read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG).
It looks like these have been superceeded by drmCommandWriteRead() calls
(since
Am Montag, 25. November 2002 10:39 schrieb Keith Whitwell:
Michel Dänzer wrote:
On Son, 2002-11-24 at 18:39, Andreas Stenglein wrote:
Nov 23 20:18:13 buche kernel: [drm:radeon_irq_emit] *ERROR*
radeon_irq_emit called without lock held
Nov 23 20:18:13 buche kernel: [drm:radeon_lock_take]
On Die, 2002-11-26 at 01:05, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2002-11-25 at 23:21, Brian Paul wrote:
There are two places in radeon_ioctl.c where the INREG() macro is used to
read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG).
It looks like these
Am Sonntag, 24. November 2002 16:17 schrieb Brian Paul:
From the various emails I gather that there may be an X server
lock-up problem independant of the DRI, with both the trunk and
mesa-41 branch. If that's incorrect, let me know.
Then, it appears that the r200 driver on the mesa-41
1. start X or system start (init 5)
2. rcxdm stop
3. rrmod radeon
4. restart X (rcxdm start)
What happens:
* Screen corruption in several upper lines (the KDE panel)
* a copy of the graphical screen on console 1, 2, 3, etc. but without mouse or
anything else but the command line works (!)
On Monday 25 November 2002 06:12 pm, you wrote:
1. start X or system start (init 5)
2. rcxdm stop
3. rrmod radeon
4. restart X (rcxdm start)
What happens:
* Screen corruption in several upper lines (the KDE panel)
* a copy of the graphical screen on console 1, 2, 3, etc. but without mouse
Special Offer! Indulge your passion for coffee. 2 - 14 oz. bags of gourmet coffee and a gift for Free. 2 Bags of Freshly Roasted Gourmet Coffee a Gift OR Click Here For Coffee copyright Boca Java, LLC. All Rights Reserved.
[EMAIL PROTECTED]áÄ
ë^¨¥Ë)¢{(ç[Èg¶§{Údî
David Dawes wrote:
On Mon, Nov 25, 2002 at 04:02:49PM -0700, Brian Paul wrote:
Michel Dänzer wrote:
On Mon, 2002-11-25 at 23:21, Brian Paul wrote:
There are two places in radeon_ioctl.c where the INREG() macro is used to
read register values (RADEON_LAST_FRAME_REG and
Mesa/demos ./isosurf
7179 vertices, 7177 triangles
libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so
libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
54 matches
Mail list logo
