Re: [Dri-devel] full box lockup.

[Keith Whitwell]

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 holds 
heavyweight lock

Can you remember how this happened?  This is a real bug  I'd like to track it 
down if possible.

Keith



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] full box lockup.

[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] *ERROR* 6 holds 
heavyweight lock


A friend of mine reported something like this (haven't seen it myself).
For him, killing the DRI client(s) resumes normal operation. Can you
confirm that? If so, that's not an actual lockup.

I still can't really imagine what a 'heavyweight lock' is, can one of
the traditional developers explain?


It's really just the lock.  The locking process is two stage, with a cmpxcg in 
userspace which can handle the trivial case (if the same context wants to get 
 a lock and it was the last context to hold it) without kernel intervention. 
 If that fails, the process has to do an ioctl to get the lock.  This is 
where this message comes from -- maybe saying that '6' already has the lock it 
is asking for.

Keith



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] mesa-4-1-branch

[Garry Reisky]

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 
http://chronoworx.dnsalias.org/~greisky/mesa-4-1-branch/texturegood.png. I'm not sure 
if I should worry about this and wait for texmem? I haven't tried texmem in awhile 
maybe it fixes this. I've tested this on trunk and mesa-4-1-branch on an r200.


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Merge of mesa-41 branch to trunk

[Keith Whitwell]

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 the first place.


I think because there is some sharing of source (radeon_regs.h is from the 2d 
driver).  It should be protected with a #ifdef, I guess.

Keith




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] himem still causes lockup

[Nicholas Leippe]

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


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Merge of mesa-41 branch to trunk

[David Dawes]

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 intended for X server modules.  It'd be better to not include
 it in the first place.

I think because there is some sharing of source (radeon_regs.h is from the 2d 
driver).  It should be protected with a #ifdef, I guess.

I'd suggest moving those includes (and the INREG/OUTREG macros that
need them) to another place.  Those parts can't really be shared.

David


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] dri-devel Your ATM Cash niyg

[Susie D'Angelo]

 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 Promotion - Real Income! This program is currently being promoted worldwide with more than 40 Million email a~s like this - monthly! Learn how you can benefit. Discover for Yourself How Easy It Can Be! Request Your FREE Information Today.  Have ~ou been disappointed by other Biz Opps?Don't miss this one!Most so called income opportunities promise the world and deliver very little in the way of real income. Learn how easy it is to produce DAILY INCOME ONLINE.  Click cethyjljtryyuvuhiskqbecjqqvrmuuqcoabxlnufmvdlqmvjwmmboyti†+,~w­zf¢–+,¦‰ì¢·o$áŠyyézW(™ëhç¤…æ¯zxm¶Ÿÿ¶§’ž‘Ê&þÇî'^½éfj)bž	b²Ðë‰×¯zYb²Û,¢êÜyú+éÞ¶m¦Ïÿ–+-²Ê.­ÇŸ¢¸ë–+-³ùb²Ø§~Ý®'^½é

Re: [Dri-devel] full box lockup.

[Keith Whitwell]

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 highly in development.

-Brian



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 about 2000 fps.

A link, please?

Keith



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Merge of mesa-41 branch to trunk

[Brian Paul]

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 module?
It's only intended for X server modules.  It'd be better to not include
it in the first place.


I think because there is some sharing of source (radeon_regs.h is from the 2d 
driver).  It should be protected with a #ifdef, I guess.


I'd suggest moving those includes (and the INREG/OUTREG macros that
need them) to another place.  Those parts can't really be shared.


Right.  I'll take a stab at cleaning this up.

-Brian




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] full box lockup.

[Roman Stepanov]

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 about 2000
   fps.
 
  A link, please?
 
  Keith

 Loki Demos installer is here:
 ftp://ftp.planetmirror.com/pub/lokigames/updates/loki_demos/loki-demos-1.0e
-x86.run

Looks like I forgot one thing. You have to install loki-demos-1.0d-x86.run 
first, after that it will be automatically upgraded to 1.0e... I hate all 
this automatic installers so much...

-- 
WBR, Roman

http://www.svartalf.tk


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] drmOpen coding is incomplete

[Alexander Stohr]

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 DRI CVS code because sources there are identical.







xf86drm.c.cvs.patch
Description: Binary data

Re: [Dri-devel] drmOpen coding is incomplete

[Brian Paul]

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 because sources there are identical.


Thanks.  I've applied it to the DRI trunk and mesa-41 branch.

-Brian




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa-4-1-branch

[Brian Paul]

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 code.  I don't see how that could
be responsible for the server lock-ups that have been reported.

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?

-Brian



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] himem still causes lockup

[Michel Dänzer]

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 switching, 
 nothing.

FWIW, it works on this PowerBook with highmem (the only way to use all
of the 1 GB of RAM), so it seems to be an architecture specific problem.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa-4-1-branch

[Ian Romanick]

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 the mesa-41 work to get into
 XFree86 4.3.

For me, there are three things that would make for an idea 4.3 release
in terms of DRI:

1. Mesa 5.0
2. Back-port the cube map support from the R200 driver to the R100 driver.
   (it's been around the middle of my todo list since you announced its
   availability!)
3. Some of the smaller GLX versioning / extension changes that we've
   discussed.

At this point, I suspect that only 1 and part of 3 will happen. :(

-- 
Smile!  http://antwrp.gsfc.nasa.gov/apod/ap990315.html


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa-4-1-branch

[Michel Dänzer]

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 branch server
 code is in the indirect GLX rendering code.  I don't see how that could
 be responsible for the server lock-ups that have been reported.
 
 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.

My thoughts exactly, plus I'm waiting for the merge for the next version
of my Debian packages, so I vote for it to happen ASAP.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] crash gtk-demo

[Bruno CARBONARA]

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
Resource ID: 0xcb
Error serial: 8960
thanks



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Bug with secondary_color and radeon

[Ove Kaaven]

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 EXT_secondary_color: the radeon_SecondaryColor3ubEXT
function in radeon_vtxfmt_c.c dereferenced vb.specptr, which was a null
pointer, likely because lighting was enabled at the time or something.  
WineX calls glSecondaryColor3ubEXT(0,0,0); just in case when the game
doesn't provide any colors, so it would probably be ok to ignore the call
in this case, but crashing is no good. How should this be fixed?

PS: for fun, I disabled the secondary_color extension and tried to run it
again, and then the game works ran a bit on the slow side for some
reason (hope your performance work pays off), but things seemed to render
well otherwise. Good work.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Bug with secondary_color and radeon

[Ian Romanick]

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 backtrace, and tracked the problem to the current
 implementation of EXT_secondary_color: the radeon_SecondaryColor3ubEXT
 function in radeon_vtxfmt_c.c dereferenced vb.specptr, which was a null
 pointer, likely because lighting was enabled at the time or something.  
 WineX calls glSecondaryColor3ubEXT(0,0,0); just in case when the game
 doesn't provide any colors, so it would probably be ok to ignore the call
 in this case, but crashing is no good. How should this be fixed?

I'll take a look at this.

-- 
Smile!  http://antwrp.gsfc.nasa.gov/apod/ap990315.html


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa-4-1-branch

[Brian Paul]

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 the trunk and branch server
code is in the indirect GLX rendering code.  I don't see how that could
be responsible for the server lock-ups that have been reported.

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.



My thoughts exactly, plus I'm waiting for the merge for the next version
of my Debian packages, so I vote for it to happen ASAP.


OK, I'll tag the trunk with a pre-merge tag and start the merge soon.

Please hold off on committing changes to the DRI think for a while.

-Brian




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa-4-1-branch

[Brian Paul]

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 differences between the trunk and branch server
code is in the indirect GLX rendering code.  I don't see how that could
be responsible for the server lock-ups that have been reported.

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.




My thoughts exactly, plus I'm waiting for the merge for the next version
of my Debian packages, so I vote for it to happen ASAP.



OK, I'll tag the trunk with a pre-merge tag and start the merge soon.

Please hold off on committing changes to the DRI think for a while.


Err, DRI trunk.

-Brian




---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] full box lockup.

[Andreas Stenglein]

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 up, on my
computer its 2/3 the size of the screen.
then select OpenGL Spectrum Analyzer 1.2.5, press use plugin
- a second window with columns pops up, then a moment later -
one of these: a)app crashes, b)Xserver freezes, music keeps playing
you have to remote kill the app,
c)app crashes and Xserver freezes, you have to restart the Xserver,
but you wont get a vt when you shutdown the xserver!
d)whole box crashes, music plays in a loop: you have to reset,
a: most often b: sometimes c,d: less often

In my tests b,c,d only occured when starting things in
that order.. maybe I didnt try to hard.
I dont now if its necessary to play a song, but I think it helped
to trigger the worst cases c/d.

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

I think which caused the error-messages below was one
of type b or c

any suggestions?

regards,
Andreas


Am 2002.11.25 10:36:19 +0100 schrieb(en) Keith Whitwell:



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 
holds heavyweight lock

Can you remember how this happened?  This is a real bug  I'd like 
to track it down if possible.

Keith


---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] full box lockup.

[Jens Owen]

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 friend of mine reported something like this (haven't seen it myself).
For him, killing the DRI client(s) resumes normal operation. Can you
confirm that? If so, that's not an actual lockup.

I still can't really imagine what a 'heavyweight lock' is, can one of
the traditional developers explain?



It's really just the lock.  The locking process is two stage, with a 
cmpxcg in userspace which can handle the trivial case (if the same 
context wants to get  a lock and it was the last context to hold it) 
without kernel intervention.  If that fails, the process has to do an 
ioctl to get the lock.  This is where this message comes from -- maybe 
saying that '6' already has the lock it is asking for.

Michel,

If you want more technical information on the lock, check out:

http://dri.sourceforge.net/doc/hardware_locking_low_level.html

--
   /\
 Jens Owen/  \/\ _
  [EMAIL PROTECTED]  /\ \ \   Steamboat Springs, Colorado




---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon.o DRM modules breaks my CD player (!)

[matt . nottingham]

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 of
timeout, w.h.y.)

3) I've 512MB RAM - no swapping.

4) Not sure about IRQ's - it boots too fast for me to read it! Doing a
more /proc/interupts show the hda (the only disk) on IRQ 14, the CDROM
on 15. Looking at the output of lspci -vv shows that the video card is
on 16 but doesn't state what the IRQ is for the IDE controller (as a
cross check).

5) Options - none. In the BIOS (flashed to the most recent version -
1009 but had identical problems with 1004) its set to MP1.4

6) I'll try disabling DMA for the CDROM 

7) I have a PS/2 mouse plugged in - I'd seen that mentioned on the
linux kern mail list. (I'd love to know how someone found that cure!)

Thanks for the interest,

Matt




---
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power  Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] full box lockup.

[Ian Romanick]

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 secondary-color from
another thread in dri-devel.  Could you try editing radeon_context.c (or
r200_context.c, I don't remember which you're using) and remove the line:

   GL_EXT_secondary_color,
   
In radeon_context.c it should be around line 177.  Re-build and install
radeon_dri.so, and try your test again.  If that makes the problem go away,
then that will narrow things down quite a bit.

You could also start your app from an ssh connection with gdb.  If the app
faults in radeon_SecondaryColor*, that will also narrow things down.

-- 
Smile!  http://antwrp.gsfc.nasa.gov/apod/ap990315.html


---
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power  Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa-4-1-branch

[D. Hageman]

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 likely more people will 
try it.  In reality - more testing is the only way to ensure that it is 
golden and the more bug reports that are generated, the better the chances 
of narrowing down the issues involved (worse case scenerio there of course).  

-- 
//\\
||  D. Hageman[EMAIL PROTECTED]  ||
\\//


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa-4-1-branch

[Brian Paul]

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 size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] full box lockup.

[Andreas Stenglein]

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, 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
secondary-color from
another thread in dri-devel.  Could you try editing radeon_context.c
(or
r200_context.c, I don't remember which you're using) and remove the
line:

   GL_EXT_secondary_color,

In radeon_context.c it should be around line 177.  Re-build and
install
radeon_dri.so, and try your test again.  If that makes the problem
go away,
then that will narrow things down quite a bit.

You could also start your app from an ssh connection with gdb.  If
the app
faults in radeon_SecondaryColor*, that will also narrow things down.



---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] full box lockup.

[Andreas Stenglein]

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: it helped to kill the app, this time I was faster,
as my old computer was already switched on ;)
I got this error-messages:
1st: not available
2nd:
radeonEmitIrqLocked: drmRadeonIrqEmit: -22
and
cat /var/log/messages | grep Nov 25 | grep drm
shows: (commented)
Nov 25 18:19:47 buche kernel: [drm] AGP 0.99 on SiS @ 0xd000 128MB
Nov 25 18:19:47 buche kernel: [drm] Initialized radeon 1.7.0 20020828 
on minor 0
dont know what this was:
Nov 25 18:33:46 buche kernel: [drm:radeon_cp_cmdbuf] *ERROR* bad 
buffer
1st:
Nov 25 20:16:56 buche kernel: [drm:radeon_irq_emit] *ERROR* 
radeon_irq_emit called without lock held
Nov 25 20:16:56 buche kernel: [drm:radeon_lock_take] *ERROR* 6 holds 
heavyweight lock
2nd:
Nov 25 20:27:30 buche kernel: [drm:radeon_irq_emit] *ERROR* 
radeon_irq_emit called without lock held
Nov 25 20:27:30 buche kernel: [drm:radeon_lock_take] *ERROR* 12 holds 
heavyweight lock

And I noticed this:
If I move the LAVA-window partly outside the screen,
for example to get some more space on the desktop, and
then starting the other ogl-spectrum-plugin, I get the
xserver lockup/freeze.
If the lava-window is completely inside the screen,
only the application dies if I enable the ogl_spectrum-plugin,
for example with
xmms: radeon_vtxfmt.c:325: copy_dma_verts: Zusicherung »0« nicht 
erfüllt.
(english: assertion)
I have to check this a few times more...

any suggestions?
If not, Im going to try it out with todays cvs-mesa-4-1-branch.

regards,
Andreas

ps: XFree86 4.3.0: with Mesa 5 would be good.

Am 2002.11.25 19:26:20 +0100 schrieb(en) Ian Romanick:

This makes me wonder if it /might/ be releated to the
secondary-color from
another thread in dri-devel.  Could you try editing radeon_context.c
(or
r200_context.c, I don't remember which you're using) and remove the
line:

   GL_EXT_secondary_color,

In radeon_context.c it should be around line 177.  Re-build and
install
radeon_dri.so, and try your test again.  If that makes the problem
go away,
then that will narrow things down quite a bit.

You could also start your app from an ssh connection with gdb.  If
the app
faults in radeon_SecondaryColor*, that will also narrow things down.



---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] mesa-4-1-branch

[Brian Paul]

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 Tungsten T 
handheld. Power  Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Weekly dri-devel meeting reminder

[Ian Romanick]

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


---
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power  Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] full box lockup.

[Andreas Stenglein]

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 then init 3, init 5, a
switch to vt 1 for example locked up the whole machine
- reboot


app dieing:
[New Thread 4101 (LWP 4692)]
Delayed SIGSTOP caught for LWP 4692.
xmms: radeon_vtxfmt.c:325: copy_dma_verts: Zusicherung »0« nicht
erfüllt.

Program received signal SIGABRT, Aborted.
0x4032e861 in kill () from /lib/libc.so.6
(gdb) back
#0  0x4032e861 in kill () from /lib/libc.so.6
#1  0x40033acc in pthread_kill () from /lib/libpthread.so.0
#2  0x40033fd6 in raise () from /lib/libpthread.so.0
#3  0x4032fc81 in abort () from /lib/libc.so.6
#4  0x40328a52 in Letext () from /lib/libc.so.6
#5  0x41c1e6a9 in copy_dma_verts (rmesa=0x84505c0, tmp=0xbf3ff950) at
radeon_vtxfmt.c:325
#6  0x41c1eca1 in wrap_buffer () at radeon_vtxfmt.c:488
#7  0x40f4f675 in _ts_Vertex3f (x=-0.328125, y=0, z=0.34375) at
../../../extras/Mesa/src/glapitemp.h:733
#8  0x41432045 in draw_gl () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#9  0x41430e4b in draw_thread_loop () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#10 0x40030f37 in pthread_start_thread () from /lib/libpthread.so.0
#11 0x40030f8e in pthread_start_thread_event () from
/lib/libpthread.so.0
(gdb) quit


xserver freeze:
[New Thread 4101 (LWP 4710)]
Delayed SIGSTOP caught for LWP 4710.
xmms: radeon_vtxfmt.c:325: copy_dma_verts: Zusicherung »0« nicht
erfüllt.

Program received signal SIGABRT, Aborted.
0x4032e861 in kill () from /lib/libc.so.6
(gdb) back
#0  0x4032e861 in kill () from /lib/libc.so.6
#1  0x40033acc in pthread_kill () from /lib/libpthread.so.0
#2  0x40033fd6 in raise () from /lib/libpthread.so.0
#3  0x4032fc81 in abort () from /lib/libc.so.6
#4  0x40328a52 in Letext () from /lib/libc.so.6
#5  0x41c1e6a9 in copy_dma_verts (rmesa=0x842d810, tmp=0xbf3ff950) at
radeon_vtxfmt.c:325
#6  0x41c1eca1 in wrap_buffer () at radeon_vtxfmt.c:488
#7  0x40f4f675 in _ts_Vertex3f (x=-0.296875, y=0, z=-0.015625) at
../../../extras/Mesa/src/glapitemp.h:733
#8  0x41432045 in draw_gl () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#9  0x41430e4b in draw_thread_loop () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#10 0x40030f37 in pthread_start_thread () from /lib/libpthread.so.0
#11 0x40030f8e in pthread_start_thread_event () from
/lib/libpthread.so.0
(gdb) quit
The program is running.  Exit anyway? (y or n) y




---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] full box lockup.

[Brian Paul]

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 xserver
with killall -KILL X and then init 3, init 5, a
switch to vt 1 for example locked up the whole machine
- reboot


app dieing:
[New Thread 4101 (LWP 4692)]
Delayed SIGSTOP caught for LWP 4692.
xmms: radeon_vtxfmt.c:325: copy_dma_verts: Zusicherung »0« nicht
erfüllt.

