On Sat, 10 Apr 2010 15:57:03 +0100 Ben Hutchings wrote: > On Sat, 2010-04-10 at 10:45 -0400, Michael Gilbert wrote: > > 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. > > Nothing is crashing.
"crash" may not have been the best choice of terminology, since yes it did not bring the whole system down. it is an "oops" (in kernel speak), and as such ill-defined behavior should be expected from applications that expect the MTRR code to be functioning properly. > [...] > > there is probably some incompatibility with MTRR and his hardware. > > You clearly have no idea what an MTRR is. i'll readily admit to that; although i don't see why that matters. from a high-level perspective, i know that it's just a memory/communication interface between the processor and video card. i've never had cause to concern myself with MTRR before, and i have no desire to expend much cognitive effort since it's not something i have much interest in anyway. but even so, you're calling me out on my choice of verbiage again, which isn't very productive. maybe a better sentance would have been: my best guess is that there is a problem in linux's MTRR code due to the submitter's specific hardware. so i guess the real question is: should the MTRR code not oops for his hardware, or is it the responsibility of downstream applications to be more robust when the MTRR code does oops? mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
