* Re: linux-2.6.30.1 with gcc-3.4.6 compile error
From: Eric Dumazet @ 2009-07-13 17:29 UTC (permalink / raw)
To: Teck Choon Giam; +Cc: linux-kernel, Linux Netdev List, David S. Miller
In-Reply-To: <9b5c9bb30907130944l3624870ck507f5a9f0f79452b@mail.gmail.com>
Teck Choon Giam a écrit :
> Hi,
>
> Anyone encounter the below error while compiling linux-2.6.30.1 with gcc-3.4.6?
>
> drivers/net/igb/igb_main.c: In function `igb_up':
> drivers/net/igb/igb_main.c:130: sorry, unimplemented: inlining failed
> in call to 'igb_set_rah_pool': function body not available
> drivers/net/igb/igb_main.c:938: sorry, unimplemented: called from here
> drivers/net/igb/igb_main.c:133: sorry, unimplemented: inlining failed
> in call to 'igb_set_vmolr': function body not available
> drivers/net/igb/igb_main.c:939: sorry, unimplemented: called from here
> make[3]: *** [drivers/net/igb/igb_main.o] Error 1
> make[2]: *** [drivers/net/igb] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
>
> This is CentOS 4.x system. While using same configuration to compile
> in CentOS 5.x systems with gcc-4.1.2 do not encounter such error and
> my guess is gcc version issue? Any idea?
>
You are right, this driver cannot compile with gcc-3.4.6 and needs
following patch.
[PATCH] igb: gcc-3.4.6 fix
forward declaration of inline function should be avoided, or
old gcc cannot compile.
Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index be48029..adb09d3 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -127,14 +127,48 @@ static void igb_restore_vlan(struct igb_adapter *);
static void igb_ping_all_vfs(struct igb_adapter *);
static void igb_msg_task(struct igb_adapter *);
static int igb_rcv_msg_from_vf(struct igb_adapter *, u32);
-static inline void igb_set_rah_pool(struct e1000_hw *, int , int);
static void igb_set_mc_list_pools(struct igb_adapter *, int, u16);
static void igb_vmm_control(struct igb_adapter *);
-static inline void igb_set_vmolr(struct e1000_hw *, int);
-static inline int igb_set_vf_rlpml(struct igb_adapter *, int, int);
static int igb_set_vf_mac(struct igb_adapter *adapter, int, unsigned char *);
static void igb_restore_vf_multicasts(struct igb_adapter *adapter);
+static inline void igb_set_vmolr(struct e1000_hw *hw, int vfn)
+{
+ u32 reg_data;
+
+ reg_data = rd32(E1000_VMOLR(vfn));
+ reg_data |= E1000_VMOLR_BAM | /* Accept broadcast */
+ E1000_VMOLR_ROPE | /* Accept packets matched in UTA */
+ E1000_VMOLR_ROMPE | /* Accept packets matched in MTA */
+ E1000_VMOLR_AUPE | /* Accept untagged packets */
+ E1000_VMOLR_STRVLAN; /* Strip vlan tags */
+ wr32(E1000_VMOLR(vfn), reg_data);
+}
+
+static inline int igb_set_vf_rlpml(struct igb_adapter *adapter, int size,
+ int vfn)
+{
+ struct e1000_hw *hw = &adapter->hw;
+ u32 vmolr;
+
+ vmolr = rd32(E1000_VMOLR(vfn));
+ vmolr &= ~E1000_VMOLR_RLPML_MASK;
+ vmolr |= size | E1000_VMOLR_LPE;
+ wr32(E1000_VMOLR(vfn), vmolr);
+
+ return 0;
+}
+
+static inline void igb_set_rah_pool(struct e1000_hw *hw, int pool, int entry)
+{
+ u32 reg_data;
+
+ reg_data = rd32(E1000_RAH(entry));
+ reg_data &= ~E1000_RAH_POOL_MASK;
+ reg_data |= E1000_RAH_POOL_1 << pool;;
+ wr32(E1000_RAH(entry), reg_data);
+}
+
#ifdef CONFIG_PM
static int igb_suspend(struct pci_dev *, pm_message_t);
static int igb_resume(struct pci_dev *);
@@ -5418,43 +5452,6 @@ static void igb_io_resume(struct pci_dev *pdev)
igb_get_hw_control(adapter);
}
-static inline void igb_set_vmolr(struct e1000_hw *hw, int vfn)
-{
- u32 reg_data;
-
- reg_data = rd32(E1000_VMOLR(vfn));
- reg_data |= E1000_VMOLR_BAM | /* Accept broadcast */
- E1000_VMOLR_ROPE | /* Accept packets matched in UTA */
- E1000_VMOLR_ROMPE | /* Accept packets matched in MTA */
- E1000_VMOLR_AUPE | /* Accept untagged packets */
- E1000_VMOLR_STRVLAN; /* Strip vlan tags */
- wr32(E1000_VMOLR(vfn), reg_data);
-}
-
-static inline int igb_set_vf_rlpml(struct igb_adapter *adapter, int size,
- int vfn)
-{
- struct e1000_hw *hw = &adapter->hw;
- u32 vmolr;
-
- vmolr = rd32(E1000_VMOLR(vfn));
- vmolr &= ~E1000_VMOLR_RLPML_MASK;
- vmolr |= size | E1000_VMOLR_LPE;
- wr32(E1000_VMOLR(vfn), vmolr);
-
- return 0;
-}
-
-static inline void igb_set_rah_pool(struct e1000_hw *hw, int pool, int entry)
-{
- u32 reg_data;
-
- reg_data = rd32(E1000_RAH(entry));
- reg_data &= ~E1000_RAH_POOL_MASK;
- reg_data |= E1000_RAH_POOL_1 << pool;;
- wr32(E1000_RAH(entry), reg_data);
-}
-
static void igb_set_mc_list_pools(struct igb_adapter *adapter,
int entry_count, u16 total_rar_filters)
{
^ permalink raw reply related
* Re: [PATCH] NET: Fix locking issues in PPP, 6pack, mkiss and strip line disciplines.
From: David Miller @ 2009-07-13 17:31 UTC (permalink / raw)
To: alan; +Cc: ralf, netdev, guido, paulus, linux-hams, hans
In-Reply-To: <20090713091928.7e89bab8@lxorguk.ukuu.org.uk>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Mon, 13 Jul 2009 09:19:28 +0100
> Historically it went
>
> network bh
> transmit packet
> ldisc layer
> tty write method
>
> and lots of code assumed that.
They still can assume such things. All locking is BH based, all
networking transmit paths occur in BH or with BH's disabled, never in
hardware interrupt context.
Even TX reclaim hardware interrupts that free SKBs reschedule that
work to BH context.
> Today the network bits get kicked off at IRQ level.
That would be news to me :)
Where do you see that in the traces that Ralf posted? His trace was
in fact a TTY receive path via USB:
cpu_idle()
handle_IRQ_event()
uhci_irq()
ftdi_read_bulk_callback()
ftdi_process_read()
tty_flip_buffer()
flush_to_ldisc()
mkiss_receive_buf()
spin_lock_bh() --> BH disable in hard IRQ, OH NOEZ!
And, as Ralf's changelog stated:
--------------------
The issue was, that the locking code in mkiss was assuming it was only
ever being called in process or bh context. Fixed by converting the
involved locking code to use irq-safe locks.
--------------------
mkiss_receive_buf(), the problematic code path, is invoked by
the TTY layer directly from LDISC flushing and the TTY device's
IRQ handler here.
How does networking's TX policy have anything to do with this?
^ permalink raw reply
* Re: [PATCH] gre: copy ToS/DiffServ bits to outer IP header
From: David Miller @ 2009-07-13 17:44 UTC (permalink / raw)
To: aj; +Cc: netdev, kuznet, kaber
In-Reply-To: <20090713133225.GA20946@urbino.open.ch>
From: Andreas Jaggi <aj@open.ch>
Date: Mon, 13 Jul 2009 15:32:25 +0200
> @@ -24,6 +24,7 @@
> #define GRE_REC __constant_htons(0x0700)
> #define GRE_FLAGS __constant_htons(0x00F8)
> #define GRE_VERSION __constant_htons(0x0007)
> +#define GRE_COPY_TOS __constant_htons(0x0008)
>
> struct ip_tunnel_parm
> {
This seems dangerious, and unnecessary.
If some future RFC defines this flag, we'll have to change
this and add ugly compat code to keep older tools working.
Why not just create a new IFLA_GRE_* attribute to pass in
flags like this that purely are private to the GRE Linux
tunnel driver and have nothing to do with values defined
by GRE tunnel headers at all?
I'm definitely not applying this as-is.
^ permalink raw reply
* Re: use after free bug in socket code
From: Oliver Hartkopp @ 2009-07-13 17:46 UTC (permalink / raw)
To: Lothar Waßmann
Cc: Herbert Xu, davem, netdev, urs.thuermann, Urs Thuermann
In-Reply-To: <19035.23045.386506.297464@ipc1.ka-ro>
Lothar Waßmann wrote:
> Herbert Xu writes:
>> Lothar Waßmann <LW@karo-electronics.de> wrote:
>>> So, could you point me to the place where the reference count of the
>>> socket object is being incremented when a struct sock is associated
>>> with it?
>> It's implicit. Anyway, you should remodel your release function
>> on a working protocol.
>>
> OK. I checked the release functions of the can raw and bcm protocols
> and found that they obviously are the culprits since they lack the
> call to sock_orphan that other network protocol drivers have:
>
> diff -ur linux-2.6.30/net/can/bcm.c linux-2.6.30-karo/net/can/bcm.c
> --- linux-2.6.30/net/can/bcm.c 2009-06-10 05:05:27.000000000 +0200
> +++ linux-2.6.30-karo/net/can/bcm.c 2009-07-12 20:12:38.000000000 +0200
> @@ -1469,6 +1469,9 @@
> bo->ifindex = 0;
> }
>
> + sock_orphan(sk);
> + sock->sk = NULL;
> +
> release_sock(sk);
> sock_put(sk);
>
> diff -ur linux-2.6.30/net/can/raw.c linux-2.6.30-karo/net/can/raw.c
> --- linux-2.6.30/net/can/raw.c 2009-06-10 05:05:27.000000000 +0200
> +++ linux-2.6.30-karo/net/can/raw.c 2009-07-12 20:12:29.000000000 +0200
> @@ -306,6 +306,9 @@
> ro->bound = 0;
> ro->count = 0;
>
> + sock_orphan(sk);
> + sock->sk = NULL;
> +
> release_sock(sk);
> sock_put(sk);
>
>
>
> Could someone of the CAN-Folks comment on this?
Hello Lothar,
unfortunately i did not get any answer from Urs so far, who originally created
these lines of code.
But from what i was able to get from browsing similar code in the Kernel that
at least sock_orphan() is called in the appropriate socket release functions,
which is indeed not done by the mentioned PF_CAN protocols right now.
I assume you already tested this patch (at least with CAN_RAW) successfully,
right?
If so, i would have no objections to add my Acked-by to these changes.
Would you like to prepare a proper patch and post it on netdev?
Thanks for digging that issue!
Best regards,
Oliver
ps. This code section was stable for more than three years now. Can you tell
me, how you kicked your system to run into this problem?
^ permalink raw reply
* Re: [PATCH v2] Receive Packet Steering
From: David Miller @ 2009-07-13 17:49 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <65634d660905032103h614225dbg9911e290f5537fbf@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Sun, 3 May 2009 21:03:01 -0700
> @@ -758,6 +758,8 @@ struct net_device
> void *ax25_ptr; /* AX.25 specific data */
> struct wireless_dev *ieee80211_ptr; /* IEEE 802.11 specific data,
> assign before registering */
> + u16 *rps_map;
> + int rps_map_len;
>
> /*
> * Cache line mostly used on receive path (including eth_type_trans())
So essentially this table is a user defined (via sysctl) group of cpus
among which to distribute incoming traffic for a device, right?
Why not take this to it's logical end point, which is to monitor
transmits using a tiny flow lookup table, and map receives of the same
flow to the same cpu?
You can even "cheat" and not store the whole flow key in the small
lookup table, just use the resulting hash value as the key. Also,
if "best effort" is considered OK you can even do away with hash
chaining as well, further decreasing the space cost of the table.
If your goal is to steer traffic to the cpu on which the receiving
application is operating, that seems to me to be the only way to
reliably and consistently hit that target.
^ permalink raw reply
* Re: use after free bug in socket code
From: David Miller @ 2009-07-13 17:54 UTC (permalink / raw)
To: oliver; +Cc: LW, herbert, netdev, urs.thuermann, urs
In-Reply-To: <4A5B730B.8090902@hartkopp.net>
From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Mon, 13 Jul 2009 19:46:51 +0200
> But from what i was able to get from browsing similar code in the Kernel that
> at least sock_orphan() is called in the appropriate socket release functions,
> which is indeed not done by the mentioned PF_CAN protocols right now.
>
> I assume you already tested this patch (at least with CAN_RAW) successfully,
> right?
>
> If so, i would have no objections to add my Acked-by to these changes.
>
> Would you like to prepare a proper patch and post it on netdev?
Indeed, please do make such a formal submission once properly tested.
Thanks!
^ permalink raw reply
* Re: [PATCH] atlx: duplicate testing of MCAST flag
From: David Miller @ 2009-07-13 18:03 UTC (permalink / raw)
To: jcliburn; +Cc: roel.kluin, atl1-devel, akpm, netdev
In-Reply-To: <3400f2f60907121704s105ba16bqebcdb75bc855888e@mail.gmail.com>
From: "J. K. Cliburn" <jcliburn@gmail.com>
Date: Sun, 12 Jul 2009 19:04:20 -0500
> On Sun, Jul 12, 2009 at 6:12 PM, Roel Kluin<roel.kluin@gmail.com> wrote:
>> Fix duplicate testing of MCAST flag
>>
>> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> Acked-by: Jay Cliburn <jcliburn@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: linux-2.6.30.1 with gcc-3.4.6 compile error
From: David Miller @ 2009-07-13 18:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: giamteckchoon, linux-kernel, netdev
In-Reply-To: <4A5B6F12.6030101@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 13 Jul 2009 19:29:54 +0200
> [PATCH] igb: gcc-3.4.6 fix
>
> forward declaration of inline function should be avoided, or
> old gcc cannot compile.
>
> Reported-by: Teck Choon Giam <giamteckchoon@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks a lot Eric.
^ permalink raw reply
* Re: [ofa-general][PATCH] mlx4_core: Synch catastrophic flow with module unload
From: David Miller @ 2009-07-13 18:14 UTC (permalink / raw)
To: yevgenyp; +Cc: rdreier, general, netdev
In-Reply-To: <4A5B5274.2020801@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Mon, 13 Jul 2009 18:27:48 +0300
> There is a race condition when the mlx4_core module is being unloaded
> during the execution of restart task due to catastrophic error.
> Added a global mutex that synchs those operations. If the catastrophic task
> tries to catch the mutex, and it is already taken, it means that somebody is unloading the
> module, and there is no point in executing the restart operation.
> If the unload function tries to catch the mutex and it is taken,
> it would wait for the catas task to finish and then unload the module.
>
> Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: Rename lookup_neigh_params function
From: David Miller @ 2009-07-13 18:17 UTC (permalink / raw)
To: klto; +Cc: netdev
In-Reply-To: <1247475220-20518-1-git-send-email-klto@zhaw.ch>
From: Tobias Klauser <klto@zhaw.ch>
Date: Mon, 13 Jul 2009 10:53:40 +0200
> Rename lookup_neigh_params to lookup_neigh_parms as the struct is named
> neigh_parms and all other functions dealing with the struct carry
> neigh_parms in their names.
>
> Signed-off-by: Tobias Klauser <klto@zhaw.ch>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] c/r: Add AF_INET support (v3)
From: John Dykstra @ 2009-07-13 19:02 UTC (permalink / raw)
To: Dan Smith; +Cc: containers, netdev, Oren Laaden, Alexey Dobriyan
In-Reply-To: <1246994776-1882-3-git-send-email-danms@us.ibm.com>
On Tue, 2009-07-07 at 12:26 -0700, Dan Smith wrote:
> Changes in v2:
> - Check for data in the TCP out-of-order queue and fail if present
Why? It seems that this would cause checkpoints to fail unexpectedly,
and is probably unnecessary in a migration scenario, because the peer
will retransmit the segments given appropriate ACKs.
-- John
^ permalink raw reply
* Re: [PATCH 2/2] c/r: Add AF_INET support (v3)
From: Dan Smith @ 2009-07-13 19:10 UTC (permalink / raw)
To: John Dykstra; +Cc: containers, netdev, Oren Laaden, Alexey Dobriyan
In-Reply-To: <1247511728.15106.1.camel@merlyn>
JD> Why? It seems that this would cause checkpoints to fail
JD> unexpectedly,
Well, there are other places where the checkpoint will fail with EBUSY
because something is in a transitional state.
JD> and is probably unnecessary in a migration scenario, because the
JD> peer will retransmit the segments given appropriate ACKs.
Cool, sounds like we can punt on this particular one... Thanks :)
--
Dan Smith
IBM Linux Technology Center
email: danms@us.ibm.com
^ permalink raw reply
* Re: [PATCH] NET: Fix locking issues in PPP, 6pack, mkiss and strip line disciplines.
From: Alan Cox @ 2009-07-13 19:27 UTC (permalink / raw)
To: David Miller; +Cc: ralf, netdev, guido, paulus, linux-hams, hans
In-Reply-To: <20090713.103139.188324296.davem@davemloft.net>
> spin_lock_bh() --> BH disable in hard IRQ, OH NOEZ!
No I didn't see his original message just the patch - his original is a
fixed bug.
> mkiss_receive_buf(), the problematic code path, is invoked by
> the TTY layer directly from LDISC flushing and the TTY device's
> IRQ handler here.
>
> How does networking's TX policy have anything to do with this?
Sorry I'd been looking at the other side stuff with ppp which is a
sleeping v bh issue and misinterpreted Ralf's post.
In fact Ralf's fix isn't needed. The incorrect uses of tty->low_latency
all got killed and the pty code got rewritten which was the other case
that could occur.
^ permalink raw reply
* Re: [ofa-general][PATCH] mlx4_core: Synch catastrophic flow with module unload
From: Roland Dreier @ 2009-07-13 19:45 UTC (permalink / raw)
To: David Miller; +Cc: yevgenyp, general, netdev
In-Reply-To: <20090713.111407.196601373.davem@davemloft.net>
> Applied, thanks.
Dave, please don't apply mlx4_core patches without giving me a chance to
review them. In this case the patch looks buggy to me: I don't see how
it handles, say, hot remove of one device -- it only handles module
removal. And I would hope we could fix this without adding a global
symbol as namespace polluting as "drv_mutex".
Yevgeny didn't even send this patch to you; he just cc'ed netdev as a
courtesy. However I understand that the physical location of mlx4_core
in drivers/net makes it easy to do this. Maybe this is the best
argument in favor of moving the mlx4_core stuff to drivers/shared?
- R.
^ permalink raw reply
* Re: [ofa-general][PATCH] mlx4_core: Synch catastrophic flow with module unload
From: David Miller @ 2009-07-13 20:09 UTC (permalink / raw)
To: rdreier; +Cc: netdev, general
In-Reply-To: <adak52cv02r.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Mon, 13 Jul 2009 12:45:32 -0700
> > Applied, thanks.
>
> Dave, please don't apply mlx4_core patches without giving me a chance to
> review them. In this case the patch looks buggy to me: I don't see how
> it handles, say, hot remove of one device -- it only handles module
> removal. And I would hope we could fix this without adding a global
> symbol as namespace polluting as "drv_mutex".
>
> Yevgeny didn't even send this patch to you; he just cc'ed netdev as a
> courtesy. However I understand that the physical location of mlx4_core
> in drivers/net makes it easy to do this. Maybe this is the best
> argument in favor of moving the mlx4_core stuff to drivers/shared?
If it gets sent to netdev, it's for a networking driver, and it says
"PATCH" rather than "RFC" or "please review" or "don't apply" you
cannot reasonably expect me to not look into applying the thing.
And if you're saying that patches for this device should start not
going through me, and the tactic to accomplish that is to move the
bulk of the driver into some driver/shared area, that's really weird.
Anyways I didn't push the patch out to kernel.org yet so it's easy for
me to remove it.
^ permalink raw reply
* [PATCH 2/4] drivers/net/wireless: adjust NULL test
From: Julia Lawall @ 2009-07-13 20:44 UTC (permalink / raw)
To: netdev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Clearly bss cannot be NULL at the point of the test. The just allocated
bss->bss is more appropriate to test at this point.
A simplified version of the semantic match that finds this problem is as
follows: (http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@r@
expression x,E,E1;
identifier f,l;
position p1,p2;
@@
*x@p1->f = E1;
... when != x = E
when != goto l;
(
*x@p2 == NULL
|
*x@p2 != NULL
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/iwmc3200wifi/rx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
index 3909477..453fcb2 100644
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -698,7 +698,7 @@ static int iwm_mlme_update_bss_table(struct iwm_priv *iwm, u8 *buf,
}
bss->bss = kzalloc(bss_len, GFP_KERNEL);
- if (!bss) {
+ if (!bss->bss) {
kfree(bss);
IWM_ERR(iwm, "Couldn't allocate bss\n");
return -ENOMEM;
^ permalink raw reply related
* [PATCH 2/2] NET: sungem, use spin_trylock_irqsave
From: Jiri Slaby @ 2009-07-13 21:23 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Jiri Slaby
In-Reply-To: <1247520220-31960-1-git-send-email-jirislaby@gmail.com>
Use spin_trylock_irqsave instead of open-coded
local_irq_save+spin_trylock.
Impact: cleanup
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
---
drivers/net/sungem.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/sungem.c b/drivers/net/sungem.c
index d2dfe0a..22474a8 100644
--- a/drivers/net/sungem.c
+++ b/drivers/net/sungem.c
@@ -1032,10 +1032,8 @@ static int gem_start_xmit(struct sk_buff *skb, struct net_device *dev)
(csum_stuff_off << 21));
}
- local_irq_save(flags);
- if (!spin_trylock(&gp->tx_lock)) {
+ if (!spin_trylock_irqsave(&gp->tx_lock)) {
/* Tell upper layer to requeue */
- local_irq_restore(flags);
return NETDEV_TX_LOCKED;
}
/* We raced with gem_do_stop() */
--
1.6.3.2
^ permalink raw reply related
* [PATCH 1/2] NET: phy_device, fix lock imbalance
From: Jiri Slaby @ 2009-07-13 21:23 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Jiri Slaby
Don't forget to unlock a mutex in phy_scan_fixups on a fail path.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
---
drivers/net/phy/phy_device.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index eba937c..b10fedd 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -134,8 +134,10 @@ int phy_scan_fixups(struct phy_device *phydev)
err = fixup->run(phydev);
- if (err < 0)
+ if (err < 0) {
+ mutex_unlock(&phy_fixup_lock);
return err;
+ }
}
}
mutex_unlock(&phy_fixup_lock);
--
1.6.3.2
^ permalink raw reply related
* Re: [ofa-general][PATCH] mlx4_core: Synch catastrophic flow with module unload
From: Roland Dreier @ 2009-07-13 21:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, general
In-Reply-To: <20090713.130936.41603615.davem@davemloft.net>
> If it gets sent to netdev, it's for a networking driver, and it says
> "PATCH" rather than "RFC" or "please review" or "don't apply" you
> cannot reasonably expect me to not look into applying the thing.
> And if you're saying that patches for this device should start not
> going through me, and the tactic to accomplish that is to move the
> bulk of the driver into some driver/shared area, that's really weird.
Well, first of all, if a driver, networking or not, has an active
maintainer, I would expect you to give that maintainer a chance to look
at any not-totally-trivial patches affecting that driver.
But in this case, mlx4_core (as opposed to mlx4_en from the same
drivers/net/mlx4 directory) really is not a network driver -- it is a
low-level multiplexer for access to hardware that really is more
InfiniBand than ethernet (with a dash of Fibre Channel thrown in). And
yes, I am saying that making it clearer that mlx4_core is not an
network driver by moving the source to a more appropriate place does
seem to make sense.
> Anyways I didn't push the patch out to kernel.org yet so it's easy for
> me to remove it.
Thanks.
- R.
^ permalink raw reply
* Re: [PATCH v2] Receive Packet Steering
From: Tom Herbert @ 2009-07-13 22:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090713.104950.121936768.davem@davemloft.net>
On Mon, Jul 13, 2009 at 10:49 AM, David Miller <davem@davemloft.net> wrote:
>
> From: Tom Herbert <therbert@google.com>
> Date: Sun, 3 May 2009 21:03:01 -0700
>
> > @@ -758,6 +758,8 @@ struct net_device
> > void *ax25_ptr; /* AX.25 specific data */
> > struct wireless_dev *ieee80211_ptr; /* IEEE 802.11 specific data,
> > assign before registering */
> > + u16 *rps_map;
> > + int rps_map_len;
> >
> > /*
> > * Cache line mostly used on receive path (including eth_type_trans())
>
> So essentially this table is a user defined (via sysctl) group of cpus
> among which to distribute incoming traffic for a device, right?
Yes. It's a simple static table.
>
> Why not take this to it's logical end point, which is to monitor
> transmits using a tiny flow lookup table, and map receives of the same
> flow to the same cpu?
Is it better do use transmits, or monitor where recvmsg was called?
>
> You can even "cheat" and not store the whole flow key in the small
> lookup table, just use the resulting hash value as the key. Also,
> if "best effort" is considered OK you can even do away with hash
> chaining as well, further decreasing the space cost of the table.
Right. In fact, just using the hash as the key is what you want when
device provides the hash (i.e. Toeplitz). The caveat is that we
should to prevent OOO packets when threads migrate, I think I have a
reasonable solution for that following your earlier suggestion.
I hope to have a new patch soon for steering packets to application
CPU and using device hash, thanks for bugging me on it!
>
> If your goal is to steer traffic to the cpu on which the receiving
> application is operating, that seems to me to be the only way to
> reliably and consistently hit that target.
^ permalink raw reply
* [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
From: Tomas Winkler @ 2009-07-13 22:09 UTC (permalink / raw)
To: drzeus-list, netdev, linux-wireless, linux-kernel; +Cc: Tomas Winkler
1. add intel's sdio vendor id to sdio_ids.h
2. move iwmc3200 sdio devices ids to sdio_ids.h
This patch is against 2.6.31-rc2
7638d5322bd89d49e013a03fe2afaeb6d214fabd
Cc:inaky.perez-gonzalez@intel.com
Cc:cindy.h.kao@intel.com
Cc:samuel.ortiz@intel.com
Cc:yi.zhu@intel.com
Cc:drzeus-list@drzeus.cx
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
drivers/net/wimax/i2400m/sdio.c | 10 ++++------
drivers/net/wireless/iwmc3200wifi/sdio.c | 4 +++-
drivers/net/wireless/iwmc3200wifi/sdio.h | 3 ---
include/linux/mmc/sdio_ids.h | 5 +++++
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wimax/i2400m/sdio.c b/drivers/net/wimax/i2400m/sdio.c
index 2538825..3dc1990 100644
--- a/drivers/net/wimax/i2400m/sdio.c
+++ b/drivers/net/wimax/i2400m/sdio.c
@@ -58,6 +58,7 @@
*/
#include <linux/debugfs.h>
+#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio.h>
#include <linux/mmc/sdio_func.h>
#include "i2400m-sdio.h"
@@ -501,14 +502,11 @@ void i2400ms_remove(struct sdio_func *func)
d_fnend(3, dev, "SDIO func %p\n", func);
}
-enum {
- I2400MS_INTEL_VID = 0x89,
-};
-
static
const struct sdio_device_id i2400ms_sdio_ids[] = {
- /* Intel: i2400m WiMAX over SDIO */
- { SDIO_DEVICE(I2400MS_INTEL_VID, 0x1402) },
+ /* Intel: i2400m WiMAX (iwm3200) over SDIO */
+ { SDIO_DEVICE(SDIO_VENDOR_ID_INTEL,
+ SDIO_DEVICE_ID_INTEL_IWMC3200WIMAX) },
{ }, /* end: all zeroes */
};
MODULE_DEVICE_TABLE(sdio, i2400ms_sdio_ids);
diff --git a/drivers/net/wireless/iwmc3200wifi/sdio.c b/drivers/net/wireless/iwmc3200wifi/sdio.c
index 9166818..995a3f6 100644
--- a/drivers/net/wireless/iwmc3200wifi/sdio.c
+++ b/drivers/net/wireless/iwmc3200wifi/sdio.c
@@ -65,6 +65,7 @@
#include <linux/kernel.h>
#include <linux/netdevice.h>
#include <linux/debugfs.h>
+#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio.h>
#include <linux/mmc/sdio_func.h>
@@ -492,7 +493,8 @@ static void iwm_sdio_remove(struct sdio_func *func)
}
static const struct sdio_device_id iwm_sdio_ids[] = {
- { SDIO_DEVICE(SDIO_VENDOR_ID_INTEL, SDIO_DEVICE_ID_IWM) },
+ { SDIO_DEVICE(SDIO_VENDOR_ID_INTEL,
+ SDIO_DEVICE_ID_INTEL_IWMC3200WIFI) },
{ /* end: all zeroes */ },
};
MODULE_DEVICE_TABLE(sdio, iwm_sdio_ids);
diff --git a/drivers/net/wireless/iwmc3200wifi/sdio.h b/drivers/net/wireless/iwmc3200wifi/sdio.h
index b3c156b..aab6b68 100644
--- a/drivers/net/wireless/iwmc3200wifi/sdio.h
+++ b/drivers/net/wireless/iwmc3200wifi/sdio.h
@@ -39,9 +39,6 @@
#ifndef __IWM_SDIO_H__
#define __IWM_SDIO_H__
-#define SDIO_VENDOR_ID_INTEL 0x89
-#define SDIO_DEVICE_ID_IWM 0x1403
-
#define IWM_SDIO_DATA_ADDR 0x0
#define IWM_SDIO_INTR_ENABLE_ADDR 0x14
#define IWM_SDIO_INTR_STATUS_ADDR 0x13
diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index 39751c8..b46a57a 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -22,6 +22,11 @@
/*
* Vendors and devices. Sort key: vendor first, device next.
*/
+#define SDIO_VENDOR_ID_INTEL 0x0089
+#define SDIO_DEVICE_ID_INTEL_IWMC3200WIMAX 0x1402
+#define SDIO_DEVICE_ID_INTEL_IWMC3200WIFI 0x1403
+#define SDIO_DEVICE_ID_INTEL_IWMC3200TOP 0x1404
+#define SDIO_DEVICE_ID_INTEL_IWMC3200BT 0x1406
#define SDIO_VENDOR_ID_MARVELL 0x02df
#define SDIO_DEVICE_ID_MARVELL_LIBERTAS 0x9103
--
1.6.0.6
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: weird problem
From: Paweł Staszewski @ 2009-07-13 23:26 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Eric Dumazet, Eric Dumazet, Linux Network Development list
In-Reply-To: <20090711062455.GA3095@ami.dom.local>
Jarek Poplawski pisze:
> On Fri, Jul 10, 2009 at 04:47:54PM +0200, Jarek Poplawski wrote:
>
>> On Fri, Jul 10, 2009 at 01:59:00AM +0200, Paweł Staszewski wrote:
>>
>>> Today i make other tests with change of
>>> /proc/sys/net/ipv4/rt_cache_rebuild_count and kernel 2.6.30.1
>>>
>>> And when rt_cache_rebuild_count is set to "-1" i have always load on
>>> x86_64 machine approx 40-50% of each cpu where network card is binded by
>>> irq_aff
>>>
>>> when rt_cache_rebuild_count is set to more than "-1" i have 15 to 20 sec
>>> of 1 to 3% cpu and after 40-50% cpu
>>>
>> ...
>>
>> Here is one more patch for testing (with caution!). It adds possibility
>> to turn off cache disabling (so it should even more resemble 2.6.28)
>> after setting: rt_cache_rebuild_count = 0
>>
>> I'd like you to try this patch:
>> 1) together with the previous patch and "rt_cache_rebuild_count = 0"
>> to check if there is still the difference wrt. 2.6.28; Btw., let
>> me know which /proc/sys/net/ipv4/route/* settings do you need to
>> change and why
>>
>> 2) alone (without the previous patch) and "rt_cache_rebuild_count = 0"
>>
>> 3) if it's possible to try 2.6.30.1 without these patches, but with
>> default /proc/sys/net/ipv4/route/* settings, and higher
>> rt_cache_rebuild_count, e.g. 100; I'm interested if/how long it
>> takes to trigger higher cpu load and the warning "... rebuilds is
>> over limit, route caching disabled"; (Btw., I wonder why you didn't
>> mention about these or maybe also other route caching warnings?)
>>
>
> Here is take 2 to respect setting "rt_cache_rebuild_count = 0" even
> after cache rebuild counter has been increased earlier. (Btw, don't
> forget about this setting after going back to vanilla kernel.)
>
>
Applied to 2.6.30.1
1) With
rt_cache_rebuild_count = 0
grep . /proc/sys/net/ipv4/route/*
/proc/sys/net/ipv4/route/error_burst:1250
/proc/sys/net/ipv4/route/error_cost:250
/proc/sys/net/ipv4/route/gc_elasticity:4
/proc/sys/net/ipv4/route/gc_interval:15
/proc/sys/net/ipv4/route/gc_min_interval:0
/proc/sys/net/ipv4/route/gc_min_interval_ms:0
/proc/sys/net/ipv4/route/gc_thresh:190536
/proc/sys/net/ipv4/route/gc_timeout:15
/proc/sys/net/ipv4/route/max_size:1524288
/proc/sys/net/ipv4/route/min_adv_mss:256
/proc/sys/net/ipv4/route/min_pmtu:552
/proc/sys/net/ipv4/route/mtu_expires:600
/proc/sys/net/ipv4/route/redirect_load:5
/proc/sys/net/ipv4/route/redirect_number:9
/proc/sys/net/ipv4/route/redirect_silence:5120
/proc/sys/net/ipv4/route/secret_interval:3600
I tune this route parameters after looking of traffic/route cache to have not many entries in cache that are not needed anymore
so gc_timeout = 15
limit of max entries = 1524288
And make route cahce a little more "faster" for me after tune
gc_elasticity
secret_interval
gc_interval
gc_thresh
So with this parameters
15 sec of
something like this:
00:41:23 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
00:41:24 all 0.00 0.00 0.12 0.00 1.49 10.46 0.00 0.00 87.92
00:41:24 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:41:24 1 0.00 0.00 0.00 0.00 4.00 36.00 0.00 0.00 60.00
00:41:24 2 0.00 0.00 0.00 0.00 8.91 47.52 0.00 0.00 43.56
00:41:24 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:41:24 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:41:24 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:41:24 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:41:24 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
and 15 sec of something like this:
00:41:44 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
00:41:45 all 0.00 0.00 0.00 0.00 0.00 0.42 0.00 0.00 99.58
00:41:45 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:41:45 1 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 99.00
00:41:45 2 0.00 0.00 0.00 0.00 0.00 2.04 0.00 0.00 97.96
00:41:45 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:41:45 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:41:45 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:41:45 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:41:45 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
So i change
/proc/sys/net/ipv4/route/gc_timeout to 1
with
rt_cache_rebuild_count = 0
And output is like 20 sec of something like this
00:48:52 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
00:48:53 all 0.00 0.00 0.19 0.00 0.19 0.58 0.00 0.00 99.03
00:48:53 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:53 1 0.00 0.00 0.99 0.00 0.99 0.00 0.00 0.00 98.02
00:48:53 2 0.00 0.00 0.00 0.00 0.00 2.00 0.00 0.00 98.00
00:48:53 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:53 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:53 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:53 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:53 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
and after this two second of something like this:
00:48:49 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
00:48:50 all 0.00 0.00 0.09 0.00 0.27 2.17 0.00 0.00 97.46
00:48:50 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:50 1 0.00 0.00 0.00 0.00 1.96 6.86 0.00 0.00 91.18
00:48:50 2 0.00 0.00 0.00 0.00 0.99 16.83 0.00 0.00 82.18
00:48:50 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:50 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:50 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:50 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:50 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:50 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
00:48:51 all 0.00 0.00 0.00 0.00 1.86 10.41 0.00 0.00 87.73
00:48:51 0 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 99.00
00:48:51 1 0.00 0.00 0.00 0.00 4.85 26.21 0.00 0.00 68.93
00:48:51 2 0.00 0.00 1.00 0.00 5.00 29.00 0.00 0.00 65.00
00:48:51 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:51 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:51 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:51 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:48:51 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
Another test:
gc_timeout = 1
rt_cache_rebuild_count = 100
10 to 14 sec of something like this:
00:51:36 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
00:51:37 all 0.00 0.00 0.00 0.00 0.00 0.27 0.00 0.00 99.73
00:51:37 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:51:37 1 0.00 0.00 0.00 0.00 0.00 2.00 0.00 0.00 98.00
00:51:37 2 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 99.00
00:51:37 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:51:37 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:51:37 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:51:37 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:51:37 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
and two seconds of 10 to 30% cpu load more
2).
Only last patch
and almost all the time output like this
00:59:49 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
00:59:50 all 0.00 0.00 0.13 0.00 1.73 8.00 0.00 0.00 90.13
00:59:50 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:59:50 1 0.00 0.00 0.00 0.00 4.00 24.00 0.00 0.00 72.00
00:59:50 2 0.00 0.00 0.00 0.00 8.91 34.65 0.00 0.00 56.44
00:59:50 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:59:50 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:59:50 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:59:50 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00:59:50 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
sometimes after 15 to 30 sec i have 1 to 2% cpu load
3).
with default settings and without this patch i have almost all the time output like this:
01:21:40 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
01:21:41 all 0.00 0.00 0.00 0.00 2.14 10.97 0.00 0.00 86.89
01:21:41 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
01:21:41 1 0.00 0.00 0.00 0.00 6.93 34.65 0.00 0.00 58.42
01:21:41 2 0.00 0.00 0.00 0.00 7.07 42.42 0.00 0.00 50.51
01:21:41 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
01:21:41 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
01:21:41 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
01:21:41 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
01:21:41 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
with my settings:
/proc/sys/net/ipv4/route/error_burst:1250
/proc/sys/net/ipv4/route/error_cost:250
/proc/sys/net/ipv4/route/gc_elasticity:4
/proc/sys/net/ipv4/route/gc_interval:15
/proc/sys/net/ipv4/route/gc_min_interval:0
/proc/sys/net/ipv4/route/gc_min_interval_ms:0
/proc/sys/net/ipv4/route/gc_thresh:190536
/proc/sys/net/ipv4/route/gc_timeout:15
/proc/sys/net/ipv4/route/max_size:1524288
/proc/sys/net/ipv4/route/min_adv_mss:256
/proc/sys/net/ipv4/route/min_pmtu:552
/proc/sys/net/ipv4/route/mtu_expires:600
/proc/sys/net/ipv4/route/redirect_load:5
/proc/sys/net/ipv4/route/redirect_number:9
/proc/sys/net/ipv4/route/redirect_silence:5120
/proc/sys/net/ipv4/route/secret_interval:3600
15 sec of 30 to 50 % cpu and 15 sec 1 to 2 % cpu
with
/proc/sys/net/ipv4/route/gc_interval:1
almost all the time like this
01:23:45 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
01:23:46 all 0.00 0.00 0.00 0.00 0.00 0.12 0.00 0.00 99.88
01:23:46 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
01:23:46 1 0.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 99.00
01:23:46 2 0.00 0.00 0.00 0.00 0.00 1.02 0.00 0.00 98.98
01:23:46 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
01:23:46 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
01:23:46 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
01:23:46 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
01:23:46 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
with max two outputs of 20 to 30% cpu in different times from 12 to 15sec
And i dont know but i think patch for turning off route cache is not working
because with this patches and
rt_cache_rebuild_count = 0
I have
rtstat -k entries -c 10 -i 1
rt_cache|
entries|
52929|
46301|
40971|
36928|
34882|
34915|
36431|
37752|
Regards
Pawel Staszewski
> Jarek P.
> --- (debugging patch #2 take 2; apply to 2.6.30.1 or 2.6.29.6)
>
>
> net/ipv4/route.c | 21 ++++++++++++++-------
> 1 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 278f46f..f74db20 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -678,8 +678,9 @@ static inline u32 rt_score(struct rtable *rt)
>
> static inline bool rt_caching(const struct net *net)
> {
> - return net->ipv4.current_rt_cache_rebuild_count <=
> - net->ipv4.sysctl_rt_cache_rebuild_count;
> + return (net->ipv4.current_rt_cache_rebuild_count <=
> + net->ipv4.sysctl_rt_cache_rebuild_count) ||
> + net->ipv4.sysctl_rt_cache_rebuild_count == 0;
> }
>
> static inline bool compare_hash_inputs(const struct flowi *fl1,
> @@ -1181,12 +1182,18 @@ restart:
> } else {
> if (chain_length > rt_chain_length_max) {
> struct net *net = dev_net(rt->u.dst.dev);
> - int num = ++net->ipv4.current_rt_cache_rebuild_count;
> - if (!rt_caching(dev_net(rt->u.dst.dev))) {
> - printk(KERN_WARNING "%s: %d rebuilds is over limit, route caching disabled\n",
> - rt->u.dst.dev->name, num);
> +
> + if (net->ipv4.sysctl_rt_cache_rebuild_count > 0) {
> + int num = ++net->ipv4.current_rt_cache_rebuild_count;
> +
> + if (!rt_caching(net))
> + printk(KERN_WARNING
> + "%s: %d rebuilds is over limit, "
> + "route caching disabled\n",
> + rt->u.dst.dev->name, num);
> +
> + rt_emergency_hash_rebuild(net);
> }
> - rt_emergency_hash_rebuild(dev_net(rt->u.dst.dev));
> }
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
From: Zhu, Yi @ 2009-07-14 1:59 UTC (permalink / raw)
To: Winkler, Tomas,
drzeus-list-p3sGCRWkH8CeZLLa646FqQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux
Cc: Winkler, Tomas
In-Reply-To: <1247522953-12702-1-git-send-email-tomas.winkler-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Tomas wrote:
> +#define SDIO_VENDOR_ID_INTEL 0x0089
> +#define SDIO_DEVICE_ID_INTEL_IWMC3200WIMAX 0x1402
> +#define SDIO_DEVICE_ID_INTEL_IWMC3200WIFI 0x1403
> +#define SDIO_DEVICE_ID_INTEL_IWMC3200TOP 0x1404
Looks good. Please replace the above spaces with a TAB.
> +#define SDIO_DEVICE_ID_INTEL_IWMC3200BT 0x1406
>
> #define SDIO_VENDOR_ID_MARVELL 0x02df
> #define SDIO_DEVICE_ID_MARVELL_LIBERTAS 0x9103
Thanks,
-yi
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* Re: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
From: David Miller @ 2009-07-14 2:10 UTC (permalink / raw)
To: tomas.winkler; +Cc: drzeus-list, netdev, linux-wireless, linux-kernel
In-Reply-To: <1247522953-12702-1-git-send-email-tomas.winkler@intel.com>
From: Tomas Winkler <tomas.winkler@intel.com>
Date: Tue, 14 Jul 2009 01:09:13 +0300
> 1. add intel's sdio vendor id to sdio_ids.h
> 2. move iwmc3200 sdio devices ids to sdio_ids.h
>
> This patch is against 2.6.31-rc2
> 7638d5322bd89d49e013a03fe2afaeb6d214fabd
>
> Cc:inaky.perez-gonzalez@intel.com
> Cc:cindy.h.kao@intel.com
> Cc:samuel.ortiz@intel.com
> Cc:yi.zhu@intel.com
> Cc:drzeus-list@drzeus.cx
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Since wimax stuff goes directly through me and John Linville handles
wireless things, you're making this overly difficult by combining
changes for those two subsystems into a single patch.
Please split this up, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] NET: sungem, use spin_trylock_irqsave
From: David Miller @ 2009-07-14 2:12 UTC (permalink / raw)
To: jirislaby; +Cc: netdev, linux-kernel
In-Reply-To: <1247520220-31960-2-git-send-email-jirislaby@gmail.com>
Please DO NOT combine cleanups with real bug fixes into
a patch series.
Bug fixes go to one tree, the rest go to another tree, and that is
especially the case this late in the RC series.
A series of patches are a group of changes that are supposed to be
related and are expected to be applied all to the same tree. That is
not true of the patches you have posted here.
^ 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