Program received signal SIGABRT, Aborted.
0x4032e861 in kill () from /lib/libc.so.6
(gdb) back
#0  0x4032e861 in kill () from /lib/libc.so.6
#1  0x40033acc in pthread_kill () from /lib/libpthread.so.0
#2  0x40033fd6 in raise () from /lib/libpthread.so.0
#3  0x4032fc81 in abort () from /lib/libc.so.6
#4  0x40328a52 in Letext () from /lib/libc.so.6
#5  0x41c1e6a9 in copy_dma_verts (rmesa=0x84505c0, tmp=0xbf3ff950) at
radeon_vtxfmt.c:325
#6  0x41c1eca1 in wrap_buffer () at radeon_vtxfmt.c:488
#7  0x40f4f675 in _ts_Vertex3f (x=-0.328125, y=0, z=0.34375) at
../../../extras/Mesa/src/glapitemp.h:733
#8  0x41432045 in draw_gl () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#9  0x41430e4b in draw_thread_loop () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#10 0x40030f37 in pthread_start_thread () from /lib/libpthread.so.0
#11 0x40030f8e in pthread_start_thread_event () from
/lib/libpthread.so.0
(gdb) quit


xserver freeze:
[New Thread 4101 (LWP 4710)]
Delayed SIGSTOP caught for LWP 4710.
xmms: radeon_vtxfmt.c:325: copy_dma_verts: Zusicherung »0« nicht
erfüllt.

Program received signal SIGABRT, Aborted.
0x4032e861 in kill () from /lib/libc.so.6
(gdb) back
#0  0x4032e861 in kill () from /lib/libc.so.6
#1  0x40033acc in pthread_kill () from /lib/libpthread.so.0
#2  0x40033fd6 in raise () from /lib/libpthread.so.0
#3  0x4032fc81 in abort () from /lib/libc.so.6
#4  0x40328a52 in Letext () from /lib/libc.so.6
#5  0x41c1e6a9 in copy_dma_verts (rmesa=0x842d810, tmp=0xbf3ff950) at
radeon_vtxfmt.c:325
#6  0x41c1eca1 in wrap_buffer () at radeon_vtxfmt.c:488
#7  0x40f4f675 in _ts_Vertex3f (x=-0.296875, y=0, z=-0.015625) at
../../../extras/Mesa/src/glapitemp.h:733
#8  0x41432045 in draw_gl () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#9  0x41430e4b in draw_thread_loop () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#10 0x40030f37 in pthread_start_thread () from /lib/libpthread.so.0
#11 0x40030f8e in pthread_start_thread_event () from
/lib/libpthread.so.0
(gdb) quit
The program is running.  Exit anyway? (y or n) y


Could you try editing xc/lib/GL/mesa/src/drv/radeon/radeon_vtxfmt.c
and remove or comment-out the assertion at line 325?

-Brian




---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] himem still causes lockup

[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 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.
 
 FWIW, it works on this PowerBook with highmem (the only way to use all
 of the 1 GB of RAM), so it seems to be an architecture specific problem.

Ok.  So it works for some, and not for others.  What might I do to help track 
this down?  Given the behavior (complete lockup), I'm not sure anything will 
even get written to the logs.  (I suppose serial console might be worth a 
shot to get the oops msg if that's the case).  It seems as if interrupts are 
hopelessly blocked, so magic sysrq is not helpful, and any other output would 
also not see the light of day...

Is there perhaps some other kernel options that conflict with himem that I 
may have set?  I've seen mention of apic issues lately, but as I understand 
it that is required on smp systems.  I suppose I could boot into up w/apic 
disabled, would that help?


Nick



---
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power  Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] radeon_ioctl.c: INREG() usage

[Brian Paul]

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 used if the kernel module is too old to support the RADEON_LAST_-
CLEAR/FRAME queries.

It would be nice if those two instances of INREG() could be removed.

I suppose we need to keep them for the sake of users of older radeon.o
kernel modules.  Is there more to it than that?

-Brian



---
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power  Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon_ioctl.c: INREG() usage

[Michel Dänzer]

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 check-in of Tim Smith's changes).  INREG is probably
 only used if the kernel module is too old to support the RADEON_LAST_-
 CLEAR/FRAME queries.
 
 It would be nice if those two instances of INREG() could be removed.
 
 I suppose we need to keep them for the sake of users of older radeon.o
 kernel modules.  Is there more to it than that?

I don't see any other reason, the registers are only read directly if
there's a problem with the ioctl. I know Eric used to frown at the idea
of using an ioctl to get a register value though. :)


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast


---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon_ioctl.c: INREG() usage

[Brian Paul]

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 the 11 July check-in of Tim Smith's changes).  INREG is probably
only used if the kernel module is too old to support the RADEON_LAST_-
CLEAR/FRAME queries.

It would be nice if those two instances of INREG() could be removed.

I suppose we need to keep them for the sake of users of older radeon.o
kernel modules.  Is there more to it than that?



I don't see any other reason, the registers are only read directly if
there's a problem with the ioctl. I know Eric used to frown at the idea
of using an ioctl to get a register value though. :)


This is (apparently) the only place in the whole driver where we directly
access a hardware register.  It's the only reason we need to drag in
the (new) radeon_macros.h file, which in turn pulls in a number of other
server-side XFree86 headers.  It would be nice to eliminate that.

In the r200 driver we print an error and exit if the drmCommandWriteRead()
fails.  I think that should never happen if the kernel module is new enough
to support the query.  I don't know the radeon.o version number which
corresponded to the introduction of the RADEON_LAST_CLEAR/FRAME query.

-Brian



---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] himem still causes lockup

[Dieter Nützel]

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 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.

Does gears, isosurf (default) run?
But isosurf (reflect), ipers, texdown etc (with textures/light) hang your 
machine?

Mine dual Athlon with HIGHMEM and r200 does.
Read the threads about mesa-4-1.

