On Thu, May 27, 2010 at 2:13 AM, Joshua Oreman <[email protected]> wrote: > On Thu, May 27, 2010 at 1:59 AM, Michael Brown <[email protected]> > wrote: >> On Thursday 27 May 2010 09:30:42 Joshua Oreman wrote: >>> This was reported by Kyle Kienapfel on #etherboot today, on a system >>> with a Phoenix Award BIOS ("the motherboard from an Acer Aspire E700 >>> crammed into an old case"). He was getting a banner of >>> >>> 03:03.0 CE00 PCI3.00 PnP BBS pmm0...@08 EC00 >>> >>> and a freeze with two gibberish characters printed immediately after >>> the POST-time prompt. This failure mode suggests to me that we did >>> write something to EC00; if we hadn't, it seems there shouldn't have >>> been a problem until the actual BEV execution. the A test with iPXE's >>> PMM enhancements worked: >>> >>> 03:02.0 CE00 PCI3.00 PnP BBS PMM+0042D600+0043B4E0 E000 >>> >>> though I suspect that was only randomly by virtue of the different >>> runtime address. With gPXE + this patch we got >>> >>> 03:02.0 CE00 PCI3.00!DE00 PnP BBS pmm0...@08 CE00 >>> >>> which also worked. >>> >>> I'm not sure why the runtime address was different each time, but I >>> don't know of any system where 0xe0000 and up are not mapped to [a >>> shadowed copy of] the system BIOS. >> >> I don't know of any such system, but they *are* allowed to exist according to >> the spec. >> >> The iPXE banner line suggests that we successfully relocated to 0xe000, which >> would indicate that the BIOS in question does allow (and expect) option ROMs >> to live outside the [0xc000,0xe000) region. Also, although the runtime >> address is changing each time, it is always (so far) a potentially valid >> address (in the range [0xa000,0xffff) and 2kB-aligned). > > It's possible that the code from E000 to E800 or so has to do with > system bootstrapping that's not called after we return; this is what I > meant by "suspect this was only randomly". The absence of a crash > doesn't confirm that we did the right thing, but the presence of a > crash is a pretty strong indicator that we did the wrong thing. > > Note that my patch doesn't actually care whether the runtime segment > is above E000; it only checks whether the init-time segment is below > A000. The logic is that if the init-time segment is already in the > BIOS area it's probably meant to also be the runtime segment. I'm not > sure what the relative numbers of systems are that validly put the > runtime segment above E000 versus validly put the init-time segment > above A000 versus have broken PCI3 support that happens to leave > something reasonable-looking in %gs (where this case seems to be one > of the latter). Fixing the problem on this BIOS would necessarily > break one of the first two groups. > >> It would be interesting to see what happens to a second such iPXE/gPXE ROM in >> this system; the relative positioning of the init-time and runtime segments >> for the two (preferably identical) ROMs might give some insight into what the >> BIOS is doing. > > I agree. Adding Kyle on CC - Kyle, any chance you could try stock gPXE > and gPXE-with-this-patch with two identically-flashed cards in your > problem system? > > -- Josh >
Intel disabled 03:02.0 CD00 PCI3.00!DE00 PnP BBS pmm0...@08 CD00 03:03.0 CE00 PCI3.00!DE00 PnP BBS pmm0...@08 CE00 Intel Enabled 03:02.0 CE00 PCI3.00!DE00 PnP BBS pmm0...@08 CE00 03:03.0 CF00 PCI3.00!DE00 PnP BBS pmm0...@08 CF00 Also of note, dhcp doesn't work from the roms in this problem computer, also not from a chainloaded gpxe.pxe (dhcp net1) card works inside linux _______________________________________________ gPXE-devel mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe-devel
