[Pkg-fglrx-devel] Bug#576942: Bug#576942: /boot/vmlinuz-2.6.32-3-amd64: kernel fix for wrong mtrr mask from MS-7252 bios may be wrong and cause problems with fglrx-driver

[Michael Gilbert]

On Sat, 10 Apr 2010 15:18:43 +0200 Friedrich Delgado Friedrichs wrote:

> 
> Ben Hutchings schrieb:
> > On Thu, 2010-04-08 at 14:26 +0200, Friedrich Delgado Friedrichs wrote:
> > > [    0.000000] WARNING: at /build/mattems-linux-2.6_2.6.32-9-amd64-NYTFdD/linux-2.6-2.6.32-9/debian/build/source_amd64_none/arch/x86/kernel/cpu/mtrr/generic.c:467 generic_get_mtrr+0xbf/0xf9()
> > > [    0.000000] Hardware name: MS-7252
> > > [    0.000000] mtrr: your BIOS has set up an incorrect mask, fixing it up.
> 
> > > are supposed to indicate a crash in the kernel.
> > It's not a crash, it's a warning about a BIOS bug.
> 
> In fact, that's what I suspected as well.
> 
> Is there any way this bios bug could cause me further trouble?

the key here is that the submitter's MTRR is crashing irrespective of fglrx.
don't be thrown off by the fact that he has mistaken a (probably unrelated)
warning message for the error.  looking at his logs using the free radeon
driver, you can see that MTRR crashes there as well:

[    0.000000] mtrr: your BIOS has set up an incorrect mask, fixing it up.
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.32-3-amd64 #1
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff8102238b>] ? generic_get_mtrr+0xbf/0xf9
[    0.000000]  [<ffffffff8102238b>] ? generic_get_mtrr+0xbf/0xf9
[    0.000000]  [<ffffffff8104dbf0>] ? warn_slowpath_common+0x77/0xa3
[    0.000000]  [<ffffffff8104dc78>] ? warn_slowpath_fmt+0x51/0x59
[    0.000000]  [<ffffffff81022497>] ? mtrr_wrmsr+0x1c/0x49
[    0.000000]  [<ffffffff8102269c>] ? get_fixed_ranges+0x71/0x98
[    0.000000]  [<ffffffff81022497>] ? mtrr_wrmsr+0x1c/0x49
[    0.000000]  [<ffffffff8102255b>] ? prepare_set+0x97/0x9d
[    0.000000]  [<ffffffff810225b4>] ? post_set+0x53/0x60
[    0.000000]  [<ffffffff814e1c6b>] ? get_mtrr_state+0x2eb/0x2f6
[    0.000000]  [<ffffffff8102238b>] ? generic_get_mtrr+0xbf/0xf9
[    0.000000]  [<ffffffff812ed452>] ? printk+0x4e/0x5c
[    0.000000]  [<ffffffff814e2842>] ? mtrr_trim_uncached_memory+0x91/0x311
[    0.000000]  [<ffffffff814e17db>] ? mtrr_bp_init+0x1b1/0x1d4
[    0.000000]  [<ffffffff8122f2d2>] ? dmi_name_in_serial+0x1d/0x28
[    0.000000]  [<ffffffff814ebacc>] ? early_gart_iommu_check+0x9b/0x287
[    0.000000]  [<ffffffff814ddd09>] ? setup_arch+0x43f/0x9c6
[    0.000000]  [<ffffffff811ef173>] ? extract_entropy+0x6a/0x125
[    0.000000]  [<ffffffff814da140>] ? early_idt_handler+0x0/0x71
[    0.000000]  [<ffffffff814da9d6>] ? start_kernel+0xcf/0x3dc
[    0.000000]  [<ffffffff814da3b7>] ? x86_64_start_kernel+0xf9/0x106

the only noticable consequence of this crash so far is that fglrx doesn't
work (when he uses that), but that is expected since it depends on a working
MTRR.  however, since the crash is reproducible with the free driver, i
think that aquits fglrx of any wrongdoing.

there is probably some incompatibility with MTRR and his hardware.

i would like to reassign this to the kernel if that is ok.  thanks for
looking into this.

mike