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

[Friedrich Delgado Friedrichs]

Hi!

Michael Gilbert schrieb:
> On Thu, 7 Jan 2010 01:46:55 +0100 Friedrich Delgado Friedrichs wrote:
> > Michael Gilbert schrieb:
> > > On Thu, 7 Jan 2010 00:12:58 +0100, Friedrich Delgado Friedrichs wrote:
> > > Given the fact that the fglrx driver needs a working MTRR lead me to
> > > conclude that your crashing MTRR is the root cause of the problem.
> > 
> > fglrx driver 9.8 works with that same crashing mtrr.
> > 
> > > BTW, your logs say that your MTRR is crashing.  The stuff following
> > > 'Call Trace' is a backtrace, which you get when something crashes.
> > 
> > Well, the line
> > 
> > mtrr: your BIOS has set up an incorrect mask, fixing it up.
> > 
> > and the word 'WARNING' led me to believe that the linux kernel is
> > working around a problem in my bios. But you're probably right, the
> > kernel (package) maintainers should know exactly what that means.
> > 
> > I'm still not sure a bug report against the kernel is appropriate
> > here, as I only have problems with specific versions of the fglrx
> > driver on one specific mainboard + bios.
> 
> If MTRR crashes without fglrx, then it is kernel problem.  MTRR may
> have become more important since 9-9 (this is conjecture since I have
> no evidence to back this up), which would explain why older versions
> worked ok.

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.

In fact I've seen older posts and howtos on how to get fglrx to work
that included fixing the mtrr mask by hand (with a script). I never
had to do that (I may have started using fglrx after 2.6.28, not
sure).

This may still be the cause of the problem, but it's certainly not a crash.

> 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.

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.

 - 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.

If it's a problem with the binary blob, then only ati can fix it.

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.

Kind regards
     Friedel
-- 
        Friedrich Delgado Friedrichs <friedel at nomaden.org>
                             TauPan on Ircnet and Freenode ;)