[Bug 7128] Radeon R300 lockup on 2 clients accessing XV

2007-01-15 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=7128  
 




--- Additional Comments From [EMAIL PROTECTED]  2007-01-15 02:43 ---
I had a hangup some minutes ago:

Jan 15 11:29:38 localhost kernel: [ 7907.609190] [drm:radeon_cp_idle] *ERROR*
radeon_cp_idle called without lock held
Jan 15 11:29:38 localhost kernel: [ 7907.621161] [drm:radeon_cp_reset] *ERROR*
radeon_cp_reset called without lock held
Jan 15 11:29:38 localhost kernel: [ 7907.621175] [drm:radeon_cp_start] *ERROR*
radeon_cp_start called without lock held
Jan 15 11:29:38 localhost kernel: [ 7907.621187] [drm:radeon_cp_idle] *ERROR*
radeon_cp_idle called without lock held
Jan 15 11:29:38 localhost kernel: [ 7907.633176] [drm:radeon_cp_reset] *ERROR*
radeon_cp_reset called without lock held
Jan 15 11:29:38 localhost kernel: [ 7907.633191] [drm:radeon_cp_start] *ERROR*
radeon_cp_start called without lock held

I reckon it was gnash trying to display something.

If I can supply you with more information, let me know.  
 
 
--   
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email 
 
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 9641] lack of textures in Heroes Of Might And Magic V

2007-01-15 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=9641  
 

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-01-13 16:01 ---
You were right, after installing libtxc_dxtn060508 Heroes Of Might And Magic V
demo works correctly with DRI on Radeon X550.  
 
 
--   
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email 
 
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Radeon 7000 and DRI = freeze. Bug?

2007-01-15 Thread Marcos mjs
Hi,

I have the Xorg V.7.1.1 on my linux. When I will enable the DRI the screen 
freezy on start of X.

In the X log the error that I found is: reseting engine. It's repeat without 
stop.

Hardware:

AMD 64 Sempron
ATI Radeon 7000
MoBo A7V8X

Dates:

Kernel: 2.6.17-10-386
Modules: 
radeon117920  0 
drm72468  1 radeon
ati_agp 9612  0 
amd64_agp  12228  1 
agpgart33456  3 ati_agp,drm,amd64_agp

This is the last part of log:

  956 (==) RADEON(0): Not using accelerated EXA DownloadFromScreen hook
  957 (II) RADEON(0): Allocating from a screen of 65536 kb
  958 (II) RADEON(0): Will use 5120 kb for front buffer at offset 0x
  959 (II) RADEON(0): Will use 16 kb for hardware cursor at offset 0x0050
  960 (II) RADEON(0): Will use 5120 kb for back buffer at offset 0x00504000
  961 (II) RADEON(0): Will use 5120 kb for depth buffer at offset 0x00a04000
  962 (II) RADEON(0): Will use 24832 kb for textures at offset 0x00f04000
  963 (II) RADEON(0): Will use 25328 kb for X Server offscreen at offset 