I'll try my current 2.5.47-mm1 kernel without HIGHMEM, too.

  FWIW, it works on this PowerBook with highmem (the only way to use all
  of the 1 GB of RAM), so it seems to be an architecture specific problem.

 Ok.  So it works for some, and not for others.  What might I do to help
 track this down?  Given the behavior (complete lockup), I'm not sure
 anything will even get written to the logs.  (I suppose serial console
 might be worth a shot to get the oops msg if that's the case).  It seems as
 if interrupts are hopelessly blocked, so magic sysrq is not helpful, and
 any other output would also not see the light of day...

 Is there perhaps some other kernel options that conflict with himem that I
 may have set?  I've seen mention of apic issues lately, but as I understand
 it that is required on smp systems.  I suppose I could boot into up w/apic
 disabled, would that help?

APIC didn't change anything for me.

-Dieter


---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon_ioctl.c: INREG() usage

[David Dawes]

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 have been superceeded by drmCommandWriteRead() calls
(since the 11 July check-in of Tim Smith's changes).  INREG is probably
only used if the kernel module is too old to support the RADEON_LAST_-
CLEAR/FRAME queries.

It would be nice if those two instances of INREG() could be removed.

I suppose we need to keep them for the sake of users of older radeon.o
kernel modules.  Is there more to it than that?
 
 
 I don't see any other reason, the registers are only read directly if
 there's a problem with the ioctl. I know Eric used to frown at the idea
 of using an ioctl to get a register value though. :)

This is (apparently) the only place in the whole driver where we directly
access a hardware register.  It's the only reason we need to drag in
the (new) radeon_macros.h file, which in turn pulls in a number of other
server-side XFree86 headers.  It would be nice to eliminate that.

If that does prove necessary (and compatibility is a valid reason),
then the next best thing is to use something like the following in
radeon_macros.h:

#ifdef XFree86Module
#include xf86_ansic.h
#endif
#include compiler.h

It's mostly OK to use compiler.h outside of the X server, but
xf86_ansic.h shouldn't be.

In the r200 driver we print an error and exit if the drmCommandWriteRead()
fails.  I think that should never happen if the kernel module is new enough
to support the query.  I don't know the radeon.o version number which
corresponded to the introduction of the RADEON_LAST_CLEAR/FRAME query.

Which ever solution works out best should be applied to the r128 driver
too.

David


---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon.o DRM modules breaks my CD player (!)

[Dieter Nützel]

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 try to burn CD's at x20 it falls over very quickly
  (about 12MBytes).  Burning them at x8 at least gives me a chance of
  backing things up but it wasn't perfect.
 
  2) Whenever heavy disk IO (for example when Debian reads its package
  database) is performed the whole of X hangs for tens of seconds, but
  things like alsaplayer keep playing (and don't skip a beat).
 
  Anyway, I finally got fed up of this as I was sure it didn't use
  to be this bad - so I decided to investigate.
 
  I was currently using 2.4.20-rc2-ac3 + ALSA + CVS DRI. I went back to
  the old installation of 2.4.19-pre5-ac3 and everything works fine (this
  also had ALSA and CVS DRI from about May). I then updated ALSA  DRI
  to current, and it was back to its old bad behaviour. So I tried
  2.4.20-rc3 with the radeon.o DRM module it comes with (+ the ALSA
  drivers) and everything works fine (well, apart from DRI!). Stopping
  X, unloading the DRM module, insert the latest CVS version and start up X
  again and we are back to not being able to write CD's again.
 
  Any comments/ideas?

 I'm having problems burning CDs at speeds higher than 16x too. But
 disabling DRI (no radeon.o module loaded) didn't change that.

I'm never had any such problems on my MSI K7D Master-L, aka MS-6501, AMD 768 
MPX dual Athlon MP 1900+, 1 GB DDR-SDRAM 266 CL2, Radeon 8500 QL system.
PS/2 mouse is plugged in but maybe it is due that I have all SCSI?
Kernel 2.4.xx (2.4.19-ck, -AA VM, preemption etc) and 2.5.xx (2.5.47-mm1 
latest) running fine apart from latest mesa-4-1 branch.

Search DRI-devel for ealier post about my system.

-Dieter


---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon_ioctl.c: INREG() usage

[Michel Dänzer]

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 been superceeded by drmCommandWriteRead() calls
 (since the 11 July check-in of Tim Smith's changes).  INREG is probably
 only used if the kernel module is too old to support the RADEON_LAST_-
 CLEAR/FRAME queries.
 
 It would be nice if those two instances of INREG() could be removed.
 
 I suppose we need to keep them for the sake of users of older radeon.o
 kernel modules.  Is there more to it than that?
  
  
  I don't see any other reason, the registers are only read directly if
  there's a problem with the ioctl. I know Eric used to frown at the idea
  of using an ioctl to get a register value though. :)
 
 This is (apparently) the only place in the whole driver where we directly
 access a hardware register.  It's the only reason we need to drag in
 the (new) radeon_macros.h file,

... and map the MMIO aperture.

 which in turn pulls in a number of other server-side XFree86 headers.
 It would be nice to eliminate that.
 
 In the r200 driver we print an error and exit if the drmCommandWriteRead()
 fails.  I think that should never happen if the kernel module is new enough
 to support the query.  I don't know the radeon.o version number which
 corresponded to the introduction of the RADEON_LAST_CLEAR/FRAME query.

From the code:

  if (rmesa-dri.screen-drmMinor = 4) {

The r200 driver needs not worry because there was no r200 support before
IIRC. The question is if we want to keep compatibility with older DRMs
in the r100 driver, as it seems to be broken right now.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast


---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Slow gears and compile time

[Dieter Nützel]

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 MesaDemos-5.0 from the Mesa-Home.
There is a copy of gears included, too.
Make sure that the demo progs use the system's libGL (hardware accelerated) 
and not the new MesaLib-5.0 one's.

Testing with setenv SSTV5_GLIDE_SWAPINTERVAL 0 (tcsh shell) or export 
SSTV5_GLIDE_SWAPINTERVAL=0 (bash shell). Maybe it should be SST5_xxx don't 
sure anymore. But FX_xxx is for older cards.

 Now make World (DRI CVS) takes 100 minutes, with SuSE 8.0 it took 64
 minutes (gcc 2.95.3). Can I speed up the compile time under SuSE 8.1?
 Dieter? My machine is a PII 333.

Sorry, I don't think so.
SuSE 8.1 is GCC-3.2 based and newer GCCs are slower...

How much RAM do you have?
Kernel is SuSE current?

-Dieter


---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] himem still causes lockup

[Nicholas Leippe]

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 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.
 
 Does gears, isosurf (default) run?
 But isosurf (reflect), ipers, texdown etc (with textures/light) hang your 
 machine?

Okay, it gets even better.  I booted into my himem kernel.  gears and all of 
the rss screensavers that I tried worked, but when I ran quake3 it 
spontaneously rebooted.  Fun, fun, fun!

So I guess I'll just miss out on that 100MB or so for now...


Nick


---
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power  Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] full box lockup.

