* [net-next 2/9] e1000e: WoL fails on device ID 0x1501
From: Jeff Kirsher @ 2011-10-06 11:02 UTC (permalink / raw)
To: davem; +Cc: Bruce Allan, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1317898959-16550-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
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: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 4ec5a5a..ad34de0 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -811,7 +811,7 @@ static s32 e1000_get_variants_ich8lan(struct e1000_adapter *adapter)
}
if ((adapter->hw.mac.type == e1000_ich8lan) &&
- (adapter->hw.phy.type == e1000_phy_igp_3))
+ (adapter->hw.phy.type != e1000_phy_ife))
adapter->flags |= FLAG_LSC_GIG_SPEED_DROP;
/* Enable workaround for 82579 w/ ME enabled */
@@ -3642,15 +3642,14 @@ void e1000e_igp3_phy_powerdown_workaround_ich8lan(struct e1000_hw *hw)
* LPLU, Gig disable, MDIC PHY reset):
* 1) Set Kumeran Near-end loopback
* 2) Clear Kumeran Near-end loopback
- * Should only be called for ICH8[m] devices with IGP_3 Phy.
+ * Should only be called for ICH8[m] devices with any 1G Phy.
**/
void e1000e_gig_downshift_workaround_ich8lan(struct e1000_hw *hw)
{
s32 ret_val;
u16 reg_data;
- if ((hw->mac.type != e1000_ich8lan) ||
- (hw->phy.type != e1000_phy_igp_3))
+ if ((hw->mac.type != e1000_ich8lan) || (hw->phy.type == e1000_phy_ife))
return;
ret_val = e1000e_read_kmrn_reg(hw, E1000_KMRNCTRLSTA_DIAG_OFFSET,
@@ -3686,6 +3685,9 @@ void e1000_suspend_workarounds_ich8lan(struct e1000_hw *hw)
phy_ctrl |= E1000_PHY_CTRL_D0A_LPLU | E1000_PHY_CTRL_GBE_DISABLE;
ew32(PHY_CTRL, phy_ctrl);
+ if (hw->mac.type == e1000_ich8lan)
+ e1000e_gig_downshift_workaround_ich8lan(hw);
+
if (hw->mac.type >= e1000_pchlan) {
e1000_oem_bits_config_ich8lan(hw, false);
e1000_phy_hw_reset_ich8lan(hw);
--
1.7.6.4
^ permalink raw reply related
* [net-next 3/9] ixgbe: Fix PFC mask generation
From: Jeff Kirsher @ 2011-10-06 11:02 UTC (permalink / raw)
To: davem; +Cc: Mark Rustad, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1317898959-16550-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Mark Rustad <mark.d.rustad@intel.com>
Fix PFC mask generation to OR in only a single bit for each priority in
the PFC mask returned via netlink.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.c
index 83bf7cc..3d44b15 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.c
@@ -184,7 +184,7 @@ void ixgbe_dcb_unpack_pfc(struct ixgbe_dcb_config *cfg, u8 *pfc_en)
*pfc_en = 0;
for (i = 0; i < MAX_TRAFFIC_CLASS; i++)
- *pfc_en |= (cfg->tc_config[i].dcb_pfc & 0xF) << i;
+ *pfc_en |= !!(cfg->tc_config[i].dcb_pfc & 0xF) << i;
}
void ixgbe_dcb_unpack_refill(struct ixgbe_dcb_config *cfg, int direction,
--
1.7.6.4
^ permalink raw reply related
* [net-next 1/9] e1000e: WoL can fail on 82578DM
From: Jeff Kirsher @ 2011-10-06 11:02 UTC (permalink / raw)
To: davem; +Cc: Bruce Allan, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1317898959-16550-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
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: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 3b063e1..4ec5a5a 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1319,16 +1319,20 @@ static s32 e1000_oem_bits_config_ich8lan(struct e1000_hw *hw, bool d0_state)
if (mac_reg & E1000_PHY_CTRL_D0A_LPLU)
oem_reg |= HV_OEM_BITS_LPLU;
+
+ /* Set Restart auto-neg to activate the bits */
+ if (!e1000_check_reset_block(hw))
+ oem_reg |= HV_OEM_BITS_RESTART_AN;
} else {
- if (mac_reg & E1000_PHY_CTRL_NOND0A_GBE_DISABLE)
+ if (mac_reg & (E1000_PHY_CTRL_GBE_DISABLE |
+ E1000_PHY_CTRL_NOND0A_GBE_DISABLE))
oem_reg |= HV_OEM_BITS_GBE_DIS;
- if (mac_reg & E1000_PHY_CTRL_NOND0A_LPLU)
+ if (mac_reg & (E1000_PHY_CTRL_D0A_LPLU |
+ E1000_PHY_CTRL_NOND0A_LPLU))
oem_reg |= HV_OEM_BITS_LPLU;
}
- /* Restart auto-neg to activate the bits */
- if (!e1000_check_reset_block(hw))
- oem_reg |= HV_OEM_BITS_RESTART_AN;
+
ret_val = hw->phy.ops.write_reg_locked(hw, HV_OEM_BITS, oem_reg);
out:
@@ -3684,6 +3688,7 @@ void e1000_suspend_workarounds_ich8lan(struct e1000_hw *hw)
if (hw->mac.type >= e1000_pchlan) {
e1000_oem_bits_config_ich8lan(hw, false);
+ e1000_phy_hw_reset_ich8lan(hw);
ret_val = hw->phy.ops.acquire(hw);
if (ret_val)
return;
--
1.7.6.4
^ permalink raw reply related
* [net-next 0/9][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-10-06 11:02 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
The following series contains updates to e1000e, igb and ixgbe. Here
is a quick summary:
- e1000e: fixes for 2 WoL issues
- igb: fix for I2C, and 2 Alt. MAC address updates
- ixgbe: fix dependencies for 8 traffic classes, add X540 traffic
class support and a fix for PFC mask generation
The following are changes since commit f0cd7bdc042310b6b104f133bbfd520a72b3c08a:
bnx2x: remove some dead code
and are available in the git repository at
git://github.com/Jkirsher/net-next.git
Akeem G. Abodunrin (3):
igb: Code to prevent overwriting SFP I2C
igb: Alternate MAC Address EEPROM Updates
igb: Alternate MAC Address Updates for Func2&3
Bruce Allan (2):
e1000e: WoL can fail on 82578DM
e1000e: WoL fails on device ID 0x1501
John Fastabend (3):
ixgbe: fixup hard dependencies on supporting 8 traffic classes
ixgbe: DCB X540 devices support max traffic class of 4
ixgbe: X540 devices RX PFC frames pause traffic even if disabled
Mark Rustad (1):
ixgbe: Fix PFC mask generation
drivers/net/ethernet/intel/e1000e/ich8lan.c | 25 +++++---
drivers/net/ethernet/intel/igb/e1000_mac.c | 9 ++-
drivers/net/ethernet/intel/igb/e1000_phy.c | 6 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.c | 22 ++++++--
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.h | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c | 46 ++++++++++++---
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.h | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_nl.c | 60 +++++++++++++++-----
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 29 ++++++++--
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 3 +-
10 files changed, 158 insertions(+), 47 deletions(-)
--
1.7.6.4
^ permalink raw reply
* Re: [PATCH] IPv6: DAD from bonding iface is treated as dup address from others
From: Neil Horman @ 2011-10-06 11:00 UTC (permalink / raw)
To: Yinglin Sun
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <1317873550-1677-1-git-send-email-Yinglin.Sun@emc.com>
On Wed, Oct 05, 2011 at 08:59:10PM -0700, Yinglin Sun wrote:
> Steps to reproduce this issue:
> 1. create bond0 over eth0 and eth1, set the mode to balance-xor
> 2. add an IPv6 address to bond0
> 3. DAD packet is sent out from one slave and then is looped back from
> the other slave. Therefore, it is treated as a duplicate address and
> stays tentative afterwards:
> kern.info:
> Oct 5 11:50:18 testvm1 kernel: [ 129.224353] bond0: IPv6 duplicate address 1234::1 detected!
>
> Signed-off-by: Yinglin Sun <Yinglin.Sun@emc.com>
> ---
> net/ipv6/ndisc.c | 15 +++++++++++++--
> 1 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> index 9da6e02..c82f4c7 100644
> --- a/net/ipv6/ndisc.c
> +++ b/net/ipv6/ndisc.c
> @@ -809,9 +809,10 @@ static void ndisc_recv_ns(struct sk_buff *skb)
>
> if (ifp->flags & (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)) {
> if (dad) {
> + const unsigned char *sadr;
> + sadr = skb_mac_header(skb);
> +
> if (dev->type == ARPHRD_IEEE802_TR) {
> - const unsigned char *sadr;
> - sadr = skb_mac_header(skb);
> if (((sadr[8] ^ dev->dev_addr[0]) & 0x7f) == 0 &&
> sadr[9] == dev->dev_addr[1] &&
> sadr[10] == dev->dev_addr[2] &&
> @@ -821,6 +822,16 @@ static void ndisc_recv_ns(struct sk_buff *skb)
> /* looped-back to us */
> goto out;
> }
> + } else if (dev->type == ARPHRD_ETHER) {
> + if (sadr[6] == dev->dev_addr[0] &&
> + sadr[7] == dev->dev_addr[1] &&
> + sadr[8] == dev->dev_addr[2] &&
> + sadr[9] == dev->dev_addr[3] &&
> + sadr[10] == dev->dev_addr[4] &&
> + sadr[11] == dev->dev_addr[5]) {
> + /* looped-back to us */
> + goto out;
> + }
> }
>
> /*
> --
> 1.7.4.1
>
Nack, This seems like it will just completely break DAD. What if theres another
system out there with the same mac address. A response from that system would
get dropped by this filter, instead of causing The local system to stop using
the address. What you really want to do is modify
bond_should_deliver_exact_match to detect this frame on the inactive slave or
some such, and drop the frame there.
Neil
^ permalink raw reply
* bnx2 rxhash
From: Jasper Spaans @ 2011-10-06 9:57 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: mchan
[-- Attachment #1: Type: text/plain, Size: 4318 bytes --]
Hi list,
I'm doing some experiments with rxhash and packet capturing, and I'm
seeing some unexpected results when receiving data (which happens in
promiscuous mode). This behaviour seems to be similar to that seen in
the question asked previously by Christophe Ngo Van Duc:
http://kerneltrap.com/mailarchive/linux-netdev/2010/7/2/6280474
The data I'm processing consists of (almost 100% tcp) traffic between an
ssl-offloader and a cluster of webservers, so the range of mac-addresses
is rather limited. This ssl-offloader does preserve the IP-address and
tcp ports of the clients, so if the rxhash is based on that data, it
should be distributed evenly.
Is there anything I can do about this?
Thanks,
Jasper
The raw data:
spaans@dhcp-074:~$ uname -a
Linux dhcp-074 3.0.4 #7 SMP Tue Sep 13 12:52:01 CEST 2011 x86_64 GNU/Linux
spaans@dhcp-074:~$ grep eth6 /proc/interrupts | cut -b -30,270-
142: 57070 0 PCI-MSI-edge eth6-0
143: 0 0 PCI-MSI-edge eth6-1
144: 0 0 PCI-MSI-edge eth6-2
145: 0 0 PCI-MSI-edge eth6-3
146: 0 0 PCI-MSI-edge eth6-4
147: 17127 0 PCI-MSI-edge eth6-5
148: 24 0 PCI-MSI-edge eth6-6
149: 0 0 PCI-MSI-edge eth6-7
This is rather different from the behaviour I get with an intel card:
spaans@dhcp-074:~$ grep eth2 /proc/interrupts | cut -b -30,270-
98: 3 0 PCI-MSI-edge eth2
99: 4492 0 PCI-MSI-edge eth2-TxRx-0
100: 4647 0 PCI-MSI-edge eth2-TxRx-1
101: 4369 0 PCI-MSI-edge eth2-TxRx-2
102: 4579 0 PCI-MSI-edge eth2-TxRx-3
103: 4184 0 PCI-MSI-edge eth2-TxRx-4
104: 51268 0 PCI-MSI-edge eth2-TxRx-5
105: 4610 0 PCI-MSI-edge eth2-TxRx-6
106: 4528 0 PCI-MSI-edge eth2-TxRx-7
In both cases, only Tx-5 was used for sending data.
Information about the nics:
from dmesg:
[ 5.857778] igb 0000:08:00.0: Intel(R) Gigabit Ethernet Network
Connection
[ 5.857780] igb 0000:08:00.0: eth6: (PCIe:2.5Gb/s:Width x4)
00:1b:21:b9:b8:dc
[ 5.858101] igb 0000:08:00.0: eth6: PBA No: G18771-002
[ 5.858102] igb 0000:08:00.0: Using MSI-X interrupts. 8 rx queue(s),
8 tx queue(s)
note that this interface is renamed to eth2 after boot
spaans@dhcp-074:~$ ip link sh eth2
8: eth2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq
state UP qlen 1000
link/ether 00:1b:21:b9:b8:dc brd ff:ff:ff:ff:ff:ff
spaans@dhcp-074:~$ sudo ethtool -k eth2
Offload parameters for eth2:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off
spaans@dhcp-074:~$ sudo ethtool -i eth2
driver: igb
version: 3.0.6-k2
firmware-version: 1.5-1
bus-info: 0000:08:00.0
vs
from dmesg:
[ 5.090860] bnx2 0000:02:00.0: eth2: Broadcom NetXtreme II BCM5709
1000Base-T (C0) PCI Express found at mem d8000000, IRQ 32, node addr
18:03:73:fa:0f:0e
note that this interface is renamed to eth6 after boot
spaans@dhcp-074:~$ ip link sh eth6
4: eth6: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq
state UP qlen 1000
link/ether 18:03:73:fa:0f:0e brd ff:ff:ff:ff:ff:ff
spaans@dhcp-074:~$ sudo ethtool -k eth6
Offload parameters for eth6:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: on
spaans@dhcp-074:~$ sudo ethtool -i eth6
driver: bnx2
version: 2.1.6
firmware-version: 6.2.12 bc 5.2.3 NCSI 2.0.11
bus-info: 0000:02:00.0
--
/\____/\ Ir. Jasper Spaans
\ (_)/ Fox-IT Experts in IT Security!
\ X T: +31-15-2847999
\ / \ M: +31-6-41588725
\/ KvK Haaglanden 27301624
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2679 bytes --]
^ permalink raw reply
* Asserting ECN from userspace?
From: David Täht @ 2011-10-05 6:18 UTC (permalink / raw)
To: netdev, bloat-devel
No sooner had I noted (with pleasure) the kernel's new ability to
correctly set the dscp bits on IPv6 TCP streams without messing with the
negotiated ECN status, that I found several use cases where being able
to assert ECN from userspace (for either ipv4, or ipv6) would be useful.
1) Applications such as bittorrent (transmission, etc) that are much
more aware of their overall environment could assert ECN on their UDP
streams to indicate congestion.
2) Test tools. It would be nice to be able, from userspace, to easily
diagnose if ECN was working on a stream, end to end, and being able to
set and receive the ECN bits on a less algorithmic basis (ie, not wedged
deep within a kernel aqm such as RED or SFB)
3) Web Proxies. A web proxy could note when it was experiencing
congestion on one side of the proxied connection (or another) and signal
the other side to slow down.
Ah, ECN, we hardly know ye.
as for item 1 I'm hard pressed to think of a case where setting the ECN
bits on udp streams would introduce a security problem.
As for 2, can live without.
As for 3... perhaps a grantable network capability? A proxy could
acquire privs to twiddle those bits before dropping root privs.
That begs the question of how to see those bits in the first place. OOB
data?
And twiddling them, on a per stream basis, for a single packet, would
seem to require something more robust than setsockopt/getsockopt
(although that would work for udp streams)
^ permalink raw reply
* Re: [PATCH net] mscan: zero accidentally copied register content
From: Wolfram Sang @ 2011-10-06 9:24 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Oliver Hartkopp, Linux Netdev List, Andre Naujoks
In-Reply-To: <4E8D7065.8040905@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 896 bytes --]
> Why do you want to change 16-bit accesses in general? They are faster
> than two 8 bit accesses.
Yup, was thinking the same.
>
> > IMHO this fix is small and clear and especially not risky. I wonder if
> > reworking the 16 bit register access is worth the effort?
>
> I would prefer:
>
> if (!(frame->can_id & CAN_RTR_FLAG)) {
> void __iomem *data = ®s->rx.dsr1_0;
> u16 *payload = (u16 *)frame->data;
>
> for (i = 0; i < frame->can_dlc / 2; i++) {
> *payload++ = in_be16(data);
> data += 2 + _MSCAN_RESERVED_DSR_SIZE;
> }
> /* copy remaining byte */
if any
> if (frame->can_dlc & 1)
> frame->data[frame->can_dlc - 1] = in_8(data);
Ack.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH net] mscan: zero accidentally copied register content
From: Wolfgang Grandegger @ 2011-10-06 9:09 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: Wolfram Sang, Linux Netdev List, Andre Naujoks
In-Reply-To: <4E8D528D.8020607@hartkopp.net>
Hi Oliver,
On 10/06/2011 09:02 AM, Oliver Hartkopp wrote:
> On 10/05/11 18:10, Oliver Hartkopp wrote:
>
>> On 10/05/11 17:51, Wolfram Sang wrote:
>
>>>> + /* zero accidentally copied register content at odd DLCs */
>>>> + if (frame->can_dlc & 1)
>>>> + frame->data[frame->can_dlc] = 0;
>>>> }
>>>>
>>>> out_8(®s->canrflg, MSCAN_RXF);
>>>
>>> Nice catch, but wouldn't it be more elegant to never have an invalid byte
>>> in the first place?
>>>
>>> if (can_dlc & 1)
>>> *payload = in_be16() & mask;
>>>
>>
>>
>> Hm, then i would rather think about changing the for() statement and to read
>> byte-by-byte instead of the current in_be16() usage with the 16bit access
>> drawbacks ...
>>
>
>
> I think if one would like to rework the 16bit register access (which is used
> in the rx path /and/ in the tx path also) this should go via net-next after
> some discussion and testing.
Why do you want to change 16-bit accesses in general? They are faster
than two 8 bit accesses.
> IMHO this fix is small and clear and especially not risky. I wonder if
> reworking the 16 bit register access is worth the effort?
I would prefer:
if (!(frame->can_id & CAN_RTR_FLAG)) {
void __iomem *data = ®s->rx.dsr1_0;
u16 *payload = (u16 *)frame->data;
for (i = 0; i < frame->can_dlc / 2; i++) {
*payload++ = in_be16(data);
data += 2 + _MSCAN_RESERVED_DSR_SIZE;
}
/* copy remaining byte */
if (frame->can_dlc & 1)
frame->data[frame->can_dlc - 1] = in_8(data);
}
Wolfgang.
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree with the net tree
From: Arend van Spriel @ 2011-10-06 8:59 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Eliad Peller, John W. Linville, David Miller,
netdev@vger.kernel.org
In-Reply-To: <20111006155810.14a6b5c199edc388bbf11437@canb.auug.org.au>
On 10/06/2011 06:58 AM, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/brcm80211/brcmsmac/mac80211_if.c between commit
> 37a41b4affa3 ("mac80211: add ieee80211_vif param to tsf functions") from
> the net tree and commit 3956b4a2ddb0 ("staging: brcm80211: remove locking
> macro definitions") from the staging tree.
>
> I fixed it up (which essentially means I used the staging tree version
> with one small change to the brcms_ops_conf_tx prototype) and can carry
> the fixes as necessary.
Thanks, Stephen
I had to make the mac80211 conf_tx callback change for the mainline
patch as well.
Acked.
Gr. AvS
^ permalink raw reply
* Re: [PATCH v4 7/8] Display current tcp memory allocation in kmem cgroup
From: Kirill A. Shutemov @ 2011-10-06 8:46 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, avagin
In-Reply-To: <4E8ACD6E.3090208@parallels.com>
On Tue, Oct 04, 2011 at 01:10:06PM +0400, Glauber Costa wrote:
> On 10/03/2011 04:36 PM, Kirill A. Shutemov wrote:
> > On Mon, Oct 03, 2011 at 04:26:41PM +0400, Glauber Costa wrote:
> >> On 10/03/2011 04:25 PM, Kirill A. Shutemov wrote:
> >>> On Mon, Oct 03, 2011 at 04:19:18PM +0400, Glauber Costa wrote:
> >>>> On 10/03/2011 04:14 PM, Kirill A. Shutemov wrote:
> >>>>> On Mon, Oct 03, 2011 at 02:18:42PM +0400, Glauber Costa wrote:
> >>>>>> This patch introduces kmem.tcp_current_memory file, living in the
> >>>>>> kmem_cgroup filesystem. It is a simple read-only file that displays the
> >>>>>> amount of kernel memory currently consumed by the cgroup.
> >>>>>>
> >>>>>> Signed-off-by: Glauber Costa<glommer@parallels.com>
> >>>>>> CC: David S. Miller<davem@davemloft.net>
> >>>>>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu@jp.fujitsu.com>
> >>>>>> CC: Eric W. Biederman<ebiederm@xmission.com>
> >>>>>> ---
> >>>>>> Documentation/cgroups/memory.txt | 1 +
> >>>>>> mm/memcontrol.c | 11 +++++++++++
> >>>>>> 2 files changed, 12 insertions(+), 0 deletions(-)
> >>>>>>
> >>>>>> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
> >>>>>> index 1ffde3e..f5a539d 100644
> >>>>>> --- a/Documentation/cgroups/memory.txt
> >>>>>> +++ b/Documentation/cgroups/memory.txt
> >>>>>> @@ -79,6 +79,7 @@ Brief summary of control files.
> >>>>>> memory.independent_kmem_limit # select whether or not kernel memory limits are
> >>>>>> independent of user limits
> >>>>>> memory.kmem.tcp.max_memory # set/show hard limit for tcp buf memory
> >>>>>> + memory.kmem.tcp.current_memory # show current tcp buf memory allocation
> >>>>>
> >>>>> Both are in pages, right?
> >>>>> Shouldn't it be scaled to bytes and named uniform with other memcg file?
> >>>>> memory.kmem.tcp.limit_in_bytes/usage_in_bytes.
> >>>>>
> >>>> You are absolutely correct.
> >>>> Since the internal tcp comparison works, I just ended up never noticing
> >>>> this.
> >>>
> >>> Should we have failcnt and max_usage_in_bytes for tcp as well?
> >>>
> >>
> >> Well, we get a fail count from the tracer anyway, so I don't really see
> >> a need for that. I see value in having it for the slab allocation
> >> itself, but since this only controls the memory pressure framework, I
> >> think we can live without it.
> >>
> >> That said, this is not a strong opinion. I can add it if you'd prefer.
> >
> > It's good for userspace to have the same set of files for all domains:
> > - memory;
> > - memory.memsw;
> > - memory.kmem;
> > - memory.kmem.tcp;
> > - etc.
> > Userspace can reuse code for handling them in this case.
> >
> Ok. Back on this.
>
> Not all domains have all files anyway.
$ ls -l *.{failcnt,limit_in_bytes,max_usage_in_bytes,usage_in_bytes}
-rw-r--r-- 1 root root 0 Oct 6 11:34 memory.failcnt
-rw-r--r-- 1 root root 0 Oct 6 11:34 memory.limit_in_bytes
-rw-r--r-- 1 root root 0 Oct 6 11:34 memory.max_usage_in_bytes
-rw-r--r-- 1 root root 0 Oct 6 11:34 memory.memsw.failcnt
-rw-r--r-- 1 root root 0 Oct 6 11:34 memory.memsw.limit_in_bytes
-rw-r--r-- 1 root root 0 Oct 6 11:34 memory.memsw.max_usage_in_bytes
-r--r--r-- 1 root root 0 Oct 6 11:34 memory.memsw.usage_in_bytes
-r--r--r-- 1 root root 0 Oct 6 11:34 memory.usage_in_bytes
Hm?..
> max_usage seems to be a property of the main memcg, not of its domains.
> failcnt is present on memsw, and on that only. The problem here, is that
> this can fail ( and usually will ) in codepaths outside the memory
> controller. (see net/core/sock.c:__sk_mem_schedule)
+1 reason to use res_counter. It provides all data needed for this files.
> Also, max_usage makes sense for kernel memory as a whole, but I don't
> think it makes sense here as we're only controlling a specific pressure
> condition.
max_usage is reasonable for everything you can limit. It allows you to
track if limit is set appropriate.
--
Kirill A. Shutemov
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v5 6/8] tcp buffer limitation: per-cgroup limit
From: Glauber Costa @ 2011-10-06 8:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill, avagin, devel
In-Reply-To: <1317805090.2473.28.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 10/05/2011 12:58 PM, Eric Dumazet wrote:
> Le mercredi 05 octobre 2011 à 12:08 +0400, Glauber Costa a écrit :
>> On 10/04/2011 04:48 PM, Eric Dumazet wrote:
>
>>> 2) Could you add const qualifiers when possible to your pointers ?
>>
>> Well, I'll go over the patches again and see where I can add them.
>> Any specific place site you're concerned about?
>
> Everywhere its possible :
>
> It helps reader to instantly knows if a function is about to change some
> part of the object or only read it, without reading function body.
Sure it does.
So, give me your opinion on this:
most of the acessors inside struct sock do not modify the pointers,
but return an address of an element inside it (that can later on be
modified by the caller.
I think it is fine for the purpose of clarity, but to avoid warnings we
end up having to do stuff like this:
+#define CONSTCG(m) ((struct mem_cgroup *)(m))
+long *tcp_sysctl_mem(const struct mem_cgroup *memcg)
+{
+ return CONSTCG(memcg)->tcp.tcp_prot_mem;
+}
Is it acceptable?
^ permalink raw reply
* Re: [PATCH 1/8] vxge: convert to SKB paged frag API.
From: Ian Campbell @ 2011-10-06 7:05 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev@vger.kernel.org, Jon Mason
In-Reply-To: <CAHXqBFKX5eojLMhT1MW1inAUH9cfVne4-rhDQYSLsUh-OTzuPQ@mail.gmail.com>
On Wed, 2011-10-05 at 22:03 +0100, Michał Mirosław wrote:
> 2011/10/5 Ian Campbell <ian.campbell@citrix.com>:
> [...]
> > --- a/drivers/net/ethernet/neterion/vxge/vxge-main.c
> > +++ b/drivers/net/ethernet/neterion/vxge/vxge-main.c
> > @@ -923,9 +923,9 @@ vxge_xmit(struct sk_buff *skb, struct net_device *dev)
> > if (!frag->size)
> > continue;
> >
> > - dma_pointer = (u64) pci_map_page(fifo->pdev, frag->page,
> > - frag->page_offset, frag->size,
> > - PCI_DMA_TODEVICE);
> > + dma_pointer = (u64)skb_frag_dma_map(&fifo->pdev->dev, frag,
> > + 0, frag->size,
> > + PCI_DMA_TODEVICE);
>
> This should be DMA_TO_DEVICE instead of PCI_DMA_TODEVICE.
>
> >
> > if (unlikely(pci_dma_mapping_error(fifo->pdev, dma_pointer)))
> > goto _exit2;
>
> I would also change this to dma_mapping_error() in one go.
>
> Just a random patch check.
Thanks Michał.
I'm sure I must have made the same mistakes in a whole bunch of patches
which have already been applied. I'll knock up a fixup patch.
Cheers,
Ian.
>
> Best Regards,
> Michał Mirosław
^ permalink raw reply
* Re: [PATCH net] mscan: zero accidentally copied register content
From: Oliver Hartkopp @ 2011-10-06 7:02 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Wolfgang Grandegger, Linux Netdev List, Andre Naujoks
In-Reply-To: <4E8C8175.2040202@hartkopp.net>
On 10/05/11 18:10, Oliver Hartkopp wrote:
> On 10/05/11 17:51, Wolfram Sang wrote:
>>> + /* zero accidentally copied register content at odd DLCs */
>>> + if (frame->can_dlc & 1)
>>> + frame->data[frame->can_dlc] = 0;
>>> }
>>>
>>> out_8(®s->canrflg, MSCAN_RXF);
>>
>> Nice catch, but wouldn't it be more elegant to never have an invalid byte
>> in the first place?
>>
>> if (can_dlc & 1)
>> *payload = in_be16() & mask;
>>
>
>
> Hm, then i would rather think about changing the for() statement and to read
> byte-by-byte instead of the current in_be16() usage with the 16bit access
> drawbacks ...
>
I think if one would like to rework the 16bit register access (which is used
in the rx path /and/ in the tx path also) this should go via net-next after
some discussion and testing.
IMHO this fix is small and clear and especially not risky. I wonder if
reworking the 16 bit register access is worth the effort?
Regards,
Oliver
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree with the net tree
From: Stephen Rothwell @ 2011-10-06 6:16 UTC (permalink / raw)
To: David Miller
Cc: greg, linux-next, linux-kernel, Ian.Campbell, netdev, mark.einon
In-Reply-To: <20111006.015622.2047301950614681216.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
Hi Dave,
On Thu, 06 Oct 2011 01:56:22 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> Yep, we saw this one coming too. I think you'll need to carry this one
> until the merge window flushes out.
Sure, no problem.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree with the net tree
From: David Miller @ 2011-10-06 5:56 UTC (permalink / raw)
To: sfr; +Cc: greg, linux-next, linux-kernel, Ian.Campbell, netdev, mark.einon
In-Reply-To: <20111006160433.44de2a1374b6ec4efc97e04e@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 6 Oct 2011 16:04:33 +1100
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/et131x/et1310_tx.c between commit bf3f1a6081aa ("et131x:
> convert to SKB paged frag API") from the net tree and commit 10f00a49b048
> ("staging: et131x: Rename var name 'etdev' to 'adapter' throughout
> module") from the staging tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Yep, we saw this one coming too. I think you'll need to carry this one
until the merge window flushes out.
Thanks!
^ permalink raw reply
* linux-next: manual merge of the staging tree with the net tree
From: Stephen Rothwell @ 2011-10-06 5:04 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Ian Campbell, David Miller, netdev,
Mark Einon
[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/et131x/et1310_tx.c between commit bf3f1a6081aa ("et131x:
convert to SKB paged frag API") from the net tree and commit 10f00a49b048
("staging: et131x: Rename var name 'etdev' to 'adapter' throughout
module") from the staging tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/staging/et131x/et1310_tx.c
index 03e7a4e,2ecb934..0000000
--- a/drivers/staging/et131x/et1310_tx.c
+++ b/drivers/staging/et131x/et1310_tx.c
@@@ -519,12 -392,12 +392,12 @@@ static int nic_send_packet(struct et131
* returned by pci_map_page() is always 32-bit
* addressable (as defined by the pci/dma subsystem)
*/
- desc[frag++].addr_lo =
- pci_map_page(adapter->pdev,
- frags[i - 1].page,
- frags[i - 1].page_offset,
- frags[i - 1].size,
- PCI_DMA_TODEVICE);
+ desc[frag++].addr_lo = skb_frag_dma_map(
- &etdev->pdev->dev,
++ &adapter->pdev->dev,
+ &frags[i - 1],
+ 0,
+ frags[i - 1].size,
+ PCI_DMA_TODEVICE);
}
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the staging tree with the net tree
From: Stephen Rothwell @ 2011-10-06 4:58 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Eliad Peller, John W. Linville,
David Miller, netdev, Arend van Spriel
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/brcm80211/brcmsmac/mac80211_if.c between commit
37a41b4affa3 ("mac80211: add ieee80211_vif param to tsf functions") from
the net tree and commit 3956b4a2ddb0 ("staging: brcm80211: remove locking
macro definitions") from the staging tree.
I fixed it up (which essentially means I used the staging tree version
with one small change to the brcms_ops_conf_tx prototype) and can carry
the fixes as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Aandacht onze webmail gebruiker!
From: Posta Administrator @ 2011-10-06 1:52 UTC (permalink / raw)
Unser Sehr geehrter Webmail-Benutzer!
Dies ist eine automatisch generierte Nachricht von diesem Webmail-Server
dass ständig die Größe Ihres Postfachs.
Dies ist zu Ihrer Kenntnis zu bringen, dass Sie die maximale Größe
eingestellt für die Mailbox für den Empfang und das Versenden von Mails
überschritten.
Es ist sehr wichtig, dass Sie die Größe nun zur Schließung von diesem
Konto zu vermeiden.
Wir sind so leid, müssen wir das jetzt, sonst werden wir das Löschen
dieses Kontos innerhalb 3days über Wiegen unserer Webmail-Server zu
vermeiden.
Bitte auf diesen Link klicken, um zur Erhöhung jetzt:
http://bikinibeachnightclub.com/register/use/webmail-quota-form/form1.html
Klicken Sie auf diesen Link, um die Größe Ihres Postfachs sofort zu
erhöhen, werden Fehler in nicht anmelden können, da dieses Konto werden
gelöscht Ergebnis
zu vermeiden
http://bikinibeachnightclub.com/register/use/webmail-quota-form/form1.html
Letzte Warnung: Nichtbeachtung der Mailbox-Größe zu erhöhen jetzt
definitiv in Folge
permanente Unfähigkeit, in den Posteingang und den de-Aktivierung dieses
Webmail-Konto innerhalb 3days anmelden.
Bitte beachten Sie!
Wir entschuldigen uns für die Unannehmlichkeiten!
CopyRight © WEBMAIL ADMINISTRATOR
^ permalink raw reply
* [PATCH] IPv6: DAD from bonding iface is treated as dup address from others
From: Yinglin Sun @ 2011-10-06 3:59 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy <kabe
Cc: netdev, Yinglin Sun
Steps to reproduce this issue:
1. create bond0 over eth0 and eth1, set the mode to balance-xor
2. add an IPv6 address to bond0
3. DAD packet is sent out from one slave and then is looped back from
the other slave. Therefore, it is treated as a duplicate address and
stays tentative afterwards:
kern.info:
Oct 5 11:50:18 testvm1 kernel: [ 129.224353] bond0: IPv6 duplicate address 1234::1 detected!
Signed-off-by: Yinglin Sun <Yinglin.Sun@emc.com>
---
net/ipv6/ndisc.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 9da6e02..c82f4c7 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -809,9 +809,10 @@ static void ndisc_recv_ns(struct sk_buff *skb)
if (ifp->flags & (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)) {
if (dad) {
+ const unsigned char *sadr;
+ sadr = skb_mac_header(skb);
+
if (dev->type == ARPHRD_IEEE802_TR) {
- const unsigned char *sadr;
- sadr = skb_mac_header(skb);
if (((sadr[8] ^ dev->dev_addr[0]) & 0x7f) == 0 &&
sadr[9] == dev->dev_addr[1] &&
sadr[10] == dev->dev_addr[2] &&
@@ -821,6 +822,16 @@ static void ndisc_recv_ns(struct sk_buff *skb)
/* looped-back to us */
goto out;
}
+ } else if (dev->type == ARPHRD_ETHER) {
+ if (sadr[6] == dev->dev_addr[0] &&
+ sadr[7] == dev->dev_addr[1] &&
+ sadr[8] == dev->dev_addr[2] &&
+ sadr[9] == dev->dev_addr[3] &&
+ sadr[10] == dev->dev_addr[4] &&
+ sadr[11] == dev->dev_addr[5]) {
+ /* looped-back to us */
+ goto out;
+ }
}
/*
--
1.7.4.1
^ permalink raw reply related
* [ethtool] ethtool: fix flow control register dump for 82599 and newer
From: Jeff Kirsher @ 2011-10-06 2:17 UTC (permalink / raw)
To: bhutchings; +Cc: Emil Tantilov, netdev, gospo, Jeff Kirsher
From: Emil Tantilov <emil.s.tantilov@intel.com>
Fix reporting of the flow control settings in the register dump for ixgbe.
Use MFLCN for 82599 and X540 HW instead of FCTRL.
This patch also adds the ability to check for mac type.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
ixgbe.c | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 129 insertions(+), 9 deletions(-)
diff --git a/ixgbe.c b/ixgbe.c
index 998c008..e64d34a 100644
--- a/ixgbe.c
+++ b/ixgbe.c
@@ -26,18 +26,118 @@
#define IXGBE_HLREG0_LPBK 0x00008000
#define IXGBE_RMCS_TFCE_802_3X 0x00000008
#define IXGBE_RMCS_TFCE_PRIORITY 0x00000010
+#define IXGBE_MFLCN_PMCF 0x00000001 /* Pass MAC Control Frames */
+#define IXGBE_MFLCN_DPF 0x00000002 /* Discard Pause Frame */
+#define IXGBE_MFLCN_RPFCE 0x00000004 /* Receive Priority FC Enable */
+#define IXGBE_MFLCN_RFCE 0x00000008 /* Receive FC Enable */
+
+/* Device IDs */
+#define IXGBE_DEV_ID_82598 0x10B6
+#define IXGBE_DEV_ID_82598_BX 0x1508
+#define IXGBE_DEV_ID_82598AF_DUAL_PORT 0x10C6
+#define IXGBE_DEV_ID_82598AF_SINGLE_PORT 0x10C7
+#define IXGBE_DEV_ID_82598EB_SFP_LOM 0x10DB
+#define IXGBE_DEV_ID_82598AT 0x10C8
+#define IXGBE_DEV_ID_82598AT2 0x150B
+#define IXGBE_DEV_ID_82598EB_CX4 0x10DD
+#define IXGBE_DEV_ID_82598_CX4_DUAL_PORT 0x10EC
+#define IXGBE_DEV_ID_82598_DA_DUAL_PORT 0x10F1
+#define IXGBE_DEV_ID_82598_SR_DUAL_PORT_EM 0x10E1
+#define IXGBE_DEV_ID_82598EB_XF_LR 0x10F4
+#define IXGBE_DEV_ID_82599_KX4 0x10F7
+#define IXGBE_DEV_ID_82599_KX4_MEZZ 0x1514
+#define IXGBE_DEV_ID_82599_KR 0x1517
+#define IXGBE_DEV_ID_82599_T3_LOM 0x151C
+#define IXGBE_DEV_ID_82599_CX4 0x10F9
+#define IXGBE_DEV_ID_82599_SFP 0x10FB
+#define IXGBE_DEV_ID_82599_BACKPLANE_FCOE 0x152a
+#define IXGBE_DEV_ID_82599_SFP_FCOE 0x1529
+#define IXGBE_SUBDEV_ID_82599_SFP 0x11A9
+#define IXGBE_DEV_ID_82599_SFP_EM 0x1507
+#define IXGBE_DEV_ID_82599_SFP_SF2 0x154D
+#define IXGBE_DEV_ID_82599EN_SFP 0x1557
+#define IXGBE_DEV_ID_82599_XAUI_LOM 0x10FC
+#define IXGBE_DEV_ID_82599_COMBO_BACKPLANE 0x10F8
+#define IXGBE_SUBDEV_ID_82599_KX4_KR_MEZZ 0x000C
+#define IXGBE_DEV_ID_82599_LS 0x154F
+#define IXGBE_DEV_ID_X540T 0x1528
+
+/*
+ * Enumerated types specific to the ixgbe hardware
+ * Media Access Controlers
+ */
+enum ixgbe_mac_type {
+ ixgbe_mac_unknown = 0,
+ ixgbe_mac_82598EB,
+ ixgbe_mac_82599EB,
+ ixgbe_mac_X540,
+ ixgbe_num_macs
+};
+
+enum ixgbe_mac_type
+ixgbe_get_mac_type(u16 device_id)
+{
+ enum ixgbe_mac_type mac_type = ixgbe_mac_unknown;
+
+ switch (device_id) {
+ case IXGBE_DEV_ID_82598:
+ case IXGBE_DEV_ID_82598_BX:
+ case IXGBE_DEV_ID_82598AF_DUAL_PORT:
+ case IXGBE_DEV_ID_82598AF_SINGLE_PORT:
+ case IXGBE_DEV_ID_82598EB_SFP_LOM:
+ case IXGBE_DEV_ID_82598AT:
+ case IXGBE_DEV_ID_82598AT2:
+ case IXGBE_DEV_ID_82598EB_CX4:
+ case IXGBE_DEV_ID_82598_CX4_DUAL_PORT:
+ case IXGBE_DEV_ID_82598_DA_DUAL_PORT:
+ case IXGBE_DEV_ID_82598_SR_DUAL_PORT_EM:
+ case IXGBE_DEV_ID_82598EB_XF_LR:
+ mac_type = ixgbe_mac_82598EB;
+ break;
+ case IXGBE_DEV_ID_82599_KX4:
+ case IXGBE_DEV_ID_82599_KX4_MEZZ:
+ case IXGBE_DEV_ID_82599_KR:
+ case IXGBE_DEV_ID_82599_T3_LOM:
+ case IXGBE_DEV_ID_82599_CX4:
+ case IXGBE_DEV_ID_82599_SFP:
+ case IXGBE_DEV_ID_82599_BACKPLANE_FCOE:
+ case IXGBE_DEV_ID_82599_SFP_FCOE:
+ case IXGBE_SUBDEV_ID_82599_SFP:
+ case IXGBE_DEV_ID_82599_SFP_EM:
+ case IXGBE_DEV_ID_82599_SFP_SF2:
+ case IXGBE_DEV_ID_82599EN_SFP:
+ case IXGBE_DEV_ID_82599_XAUI_LOM:
+ case IXGBE_DEV_ID_82599_COMBO_BACKPLANE:
+ case IXGBE_SUBDEV_ID_82599_KX4_KR_MEZZ:
+ case IXGBE_DEV_ID_82599_LS:
+ mac_type = ixgbe_mac_82599EB;
+ break;
+ case IXGBE_DEV_ID_X540T:
+ mac_type = ixgbe_mac_X540;
+ break;
+ default:
+ mac_type = ixgbe_mac_82598EB;
+ break;
+ }
+
+ return mac_type;
+}
int
ixgbe_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
{
u32 *regs_buff = (u32 *)regs->data;
u32 reg;
- u8 i;
+ u16 hw_device_id = (u16) regs->version;
u8 version = (u8)(regs->version >> 24);
+ u8 i;
+ enum ixgbe_mac_type mac_type;
if (version != 1)
return -1;
+ mac_type = ixgbe_get_mac_type(hw_device_id);
+
reg = regs_buff[1065];
fprintf(stdout,
"0x042A4: LINKS (Link Status register) 0x%08X\n"
@@ -50,24 +150,44 @@ ixgbe_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
reg = regs_buff[515];
fprintf(stdout,
"0x05080: FCTRL (Filter Control register) 0x%08X\n"
- " Receive Flow Control Packets: %s\n"
- " Receive Priority Flow Control Packets: %s\n"
- " Discard Pause Frames: %s\n"
- " Pass MAC Control Frames: %s\n"
" Broadcast Accept: %s\n"
" Unicast Promiscuous: %s\n"
" Multicast Promiscuous: %s\n"
" Store Bad Packets: %s\n",
reg,
- reg & IXGBE_FCTRL_RFCE ? "enabled" : "disabled",
- reg & IXGBE_FCTRL_RPFCE ? "enabled" : "disabled",
- reg & IXGBE_FCTRL_DPF ? "enabled" : "disabled",
- reg & IXGBE_FCTRL_PMCF ? "enabled" : "disabled",
reg & IXGBE_FCTRL_BAM ? "enabled" : "disabled",
reg & IXGBE_FCTRL_UPE ? "enabled" : "disabled",
reg & IXGBE_FCTRL_MPE ? "enabled" : "disabled",
reg & IXGBE_FCTRL_SBP ? "enabled" : "disabled");
+ /* Some FCTRL bits are valid only on 82598 */
+ if (mac_type == ixgbe_mac_82598EB) {
+ fprintf(stdout,
+ " Receive Flow Control Packets: %s\n"
+ " Receive Priority Flow Control Packets: %s\n"
+ " Discard Pause Frames: %s\n"
+ " Pass MAC Control Frames: %s\n",
+ reg & IXGBE_FCTRL_RFCE ? "enabled" : "disabled",
+ reg & IXGBE_FCTRL_RPFCE ? "enabled" : "disabled",
+ reg & IXGBE_FCTRL_DPF ? "enabled" : "disabled",
+ reg & IXGBE_FCTRL_PMCF ? "enabled" : "disabled");
+ }
+
+ reg = regs_buff[1128];
+ if (mac_type >= ixgbe_mac_82599EB) {
+ fprintf(stdout,
+ "0x04294: MFLCN (TabMAC Flow Control register) 0x%08X\n"
+ " Receive Flow Control Packets: %s\n"
+ " Discard Pause Frames: %s\n"
+ " Pass MAC Control Frames: %s\n"
+ " Receive Priority Flow Control Packets: %s\n",
+ reg,
+ reg & IXGBE_MFLCN_RFCE ? "enabled" : "disabled",
+ reg & IXGBE_FCTRL_DPF ? "enabled" : "disabled",
+ reg & IXGBE_FCTRL_PMCF ? "enabled" : "disabled",
+ reg & IXGBE_FCTRL_RPFCE ? "enabled" : "disabled");
+ }
+
reg = regs_buff[516];
fprintf(stdout,
"0x05088: VLNCTRL (VLAN Control register) 0x%08X\n"
--
1.7.6.4
^ permalink raw reply related
* Re: [RFC] [PATCH] virtio: Dont add "config" to list for !per_vq_vector
From: Rusty Russell @ 2011-10-06 0:31 UTC (permalink / raw)
To: Michael S. Tsirkin, Krishna Kumar; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20111005104822.GC5587@redhat.com>
On Wed, 5 Oct 2011 08:48:23 -0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Oct 05, 2011 at 11:08:59AM +0530, Krishna Kumar wrote:
> > For the MSI but non-per_vq_vector case, the config/change vq
> > also gets added to the list of vqs that need to process the
> > MSI interrupt. This is not needed as config has it's own
> > handler (vp_config_changed). In any case, vring_interrupt()
> > finds nothing needs to be done on this vq.
> >
> > I tested this patch by testing the "Fallback:" and "Finally
> > fall back" cases in vp_find_vqs(). Please review.
> >
> > Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> (note: this is not a bugfix so not 3.1 material).
Thanks, applied.
Cheers,
Rusty.
^ permalink raw reply
* A new 40G Network driver ready to submit to the kernel tree
From: Joyce Yu - System Software @ 2011-10-05 23:13 UTC (permalink / raw)
To: netdev
I have a new 40G Network driver ready to submit to the kernel tree. The
driver has been ported to latest linux-3.0-rc5 and net-2.6-353e5c9 tree.
The driver versions for 2.6.18 and 2.6.32 based kernel have been fully
tested and released to the customer. Shall I just send the driverxx.c
and driverxx.h for net-2.6-353e5c9 and linux-3.0-rc5 to this alias?
Thanks,
Joyce
^ permalink raw reply
* Re: [PATCH 1/4] atm: solos-pci: Add AnnexA/M capability attributes
From: David Miller @ 2011-10-05 23:12 UTC (permalink / raw)
To: dwmw2; +Cc: nathan, netdev, linux-atm-general, linux-kernel
In-Reply-To: <1317855694.2426.2.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 06 Oct 2011 00:01:31 +0100
> On Wed, 2011-10-05 at 17:50 -0400, David Miller wrote:
>>
>> David, Nathan's patches look fine to me, want me to stick them into
>> net-next?
>
> Please. All of them can be
>
> Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Done, thanks everyone.
^ permalink raw reply
* Re: [PATCH 1/4] atm: solos-pci: Add AnnexA/M capability attributes
From: David Woodhouse @ 2011-10-05 23:01 UTC (permalink / raw)
To: David Miller; +Cc: nathan, netdev, linux-atm-general, linux-kernel
In-Reply-To: <20111005.175019.1707448511283364180.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 258 bytes --]
On Wed, 2011-10-05 at 17:50 -0400, David Miller wrote:
>
> David, Nathan's patches look fine to me, want me to stick them into
> net-next?
Please. All of them can be
Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Thanks.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5818 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox