* Re: [PATCH 2/2] ipg: redundancy with mii.h
From: Francois Romieu @ 2006-05-05 0:24 UTC (permalink / raw)
To: David Vrabel; +Cc: Pekka J Enberg, linux-kernel, netdev, david
In-Reply-To: <4459A4A6.1080207@cantab.net>
David Vrabel <dvrabel@cantab.net> :
[...]
> > ipg: replace #define with enum
> >
> > Added some underscores to improve readability.
> >
> > Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
>
> Nack. Register names in code should match those used in the
> documentation (even if they are a bit unreadable). Though I will
> conceed that the available datasheet doesn't actually describe the
> majority of the registers.
We will have to agree to disagree. Feel free to open a different
branch.
--
Ueimor
^ permalink raw reply
* Re: RFC: au1000_etc.c phylib rewrite
From: Andy Fleming @ 2006-05-05 0:36 UTC (permalink / raw)
To: Herbert Valerio Riedel
Cc: Mark Schank, ppopov, sshtylyov, linux-mips, jgarzik, netdev,
Ralf Baechle, Robin H. Johnson
In-Reply-To: <1146674056.31241.18.camel@localhost.localdomain>
On May 3, 2006, at 11:34, Herbert Valerio Riedel wrote:
> hello *
>
> On Tue, 2006-05-02 at 11:20 -0500, Mark Schank wrote:
>> At 08:23 AM 5/2/06 +0200, Herbert Valerio Riedel wrote:
>>> On Mon, 2006-05-01 at 15:09 -0500, Mark Schank wrote:
>>>> The Cogent CSB655 used the Broadcom Dual Phy. They eventually
>>>> redesigned
>>>> the board and switched to two single Broadcom phys, but they
>>>> continued to
>>>> control both phys through MAC0, which is the actual purpose of the
>>> dual-phy
>>>> hack. I am a user of the CSB655, so I sort of care.
>>>>
>>>> Will the new PHY framework allow a second PHY for a second MAC
>>>> (MAC1) be
>>>> controlled from the first MAC's (MAC0) mdio interface?
That definitely isn't a problem (though it looks like you've probably
figured that out). The original user (gianfar) has a similar setup,
where all 2-4 NICs use TSEC0's MII interface to control the PHYs. It
was actually one of the reasons for writing it in the first place--to
more cleanly share that interface between several different device
instances.
>>>
>>> should'nt be a problem (as opposed to the bosporus case... see
>>> below)...
>>> I assume the phy-addresses on which the boarcom dual phy is
>>> configured
>>> are the same for all Cogent CSB655 boards?
>>
>> Dual PHY configuration:
>> MAC0 - phy addr 4
>> MAC1 - phy addr 3
>> Single PHY configuration:
>> MAC0 - phy addr 1
>> MAC1 - phy addr 0
>
> while at it, does anyone happen to know what the phy-addr/MAC
> assignment
> on the XXS1500 is?
>
>>> does this need to be autodetected dynamically at runtime, or can
>>> we rely
>>> on a compile time Kconfig-conditional to set a static phy-addr<-
>>> >eth%
>>> d-phy mapping for this board-specific case? Or de we really need
>>> such a
>>> complex mii_probe() function to detect weird scenarios? :)
>>
>> The compile time Kconfig-conditional should be okay. The driver
>> need to
>> handle the fact that the MAC1's phy is controlled by MAC0's mdio
>> interface. This means that MAC0 controller can not be disabled
>> when the
>> associated eth% device is down, otherwise you lose the ability to
>> control
>> MAC1's phy.
>
> ...or at least, the MAC associated with the particular MII bus
> should be
> brought up if necessary before any mdio access (that's what I'm
> implementing right now)
>
> but one thing that seems strange to me; CONFIG_BCM5222_DUAL_PHY
> doesn't
> seem to be defined anywhere; shouldn't that be at least defined in
> some
> Kconfig file, especially if the XXS1550 board is supposed to make
> use of
> it?
>
> btw, is the CSB655 supported at all in the 2.6 linux-mips branch, I
> couldn't find any mention of it in Kconfig files either?
>
>>> using static phy addr mappings would also allow for setting
>>> board-specific phy-irq assignments, which would then be handled
>>> by the
>>> phylib facilities, instead of polling the status of phy with a
>>> timer;
>>> (and in case we don't have any board-specific compile time
>>> setting, we
>>> can still fall back to search the phy-addresses for a PHY at
>>> runtime as
>>> the generic case)
>>
>> Will the phylib facilities handle the case where two phys share a
>> single IRQ?
>
> afaics from the source, it doesn't handle the case of multiplexed phy
> notification irqs; although the interrupt is requested with the
> SA_SHIRQ
> flag, the first phy-interrupt-handler to be called already returns
> IRQ_HANDLED... doesn't feel right in some way ;-)
The PHY layer does handle multiplexed interrupts (I've got boards
with 4 PHYs sharing the same IRQ). While I'm not sure returning
IRQ_HANDLED is the perfect implementation, I'm not sure there are any
options. I've worked pretty hard to ensure that PHY transactions
don't occur in interrupt context so that it's possible to implement a
driver that has an interrupt signal the end of a transaction. As
such, reading the PHY interrupt status cannot happen in the interrupt
handler, which means the interrupt handler doesn't have the ability
to determine whether any particular invocation is handling the actual
cause of the interrupt.
From what I've seen of the interrupt code, this is only an issue if
a spurious interrupt starts troubling the same line the PHY is
using. Does anyone disagree, or have some better suggestion for how
to handle this?
^ permalink raw reply
* [PATCH 0/2] bcm43xx: fix whitespace
From: Stefano Brivio @ 2006-05-05 0:58 UTC (permalink / raw)
To: John W. Linville, Andrew Morton; +Cc: bcm43xx-dev, netdev
This applies to 2.6.17-rc3.
--
Fix whitespace.
Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 00:50:00.370034536 +0200
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 02:43:44.981535888 +0200
@@ -128,13 +128,13 @@ MODULE_PARM_DESC(fwpostfix, "Postfix for
static struct pci_device_id bcm43xx_pci_tbl[] = {
/* Broadcom 4303 802.11b */
{ PCI_VENDOR_ID_BROADCOM, 0x4301, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
- /* Broadcom 4307 802.11b */
+ /* Broadcom 4307 802.11b */
{ PCI_VENDOR_ID_BROADCOM, 0x4307, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
- /* Broadcom 4318 802.11b/g */
+ /* Broadcom 4318 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4318, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4306 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4320, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
- /* Broadcom 4306 802.11a */
+ /* Broadcom 4306 802.11a */
// { PCI_VENDOR_ID_BROADCOM, 0x4321, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4309 802.11a/b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4324, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
--
Ciao
Stefano
^ permalink raw reply
* [PATCH 2/2] bcm43xx: add PCI ID for bcm4319
From: Stefano Brivio @ 2006-05-05 1:02 UTC (permalink / raw)
To: John W. Linville, Andrew Morton; +Cc: bcm43xx-dev, netdev
bcm4319 is reported to work. This applies to 2.6.17-rc3.
--
Add PCI ID for bcm4319.
Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 00:50:00.370034536 +0200
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 02:56:42.216378232 +0200
@@ -132,6 +132,8 @@ MODULE_PARM_DESC(fwpostfix, "Postfix for
{ PCI_VENDOR_ID_BROADCOM, 0x4307, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4318 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4318, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+ /* Broadcom 4319 802.11a/b/g */
+ { PCI_VENDOR_ID_BROADCOM, 0x4319, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4306 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4320, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4306 802.11a */
--
Ciao
Stefano
^ permalink raw reply
* Re: [PATCH 0/2] bcm43xx: fix whitespace
From: Stefano Brivio @ 2006-05-05 1:07 UTC (permalink / raw)
To: John W. Linville, Andrew Morton; +Cc: bcm43xx-dev, netdev
In-Reply-To: <20060505025829.5d4b072f@localhost>
On Fri, 5 May 2006 02:58:29 +0200
Stefano Brivio <stefano.brivio@polimi.it> wrote:
> This applies to 2.6.17-rc3.
Heh, sorry. It's PATCH 1/2, not 0/2. :)
--
Ciao
Stefano
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Rusty Russell @ 2006-05-05 1:31 UTC (permalink / raw)
To: David S. Miller; +Cc: kelly, netdev
In-Reply-To: <20060504.162223.44735502.davem@davemloft.net>
On Thu, 2006-05-04 at 16:22 -0700, David S. Miller wrote:
> From: Kelly Daly <kelly@au1.ibm.com>
> Date: Thu, 4 May 2006 12:59:23 +1000
>
> > We DID write an infrastructure to resolve this issue, although it is more
> > complex than the dynamic descriptor scheme for userspace. And we want to
> > keep this simple - right?
>
> Yes.
>
> I wonder if it is possible to manage the buffer pool just like a SLAB
> cache to deal with the variable lifetimes. The system has a natural
> "working set" size of networking buffers at a given point in time and
> even the default net channel can grow to accomodate that with some
> kind of limit.
>
> This is kind of what I was alluding to in the past, in that we now
> have globals limits on system TCP socket memory when really what we
> want to do is have a set of global generic system packet memory
> limits.
>
> These two things can tie in together.
Hi Dave,
We kept a simple "used" bitmap, but to avoid the consumer touching it,
also put a "I am masquerading as an SKB" bit in the trailer, like so:
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .16405-linux-2.6.17-rc3-git7/include/linux/skbuff.h .16405-linux-2.6.17-rc3-git7.updated/include/linux/skbuff.h
--- .16405-linux-2.6.17-rc3-git7/include/linux/skbuff.h 2006-05-03 22:07:14.000000000 +1000
+++ .16405-linux-2.6.17-rc3-git7.updated/include/linux/skbuff.h 2006-05-03 22:07:15.000000000 +1000
@@ -133,7 +133,8 @@ struct skb_frag_struct {
*/
struct skb_shared_info {
atomic_t dataref;
- unsigned short nr_frags;
+ unsigned short nr_frags : 15;
+ unsigned int chan_as_skb : 1;
unsigned short tso_size;
unsigned short tso_segs;
unsigned short ufo_size;
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .16405-linux-2.6.17-rc3-git7/net/core/skbuff.c .16405-linux-2.6.17-rc3-git7.updated/net/core/skbuff.c
--- .16405-linux-2.6.17-rc3-git7/net/core/skbuff.c 2006-05-03 22:07:14.000000000 +1000
+++ .16405-linux-2.6.17-rc3-git7.updated/net/core/skbuff.c 2006-05-03 22:07:15.000000000 +1000
@@ -289,6 +289,7 @@ struct sk_buff *skb_netchan_graft(struct
skb_shinfo(skb)->ufo_size = 0;
skb_shinfo(skb)->ip6_frag_id = 0;
skb_shinfo(skb)->frag_list = NULL;
+ skb_shinfo(skb)->chan_as_skb = 1;
return skb;
}
@@ -328,7 +329,10 @@ void skb_release_data(struct sk_buff *sk
if (skb_shinfo(skb)->frag_list)
skb_drop_fraglist(skb);
- kfree(skb->head);
+ if (skb_shinfo(skb)->chan_as_skb)
+ skb_shinfo(skb)->chan_as_skb = 0;
+ else
+ kfree(skb->head);
}
}
Buffer allocation would be: find_first_bit, check that it's not actually
inside an skb, or otherwise find_next_bit. Assuming most buffers do not
go down default channel, this is efficient.
Problems:
1) it's still not cache-friendly with producers on multiple CPUs. We
could divide up the bitmap into per-cpu regions to try first to improve
cache behaviour.
2) In addition, we had every buffer one page large. This isn't
sufficient for jumbo frames, and wasteful for ethernet. So if we
statically assign descriptors -> buffers, we need to have multiple
sizes.
3) OTOH, if descriptor table is dynamic, we have cache issues again as
multiple people are writing to it, and it's not clear what we really
gain over direct pointers.
4) Grow/shrink can be done, but needs stop_machine, or maybe tricky RCU.
5) The killer for me: we can't use our scheme straight-to-userspace
anyway, since we can't trust the (user-writable) ringbuffer in deciding
what buffers to release. Since we need to store this somewhere, we need
a test in netchannel_enqueue. At which point, we might as well
translate to "descriptors" at that point, anyway (since descriptors are
only really needed for userspace). Something like:
tail = np->netchan_tail;
if (tail == np->netchan_head)
return -ENOMEM;
+ /* Write to userspace? They can't deref ptr anyway. */
+ if (np->shadow_ring && !netchan_local_buf(bp)) {
+ np->shadow_ring[tail] = bp;
+ bp = (void *)-1;
+ }
np->netchan_queue[tail++] = bp;
if (tail == NET_CHANNEL_ENTRIES)
(We don't have local buffers yet, but I'm assuming we'll use v. low
pointers for them). Userspace goes "desc number is in range, we can
access directly" or "desc number isn't, call into kernel to copy them
for us".
> So, are you still sure you want to do away with the descriptors for
> the default channel? Is the scheme I have outlined above doable or
> is there some critical barrier or some complexity issue which makes
> it undesirable?
I think it's simpler to build global alloc limiters on what we have.
The slab already has the nice lifetime and cache-friendly properties we
want, so we just have to write the limiting code. There's enough work
there to keep us busy 8)
Cheers,
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
^ permalink raw reply
* Re: [rfc][patch] ipvs: use proper timeout instead of fixed value
From: Horms @ 2006-05-05 0:47 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, wensong, ja
In-Reply-To: <20060504201116.GA24394@gospo.rdu.redhat.com>
On Thu, May 04, 2006 at 04:11:16PM -0400, Andy Gospodarek wrote:
>
> Instead of using the default timeout of 3 minutes, this uses the timeout
> specific to the protocol used for the connection. The 3 minute timeout
> seems somewhat arbitrary (though I know it is used other places in the
> ipvs code) and when failing over it would be much nicer to use one of
> the configured timeout values.
Hi Andy,
I agree that the current value is somewhat arbitary,
however I'm more in favour of setting it idependantly
of other timeouts, perhaps via proc. In any case,
won't pp->timeout_table[cp->state] be rather long in
the ESTABLISHED case?
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> ---
>
> ip_vs_sync.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c
> --- a/net/ipv4/ipvs/ip_vs_sync.c
> +++ b/net/ipv4/ipvs/ip_vs_sync.c
> @@ -67,7 +67,6 @@ struct ip_vs_sync_conn_options {
> struct ip_vs_seq out_seq; /* outgoing seq. struct */
> };
>
> -#define IP_VS_SYNC_CONN_TIMEOUT (3*60*HZ)
> #define SIMPLE_CONN_SIZE (sizeof(struct ip_vs_sync_conn))
> #define FULL_CONN_SIZE \
> (sizeof(struct ip_vs_sync_conn) + sizeof(struct ip_vs_sync_conn_options))
> @@ -279,6 +278,7 @@ static void ip_vs_process_message(const
> struct ip_vs_sync_conn *s;
> struct ip_vs_sync_conn_options *opt;
> struct ip_vs_conn *cp;
> + struct ip_vs_protocol *pp;
> char *p;
> int i;
>
> @@ -337,7 +337,8 @@ static void ip_vs_process_message(const
> p += SIMPLE_CONN_SIZE;
>
> atomic_set(&cp->in_pkts, sysctl_ip_vs_sync_threshold[0]);
> - cp->timeout = IP_VS_SYNC_CONN_TIMEOUT;
> + pp = ip_vs_proto_get(s->protocol);
> + cp->timeout = pp->timeout_table[cp->state];
> ip_vs_conn_put(cp);
>
> if (p > buffer+buflen) {
--
Horms http://www.vergenet.net/~horms/
^ permalink raw reply
* [PATCH wireless-dev] d80211: Don't discriminate against 802.11b drivers
From: Michael Wu @ 2006-05-05 2:32 UTC (permalink / raw)
To: John W. Linville; +Cc: Jiri Benc, Jouni Malinen, netdev, jkmaline
This makes the current hack used to prevent 802.11g cards from scanning with
802.11b channels not break scanning in 802.11b drivers.
Signed-off-by: Michael Wu <flamingice@sourmilk.net>
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 2720f1d..5c8fe22 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -2566,7 +2566,7 @@ int ieee80211_sta_req_scan(struct net_de
memcpy(local->scan_ssid, ssid, ssid_len);
} else
local->scan_ssid_len = 0;
- local->scan_skip_11b = 1; /* FIX: clear this is 11g is not supported */
+ local->scan_skip_11b = local->hw->num_modes > 1;
local->scan_state = SCAN_SET_CHANNEL;
local->scan_hw_mode_idx = 0;
local->scan_channel_idx = 0;
^ permalink raw reply related
* iwconfig shows Encrypt key off when using WEP.
From: Alex Davis @ 2006-05-05 2:37 UTC (permalink / raw)
To: linville, netdev
In-Reply-To: <20060426204937.GF7922@tuxdriver.com>
I'm using the latest wireless dev git. wireless tools version 28.
wpa_supplicant 0.4.8 .
Here's the output of iwconfig wlan0:
wlan0 IEEE 802.11g ESSID:"mysid"
Mode:Managed Frequency:2.437 GHz Access Point: xx:xx.....
RTS thr:off Fragment thr=2346 B
Encryption key:off <--- should be 'on'
Here's lspci -v:
2:03.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03)
Subsystem: Dell Truemobile 1450 MiniPCI
Flags: bus master, fast devsel, latency 32, IRQ 7
Memory at fafee000 (32-bit, non-prefetchable) [size=8K]
Here's the dmesg output from loading the module:
21428.599628] bcm43xx_d80211 driver
[21428.609511] ACPI: PCI Interrupt 0000:02:03.0[A] -> Link [LNKB] -> GSI 7 (level, low) -> IRQ 7
[21428.615559] bcm43xx_d80211: Chip ID 0x4306, rev 0x3
[21428.615561] bcm43xx_d80211: Number of cores: 5
[21428.615566] bcm43xx_d80211: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled
[21428.615574] bcm43xx_d80211: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled
[21428.615582] bcm43xx_d80211: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled
[21428.615590] bcm43xx_d80211: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled
[21428.615597] bcm43xx_d80211: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled
[21428.618895] bcm43xx_d80211: PHY connected
[21428.618907] bcm43xx_d80211: Detected PHY: Version: 2, Type 2, Revision 2
[21428.618928] bcm43xx_d80211: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
[21428.618943] bcm43xx_d80211: Radio turned off
[21428.618970] bcm43xx_d80211: Radio turned off
[21428.689486] wmaster0: Selected rate control algorithm 'simple'
[21428.789510] bcm43xx_d80211: PHY connected
[21428.992261] bcm43xx_d80211: Radio turned on
[21429.186760] bcm43xx_d80211: Chip initialized
[21429.186974] bcm43xx_d80211: DMA initialized
[21429.186985] bcm43xx_d80211: 80211 cores initialized
[21429.187199] bcm43xx_d80211: Keys cleared
[21429.187239] wmaster0: Does not support passive scan, disabled
Here's my wep.conf file:
# Static WEP keys
ctrl_interface=/var/run/wpa_supplicant
network={
ssid="mysid"
auth_alg=OPEN
key_mgmt=NONE
wep_key0=111111919191919191919
wep_tx_keyidx=0
}
Here's the wpa_supplicant command:
wpa_supplicant -D wext -c ~/wep.conf -i wlan0
Other than that, it's been working perfectly.
Thanks
I code, therefore I am
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Kelly Daly @ 2006-05-05 2:48 UTC (permalink / raw)
To: David S. Miller; +Cc: rusty, netdev
In-Reply-To: <20060504.161148.44973535.davem@davemloft.net>
On Friday 05 May 2006 09:11, David S. Miller wrote:
> I very much fear abuse of the inet_hashes[] array. So I'd rather
> hide it behind a programmatic interface, something like:
done! I will continue with implementation of default netchannel for now.
> Thanks!
anytime =)
Cheers,
K
______________________
diff -urp davem_orig/include/net/inet_hashtables.h kelly/include/net/inet_hashtables.h
--- davem_orig/include/net/inet_hashtables.h 2006-04-27 00:08:32.000000000 +1000
+++ kelly/include/net/inet_hashtables.h 2006-05-05 12:05:33.000000000 +1000
@@ -418,4 +418,7 @@ static inline struct sock *inet_lookup(s
extern int inet_hash_connect(struct inet_timewait_death_row *death_row,
struct sock *sk);
+extern void inet_hash_register(u8 proto, struct inet_hashinfo *hashinfo);
+extern struct sock *inet_lookup_proto(u8 protocol, u32 saddr, u16 sport, u32 daddr, u16 dport, int ifindex);
+
#endif /* _INET_HASHTABLES_H */
diff -urp davem_orig/include/net/sock.h kelly/include/net/sock.h
--- davem_orig/include/net/sock.h 2006-05-02 13:42:10.000000000 +1000
+++ kelly/include/net/sock.h 2006-05-04 14:28:59.000000000 +1000
@@ -196,6 +196,7 @@ struct sock {
unsigned short sk_type;
int sk_rcvbuf;
socket_lock_t sk_lock;
+ struct netchannel *sk_channel;
wait_queue_head_t *sk_sleep;
struct dst_entry *sk_dst_cache;
struct xfrm_policy *sk_policy[2];
diff -urp davem_orig/net/core/dev.c kelly/net/core/dev.c
--- davem_orig/net/core/dev.c 2006-04-27 15:49:27.000000000 +1000
+++ kelly/net/core/dev.c 2006-05-05 10:39:22.000000000 +1000
@@ -116,6 +116,7 @@
#include <net/iw_handler.h>
#include <asm/current.h>
#include <linux/audit.h>
+#include <net/inet_hashtables.h>
/*
* The list of packet types we will receive (as opposed to discard)
@@ -190,6 +191,8 @@ static inline struct hlist_head *dev_ind
return &dev_index_head[ifindex & ((1<<NETDEV_HASHBITS)-1)];
}
+static struct netchannel default_netchannel;
+
/*
* Our notifier list
*/
@@ -1907,6 +1910,34 @@ struct netchannel_buftrailer *__netchann
}
EXPORT_SYMBOL_GPL(__netchannel_dequeue);
+
+/* Find the channel for a packet, or return default channel. */
+struct netchannel *find_netchannel(const struct netchannel_buftrailer *np)
+{
+ struct sock *sk = NULL;
+ unsigned long dlen = np->netchan_buf_len - np->netchan_buf_offset;
+ void *data = (void *)np - dlen;
+
+ switch (np->netchan_buf_proto) {
+ case __constant_htons(ETH_P_IP): {
+ struct iphdr *ip = data;
+ int iphl = ip->ihl * 4;
+
+ if (dlen >= (iphl + 4) && iphl == sizeof(struct iphdr)) {
+ u16 *ports = (u16 *)(ip + 1);
+ sk = inet_lookup_proto(ip->protocol,
+ ip->saddr, ports[0],
+ ip->daddr, ports[1],
+ np->netchan_buf_dev->ifindex);
+ break;
+ }
+ }
+ }
+ if (sk && sk->sk_channel)
+ return sk->sk_channel;
+ return &default_netchannel;
+}
+
static gifconf_func_t * gifconf_list [NPROTO];
/**
@@ -3421,6 +3452,9 @@ static int __init net_dev_init(void)
hotcpu_notifier(dev_cpu_callback, 0);
dst_init();
dev_mcast_init();
+
+ /* FIXME: This should be attached to thread/threads. */
+ netchannel_init(&default_netchannel, NULL, NULL);
rc = 0;
out:
return rc;
diff -urp davem_orig/net/ipv4/inet_hashtables.c kelly/net/ipv4/inet_hashtables.c
--- davem_orig/net/ipv4/inet_hashtables.c 2006-04-27 00:08:33.000000000 +1000
+++ kelly/net/ipv4/inet_hashtables.c 2006-05-05 12:05:33.000000000 +1000
@@ -337,3 +337,25 @@ out:
}
EXPORT_SYMBOL_GPL(inet_hash_connect);
+
+static struct inet_hashinfo *inet_hashes[256];
+
+void inet_hash_register(u8 proto, struct inet_hashinfo *hashinfo)
+{
+ BUG_ON(inet_hashes[proto]);
+ inet_hashes[proto] = hashinfo;
+}
+EXPORT_SYMBOL(inet_hash_register);
+
+struct sock *inet_lookup_proto(u8 protocol, u32 saddr, u16 sport, u32 daddr, u16 dport, int ifindex)
+{
+ struct sock *sk = NULL;
+ if (inet_hashes[protocol]) {
+ sk = inet_lookup(inet_hashes[protocol],
+ saddr, sport,
+ daddr, dport,
+ ifindex);
+ }
+ return sk;
+}
+EXPORT_SYMBOL(inet_lookup_proto);
diff -urp davem_orig/net/ipv4/tcp.c kelly/net/ipv4/tcp.c
--- davem_orig/net/ipv4/tcp.c 2006-04-27 00:08:33.000000000 +1000
+++ kelly/net/ipv4/tcp.c 2006-05-05 11:29:18.000000000 +1000
@@ -2173,6 +2173,7 @@ void __init tcp_init(void)
tcp_hashinfo.ehash_size << 1, tcp_hashinfo.bhash_size);
tcp_register_congestion_control(&tcp_reno);
+ inet_hash_register(IPPROTO_TCP, &tcp_hashinfo);
}
EXPORT_SYMBOL(tcp_close);
^ permalink raw reply
* Re: [rfc][patch] ipvs: use proper timeout instead of fixed value
From: Andy Gospodarek @ 2006-05-05 2:51 UTC (permalink / raw)
To: Horms; +Cc: Andy Gospodarek, netdev, wensong, ja
In-Reply-To: <20060505004754.GA6943@verge.net.au>
On Fri, May 05, 2006 at 09:47:56AM +0900, Horms wrote:
> On Thu, May 04, 2006 at 04:11:16PM -0400, Andy Gospodarek wrote:
> >
> > Instead of using the default timeout of 3 minutes, this uses the timeout
> > specific to the protocol used for the connection. The 3 minute timeout
> > seems somewhat arbitrary (though I know it is used other places in the
> > ipvs code) and when failing over it would be much nicer to use one of
> > the configured timeout values.
>
> Hi Andy,
>
> I agree that the current value is somewhat arbitary,
> however I'm more in favour of setting it idependantly
> of other timeouts, perhaps via proc. In any case,
> won't pp->timeout_table[cp->state] be rather long in
> the ESTABLISHED case?
>
Horms,
I agree that there could be a long timeout for ESTABLISHED connections,
but I've run across a situation where I need exactly that. When testing
failover from master to backup I realize that all of my interactive
sessions get dropped much sooner than the timeout I've configured (mine
is currently set for much longer than 3 minutes). If I wanted
established connections to timeout quickly I would set the timeout to be
a small value.
-andy
> > Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> > ---
> >
> > ip_vs_sync.c | 5 +++--
> > 1 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c
> > --- a/net/ipv4/ipvs/ip_vs_sync.c
> > +++ b/net/ipv4/ipvs/ip_vs_sync.c
> > @@ -67,7 +67,6 @@ struct ip_vs_sync_conn_options {
> > struct ip_vs_seq out_seq; /* outgoing seq. struct */
> > };
> >
> > -#define IP_VS_SYNC_CONN_TIMEOUT (3*60*HZ)
> > #define SIMPLE_CONN_SIZE (sizeof(struct ip_vs_sync_conn))
> > #define FULL_CONN_SIZE \
> > (sizeof(struct ip_vs_sync_conn) + sizeof(struct ip_vs_sync_conn_options))
> > @@ -279,6 +278,7 @@ static void ip_vs_process_message(const
> > struct ip_vs_sync_conn *s;
> > struct ip_vs_sync_conn_options *opt;
> > struct ip_vs_conn *cp;
> > + struct ip_vs_protocol *pp;
> > char *p;
> > int i;
> >
> > @@ -337,7 +337,8 @@ static void ip_vs_process_message(const
> > p += SIMPLE_CONN_SIZE;
> >
> > atomic_set(&cp->in_pkts, sysctl_ip_vs_sync_threshold[0]);
> > - cp->timeout = IP_VS_SYNC_CONN_TIMEOUT;
> > + pp = ip_vs_proto_get(s->protocol);
> > + cp->timeout = pp->timeout_table[cp->state];
> > ip_vs_conn_put(cp);
> >
> > if (p > buffer+buflen) {
>
> --
> Horms http://www.vergenet.net/~horms/
>
> -
> 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
* [RFC PATCH] [IPV6] ADDRCONF: Convert addrconf_lock to RCU.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-05-05 3:24 UTC (permalink / raw)
To: davem; +Cc: netdev, yoshfuji
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 750e250..74dca37 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -127,20 +127,18 @@ extern int unregister_inet6addr_notifier
static inline struct inet6_dev *
__in6_dev_get(struct net_device *dev)
{
- return (struct inet6_dev *)dev->ip6_ptr;
+ return rcu_dereference(dev->ip6_ptr);
}
-extern rwlock_t addrconf_lock;
-
static inline struct inet6_dev *
in6_dev_get(struct net_device *dev)
{
struct inet6_dev *idev = NULL;
- read_lock(&addrconf_lock);
- idev = dev->ip6_ptr;
+ rcu_read_lock();
+ idev = __in6_dev_get(dev);
if (idev)
atomic_inc(&idev->refcnt);
- read_unlock(&addrconf_lock);
+ rcu_read_unlock();
return idev;
}
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index c23e9c0..e3b326d 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -1786,7 +1786,7 @@ static void pktgen_setup_inject(struct p
* use ipv6_get_lladdr if/when it's get exported
*/
- read_lock(&addrconf_lock);
+ rcu_read_lock();
if ((idev = __in6_dev_get(pkt_dev->odev)) != NULL) {
struct inet6_ifaddr *ifp;
@@ -1805,7 +1805,7 @@ static void pktgen_setup_inject(struct p
}
read_unlock_bh(&idev->lock);
}
- read_unlock(&addrconf_lock);
+ rcu_read_unlock();
if (err)
printk("pktgen: ERROR: IPv6 link address not availble.\n");
}
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 445006e..6cb12d4 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -118,9 +118,6 @@ static int ipv6_count_addresses(struct i
static struct inet6_ifaddr *inet6_addr_lst[IN6_ADDR_HSIZE];
static DEFINE_RWLOCK(addrconf_hash_lock);
-/* Protects inet6 devices */
-DEFINE_RWLOCK(addrconf_lock);
-
static void addrconf_verify(unsigned long);
static DEFINE_TIMER(addr_chk_timer, addrconf_verify, 0, 0);
@@ -405,9 +402,8 @@ static struct inet6_dev * ipv6_add_dev(s
if (netif_carrier_ok(dev))
ndev->if_flags |= IF_READY;
- write_lock_bh(&addrconf_lock);
- dev->ip6_ptr = ndev;
- write_unlock_bh(&addrconf_lock);
+ /* protected by rtnl_lock */
+ rcu_assign_pointer(dev->ip6_ptr, ndev);
ipv6_mc_init_dev(ndev);
ndev->tstamp = jiffies;
@@ -471,7 +467,7 @@ static void addrconf_forward_change(void
read_lock(&dev_base_lock);
for (dev=dev_base; dev; dev=dev->next) {
- read_lock(&addrconf_lock);
+ rcu_read_lock();
idev = __in6_dev_get(dev);
if (idev) {
int changed = (!idev->cnf.forwarding) ^ (!ipv6_devconf.forwarding);
@@ -479,7 +475,7 @@ static void addrconf_forward_change(void
if (changed)
dev_forward_change(idev);
}
- read_unlock(&addrconf_lock);
+ rcu_read_unlock();
}
read_unlock(&dev_base_lock);
}
@@ -520,7 +516,7 @@ ipv6_add_addr(struct inet6_dev *idev, co
int hash;
int err = 0;
- read_lock_bh(&addrconf_lock);
+ rcu_read_lock_bh();
if (idev->dead) {
err = -ENODEV; /*XXX*/
goto out2;
@@ -590,7 +586,7 @@ ipv6_add_addr(struct inet6_dev *idev, co
in6_ifa_hold(ifa);
write_unlock(&idev->lock);
out2:
- read_unlock_bh(&addrconf_lock);
+ rcu_read_unlock_bh();
if (likely(err == 0))
atomic_notifier_call_chain(&inet6addr_chain, NETDEV_UP, ifa);
@@ -887,7 +883,7 @@ int ipv6_dev_get_saddr(struct net_device
memset(&hiscore, 0, sizeof(hiscore));
read_lock(&dev_base_lock);
- read_lock(&addrconf_lock);
+ rcu_read_lock();
for (dev = dev_base; dev; dev=dev->next) {
struct inet6_dev *idev;
@@ -1096,7 +1092,7 @@ record_it:
}
read_unlock_bh(&idev->lock);
}
- read_unlock(&addrconf_lock);
+ rcu_read_unlock();
read_unlock(&dev_base_lock);
if (!ifa_result)
@@ -1120,7 +1116,7 @@ int ipv6_get_lladdr(struct net_device *d
struct inet6_dev *idev;
int err = -EADDRNOTAVAIL;
- read_lock(&addrconf_lock);
+ rcu_read_lock();
if ((idev = __in6_dev_get(dev)) != NULL) {
struct inet6_ifaddr *ifp;
@@ -1134,7 +1130,7 @@ int ipv6_get_lladdr(struct net_device *d
}
read_unlock_bh(&idev->lock);
}
- read_unlock(&addrconf_lock);
+ rcu_read_unlock();
return err;
}
@@ -1435,7 +1431,7 @@ static void ipv6_regen_rndid(unsigned lo
struct inet6_dev *idev = (struct inet6_dev *) data;
unsigned long expires;
- read_lock_bh(&addrconf_lock);
+ rcu_read_lock_bh();
write_lock_bh(&idev->lock);
if (idev->dead)
@@ -1459,7 +1455,7 @@ static void ipv6_regen_rndid(unsigned lo
out:
write_unlock_bh(&idev->lock);
- read_unlock_bh(&addrconf_lock);
+ rcu_read_unlock_bh();
in6_dev_put(idev);
}
@@ -2291,10 +2287,9 @@ static int addrconf_ifdown(struct net_de
Do not dev_put!
*/
if (how == 1) {
- write_lock_bh(&addrconf_lock);
- dev->ip6_ptr = NULL;
- idev->dead = 1;
- write_unlock_bh(&addrconf_lock);
+ set_wmb(idev->dead, 1);
+ /* protected by rtnl_lock */
+ rcu_assign_pointer(dev->ip6_ptr, NULL);
/* Step 1.5: remove snmp6 entry */
snmp6_unregister_dev(idev);
@@ -3348,10 +3343,10 @@ static void __ipv6_ifa_notify(int event,
static void ipv6_ifa_notify(int event, struct inet6_ifaddr *ifp)
{
- read_lock_bh(&addrconf_lock);
+ rcu_read_lock_bh();
if (likely(ifp->idev->dead == 0))
__ipv6_ifa_notify(event, ifp);
- read_unlock_bh(&addrconf_lock);
+ rcu_read_unlock_bh();
}
#ifdef CONFIG_SYSCTL
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 39ec528..8d71496 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -57,7 +57,7 @@ ip6_onlink(struct in6_addr *addr, struct
int onlink;
onlink = 0;
- read_lock(&addrconf_lock);
+ rcu_read_lock();
idev = __in6_dev_get(dev);
if (idev) {
read_lock_bh(&idev->lock);
@@ -69,7 +69,7 @@ ip6_onlink(struct in6_addr *addr, struct
}
read_unlock_bh(&idev->lock);
}
- read_unlock(&addrconf_lock);
+ rcu_read_unlock();
return onlink;
}
diff --git a/net/ipv6/ipv6_syms.c b/net/ipv6/ipv6_syms.c
index 1648278..628f1b6 100644
--- a/net/ipv6/ipv6_syms.c
+++ b/net/ipv6/ipv6_syms.c
@@ -15,7 +15,6 @@ EXPORT_SYMBOL(ndisc_mc_map);
EXPORT_SYMBOL(register_inet6addr_notifier);
EXPORT_SYMBOL(unregister_inet6addr_notifier);
EXPORT_SYMBOL(ip6_route_output);
-EXPORT_SYMBOL(addrconf_lock);
EXPORT_SYMBOL(ipv6_setsockopt);
EXPORT_SYMBOL(ipv6_getsockopt);
EXPORT_SYMBOL(inet6_register_protosw);
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index c20d282..5bdc117 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -321,9 +321,9 @@ static void sctp_v6_copy_addrlist(struct
struct inet6_ifaddr *ifp;
struct sctp_sockaddr_entry *addr;
- read_lock(&addrconf_lock);
+ rcu_read_lock();
if ((in6_dev = __in6_dev_get(dev)) == NULL) {
- read_unlock(&addrconf_lock);
+ rcu_read_unlock();
return;
}
@@ -342,7 +342,7 @@ static void sctp_v6_copy_addrlist(struct
}
read_unlock(&in6_dev->lock);
- read_unlock(&addrconf_lock);
+ rcu_read_unlock();
}
/* Initialize a sockaddr_storage from in incoming skb. */
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* Re: [rfc][patch] ipvs: use proper timeout instead of fixed value
From: Horms @ 2006-05-05 3:20 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, wensong, ja
In-Reply-To: <20060505025111.GA29142@gospo.rdu.redhat.com>
On Thu, May 04, 2006 at 10:51:11PM -0400, Andy Gospodarek wrote:
> On Fri, May 05, 2006 at 09:47:56AM +0900, Horms wrote:
> > On Thu, May 04, 2006 at 04:11:16PM -0400, Andy Gospodarek wrote:
> > >
> > > Instead of using the default timeout of 3 minutes, this uses the timeout
> > > specific to the protocol used for the connection. The 3 minute timeout
> > > seems somewhat arbitrary (though I know it is used other places in the
> > > ipvs code) and when failing over it would be much nicer to use one of
> > > the configured timeout values.
> >
> > Hi Andy,
> >
> > I agree that the current value is somewhat arbitary,
> > however I'm more in favour of setting it idependantly
> > of other timeouts, perhaps via proc. In any case,
> > won't pp->timeout_table[cp->state] be rather long in
> > the ESTABLISHED case?
> >
>
> Horms,
>
> I agree that there could be a long timeout for ESTABLISHED connections,
> but I've run across a situation where I need exactly that. When testing
> failover from master to backup I realize that all of my interactive
> sessions get dropped much sooner than the timeout I've configured (mine
> is currently set for much longer than 3 minutes). If I wanted
> established connections to timeout quickly I would set the timeout to be
> a small value.
Sorry, I missunderstood your patch completely the first time around.
Yes I think this is an excellent idea. Assuming its tested and works
I'm happy to sign off on it and prod DaveM.
--
Horms http://www.vergenet.net/~horms/
^ permalink raw reply
* Re: [RFC PATCH] [IPV6] ADDRCONF: Convert addrconf_lock to RCU.
From: Herbert Xu @ 2006-05-05 4:08 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ????; +Cc: davem, netdev, yoshfuji
In-Reply-To: <20060505.122452.46183936.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / ???? <yoshfuji@linux-ipv6.org> wrote:
>
> @@ -2291,10 +2287,9 @@ static int addrconf_ifdown(struct net_de
> Do not dev_put!
> */
> if (how == 1) {
> - write_lock_bh(&addrconf_lock);
> - dev->ip6_ptr = NULL;
> - idev->dead = 1;
> - write_unlock_bh(&addrconf_lock);
> + set_wmb(idev->dead, 1);
> + /* protected by rtnl_lock */
> + rcu_assign_pointer(dev->ip6_ptr, NULL);
A pet peeve of mine: As a general rule you do not need to use
rcu_assign_pointer when clearing an RCU pointer. The whole point
of that construct is to place a barrier between initialising an
object and assigning the address of that object to the pointer.
Since the object pointed to by NULL requires no initialisation, you
don't need the barrier.
I'd also like to know the purpose of the wmb after idev->dead = 1.
Thanks,
--
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
* RE: pci_enable_msix throws up error
From: Ayaz Abdulla @ 2006-05-05 5:14 UTC (permalink / raw)
To: ravinandan.arakali, linux-kernel; +Cc: Ananda. Raju, netdev, Leonid Grossman
I noticed the same behaviour, i.e. can not use both MSI and MSIX without
rebooting.
I had sent a message to the maintainer of the MSI/MSIX source a few
months ago and got a response that they were working on fixing it. Not
sure what the progress is on it.
Ayaz
nvpublic
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Ravinandan Arakali
Sent: Thursday, May 04, 2006 4:16 PM
To: linux-kernel@vger.kernel.org
Cc: Ananda. Raju; netdev@vger.kernel.org; Leonid Grossman
Subject: pci_enable_msix throws up error
Hi,
I am seeing the following problem with MSI/MSI-X.
Note: I am copying netdev since other network drivers use
this feature and somebody on the list could throw light.
Our 10G network card(Xframe II) supports MSI and MSI-X.
When I load/unload the driver with MSI support followed
by an attempt to load with MSI-X, I get the following
message from pci_enable_msix:
"Can't enable MSI-X. Device already has an MSI vector assigned"
I seem to be doing the correct things when unloading the
MSI driver. Basically, I do free_irq() followed by pci_disable_msi().
Any idea what I am missing ?
Further analysis:
Looking at the code, the following check(when it finds a match) in
msi_lookup_vector(called by pci_enable_msix) seems to throw up this
message:
if (!msi_desc[vector] || msi_desc[vector]->dev != dev ||
msi_desc[vector]->msi_attrib.type != type ||
msi_desc[vector]->msi_attrib.default_vector != dev->irq)
pci_enable_msi, on successful completion will populate the
fields in msi_desc. But neither pci_disable_msi nor free_irq
seems to undo/unpopulate the msi_desc table.
Could this be the cause for the problem ?
Thanks,
Ravi
-
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] bcm43xx-d80211: proper implementation of virtual interface support
From: Ulrich Kunitz @ 2006-05-05 5:45 UTC (permalink / raw)
To: Jiri Benc; +Cc: Ivo van Doorn, Marcus Better, netdev
In-Reply-To: <20060505002215.1972e12b@logostar.upir.cz>
> The actual problem is with receiving. ACK frames need to be sent exactly
> after SIFS interval (10 or 16 microseconds depending on a PHY, +/- 10%)
> after last bit of the frame was received. This means it cannot be done in a
> software. You need to tell the hardware about MAC address you are using and
> hardware will ACK all frames destined to that address (well, actually only
> that received with valid FCS, but it doesn't matter). And most hardware
> don't allow to specify more MAC addresses.
>
> Jiri
Good explanation. ZD1211 allows to specify a second RX address, I
wondered, what this is good for. So for ZD1211 we could support
two virtual interfaces. However in AP mode one virtual device
would have to send the beacons on its own. But there could be also
support for one interface in AP and the other in STA mode.
Uli
--
Ulrich Kunitz - kune@deine-taler.de
^ permalink raw reply
* 2.6.17-rc1: ping: sendmsg: No buffer space available
From: Ville Herva @ 2006-05-05 6:39 UTC (permalink / raw)
To: netdev
In-Reply-To: <20050606224729.B12034@flint.arm.linux.org.uk>
I don't know if
http://bugzilla.kernel.org/show_bug.cgi?id=4615
has been solved yet, but I'm seeing a similar thing with 2.6.17-rc1 and a ppp
connection over ssh.
Earlier kernels (at least linux-2.6.14-rc4) did not show this with the
exactly same settings.
How it happens:
- open up the ppp connection over ssh.
- stress it a bit with samba
- after a few minutes, pinging the remote end gives
ping: sendmsg: No buffer space available
and I have to re-establish the connection
The ssh connection seems solid afaict. Also, with bare ssh connetion, no
problems occur even under load. The ppp connection seems prone to hang
especially with SMB traffic (don't know why.)
In dmesg, there seems to be nothing relevant. /proc/slabinfo doesn't seem to
to have anything alerting in it.
The underlying connection is ADSL (8/1Mbit). The driver is eepro100. ppp is
ppp-2.4.3-6.2.1.
ppp_deflate is in use:
ppp_deflate 5536 3
zlib_deflate 18360 1 ppp_deflate
bsd_comp 5312 0
ppp_async 9664 2
crc_ccitt 1952 1 ppp_async
ppp_generic 20468 11 ppp_deflate,bsd_comp,ppp_async
^ permalink raw reply
* Fw: [Bugme-new] [Bug 6495] New: Vlan MTU Fragmentation
From: Andrew Morton @ 2006-05-05 6:56 UTC (permalink / raw)
To: netdev; +Cc: bugme-daemon@kernel-bugs.osdl.org
Begin forwarded message:
Date: Thu, 4 May 2006 23:15:56 -0700
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 6495] New: Vlan MTU Fragmentation
http://bugzilla.kernel.org/show_bug.cgi?id=6495
Summary: Vlan MTU Fragmentation
Kernel Version: 2.6.16.12
Status: NEW
Severity: normal
Owner: shemminger@osdl.org
Submitter: slavon@bigtelecom.ru
Steps to reproduce:
ifconfing eth0 mtu 1500
ifconfing eth0.100 mtu 1500
ping www.ru -s 2000
-- BAD --
----------------
ifconfing eth0 mtu 1500
ifconfing eth0.100 mtu 1496
ping www.ru -s 2000
--NORMAL--
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* Re: pci_enable_msix throws up error
From: Andi Kleen @ 2006-05-05 8:44 UTC (permalink / raw)
To: Ayaz Abdulla
Cc: ravinandan.arakali, linux-kernel, Ananda. Raju, netdev,
Leonid Grossman
In-Reply-To: <DBFABB80F7FD3143A911F9E6CFD477B00BA5E264@hqemmail02.nvidia.com>
On Friday 05 May 2006 07:14, Ayaz Abdulla wrote:
> I noticed the same behaviour, i.e. can not use both MSI and MSIX without
> rebooting.
>
> I had sent a message to the maintainer of the MSI/MSIX source a few
> months ago and got a response that they were working on fixing it. Not
> sure what the progress is on it.
The best way to make progress faster would be for someone like you
who needs it to submit a patch to fix it then.
-Andi
^ permalink raw reply
* [x86_64, NET] smp_rmb() in dst_destroy() seems very expensive, ditto in kfree_skb()
From: Eric Dumazet @ 2006-05-05 8:49 UTC (permalink / raw)
To: David S. Miller, Andi Kleen; +Cc: netdev
In-Reply-To: <20060504.162546.88959729.davem@davemloft.net>
On a dual opteron box, I noticed high oprofile numbers in net/core/dst.c
, function dst_destroy(struct dst_entry * dst)
It appears the smb_rmb() done at the begining of dst_destroy() is the
killer (this is a lfence machine instruction, that apparently is doing
a *lot* of things... may be IO related...) that is responsible for 80%
of the cpu time used by the whole function.
I dont understand very much all variety of available barriers, and why
this smb_rmb() is used in dst_destroy().
I missed the corresponding wmb that should be done somewhere in the dst
code.
Do we have an alternative to smp_rmb() in the dst_destroy()/ kfree_skb()
context ?
Documentation/memory-barriers.txt mentions several 'advanced barrier
functions' but I'm really lost.
ffffffff803b5f80 <dst_destroy>: /* dst_destroy total: 237528 0.5635 */
163 3.9e-04 :ffffffff803b5f80: push %r12
3483 0.0083 :ffffffff803b5f82: push %rbp
:ffffffff803b5f83: mov %rdi,%rbp
7 1.7e-05 :ffffffff803b5f86: push %rbx
201 4.8e-04 :ffffffff803b5f87: lfence
192133 0.4558 :ffffffff803b5f8a: data16
:ffffffff803b5f8b: data16
:ffffffff803b5f8c: nop
4 9.5e-06 :ffffffff803b5f8d: data16
:ffffffff803b5f8e: data16
:ffffffff803b5f8f: nop
:ffffffff803b5f90: mov 0x90(%rbp),%rdi
ffffffff803ae8a0 <kfree_skb>: /* kfree_skb total: 145240 0.3446 */
1873 0.0044 :ffffffff803ae8a0: test %rdi,%rdi
2127 0.0050 :ffffffff803ae8a3: je ffffffff803ae8c7
<kfree_skb+0x27>
81 1.9e-04 :ffffffff803ae8a5: mov 0xbc(%rdi),%eax
1 2.4e-06 :ffffffff803ae8ab: dec %eax
2303 0.0055 :ffffffff803ae8ad: jne ffffffff803ae8b4
<kfree_skb+0x14>
221 5.2e-04 :ffffffff803ae8af: lfence
137609 0.3265 :ffffffff803ae8b2: jmp ffffffff803ae8c2
<kfree_skb+0x22>
:ffffffff803ae8b4: lock decl 0xbc(%rdi)
38 9.0e-05 :ffffffff803ae8bb: sete %al
86 2.0e-04 :ffffffff803ae8be: test %al,%al
:ffffffff803ae8c0: je ffffffff803ae8c7
<kfree_skb+0x27>
806 0.0019 :ffffffff803ae8c2: jmpq ffffffff803ae7d0
<__kfree_skb>
95 2.3e-04 :ffffffff803ae8c7: repz retq
Thank you
Eric
^ permalink raw reply
* Re: VJ Channel API - driver level (PATCH)
From: Evgeniy Polyakov @ 2006-05-05 9:36 UTC (permalink / raw)
To: David S. Miller; +Cc: alex, caitlinb, Leonid.Grossman, shemminger, netdev
In-Reply-To: <20060504.160432.48902082.davem@davemloft.net>
On Thu, May 04, 2006 at 04:04:32PM -0700, David S. Miller (davem@davemloft.net) wrote:
> Hardware folks are jumping the gun and it's very annoying and takes
> precious time away from thinking about and working on the
> implementation.
Hardware folks could also create it's own implementation and show community
if theirs approach is good or not.
--
Evgeniy Polyakov
^ permalink raw reply
* too many iterations (6) in nv_nic_irq
From: Carl-Daniel Hailfinger @ 2006-05-05 10:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Ayaz Abdulla, netdev
Hi Jeff,
IIRC you had "too many iterations (6) in nv_nic_irq" appear regularly
in your dmesg with kernel 2.6.16. Did this disappear in more recent
kernels? If not, can you try the disable_msi and disable_msix module
parameters if they help in your case?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
^ permalink raw reply
* Re: [x86_64, NET] smp_rmb() in dst_destroy() seems very expensive, ditto in kfree_skb()
From: Herbert Xu @ 2006-05-05 10:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, ak, netdev
In-Reply-To: <445B11A3.1020407@cosmosbay.com>
Eric Dumazet <dada1@cosmosbay.com> wrote:
>
> I missed the corresponding wmb that should be done somewhere in the dst
> code.
The wmb for dst's is in dst_release while skb's have an implicit barrier
through atomic_dec_and_test in kfree_skb.
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
* Re: [PATCH wireless-dev] d80211: Add support for user space client MLME
From: Johannes Berg @ 2006-05-05 10:13 UTC (permalink / raw)
To: Jouni Malinen; +Cc: Jiri Benc, John W. Linville, netdev, jkmaline
In-Reply-To: <20060504164423.GA12204@instant802.com>
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
On Thu, 2006-05-04 at 09:44 -0700, Jouni Malinen wrote:
> Yes. Currently, I'm just using a configuration file parameter for this,
> but this information should eventually be exported by the kernel code to
> allow wpa_supplicant to select which mode to use without requiring user
> configuration.
For the upcoming netlink interface, I'd suggest having a group of calls
that are needed for full-mac devices (similar to the current wext) and a
second group that are needed for soft-mlme, that way you simply try out
one for the soft-mlme and if not implemented fall back to hard, or the
other way around. Maybe.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH] bcm43xx-d80211: proper implementation of virtual interface support
From: Johannes Berg @ 2006-05-05 10:15 UTC (permalink / raw)
To: Ulrich Kunitz; +Cc: Jiri Benc, Ivo van Doorn, Marcus Better, netdev
In-Reply-To: <Pine.LNX.4.58.0605050738240.21178@p15091797.pureserver.info>
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
On Fri, 2006-05-05 at 07:45 +0200, Ulrich Kunitz wrote:
> But there could be also
> support for one interface in AP and the other in STA mode.
That's actually a much more interesting use case for WDS.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ 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