Michael Decker: Driver Development

Week 9

23 & 24 July

Marty reported the eepro100 stopped receiving packets after a delay on occasion. He was testing with an 82557, which I unfortunately don't have available to test with. I did manage to reproduce the behavior with an 82558. It is a very intermittent bug.

Intel does report a possible rx hang condition from waking up the MAC on an 82559B. I suspect this is what is occuring here. However, I have not found an errata listing for the 82557 and don't know if such a bug exists in these cards as well.

Intel's workaround for the 82559B is to disable the MAC from sleeping via an EEPROM bit. This seems to push the problem into the user realm. While this change can be made programmatically, it seems to cross a line in configuring user's hardware. And besides, even Donald Becker didn't like the idea. The linux driver's solution seems to periodically issue a multicast list command to keep the MAC awake.

Unfortunately, the gPXE driver doesn't use multicast filters currently. The code to perform this operation is rather lengthy, involving a custom config command followed by the multicast command. My own personal experience with issuing config commands has been uncomfortable, as I found it necessary to issue a following START rather than RESUME, despite not finding documentation indicating such. The linux driver uses a RESUME following the config, so I'll have to hope this config command works as such.

However, in the mean time.. I was amazed to actually uncover a bug that was staring me in the face the whole time in ifec_net_poll(). One extra ! symbol was completely skipping over the code intended to keep the receiver active.