* Re: no reassembly for outgoing packets on RAW socket
From: Patrick McHardy @ 2010-06-04 12:03 UTC (permalink / raw)
To: Jiri Olsa; +Cc: netdev
In-Reply-To: <20100604112708.GA1958@jolsa.lab.eng.brq.redhat.com>
Jiri Olsa wrote:
> hi,
>
> I'd like to be able to sendout a single IP packet with MF flag set.
>
> When using RAW sockets the packet will get stuck in the
> netfilter (NF_INET_LOCAL_OUT nf_defrag_ipv4 reassembly unit)
> and wont ever make it out..
>
> I made a change which bypass the outgoing reassembly for
> RAW sockets, but I'm not sure wether it's too invasive..
That would break reassembly (and thus connection tracking) for cases
where its really intended.
> Is there any standard for RAW sockets behaviour?
> Or another way around? :)
You could use the NOTRACK target to bypass connection tracking.
^ permalink raw reply
* [PATCH net-next-2.6] net: Remove unnecessary net action assertion
From: jamal @ 2010-06-04 12:06 UTC (permalink / raw)
To: davem; +Cc: Herbert Xu, Jiri Pirko, netdev
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
I will followup with another (independent) change on pedit.
cheers,
jamal
[-- Attachment #2: act-nomunge --]
[-- Type: text/plain, Size: 1141 bytes --]
commit 45c644796fe2aa834918b15d7b41e57ccf86c1b3
Author: Jamal Hadi Salim <hadi@cyberus.ca>
Date: Fri Jun 4 06:16:30 2010 -0400
net: Remove unnecessary net action assertion
The extra assertion to allow packet munging only when there are
no other ptypes listening which may have worked around an old bug
is unnecessary. It is sufficient to check if the skb is cloned before
trampling on it. Thanks to Herbert Xu for being persistent and patient
in getting this across.
[Note that cloning checks and assertions are the general rule used
by tc actions (documentation/networking/tc-actions-env-rules.txt)].
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
diff --git a/net/core/dev.c b/net/core/dev.c
index ec01a59..b272752 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2662,9 +2662,6 @@ static inline struct sk_buff *handle_ing(struct sk_buff *skb,
if (*pt_prev) {
*ret = deliver_skb(skb, *pt_prev, orig_dev);
*pt_prev = NULL;
- } else {
- /* Huh? Why does turning on AF_PACKET affect this? */
- skb->tc_verd = SET_TC_OK2MUNGE(skb->tc_verd);
}
switch (ing_filter(skb)) {
^ permalink raw reply related
* Re: [PATCH v2] net: check for refcount if pop a stacked dst_entry
From: Eric Dumazet @ 2010-06-04 12:06 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20100604115737.GA5570@secunet.com>
Le vendredi 04 juin 2010 à 13:57 +0200, Steffen Klassert a écrit :
> xfrm triggers a warning if dst_pop() drops a refcount
> on a noref dst. This patch changes dst_pop() to
> skb_dst_pop(). skb_dst_pop() drops the refcnt only
> on a refcounted dst. Also we don't clone the child
> dst_entry, so it is not refcounted and we can use
> skb_dst_set_noref() in xfrm_output_one().
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> ---
Thanks a lot Steffen !
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* still having r8169 woes with XID 18000000
From: Timo Teräs @ 2010-06-04 12:10 UTC (permalink / raw)
To: françois romieu; +Cc: netdev
Hi,
After fixing the MAC issues earlier, I'm still seeing some weird trouble
with my RTL8169sc/8110sc / XID 18000000 boards.
The box(es) were originally running 2.6.30.x kernel and everything
worked without major problems. But after upgrading to 2.6.32.x (and even
with most of the newer fixes included too), it seems that the sometimes
(not too often) some of the interfaces just won't work after reboot
(cold or hard). It's a 3-in-1 board, and usually when this happens one
of the interfaces won't work but the other two do work.
Whenever an interface is "broken", the following conditions are true:
- forcing it to 10mbit/s and disabling autoneg will make it work
- when it's not working ethtool -S reports rx_errors and align_errors
increasing
- when autoneg is on, ethtool says that "Link Detected: no"
I do see that between the above two kernel versions PHY init code was
introduced for this XID (RTL_GIGA_MAC_VER_05) in commit 2e955856ff. I
wonder if it makes sense trying to revert this. Should the NIC still
work? Do you see any other suspicious commits?
Unrelated, I notice that if I have 1GB links autonegotiated, 'ip link'
will show them as "state UNKNOWN". Forced manual links get "state UP" as
expected. This is for the operstate field.
- Timo
^ permalink raw reply
* Re: [RFC nf-next-2.6] conntrack: per cpu nf_conntrack_untracked
From: Changli Gao @ 2010-06-04 12:10 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, Netfilter Developers, netdev
In-Reply-To: <4C08E62A.9020607@trash.net>
On Fri, Jun 4, 2010 at 7:40 PM, Patrick McHardy <kaber@trash.net> wrote:
> Eric Dumazet wrote:
>> Obviously, an IPS_UNTRACKED bit would be much easier to implement.
>> Would it be acceptable ?
>
> That also would be fine. However the main idea behind using a nfctinfo
> bit was that we wouldn't need the untracked conntrack anymore at all.
> But I guess a per-cpu untrack conntrack would already be an improvement
> over the current situation.
I think Eric didn't mean ip_conntrack_info but ip_conntrack_status
bit. Since we have had a IPS_TEMPLATE bit, I think another
IPS_UNTRACKED bit is also acceptable.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [RFC nf-next-2.6] conntrack: per cpu nf_conntrack_untracked
From: Patrick McHardy @ 2010-06-04 12:29 UTC (permalink / raw)
To: Changli Gao; +Cc: Eric Dumazet, Netfilter Developers, netdev
In-Reply-To: <AANLkTilKEpFTg5bH8d9UE3a3DVJNAGYz10Jgkt6lXtJ0@mail.gmail.com>
Changli Gao wrote:
> On Fri, Jun 4, 2010 at 7:40 PM, Patrick McHardy <kaber@trash.net> wrote:
>> Eric Dumazet wrote:
>>> Obviously, an IPS_UNTRACKED bit would be much easier to implement.
>>> Would it be acceptable ?
>> That also would be fine. However the main idea behind using a nfctinfo
>> bit was that we wouldn't need the untracked conntrack anymore at all.
>> But I guess a per-cpu untrack conntrack would already be an improvement
>> over the current situation.
>
> I think Eric didn't mean ip_conntrack_info but ip_conntrack_status
> bit. Since we have had a IPS_TEMPLATE bit, I think another
> IPS_UNTRACKED bit is also acceptable.
Yes, of course. But using one of these bits implies that we'd still
have the untracked conntrack.
^ permalink raw reply
* Re: [RFC nf-next-2.6] conntrack: per cpu nf_conntrack_untracked
From: Eric Dumazet @ 2010-06-04 12:36 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Changli Gao, Netfilter Developers, netdev
In-Reply-To: <4C08F1A4.2050906@trash.net>
Le vendredi 04 juin 2010 à 14:29 +0200, Patrick McHardy a écrit :
> Changli Gao wrote:
> > On Fri, Jun 4, 2010 at 7:40 PM, Patrick McHardy <kaber@trash.net> wrote:
> >> Eric Dumazet wrote:
> >>> Obviously, an IPS_UNTRACKED bit would be much easier to implement.
> >>> Would it be acceptable ?
> >> That also would be fine. However the main idea behind using a nfctinfo
> >> bit was that we wouldn't need the untracked conntrack anymore at all.
> >> But I guess a per-cpu untrack conntrack would already be an improvement
> >> over the current situation.
> >
> > I think Eric didn't mean ip_conntrack_info but ip_conntrack_status
> > bit. Since we have had a IPS_TEMPLATE bit, I think another
> > IPS_UNTRACKED bit is also acceptable.
>
> Yes, of course. But using one of these bits implies that we'd still
> have the untracked conntrack.
Yes, it was my idea, with a per_cpu untracked conntrack.
I'll submit a patch, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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
* Re: still having r8169 woes with XID 18000000
From: Phil Sutter @ 2010-06-04 12:36 UTC (permalink / raw)
To: Timo Teräs; +Cc: françois romieu, netdev
In-Reply-To: <4C08ED47.1030800@iki.fi>
Hi,
On Fri, Jun 04, 2010 at 03:10:47PM +0300, Timo Teräs wrote:
> After fixing the MAC issues earlier, I'm still seeing some weird trouble
> with my RTL8169sc/8110sc / XID 18000000 boards.
>
> The box(es) were originally running 2.6.30.x kernel and everything
> worked without major problems. But after upgrading to 2.6.32.x (and even
> with most of the newer fixes included too), it seems that the sometimes
> (not too often) some of the interfaces just won't work after reboot
> (cold or hard). It's a 3-in-1 board, and usually when this happens one
> of the interfaces won't work but the other two do work.
>
> Whenever an interface is "broken", the following conditions are true:
> - forcing it to 10mbit/s and disabling autoneg will make it work
> - when it's not working ethtool -S reports rx_errors and align_errors
> increasing
> - when autoneg is on, ethtool says that "Link Detected: no"
This (your last point) is about what we were experiencing at work using
PCI-based Gigabit Realtek NICs. Our solution to the problem was to
switch to a different NIC (Intel e1000), which obviously solves any
problems. ;)
But I've done some tests before, mainly being inspired by these mails:
http://permalink.gmane.org/gmane.linux.network/160136
http://permalink.gmane.org/gmane.linux.network/160280
and after some feedback from the mainboard manufacturer I've tested the
out-of-tree driver Realtek provides (version 6.013.00), which seems to
not have this issue. Very interesting results show up when comparing
6.013 with 6.012 (citing myself):
Comparing r8169-6.013 with it's predecessor 6.012, you'll find a newly
enabled function rtl8169_phy_power_up() as well as some more invocations
of rtl8169_phy_power_down().
This is probably the solution to these (at least in our case) very
sporadic, but highly annoying, problems. In fact, when our NIC didn't
detect any link, it needed a full power-cycle (no success with
reset-button), so almost not workaroundable.
HTH, Phil
^ permalink raw reply
* [PATCH net-next-2.6] net sched: make pedit check for clones instead
From: jamal @ 2010-06-04 12:43 UTC (permalink / raw)
To: davem; +Cc: Herbert Xu, Jiri Pirko, netdev
[-- Attachment #1: Type: text/plain, Size: 198 bytes --]
And here's the second one. I noticed Changli's changes are not yet in
net-next. I will wait for that change to propagate and then send the
fix to pedit that i discussed with Herbert.
cheers,
jamal
[-- Attachment #2: pedit1 --]
[-- Type: text/plain, Size: 806 bytes --]
commit 0697bf778d48d155ef48f652cee8f103db3dcedb
Author: Jamal Hadi Salim <hadi@cyberus.ca>
Date: Fri Jun 4 08:39:47 2010 -0400
net sched: make pedit check for clones instead
Now that the core path doesnt set OK to munge we detect
writable skbs by looking to see if they are cloned.
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c
index fdbd0b7..8d15caf 100644
--- a/net/sched/act_pedit.c
+++ b/net/sched/act_pedit.c
@@ -127,8 +127,7 @@ static int tcf_pedit(struct sk_buff *skb, struct tc_action *a,
int i, munged = 0;
u8 *pptr;
- if (!(skb->tc_verd & TC_OK2MUNGE)) {
- /* should we set skb->cloned? */
+ if (skb_cloned(skb)) {
if (pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) {
return p->tcf_action;
}
^ permalink raw reply related
* Re: [2.6.35-rc1] page alloc failure order:1, mode:0x4020
From: Eric Dumazet @ 2010-06-04 12:53 UTC (permalink / raw)
To: Michael Guntsche; +Cc: linux-kernel, netdev
In-Reply-To: <20100604092025.GA96690@trillian.comsick.at>
Le vendredi 04 juin 2010 à 11:20 +0200, Michael Guntsche a écrit :
> Hi list,
>
> Testing 2.6.35-rc1 on my powerpc based routerboard I saw the following page allocation
> error happening during an apt-get update with a semi loaded wlan
> interface
>
> [309611.189267] __alloc_pages_slowpath: 52 callbacks suppressed
> [309611.194959] gzip: page allocation failure. order:1, mode:0x4020
> [309611.200981] Call Trace:
> [309611.203547] [c399bc50] [c0008144] show_stack+0x48/0x15c (unreliable)
> [309611.210041] [c399bc80] [c006268c] __alloc_pages_nodemask+0x3d4/0x52c
> [309611.216512] [c399bd20] [c008619c] __slab_alloc+0x560/0x570
> [309611.222111] [c399bd60] [c0086a98] __kmalloc_track_caller+0xd4/0x104
> [309611.228505] [c399bd80] [c01dd220] __alloc_skb+0x64/0x124
> [309611.233944] [c399bda0] [c994e034] ath_rxbuf_alloc+0x34/0xbc [ath]
> [309611.240178] [c399bdc0] [c9a1ec9c] ath_rx_tasklet+0x480/0x7c4 [ath9k]
> [309611.246658] [c399be80] [c9a1dae0] ath9k_tasklet+0x114/0x13c [ath9k]
> [309611.253055] [c399bea0] [c002532c] tasklet_action+0x88/0x104
> [309611.258746] [c399bec0] [c0025e30] __do_softirq+0xb4/0x134
> [309611.264261] [c399bf00] [c0005ec4] do_softirq+0x58/0x5c
> [309611.269514] [c399bf10] [c0025c20] irq_exit+0x7c/0x9c
> [309611.274591] [c399bf20] [c0005f64] do_IRQ+0x9c/0xb4
> [309611.279509] [c399bf40] [c00117d8] ret_from_except+0x0/0x14
> [309611.285112] --- Exception: 501 at 0xff31f0c
> [309611.285121] LR = 0xff32548
> [309611.292536] Mem-Info:
> [309611.294899] DMA per-cpu:
> [309611.297528] CPU 0: hi: 42, btch: 7 usd: 18
> [309611.302444] active_anon:1040 inactive_anon:1160 isolated_anon:0
> [309611.302455] active_file:14871 inactive_file:9440 isolated_file:0
> [309611.302467] unevictable:491 dirty:1258 writeback:0 unstable:0
> [309611.302478] free:628 slab_reclaimable:832 slab_unreclaimable:2312
> [309611.302490] mapped:2254 shmem:36 pagetables:202 bounce:0
> [309611.332409] DMA free:2512kB min:1440kB low:1800kB high:2160kB active_anon:4160kB inactive_anon:4640kB active_file:59484kB inactive_file:37760kB unevictable:1964kB isolated(anon):0kB isolated(file):0kB present:130048kB mlocked:1964kB dirty:5032kB writeback:0kB mapped:9016kB shmem:144kB slab_reclaimable:3328kB slab_unreclaimable:9248kB kernel_stack:528kB pagetables:808kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> [309611.372230] lowmem_reserve[]: 0 0 0
> [309611.375835] DMA: 596*4kB 14*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2512kB
> [309611.386215] 24770 total pagecache pages
> [309611.390147] 0 pages in swap cache
> [309611.393559] Swap cache stats: add 0, delete 0, find 0/0
> [309611.398884] Free swap = 0kB
> [309611.401857] Total swap = 0kB
> [309611.411877] 32768 pages RAM
> [309611.414765] 1228 pages reserved
> [309611.418000] 27690 pages shared
> [309611.421147] 8802 pages non-shared
> [309611.424560] SLUB: Unable to allocate memory on node -1 (gfp=0x20)
> [309611.430764] cache: kmalloc-8192, object size: 8192, buffer size: 8192, default order: 3, min order: 1
> [309611.440276] node 0: slabs: 155, objs: 620, free: 0
> [309611.445439] skbuff alloc of size 3872 failed
order-1 allocations are unfortunate, since this hardware should use
order-0 ones if possible, and it seems it was its goal.
3872 (0xF20) comes from
#define IEEE80211_MAX_MPDU_LEN (3840 + FCS_LEN +
(IEEE80211_WEP_IVLEN + \
IEEE80211_WEP_KIDLEN + \
IEEE80211_WEP_CRCLEN))
common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN +
ah->caps.rx_status_len,
min(common->cachelsz, (u16)64));
Then __dev_alloc_skb() adds two more blocs :
NET_SKB_PAD (64 bytes on your platform ?)
sizeof(struct skb_shared_info)
(on 32bit : 0x104 ... oh well that might be the problem : it is rounded
to 0x140)
And ath driver adds common->cachelsz (I dont know its value)
-> more than 4096 bytes
1) Maybe rx_bufsize should not include the roundup() since
ath_rxbuf_alloc() also do an alignment adjustment ?
2) We should try to reduce skb_shared_info by four bytes.
Could you try this patch ?
We make sure rx_bufsize + various overhead <= PAGE_SIZE
But I am not sure its legal for the hardware...
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index ca6065b..0a0dc3a 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -226,10 +226,10 @@ static int ath_rx_edma_init(struct ath_softc *sc, int nbufs)
u32 size;
- common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN +
- ah->caps.rx_status_len,
- min(common->cachelsz, (u16)64));
-
+ size = roundup(IEEE80211_MAX_MPDU_LEN + ah->caps.rx_status_len,
+ min(common->cachelsz, (u16)64));
+ common->rx_bufsize = max_t(u32, size,
+ SKB_MAX_ORDER(NET_SKB_PAD + common->cachelsz, 0));
ath9k_hw_set_rx_bufsize(ah, common->rx_bufsize -
ah->caps.rx_status_len);
^ permalink raw reply related
* Re: still having r8169 woes with XID 18000000
From: Timo Teräs @ 2010-06-04 13:02 UTC (permalink / raw)
To: phil; +Cc: netdev, françois romieu
In-Reply-To: <20100604123641.ED8154CD45@orbit.nwl.cc>
On 06/04/2010 03:36 PM, Phil Sutter wrote:
> On Fri, Jun 04, 2010 at 03:10:47PM +0300, Timo Teräs wrote:
>> After fixing the MAC issues earlier, I'm still seeing some weird trouble
>> with my RTL8169sc/8110sc / XID 18000000 boards.
>>
>> The box(es) were originally running 2.6.30.x kernel and everything
>> worked without major problems. But after upgrading to 2.6.32.x (and even
>> with most of the newer fixes included too), it seems that the sometimes
>> (not too often) some of the interfaces just won't work after reboot
>> (cold or hard). It's a 3-in-1 board, and usually when this happens one
>> of the interfaces won't work but the other two do work.
>>
>> Whenever an interface is "broken", the following conditions are true:
>> - forcing it to 10mbit/s and disabling autoneg will make it work
>> - when it's not working ethtool -S reports rx_errors and align_errors
>> increasing
>> - when autoneg is on, ethtool says that "Link Detected: no"
>
> This (your last point) is about what we were experiencing at work using
> PCI-based Gigabit Realtek NICs. Our solution to the problem was to
> switch to a different NIC (Intel e1000), which obviously solves any
> problems. ;)
>
> But I've done some tests before, mainly being inspired by these mails:
> http://permalink.gmane.org/gmane.linux.network/160136
> http://permalink.gmane.org/gmane.linux.network/160280
> and after some feedback from the mainboard manufacturer I've tested the
> out-of-tree driver Realtek provides (version 6.013.00), which seems to
> not have this issue. Very interesting results show up when comparing
> 6.013 with 6.012 (citing myself):
>
> Comparing r8169-6.013 with it's predecessor 6.012, you'll find a newly
> enabled function rtl8169_phy_power_up() as well as some more invocations
> of rtl8169_phy_power_down().
>
> This is probably the solution to these (at least in our case) very
> sporadic, but highly annoying, problems. In fact, when our NIC didn't
> detect any link, it needed a full power-cycle (no success with
> reset-button), so almost not workaroundable.
Sounds very similar to the problem I have. Thanks for the pointers!
It looks like the r8169 driver does have phy power up code in it, but
it's only executed for specific versions of the chip. Realtek driver
seems to do it unconditionally.
The check seems to be:
if ((tp->mac_version == RTL_GIGA_MAC_VER_11) ||
(tp->mac_version == RTL_GIGA_MAC_VER_12) ||
(tp->mac_version >= RTL_GIGA_MAC_VER_17)) {
I wonder if I should just add my mac version there (_VER_05) and test if
it'll make it better.
- Timo
^ permalink raw reply
* Re: [PATCH net-next-2.6] net sched: make pedit check for clones instead
From: Herbert Xu @ 2010-06-04 13:05 UTC (permalink / raw)
To: jamal; +Cc: davem, Jiri Pirko, netdev
In-Reply-To: <1275655386.3445.62.camel@bigi>
On Fri, Jun 04, 2010 at 08:43:06AM -0400, jamal wrote:
> And here's the second one. I noticed Changli's changes are not yet in
> net-next. I will wait for that change to propagate and then send the
> fix to pedit that i discussed with Herbert.
Thanks Jamal!
BTW, I think this patch should go in first (before the one that
removes the OK2MUNGE setting) to be on the safe side.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* net-next Build error in qlogic driver from randconfig.
From: Andrew Hendry @ 2010-06-04 13:20 UTC (permalink / raw)
To: netdev; +Cc: Amit Kumar Salecha, Anirban Chakraborty
net-next currently gives a build error from a randconfig.
# CONFIG_INET is not set
CONFIG_QLCNIC=m
ERROR: "qlcnicvf_set_ilb_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
ERROR: "qlcnicvf_config_bridged_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
ERROR: "qlcnicvf_config_led" [drivers/net/qlcnic/qlcnic.ko] undefined!
ERROR: "qlcnicvf_clear_ilb_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
ERROR: "qlcnicvf_start_firmware" [drivers/net/qlcnic/qlcnic.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs....
^ permalink raw reply
* Re: net-next Build error in qlogic driver from randconfig.
From: andrew hendry @ 2010-06-04 13:23 UTC (permalink / raw)
To: netdev; +Cc: Amit Kumar Salecha, Anirban Chakraborty
In-Reply-To: <1275657622.8635.13.camel@jaunty>
sorry ignore, i see it just got fixed.
On Fri, Jun 4, 2010 at 11:20 PM, Andrew Hendry <andrew.hendry@gmail.com> wrote:
>
> net-next currently gives a build error from a randconfig.
> # CONFIG_INET is not set
> CONFIG_QLCNIC=m
>
> ERROR: "qlcnicvf_set_ilb_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
> ERROR: "qlcnicvf_config_bridged_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
> ERROR: "qlcnicvf_config_led" [drivers/net/qlcnic/qlcnic.ko] undefined!
> ERROR: "qlcnicvf_clear_ilb_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
> ERROR: "qlcnicvf_start_firmware" [drivers/net/qlcnic/qlcnic.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> make: *** Waiting for unfinished jobs....
>
>
>
^ permalink raw reply
* [PATCH] htb: remove two unnecessary assignments
From: Changli Gao @ 2010-06-04 11:33 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David S. Miller, netdev, Changli Gao
remove two unnecessary assignments
we don't need to assign NULL when initialize structure objects.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/sched/sch_htb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index 0b52b8d..4be8d04 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -1550,7 +1550,6 @@ static const struct Qdisc_class_ops htb_class_ops = {
};
static struct Qdisc_ops htb_qdisc_ops __read_mostly = {
- .next = NULL,
.cl_ops = &htb_class_ops,
.id = "htb",
.priv_size = sizeof(struct htb_sched),
@@ -1561,7 +1560,6 @@ static struct Qdisc_ops htb_qdisc_ops __read_mostly = {
.init = htb_init,
.reset = htb_reset,
.destroy = htb_destroy,
- .change = NULL /* htb_change */,
.dump = htb_dump,
.owner = THIS_MODULE,
};
^ permalink raw reply related
* [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-06-04 13:43 UTC (permalink / raw)
To: ath5k-devel
Cc: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Bob Copeland,
John W. Linville, GeunSik Lim, Greg Kroah-Hartman, Lukas Turek,
Mark Hindley, Johannes Berg, Jiri Kosina, Kalle Valo, Keng-Yu Lin,
Luca Verdesca, Shahar Or, linux-wireless, netdev, linux-kernel
Hi!
Here is the patch to disable ath5k leds support on build stage.
However if the leds support was enabled do not force selection of 802.11 leds layer.
Depency on LEDS_CLASS is kept.
Suggestion given by Pavel Roskin and Bob Copeland applied.
Regards,
--Dima
---
drivers/net/wireless/ath/ath5k/Kconfig | 12 +++++++++---
drivers/net/wireless/ath/ath5k/Makefile | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 22 ++++++++++++++++++++++
drivers/net/wireless/ath/ath5k/base.h | 13 +++++++++----
drivers/net/wireless/ath/ath5k/gpio.c | 2 ++
5 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/Kconfig b/drivers/net/wireless/ath/ath5k/Kconfig
index eb83b7b..29f4572 100644
--- a/drivers/net/wireless/ath/ath5k/Kconfig
+++ b/drivers/net/wireless/ath/ath5k/Kconfig
@@ -1,9 +1,6 @@
config ATH5K
tristate "Atheros 5xxx wireless cards support"
depends on PCI && MAC80211
- select MAC80211_LEDS
- select LEDS_CLASS
- select NEW_LEDS
---help---
This module adds support for wireless adapters based on
Atheros 5xxx chipset.
@@ -18,6 +15,15 @@ config ATH5K
If you choose to build a module, it'll be called ath5k. Say M if
unsure.
+
+config ATH5K_LEDS
+ tristate "Atheros 5xxx wireless cards LEDs support"
+ depends on ATH5K
+ select NEW_LEDS
+ select LEDS_CLASS
+ ---help---
+ Atheros 5xxx LED support.
+
config ATH5K_DEBUG
bool "Atheros 5xxx debugging"
depends on ATH5K
diff --git a/drivers/net/wireless/ath/ath5k/Makefile b/drivers/net/wireless/ath/ath5k/Makefile
index cc09595..6d552dd 100644
--- a/drivers/net/wireless/ath/ath5k/Makefile
+++ b/drivers/net/wireless/ath/ath5k/Makefile
@@ -10,8 +10,8 @@ ath5k-y += phy.o
ath5k-y += reset.o
ath5k-y += attach.o
ath5k-y += base.o
-ath5k-y += led.o
ath5k-y += rfkill.o
ath5k-y += ani.o
ath5k-$(CONFIG_ATH5K_DEBUG) += debug.o
+ath5k-$(CONFIG_ATH5K_LEDS) += led.o
obj-$(CONFIG_ATH5K) += ath5k.o
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 2785946..bb7e09a 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1148,11 +1148,27 @@ struct ath5k_hw {
int ath5k_hw_attach(struct ath5k_softc *sc);
void ath5k_hw_detach(struct ath5k_hw *ah);
+#ifdef CONFIG_ATH5K_LEDS
/* LED functions */
int ath5k_init_leds(struct ath5k_softc *sc);
void ath5k_led_enable(struct ath5k_softc *sc);
void ath5k_led_off(struct ath5k_softc *sc);
void ath5k_unregister_leds(struct ath5k_softc *sc);
+#else
+static inline int ath5k_init_leds(struct ath5k_softc *sc)
+{
+ return 0;
+}
+static inline void ath5k_led_enable(struct ath5k_softc *sc)
+{
+}
+static inline void ath5k_led_off(struct ath5k_softc *sc)
+{
+}
+static inline void ath5k_unregister_leds(struct ath5k_softc *sc)
+{
+}
+#endif
/* Reset Functions */
int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial);
@@ -1233,7 +1249,13 @@ int ath5k_hw_set_slot_time(struct ath5k_hw *ah, unsigned int slot_time);
int ath5k_hw_init_desc_functions(struct ath5k_hw *ah);
/* GPIO Functions */
+#ifdef CONFIG_ATH5K_LEDS
void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state);
+#else
+static inline void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state)
+{
+}
+#endif
int ath5k_hw_set_gpio_input(struct ath5k_hw *ah, u32 gpio);
int ath5k_hw_set_gpio_output(struct ath5k_hw *ah, u32 gpio);
u32 ath5k_hw_get_gpio(struct ath5k_hw *ah, u32 gpio);
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index 56221bc..97b26c1 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -86,6 +86,7 @@ struct ath5k_txq {
#define ATH5K_LED_MAX_NAME_LEN 31
+#ifdef CONFIG_ATH5K_LEDS
/*
* State for LED triggers
*/
@@ -95,6 +96,7 @@ struct ath5k_led
struct ath5k_softc *sc; /* driver state */
struct led_classdev led_dev; /* led classdev */
};
+#endif
/* Rfkill */
struct ath5k_rfkill {
@@ -186,9 +188,6 @@ struct ath5k_softc {
u8 bssidmask[ETH_ALEN];
- unsigned int led_pin, /* GPIO pin for driving LED */
- led_on; /* pin setting for LED on */
-
struct tasklet_struct restq; /* reset tasklet */
unsigned int rxbufsize; /* rx size based on mtu */
@@ -196,7 +195,6 @@ struct ath5k_softc {
spinlock_t rxbuflock;
u32 *rxlink; /* link ptr in last RX desc */
struct tasklet_struct rxtq; /* rx intr tasklet */
- struct ath5k_led rx_led; /* rx led */
struct list_head txbuf; /* transmit buffer */
spinlock_t txbuflock;
@@ -204,7 +202,14 @@ struct ath5k_softc {
struct ath5k_txq txqs[AR5K_NUM_TX_QUEUES]; /* tx queues */
struct ath5k_txq *txq; /* main tx queue */
struct tasklet_struct txtq; /* tx intr tasklet */
+
+
+#ifdef CONFIG_ATH5K_LEDS
+ unsigned int led_pin, /* GPIO pin for driving LED */
+ led_on; /* pin setting for LED on */
+ struct ath5k_led rx_led; /* rx led */
struct ath5k_led tx_led; /* tx led */
+#endif
struct ath5k_rfkill rf_kill;
diff --git a/drivers/net/wireless/ath/ath5k/gpio.c b/drivers/net/wireless/ath/ath5k/gpio.c
index 64a27e7..9e757b3 100644
--- a/drivers/net/wireless/ath/ath5k/gpio.c
+++ b/drivers/net/wireless/ath/ath5k/gpio.c
@@ -25,6 +25,7 @@
#include "debug.h"
#include "base.h"
+#ifdef CONFIG_ATH5K_LEDS
/*
* Set led state
*/
@@ -76,6 +77,7 @@ void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state)
else
AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG, led_5210);
}
+#endif
/*
* Set GPIO inputs
--
1.7.1
^ permalink raw reply related
* Re: still having r8169 woes with XID 18000000
From: Phil Sutter @ 2010-06-04 13:43 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev, françois romieu
In-Reply-To: <4C08F953.1050800@iki.fi>
Hi,
On Fri, Jun 04, 2010 at 04:02:11PM +0300, Timo Teräs wrote:
> > Comparing r8169-6.013 with it's predecessor 6.012, you'll find a newly
> > enabled function rtl8169_phy_power_up() as well as some more invocations
> > of rtl8169_phy_power_down().
> >
> > This is probably the solution to these (at least in our case) very
> > sporadic, but highly annoying, problems. In fact, when our NIC didn't
> > detect any link, it needed a full power-cycle (no success with
> > reset-button), so almost not workaroundable.
>
> Sounds very similar to the problem I have. Thanks for the pointers!
>
> It looks like the r8169 driver does have phy power up code in it, but
> it's only executed for specific versions of the chip. Realtek driver
> seems to do it unconditionally.
Hmm. I actually never looked at the corresponding parts of the
in-tree-driver, but that would have definitely been the next step in
order to fix it.
> The check seems to be:
> if ((tp->mac_version == RTL_GIGA_MAC_VER_11) ||
> (tp->mac_version == RTL_GIGA_MAC_VER_12) ||
> (tp->mac_version >= RTL_GIGA_MAC_VER_17)) {
>
> I wonder if I should just add my mac version there (_VER_05) and test if
> it'll make it better.
Surely worth a try. On the other hand, looking at the sheer mass of
problem reports regarding this driver, making it worse is rather hard to
do I guess. :)
(Good night and) good luck, Phil
^ permalink raw reply
* Re: Is CONFIG_IP_VS_IPV6 still/really dangerous?
From: Julius Volz @ 2010-06-04 14:14 UTC (permalink / raw)
To: Ferenc Wagner; +Cc: netdev, robert.gallagher
In-Reply-To: <87631y3nr3.fsf@tac.ki.iif.hu>
Hi Ferenc,
On Fri, Jun 4, 2010 at 3:56 PM, Ferenc Wagner <wferi@niif.hu> wrote:
> Hi,
>
> In commit fab0de02fb0da83b90cec7fce4294747d86d5c6f CONFIG_IP_VS_IPV6 is
> described as:
>
> Add IPv6 support to IPVS. This is incomplete and might be dangerous.
>
> I agree its implementation is incomplete. But I wonder if it's really
> dangerous in the sense that generic distribution kernels shouldn't
> enable it, because it can break unrelated (eg. IPv4 IPVS) functionality.
>
> What does that warning mean today? Isn't it out of date?
I wrote the IPv6 support back in the day, but never used it
large-scale. Rob Gallagher from HEAnet was doing some bigger
experiments with it, but I'm not sure how far it went. CCing him.
There are probably some other people out there that have tested it
extensively. Maybe try the lvs-users and lvs-devel mailing lists?
http://www.linuxvirtualserver.org/mailing.html
Julius
--
Julius Volz - Site Reliability Engineer
Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1
^ permalink raw reply
* Re: [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: John W. Linville @ 2010-06-04 14:09 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Bob Copeland,
GeunSik Lim, Greg Kroah-Hartman, Lukas Turek, Mark Hindley,
Johannes Berg, Jiri Kosina, Kalle Valo, Keng-Yu Lin,
Luca Verdesca, Shahar Or, linux-wireless, netdev, linux-kernel
In-Reply-To: <4c0804e2.0c3ddf0a.2771.10f7@mx.google.com>
On Thu, Jun 03, 2010 at 10:39:30PM +0300, Dmytro Milinevskyy wrote:
> Hi!
>
> Here is the patch to disable ath5k leds support on build stage.
> However if the leds support was enabled do not force selection of 802.11 leds layer.
> Depency on LEDS_CLASS is kept.
>
> Suggestion given by Pavel Roskin and Bob Copeland applied.
>
> Regards,
>
> --Dima
Needs at least a Signed-off-by line, and preferrably a changelog that
explains what the patch is doing and (especially) why it is necessary.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Is CONFIG_IP_VS_IPV6 still/really dangerous?
From: Ferenc Wagner @ 2010-06-04 13:56 UTC (permalink / raw)
To: Julius Volz; +Cc: netdev
Hi,
In commit fab0de02fb0da83b90cec7fce4294747d86d5c6f CONFIG_IP_VS_IPV6 is
described as:
Add IPv6 support to IPVS. This is incomplete and might be dangerous.
I agree its implementation is incomplete. But I wonder if it's really
dangerous in the sense that generic distribution kernels shouldn't
enable it, because it can break unrelated (eg. IPv4 IPVS) functionality.
What does that warning mean today? Isn't it out of date?
--
Thanks,
Feri.
^ permalink raw reply
* Re: [Patch 2/2] mlx4: add dynamic LRO disable support
From: Ben Hutchings @ 2010-06-04 14:25 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, herbert.xu, nhorman, sgruszka, davem
In-Reply-To: <4C085D45.6040001@redhat.com>
On Fri, 2010-06-04 at 09:56 +0800, Cong Wang wrote:
> On 06/03/10 20:37, Ben Hutchings wrote:
> > On Wed, 2010-06-02 at 23:39 -0400, Amerigo Wang wrote:
> >> This patch adds dynamic LRO diable support for mlx4 net driver.
> >> It also fixes a bug of mlx4, which checks NETIF_F_LRO flag in rx
> >> path without rtnl lock.
> > [...]
> >
> > Is that flag test actually unsafe - and if so, how is testing num_lro
> > any better? Perhaps access to net_device::features should be wrapped
> > with ACCESS_ONCE() to ensure that reads and writes are atomic.
> >
>
> At least, I don't find there is any race with 'num_lro', thus
> no lock is needed.
In both cases there is a race condition but it is harmless so long as
the read and the write are atomic. There is a general assumption in
networking code that this is the case for int and long. Personally I
would prefer to see this made explicit using ACCESS_ONCE(), but I don't
see any specific problem in mlx4 (not that I'm familiar with this driver
either).
Now that I look at the patch again, I see you're using a static (i.e.
global) variable to 'back up' the non-zero (enabled) value of num_lro.
This is introducing a bug! The correct value is apparently set in
mlx4_en_get_profile(); you would need to replicate that.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: 200 millisecond timeouts in TCP
From: Satoru SATOH @ 2010-06-04 15:02 UTC (permalink / raw)
To: Ryousei Takano; +Cc: Ivan Novick, netdev
In-Reply-To: <AANLkTilsYS8P2VqATmasXjjdhjPMMZznIHBByXc1i8cU@mail.gmail.com>
It's possible to tune the RTO min value (rto_min) per route since
2.6.23+. (see also the manual of iproute2, ip(8) )
- satoru
On Fri, Jun 04, 2010 at 03:58:57PM +0900, Ryousei Takano wrote:
> On Fri, Jun 4, 2010 at 7:37 AM, Ivan Novick <novickivan@gmail.com> wrote:
> > Hello,
> >
> > Using tcpdump and systemtap I am seeing that sometimes retransmission
> > of data is sent after waiting 200 milliseconds. However sometimes
> > retransmissions happen quicker.
> >
> > Is there a specifc event that causes these 200 milisec delays to kick
> > in? Are those events identifiable in netstat -s output?
> >
> > Also do you know if the timeout numbers for TCP are configurable parameters?
> >
> The minimum RTO value is fixed to 200 ms. It is useful to make the min/max
> RTO values tunable. For example, reducing the minimum RTO value is effective
> for TCP incast problem [1]. Of course, it may occur spurious retransmissions.
>
> [1] Vijay Vasudevan, et al, Safe and Effective Fine-grained TCP Retransmissions
> for Datacenter Communication, SIGCOMM2009
>
> In Solaris, there are two tunable parameters: tcp_rexmit_interval_min/max.
>
> Do you have plan to introduce sysctl parameters like these to the Linux.
>
> Thanks,
> Ryousei
^ permalink raw reply
* Re: [PATCH] rps: tcp: fix rps_sock_flow_table table updates
From: Tom Herbert @ 2010-06-04 15:15 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20100603.200721.59663365.davem@davemloft.net>
Looks good to me. Thanks Eric.
Tom
On Thu, Jun 3, 2010 at 8:07 PM, David Miller <davem@davemloft.net> wrote:
>
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 03 Jun 2010 21:03:58 +0200
>
> > I believe a moderate SYN flood attack can corrupt RFS flow table
> > (rps_sock_flow_table), making RPS/RFS much less effective.
> ...
> > This patch moves sock_rps_save_rxhash() to a sock locked section,
> > and only for non LISTEN sockets.
>
> This looks good to me.
>
> Tom, please review.
^ permalink raw reply
* [PATCH] act_mirred: don't clone skb when skb isn't shared
From: Changli Gao @ 2010-06-04 13:43 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David S. Miller, netdev, Changli Gao
don't clone skb when skb isn't shared
When the tcf_action is TC_ACT_STOLEN, and the skb isn't shared, we don't need
to clone a new skb. As the skb will be freed after this function returns, we
can use it freely once we get a reference to it.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/sched/act_mirred.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index c0b6863..79d4318 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -169,13 +169,20 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
goto out;
}
- skb2 = skb_act_clone(skb, GFP_ATOMIC);
- if (skb2 == NULL)
- goto out;
+ at = G_TC_AT(skb->tc_verd);
+ if (m->tcf_action == TC_ACT_STOLEN && !skb_shared(skb)) {
+ skb2 = skb_get(skb);
+ skb2->tc_verd = SET_TC_VERD(skb2->tc_verd, 0);
+ skb2->tc_verd = CLR_TC_OK2MUNGE(skb2->tc_verd);
+ skb2->tc_verd = CLR_TC_MUNGED(skb2->tc_verd);
+ } else {
+ skb2 = skb_act_clone(skb, GFP_ATOMIC);
+ if (skb2 == NULL)
+ goto out;
+ }
m->tcf_bstats.bytes += qdisc_pkt_len(skb2);
m->tcf_bstats.packets++;
- at = G_TC_AT(skb->tc_verd);
if (!(at & AT_EGRESS)) {
if (m->tcfm_ok_push)
skb_push(skb2, skb2->dev->hard_header_len);
@@ -185,8 +192,8 @@ static int tcf_mirred(struct sk_buff *skb, struct tc_action *a,
if (m->tcfm_eaction != TCA_EGRESS_MIRROR)
skb2->tc_verd = SET_TC_FROM(skb2->tc_verd, at);
- skb2->dev = dev;
skb2->skb_iif = skb->dev->ifindex;
+ skb2->dev = dev;
dev_queue_xmit(skb2);
err = 0;
^ permalink raw reply related
* Re: [Patch] infiniband: check local reserved ports
From: Roland Dreier @ 2010-06-04 16:04 UTC (permalink / raw)
To: Cong Wang
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Tetsuo Handa,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4C085C9A.30506-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Should this inet_is_reserved_local_port() test apply to all the "port
> > spaces" that this code is handling? I honestly am ignorant of the
> > intended semantics of the new local_reserved_ports stuff, hence my question.
> Yes, but I only found this case, is there any else?
My question was more in the other direction: should this test apply to
all the "port spaces" handled here? From looking at the code, it
appears the answer is yes -- it seems that putting a port in
local_reserved_ports reserves that port for IPv4 and IPv6, UDP, TCP,
SCTP, DCCP, everything, so we should probably reserve all RDMA CM ports too.
--
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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