#
267654 |
|
19-Jun-2014 |
gjb |
Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
248292 |
|
14-Mar-2013 |
jfv |
MFC of the E1000 drivers including revisions: ------------------------------------------------------------------------ r238765 | luigi | 2012-07-25 04:28:15 -0700 (Wed, 25 Jul 2012) | 7 lines Use legacy interrupts as a default. This gives up to 10% speedup when used in qemu (and this driver is for non-PCIe cards, so probably its largest use is in virtualized environments). ------------------------------------------------------------------------ r238770 | luigi | 2012-07-25 05:51:33 -0700 (Wed, 25 Jul 2012) | 4 lines remove some extra testing code that slipped into the previous commit ------------------------------------------------------------------------ r238953 | jfv | 2012-07-31 11:44:10 -0700 (Tue, 31 Jul 2012) | 6 lines Clean up some unused leftover code from em Make IRQ style a tuneable Fix lock handling in the interrupt handler ------------------------------------------------------------------------ r238981 | sbruno | 2012-08-01 17:00:34 -0700 (Wed, 01 Aug 2012) | 9 lines CPU_NEXT() already handles wrapping around to the beginning. Also, in a system with sparse CPU IDs, you can have a valid CPU ID > mp_ncpus (e.g. if you have two CPUs 0 and 4, with mp_maxid == 4 and mp_ncpus == 2). ------------------------------------------------------------------------ r239105 | jfv | 2012-08-06 13:44:05 -0700 (Mon, 06 Aug 2012) | 5 lines Correct the mq_start routine to avoid out-of-order packet delivery, always enqueue when possible. Also correct the DEPLETED test as multiple bits might be set. Thanks to Randall Stewart for the changes! ------------------------------------------------------------------------ r239109 | jfv | 2012-08-06 15:43:49 -0700 (Mon, 06 Aug 2012) | 6 lines Make the polling interface in igb able to handle multiqueue, and correct the rxdone handling. Update the polling man page to include igb as well. ------------------------------------------------------------------------ r239304 | jfv | 2012-08-15 10:12:40 -0700 (Wed, 15 Aug 2012) | 10 lines Customer report of a panic on boot due to the old "m_getjcl:invalid cluster type" that occurred some time back with the igb driver. This happens often when booting over the net. I believe the NIC hardware is left in a warm state when handed over to the driver, and a stray RX interrupt happens earlier than the code is prepared for it to happen. This change was verified to fix the problem, its kind of a bandaid... but it is similar to what was done in the igb code. ------------------------------------------------------------------------ r240693 | gavin | 2012-09-19 05:27:23 -0700 (Wed, 19 Sep 2012) | 5 lines Switch some PCI register reads from using magic numbers to using the names defined in pcireg.h ------------------------------------------------------------------------ r241856 | eadler | 2012-10-21 20:41:14 -0700 (Sun, 21 Oct 2012) | 7 lines Now that device disabling is generic, remove extraneous code from the device drivers that used to provide this feature. ------------------------------------------------------------------------ r241885 | eadler | 2012-10-22 06:06:09 -0700 (Mon, 22 Oct 2012) | 7 lines This isn't functionally identical. In some cases a hint to disable unit 0 would in fact disable all units. This reverts r241856 ------------------------------------------------------------------------ r243570 | glebius | 2012-11-26 12:03:57 -0800 (Mon, 26 Nov 2012) | 14 lines drbr_enqueue() awlays consumes mbuf, no matter did it fail or not. The mbuf pointer is no longer valid, so can't be reused after. Fix igb_mq_start() where mbuf pointer was used after drbr_enqueue(). This eventually leads us to all invocations of igb_mq_start_locked() called with third argument as NULL. This allows us to simplify this function. ------------------------------------------------------------------------ r245334 | smh | 2013-01-12 08:05:55 -0800 (Sat, 12 Jan 2013) | 9 lines Fixed mbuf free when receive structures fail to allocate. This prevents quad igb card on high core machines, without any nmbcluster or igb queue tuning wedging the boot process if all nics are configured. ------------------------------------------------------------------------ r246128 | sbz | 2013-01-30 10:01:20 -0800 (Wed, 30 Jan 2013) | 5 lines Use DEVMETHOD_END macro defined in sys/bus.h instead of {0, 0} sentinel on device_method_t arrays ------------------------------------------------------------------------ r246482 | rrs | 2013-02-07 07:20:54 -0800 (Thu, 07 Feb 2013) | 30 lines This fixes a out-of-order problem with several of the newer drivers. The basic problem was that the driver was pulling the mbuf off the drbr ring and then when sending with xmit(), encounting a full transmit ring. Thus the lower layer xmit() function would return an error, and the drivers would then append the data back on to the ring. For TCP this is a horrible scenario sure to bring on a fast-retransmit.
The fix is to use drbr_peek() to pull the data pointer but not remove it from the ring. If it fails then we either call the new drbr_putback or drbr_advance method. Advance moves it forward (we do this sometimes when the xmit() function frees the mbuf). When we succeed we always call advance. The putback will always copy the mbuf back to the top of the ring. Note that the putback *cannot* be used with a drbr_dequeue() only with drbr_peek(). We most of the time, in putback, would not need to copy it back since most likey the mbuf is still the same, but sometimes xmit() functions will change the mbuf via a pullup or other call. So the optimial case for the single consumer is to always copy it back. If we ever do a multiple_consumer (for lagg?) we will need a test and atomic in the put back possibly a seperate putback_mc() in the ring buf. ------------------------------------------------------------------------ r247064 | jfv | 2013-02-20 16:25:45 -0800 (Wed, 20 Feb 2013) | 19 lines Refresh on the shared code for the E1000 drivers. - bear with me, there are lots of white space changes, I would not do them, but I am a mere consumer of this stuff and if these drivers are to stay in shape they need to be taken.
em driver changes: support for the new i217/i218 interfaces
igb driver changes: - TX mq start has a quick turnaround to the stack - Link/media handling improvement - When link status changes happen the current flow control state will now be displayed. - A few white space/style changes.
lem driver changes: - the shared code uncovered a bogus write to the RLPML register (which does not exist in this hardware) in the vlan code,this is removed. ------------------------------------------------------------------------
|
#
235527 |
|
16-May-2012 |
jfv |
MFC of the e1000 drivers: revisions include 227309,228281,228386,228387,228393,228405, 228415,228788,228803,229606,229767,229939, 230023,230024,230742,231796,232238,233708, 234154,234665,235256
|
#
225736 |
|
22-Sep-2011 |
kensmith |
Copy head to stable/9 as part of 9.0-RELEASE release cycle.
Approved by: re (implicit)
|
#
218588 |
|
11-Feb-2011 |
jfv |
Fix the shared code to be consistent with Intel-internal, and now build.
|
#
213234 |
|
27-Sep-2010 |
jfv |
Update code from Intel: - Sync shared code with Intel internal - New client chipset support added - em driver - fixes to 82574, limit queues to 1 but use MSIX - em driver - large changes in TX checksum offload and tso code, thanks to yongari. - some small changes for watchdog issues. - igb driver - local timer watchdog code was missing locking this and a couple other watchdog related fixes. - bug in rx discard found by Andrew Boyer, check for null pointer
MFC: a week
|
#
205869 |
|
29-Mar-2010 |
jfv |
Update to igb and em:
em revision 7.0.0: - Using driver devclass, seperate legacy (pre-pcie) code into a seperate source file. This will at least help protect against regression issues. It compiles along with em, and is transparent to end use, devices in each appear to be 'emX'. When using em in a modular form this also allows the legacy stuff to be defined out. - Add tx and rx rings as in igb, in the 82574 this becomes actual multiqueue for the first time (2 queues) while in other PCIE adapters its just make code cleaner. - Add RX mbuf handling logic that matches igb, this will eliminate packet drops due to temporary mbuf shortage.
igb revision 1.9.3: - Following the ixgbe code, use a new approach in what was called 'get_buf', the routine now has been made independent of rxeof, it now does the update to the engine TDT register, this design allows temporary mbuf resources to become non-critical, not requiring a packet to be discarded, instead it just returns and does not increment the tail pointer. - With the above change it was also unnecessary to keep 'spare' maps around, since we do not have the discard issue. - Performance tweaks and improvements to the code also.
MFC in a week
|
#
203049 |
|
26-Jan-2010 |
jfv |
Update the 1G drivers, shared code sync with Intel, igb now has a queue notion that has a single interrupt with an RX/TX pair, this will reduce the total interrupts seen on a system. Both em and igb have a new watchdog method. igb has fixes from Pyun Yong-Hyeon that have improved stability, thank you :)
I wish to MFC this for 7.3 asap, please test if able.
|
#
200243 |
|
07-Dec-2009 |
jfv |
Resync with Intel versions of both the em and igb drivers. These add new hardware support, most importantly the pch (i5 chipset) in the em driver. Also, both drivers now have the simplified (and I hope improved) watchdog code. The igb driver uses the new RX cleanup that I first implemented in ixgbe.
em - version 6.9.24 igb - version 1.8.4
|
#
194865 |
|
24-Jun-2009 |
jfv |
Updates for both the em and igb drivers, add support for multiqueue tx, shared code updates, new device support, and some bug fixes.
|
#
190872 |
|
09-Apr-2009 |
jfv |
This delta syncs the em and igb drivers with Intel, adds header split and SCTP support into the igb driver. Various small improvements and fixes.
MFC after: 2 weeks
|
#
185353 |
|
26-Nov-2008 |
jfv |
This delta is primarily a fix for es2lan devices that will sometimes fail to initialize problem due to a lock contention with management hardware. However, in order to deliver that fix it was necessary to take a shared code update as a whole, and this required scattered changes in the core code to be compatible.
The em driver now has VLAN HW support added as the igb driver had previously.
MFC after: ASAP - in time for 7.1 RELEASE
|
#
181027 |
|
30-Jul-2008 |
jfv |
Merge of the source for igb and em into dev/e1000, this proved to be necessary to make the static drivers work in EITHER/OR or BOTH configurations. Modules will still build in sys/modules/igb or em as before.
This also updates the igb driver for support for the 82576 adapter, adds shared code fixes, and etc....
MFC after: ASAP
|
#
178523 |
|
25-Apr-2008 |
jfv |
This delta has a few important items:
PR 122839 is fixed in both em and in igb
Second, the issue on building modules since the static kernel build changes is now resolved. I was not able to get the fancier directory hierarchy working, but this works, both em and igb build as modules now.
Third, there is now support in em for two new NICs, Hartwell (or 82574) is a low cost PCIE dual port adapter that has MSIX, for this release it uses 3 vectors only, RX, TX, and LINK. In the next release I will add a second TX and RX queue. Also, there is support here for ICH10, the followon to ICH9. Both of these are early releases, general availability will follow soon.
Fourth: On Hartwell and ICH10 we now have IEEE 1588 PTP support, I have implemented this in a provisional way so that early adopters may try and comment on the functionality. The IOCTL structure may change. This feature is off by default, you need to edit the Makefile and add the EM_TIMESYNC define to get the code.
Enjoy all!!
|
#
177867 |
|
02-Apr-2008 |
jfv |
This update primarily addresses the ability to have both the em and the igb driver static in the kernel. But it also reflects some other bug fixes in my development stream at Intel. PR 122373 is also fixed in this code.
|
#
176667 |
|
29-Feb-2008 |
jfv |
This change introduces a split to the Intel E1000 driver, now rather than just em, there is an igb driver (this follows behavior with our Linux drivers). All adapters up to the 82575 are supported in em, and new client/desktop support will continue to be in that adapter.
The igb driver is for new server NICs like the 82575 and its followons. Advanced features for virtualization and performance will be in this driver.
Also, both drivers now have shared code that is up to the latest we have released. Some stylistic changes as well.
Enjoy :)
|
#
173788 |
|
20-Nov-2007 |
jfv |
Driver version 6.7.3 - Bring HEAD up to the latest shared code - Fix TSO problem using limited MSS and forwarding - Dual lock implementation - New device support - For my ease, this code can compile in either 6.x or later - brings this driver in sync with the 6.3
|
#
169589 |
|
15-May-2007 |
jfv |
This delta adds two bug fixes: one that makes HW Offload logic in legacy codepath match the 82575, without this we were seeing bridging fail on 82546 adapters. Secondly, I have limited TSO to PCI Express adapters, I meant to do this and it got dropped in the earlier delta. Next, I am dropping in the latest shared code from our development team, consensus was that this should be done frequently, so I am :)
Approved by: pdeuskar
|
#
169248 |
|
04-May-2007 |
rwatson |
$FreeBSD$ tags are not compilable C code; wrap in either __FBSDID() or in comments for .c and .h files respectively. Jack may want to clean up style or other aspects once he's up and about again, but this gets the kernel compiling.
|
#
169240 |
|
03-May-2007 |
jfv |
Merge in the new driver (6.5.0) of Intel. This has a new shared code infrastructure that is family specific and modular. There is also support for our latest gigabit nic, the 82575 that is MSI/X and multiqueue capable.
The new shared code changes some interfaces to the core code but testing at Intel has been going on for months, it is fairly stable.
I have attempted to be careful in retaining any fixes that CURRENT had and we did not, I apologize in advance if any thing gets clobbered, I'm sure I'll hear about it :)
Approved by pdeuskar
|