[ipxe-devel] Negative implications of doing undinet_poll loop even if ISR not triggered?
Jarrod Johnson
jarrod.b.johnson at gmail.com
Sun Feb 12 13:57:35 UTC 2012
The only other strategy I would think is if the ISR is never triggered for
any reason by a certain deadline, it'd probably be a strong indicator that
something's not right.
UNDI is a minefield of dubious implementations...
On Sun, Feb 12, 2012 at 8:53 AM, Michael Brown <mbrown at fensystems.co.uk>wrote:
> On Sunday 12 Feb 2012 13:24:59 Jarrod Johnson wrote:
> > Well, I have an Emulex firmware that is doing so, but I think they may
> have
> > some working levels of firmware and some not. It might also have some
> sort
> > of interaction with system firmware, as I'm fairly sure they've gotten
> this
> > working in the past without the workaround and really insufficient time
> has
> > been spent determining why the interrupts aren't coming.
> >
> > As far as detecting, I haven't tried but I was wondering if on transmit
> of
> > a packet we set some really short timeout (tx completion should be very
> > very soon) and if no TX completion interrupt comes along during
> > undinet_poll, could declare that interrupts are not coming.
>
> That was my thought as well. I'm not sure that all PXE stacks will
> generate
> TX completion interrupts, though, so that strategy might create false
> positives.
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20120212/f0c72b7c/attachment.htm>
More information about the ipxe-devel
mailing list