This is SMBus controller found in Intel Platform Controller Hub (PCH),
which is a general name that refers to Intel 5 Series chipsets and
3400 Series chipsets.
Submitted by: Dmitry S. Luhtionov <mitya@cabletv.dp.ua>
MFC after: 3 days
- move global variables around to reduce the scope and make them
static if possible;
- add an ipfw_ prefix to all public functions to prevent conflicts
(the same should be done for variables);
- try to pack variable declaration in an uniform way across files;
- clarify some comments;
- remove some misspelling of names (#define V_foo VNET(bar)) that
slipped in due to cut&paste
- remove duplicate static variables in different files;
MFC after: 1 month
and the sockopt routines (the upper half of the kernel).
Whoever is the author of the 'table' code (Ruslan/glebius/oleg ?)
please change the attribution in ip_fw_table.c. I have copied
the copyright line from ip_fw2.c but it carries my name and I have
neither written nor designed the feature so I don't deserve
the credit.
MFC after: 1 month
At this time we pull out from ip_fw2.c the logging functions, and
support for dynamic rules, and move kernel-only stuff into
netinet/ipfw/ip_fw_private.h
No ABI change involved in this commit, unless I made some mistake.
ip_fw.h has changed, though not in the userland-visible part.
Files touched by this commit:
conf/files
now references the two new source files
netinet/ip_fw.h
remove kernel-only definitions gone into netinet/ipfw/ip_fw_private.h.
netinet/ipfw/ip_fw_private.h
new file with kernel-specific ipfw definitions
netinet/ipfw/ip_fw_log.c
ipfw_log and related functions
netinet/ipfw/ip_fw_dynamic.c
code related to dynamic rules
netinet/ipfw/ip_fw2.c
removed the pieces that goes in the new files
netinet/ipfw/ip_fw_nat.c
minor rearrangement to remove LOOKUP_NAT from the
main headers. This require a new function pointer.
A bunch of other kernel files that included netinet/ip_fw.h now
require netinet/ipfw/ip_fw_private.h as well.
Not 100% sure i caught all of them.
MFC after: 1 month
lookup {dst-ip|src-ip|dst-port|src-port|uid|jail} N
which searches the specified field in table N and sets tablearg
accordingly.
With dst-ip or src-ip the option replicates two existing options.
When used with other arguments, the option can be useful to
quickly dispatch traffic based on other fields.
Work supported by the Onelab project.
MFC after: 1 week
after ether_ifattach(), as ether_ifattach() initializes it with
ETHER_HDR_LEN.
While I'm here remove setting if_mtu, it's already handled in
ether_ifattach().
called and vge(4) used to drive auto-negotiation timer(mii_tick) in
vge_tick(). Therefore the mii_tick was not called for every hz such
that auto-negotiation complete was never handled in vge(4).
Use mii_pollstat to extract current negotiated speed/duplex instead
of mii_tick. The latter is valid only for auto-negotiation case.
While I'm here change the confusing function name vge_tick() to
vge_link_statchg().
is called in vge_init_lock(), vge(4) always used to reload EEPROM.
Also add more comment why vge(4) clears VGE_CHIPCFG0_PACPI bit.
While I'm here add missing new line in vge_reset().
controllers(VT613x), we assume the PHY address is 1.
Use the saved PHY address in MII register access routines and
remove accessing VGE_MIICFG register.
While I'm here save PCI express capability register which will be
used in near future.
record device specific bits. Remove vge_link and use vge_flags.
While here, move clearing link state before mii_mediachg() as
mii_mediachg() may affect link state.
if_alloc() of ifp. This fixes the panic reported in the PR, but
not the attach failure.
PR: kern/139079
Tested by: Steven Noonan <steven uplinklabs.net>
Reviewed by: thompsa
Approved by: ed (mentor)
MFC after: 2 weeks`
seems to work like a tag that indicates 'not list end' of queued
frames. Without having a VGE_TXDESC_Q bit indicates 'list end'. So
the last frame of multiple queued frames has no VGE_TXDESC_Q bit.
The hardware has peculiar behavior for VGE_TXDESC_Q bit handling.
If the VGE_TXDESC_Q bit of descriptor was set the controller would
fetch next descriptor. However if next descriptor's OWN bit was
cleared but VGE_TXDESC_Q was set, it could confuse controller.
Clearing VGE_TXDESC_Q bit for transmitted frames ensure correct
behavior.
o Separate TX/RX buffer DMA tag from TX/RX descriptor ring DMA tag.
o Separate RX buffer DMA tag from common buffer DMA tag. RX DMA
tag has different restriction compared to TX DMA tag.
o Add 40bit DMA address support.
o Adjust TX/RX descriptor ring alignment to 64 bytes from 256
bytes as documented in datasheet.
o Added check to ensure TX/RX ring reside within a 4GB boundary.
Since TX/RX ring shares the same high address register they
should have the same high address.
o TX/RX side bus_dmamap_load_mbuf_sg(9) support.
o Add lock assertion to vge_setmulti().
o Add RX spare DMA map to recover from DMA map load failure.
o Add optimized RX buffer handler, vge_discard_rxbuf which is
activated when vge(4) sees bad frames.
o Don't blindly update VGE_RXDESC_RESIDUECNT register. Datasheet
says the register should be updated only when number of
available RX descriptors are multiple of 4.
o Use __NO_STRICT_ALIGNMENT instead of defining VGE_FIXUP_RX which
is only set for i386 architecture. Previously vge(4) also
performed expensive copy operation to align IP header on amd64.
This change should give RX performance boost on amd64
architecture.
o Don't reinitialize controller if driver is already running. This
should reduce number of link state flipping.
o Since vge(4) drops a driver lock before passing received frame
to upper layer, make sure vge(4) is still running after
re-acquiring driver lock.
o Add second argument count to vge_rxeof(). The argument will
limit number of packets could be processed in RX handler.
o Rearrange vge_rxeof() not to allocate RX buffer if received
frame was bad packet.
o Removed if_printf that prints DMA map failure. This type of
message shouldn't be used in fast path of driver.
o Reduce number of allowed TX buffer fragments to 6 from 7. A TX
descriptor allows 7 fragments of a frame. However the CMZ field
of descriptor has just 3bits and the controller wants to see
fragment + 1 in the field. So if we have 7 fragments the field
value would be 0 which seems to cause unexpected results under
certain conditions. This change should fix occasional TX hang
observed on vge(4).
o Simplify vge_stat_locked() and add number of available TX
descriptor check.
o vge(4) controllers lack padding short frames. Make sure to fill
zero for the padded bytes. This closes unintended information
disclosure.
o Don't set VGE_TDCTL_JUMBO flag. Datasheet is not clear whether
this bit should be set by driver or write-back status bit after
transmission. At least vendor's driver does not set this bit so
remove it. Without this bit vge(4) still can send jumbo frames.
o Don't start driver when vge(4) know there are not enough RX
buffers.
o Remove volatile keyword in RX descriptor structure. This should
be handled by bus_dma(9).
o Collapse two 16bits member of TX/RX descriptor into single 32bits
member.
o Reduce number of RX descriptors to 252 from 256. The
VGE_RXDESCNUM is 16bits register but only lower 8bits are valid.
So the maximum number of RX descriptors would be 255. However
the number of should be multiple of 4 as controller wants to
update 4 RX descriptors at a time. This limits the maximum
number of RX descriptor to be 252.
Tested by: Dewayne Geraghty (dewayne.geraghty <> heuristicsystems dot com dot au)
Carey Jones (m.carey.jones <> gmail dot com)
Yoshiaki Kasahara (kasahara <> nc dor kyushu-u dot ac dotjp)
struct callout_cpu. From the comment in the file:
+ * There is one struct callout_cpu per cpu, holding all relevant
+ * state for the callout processing thread on the individual CPU.
+ * In particular:
+ * cc_ticks is incremented once per tick in callout_cpu().
+ * It tracks the global 'ticks' but in a way that the individual
+ * threads should not worry about races in the order in which
+ * hardclock() and hardclock_cpu() run on the various CPUs.
+ * cc_softclock is advanced in callout_cpu() to point to the
+ * first entry in cc_callwheel that may need handling. In turn,
+ * a softclock() is scheduled so it can serve the various entries i
+ * such that cc_softclock <= i <= cc_ticks .
Together with a smaller patch committed in september, this fixes a
bug that affects 8.0 with apps that rely on callouts to fire exactly
in the number of ticks specified (qemu among them).
Right now, callouts in 8.0 fire one tick late.
This was discussed in september with JeffR and jhb
MFC after: 3 days
