I'm sorry I wasn't clear.  The problem I'm seeing is that on my NetBSD
machine, with the bge(4) driver active and running with hardware tcp4csum
enabled, the machine recieves a large number of packets with tcp checksum
errors.  When I run tcpdump to watch a particular flow, I see the other
side, the non-NetBSD machine, sending packets, but the NetBSD machine isn't
responding, even though the packets are coming in.  My speculation, based
on the test of turning off tcp4csum and then watching the same flow and
seeing all work fine, is that somehow, and this is where I'm not sure I
completely understand what is going on, even though, for purposes of
running tcpdump, the interface is in promiscuous mode, and I see the
incoming traffic, the stack is rejecting the packet as having a bad tcp
checksum, after it gives the packet to the bpf(4) driver and tcpdump.  
	So, I guess my question, based on this further analysis, is, if the
problem were a hardware  error, would incoming packets even make it to the
bpf driver?  If the answer is no, then it seems like the problem is
somewhere in the bge(4) driver in as much as it is mis-reporting the status
of the tcp4 checksum test that the hardware performed.
Any ideas, anyone?

P.S.  For the record, for the tests I was doing, I couldn't report on the
tcp checksum error rate on the non-NetBSD machine, because there were many
of them, and they weren't machines I have control over.  However, it is
pretty clear, now, as I think about it, that the problem is with the
reception of traffic, not the generation of it.