* nf_reject_ipv4: module license 'unspecified' taints kernel
From: Dave Young @ 2014-10-10 9:19 UTC (permalink / raw)
To: pablo; +Cc: davem, netdev, linux-kernel
Hi,
With today's linus tree, I got below kmsg:
[ 23.545204] nf_reject_ipv4: module license 'unspecified' taints kernel.
[ 23.551886] Disabling lock debugging due to kernel taint
[ 23.557302] nf_reject_ipv4: Unknown symbol lock_is_held (err 0)
[ 23.563256] nf_reject_ipv4: Unknown symbol rcu_read_lock_bh_held (err 0)
[ 23.569992] nf_reject_ipv4: Unknown symbol ip_local_out_sk (err 0)
[ 23.576206] nf_reject_ipv4: Unknown symbol debug_lockdep_rcu_enabled (err 0)
[ 23.583290] nf_reject_ipv4: Unknown symbol rcu_is_watching (err 0)
[ 23.589523] nf_reject_ipv4: Unknown symbol rcu_lock_map (err
It could be caused by below commit:
commit c8d7b98bec43faaa6583c3135030be5eb4693acb
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri Sep 26 14:35:15 2014 +0200
netfilter: move nf_send_resetX() code to nf_reject_ipvX modules
Move nf_send_reset() and nf_send_reset6() to nf_reject_ipv4 and
nf_reject_ipv6 respectively. This code is shared by x_tables and
nf_tables.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
I believe there's similar issue for ipv6 reject part though I have disabled ipv6
in my .config.
Let me know if you need any furthur information.
Thanks
Dave
^ permalink raw reply
* Re: Micrel KSZ8031 - phy link missing
From: Angelo Dureghello @ 2014-10-10 9:32 UTC (permalink / raw)
To: netdev, Bruno Thomsen
In-Reply-To: <915054555B5659448ACF8A70E114824D0163C79016@Exchange2010.kamstrup.dk>
Dear Bruno,
many thanks,
i still have the issue after patching kernel 3.17.
static int ksz8021_config_init(struct phy_device *phydev)
{
const u16 val = KSZPHY_OMSO_B_CAST_OFF | KSZPHY_OMSO_RMII_OVERRIDE;
int rc;
rc = kszphy_setup_led(phydev, 0x1f, 4);
if (rc)
dev_err(&phydev->dev, "failed to set led mode\n");
/*
* signalled no-link to linux-net community, followed
* see [PATCH] phy/micrel: KSZ8031RNL RMII clock
reconfiguration bug
*/
rc = ksz_config_flags(phydev);
if (rc < 0)
return rc;
rc = phy_write(phydev, MII_KSZPHY_OMSO, val);
return rc < 0 ? rc : 0;
}
I am using RMII in my custom board, don't know if it makes any difference.
Scanning device for bad blocks
Bad block table written to 0x000007fe0000, version 0x01
Bad block table written to 0x000007fc0000, version 0x01
8 cmdlinepart partitions found on MTD device davinci_nand.0
Creating 8 MTD partitions on "davinci_nand.0":
0x000000000000-0x000000020000 : "u-boot-env"
0x000000020000-0x000000180000 : "u-boot"
0x000000180000-0x0000001a0000 : "bootparms"
0x0000001a0000-0x000000200000 : "factory-info"
EMAC: device MAC address: 00:08:e1:03:2a:c5
GPIO LEDs: old hardware revision detected
0x000000200000-0x000000600000 : "kernel"
0x000000600000-0x000000700000 : "config"
0x000000700000-0x000004300000 : "rootfs"
0x000004300000-0x000007f00000 : "update"
davinci_nand davinci_nand.0: controller rev. 2.5
davinci_mdio davinci_mdio.0: Runtime PM disabled, clock forced on.
davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
davinci_mdio davinci_mdio.0: detected phy mask fffffffc
libphy: davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[0]: device davinci_mdio-0:00, driver
Micrel KSZ8031
davinci_mdio davinci_mdio.0: phy[1]: device davinci_mdio-0:01, driver
Micrel KSZ8031
omap_rtc da830-rtc: rtc core: registered da830-rtc as rtc0
......
Starting LED service: done
Setting time zone...
UTC
Time zone set
Starting network...
davinci_mdio davinci_mdio.0: resetting idled controller
net eth0: attached PHY driver [Micrel KSZ8031]
(mii_bus:phy_addr=davinci_mdio-0:00, id=221556)
udhcpc (v1.20.2) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
.....
Angelo
On 09/10/2014 17:05, Bruno Thomsen wrote:
> [PATCH] phy/micrel: KSZ8031RNL RMII clock reconfiguration bug
^ permalink raw reply
* RE: nf_reject_ipv4: module license 'unspecified' taints kernel
From: David Laight @ 2014-10-10 9:53 UTC (permalink / raw)
To: 'Dave Young', pablo@netfilter.org
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20141010091904.GD1981@darkstar.nay.redhat.com>
From: Dave Young
> With today's linus tree, I got below kmsg:
> [ 23.545204] nf_reject_ipv4: module license 'unspecified' taints kernel.
> [ 23.551886] Disabling lock debugging due to kernel taint
...
Not 100% related, but why does loading a non-GPL module disable
lock debugging?
(Is 'lock debugging' actually useful?)
David
^ permalink raw reply
* Re: nf_reject_ipv4: module license 'unspecified' taints kernel
From: Pablo Neira Ayuso @ 2014-10-10 9:56 UTC (permalink / raw)
To: Dave Young; +Cc: davem, netdev, linux-kernel, netfilter-devel
In-Reply-To: <20141010091904.GD1981@darkstar.nay.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
On Fri, Oct 10, 2014 at 05:19:04PM +0800, Dave Young wrote:
> Hi,
>
> With today's linus tree, I got below kmsg:
> [ 23.545204] nf_reject_ipv4: module license 'unspecified' taints kernel.
>
> It could be caused by below commit:
>
> commit c8d7b98bec43faaa6583c3135030be5eb4693acb
> Author: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Fri Sep 26 14:35:15 2014 +0200
>
> netfilter: move nf_send_resetX() code to nf_reject_ipvX modules
>
> Move nf_send_reset() and nf_send_reset6() to nf_reject_ipv4 and
> nf_reject_ipv6 respectively. This code is shared by x_tables and
> nf_tables.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Patch attached, thanks for reporting.
P.S: Please, Cc netfilter-devel@vger.kernel.org in future reports, so
we make sure things don't get lost.
[-- Attachment #2: 0001-netfilter-missing-module-license-in-the-nf_reject_ip.patch --]
[-- Type: text/x-diff, Size: 1710 bytes --]
>From d4358bcf64ba7a64d4de4e1dc5533c4c8f88ea82 Mon Sep 17 00:00:00 2001
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri, 10 Oct 2014 11:25:20 +0200
Subject: [PATCH] netfilter: missing module license in the nf_reject_ipvX
modules
[ 23.545204] nf_reject_ipv4: module license 'unspecified' taints kernel.
Reported-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/nf_reject_ipv4.c | 3 +++
net/ipv6/netfilter/nf_reject_ipv6.c | 4 ++++
2 files changed, 7 insertions(+)
diff --git a/net/ipv4/netfilter/nf_reject_ipv4.c b/net/ipv4/netfilter/nf_reject_ipv4.c
index b023b4e..92b303d 100644
--- a/net/ipv4/netfilter/nf_reject_ipv4.c
+++ b/net/ipv4/netfilter/nf_reject_ipv4.c
@@ -6,6 +6,7 @@
* published by the Free Software Foundation.
*/
+#include <linux/module.h>
#include <net/ip.h>
#include <net/tcp.h>
#include <net/route.h>
@@ -125,3 +126,5 @@ void nf_send_reset(struct sk_buff *oldskb, int hook)
kfree_skb(nskb);
}
EXPORT_SYMBOL_GPL(nf_send_reset);
+
+MODULE_LICENSE("GPL");
diff --git a/net/ipv6/netfilter/nf_reject_ipv6.c b/net/ipv6/netfilter/nf_reject_ipv6.c
index 5f5f043..20d9def 100644
--- a/net/ipv6/netfilter/nf_reject_ipv6.c
+++ b/net/ipv6/netfilter/nf_reject_ipv6.c
@@ -5,6 +5,8 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
+#include <linux/module.h>
#include <net/ipv6.h>
#include <net/ip6_route.h>
#include <net/ip6_fib.h>
@@ -161,3 +163,5 @@ void nf_send_reset6(struct net *net, struct sk_buff *oldskb, int hook)
ip6_local_out(nskb);
}
EXPORT_SYMBOL_GPL(nf_send_reset6);
+
+MODULE_LICENSE("GPL");
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] phy/micrel: KSZ8031RNL RMII clock reconfiguration bug
From: Angelo Dureghello @ 2014-10-10 10:02 UTC (permalink / raw)
To: netdev, Bruno Thomsen
In-Reply-To: <1412866094-4972-1-git-send-email-bth@kamstrup.dk>
I add some useful info:
there is a carrier change after phy is attached, but link state arrives
as zero.
[root@xb ~]# cat /sys/class/net/eth0/carrier
carrier carrier_changes
[root@xb ~]# cat /sys/class/net/eth0/carrier
0
[root@xb ~]# cat /sys/class/net/eth0/carrier_changes
1
Regards,
Angelo
On 09/10/2014 16:48, Bruno Thomsen wrote:
> Bug: Unable to send and receive Ethernet packets with Micrel PHY.
>
> Affected devices:
> KSZ8031RNL (commercial temp)
> KSZ8031RNLI (industrial temp)
>
> Description:
> PHY device is correctly detected during probe.
> PHY power-up default is 25MHz crystal clock input
> and output 50MHz RMII clock to MAC.
> Reconfiguration of PHY to input 50MHz RMII clock from MAC
> causes PHY to become unresponsive if clock source is changed
> after Operation Mode Strap Override (OMSO) register setup.
>
> Cause:
> Long lead times on parts where clock setup match circuit design
> forces the usage of similar parts with wrong default setup.
>
> Solution:
> Swapped KSZ8031 register setup and added phy_write return code validation.
>
> Tested with Freescale i.MX28 Fast Ethernet Controler (fec).
>
> Signed-off-by: Bruno Thomsen <bth@kamstrup.dk>
> ---
> drivers/net/phy/micrel.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index 011dbda..ec3f646 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -194,8 +194,10 @@ static int ksz8021_config_init(struct phy_device *phydev)
> if (rc)
> dev_err(&phydev->dev, "failed to set led mode\n");
>
> - phy_write(phydev, MII_KSZPHY_OMSO, val);
> rc = ksz_config_flags(phydev);
> + if (rc < 0)
> + return rc;
> + rc = phy_write(phydev, MII_KSZPHY_OMSO, val);
> return rc < 0 ? rc : 0;
> }
>
^ permalink raw reply
* RE: [PATCH net 0/5] net: fix races accessing page->_count
From: David Laight @ 2014-10-10 10:02 UTC (permalink / raw)
To: 'Eric Dumazet', David S. Miller
Cc: netdev@vger.kernel.org, Alexander Duyck, Andres Lagar-Cavilla,
Greg Thelen, Hugh Dickins, David Rientjes
In-Reply-To: <1412918694-22882-1-git-send-email-edumazet@google.com>
From: Eric Dumazet
> This is illegal to use atomic_set(&page->_count, ...) even if we 'own'
> the page. Other entities in the kernel need to use get_page_unless_zero()
> to get a reference to the page before testing page properties, so we could
> loose a refcount increment.
Plausibly the atomic_inc() could be avoided by allocating the page
with multiple references, or by gabbing a lot of extra references
and keeping a local count of when they are 'used' (by passing
ownership onwards).
David
^ permalink raw reply
* Re: [PATCH net 1/3] net: sctp: fix skb_over_panic when receiving malformed ASCONF chunks
From: Joshua Kinard @ 2014-10-10 10:04 UTC (permalink / raw)
To: Daniel Borkmann, davem; +Cc: linux-sctp, netdev, Vlad Yasevich
In-Reply-To: <1412888133-833-2-git-send-email-dborkman@redhat.com>
On 10/09/2014 16:55, Daniel Borkmann wrote:
> Commit 6f4c618ddb0 ("SCTP : Add paramters validity check for
> ASCONF chunk") added basic verification of ASCONF chunks, however,
> it is still possible to remotely crash a server by sending a
> special crafted ASCONF chunk, even up to pre 2.6.12 kernels:
>
> skb_over_panic: text:ffffffffa01ea1c3 len:31056 put:30768
> head:ffff88011bd81800 data:ffff88011bd81800 tail:0x7950
> end:0x440 dev:<NULL>
> ------------[ cut here ]------------
> kernel BUG at net/core/skbuff.c:129!
> [...]
> Call Trace:
> <IRQ>
> [<ffffffff8144fb1c>] skb_put+0x5c/0x70
> [<ffffffffa01ea1c3>] sctp_addto_chunk+0x63/0xd0 [sctp]
[snip]
>
> This can be triggered e.g., through a simple scripted nmap
> connection scan injecting the chunk after the handshake, for
> example, ...
>
> -------------- INIT[ASCONF; ASCONF_ACK] ------------->
> <----------- INIT-ACK[ASCONF; ASCONF_ACK] ------------
> -------------------- COOKIE-ECHO -------------------->
> <-------------------- COOKIE-ACK ---------------------
> ------------------ ASCONF; UNKNOWN ------------------>
>
> ... where ASCONF chunk of length 280 contains 2 parameters ...
>
> 1) Add IP address parameter (param length: 16)
> 2) Add/del IP address parameter (param length: 255)
>
> ... followed by an UNKNOWN chunk of e.g. 4 bytes. Here, the
> Address Parameter in the ASCONF chunk is even missing, too.
> This is just an example and similarly-crafted ASCONF chunks
> could be used just as well.
If I am reading correctly, this crash can only be triggered by actually getting
through the SCTP handshake, then sending this specially-crafted ASCONF chunk?
Meaning a blind nmap scan using this tactic against a random netblock wouldn't
just randomly knock servers offline? This would seem to reduce the attack
surface a quite bit by requiring the remote endpoint to actually respond.
Is there a CVE # for this?
Thanks!,
--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28
"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
^ permalink raw reply
* RE: Micrel KSZ8031 - phy link missing
From: Bruno Thomsen @ 2014-10-10 10:31 UTC (permalink / raw)
To: Angelo Dureghello, netdev@vger.kernel.org
In-Reply-To: <5437A7A2.3020700@gmail.com>
Hey
> i still have the issue after patching kernel 3.17.
> ...
> I am using RMII in my custom board, don't know if it makes any difference.
What RMII clock source do you use? MAC, PHY or external?
If your MAC output the RMII clock you need to enable MICREL_PHY_50MHZ_CLK flag in phydev->dev_flags.
Venlig hilsen / Best regards
Kamstrup A/S <http://www.kamstrup.dk>
Bruno Thomsen
Development engineer
Technology
Kamstrup A/S
Industrivej 28
DK-8660 Skanderborg
Tel: +45 89 93 10 00
Fax: +45 89 93 10 01
Dir: +45 89 93 13 94
E-mail: bth@kamstrup.dk
Web: www.kamstrup.dk
^ permalink raw reply
* Re: Micrel KSZ8031 - phy link missing
From: Angelo Dureghello @ 2014-10-10 10:54 UTC (permalink / raw)
To: Bruno Thomsen, netdev@vger.kernel.org
In-Reply-To: <915054555B5659448ACF8A70E114824D0163C7A77B@Exchange2010.kamstrup.dk>
Dear Thomsen,
thanks for the prompt help,
well i am setting up that clock pin in my board.c, as
#define DA850_EVM_PHY_ID "davinci_mdio-0:00"
#define DA850_MII_MDIO_CLKEN_PIN GPIO_TO_PIN(2, 6)
ret = davinci_cfg_reg(DA850_GPIO2_6);
if (ret)
pr_warn("%s:GPIO(2,6) mux setup failed\n", __func__);
ret = gpio_request(DA850_MII_MDIO_CLKEN_PIN, "mdio_clk_en");
if (ret) {
pr_warn("Cannot open GPIO %d\n", DA850_MII_MDIO_CLKEN_PIN);
return ret;
}
/* Enable/Disable MII MDIO clock */
gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, rmii_en);
Probably it's me that i am doing something illegal, i explain:
I am moving from a 3.5.1 to a 3.17 kernel, but have a special board.c
startup file i cannot convert into DT easily.
So i am booting using old way (board.c).
Now, new kernels have "pinctrl" that probably jump over my gpio setting
later in the boot, is it possible ?
Thanks
Angelo
On 10/10/2014 12:31, Bruno Thomsen wrote:
> Hey
>
>> i still have the issue after patching kernel 3.17.
>> ...
>> I am using RMII in my custom board, don't know if it makes any difference.
> What RMII clock source do you use? MAC, PHY or external?
>
> If your MAC output the RMII clock you need to enable MICREL_PHY_50MHZ_CLK flag in phydev->dev_flags.
>
>
> Venlig hilsen / Best regards
>
> Kamstrup A/S <http://www.kamstrup.dk>
> Bruno Thomsen
> Development engineer
> Technology
>
> Kamstrup A/S
> Industrivej 28
> DK-8660 Skanderborg
> Tel: +45 89 93 10 00
> Fax: +45 89 93 10 01
> Dir: +45 89 93 13 94
> E-mail: bth@kamstrup.dk
> Web: www.kamstrup.dk
^ permalink raw reply
* RE: eth_get_headlen() and unaligned accesses...
From: David Laight @ 2014-10-10 10:59 UTC (permalink / raw)
To: 'David Miller', alexander.h.duyck@redhat.com
Cc: netdev@vger.kernel.org
In-Reply-To: <20141010.004316.2276717749634684299.davem@davemloft.net>
From: David Miller
> From: Alexander Duyck <alexander.h.duyck@redhat.com>
> Date: Thu, 09 Oct 2014 20:10:01 -0700
>
> > On 10/09/2014 05:12 PM, David Miller wrote:
> >> So, we have a bit of a problem, this is on sparc64:
> >>
> >> [423475.740836] Kernel unaligned access at TPC[81d330]
> >> __skb_flow_get_ports+0x70/0xe0
> >> [423475.755756] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0+ #2
> >> [423475.767854] Call Trace:
> >> [423475.772877] [0000000000433288] kernel_unaligned_trap+0x368/0x5c0
> >> [423475.785203] [000000000042a824] sun4v_do_mna+0x84/0xa0
> >> [423475.795624] [0000000000406cd0] sun4v_mna+0x5c/0x68
> >> [423475.805521] [000000000081d330] __skb_flow_get_ports+0x70/0xe0
> >> [423475.817323] [000000000081d6ac] __skb_flow_dissect+0x1ac/0x460
> >> [423475.829128] [0000000000843c98] eth_get_headlen+0x38/0xa0
> >> [423475.840083] [0000000010064d54] igb_poll+0x8d4/0xf60 [igb]
> >> [423475.851184] [00000000008243c8] net_rx_action+0xa8/0x1c0
> >>
> >> The chip DMA's to the beginning of a frag page and (unless timestamps
> >> are enabled) that's where the ethernet header begins.
> >>
> >> So any larger than 16-bit access to the IP and later headers will be
> >> unaligned.
> >>
> >> We have various ways we can deal with this based upon the capabilities
> >> of the chips involved. Can we configure the IGB to put 2 "don't care"
> >> bytes at the beginning of the packet?
> >
> > The problem is the igb part expects to be able to use 2K buffers which
> > means it will always try to use the full half of a page.
>
> Let me try to ask this again.
>
> Can you configure the MAC to put two garbage bytes at the head of
> the packet data as it feeds it into the DMA fifos on the IGB chip?
>
> This is an essential (again: _essential_) feature for chips that
> manage RX buffers as power-of-2 chunks of pages, as it is the only
> cheap way to get the IP headers 32-bit aligned in those power-of-2 DMA
> buffer blocks.
Not only the IP header, at some point all of the data is likely to
accessed (preferably) as words - if only as a final copy of the
userdata somewhere.
So if you can't efficiently DMA the destination MAC address to a 4n+2
boundary you might as well do a realigning copy of the entire frame
into a separate skb.
Which probably means you should use a different ethernet adapter.
This isn't exactly a new problem.
One of the changes between the Sbus 'DMA' and 'DMA+' parts was that the
latter would do Sbus bursts for transfers (from the lance) that started
misaligned.
David
^ permalink raw reply
* Re: r8168 is needed to enter P-state: Package State 6 (pc6)onHaswell hardware: does the patch below against current kernel make a difference? Yes, it does
From: Ceriel Jacobs @ 2014-10-10 11:09 UTC (permalink / raw)
To: Francois Romieu; +Cc: Hayes Wang, nic_swsd, netdev@vger.kernel.org
In-Reply-To: <20141009221458.GA20126@electric-eye.fr.zoreil.com>
ASPM is enabled in the BIOS as far as possible.
ASPM is also enabled using kernel parameters:
1. pcie_aspm.policy=powersave
2. pcie_aspm=force
Despite the result for 03:00.0 (and 2 other PCIe devices) is:
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
I have filed a bug report for that at:
https://bugzilla.kernel.org/show_bug.cgi?id=85621
In my testing before, I did manually enable L0s L1 ASPM after login
prompt using:
# setpci -s 03:00.0 0x80.B=0x43 (also for 3 other ASPM PCIe devices)
=============================
Now back to your Realtek test request
=============================
For your information: I am running all testing remote via SSH over the
Realtek NIc.
=======
L0s and L1 = PC6
=======
# setpci -s 03:00.0 0x80.B=0x43
# lspci -vvvv -s 03:00.0 | grep LnkCtl:
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- ...
PC6 reached in 1 powertop screen update (5 second interval)
C3 (pc3) 21.0% | C3 (cc3) 0.0% | C3-HSW 0.0% 0.0 ms
C6 (pc6) 76.0% | C6 (cc6) 99.9% | C6-HSW 99.9% 198.1 ms
=======
L1 only = no PC6
=======
# setpci -s 03:00.0 0x80.B=0x42
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
C3 (pc3) 99.8% | C3 (cc3) 0.0% | C3-HSW 0.0% 0.0 ms
C6 (pc6) 0.0% | C6 (cc6) 99.9% | C6-HSW 100.0% 206.4 ms
=======
L0s only = PC6 !!
=======
# setpci -s 03:00.0 0x80.B=0x41
LnkCtl: ASPM L0s Enabled; RCB 64 bytes Disabled- ...
C3 (pc3) 10.6% | C3 (cc3) 0.0% | C3-HSW 0.0% 0.0 ms
C6 (pc6) 89.1% | C6 (cc6) 99.9% | C6-HSW 99.9% 210.7 ms
=======
Disabled = no PC6
=======
# setpci -s 03:00.0 0x80.B=0x40
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
C3 (pc3) 99.8% | C3 (cc3) 0.0% | C3-HSW 0.0% 0.0 ms
C6 (pc6) 0.0% | C6 (cc6) 99.9% | C6-HSW 99.9% 230.1 ms
Now I am wondering whether it is by design or a bug that PC6 is not
reached when only L1 ASPM is activated
An applause for:
1. saving "polar bears",
2. letting me test a little more,
3. realtime behavior changing (no module unloading and loading to active
ASPM, just set the config space registers).
Francois Romieu schreef op 10-10-14 om 00:14:
> Ceriel Jacobs <linux-ide@crashplan.pro> :
>> Francois Romieu schreef op 07-10-14 om 00:13:
>>> Ceriel, does the patch below against current kernel make a difference?
> [...]
>> New r8169 "powertop" result (even without --auto-tune):
>> C2 (pc2) 0.0% | |
>> C3 (pc3) 9.9% | C3 (cc3) 0.7% | C3-HSW 0.7% 16.4 ms
>> C6 (pc6) 89.9% | C6 (cc6) 99.2% | C6-HSW 99.2% 223.2 ms
>> ---
>
> Fine (almost: I hope that ASPM was enabled from bios or during boot
> behind your back).
>
> Remember your "lspci -nnkvv -s 03:00.0" ?
>
> 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 11)
> [...]
> Capabilities: [70] Express (v2) Endpoint, MSI 01
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
> 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, Exit Latency L0s unlimited, L1 <64us
> ClockPM+ Surprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>
> It should now look like:
> [...]
> LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
>
> Let's temporarily disable it and see if powertop notices a difference.
>
> <full disclosure>
>
> "Capabilities: [70]" above gives you the offset of the relevant registers:
> # lspci -xxx -s 03:00.0
> [...]
> 70: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
> ^^ -> "[70]"
>
> You are interested in the Link Control register, aka PCI_EXP_LNKCTL in
> /usr/include/pci/header.h (devel part of pciutils) or kernel's
> include/uapi/linux/pci_regs.h. It's 16 bytes further, thus
> [...]
> 70: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
> 80: 42 .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
> ^^
>
> 0x42 matches "LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
> ExtSynch-" built from above. There may be differences but the 3 lower
> weight binary digits in 0x42 encode ASPM control (0=nada, 1=L0, 2=L1,
> see PCI_EXP_LNKCTL_ASPxyz in include/uapi/linux/pci_regs.h). Mask these
> out (0x42 & ~0x03) and feed the resulting value back into the Link
> Control register:
>
> # setpci -s 03:00.0 CAP_EXP+10.b=0x40
>
> (CAP_EXP is pciutils's alias for the PCI Express capability block, see
> PCI_CAP_ID_EXP in kernel's include/uapi/linux/pci_regs.h)
>
> If you are not too sure about the 0x40 value, you can retrieve it with
> lspci and an unpatched r8169 driver.
>
> </full disclosure>
>
> If I have understood Hayes correctly and he got my question right, lspci
> should now tell that ASPM is disabled. C6 should not be reached anymore.
>
> ASPM could thus be enabled unconditionally at the driver level, then
> controled through the PCI config registers. Kernel r8169 driver would
> thus protect polar bears as Realtek's own r8168 driver already does.
>
> I can't exclude that it will fail miserably in a firework of smelly
> smoke though.
>
^ permalink raw reply
* RE: [PATCH] phy/micrel: KSZ8031RNL RMII clock reconfiguration bug
From: Bruno Thomsen @ 2014-10-10 11:24 UTC (permalink / raw)
To: Angelo Dureghello, netdev@vger.kernel.org
In-Reply-To: <5437AEC0.9010209@gmail.com>
Hey again
> I add some useful info:
> there is a carrier change after phy is attached, but link state arrives as zero.
>
> [root@xb ~]# cat /sys/class/net/eth0/carrier
> carrier carrier_changes
> [root@xb ~]# cat /sys/class/net/eth0/carrier
> 0
> [root@xb ~]# cat /sys/class/net/eth0/carrier_changes
> 1
Just to clarify, this patch fixes a real bug and from your first bug rapport it sounded like a similar issue.
On 09/10/2014 16:48, Bruno Thomsen wrote:
> Bug: Unable to send and receive Ethernet packets with Micrel PHY.
>
> Affected devices:
> KSZ8031RNL (commercial temp)
> KSZ8031RNLI (industrial temp)
>
> Description:
> PHY device is correctly detected during probe.
> PHY power-up default is 25MHz crystal clock input and output 50MHz
> RMII clock to MAC.
> Reconfiguration of PHY to input 50MHz RMII clock from MAC causes PHY
> to become unresponsive if clock source is changed after Operation Mode
> Strap Override (OMSO) register setup.
>
Venlig hilsen / Best regards
Kamstrup A/S <http://www.kamstrup.dk>
Bruno Thomsen
Development engineer
Technology
Kamstrup A/S
Industrivej 28
DK-8660 Skanderborg
Tel: +45 89 93 10 00
Fax: +45 89 93 10 01
Dir: +45 89 93 13 94
E-mail: bth@kamstrup.dk
Web: www.kamstrup.dk
^ permalink raw reply
* Re: [PATCH iproute2] ip lib: Change timestamp to be shorter and on the same line
From: Vadim Kochan @ 2014-10-10 11:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <CAMw6YJJcu69p=43c3ey2Ha1q_7Rkzs00jOtyiK058nNEcE78Wg@mail.gmail.com>
Hi,
I was thinking about new option but can't find out nothing better than
"-tshort" matched option.
Regards,
On Wed, Sep 17, 2014 at 9:06 AM, Vadim Kochan <vadim4j@gmail.com> wrote:
> Sure, I can add new option, currently timestamp is printed on separated
> line so this solution I think can be easier to parse when it will be
> on the same line as message,
> and easier to detect to which message timestamp belongs.
>
> On Wed, Sep 17, 2014 at 5:38 AM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
>> On Tue, 16 Sep 2014 12:58:06 +0300
>> Vadim Kochan <vadim4j@gmail.com> wrote:
>>
>>> Changed timestamp format to look like more logging info:
>>>
>>> [Sep 01 20:56:11.853146]2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default
>>> link/ether 3c:97:0e:a3:86:2e brd ff:ff:ff:ff:ff:ff
>>>
>>> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
>>> ---
>>> lib/utils.c | 7 +++----
>>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/lib/utils.c b/lib/utils.c
>>> index dc21567..03092ba 100644
>>> --- a/lib/utils.c
>>> +++ b/lib/utils.c
>>> @@ -772,14 +772,13 @@ __u8* hexstring_a2n(const char *str, __u8 *buf, int blen)
>>> int print_timestamp(FILE *fp)
>>> {
>>> struct timeval tv;
>>> - char *tstr;
>>> + char tstr[40] = {};
>>>
>>> memset(&tv, 0, sizeof(tv));
>>> gettimeofday(&tv, NULL);
>>>
>>> - tstr = asctime(localtime(&tv.tv_sec));
>>> - tstr[strlen(tstr)-1] = 0;
>>> - fprintf(fp, "Timestamp: %s %ld usec\n", tstr, (long)tv.tv_usec);
>>> + strftime(tstr, sizeof(tstr), "%b %d %H:%M:%S", localtime(&tv.tv_sec));
>>> + fprintf(fp, "[%s.%ld]", tstr, (long)tv.tv_usec);
>>> return 0;
>>> }
>>>
>>
>> I am loath to change the output format since people write scripts parsing
>> output. Maybe add a new flag option to choose format?
^ permalink raw reply
* RE: Micrel KSZ8031 - phy link missing
From: Bruno Thomsen @ 2014-10-10 11:32 UTC (permalink / raw)
To: Angelo Dureghello, netdev@vger.kernel.org
In-Reply-To: <5437BACA.1000201@gmail.com>
Hey again,
> thanks for the prompt help,
> well i am setting up that clock pin in my board.c, as
> ..
>
> Probably it's me that i am doing something illegal, i explain:
>
> I am moving from a 3.5.1 to a 3.17 kernel, but have a special board.c startup file i cannot convert into DT easily.
> So i am booting using old way (board.c).
> Now, new kernels have "pinctrl" that probably jump over my gpio setting later in the boot, is it possible ?
Looks like you just enable clock output from DA850. You also need to setup PHY to accept RMII clock from MAC.
This can be done with something like this...
static int angelo_board_phy_fixup(struct phy_device *phy)
{
phy->dev_flags |= MICREL_PHY_50MHZ_CLK;
return 0;
}
static void __init angelo_board_init(void)
{
phy_register_fixup_for_uid(PHY_ID_KSZ8031, MICREL_PHY_ID_MASK,
angelo_board_phy_fixup);
// Old board init
}
Venlig hilsen / Best regards
Kamstrup A/S <http://www.kamstrup.dk>
Bruno Thomsen
Development engineer
Technology
Kamstrup A/S
Industrivej 28
DK-8660 Skanderborg
Tel: +45 89 93 10 00
Fax: +45 89 93 10 01
Dir: +45 89 93 13 94
E-mail: bth@kamstrup.dk
Web: www.kamstrup.dk
^ permalink raw reply
* Re: [PATCH net 0/5] net: fix races accessing page->_count
From: Eric Dumazet @ 2014-10-10 11:37 UTC (permalink / raw)
To: David Laight
Cc: 'Eric Dumazet', David S. Miller, netdev@vger.kernel.org,
Alexander Duyck, Andres Lagar-Cavilla, Greg Thelen, Hugh Dickins,
David Rientjes
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D174C833D@AcuExch.aculab.com>
On Fri, 2014-10-10 at 10:02 +0000, David Laight wrote:
> From: Eric Dumazet
> > This is illegal to use atomic_set(&page->_count, ...) even if we 'own'
> > the page. Other entities in the kernel need to use get_page_unless_zero()
> > to get a reference to the page before testing page properties, so we could
> > loose a refcount increment.
>
> Plausibly the atomic_inc() could be avoided by allocating the page
> with multiple references, or by gabbing a lot of extra references
> and keeping a local count of when they are 'used' (by passing
> ownership onwards).
Well, this is the idea already in place.
I assume you read __netdev_alloc_frag() ?
Note this is a fix, and a fix should be minimal and obvious.
^ permalink raw reply
* Re: [PATCH net 2/5] igb: fix race accessing page->_count
From: Eric Dumazet @ 2014-10-10 11:47 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Eric Dumazet, David S. Miller, netdev, Alexander Duyck,
Andres Lagar-Cavilla, Greg Thelen, Hugh Dickins, David Rientjes
In-Reply-To: <CAL3LdT5_uQ07kbB+N6RY1yMe3yfko6O2g+QsTaz1-TDk7A1CCQ@mail.gmail.com>
On Thu, 2014-10-09 at 22:55 -0700, Jeff Kirsher wrote:
> On Thu, Oct 9, 2014 at 10:24 PM, Eric Dumazet <edumazet@google.com> wrote:
> > This is illegal to use atomic_set(&page->_count, 2) even if we 'own'
> > the page. Other entities in the kernel need to use get_page_unless_zero()
> > to get a reference to the page before testing page properties, so we could
> > loose a refcount increment.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Since this is apart of a series, if the changes to skbuff are ok, then
> the changes to the Intel drivers are ok.
Thanks Jeff, I am sending v2 including your Acked-by and ixgbe title
fix.
^ permalink raw reply
* [PATCH v2 net 0/5] net: fix races accessing page->_count
From: Eric Dumazet @ 2014-10-10 11:48 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Alexander Duyck, Jeff Kirsher, Andres Lagar-Cavilla,
Greg Thelen, Hugh Dickins, David Rientjes, Eric Dumazet
This is illegal to use atomic_set(&page->_count, ...) even if we 'own'
the page. Other entities in the kernel need to use get_page_unless_zero()
to get a reference to the page before testing page properties, so we could
loose a refcount increment.
The only case it is valid is when page->_count is 0, we can use this in
__netdev_alloc_frag()
Note that I never seen crashes caused by these races, the issue was reported
by Andres Lagar-Cavilla and Hugh Dickins.
Eric Dumazet (5):
fm10k: fix race accessing page->_count
igb: fix race accessing page->_count
ixgbe: fix race accessing page->_count
mlx4: fix race accessing page->_count
net: fix races in page->_count manipulation
drivers/net/ethernet/intel/fm10k/fm10k_main.c | 7 +++----
drivers/net/ethernet/intel/igb/igb_main.c | 7 +++----
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 8 +++-----
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +++---
net/core/skbuff.c | 25 ++++++++++++++++++-------
5 files changed, 30 insertions(+), 23 deletions(-)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply
* [PATCH v2 net 1/5] fm10k: fix race accessing page->_count
From: Eric Dumazet @ 2014-10-10 11:48 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Alexander Duyck, Jeff Kirsher, Andres Lagar-Cavilla,
Greg Thelen, Hugh Dickins, David Rientjes, Eric Dumazet
In-Reply-To: <1412941698-17502-1-git-send-email-edumazet@google.com>
This is illegal to use atomic_set(&page->_count, 2) even if we 'own'
the page. Other entities in the kernel need to use get_page_unless_zero()
to get a reference to the page before testing page properties, so we could
loose a refcount increment.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_main.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_main.c b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
index 6c800a330d66..9d7118a0d67a 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_main.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
@@ -219,11 +219,10 @@ static bool fm10k_can_reuse_rx_page(struct fm10k_rx_buffer *rx_buffer,
/* flip page offset to other buffer */
rx_buffer->page_offset ^= FM10K_RX_BUFSZ;
- /* since we are the only owner of the page and we need to
- * increment it, just set the value to 2 in order to avoid
- * an unnecessary locked operation
+ /* Even if we own the page, we are not allowed to use atomic_set()
+ * This would break get_page_unless_zero() users.
*/
- atomic_set(&page->_count, 2);
+ atomic_inc(&page->_count);
#else
/* move offset up to the next cache line */
rx_buffer->page_offset += truesize;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH v2 net 2/5] igb: fix race accessing page->_count
From: Eric Dumazet @ 2014-10-10 11:48 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Alexander Duyck, Jeff Kirsher, Andres Lagar-Cavilla,
Greg Thelen, Hugh Dickins, David Rientjes, Eric Dumazet
In-Reply-To: <1412941698-17502-1-git-send-email-edumazet@google.com>
This is illegal to use atomic_set(&page->_count, 2) even if we 'own'
the page. Other entities in the kernel need to use get_page_unless_zero()
to get a reference to the page before testing page properties, so we could
loose a refcount increment.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index ae59c0b108c5..a21b14495ebd 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -6545,11 +6545,10 @@ static bool igb_can_reuse_rx_page(struct igb_rx_buffer *rx_buffer,
/* flip page offset to other buffer */
rx_buffer->page_offset ^= IGB_RX_BUFSZ;
- /* since we are the only owner of the page and we need to
- * increment it, just set the value to 2 in order to avoid
- * an unnecessary locked operation
+ /* Even if we own the page, we are not allowed to use atomic_set()
+ * This would break get_page_unless_zero() users.
*/
- atomic_set(&page->_count, 2);
+ atomic_inc(&page->_count);
#else
/* move offset up to the next cache line */
rx_buffer->page_offset += truesize;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH v2 net 3/5] ixgbe: fix race accessing page->_count
From: Eric Dumazet @ 2014-10-10 11:48 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Alexander Duyck, Jeff Kirsher, Andres Lagar-Cavilla,
Greg Thelen, Hugh Dickins, David Rientjes, Eric Dumazet
In-Reply-To: <1412941698-17502-1-git-send-email-edumazet@google.com>
This is illegal to use atomic_set(&page->_count, 2) even if we 'own'
the page. Other entities in the kernel need to use get_page_unless_zero()
to get a reference to the page before testing page properties, so we could
loose a refcount increment.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index d677b5a23b58..fec5212d4337 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1865,12 +1865,10 @@ static bool ixgbe_add_rx_frag(struct ixgbe_ring *rx_ring,
/* flip page offset to other buffer */
rx_buffer->page_offset ^= truesize;
- /*
- * since we are the only owner of the page and we need to
- * increment it, just set the value to 2 in order to avoid
- * an unecessary locked operation
+ /* Even if we own the page, we are not allowed to use atomic_set()
+ * This would break get_page_unless_zero() users.
*/
- atomic_set(&page->_count, 2);
+ atomic_inc(&page->_count);
#else
/* move offset up to the next cache line */
rx_buffer->page_offset += truesize;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH v2 net 4/5] mlx4: fix race accessing page->_count
From: Eric Dumazet @ 2014-10-10 11:48 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Alexander Duyck, Jeff Kirsher, Andres Lagar-Cavilla,
Greg Thelen, Hugh Dickins, David Rientjes, Eric Dumazet
In-Reply-To: <1412941698-17502-1-git-send-email-edumazet@google.com>
This is illegal to use atomic_set(&page->_count, ...) even if we 'own'
the page. Other entities in the kernel need to use get_page_unless_zero()
to get a reference to the page before testing page properties, so we could
loose a refcount increment.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index a33048ee9621..01660c595f5c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -76,10 +76,10 @@ static int mlx4_alloc_pages(struct mlx4_en_priv *priv,
page_alloc->dma = dma;
page_alloc->page_offset = frag_info->frag_align;
/* Not doing get_page() for each frag is a big win
- * on asymetric workloads.
+ * on asymetric workloads. Note we can not use atomic_set().
*/
- atomic_set(&page->_count,
- page_alloc->page_size / frag_info->frag_stride);
+ atomic_add(page_alloc->page_size / frag_info->frag_stride - 1,
+ &page->_count);
return 0;
}
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH v2 net 5/5] net: fix races in page->_count manipulation
From: Eric Dumazet @ 2014-10-10 11:48 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Alexander Duyck, Jeff Kirsher, Andres Lagar-Cavilla,
Greg Thelen, Hugh Dickins, David Rientjes, Eric Dumazet
In-Reply-To: <1412941698-17502-1-git-send-email-edumazet@google.com>
This is illegal to use atomic_set(&page->_count, ...) even if we 'own'
the page. Other entities in the kernel need to use get_page_unless_zero()
to get a reference to the page before testing page properties, so we could
loose a refcount increment.
The only case it is valid is when page->_count is 0
Fixes: 540eb7bf0bbed ("net: Update alloc frag to reduce get/put page usage and recycle pages")
Signed-off-by: Eric Dumaze <edumazet@google.com>
---
net/core/skbuff.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index a30d750647e7..829d013745ab 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -360,18 +360,29 @@ refill:
goto end;
}
nc->frag.size = PAGE_SIZE << order;
-recycle:
- atomic_set(&nc->frag.page->_count, NETDEV_PAGECNT_MAX_BIAS);
+ /* Even if we own the page, we do not use atomic_set().
+ * This would break get_page_unless_zero() users.
+ */
+ atomic_add(NETDEV_PAGECNT_MAX_BIAS - 1,
+ &nc->frag.page->_count);
nc->pagecnt_bias = NETDEV_PAGECNT_MAX_BIAS;
nc->frag.offset = 0;
}
if (nc->frag.offset + fragsz > nc->frag.size) {
- /* avoid unnecessary locked operations if possible */
- if ((atomic_read(&nc->frag.page->_count) == nc->pagecnt_bias) ||
- atomic_sub_and_test(nc->pagecnt_bias, &nc->frag.page->_count))
- goto recycle;
- goto refill;
+ if (atomic_read(&nc->frag.page->_count) != nc->pagecnt_bias) {
+ if (!atomic_sub_and_test(nc->pagecnt_bias,
+ &nc->frag.page->_count))
+ goto refill;
+ /* OK, page count is 0, we can safely set it */
+ atomic_set(&nc->frag.page->_count,
+ NETDEV_PAGECNT_MAX_BIAS);
+ } else {
+ atomic_add(NETDEV_PAGECNT_MAX_BIAS - nc->pagecnt_bias,
+ &nc->frag.page->_count);
+ }
+ nc->pagecnt_bias = NETDEV_PAGECNT_MAX_BIAS;
+ nc->frag.offset = 0;
}
data = page_address(nc->frag.page) + nc->frag.offset;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Re: [PATCH v3] Add support for GPIOs for SMSC LAN95xx chips.
From: Bjørn Mork @ 2014-10-10 12:02 UTC (permalink / raw)
To: Evgeny Boger
Cc: Daniele Forsi, Steve Glendinning, David Miller, netdev, linux-usb
In-Reply-To: <1412806498-22556-1-git-send-email-boger@contactless.ru>
Evgeny Boger <boger@contactless.ru> writes:
> For LAN951x:
> GPIOs with offsets 0-7 are named "GPIO3" - "GPIO7",
The number of offsets does not match the number of names.
Bjørn
^ permalink raw reply
* Re: Micrel KSZ8031 - phy link missing
From: Angelo Dureghello @ 2014-10-10 12:54 UTC (permalink / raw)
To: Bruno Thomsen, netdev@vger.kernel.org
In-Reply-To: <915054555B5659448ACF8A70E114824D0163C7A7F9@Exchange2010.kamstrup.dk>
Dear Bruno,
i added the fixup, nothing changes.
I am tracing flags at ksz8021_config_ini:
Starting network...
davinci_mdio davinci_mdio.0: resetting idled controller
micrel.c: ksz8021_config_init: flags: 0x00000203
net eth0: attached PHY driver [Micrel KSZ8031]
(mii_bus:phy_addr=davinci_mdio-0:00, id=221556)
udhcpc (v1.20.2) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
So, MICREL_PHY_50MHZ_CLK seems to be set.
I have the suspect that the clock is not received from the phy.
Unfortunately i can't check
with the scope, the micrel chip is on a hidden part of the board.
From what i remember, when i was trying to init emac/phy by devicetree,
it was working.
[root@barix ~]# cat /sys/class/net/eth0/carrier
0
[root@barix ~]# cat /sys/class/net/eth0/carrier_changes
1
[root@barix ~]#
I realize at this point is my own debugging / issue.
But if you have any idea how to debug this, i can put some traces here
and there.
Still many thanks,
Angelo
On 10/10/2014 13:32, Bruno Thomsen wrote:
> Hey again,
> Looks like you just enable clock output from DA850. You also need to setup PHY to accept RMII clock from MAC.
> This can be done with something like this...
>
> ...
>
>
^ permalink raw reply
* [PATCH] ipv6: notify userspace when we added or changed an ipv6 token
From: Lubomir Rintel @ 2014-10-10 14:08 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, David S. Miller, Lubomir Rintel,
Hannes Frederic Sowa, Daniel Borkmann
NetworkManager might want to know that it changed when the router advertisement
arrives.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Daniel Borkmann <dborkman@redhat.com>
---
net/ipv6/addrconf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 3e118df..3d11390 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4528,6 +4528,7 @@ static int inet6_set_iftoken(struct inet6_dev *idev, struct in6_addr *token)
}
write_unlock_bh(&idev->lock);
+ netdev_state_change(dev);
addrconf_verify_rtnl();
return 0;
}
--
1.9.3
^ 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