From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga02.intel.com ([134.134.136.20]) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TAiwB-0004Gl-Nd for linux-mtd@lists.infradead.org; Sun, 09 Sep 2012 14:56:40 +0000 Message-ID: <1347202600.5876.7.camel@sbsiddha-ivb> Subject: Re: mtd: kernel BUG at arch/x86/mm/pat.c:279! From: Suresh Siddha To: Linus Torvalds Date: Sun, 09 Sep 2012 07:56:40 -0700 In-Reply-To: References: <1340959739.2936.28.camel@lappy> <1347057778.26695.68.camel@sbsiddha-desk.sc.intel.com> <1347062045.26695.82.camel@sbsiddha-desk.sc.intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: "linux-kernel@vger.kernel.org" , linux-mm , linux-mtd@lists.infradead.org, Sasha Levin , Dave Jones , Andrew Morton , dwmw2@infradead.org Reply-To: suresh.b.siddha@intel.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sat, 2012-09-08 at 12:57 -0700, Linus Torvalds wrote: > Whatever. Something like this (TOTALLY UNTESTED) attached patch should > get the mtdchar overflows to go away, It looks good to me. Acked-by: Suresh Siddha Sasha, can you please give this a try? > but it does *not* fix the fact > that the MTRR start/end model is broken. It really is technically > valid to have a resource_size_t range of 0xfffffffffffff000+0x1000, > and right now it causes a BUG_ON() in pat.c. > > Suresh? yes but that is not a valid range I think because of the supported physical address bit limits of the processor and also the max architecture limit of 52 address bits. I guess we should be checking for those limits in pat.c, especially bits above 52 are ignored by the HW and they can easily cause conflicting aliases with other valid regions. I will get back with a different patch to fix this. thanks, suresh