From owner-freebsd-arch@FreeBSD.ORG Sat Jan 3 17:27:39 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E7D2A32; Sat, 3 Jan 2015 17:27:39 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7C8C764B5F; Sat, 3 Jan 2015 17:27:39 +0000 (UTC) Received: from [10.0.1.110] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 69CBE341F854; Sat, 3 Jan 2015 09:27:38 -0800 (PST) Subject: Re: odd behaviour with graphics, vt(4), VGA, and probing the text region leading to NMIs at boot Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alfred Perlstein In-Reply-To: Date: Sat, 3 Jan 2015 09:31:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2F715AD9-CF34-4516-B75E-E14C77BFD2E3@mu.org> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 17:27:39 -0000 Sounds like the virtualization code is sensitive to the mode. Meaning = that whatever is virtualizing the graphics card doesn't do the proper = thing when you're in a graphical mode. Can't the probes be turned off? Basically when the "card" is in gfx mode, it doesn't do the right thing = for those memory addresses. Sounds like the fix would be to not touch = those regions unless you're actually in text mode. =20 On Jan 3, 2015, at 9:12 AM, Adrian Chadd wrote: > Hi, >=20 > I found -head didn't boot on a T400 I have here with external radeon > graphics (ie, not using the intel graphics.) >=20 > I was getting a memory parity error NMI upon boot, shortly after > probing option ROMs. >=20 > It turns out that it's the ISA device probe/attach path trying to > attach the VGA adapter, and doing testing of the memory regions at > 0xb800:0000 (mono text) and 0xb000:0000 (colour text) - yes, I'm using > the 8086 real mode notation because I'm talking about ISA graphics > cards. >=20 > If I boot -HEAD with vt(4) in graphics mode, then it's using 640x480 > graphics and that's mapped at 0xa000:0000 for 64k. There apparently > isn't anything at 0xb800:0000 or 0xb000:0000 and touching those > regions leads to an NMI. >=20 > Now, the tricksy bit is that it's not accessing those addresses > directly - it's going via the physical map, that's mapped it at > 0xc00b8000 and 0xc00b0000 - yes, those are 32 bit (virtual, kernel > mode) addresses. I don't know if this is part of the problem. >=20 > If I boot -HEAD with vt(4) in text mode (hw.vga.textmode=3D1) then it = boots fine. >=20 > So - has anyone else seen/debugged this? It doesn't happen on > everything - just this one T400 I have. But I can't help but wonder > what else is going to get finnicky about ISA probing like this. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" >=20