* Re: 3.4.1 and 3.5-rc1 Packet lost at 250Mb/s
From: Andre Tomt @ 2012-10-08 12:59 UTC (permalink / raw)
To: Eric Dumazet; +Cc: adam.niescierowicz, Netdev
In-Reply-To: <5072C7F4.1090002@tomt.net>
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]
On 08. okt. 2012 14:32, Andre Tomt wrote:
> On 08. okt. 2012 14:13, Eric Dumazet wrote:
>> On Mon, 2012-10-08 at 14:00 +0200, Andre Tomt wrote:
>>> On 08. okt. 2012 12:49, Nieścierowicz Adam wrote:
>>>> W dniu 08.10.2012 11:47, Eric Dumazet napisał(a):
>>>>> Anyway you dont say where are drops, (ifconfig give us very few drops)
>>>>
>>>> you can see no losses(drop), but a temporary decline in traffic on the
>>>> interface to 0kb/s
>>>
>>> This sounds very familiar, could it be something similar to:
>>> http://marc.info/?l=linux-netdev&m=134594936016796&w=3
>>>
>>> The chip seems to be of the same family (though not model)
>>
>> Yes, but Adam says 3.4.1 already has a problem, while
>> commit 2cb7a9cc008c25dc03314de563c00c107b3e5432 is in 3.5 only.
> >
>> Since Adam uses Intel e1000e, it could be the BQL related problem.
>
> The other chips have had DMA burst flag enabled for longer, so that he
> sees the same problem in 3.4 while I'm not makes sense. Hmm, as 3.4 is
> when BQL went in (IIRC) it seems very likely that this BQL issue is the
> problem for both of us.
To clarify; I think the DMA burst flag in the driver triggers the BQL
related issue. Judging by the patchwork link for wthresh=1 this seems
very related indeed.
Removing the FLAG2_DMA_BURST flag for 82574 in the driver works for me.
Adam, it might be worth testing out a build on your system too with the
flag removed. If you try the attached patch (for 3.6, probably OK for
3.5) and the problem dissapears, we are probably at least talking about
the same bug.
[-- Attachment #2: e1000e-disable-dma-burst.patch --]
[-- Type: text/x-patch, Size: 1355 bytes --]
diff -Naur linux-3.6.1/drivers/net/ethernet/intel/e1000e/82571.c linux-3.6.1-2/drivers/net/ethernet/intel/e1000e/82571.c
--- linux-3.6.1/drivers/net/ethernet/intel/e1000e/82571.c 2012-10-07 17:41:28.000000000 +0200
+++ linux-3.6.1-2/drivers/net/ethernet/intel/e1000e/82571.c 2012-10-08 14:54:08.853095363 +0200
@@ -2031,8 +2031,7 @@
| FLAG_RESET_OVERWRITES_LAA /* errata */
| FLAG_TARC_SPEED_MODE_BIT /* errata */
| FLAG_APME_CHECK_PORT_B,
- .flags2 = FLAG2_DISABLE_ASPM_L1 /* errata 13 */
- | FLAG2_DMA_BURST,
+ .flags2 = FLAG2_DISABLE_ASPM_L1, /* errata 13 */
.pba = 38,
.max_hw_frame_size = DEFAULT_JUMBO,
.get_variants = e1000_get_variants_82571,
@@ -2049,8 +2048,7 @@
| FLAG_APME_IN_CTRL3
| FLAG_HAS_CTRLEXT_ON_LOAD
| FLAG_TARC_SPEED_MODE_BIT, /* errata */
- .flags2 = FLAG2_DISABLE_ASPM_L1 /* errata 13 */
- | FLAG2_DMA_BURST,
+ .flags2 = FLAG2_DISABLE_ASPM_L1, /* errata 13 */
.pba = 38,
.max_hw_frame_size = DEFAULT_JUMBO,
.get_variants = e1000_get_variants_82571,
@@ -2090,8 +2088,7 @@
.flags2 = FLAG2_CHECK_PHY_HANG
| FLAG2_DISABLE_ASPM_L0S
| FLAG2_DISABLE_ASPM_L1
- | FLAG2_NO_DISABLE_RX
- | FLAG2_DMA_BURST,
+ | FLAG2_NO_DISABLE_RX,
.pba = 32,
.max_hw_frame_size = DEFAULT_JUMBO,
.get_variants = e1000_get_variants_82571,
^ permalink raw reply
* Re: [STABLE][3.0][3.2][Add PATCH] phy/fixed: use an unique MDIO bus name
From: Florian Fainelli @ 2012-10-08 12:52 UTC (permalink / raw)
To: Steven Rostedt; +Cc: David Miller, ben, linux-kernel, stable, gregkh, netdev
In-Reply-To: <1349699954.6755.110.camel@gandalf.local.home>
On Monday 08 October 2012 08:39:14 Steven Rostedt wrote:
> On Sun, 2012-10-07 at 14:56 -0400, David Miller wrote:
>
> > But this change impacted a lot of MDIO drivers and there were
> > regressions that needed to be fixed up the first time this stuff
> > went in.
>
> If it's that big of a deal then we can forget about this fix. I can get
> around it if I tweak my config. Probably just skip the MDIO stuff.
Yes, I think you can just drop the change considering the number of depending
commits.
--
Florian
^ permalink raw reply
* Re: [RFC:PATCH 3.6.0-] net/ipconfig: Extend ipconfig retries to device open
From: Srinivas KANDAGATLA @ 2012-10-08 12:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20121007.001156.294004123796199582.davem@davemloft.net>
On 07/10/12 05:11, David Miller wrote:
> From: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>
> Date: Thu, 4 Oct 2012 16:38:43 +0100
>
>> This patch adds retries to ipconfig at device open, the reason to do
>> this is: Lets say If some mdio bus driver decide to use defered probe
>> when it does not find any phys on the bus. The same mdio-bus driver is
>> re-probed as part of lateinit calls. However ipconfig also fits into
>> lateinit calls, so if ipconfig is called before the re-probe of mdio-bus
>> driver, the mac driver will fail to find a valid PHY on the mdio-bus.
> Real device drivers for real devices should not probe using late
> initcalls.
I agree,
Let me summarize what I did try.
I wanted to use "Defered Probe Feature" which went in 3.4 kernel to
solve a sequencing issue.
So modified Mdio-driver accordingly, mdio-driver decided to defer its
probe for the first-time when It could not detect any PHY's on the BUS.
(second time) device probe is actually called in lateinit call sequence
by "Defered Probe Code".
>
> The whole point of late initcalls is that you can be certain that they
> run after such things.
Yes I agree.
>
> Fix the virus not the symptom.
>
> I'm not applying this patch.
This use-case here is totally possible given that mdio bus can be
independent driver to MAC driver and Vice-versa.
So there might be situation at times that mdio bus driver might depend
on MAC driver, like in my case MAC driver has to setup itself to provide
clock to PHY's on MDIO bus before mdio-bus driver scan phys.
So using "Defered probe" feature for mdio-bus drivers will never work.
Thanks,
srini
^ permalink raw reply
* Re: [STABLE][3.0][3.2][Add PATCH] phy/fixed: use an unique MDIO bus name
From: Steven Rostedt @ 2012-10-08 12:39 UTC (permalink / raw)
To: David Miller; +Cc: ben, linux-kernel, stable, gregkh, florian, netdev
In-Reply-To: <20121007.145622.83624305358947187.davem@davemloft.net>
On Sun, 2012-10-07 at 14:56 -0400, David Miller wrote:
> But this change impacted a lot of MDIO drivers and there were
> regressions that needed to be fixed up the first time this stuff
> went in.
If it's that big of a deal then we can forget about this fix. I can get
around it if I tweak my config. Probably just skip the MDIO stuff.
-- Steve
^ permalink raw reply
* Re: 3.4.1 and 3.5-rc1 Packet lost at 250Mb/s
From: Andre Tomt @ 2012-10-08 12:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: adam.niescierowicz, Netdev
In-Reply-To: <1349698406.21172.3168.camel@edumazet-glaptop>
On 08. okt. 2012 14:13, Eric Dumazet wrote:
> On Mon, 2012-10-08 at 14:00 +0200, Andre Tomt wrote:
>> On 08. okt. 2012 12:49, Nieścierowicz Adam wrote:
>>> W dniu 08.10.2012 11:47, Eric Dumazet napisał(a):
>>>> Anyway you dont say where are drops, (ifconfig give us very few drops)
>>>
>>> you can see no losses(drop), but a temporary decline in traffic on the
>>> interface to 0kb/s
>>
>> This sounds very familiar, could it be something similar to:
>> http://marc.info/?l=linux-netdev&m=134594936016796&w=3
>>
>> The chip seems to be of the same family (though not model)
>
> Yes, but Adam says 3.4.1 already has a problem, while
> commit 2cb7a9cc008c25dc03314de563c00c107b3e5432 is in 3.5 only.
>
> Since Adam uses Intel e1000e, it could be the BQL related problem.
The other chips have had DMA burst flag enabled for longer, so that he
sees the same problem in 3.4 while I'm not makes sense. Hmm, as 3.4 is
when BQL went in (IIRC) it seems very likely that this BQL issue is the
problem for both of us.
> (Not sure if Intel guys finally fixed the problem, if not, its really
> insane)
>
> http://patchwork.ozlabs.org/patch/163298/
Ugh. :)
^ permalink raw reply
* [ANNOUNCE] ulogd 2.0.1 release
From: Pablo Neira Ayuso @ 2012-10-08 12:15 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
Hi!
The Netfilter project proudly presents:
ulogd 2.0.1
This releases includes support for the nfacct extended iptables
accounting infrastructure.
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/ulogd/downloads.html
ftp://ftp.netfilter.org/pub/ulogd/
Have fun!
[-- Attachment #2: changes-ulogd-2.0.1.txt --]
[-- Type: text/plain, Size: 980 bytes --]
Eric Leblond (6):
NFCT: fix crash in polling mode if used by two stacks
nfacct: add variable to not zero counter after read
pgsql schema: add nfacct table
pgsql schema: fix timestamp default value
pgsql: only disable key if it starts with underscore
nfacct: add timestamp option
Michael Tremer (1):
sqlite3: Add more logging if database initialization fails.
Pablo Neira Ayuso (9):
src: add ULOGD_DTYPE_SUM for nfacct-based accounting
output: XML: support for NFACCT input plugin
output: XML: display time for NFACCT
input: NFCT: fix compilation warning with gcc-4.7
src: fix version that -V displays
ulogd.conf: slightly expand documentation on zerocounter option for nfacct
filter: IP2HBIN: fix compilation warning with gcc-4.7
src: update copyright and authors information
bump version to 2.0.1
Thomas Jarosch (1):
ipfix: fix bracket imbalance if IPPROTO_SCTP is defined
^ permalink raw reply
* Re: 3.4.1 and 3.5-rc1 Packet lost at 250Mb/s
From: Eric Dumazet @ 2012-10-08 12:13 UTC (permalink / raw)
To: Andre Tomt; +Cc: adam.niescierowicz, Netdev
In-Reply-To: <5072C063.6000302@tomt.net>
On Mon, 2012-10-08 at 14:00 +0200, Andre Tomt wrote:
> On 08. okt. 2012 12:49, Nieścierowicz Adam wrote:
> > W dniu 08.10.2012 11:47, Eric Dumazet napisał(a):
> >> Anyway you dont say where are drops, (ifconfig give us very few drops)
> >
> > you can see no losses(drop), but a temporary decline in traffic on the
> > interface to 0kb/s
>
> This sounds very familiar, could it be something similar to:
> http://marc.info/?l=linux-netdev&m=134594936016796&w=3
>
> The chip seems to be of the same family (though not model)
Yes, but Adam says 3.4.1 already has a problem, while
commit 2cb7a9cc008c25dc03314de563c00c107b3e5432 is in 3.5 only.
Since Adam uses Intel e1000e, it could be the BQL related problem.
(Not sure if Intel guys finally fixed the problem, if not, its really
insane)
http://patchwork.ozlabs.org/patch/163298/
^ permalink raw reply
* Re: 3.4.1 and 3.5-rc1 Packet lost at 250Mb/s
From: Andre Tomt @ 2012-10-08 12:00 UTC (permalink / raw)
To: adam.niescierowicz; +Cc: Eric Dumazet, Netdev
In-Reply-To: <80bb011e8f1289218087633fd7b115ea@justnet.pl>
On 08. okt. 2012 12:49, Nieścierowicz Adam wrote:
> W dniu 08.10.2012 11:47, Eric Dumazet napisał(a):
>> Anyway you dont say where are drops, (ifconfig give us very few drops)
>
> you can see no losses(drop), but a temporary decline in traffic on the
> interface to 0kb/s
This sounds very familiar, could it be something similar to:
http://marc.info/?l=linux-netdev&m=134594936016796&w=3
The chip seems to be of the same family (though not model)
^ permalink raw reply
* Re: 3.4.1 and 3.5-rc1 Packet lost at 250Mb/s
From: Nieścierowicz Adam @ 2012-10-08 12:06 UTC (permalink / raw)
To: Andre Tomt; +Cc: Eric Dumazet, Netdev
In-Reply-To: <5072C063.6000302@tomt.net>
W dniu 08.10.2012 14:00, Andre Tomt napisał(a):
> On 08. okt. 2012 12:49, Nieścierowicz Adam wrote:
>
>> W dniu 08.10.2012 11:47, Eric Dumazet napisał(a):
>>
>>> Anyway you dont say where are drops, (ifconfig give us very few
>>> drops)
>> you can see no losses(drop), but a temporary decline in traffic on
>> the
>> interface to 0kb/s
>
> This sounds very familiar, could it be something similar to:
> http://marc.info/?l=linux-netdev&m=134594936016796&w=3 [1]
>
> The chip seems to be of the same family (though not model)
In fact it looks similarly.
Here the problem has performed in kernel 3.4.1, 3.5-rcX, and 3.6
^ permalink raw reply
* [ANNOUNCE] conntrack-tools 1.4.0 release
From: Pablo Neira Ayuso @ 2012-10-08 11:50 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
Hi!
The Netfilter project proudly presents:
conntrack-tools 1.4.0
This release adds the user-space helper infrastructure which includes
the RPC portmapper (to support NFSv3) and Oracle*TNS helpers.
More information available at:
http://conntrack-tools.netfilter.org/manual.html
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/conntrack-tools/downloads.html
ftp://ftp.netfilter.org/pub/conntrack-tools/
Have fun!
[-- Attachment #2: changes-conntrack-tools-1.4.0.txt --]
[-- Type: text/plain, Size: 1262 bytes --]
Ansis Atteka (1):
tests: conntrackd: fix compile errors and warnings
Jozsef Kadlecsik (2):
conntrackd: RPC helper added to cthelper
conntrackd: TNS helper added to cthelper
Nicolas Dichtel (1):
build: fix libraries dependencies in Makefiles
Pablo Neira Ayuso (14):
conntrack: add support for stats dumping via ctnetlink
conntrack: -C uses ctnetlink instead of /proc/sys/net/netfilter/nf_conntrack_count
conntrackd: generalize file descriptor infrastructure
conntrackd: move ctnetlink code to ctnl.c (removed from run.c)
conntrackd: add cthelper infrastructure (+ example FTP helper)
tests: conntrackd: add cthelper-test infrastructure
nfct: helper: use CONNTRACKD_LIB_DIR variable set during configuration
cthelper: disable debugging information by default
cthelper: ftp: fix EPRT case for IPv4
conntrackd: parse: fix wrong maximum length for ATTR_EXP_FN
conntrackd: cthelper: add QueueLen option
conntrackd: fix crash if ExpectationSync is enabled on old Linux kernels
doc: detail user-space helper support
bump version to 1.4.0 and update dependencies
Vincent Bernat (1):
conntrackd: don't resync expectations if such sync has been disabled
^ permalink raw reply
* Re: [PATCH] pch_pge: Fix build error by selecting all the possible dependencies.
From: Haicheng Li @ 2012-10-08 11:15 UTC (permalink / raw)
To: Haicheng Li; +Cc: davem, haicheng.li, linux-kernel, netdev, fengguang.wu
In-Reply-To: <1349670580-11158-1-git-send-email-haicheng.lee@gmail.com>
Just realized a typo in the subject, pls. ignore this. will send a new soon.
sorry.
On 10/08/2012 12:29 PM, Haicheng Li wrote:
> Fengguang reported a kernel build failure as folowing:
> drivers/built-in.o: In function `pch_gbe_ioctl':
> pch_gbe_main.c:(.text+0x510370): undefined reference to `pch_ch_control_write'
> pch_gbe_main.c:(.text+0x510393): undefined reference to `pch_ch_control_write'
> pch_gbe_main.c:(.text+0x5103b3): undefined reference to `pch_ch_control_write'
> ..
>
> It's a regression by commit da1586461. The root cause is that
> the CONFIG_PPS is not set there, consequently CONFIG_PTP_1588_CLOCK
> can not be set anyway, which finally causes ptp_pch and pch_gbe_main
> build failures.
>
> As David prefers to use *select* to fix such module co-dependency issues,
> this patch explicitly selects all the possible dependencies of PCH_PTP.
>
> Reported-by: Fengguang Wu<fengguang.wu@intel.com>
> Reviewed-by: David S. Miller<davem@davemloft.net>
> Signed-off-by: Haicheng Li<haicheng.lee@gmail.com>
> ---
> drivers/net/ethernet/oki-semi/pch_gbe/Kconfig | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig b/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig
> index 9730241..5296cc8 100644
> --- a/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig
> +++ b/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig
> @@ -26,6 +26,9 @@ if PCH_GBE
> config PCH_PTP
> bool "PCH PTP clock support"
> default n
> + depends on EXPERIMENTAL
> + select PPS
> + select PTP_1588_CLOCK
> select PTP_1588_CLOCK_PCH
> ---help---
> Say Y here if you want to use Precision Time Protocol (PTP) in the
^ permalink raw reply
* [PATCH v2 3/3] ipv4: Don't report stale pmtu values to userspace
From: Steffen Klassert @ 2012-10-08 10:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1349690144.21172.3024.camel@edumazet-glaptop>
We report cached pmtu values even if they are already expired.
Change this to not report these values after they are expired
and fix a race in the expire time calculation, as suggested by
Eric Dumazet.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/route.c | 19 +++++++++++--------
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 741df67..132e0df 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2187,8 +2187,18 @@ 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) {
+ unsigned long now = jiffies;
+
+ if (time_before(now, expires))
+ expires -= now;
+ 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 +2208,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: 3.4.1 and 3.5-rc1 Packet lost at 250Mb/s
From: Nieścierowicz Adam @ 2012-10-08 10:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Netdev
In-Reply-To: <1349689640.21172.3008.camel@edumazet-glaptop>
W dniu 08.10.2012 11:47, Eric Dumazet napisał(a):
> 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/ [1]
>
> I said eth2 and eth3
>
eth2,eth3 and eth4,eth5 is the same card so I changed them as well, or
made a mistake?
> And you should use cpu11->cpu15 instead of cpu6->cpu9 since they are
> in
> use...
>
I read in the file Documentation/networking/scaling.txt
---
if the rps_cpus for each queue are the ones that
share the same memory domain as the interrupting CPU for that queue
---
so i used the same CPU, I misunderstood?
> Anyway you dont say where are drops, (ifconfig give us very few
> drops)
you can see no losses(drop), but a temporary decline in traffic on the
interface to 0kb/s
>
> 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 ?
Packets come mainly from two routers(Edge BGP and local NAT)
^ permalink raw reply
* [ANNOUNCE] libnetfilter_queue 1.0.2 release
From: Pablo Neira Ayuso @ 2012-10-08 10:49 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
In-Reply-To: <20121008092636.GA15925@1984>
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
Hi!
The Netfilter project proudly presents:
libnetfilter_queue 1.0.2
This release provides new interfaces to interact with libmnl.
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/libnetfilter_queue/downloads.html
ftp://ftp.netfilter.org/pub/libnetfilter_queue/
Have fun!
[-- Attachment #2: changes-libnetfilter_queue-1.0.2.txt --]
[-- Type: text/plain, Size: 731 bytes --]
Jan Engelhardt (3):
build: remove unnecessary AC_EXEEXT
build: remove unused lines in Makefile.am
build: remove stray empty variable
Krishna Kumar (1):
src: implement API to set per-queue flags
Pablo Neira Ayuso (9):
add new libnetfilter_queue API for libmnl
add pkt_buff and protocol helper functions
add mangle functions for IPv4/TCP and IPv4/UDP
extra: pktbuff: pktb_expand_tail return 0 if there is no room in the tail
pktbuff: fix pktb_push, _pull and _put function
src: update doxygen documentation for new API for libmnl
examples: nf-queue: fix compilation warning with gcc-4.7
fix compilation warning in nfq_get_payload
bump version to 1.0.2
^ permalink raw reply
* Re: [PATCH 3/3] ipv4: Don't report stale pmtu values to userspace
From: Steffen Klassert @ 2012-10-08 10:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1349690144.21172.3024.camel@edumazet-glaptop>
On Mon, Oct 08, 2012 at 11:55:44AM +0200, Eric Dumazet wrote:
> On Mon, 2012-10-08 at 10:48 +0200, Steffen Klassert wrote:
> > 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;
>
> Seeing this racy code, we could fix it as well.
Sure, we can :)
>
> jiffies is volatile and can change between the test and subtraction.
>
> So we could in theory get strange result.
>
> I suggest using :
>
> if (expires) {
> unsigned long now = jiffies;
>
> if (time_before(now, expires))
> expires -= now;
> else
> expires = 0;
> }
I'll go with the version above and send an updated patch.
Thanks.
^ permalink raw reply
* Re: [V5 PATCH 0/8] csiostor: Chelsio FCoE offload driver submission
From: James Bottomley @ 2012-10-08 10:25 UTC (permalink / raw)
To: Naresh Kumar Inna
Cc: linux-scsi@vger.kernel.org, Dimitrios Michailidis, Casey Leedom,
netdev@vger.kernel.org, Chethan Seshadri
In-Reply-To: <5072A5C5.6070102@chelsio.com>
On Mon, 2012-10-08 at 15:37 +0530, Naresh Kumar Inna wrote:
> Please let me know if you are expecting any more changes to this driver
> to resume its review. I have addressed all review comments as of the
> last series of patches (below).
No, I don't think so, but please understand that the review talent is
all busy concentrating on the merge window for at least the next week
and a bit, so I won't be able to get them to pay attention until 3.7-rc1
is released.
Thanks,
James
^ permalink raw reply
* Re: [V5 PATCH 0/8] csiostor: Chelsio FCoE offload driver submission
From: Naresh Kumar Inna @ 2012-10-08 10:07 UTC (permalink / raw)
To: JBottomley@parallels.com
Cc: Naresh Kumar Inna, linux-scsi@vger.kernel.org,
Dimitrios Michailidis, Casey Leedom, netdev@vger.kernel.org,
Chethan Seshadri
In-Reply-To: <1348507072-25625-1-git-send-email-naresh@chelsio.com>
Hi James,
Please let me know if you are expecting any more changes to this driver
to resume its review. I have addressed all review comments as of the
last series of patches (below).
Thanks,
Naresh.
On 9/24/2012 10:47 PM, Naresh Kumar Inna wrote:
> This is the initial submission of the Chelsio FCoE offload driver (csiostor)
> to the upstream kernel. This driver currently supports FCoE offload
> functionality over Chelsio T4-based 10Gb Converged Network Adapters.
>
> The following patches contain the driver sources for csiostor driver and
> updates to firmware/hardware header files shared between csiostor,
> cxgb4 (Chelsio T4-based NIC driver) and cxgb4vf (Chelsio T4-based Virtual
> Function NIC driver). The csiostor driver is dependent on these
> header updates. These patches have been generated against scsi 'misc' branch.
>
> csiostor is a low level SCSI driver that interfaces with PCI, SCSI midlayer and
> FC transport subsystems. This driver claims the FCoE PCIe function on
> Chelsio Converged Network Adapters. It relies on firmware events for slow path
> operations like discovery, thereby offloading session management. The driver
> programs firmware via Work Request interfaces for fast path I/O offload
> features.
>
> Version V5 of the patches addresses James's comment, primary among them being
> moving to the lockless version of queuecommand(). Rest of the V5 changes are
> listed in the individual patches.
>
> Here is the brief description of patches:
> [V5 PATCH 1/8]: Updates to header files shared between cxgb4, cxgb4vf and
> csiostor.
> [V5 PATCH 2/8]: Header files part 1.
> [V5 PATCH 3/8]: Header files part 2.
> [V5 PATCH 4/8]: Driver initialization and Work Request services.
> [V5 PATCH 5/8]: FC transport interfaces and mailbox services.
> [V5 PATCH 6/8]: Local and remote port state tracking functionality.
> [V5 PATCH 7/8]: Interrupt handling and fast path I/O functionality.
> [V5 PATCH 8/8]: Hardware interface, Makefile and Kconfig changes.
>
> Naresh Kumar Inna (8):
> cxgb4/cxgb4vf: Chelsio FCoE offload driver submission (common header
> updates).
> csiostor: Chelsio FCoE offload driver submission (headers part 1).
> csiostor: Chelsio FCoE offload driver submission (headers part 2).
> csiostor: Chelsio FCoE offload driver submission (sources part 1).
> csiostor: Chelsio FCoE offload driver submission (sources part 2).
> csiostor: Chelsio FCoE offload driver submission (sources part 3).
> csiostor: Chelsio FCoE offload driver submission (sources part 4).
> csiostor: Chelsio FCoE offload driver submission (sources part 5).
>
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 +-
> drivers/net/ethernet/chelsio/cxgb4/sge.c | 10 +-
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 16 +-
> drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 1 +
> drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 69 +-
> drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 104 +-
> drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 11 +-
> drivers/scsi/Kconfig | 1 +
> drivers/scsi/Makefile | 1 +
> drivers/scsi/csiostor/Kconfig | 19 +
> drivers/scsi/csiostor/Makefile | 11 +
> drivers/scsi/csiostor/csio_attr.c | 804 +++++
> drivers/scsi/csiostor/csio_defs.h | 121 +
> drivers/scsi/csiostor/csio_hw.c | 4395 +++++++++++++++++++++++
> drivers/scsi/csiostor/csio_hw.h | 666 ++++
> drivers/scsi/csiostor/csio_init.c | 1274 +++++++
> drivers/scsi/csiostor/csio_init.h | 158 +
> drivers/scsi/csiostor/csio_isr.c | 624 ++++
> drivers/scsi/csiostor/csio_lnode.c | 2133 +++++++++++
> drivers/scsi/csiostor/csio_lnode.h | 255 ++
> drivers/scsi/csiostor/csio_mb.c | 1769 +++++++++
> drivers/scsi/csiostor/csio_mb.h | 278 ++
> drivers/scsi/csiostor/csio_rnode.c | 889 +++++
> drivers/scsi/csiostor/csio_rnode.h | 141 +
> drivers/scsi/csiostor/csio_scsi.c | 2554 +++++++++++++
> drivers/scsi/csiostor/csio_scsi.h | 342 ++
> drivers/scsi/csiostor/csio_wr.c | 1632 +++++++++
> drivers/scsi/csiostor/csio_wr.h | 512 +++
> drivers/scsi/csiostor/t4fw_api_stor.h | 578 +++
> 29 files changed, 19333 insertions(+), 37 deletions(-)
> create mode 100644 drivers/scsi/csiostor/Kconfig
> create mode 100644 drivers/scsi/csiostor/Makefile
> create mode 100644 drivers/scsi/csiostor/csio_attr.c
> create mode 100644 drivers/scsi/csiostor/csio_defs.h
> create mode 100644 drivers/scsi/csiostor/csio_hw.c
> create mode 100644 drivers/scsi/csiostor/csio_hw.h
> create mode 100644 drivers/scsi/csiostor/csio_init.c
> create mode 100644 drivers/scsi/csiostor/csio_init.h
> create mode 100644 drivers/scsi/csiostor/csio_isr.c
> create mode 100644 drivers/scsi/csiostor/csio_lnode.c
> create mode 100644 drivers/scsi/csiostor/csio_lnode.h
> create mode 100644 drivers/scsi/csiostor/csio_mb.c
> create mode 100644 drivers/scsi/csiostor/csio_mb.h
> create mode 100644 drivers/scsi/csiostor/csio_rnode.c
> create mode 100644 drivers/scsi/csiostor/csio_rnode.h
> create mode 100644 drivers/scsi/csiostor/csio_scsi.c
> create mode 100644 drivers/scsi/csiostor/csio_scsi.h
> create mode 100644 drivers/scsi/csiostor/csio_wr.c
> create mode 100644 drivers/scsi/csiostor/csio_wr.h
> create mode 100644 drivers/scsi/csiostor/t4fw_api_stor.h
>
^ permalink raw reply
* Re: [PATCH 3/3] ipv4: Don't report stale pmtu values to userspace
From: Eric Dumazet @ 2012-10-08 9:55 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20121008084853.GE15622@secunet.com>
On Mon, 2012-10-08 at 10:48 +0200, Steffen Klassert wrote:
> 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;
Seeing this racy code, we could fix it as well.
jiffies is volatile and can change between the test and subtraction.
So we could in theory get strange result.
I suggest using :
if (expires) {
unsigned long now = jiffies;
if (time_before(now, expires))
expires -= now;
else
expires = 0;
}
or
if (expires)
expires = max_t(signed long, 0L, expires - jiffies);
> + else
> + expires = 0;
> + }
> +
^ 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
* 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: [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] 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: 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
* [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
* 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
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