[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions
https://bugs.freedesktop.org/show_bug.cgi?id=28860 --- Comment #12 from Marek Ol??k 2010-07-14 22:46:06 PDT --- If you revert 8c836f7f740c6f74511c727c7bed0680ddba9974, do those messages go away? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Regression 2.6.34->2.6.35-rc4: radeaon KMS an RS690 broken
On Wed, Jul 14, 2010 at 9:30 PM, Jerome Glisse wrote: > On 07/14/2010 02:51 PM, Torsten Kaiser wrote: >> >> On Tue, Jul 13, 2010 at 9:10 PM, Alex Deucher >> ?wrote: >>> >>> On Tue, Jul 13, 2010 at 2:29 PM, Torsten Kaiser >>> ?wrote: But the CP is still broken: >>> >>> Is this a regression? ?If so, can you bisect it? >>> >>> Alex >> >> I bisected it to this commit: >> >> d594e46ace22afa1621254f6f669e65430048153 is the first bad commit >> commit d594e46ace22afa1621254f6f669e65430048153 >> Author: Jerome Glisse >> Date: ? Wed Feb 17 21:54:29 2010 + >> >> ? ? drm/radeon/kms: simplify memory controller setup V2 >> >> ? ? Get rid of _location and use _start/_end also simplify the >> ? ? computation of vram_start|end& ?gtt_start|end. For R1XX-R2XX >> ? ? we place VRAM at the same address of PCI aperture, those GPU >> ? ? shouldn't have much memory and seems to behave better when >> ? ? setup that way. For R3XX and newer we place VRAM at 0. For >> ? ? R6XX-R7XX AGP we place VRAM before or after AGP aperture this >> ? ? might limit to limit the VRAM size but it's very unlikely. >> ? ? For IGP we don't change the VRAM placement. >> >> ? ? Tested on (compiz,quake3,suspend/resume): >> ? ? PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710 >> ? ? AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730 >> ? ? IGP:RS480(RPB*),RS690,RS780(RPB*),RS880 >> >> ? ? RPB: resume previously broken >> >> ? ? V2 correct commit message to reflect more accurately the bug >> ? ? and move VRAM placement to 0 for most of the GPU to avoid >> ? ? limiting VRAM. >> >> ? ? Signed-off-by: Jerome Glisse >> ? ? Signed-off-by: Dave Airlie >> >> :04 04 05c1e456fcf6565aa8711e4933807956d0055cca >> 792c6be2bd161a52500c5e8d685ee651cd5af07e M ? ? drivers >> >> HTH, Torsten >> [ ? ?0.426931] Linux agpgart interface v0.103 [ ? ?0.427092] [drm] Initialized drm 1.1.0 20060810 [ ? ?0.427196] [drm] radeon defaulting to kernel modesetting. [ ? ?0.427255] [drm] radeon kernel modesetting enabled. [ ? ?0.427372] radeon :01:05.0: PCI INT A -> ?GSI 18 (level, low) -> ?IRQ 18 [ ? ?0.429659] [drm] initializing kernel modesetting (RS690 0x1002:0x791E). [ ? ?0.429817] [drm] register mmio base: 0xFE9F [ ? ?0.429876] [drm] register mmio size: 65536 [ ? ?0.430457] ATOM BIOS: ATI [ ? ?0.430532] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF (32M used) [ ? ?0.430592] radeon :01:05.0: GTT: 512M 0xBE00 - 0xDDFF [ ? ?0.430675] [drm] radeon: irq initialized. [ ? ?0.430737] mtrr: type mismatch for fc00,200 old: write-back new: write-comb ining [ ? ?0.430811] [drm] Detected VRAM RAM=32M, BAR=32M [ ? ?0.430868] [drm] RAM width 128bits DDR [ ? ?0.431011] [TTM] Zone ?kernel: Available graphics memory: 2010234 kiB. [ ? ?0.431070] [TTM] Initializing pool allocator. [ ? ?0.431147] [drm] radeon: 32M of VRAM memory ready [ ? ?0.431205] [drm] radeon: 512M of GTT memory ready. [ ? ?0.431266] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ ? ?0.434654] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ ? ?0.441719] [drm] Loading RS690/RS740 Microcode [ ? ?0.441926] [drm] radeon: ring at 0xBE00 [ ? ?0.577118] [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0x CAFEDEAD) [ ? ?0.577192] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [ ? ?0.577252] radeon :01:05.0: failled initializing CP (-22). [ ? ?0.577310] radeon :01:05.0: Disabling GPU acceleration [ ? ?0.577440] [drm] radeon: cp finalized [ ? ?0.578078] [drm] Default TV standard: NTSC [ ? ?0.578314] [drm] Default TV standard: NTSC [ ? ?0.578590] [drm] Radeon Display Connectors [ ? ?0.578648] [drm] Connector 0: [ ? ?0.578706] [drm] ? VGA [ ? ?0.578764] [drm] ? DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [ ? ?0.578837] [drm] ? Encoders: [ ? ?0.578894] [drm] ? ? CRT1: INTERNAL_KLDSCP_DAC1 [ ? ?0.578952] [drm] Connector 1: [ ? ?0.579010] [drm] ? S-video [ ? ?0.579067] [drm] ? Encoders: [ ? ?0.579124] [drm] ? ? TV1: INTERNAL_KLDSCP_DAC1 [ ? ?0.579182] [drm] Connector 2: [ ? ?0.579239] [drm] ? HDMI-A [ ? ?0.579297] [drm] ? DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [ ? ?0.579369] [drm] ? Encoders: [ ? ?0.579427] [drm] ? ? DFP3: INTERNAL_LVTM1 [ ? ?0.773375] [drm] fb mappable at 0xFC04 [ ? ?0.773434] [drm] vram apper at 0xFC00 [ ? ?0.773491] [drm] size 786432 [ ? ?0.773549] [drm] fb depth is 8 [ ? ?0.773606] [drm] ? ?pitch is 1024 [ ? ?0.773737] fbcon: radeondrmfb (fb0) is primary device [ ? ?0.793240] Console: switching to colour frame buffer device 128x48 [ ? ?0.794833] fb0: radeondrmfb frame buffer device [ ? ?0.794852] drm: registered panic notifier [ ? ?0.794871]
[PATCH] drm/i810: fixed coding style issues
Fixed brace, macro and spacing coding style issues, and a C99 comment.
Signed-off-by: Nicolas Kaiser
---
drivers/gpu/drm/i810/i810_dma.c | 81 ++
drivers/gpu/drm/i810/i810_drv.h | 64 ---
2 files changed, 71 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index 997d917..09c86ed 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -60,9 +60,8 @@ static struct drm_buf *i810_freelist_get(struct drm_device *
dev)
/* In use is already a pointer */
used = cmpxchg(buf_priv->in_use, I810_BUF_FREE,
I810_BUF_CLIENT);
- if (used == I810_BUF_FREE) {
+ if (used == I810_BUF_FREE)
return buf;
- }
}
return NULL;
}
@@ -71,7 +70,7 @@ static struct drm_buf *i810_freelist_get(struct drm_device *
dev)
* yet, the hardware updates in use for us once its on the ring buffer.
*/
-static int i810_freelist_put(struct drm_device * dev, struct drm_buf * buf)
+static int i810_freelist_put(struct drm_device *dev, struct drm_buf *buf)
{
drm_i810_buf_priv_t *buf_priv = buf->dev_private;
int used;
@@ -121,7 +120,7 @@ static const struct file_operations i810_buffer_fops = {
.fasync = drm_fasync,
};
-static int i810_map_buffer(struct drm_buf * buf, struct drm_file *file_priv)
+static int i810_map_buffer(struct drm_buf *buf, struct drm_file *file_priv)
{
struct drm_device *dev = file_priv->minor->dev;
drm_i810_buf_priv_t *buf_priv = buf->dev_private;
@@ -152,7 +151,7 @@ static int i810_map_buffer(struct drm_buf * buf, struct
drm_file *file_priv)
return retcode;
}
-static int i810_unmap_buffer(struct drm_buf * buf)
+static int i810_unmap_buffer(struct drm_buf *buf)
{
drm_i810_buf_priv_t *buf_priv = buf->dev_private;
int retcode = 0;
@@ -172,7 +171,7 @@ static int i810_unmap_buffer(struct drm_buf * buf)
return retcode;
}
-static int i810_dma_get_buffer(struct drm_device * dev, drm_i810_dma_t * d,
+static int i810_dma_get_buffer(struct drm_device *dev, drm_i810_dma_t *d,
struct drm_file *file_priv)
{
struct drm_buf *buf;
@@ -202,7 +201,7 @@ static int i810_dma_get_buffer(struct drm_device * dev,
drm_i810_dma_t * d,
return retcode;
}
-static int i810_dma_cleanup(struct drm_device * dev)
+static int i810_dma_cleanup(struct drm_device *dev)
{
struct drm_device_dma *dma = dev->dma;
@@ -218,9 +217,8 @@ static int i810_dma_cleanup(struct drm_device * dev)
drm_i810_private_t *dev_priv =
(drm_i810_private_t *) dev->dev_private;
- if (dev_priv->ring.virtual_start) {
+ if (dev_priv->ring.virtual_start)
drm_core_ioremapfree(_priv->ring.map, dev);
- }
if (dev_priv->hw_status_page) {
pci_free_consistent(dev->pdev, PAGE_SIZE,
dev_priv->hw_status_page,
@@ -242,7 +240,7 @@ static int i810_dma_cleanup(struct drm_device * dev)
return 0;
}
-static int i810_wait_ring(struct drm_device * dev, int n)
+static int i810_wait_ring(struct drm_device *dev, int n)
{
drm_i810_private_t *dev_priv = dev->dev_private;
drm_i810_ring_buffer_t *ring = &(dev_priv->ring);
@@ -271,11 +269,11 @@ static int i810_wait_ring(struct drm_device * dev, int n)
udelay(1);
}
- out_wait_ring:
+out_wait_ring:
return iters;
}
-static void i810_kernel_lost_context(struct drm_device * dev)
+static void i810_kernel_lost_context(struct drm_device *dev)
{
drm_i810_private_t *dev_priv = dev->dev_private;
drm_i810_ring_buffer_t *ring = &(dev_priv->ring);
@@ -287,7 +285,7 @@ static void i810_kernel_lost_context(struct drm_device *
dev)
ring->space += ring->Size;
}
-static int i810_freelist_init(struct drm_device * dev, drm_i810_private_t *
dev_priv)
+static int i810_freelist_init(struct drm_device *dev, drm_i810_private_t
*dev_priv)
{
struct drm_device_dma *dma = dev->dma;
int my_idx = 24;
@@ -322,9 +320,9 @@ static int i810_freelist_init(struct drm_device * dev,
drm_i810_private_t * dev_
return 0;
}
-static int i810_dma_initialize(struct drm_device * dev,
- drm_i810_private_t * dev_priv,
- drm_i810_init_t * init)
+static int i810_dma_initialize(struct drm_device *dev,
+ drm_i810_private_t *dev_priv,
+ drm_i810_init_t *init)
{
struct drm_map_list *r_list;
memset(dev_priv, 0, sizeof(drm_i810_private_t));
@@ -462,7 +460,7 @@ static int i810_dma_init(struct drm_device *dev, void *data,
* Use 'volatile' &
drm: refresh rate down to 60 Hz in 2.6.35-rc5
[ Resending to the right mailing list. I looked up in MAINTAINERS, but forgot to run "git bisect reset" and got the wrong address for dri-devel at . Apologies to all who receive this twice. ] After upgrading to 2.6.35-rc5, I noticed that my monitor reports a refresh rate of 60 Hz when nouveau.ko is loaded, rather than the 75 Hz I got on 2.6.34. Graphics card is an NV86 (GeForce 8500 GT), the monitor is a 1280x1024 TFT (Yakumo 19AL) connected via VGA. I bisected this to the following commit: --8<---cut here---start->8--- commit c867df7043b738da4f4d358d7039c243a29b4272 Author: Adam Jackson Date: Mon Mar 29 21:43:21 2010 + drm/edid: Reshuffle mode list construction to closer match the spec Also, document what the spec says to do. Signed-off-by: Adam Jackson Signed-off-by: Dave Airlie diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 9c4717f..858fedc 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1377,10 +1377,24 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) quirks = edid_get_quirks(edid); - num_modes += add_established_modes(connector, edid); - num_modes += add_standard_modes(connector, edid); + /* +* EDID spec says modes should be preferred in this order: +* - preferred detailed mode +* - other detailed modes from base block +* - detailed modes from extension blocks +* - CVT 3-byte code modes +* - standard timing codes +* - established timing codes +* - modes inferred from GTF or CVT range information +* +* We don't quite implement this yet, but we're close. +* +* XXX order for additional mode types in extension blocks? +*/ num_modes += add_detailed_info(connector, edid, quirks); num_modes += add_detailed_info_eedid(connector, edid, quirks); + num_modes += add_standard_modes(connector, edid); + num_modes += add_established_modes(connector, edid); if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75)) edid_fixup_preferred(connector, quirks); --8<---cut here---end--->8--- How do I get the 75 Hz refresh rate back? Adding "video=1280x1024 at 75" as described in the nouveau wiki? has no effect. Regards, Sven ? http://nouveau.freedesktop.org/wiki/KernelModeSetting
glint KMS - how to proceed?
On Wed, Jul 14, 2010 at 2:13 PM, James Simmons wrote: > >> Whoo! I'll put this up on k.org as soon as I can get it working. > > The only problem is it will not work with X running with the tdfx xorg > driver :-( The driver will need more love as well. That's alright. I am, if nothing else, a lover of DDXs. tdfx needs it anyway -- DRI1 is kind of painful with the current setup. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson
Regression 2.6.34->2.6.35-rc4: radeaon KMS an RS690 broken
tandard: NTSC
>>>>> [ ? ?0.578590] [drm] Radeon Display Connectors
>>>>> [ ? ?0.578648] [drm] Connector 0:
>>>>> [ ? ?0.578706] [drm] ? VGA
>>>>> [ ? ?0.578764] [drm] ? DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48
>>>>> 0x7e5c 0x7e4c
>>>>> [ ? ?0.578837] [drm] ? Encoders:
>>>>> [ ? ?0.578894] [drm] ? ? CRT1: INTERNAL_KLDSCP_DAC1
>>>>> [ ? ?0.578952] [drm] Connector 1:
>>>>> [ ? ?0.579010] [drm] ? S-video
>>>>> [ ? ?0.579067] [drm] ? Encoders:
>>>>> [ ? ?0.579124] [drm] ? ? TV1: INTERNAL_KLDSCP_DAC1
>>>>> [ ? ?0.579182] [drm] Connector 2:
>>>>> [ ? ?0.579239] [drm] ? HDMI-A
>>>>> [ ? ?0.579297] [drm] ? DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58
>>>>> 0x7e4c 0x7e5c
>>>>> [ ? ?0.579369] [drm] ? Encoders:
>>>>> [ ? ?0.579427] [drm] ? ? DFP3: INTERNAL_LVTM1
>>>>> [ ? ?0.773375] [drm] fb mappable at 0xFC04
>>>>> [ ? ?0.773434] [drm] vram apper at 0xFC00
>>>>> [ ? ?0.773491] [drm] size 786432
>>>>> [ ? ?0.773549] [drm] fb depth is 8
>>>>> [ ? ?0.773606] [drm] ? ?pitch is 1024
>>>>> [ ? ?0.773737] fbcon: radeondrmfb (fb0) is primary device
>>>>> [ ? ?0.793240] Console: switching to colour frame buffer device 128x48
>>>>> [ ? ?0.794833] fb0: radeondrmfb frame buffer device
>>>>> [ ? ?0.794852] drm: registered panic notifier
>>>>> [ ? ?0.794871] Slow work thread pool: Starting up
>>>>> [ ? ?0.794932] Slow work thread pool: Ready
>>>>> [ ? ?0.794953] [drm] Initialized radeon 2.5.0 20080528 for
>>>>> :01:05.0 on minor 0
>>>>>
>>>>>
>>>>> Torsten
>>>>>
>>>>
>>
>> Does the attached patch works ? (try to change the if 0 to if 1 too
>
> The patch doesn't compile, but after changing mc->foo to rdev->mc.foo it
> built.
>
I discussed this with Jerome and I think we found the root cause.
Does this patch help?
Alex
> Result from the original patch ("if 0"):
> [ ? ?0.429603] [drm] initializing kernel modesetting (RS690 0x1002:0x791E).
> [ ? ?0.429751] [drm] register mmio base: 0xFE9F
> [ ? ?0.429809] [drm] register mmio size: 65536
> [ ? ?0.430385] ATOM BIOS: ATI
> [ ? ?0.430460] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF (32M
> used)
> [ ? ?0.430520] radeon :01:05.0: GTT: 512M 0xB000 - 0xCFFF
> [ ? ?0.430603] [drm] radeon: irq initialized.
> [ ? ?0.430666] mtrr: type mismatch for fc00,200 old:
> write-back new: write-combining
> [ ? ?0.430739] [drm] Detected VRAM RAM=32M, BAR=32M
> [ ? ?0.430797] [drm] RAM width 128bits DDR
> [ ? ?0.430940] [TTM] Zone ?kernel: Available graphics memory: 2010234 kiB.
> [ ? ?0.430999] [TTM] Initializing pool allocator.
> [ ? ?0.431075] [drm] radeon: 32M of VRAM memory ready
> [ ? ?0.431133] [drm] radeon: 512M of GTT memory ready.
> [ ? ?0.431194] [drm] GART: num cpu pages 131072, num gpu pages 131072
> [ ? ?0.434577] [drm] radeon: 1 quad pipes, 1 z pipes initialized.
> [ ? ?0.441645] [drm] Loading RS690/RS740 Microcode
> [ ? ?0.441853] [drm] radeon: ring at 0xB000
> [ ? ?0.576773] [drm:r100_ring_test] *ERROR* radeon: ring test failed
> (sracth(0x15E4)=0xCAFEDEAD)
> [ ? ?0.576847] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
> [ ? ?0.576907] radeon :01:05.0: failled initializing CP (-22).
> [ ? ?0.576965] radeon :01:05.0: Disabling GPU acceleration
>
> Result from patch after changing it to "if 1":
> [ ? ?0.400348] [drm] initializing kernel modesetting (RS690 0x1002:0x791E).
> [ ? ?0.400497] [drm] register mmio base: 0xFE9F
> [ ? ?0.400556] [drm] register mmio size: 65536
> [ ? ?0.401097] ATOM BIOS: ATI
> [ ? ?0.401171] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF (32M
> used)
> [ ? ?0.401231] radeon :01:05.0: GTT: 512M 0x - 0x1FFF
> [ ? ?0.401314] [drm] radeon: irq initialized.
> [ ? ?0.401377] mtrr: type mismatch for fc00,200 old:
> write-back new: write-combining
> [ ? ?0.401451] [drm] Detected VRAM RAM=32M, BAR=32M
> [ ? ?0.401509] [drm] RAM width 128bits DDR
> [ ? ?0.401597] [TTM] Zone ?kernel: Available graphics memory: 2010234 kiB.
> [ ? ?0.401656] [TTM] Initializing pool allocator.
> [ ? ?0.401732] [drm] radeon: 32M of VRAM memory ready
> [ ? ?0.401791] [drm] radeon: 512M of GTT memory ready.
> [ ? ?0.401852] [drm] GART: num cpu pages 131072, num gpu pages 131072
> [ ? ?0.405242] [drm] radeon: 1 quad pipes, 1 z pipes initialized.
> [ ? ?0.412298] [drm] Loading RS690/RS740 Microcode
> [ ? ?0.412507] [drm] radeon: ring at 0x
> [ ? ?0.412582] [drm] ring test succeeded in 1 usecs
> [ ? ?0.412726] [drm] radeon: ib pool ready.
> [ ? ?0.412792] [drm] ib test succeeded in 0 usecs
>
> Torsten
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-kms-fix-gtt-MC-base-alignment-on-rs4xx-rs.patch
Type: text/x-patch
Size: 7692 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100714/3fcdd1f7/attachment-0001.bin>
Regression 2.6.34->2.6.35-rc4: radeaon KMS an RS690 broken
On 07/14/2010 04:05 PM, Torsten Kaiser wrote: > On Wed, Jul 14, 2010 at 9:30 PM, Jerome Glisse > wrote: >> On 07/14/2010 02:51 PM, Torsten Kaiser wrote: >>> >>> On Tue, Jul 13, 2010 at 9:10 PM, Alex Deucher >>> wrote: On Tue, Jul 13, 2010 at 2:29 PM, Torsten Kaiser wrote: > > But the CP is still broken: Is this a regression? If so, can you bisect it? Alex >>> >>> I bisected it to this commit: >>> >>> d594e46ace22afa1621254f6f669e65430048153 is the first bad commit >>> commit d594e46ace22afa1621254f6f669e65430048153 >>> Author: Jerome Glisse >>> Date: Wed Feb 17 21:54:29 2010 + >>> >>> drm/radeon/kms: simplify memory controller setup V2 >>> >>> Get rid of _location and use _start/_end also simplify the >>> computation of vram_start|end>t_start|end. For R1XX-R2XX >>> we place VRAM at the same address of PCI aperture, those GPU >>> shouldn't have much memory and seems to behave better when >>> setup that way. For R3XX and newer we place VRAM at 0. For >>> R6XX-R7XX AGP we place VRAM before or after AGP aperture this >>> might limit to limit the VRAM size but it's very unlikely. >>> For IGP we don't change the VRAM placement. >>> >>> Tested on (compiz,quake3,suspend/resume): >>> PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710 >>> AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730 >>> IGP:RS480(RPB*),RS690,RS780(RPB*),RS880 >>> >>> RPB: resume previously broken >>> >>> V2 correct commit message to reflect more accurately the bug >>> and move VRAM placement to 0 for most of the GPU to avoid >>> limiting VRAM. >>> >>> Signed-off-by: Jerome Glisse >>> Signed-off-by: Dave Airlie >>> >>> :04 04 05c1e456fcf6565aa8711e4933807956d0055cca >>> 792c6be2bd161a52500c5e8d685ee651cd5af07e M drivers >>> >>> HTH, Torsten >>> > [0.426931] Linux agpgart interface v0.103 > [0.427092] [drm] Initialized drm 1.1.0 20060810 > [0.427196] [drm] radeon defaulting to kernel modesetting. > [0.427255] [drm] radeon kernel modesetting enabled. > [0.427372] radeon :01:05.0: PCI INT A ->GSI 18 (level, low) -> > IRQ 18 > [0.429659] [drm] initializing kernel modesetting (RS690 > 0x1002:0x791E). > [0.429817] [drm] register mmio base: 0xFE9F > [0.429876] [drm] register mmio size: 65536 > [0.430457] ATOM BIOS: ATI > [0.430532] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF > (32M used) > [0.430592] radeon :01:05.0: GTT: 512M 0xBE00 - 0xDDFF > [0.430675] [drm] radeon: irq initialized. > [0.430737] mtrr: type mismatch for fc00,200 old: > write-back new: write-comb > ining > [0.430811] [drm] Detected VRAM RAM=32M, BAR=32M > [0.430868] [drm] RAM width 128bits DDR > [0.431011] [TTM] Zone kernel: Available graphics memory: 2010234 > kiB. > [0.431070] [TTM] Initializing pool allocator. > [0.431147] [drm] radeon: 32M of VRAM memory ready > [0.431205] [drm] radeon: 512M of GTT memory ready. > [0.431266] [drm] GART: num cpu pages 131072, num gpu pages 131072 > [0.434654] [drm] radeon: 1 quad pipes, 1 z pipes initialized. > [0.441719] [drm] Loading RS690/RS740 Microcode > [0.441926] [drm] radeon: ring at 0xBE00 > [0.577118] [drm:r100_ring_test] *ERROR* radeon: ring test failed > (sracth(0x15E4)=0x > CAFEDEAD) > [0.577192] [drm:r100_cp_init] *ERROR* radeon: cp isn't working > (-22). > [0.577252] radeon :01:05.0: failled initializing CP (-22). > [0.577310] radeon :01:05.0: Disabling GPU acceleration > [0.577440] [drm] radeon: cp finalized > [0.578078] [drm] Default TV standard: NTSC > [0.578314] [drm] Default TV standard: NTSC > [0.578590] [drm] Radeon Display Connectors > [0.578648] [drm] Connector 0: > [0.578706] [drm] VGA > [0.578764] [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 > 0x7e5c 0x7e4c > [0.578837] [drm] Encoders: > [0.578894] [drm] CRT1: INTERNAL_KLDSCP_DAC1 > [0.578952] [drm] Connector 1: > [0.579010] [drm] S-video > [0.579067] [drm] Encoders: > [0.579124] [drm] TV1: INTERNAL_KLDSCP_DAC1 > [0.579182] [drm] Connector 2: > [0.579239] [drm] HDMI-A > [0.579297] [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 > 0x7e4c 0x7e5c > [0.579369] [drm] Encoders: > [0.579427] [drm] DFP3: INTERNAL_LVTM1 > [0.773375] [drm] fb mappable at 0xFC04 > [0.773434] [drm] vram apper at 0xFC00 > [0.773491] [drm] size 786432 > [0.773549] [drm] fb depth is 8 > [0.773606] [drm]pitch is 1024 > [0.773737] fbcon: radeondrmfb (fb0) is primary device > [
[Bug 29067] New: WebGL in Firefox is very slow (pegs the cpu)
https://bugs.freedesktop.org/show_bug.cgi?id=29067 Summary: WebGL in Firefox is very slow (pegs the cpu) Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: sa at whiz.se WebGL in Firefox (4.0b1) is very slow on r300g, it seems to be using an excessive amount of CPU, this is not the case in Chrome, where things seem to be working very well. I'm not really sure if this is a bug in the driver, or in Firefox, but on i965 performance seems to be the same in both browsers. This problem is very noticeable in demos which measure framerate, such as: http://cs.helsinki.fi/u/ilmarihe/demo/demo.html http://cs.helsinki.fi/u/ilmarihe/demo2/paint.html Another good test is an interactive demo like the teapot, where lag is noticable: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/google/shiny-teapot/index.html WebGL requires support for pbuffers (for both Firefox and Chrome) so Xserver 1.9.0 is required. For more general tips on getting webgl running see: http://learningwebgl.com/blog/?p=11 System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: 6.13.1 -- xserver: 1.8.99.904 (1.9.0 RC 4) -- mesa: f8d81c31cee30821da3aab331a57f484f6a07a5d -- drm: 6ea2bda5f5ec8f27359760ce580fdad3df0464df -- kernel: 2.6.35-rc5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Regression 2.6.34->2.6.35-rc4: radeaon KMS an RS690 broken
On Wed, Jul 14, 2010 at 2:51 PM, Torsten Kaiser wrote: > On Tue, Jul 13, 2010 at 9:10 PM, Alex Deucher > wrote: >> On Tue, Jul 13, 2010 at 2:29 PM, Torsten Kaiser >> wrote: >>> But the CP is still broken: >> >> Is this a regression? ?If so, can you bisect it? >> >> Alex > > I bisected it to this commit: Jerome, Any thoughts? I got another report of the CP being broken an an rs690 on IRC as well. Looks like the checks that clipped vram based on the aperture size got removed on rs600 and rs690. Also, I think ideally we want always want mc_vram_size and the internal MC vram map to always be the actual vram size while the part we expose to the memory manager should be clipped to the aperture size. I think that was the root cause of the old brightness lockup bug since there is a bios scratch area usually at the end of vram which causes problems if we've limited the MC's vram map. Alex > > d594e46ace22afa1621254f6f669e65430048153 is the first bad commit > commit d594e46ace22afa1621254f6f669e65430048153 > Author: Jerome Glisse > Date: ? Wed Feb 17 21:54:29 2010 + > > ? ?drm/radeon/kms: simplify memory controller setup V2 > > ? ?Get rid of _location and use _start/_end also simplify the > ? ?computation of vram_start|end & gtt_start|end. For R1XX-R2XX > ? ?we place VRAM at the same address of PCI aperture, those GPU > ? ?shouldn't have much memory and seems to behave better when > ? ?setup that way. For R3XX and newer we place VRAM at 0. For > ? ?R6XX-R7XX AGP we place VRAM before or after AGP aperture this > ? ?might limit to limit the VRAM size but it's very unlikely. > ? ?For IGP we don't change the VRAM placement. > > ? ?Tested on (compiz,quake3,suspend/resume): > ? ?PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710 > ? ?AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730 > ? ?IGP:RS480(RPB*),RS690,RS780(RPB*),RS880 > > ? ?RPB: resume previously broken > > ? ?V2 correct commit message to reflect more accurately the bug > ? ?and move VRAM placement to 0 for most of the GPU to avoid > ? ?limiting VRAM. > > ? ?Signed-off-by: Jerome Glisse > ? ?Signed-off-by: Dave Airlie > > :04 04 05c1e456fcf6565aa8711e4933807956d0055cca > 792c6be2bd161a52500c5e8d685ee651cd5af07e M ? ? drivers > > HTH, Torsten > >>> [ ? ?0.426931] Linux agpgart interface v0.103 >>> [ ? ?0.427092] [drm] Initialized drm 1.1.0 20060810 >>> [ ? ?0.427196] [drm] radeon defaulting to kernel modesetting. >>> [ ? ?0.427255] [drm] radeon kernel modesetting enabled. >>> [ ? ?0.427372] radeon :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ >>> 18 >>> [ ? ?0.429659] [drm] initializing kernel modesetting (RS690 0x1002:0x791E). >>> [ ? ?0.429817] [drm] register mmio base: 0xFE9F >>> [ ? ?0.429876] [drm] register mmio size: 65536 >>> [ ? ?0.430457] ATOM BIOS: ATI >>> [ ? ?0.430532] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF (32M >>> used) >>> [ ? ?0.430592] radeon :01:05.0: GTT: 512M 0xBE00 - 0xDDFF >>> [ ? ?0.430675] [drm] radeon: irq initialized. >>> [ ? ?0.430737] mtrr: type mismatch for fc00,200 old: >>> write-back new: write-comb >>> ining >>> [ ? ?0.430811] [drm] Detected VRAM RAM=32M, BAR=32M >>> [ ? ?0.430868] [drm] RAM width 128bits DDR >>> [ ? ?0.431011] [TTM] Zone ?kernel: Available graphics memory: 2010234 kiB. >>> [ ? ?0.431070] [TTM] Initializing pool allocator. >>> [ ? ?0.431147] [drm] radeon: 32M of VRAM memory ready >>> [ ? ?0.431205] [drm] radeon: 512M of GTT memory ready. >>> [ ? ?0.431266] [drm] GART: num cpu pages 131072, num gpu pages 131072 >>> [ ? ?0.434654] [drm] radeon: 1 quad pipes, 1 z pipes initialized. >>> [ ? ?0.441719] [drm] Loading RS690/RS740 Microcode >>> [ ? ?0.441926] [drm] radeon: ring at 0xBE00 >>> [ ? ?0.577118] [drm:r100_ring_test] *ERROR* radeon: ring test failed >>> (sracth(0x15E4)=0x >>> CAFEDEAD) >>> [ ? ?0.577192] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). >>> [ ? ?0.577252] radeon :01:05.0: failled initializing CP (-22). >>> [ ? ?0.577310] radeon :01:05.0: Disabling GPU acceleration >>> [ ? ?0.577440] [drm] radeon: cp finalized >>> [ ? ?0.578078] [drm] Default TV standard: NTSC >>> [ ? ?0.578314] [drm] Default TV standard: NTSC >>> [ ? ?0.578590] [drm] Radeon Display Connectors >>> [ ? ?0.578648] [drm] Connector 0: >>> [ ? ?0.578706] [drm] ? VGA >>> [ ? ?0.578764] [drm] ? DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 >>> 0x7e5c 0x7e4c >>> [ ? ?0.578837] [drm] ? Encoders: >>> [ ? ?0.578894] [drm] ? ? CRT1: INTERNAL_KLDSCP_DAC1 >>> [ ? ?0.578952] [drm] Connector 1: >>> [ ? ?0.579010] [drm] ? S-video >>> [ ? ?0.579067] [drm] ? Encoders: >>> [ ? ?0.579124] [drm] ? ? TV1: INTERNAL_KLDSCP_DAC1 >>> [ ? ?0.579182] [drm] Connector 2: >>> [ ? ?0.579239] [drm] ? HDMI-A >>> [ ? ?0.579297] [drm] ? DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 >>> 0x7e4c 0x7e5c >>> [ ? ?0.579369] [drm] ? Encoders: >>> [ ? ?0.579427] [drm] ? ? DFP3: INTERNAL_LVTM1 >>> [ ? ?0.773375] [drm] fb mappable at 0xFC04 >>> [ ? ?0.773434] [drm] vram apper at
Regression 2.6.34->2.6.35-rc4: radeaon KMS an RS690 broken
t;>> [0.773375] [drm] fb mappable at 0xFC04 >>> [0.773434] [drm] vram apper at 0xFC00 >>> [0.773491] [drm] size 786432 >>> [0.773549] [drm] fb depth is 8 >>> [0.773606] [drm]pitch is 1024 >>> [0.773737] fbcon: radeondrmfb (fb0) is primary device >>> [0.793240] Console: switching to colour frame buffer device 128x48 >>> [0.794833] fb0: radeondrmfb frame buffer device >>> [0.794852] drm: registered panic notifier >>> [0.794871] Slow work thread pool: Starting up >>> [0.794932] Slow work thread pool: Ready >>> [0.794953] [drm] Initialized radeon 2.5.0 20080528 for >>> :01:05.0 on minor 0 >>> >>> >>> Torsten >>> >> Does the attached patch works ? (try to change the if 0 to if 1 too Cheers, Jerome -- next part -- An embedded and charset-unspecified text was scrubbed... Name: 0001-HACK-RS690.patch URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100714/dd11263b/attachment.asc>
[PATCH] HACK RS690
--- drivers/gpu/drm/radeon/rs690.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/rs690.c b/drivers/gpu/drm/radeon/rs690.c index 23676b6..9dd9c6d 100644 --- a/drivers/gpu/drm/radeon/rs690.c +++ b/drivers/gpu/drm/radeon/rs690.c @@ -162,7 +162,15 @@ void rs690_mc_init(struct radeon_device *rdev) rs690_pm_info(rdev); rdev->mc.igp_sideport_enabled = radeon_atombios_sideport_present(rdev); radeon_vram_location(rdev, >mc, base); - radeon_gtt_location(rdev, >mc); +// radeon_gtt_location(rdev, >mc); +#if 0 + mc->gtt_start = 0; +#else + mc->gtt_start = 0xB000; +#endif + mc->gtt_end = mc->gtt_start + mc->gtt_size - 1; + dev_info(rdev->dev, "GTT: %lluM 0x%08llX - 0x%08llX\n", + mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end); radeon_update_bandwidth_info(rdev); } -- 1.7.1 --020904090508030502060707--
[Bug 29062] hp dv5000: xpress 200m 5955 + KMS does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=29062 --- Comment #3 from Dave Airlie 2010-07-14 14:13:34 PDT --- 580b4fffbbdc3c899ee1f8189ba321bd60b48840 in Linus tree is a quirk for my rs48x laptop, you try expanding it to cover your laptop, or just force it on for testing. drm/radeon: add quirk to make HP nx6125 laptop resume -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29066] pipes triggers Assertion `boi->space_accounted' failed
https://bugs.freedesktop.org/show_bug.cgi?id=29066 Tormod Volden changed: What|Removed |Added Attachment #37056|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29066] pipes triggers Assertion `boi->space_accounted' failed
https://bugs.freedesktop.org/show_bug.cgi?id=29066 --- Comment #1 from Tormod Volden 2010-07-14 14:02:37 PDT --- Created an attachment (id=37057) --> (https://bugs.freedesktop.org/attachment.cgi?id=37057) dmesg output including gallium run -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29066] New: pipes triggers Assertion `boi->space_accounted' failed
https://bugs.freedesktop.org/show_bug.cgi?id=29066 Summary: pipes triggers Assertion `boi->space_accounted' failed Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: bugzi09.fdo.tormod at xoxy.net Created an attachment (id=37056) --> (https://bugs.freedesktop.org/attachment.cgi?id=37056) full backtrace (classic driver from git) Originally reported on Ubuntu 10.04 in https://bugs.launchpad.net/bugs/602267 and the user has also tested latest git, classic and gallium. Running "pipes" from xscreensaver crashes on RS482 with this message: pipes: ../../radeon/radeon_cs_gem.c:129: cs_gem_write_reloc: Assertion `boi->space_accounted' failed. (see attached backtrace) With gallium, it does not crash but this message is seen: radeon: The kernel rejected CS, see dmesg for more information. dmesg contains: [drm:r100_cs_packet_parse] *ERROR* Packet (351:3:16383) end after CS buffer (1020) ! [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! Hardware: 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS482 [Radeon Xpress 200M] [1002:5975] Subsystem: NEC Corporation Device [1033:8800] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions
https://bugs.freedesktop.org/show_bug.cgi?id=28860 Sven Arvidsson changed: What|Removed |Added Attachment #36892|0 |1 is obsolete|| --- Comment #11 from Sven Arvidsson 2010-07-14 12:37:34 PDT --- Created an attachment (id=37050) --> (https://bugs.freedesktop.org/attachment.cgi?id=37050) Yo Frankie screenshot Awesome, thanks for taking an interest! It's still not working correctly, I'm attaching a new screenshot. I'm also getting these errors now: radeon: The kernel rejected CS, see dmesg for more information. Jul 14 21:28:43 zoe kernel: [21717.383601] [drm:r100_cs_track_check] *ERROR* [drm] Buffer too small for color buffer 0 (need 1310720 have 1228800) ! Jul 14 21:28:43 zoe kernel: [21717.383605] [drm:r100_cs_track_check] *ERROR* [drm] color buffer 0 (640 4 0 512) Jul 14 21:28:43 zoe kernel: [21717.383607] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! The log file at http://whiz.se/temp/yofrankie-fp.log.gz has been updated. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29062] hp dv5000: xpress 200m 5955 + KMS does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=29062 Andres Cimmarusti changed: What|Removed |Added Attachment #37046|dmesg just after failed |dmesg description|resume | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29062] hp dv5000: xpress 200m 5955 + KMS does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=29062 Andres Cimmarusti changed: What|Removed |Added Attachment #37047|My current Xorg log |Xorg0.log description|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29062] hp dv5000: xpress 200m 5955 + KMS does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=29062 --- Comment #2 from Andres Cimmarusti 2010-07-14 12:03:36 PDT --- Created an attachment (id=37048) --> (https://bugs.freedesktop.org/attachment.cgi?id=37048) lspci -v -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29062] hp dv5000: xpress 200m 5955 + KMS does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=29062 --- Comment #1 from Andres Cimmarusti 2010-07-14 12:01:55 PDT --- Created an attachment (id=37047) --> (https://bugs.freedesktop.org/attachment.cgi?id=37047) My current Xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29062] New: hp dv5000: xpress 200m 5955 + KMS does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=29062 Summary: hp dv5000: xpress 200m 5955 + KMS does not resume from suspend Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: acimmarusti at gmail.com Created an attachment (id=37046) --> (https://bugs.freedesktop.org/attachment.cgi?id=37046) dmesg just after failed resume When I try suspending using KMS my computer (an HP Pavilion dv5035nr laptop) does not resume. Furthermore I've tried logging into it remotely to obtain a backtrace from X with no success (following this procedure: http://ubuntuforums.org/showthread.php?t=1228332). I'm letting NetworkManager handle my network interfaces, however, I also tried using dhcp directly in the /etc/network/interfaces file. The laptop screen is completely blank so I can't switch to another session. The keyboard doesn't respond so it seems like the kernel crashed. When using UMS the resume process happens perfectly. I dedicated a large portion of the day to finding a clue to this one. Following this advice: http://lxr.linux.no/#linux+v2.6.34.1/Documentation/power/s2ram.txt I was able to extract a trace from the failed resume process: Magic number: 0:981:799 hash matches drivers/base/power/main.c:523 pci :01:05.0: hash matches ec PNP0C09:00: hash matches The first hash match is none other than my ATI Radeon card as I easily verified with lspci: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon XPRESS 200M 5955 (PCIE) However, the above link says that the likely culprit in the failed resume process is the last hash match. This corresponds to the EC driver: http://lxr.free-electrons.com/source/drivers/acpi/ec.c My card was, till recently, listed under embedded graphics at the AMD/ATI website. So there appears to be some conflict when using KMS between radeon and ec that causes the kernel to hang (that explains why I can't ssh into my computer to get a trace). I would appreciate some advice and guidance in further debugging this issue, since I'm flying half-blind. I have compiled my kernel with support for ACPI_DEBUG and I included a quirk David Airlie used to get suspend to work with a HP nx6125 laptop but applied for my model (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=580b4fffbbdc3c899ee1f8189ba321bd60b48840) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #13 from Andy Furniss 2010-07-14 05:04:35 PDT --- (In reply to comment #12) > Created an attachment (id=37035) View: https://bugs.freedesktop.org/attachment.cgi?id=37035 Review: https://bugs.freedesktop.org/review?bug=28341=37035 > Revert xf86-video-ati commit 30591320ec46e491ba20904cc64f3405b51c6505 That fixes my two test cases - ipers and sauerbraten. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #12 from Michel D?nzer 2010-07-14 04:22:20 PDT --- Created an attachment (id=37035) View: https://bugs.freedesktop.org/attachment.cgi?id=37035 Review: https://bugs.freedesktop.org/review?bug=28341=37035 Revert xf86-video-ati commit 30591320ec46e491ba20904cc64f3405b51c6505 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341
--- Comment #11 from Andy Furniss 2010-07-14
04:03:15 PDT ---
(In reply to comment #10)
> Does reverting xf86-video-ati Git commit
> 30591320ec46e491ba20904cc64f3405b51c6505 ('kms: add support for the MSC swap &
> sync API') fix this problem?
It doesn't revert on master for me.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341
--- Comment #10 from Michel D?nzer 2010-07-14 02:30:55
PDT ---
Does reverting xf86-video-ati Git commit
30591320ec46e491ba20904cc64f3405b51c6505 ('kms: add support for the MSC swap &
sync API') fix this problem?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions
https://bugs.freedesktop.org/show_bug.cgi?id=28860 --- Comment #10 from Tom Stellard 2010-07-13 23:10:59 PDT --- Created an attachment (id=37010) View: https://bugs.freedesktop.org/attachment.cgi?id=37010 Review: https://bugs.freedesktop.org/review?bug=28860=37010 Hacked together presubtract support Can you try again with this patch applied to master and post the output with RADEON_DEBUG=fp. Also, if you notice anything new that this patch breaks, 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.
[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions
https://bugs.freedesktop.org/show_bug.cgi?id=28860 --- Comment #10 from Tom Stellard tstel...@gmail.com 2010-07-13 23:10:59 PDT --- Created an attachment (id=37010) View: https://bugs.freedesktop.org/attachment.cgi?id=37010 Review: https://bugs.freedesktop.org/review?bug=28860attachment=37010 Hacked together presubtract support Can you try again with this patch applied to master and post the output with RADEON_DEBUG=fp. Also, if you notice anything new that this patch breaks, 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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341
--- Comment #10 from Michel Dänzer mic...@daenzer.net 2010-07-14 02:30:55 PDT
---
Does reverting xf86-video-ati Git commit
30591320ec46e491ba20904cc64f3405b51c6505 ('kms: add support for the MSC swap
sync API') fix this problem?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341
--- Comment #11 from Andy Furniss li...@andyfurniss.entadsl.com 2010-07-14
04:03:15 PDT ---
(In reply to comment #10)
Does reverting xf86-video-ati Git commit
30591320ec46e491ba20904cc64f3405b51c6505 ('kms: add support for the MSC swap
sync API') fix this problem?
It doesn't revert on master for me.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #12 from Michel Dänzer mic...@daenzer.net 2010-07-14 04:22:20 PDT --- Created an attachment (id=37035) View: https://bugs.freedesktop.org/attachment.cgi?id=37035 Review: https://bugs.freedesktop.org/review?bug=28341attachment=37035 Revert xf86-video-ati commit 30591320ec46e491ba20904cc64f3405b51c6505 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28341] Flickering screen in Neverball on drm-radeon-testing
https://bugs.freedesktop.org/show_bug.cgi?id=28341 --- Comment #13 from Andy Furniss li...@andyfurniss.entadsl.com 2010-07-14 05:04:35 PDT --- (In reply to comment #12) Created an attachment (id=37035) View: https://bugs.freedesktop.org/attachment.cgi?id=37035 Review: https://bugs.freedesktop.org/review?bug=28341attachment=37035 Revert xf86-video-ati commit 30591320ec46e491ba20904cc64f3405b51c6505 That fixes my two test cases - ipers and sauerbraten. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: fixed brace, spacing and whitespace coding style issues
Fixed brace, spacing and whitespace coding style issues.
Signed-off-by: Nicolas Kaiser ni...@nikai.net
---
drivers/gpu/drm/ati_pcigart.c |9 ++--
drivers/gpu/drm/drm_agpsupport.c| 15 +++
drivers/gpu/drm/drm_bufs.c | 49
drivers/gpu/drm/drm_context.c | 17 +++
drivers/gpu/drm/drm_crtc.c | 53 -
drivers/gpu/drm/drm_crtc_helper.c |7 +--
drivers/gpu/drm/drm_dma.c |7 +--
drivers/gpu/drm/drm_dp_i2c_helper.c |5 +-
drivers/gpu/drm/drm_drawable.c |3 +-
drivers/gpu/drm/drm_drv.c |9 +---
drivers/gpu/drm/drm_edid.c | 21 -
drivers/gpu/drm/drm_fb_helper.c | 32 +++---
drivers/gpu/drm/drm_fops.c |8 ++--
drivers/gpu/drm/drm_hashtab.c | 13 ++---
drivers/gpu/drm/drm_ioc32.c |1 -
drivers/gpu/drm/drm_irq.c |4 +-
drivers/gpu/drm/drm_lock.c | 11 ++---
drivers/gpu/drm/drm_memory.c| 10 ++--
drivers/gpu/drm/drm_mm.c|7 +--
drivers/gpu/drm/drm_modes.c |3 +-
drivers/gpu/drm/drm_pci.c |6 +--
drivers/gpu/drm/drm_proc.c |2 +-
drivers/gpu/drm/drm_scatter.c |4 +-
drivers/gpu/drm/drm_sman.c | 34 --
drivers/gpu/drm/drm_stub.c | 26 +--
drivers/gpu/drm/drm_sysfs.c | 86 +-
drivers/gpu/drm/drm_vm.c|7 +--
27 files changed, 191 insertions(+), 258 deletions(-)
diff --git a/drivers/gpu/drm/ati_pcigart.c b/drivers/gpu/drm/ati_pcigart.c
index 17be051..a8df5e9 100644
--- a/drivers/gpu/drm/ati_pcigart.c
+++ b/drivers/gpu/drm/ati_pcigart.c
@@ -141,11 +141,10 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
pages = (entry-pages = max_real_pages)
? entry-pages : max_real_pages;
- if (gart_info-gart_table_location == DRM_ATI_GART_MAIN) {
+ if (gart_info-gart_table_location == DRM_ATI_GART_MAIN)
memset(pci_gart, 0, max_ati_pages * sizeof(u32));
- } else {
+ else
memset_io((void __iomem *)map-handle, 0, max_ati_pages *
sizeof(u32));
- }
gart_idx = 0;
for (i = 0; i pages; i++) {
@@ -164,7 +163,7 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
for (j = 0; j (PAGE_SIZE / ATI_PCIGART_PAGE_SIZE); j++) {
u32 val;
- switch(gart_info-gart_reg_if) {
+ switch (gart_info-gart_reg_if) {
case DRM_ATI_GART_IGP:
val = page_base | 0xc;
break;
@@ -193,7 +192,7 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
mb();
#endif
- done:
+done:
gart_info-addr = address;
gart_info-bus_addr = bus_address;
return ret;
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index ba38e01..91ca82d 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -71,7 +71,6 @@ int drm_agp_info(struct drm_device *dev, struct drm_agp_info
*info)
return 0;
}
-
EXPORT_SYMBOL(drm_agp_info);
int drm_agp_info_ioctl(struct drm_device *dev, void *data,
@@ -96,7 +95,7 @@ int drm_agp_info_ioctl(struct drm_device *dev, void *data,
* Verifies the AGP device hasn't been acquired before and calls
* \c agp_backend_acquire.
*/
-int drm_agp_acquire(struct drm_device * dev)
+int drm_agp_acquire(struct drm_device *dev)
{
if (!dev-agp)
return -ENODEV;
@@ -107,7 +106,6 @@ int drm_agp_acquire(struct drm_device * dev)
dev-agp-acquired = 1;
return 0;
}
-
EXPORT_SYMBOL(drm_agp_acquire);
/**
@@ -136,7 +134,7 @@ int drm_agp_acquire_ioctl(struct drm_device *dev, void
*data,
*
* Verifies the AGP device has been acquired and calls \c agp_backend_release.
*/
-int drm_agp_release(struct drm_device * dev)
+int drm_agp_release(struct drm_device *dev)
{
if (!dev-agp || !dev-agp-acquired)
return -EINVAL;
@@ -162,7 +160,7 @@ int drm_agp_release_ioctl(struct drm_device *dev, void
*data,
* Verifies the AGP device has been acquired but not enabled, and calls
* \c agp_enable.
*/
-int drm_agp_enable(struct drm_device * dev, struct drm_agp_mode mode)
+int drm_agp_enable(struct drm_device *dev, struct drm_agp_mode mode)
{
if (!dev-agp || !dev-agp-acquired)
return -EINVAL;
@@ -172,7 +170,6 @@ int drm_agp_enable(struct drm_device * dev, struct
drm_agp_mode mode)
dev-agp-enabled = 1;
return 0;
}
-
EXPORT_SYMBOL(drm_agp_enable);
int drm_agp_enable_ioctl(struct drm_device *dev, void *data,
@@ -431,7 +428,7 @@ DRM_AGP_MEM *drm_agp_allocate_memory(struct agp_bridge_data
* bridge,
}
/** Calls
Re: Regression 2.6.34-2.6.35-rc4: radeaon KMS an RS690 broken
On Tue, Jul 13, 2010 at 9:10 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jul 13, 2010 at 2:29 PM, Torsten Kaiser just.for.l...@googlemail.com wrote: But the CP is still broken: Is this a regression? If so, can you bisect it? Alex I bisected it to this commit: d594e46ace22afa1621254f6f669e65430048153 is the first bad commit commit d594e46ace22afa1621254f6f669e65430048153 Author: Jerome Glisse jgli...@redhat.com Date: Wed Feb 17 21:54:29 2010 + drm/radeon/kms: simplify memory controller setup V2 Get rid of _location and use _start/_end also simplify the computation of vram_start|end gtt_start|end. For R1XX-R2XX we place VRAM at the same address of PCI aperture, those GPU shouldn't have much memory and seems to behave better when setup that way. For R3XX and newer we place VRAM at 0. For R6XX-R7XX AGP we place VRAM before or after AGP aperture this might limit to limit the VRAM size but it's very unlikely. For IGP we don't change the VRAM placement. Tested on (compiz,quake3,suspend/resume): PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710 AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730 IGP:RS480(RPB*),RS690,RS780(RPB*),RS880 RPB: resume previously broken V2 correct commit message to reflect more accurately the bug and move VRAM placement to 0 for most of the GPU to avoid limiting VRAM. Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com :04 04 05c1e456fcf6565aa8711e4933807956d0055cca 792c6be2bd161a52500c5e8d685ee651cd5af07e M drivers HTH, Torsten [ 0.426931] Linux agpgart interface v0.103 [ 0.427092] [drm] Initialized drm 1.1.0 20060810 [ 0.427196] [drm] radeon defaulting to kernel modesetting. [ 0.427255] [drm] radeon kernel modesetting enabled. [ 0.427372] radeon :01:05.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 0.429659] [drm] initializing kernel modesetting (RS690 0x1002:0x791E). [ 0.429817] [drm] register mmio base: 0xFE9F [ 0.429876] [drm] register mmio size: 65536 [ 0.430457] ATOM BIOS: ATI [ 0.430532] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF (32M used) [ 0.430592] radeon :01:05.0: GTT: 512M 0xBE00 - 0xDDFF [ 0.430675] [drm] radeon: irq initialized. [ 0.430737] mtrr: type mismatch for fc00,200 old: write-back new: write-comb ining [ 0.430811] [drm] Detected VRAM RAM=32M, BAR=32M [ 0.430868] [drm] RAM width 128bits DDR [ 0.431011] [TTM] Zone kernel: Available graphics memory: 2010234 kiB. [ 0.431070] [TTM] Initializing pool allocator. [ 0.431147] [drm] radeon: 32M of VRAM memory ready [ 0.431205] [drm] radeon: 512M of GTT memory ready. [ 0.431266] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 0.434654] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ 0.441719] [drm] Loading RS690/RS740 Microcode [ 0.441926] [drm] radeon: ring at 0xBE00 [ 0.577118] [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0x CAFEDEAD) [ 0.577192] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [ 0.577252] radeon :01:05.0: failled initializing CP (-22). [ 0.577310] radeon :01:05.0: Disabling GPU acceleration [ 0.577440] [drm] radeon: cp finalized [ 0.578078] [drm] Default TV standard: NTSC [ 0.578314] [drm] Default TV standard: NTSC [ 0.578590] [drm] Radeon Display Connectors [ 0.578648] [drm] Connector 0: [ 0.578706] [drm] VGA [ 0.578764] [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [ 0.578837] [drm] Encoders: [ 0.578894] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 0.578952] [drm] Connector 1: [ 0.579010] [drm] S-video [ 0.579067] [drm] Encoders: [ 0.579124] [drm] TV1: INTERNAL_KLDSCP_DAC1 [ 0.579182] [drm] Connector 2: [ 0.579239] [drm] HDMI-A [ 0.579297] [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [ 0.579369] [drm] Encoders: [ 0.579427] [drm] DFP3: INTERNAL_LVTM1 [ 0.773375] [drm] fb mappable at 0xFC04 [ 0.773434] [drm] vram apper at 0xFC00 [ 0.773491] [drm] size 786432 [ 0.773549] [drm] fb depth is 8 [ 0.773606] [drm] pitch is 1024 [ 0.773737] fbcon: radeondrmfb (fb0) is primary device [ 0.793240] Console: switching to colour frame buffer device 128x48 [ 0.794833] fb0: radeondrmfb frame buffer device [ 0.794852] drm: registered panic notifier [ 0.794871] Slow work thread pool: Starting up [ 0.794932] Slow work thread pool: Ready [ 0.794953] [drm] Initialized radeon 2.5.0 20080528 for :01:05.0 on minor 0 Torsten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29062] New: hp dv5000: xpress 200m 5955 + KMS does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=29062 Summary: hp dv5000: xpress 200m 5955 + KMS does not resume from suspend Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: acimmaru...@gmail.com Created an attachment (id=37046) -- (https://bugs.freedesktop.org/attachment.cgi?id=37046) dmesg just after failed resume When I try suspending using KMS my computer (an HP Pavilion dv5035nr laptop) does not resume. Furthermore I've tried logging into it remotely to obtain a backtrace from X with no success (following this procedure: http://ubuntuforums.org/showthread.php?t=1228332). I'm letting NetworkManager handle my network interfaces, however, I also tried using dhcp directly in the /etc/network/interfaces file. The laptop screen is completely blank so I can't switch to another session. The keyboard doesn't respond so it seems like the kernel crashed. When using UMS the resume process happens perfectly. I dedicated a large portion of the day to finding a clue to this one. Following this advice: http://lxr.linux.no/#linux+v2.6.34.1/Documentation/power/s2ram.txt I was able to extract a trace from the failed resume process: Magic number: 0:981:799 hash matches drivers/base/power/main.c:523 pci :01:05.0: hash matches ec PNP0C09:00: hash matches The first hash match is none other than my ATI Radeon card as I easily verified with lspci: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon XPRESS 200M 5955 (PCIE) However, the above link says that the likely culprit in the failed resume process is the last hash match. This corresponds to the EC driver: http://lxr.free-electrons.com/source/drivers/acpi/ec.c My card was, till recently, listed under embedded graphics at the AMD/ATI website. So there appears to be some conflict when using KMS between radeon and ec that causes the kernel to hang (that explains why I can't ssh into my computer to get a trace). I would appreciate some advice and guidance in further debugging this issue, since I'm flying half-blind. I have compiled my kernel with support for ACPI_DEBUG and I included a quirk David Airlie used to get suspend to work with a HP nx6125 laptop but applied for my model (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=580b4fffbbdc3c899ee1f8189ba321bd60b48840) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29062] hp dv5000: xpress 200m 5955 + KMS does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=29062 --- Comment #1 from Andres Cimmarusti acimmaru...@gmail.com 2010-07-14 12:01:55 PDT --- Created an attachment (id=37047) -- (https://bugs.freedesktop.org/attachment.cgi?id=37047) My current Xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29062] hp dv5000: xpress 200m 5955 + KMS does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=29062 Andres Cimmarusti acimmaru...@gmail.com changed: What|Removed |Added Attachment #37047|My current Xorg log |Xorg0.log description|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm: refresh rate down to 60 Hz in 2.6.35-rc5
[ Resending to the right mailing list. I looked up in MAINTAINERS, but forgot to run git bisect reset and got the wrong address for dri-de...@. Apologies to all who receive this twice. ] After upgrading to 2.6.35-rc5, I noticed that my monitor reports a refresh rate of 60 Hz when nouveau.ko is loaded, rather than the 75 Hz I got on 2.6.34. Graphics card is an NV86 (GeForce 8500 GT), the monitor is a 1280x1024 TFT (Yakumo 19AL) connected via VGA. I bisected this to the following commit: --8---cut here---start-8--- commit c867df7043b738da4f4d358d7039c243a29b4272 Author: Adam Jackson a...@redhat.com Date: Mon Mar 29 21:43:21 2010 + drm/edid: Reshuffle mode list construction to closer match the spec Also, document what the spec says to do. Signed-off-by: Adam Jackson a...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 9c4717f..858fedc 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1377,10 +1377,24 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) quirks = edid_get_quirks(edid); - num_modes += add_established_modes(connector, edid); - num_modes += add_standard_modes(connector, edid); + /* +* EDID spec says modes should be preferred in this order: +* - preferred detailed mode +* - other detailed modes from base block +* - detailed modes from extension blocks +* - CVT 3-byte code modes +* - standard timing codes +* - established timing codes +* - modes inferred from GTF or CVT range information +* +* We don't quite implement this yet, but we're close. +* +* XXX order for additional mode types in extension blocks? +*/ num_modes += add_detailed_info(connector, edid, quirks); num_modes += add_detailed_info_eedid(connector, edid, quirks); + num_modes += add_standard_modes(connector, edid); + num_modes += add_established_modes(connector, edid); if (quirks (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75)) edid_fixup_preferred(connector, quirks); --8---cut here---end---8--- How do I get the 75 Hz refresh rate back? Adding video=1280x1...@75 as described in the nouveau wiki¹ has no effect. Regards, Sven ¹ http://nouveau.freedesktop.org/wiki/KernelModeSetting ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression 2.6.34-2.6.35-rc4: radeaon KMS an RS690 broken
On 07/14/2010 02:51 PM, Torsten Kaiser wrote: On Tue, Jul 13, 2010 at 9:10 PM, Alex Deucheralexdeuc...@gmail.com wrote: On Tue, Jul 13, 2010 at 2:29 PM, Torsten Kaiser just.for.l...@googlemail.com wrote: But the CP is still broken: Is this a regression? If so, can you bisect it? Alex I bisected it to this commit: d594e46ace22afa1621254f6f669e65430048153 is the first bad commit commit d594e46ace22afa1621254f6f669e65430048153 Author: Jerome Glissejgli...@redhat.com Date: Wed Feb 17 21:54:29 2010 + drm/radeon/kms: simplify memory controller setup V2 Get rid of _location and use _start/_end also simplify the computation of vram_start|end gtt_start|end. For R1XX-R2XX we place VRAM at the same address of PCI aperture, those GPU shouldn't have much memory and seems to behave better when setup that way. For R3XX and newer we place VRAM at 0. For R6XX-R7XX AGP we place VRAM before or after AGP aperture this might limit to limit the VRAM size but it's very unlikely. For IGP we don't change the VRAM placement. Tested on (compiz,quake3,suspend/resume): PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710 AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730 IGP:RS480(RPB*),RS690,RS780(RPB*),RS880 RPB: resume previously broken V2 correct commit message to reflect more accurately the bug and move VRAM placement to 0 for most of the GPU to avoid limiting VRAM. Signed-off-by: Jerome Glissejgli...@redhat.com Signed-off-by: Dave Airlieairl...@redhat.com :04 04 05c1e456fcf6565aa8711e4933807956d0055cca 792c6be2bd161a52500c5e8d685ee651cd5af07e M drivers HTH, Torsten [0.426931] Linux agpgart interface v0.103 [0.427092] [drm] Initialized drm 1.1.0 20060810 [0.427196] [drm] radeon defaulting to kernel modesetting. [0.427255] [drm] radeon kernel modesetting enabled. [0.427372] radeon :01:05.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [0.429659] [drm] initializing kernel modesetting (RS690 0x1002:0x791E). [0.429817] [drm] register mmio base: 0xFE9F [0.429876] [drm] register mmio size: 65536 [0.430457] ATOM BIOS: ATI [0.430532] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF (32M used) [0.430592] radeon :01:05.0: GTT: 512M 0xBE00 - 0xDDFF [0.430675] [drm] radeon: irq initialized. [0.430737] mtrr: type mismatch for fc00,200 old: write-back new: write-comb ining [0.430811] [drm] Detected VRAM RAM=32M, BAR=32M [0.430868] [drm] RAM width 128bits DDR [0.431011] [TTM] Zone kernel: Available graphics memory: 2010234 kiB. [0.431070] [TTM] Initializing pool allocator. [0.431147] [drm] radeon: 32M of VRAM memory ready [0.431205] [drm] radeon: 512M of GTT memory ready. [0.431266] [drm] GART: num cpu pages 131072, num gpu pages 131072 [0.434654] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [0.441719] [drm] Loading RS690/RS740 Microcode [0.441926] [drm] radeon: ring at 0xBE00 [0.577118] [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0x CAFEDEAD) [0.577192] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [0.577252] radeon :01:05.0: failled initializing CP (-22). [0.577310] radeon :01:05.0: Disabling GPU acceleration [0.577440] [drm] radeon: cp finalized [0.578078] [drm] Default TV standard: NTSC [0.578314] [drm] Default TV standard: NTSC [0.578590] [drm] Radeon Display Connectors [0.578648] [drm] Connector 0: [0.578706] [drm] VGA [0.578764] [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [0.578837] [drm] Encoders: [0.578894] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [0.578952] [drm] Connector 1: [0.579010] [drm] S-video [0.579067] [drm] Encoders: [0.579124] [drm] TV1: INTERNAL_KLDSCP_DAC1 [0.579182] [drm] Connector 2: [0.579239] [drm] HDMI-A [0.579297] [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [0.579369] [drm] Encoders: [0.579427] [drm] DFP3: INTERNAL_LVTM1 [0.773375] [drm] fb mappable at 0xFC04 [0.773434] [drm] vram apper at 0xFC00 [0.773491] [drm] size 786432 [0.773549] [drm] fb depth is 8 [0.773606] [drm]pitch is 1024 [0.773737] fbcon: radeondrmfb (fb0) is primary device [0.793240] Console: switching to colour frame buffer device 128x48 [0.794833] fb0: radeondrmfb frame buffer device [0.794852] drm: registered panic notifier [0.794871] Slow work thread pool: Starting up [0.794932] Slow work thread pool: Ready [0.794953] [drm] Initialized radeon 2.5.0 20080528 for :01:05.0 on minor 0 Torsten Does the attached patch works ? (try to change the if 0 to if 1 too Cheers, Jerome From c699536948731a37372dbc12062559265fcc2f3c Mon Sep 17 00:00:00 2001 From: Jerome Glisse jgli...@redhat.com Date: Wed, 14 Jul 2010 15:28:53 -0400
Re: Regression 2.6.34-2.6.35-rc4: radeaon KMS an RS690 broken
On Wed, Jul 14, 2010 at 2:51 PM, Torsten Kaiser just.for.l...@googlemail.com wrote: On Tue, Jul 13, 2010 at 9:10 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jul 13, 2010 at 2:29 PM, Torsten Kaiser just.for.l...@googlemail.com wrote: But the CP is still broken: Is this a regression? If so, can you bisect it? Alex I bisected it to this commit: Jerome, Any thoughts? I got another report of the CP being broken an an rs690 on IRC as well. Looks like the checks that clipped vram based on the aperture size got removed on rs600 and rs690. Also, I think ideally we want always want mc_vram_size and the internal MC vram map to always be the actual vram size while the part we expose to the memory manager should be clipped to the aperture size. I think that was the root cause of the old brightness lockup bug since there is a bios scratch area usually at the end of vram which causes problems if we've limited the MC's vram map. Alex d594e46ace22afa1621254f6f669e65430048153 is the first bad commit commit d594e46ace22afa1621254f6f669e65430048153 Author: Jerome Glisse jgli...@redhat.com Date: Wed Feb 17 21:54:29 2010 + drm/radeon/kms: simplify memory controller setup V2 Get rid of _location and use _start/_end also simplify the computation of vram_start|end gtt_start|end. For R1XX-R2XX we place VRAM at the same address of PCI aperture, those GPU shouldn't have much memory and seems to behave better when setup that way. For R3XX and newer we place VRAM at 0. For R6XX-R7XX AGP we place VRAM before or after AGP aperture this might limit to limit the VRAM size but it's very unlikely. For IGP we don't change the VRAM placement. Tested on (compiz,quake3,suspend/resume): PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710 AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730 IGP:RS480(RPB*),RS690,RS780(RPB*),RS880 RPB: resume previously broken V2 correct commit message to reflect more accurately the bug and move VRAM placement to 0 for most of the GPU to avoid limiting VRAM. Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com :04 04 05c1e456fcf6565aa8711e4933807956d0055cca 792c6be2bd161a52500c5e8d685ee651cd5af07e M drivers HTH, Torsten [ 0.426931] Linux agpgart interface v0.103 [ 0.427092] [drm] Initialized drm 1.1.0 20060810 [ 0.427196] [drm] radeon defaulting to kernel modesetting. [ 0.427255] [drm] radeon kernel modesetting enabled. [ 0.427372] radeon :01:05.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 0.429659] [drm] initializing kernel modesetting (RS690 0x1002:0x791E). [ 0.429817] [drm] register mmio base: 0xFE9F [ 0.429876] [drm] register mmio size: 65536 [ 0.430457] ATOM BIOS: ATI [ 0.430532] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF (32M used) [ 0.430592] radeon :01:05.0: GTT: 512M 0xBE00 - 0xDDFF [ 0.430675] [drm] radeon: irq initialized. [ 0.430737] mtrr: type mismatch for fc00,200 old: write-back new: write-comb ining [ 0.430811] [drm] Detected VRAM RAM=32M, BAR=32M [ 0.430868] [drm] RAM width 128bits DDR [ 0.431011] [TTM] Zone kernel: Available graphics memory: 2010234 kiB. [ 0.431070] [TTM] Initializing pool allocator. [ 0.431147] [drm] radeon: 32M of VRAM memory ready [ 0.431205] [drm] radeon: 512M of GTT memory ready. [ 0.431266] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 0.434654] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ 0.441719] [drm] Loading RS690/RS740 Microcode [ 0.441926] [drm] radeon: ring at 0xBE00 [ 0.577118] [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0x CAFEDEAD) [ 0.577192] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [ 0.577252] radeon :01:05.0: failled initializing CP (-22). [ 0.577310] radeon :01:05.0: Disabling GPU acceleration [ 0.577440] [drm] radeon: cp finalized [ 0.578078] [drm] Default TV standard: NTSC [ 0.578314] [drm] Default TV standard: NTSC [ 0.578590] [drm] Radeon Display Connectors [ 0.578648] [drm] Connector 0: [ 0.578706] [drm] VGA [ 0.578764] [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [ 0.578837] [drm] Encoders: [ 0.578894] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 0.578952] [drm] Connector 1: [ 0.579010] [drm] S-video [ 0.579067] [drm] Encoders: [ 0.579124] [drm] TV1: INTERNAL_KLDSCP_DAC1 [ 0.579182] [drm] Connector 2: [ 0.579239] [drm] HDMI-A [ 0.579297] [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [ 0.579369] [drm] Encoders: [ 0.579427] [drm] DFP3: INTERNAL_LVTM1 [ 0.773375] [drm] fb mappable at 0xFC04 [ 0.773434] [drm] vram apper at 0xFC00 [ 0.773491] [drm] size 786432 [ 0.773549] [drm] fb depth is 8 [
[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions
https://bugs.freedesktop.org/show_bug.cgi?id=28860 Sven Arvidsson s...@whiz.se changed: What|Removed |Added Attachment #36892|0 |1 is obsolete|| --- Comment #11 from Sven Arvidsson s...@whiz.se 2010-07-14 12:37:34 PDT --- Created an attachment (id=37050) -- (https://bugs.freedesktop.org/attachment.cgi?id=37050) Yo Frankie screenshot Awesome, thanks for taking an interest! It's still not working correctly, I'm attaching a new screenshot. I'm also getting these errors now: radeon: The kernel rejected CS, see dmesg for more information. Jul 14 21:28:43 zoe kernel: [21717.383601] [drm:r100_cs_track_check] *ERROR* [drm] Buffer too small for color buffer 0 (need 1310720 have 1228800) ! Jul 14 21:28:43 zoe kernel: [21717.383605] [drm:r100_cs_track_check] *ERROR* [drm] color buffer 0 (640 4 0 512) Jul 14 21:28:43 zoe kernel: [21717.383607] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! The log file at http://whiz.se/temp/yofrankie-fp.log.gz has been updated. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i810: fixed coding style issues
Fixed brace, macro and spacing coding style issues, and a C99 comment.
Signed-off-by: Nicolas Kaiser ni...@nikai.net
---
drivers/gpu/drm/i810/i810_dma.c | 81 ++
drivers/gpu/drm/i810/i810_drv.h | 64 ---
2 files changed, 71 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index 997d917..09c86ed 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -60,9 +60,8 @@ static struct drm_buf *i810_freelist_get(struct drm_device *
dev)
/* In use is already a pointer */
used = cmpxchg(buf_priv-in_use, I810_BUF_FREE,
I810_BUF_CLIENT);
- if (used == I810_BUF_FREE) {
+ if (used == I810_BUF_FREE)
return buf;
- }
}
return NULL;
}
@@ -71,7 +70,7 @@ static struct drm_buf *i810_freelist_get(struct drm_device *
dev)
* yet, the hardware updates in use for us once its on the ring buffer.
*/
-static int i810_freelist_put(struct drm_device * dev, struct drm_buf * buf)
+static int i810_freelist_put(struct drm_device *dev, struct drm_buf *buf)
{
drm_i810_buf_priv_t *buf_priv = buf-dev_private;
int used;
@@ -121,7 +120,7 @@ static const struct file_operations i810_buffer_fops = {
.fasync = drm_fasync,
};
-static int i810_map_buffer(struct drm_buf * buf, struct drm_file *file_priv)
+static int i810_map_buffer(struct drm_buf *buf, struct drm_file *file_priv)
{
struct drm_device *dev = file_priv-minor-dev;
drm_i810_buf_priv_t *buf_priv = buf-dev_private;
@@ -152,7 +151,7 @@ static int i810_map_buffer(struct drm_buf * buf, struct
drm_file *file_priv)
return retcode;
}
-static int i810_unmap_buffer(struct drm_buf * buf)
+static int i810_unmap_buffer(struct drm_buf *buf)
{
drm_i810_buf_priv_t *buf_priv = buf-dev_private;
int retcode = 0;
@@ -172,7 +171,7 @@ static int i810_unmap_buffer(struct drm_buf * buf)
return retcode;
}
-static int i810_dma_get_buffer(struct drm_device * dev, drm_i810_dma_t * d,
+static int i810_dma_get_buffer(struct drm_device *dev, drm_i810_dma_t *d,
struct drm_file *file_priv)
{
struct drm_buf *buf;
@@ -202,7 +201,7 @@ static int i810_dma_get_buffer(struct drm_device * dev,
drm_i810_dma_t * d,
return retcode;
}
-static int i810_dma_cleanup(struct drm_device * dev)
+static int i810_dma_cleanup(struct drm_device *dev)
{
struct drm_device_dma *dma = dev-dma;
@@ -218,9 +217,8 @@ static int i810_dma_cleanup(struct drm_device * dev)
drm_i810_private_t *dev_priv =
(drm_i810_private_t *) dev-dev_private;
- if (dev_priv-ring.virtual_start) {
+ if (dev_priv-ring.virtual_start)
drm_core_ioremapfree(dev_priv-ring.map, dev);
- }
if (dev_priv-hw_status_page) {
pci_free_consistent(dev-pdev, PAGE_SIZE,
dev_priv-hw_status_page,
@@ -242,7 +240,7 @@ static int i810_dma_cleanup(struct drm_device * dev)
return 0;
}
-static int i810_wait_ring(struct drm_device * dev, int n)
+static int i810_wait_ring(struct drm_device *dev, int n)
{
drm_i810_private_t *dev_priv = dev-dev_private;
drm_i810_ring_buffer_t *ring = (dev_priv-ring);
@@ -271,11 +269,11 @@ static int i810_wait_ring(struct drm_device * dev, int n)
udelay(1);
}
- out_wait_ring:
+out_wait_ring:
return iters;
}
-static void i810_kernel_lost_context(struct drm_device * dev)
+static void i810_kernel_lost_context(struct drm_device *dev)
{
drm_i810_private_t *dev_priv = dev-dev_private;
drm_i810_ring_buffer_t *ring = (dev_priv-ring);
@@ -287,7 +285,7 @@ static void i810_kernel_lost_context(struct drm_device *
dev)
ring-space += ring-Size;
}
-static int i810_freelist_init(struct drm_device * dev, drm_i810_private_t *
dev_priv)
+static int i810_freelist_init(struct drm_device *dev, drm_i810_private_t
*dev_priv)
{
struct drm_device_dma *dma = dev-dma;
int my_idx = 24;
@@ -322,9 +320,9 @@ static int i810_freelist_init(struct drm_device * dev,
drm_i810_private_t * dev_
return 0;
}
-static int i810_dma_initialize(struct drm_device * dev,
- drm_i810_private_t * dev_priv,
- drm_i810_init_t * init)
+static int i810_dma_initialize(struct drm_device *dev,
+ drm_i810_private_t *dev_priv,
+ drm_i810_init_t *init)
{
struct drm_map_list *r_list;
memset(dev_priv, 0, sizeof(drm_i810_private_t));
@@ -462,7 +460,7 @@ static int i810_dma_init(struct drm_device *dev, void *data,
* Use
Re: Regression 2.6.34-2.6.35-rc4: radeaon KMS an RS690 broken
On Wed, Jul 14, 2010 at 9:30 PM, Jerome Glisse gli...@freedesktop.org wrote: On 07/14/2010 02:51 PM, Torsten Kaiser wrote: On Tue, Jul 13, 2010 at 9:10 PM, Alex Deucheralexdeuc...@gmail.com wrote: On Tue, Jul 13, 2010 at 2:29 PM, Torsten Kaiser just.for.l...@googlemail.com wrote: But the CP is still broken: Is this a regression? If so, can you bisect it? Alex I bisected it to this commit: d594e46ace22afa1621254f6f669e65430048153 is the first bad commit commit d594e46ace22afa1621254f6f669e65430048153 Author: Jerome Glissejgli...@redhat.com Date: Wed Feb 17 21:54:29 2010 + drm/radeon/kms: simplify memory controller setup V2 Get rid of _location and use _start/_end also simplify the computation of vram_start|end gtt_start|end. For R1XX-R2XX we place VRAM at the same address of PCI aperture, those GPU shouldn't have much memory and seems to behave better when setup that way. For R3XX and newer we place VRAM at 0. For R6XX-R7XX AGP we place VRAM before or after AGP aperture this might limit to limit the VRAM size but it's very unlikely. For IGP we don't change the VRAM placement. Tested on (compiz,quake3,suspend/resume): PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710 AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730 IGP:RS480(RPB*),RS690,RS780(RPB*),RS880 RPB: resume previously broken V2 correct commit message to reflect more accurately the bug and move VRAM placement to 0 for most of the GPU to avoid limiting VRAM. Signed-off-by: Jerome Glissejgli...@redhat.com Signed-off-by: Dave Airlieairl...@redhat.com :04 04 05c1e456fcf6565aa8711e4933807956d0055cca 792c6be2bd161a52500c5e8d685ee651cd5af07e M drivers HTH, Torsten [ 0.426931] Linux agpgart interface v0.103 [ 0.427092] [drm] Initialized drm 1.1.0 20060810 [ 0.427196] [drm] radeon defaulting to kernel modesetting. [ 0.427255] [drm] radeon kernel modesetting enabled. [ 0.427372] radeon :01:05.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 0.429659] [drm] initializing kernel modesetting (RS690 0x1002:0x791E). [ 0.429817] [drm] register mmio base: 0xFE9F [ 0.429876] [drm] register mmio size: 65536 [ 0.430457] ATOM BIOS: ATI [ 0.430532] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF (32M used) [ 0.430592] radeon :01:05.0: GTT: 512M 0xBE00 - 0xDDFF [ 0.430675] [drm] radeon: irq initialized. [ 0.430737] mtrr: type mismatch for fc00,200 old: write-back new: write-comb ining [ 0.430811] [drm] Detected VRAM RAM=32M, BAR=32M [ 0.430868] [drm] RAM width 128bits DDR [ 0.431011] [TTM] Zone kernel: Available graphics memory: 2010234 kiB. [ 0.431070] [TTM] Initializing pool allocator. [ 0.431147] [drm] radeon: 32M of VRAM memory ready [ 0.431205] [drm] radeon: 512M of GTT memory ready. [ 0.431266] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 0.434654] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ 0.441719] [drm] Loading RS690/RS740 Microcode [ 0.441926] [drm] radeon: ring at 0xBE00 [ 0.577118] [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0x CAFEDEAD) [ 0.577192] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [ 0.577252] radeon :01:05.0: failled initializing CP (-22). [ 0.577310] radeon :01:05.0: Disabling GPU acceleration [ 0.577440] [drm] radeon: cp finalized [ 0.578078] [drm] Default TV standard: NTSC [ 0.578314] [drm] Default TV standard: NTSC [ 0.578590] [drm] Radeon Display Connectors [ 0.578648] [drm] Connector 0: [ 0.578706] [drm] VGA [ 0.578764] [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [ 0.578837] [drm] Encoders: [ 0.578894] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 0.578952] [drm] Connector 1: [ 0.579010] [drm] S-video [ 0.579067] [drm] Encoders: [ 0.579124] [drm] TV1: INTERNAL_KLDSCP_DAC1 [ 0.579182] [drm] Connector 2: [ 0.579239] [drm] HDMI-A [ 0.579297] [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [ 0.579369] [drm] Encoders: [ 0.579427] [drm] DFP3: INTERNAL_LVTM1 [ 0.773375] [drm] fb mappable at 0xFC04 [ 0.773434] [drm] vram apper at 0xFC00 [ 0.773491] [drm] size 786432 [ 0.773549] [drm] fb depth is 8 [ 0.773606] [drm] pitch is 1024 [ 0.773737] fbcon: radeondrmfb (fb0) is primary device [ 0.793240] Console: switching to colour frame buffer device 128x48 [ 0.794833] fb0: radeondrmfb frame buffer device [ 0.794852] drm: registered panic notifier [ 0.794871] Slow work thread pool: Starting up [ 0.794932] Slow work thread pool: Ready [ 0.794953] [drm] Initialized radeon 2.5.0 20080528 for :01:05.0 on minor 0 Torsten Does the attached patch works ? (try to change the if 0 to if 1 too The
Re: Regression 2.6.34-2.6.35-rc4: radeaon KMS an RS690 broken
On 07/14/2010 04:05 PM, Torsten Kaiser wrote: On Wed, Jul 14, 2010 at 9:30 PM, Jerome Glissegli...@freedesktop.org wrote: On 07/14/2010 02:51 PM, Torsten Kaiser wrote: On Tue, Jul 13, 2010 at 9:10 PM, Alex Deucheralexdeuc...@gmail.com wrote: On Tue, Jul 13, 2010 at 2:29 PM, Torsten Kaiser just.for.l...@googlemail.comwrote: But the CP is still broken: Is this a regression? If so, can you bisect it? Alex I bisected it to this commit: d594e46ace22afa1621254f6f669e65430048153 is the first bad commit commit d594e46ace22afa1621254f6f669e65430048153 Author: Jerome Glissejgli...@redhat.com Date: Wed Feb 17 21:54:29 2010 + drm/radeon/kms: simplify memory controller setup V2 Get rid of _location and use _start/_end also simplify the computation of vram_start|endgtt_start|end. For R1XX-R2XX we place VRAM at the same address of PCI aperture, those GPU shouldn't have much memory and seems to behave better when setup that way. For R3XX and newer we place VRAM at 0. For R6XX-R7XX AGP we place VRAM before or after AGP aperture this might limit to limit the VRAM size but it's very unlikely. For IGP we don't change the VRAM placement. Tested on (compiz,quake3,suspend/resume): PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710 AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730 IGP:RS480(RPB*),RS690,RS780(RPB*),RS880 RPB: resume previously broken V2 correct commit message to reflect more accurately the bug and move VRAM placement to 0 for most of the GPU to avoid limiting VRAM. Signed-off-by: Jerome Glissejgli...@redhat.com Signed-off-by: Dave Airlieairl...@redhat.com :04 04 05c1e456fcf6565aa8711e4933807956d0055cca 792c6be2bd161a52500c5e8d685ee651cd5af07e M drivers HTH, Torsten [0.426931] Linux agpgart interface v0.103 [0.427092] [drm] Initialized drm 1.1.0 20060810 [0.427196] [drm] radeon defaulting to kernel modesetting. [0.427255] [drm] radeon kernel modesetting enabled. [0.427372] radeon :01:05.0: PCI INT A -GSI 18 (level, low) - IRQ 18 [0.429659] [drm] initializing kernel modesetting (RS690 0x1002:0x791E). [0.429817] [drm] register mmio base: 0xFE9F [0.429876] [drm] register mmio size: 65536 [0.430457] ATOM BIOS: ATI [0.430532] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF (32M used) [0.430592] radeon :01:05.0: GTT: 512M 0xBE00 - 0xDDFF [0.430675] [drm] radeon: irq initialized. [0.430737] mtrr: type mismatch for fc00,200 old: write-back new: write-comb ining [0.430811] [drm] Detected VRAM RAM=32M, BAR=32M [0.430868] [drm] RAM width 128bits DDR [0.431011] [TTM] Zone kernel: Available graphics memory: 2010234 kiB. [0.431070] [TTM] Initializing pool allocator. [0.431147] [drm] radeon: 32M of VRAM memory ready [0.431205] [drm] radeon: 512M of GTT memory ready. [0.431266] [drm] GART: num cpu pages 131072, num gpu pages 131072 [0.434654] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [0.441719] [drm] Loading RS690/RS740 Microcode [0.441926] [drm] radeon: ring at 0xBE00 [0.577118] [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0x CAFEDEAD) [0.577192] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [0.577252] radeon :01:05.0: failled initializing CP (-22). [0.577310] radeon :01:05.0: Disabling GPU acceleration [0.577440] [drm] radeon: cp finalized [0.578078] [drm] Default TV standard: NTSC [0.578314] [drm] Default TV standard: NTSC [0.578590] [drm] Radeon Display Connectors [0.578648] [drm] Connector 0: [0.578706] [drm] VGA [0.578764] [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [0.578837] [drm] Encoders: [0.578894] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [0.578952] [drm] Connector 1: [0.579010] [drm] S-video [0.579067] [drm] Encoders: [0.579124] [drm] TV1: INTERNAL_KLDSCP_DAC1 [0.579182] [drm] Connector 2: [0.579239] [drm] HDMI-A [0.579297] [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [0.579369] [drm] Encoders: [0.579427] [drm] DFP3: INTERNAL_LVTM1 [0.773375] [drm] fb mappable at 0xFC04 [0.773434] [drm] vram apper at 0xFC00 [0.773491] [drm] size 786432 [0.773549] [drm] fb depth is 8 [0.773606] [drm]pitch is 1024 [0.773737] fbcon: radeondrmfb (fb0) is primary device [0.793240] Console: switching to colour frame buffer device 128x48 [0.794833] fb0: radeondrmfb frame buffer device [0.794852] drm: registered panic notifier [0.794871] Slow work thread pool: Starting up [0.794932] Slow work thread pool: Ready [0.794953] [drm] Initialized radeon 2.5.0 20080528 for :01:05.0 on minor 0 Torsten Does the attached patch works ? (try to change the if 0 to if 1 too The patch doesn't compile,
[Bug 29066] pipes triggers Assertion `boi-space_accounted' failed
https://bugs.freedesktop.org/show_bug.cgi?id=29066 --- Comment #1 from Tormod Volden bugzi09.fdo.tor...@xoxy.net 2010-07-14 14:02:37 PDT --- Created an attachment (id=37057) -- (https://bugs.freedesktop.org/attachment.cgi?id=37057) dmesg output including gallium run -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29066] pipes triggers Assertion `boi-space_accounted' failed
https://bugs.freedesktop.org/show_bug.cgi?id=29066 Tormod Volden bugzi09.fdo.tor...@xoxy.net changed: What|Removed |Added Attachment #37056|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29062] hp dv5000: xpress 200m 5955 + KMS does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=29062 --- Comment #3 from Dave Airlie airl...@freedesktop.org 2010-07-14 14:13:34 PDT --- 580b4fffbbdc3c899ee1f8189ba321bd60b48840 in Linus tree is a quirk for my rs48x laptop, you try expanding it to cover your laptop, or just force it on for testing. drm/radeon: add quirk to make HP nx6125 laptop resume -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression 2.6.34-2.6.35-rc4: radeaon KMS an RS690 broken
On Wed, Jul 14, 2010 at 4:05 PM, Torsten Kaiser just.for.l...@googlemail.com wrote: On Wed, Jul 14, 2010 at 9:30 PM, Jerome Glisse gli...@freedesktop.org wrote: On 07/14/2010 02:51 PM, Torsten Kaiser wrote: On Tue, Jul 13, 2010 at 9:10 PM, Alex Deucheralexdeuc...@gmail.com wrote: On Tue, Jul 13, 2010 at 2:29 PM, Torsten Kaiser just.for.l...@googlemail.com wrote: But the CP is still broken: Is this a regression? If so, can you bisect it? Alex I bisected it to this commit: d594e46ace22afa1621254f6f669e65430048153 is the first bad commit commit d594e46ace22afa1621254f6f669e65430048153 Author: Jerome Glissejgli...@redhat.com Date: Wed Feb 17 21:54:29 2010 + drm/radeon/kms: simplify memory controller setup V2 Get rid of _location and use _start/_end also simplify the computation of vram_start|end gtt_start|end. For R1XX-R2XX we place VRAM at the same address of PCI aperture, those GPU shouldn't have much memory and seems to behave better when setup that way. For R3XX and newer we place VRAM at 0. For R6XX-R7XX AGP we place VRAM before or after AGP aperture this might limit to limit the VRAM size but it's very unlikely. For IGP we don't change the VRAM placement. Tested on (compiz,quake3,suspend/resume): PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710 AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730 IGP:RS480(RPB*),RS690,RS780(RPB*),RS880 RPB: resume previously broken V2 correct commit message to reflect more accurately the bug and move VRAM placement to 0 for most of the GPU to avoid limiting VRAM. Signed-off-by: Jerome Glissejgli...@redhat.com Signed-off-by: Dave Airlieairl...@redhat.com :04 04 05c1e456fcf6565aa8711e4933807956d0055cca 792c6be2bd161a52500c5e8d685ee651cd5af07e M drivers HTH, Torsten [ 0.426931] Linux agpgart interface v0.103 [ 0.427092] [drm] Initialized drm 1.1.0 20060810 [ 0.427196] [drm] radeon defaulting to kernel modesetting. [ 0.427255] [drm] radeon kernel modesetting enabled. [ 0.427372] radeon :01:05.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 0.429659] [drm] initializing kernel modesetting (RS690 0x1002:0x791E). [ 0.429817] [drm] register mmio base: 0xFE9F [ 0.429876] [drm] register mmio size: 65536 [ 0.430457] ATOM BIOS: ATI [ 0.430532] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF (32M used) [ 0.430592] radeon :01:05.0: GTT: 512M 0xBE00 - 0xDDFF [ 0.430675] [drm] radeon: irq initialized. [ 0.430737] mtrr: type mismatch for fc00,200 old: write-back new: write-comb ining [ 0.430811] [drm] Detected VRAM RAM=32M, BAR=32M [ 0.430868] [drm] RAM width 128bits DDR [ 0.431011] [TTM] Zone kernel: Available graphics memory: 2010234 kiB. [ 0.431070] [TTM] Initializing pool allocator. [ 0.431147] [drm] radeon: 32M of VRAM memory ready [ 0.431205] [drm] radeon: 512M of GTT memory ready. [ 0.431266] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 0.434654] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ 0.441719] [drm] Loading RS690/RS740 Microcode [ 0.441926] [drm] radeon: ring at 0xBE00 [ 0.577118] [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0x CAFEDEAD) [ 0.577192] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [ 0.577252] radeon :01:05.0: failled initializing CP (-22). [ 0.577310] radeon :01:05.0: Disabling GPU acceleration [ 0.577440] [drm] radeon: cp finalized [ 0.578078] [drm] Default TV standard: NTSC [ 0.578314] [drm] Default TV standard: NTSC [ 0.578590] [drm] Radeon Display Connectors [ 0.578648] [drm] Connector 0: [ 0.578706] [drm] VGA [ 0.578764] [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [ 0.578837] [drm] Encoders: [ 0.578894] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 0.578952] [drm] Connector 1: [ 0.579010] [drm] S-video [ 0.579067] [drm] Encoders: [ 0.579124] [drm] TV1: INTERNAL_KLDSCP_DAC1 [ 0.579182] [drm] Connector 2: [ 0.579239] [drm] HDMI-A [ 0.579297] [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [ 0.579369] [drm] Encoders: [ 0.579427] [drm] DFP3: INTERNAL_LVTM1 [ 0.773375] [drm] fb mappable at 0xFC04 [ 0.773434] [drm] vram apper at 0xFC00 [ 0.773491] [drm] size 786432 [ 0.773549] [drm] fb depth is 8 [ 0.773606] [drm] pitch is 1024 [ 0.773737] fbcon: radeondrmfb (fb0) is primary device [ 0.793240] Console: switching to colour frame buffer device 128x48 [ 0.794833] fb0: radeondrmfb frame buffer device [ 0.794852] drm: registered panic notifier [ 0.794871] Slow work thread pool: Starting up [ 0.794932] Slow work thread pool: Ready [ 0.794953] [drm] Initialized radeon 2.5.0 20080528 for :01:05.0 on minor 0
[Bug 29067] New: WebGL in Firefox is very slow (pegs the cpu)
https://bugs.freedesktop.org/show_bug.cgi?id=29067 Summary: WebGL in Firefox is very slow (pegs the cpu) Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: s...@whiz.se WebGL in Firefox (4.0b1) is very slow on r300g, it seems to be using an excessive amount of CPU, this is not the case in Chrome, where things seem to be working very well. I'm not really sure if this is a bug in the driver, or in Firefox, but on i965 performance seems to be the same in both browsers. This problem is very noticeable in demos which measure framerate, such as: http://cs.helsinki.fi/u/ilmarihe/demo/demo.html http://cs.helsinki.fi/u/ilmarihe/demo2/paint.html Another good test is an interactive demo like the teapot, where lag is noticable: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/google/shiny-teapot/index.html WebGL requires support for pbuffers (for both Firefox and Chrome) so Xserver 1.9.0 is required. For more general tips on getting webgl running see: http://learningwebgl.com/blog/?p=11 System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: 6.13.1 -- xserver: 1.8.99.904 (1.9.0 RC 4) -- mesa: f8d81c31cee30821da3aab331a57f484f6a07a5d -- drm: 6ea2bda5f5ec8f27359760ce580fdad3df0464df -- kernel: 2.6.35-rc5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: glint KMS - how to proceed?
On Wed, Jul 14, 2010 at 2:13 PM, James Simmons jsimm...@infradead.org wrote: Whoo! I'll put this up on k.org as soon as I can get it working. The only problem is it will not work with X running with the tdfx xorg driver :-( The driver will need more love as well. That's alright. I am, if nothing else, a lover of DDXs. tdfx needs it anyway -- DRI1 is kind of painful with the current setup. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: check/restore sanity before doing anything else with GPU.
From: Dave Airlie airl...@redhat.com
On systems using kexec, the new kernel is booted straight from the old kernel,
without any warning to the graphics driver. So the GPU is basically left as-is
in a running state, however the CPU side is completly reset.
Without stating the saneness of anyone using kexec on live systems, we should
at least try not to crash the GPU. This patch resets 3 registers to 0 that
could cause bad things to happen to the running system.
This allows kexec to work on a Power6/RN50 system.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/r100.c| 27 +++
drivers/gpu/drm/radeon/r300.c|2 ++
drivers/gpu/drm/radeon/r420.c|2 ++
drivers/gpu/drm/radeon/r520.c|2 ++
drivers/gpu/drm/radeon/radeon_asic.h |1 +
drivers/gpu/drm/radeon/rs400.c |2 ++
drivers/gpu/drm/radeon/rs600.c |2 ++
drivers/gpu/drm/radeon/rs690.c |2 ++
drivers/gpu/drm/radeon/rv515.c |2 ++
9 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 5aa2995..5d14732 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3809,6 +3809,31 @@ void r100_fini(struct radeon_device *rdev)
rdev-bios = NULL;
}
+/*
+ * Due to how kexec works, it can leave the hw fully initialised when it
+ * boots the new kernel. However doing our init sequence with the CP and
+ * WB stuff setup causes GPU hangs on the RN50 at least. So at startup
+ * do some quick sanity checks and restore sane values to avoid this
+ * problem.
+ */
+void r100_restore_sanity(struct radeon_device *rdev)
+{
+ u32 tmp;
+
+ tmp = RREG32(RADEON_CP_CSQ_CNTL);
+ if (tmp) {
+ WREG32(RADEON_CP_CSQ_CNTL, 0);
+ }
+ tmp = RREG32(RADEON_CP_RB_CNTL);
+ if (tmp) {
+ WREG32(RADEON_CP_RB_CNTL, 0);
+ }
+ tmp = RREG32(RADEON_SCRATCH_UMSK);
+ if (tmp) {
+ WREG32(RADEON_SCRATCH_UMSK, 0);
+ }
+}
+
int r100_init(struct radeon_device *rdev)
{
int r;
@@ -3821,6 +3846,8 @@ int r100_init(struct radeon_device *rdev)
radeon_scratch_init(rdev);
/* Initialize surface registers */
radeon_surface_init(rdev);
+ /* sanity check some register to avoid hangs like after kexec */
+ r100_restore_sanity(rdev);
/* TODO: disable VGA need to use VGA request */
/* BIOS*/
if (!radeon_get_bios(rdev)) {
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 7e81db5..3c34da0 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1377,6 +1377,8 @@ int r300_init(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
/* TODO: disable VGA need to use VGA request */
+ /* restore some register to sane defaults */
+ r100_restore_sanity(rdev);
/* BIOS*/
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index e6c8914..59f7bcc 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -343,6 +343,8 @@ int r420_init(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
/* TODO: disable VGA need to use VGA request */
+ /* restore some register to sane defaults */
+ r100_restore_sanity(rdev);
/* BIOS*/
if (!radeon_get_bios(rdev)) {
if (ASIC_IS_AVIVO(rdev))
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index 34330df..213e2e0 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -230,6 +230,8 @@ int r520_init(struct radeon_device *rdev)
radeon_scratch_init(rdev);
/* Initialize surface registers */
radeon_surface_init(rdev);
+ /* restore some register to sane defaults */
+ r100_restore_sanity(rdev);
/* TODO: disable VGA need to use VGA request */
/* BIOS*/
if (!radeon_get_bios(rdev)) {
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index c0bbaa6..a5aff75 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -113,6 +113,7 @@ void r100_wb_fini(struct radeon_device *rdev);
int r100_wb_init(struct radeon_device *rdev);
int r100_cp_reset(struct radeon_device *rdev);
void r100_vga_render_disable(struct radeon_device *rdev);
+void r100_restore_sanity(struct radeon_device *rdev);
int r100_cs_track_check_pkt3_indx_buffer(struct radeon_cs_parser *p,
struct radeon_cs_packet *pkt,
struct radeon_bo *robj);
diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions
https://bugs.freedesktop.org/show_bug.cgi?id=28860 --- Comment #12 from Marek Olšák mar...@gmail.com 2010-07-14 22:46:06 PDT --- If you revert 8c836f7f740c6f74511c727c7bed0680ddba9974, do those messages go away? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression 2.6.34-2.6.35-rc4: radeaon KMS an RS690 broken
On Thu, Jul 15, 2010 at 12:16 AM, Alex Deucher alexdeuc...@gmail.com wrote: I discussed this with Jerome and I think we found the root cause. Does this patch help? (patch 0001-drm-radeon-kms-fix-gtt-MC-base-alignment-on-rs4xx-rs.patch) Yes: [0.426978] Linux agpgart interface v0.103 [0.427141] [drm] Initialized drm 1.1.0 20060810 [0.427242] [drm] radeon defaulting to kernel modesetting. [0.427300] [drm] radeon kernel modesetting enabled. [0.427417] radeon :01:05.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [0.429732] [drm] initializing kernel modesetting (RS690 0x1002:0x791E). [0.429890] [drm] register mmio base: 0xFE9F [0.429948] [drm] register mmio size: 65536 [0.430537] ATOM BIOS: ATI [0.430612] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF (32M used) [0.430672] radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF [0.430754] [drm] radeon: irq initialized. [0.430817] mtrr: type mismatch for fc00,200 old: write-back new: write-combining [0.430890] [drm] Detected VRAM RAM=32M, BAR=32M [0.430947] [drm] RAM width 128bits DDR [0.431090] [TTM] Zone kernel: Available graphics memory: 2010234 kiB. [0.431149] [TTM] Initializing pool allocator. [0.431224] [drm] radeon: 32M of VRAM memory ready [0.431283] [drm] radeon: 512M of GTT memory ready. [0.431343] [drm] GART: num cpu pages 131072, num gpu pages 131072 [0.434732] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [0.441796] [drm] Loading RS690/RS740 Microcode [0.442006] [drm] radeon: ring at 0xA000 [0.442080] [drm] ring test succeeded in 1 usecs [0.442223] [drm] radeon: ib pool ready. [0.442289] [drm] ib test succeeded in 0 usecs [0.442370] [drm] Default TV standard: NTSC [0.442587] [drm] Default TV standard: NTSC [0.442866] [drm] Radeon Display Connectors [0.442924] [drm] Connector 0: [0.442981] [drm] VGA [0.443039] [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [0.443111] [drm] Encoders: [0.443169] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [0.443227] [drm] Connector 1: [0.443284] [drm] S-video [0.443340] [drm] Encoders: [0.443398] [drm] TV1: INTERNAL_KLDSCP_DAC1 [0.443455] [drm] Connector 2: [0.443512] [drm] HDMI-A [0.443570] [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [0.443642] [drm] Encoders: [0.443700] [drm] DFP3: INTERNAL_LVTM1 [0.643372] [drm] fb mappable at 0xFC04 [0.643432] [drm] vram apper at 0xFC00 [0.643489] [drm] size 786432 [0.643546] [drm] fb depth is 8 [0.643603] [drm]pitch is 1024 [0.643742] fbcon: radeondrmfb (fb0) is primary device [0.663232] Console: switching to colour frame buffer device 128x48 [0.664818] fb0: radeondrmfb frame buffer device [0.664837] drm: registered panic notifier [0.664856] Slow work thread pool: Starting up [0.664919] Slow work thread pool: Ready [0.664940] [drm] Initialized radeon 2.5.0 20080528 for :01:05.0 on minor 0 Please note, that I'm only looking for ring test succeeded / ring test failed, as I'm only using the KMS fb console on that system. Thanks for the fix, Torsten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
