I just had time to try this latest patch.
Unfortunately it does not correct the issue.
Is there any way to check or change the beginning and ending addresses of
sideport memory and stolen system memory once the system is up?
If there are registers I can read or write to experiment I will be happy t
(In reply to comment #38)
> Since this bug was reported over a year ago and no real progress has been made
> in fixing it, may I ask a knowledgeable person what the last working version
> of
> the code was, before this bug was introduced? Is there any way to create a
> "radeon-unsupported" module
archaeopteryx radeontool # ./radeonreg regset 0x6564 0x
OLD: 0x6564 (6564) 0x7fff7fff (2147450879)
NEW: 0x6564 (6564) 0x7fff7fff (2147450879)
archaeopteryx radeontool # ./radeonreg regset 0x6568 0x
OLD: 0x6568 (6568) 0x7fff7fff (2147450879)
NEW: 0x6568 (6568) 0x7
(In reply to comment #20)
> (In reply to comment #18)
> > I have not yet applied Alex's patch, [...]
>
> Have you been able to test it in the meantime? It doesn't seem very likely
> it'll help, but...
>
I did finallly try the gart alignment patch (required a minor tweak,
gart.table.ram.ptr change
Experienced my first bit of corruption since adding "radeon.vramlimt=64" to my
kernel params.
When switching from tuxracer back to the native desktop mode 1366x768, the
pointer was corrupted.
One of the striking characteristics of this problem has always been that
the pointer and character glyph
5 matches
Mail list logo
