* Add support for 5704C dual-channel chip with integral copper PHY (tested)
and 5704S dual-channel SERDES/TBI gbic (untested). Add PHY DSP patch
for 5704.
* Update PHY DSP-code patch for bcm5401 to match latest Linux driver.
* Add PHY DSP-code patch for 5703 (untested).
* Update onchip buffer tunables to recommended values from Linux drivers.
* Disable MWI access. This chip family cannot hanlde PCI stalls
in the middle of an MWI burst. The driver has heuristics to detect PCI
line size, but under load, some PCI bridges may force stalls which
the attach-time heruistics do not catch. Some PCI bridges never
do this, so maybe it should be a tunable option.
* bcm5700 rev Bx chips have a race condition, where updating the
Tx producer pointer goes un-noticed by the chip. Workaround is to
write the new producer-pointer value twice.
* bcm5700 chips rev Bx wedge up if given DMA descriptors of
eight bytes or less. Once hit, only reovery is a watchdog timeout/reset.
If the offending packet is retransmitted, the chip will wedge again...
Check for teeny fragments in a Tx request, and either fold the
teeny chunk residue into an adjacent mbuf, or m_dup the entire buffer.
(NB: quirk not yet enabled; in-place folding tested only on FreeBSD.)
* Add workaround for revision Bx bcm5700: chip bugs in decoding
of PCI register writes may leave the hardware in (partial) powersave state,
such that writes to "indirect" registers do not work.
Explicitly force chip into D0 state at attach time.
* Accessing PHY registers with the bge chip in autopoll mode, when
link-state is the process of changing, may cause the bge chip to
assert PCI errors. Workaround: when doing miibus register access,
save autopoll state, disable around access, and restore autopoll state.
NB: issuing PHY resets may give a window where the problem still occurs.
* Increase Tx interrupt-coalescing thresholds, to reduce Tx-done interrupts.
after the other CPUs have already return into the PROM through prom_cpustop().
So don't do it; try to halt the other CPUs only when an actual `halt'
is requested.
My guess in this case is that the PROM does not expect its original boot
CPU to call prom_cpustop(0), or possibly treats it as the equivalent of
a prom_halt() which is then called again by some other CPU. In any case,
the result is garbage.
jonathan