Mailinglist Archive: radeonhd (427 mails)

["Christoph Piefke" <anmeldung@xxxxxxxxxxxxxxxxx>]

----- Original Message -----
From: Urigeller@xxxxxx
To: radeonhd@xxxxxxxxxxxx
Date: 06.05.2009 13:15:11
Subject: Re: [radeonhd] HD 3650/ fglrx wants 4GB of VideoRAM/ radeonhd v 1.2.5  
crashes


> Matthias Hopf wrote:
> > On May 06, 09 10:34:53 +0200, Christoph Piefke wrote:
> > > > Does removing one of the ram chips in your system help?
> > > Yes, it works fine, except that this procedure creates a rather useless 
> > > paperweight worth of 2GB ram.
> > > But screen resolution is just fine.
> > >
> > > Xorg.0.log can be found here: http://pastebin.com/m4c03dfd6
> >
> > You might have some luck with this description:
> >
> > http://lists.opensuse.org/radeonhd/2009-04/msg00253.html
> >
> > Given the complexity of the issue, you're pretty much on your own right
> > now, until somebody who *really* understands the issue (which is, for
> > instance, not me) sits down and creates a great mtrr workaround patch
> > for the kernel :-(
> >
> > Matthias
>
> I think I can update some of the informations on the issue which I
> described in the post that Matthias linked to. I recently chose to look
> again at the mentioned kernel option CONFIG_MTRR_SANITIZER. It's located
> in the "Processor type and features" section, down at the option for
> MTRR support.
>
> I enabled MTRR cleanup support (CONFIG_MTRR_SANITIZER), set MTRR cleanup
> enable value (CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT) to 1 and set MTRR
> cleanup spare reg num (CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT) to 0.
> After that, my dmesg looks like this (excerpt):
>
> [    0.000000] original variable MTRRs
>
> [    0.000000] reg 0, base: 3328MB, range: 256MB, type UC
>
> [    0.000000] reg 1, base: 3584MB, range: 512MB, type UC
>
> [    0.000000] reg 2, base: 0GB, range: 4GB, type WB
>
> [    0.000000] reg 3, base: 4GB, range: 512MB, type WB
>
> [    0.000000] reg 4, base: 4608MB, range: 256MB, type WB
>
> [    0.000000] total RAM coverred: 4096M
>
> [    0.000000] Found optimal setting for mtrr clean up
>
> [    0.000000]  gran_size: 64K  chunk_size: 64K         num_reg: 5
> lose cover RAM: 0G
> [    0.000000] New variable MTRRs
>
> [    0.000000] reg 0, base: 0GB, range: 2GB, type WB
>
> [    0.000000] reg 1, base: 2GB, range: 1GB, type WB
>
> [    0.000000] reg 2, base: 3GB, range: 256MB, type WB
>
> [    0.000000] reg 3, base: 4GB, range: 512MB, type WB
>
> [    0.000000] reg 4, base: 4608MB, range: 256MB, type WB
>
> This corresponds to the values in my original post.
> So I disabled my little hack and I'm having no problems so far (running
> this configuration since about a month). This workaround inside the
> kernel is  probably much better than mine because it corrects the MTRRs
> as one of its first actions. I had to rely on a boot script (which of
> course kicks in much later) to do this cleanup.
>
> Also, this probably implicates that the kernel has a viable method to
> detect and corret erroneous MTRR tables without any further user action.
> If you want to take a shot at this I recommend to read the help pages of
> the mentioned kernel options, this behaviour can be modified through
> boot parameters (to save you reboots and reconfigurations of your kernel).
>
> regards,
> Uri
> -- 
> To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
> For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx

Well, this sound really promising! I will try this, but I am a little bit lost 
here. Are these flags boot options or are they compiler flags and I have to 
rebuild my kernel? Where do I find the help pages for the mentioned kernel 
options?

regards, Chris




-- 
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx