Marty,
I can confirm that the original patch is reversed. I applied the following,
and it resolves my gPXE failures for both HP G7 servers using the Emulex
(ServerEngines) NICs as well as Xsigo HCAs. Presumably this affects other
polling NICs as well.
--- gpxe.orig/src/arch/i386/drivers/net//undinet.c 2010-11-16
07:47:29.000000000 -0800
+++ gpxe.new/src/arch/i386/drivers/net//undinet.c 2010-11-16
07:53:07.000000000 -0800
@@ -49,6 +49,8 @@
int isr_processing;
/** Bug workarounds */
int hacks;
+ /** Flag to indicate device supports IRQ or not */
+ int irq_supported;
};
/**
@@ -252,7 +254,7 @@
if ( ! undinic->isr_processing ) {
/* Do nothing unless ISR has been triggered */
- if ( ! undinet_isr_triggered() ) {
+ if ( undinic->irq_supported && ! undinet_isr_triggered() ) {
/* Allow interrupt to occur */
__asm__ __volatile__ ( REAL_CODE ( "sti\n\t"
"nop\n\t"
@@ -357,10 +359,12 @@
struct s_PXENV_UNDI_OPEN undi_open;
int rc;
- /* Hook interrupt service routine and enable interrupt */
- undinet_hook_isr ( undinic->irq );
- enable_irq ( undinic->irq );
- send_eoi ( undinic->irq );
+ /* Hook interrupt service routine and enable interrupt if supported */
+ if (undinic->irq_supported) {
+ undinet_hook_isr ( undinic->irq );
+ enable_irq ( undinic->irq );
+ send_eoi ( undinic->irq );
+ }
/* Set station address. Required for some PXE stacks; will
* spuriously fail on others. Ignore failures. We only ever
@@ -425,9 +429,11 @@
pxeparent_call ( undinet_entry, PXENV_UNDI_CLOSE,
&undi_close, sizeof ( undi_close ) );
- /* Disable interrupt and unhook ISR */
- disable_irq ( undinic->irq );
- undinet_unhook_isr ( undinic->irq );
+ /* Disable interrupt and unhook ISR if supported */
+ if (undinic->irq_supported) {
+ disable_irq ( undinic->irq );
+ undinet_unhook_isr ( undinic->irq );
+ }
DBGC ( undinic, "UNDINIC %p closed\n", undinic );
}
@@ -548,6 +554,7 @@
undinic->hacks |= UNDI_HACK_EB54;
}
+ undinic->irq_supported = undi_iface.ServiceFlags & SUPPORTED_IRQ ? 1 :
0;
/* Mark as link up; we don't handle link state */
netdev_link_up ( netdev );
--
Geoffrey Silver
Global Infrastructure
CITADEL
-----Original Message-----
From: gpxe-boun...@etherboot.org [mailto:gpxe-boun...@etherboot.org] On Behalf
Of Marty Connor
Sent: Saturday, November 20, 2010 2:55 PM
To: muralidhar.appa...@emulex.com
Cc: gpxe@etherboot.org; etherboot-develop...@lists.sourceforge.net
Subject: Re: [gPXE] Patch to gPXE-1.0.1 UNDI code for Interrupt Vs Polling
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
CONFIDENTIALITY AND SECURITY NOTICE
The contents of this message and any attachments may be confidential and
proprietary and also may be covered by the Electronic Communications Privacy
Act. This message is not intended to be used by, and should not be relied upon
in any way, by any third party. If you are not an intended recipient, please
inform the sender of the transmission error and delete this message immediately
without reading, disseminating, distributing or copying the contents. Citadel
makes no assurances that this e-mail and any attachments are free of viruses
and other harmful code.
_______________________________________________
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
