https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #9 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:16:28 ---
Hi, Michel.
On Fri, May 20, 2011 at 12:11, bugzilla-dae...@bugzilla.kernel.org wrote:
--- Comment #6 from Michel Dänzer mic...@daenzer.net 2011-05-20 12:11:38
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #10 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:23:27 ---
Hi there.
On Sat, May 21, 2011 at 09:16, bugzilla-dae...@bugzilla.kernel.org wrote:
OK. I can try no_wb=1 with agpmode=-1 and report back in a few
moments, to
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #11 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:34:20 ---
Another test.
On Sat, May 21, 2011 at 09:23, bugzilla-dae...@bugzilla.kernel.org wrote:
On Sat, May 21, 2011 at 09:16, bugzilla-dae...@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #12 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:42:12 ---
On Sat, May 21, 2011 at 09:34, bugzilla-dae...@bugzilla.kernel.org wrote:
On Sat, May 21, 2011 at 09:23, bugzilla-dae...@bugzilla.kernel.org wrote:
On Sat, May
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #13 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:47:45 ---
Created an attachment (id=58892)
-- (https://bugzilla.kernel.org/attachment.cgi?id=58892)
dmesg log with 2.6.39-rc7 with KMS + agpmode=-1 + no_wb=1
--
Configure
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #14 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:50:35 ---
Created an attachment (id=58902)
-- (https://bugzilla.kernel.org/attachment.cgi?id=58902)
X log with 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1
--
Configure bugmail:
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #15 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:56:33 ---
With 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1 + dynclks=1:
* I don't get the Oopsen.
* the resolution is restricted to 800x600.
* XV is not available to mplayer or
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #16 from Michel Dänzer mic...@daenzer.net 2011-05-21 14:54:25 ---
(In reply to comment #15)
With 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1 + dynclks=1:
* XV is not available to mplayer or other applications.
When the kernel
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #17 from Rogério Brito rbr...@ime.usp.br 2011-05-21 15:34:37 ---
Hi, Michel.
Thank you very much for the attention.
(In reply to comment #16)
When the kernel radeon driver fails to initialize acceleration, there's no
point in
https://bugzilla.kernel.org/show_bug.cgi?id=34772
Alex Deucher alexdeuc...@gmail.com changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #19 from Rogério Brito rbr...@ime.usp.br 2011-05-21 15:42:21 ---
(In reply to comment #18)
apples sells VGA to s-video adapters, so we list both connectors in the
driver.
Oh, sorry for the ignorance.
--
Configure bugmail:
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #20 from Michel Dänzer mic...@daenzer.net 2011-05-21 16:47:10 ---
Created an attachment (id=58922)
-- (https://bugzilla.kernel.org/attachment.cgi?id=58922)
Allow forcing on all GPU clocks
(In reply to comment #17)
Has either
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #21 from Michel Dänzer mic...@daenzer.net 2011-05-21 16:58:59 ---
Would also be interesting if one of you guys could attach dmesg with agpmode=1.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
---
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #6 from Michel Dänzer mic...@daenzer.net 2011-05-20 12:11:38 ---
(In reply to comment #1)
Anyway, things are *way* better with 2.6.38 than with 2.6.39, as with 2.6.39
the kernel doesn't even get the colors correctly---everything
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #7 from Michel Dänzer mic...@daenzer.net 2011-05-20 14:31:00 ---
I was able to reproduce the acceleration initialization failure with the Debian
2.6.39-rc7-powerpc kernel, but not with a self-built 2.6.39 kernel. So this was
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #8 from Andreas Schwab sch...@linux-m68k.org 2011-05-20 20:58:03
---
radeon.dynclks=1 causes the wrong resolution to be selected. It thinks
something is conncted to the S-video port with a max resolution of 800x600, so
it
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #1 from Rogério Brito rbr...@ime.usp.br 2011-05-19 20:34:40 ---
Just for the record, I can provide further messages of these: this is as
reproducible as I like.
In fact, I am now able to reproduce it with kernel 2.6.38 if I boot
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #2 from Rogério Brito rbr...@ime.usp.br 2011-05-19 20:36:24 ---
Created an attachment (id=58602)
-- (https://bugzilla.kernel.org/attachment.cgi?id=58602)
A dmesg log from 2.6.39-rc7 showing problems.
--
Configure bugmail:
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #3 from Rogério Brito rbr...@ime.usp.br 2011-05-19 20:37:08 ---
Created an attachment (id=58612)
-- (https://bugzilla.kernel.org/attachment.cgi?id=58612)
The log of X with the 2.6.39-rc7 kernel
--
Configure bugmail:
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #4 from Rogério Brito rbr...@ime.usp.br 2011-05-19 20:38:14 ---
Created an attachment (id=58622)
-- (https://bugzilla.kernel.org/attachment.cgi?id=58622)
A dmesg log with 2.6.38 kernel
Please, notice the GPU hang with kernel
https://bugzilla.kernel.org/show_bug.cgi?id=34772
--- Comment #5 from Rogério Brito rbr...@ime.usp.br 2011-05-19 20:38:56 ---
Created an attachment (id=58632)
-- (https://bugzilla.kernel.org/attachment.cgi?id=58632)
Log from X with the kernel 2.6.38
--
Configure bugmail:
https://bugzilla.kernel.org/show_bug.cgi?id=34772
Summary: [radeon] [R300] GPU lockups with when KMS is enabled
Product: Drivers
Version: 2.5
Kernel Version: 2.6.38
Platform: All
OS/Version: Linux
Tree: Mainline
On Wed, 2005-06-22 at 18:36 +1000, Benjamin Herrenschmidt wrote:
The problem is simple: when setting up the AGP aperture, it's putting it
after the framebuffer + CONFIG_APER_SIZE, which is wrong. On that guy,
CONFIG_APER_SIZE might only be _half_ of the mapped vram space (as the
card can be
On Thu, 2005-08-25 at 23:26 +0200, Johannes Berg wrote:
On Wed, 2005-06-22 at 18:36 +1000, Benjamin Herrenschmidt wrote:
The problem is simple: when setting up the AGP aperture, it's putting it
after the framebuffer + CONFIG_APER_SIZE, which is wrong. On that guy,
CONFIG_APER_SIZE might
On Thu, 2005-08-25 at 23:42 +0200, Jerome Glisse wrote:
IIRC there have been a patch to xorg for that and to DRM
too. Give it a try :)
For whatever reason, I can't seem to build xorg right now. I'll have a
try another time, but thanks for the heads-up.
johannes
signature.asc
Description:
On Tue, 2005-06-21 at 16:44 +0200, Johannes Berg wrote:
Jerome Glisse wrote:
I can remember from the top of my head but there is maybe some patch
that could be revealent for ppc not included in this snapshot. Thus i think
you should consider trying building xorg from cvs. Anyway with a g4 it
On 6/21/05, Vladimir Dergachev [EMAIL PROTECTED] wrote:
On Sat, 18 Jun 2005, Johannes Berg wrote:
Any idea where I should start looking for the source of the lockups or what
else to do?
The problem is likely either due to the radeon memory controller - in
particular registers like
On Tuesday 21 June 2005 10:54, Jerome Glisse wrote:
On 6/21/05, Vladimir Dergachev [EMAIL PROTECTED] wrote:
On Sat, 18 Jun 2005, Johannes Berg wrote:
Any idea where I should start looking for the source of the lockups or
what else to do?
The problem is likely either due to the radeon
On 6/21/05, Johannes Berg [EMAIL PROTECTED] wrote:
Hi,
I mainly used r300 on ppc so far thus yes it works.
Good to know.
I am using it on x86 for
the 9800 lockup. But as i used a g5 i don't know if there is an issue with
the
agp of g4, don't think so... And IIRC someone told me that
Hi,
I mainly used r300 on ppc so far thus yes it works.
Good to know.
I am using it on x86 for
the 9800 lockup. But as i used a g5 i don't know if there is an issue with the
agp of g4, don't think so... And IIRC someone told me that it worked on a
powerbook which is, i presume, what
On 6/21/05, Nicolai Haehnle [EMAIL PROTECTED] wrote:
On Tuesday 21 June 2005 10:54, Jerome Glisse wrote:
On 6/21/05, Vladimir Dergachev [EMAIL PROTECTED] wrote:
On Sat, 18 Jun 2005, Johannes Berg wrote:
Any idea where I should start looking for the source of the lockups or
what else to
Jerome Glisse wrote:
I can remember from the top of my head but there is maybe some patch
that could be revealent for ppc not included in this snapshot. Thus i think
you should consider trying building xorg from cvs. Anyway with a g4 it will
compiles a lot faster than on dumb x86 ;)
Ok,
On Sat, 18 Jun 2005, Johannes Berg wrote:
Hi,
I just tried the latest r300 cvs code (with current mesa cvs, latest
Xorg snapshot) but all I get is a lockup as soon as the X server starts.
If I have debugging enabled, I get a loop of radeon_do_cp_idle calls.
Hardware is:
:00:10.0 VGA
Hi,
I just tried the latest r300 cvs code (with current mesa cvs, latest
Xorg snapshot) but all I get is a lockup as soon as the X server starts.
If I have debugging enabled, I get a loop of radeon_do_cp_idle calls.
Hardware is:
:00:10.0 VGA compatible controller: ATI Technologies Inc RV350
On Sat, 4 Jun 2005, Nicolai Haehnle wrote:
The mirroring works as follows: each time scratch register is written
the
radeon controller uses PCI to write their value to a specific location in
system memory.
Are you sure it uses PCI? I'm assuming that the destination address for
scratch
Which way can memory controller be misprogrammed ? The part that concerns
us are positions of Video RAM, AGP and System Ram in Radeon address space.
(these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION).
The memory controller *always* assumes that system RAM (accessible via
Vladimir Dergachev schrieb:
My understanding is that AGP only does transfers system RAM - video RAM
and all transfers in the opposite direction have to use plain PCI
transfers at least as far as the bus is concerned.
AGP can do both. Every AGP compliant device has to support the
System RAM
On Sun, 5 Jun 2005, Jerome Glisse wrote:
Note that old driver was able to test whether mirroring works, so it
would correspond to behaviour of RV350 cards. It could be that R300 cards
are more touchy in this regard.
Might be worth trying to fallback to non-mirrored setup and see if that
On Sunday 05 June 2005 15:55, Vladimir Dergachev wrote:
On Sat, 4 Jun 2005, Nicolai Haehnle wrote:
The mirroring works as follows: each time scratch register is written
the
radeon controller uses PCI to write their value to a specific location
in
system memory.
Are you sure it
This
register is programmed to a value that falls within the AGP area (as
defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly.
My understanding is that AGP only does transfers system RAM - video RAM
and all transfers in the opposite direction have to use plain PCI
transfers
On Sunday 05 June 2005 20:07, Vladimir Dergachev wrote:
My understanding is that dev-agp-base is the address where the AGP
GART
mirrors the pieces of system RAM comprising AGP space.
Yes, that's my understanding, too. But what is the Radeon's business
knowing
that address? Why does it
Yes, however it is convenient to do so.
The point is that AGP base address will not normally overlap the location
of system RAM. This is, of course, only reasonable for 32 bit systems..
I understand that part, but it's not what I meant. What I mean is this: You
said, RADEON_MC_AGP_LOCATION is
On Sun, 2005-06-05 at 09:58 -0400, Vladimir Dergachev wrote:
Which way can memory controller be misprogrammed ? The part that concerns
us are positions of Video RAM, AGP and System Ram in Radeon address space.
(these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION).
My understanding is that AGP only does transfers system RAM - video RAM
and all transfers in the opposite direction have to use plain PCI
transfers at least as far as the bus is concerned.
You mean system RAM - graphics card, right? Does this mean that the
graphics card cannot always
Yes, however it is convenient to do so.
The point is that AGP base address will not normally overlap the location
of system RAM. This is, of course, only reasonable for 32 bit systems..
It will overlap it on all PowerMac's (where it will be 0)
Ben.
On Sun, 2005-06-05 at 14:45 -0400, Vladimir Dergachev wrote:
Yes, however it is convenient to do so.
The point is that AGP base address will not normally overlap the location
of system RAM. This is, of course, only reasonable for 32 bit systems..
I understand that part, but it's not
I just wanted to contribute the following piece of information that might
help with R300 lockups. I do not know whether it applies or not in this
case, but just something to be aware about.
Radeon has a memory controller which translates internal address space of
the chip into accesses
On Saturday 04 June 2005 15:01, Vladimir Dergachev wrote:
I just wanted to contribute the following piece of information that
might
help with R300 lockups. I do not know whether it applies or not in this
case, but just something to be aware about.
Radeon has a memory controller which
Are you sure it uses PCI? I'm assuming that the destination address for
scratch writeback is controlled by the RADEON_SCRATCH_ADDR register. This
register is programmed to a value that falls within the AGP area (as
defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly.
Ok,
This, of course, would not work if the memory controller is misprogrammed
- which was the cause of failures.
Goood old discussion :)
Which way can memory controller be misprogrammed ? The part that concerns
us are positions of Video RAM, AGP and System Ram in Radeon address space.
Vladimir Dergachev wrote:
This is indeed strange.. Is texture[4] used anywhere before ? Does the
same happen with latest CVS ?
There are 5 textures 0 to 4 (including 2 masks ) texture 0 and 4
appear stable 1-3 appear unstable.
With the latest CVS I once managed to run the lesson for 3 sec.
On Sun, 30 Jan 2005, Rune Petersen wrote:
Vladimir Dergachev wrote:
This is indeed strange.. Is texture[4] used anywhere before ? Does the
same happen with latest CVS ?
There are 5 textures 0 to 4 (including 2 masks ) texture 0 and 4
appear stable 1-3 appear unstable.
With the latest CVS I once
Vladimir Dergachev wrote:
On Sun, 30 Jan 2005, Rune Petersen wrote:
Vladimir Dergachev wrote:
This is indeed strange.. Is texture[4] used anywhere before ? Does the
same happen with latest CVS ?
There are 5 textures 0 to 4 (including 2 masks ) texture 0 and 4
appear stable 1-3 appear unstable.
Does the same happen if you load them in a different order ? What is the
difference between these textures ?
the first and last texture are the only textures that work properly. If I
change the order it is still the first and last texture.
To me it smells like an texture allocation/management
This is strange as the texture management code was pulled straight from
r200 driver - I would have expected it to work.
Can you tell me how to get at these offsets? it will be easier to debug
compared to lockups :)
I started looking for the code to point you to and could not resist to
On Fri, 28 Jan 2005, Rune Petersen wrote:
Vladimir Dergachev wrote:
On Thu, 27 Jan 2005, Rune Petersen wrote:
Hi,
I get lockups running anything other than glxgears.
I am running the 25 jan. snapshots of Xorg r300_driver.
Are there any simple way to locate the functions that course lockups?
I
Vladimir Dergachev wrote:
Hi,
I get lockups running anything other than glxgears.
I am running the 25 jan. snapshots of Xorg r300_driver.
Are there any simple way to locate the functions that course lockups?
I was thinking of something like simple programs or tutorials.
Try NeHe tutorial -
fallback). As for lesson20 I have no idea - try commenting out drawing code
and checking which part creates a lockup.
Btw, I am getting a partial lockup with lesson20 even without
r300_dri.so (when it is absent the driver falls back to software
rendering), so it might be due to mode
Vladimir Dergachev wrote:
Lesson 20 have 3 points that causes lockups (maybe more).
They are all related.
the first is at line 258-259:
glBindTexture(GL_TEXTURE_2D, texture[3]);
glBegin(GL_QUADS);
glBegin() is causing the lockup, but only when textures 1, 2, or 3.
if you change
On Sun, 30 Jan 2005, Rune Petersen wrote:
Vladimir Dergachev wrote:
Lesson 20 have 3 points that causes lockups (maybe more).
They are all related.
the first is at line 258-259:
glBindTexture(GL_TEXTURE_2D, texture[3]);
glBegin(GL_QUADS);
glBegin() is causing the lockup, but only when
Hi,
I get lockups running anything other than glxgears.
I am running the 25 jan. snapshots of Xorg r300_driver.
Are there any simple way to locate the functions that course lockups?
I was thinking of something like simple programs or tutorials.
Rune Petersen
On Thu, 27 Jan 2005, Rune Petersen wrote:
Hi,
I get lockups running anything other than glxgears.
I am running the 25 jan. snapshots of Xorg r300_driver.
Are there any simple way to locate the functions that course lockups?
I was thinking of something like simple programs or tutorials.
Try NeHe
Vladimir Dergachev wrote:
On Thu, 27 Jan 2005, Rune Petersen wrote:
Hi,
I get lockups running anything other than glxgears.
I am running the 25 jan. snapshots of Xorg r300_driver.
Are there any simple way to locate the functions that course lockups?
I was thinking of something like simple
63 matches
Mail list logo
