[Pkg-fglrx-devel] Bug#554847: Bug#554847: please consider unmerging

Michael Gilbert michael.s.gilbert at gmail.com
Thu Jan 7 22:55:20 UTC 2010

On Thu, 7 Jan 2010 11:18:30 +0100 Friedrich Delgado Friedrichs wrote:

> A search on google for "mtrr: your BIOS has set up an incorrect mask,
> fixing it up" yields several results from lkml and other sources gives
> me the impression that the kernel is fixing up a buggy mtrr mask from
> the bios.
> In particular, Ingo Molnar's reply at
> http://lkml.indiana.edu/hypermail/linux/kernel/0902.1/01117.html:
> >> [ 0.000000] ------------[ cut here ]------------
> >> [ 0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/generic.c:404 generic_get_mtrr+0xdf/0x119()
> >> [ 0.000000] mtrr: your BIOS has set up an incorrect mask, fixing it up.
> >
> > buggy BIOS most likely. Had the kernel not fixed up the MTRRs you'd have
> > a very slow and unhappy system now.
> This kernel feature has apparently been present since 2.6.28 at least.
> If there was reason to believe that the way the kernel fixes my mtrr
> masks is incorrect, then it would be a kernel bug.
> This may still be the cause of the problem, but it's certainly not a crash.

the warning before the crash (although perhaps related) is not the important
thing.  the crash itself is what matters.  like i said before, the fact that
you have a backtrace indicates a crash.  lines like the following are the
symbols in the crashing program:

  Nov 24 21:50:35 abrasax kernel: [    0.000000]  [<ffffffff8021dadb>] ? generic_get_mtrr+0xbf/0xf9 

normally they would not be printed (unless there were a crash). the
names of the symbols leads me to believe that it is MTRR itself that is
crashing, but it is possible that it is something else that calls MTRR.
is this explanation clear enough?

> > You need to test without fglrx, and if MTRR still crashes, a bug report
> > on the kernel is really your only option for getting the problem fixed.
> As you can see in the full dmesg output that I attached to several
> posts, the kernel fixes the mtrr mask directly after loading. It's one
> of the first kernel messages. Fglrx is loaded much, much later, (also
> visible in the dmesg log) so I see no reason to try it "without fglrx" since
> fglrx is not loaded at the point of the backtrace.

my point was that you need to reproduce the problem with a clean kernel
so you can submit a kernel bug to get help.  we are not kernel experts,
so we would be of no help in this area.

> I think the opinion of a kernel developer would still be useful here,
> in particular:
>  - I'd like to know how I can get more information about fglrx
>  crashing, since I see nothing in syslog.

they will refuse to help if you submit a bug report related to fglrx.

>  - Also if we can decide that the problem is not in the glue parts of
>  the driver, or the kernel, then it's most likely a problem in the
>  binary blob from ati.

like i said before, the root cause is that MTRR has crashed. and
without a running MTRR, you should expect software that depends on it
to have problems.

> And if there are no objections, I'll unmerge this bug and fix the
> version information on this bug, since there is no relation to the one
> it was merged with.

i've already done this.

this bug is in your hands now.  if you care about it, do the leg work
to send a clean report to the kernel.  otherwise, we can't help because
we are not kernel experts.

kind regards,

More information about the Pkg-fglrx-devel mailing list