0x02744000
  964 (**) RADEON(0): Initializing backing store
  965 (==) RADEON(0): Backing store disabled
  966 (**) RADEON(0): DRI Finishing init !
  967 (II) RADEON(0): X context handle = 0x1
  968 (II) RADEON(0): [drm] installed DRM signal handler
  969 (II) RADEON(0): [DRI] installation complete
  970 (**) RADEON(0): EngineRestore (32/32)
  971 (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
  972 (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers
  973 (II) RADEON(0): [drm] dma control initialized, using IRQ 209
  974 (II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808
  975 (WW) RADEON(0): DRI init changed memory map, adjusting ...
  976 (WW) RADEON(0):   MC_FB_LOCATION  was: 0xf3fff000 is: 0xf3fff000
  977 (WW) RADEON(0):   MC_AGP_LOCATION was: 0xffc0 is: 0xec7fec00
  978 (**) RADEON(0): GRPH_BUFFER_CNTL from 20095c5c to 20195c5c
  979 (II) RADEON(0): Direct rendering enabled
  980 (**) RADEON(0): Setting up final surfaces
  981 (**) RADEON(0): Initializing Acceleration
  982 (II) RADEON(0): Render acceleration enabled for R100 type cards.
  983 (**) RADEON(0): EngineInit (32/32)
  984 (**) RADEON(0): Pitch for acceleration = 160
  985 (**) RADEON(0): EngineRestore (32/32)
  986 (**) RADEON(0): Idle timed out: 64 entries, stat=0x80010140
  987 (EE) RADEON(0): Idle timed out, resetting engine...
  988 (**) RADEON(0): EngineRestore (32/32)
  989 (**) RADEON(0): Idle timed out: 64 entries, stat=0x80010140
  990 (EE) RADEON(0): Idle timed out, resetting engine...
  991 (**) RADEON(0): EngineRestore (32/32)
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Debugging the Radeon 200M command processor (CP)

2007-01-15 Thread Phillip Ezolt

Jerome,

On 1/13/07, Jerome Glisse [EMAIL PROTECTED] wrote:



 Is it something like this:

 BEGIN_RING(2);
 OUT_RING( CP_PACKET0( RADEON_SCRATCH_REG5, 0 ) );\
 OUT_RING( 0xDEADBEEF);   \
 ADVANCE_RING()
 COMMIT_RING()

Should be do the work, then you read the scratch reg via MMIO to see
if the value was set.



Alright, I tried that, but no luck.

I was able to read and write the register using a MMIO, but when I wrote to
the register with the CP, the value never showed up on in the register.  (I
waited for the cp to idle before I read it back.. I also read it a few
seconds later..)

However, the read pointer IS advancing, so the cp must be doing something.
I suspect that it is just executing random commands.  So, my current theory
is that:
1) The CP is actually working. (Because the read pointer is advancing..)
2) The ring buffer instructions are not being written where the card is
reading them from.

(BTW. I suspected that the Microcode might not be loading properly, but I
was able to read it back, and it matched what was written.)
...
I did a little more digging on this.  It really looks like the address of 
ring.start is completely different than what is in RADEON_CP_RB_BASE.  (I
realize that ring.start is a virtual address and RADEON_CP_RB_BASE is a bus
address.  However, the drmAddMap call in RADEONDRIPciInit sets the address
to 0, so I don't think it is setting 0x580 properly either...)

In any event, I think that the radeon DRM module and the card have a
completely different idea of where the ringbuffer is.  (And as a result the
card is executing crap)

I'm off to find out how all of those mappings work... (I also am going to
strace the fglrx driver to see how it sets them up...)

Does anyone know of any documents (other than:
http://www.xfree86.org/current/DESIGN9.html)
to help with understanding the mappings and how a GART/lack of GART would
interact?



I don't think there is any place for this except user account, you
could send it to me and i will put it in mine.

best,
Jerome Glisse



Ok.  I have to fix a bug which causes some of the output to be incorrect.
Once I fix it, I'll send it to you in a personal email.

Cheers,
--Phil
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Debugging the Radeon 200M command processor (CP)

2007-01-15 Thread Alex Deucher
On 1/15/07, Phillip Ezolt [EMAIL PROTECTED] wrote:
 Jerome,

 On 1/13/07, Jerome Glisse [EMAIL PROTECTED]  wrote:
  
   Is it something like this:
  
   BEGIN_RING(2);
   OUT_RING( CP_PACKET0( RADEON_SCRATCH_REG5, 0 ) );\
   OUT_RING( 0xDEADBEEF);   \
   ADVANCE_RING()
   COMMIT_RING()
 
  Should be do the work, then you read the scratch reg via MMIO to see
  if the value was set.

 Alright, I tried that, but no luck.

 I was able to read and write the register using a MMIO, but when I wrote to
 the register with the CP, the value never showed up on in the register.  (I
 waited for the cp to idle before I read it back.. I also read it a few
 seconds later..)

 However, the read pointer IS advancing, so the cp must be doing something.
 I suspect that it is just executing random commands.  So, my current theory
 is that:
 1) The CP is actually working. (Because the read pointer is advancing..)
 2) The ring buffer instructions are not being written where the card is
 reading them from.

 (BTW. I suspected that the Microcode might not be loading properly, but I
 was able to read it back, and it matched what was written.)
 ...

The r300 microcode in the current drm may not work properly on XPRESS
cards period.  You might try again with the microcode you extract from
fglrx or the windows driver.  Updated microcode for some of the other
cards may fix other problems.  Perhaps it make sense to figure out
what microcode fglrx loads on which cards.

Alex

 I did a little more digging on this.  It really looks like the address of
 ring.start is completely different than what is in RADEON_CP_RB_BASE.  (I
 realize that ring.start is a virtual address and RADEON_CP_RB_BASE is a bus
 address.  However, the drmAddMap call in RADEONDRIPciInit sets the address
 to 0, so I don't think it is setting 0x580 properly either...)

 In any event, I think that the radeon DRM module and the card have a
 completely different idea of where the ringbuffer is.  (And as a result the
 card is executing crap)

 I'm off to find out how all of those mappings work... (I also am going to
 strace the fglrx driver to see how it sets them up...)

 Does anyone know of any documents (other than:
 http://www.xfree86.org/current/DESIGN9.html)
  to help with understanding the mappings and how a GART/lack of GART would
 interact?
 
  I don't think there is any place for this except user account, you
  could send it to me and i will put it in mine.
 
  best,
  Jerome Glisse
 

 Ok.  I have to fix a bug which causes some of the output to be incorrect.
 Once I fix it, I'll send it to you in a personal email.

 Cheers,
 --Phil
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

 --
 ___
 Dri-devel mailing list
 Dri-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dri-devel




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 7128] Radeon R300 lockup on 2 clients accessing XV