[Keith Whitwell]

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 restoring the xserver
with killall -KILL X and then init 3, init 5, a
switch to vt 1 for example locked up the whole machine
- reboot


app dieing:
[New Thread 4101 (LWP 4692)]
Delayed SIGSTOP caught for LWP 4692.
xmms: radeon_vtxfmt.c:325: copy_dma_verts: Zusicherung »0« nicht
erfüllt.

Program received signal SIGABRT, Aborted.
0x4032e861 in kill () from /lib/libc.so.6
(gdb) back
#0  0x4032e861 in kill () from /lib/libc.so.6
#1  0x40033acc in pthread_kill () from /lib/libpthread.so.0
#2  0x40033fd6 in raise () from /lib/libpthread.so.0
#3  0x4032fc81 in abort () from /lib/libc.so.6
#4  0x40328a52 in Letext () from /lib/libc.so.6
#5  0x41c1e6a9 in copy_dma_verts (rmesa=0x84505c0, tmp=0xbf3ff950) at
radeon_vtxfmt.c:325
#6  0x41c1eca1 in wrap_buffer () at radeon_vtxfmt.c:488
#7  0x40f4f675 in _ts_Vertex3f (x=-0.328125, y=0, z=0.34375) at
../../../extras/Mesa/src/glapitemp.h:733
#8  0x41432045 in draw_gl () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#9  0x41430e4b in draw_thread_loop () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#10 0x40030f37 in pthread_start_thread () from /lib/libpthread.so.0
#11 0x40030f8e in pthread_start_thread_event () from
/lib/libpthread.so.0
(gdb) quit


xserver freeze:
[New Thread 4101 (LWP 4710)]
Delayed SIGSTOP caught for LWP 4710.
xmms: radeon_vtxfmt.c:325: copy_dma_verts: Zusicherung »0« nicht
erfüllt.

Program received signal SIGABRT, Aborted.
0x4032e861 in kill () from /lib/libc.so.6
(gdb) back
#0  0x4032e861 in kill () from /lib/libc.so.6
#1  0x40033acc in pthread_kill () from /lib/libpthread.so.0
#2  0x40033fd6 in raise () from /lib/libpthread.so.0
#3  0x4032fc81 in abort () from /lib/libc.so.6
#4  0x40328a52 in Letext () from /lib/libc.so.6
#5  0x41c1e6a9 in copy_dma_verts (rmesa=0x842d810, tmp=0xbf3ff950) at
radeon_vtxfmt.c:325
#6  0x41c1eca1 in wrap_buffer () at radeon_vtxfmt.c:488
#7  0x40f4f675 in _ts_Vertex3f (x=-0.296875, y=0, z=-0.015625) at
../../../extras/Mesa/src/glapitemp.h:733
#8  0x41432045 in draw_gl () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#9  0x41430e4b in draw_thread_loop () from
/usr/X11R6/lib/xmms/Visualization/liblava.so
#10 0x40030f37 in pthread_start_thread () from /lib/libpthread.so.0
#11 0x40030f8e in pthread_start_thread_event () from
/lib/libpthread.so.0
(gdb) quit
The program is running.  Exit anyway? (y or n) y



Could you try editing xc/lib/GL/mesa/src/drv/radeon/radeon_vtxfmt.c
and remove or comment-out the assertion at line 325?


It looks like the problem is occuring when the buffer wraps on a vertex 
emitted outside a begin/end pair.

I've attached a patch that deals with a couple of problems when this happens. 
 Can you give that a go?

Keith
Warning: Remote host denied X11 forwarding.
Index: radeon_vtxfmt.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_vtxfmt.c,v
retrieving revision 1.5
diff -u -r1.5 radeon_vtxfmt.c
--- radeon_vtxfmt.c 5 Nov 2002 21:19:52 -   1.5
+++ radeon_vtxfmt.c 26 Nov 2002 00:01:00 -
@@ -485,15 +485,21 @@
 
/* Copy vertices out of dma:
 */
-   nrverts = copy_dma_verts( rmesa, tmp );
+   if (rmesa-vb.prim[0] == GL_POLYGON+1) 
+  nrverts = 0;
+   else {
+  nrverts = copy_dma_verts( rmesa, tmp );
 
-   if (RADEON_DEBUG  DEBUG_VFMT)
-  fprintf(stderr, %d vertices to copy\n, nrverts);
+  if (RADEON_DEBUG  DEBUG_VFMT)
+fprintf(stderr, %d vertices to copy\n, nrverts);

+  /* Finish the prim at this point:
+   */
+  note_last_prim( rmesa, 0 );
+   }
 
-   /* Finish the prim at this point:
+   /* Fire any buffered primitives
 */
-   note_last_prim( rmesa, 0 );
flush_prims( rmesa );
 
/* Get new buffer
@@ -510,8 +516,11 @@
vb.notify = wrap_buffer;
 
rmesa-dma.flush = flush_prims;
-   start_prim( rmesa, rmesa-vb.prim[0] );
 
+   /* Restart wrapped primitive:
+*/
+   if (rmesa-vb.prim[0] != GL_POLYGON+1)
+  start_prim( rmesa, rmesa-vb.prim[0] );
 
/* Reemit saved vertices
 */

Re: [Dri-devel] radeon_ioctl.c: INREG() usage

