On Wednesday 10 Nov 2010 19:38:04 Muralidhar.Appalla at emulex.com wrote: > We are having problem booting through gPXE with our UNDI drivers and we > debugged this issue further and found that gPXE always expecting the > underlying hardware to generate interrupts whenever it receives a packet > from network. In our case as we are running in polling mode and our > hardware has not been programmed to generate interrupts. In this > situations how can we make gPXE work with our UNDI drivers? > > Is there any reason that gPXE always expects interrupts to be enabled by > underlying hardware? In my opinion can gPXE first find out whether device > supports interrupts or not by looking at the bit 12 in "Serviceflags" > field in PXEENV_UNDI_GET_IFACE_INFO (opcode=0x13) API and accordingly act > on that? If this bit is set then that means device supports interrupts > otherwise device does not support interrupts and upper layer protocol > drivers should not hook interrupts. > > Any ideas or advise is greatly appreciated.
(Redirecting to ipxe-devel list; please use iPXE instead of gPXE.) The original UNDI implementation in Etherboot used the underlying PXE stack in polling mode. Unfortunately, there are some cards that hang the machine when used in this way. Specifically, calling PXENV_UNDI_ISR with FuncFlag set to PXENV_UNDI_ISR_IN_START when the card does *not* have a packet ready to receive would hang the machine, rather than returning PXENV_UNDI_ISR_OUT_NOT_OURS. The implementation was therefore changed to call PXENV_UNDI_ISR only in response to interrupts. It would be viable to check the SUPPORTED_IRQ bit returned by PXENV_UNDI_GET_IFACE_INFO, though this is not done by the current code. Michael
