Hi Muralidhar,

Your patch looks interesting, but I think you may have inverted the diff
(new->old instead of old->new).  Can you verify this?

Thanks,

/ Marty /

On 11/18/10 3:03 PM, muralidhar.appa...@emulex.com wrote:
> Hi,
> 
> Problem Description: We have noticed that gPXE UNDI code is always
> expecting interrupt(s) to be generated by the underlying NIC HW to
> process the receive path in undinet_poll() routine. This is causing
> problem on some of the PCI NIC controllers where though the NIC
> device supports IRQ and able to generate interrupts,  during PXE UNDI
> code some devices do not enable interrupts on their device and run in
> polling mode. Those devices expect upper layer UNDI drivers to poll
> for the receive packets instead of waiting for interrupt from the
> device. But in undinet_poll() routine the code checks for ISR
> triggered or not if not it just returns. [(please check "if
> (undinet_isr_triggered)" statement ) in undinet_poll()]
> 
> Solution Description: I have attached a patch here to take care of
> this so that gPXE UNDI code will work on both types of devices
> (interrupt & polling supported devices). The patch is to check
> whether the device supports IRQ or not in "ServiceFlags" returned by
> the API call PXENV_UNDI_GET_IFACE_INFO in undinet_probe() routine. If
> the underlying device supports IRQ  then enable the newly introduced
> flag "irq_supported" in undi_nic structure. Later in  undinet_open()
> & undinet_close() routines check this flag (irq_supported) to decide
> to hook the interrupts or to unhook the interrupts. Also in
> undinet_poll() routine check whether interrupt got generated or not,
> only if the device supports interrupts otherwise get the packet from
> underlying UNDI NIC drivers by calling PXENV_UNDI_ISR using FuncFlag
> PXEENV_UNDI_ISR_GET_NEXT.
> 
> I am attaching here the patch for review and acceptance.
> 
> Muralidhar Appalla
> Engineer Principal
> 2560 N.First Street
> Sanjose,CA
> Emulex Corporation
> (408)678-3472 (work)

_______________________________________________
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe

Reply via email to