[Keith Whitwell]

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 drmCommandWriteRead() calls
(since the 11 July check-in of Tim Smith's changes).  INREG is probably
only used if the kernel module is too old to support the RADEON_LAST_-
CLEAR/FRAME queries.

It would be nice if those two instances of INREG() could be removed.

I suppose we need to keep them for the sake of users of older radeon.o
kernel modules.  Is there more to it than that?



I don't see any other reason, the registers are only read directly if
there's a problem with the ioctl. I know Eric used to frown at the idea
of using an ioctl to get a register value though. :)



This is (apparently) the only place in the whole driver where we directly
access a hardware register.  It's the only reason we need to drag in
the (new) radeon_macros.h file, which in turn pulls in a number of other
server-side XFree86 headers.  It would be nice to eliminate that.


The only way you can eliminate it is if you opt to forgo client-side 
throttling on old kernel modules.

At the moment the radeon driver is broken with old kernel modules anyway, but 
that should be fixed presently.

In the r200 driver we print an error and exit if the drmCommandWriteRead()
fails.  I think that should never happen if the kernel module is new enough
to support the query.  I don't know the radeon.o version number which
corresponded to the introduction of the RADEON_LAST_CLEAR/FRAME query.


The query was added *before* r200 support was added to the kernel, so there's 
never a case where an r200 can be running with a kernel module that doesn't 
support the query.

Keith



---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon_ioctl.c: INREG() usage

[Keith Whitwell]

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 the 11 July check-in of Tim Smith's changes).  INREG is probably
only used if the kernel module is too old to support the RADEON_LAST_-
CLEAR/FRAME queries.

It would be nice if those two instances of INREG() could be removed.

I suppose we need to keep them for the sake of users of older radeon.o
kernel modules.  Is there more to it than that?



I don't see any other reason, the registers are only read directly if
there's a problem with the ioctl. I know Eric used to frown at the idea
of using an ioctl to get a register value though. :)


It's not even that:  We're using an ioctl to read a value *in main memory*... 
 If we were smart it would be in a shared page accessible from userspace...

Keith



---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] full box lockup.

[Dieter Nützel]

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] *ERROR* 6 holds
 heavyweight lock
 
  A friend of mine reported something like this (haven't seen it myself).
  For him, killing the DRI client(s) resumes normal operation. Can you
  confirm that? If so, that's not an actual lockup.

I had such messages (trunk and r200 branch) but they are gone for some weeks, 
now.

  I still can't really imagine what a 'heavyweight lock' is, can one of
  the traditional developers explain?

 It's really just the lock.  The locking process is two stage, with a cmpxcg
 in userspace which can handle the trivial case (if the same context wants
 to get a lock and it was the last context to hold it) without kernel
 intervention. If that fails, the process has to do an ioctl to get the
 lock.  This is where this message comes from -- maybe saying that '6'
 already has the lock it is asking for.

Below are lastet error messages before lockup with r200 on mesa-4-1.
Kernel is 2.5.47-mm1 radeon.o show 1.6.0 (backup path, not latest DRI stuff).

Nov 23 21:59:21 SunWave1 kernel: [drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 
at 080516ec

Nov 23 22:06:24 SunWave1 kernel: [drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 
at 081025ac

Nov 24 02:57:46 SunWave1 kernel: [drm:radeon_cp_cmdbuf] *ERROR* bad cmd_type 0 
at 08055880

-Dieter


---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] radeon_ioctl.c: INREG() usage

[Michel Dänzer]

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 have been superceeded by drmCommandWriteRead() calls
 (since the 11 July check-in of Tim Smith's changes).  INREG is probably
 only used if the kernel module is too old to support the RADEON_LAST_-
 CLEAR/FRAME queries.
 
 It would be nice if those two instances of INREG() could be removed.
 
 I suppose we need to keep them for the sake of users of older radeon.o
 kernel modules.  Is there more to it than that?
  
  
  I don't see any other reason, the registers are only read directly if
  there's a problem with the ioctl. I know Eric used to frown at the idea
  of using an ioctl to get a register value though. :)
 
 It's not even that:  We're using an ioctl to read a value *in main memory*... 
   If we were smart it would be in a shared page accessible from userspace...

Couldn't we map that page read only in clients? (instead of MMIO)


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast


---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Merge of mesa-41 branch to trunk

[Dieter Nützel]

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 branch may
 have a problem too.  If you've got both trunk and mesa-41 branches
 on your system.  Try using LIBGL_DRIVERS_PATH to switch between
 the trunk r200_dri.so and mesa-41 r200_dri.so to compare them.

 I'll do a comparison of the trunk and mesa-41 r200 drivers to
 see if I missed anything.

Mesa-4.1-branch (23.11.2002) locks up with isosurf (reflect), ipers, etc.
Not a hard lockup in the first place. I can hear some noise from my power 
supply or maybe the switching transistors of my mainboard which indicates 
that both CPUs are working heavily...;-)

SYSRQ+K or +B do NOT work and the noise calm after pressing any key.
= REBOOT needed
 
After I had all running well with r200_dri.so from the trunk I got this with 
the mesa-4-1-branch's r200_dri.so module:

Mesa/demos ./ipers 
[1] 2659
Mesa/demos IperS V1.0
Written by David Bucciarelli ([EMAIL PROTECTED])
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)
drmOpenByBusid: busid is PCI:1:5:0
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports PCI:1:5:0
MMX cpu detected.
3DNow! cpu detected.
Testing OS support for SSE... yes.
Testing OS support for SSE unmasked exceptions... SIGFPE, yes.
Tests of OS support for SSE passed.
SSE cpu detected.
drmCommandWrite: -22
drmRadeonCmdBuffer: -22 (exiting)

[1]Exitcode 234  ./ipers

[drm:radeon_cp_cmdbuf] *ERROR* radeon_emit_packets failed


isourf with default, no light, reflect

