odd behaviour with graphics, vt(4), VGA, and probing the text region leading to NMIs at boot

Alfred Perlstein bright at mu.org
Sat Jan 3 17:27:39 UTC 2015


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.  

On Jan 3, 2015, at 9:12 AM, Adrian Chadd wrote:

> Hi,
> 
> I found -head didn't boot on a T400 I have here with external radeon
> graphics (ie, not using the intel graphics.)
> 
> I was getting a memory parity error NMI upon boot, shortly after
> probing option ROMs.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> If I boot -HEAD with vt(4) in text mode (hw.vga.textmode=1) then it boots fine.
> 
> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> 



More information about the freebsd-arch mailing list