* Re: 3.4.1 and 3.5-rc1 Packet lost at 250Mb/s
From: Eric Dumazet @ 2012-10-08 6:22 UTC (permalink / raw)
To: adam.niescierowicz; +Cc: Netdev
In-Reply-To: <409ac8b30a6994028562e1a159ac60aa@justnet.pl>
On Sun, 2012-10-07 at 21:18 +0200, Nieścierowicz Adam wrote:
> W dniu 06.07.2012 12:13, Eric Dumazet napisał(a):
>
> > On Fri, 2012-07-06 at 11:47 +0200, Nieścierowicz Adam wrote:
> >
> >> Hello, Can I send something that will help determine the cause of
> >> the
> >> problem? W dniu 08.06.2012 11:41, Eric Dumazet napisał(a):
> >>
> >>> On Fri, 2012-06-08 at 10:58 +0200, Nieścierowicz Adam wrote:
> >>>
> >>>> Hello, recently we changed on the router kernel from 2.6.38.1 to
> >>>> 3.4.1 and noticed 30% packet loss when traffic increases up to
> >>>> 250MB / s. Similar is for kernel 3.5-rc1 Here a link to ifstat
> >>>> http://wklej.org/id/767577/ [1] [2]
> >>> You should give as much as possible delails on your setup
> >>> (hardware,
> >>> software) lspci cat /proc/cpuinfo cat /proc/interrupts ifconfig -a
> >>> tc
> >>> -s -d qdisc dmesg netstat -s
> >> currently running on 2.6.38.1 and traffic is 100Mb / s lspci:
> >> http://wklej.org/id/769102/ [2] /proc/cpuinfo:
> >> http://wklej.org/id/769104/ [3] /proc/interrupts:
> >> http://wklej.org/id/769106/ [4] ifconfig -a:
> >> http://wklej.org/id/769108/ [5] tc -s -d qdisc:
> >> http://wklej.org/id/769109/ [6] dmesg: here are some logs from
> >> iptables
> >> netstat -s: http://wklej.org/id/769110/ [7] lsmod:
> >> http://wklej.org/id/769117/ [8] /proc/net/softnet_stat:
> >> http://wklej.org/id/769116/ [9]
> >
> > Same infos of 3.5-rcX kernel would be nice.
> >
> > What NIC is eth0 ? (dmesg please)
> >
> > It seems all network traffic on 2.6.38 is handled by a single cpu
> > (cpu0)
> >
> > (seen in /proc/interrupts)
> >
> > I suspect that with 3.4 or 3.5 kernels, traffic is handled by many
> > cpus
> > and they hit false sharing and contention.
> >
> > You probably get better performance doing some affinity tuning :
> >
> > For example,
> > eth0 serviced by cpu0
> > eth2 serviced by cpu1
> > eth3 serviced by cpu2
> > eth5 serviced by cpu3
> >
> > and so on...
> >
> > check and/or set /proc/irq/${NUM}/smp_affinity
>
> hello
> I would go back to an earlier thread.
>
> Currently is installed kernel 3.6.0 and symptoms are the same
>
> about configuration:
>
> - affinity on
>
> - lspci: http://wklej.org/id/843156/ [10]
>
> - /proc/cpuinfo: http://wklej.org/id/843158/ [11]
>
> - /proc/interrupts: http://wklej.org/id/843161/ [12]
>
> - ifconfig -a: http://wklej.org/id/843162/ [13]
>
> - tc -s -d qdisc: http://wklej.org/id/843164/ [14]
>
> - dmesg: http://wklej.org/id/843166/ [15]
>
> - lsmod: http://wklej.org/id/843167/ [16]
>
> - /proc/net/softnet_stat: /proc/net/softnet_stat
>
> attach something else?
>
> Thanks
You should use RPS on eth2/eth3 because they are non multi queue.
Documentation/networking/scaling.txt should give you all the needed info
^ permalink raw reply
* Re: [PATCH] pppoatm: don't send frames to destroyed vcc
From: Krzysztof Mazur @ 2012-10-08 6:23 UTC (permalink / raw)
To: David Woodhouse; +Cc: mitch, netdev, davem, linux-kernel
In-Reply-To: <20121006153804.GA13564@shrek.podlesie.net>
On Sat, Oct 06, 2012 at 05:38:04PM +0200, Krzysztof Mazur wrote:
> On Sat, Oct 06, 2012 at 02:32:50PM +0100, David Woodhouse wrote:
> > On Sat, 2012-10-06 at 14:19 +0200, Krzysztof Mazur wrote:
> > > Now pppoatm_send(), like vcc_sendmsg(), checks for vcc flags that
> > > indicate that vcc is not ready.
> >
> > And what locking prevents the flag from being set immediately after we
> > check it?
> >
>
> nothing, this patch should fix this.
>
>
> vcc = ATM_SKB(skb)->vcc;
> + bh_lock_sock(sk_atm(vcc));
After bh_lock_sock() sock_owned_by_user(sk_atm(vcc)) should be checked
here. I'm sending fixed patch.
> if (test_bit(ATM_VF_RELEASED, &vcc->flags)
> || test_bit(ATM_VF_CLOSE, &vcc->flags)
Krzysiek
--
>From 3ae93335423ed0ba526dc80163ff6dfeba9bbea1 Mon Sep 17 00:00:00 2001
From: Krzysztof Mazur <krzysiek@podlesie.net>
Date: Mon, 8 Oct 2012 08:10:22 +0200
Subject: [PATCH] pppoatm: fix race condition with destroying of vcc
The pppoatm_send() calls vcc->send() and now also checks for
some vcc flags that indicate destroyed vcc without proper locking.
The vcc_sendmsg() uses lock_sock(sk). This lock is used by
vcc_release(), so vcc_destroy_socket() will not be called between
check and during ->send(). The vcc_release_async() sets ATM_VF_CLOSE,
but it should be safe to call ->send() after it, because
vcc->dev->ops->close() is not called.
The pppoatm_send() is called with BH disabled, so bh_lock_sock()
should be used instead of lock_sock().
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
net/atm/pppoatm.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c
index 0dcb5dc..e3b2d69 100644
--- a/net/atm/pppoatm.c
+++ b/net/atm/pppoatm.c
@@ -270,6 +270,7 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
{
struct pppoatm_vcc *pvcc = chan_to_pvcc(chan);
struct atm_vcc *vcc;
+ int ret;
ATM_SKB(skb)->vcc = pvcc->atmvcc;
pr_debug("(skb=0x%p, vcc=0x%p)\n", skb, pvcc->atmvcc);
@@ -304,17 +305,24 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
}
vcc = ATM_SKB(skb)->vcc;
+ bh_lock_sock(sk_atm(vcc));
+ if (sock_owned_by_user(sk_atm(vcc)))
+ goto nospace_unlock_sock;
if (test_bit(ATM_VF_RELEASED, &vcc->flags)
|| test_bit(ATM_VF_CLOSE, &vcc->flags)
|| !test_bit(ATM_VF_READY, &vcc->flags))
- goto nospace;
+ goto nospace_unlock_sock;
atomic_add(skb->truesize, &sk_atm(ATM_SKB(skb)->vcc)->sk_wmem_alloc);
ATM_SKB(skb)->atm_options = ATM_SKB(skb)->vcc->atm_options;
pr_debug("atm_skb(%p)->vcc(%p)->dev(%p)\n",
skb, ATM_SKB(skb)->vcc, ATM_SKB(skb)->vcc->dev);
- return ATM_SKB(skb)->vcc->send(ATM_SKB(skb)->vcc, skb)
+ ret = ATM_SKB(skb)->vcc->send(ATM_SKB(skb)->vcc, skb)
? DROP_PACKET : 1;
+ bh_unlock_sock(sk_atm(vcc));
+ return ret;
+nospace_unlock_sock:
+ bh_unlock_sock(sk_atm(vcc));
nospace:
/*
* We don't have space to send this SKB now, but we might have
--
1.7.12.2.2.g1c3c581
^ permalink raw reply related
* [PATCH v4] skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard.
From: Graham Gower @ 2012-10-08 6:43 UTC (permalink / raw)
To: davem; +Cc: netdev, shemminger
Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to send/receive
packets on a system with >4gb ram unless a 32bit DMA mask is used.
This issue has been around for years and a fix was sent 3.5 years ago, but
there was some debate as to whether it should instead be fixed as a PCI quirk.
http://www.spinics.net/lists/netdev/msg88670.html
However, 18 months later a similar workaround was introduced for another
chipset exhibiting the same problem.
http://www.spinics.net/lists/netdev/msg142287.html
Signed-off-by: Graham Gower <graham.gower@gmail.com>
--- a/drivers/net/ethernet/marvell/skge.c.bak
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -4143,6 +4143,13 @@
DMI_MATCH(DMI_BOARD_NAME, "nForce"),
},
},
+ {
+ .ident = "ASUS P5NSLI",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
+ DMI_MATCH(DMI_BOARD_NAME, "P5NSLI")
+ },
+ },
{}
};
^ permalink raw reply
* Re: [PATCH v4] skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard.
From: David Miller @ 2012-10-08 7:07 UTC (permalink / raw)
To: graham.gower; +Cc: netdev, shemminger
In-Reply-To: <5072760C.7060004@gmail.com>
From: Graham Gower <graham.gower@gmail.com>
Date: Mon, 08 Oct 2012 17:13:24 +1030
> Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to
> send/receive
> packets on a system with >4gb ram unless a 32bit DMA mask is used.
Please format this ascii text properly. WHy is there a line
with just two words surrounded by full nearly 80-column lines?
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
THis is still formatted incorrectly, it's actually in the file
not due to your email client.
Can you indent the thing properly, please?
This is V4 of this patch, and suffering purely from first order coding
style and procedural stuff. As you can imagine, it's very frustrating
to have to spend this much time getting such simple things taken care
of.
^ permalink raw reply
* [patch] cxgb4: allocate enough data in t4_memory_rw()
From: Dan Carpenter @ 2012-10-08 7:12 UTC (permalink / raw)
To: Dimitris Michailidis, Vipul Pandya; +Cc: netdev, kernel-janitors
MEMWIN0_APERTURE is the size in bytes.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
This was introduced in 8c357ebd569 "cxgb4: Dynamically allocate memory
in t4_memory_rw() and get_vpd_params()" from Oct 3.
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 137a244..e914c41 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -417,7 +417,7 @@ static int t4_memory_rw(struct adapter *adap, int mtype, u32 addr, u32 len,
if ((addr & 0x3) || (len & 0x3))
return -EINVAL;
- data = vmalloc(MEMWIN0_APERTURE/sizeof(__be32));
+ data = vmalloc(MEMWIN0_APERTURE);
if (!data)
return -ENOMEM;
^ permalink raw reply related
* Re: [patch] cxgb4: allocate enough data in t4_memory_rw()
From: David Miller @ 2012-10-08 7:13 UTC (permalink / raw)
To: dan.carpenter; +Cc: dm, vipul, netdev, kernel-janitors
In-Reply-To: <20121008071210.GA17400@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 8 Oct 2012 10:12:11 +0300
> MEMWIN0_APERTURE is the size in bytes.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
> ---
> This was introduced in 8c357ebd569 "cxgb4: Dynamically allocate memory
> in t4_memory_rw() and get_vpd_params()" from Oct 3.
Sigh, putting bad on top of bad...
^ permalink raw reply
* Re: [PATCH] net: gro: selective flush of packets
From: Eric Dumazet @ 2012-10-08 7:39 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, netdev, Jesse Gross, Tom Herbert, Yuchung Cheng
In-Reply-To: <1349587787.21172.1908.camel@edumazet-glaptop>
On Sun, 2012-10-07 at 07:29 +0200, Eric Dumazet wrote:
> On Sun, 2012-10-07 at 08:32 +0800, Herbert Xu wrote:
> > Why don't we just always flush everything?
>
> This is what I tried first, but it lowered performance on several
> typical workloads.
>
> Using this simple heuristic increases performance.
>
>
By the way, one of the beauty of GRO is it helps under load to aggregate
packets and reduce cpu load. People wanting very low latencies should
probably not use GRO, and if they use it or not, receiving a full 64
packets batch on a particular NIC makes latencies very unpredictable.
So if we consumed all budget in a napi->poll() handler, its because we
are under load and we dont really want to cancel GRO aggregation.
Next napi->poll() invocation will have more chances to coalesce frames.
If there is only one flow, its OK because a 64 packet window allows ~4
GRO super packets to be built, regardless of an unconditional flush, but
with 8 flows, it would roughly give 100% increase of GRO packets sent to
upper layers.
Only needed safety measure is to make sure we dont let packets for a too
long time in case we never complete napi, this is what this patch does,
with a latency average of 0.5 ms (for slow flows)
^ permalink raw reply
* RE: [PATCH] flexcan: disable bus error interrupts for the i.MX28
From: Dong Aisheng-B29396 @ 2012-10-08 7:59 UTC (permalink / raw)
To: Wolfgang Grandegger, Shawn Guo; +Cc: Linux Netdev List, Linux-CAN, Hui Wang
In-Reply-To: <50719647.4070404@grandegger.com>
Hi Wolfgang,
>On 10/07/2012 05:09 AM, Shawn Guo wrote:
>> On Fri, Sep 28, 2012 at 03:17:15PM +0200, Wolfgang Grandegger wrote:
>>> Due to a bug in most Flexcan cores, the bus error interrupt needs to
>>> be enabled. Otherwise we don't get any error warning or passive
>>> interrupts. This is _not_ necessay for the i.MX28 and this patch
>>> disables bus error interrupts if "berr-reporting" is not requested.
>>> This avoids bus error flooding, which might harm, especially on
>>> low-end systems.
>>>
>>> To handle such quirks of the Flexcan cores, a hardware feature flag
>>> has been introduced, also replacing the "hw_ver" variable. So far
>>> nobody could tell what Flexcan core version is available on what
>>> Freescale SOC, apart from the i.MX6Q and P1010, and which bugs or
>>> features are present on the various "hw_rev".
>>>
>>> CC: Hui Wang <jason77.wang@gmail.com>
>>> CC: Shawn Guo <shawn.guo@linaro.org>
>>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>>> ---
>>>
>>> Concerning the bug, I know that the i.MX35 does have it. Maybe other
>>> Flexcan cores than on the i.MX28 does *not* have it either. If you
>>> have a chance, please check on the P1010, i.MX6Q, i.MX51, i.MX53,
>>> etc.
>>
>>>From what I can tell, i.MX35, i.MX51 and i.MX53 use the same version,
>> so they should all have the bug. And for i.MX6Q, since it uses a
>> newer version even than i.MX28, I would believe it's affected by the bug.
>> But I'm copying Dong who should have better knowledge about this to
>> confirm.
>
>Thank for clarification. I have a i.MX6Q board but without CAN adapter :(,
>unfortunately. Otherwise I would try it out myself.
>
How did you verify this issue?
I just checked our ic guy of flexcan, it seems he also had no sense of this issue.
Below is some version info what I got:
Mx6s use FlexCAN3, with IP version 10.00.12.00
Mx53 use FlexCAN2 (with glitch filter), with IP version 03.00.00.00
Mx28 use FlexCAN2 (with glitch filter), with IP version 03.00.04.00
Mx35 use FlexCAN2 (without glitch filter) , with IP version 03.00.00.00
Mx25 use FlexCAN2 (without glitch filter), with IP version 03.00.00.00
I'm not sure if mx6q has such issue.
Regards
Dong Aisheng
>>> drivers/net/can/flexcan.c | 29 +++++++++++++++++++----------
>>> 1 files changed, 19 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
>>> index c5f1431..c78ecfc 100644
>>> --- a/drivers/net/can/flexcan.c
>>> +++ b/drivers/net/can/flexcan.c
>>> @@ -144,6 +144,10 @@
>>>
>>> #define FLEXCAN_MB_CODE_MASK (0xf0ffffff)
>>>
>>> +/* FLEXCAN hardware feature flags */
>>> +#define FLEXCAN_HAS_V10_FEATURES BIT(1) /* For core version >= 10
>*/
>>> +#define FLEXCAN_HAS_BROKEN_ERR_STATE BIT(2) /* Broken error state
>handling */
>>> +
>>> /* Structure of the message buffer */ struct flexcan_mb {
>>> u32 can_ctrl;
>>> @@ -178,7 +182,7 @@ struct flexcan_regs { };
>>>
>>> struct flexcan_devtype_data {
>>> - u32 hw_ver; /* hardware controller version */
>>> + u32 features; /* hardware controller features */
>>> };
>>>
>>> struct flexcan_priv {
>>> @@ -197,11 +201,11 @@ struct flexcan_priv { };
>>>
>>> static struct flexcan_devtype_data fsl_p1010_devtype_data = {
>>> - .hw_ver = 3,
>>> + .features = FLEXCAN_HAS_BROKEN_ERR_STATE,
>>> };
>>> -
>>> +static struct flexcan_devtype_data fsl_imx28_devtype_data;
>>> static struct flexcan_devtype_data fsl_imx6q_devtype_data = {
>>> - .hw_ver = 10,
>>> + .features = FLEXCAN_HAS_V10_FEATURES |
>>> +FLEXCAN_HAS_BROKEN_ERR_STATE,
>>> };
>>>
>>> static const struct can_bittiming_const flexcan_bittiming_const = {
>>> @@ -741,15 +745,19 @@ static int flexcan_chip_start(struct net_device
>*dev)
>>> * enable tx and rx warning interrupt
>>> * enable bus off interrupt
>>> * (== FLEXCAN_CTRL_ERR_STATE)
>>> - *
>>> - * _note_: we enable the "error interrupt"
>>> - * (FLEXCAN_CTRL_ERR_MSK), too. Otherwise we don't get any
>>> - * warning or bus passive interrupts.
>>> */
>>> reg_ctrl = flexcan_read(®s->ctrl);
>>> reg_ctrl &= ~FLEXCAN_CTRL_TSYN;
>>> reg_ctrl |= FLEXCAN_CTRL_BOFF_REC | FLEXCAN_CTRL_LBUF |
>>> - FLEXCAN_CTRL_ERR_STATE | FLEXCAN_CTRL_ERR_MSK;
>>> + FLEXCAN_CTRL_ERR_STATE;
>>> + /*
>>> + * enable the "error interrupt" (FLEXCAN_CTRL_ERR_MSK),
>>> + * on most Flexcan cores, too. Otherwise we don't get
>>> + * any error warning or passive interrupts.
>>> + */
>>> + if (priv->devtype_data->features & FLEXCAN_HAS_BROKEN_ERR_STATE ||
>>> + priv->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING)
>>> + reg_ctrl |= FLEXCAN_CTRL_ERR_MSK;
>>>
>>> /* save for later use */
>>> priv->reg_ctrl_default = reg_ctrl;
>>> @@ -772,7 +780,7 @@ static int flexcan_chip_start(struct net_device
>*dev)
>>> flexcan_write(0x0, ®s->rx14mask);
>>> flexcan_write(0x0, ®s->rx15mask);
>>>
>>> - if (priv->devtype_data->hw_ver >= 10)
>>> + if (priv->devtype_data->features & FLEXCAN_HAS_V10_FEATURES)
>>> flexcan_write(0x0, ®s->rxfgmask);
>>>
>>> flexcan_transceiver_switch(priv, 1); @@ -954,6 +962,7 @@ static
>>> void __devexit unregister_flexcandev(struct net_device *dev)
>>>
>>> static const struct of_device_id flexcan_of_match[] = {
>>> { .compatible = "fsl,p1010-flexcan", .data =
>>> &fsl_p1010_devtype_data, },
>>> + { .compatible = "fsl,imx28-flexcan", .data =
>>> +&fsl_imx28_devtype_data, },
>>> { .compatible = "fsl,imx6q-flexcan", .data =
>&fsl_imx6q_devtype_data, },
>>> { /* sentinel */ },
>>> };
>>> --
>>> 1.7.7.6
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-can"
>> in the body of a message to majordomo@vger.kernel.org More majordomo
>> info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
^ permalink raw reply
* [ANNOUNCE] iptables 1.4.16.2 release
From: Pablo Neira Ayuso @ 2012-10-08 8:26 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
[-- Attachment #1: Type: text/plain, Size: 342 bytes --]
Hi!
The Netfilter project proudly presents:
iptables 1.4.16.2
This release fixes the NOTRACK target and the entire aliasing
infrastructure.
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/iptables/downloads.html
ftp://ftp.netfilter.org/pub/iptables/
[-- Attachment #2: changes-iptables-1.4.16.2.txt --]
[-- Type: text/plain, Size: 139 bytes --]
Jan Engelhardt (1):
iptables: restore NOTRACK functionality, target aliasing
Pablo Neira Ayuso (1):
bump version to 1.4.16.2
^ permalink raw reply
* Re: [RFC PATCH 0/5] net: socket bind to file descriptor introduced
From: Stanislav Kinsbursky @ 2012-10-08 8:37 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Eric W. Biederman, tglx@linutronix.de, mingo@redhat.com,
davem@davemloft.net, hpa@zytor.com,
thierry.reding@avionic-design.de, bfields@redhat.com,
eric.dumazet@gmail.com, Pavel Emelianov, neilb@suse.de,
netdev@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, paul.gortmaker@windriver.com,
viro@zeniv.linux.org.uk, gorcunov@openvz.org,
akpm@linux-foundation.org, tim.c.chen@linux.intel.com,
"devel@ope
In-Reply-To: <20121005200009.GA30139@fieldses.org>
06.10.2012 00:00, J. Bruce Fields пишет:
> On Tue, Sep 04, 2012 at 03:00:07PM -0400, bfields wrote:
>> On Mon, Aug 20, 2012 at 02:18:13PM +0400, Stanislav Kinsbursky wrote:
>>> 16.08.2012 07:03, Eric W. Biederman пишет:
>>>> Stanislav Kinsbursky <skinsbursky@parallels.com> writes:
>>>>
>>>>> This patch set introduces new socket operation and new system call:
>>>>> sys_fbind(), which allows to bind socket to opened file.
>>>>> File to bind to can be created by sys_mknod(S_IFSOCK) and opened by
>>>>> open(O_PATH).
>>>>>
>>>>> This system call is especially required for UNIX sockets, which has name
>>>>> lenght limitation.
>>>>>
>>>>> The following series implements...
>>>>
>>>> Hmm. I just realized this patchset is even sillier than I thought.
>>>>
>>>> Stanislav is the problem you are ultimately trying to solve nfs clients
>>>> in a container connecting to the wrong user space rpciod?
>>>>
>>>
>>> Hi, Eric.
>>> The problem you mentioned was the reason why I started to think about this.
>>> But currently I believe, that limitations in unix sockets connect or
>>> bind should be removed, because it will be useful it least for CRIU
>>> project.
>>>
>>>> Aka net/sunrpc/xprtsock.c:xs_setup_local only taking an absolute path
>>>> and then creating a delayed work item to actually open the unix domain
>>>> socket?
>>>>
>>>> The straight correct and straight forward thing to do appears to be:
>>>> - Capture the root from current->fs in xs_setup_local.
>>>> - In xs_local_finish_connect change current->fs.root to the captured
>>>> version of root before kernel_connect, and restore current->fs.root
>>>> after kernel_connect.
>>>>
>>>> It might not be a bad idea to implement open on unix domain sockets in
>>>> a filesystem as create(AF_LOCAL)+connect() which would allow you to
>>>> replace __sock_create + kernel_connect with a simple file_open_root.
>>>>
>>>
>>> I like the idea of introducing new family (AF_LOCAL_AT for example)
>>> and new sockaddr for connecting or binding from specified root. The
>>> only thing I'm worrying is passing file descriptor to unix bind or
>>> connect routine. Because this approach doesn't provide easy way to
>>> use such family and sockaddr in kernel (like in NFS example).
>>>
>>>> But I think the simple scheme of:
>>>> struct path old_root;
>>>> old_root = current->fs.root;
>>>> kernel_connect(...);
>>>> current->fs.root = old_root;
>>>>
>>>> Is more than sufficient and will remove the need for anything
>>>> except a purely local change to get nfs clients to connect from
>>>> containers.
>>>>
>>>
>>> That was my first idea.
>>
>> So is this what you're planning on doing now?
>
> What ever happened to this?
>
Sorry, was busy.
I'll prepare patch today, I hope.
> --b.
>
>>
>>> And probably it would be worth to change all
>>> fs_struct to support sockets with relative path.
>>> What do you think about it?
>>
>> I didn't understand the question. Are you suggesting that changes to
>> fs_struct would be required to make this work? I don't see why.
>>
>> --b.
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* [PATCH 0/3] ipv4: pmtu fixes
From: Steffen Klassert @ 2012-10-08 8:46 UTC (permalink / raw)
To: David Miller; +Cc: netdev
This patchset fixes some issues that came with the routing cache removal.
1) IPsec and others (udp, ipvs) may cache output routes, these routes
need to be invalidated on pmtu events in the same way e.g. tcp socket
cached routes are invalidated. With this we always invalidate or update
(if we already use a nh exeption route) the old route on pmtu events.
This has the drawback that we may needlessly invalidate an uncached route,
but this fixes all the users that cache routes and pmtu events are rare, so
this should not be a real issue.
2) We create nh exeptions if a user (e.g. tracepath) tries to do pmtu
dicsovery with packets bigger than the output device mtu. The device mtu
is not learned and does not expire, so don't create an exeption route.
3) We report cached pmtu values to userspace even if they are expired.
Fix this by checking for expiration before we report.
^ permalink raw reply
* [PATCH 1/3] ipv4: Always invalidate or update the route on pmtu events
From: Steffen Klassert @ 2012-10-08 8:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20121008084642.GB15622@secunet.com>
Some protocols, like IPsec still cache routes. So we need to invalidate
the old route on pmtu events to avoid the reuse of stale routes.
We also need to update the mtu and expire time of the route if we already
use a nh exeption route, otherwise we ignore newly learned pmtu values
after the first expiration.
With this patch we always invalidate or update the route on pmtu events.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/route.c | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index ff62206..90ba835 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -904,22 +904,29 @@ out: kfree_skb(skb);
return 0;
}
-static u32 __ip_rt_update_pmtu(struct rtable *rt, struct flowi4 *fl4, u32 mtu)
+static void __ip_rt_update_pmtu(struct rtable *rt, struct flowi4 *fl4, u32 mtu)
{
+ struct dst_entry *dst = &rt->dst;
struct fib_result res;
if (mtu < ip_rt_min_pmtu)
mtu = ip_rt_min_pmtu;
+ if (!rt->rt_pmtu) {
+ dst->obsolete = DST_OBSOLETE_KILL;
+ } else {
+ rt->rt_pmtu = mtu;
+ dst->expires = max(1UL, jiffies + ip_rt_mtu_expires);
+ }
+
rcu_read_lock();
- if (fib_lookup(dev_net(rt->dst.dev), fl4, &res) == 0) {
+ if (fib_lookup(dev_net(dst->dev), fl4, &res) == 0) {
struct fib_nh *nh = &FIB_RES_NH(res);
update_or_create_fnhe(nh, fl4->daddr, 0, mtu,
jiffies + ip_rt_mtu_expires);
}
rcu_read_unlock();
- return mtu;
}
static void ip_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
@@ -929,14 +936,7 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
struct flowi4 fl4;
ip_rt_build_flow_key(&fl4, sk, skb);
- mtu = __ip_rt_update_pmtu(rt, &fl4, mtu);
-
- if (!rt->rt_pmtu) {
- dst->obsolete = DST_OBSOLETE_KILL;
- } else {
- rt->rt_pmtu = mtu;
- rt->dst.expires = max(1UL, jiffies + ip_rt_mtu_expires);
- }
+ __ip_rt_update_pmtu(rt, &fl4, mtu);
}
void ipv4_update_pmtu(struct sk_buff *skb, struct net *net, u32 mtu,
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] ipv4: Don't create nh exeption when the device mtu is smaller than the reported pmtu
From: Steffen Klassert @ 2012-10-08 8:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20121008084642.GB15622@secunet.com>
When a local tool like tracepath tries to send packets bigger than
the device mtu, we create a nh exeption and set the pmtu to device
mtu. The device mtu does not expire, so check if the device mtu is
smaller than the reported pmtu and don't crerate a nh exeption in
that case.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/route.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 90ba835..741df67 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -909,6 +909,9 @@ static void __ip_rt_update_pmtu(struct rtable *rt, struct flowi4 *fl4, u32 mtu)
struct dst_entry *dst = &rt->dst;
struct fib_result res;
+ if (dst->dev->mtu < mtu)
+ return;
+
if (mtu < ip_rt_min_pmtu)
mtu = ip_rt_min_pmtu;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] ipv4: Don't report stale pmtu values to userspace
From: Steffen Klassert @ 2012-10-08 8:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20121008084642.GB15622@secunet.com>
We report cached pmtu values even if they are already expired.
Change this to not report these values after they are expired.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/route.c | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 741df67..24b52dd 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2187,8 +2187,16 @@ static int rt_fill_info(struct net *net, __be32 dst, __be32 src,
nla_put_be32(skb, RTA_GATEWAY, rt->rt_gateway))
goto nla_put_failure;
+ expires = rt->dst.expires;
+ if (expires) {
+ if (time_before(jiffies, expires))
+ expires -= jiffies;
+ else
+ expires = 0;
+ }
+
memcpy(metrics, dst_metrics_ptr(&rt->dst), sizeof(metrics));
- if (rt->rt_pmtu)
+ if (rt->rt_pmtu && expires)
metrics[RTAX_MTU - 1] = rt->rt_pmtu;
if (rtnetlink_put_metrics(skb, metrics) < 0)
goto nla_put_failure;
@@ -2198,13 +2206,6 @@ static int rt_fill_info(struct net *net, __be32 dst, __be32 src,
goto nla_put_failure;
error = rt->dst.error;
- expires = rt->dst.expires;
- if (expires) {
- if (time_before(jiffies, expires))
- expires -= jiffies;
- else
- expires = 0;
- }
if (rt_is_input_route(rt)) {
if (nla_put_u32(skb, RTA_IIF, rt->rt_iif))
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] flexcan: disable bus error interrupts for the i.MX28
From: Wolfgang Grandegger @ 2012-10-08 9:03 UTC (permalink / raw)
To: Dong Aisheng-B29396; +Cc: Shawn Guo, Linux Netdev List, Linux-CAN, Hui Wang
In-Reply-To: <7FE21149F4667147B645348EC60578850B2A361F@039-SN2MPN1-011.039d.mgd.msft.net>
Hi Dong,
On 10/08/2012 09:59 AM, Dong Aisheng-B29396 wrote:
> Hi Wolfgang,
>
>> On 10/07/2012 05:09 AM, Shawn Guo wrote:
>>> On Fri, Sep 28, 2012 at 03:17:15PM +0200, Wolfgang Grandegger wrote:
>>>> Due to a bug in most Flexcan cores, the bus error interrupt needs to
>>>> be enabled. Otherwise we don't get any error warning or passive
>>>> interrupts. This is _not_ necessay for the i.MX28 and this patch
>>>> disables bus error interrupts if "berr-reporting" is not requested.
>>>> This avoids bus error flooding, which might harm, especially on
>>>> low-end systems.
>>>>
>>>> To handle such quirks of the Flexcan cores, a hardware feature flag
>>>> has been introduced, also replacing the "hw_ver" variable. So far
>>>> nobody could tell what Flexcan core version is available on what
>>>> Freescale SOC, apart from the i.MX6Q and P1010, and which bugs or
>>>> features are present on the various "hw_rev".
>>>>
>>>> CC: Hui Wang <jason77.wang@gmail.com>
>>>> CC: Shawn Guo <shawn.guo@linaro.org>
>>>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>>>> ---
>>>>
>>>> Concerning the bug, I know that the i.MX35 does have it. Maybe other
>>>> Flexcan cores than on the i.MX28 does *not* have it either. If you
>>>> have a chance, please check on the P1010, i.MX6Q, i.MX51, i.MX53,
>>>> etc.
>>>
>>> >From what I can tell, i.MX35, i.MX51 and i.MX53 use the same version,
>>> so they should all have the bug. And for i.MX6Q, since it uses a
>>> newer version even than i.MX28, I would believe it's affected by the bug.
>>> But I'm copying Dong who should have better knowledge about this to
>>> confirm.
>>
>> Thank for clarification. I have a i.MX6Q board but without CAN adapter :(,
>> unfortunately. Otherwise I would try it out myself.
>>
> How did you verify this issue?
I provoke state changes, e.g. by sending a message without connection to
the bus. On the Mx28, the TWRN_INT/RWRN_INT/(BOFF_INT?) does trigger the
corresponding interrupt. This does not work properly on some other
cores, e.g. the Mx35. Therefore we enable ERR_INT for those cores to
realize state changes.
> I just checked our ic guy of flexcan, it seems he also had no sense of this issue.
>
> Below is some version info what I got:
> Mx6s use FlexCAN3, with IP version 10.00.12.00
> Mx53 use FlexCAN2 (with glitch filter), with IP version 03.00.00.00
> Mx28 use FlexCAN2 (with glitch filter), with IP version 03.00.04.00
> Mx35 use FlexCAN2 (without glitch filter) , with IP version 03.00.00.00
> Mx25 use FlexCAN2 (without glitch filter), with IP version 03.00.00.00
> I'm not sure if mx6q has such issue.
OK, we need to find that out experimentally.
Wolfgang.
^ permalink raw reply
* [ANNOUNCE] libnfnetlink 1.0.1 release
From: Pablo Neira Ayuso @ 2012-10-08 9:04 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
Hi!
The Netfilter project proudly presents:
libnfnetlink 1.0.1
This release contains minor fixes and updates for this library.
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/libnfnetlink/downloads.html
ftp://ftp.netfilter.org/pub/libnfnetlink/
Have fun!
[-- Attachment #2: changes-libnfnetlink-1.0.1.txt --]
[-- Type: text/plain, Size: 1713 bytes --]
Jan Engelhardt (22):
build: use autoconf-suggested naming of files
build: use modern call syntax for AC_INIT, AM_INIT_AUTOMAKE
build: avoid use of deprecated INCLUDES
build: use simpler autoreconf in autogen
build: use AC_CONFIG_MACRO_DIR as directed
build: run AC_CANONICAL_HOST only
build: remove statements without effect
build: remove -fPIC flag
Add .gitignore files
build: use AC_OUTPUT
build: default to not building static libraries
Remove distro-specific parts
src: remove redundant casts
build: remove unused LIBTOOL_DEPS
build: use -Wall across the entire source
utils: resolve compiler warning
nfnl: avoid exit on large packet
build: fix error with automake-1.9
Update .gitignore
build: use AC_CONFIG_AUX_DIR and stash away tools
build: disable implicit .tar.gz archive generation and use POSIX mode
build: remove unnecessary AC_EXEEXT
Jiri Popelka (1):
src: BAD_SIZEOF
Pablo Neira Ayuso (13):
src: add COPYING file that include licensing terms
iftable: fix wrong handler unregistration on error
license: upgrade to GPLv2+
Merge branch 'master' of git://dev.medozas.de/libnfnetlink
build: kernel-like compilation messages
src: update copyright header
utils: iftest: display link state (UP/DOWN)
utils: iftest: pass the device name you want to obtain information for
utils: iftest: check return value of nlif_query
utils: iftest: relax check of nlif_name2index
iftable: fix incomplete list of interfaces via nlif_query
nfnl: fix compilation warning with gcc-4.7
bump version to 1.0.1
^ permalink raw reply
* Re: [PATCH v4] skge: Add DMA mask quirk for Marvell 88E8001 on ASUS P5NSLI motherboard.
From: graham.gower @ 2012-10-08 9:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, shemminger@vyatta.com
In-Reply-To: <20121008.030707.864754447318232909.davem@davemloft.net>
Well its pretty frustrating from my end too.
Fuck it, i dont care enough. I'll just keep patching kernels locally until my hardware expires.
On 08/10/2012, at 5:37 PM, David Miller <davem@davemloft.net> wrote:
> From: Graham Gower <graham.gower@gmail.com>
> Date: Mon, 08 Oct 2012 17:13:24 +1030
>
>> Marvell 88E8001 on an ASUS P5NSLI motherboard is unable to
>> send/receive
>> packets on a system with >4gb ram unless a 32bit DMA mask is used.
>
> Please format this ascii text properly. WHy is there a line
> with just two words surrounded by full nearly 80-column lines?
>
>> + .matches = {
>> + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
>
> THis is still formatted incorrectly, it's actually in the file
> not due to your email client.
>
> Can you indent the thing properly, please?
>
> This is V4 of this patch, and suffering purely from first order coding
> style and procedural stuff. As you can imagine, it's very frustrating
> to have to spend this much time getting such simple things taken care
> of.
^ permalink raw reply
* RE: [PATCH] flexcan: disable bus error interrupts for the i.MX28
From: Dong Aisheng-B29396 @ 2012-10-08 9:13 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Shawn Guo, Linux Netdev List, Linux-CAN, Hui Wang
In-Reply-To: <507296F2.9010402@grandegger.com>
Hi Wolfgang,
>Hi Dong,
>
>On 10/08/2012 09:59 AM, Dong Aisheng-B29396 wrote:
>> Hi Wolfgang,
>>
>>> On 10/07/2012 05:09 AM, Shawn Guo wrote:
>>>> On Fri, Sep 28, 2012 at 03:17:15PM +0200, Wolfgang Grandegger wrote:
>>>>> Due to a bug in most Flexcan cores, the bus error interrupt needs
>>>>> to be enabled. Otherwise we don't get any error warning or passive
>>>>> interrupts. This is _not_ necessay for the i.MX28 and this patch
>>>>> disables bus error interrupts if "berr-reporting" is not requested.
>>>>> This avoids bus error flooding, which might harm, especially on
>>>>> low-end systems.
>>>>>
>>>>> To handle such quirks of the Flexcan cores, a hardware feature flag
>>>>> has been introduced, also replacing the "hw_ver" variable. So far
>>>>> nobody could tell what Flexcan core version is available on what
>>>>> Freescale SOC, apart from the i.MX6Q and P1010, and which bugs or
>>>>> features are present on the various "hw_rev".
>>>>>
>>>>> CC: Hui Wang <jason77.wang@gmail.com>
>>>>> CC: Shawn Guo <shawn.guo@linaro.org>
>>>>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>>>>> ---
>>>>>
>>>>> Concerning the bug, I know that the i.MX35 does have it. Maybe
>>>>> other Flexcan cores than on the i.MX28 does *not* have it either.
>>>>> If you have a chance, please check on the P1010, i.MX6Q, i.MX51,
>>>>> i.MX53, etc.
>>>>
>>>> >From what I can tell, i.MX35, i.MX51 and i.MX53 use the same
>>>> >version,
>>>> so they should all have the bug. And for i.MX6Q, since it uses a
>>>> newer version even than i.MX28, I would believe it's affected by the
>bug.
>>>> But I'm copying Dong who should have better knowledge about this to
>>>> confirm.
>>>
>>> Thank for clarification. I have a i.MX6Q board but without CAN
>>> adapter :(, unfortunately. Otherwise I would try it out myself.
>>>
>> How did you verify this issue?
>
>I provoke state changes, e.g. by sending a message without connection to
>the bus. On the Mx28, the TWRN_INT/RWRN_INT/(BOFF_INT?) does trigger the
>corresponding interrupt. This does not work properly on some other cores,
>e.g. the Mx35. Therefore we enable ERR_INT for those cores to realize
>state changes.
Thanks for the info.
>> I just checked our ic guy of flexcan, it seems he also had no sense of
>this issue.
>>
>> Below is some version info what I got:
>> Mx6s use FlexCAN3, with IP version 10.00.12.00
>> Mx53 use FlexCAN2 (with glitch filter), with IP version 03.00.00.00
>> Mx28 use FlexCAN2 (with glitch filter), with IP version 03.00.04.00
>> Mx35 use FlexCAN2 (without glitch filter) , with IP version
>> 03.00.00.00
>> Mx25 use FlexCAN2 (without glitch filter), with IP version 03.00.00.00
>> I'm not sure if mx6q has such issue.
>
>OK, we need to find that out experimentally.
>
Our IC owner double checked the MX35 and MX53 IP and found the RX_WARN & TX_WARN
Interrupt source actually are not connected to ARM.
That means flexcan will not trigger interrupt to ARM core even RX_WARN or TX_WARN
Happens.
This may be the root cause that why you cannot see RX_WARN interrupt if not enable
bus error interrupt on mx35.
He also checked that mx6q has the rx/tx warning interrupt connected to arm.
So we guess mx6q does not have this issue.
Anyway, we can test to confirm.
Regards
Dong Aisheng
^ permalink raw reply
* BUG: unable to handle kernel NULL pointer dereference in qfq_dequeue()
From: Cong Wang @ 2012-10-08 9:15 UTC (permalink / raw)
To: stephen hemminger; +Cc: Eric Dumazet, David S. Miller, netdev, Thomas Graf
Hi, all,
We got the following kernel crash on RHEL6 and I confirmed upstream has
the same problem (I didn't save this kernel log though):
BUG: unable to handle kernel NULL pointer dereference at
0000000000000010
IP: [<ffffffffa02c3dca>] qfq_dequeue+0x30a/0x490 [sch_qfq]
PGD 1fbed067 PUD 1b103067 PMD 0
Oops: 0000 [#1] SMP
last sysfs
file: /sys/devices/pci0000:00/0000:00:08.0/virtio4/net/eth2/address
CPU 0
Modules linked in: cls_u32 sch_qfq sch_cbq ip6t_REJECT nf_conntrack_ipv6
nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6
virtio_balloon snd_intel8x0 snd_ac97_codec ac97_bus snd_seq
snd_seq_device
snd_pcm snd_timer snd soundcore snd_page_alloc virtio_net i2c_piix4
i2c_core
ext4 mbcache jbd2 virtio_blk virtio_pci virtio_ring virtio pata_acpi
ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod [last
unloaded:
scsi_wait_scan]
Pid: 0, comm: swapper Not tainted 2.6.32-259.el6.x86_64 #1 Red Hat KVM
RIP: 0010:[<ffffffffa02c3dca>] [<ffffffffa02c3dca>] qfq_dequeue
+0x30a/0x490
[sch_qfq]
RSP: 0018:ffff880002203da0 EFLAGS: 00010287
RAX: ffffffffffffffb0 RBX: ffff88001f45e0c0 RCX: 0000000000000029
RDX: fffffe0000000000 RSI: 0000000000000001 RDI: ffff88001f45f718
RBP: ffff880002203de0 R08: 0000000000000007 R09: 0000000225c602e3
R10: 00000000ffffffff R11: dead000000200200 R12: 0000000000000013
R13: ffff88001f124ea8 R14: ffff88001f45f6b8 R15: 0028940000000000
FS: 0000000000000000(0000) GS:ffff880002200000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000010 CR3: 000000001b277000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff81a00000, task
ffffffff81a8d020)
Stack:
ffff88001f45e000 0028900000000000 ffff880002203de0 ffff88001f4fcc00
<d> ffff88001f4fcc00 0000000000000000 0000000000000001 ffff88001ad640c0
<d> ffff880002203e60 ffffffffa02b9c85 ffff88001f4fcc00 ffff88001f4fcc00
Call Trace:
<IRQ>
[<ffffffffa02b9c85>] cbq_dequeue+0x365/0x730 [sch_cbq]
[<ffffffff81456c3f>] __qdisc_run+0x3f/0xe0
[<ffffffff81436c00>] net_tx_action+0x130/0x1c0
[<ffffffff8102b46d>] ? lapic_next_event+0x1d/0x30
[<ffffffff81073d81>] __do_softirq+0xc1/0x1e0
[<ffffffff81096b10>] ? hrtimer_interrupt+0x140/0x250
[<ffffffff8100c24c>] call_softirq+0x1c/0x30
[<ffffffff8100de85>] do_softirq+0x65/0xa0
[<ffffffff81073b65>] irq_exit+0x85/0x90
[<ffffffff81502bc0>] smp_apic_timer_interrupt+0x70/0x9b
[<ffffffff8100bc13>] apic_timer_interrupt+0x13/0x20
<EOI>
[<ffffffff810387cb>] ? native_safe_halt+0xb/0x10
[<ffffffff810149cd>] default_idle+0x4d/0xb0
[<ffffffff81009e06>] cpu_idle+0xb6/0x110
[<ffffffff814e137a>] rest_init+0x7a/0x80
[<ffffffff81c21f7b>] start_kernel+0x424/0x430
[<ffffffff81c2133a>] x86_64_start_reservations+0x125/0x129
[<ffffffff81c21438>] x86_64_start_kernel+0xfa/0x109
Code: 7c 03 50 4d 8b 7e 58 e8 b5 f6 ff ff 48 85 c0 0f 84 3c 01 00 00 41
8b 4e
60 be 01 00 00 00 49 8d 7e 60 48 89 f2 48 d3 e2 48 f7 da <48> 23 50 60
49 39 56
50 0f 84 d6 00 00 00 b8 02 00 00 00 49 89
RIP [<ffffffffa02c3dca>] qfq_dequeue+0x30a/0x490 [sch_qfq]
RSP <ffff880002203da0>
CR2: 0000000000000010
This crash can be easily reproduced in KVM guests by the following
steps:
1. on virt-guest1 setup qdisc with qfq with this script:
http://pastebin.com/BRaSXLzq
2. on virt-guest2 start listening on ports 1234, 1235
# nc -l 1234 > /dev/null 2>&1
# nc -l 1235 > /dev/null 2>&1
3. on virt-guest1 send traffic to virt-guest2
# yes | nc $virt-guest2_ip_addr 1234
# yes | nc $virt-guest2_ip_addr 1235
I am not familiar with qfq qdisc. Any ideas?
Thanks!
^ permalink raw reply
* [ANNOUNCE] libnetfilter_conntrack 1.0.2 release
From: Pablo Neira Ayuso @ 2012-10-08 9:26 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
Hi!
The Netfilter project proudly presents:
libnetfilter_conntrack 1.0.2
This release provides new interfaces to interact with libmnl and
several fixes.
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/libnetfilter_conntrack/downloads.html
ftp://ftp.netfilter.org/pub/libnetfilter_conntrack/
Have fun!
[-- Attachment #2: changes-libnetfilter_conntrack-1.0.2.txt --]
[-- Type: text/plain, Size: 1183 bytes --]
Florian Westphal (1):
snprintf: print conntrack helper name, too
Jan Engelhardt (5):
build: remove unused LDFLAGS
qa: change an if to elseif
build: remove unused -DLIBNETFILTER_CONNTRACK_DIR
Update .gitignore
build: move library flags to CPPFLAGS
Pablo Neira Ayuso (14):
conntrack: add new API to build/parse ctnetlink messages using libmnl
expect: add new API to build/parse ctnetlink messages using libmnl
examples: add example using libmnl and the new low-level API (conntrack)
examples: add example using libmnl and the new low-level API (expectation)
conntrack: add nfct_set_attr_l and ATTR_HELPER_INFO
include: refresh linux_nfnetlink_conntrack.h
conntrack: more verbose debugging for BPF filter generation
conntrack: fix autogenerated BPF code for IPv6 filtering
conntrack: fix BPF code for IPv6 filtering in case of NFCT_FILTER_LOGIC_POSITIVE
expect: fix compilation warning in nfexp_nlmsg_build
expect: missing layer 3 protocol number in NAT information
expect: add example that creates an expectation with NAT
bump version to 1.0.2
update LIBVERSION
^ permalink raw reply
* Re: 3.4.1 and 3.5-rc1 Packet lost at 250Mb/s
From: Nieścierowicz Adam @ 2012-10-08 9:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Netdev
In-Reply-To: <1349677373.21172.2756.camel@edumazet-glaptop>
>
> You should use RPS on eth2/eth3 because they are non multi queue.
>
> Documentation/networking/scaling.txt should give you all the needed
> info
I set processors for rps such as affinity, unfortunately it did not
help
---
cat /sys/class/net/eth{2,3,4,5}/queues/rx-0/rps_cpus
0040
0080
0100
0200
---
CPU affinity http://wklej.org/id/843161/
^ permalink raw reply
* Re: [PATCH] flexcan: disable bus error interrupts for the i.MX28
From: Marc Kleine-Budde @ 2012-10-08 9:31 UTC (permalink / raw)
To: Dong Aisheng-B29396
Cc: Wolfgang Grandegger, Shawn Guo, Linux Netdev List, Linux-CAN,
Hui Wang
In-Reply-To: <7FE21149F4667147B645348EC60578850B2A8D51@039-SN2MPN1-011.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]
On 10/08/2012 11:13 AM, Dong Aisheng-B29396 wrote:
>>> I just checked our ic guy of flexcan, it seems he also had no sense of
>> this issue.
>>>
>>> Below is some version info what I got:
>>> Mx6s use FlexCAN3, with IP version 10.00.12.00
>>> Mx53 use FlexCAN2 (with glitch filter), with IP version 03.00.00.00
>>> Mx28 use FlexCAN2 (with glitch filter), with IP version 03.00.04.00
>>> Mx35 use FlexCAN2 (without glitch filter) , with IP version
>>> 03.00.00.00
>>> Mx25 use FlexCAN2 (without glitch filter), with IP version 03.00.00.00
>>> I'm not sure if mx6q has such issue.
>>
>> OK, we need to find that out experimentally.
>>
> Our IC owner double checked the MX35 and MX53 IP and found the RX_WARN & TX_WARN
> Interrupt source actually are not connected to ARM.
Does this mean it's a SoC problem, not a problem of the ip core?
> That means flexcan will not trigger interrupt to ARM core even RX_WARN or TX_WARN
> Happens.
> This may be the root cause that why you cannot see RX_WARN interrupt if not enable
> bus error interrupt on mx35.
> He also checked that mx6q has the rx/tx warning interrupt connected to arm.
> So we guess mx6q does not have this issue.
> Anyway, we can test to confirm.
What about mx25?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* RE: [PATCH] flexcan: disable bus error interrupts for the i.MX28
From: Dong Aisheng-B29396 @ 2012-10-08 9:42 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Wolfgang Grandegger, Shawn Guo, Linux Netdev List, Linux-CAN,
Hui Wang
In-Reply-To: <50729D73.3050409@pengutronix.de>
>-----Original Message-----
>From: Marc Kleine-Budde [mailto:mkl@pengutronix.de]
>Sent: Monday, October 08, 2012 5:32 PM
>To: Dong Aisheng-B29396
>Cc: Wolfgang Grandegger; Shawn Guo; Linux Netdev List; Linux-CAN; Hui Wang
>Subject: Re: [PATCH] flexcan: disable bus error interrupts for the i.MX28
>Importance: High
>
>On 10/08/2012 11:13 AM, Dong Aisheng-B29396 wrote:
>>>> I just checked our ic guy of flexcan, it seems he also had no sense
>>>> of
>>> this issue.
>>>>
>>>> Below is some version info what I got:
>>>> Mx6s use FlexCAN3, with IP version 10.00.12.00
>>>> Mx53 use FlexCAN2 (with glitch filter), with IP version 03.00.00.00
>>>> Mx28 use FlexCAN2 (with glitch filter), with IP version 03.00.04.00
>>>> Mx35 use FlexCAN2 (without glitch filter) , with IP version
>>>> 03.00.00.00
>>>> Mx25 use FlexCAN2 (without glitch filter), with IP version
>>>> 03.00.00.00 I'm not sure if mx6q has such issue.
>>>
>>> OK, we need to find that out experimentally.
>>>
>> Our IC owner double checked the MX35 and MX53 IP and found the RX_WARN
>> & TX_WARN Interrupt source actually are not connected to ARM.
>
>Does this mean it's a SoC problem, not a problem of the ip core?
>
It's not a problem of ip core, it's about how to use the IP.
I do not know why some i.MX SoCs does not use rx/tx warn interrupts.
>> That means flexcan will not trigger interrupt to ARM core even RX_WARN
>> or TX_WARN Happens.
>> This may be the root cause that why you cannot see RX_WARN interrupt
>> if not enable bus error interrupt on mx35.
>> He also checked that mx6q has the rx/tx warning interrupt connected to
>arm.
>> So we guess mx6q does not have this issue.
>> Anyway, we can test to confirm.
>
>What about mx25?
>
For mx25 and mx28, he could not access it now.
Will check tomorrow.
Regards
Dong Aisheng
^ permalink raw reply
* Re: [patch net] sky2: fix rx filter setup on link up
From: Mirko Lindner @ 2012-10-08 9:44 UTC (permalink / raw)
To: Jiri Pirko
Cc: Stephen Hemminger, netdev@vger.kernel.org, davem@davemloft.net,
linux-kernel@vger.kernel.org
In-Reply-To: <20121004074004.GA6620@minipsycho.orion>
On Thu, 2012-10-04 at 00:40 -0700, Jiri Pirko wrote:
> Tue, Sep 18, 2012 at 02:38:52AM CEST, mlindner@marvell.com wrote:
> >>Mon, Sep 17, 2012 at 06:12:14PM CEST, shemminger@vyatta.com wrote:
> >>>On Mon, 17 Sep 2012 17:10:17 +0200
> >>>Jiri Pirko <jiri@resnulli.us> wrote:
> >>>
> >>>> In my case I have following problem. sky2_set_multicast() sets registers
> >>>> GM_MC_ADDR_H[1-4] correctly to:
> >>>> 0000 0800 0001 0410
> >>>> However, when adapter gets link and sky2_link_up() is called, the values
> >>>> are for some reason different:
> >>>> 0000 0800 0016 0410
> >>>
> >>>Rather than papering over the problem, it would be better to
> >>>trace back what is setting those registers and fix that code.
> >
> >>Yes, I did that. No code at sky2.[ch] is writing to this registers other
> >>than sky2_set_multicast() and sky2_gmac_reset() (I hooked on sky2_write*()).
> >>So I strongly believe this is a HW issue (maybe only issue of my revision
> >>"Yukon-2 EC chip revision 2")
> >
> >I would like to check the registers as soon as I'm back in my office next week and report my findings.
> >Could you also please check the hint from Stephen?
>
> Mirko, did you have a chance to look at this?
>
Sorry Jiri,
I was the last three weeks at a customer's office and not in our lab.
I'll check the issue this week.
Mirko
^ permalink raw reply
* Re: 3.4.1 and 3.5-rc1 Packet lost at 250Mb/s
From: Eric Dumazet @ 2012-10-08 9:47 UTC (permalink / raw)
To: adam.niescierowicz; +Cc: Netdev
In-Reply-To: <9819d6943a7cfddfc8fa49217aa4842e@justnet.pl>
On Mon, 2012-10-08 at 11:29 +0200, Nieścierowicz Adam wrote:
> >
> > You should use RPS on eth2/eth3 because they are non multi queue.
> >
> > Documentation/networking/scaling.txt should give you all the needed
> > info
>
> I set processors for rps such as affinity, unfortunately it did not
> help
>
> ---
> cat /sys/class/net/eth{2,3,4,5}/queues/rx-0/rps_cpus
> 0040
> 0080
> 0100
> 0200
> ---
> CPU affinity http://wklej.org/id/843161/
>
>
I said eth2 and eth3
And you should use cpu11->cpu15 instead of cpu6->cpu9 since they are in
use...
Anyway you dont say where are drops, (ifconfig give us very few drops)
Also your eth0 seems to have a strange balance :
RX interrupts seems to be well balanced on 4 queues :
76: 503 0 169271690 0 0 0 PCI-MSI-edge eth0-rx-0
77: 405 0 0 164532538 0 0 PCI-MSI-edge eth0-rx-1
78: 408 0 0 0 152778723 0 PCI-MSI-edge eth0-rx-2
79: 349 0 0 0 0 155011301 PCI-MSI-edge eth0-rx-3
80: 144 0 443432394 0 0 0 PCI-MSI-edge eth0-tx-0
81: 18 0 0 2043311 0 0 PCI-MSI-edge eth0-tx-1
82: 30 0 0 0 1934537 0 PCI-MSI-edge eth0-tx-2
83: 137 0 0 0 0 1968272 PCI-MSI-edge eth0-tx-3
But TX seems to mostly use queue 0
Packets sent to eth0 are coming from where ?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox