On Mon, 2012-11-05 at 11:37 +0100, Greg KH wrote: > On Sun, Nov 04, 2012 at 05:35:06PM +0000, Matt Fleming wrote: > > From: Matt Fleming <matt.fleming@xxxxxxxxx> > > > > We've started getting reports of users seeing Machine Check Exceptions > > when booting their Samsung laptops in UEFI mode, > > > > https://bugzilla.kernel.org/show_bug.cgi?id=47121 > > > > This module seems to be the culprit as it's grovelling around in the > > 0xf0000 region which has no mapping in either the e820 or EFI memory > > maps on the affected machines. > > So, does this mean that if we try to ioremap a memory location in the > kernel, like this driver is, it will not fail, but, when accessing the > memory, bad things happen? Yes. I'm not sure exactly what sequence of memory accesses is causing the MCEs because the above bug report states that the MCEs were frequent but intermittent and I don't have any hardware to reproduce this on. > That's not good, shouldn't the call to ioremap_nocache() have failed > originally? That sounds like a core EFI/platform bug here, and one that > you might run into other places. I think it's an x86 bug. AFAIK it's entirely possible to ioremap arbitrary memory addresses whether or not the firmware/BIOS knows about them (by which I mean, includes a mapping in the e820 map). It's just that traditionally the firmware didn't throw MCEs when you peeked at some part of the address map. The < 1MB region of the x86 address map also fills me with visions of voodoo. Jacob Shin and Yinghai Lu have been working on some patches that avoid mapping the holes (the address regions for which there is no entry in the e820 memmap) and I think that could be used to address this problem. > Shouldn't fixing that be the real fix? Absolutely, and it was always my intention to fix this properly so that I didn't have the same bug reported to me over and over again. However, initially I was more concerned about writing a fix that was good enough and small enough to be marked for stable. Messing with the kernel memory map, particularly for EFI systems, has been fraught with peril in the past. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
