https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #71 from Martin Steigerwald Martin@Lichtvoll.de 2010-09-21 05:31:43 PDT --- (In reply to comment #70)

Ok here's an update: I've now tested putting the vram at the following locations (in order):

• 0x00000000: This is the same location as vram used to be at before the identified bad commit and works.
• 0x10000000: This is before GTT (which starts at 0xd0000000), with some room to spare. This works without freezing, tested for two days.
• 0xf0000000: This is after GTT (which ends at 0xdfffffff), with some room to spare. This works, tested for two days.
• 0xcc000000: This is directly in front of GTT, with no room to spare. This works, tested for several days.
• 0xe0000000: This is directly behind GTT, with no room to spare. This where vram is placed starting with the identified commit, and as expected it froze within minutes.

Da Fox, I seem to have the same setup which is not surprising if you also have an ThinkPad T42:

shambhala:~> dmesg | grep GTT radeon 0000:01:00.0: GTT: 256M 0xD0000000 - 0xDFFFFFFF radeon 0000:01:00.0: GTT: 256M 0xD0000000 - 0xDFFFFFFF

Thus I do not think I need to test the same values again. Are there some other values I should test? Maybe we can share this work.

Thanks for your hints regarding AGP. I think it might make sense to use that agp mode option, cause:

shambhala:~> lspci | grep AGP 00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03) shambhala:~> dmesg | grep -i AGP [drm] AGP mode requested: 1 agpgart-intel 0000:00:00.0: AGP 2.0 bridge agpgart-intel 0000:00:00.0: putting AGP V2 device into 1x mode radeon 0000:01:00.0: putting AGP V2 device into 1x mode [drm] AGP mode requested: 1 agpgart-intel 0000:00:00.0: AGP 2.0 bridge agpgart-intel 0000:00:00.0: putting AGP V2 device into 1x mode radeon 0000:01:00.0: putting AGP V2 device into 1x mode

Did you set the agpmode module parameter for radeon or are you getting 4x setup automatically? If the later I wonder why I get 1x automatically.