Non-SMP, i386-only, no polling in the idle loop at the moment.
To use this code you must compile a kernel with
options DEVICE_POLLING
and at runtime enable polling with
sysctl kern.polling.enable=1
The percentage of CPU reserved to userland can be set with
sysctl kern.polling.user_frac=NN (default is 50)
while the remainder is used by polling device drivers and netisr's.
These are the only two variables that you should need to touch. There
are a few more parameters in kern.polling but the default values
are adequate for all purposes. See the code in kern_poll.c for
more details on them.
Polling in the idle loop will be implemented shortly by introducing
a kernel thread which does the job. Until then, the amount of CPU
dedicated to polling will never exceed (100-user_frac).
The equivalent (actually, better) code for -stable is at
http://info.iet.unipi.it/~luigi/polling/
and also supports polling in the idle loop.
NOTE to Alpha developers:
There is really nothing in this code that is i386-specific.
If you move the 2 lines supporting the new option from
sys/conf/{files,options}.i386 to sys/conf/{files,options} I am
pretty sure that this should work on the Alpha as well, just that
I do not have a suitable test box to try it. If someone feels like
trying it, I would appreciate it.
NOTE to other developers:
sure some things could be done better, and as always I am open to
constructive criticism, which a few of you have already given and
I greatly appreciated.
However, before proposing radical architectural changes, please
take some time to possibly try out this code, or at the very least
read the comments in kern_poll.c, especially re. the reason why I
am using a soft netisr and cannot (I believe) replace it with a
simple timeout.
Quick description of files touched by this commit:
sys/conf/files.i386
new file kern/kern_poll.c
sys/conf/options.i386
new option
sys/i386/i386/trap.c
poll in trap (disabled by default)
sys/kern/kern_clock.c
initialization and hardclock hooks.
sys/kern/kern_intr.c
minor swi_net changes
sys/kern/kern_poll.c
the bulk of the code.
sys/net/if.h
new flag
sys/net/if_var.h
declaration for functions used in device drivers.
sys/net/netisr.h
NETISR_POLL
sys/dev/fxp/if_fxp.c
sys/dev/fxp/if_fxpvar.h
sys/pci/if_dc.c
sys/pci/if_dcreg.h
sys/pci/if_sis.c
sys/pci/if_sisreg.h
device driver modifications
Introduce an additional device flag for those NICs which require the
transmit buffers to be aligned to 32-bit boundaries.
(the equivalen fix for STABLE is slightly simpler because there are
no supported chips which require this alignment there.)
controllers. There still seems to be some issues with the DRI copying code
for some adapters, at least it doesn't hang the system now. Input would be
appreciated.
PR: 32301
Obtained from: Eric Anhlot <eanholt@gladstone.uoregon.edu>, Joe <joeo@nks.net>
The reason we are required to commit to -current first is so that later
MFC's do not risk the loss of existing bug fixes. Even if this was not
strictly required in -current, it should still be fixed there too.
The reason we are required to commit to -current first is so that later
MFC's do not risk the loss of existing bug fixes. Even if this was not
strictly required in -current, it should still be fixed there too.
mbuf allocation fails, and fix (i hope) a couple of style bugs.
I believe these printf() are extremely dangerous because now they can
occur on every incoming packet and are not rate limited. They were
meant to warn the sysadmin about lack of resources, but now they
can become a nice way to panic your system under load.
Other drivers (e.g. the fxp driver) have nothing like this.
There is a pending discussion on putting this kind of warnings
elsewhere, and I hope we can fix this soon.
underlying unaligned bcopy) on incoming packets that are already
available (albeit unaligned) in a buffer.
The performance improvement varies, depending on CPU and memory
speed, but can be quite large especially on slow CPUs. I have seen
over 50% increase on forwarding speed on the sis driver for the
486/133 (embedded systems), which does exactly the same thing.
The behaviour is controlled by a sysctl variable, hw.dc_quick which
defaults to 1. Set it to 0 to restore the old behaviour.
After running a few experiments (in userland, though) I am convinced
that doing the m_devget() is detrimental to performance in almost
all cases.
Even if your CPU has degraded performance with misaligned data,
the bcopy() in the driver has the same overhead due to misaligment
as the one that you save in the uiomove(), plus you do one extra
copy and pollute the cache.
But more often than not, you do not even have to touch the payload,
e.g. when you are forwarding packets, and even in the often-cited
case of NFS, you often end up passing a pointer to the payload to
the disk controller.
In any case, you can play with the sysctl variable to toggle between
the two behaviours, and see if it makes a difference.
MFC-after: 3 days
have alignment problems.
On small boxes (e.g. the net4501 from Soekris, featuring a 486/133)
this provides huge performance benefits: the peak forwarding rate
with avg.sized packets goes up by 50-70% because of this change
alone. Faster CPUs might benefit less from this change, but in any
case the CPU has better things to do than waste time on useless
memory-to-memory copies.
Several drivers (for Tulip-like cards) might benefit from a similar
change.
Right now the new behaviour is controlled by a sysctl variable,
hw.sis_quick which defaults to 1 (on), you can set it to 0 to
reintroduce the old behaviour (and compare the results). The
variable is only there to show how much you can gain with this
change, it will go away soon.
Also, slightly simplify the code to initialize the ring buffers,
and remove a couple of dangerous printf's which could trigger on
any packet in case of mbuf shortage.
MFC-after: 3 days
idle and the driver would not detect the event, requiring userland
to cycle the interface to bring it up again.
The fix consists in adding SIS_IMR_RX_IDLE to the interrupt mask and
add a command in sis_intr() to restart the receiver when this happens.
While at it, make the test of status bits more efficient.
in the 21143, instead of giving priority to the receive unit.
This gives a 10-15% performance improvement in the forwarding rate
under heavy load.
Reviewed-by: Bill Paul
Jonathon Lemon's driver (gx) is at least as fast and has more features
and is likely to be better supported.
It is also possible that Intel might support this chipset in FreeBSD
with their own driver. Somewhat secretive and furtive rumblings from
certain Yahoo employees have indicated that this might happen soon.
I'm a little unhappy at the lack of discussion on the net list about
this, or on developers, or on hackers, or the lack of mention on
audit. This then leaves me to try and figure out the right thing
to do.
I've concluded that the right thing to do is to remove wx from FreeBSD,
as this is probably best for FreeBSD.
What the heck, the OpenBSD version will benefit.
1. Add wx_txint_delay as a tunable (defaults to 5000 now, or ~5ms) and switch
to using delayed TXDW interrupts. Since the chip continues to reload the
TIDV with this value for each descriptor written back, this allows continued
deferral of the actual interrupt until the last packet completes (assuming
that 5ms between multiple packets transmitting is reasonable).
2. Add two other SYSCTL entities:
hw.wx.dump_stats
hw.wx.clear_stats
to be used, hackey hackey, to get the watchdog routine to dump/clear
the current softc statistics.
Usage would be:
sysctl -w hw.wx.dump_stats=UNIT
to cause the current stats to be dumped for UNIT.
3. Attempt to clean up wx_detach routine so we don't panic. Well, things
still panic, but given that the code is just like other NIC drivers,
I suspect it's actually something elsewhere, like e1000phy, that's actually
blowing up.
4. Skip the entire test for runt packets- after doing somet thinking
and experimenting, I believe that the chip only doesn't like it if
the whole frame to xmit is < 16 bytes- each TFD can be some fragment
of that. This should improve performance a chunk because of all of the
(14 byte ETHERHEADER + DATA) mbuf chains.
5. Keep track of total frame length. Try not to xmit an odd byte frame-
this is supposed to get around some dumb Cisco switch problems.
6. On the last packet, also set Interrupt Delay && Report Packet Sent
(see #1 above)
7. Attempt to do xmit garbage collection *first* in order to avoid setting
IFF_OACTIVE if at all possible.
MFC after: 1 week
We only support the size of frame we are currently allocating, which
is MCLBYTES - sizeof (struct ether_header) usable, so don't set an
MTU that would go over this.
it now really gets in the way.
This allows us to fix several problems- not least of which was problems
of ordering about when you'd have a device softc for an miibus child
available or not. Move some steps of things around.
Put the ifnet/arpcom structure at the head of the softc (PR 29249).
Don't do tx gc in the interrupt service routine- that seems to make
things a bit more efficient.
Enable jumbo support by default- but this version of 'jumbo' is broken
because it really is just using multiple tfd/rfd's to match a packet,
which will never be > CLSIZE anyway.
This should begin the first steps toward cleaning this driver up.
PR: 29249
MFC after: 1 week
seems to set up memory spaces correctly. This change actually did work for
me using -STABLE, XFree86 4.0.3 ~ some snapshot of DRI awhile back. I sent
mail to dfr to no avail, perhaps someone else would like to test it with
DRI.
Anyway, people have been nagging me about this change for awhile, so here's
the commit.
amdpm(4) and smb(4).
This device can be used with userland programs such as sysutils/lmmon
to retrieve sensor information from the motherboard.
PR: kern/23989
Obtained from: Matthew C. Forman <mcf@dmu.ac.uk>
Based on: alpm(4)
Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
laptops with this chip should test this and report back as I don't have
access to this hardware myself. People with -stable systems should try
the patch at:
http://www.freebsd.org/~wpaul/conexant.patch.gz
Submitted by: Phil Kernick <Phil@Kernick.org>
dual function card. It needs pretty much the same flags as the 656C,
except that it seems to need both the INVERT_MII_PWR and INVERT_LED_PWR
flags set. Tested with cardbus in -current as of today.
Also added support for the 3c656, which looks to be the same as
the 656B, except it doesn't need the EEPROM_8BIT flag. I think. This
one is untested, but the added support should not break any of the
other cards.
prevent/workaround TX lockups in this driver. The secret seems to be to
not let the TX DMA queue become too full. If we have too many packets
in the queue, we should wait for them to drain a bit before trying to
queue more. This should prevent the lockup from occurring, and if it
does occur, there is special code in sf_start() to kick the NIC in the
head and get it going again.
Special thanks to Glen Neff for helping me test this fix.
night of testing before merging to -stable.
Also added to code to detect TX underruns and automatically increase the
TX threshold to avoid them. Carefully placed diagnostig printf() about
this under #ifdef DIAGNOSTIC to avoid getting any panicky e-mails from
confused users, like I always do with the xl and dc drivers.
calling vtophys() and contigmalloc()/contigfree() directly. Hopefully,
I have shaken out all of the problems with busdma on the alpha now.
(Everything seems to work as expected.)
Also, change the max RX DMA limit to 1024 bytes instead of "unlimited,"
as the latter seems not to work correctly on the alpha that I tested.
(At 100Mbps, all attempts to receive frames yield RX errors.)
common_attach is wrong as common attach initialize some fileds used by
mediainit routine. This was hard to notify because loading driver as kld
lead to mediainit routine being called after common_attach, though probe_phy
is called before.
MFC after: 1 week
never completed" message. The RX reset takes longer complete than it
used to, a lot longer in fact than xl_wait() is prepared to wait.
When we do the RX reset in xl_reset(), this cases xl_wait() to time out
and whine. We wait a little extra time now after the RX reset, which
should silence the warning.
Thanks to obrien for finally getting me a box with a NIC that
causes this problem for me to tinker with.
a bunch of frames. In this case, the dc_link flag is cleared, and dc_start()
stops draining the if_snd send queue, which results in lots of 'no buffers
available' errors being reported to applications. The whole idea behind
not draining the send queue until the link comes up was to avoid having
the gratuitous ARP being lost while we're waiting for autoneg to complete
after the interface is first brought up. As an optimization, change the
test in dc_start() so that we only bail if dc_link is not set _and_ there
are less than 10 packets in the send queue. If the queue has many frames
in it, we need to drain them. If the queue has a small number of frames
in it, we can hold off on sending them until the link comes up.
MFC after: 1 week
something: offset into the first mbuf of the target chain before copying
the source data over.
Make drivers using m_devget() with a first argument "data - ETHER_ALIGN"
to use the offset argument to pass ETHER_ALIGN in. The way it was previously
done is potentially dangerous if the source data was at the top of a page
and the offset caused the previous page to be copied (if the
previous page has not yet been appropriately mapped).
The old `offset' argument in m_devget() is not used anywhere (it's always
0) and dates back to ~1995 (and earlier?) when support for ethernet trailers
existed. With that support gone, it was merely collecting dust.
Tested on alpha by: jlemon
Partially submitted by: jlemon
Reviewed by: jlemon
MFC after: 3 weeks
412: warning: long unsigned int format, unsigned int arg (arg 3)
418: warning: long unsigned int format, unsigned int arg (arg 3)
424: warning: long unsigned int format, unsigned int arg (arg 3)
PCN_BCR_CLRBIT(sc, PCN_BCR_MIICTL, PCN_MIICTL_DANAS);
should be:
PCN_BCR_SETBIT(sc, PCN_BCR_MIICTL, PCN_MIICTL_DANAS);
Turning this bit on is what disables MII autoneg, not turning it off.
Without this, manually setting the media doesn't work.
Noticed by: Jim Browne <jbrowne@jbrowne.com>
setting the 'max packet size' register in window 3. This only
works for cards based on the cyclone or newer chipsets (i.e. it
won't work with the original 3c905/boomerang cards).
There is a trick which will work with the boomerang, which is to turn
on the 'large packets ok' bit in the MAC control register, however this
lets the chip accept any frame up to 4K in length, which is larger than
the mbuf cluster buffers we use to receive frames. If somebody sends us
such a frame and the chip DMAs it to us, it could write past the end
of the cluster buffer and clobber something.
PR: kern/27742
vm_mtx does not recurse and is required for most low level
vm operations.
faults can not be taken without holding Giant.
Memory subsystems can now call the base page allocators safely.
Almost all atomic ops were removed as they are covered under the
vm mutex.
Alpha and ia64 now need to catch up to i386's trap handlers.
FFS and NFS have been tested, other filesystems will need minor
changes (grabbing the vm lock when twiddling page properties).
Reviewed (partially) by: jake, jhb
of the pcic class of devices. Go ahead and move it to the "usual"
place. I say "usual" in quotes since it isn't exactly right (not in
dev/blah), but it is closer than before.
much more often that expected and negatively impact performance when
running at 100mbps. I need to figure out if there's a better way to
handle this, but for now this shouldn't hurt anything.
use TAILQ macros. The sk_attach_xmac() routine calls sk_init_xmac()
before doing the transceiver probe, but *before* ether_ifattach()
is called. This causes sk_init_xmac() to call sk_setmulti(), which
tries to do a TAILQ_FOREACH(), which it can't do because ether_ifattach()
hasn't done a TAILQ_INIT() yet. This causes a NULL pointer dereference
and panic in sk_setmulti() at driver load/initialization time.
Fixed by calling ether_ifattach() before the MII probe.
The code in RELENG_4 still uses the old way of enumerating the
multicast list and doesn't have this problem. Yet.
The constant I was using was correct, but I mislabeled it as 256K when
it should have been 512K. This doesn't actually change the code, but
it clarifies things somewhat.
Submitted by: Chuck Cranor <chuck@research.att.com>
parts. This is based on the newcard code that turns it off :-). We
can now reboot after NEWCARD or Windows and have OLDCARD work. Add
support for the RL5C466 while I'm at it.
Treat TI1031 the same as the CLPD6832. It doesn't work yet, but sucks
less than it did before.
Also add a few #defines for other changes in the pipe.
1. Pick up MII/PHY support for Livengood copper part (10/100/1000) from
Parag Patel. It was a fairly complete but not quite platform independent
job.
2. Finish silly offset differences that LIVENGOOD vs. WISEMAN registers
have (so the !)$*!)$*!$ fiber LIVENGOOD now works too).
3. Ansify the source.
So- we now suppor tthe PRO1000F and PRO1000T adapters.
1. The offsets for some registers change in LIVENGOOD. Gratuitously.
2. Define LIVENGOOD and LIVENGOOD_CU part numbers. Add some more
specific LIVENGOOD defaults.
3. Add definitions for PHY support for the copper LIVENGOOD part
(10/100/1000).
interface on this chip is compatable with the PIIX4. The catch is that
this interferes with isab0 which wants to attach to the same PCI node.
It seems to work, but we only tested it on systems with no ISA cards.
in vr_init(). The VIA Rhine chip happens to be able to automatically
read its station address from the EEPROM automatically when reset,
so you don't need to program the filter if you want to keep using the
factory default address, but if you want to change it with "ifconfig vr0
ether xx:xx:xx:xx:xx:xx" then we need to manually set it in the init
routine.
in VMware reports 0x00000000 in the PCI subsystem ID register, but
0x10001000 when you read the mirror registers in I/O space. This causes
pcn_probe() to think it's found a card in 32-bit mode, and performing
a 32-bit I/O access makes on a 16-bit port makes VMware go boom. Special
case the 0x10001000 value until somebody at VMware grows a clue.
Finally discovered by: Andrew Gallatin
- Use pci_get_powerstate()/pci_set_powerstate() in all the other drivers
that need them so we don't have to fiddle with the PCI power management
registers directly.
- Use pci_enable_busmaster()/pci_enable_io() to turn on busmastering and
PIO/memory mapped accesses.
- Add support to the RealTek driver for the D-Link DFE-530TX+ which has
a RealTek 8139 with its own PCI ID. (Submitted by Jason Wright)
- Have the SiS 900/National DP83815 driver be sure to disable PME
mode in sis_reset(). This apparently fixes a problem on some
motherboards where the DP83815 chip fails to receive packets.
(Submitted by Chuck McCrobie <mccrobie@cablespeed.com>)
