* Kenneth R. Crudup wrote: > > > write-combining @ 0x604a800000-0x604b000000 > > > uncached-minus @ 0x604b100000-0x604b110000 > > > This WC region was probably unaffected by the bug. > > For my education, and for completeness' sake, is there a proc/sys entry > that would tell me which device/module has reserved which PAT region? Not that I know of :-/ I suspect you could run the attached patch and run: dmesg | grep -i 'x86/pat' To see all the ioremap() activities, with a symbolic name of the caller printed. I'm quite sure 0x604a800000 will be among them, pointing to somewhere like i915_vma_pin_iomap(), ggtt_init_hw() or ggtt_probe_common() in the i915 GPU driver? Another possibility is that this is the FB framebuffer, mapped by efifb_probe() or so? Patch is untested though. :-) Thanks, Ingo =================> arch/x86/mm/ioremap.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 1ff9c2030b4f..2f0a4f99471a 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -166,6 +166,8 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size, int retval; void __iomem *ret_addr; + printk("# x86/pat: ioremap(%016Lx, %08lx, pcm: %d), caller: %pS\n", phys_addr, size, pcm, caller); + /* Don't allow wraparound or zero size */ last_addr = phys_addr + size - 1; if (!size || last_addr < phys_addr)