* Re: [PATCH 1/1] PHY configuration for compatible issue
From: Guo-Fu Tseng @ 2011-11-21 5:35 UTC (permalink / raw)
To: AriesLee, Aries Lee, netdev
In-Reply-To: <1321870127-15541-1-git-send-email-AriesLee@jmicron.com>
On Mon, 21 Nov 2011 18:08:47 +0800, AriesLee wrote
> To perform PHY calibration and set a different EA value by chip ID,
> Whenever the NIC chip power on, ie booting or resuming, we need to
> force HW to calibrate PHY parameter again, and also set a proper EA
> value which gather from experiment.
>
> Those procedures help to reduce compatible issues(NIC is unable to link
> up in some special case) in giga speed.
>
> Signed-off-by: AriesLee <AriesLee@jmicron.com>
> ---
> drivers/net/ethernet/jme.c | 113
> ++++++++++++++++++++++++++++++++++++++++++- drivers/net/ethernet/jme.h
> | 19 +++++++ 2 files changed, 129 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
> index df3ab83..4d217b8 100644
> --- a/drivers/net/ethernet/jme.c
> +++ b/drivers/net/ethernet/jme.c
> @@ -1744,6 +1744,112 @@ jme_phy_off(struct jme_adapter *jme)
> jme_new_phy_off(jme);
> }
>
> +static void
> +jme_phy_specreg_read(struct jme_adapter *jme, u32 specreg, u32 *phy_data)
> +{
> + u32 phy_addr;
> +
> + phy_addr = JM_PHY_SPEC_REG_READ | specreg;
> + jme_mdio_write(jme->dev, jme->mii_if.phy_id, JM_PHY_SPEC_ADDR_REG,
> + phy_addr);
> + *phy_data = jme_mdio_read(jme->dev, jme->mii_if.phy_id,
> + JM_PHY_SPEC_DATA_REG);
> +}
Is there any particular reason that you pass the address of reading data.
Instead of just returning the value? (phy_data)
It would be more consistent if you return the value in this kind of
read function.
Otherwise this path all seems to be OK to me. :)
Signed-off-by: Guo-Fu Tseng <cooldavid@cooldavid.org>
Guo-Fu Tseng
^ permalink raw reply
* Problems with dropped packets on bonded interface for 3.x kernels
From: Albert Chin @ 2011-11-21 5:16 UTC (permalink / raw)
To: netdev
I'm running Ubuntu 11.10 on an Intel SR2625URLXR system with an Intel
S5520UR motherboard and an internal Intel E1G44HT (I340-T4) Quad Port
Server Adapter. I am seeing dropped packets on a bonded interface,
comprised of two GigE ports on the Intel E1G44HT Quad Port Server
Adapter. The following kernels exhibit this problem:
3.0.0-12-server, 3.0.0-13-server, 3.1.0-2-server, 3.2.0-rc2
Installing Fedora 16 with a 3.1.1-1.fc16.x86_64 also showed dropped
packets.
I also tried RHEL6 with a 2.6.32-131.17.1.el6.x86_64 kernel and didn't
see any dropped packets. Testing an older 2.6.32-28.55-generic Ubuntu
kernel also didn't show any dropped packets.
So, with 2.6, I don't see dropped packets, but everything including
3.0 and after show dropped packets.
# ifconfig bond0
bond0 Link encap:Ethernet HWaddr 00:1b:21:d3:f6:0a
inet6 addr: fe80::21b:21ff:fed3:f60a/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:225 errors:0 dropped:186 overruns:0 frame:0
TX packets:231 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:25450 (25.4 KB) TX bytes:28368 (28.3 KB)
With lacp_rate=fast, I see higher packet loss than with
lacp_rate=slow. I've tried bonding t
This server has the following network controllers for the two internal
NICs:
# lspci -vv
01:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit Network Connection (rev 02)
01:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit Network Connection (rev 02)
And it has the following network controllers for the four NICs on the
I340-T4 PCI-E card:
# lspci -vv
0a:00.0 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)
0a:00.1 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)
0a:00.2 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)
0a:00.3 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)
I tried bonding the two 82575EB NICs rather than two NICs on the 82580
but see the same dropped packet issue.
I have replaced the cables, tested each port individually on the
switch without bonding, and don't see any reason to expect hardware as
the issue. The switch is a Summit Extreme 400-48t.
I am using a 802.3ad configuration:
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 0
802.3ad info
LACP rate: fast
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 1
Actor Key: 17
Partner Key: 24
Partner Mac Address: 00:04:96:18:54:d5
Slave Interface: eth4
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:1b:21:d3:f6:0a
Aggregator ID: 1
Slave queue ID: 0
Slave Interface: eth5
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:1b:21:d3:f6:0b
Aggregator ID: 2
Slave queue ID: 0
Anyone have any ideas?
--
albert chin (china@thewrittenword.com)
^ permalink raw reply
* [PATCH net-next 3/3] be2net: workaround to fix a BE bug
From: Ajit Khaparde @ 2011-11-21 5:22 UTC (permalink / raw)
To: netdev, davem
For vlan tagged pkts, BE
1) calculates checksum even when CSO is not requested
2) calculates checksum wrongly for padded pkt less than 60 bytes long.
As a workaround disable TX vlan offloading in such cases.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/ethernet/emulex/benet/be.h | 16 +++++++++++++
drivers/net/ethernet/emulex/benet/be_main.c | 32 +++++++++++++++++++-------
2 files changed, 39 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 34f162d..c4fcea69 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -518,6 +518,22 @@ static inline void be_vf_eth_addr_generate(struct be_adapter *adapter, u8 *mac)
memcpy(mac, adapter->netdev->dev_addr, 3);
}
+static inline u16 be_get_tx_vlan_tag(struct be_adapter *adapter,
+ struct sk_buff *skb)
+{
+ u8 vlan_prio;
+ u16 vlan_tag;
+
+ vlan_tag = vlan_tx_tag_get(skb);
+ vlan_prio = (vlan_tag & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
+ /* If vlan priority provided by OS is NOT in available bmap */
+ if (!(adapter->vlan_prio_bmap & (1 << vlan_prio)))
+ vlan_tag = (vlan_tag & ~VLAN_PRIO_MASK) |
+ adapter->recommended_prio;
+
+ return vlan_tag;
+}
+
static inline bool be_multi_rxq(const struct be_adapter *adapter)
{
return adapter->num_rx_qs > 1;
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 95d41ba..db27269 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -554,8 +554,7 @@ static inline void wrb_fill(struct be_eth_wrb *wrb, u64 addr, int len)
static void wrb_fill_hdr(struct be_adapter *adapter, struct be_eth_hdr_wrb *hdr,
struct sk_buff *skb, u32 wrb_cnt, u32 len)
{
- u8 vlan_prio = 0;
- u16 vlan_tag = 0;
+ u16 vlan_tag;
memset(hdr, 0, sizeof(*hdr));
@@ -584,14 +583,9 @@ static void wrb_fill_hdr(struct be_adapter *adapter, struct be_eth_hdr_wrb *hdr,
AMAP_SET_BITS(struct amap_eth_hdr_wrb, udpcs, hdr, 1);
}
- if (vlan_tx_tag_present(skb)) {
+ if (adapter->vlans_added && vlan_tx_tag_present(skb)) {
AMAP_SET_BITS(struct amap_eth_hdr_wrb, vlan, hdr, 1);
- vlan_tag = vlan_tx_tag_get(skb);
- vlan_prio = (vlan_tag & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
- /* If vlan priority provided by OS is NOT in available bmap */
- if (!(adapter->vlan_prio_bmap & (1 << vlan_prio)))
- vlan_tag = (vlan_tag & ~VLAN_PRIO_MASK) |
- adapter->recommended_prio;
+ vlan_tag = be_get_tx_vlan_tag(adapter, skb);
AMAP_SET_BITS(struct amap_eth_hdr_wrb, vlan_tag, hdr, vlan_tag);
}
@@ -694,6 +688,25 @@ static netdev_tx_t be_xmit(struct sk_buff *skb,
u32 start = txq->head;
bool dummy_wrb, stopped = false;
+ /* For vlan tagged pkts, BE
+ * 1) calculates checksum even when CSO is not requested
+ * 2) calculates checksum wrongly for padded pkt less than
+ * 60 bytes long.
+ * As a workaround disable TX vlan offloading in such cases.
+ */
+ if (unlikely(vlan_tx_tag_present(skb) &&
+ (skb->ip_summed != CHECKSUM_PARTIAL || skb->len <= 60))) {
+ skb = skb_share_check(skb, GFP_ATOMIC);
+ if (unlikely(!skb))
+ goto tx_drop;
+
+ skb = __vlan_put_tag(skb, be_get_tx_vlan_tag(adapter, skb));
+ if (unlikely(!skb))
+ goto tx_drop;
+
+ skb->vlan_tci = 0;
+ }
+
wrb_cnt = wrb_cnt_for_skb(adapter, skb, &dummy_wrb);
copied = make_tx_wrbs(adapter, txq, skb, wrb_cnt, dummy_wrb);
@@ -719,6 +732,7 @@ static netdev_tx_t be_xmit(struct sk_buff *skb,
skb_shinfo(skb)->gso_segs, stopped);
} else {
txq->head = start;
+tx_drop:
dev_kfree_skb_any(skb);
}
return NETDEV_TX_OK;
--
1.7.5.4
^ permalink raw reply related
* [PATCH] dccp: fix error propagation in dccp_v4_connect
From: roy.qing.li @ 2011-11-21 5:18 UTC (permalink / raw)
To: netdev
From: RongQing.Li <roy.qing.li@gmail.com>
The errcode is not updated when ip_route_newports() fails.
Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
---
net/dccp/ipv4.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 90a919a..3f4e541 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -111,6 +111,7 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
rt = ip_route_newports(fl4, rt, orig_sport, orig_dport,
inet->inet_sport, inet->inet_dport, sk);
if (IS_ERR(rt)) {
+ err = PTR_ERR(rt);
rt = NULL;
goto failure;
}
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 2/3] be2net: update some counters to display via ethtool
From: Ajit Khaparde @ 2011-11-21 5:12 UTC (permalink / raw)
To: netdev, davem
update pmem_fifo_overflow_drop, rx_priority_pause_frames counters.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 93869d4..95d41ba 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -315,6 +315,8 @@ static void populate_be3_stats(struct be_adapter *adapter)
struct be_drv_stats *drvs = &adapter->drv_stats;
be_dws_le_to_cpu(hw_stats, sizeof(*hw_stats));
+ drvs->pmem_fifo_overflow_drop = port_stats->pmem_fifo_overflow_drop;
+ drvs->rx_priority_pause_frames = port_stats->rx_priority_pause_frames;
drvs->rx_pause_frames = port_stats->rx_pause_frames;
drvs->rx_crc_errors = port_stats->rx_crc_errors;
drvs->rx_control_frames = port_stats->rx_control_frames;
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next 0/3] be2net: patch series
From: Ajit Khaparde @ 2011-11-21 5:12 UTC (permalink / raw)
To: netdev, davem
Please apply.
Thanks
-Ajit
[1/3] be2net: fix to display Pause autonegotiation setting
[2/3] be2net: update some counters to display via ethtool
[3/3] be2net: workaround to fix a BE bug
^ permalink raw reply
* [PATCH net-next 1/3] be2net: fix to display Pause autonegotiation setting
From: Ajit Khaparde @ 2011-11-21 5:12 UTC (permalink / raw)
To: netdev, davem
Pause autonegotiation is supported by default.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_ethtool.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 575c783..ff53489 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -538,7 +538,7 @@ be_get_pauseparam(struct net_device *netdev, struct ethtool_pauseparam *ecmd)
struct be_adapter *adapter = netdev_priv(netdev);
be_cmd_get_flow_control(adapter, &ecmd->tx_pause, &ecmd->rx_pause);
- ecmd->autoneg = 0;
+ ecmd->autoneg = 1;
}
static int
--
1.7.5.4
^ permalink raw reply related
* Wir bieten Darlehen
From: CAPITAL EQUALITY LOAN COMPANY @ 2011-11-21 2:57 UTC (permalink / raw)
Hiermit möchten wir Sie darüber informieren, dass CAPITAL GLEICHHEIT
Loan Company ist derzeit ein Darlehen anbieten zu 3% Zins.
Wir bieten eine Vielzahl von Krediten an unsere Kunden. Was auch immer
Ihr Darlehen braucht, sind große oder kleine, persönliche oder
Hypotheken, sind wir bereit, mit Ihnen darüber, wie wir Ihre
Bedürfnisse zu sprechen. Anmeldeformular unter
CAPITAL GLEICHHEIT Loan Company
71 Queen Victoria Street
London, United Kingdom, EC4V 4DE
Bewerbungsformular:
1) Vollständiger Name :.........
2) Land :..............
3) Anschrift: ...
4) Sex :..............
5) Familienstand :......................
6) Beruf :..............
7) Telefon :......
8) Monatliches Einkommen :.....................
9) Darlehensbetrag Benötigte :...............
10) Dauer der Ausleihe :..................
11) Zweck des Darlehens :.................
12) Alter: ..............
Rosmarie Neely
Loan Officer
E-mail: capitalequalityloancompany@yahoo.com.hk
Tell: +447035958575
Fax: +448447742385
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* MSL WINNING NOTIFICATION 2011 WQLHPIUVRJ
From: Microsoft @ 2011-11-21 3:02 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 159 bytes --]
Att:
You have to urgently contact your claims agent to redeem your winning prize.
Microsoft Lottery
Managment Board
GRPVWCCNJTXMMRSGULXXUDPQUSDDXKQBBZPFZB
[-- Attachment #2: MSL-WINNING NOTIFICATION 2011.doc --]
[-- Type: application/msword, Size: 73216 bytes --]
^ permalink raw reply
* Re: [PATCH for 2.6.32 (untested)] netns: Add quota for number of NET_NS instances.
From: Eric W. Biederman @ 2011-11-21 2:45 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: netdev
In-Reply-To: <201111210157.pAL1vbRo089486@www262.sakura.ne.jp>
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:
> Eric W. Biederman wrote:
>> Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:
>>
>> > In order to solve below problems, can we add sysctl variable for
>> > restricting number of NET_NS instances?
>>
>> I don't have any particular problems with patch but I don't think it
>> will result in a working system that is easy to keep working. Tuning
>> static limits can be fickle.
>
> What I worry is that, although clone() is an operation that is allowed to
> sleep, waiting for too long might be annoying for users, especially when the
> user cannot easily send Ctrl-C or SIGKILL. (I think ftp client is an
> example.)
An ftp client can always close the connection. We already have to
contend for the net_mutex when both creating and destroying network
namespaces so I would be surprised if it is actually a problem.
But the reality is that under high connection load if we actually want
to use network namespaces we have to wait for previous network
namespaces to clean up. So I am not particularly worried. Especially
since most of the cleanup speed issues when there is a backlog have
been fixed in more recent kernels.
>> My inclination in this case the practical fix is that during network
>> namespace allocation someone take a look at the cleanup_list. See
>> that there is ongoing cleanup activity, and wait until at least one
>> network namespace has cleaned up. Perhaps by creating a work struct
>> and waiting for it to cycle through the netns workqueue.
>
> Are you suggesting that we should wait only when "the number of NET_NS
> instances exceeded quota" and "there is a dead NET_NS instance"?
> In other words, let clone() fail immediately if "the number of NET_NS
> instances exceeded quota" but "cleanup_list is empty"?
>
> If you are suggesting that we should always wait until "the number of NET_NS
> instances becomes smaller than quota", clone() might sleep too long when the
> user cannot easily send signals.
I am suggesting that if a netns instance is being cleaned up we should
wait for one netns instance to be cleaned up. A single netns instance
does not take long to clean up (in general). But a lot of netns
instances do take a while.
With waiting for one netns instance to be cleaned up we should be able
to guarantee that we don't develop a substantial backlog network
namespaces to be cleaned up. And that was the problem.
I don't expect we need to do anything if there are no network namespaces
not being cleaned up.
There is of course debian's solution which was to simply tweak vsftp
to not use network namespaces on 2.6.32 and only enable the feature
on later kernels. But you seem to want to do something a little
more substantial than that.
Eric
^ permalink raw reply
* [PATCH 1/1] PHY configuration for compatible issue
From: AriesLee @ 2011-11-21 10:08 UTC (permalink / raw)
To: Aries Lee, Guo-Fu Tseng, netdev; +Cc: AriesLee
To perform PHY calibration and set a different EA value by chip ID,
Whenever the NIC chip power on, ie booting or resuming, we need to
force HW to calibrate PHY parameter again, and also set a proper EA
value which gather from experiment.
Those procedures help to reduce compatible issues(NIC is unable to link
up in some special case) in giga speed.
Signed-off-by: AriesLee <AriesLee@jmicron.com>
---
drivers/net/ethernet/jme.c | 113 ++++++++++++++++++++++++++++++++++++++++++-
drivers/net/ethernet/jme.h | 19 +++++++
2 files changed, 129 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index df3ab83..4d217b8 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -1744,6 +1744,112 @@ jme_phy_off(struct jme_adapter *jme)
jme_new_phy_off(jme);
}
+static void
+jme_phy_specreg_read(struct jme_adapter *jme, u32 specreg, u32 *phy_data)
+{
+ u32 phy_addr;
+
+ phy_addr = JM_PHY_SPEC_REG_READ | specreg;
+ jme_mdio_write(jme->dev, jme->mii_if.phy_id, JM_PHY_SPEC_ADDR_REG,
+ phy_addr);
+ *phy_data = jme_mdio_read(jme->dev, jme->mii_if.phy_id,
+ JM_PHY_SPEC_DATA_REG);
+}
+
+static void
+jme_phy_specreg_write(struct jme_adapter *jme, u32 ext_reg, u32 phy_data)
+{
+ u32 phy_addr;
+
+ phy_addr = JM_PHY_SPEC_REG_WRITE | ext_reg;
+ jme_mdio_write(jme->dev, jme->mii_if.phy_id, JM_PHY_SPEC_DATA_REG,
+ phy_data);
+ jme_mdio_write(jme->dev, jme->mii_if.phy_id, JM_PHY_SPEC_ADDR_REG,
+ phy_addr);
+}
+
+static int
+jme_phy_calibration(struct jme_adapter *jme)
+{
+ u32 ctrl1000, phy_data;
+
+ jme_phy_off(jme);
+ jme_phy_on(jme);
+ /* Enabel PHY test mode 1 */
+ ctrl1000 = jme_mdio_read(jme->dev, jme->mii_if.phy_id, MII_CTRL1000);
+ ctrl1000 &= ~PHY_GAD_TEST_MODE_MSK;
+ ctrl1000 |= PHY_GAD_TEST_MODE_1;
+ jme_mdio_write(jme->dev, jme->mii_if.phy_id, MII_CTRL1000, ctrl1000);
+
+ jme_phy_specreg_read(jme, JM_PHY_EXT_COMM_2_REG, &phy_data);
+ phy_data &= ~JM_PHY_EXT_COMM_2_CALI_MODE_0;
+ phy_data |= JM_PHY_EXT_COMM_2_CALI_LATCH |
+ JM_PHY_EXT_COMM_2_CALI_ENABLE;
+ jme_phy_specreg_write(jme, JM_PHY_EXT_COMM_2_REG, phy_data);
+ msleep(20);
+ jme_phy_specreg_read(jme, JM_PHY_EXT_COMM_2_REG, &phy_data);
+ phy_data &= ~(JM_PHY_EXT_COMM_2_CALI_ENABLE |
+ JM_PHY_EXT_COMM_2_CALI_MODE_0 |
+ JM_PHY_EXT_COMM_2_CALI_LATCH);
+ jme_phy_specreg_write(jme, JM_PHY_EXT_COMM_2_REG, phy_data);
+
+ /* Disable PHY test mode */
+ ctrl1000 = jme_mdio_read(jme->dev, jme->mii_if.phy_id, MII_CTRL1000);
+ ctrl1000 &= ~PHY_GAD_TEST_MODE_MSK;
+ jme_mdio_write(jme->dev, jme->mii_if.phy_id, MII_CTRL1000, ctrl1000);
+ return 0;
+}
+
+static int
+jme_phy_setEA(struct jme_adapter *jme)
+{
+ u32 phy_comm0 = 0, phy_comm1 = 0;
+ u8 nic_ctrl;
+
+ pci_read_config_byte(jme->pdev, PCI_PRIV_SHARE_NICCTRL, &nic_ctrl);
+ if ((nic_ctrl & 0x3) == JME_FLAG_PHYEA_ENABLE)
+ return 0;
+
+ switch (jme->pdev->device) {
+ case PCI_DEVICE_ID_JMICRON_JMC250:
+ if (((jme->chip_main_rev == 5) &&
+ ((jme->chip_sub_rev == 0) || (jme->chip_sub_rev == 1) ||
+ (jme->chip_sub_rev == 3))) ||
+ (jme->chip_main_rev >= 6)) {
+ phy_comm0 = 0x008A;
+ phy_comm1 = 0x4109;
+ }
+ if ((jme->chip_main_rev == 3) &&
+ ((jme->chip_sub_rev == 1) || (jme->chip_sub_rev == 2)))
+ phy_comm0 = 0xE088;
+ break;
+ case PCI_DEVICE_ID_JMICRON_JMC260:
+ if (((jme->chip_main_rev == 5) &&
+ ((jme->chip_sub_rev == 0) || (jme->chip_sub_rev == 1) ||
+ (jme->chip_sub_rev == 3))) ||
+ (jme->chip_main_rev >= 6)) {
+ phy_comm0 = 0x008A;
+ phy_comm1 = 0x4109;
+ }
+ if ((jme->chip_main_rev == 3) &&
+ ((jme->chip_sub_rev == 1) || (jme->chip_sub_rev == 2)))
+ phy_comm0 = 0xE088;
+ if ((jme->chip_main_rev == 2) && (jme->chip_sub_rev == 0))
+ phy_comm0 = 0x608A;
+ if ((jme->chip_main_rev == 2) && (jme->chip_sub_rev == 2))
+ phy_comm0 = 0x408A;
+ break;
+ default:
+ return -ENODEV;
+ }
+ if (phy_comm0)
+ jme_phy_specreg_write(jme, JM_PHY_EXT_COMM_0_REG, phy_comm0);
+ if (phy_comm1)
+ jme_phy_specreg_write(jme, JM_PHY_EXT_COMM_1_REG, phy_comm1);
+
+ return 0;
+}
+
static int
jme_open(struct net_device *netdev)
{
@@ -1769,7 +1875,8 @@ jme_open(struct net_device *netdev)
jme_set_settings(netdev, &jme->old_ecmd);
else
jme_reset_phy_processor(jme);
-
+ jme_phy_calibration(jme);
+ jme_phy_setEA(jme);
jme_reset_link(jme);
return 0;
@@ -3184,7 +3291,8 @@ jme_resume(struct device *dev)
jme_set_settings(netdev, &jme->old_ecmd);
else
jme_reset_phy_processor(jme);
-
+ jme_phy_calibration(jme);
+ jme_phy_setEA(jme);
jme_start_irq(jme);
netif_device_attach(netdev);
@@ -3239,4 +3347,3 @@ MODULE_DESCRIPTION("JMicron JMC2x0 PCI Express Ethernet driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_VERSION);
MODULE_DEVICE_TABLE(pci, jme_pci_tbl);
-
diff --git a/drivers/net/ethernet/jme.h b/drivers/net/ethernet/jme.h
index 02ea27c..4304072 100644
--- a/drivers/net/ethernet/jme.h
+++ b/drivers/net/ethernet/jme.h
@@ -760,6 +760,25 @@ enum jme_rxmcs_bits {
RXMCS_CHECKSUM,
};
+/* Extern PHY common register 2 */
+
+#define PHY_GAD_TEST_MODE_1 0x00002000
+#define PHY_GAD_TEST_MODE_MSK 0x0000E000
+#define JM_PHY_SPEC_REG_READ 0x00004000
+#define JM_PHY_SPEC_REG_WRITE 0x00008000
+#define PHY_CALIBRATION_DELAY 20
+#define JM_PHY_SPEC_ADDR_REG 0x1E
+#define JM_PHY_SPEC_DATA_REG 0x1F
+
+#define JM_PHY_EXT_COMM_0_REG 0x30
+#define JM_PHY_EXT_COMM_1_REG 0x31
+#define JM_PHY_EXT_COMM_2_REG 0x32
+#define JM_PHY_EXT_COMM_2_CALI_ENABLE 0x01
+#define JM_PHY_EXT_COMM_2_CALI_MODE_0 0x02
+#define JM_PHY_EXT_COMM_2_CALI_LATCH 0x10
+#define PCI_PRIV_SHARE_NICCTRL 0xF5
+#define JME_FLAG_PHYEA_ENABLE 0x2
+
/*
* Wakeup Frame setup interface registers
*/
--
1.7.4.4
^ permalink raw reply related
* RE: [PATCH 1/1] PHY configuration for compatible issue
From: Aries Lee @ 2011-11-21 2:13 UTC (permalink / raw)
To: 'Guo-Fu Tseng', netdev; +Cc: 'AriesLee'
In-Reply-To: <20111119041736.M37290@cooldavid.org>
Yes ~~ that's indeed a good suggestion
-----Original Message-----
From: Guo-Fu Tseng [mailto:cooldavid@cooldavid.org]
Sent: Saturday, November 19, 2011 12:20 PM
To: Aries Lee; netdev@vger.kernel.org
Cc: 'AriesLee'
Subject: RE: [PATCH 1/1] PHY configuration for compatible issue
On Fri, 18 Nov 2011 15:13:37 +0800, Aries Lee wrote
> Hi Guo-Fu and All
>
> Because jme_phy_on() and jme_phy_off() just turn on/off the PHY, the
> value of extern register is still the power on default value, not the most
> robust value which we collect in the LAB.
Sure, I got it. That's the point of this patch isn't it? :p
+ /* Turn PHY off */
+ bmcr = jme_mdio_read(jme->dev, jme->mii_if.phy_id, MII_BMCR);
+ bmcr |= BMCR_PDOWN;
+ jme_mdio_write(jme->dev, jme->mii_if.phy_id, MII_BMCR, bmcr);
+ /* Turn PHY on */
+ bmcr = jme_mdio_read(jme->dev, jme->mii_if.phy_id, MII_BMCR);
+ bmcr &= ~BMCR_PDOWN;
+ jme_mdio_write(jme->dev, jme->mii_if.phy_id, MII_BMCR, bmcr);
But what I mean is this part of the code.
Guo-Fu Tseng
^ permalink raw reply
* Re: [PATCH for 2.6.32 (untested)] netns: Add quota for number of NET_NS instances.
From: Tetsuo Handa @ 2011-11-21 1:57 UTC (permalink / raw)
To: ebiederm; +Cc: netdev
In-Reply-To: <m1bos6wfnt.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:
>
> > In order to solve below problems, can we add sysctl variable for
> > restricting number of NET_NS instances?
>
> I don't have any particular problems with patch but I don't think it
> will result in a working system that is easy to keep working. Tuning
> static limits can be fickle.
What I worry is that, although clone() is an operation that is allowed to
sleep, waiting for too long might be annoying for users, especially when the
user cannot easily send Ctrl-C or SIGKILL. (I think ftp client is an example.)
> My inclination in this case the practical fix is that during network
> namespace allocation someone take a look at the cleanup_list. See
> that there is ongoing cleanup activity, and wait until at least one
> network namespace has cleaned up. Perhaps by creating a work struct
> and waiting for it to cycle through the netns workqueue.
Are you suggesting that we should wait only when "the number of NET_NS
instances exceeded quota" and "there is a dead NET_NS instance"?
In other words, let clone() fail immediately if "the number of NET_NS
instances exceeded quota" but "cleanup_list is empty"?
If you are suggesting that we should always wait until "the number of NET_NS
instances becomes smaller than quota", clone() might sleep too long when the
user cannot easily send signals.
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Alex,Shi @ 2011-11-21 0:44 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, Eric Dumazet
In-Reply-To: <20111118120201.GA1642@x4.trippels.de>
On Fri, 2011-11-18 at 20:02 +0800, Markus Trippelsdorf wrote:
> On 2011.11.18 at 09:54 +0100, Markus Trippelsdorf wrote:
> > On 2011.11.18 at 16:43 +0800, Alex,Shi wrote:
> > > > >
> > > > > The dirty flag comes from a bunch of unrelated xfs patches from Christoph, that
> > > > > I'm testing right now.
> > >
> > > Where is the xfs patchset? I am wondering if it is due to slub code.
>
> I begin to wonder if this might be the result of a compiler bug.
> The kernel in question was compiled with gcc version 4.7.0 20111117. And
> there was commit to the gcc repository today that looks suspicious:
> http://gcc.gnu.org/viewcvs?view=revision&revision=181466
>
Tell us if it is still there and you can reproduce it.
> Will have to dig deeper, but if this turns out to be the cause of the
> issue, I apologize for the noise.
>
That's all right.
--
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: [RFC] kvm tools: Implement multiple VQ for virtio-net
From: Rusty Russell @ 2011-11-21 0:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, gorcunov, kvm, Asias He, virtualization,
Pekka Enberg, Sasha Levin, netdev, mingo, Stephen Hemminger
In-Reply-To: <20111116072317.GG5433@redhat.com>
On Wed, 16 Nov 2011 09:23:17 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Nov 16, 2011 at 10:34:42AM +1030, Rusty Russell wrote:
> > On Mon, 14 Nov 2011 15:05:07 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > On Mon, Nov 14, 2011 at 02:25:17PM +0200, Pekka Enberg wrote:
> > > > On Mon, Nov 14, 2011 at 4:04 AM, Asias He <asias.hejun@gmail.com> wrote:
> > > > > Why both the bandwidth and latency performance are dropping so dramatically
> > > > > with multiple VQ?
> > > >
> > > > What's the expected benefit from multiple VQs
> > >
> > > Heh, the original patchset didn't mention this :) It really should.
> > > They are supposed to speed up networking for high smp guests.
> >
> > If we have one queue per guest CPU, does this allow us to run lockless?
> >
> > Thanks,
> > Rusty.
>
> LLTX? It's supposed to be deprecated, isn't it?
I was referring back to "Subject: virtio net lockless ring" which
Stephen sent back in June, nothing more specific.
I assumed from his query that this was still an active area of
exploration...
Stephen?
Thanks,
Rusty.
^ permalink raw reply
* Recursive routing causes MTU collapse (was Re: Bug? GRE tunnel periodically won't transmit some packets)
From: Chris Siebenmann @ 2011-11-21 0:23 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: cks
In-Reply-To: <20111110051649.505C8362D2@apps0.cs.toronto.edu>
I believe I've identified the root cause of my GRE tunnel packet
transmission problems. The short summary is that I have a 'recursive'
routing, where the route for the tunnel endpoint can nominally be routed
over the tunnel itself. In current kernel versions, when a packet for
the tunnel endpoint is actually routed over the tunnel the path MTUs
determined for the endpoint and the tunnel both collapse down to very
small values.
Here is the routing I have. First, the links themselves, for the DSL
PPPoE device and the GRE tunnel:
3: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
inet 66.96.18.208 peer 66.96.31.6/32 scope global ppp0
5: extun: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1200 qdisc noqueue state UNKNOWN
link/gre 66.96.18.208 peer 128.100.3.58
inet 128.100.3.52/32 scope global extun
(My IPSec policy forces GRE traffic between 128.100.3.58 and
66.96.18.208 to be encrypted in 'esp/tunnel' mode.)
Now the recursion. To reach other machines on 128.100.3.0/24, I route
128.100.3.0/24 over the GRE tunnel:
; ip route list match 128.100.3.51
default dev ppp0 scope link
128.100.3.0/24 dev extun scope link
I also have policy based routing set to force traffic with an IP
origin of 66.96.18.208 out over the PPP link and traffic with an
IP origin of 128.100.3.52 out the GRE tunnel.
With this setup in place, if I do anything that tries to talk to
128.100.3.58 (such as ping or ssh) what I get is an immediate path
MTU collapse for the 66.96.18.208 -> 128.100.3.58 link used by the
GRE tunnel, ending when the path MTU for 66.96.18.208 -> 128.100.3.58
reaches 552 octets. At this point various things choke (I am guessing
because the GRE tunnel expects a minimum MTU of 576 octets).
If I add a host route for 128.100.3.58 that forces traffic for it
through ppp0 I can mostly avoid this route collapse:
; ip route list exact 128.100.3.58
128.100.3.58 dev ppp0 scope link src 66.96.18.208 mtu 1492
However, even with this if I explicitly force traffic for 128.100.3.58
over the GRE tunnel (such as by specifying the IP source address
so as to make my policy based routing kick in) I still see the MTU
collapse. Using 'mtu lock 1492' instead of plain 'mtu 1492' on this
host-based route does not appear to change anything.
This did not happen back in kernel 2.6.35.14 (the Fedora 14 kernel) and
previous kernels (going back years). In that kernel everything was happy
even without the ppp0-forcing host route for 128.100.3.58 and I could
talk to 128.100.3.58 over the GRE tunnel without causing any path MTU
changes (and without problems in general).
(This always made my head hurt a little bit but since it worked,
I didn't worry about it.)
- cks
^ permalink raw reply
* MSL WINNING NOTIFICATION 2011 XVWJCSZDXM
From: Microsoft @ 2011-11-20 23:44 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 159 bytes --]
Att:
You have to urgently contact your claims agent to redeem your winning prize.
Microsoft Lottery
Managment Board
NXBHSSXKKJXQVEPVFMHZXEVPQIMUSQIYWILLHN
[-- Attachment #2: MSL-WINNING NOTIFICATION 2011.doc --]
[-- Type: application/msword, Size: 73216 bytes --]
^ permalink raw reply
* sky2 tx watchdog timeout with 1Gb speed
From: Milan Kocian @ 2011-11-20 23:21 UTC (permalink / raw)
To: netdev
hi all,
I switched my home pc from 100Mb/s to 1000Mb/s and I see
this warning below.
The original kernel was 2.6.39.4 then I tested 3.1.1 with the same
result. (self compiled 32bit vanilla). The workaround is to force 10/100 speed
on my new switch (hp).
lspci:
03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 13)
Subsystem: Giga-byte Technology Device e000
Flags: bus master, fast devsel, latency 0, IRQ 45
Memory at f5000000 (64-bit, non-prefetchable) [size=16K]
I/O ports at 9000 [size=256]
[virtual] Expansion ROM at 80300000 [disabled] [size=128K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [5c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: sky2
Nov 20 21:32:54 milu kernel: sky2 0000:03:00.0: eth0: Link is up at 1000 Mbps, full duplex, flow control both
Nov 20 21:35:29 milu kernel: ------------[ cut here ]------------
Nov 20 21:35:29 milu kernel: WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x1fa/0x206()
Nov 20 21:35:29 milu kernel: Hardware name: 965GM-S2
Nov 20 21:35:29 milu kernel: NETDEV WATCHDOG: eth0 (sky2): transmit queue 0 timed out
Nov 20 21:35:29 milu kernel: Modules linked in: parport_pc parport fuse nfsd ipv6 nfs lockd auth_rpcgss nfs_acl sunrpc usbhid snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_intel8x0 sg snd_ac97_codec sr_mod ac97_bus cdrom sky2 snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss intel_agp snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd bitrev i2c_i801 crc32 intel_gtt uhci_hcd i2c_core ehci_hcd soundcore usbcore agpgart evdev snd_page_alloc
Nov 20 21:35:29 milu kernel: Pid: 0, comm: swapper Not tainted 3.1.1 #2
Nov 20 21:35:29 milu kernel: Call Trace:
Nov 20 21:35:29 milu kernel: [<c102cd5d>] ? warn_slowpath_common+0x6c/0x94
Nov 20 21:35:29 milu kernel: [<c1254deb>] ? dev_watchdog+0x1fa/0x206
Nov 20 21:35:29 milu kernel: [<c1254deb>] ? dev_watchdog+0x1fa/0x206
Nov 20 21:35:29 milu kernel: [<c102ce0e>] ? warn_slowpath_fmt+0x33/0x37
Nov 20 21:35:29 milu kernel: [<c1254deb>] ? dev_watchdog+0x1fa/0x206
Nov 20 21:35:29 milu kernel: [<c1254bf1>] ? qdisc_reset+0x2d/0x2d
Nov 20 21:35:29 milu kernel: [<c1036434>] ? run_timer_softirq+0xc6/0x1c4
Nov 20 21:35:29 milu kernel: [<c1027e9b>] ? run_rebalance_domains+0x148/0x169
Nov 20 21:35:29 milu kernel: [<c103163b>] ? __do_softirq+0x6e/0xea
Nov 20 21:35:29 milu kernel: [<c10315cd>] ? remote_softirq_receive+0x11/0x11
Nov 20 21:35:29 milu kernel: <IRQ> [<c1031906>] ? irq_exit+0x5b/0x67
Nov 20 21:35:29 milu kernel: [<c101631f>] ? smp_apic_timer_interrupt+0x51/0x81
Nov 20 21:35:29 milu kernel: [<c12ccd96>] ? apic_timer_interrupt+0x2a/0x30
Nov 20 21:35:29 milu kernel: [<c13f007b>] ? asus_hides_smbus_hostbridge+0xcb/0x249
Nov 20 21:35:29 milu kernel: [<c1008732>] ? mwait_idle+0x41/0x51
Nov 20 21:35:29 milu kernel: [<c10015d8>] ? cpu_idle+0x74/0x84
Nov 20 21:35:29 milu kernel: [<c13d6638>] ? start_kernel+0x28a/0x28f
Nov 20 21:35:29 milu kernel: [<c13d615e>] ? loglevel+0x2b/0x2b
Nov 20 21:35:29 milu kernel: ---[ end trace ef84175f674c7842 ]---
Nov 20 21:35:29 milu kernel: sky2 0000:03:00.0: eth0: tx timeout
Nov 20 21:35:29 milu kernel: sky2 0000:03:00.0: eth0: transmit ring 52 .. 30 report=52 done=52
Nov 20 21:35:32 milu kernel: sky2 0000:03:00.0: eth0: Link is up at 1000 Mbps, full duplex, flow control both
Nov 20 21:37:13 milu kernel: sky2 0000:03:00.0: eth0: tx timeout
Nov 20 21:37:13 milu kernel: sky2 0000:03:00.0: eth0: transmit ring 37 .. 15 report=37 done=37
Nov 20 21:37:16 milu kernel: sky2 0000:03:00.0: eth0: Link is up at 1000 Mbps, full duplex, flow control both
Any suggestion ? As I said its home machine so I can test what you want :-).
best regards,
--
Milan Kocian
^ permalink raw reply
* Re: [rfc 00/18] slub: irqless/lockless slow allocation paths
From: David Rientjes @ 2011-11-20 23:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Christoph Lameter, David Miller, Pekka Enberg, Andi Kleen, tj,
Metathronius Galabant, Matt Mackall, Adrian Drzewiecki,
Shaohua Li, Alex Shi, linux-mm, netdev
In-Reply-To: <1321465534.4182.37.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Wed, 16 Nov 2011, Eric Dumazet wrote:
> > Adding SLUB_STATS gives :
> >
> > $ cd /sys/kernel/slab/skbuff_head_cache ; grep . *
> > aliases:6
> > align:8
> > grep: alloc_calls: Function not implemented
> > alloc_fastpath:89181782 C0=89173048 C1=1599 C2=1357 C3=2140 C4=802 C5=675 C6=638 C7=1523
> > alloc_from_partial:412658 C0=412658
> > alloc_node_mismatch:0
> > alloc_refill:593417 C0=593189 C1=19 C2=15 C3=24 C4=51 C5=18 C6=17 C7=84
> > alloc_slab:2831313 C0=2831285 C1=2 C2=2 C3=2 C4=2 C5=12 C6=4 C7=4
> > alloc_slowpath:4430371 C0=4430112 C1=20 C2=17 C3=25 C4=57 C5=31 C6=21 C7=88
> > cache_dma:0
> > cmpxchg_double_cpu_fail:0
> > cmpxchg_double_fail:1 C0=1
> > cpu_partial:30
> > cpu_partial_alloc:592991 C0=592981 C2=1 C4=5 C5=2 C6=1 C7=1
> > cpu_partial_free:4429836 C0=592981 C1=25 C2=19 C3=23 C4=3836767 C5=6 C6=8 C7=7
> > cpuslab_flush:0
> > cpu_slabs:107
> > deactivate_bypass:3836954 C0=3836923 C1=1 C2=2 C3=1 C4=6 C5=13 C6=4 C7=4
> > deactivate_empty:2831168 C4=2831168
> > deactivate_full:0
> > deactivate_remote_frees:0
> > deactivate_to_head:0
> > deactivate_to_tail:0
> > destroy_by_rcu:0
> > free_add_partial:0
> > grep: free_calls: Function not implemented
> > free_fastpath:21192924 C0=21186268 C1=1420 C2=1204 C3=1966 C4=572 C5=349 C6=380 C7=765
> > free_frozen:67988498 C0=516 C1=121 C2=85 C3=841 C4=67986468 C5=215 C6=76 C7=176
> > free_remove_partial:18 C4=18
> > free_slab:2831186 C4=2831186
> > free_slowpath:71825749 C0=609 C1=146 C2=104 C3=864 C4=71823538 C5=221 C6=84 C7=183
> > hwcache_align:0
> > min_partial:5
> > objects:2494
> > object_size:192
> > objects_partial:121
> > objs_per_slab:21
> > order:0
> > order_fallback:0
> > partial:14
> > poison:0
> > reclaim_account:0
> > red_zone:0
> > reserved:0
> > sanity_checks:0
> > slabs:127
> > slabs_cpu_partial:99(99) C1=25(25) C2=18(18) C3=23(23) C4=16(16) C5=4(4) C6=7(7) C7=6(6)
> > slab_size:192
> > store_user:0
> > total_objects:2667
> > trace:0
> >
>
> And the SLUB stats for the 2048 bytes slab is even worse : About every
> alloc/free is slow path
>
> $ cd /sys/kernel/slab/:t-0002048 ; grep . *
> aliases:0
> align:8
> grep: alloc_calls: Function not implemented
> alloc_fastpath:8199220 C0=8196915 C1=306 C2=63 C3=297 C4=319 C5=550
> C6=722 C7=48
> alloc_from_partial:13931406 C0=13931401 C3=1 C5=4
> alloc_node_mismatch:0
> alloc_refill:70871657 C0=70871629 C1=2 C3=3 C4=9 C5=11 C6=3
> alloc_slab:1335 C0=1216 C1=17 C2=2 C3=15 C4=17 C5=22 C6=44 C7=2
> alloc_slowpath:155455299 C0=155455144 C1=18 C2=1 C3=21 C4=27 C5=40 C6=47
> C7=1
I certainly sympathize with your situation; these stats are even worse
with netperf TCP_RR where slub regresses very heavily against slab.
--
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 for 2.6.32 (untested)] netns: Add quota for number of NET_NS instances.
From: Eric W. Biederman @ 2011-11-20 23:13 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: netdev
In-Reply-To: <201111201622.FDJ51567.VLFHQFMFOOSOtJ@I-love.SAKURA.ne.jp>
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:
> In order to solve below problems, can we add sysctl variable for
> restricting number of NET_NS instances?
I don't have any particular problems with patch but I don't think it
will result in a working system that is easy to keep working. Tuning
static limits can be fickle.
Simply throttling the number of processes as anything reasonable will do
should keep the problem in check. The practical issue is that we have
a huge build of network namespaces that don't get cleaned up.
My inclination in this case the practical fix is that during network
namespace allocation someone take a look at the cleanup_list. See
that there is ongoing cleanup activity, and wait until at least one
network namespace has cleaned up. Perhaps by creating a work struct
and waiting for it to cycle through the netns workqueue.
That should throttle network namespace creation to the same speed as
network namespace deletion and prevent the problem of too many
dead network namespaces building up and taking resources.
Eric
> --------------------------------------------------
> [PATCH for 2.6.32 (untested)] netns: Add quota for number of NET_NS instances.
>
> CONFIG_NET_NS support in 2.6.32 has a problem that leads to OOM killer when
> clone(CLONE_NEWNET) is called instantly.
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/720095
> But disabling CONFIG_NET_NS broke lxc containers.
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/790863
>
> This patch introduces /proc/sys/net/core/netns_max interface that limits
> max number of network namespace instances.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> include/net/sock.h | 4 ++++
> net/core/net_namespace.c | 9 +++++++++
> net/core/sysctl_net_core.c | 10 ++++++++++
> 3 files changed, 23 insertions(+)
>
> --- linux-2.6.32.48.orig/include/net/sock.h
> +++ linux-2.6.32.48/include/net/sock.h
> @@ -1598,4 +1598,8 @@ extern int sysctl_optmem_max;
> extern __u32 sysctl_wmem_default;
> extern __u32 sysctl_rmem_default;
>
> +#ifdef CONFIG_NET_NS
> +extern int max_netns_count;
> +#endif
> +
> #endif /* _SOCK_H */
> --- linux-2.6.32.48.orig/net/core/net_namespace.c
> +++ linux-2.6.32.48/net/core/net_namespace.c
> @@ -81,12 +81,18 @@ static struct net_generic *net_alloc_gen
> #ifdef CONFIG_NET_NS
> static struct kmem_cache *net_cachep;
> static struct workqueue_struct *netns_wq;
> +static atomic_t used_netns_count = ATOMIC_INIT(0);
> +unsigned int max_netns_count;
>
> static struct net *net_alloc(void)
> {
> struct net *net = NULL;
> struct net_generic *ng;
>
> + atomic_inc(&used_netns_count);
> + if (atomic_read(&used_netns_count) > max_netns_count)
> + goto out;
> +
> ng = net_alloc_generic();
> if (!ng)
> goto out;
> @@ -96,7 +102,9 @@ static struct net *net_alloc(void)
> goto out_free;
>
> rcu_assign_pointer(net->gen, ng);
> + return net;
> out:
> + atomic_dec(&used_netns_count);
> return net;
>
> out_free:
> @@ -115,6 +123,7 @@ static void net_free(struct net *net)
> #endif
> kfree(net->gen);
> kmem_cache_free(net_cachep, net);
> + atomic_dec(&used_netns_count);
> }
>
> static struct net *net_create(void)
> --- linux-2.6.32.48.orig/net/core/sysctl_net_core.c
> +++ linux-2.6.32.48/net/core/sysctl_net_core.c
> @@ -89,6 +89,16 @@ static struct ctl_table net_core_table[]
> .mode = 0644,
> .proc_handler = proc_dointvec
> },
> +#ifdef CONFIG_NET_NS
> + {
> + .ctl_name = CTL_UNNUMBERED,
> + .procname = "netns_max",
> + .data = &max_netns_count,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> + },
> +#endif
> #endif /* CONFIG_NET */
> {
> .ctl_name = NET_CORE_BUDGET,
^ permalink raw reply
* [PATCH net-next] tg3: Fix advertisement handling
From: Hiroaki SHIMODA @ 2011-11-20 23:07 UTC (permalink / raw)
To: davem, mcarlson, mchan; +Cc: netdev
Commit 28011cf19b (net: Add ethtool to mii advertisment conversion
helpers) added a helper function ethtool_adv_to_mii_100bt() and
tg3_copper_is_advertising_all(), tg3_phy_autoneg_cfg() were
modified to use this.
Before that commit, ethtool to mii advertisement conversion was
done wrt speed, but now pause operation is also taken account.
So, in tg3_copper_is_advertising_all(), below condition becomes
true and this makes link up fails.
if ((adv_reg & ADVERTISE_ALL) != all_mask)
return 0;
To fix this add ADVERTISE_ALL bit and operation to cap speed.
Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
---
drivers/net/ethernet/broadcom/tg3.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 024ca1d..c00e648 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -3594,7 +3594,7 @@ static int tg3_phy_autoneg_cfg(struct tg3 *tp, u32 advertise, u32 flowctrl)
u32 val, new_adv;
new_adv = ADVERTISE_CSMA;
- new_adv |= ethtool_adv_to_mii_100bt(advertise);
+ new_adv |= ethtool_adv_to_mii_100bt(advertise) & ADVERTISE_ALL;
new_adv |= tg3_advert_flowctrl_1000T(flowctrl);
err = tg3_writephy(tp, MII_ADVERTISE, new_adv);
@@ -3783,7 +3783,7 @@ static int tg3_copper_is_advertising_all(struct tg3 *tp, u32 mask)
if (tg3_readphy(tp, MII_ADVERTISE, &adv_reg))
return 0;
- if ((adv_reg & ADVERTISE_ALL) != all_mask)
+ if ((adv_reg & ADVERTISE_ALL) != (all_mask & ADVERTISE_ALL))
return 0;
if (!(tp->phy_flags & TG3_PHYFLG_10_100_ONLY)) {
^ permalink raw reply related
* MPLS for Linux kernel
From: Igor Maravić @ 2011-11-20 21:59 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Hi all,
I've been working on implementation of MPLS for Linux kernel, for a
some time now.
I continued the work of James Leu
(https://sourceforge.net/projects/mpls-linux/) and used some fixes of
Jorge Boncompte
(http://mpls-linux.git.sourceforge.net/git/gitweb.cgi?p=mpls-linux/net-next;a=shortlog;h=refs/heads/net-next-mpls).
I fixed a lot of bugs, so now it can be compiled and run with all
Kernel Hacking options enabled.
My code could be found on this sites:
https://github.com/i-maravic/MPLS-Linux
https://github.com/i-maravic/iproute2
Any feedback is appreciated :)
On Dave's blog I read that MPLS is one of the things that should be
implemented in to the Linux kernel.
What is the procedure to do that with this code?
BR
Igor Maravić
^ permalink raw reply
* Re: [PATCH V2] Add ethtool to mii advertisment conversion helpers
From: David Miller @ 2011-11-20 21:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: mcarlson, netdev, mchan
In-Reply-To: <1321823497.4984.4.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 20 Nov 2011 22:11:37 +0100
> For reference, the revert on tg3 :
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index 024ca1d..365cd47 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -3594,7 +3594,15 @@ static int tg3_phy_autoneg_cfg(struct tg3 *tp, u32 advertise, u32 flowctrl)
> u32 val, new_adv;
>
> new_adv = ADVERTISE_CSMA;
> - new_adv |= ethtool_adv_to_mii_100bt(advertise);
> + if (advertise & ADVERTISED_10baseT_Half)
> + new_adv |= ADVERTISE_10HALF;
> + if (advertise & ADVERTISED_10baseT_Full)
> + new_adv |= ADVERTISE_10FULL;
> + if (advertise & ADVERTISED_100baseT_Half)
> + new_adv |= ADVERTISE_100HALF;
> + if (advertise & ADVERTISED_100baseT_Full)
> + new_adv |= ADVERTISE_100FULL;
> +
> new_adv |= tg3_advert_flowctrl_1000T(flowctrl);
>
Well, for one thing the flow control handling is subtly changed here.
ethtool_adv_to_mii_100bt() does it's own setting of the flow control
advertisement bits. It sets ADVERTISE_PAUSE_CAP and
ADVERTISE_PAUSE_ASYM.
But here in tg3, tg3_advert_flowctrl_1000T() has it's own seperate
logic for setting those bits.
I cannot say for certain that this is what it causing your problems,
but it is clear now that these transformations were not done carefully
enough.
^ permalink raw reply
* Firmware errors and warnings with Centrino Advanced-N 6205
From: Udo Steinberg @ 2011-11-20 20:50 UTC (permalink / raw)
To: linux-wireless, netdev
[-- Attachment #1: Type: text/plain, Size: 20689 bytes --]
Hi,
I'm repeatedly getting firmware errors and warnings on my Centrino 6205 WiFi
card with Linux 3.1. These warnings keep filling the logs at a rate that is
not funny. Any idea how to fix this issue or at least rate-limit those
messages?
Cheers,
- Udo
Excerpt from syslog:
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Microcode SW error detected. Restarting 0x82000000.
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Loaded firmware version: 17.168.5.3 build 42301
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Start IWL Error Log Dump:
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Status: 0x000512E4, count: 6
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00002078 | ADVANCED_SYSASSERT
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00009514 | uPc
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink1
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink2
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x0000D1F2 | interruptlink1
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000000 | interruptlink2
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x01008035 | data1
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x0000C90F | data2
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x000005A7 | line
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x5080B520 | beacon time
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0xCC515AE0 | tsf low
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000003 | tsf hi
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp1
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x29703BF0 | time gp2
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp3
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x000111A8 | uCode version
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x000000B0 | hw version
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00480303 | board version
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x09E8004E | hcmd
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR values:
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_HW_IF_CONFIG_REG: 0X00480303
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_INT_COALESCING: 0X0000ff40
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_INT: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_INT_MASK: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_FH_INT_STATUS: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GPIO_IN: 0X00000030
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_RESET: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GP_CNTRL: 0X080403c5
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_HW_REV: 0X000000b0
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_EEPROM_REG: 0X07d60ffd
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_EEPROM_GP: 0X90000001
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_OTP_GP_REG: 0X00030001
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GIO_REG: 0X00080044
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GP_UCODE_REG: 0X000093bb
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GP_DRIVER_REG: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP1: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP2: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_LED_REG: 0X00000078
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_DRAM_INT_TBL_REG: 0X88214dd2
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_ANA_PLL_CFG: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_HW_REV_WA_REG: 0X0001001a
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_DBG_HPET_MEM_REG: 0Xffff0010
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH register values:
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21316d00
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X021479c0
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_WPTR: 0X00000060
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_TSSR_TX_STATUS_REG: 0X07ff0001
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_TSSR_TX_ERROR_REG: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695219435:0x028a001c:0217
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221022:0x028b001c:0206
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221023:0x00000001:0204
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221026:0x00000001:0214
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221027:0x01001110:0205
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221051:0x00000020:0208
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221070:0x00000000:0302
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221104:0x00000001:0203
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221109:0x028b001c:0206
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221110:0x00000040:0204
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221113:0x01000110:0211
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221117:0x00000000:0212
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221159:0x00000000:0215
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221162:0x00000008:0220
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221179:0x00000000:0302
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221211:0x000000d4:0303
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221215:0x0000128c:0217
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221215:0x028b001c:0217
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221224:0x09e8004e:0401
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221234:0x00000000:0125
Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Error sending REPLY_ADD_STA: time out after 2000ms.
Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Adding station 00:24:fe:41:8d:0e failed.
Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Unable to add station 00:24:fe:41:8d:0e (-110)
Nov 20 20:47:42 x220 kernel: ------------[ cut here ]------------
Nov 20 20:47:42 x220 kernel: WARNING: at net/mac80211/util.c:1208 ieee80211_reconfig+0x1f1/0x407()
Nov 20 20:47:42 x220 kernel: Hardware name: 4290W4H
Nov 20 20:47:42 x220 kernel: Pid: 1896, comm: kworker/0:0 Not tainted 3.1.0 #2
Nov 20 20:47:42 x220 kernel: Call Trace:
Nov 20 20:47:42 x220 kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
Nov 20 20:47:42 x220 kernel: [<ffffffff813b8966>] ? ieee80211_reconfig+0x1f1/0x407
Nov 20 20:47:42 x220 kernel: [<ffffffff8139e8dc>] ? ieee80211_recalc_smps_work+0x32/0x32
Nov 20 20:47:42 x220 kernel: [<ffffffff8139e95a>] ? ieee80211_restart_work+0x7e/0x87
Nov 20 20:47:42 x220 kernel: [<ffffffff810472fa>] ? process_one_work+0x1c8/0x2e3
Nov 20 20:47:42 x220 kernel: [<ffffffff810480c9>] ? worker_thread+0x17a/0x23a
Nov 20 20:47:42 x220 kernel: [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
Nov 20 20:47:42 x220 kernel: [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba97>] ? kthread+0x7a/0x82
Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b0>] ? gs_change+0xb/0xb
Nov 20 20:47:42 x220 kernel: ---[ end trace c69a09b105aa81ab ]---
Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Invalid station for AGG tid 0
Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Attempting to modify non-existing station 0
Nov 20 20:47:42 x220 kernel: ------------[ cut here ]------------
Nov 20 20:47:42 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
Nov 20 20:47:42 x220 kernel: Hardware name: 4290W4H
Nov 20 20:47:42 x220 kernel: Pid: 3, comm: ksoftirqd/0 Tainted: G W 3.1.0 #2
Nov 20 20:47:42 x220 kernel: Call Trace:
Nov 20 20:47:42 x220 kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
Nov 20 20:47:42 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
Nov 20 20:47:42 x220 kernel: [<ffffffff8102adde>] ? update_curr+0x77/0xd0
Nov 20 20:47:42 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
Nov 20 20:47:42 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
Nov 20 20:47:42 x220 kernel: [<ffffffff813b5f55>] ? ieee80211_tx_pending+0x14b/0x20a
Nov 20 20:47:42 x220 kernel: [<ffffffff8103ab0a>] ? tasklet_action+0x67/0xa7
Nov 20 20:47:42 x220 kernel: [<ffffffff8103ae64>] ? __do_softirq+0x7f/0x106
Nov 20 20:47:42 x220 kernel: [<ffffffff8103af96>] ? run_ksoftirqd+0xab/0x193
Nov 20 20:47:42 x220 kernel: [<ffffffff8103aeeb>] ? __do_softirq+0x106/0x106
Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba97>] ? kthread+0x7a/0x82
Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b0>] ? gs_change+0xb/0xb
Nov 20 20:47:42 x220 kernel: ---[ end trace c69a09b105aa81ac ]---
Nov 20 20:47:43 x220 kernel: ------------[ cut here ]------------
Nov 20 20:47:43 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
Nov 20 20:47:43 x220 kernel: Hardware name: 4290W4H
Nov 20 20:47:43 x220 kernel: Pid: 1902, comm: firefox Tainted: G W 3.1.0 #2
Nov 20 20:47:43 x220 kernel: Call Trace:
Nov 20 20:47:43 x220 kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
Nov 20 20:47:43 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
Nov 20 20:47:43 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
Nov 20 20:47:43 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
Nov 20 20:47:43 x220 kernel: [<ffffffff813b54ba>] ? ieee80211_tx+0x95/0xad
Nov 20 20:47:43 x220 kernel: [<ffffffff813b5618>] ? ieee80211_xmit+0x146/0x159
Nov 20 20:47:43 x220 kernel: [<ffffffff813b5dbb>] ? ieee80211_subif_start_xmit+0x5b8/0x5d5
Nov 20 20:47:43 x220 kernel: [<ffffffff81330ef8>] ? dev_hard_start_xmit+0x3f2/0x4f0
Nov 20 20:47:43 x220 kernel: [<ffffffff81342978>] ? sch_direct_xmit+0x67/0x18d
Nov 20 20:47:43 x220 kernel: [<ffffffff813313b5>] ? dev_queue_xmit+0x2fe/0x4fc
Nov 20 20:47:43 x220 kernel: [<ffffffff8134f3b4>] ? ip_finish_output+0x216/0x267
Nov 20 20:47:43 x220 kernel: [<ffffffff8134ea04>] ? ip_queue_xmit+0x2c8/0x304
Nov 20 20:47:43 x220 kernel: [<ffffffff81051ff1>] ? getnstimeofday+0x54/0xa5
Nov 20 20:47:43 x220 kernel: [<ffffffff8136014b>] ? tcp_transmit_skb+0x6b4/0x6f4
Nov 20 20:47:43 x220 kernel: [<ffffffff813609d3>] ? tcp_write_xmit+0x7c8/0x8b0
Nov 20 20:47:43 x220 kernel: [<ffffffff81328188>] ? __alloc_skb+0x5f/0x114
Nov 20 20:47:43 x220 kernel: [<ffffffff81360b04>] ? __tcp_push_pending_frames+0x18/0x73
Nov 20 20:47:43 x220 kernel: [<ffffffff81356ab0>] ? tcp_close+0x157/0x390
Nov 20 20:47:43 x220 kernel: [<ffffffff81370c00>] ? inet_release+0x77/0x80
Nov 20 20:47:43 x220 kernel: [<ffffffff81322d65>] ? sock_release+0x10/0x54
Nov 20 20:47:43 x220 kernel: [<ffffffff81322dcb>] ? sock_close+0x22/0x29
Nov 20 20:47:43 x220 kernel: [<ffffffff810a89cf>] ? fput+0xea/0x194
Nov 20 20:47:43 x220 kernel: [<ffffffff810a6d0f>] ? filp_close+0x62/0x6a
Nov 20 20:47:43 x220 kernel: [<ffffffff810a6da8>] ? sys_close+0x91/0xd5
Nov 20 20:47:43 x220 kernel: [<ffffffff813d0e3b>] ? system_call_fastpath+0x16/0x1b
Nov 20 20:47:43 x220 kernel: ---[ end trace c69a09b105aa81ad ]---
Nov 20 20:47:43 x220 kernel: ------------[ cut here ]------------
Nov 20 20:47:43 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
Nov 20 20:47:43 x220 kernel: Hardware name: 4290W4H
Nov 20 20:47:43 x220 kernel: Pid: 0, comm: swapper Tainted: G W 3.1.0 #2
Nov 20 20:47:43 x220 kernel: Call Trace:
Nov 20 20:47:43 x220 kernel: <IRQ> [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
Nov 20 20:47:43 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
Nov 20 20:47:43 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
Nov 20 20:47:43 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
Nov 20 20:47:43 x220 kernel: [<ffffffff813b54ba>] ? ieee80211_tx+0x95/0xad
Nov 20 20:47:43 x220 kernel: [<ffffffff813b5618>] ? ieee80211_xmit+0x146/0x159
Nov 20 20:47:43 x220 kernel: [<ffffffff813b5dbb>] ? ieee80211_subif_start_xmit+0x5b8/0x5d5
Nov 20 20:47:43 x220 kernel: [<ffffffff81330ef8>] ? dev_hard_start_xmit+0x3f2/0x4f0
Nov 20 20:47:43 x220 kernel: [<ffffffff81342978>] ? sch_direct_xmit+0x67/0x18d
Nov 20 20:47:43 x220 kernel: [<ffffffff813313b5>] ? dev_queue_xmit+0x2fe/0x4fc
Nov 20 20:47:43 x220 kernel: [<ffffffff8102adde>] ? update_curr+0x77/0xd0
Nov 20 20:47:43 x220 kernel: [<ffffffff8134f3b4>] ? ip_finish_output+0x216/0x267
Nov 20 20:47:43 x220 kernel: [<ffffffff8134ea04>] ? ip_queue_xmit+0x2c8/0x304
Nov 20 20:47:43 x220 kernel: [<ffffffff81051ff1>] ? getnstimeofday+0x54/0xa5
Nov 20 20:47:43 x220 kernel: [<ffffffff8136014b>] ? tcp_transmit_skb+0x6b4/0x6f4
Nov 20 20:47:43 x220 kernel: [<ffffffff8135a3f9>] ? tcp_fin.clone.31+0x5c/0x18f
Nov 20 20:47:43 x220 kernel: [<ffffffff8135a94e>] ? tcp_data_queue+0x2de/0xb46
Nov 20 20:47:43 x220 kernel: [<ffffffff8135dca3>] ? tcp_validate_incoming+0x1bb/0x28b
Nov 20 20:47:43 x220 kernel: [<ffffffff8135ec3b>] ? tcp_rcv_state_process+0x8f5/0x96e
Nov 20 20:47:43 x220 kernel: [<ffffffff81363d0d>] ? tcp_v4_do_rcv+0x240/0x284
Nov 20 20:47:43 x220 kernel: [<ffffffff8133f9f4>] ? sk_filter+0x6d/0x78
Nov 20 20:47:43 x220 kernel: [<ffffffff81365aa1>] ? tcp_v4_rcv+0x416/0x65e
Nov 20 20:47:43 x220 kernel: [<ffffffff8134b6b0>] ? ip_local_deliver+0xa5/0xfe
Nov 20 20:47:43 x220 kernel: [<ffffffff8132ee96>] ? __netif_receive_skb+0x279/0x2af
Nov 20 20:47:43 x220 kernel: [<ffffffff810b3a0a>] ? send_sigio_to_task+0xf6/0x108
Nov 20 20:47:43 x220 kernel: [<ffffffff81331f3c>] ? netif_receive_skb+0x7e/0x84
Nov 20 20:47:43 x220 kernel: [<ffffffff8104033b>] ? mod_timer+0x189/0x1a1
Nov 20 20:47:43 x220 kernel: [<ffffffff813b1201>] ? ieee80211_deliver_skb+0xc3/0x104
Nov 20 20:47:43 x220 kernel: [<ffffffff813b20c8>] ? ieee80211_rx_handlers+0xe86/0x17e2
Nov 20 20:47:43 x220 kernel: [<ffffffff810b42fd>] ? send_sigio+0x91/0xa7
Nov 20 20:47:43 x220 kernel: [<ffffffff8102f3b6>] ? __wake_up+0x35/0x46
Nov 20 20:47:43 x220 kernel: [<ffffffff813b30d5>] ? ieee80211_prepare_and_rx_handle+0x6b1/0x734
Nov 20 20:47:43 x220 kernel: [<ffffffff813b39f8>] ? ieee80211_rx+0x735/0x7ac
Nov 20 20:47:43 x220 kernel: [<ffffffff81285f46>] ? iwl_rx_reply_rx+0x467/0x47e
Nov 20 20:47:43 x220 kernel: [<ffffffff813a021b>] ? ieee80211_tx_status+0x72d/0x73f
Nov 20 20:47:43 x220 kernel: [<ffffffff8128c444>] ? iwl_irq_tasklet+0x402/0x675
Nov 20 20:47:43 x220 kernel: [<ffffffff8103ab0a>] ? tasklet_action+0x67/0xa7
Nov 20 20:47:43 x220 kernel: [<ffffffff8103ae64>] ? __do_softirq+0x7f/0x106
Nov 20 20:47:43 x220 kernel: [<ffffffff813d22ac>] ? call_softirq+0x1c/0x26
Nov 20 20:47:43 x220 kernel: [<ffffffff810033fe>] ? do_softirq+0x31/0x67
Nov 20 20:47:43 x220 kernel: [<ffffffff8103b118>] ? irq_exit+0x44/0xb0
Nov 20 20:47:43 x220 kernel: [<ffffffff8100313f>] ? do_IRQ+0x94/0xad
Nov 20 20:47:43 x220 kernel: [<ffffffff813d07eb>] ? common_interrupt+0x6b/0x6b
Nov 20 20:47:43 x220 kernel: <EOI> [<ffffffff8104f02c>] ? __hrtimer_start_range_ns+0x2c6/0x2d9
Nov 20 20:47:43 x220 kernel: [<ffffffff8118a94a>] ? intel_idle+0xcd/0xe9
Nov 20 20:47:43 x220 kernel: [<ffffffff8118a926>] ? intel_idle+0xa9/0xe9
Nov 20 20:47:43 x220 kernel: [<ffffffff812dca4d>] ? cpuidle_idle_call+0xa0/0xdb
Nov 20 20:47:43 x220 kernel: [<ffffffff81000699>] ? cpu_idle+0x53/0x7c
Nov 20 20:47:43 x220 kernel: [<ffffffff816879fa>] ? start_kernel+0x2be/0x2c9
Nov 20 20:47:43 x220 kernel: ---[ end trace c69a09b105aa81ae ]---
Nov 20 20:47:43 x220 kernel: ------------[ cut here ]------------
Nov 20 20:47:43 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
Nov 20 20:47:43 x220 kernel: Hardware name: 4290W4H
Nov 20 20:47:43 x220 kernel: Pid: 0, comm: swapper Tainted: G W 3.1.0 #2
Nov 20 20:47:43 x220 kernel: Call Trace:
Nov 20 20:47:43 x220 kernel: <IRQ> [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
Nov 20 20:47:43 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
Nov 20 20:47:43 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
Nov 20 20:47:43 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
Nov 20 20:47:43 x220 kernel: [<ffffffff813b54ba>] ? ieee80211_tx+0x95/0xad
Nov 20 20:47:43 x220 kernel: [<ffffffff813b5618>] ? ieee80211_xmit+0x146/0x159
Nov 20 20:47:43 x220 kernel: [<ffffffff813b5dbb>] ? ieee80211_subif_start_xmit+0x5b8/0x5d5
Nov 20 20:47:43 x220 kernel: [<ffffffff81330ef8>] ? dev_hard_start_xmit+0x3f2/0x4f0
Nov 20 20:47:43 x220 kernel: [<ffffffff81048223>] ? queue_work_on+0x16/0x20
Nov 20 20:47:43 x220 kernel: [<ffffffff81048274>] ? queue_work+0x47/0x52
Nov 20 20:47:43 x220 kernel: [<ffffffff81342978>] ? sch_direct_xmit+0x67/0x18d
Nov 20 20:47:43 x220 kernel: [<ffffffff810b42fd>] ? send_sigio+0x91/0xa7
Nov 20 20:47:43 x220 kernel: [<ffffffff813313b5>] ? dev_queue_xmit+0x2fe/0x4fc
Nov 20 20:47:43 x220 kernel: [<ffffffff8107a785>] ? free_one_page+0x24e/0x264
Nov 20 20:47:43 x220 kernel: [<ffffffff8134f3b4>] ? ip_finish_output+0x216/0x267
Nov 20 20:47:43 x220 kernel: [<ffffffff8134ea04>] ? ip_queue_xmit+0x2c8/0x304
Nov 20 20:47:43 x220 kernel: [<ffffffff81051ff1>] ? getnstimeofday+0x54/0xa5
Nov 20 20:47:43 x220 kernel: [<ffffffff8136014b>] ? tcp_transmit_skb+0x6b4/0x6f4
Nov 20 20:47:43 x220 kernel: [<ffffffff81360f7b>] ? tcp_retransmit_skb+0x41c/0x505
Nov 20 20:47:43 x220 kernel: [<ffffffff81285f46>] ? iwl_rx_reply_rx+0x467/0x47e
Nov 20 20:47:43 x220 kernel: [<ffffffff81362ca0>] ? tcp_retransmit_timer+0x4f8/0x4f8
Nov 20 20:47:43 x220 kernel: [<ffffffff81362b02>] ? tcp_retransmit_timer+0x35a/0x4f8
Nov 20 20:47:43 x220 kernel: [<ffffffff81362d3b>] ? tcp_write_timer+0x9b/0x18d
Nov 20 20:47:43 x220 kernel: [<ffffffff8103fe83>] ? run_timer_softirq+0x19b/0x230
Nov 20 20:47:43 x220 kernel: [<ffffffff8103ae64>] ? __do_softirq+0x7f/0x106
Nov 20 20:47:43 x220 kernel: [<ffffffff813d22ac>] ? call_softirq+0x1c/0x26
Nov 20 20:47:43 x220 kernel: [<ffffffff810033fe>] ? do_softirq+0x31/0x67
Nov 20 20:47:43 x220 kernel: [<ffffffff8103b118>] ? irq_exit+0x44/0xb0
Nov 20 20:47:43 x220 kernel: [<ffffffff81014a09>] ? smp_apic_timer_interrupt+0x85/0x95
Nov 20 20:47:43 x220 kernel: [<ffffffff813d184b>] ? apic_timer_interrupt+0x6b/0x70
Nov 20 20:47:43 x220 kernel: <EOI> [<ffffffff8118a94a>] ? intel_idle+0xcd/0xe9
Nov 20 20:47:43 x220 kernel: [<ffffffff8118a926>] ? intel_idle+0xa9/0xe9
Nov 20 20:47:43 x220 kernel: [<ffffffff812dca4d>] ? cpuidle_idle_call+0xa0/0xdb
Nov 20 20:47:43 x220 kernel: [<ffffffff81000699>] ? cpu_idle+0x53/0x7c
Nov 20 20:47:43 x220 kernel: [<ffffffff816879fa>] ? start_kernel+0x2be/0x2c9
Nov 20 20:47:43 x220 kernel: ---[ end trace c69a09b105aa81af ]---
... and it goes on and on
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH V2] Add ethtool to mii advertisment conversion helpers
From: Eric Dumazet @ 2011-11-20 21:11 UTC (permalink / raw)
To: David Miller; +Cc: mcarlson, netdev, mchan
In-Reply-To: <20111116.184032.1176336205445892405.davem@davemloft.net>
Le mercredi 16 novembre 2011 à 18:40 -0500, David Miller a écrit :
> From: "Matt Carlson" <mcarlson@broadcom.com>
> Date: Wed, 16 Nov 2011 15:27:37 -0800
>
> > Translating between ethtool advertisement settings and MII
> > advertisements are common operations for ethernet drivers. This patch
> > adds a set of helper functions that implements the conversion. The
> > patch then modifies a couple of the drivers to use the new functions.
> >
> > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > Signed-off-by: Michael Chan <mchan@broadcom.com>
>
> Looks better, applied, thanks :)
For an unknown reason I had to revert this commit to make my tg3 working
again on my laptop connected with a cross cable to one IGB NIC.
Before my revert, link was constantly flapping
(Should be running at 1000Mbps, full duplex)
09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5755M Gigabit Ethernet PCI Express (rev 02)
Subsystem: Dell Device 01f9
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 45
Region 0: Memory at f1ef0000 (64-bit, non-prefetchable) [size=64K]
Expansion ROM at <ignored> [disabled]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data
Product Name: Broadcom NetXtreme Gigabit Ethernet Controller
Read-only fields:
[PN] Part number: BCM95755m
[EC] Engineering changes: 01f9.004
[SN] Serial number: 0123456789
[MN] Manufacture ID: 31 34 65 34
[RV] Reserved: checksum good, 28 byte(s) reserved
Read/write fields:
[YA] Asset tag: XYZ01234567
[RW] Read-write area: 107 byte(s) free
End
Capabilities: [58] Vendor Specific Information: Len=78 <?>
Capabilities: [e8] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 41b1
Capabilities: [d0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO+ CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP+ BadDLLP+ Rollover- Timeout+ NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 0e, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [13c v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-21-70-ff-fe-b0-e4-89
Capabilities: [16c v1] Power Budgeting <?>
Kernel driver in use: tg3
Kernel modules: tg3
For reference, the revert on tg3 :
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 024ca1d..365cd47 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -3594,7 +3594,15 @@ static int tg3_phy_autoneg_cfg(struct tg3 *tp, u32 advertise, u32 flowctrl)
u32 val, new_adv;
new_adv = ADVERTISE_CSMA;
- new_adv |= ethtool_adv_to_mii_100bt(advertise);
+ if (advertise & ADVERTISED_10baseT_Half)
+ new_adv |= ADVERTISE_10HALF;
+ if (advertise & ADVERTISED_10baseT_Full)
+ new_adv |= ADVERTISE_10FULL;
+ if (advertise & ADVERTISED_100baseT_Half)
+ new_adv |= ADVERTISE_100HALF;
+ if (advertise & ADVERTISED_100baseT_Full)
+ new_adv |= ADVERTISE_100FULL;
+
new_adv |= tg3_advert_flowctrl_1000T(flowctrl);
err = tg3_writephy(tp, MII_ADVERTISE, new_adv);
@@ -3604,7 +3612,11 @@ static int tg3_phy_autoneg_cfg(struct tg3 *tp, u32 advertise, u32 flowctrl)
if (tp->phy_flags & TG3_PHYFLG_10_100_ONLY)
goto done;
- new_adv = ethtool_adv_to_mii_1000T(advertise);
+ new_adv = 0;
+ if (advertise & ADVERTISED_1000baseT_Half)
+ new_adv |= ADVERTISE_1000HALF;
+ if (advertise & ADVERTISED_1000baseT_Full)
+ new_adv |= ADVERTISE_1000FULL;
if (tp->pci_chip_rev_id == CHIPREV_ID_5701_A0 ||
tp->pci_chip_rev_id == CHIPREV_ID_5701_B0)
@@ -3778,7 +3790,14 @@ static int tg3_copper_is_advertising_all(struct tg3 *tp, u32 mask)
{
u32 adv_reg, all_mask = 0;
- all_mask = ethtool_adv_to_mii_100bt(mask);
+ if (mask & ADVERTISED_10baseT_Half)
+ all_mask |= ADVERTISE_10HALF;
+ if (mask & ADVERTISED_10baseT_Full)
+ all_mask |= ADVERTISE_10FULL;
+ if (mask & ADVERTISED_100baseT_Half)
+ all_mask |= ADVERTISE_100HALF;
+ if (mask & ADVERTISED_100baseT_Full)
+ all_mask |= ADVERTISE_100FULL;
if (tg3_readphy(tp, MII_ADVERTISE, &adv_reg))
return 0;
@@ -3789,7 +3808,11 @@ static int tg3_copper_is_advertising_all(struct tg3 *tp, u32 mask)
if (!(tp->phy_flags & TG3_PHYFLG_10_100_ONLY)) {
u32 tg3_ctrl;
- all_mask = ethtool_adv_to_mii_1000T(mask);
+ all_mask = 0;
+ if (mask & ADVERTISED_1000baseT_Half)
+ all_mask |= ADVERTISE_1000HALF;
+ if (mask & ADVERTISED_1000baseT_Full)
+ all_mask |= ADVERTISE_1000FULL;
if (tg3_readphy(tp, MII_CTRL1000, &tg3_ctrl))
return 0;
@@ -4880,19 +4903,23 @@ static int tg3_setup_fiber_mii_phy(struct tg3 *tp, int force_reset)
(tp->phy_flags & TG3_PHYFLG_PARALLEL_DETECT)) {
/* do nothing, just check for link up at the end */
} else if (tp->link_config.autoneg == AUTONEG_ENABLE) {
- u32 adv, newadv;
+ u32 adv, new_adv;
err |= tg3_readphy(tp, MII_ADVERTISE, &adv);
- newadv = adv & ~(ADVERTISE_1000XFULL | ADVERTISE_1000XHALF |
- ADVERTISE_1000XPAUSE |
- ADVERTISE_1000XPSE_ASYM |
- ADVERTISE_SLCT);
+ new_adv = adv & ~(ADVERTISE_1000XFULL | ADVERTISE_1000XHALF |
+ ADVERTISE_1000XPAUSE |
+ ADVERTISE_1000XPSE_ASYM |
+ ADVERTISE_SLCT);
+
+ new_adv |= tg3_advert_flowctrl_1000X(tp->link_config.flowctrl);
- newadv |= tg3_advert_flowctrl_1000X(tp->link_config.flowctrl);
- newadv |= ethtool_adv_to_mii_1000X(tp->link_config.advertising);
+ if (tp->link_config.advertising & ADVERTISED_1000baseT_Half)
+ new_adv |= ADVERTISE_1000XHALF;
+ if (tp->link_config.advertising & ADVERTISED_1000baseT_Full)
+ new_adv |= ADVERTISE_1000XFULL;
- if ((newadv != adv) || !(bmcr & BMCR_ANENABLE)) {
- tg3_writephy(tp, MII_ADVERTISE, newadv);
+ if ((new_adv != adv) || !(bmcr & BMCR_ANENABLE)) {
+ tg3_writephy(tp, MII_ADVERTISE, new_adv);
bmcr |= BMCR_ANENABLE | BMCR_ANRESTART;
tg3_writephy(tp, MII_BMCR, bmcr);
^ permalink raw reply related
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