2007-01-15 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=7128  
 

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2007-01-15 07:51 ---
Can you try to get a backtrace from the X server when this happens?  
 
 
--   
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email 
 
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 8541] Strange effect?

2007-01-15 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=8541  
 

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2007-01-15 07:59 ---
Please attach the full log file.  
 
 
--   
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email 
 
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Debugging the Radeon 200M command processor (CP)

2007-01-15 Thread Phillip Ezolt

Alex,

On 1/15/07, Alex Deucher [EMAIL PROTECTED] wrote:


On 1/15/07, Phillip Ezolt [EMAIL PROTECTED] wrote:
 Jerome,

 On 1/13/07, Jerome Glisse [EMAIL PROTECTED]  wrote:
  
   Is it something like this:
  
   BEGIN_RING(2);
   OUT_RING( CP_PACKET0( RADEON_SCRATCH_REG5, 0 ) );\
   OUT_RING( 0xDEADBEEF);   \
   ADVANCE_RING()
   COMMIT_RING()
 
  Should be do the work, then you read the scratch reg via MMIO to see
  if the value was set.

 Alright, I tried that, but no luck.

 I was able to read and write the register using a MMIO, but when I wrote
to
 the register with the CP, the value never showed up on in the
register.  (I
 waited for the cp to idle before I read it back.. I also read it a few
 seconds later..)

 However, the read pointer IS advancing, so the cp must be doing
something.
 I suspect that it is just executing random commands.  So, my current
theory
 is that:
 1) The CP is actually working. (Because the read pointer is advancing..)
 2) The ring buffer instructions are not being written where the card is
 reading them from.

 (BTW. I suspected that the Microcode might not be loading properly, but
I
 was able to read it back, and it matched what was written.)
 ...

The r300 microcode in the current drm may not work properly on XPRESS
cards period.  You might try again with the microcode you extract from
fglrx or the windows driver.  Updated microcode for some of the other
cards may fix other problems.  Perhaps it make sense to figure out
what microcode fglrx loads on which cards.

Alex



Alright.  This is easy enough for me to try. I can get the EXACT FW that the
8.32.5 driver uses for my card by running one of the dump routines that I
have laying around. (After fglrx has started up.)

BTW. I actually put the FW from a previous version of the driver (pre 8.32.5),
and it didn't make a difference.  However, I haven't tried it with the
8.32.5 version of fglrx... which works pretty well with this card.

Thanks for the hint.  I'll do it tonight.

Cheers,
--Phil
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Debugging the Radeon 200M command processor (CP)

2007-01-15 Thread Dave Airlie

 ...
 I did a little more digging on this.  It really looks like the address of 
 ring.start is completely different than what is in RADEON_CP_RB_BASE.  (I
 realize that ring.start is a virtual address and RADEON_CP_RB_BASE is a bus
 address.  However, the drmAddMap call in RADEONDRIPciInit sets the address
 to 0, so I don't think it is setting 0x580 properly either...)

 In any event, I think that the radeon DRM module and the card have a
 completely different idea of where the ringbuffer is.  (And as a result the
 card is executing crap)

 I'm off to find out how all of those mappings work... (I also am going to
 strace the fglrx driver to see how it sets them up...)



I've looked at one of these laptops yesterday (thanks mjg59...) and I 
thought it might be possible to get PCI GART working on it, I didn't get 
it working, but I think it might be an initial method.. I'm hoping to get 
some time later in the week to look at it again.. another quick hack 
method might be to place the CP in the reserved framebuffer memory (as 
it is all UMA) and see if that works

Dave.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [nouveau] a million little pieces affecting nvidia drivers

2007-01-15 Thread Alexy Khrabrov
Philipp, Mark --

Thanks for the concise and extremely useful explanation!  This is
worthy of being on the front page of a wiki.

Cheers,
Alexy

On 1/15/07, Michel Dänzer [EMAIL PROTECTED] wrote:
 On Sun, 2007-01-14 at 00:22 +0100, Philipp Klaus Krause wrote:
 
  GLX canbe used over a network, but currently the free drivers don't support
  hardware-acceleration in this case.

 That's no longer true since the introduction of AIGLX in X.org 7.1.


 --
 Earthling Michel Dänzer   |  http://tungstengraphics.com
 Libre software enthusiast |  Debian, X and DRI developer



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [nouveau] a million little pieces affecting nvidia drivers

2007-01-15 Thread Stephane Marchesin
Alexy Khrabrov wrote:
 Philipp, Mark --

 Thanks for the concise and extremely useful explanation!  This is
 worthy of being on the front page of a wiki.

   
Also, there is that :
http://people.freedesktop.org/~ajax/dri-explanation.txt

Stephane



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel