Bug 16574 - Error initialising KMS with R200
Error initialising KMS with R200
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Video(AGP)
i386 Linux
: P1 normal
Assigned To: Dave Airlie
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-12 21:35 UTC by Chris Rankin
Modified: 2010-08-16 22:14 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.35.1
Tree: Mainline
Regression: Yes


Attachments
Full dmesg log (31.19 KB, text/plain)
2010-08-12 21:35 UTC, Chris Rankin
Details
Dmesg log from working 2.6.34.2 kernel (27.34 KB, text/plain)
2010-08-15 13:09 UTC, Chris Rankin
Details
Fix VRAM/GTT overlapping detection (1.26 KB, patch)
2010-08-16 15:54 UTC, Jérôme Glisse
Details | Diff
New dmesg log after patching (648 bytes, text/plain)
2010-08-16 19:42 UTC, Chris Rankin
Details
New dmesg log after patching (2.31 KB, text/plain)
2010-08-16 19:46 UTC, Chris Rankin
Details

Description Chris Rankin 2010-08-12 21:35:39 UTC
Created attachment 27420 [details]
Full dmesg log

This is the error from the dmesg log:

[drm] Loading R200 Microcode
[drm] radeon: ring at 0x00000000F8000000
[drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
[drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
radeon 0000:01:00.0: failled initializing CP (-22).
radeon 0000:01:00.0: Disabling GPU acceleration
[drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
Failed to wait GUI idle while programming pipes. Bad things might happen.
[drm] radeon: cp finalized
radeon 0000:01:00.0: (r100_asic_reset:2088) RBBM_STATUS=0x80010140
radeon 0000:01:00.0: (r100_asic_reset:2109) RBBM_STATUS=0x80010140
radeon 0000:01:00.0: (r100_asic_reset:2117) RBBM_STATUS=0x00000140
radeon 0000:01:00.0: restoring config space at offset 0x1 (was 0x2b00003, writing 0x2b00007)
radeon 0000:01:00.0: GPU reset succeed
[drm] radeon: cp finalized
[TTM] Finalizing pool allocator.
[TTM] Zone  kernel: Used memory at exit: 0 kiB.
[drm] radeon: ttm finalized
[drm] Forcing AGP to PCI mode

2.6.34.x seems to work OK.

This is a 1 GHz Pentium 3 machine, with a Radeon rv280.
Comment 1 Chris Rankin 2010-08-15 13:09:48 UTC
Created attachment 27451 [details]
Dmesg log from working 2.6.34.2 kernel

I was using 2.6.34.2 before upgrading to 2.6.35.1, and 2.6.34.2 had no such AGP problems.
Comment 2 Chris Rankin 2010-08-15 13:29:56 UTC
One thing that I have noticed is that when 2.6.35.1 puts the card into PCI mode, it places the ring buffer at a completely different address:

2.6.35.1 AGP:
[drm] radeon: ring at 0x00000000F8000000

2.6.35.1 PCI:
[drm] radeon: ring at 0x00000000D0000000

2.6.35.1 also uses all 256M of VRAM on this card, whereas 2.6.34.2 only tries to use 128M. So on 2.6.35.1 we get:

radeon 0000:01:00.0: GTT: 64M 0xF8000000 - 0xFBFFFFFF
radeon 0000:01:00.0: VRAM: 256M 0xF0000000 - 0xFFFFFFFF (256M used)
[drm] radeon: ring at 0x00000000F8000000

Whereas on 2.6.34.2 we only get:

radeon 0000:01:00.0: GTT: 64M 0xF8000000 - 0xFBFFFFFF
radeon 0000:01:00.0: VRAM: 128M 0xF0000000 - 0xF7FFFFFF (128M used)
[drm] radeon: ring at 0x00000000F8000000

So on 2.6.35.1 the GTT overlaps 100% with the VRAM (in AGP mode only), whereas on 2.6.34.2 it does not overlap at all.

I have no idea whether this matters or not, but the memory layout does seem to be the most significant difference between 2.6.34.x and 2.6.35.y.
Comment 4 Jérôme Glisse 2010-08-16 15:54:16 UTC
Created attachment 27468 [details]
Fix VRAM/GTT overlapping detection

Please can you check if attached patch fix the issue for you ? (pretty sure it should :))
Comment 5 Chris Rankin 2010-08-16 19:42:48 UTC
Created attachment 27474 [details]
New dmesg log after patching

Yes, that fixes it. Thanks. Although I guess this means that 128M of VRAM is all that I'll ever get out of this card (on this board).
Comment 6 Chris Rankin 2010-08-16 19:46:05 UTC
Created attachment 27475 [details]
New dmesg log after patching

(Try that again! Ahem!)

Note You need to log in before you can comment on or make changes to this bug.