- 07 10月, 2011 10 次提交
-
-
由 Alexander Duyck 提交于
This change is meant to improve the readability of the driver by separating out the cmd_type configuration and the olinfo configuration into their own functions. By doing this it is much easier to determine which ingredients go into setting up these to portions of the descriptor. Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Alexander Duyck 提交于
This change converts two tx_buffer_info index values into pointers. The advantage to this is that we reduce unnecessary computations and in the case of next_to_watch we get an added bonus of the value being able to provide additional information as a NULL value indicates it is unset versus a 0 not having any meaning for the index value. Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Alexander Duyck 提交于
This patch is meant to simplify the transmit path by reducing the overhead for creating a transmit context descriptor. The current implementation is split with igb_tso and igb_tx_csum doing two separate implementations on how to setup the tx_buffer_info structure and the tx_desc. By combining them it is possible to reduce code and simplify things since now only one function will create context descriptors. Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Alexander Duyck 提交于
In order to be able to improve the performance of the TX path it has been necessary to add addition info to the tx_buffer_info structure. However a side effect is that the structure has gotten larger and this in turn has also increased the size of the RX buffer info structure. In order to avoid this in the future I am splitting the single buffer_info structure into two separate ones and instead I will join them by making the buffer_info pointer in the ring a union of the two. Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Alexander Duyck 提交于
This change is to make the NAPI budget limits for transmit adjustable. Currently they are only set to 128, and when the changes/improvements to NAPI occur to allow for adjustability, it would be possible to tune the value for optimal performance with applications such as routing. v2: remove tie between NAPI and interrupt moderation fix work limit define name (s/IXGBE/IGB/) Update patch description to better reflect patch Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com>
-
由 Bruce Allan 提交于
When short packets are received with jumbos enabled on 82579, they can be interpreted to have a receive address that does not match any configured address. This is due to a hardware bug that can be worked around by reducing the number of IPG octets added when the packet is transferred from the PHY to the MAC. Signed-off-by: NBruce Allan <bruce.w.allan@intel.com> Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Jesse Brandeburg 提交于
The e1000 driver when running with lockdep could run into some possible deadlocks between the work items acquiring rtnl and the rtnl lock being acquired before work items were cancelled. Use a private mutex to make sure lock ordering isn't violated. The private mutex is only used to protect areas not generally covered by the rtnl lock already. Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com> CC: Thomas Gleixner <tglx@linutronix.de> CC: Tushar Dave <tushar.n.dave@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Jesse Brandeburg 提交于
With the previous commit, there are several functions that are only ever called from thread context, and are able to sleep with msleep instead of mdelay. Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com> CC: Thomas Gleixner <tglx@linutronix.de> CC: Tushar Dave <tushar.n.dave@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Jesse Brandeburg 提交于
Thomas Gleixner (tglx) reported that e1000 was delaying for many milliseconds (using mdelay) from inside timer/interrupt context. None of these paths are performance critical and can be moved into threads/work items. This patch implements the work items and the next patch changes the mdelays to msleeps. Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com> CC: Thomas Gleixner <tglx@linutronix.de> CC: Tushar Dave <tushar.n.dave@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Don Skidmore 提交于
Bump the version string to better match pair up with the out of tree driver that contains the same functionality. Signed-off-by: NDon Skidmore <donald.c.skidmore@intel.com> Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 06 10月, 2011 9 次提交
-
-
由 Akeem G. Abodunrin 提交于
Only function 1 has support for Alternate MAC Address in the EEPROM before, this update now allow function 2 and 3 to have support for Alternate MAC Address in the EEPROM. Signed-off-by: N"Akeem G. Abodunrin" <akeem.g.abodunrin@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Akeem G. Abodunrin 提交于
This code check word 0x37 in the EEPROM, if it is 0xFFFF _or_ 0x0000, then there is no Alternate MAC Address in the EEPROM. Signed-off-by: N"Akeem G. Abodunrin" <akeem.g.abodunrin@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Akeem G. Abodunrin 提交于
This patch fixes "overwrite" problem. without this fix, SFP I2C EEPROM data, which is located at A0 can be overwritten by the phy write function. Signed-off-by: N"Akeem G. Abodunrin" <akeem.g.abodunrin@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 John Fastabend 提交于
Receiving PFC (priority flow control) frames while the feature is off should not pause the traffic class. On the X540 devices the traffic class react to frames if it was previously enabled because the field is incorrectly cleared. Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 John Fastabend 提交于
X540 devices can only support up to 4 traffic classes and guarantee a "lossless" traffic class on some platforms. This patch sets the X540 devices to initialize a max traffic class value of 4 at probe time. Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 John Fastabend 提交于
This patch correctly configures DCB when less than 8 traffic classes are available in hardware. Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Mark Rustad 提交于
Fix PFC mask generation to OR in only a single bit for each priority in the PFC mask returned via netlink. Signed-off-by: NMark Rustad <mark.d.rustad@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Bruce Allan 提交于
PCI device ID 0x1501 has a hardware bug when the link downshifts for whatever reason which requires a workaround. The workaround already exists for other similar devices but is not called for 0x1501 (it should be called for any ICH8-based device that uses a GbE PHY). There is also one other instance when the workaround should be called - after disabling gigabit speed when going to Sx. Signed-off-by: NBruce Allan <bruce.w.allan@intel.com> Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Bruce Allan 提交于
During suspend, the PHY must be reset for workaround updates to take effect without restarting auto-negotiation. Also, set the disable GbE and enable Low Power Link Up (LPLU) if the EEPROM is configured to do likewise in either D0 or non-D0a instead of just the latter. Signed-off-by: NBruce Allan <bruce.w.allan@intel.com> Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 05 10月, 2011 10 次提交
-
-
由 Emil Tantilov 提交于
82598 and 82599 do not ship with this type of PHY Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com> Tested-by: NStephen Ko <stephen.s.ko@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Mika Lansirinne 提交于
There is a problem in the ixgbe driver with the reporting of the flow control parameters. The autoneg parameter is shown to be of if *either* it really is off, or current modes for both tx and rx are off. The problem is seen when the parameters are read or set when the link is down. In this case, the driver sees that tx and rx are currently off and therefore autoneg parameter is incorrectly reported to be off too. Also, the ethtool binary can not set the autoneg off since it sees that it already is. When a link later comes up, the autonegotiation is carried out normally and the driver later on reports the autoneg parameter to be on (as it is) and then it can also be changed with ethtool. The patch is made against v3.0 kernel, but the problem seems to be there since v2.6.30-rc1. Reviewer comments: What we are trying to do is to disable flow control while the cable is disconnected. Since ixgbe defaults to full flow control, we call ethtool -A autoneg off rx off tx off while the cable is disconnected. This doesn't work, because the driver sets hw->fc.current_mode = ixgbe_fc_none if the cable is unplugged. ixgbe_get_pauseparam() then reports to ethtool that nothing needs to be done. The code fixes this, but it might have some unknown consequences. Signed-off-by: NMika Lansirinne <mika.lansirinne@stonesoft.com> Reviewed-by: NEsa-Pekka Pyokkimies <esa-pekka.pyokkimies@stonesoft.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Emil Tantilov 提交于
Disabling flow control in ixgbe_check_mac_link() results in incorrect reporting by ethtool when link goes down, so remove it. Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Emil Tantilov 提交于
MFLCN register is used to set Rx flow control on parts newer than 82598. This patch sends the value of MFLCN to ethtool, so it can be used in a register dump (ethtool -d). Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com> Tested-by: NStephen Ko <stephen.s.ko@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Emil Tantilov 提交于
This patch adds support for new device ID. Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com> Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Jacob Keller 提交于
This patch fixes an issue with storing the driver version for the firmware. If the os does not support the particular firmware management tools, the firmware requires a driver version to be written as 0xFFFFFFFF rather than the actual driver version. Signed-off-by: NJacob Keller <jacob.e.keller@intel.com> Tested-by: NStephen Ko <stephen.s.ko@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Emil Tantilov 提交于
Since ixgbe_raise_i2c_clk() can never return anything else than 0 this patch removes it's return value and all checks for it. Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com> Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Emil Tantilov 提交于
Clear the data field in ixgbe_read_i2c_byte_generic so it does not accumulate 1 bit using the same variable multiple times. Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com> Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Emil Tantilov 提交于
It some situations the driver sets __IXGBE_RESETTING and then __IXGBE_DOWN flags. It is possible a link check may sneak in between. This patch adds check for both flags. The idea is to reduce register reads while the PHY is resetting. Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com> Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Jeff Kirsher 提交于
The initial function and setup tables can be marked as constant. Reported-by: NStephen Hemminger <shemminger@vyatta.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com>
-
- 29 9月, 2011 8 次提交
-
-
由 Don Skidmore 提交于
Noticed that the legacy Interrupt handler didn't have the same ECC warning as did the MSI. So this patch adds it. Signed-off-by: Don Skidmore <donald.c.skidmore> Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Don Skidmore 提交于
The X540 thermal sensor interrupt isn't a General Purpose Interrupt so doesn't need to be enabled in ixgbe_setup_gpie(). Likewise X540 doesn't use the SDP0 for thermal sensor so it doesn't need to be enabled for any device other than 82599. Signed-off-by: NDon Skidmore <donald.c.skidmore@intel.com> Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Jacob Keller 提交于
Add code to enable thermal sensors for the x540 hardware, as well as a thermal interrupt check which will exit with a critical message of a thermal overheat is detected. Intent of code allows other mac types to be added with different configuration in the future. Fixed in this version is the addition of setting the temp_sensor capable flag which was previously only set for a specific mac. Signed-off-by: NJacob Keller <jacob.e.keller@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 John Fastabend 提交于
Revise high and low threshold marks wrt flow control to account for the X540 devices and latency introduced by the loopback switch. Without this it was in theory possible to drop frames on a supposedly lossless link with X540 or SR-IOV enabled. Previously we used a magic number in a define to calculate the threshold values. This made it difficult to sort out exactly which latencies were or were not being accounted for. Here I was overly explicit and tried to used #define names that would be recognizable after reading the IEEE 802.1Qbb specification. Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Vasu Dev 提交于
Disable LLI for FCoE since regular interrupt and their moderation rate works slightly better for FCoE also. Signed-off-by: NVasu Dev <vasu.dev@intel.com> Tested-by: NRoss Brattain <ross.b.brattain@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Emil Tantilov 提交于
This patch is meant to help cleanup the interrupt throttle rate logic by storing the interrupt throttle rate as a value in microseconds instead of interrupts per second. The advantage to this approach is that the value can now be stored in an 16 bit field and doesn't require as much math to flip the value back and forth since the hardware already used microseconds when setting the rate. Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com> Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Greg Rose 提交于
Changes to clean up the vlan rx path broke trunk vlan. Trunk vlans in a VF driver are those set using: "ip link set <pfdev> vf <n> <vlanid>" Signed-off-by: NGreg Rose <gregory.v.rose@intel.com> CC: Jiri Pirko <jpirko@redhat.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
由 Dean Nelson 提交于
Doing an 'ifconfig ethN down' followed by an 'ifconfig ethN up' on a qemu-kvm guest system configured with two e1000 NICs can result in an 'unable to handle kernel paging request at 0000000100000000' or 'bad page map in process ...' or something similar. These result from a 4096-byte page being corrupted with the following two-word pattern (16-bytes) repeated throughout the entire page: 0x0000000000000000 0x0000000100000000 There can be other bits set as well. What is a constant is that the 2nd word has the 32nd bit set. So one could see: : 0x0000000000000000 0x0000000100000000 0x0000000000000000 0x0000000172adc067 <<< bad pte 0x800000006ec60067 0x0000000700000040 0x0000000000000000 0x0000000100000000 : Which came from from a process' page table I dumped out when the marked line was seen as bad by print_bad_pte(). The repeating pattern represents the e1000's two-word receive descriptor: struct e1000_rx_desc { __le64 buffer_addr; /* Address of the descriptor's data buffer */ __le16 length; /* Length of data DMAed into data buffer */ __le16 csum; /* Packet checksum */ u8 status; /* Descriptor status */ u8 errors; /* Descriptor Errors */ __le16 special; }; And the 32nd bit of the 2nd word maps to the 'u8 status' member, and corresponds to E1000_RXD_STAT_DD which indicates the descriptor is done. The corruption appears to result from the following... . An 'ifconfig ethN down' gets us into e1000_close(), which through a number of subfunctions results in: 1. E1000_RCTL_EN being cleared in RCTL register. [e1000_down()] 2. dma_free_coherent() being called. [e1000_free_rx_resources()] . An 'ifconfig ethN up' gets us into e1000_open(), which through a number of subfunctions results in: 1. dma_alloc_coherent() being called. [e1000_setup_rx_resources()] 2. E1000_RCTL_EN being set in RCTL register. [e1000_setup_rctl()] 3. E1000_RCTL_EN being cleared in RCTL register. [e1000_configure_rx()] 4. RDLEN, RDBAH and RDBAL registers being set to reflect the dma page allocated in step 1. [e1000_configure_rx()] 5. E1000_RCTL_EN being set in RCTL register. [e1000_configure_rx()] During the 'ifconfig ethN up' there is a window opened, starting in step 2 where the receives are enabled up until they are disabled in step 3, in which the address of the receive descriptor dma page known by the NIC is still the previous one which was freed during the 'ifconfig ethN down'. If this memory has been reallocated for some other use and the NIC feels so inclined, it will write to that former dma page with predictably unpleasant results. I realize that in the guest, we're dealing with an e1000 NIC that is software emulated by qemu-kvm. The problem doesn't appear to occur on bare-metal. Andy suspects that this is because in the emulator link-up is essentially instant and traffic can start flowing immediately. Whereas on bare-metal, link-up usually seems to take at least a few milliseconds. And this might be enough to prevent traffic from flowing into the device inside the window where E1000_RCTL_EN is set. So perhaps a modification needs to be made to the qemu-kvm e1000 NIC emulator to delay the link-up. But in defense of the emulator, it seems like a bad idea to enable dma operations before the address of the memory to be involved has been made known. The following patch no longer enables receives in e1000_setup_rctl() but leaves them however they were. It only enables receives in e1000_configure_rx(), and only after the dma address has been made known to the hardware. There are two places where e1000_setup_rctl() gets called. The one in e1000_configure() is followed immediately by a call to e1000_configure_rx(), so there's really no change functionally (except for the removal of the problem window. The other is in __e1000_shutdown() and is not followed by a call to e1000_configure_rx(), so there is a change functionally. But consider... . An 'ifconfig ethN down' (just as described above). . A 'suspend' of the system, which (I'm assuming) will find its way into e1000_suspend() which calls __e1000_shutdown() resulting in: 1. E1000_RCTL_EN being set in RCTL register. [e1000_setup_rctl()] And again we've re-opened the problem window for some unknown amount of time. Signed-off-by: NAndy Gospodarek <andy@greyhouse.net> Signed-off-by: NDean Nelson <dnelson@redhat.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 24 9月, 2011 3 次提交
-
-
由 Michał Mirosław 提交于
Finish conversion to unified ethtool ops: convert get_flags. Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jesse Brandeburg 提交于
Really trivial fix, use kmalloc/kfree instead of stack space. use static const instead of const to further reduce stack usage. V2: reflect changes suggested by Joe Perches before: [jbrandeb@jbrandeb-mobl2 linux-2.6]$ make checkstack|grep '\[ixgb\]' 0x00000fc1 ixgb_set_multi [ixgb]: 768 0x00001031 ixgb_set_multi [ixgb]: 768 0x000010f2 ixgb_set_multi [ixgb]: 768 0x061c ixgb_check_options [ixgb]: 448 0x09c3 ixgb_check_options [ixgb]: 448 0x0000649e ixgb_set_ringparam [ixgb]: 192 0x0000130d ixgb_xmit_frame [ixgb]: 184 0x000019e0 ixgb_xmit_frame [ixgb]: 184 0x00002267 ixgb_clean [ixgb]: 152 0x00002673 ixgb_clean [ixgb]: 152 after: 0x000064ee ixgb_set_ringparam [ixgb]: 192 0x0000135d ixgb_xmit_frame [ixgb]: 184 0x00001a30 ixgb_xmit_frame [ixgb]: 184 0x000022b7 ixgb_clean [ixgb]: 152 0x000026c3 ixgb_clean [ixgb]: 152 Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Emil Tantilov 提交于
Reloading FW during resets can cause issues. Remove the full reset as it is not needed. Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com> Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-