Oooh. I found an [mildly] interesting one today. Lately I've been making use of a small Windows via MEMDISK. It goes:
Native PXE -> PXELINUX -> gPXE (undionly.kkpxe) -> SAN-boot -> SYSLINUX -> MEMDISK -> Windows Today I [roughly] determined the point of failure for one particular model of computer... When I do: SYSLINUX -> MEMDISK -> Windows everything is fine. However in the former scenario, the computer freezes as soon as the NIC driver is installed (or in other tests where it's already installed, when the driver is started). Kernel debugging shows lots of interrupts. I was able to avoid the freeze by manually uninstalling and re-installing various PCI bus devnodes, which I assume passed along a reset of some kind of the NIC. The singular change of removing this NIC driver allows for correct operation. I am going to guess that this particular Windows driver doesn't deal well with having the NIC in whatever state gPXE has left it in. Too bad, because we have no idea when the OS will take control and not need gPXE again. Anyway, we might come across similar buggy Windows drivers in SAN-boot scenarios again. This one was for: 3Com 3C920 Integrated Fast Ethernet Controller (3C905C-TX Compatible) Vendor ID: 10B7 Device ID: 9200 Windows driver: EL90XBC5.SYS One possible solution would involve having some code in the MEMDISK image to inform gPXE to shut down the NIC. In my case, once the MEMDISK has booted, the work of the SAN connection is done. - Shao Miller _______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