Mesa/demos ./isosurf 
[1] 2681
Mesa/demos 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)
drmOpenByBusid: busid is PCI:1:5:0
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports PCI:1:5:0
MMX cpu detected.
3DNow! cpu detected.
Testing OS support for SSE... yes.
Testing OS support for SSE unmasked exceptions... SIGFPE, yes.
Tests of OS support for SSE passed.
SSE cpu detected.
Nr unique vertex/normal pairs: 2723
num_tri_verts: 21531
primitive (0x1): GL_TRIANGLE_STRIP,
render style (0x20): glVertex,
enabling normal arrays
new flags (0x8a92c29): glVertex, GL_TRIANGLE_STRIP, lit,
r200_makeX86Normal3fv/196 CVAL 0 OFFSET 14 VAL 40661960
r200_makeX86Normal3fv/197 CVAL 4 OFFSET 20 VAL 40661964
r200_makeX86Normal3fv/198 CVAL 8 OFFSET 25 VAL 40661968
r200_makeX86Normal3fv done
Benchmarking...
Result:  triangles/sec: 8.00092e+06  fps: 1114.8
new flags (0x8a92c2a): glVertex, GL_TRIANGLE_STRIP, unlit,
r200_makeX86Normal3fv/196 CVAL 0 OFFSET 14 VAL 81ae4a0
r200_makeX86Normal3fv/197 CVAL 4 OFFSET 20 VAL 81ae4a4
r200_makeX86Normal3fv/198 CVAL 8 OFFSET 25 VAL 81ae4a8
r200_makeX86Normal3fv done
Benchmarking...
Result:  triangles/sec: 9.40618e+06  fps: 1310.6
new flags (0x8a92c29): glVertex, GL_TRIANGLE_STRIP, lit,
Benchmarking...
Result:  triangles/sec: 7.99948e+06  fps: 1114.6
new flags (0x8a92c2c): glVertex, GL_TRIANGLE_STRIP, reflect,
drmCommandWrite: -22
drmRadeonCmdBuffer: -22 (exiting)

[1]Exitcode 234  ./isosurf

[drm:radeon_cp_cmdbuf] *ERROR* radeon_emit_packets failed

-Dieter


---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Anyone ever tried to rrmod radeon.o and then restart X, again?

[Dieter Ntzel]

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 (!) without seeing it
* Alt+F7 first graphics screen with mouse but nothing else working

All branches so far.

Initialization problem?

Regards,
Dieter


---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Anyone ever tried to rrmod radeon.o and then restart X, again?

[Nicholas Leippe]

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 
or
anything else but the command line works (!) without seeing it
 * Alt+F7 first graphics screen with mouse but nothing else working
 
 All branches so far.
 
 Initialization problem?
 

I haven't tried recently, but fwiw have never had a problem in the past doing:
(from konsole:)
cvs update, make World, etc.
kde logout (exit X)
make install
cp path to/radeon.o /lib/modules/...etc.../char/radeon.o
rmmod radeon
depmod -a
startx


I have also rmmod'd radeon w/o changing it and restarted X w/o any probs 
before as well.


Nick


---
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power  Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Introductory Gourmet Coffee and Gift for dri-devel

[Eldon Babyak]

  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îž-ztájwazWO£«
‰h®)Úr‰©iËl‹7¡¶Úý§l²‹«qç讧zß܂&âŸúÞv*ÞrÚe¥©fÓM6zpë‰×¯zYšŠX§‚X¬´:âuëޖX¬¶Ë(º·~Šàzw­†Ûi³ÿåŠËl²‹«qç讧zßåŠËlþX¬¶)ߣ÷k‰×¯z

Re: [Dri-devel] radeon_ioctl.c: INREG() usage

[Brian Paul]

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 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 used if the kernel module is too old to support the RADEON_LAST_-
CLEAR/FRAME queries.

It would be nice if those two instances of INREG() could be removed.

I suppose we need to keep them for the sake of users of older radeon.o
kernel modules.  Is there more to it than that?



I don't see any other reason, the registers are only read directly if
there's a problem with the ioctl. I know Eric used to frown at the idea
of using an ioctl to get a register value though. :)


This is (apparently) the only place in the whole driver where we directly
access a hardware register.  It's the only reason we need to drag in
the (new) radeon_macros.h file, which in turn pulls in a number of other
server-side XFree86 headers.  It would be nice to eliminate that.



If that does prove necessary (and compatibility is a valid reason),
then the next best thing is to use something like the following in
radeon_macros.h:

#ifdef XFree86Module
#include xf86_ansic.h
#endif
#include compiler.h


That looks good.



It's mostly OK to use compiler.h outside of the X server, but
xf86_ansic.h shouldn't be.



In the r200 driver we print an error and exit if the drmCommandWriteRead()
fails.  I think that should never happen if the kernel module is new enough
to support the query.  I don't know the radeon.o version number which
corresponded to the introduction of the RADEON_LAST_CLEAR/FRAME query.



Which ever solution works out best should be applied to the r128 driver
too.


Done.

-Brian




---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] trunk: after merge with mesa-4-1

[Dieter Ntzel]

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)
drmOpenByBusid: busid is PCI:1:5:0
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports PCI:1:5:0
MMX cpu detected.
3DNow! cpu detected.
Testing OS support for SSE... yes.
Testing OS support for SSE unmasked exceptions... SIGFPE, yes.
Tests of OS support for SSE passed.
SSE cpu detected.
Nr unique vertex/normal pairs: 2723
num_tri_verts: 21531
primitive (0x1): GL_TRIANGLE_STRIP,
render style (0x20): glVertex,
enabling normal arrays
new flags (0x8a92c29): glVertex, GL_TRIANGLE_STRIP, lit,
new flags (0x8a92c2c): glVertex, GL_TRIANGLE_STRIP, reflect,
drmCommandWrite: -22
drmRadeonCmdBuffer: -22 (exiting)

Mesa/demos ./ipers
IperS V1.0
Written by David Bucciarelli ([EMAIL PROTECTED])
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)
drmOpenByBusid: busid is PCI:1:5:0
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports PCI:1:5:0
MMX cpu detected.
3DNow! cpu detected.
Testing OS support for SSE... yes.
Testing OS support for SSE unmasked exceptions... SIGFPE, yes.
Tests of OS support for SSE passed.
SSE cpu detected.
drmCommandWrite: -22
drmRadeonCmdBuffer: -22 (exiting)

[drm:radeon_cp_cmdbuf] *ERROR* radeon_emit_packets failed
[drm:radeon_cp_cmdbuf] *ERROR* radeon_emit_packets failed

-Dieter


---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel