Followup: Netgear missing ARPs

[Neale Banks]

On Wed, 30 Jun 1999, Donald Becker wrote:

> We should use the name "PNIC" to avoid confusing with the older Tulip-based
> FA310TX card.

OK (clarity is going to be of the essence here).  Is there a simple guide
to FA310TX rev #s and what is and is not a PNIC?

> > Ah, yes, I forgot the promisc bit - at Keith's suggestion I tried this and
> > consistently that turning on promisc made the bug go away.  But, turning
> > on and immediatedly turning off promisc after "ifconfig up"ing the
> > interface didn't help (seems the interface needed to be in promisc at the
> > time of the arp).
> 
> My current theory is that the chip doesn't know it's own address, perhaps
> due to the driver not finishing the setup in time (?). 
> The confusing part is the chip recieving the transmitted packet, especially
> in half duplex mode.  That would point to a hardware bug.

Would that be consistent with the further observation that inbound arps
generally(*) succeed and that all is well after the inbound arp has
succeeded?

If your theory is correct, then this observation would imply that somehow
amongst the inbound arp query (ethernet broadcast) and outbound arp reply
(ethernet unicast?) the card figures out it's MAC address.

Ditto for the post "ifconfig up" change non-promisc->promisc->non-promisc
(but there are some vagaries here too - it works if typed from the command
line after the system has booted but not if included in the boot script
that does the initial "ifconfig up" - perhaps another pointer to a timing
thing?).

*generally: I haven't tested this one, but have seen situations pointing
to a hypothesis that the card/system behaviour is different when it is in
the state of having sent an arp query and the arp is "incomplete".  I
figure the test should go something like:
(1) PNIC arps OTHER
(2) confirm arp "incomplete"
(3) clear arp cache on OTHER
(4) OTHER arps PNIC
(5) check arp cache on both sides.

> Please continue tracking this problem down.
> I won't be able to work on this specific problem for at least three weeks,
> and I don't have any inside information on how the chip works that would
> make me more effective than you.

The best I can do is to make observations as faithfully as I can and keep
those clearly separate from any conclusions/speculations I then drive.
With a bit of luck, I might even be able to raise a good question or two
as well.  As for coding and driver internals - I'll leave that to others.

> I'm also considerign a major change in the PowerPC support -- I'll have the
> driver byte swap the descriptor rather than count the Tulip hardware.  That
> will allow the work-alike chips (PNIC, etc.) to be used on the PPC as well.
> Comments?

Playing the optimistic cynic, I'm (1) thinking that we may be on the verge
of cracking the FA310TX nut and (2) concerned about a subsequent "major
change". Would these contemplated changes be properly segregated from the
non-PPC code (e.g. in #IFs)?

Thanks,
Neale.