descriptions of WinCE behavior from Ge'rard Gambaro (jornada.free.fr).
Not tested on an actual ABF unit.
Hidden under #if 0, as we don't have a platform id for French Jornadas yet.
But I think it's better off committed before it's got lost.
observation is that some 570x devices can get themselves into a state
where they miscompute off-loaded TCP or UDP checksums on packets so
small that Ethernet padding is required. Further obsevation suggests
that the bge checksum-offload hardware is adding those padding bytes
into its TCP checksum computation. (Once a 5700 gets in this state,
even a warm boot won't fix it: it needs a hard powerdown.)
Work around the problem by padding such runts with zeros: even if the
checksum-offload adds in extra zeros, the resulting sum will be correct.
Also, dont trust the checksum-offload on received packets smaller than
the minimum ethernet frame, in case the Rx-side has a similar bug.
Finally, on packets where we do trust the outboard Rx-side TCP or UDP
checksum, the bge did not include the pseudo-header. Set the
M_CSUM_NO_PSEUDOHDR bit as well as M_CSUM_DATA, and rely on
udp_input() or tcp_input() adding in the sum via in_cksum_phdr().
if we m_dup() a packet to compactify it, and later run out of DMA
descriptors, bge_encap() will return ENOBUFS, hoping the driver will
try again later. But we have just m_freem()'d the original chain
which was m_dup()'d, leaving a pointer to the just-freed packet header
in the tx queue.
Fix by always walking the chain, shuffling data towards the head;
except if we find a runt in the very last mbuf, we must borrow data
from its predecessor.
(Patch is verbatim from a third-party tree, apologies for any style woes.)
- defer access to interrupt configuration register, as its existence depends on
HDRTYPE.
- add "skip particular funtion in multifunction device" functionality
to quirk table.
- add GEODE/NS SC1100 quirk (now boots on soekris Net4801).
means "count", in this context) the entropy we're adding because we poll the
device periodically. Sure, we poll it periodically, but it's a hardware
RNG -- the data returned should be random no matter when we read the
register!
instead of keeping sysmon_envsys_list_slock spinlock held
because some drivers might sleep in sysmon_envsys ops,
XXX sysmon_envsys_lock is now redundant
three PRs regarding them: 17836, 17837, 17838. Did a few kernel
compiles with them just to make sure they are okay. Approved by
christos@, thanks to Dave for sending the PRs and verifying to me
that they work.
