* Re: [GENETLINK]: Question: global lock (genl_mutex) possible refinement?
From: Richard MUSIL @ 2007-07-23 16:45 UTC (permalink / raw)
To: Thomas Graf; +Cc: Patrick McHardy, netdev
In-Reply-To: <20070723102909.GA9285@postel.suug.ch>
Thomas Graf wrote:
> Actually there is no reason to not use separate locks for the
> message serialization and the protection of the list of registered
> families. There is only one lock simply for the reason that I've
> never thought of anybody could think of registering a new genetlink
> family while processing a message.
Thomas,
I have been giving it a second thought and came up with something more
complex. The idea is to have locking granularity at the level of
individual families.
Message processing will lock only the family it currently processes
*and* global messaging lock, while family management routines will take
global family lock, and particular lock for family.
This should allow running registration/dereg. from message handler as
long as the family involved is not the same family in which context the
message is being processed.
On the other hand, using lock per family, ensures that message handlers
are not (accidentally) called with invalid references. This should not
be so much problem for dumpit handler, but doit uses for example family
attrs. So I added another patch which implements above described
functionality below.
> Alternatively you could also postpone the registration of the new
> genetlink family to a workqueue.
To be honest, I cannot judge whether the additional complexity I propose
outweighs the gains. In my book, it definitely does, since I like the
easiness of doit, dumpit handlers and implementation using those is
pretty straightforward.
In the long term I believe that refining the locking could also help
in situations where there is heavy traffic over genetlink, then
all family manipulations will not be blocked (which is currently the case).
Let me know, if you accept it as a patch, or should I eventually go for
plan B ;).
--
Richard
>From 63b3ee722402533aed6e137347e41ab1a1fa1127 Mon Sep 17 00:00:00 2001
From: Richard Musil <richard.musil@st.com>
Date: Mon, 23 Jul 2007 15:12:09 +0200
Subject: [PATCH] Added private mutex for each genetlink family (struct genl_family).
This mutex is used to synchronize access to particular family between message
processing handlers and management routines for families
(registering/unregistering families/ops).
This should ensure that another family can be registered or unregistered from
inside genetlink message handler. Trying to register or unregister family
from its own handler will still cause deadlock.
---
include/net/genetlink.h | 1 +
net/netlink/genetlink.c | 98 +++++++++++++++++++++++++++++++++--------------
2 files changed, 70 insertions(+), 29 deletions(-)
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index b6eaca1..681ad13 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -25,6 +25,7 @@ struct genl_family
struct nlattr ** attrbuf; /* private */
struct list_head ops_list; /* private */
struct list_head family_list; /* private */
+ struct mutex lock; /* private */
};
/**
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 5ee18eb..0104267 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -40,16 +40,30 @@ static void genl_unlock(void)
static DEFINE_MUTEX(genl_fam_mutex); /* serialization for family list management */
-static inline void genl_fam_lock(void)
+static inline void genl_fam_lock(struct genl_family *family)
{
mutex_lock(&genl_fam_mutex);
+ if (family)
+ mutex_lock(&family->lock);
}
-static inline genl_fam_unlock(void)
+static inline void genl_fam_unlock(struct genl_family *family)
{
+ if (family)
+ mutex_unlock(&family->lock);
mutex_unlock(&genl_fam_mutex);
}
+static inline void genl_onefam_lock(struct genl_family *family)
+{
+ mutex_lock(&family->lock);
+}
+
+static inline void genl_onefam_unlock(struct genl_family *family)
+{
+ mutex_unlock(&family->lock);
+}
+
#define GENL_FAM_TAB_SIZE 16
#define GENL_FAM_TAB_MASK (GENL_FAM_TAB_SIZE - 1)
@@ -162,9 +176,9 @@ int genl_register_ops(struct genl_family *family, struct genl_ops *ops)
if (ops->policy)
ops->flags |= GENL_CMD_CAP_HASPOL;
- genl_fam_lock();
+ genl_fam_lock(family);
list_add_tail(&ops->ops_list, &family->ops_list);
- genl_fam_unlock();
+ genl_fam_unlock(family);
genl_ctrl_event(CTRL_CMD_NEWOPS, ops);
err = 0;
@@ -192,16 +206,16 @@ int genl_unregister_ops(struct genl_family *family, struct genl_ops *ops)
{
struct genl_ops *rc;
- genl_fam_lock();
+ genl_fam_lock(family);
list_for_each_entry(rc, &family->ops_list, ops_list) {
if (rc == ops) {
list_del(&ops->ops_list);
- genl_fam_unlock();
+ genl_fam_unlock(family);
genl_ctrl_event(CTRL_CMD_DELOPS, ops);
return 0;
}
}
- genl_fam_unlock();
+ genl_fam_unlock(family);
return -ENOENT;
}
@@ -228,8 +242,9 @@ int genl_register_family(struct genl_family *family)
goto errout;
INIT_LIST_HEAD(&family->ops_list);
+ mutex_init(&family->lock);
- genl_fam_lock();
+ genl_fam_lock(family);
if (genl_family_find_byname(family->name)) {
err = -EEXIST;
@@ -263,14 +278,14 @@ int genl_register_family(struct genl_family *family)
family->attrbuf = NULL;
list_add_tail(&family->family_list, genl_family_chain(family->id));
- genl_fam_unlock();
+ genl_fam_unlock(family);
genl_ctrl_event(CTRL_CMD_NEWFAMILY, family);
return 0;
errout_locked:
- genl_fam_unlock();
+ genl_fam_unlock(family);
errout:
return err;
}
@@ -287,7 +302,7 @@ int genl_unregister_family(struct genl_family *family)
{
struct genl_family *rc;
- genl_fam_lock();
+ genl_fam_lock(family);
list_for_each_entry(rc, genl_family_chain(family->id), family_list) {
if (family->id != rc->id || strcmp(rc->name, family->name))
@@ -295,14 +310,16 @@ int genl_unregister_family(struct genl_family *family)
list_del(&rc->family_list);
INIT_LIST_HEAD(&family->ops_list);
- genl_fam_unlock();
+
+ genl_fam_unlock(family);
+ mutex_destroy(&family->lock);
kfree(family->attrbuf);
genl_ctrl_event(CTRL_CMD_DELFAMILY, family);
return 0;
}
- genl_fam_unlock();
+ genl_fam_unlock(family);
return -ENOENT;
}
@@ -315,38 +332,57 @@ static int genl_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
struct genlmsghdr *hdr = nlmsg_data(nlh);
int hdrlen, err;
+ genl_fam_lock(NULL);
family = genl_family_find_byid(nlh->nlmsg_type);
- if (family == NULL)
+ if (family == NULL) {
+ genl_fam_unlock(NULL);
return -ENOENT;
+ }
+
+ /* get particular family lock, but release global family lock
+ * so registering operations for other families are possible */
+ genl_onefam_lock(family);
+ genl_fam_unlock(NULL);
hdrlen = GENL_HDRLEN + family->hdrsize;
- if (nlh->nlmsg_len < nlmsg_msg_size(hdrlen))
- return -EINVAL;
+ if (nlh->nlmsg_len < nlmsg_msg_size(hdrlen)) {
+ err = -EINVAL;
+ goto unlock_out;
+ }
ops = genl_get_cmd(hdr->cmd, family);
- if (ops == NULL)
- return -EOPNOTSUPP;
+ if (ops == NULL) {
+ err = -EOPNOTSUPP;
+ goto unlock_out;
+ }
if ((ops->flags & GENL_ADMIN_PERM) &&
- security_netlink_recv(skb, CAP_NET_ADMIN))
- return -EPERM;
+ security_netlink_recv(skb, CAP_NET_ADMIN)) {
+ err = -EPERM;
+ goto unlock_out;
+ }
if (nlh->nlmsg_flags & NLM_F_DUMP) {
- if (ops->dumpit == NULL)
- return -EOPNOTSUPP;
+ if (ops->dumpit == NULL) {
+ err = -EOPNOTSUPP;
+ goto unlock_out;
+ }
- return netlink_dump_start(genl_sock, skb, nlh,
+ err = netlink_dump_start(genl_sock, skb, nlh,
ops->dumpit, ops->done);
+ goto unlock_out;
}
- if (ops->doit == NULL)
- return -EOPNOTSUPP;
+ if (ops->doit == NULL) {
+ err = -EOPNOTSUPP;
+ goto unlock_out;
+ }
if (family->attrbuf) {
err = nlmsg_parse(nlh, hdrlen, family->attrbuf, family->maxattr,
ops->policy);
if (err < 0)
- return err;
+ goto unlock_out;
}
info.snd_seq = nlh->nlmsg_seq;
@@ -356,7 +392,11 @@ static int genl_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
info.userhdr = nlmsg_data(nlh) + GENL_HDRLEN;
info.attrs = family->attrbuf;
- return ops->doit(skb, &info);
+ err = ops->doit(skb, &info);
+
+unlock_out:
+ genl_onefam_unlock(family);
+ return err;
}
static void genl_rcv(struct sock *sk, int len)
@@ -437,7 +477,7 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct netlink_callback *cb)
int fams_to_skip = cb->args[1];
if (chains_to_skip != 0)
- genl_fam_lock();
+ genl_fam_lock(NULL);
for (i = 0; i < GENL_FAM_TAB_SIZE; i++) {
if (i < chains_to_skip)
@@ -457,7 +497,7 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct netlink_callback *cb)
errout:
if (chains_to_skip != 0)
- genl_fam_unlock();
+ genl_fam_unlock(NULL);
cb->args[0] = i;
cb->args[1] = n;
--
1.5.1.6
^ permalink raw reply related
* Re: [PATCH]: Resurrect napi_poll patch.
From: Andi Kleen @ 2007-07-23 17:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Andi Kleen, David Miller, netdev, rusty, jgarzik
In-Reply-To: <20070723105822.3a9fa152@oldman.hamilton.local>
On Mon, Jul 23, 2007 at 10:58:22AM +0100, Stephen Hemminger wrote:
> On 21 Jul 2007 15:26:00 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
>
> > David Miller <davem@davemloft.net> writes:
> > >
> > > Good candidates for taking advantage of multi-napi are:
> > >
> > > 1) e1000
> > > 2) ucc_geth
> > > 3) ehea
> > > 4) sunvnet
> >
> > s2io.c
>
> sky2.c could use it because of issues with dual-port that share
> one napi for status.
Sorry, I didn't parse the sentence. Did you mean "couldn't use it" ...?
Also can you elaborate why it shouldn't work?
-Andi
^ permalink raw reply
* Re: [PATCH] make xfrm_audit_log more generic
From: Joy Latten @ 2007-07-23 17:49 UTC (permalink / raw)
To: James Morris; +Cc: netdev, davem, linux-audit, sgrubb
In-Reply-To: <Line.LNX.4.64.0707192140350.12692@d.namei>
On Thu, 2007-07-19 at 21:45 -0400, James Morris wrote:
> On Thu, 19 Jul 2007, Joy Latten wrote:
>
> > --- linux-2.6.22/include/linux/audit.h 2007-07-19 13:17:22.000000000 -0500
> > +++ linux-2.6.22.patch/include/linux/audit.h 2007-07-19 13:21:29.000000000 -0500
> > @@ -108,10 +108,7 @@
> > #define AUDIT_MAC_CIPSOV4_DEL 1408 /* NetLabel: del CIPSOv4 DOI entry */
> > #define AUDIT_MAC_MAP_ADD 1409 /* NetLabel: add LSM domain mapping */
> > #define AUDIT_MAC_MAP_DEL 1410 /* NetLabel: del LSM domain mapping */
> > -#define AUDIT_MAC_IPSEC_ADDSA 1411 /* Add a XFRM state */
> > -#define AUDIT_MAC_IPSEC_DELSA 1412 /* Delete a XFRM state */
> > -#define AUDIT_MAC_IPSEC_ADDSPD 1413 /* Add a XFRM policy */
> > -#define AUDIT_MAC_IPSEC_DELSPD 1414 /* Delete a XFRM policy */
> > +#define AUDIT_MAC_IPSEC_EVENT 1411 /* Audit IPSec events */
>
> Will this cause existing applications to break?
>
Perhaps someone in audit list could help answer this.
During testing, because I changed the above defines, all
IPSec events are listed as "MAC_IPSEC_ADDSA" for now without
userspace change. Is this ok? Or is there a better way to
migrate this change in? Perhaps leave previous IPsec defines
and just add in a new one and use it? If that is better
approach, let me know and I will change code to accomodate.
Regards,
Joy
^ permalink raw reply
* Re: [PATCH] make xfrm_audit_log more generic
From: Steve Grubb @ 2007-07-23 18:11 UTC (permalink / raw)
To: Joy Latten; +Cc: netdev, linux-audit, James Morris, davem
In-Reply-To: <1185212957.15699.322.camel@faith.austin.ibm.com>
On Monday 23 July 2007 13:49:17 Joy Latten wrote:
> > Will this cause existing applications to break?
>
> Perhaps someone in audit list could help answer this.
Probably. Its better to take a new number and let the old ones sit idle.
-Steve
^ permalink raw reply
* Re: [Bugme-new] [Bug 8789] New: Error inserting ipt_LOG (mod_path): Device or resource busy
From: Patrick McHardy @ 2007-07-23 18:18 UTC (permalink / raw)
To: t.artem; +Cc: Andrew Morton, netdev, bugme-daemon
In-Reply-To: <20070721010207.b88e1364.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
Andrew Morton wrote:
> On Sat, 21 Jul 2007 00:44:08 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
>
>
>>http://bugzilla.kernel.org/show_bug.cgi?id=8789
>>
>> Summary: Error inserting ipt_LOG (mod_path): Device or resource
>> busy
>
>
> A 2.6.12 -> 2.6.22 regression.
Crap, that was my fault.
T., can you please test whether this patch fixes it?
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 2332 bytes --]
diff --git a/net/bridge/netfilter/ebt_log.c b/net/bridge/netfilter/ebt_log.c
index 031bfa4..984e9c6 100644
--- a/net/bridge/netfilter/ebt_log.c
+++ b/net/bridge/netfilter/ebt_log.c
@@ -196,10 +196,8 @@ static int __init ebt_log_init(void)
ret = ebt_register_watcher(&log);
if (ret < 0)
return ret;
- ret = nf_log_register(PF_BRIDGE, &ebt_log_logger);
- if (ret < 0 && ret != -EEXIST)
- ebt_unregister_watcher(&log);
- return ret;
+ nf_log_register(PF_BRIDGE, &ebt_log_logger);
+ return 0;
}
static void __exit ebt_log_fini(void)
diff --git a/net/bridge/netfilter/ebt_ulog.c b/net/bridge/netfilter/ebt_ulog.c
index 9411db6..6fec352 100644
--- a/net/bridge/netfilter/ebt_ulog.c
+++ b/net/bridge/netfilter/ebt_ulog.c
@@ -308,12 +308,8 @@ static int __init ebt_ulog_init(void)
else if ((ret = ebt_register_watcher(&ulog)))
sock_release(ebtulognl->sk_socket);
- if (nf_log_register(PF_BRIDGE, &ebt_ulog_logger) < 0) {
- printk(KERN_WARNING "ebt_ulog: not logging via ulog "
- "since somebody else already registered for PF_BRIDGE\n");
- /* we cannot make module load fail here, since otherwise
- * ebtables userspace would abort */
- }
+ if (ret == 0)
+ nf_log_register(PF_BRIDGE, &ebt_ulog_logger);
return ret;
}
diff --git a/net/ipv4/netfilter/ipt_LOG.c b/net/ipv4/netfilter/ipt_LOG.c
index 5937ad1..127a5e8 100644
--- a/net/ipv4/netfilter/ipt_LOG.c
+++ b/net/ipv4/netfilter/ipt_LOG.c
@@ -479,10 +479,8 @@ static int __init ipt_log_init(void)
ret = xt_register_target(&ipt_log_reg);
if (ret < 0)
return ret;
- ret = nf_log_register(PF_INET, &ipt_log_logger);
- if (ret < 0 && ret != -EEXIST)
- xt_unregister_target(&ipt_log_reg);
- return ret;
+ nf_log_register(PF_INET, &ipt_log_logger);
+ return 0;
}
static void __exit ipt_log_fini(void)
diff --git a/net/ipv6/netfilter/ip6t_LOG.c b/net/ipv6/netfilter/ip6t_LOG.c
index b05327e..6ab9900 100644
--- a/net/ipv6/netfilter/ip6t_LOG.c
+++ b/net/ipv6/netfilter/ip6t_LOG.c
@@ -493,10 +493,8 @@ static int __init ip6t_log_init(void)
ret = xt_register_target(&ip6t_log_reg);
if (ret < 0)
return ret;
- ret = nf_log_register(PF_INET6, &ip6t_logger);
- if (ret < 0 && ret != -EEXIST)
- xt_unregister_target(&ip6t_log_reg);
- return ret;
+ nf_log_register(PF_INET6, &ip6t_logger);
+ return 0;
}
static void __exit ip6t_log_fini(void)
^ permalink raw reply related
* [2.6 patch] remove Documentation/networking/net-modules.txt
From: Adrian Bunk @ 2007-07-23 18:31 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linux-kernel
kAccording to git, the only one who touched this file during the last
5 years was me when removing drivers...
modinfo offers a less ancient version of this information.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
Documentation/networking/00-INDEX | 2
Documentation/networking/net-modules.txt | 315 -----------------------
2 files changed, 317 deletions(-)
--- linux-2.6.22-rc6-mm1/Documentation/networking/00-INDEX.old 2007-07-23 20:28:51.000000000 +0200
+++ linux-2.6.22-rc6-mm1/Documentation/networking/00-INDEX 2007-07-23 20:28:59.000000000 +0200
@@ -80,8 +80,6 @@
- Behaviour of cards under Multicast
ncsa-telnet
- notes on how NCSA telnet (DOS) breaks with MTU discovery enabled.
-net-modules.txt
- - info and "insmod" parameters for all network driver modules.
netdevices.txt
- info on network device driver functions exported to the kernel.
olympic.txt
--- linux-2.6.22-rc6-mm1/Documentation/networking/net-modules.txt 2007-07-12 20:43:37.000000000 +0200
+++ /dev/null 2006-09-19 00:45:31.000000000 +0200
@@ -1,315 +0,0 @@
-Wed 2-Aug-95 <matti.aarnio@utu.fi>
-
- Linux network driver modules
-
- Do not mistake this for "README.modules" at the top-level
- directory! That document tells about modules in general, while
- this one tells only about network device driver modules.
-
- This is a potpourri of INSMOD-time(*) configuration options
- (if such exists) and their default values of various modules
- in the Linux network drivers collection.
-
- Some modules have also hidden (= non-documented) tunable values.
- The choice of not documenting them is based on general belief, that
- the less the user needs to know, the better. (There are things that
- driver developers can use, others should not confuse themselves.)
-
- In many cases it is highly preferred that insmod:ing is done
- ONLY with defining an explicit address for the card, AND BY
- NOT USING AUTO-PROBING!
-
- Now most cards have some explicitly defined base address that they
- are compiled with (to avoid auto-probing, among other things).
- If that compiled value does not match your actual configuration,
- do use the "io=0xXXX" -parameter for the insmod, and give there
- a value matching your environment.
-
- If you are adventurous, you can ask the driver to autoprobe
- by using the "io=0" parameter, however it is a potentially dangerous
- thing to do in a live system. (If you don't know where the
- card is located, you can try autoprobing, and after possible
- crash recovery, insmod with proper IO-address..)
-
- --------------------------
- (*) "INSMOD-time" means when you load module with
- /sbin/insmod you can feed it optional parameters.
- See "man insmod".
- --------------------------
-
-
- 8390 based Network Modules (Paul Gortmaker, Nov 12, 1995)
- --------------------------
-
-(Includes: smc-ultra, ne, wd, 3c503, hp, hp-plus, e2100 and ac3200)
-
-The 8390 series of network drivers now support multiple card systems without
-reloading the same module multiple times (memory efficient!) This is done by
-specifying multiple comma separated values, such as:
-
- insmod 3c503.o io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1
-
-The above would have the one module controlling four 3c503 cards, with card 2
-and 4 using external transceivers. The "insmod" manual describes the usage
-of comma separated value lists.
-
-It is *STRONGLY RECOMMENDED* that you supply "io=" instead of autoprobing.
-If an "io=" argument is not supplied, then the ISA drivers will complain
-about autoprobing being not recommended, and begrudgingly autoprobe for
-a *SINGLE CARD ONLY* -- if you want to use multiple cards you *have* to
-supply an "io=0xNNN,0xQQQ,..." argument.
-
-The ne module is an exception to the above. A NE2000 is essentially an
-8390 chip, some bus glue and some RAM. Because of this, the ne probe is
-more invasive than the rest, and so at boot we make sure the ne probe is
-done last of all the 8390 cards (so that it won't trip over other 8390 based
-cards) With modules we can't ensure that all other non-ne 8390 cards have
-already been found. Because of this, the ne module REQUIRES an "io=0xNNN"
-argument passed in via insmod. It will refuse to autoprobe.
-
-It is also worth noting that auto-IRQ probably isn't as reliable during
-the flurry of interrupt activity on a running machine. Cards such as the
-ne2000 that can't get the IRQ setting from an EEPROM or configuration
-register are probably best supplied with an "irq=M" argument as well.
-
-
-----------------------------------------------------------------------
-Card/Module List - Configurable Parameters and Default Values
-----------------------------------------------------------------------
-
-3c501.c:
- io = 0x280 IO base address
- irq = 5 IRQ
- (Probes ports: 0x280, 0x300)
-
-3c503.c:
- io = 0 (It will complain if you don't supply an "io=0xNNN")
- irq = 0 (IRQ software selected by driver using autoIRQ)
- xcvr = 0 (Use xcvr=1 to select external transceiver.)
- (Probes ports: 0x300, 0x310, 0x330, 0x350, 0x250, 0x280, 0x2A0, 0x2E0)
-
-3c505.c:
- io = 0
- irq = 0
- dma = 6 (not autoprobed)
- (Probes ports: 0x300, 0x280, 0x310)
-
-3c507.c:
- io = 0x300
- irq = 0
- (Probes ports: 0x300, 0x320, 0x340, 0x280)
-
-3c509.c:
- io = 0
- irq = 0
- ( Module load-time probing Works reliably only on EISA, ISA ID-PROBE
- IS NOT RELIABLE! Compile this driver statically into kernel for
- now, if you need it auto-probing on an ISA-bus machine. )
-
-8390.c:
- (No public options, several other modules need this one)
-
-a2065.c:
- Since this is a Zorro board, it supports full autoprobing, even for
- multiple boards. (m68k/Amiga)
-
-ac3200.c:
- io = 0 (Checks 0x1000 to 0x8fff in 0x1000 intervals)
- irq = 0 (Read from config register)
- (EISA probing..)
-
-apricot.c:
- io = 0x300 (Can't be altered!)
- irq = 10
-
-arcnet.c:
- io = 0
- irqnum = 0
- shmem = 0
- num = 0
- DO SET THESE MANUALLY AT INSMOD!
- (When probing, looks at the following possible addresses:
- Suggested ones:
- 0x300, 0x2E0, 0x2F0, 0x2D0
- Other ones:
- 0x200, 0x210, 0x220, 0x230, 0x240, 0x250, 0x260, 0x270,
- 0x280, 0x290, 0x2A0, 0x2B0, 0x2C0,
- 0x310, 0x320, 0x330, 0x340, 0x350, 0x360, 0x370,
- 0x380, 0x390, 0x3A0, 0x3E0, 0x3F0 )
-
-ariadne.c:
- Since this is a Zorro board, it supports full autoprobing, even for
- multiple boards. (m68k/Amiga)
-
-at1700.c:
- io = 0x260
- irq = 0
- (Probes ports: 0x260, 0x280, 0x2A0, 0x240, 0x340, 0x320, 0x380, 0x300)
-
-atarilance.c:
- Supports full autoprobing. (m68k/Atari)
-
-atp.c: *Not modularized*
- (Probes ports: 0x378, 0x278, 0x3BC;
- fixed IRQs: 5 and 7 )
-
-cops.c:
- io = 0x240
- irq = 5
- nodeid = 0 (AutoSelect = 0, NodeID 1-254 is hand selected.)
- (Probes ports: 0x240, 0x340, 0x200, 0x210, 0x220, 0x230, 0x260,
- 0x2A0, 0x300, 0x310, 0x320, 0x330, 0x350, 0x360)
-
-de4x5.c:
- io = 0x000b
- irq = 10
- is_not_dec = 0 -- For non-DEC card using DEC 21040/21041/21140 chip, set this to 1
- (EISA, and PCI probing)
-
-de600.c:
- de600_debug = 0
- (On port 0x378, irq 7 -- lpt1; compile time configurable)
-
-de620.c:
- bnc = 0, utp = 0 <-- Force media by setting either.
- io = 0x378 (also compile-time configurable)
- irq = 7
-
-depca.c:
- io = 0x200
- irq = 7
- (Probes ports: ISA: 0x300, 0x200;
- EISA: 0x0c00 )
-
-dummy.c:
- No options
-
-e2100.c:
- io = 0 (It will complain if you don't supply an "io=0xNNN")
- irq = 0 (IRQ software selected by driver)
- mem = 0 (Override default shared memory start of 0xd0000)
- xcvr = 0 (Use xcvr=1 to select external transceiver.)
- (Probes ports: 0x300, 0x280, 0x380, 0x220)
-
-eepro.c:
- io = 0x200
- irq = 0
- (Probes ports: 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340, 0x360)
-
-eexpress.c:
- io = 0x300
- irq = 0 (IRQ value read from EEPROM)
- (Probes ports: 0x300, 0x270, 0x320, 0x340)
-
-eql.c:
- (No parameters)
-
-ewrk3.c:
- io = 0x300
- irq = 5
- (With module no autoprobing!
- On EISA-bus does EISA probing.
- Static linkage probes ports on ISA bus:
- 0x100, 0x120, 0x140, 0x160, 0x180, 0x1A0, 0x1C0,
- 0x200, 0x220, 0x240, 0x260, 0x280, 0x2A0, 0x2C0, 0x2E0,
- 0x300, 0x340, 0x360, 0x380, 0x3A0, 0x3C0)
-
-hp-plus.c:
- io = 0 (It will complain if you don't supply an "io=0xNNN")
- irq = 0 (IRQ read from configuration register)
- (Probes ports: 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340)
-
-hp.c:
- io = 0 (It will complain if you don't supply an "io=0xNNN")
- irq = 0 (IRQ software selected by driver using autoIRQ)
- (Probes ports: 0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240)
-
-hp100.c:
- hp100_port = 0 (IO-base address)
- (Does EISA-probing, if on EISA-slot;
- On ISA-bus probes all ports from 0x100 thru to 0x3E0
- in increments of 0x020)
-
-hydra.c:
- Since this is a Zorro board, it supports full autoprobing, even for
- multiple boards. (m68k/Amiga)
-
-ibmtr.c:
- io = 0xa20, 0xa24 (autoprobed by default)
- irq = 0 (driver cannot select irq - read from hardware)
- mem = 0 (shared memory base set at 0xd0000 and not yet
- able to override thru mem= parameter.)
-
-lance.c: *Not modularized*
- (PCI, and ISA probing; "CONFIG_PCI" needed for PCI support)
- (Probes ISA ports: 0x300, 0x320, 0x340, 0x360)
-
-loopback.c: *Static kernel component*
-
-ne.c:
- io = 0 (Explicitly *requires* an "io=0xNNN" value)
- irq = 0 (Tries to determine configured IRQ via autoIRQ)
- (Probes ports: 0x300, 0x280, 0x320, 0x340, 0x360)
-
-net_init.c: *Static kernel component*
-
-ni52.c: *Not modularized*
- (Probes ports: 0x300, 0x280, 0x360, 0x320, 0x340
- mems: 0xD0000, 0xD2000, 0xC8000, 0xCA000,
- 0xD4000, 0xD6000, 0xD8000 )
-
-ni65.c: *Not modularized* **16MB MEMORY BARRIER BUG**
- (Probes ports: 0x300, 0x320, 0x340, 0x360)
-
-pi2.c: *Not modularized* (well, NON-STANDARD modularization!)
- Only one card supported at this time.
- (Probes ports: 0x380, 0x300, 0x320, 0x340, 0x360, 0x3A0)
-
-plip.c:
- io = 0
- irq = 0 (by default, uses IRQ 5 for port at 0x3bc, IRQ 7
- for port at 0x378, and IRQ 2 for port at 0x278)
- (Probes ports: 0x278, 0x378, 0x3bc)
-
-ppp.c:
- No options (ppp-2.2+ has some, this is based on non-dynamic
- version from ppp-2.1.2d)
-
-seeq8005.c: *Not modularized*
- (Probes ports: 0x300, 0x320, 0x340, 0x360)
-
-skeleton.c: *Skeleton*
-
-slhc.c:
- No configuration parameters
-
-slip.c:
- slip_maxdev = 256 (default value from SL_NRUNIT on slip.h)
-
-
-smc-ultra.c:
- io = 0 (It will complain if you don't supply an "io=0xNNN")
- irq = 0 (IRQ val. read from EEPROM)
- (Probes ports: 0x200, 0x220, 0x240, 0x280, 0x300, 0x340, 0x380)
-
-tulip.c: *Partial modularization*
- (init-time memory allocation makes problems..)
-
-tunnel.c:
- No insmod parameters
-
-wavelan.c:
- io = 0x390 (Settable, but change not recommended)
- irq = 0 (Not honoured, if changed..)
-
-wd.c:
- io = 0 (It will complain if you don't supply an "io=0xNNN")
- irq = 0 (IRQ val. read from EEPROM, ancient cards use autoIRQ)
- mem = 0 (Force shared-memory on address 0xC8000, or whatever..)
- mem_end = 0 (Force non-std. mem. size via supplying mem_end val.)
- (eg. for 32k WD8003EBT, use mem=0xd0000 mem_end=0xd8000)
- (Probes ports: 0x300, 0x280, 0x380, 0x240)
-
-znet.c: *Not modularized*
- (Only one device on Zenith Z-Note (notebook?) systems,
- configuration information from (EE)PROM)
^ permalink raw reply
* [PATCH] TIPC: fix tipc_link_create error handling
From: Florian Westphal @ 2007-07-23 18:34 UTC (permalink / raw)
To: netdev; +Cc: per.liden, jon.maloy, tipc-discussion, allan.stephens
if printbuf allocation or tipc_node_attach_link() fails, invalid
references to the link are left in the associated node and bearer
structures.
Fix by doing printbuf allocation early and adding the new link
to b_ptr->links after tipc_node_attach_link() succeeded.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/tipc/link.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
Allan/Jon/Per: I'd appreciate if you could check wether I missed something.
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 5adfdfd..9917c64 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -423,6 +423,17 @@ struct link *tipc_link_create(struct bearer *b_ptr, const u32 peer,
return NULL;
}
+ if (LINK_LOG_BUF_SIZE) {
+ char *pb = kmalloc(LINK_LOG_BUF_SIZE, GFP_ATOMIC);
+
+ if (!pb) {
+ kfree(l_ptr);
+ warn("Link creation failed, no memory for print buffer\n");
+ return NULL;
+ }
+ tipc_printbuf_init(&l_ptr->print_buf, pb, LINK_LOG_BUF_SIZE);
+ }
+
l_ptr->addr = peer;
if_name = strchr(b_ptr->publ.name, ':') + 1;
sprintf(l_ptr->name, "%u.%u.%u:%s-%u.%u.%u:",
@@ -433,7 +444,6 @@ struct link *tipc_link_create(struct bearer *b_ptr, const u32 peer,
/* note: peer i/f is appended to link name by reset/activate */
memcpy(&l_ptr->media_addr, media_addr, sizeof(*media_addr));
k_init_timer(&l_ptr->timer, (Handler)link_timeout, (unsigned long)l_ptr);
- list_add_tail(&l_ptr->link_list, &b_ptr->links);
l_ptr->checkpoint = 1;
l_ptr->b_ptr = b_ptr;
link_set_supervision_props(l_ptr, b_ptr->media->tolerance);
@@ -459,21 +469,13 @@ struct link *tipc_link_create(struct bearer *b_ptr, const u32 peer,
l_ptr->owner = tipc_node_attach_link(l_ptr);
if (!l_ptr->owner) {
+ if (LINK_LOG_BUF_SIZE)
+ kfree(l_ptr->print_buf.buf);
kfree(l_ptr);
return NULL;
}
- if (LINK_LOG_BUF_SIZE) {
- char *pb = kmalloc(LINK_LOG_BUF_SIZE, GFP_ATOMIC);
-
- if (!pb) {
- kfree(l_ptr);
- warn("Link creation failed, no memory for print buffer\n");
- return NULL;
- }
- tipc_printbuf_init(&l_ptr->print_buf, pb, LINK_LOG_BUF_SIZE);
- }
-
+ list_add_tail(&l_ptr->link_list, &b_ptr->links);
tipc_k_signal((Handler)tipc_link_start, (unsigned long)l_ptr);
dbg("tipc_link_create(): tolerance = %u,cont intv = %u, abort_limit = %u\n",
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply related
* Re: [PATCH 0/1] ixgbe: Support for Intel(R) 10GbE PCI Express adapters - Take #2
From: Rick Jones @ 2007-07-23 18:52 UTC (permalink / raw)
To: Veeraiyan, Ayyappan
Cc: Jeff Garzik, netdev, arjan, akpm, Kok, Auke-jan H, hch,
shemminger, nhorman, inaky, mb
In-Reply-To: <E35F4F4D7F6C9E4E826FEC1F86CEF58304330045@orsmsx412.amr.corp.intel.com>
>
>
> Bidirectional test.
> 87380 65536 65536 60.01 7809.57 28.66 30.02 2.405 2.519
> TX
> 87380 65536 65536 60.01 7592.90 28.66 30.02 2.474 2.591
> RX
> ------------------------------
> 87380 65536 65536 60.01 7629.73 28.32 29.64 2.433 2.546
> RX
> 87380 65536 65536 60.01 7926.99 28.32 29.64 2.342 2.450
> TX
>
> Signle netperf stream between 2 quad-core Xeon based boxes. Tested on
> 2.6.20 and 2.6.22 kernels. Driver uses NAPI and LRO.
The bidirectional looks like a two concurrent stream (TCP_STREAM + TCP_MAERTS)
test right?
If you want a single-stream bidirectional test, then with the top of trunk
netperf you can use:
./configure --enable-burst
make install # yadda yadda
netperf -t TCP_RR -H <remote> -f m -v 2 -l 60 -c -C -- -r 64K -b 12
which will cause netperf to have 13, 64K transactions in flight at one time on
the connection, which for a 64K request size has been sufficient, thusfar
anyway, to saturate things. As there is no select/poll/whatever call in netperf
TCP_RR it might be necessary to include test-specific -s and -S options to make
sure the socket buffer (SO_SNDBUF) is large enough that none of those send()
calls ever block, lest both ends end-up blocked in a send() call.
The -f m will switch the output from transactions/s to megabits per second and
is the part requiring the top of trunk netperf. The -v 2 stuff causes extra
stuff to give bitrates in each direction and transaction/s rate as well as
computed average latency. That is also in top of trunk, otherwise, for 2.4.3
you can skip that and do the math to conver to megabits/s yourself and not get
all the other derived values.
rick jones
^ permalink raw reply
* specifying scopid's for link-local IPv6 addrs
From: Rick Jones @ 2007-07-23 19:01 UTC (permalink / raw)
To: Linux Network Development list
Folks -
People running netperf have reported that they have trouble with IPv6 under
Linux. Specifically, wereas the use of link-local IPv6 addresses "just works"
in netperf under a number of "other OSes" they do not under Linux. I'm
ass-u-me-ing 2.6 here, but not sure exactly which ones - I've seen it on a
2.6.18-based RHEL5.
Some poking about and conversation has suggested that one has to set a
sin6_scope_id in the sockaddr_in6. This needs to be an index of one of the
interfaces in the system, which I presume means walking some additional structures.
Is this a requirement which might be expected to remain in the future, or is it
something which might just go away? That will have an effect on netperf future
development.
thanks,
rick jones
^ permalink raw reply
* Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
From: Rick Jones @ 2007-07-23 18:40 UTC (permalink / raw)
To: David Miller; +Cc: ilpo.jarvinen, shemminger, noboru.obata.ar, yoshfuji, netdev
In-Reply-To: <20070713.231926.74749058.davem@davemloft.net>
David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Fri, 13 Jul 2007 09:55:10 -0700
>
>
>>Fine, but so? I suspect the point of the patch is to provide a
>>lower cap on the accumulated backoff so data starts flowing over the
>>connection within that lower cap once the link is
>>restored/failed-over.
>
>
> The backoff is there for a reason.
I'm not disputing the general value of the backoff, nor about the value of an
initial value of 60 seconds. In terms of avoiding congestive collapse one does
indeed want the exponential backoff. I'm just in agreement with the person from
Hitachi that allowing someone to tweak the backoff has a certain value.
60 seconds is already a trade-off between a pure (non capped) exponential
backoff and capping the value.
rick
^ permalink raw reply
* [PATCH [Bug 8756]] IPv6: Don't update ADVMSS on routes where the MTU is not also updated
From: Simon Arlott @ 2007-07-23 19:25 UTC (permalink / raw)
To: netdev; +Cc: bugme-daemon, David Miller
In-Reply-To: <4699D5C7.2090906@simon.arlott.org.uk>
The ADVMSS value was incorrectly updated for ALL routes when the MTU
is updated because it's outside the effect of the if statement's
condition.
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
---
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8756
net/ipv6/route.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 919de68..55ea80f 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1983,9 +1983,10 @@ static int rt6_mtu_change_route(struct rt6_info *rt, void *p_arg)
!dst_metric_locked(&rt->u.dst, RTAX_MTU) &&
(dst_mtu(&rt->u.dst) > arg->mtu ||
(dst_mtu(&rt->u.dst) < arg->mtu &&
- dst_mtu(&rt->u.dst) == idev->cnf.mtu6)))
+ dst_mtu(&rt->u.dst) == idev->cnf.mtu6))) {
rt->u.dst.metrics[RTAX_MTU-1] = arg->mtu;
- rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(arg->mtu);
+ rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(arg->mtu);
+ }
return 0;
}
--
1.5.0.1
--
Simon Arlott
^ permalink raw reply related
* Re: [PATCH 5/5] dma: use dev_to_node to get node for device in dma_alloc_pages
From: Christoph Lameter @ 2007-07-23 19:30 UTC (permalink / raw)
To: Yinghai Lu
Cc: Andrew Morton, Andi Kleen, Greg KH, rientjes, Christoph Hellwig,
David Miller, Stefan Richter, Linux Kernel Mailing List, netdev
In-Reply-To: <200707101653.09797.yinghai.lu@sun.com>
On Tue, 10 Jul 2007 16:53:09 -0700
Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
> [PATCH 5/5] dma: use dev_to_node to get node for device in
> dma_alloc_pages
Acked-by: Christoph Lameter <clameter@sgi.com>
^ permalink raw reply
* Re: [BUG] Lockup on boot when trying to bring up r8169 NIC
From: Andy Gospodarek @ 2007-07-23 19:37 UTC (permalink / raw)
To: Thomas Müller; +Cc: linux-kernel, netdev
In-Reply-To: <469F7117.2020404@mathtm.de>
On Thu, Jul 19, 2007 at 04:11:35PM +0200, Thomas Müller wrote:
> Hi,
>
> I already sent this two days ago, but I have the feeling it was
> overlooked or filtered because of a large attachment.
>
>
> If I try to boot 2.6.21.6, 2.6.22.1 or 2.6.22-git8 the system completely
> hangs when init tries to bring up my r8169-based NIC. Not even the
> keyboard lights are working anymore.
>
> If I unplug the network cable, boot continues just fine and everything
> works as it should.
> If I boot with the cable unplugged, the system also hangs and continues
> after I plug in the cable.
>
>
> Everything works fine with 2.6.20.15.
>
>
> Configuration:
> http://www.mathtm.de/config_2.6.20.15_fc6based
> http://www.mathtm.de/config_2.6.21.6_f7based
>
>
> Using a Fedora kernel (based on 2.6.21.5) I get the following kernel
> message:
> r8169: eth0: link down
> BUG: soft lockup detected on CPU#0!
> [<c0451ea2>] softlockup_tick+0xa5/0xb4
> [<c042e930>] update_process_times+0x3b/0x5e
> [<c043d298>] tick_sched_timer+0x57/0x9a
> [<c0439df5>] hrtimer_interrupt+0x12b/0x1b6
> [<c043d241>] tick_sched_timer+0x0/0x9a
> [<c0408534>] timer_interrupt+0x2c/0x32
> [<c045210e>] handle_IRQ_event+0x1a/0x3f
> [<c045354e>] handle_level_irq+0x81/0xc7
> [<c04072c7>] do_IRQ+0xb8/0xd1
> [<c04058ff>] common_interrupt+0x23/0x28
> [<c0452105>] handle_IRQ_event+0x11/0x3f
> [<c045354e>] handle_level_irq+0x81/0xc7
> [<c04534cd>] handle_level_irq+0x0/0xc7
> [<c04072bb>] do_IRQ+0xac/0xd1
> [<c04058ff>] common_interrupt+0x23/0x28
> [<c042b2dc>] __do_softirq+0x54/0xba
> [<c04071b7>] do_softirq+0x59/0xb1
> [<c04534cd>] handle_level_irq+0x0/0xc7
> [<c042b194>] irq_exit+0x38/0x6b
> [<c04072cc>] do_IRQ+0xbd/0xd1
> [<c04058ff>] common_interrupt+0x23/0x28
> [<c04200d8>] find_busiest_group+0x264/0x4c5
> [<c0601895>] _spin_unlock_irqrestore+0x8/0x9
> [<c042e863>] __mod_timer+0xa1/0xab
> [<f8a4e1ec>] rtl8169_open+0x12e/0x194 [r8169]
> [<c05a3054>] dev_open+0x2b/0x62
> [<c05a1aa1>] dev_change_flags+0x47/0xe4
> [<c05de45c>] devinet_ioctl+0x250/0x56a
> [<c04e72c0>] copy_to_user+0x3c/0x50
> [<c0598b47>] sock_ioctl+0x19f/0x1be
> [<c05989a8>] sock_ioctl+0x0/0x1be
> [<c047f713>] do_ioctl+0x1f/0x62
> [<c047f99a>] vfs_ioctl+0x244/0x256
> [<c047f9f8>] sys_ioctl+0x4c/0x64
> [<c0404f70>] syscall_call+0x7/0xb
> =======================
> r8169: eth0: link up
>
>
>
> There already is a bugzilla entry at
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242572
> I know, not everyone is a fan of bugzilla, but maybe someone wants to
> take a look at what was discussed there.
>
>
> Please CC me as I'm not subscribed to the list and don't hesitate to
> tell me that I forgot to include some crucial information ;)
>
>
> Regards,
> Thomas
>
As you know already this seems to be caused by an undesireable
interaction between the r8169 driver and a kernel with
CONFIG_DEBUG_SHIRQ=y.
It seems rtl8169_interrupt will spin (or hang) while booting until there
is an interrupt to service (like a link-change event).
-andy
^ permalink raw reply
* Re: [PATCH] TIPC: fix tipc_link_create error handling
From: Stephens, Allan @ 2007-07-23 19:49 UTC (permalink / raw)
To: Florian Westphal, netdev; +Cc: per.liden, jon.maloy, tipc-discussion
In-Reply-To: <20070723183423.GA9380@Chamillionaire.breakpoint.cc>
Hi Florian:
Changes look pretty good to me.
I'd also recommend deferring the call to k_init_timer() to the same
point as your list_add_tail() call. (If you don't, then there should
really be a k_term_timer() call in the clean up code that handles a
failure of tipc_node_attach_link().)
Regards,
Al
-----Original Message-----
From: Florian Westphal [mailto:fw@strlen.de]
Sent: Monday, July 23, 2007 2:34 PM
To: netdev@vger.kernel.org
Cc: per.liden@ericsson.com; jon.maloy@ericsson.com; Stephens, Allan;
tipc-discussion@lists.sourceforge.net
Subject: [PATCH] TIPC: fix tipc_link_create error handling
if printbuf allocation or tipc_node_attach_link() fails, invalid
references to the link are left in the associated node and bearer
structures.
Fix by doing printbuf allocation early and adding the new link to
b_ptr->links after tipc_node_attach_link() succeeded.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/tipc/link.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
Allan/Jon/Per: I'd appreciate if you could check wether I missed
something.
diff --git a/net/tipc/link.c b/net/tipc/link.c index 5adfdfd..9917c64
100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -423,6 +423,17 @@ struct link *tipc_link_create(struct bearer *b_ptr,
const u32 peer,
return NULL;
}
+ if (LINK_LOG_BUF_SIZE) {
+ char *pb = kmalloc(LINK_LOG_BUF_SIZE, GFP_ATOMIC);
+
+ if (!pb) {
+ kfree(l_ptr);
+ warn("Link creation failed, no memory for print
buffer\n");
+ return NULL;
+ }
+ tipc_printbuf_init(&l_ptr->print_buf, pb,
LINK_LOG_BUF_SIZE);
+ }
+
l_ptr->addr = peer;
if_name = strchr(b_ptr->publ.name, ':') + 1;
sprintf(l_ptr->name, "%u.%u.%u:%s-%u.%u.%u:", @@ -433,7 +444,6
@@ struct link *tipc_link_create(struct bearer *b_ptr, const u32 peer,
/* note: peer i/f is appended to link name by
reset/activate */
memcpy(&l_ptr->media_addr, media_addr, sizeof(*media_addr));
k_init_timer(&l_ptr->timer, (Handler)link_timeout, (unsigned
long)l_ptr);
- list_add_tail(&l_ptr->link_list, &b_ptr->links);
l_ptr->checkpoint = 1;
l_ptr->b_ptr = b_ptr;
link_set_supervision_props(l_ptr, b_ptr->media->tolerance); @@
-459,21 +469,13 @@ struct link *tipc_link_create(struct bearer *b_ptr,
const u32 peer,
l_ptr->owner = tipc_node_attach_link(l_ptr);
if (!l_ptr->owner) {
+ if (LINK_LOG_BUF_SIZE)
+ kfree(l_ptr->print_buf.buf);
kfree(l_ptr);
return NULL;
}
- if (LINK_LOG_BUF_SIZE) {
- char *pb = kmalloc(LINK_LOG_BUF_SIZE, GFP_ATOMIC);
-
- if (!pb) {
- kfree(l_ptr);
- warn("Link creation failed, no memory for print
buffer\n");
- return NULL;
- }
- tipc_printbuf_init(&l_ptr->print_buf, pb,
LINK_LOG_BUF_SIZE);
- }
-
+ list_add_tail(&l_ptr->link_list, &b_ptr->links);
tipc_k_signal((Handler)tipc_link_start, (unsigned long)l_ptr);
dbg("tipc_link_create(): tolerance = %u,cont intv = %u,
abort_limit = %u\n",
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply
* Re: [Bugme-new] [Bug 8797] New: WARNING from skb_gso_segment
From: Andrew Morton @ 2007-07-23 19:49 UTC (permalink / raw)
To: netdev, wensong, horms, ja; +Cc: bugme-daemon, hmkash
In-Reply-To: <bug-8797-10286@http.bugzilla.kernel.org/>
On Mon, 23 Jul 2007 09:36:08 -0700 (PDT)
bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8797
>
> Summary: WARNING from skb_gso_segment
> Product: Networking
> Version: 2.5
> KernelVersion: 2.6.22.1
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@osdl.org
> ReportedBy: hmkash@arl.army.mil
> CC: herbert@gondor.apana.org.au
>
>
> Most recent kernel where this bug did not occur: 2.6.20.4
>
> Distribution: kernel.org
>
> Hardware Environment: x86, dual-core Xeon, tg3, e1000
>
> Software Environment: ip_vs, bonding
>
> Problem Description: After upgrading kernels from 2.6.20.4 to 2.6.22.1, I
> started getting tons (27,000+ a day) of the warning messages below resulting
> from this change:
>
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commitdiff;h=f9d106a6d53b57b78eae5544f9582c643343a764
>
> This is on a system that uses ip_vs to load balance DNS traffic. Other than
> these warnings, everything appears to be normal with the load balanced DNS
> traffic.
>
> Jul 17 09:29:40 hlb1 kernel: WARNING: at net/core/dev.c:1286 skb_gso_segment()
> Jul 17 09:29:40 hlb1 kernel: [<c024d0c8>] skb_gso_segment+0x92/0x184
> Jul 17 09:29:40 hlb1 kernel: [<c024d224>] dev_gso_segment+0x10/0x34
> Jul 17 09:29:40 hlb1 kernel: [<c024d293>] dev_hard_start_xmit+0x4b/0xb1
> Jul 17 09:29:40 hlb1 kernel: [<c024d46b>] dev_queue_xmit+0x172/0x1fd
> Jul 17 09:29:40 hlb1 kernel: [<c0267828>] ip_output+0x274/0x2ad
> Jul 17 09:29:40 hlb1 kernel: [<c02673a7>] ip_finish_output+0x0/0x20d
> Jul 17 09:29:40 hlb1 kernel: [<c0267bbf>] ip_queue_xmit+0x35e/0x3a6
> Jul 17 09:29:40 hlb1 kernel: [<e0a2550c>] do_ip_vs_get_ctl+0x6f5/0x704 [ip_vs]
> Jul 17 09:29:40 hlb1 kernel: [<c0267828>] ip_output+0x274/0x2ad
> Jul 17 09:29:40 hlb1 kernel: [<e0a2687f>] ip_vs_dr_xmit+0x345/0x37b [ip_vs]
> Jul 17 09:29:40 hlb1 kernel: [<c02a336a>] _spin_lock_bh+0x8/0x10
> Jul 17 09:29:40 hlb1 kernel: [<c0276547>] tcp_cwnd_restart+0x17/0xad
> Jul 17 09:29:40 hlb1 kernel: [<c0276cbe>] tcp_transmit_skb+0x3e0/0x402
> Jul 17 09:29:40 hlb1 kernel: [<c0277846>] tso_fragment+0x15a/0x194
> Jul 17 09:29:40 hlb1 kernel: [<c0277f91>] tcp_write_xmit+0x1cc/0x22e
> Jul 17 09:29:40 hlb1 kernel: [<c0278004>] __tcp_push_pending_frames+0x11/0x60
> Jul 17 09:29:40 hlb1 kernel: [<c026e430>] tcp_sendmsg+0x9df/0xa95
> Jul 17 09:29:40 hlb1 kernel: [<c0287133>] inet_sendmsg+0x39/0x43
> Jul 17 09:29:40 hlb1 kernel: [<c0243be2>] do_sock_write+0xab/0xb2
> Jul 17 09:29:40 hlb1 kernel: [<c0243c39>] sock_aio_write+0x50/0x5c
> Jul 17 09:29:40 hlb1 kernel: [<c015c008>] do_sync_write+0xbf/0xfc
> Jul 17 09:29:40 hlb1 kernel: [<c02a2b70>] mutex_lock+0x13/0x22
> Jul 17 09:29:40 hlb1 kernel: [<c0129232>] autoremove_wake_function+0x0/0x33
> Jul 17 09:29:40 hlb1 kernel: [<c02472ad>] sock_common_getsockopt+0x1c/0x21
> Jul 17 09:29:40 hlb1 kernel: [<c0244c49>] sys_getsockopt+0x7d/0x9c
> Jul 17 09:29:40 hlb1 kernel: [<c015c10e>] vfs_write+0xc9/0x133
> Jul 17 09:29:40 hlb1 kernel: [<c015c220>] sys_write+0x41/0x67
> Jul 17 09:29:40 hlb1 kernel: [<c0103002>] sysenter_past_esp+0x5f/0x85
> Jul 17 09:29:40 hlb1 kernel: =======================
>
>
> Steps to reproduce: Unsure
>
>
> --
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- 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: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Andrew Morton @ 2007-07-23 20:24 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: Linus Torvalds, linux-kernel, netdev
In-Reply-To: <20070723190152.GA5755@martell.zuzino.mipt.ru>
On Mon, 23 Jul 2007 23:01:52 +0400
Alexey Dobriyan <adobriyan@gmail.com> wrote:
> On Mon, Jul 23, 2007 at 10:38:39PM +0400, Alexey Dobriyan wrote:
> > Managed to hit BUG_ON() in kmap_atomic_prot() three times while doing
> > nothing unusual for this box (two times it was under X, so I can't
> > guarantee, one time while trying to reproduce via ./configure in gdb
> > tarball)
Yeah, I hit this several times a few days ago. Same story: it just
randomly went splat in response to no obvious stimulus. Reported it to
netdev, was greeted with stunned silence.
> > Box has 2.5G of RAM. 2.6.22 was OK.
> >
> > [dives into framebuffer console setup for complete oops]
>
> kernel BUG at arch/i386/mm/highmem.c:38
> PREEMPT DEBUG_PAGEALLOC SLAB
> EIP at kmap_atomic_prot+0x32/0x93
> get_page_from_freelist
> __alloc_pages
> cache_alloc_refill
> cache_alloc_refill
> kmem_cache_alloc
> dst_alloc
> dst_alloc
> __ip_route_output_key
> [some junk I don't trust]
>
> eax: 0000000c
> ebx: 00000003
> ecx: c065efe0
> edx: 00000003
> edi: 00000163
>
>
> c010cc9b <kmap_atomic_prot>:
> c010cc9b: 57 push %edi
> c010cc9c: 56 push %esi
> c010cc9d: 53 push %ebx
> c010cc9e: 89 c6 mov %eax,%esi
> c010cca0: 89 d3 mov %edx,%ebx
> c010cca2: 89 cf mov %ecx,%edi
> c010cca4: b8 01 00 00 00 mov $0x1,%eax
> c010cca9: e8 dd 1b 00 00 call c010e88b <add_preempt_count>
> c010ccae: e8 b1 ac 0e 00 call c01f7964 <debug_smp_processor_id>
> c010ccb3: 6b c0 0d imul $0xd,%eax,%eax
> c010ccb6: 8d 14 03 lea (%ebx,%eax,1),%edx
> c010ccb9: 8d 04 95 00 00 00 00 lea 0x0(,%edx,4),%eax
> c010ccc0: 8b 0d 30 a1 3e c0 mov 0xc03ea130,%ecx
> c010ccc6: 29 c1 sub %eax,%ecx
> c010ccc8: 83 39 00 cmpl $0x0,(%ecx)
> c010cccb: 74 04 je c010ccd1 <kmap_atomic_prot+0x36>
> c010cccd: 0f 0b ud2a
I had more complete info: http://article.gmane.org/gmane.linux.network/66966
You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
I haven't worked out where that kmap_atomic() call is coming from yet.
Both traces point up into the page allocator, but I _think_ that's stack
gunk.
^ permalink raw reply
* Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
From: Christoph Lameter @ 2007-07-23 20:34 UTC (permalink / raw)
To: Andrew Morton
Cc: Eugene Surovegin, linux-mm, Josh Boyer, bart.vanassche, netdev,
bugme-daemon@kernel-bugs.osdl.org, linuxppc-embedded
In-Reply-To: <20070718095537.d344dc0a.akpm@linux-foundation.org>
On Wed, 18 Jul 2007 09:55:37 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> hm. It should be the case that providing SLAB_HWCACHE_ALIGN at
> kmem_cache_create() time will override slab-debugging's offsetting
> of the returned addresses.
That is true for SLUB but not in SLAB. SLAB has always ignored
SLAB_HWCACHE_ALIGN when debugging is on because of the issues involved
in placing the redzone values etc. Could be fun to fix.
^ permalink raw reply
* Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Alexey Dobriyan @ 2007-07-23 20:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, linux-kernel, netdev
In-Reply-To: <20070723132431.42afbae8.akpm@linux-foundation.org>
On Mon, Jul 23, 2007 at 01:24:31PM -0700, Andrew Morton wrote:
> On Mon, 23 Jul 2007 23:01:52 +0400
> Alexey Dobriyan <adobriyan@gmail.com> wrote:
>
> > On Mon, Jul 23, 2007 at 10:38:39PM +0400, Alexey Dobriyan wrote:
> > > Managed to hit BUG_ON() in kmap_atomic_prot() three times while doing
> > > nothing unusual for this box (two times it was under X, so I can't
> > > guarantee, one time while trying to reproduce via ./configure in gdb
> > > tarball)
>
> Yeah, I hit this several times a few days ago. Same story: it just
> randomly went splat in response to no obvious stimulus. Reported it to
> netdev, was greeted with stunned silence.
>
>
> > > Box has 2.5G of RAM. 2.6.22 was OK.
> > >
> > > [dives into framebuffer console setup for complete oops]
> >
> > kernel BUG at arch/i386/mm/highmem.c:38
> > PREEMPT DEBUG_PAGEALLOC SLAB
> > EIP at kmap_atomic_prot+0x32/0x93
> > get_page_from_freelist
> > __alloc_pages
> > cache_alloc_refill
> > cache_alloc_refill
> > kmem_cache_alloc
> > dst_alloc
> > dst_alloc
> > __ip_route_output_key
> > [some junk I don't trust]
> >
> > eax: 0000000c
> > ebx: 00000003
> > ecx: c065efe0
> > edx: 00000003
> > edi: 00000163
> >
> >
> > c010cc9b <kmap_atomic_prot>:
> > c010cc9b: 57 push %edi
> > c010cc9c: 56 push %esi
> > c010cc9d: 53 push %ebx
> > c010cc9e: 89 c6 mov %eax,%esi
> > c010cca0: 89 d3 mov %edx,%ebx
> > c010cca2: 89 cf mov %ecx,%edi
> > c010cca4: b8 01 00 00 00 mov $0x1,%eax
> > c010cca9: e8 dd 1b 00 00 call c010e88b <add_preempt_count>
> > c010ccae: e8 b1 ac 0e 00 call c01f7964 <debug_smp_processor_id>
> > c010ccb3: 6b c0 0d imul $0xd,%eax,%eax
> > c010ccb6: 8d 14 03 lea (%ebx,%eax,1),%edx
> > c010ccb9: 8d 04 95 00 00 00 00 lea 0x0(,%edx,4),%eax
> > c010ccc0: 8b 0d 30 a1 3e c0 mov 0xc03ea130,%ecx
> > c010ccc6: 29 c1 sub %eax,%ecx
> > c010ccc8: 83 39 00 cmpl $0x0,(%ecx)
> > c010cccb: 74 04 je c010ccd1 <kmap_atomic_prot+0x36>
> > c010cccd: 0f 0b ud2a
>
> I had more complete info: http://article.gmane.org/gmane.linux.network/66966
>
> You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
>
> I haven't worked out where that kmap_atomic() call is coming from yet.
> Both traces point up into the page allocator, but I _think_ that's stack
> gunk.
Ahh, you suspect networking.
Here, setup is 2 cheap-ass 100Mb realtek 8139 NICs, one to campus network
receiving ~20 junk packets per second, one gathering netconsole output
and ssh to it, no conntracks and fancy stuff.
[reboots with cables physically unplugged]
^ permalink raw reply
* Re: tg3 issues
From: Michael Chan @ 2007-07-23 21:34 UTC (permalink / raw)
To: patric; +Cc: netdev, mcarlson
In-Reply-To: <46A342DC.1030305@imperialnet.org>
On Sun, 2007-07-22 at 13:43 +0200, patric wrote:
> patric wrote:
>
> > Hi,
> >
> > Think i got something working for me at least, and the fix is quite
> > minimal and only downside that i could see from it was that you might
> > get a small delay when bringing up the interface, but that's probably
> > better than getting a non-functional interface that reports that it's up.
> >
> > The fix seems to be quite simple with just a random sleep at the end
> > of "tg3_setup_fiber_by_hand():"
> >
> > tw32_f(MAC_MODE, tp->mac_mode);
> > udelay(40);
> > }
> >
> > out:
> > udelay( net_random() % 400 );
> > return current_link_up;
> > }
> >
> > Not sure that this is a good fix or if it might break on other
> > systems, but maybe you could have a quick look at that?
> >
> > Regards,
> > Patric
> >
> > -
> > 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
> >
> Last update on this.
>
> "udelay( 100 + net_random % 300 )" seems to work much better and i have
> not had a single problem getting the link up within 10 seconds of a cold
> or warm-boot, and most often the link comes up directly without any sort
> of delay instead like before when it could hang for 30 seconds before
> getting a link, if you even got a link.
>
We'll have to do some testing to see if we can find a better solution.
Adding up to 400 usec of busy wait is not ideal. Are you connecting two
5701 fiber cards directly to each other in your setup?
^ permalink raw reply
* [PATCH 1/2] forcedeth: new device ids in pci_ids.h
From: Ayaz Abdulla @ 2007-07-23 0:43 UTC (permalink / raw)
To: Jeff Garzik, Manfred Spraul, Andrew Morton, nedev
Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 106 bytes --]
This patch contains new device ids for MCP73 chipset.
Signed-Off-By: Ayaz Abdulla <aabdulla@nvidia.com>
[-- Attachment #2: patch-device-ids-mcp73 --]
[-- Type: text/plain, Size: 759 bytes --]
--- old/include/linux/pci_ids.h 2007-07-22 18:57:26.000000000 -0400
+++ new/include/linux/pci_ids.h 2007-07-22 18:57:11.000000000 -0400
@@ -1223,6 +1223,10 @@
#define PCI_DEVICE_ID_NVIDIA_NVENET_25 0x054D
#define PCI_DEVICE_ID_NVIDIA_NVENET_26 0x054E
#define PCI_DEVICE_ID_NVIDIA_NVENET_27 0x054F
+#define PCI_DEVICE_ID_NVIDIA_NVENET_28 0x07DC
+#define PCI_DEVICE_ID_NVIDIA_NVENET_29 0x07DD
+#define PCI_DEVICE_ID_NVIDIA_NVENET_30 0x07DE
+#define PCI_DEVICE_ID_NVIDIA_NVENET_31 0x07DF
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP67_IDE 0x0560
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP73_IDE 0x056C
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP77_IDE 0x0759
^ permalink raw reply
* [PATCH 2/2] forcedeth: mcp73 device addition
From: Ayaz Abdulla @ 2007-07-23 0:43 UTC (permalink / raw)
To: Jeff Garzik, Manfred Spraul, Andrew Morton, nedev
Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 111 bytes --]
This patch contains new device settings for MCP73 chipset.
Signed-Off-By: Ayaz Abdulla <aabdulla@nvidia.com>
[-- Attachment #2: patch-forcedeth-mcp73 --]
[-- Type: text/plain, Size: 1632 bytes --]
--- old/drivers/net/forcedeth.c 2007-07-22 19:02:41.000000000 -0400
+++ new/drivers/net/forcedeth.c 2007-07-22 19:31:56.000000000 -0400
@@ -5550,6 +5550,22 @@
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_27),
.driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
},
+ { /* MCP73 Ethernet Controller */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_28),
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ },
+ { /* MCP73 Ethernet Controller */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_29),
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ },
+ { /* MCP73 Ethernet Controller */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_30),
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ },
+ { /* MCP73 Ethernet Controller */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_31),
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ },
{0,},
};
^ permalink raw reply
* Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Alexey Dobriyan @ 2007-07-23 21:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, linux-kernel, netdev
In-Reply-To: <20070723204045.GD5755@martell.zuzino.mipt.ru>
On Tue, Jul 24, 2007 at 12:40:45AM +0400, Alexey Dobriyan wrote:
> > I had more complete info: http://article.gmane.org/gmane.linux.network/66966
> >
> > You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
> >
> > I haven't worked out where that kmap_atomic() call is coming from yet.
> > Both traces point up into the page allocator, but I _think_ that's stack
> > gunk.
>
> Ahh, you suspect networking.
>
> Here, setup is 2 cheap-ass 100Mb realtek 8139 NICs, one to campus network
> receiving ~20 junk packets per second, one gathering netconsole output
> and ssh to it, no conntracks and fancy stuff.
>
> [reboots with cables physically unplugged]
OK, I run gdb recompile, cat(1) every file in /usr/portage (shitload of
small files) with both cables unplugged. It all went fine for ~5 minutes
after that it crashed exactly same way after 10 secs after plugging one
of them.
^ permalink raw reply
* Odd behaviour of proxy_arp
From: Lennart Sorensen @ 2007-07-23 20:36 UTC (permalink / raw)
To: netdev
I have been seeing some occasional strange behavior when using
proxy_arp. I have a router running with an ADSL PPPoE link to the
Internet, and an Ethernet link to a local network. It has proxy_arp
enabled on the internal Ethernet port since I sometimes have ipsec
tunnels running where I use proxy_arp to proxy for the IP assigned to
the other end of the tunnel so that local machines can find and reach
it. I run two independent subnets on the local network (one with fixed
IPs for my machines here, and another with DHCP addresses for guest
machines that visit occasionally just to give them Internet access).
I run 10.0.0.0/8 and 192.168.254.0/24 on the local network with the
router having an IP in each subnet.
The strangeness that occurs is that once in a while there is a 10
second period where the system will answer all arp requests for all IPs
on the local network, with it's own MAC address, which is clearly wrong
since it doesn't have any of those IP addresses. It seems to happen
every couple of days or so on average, although not at any specific
time. One day it happened at 11:32:30 to 11:32:39, and a few days later
it happened at 12:08:38 to 12:08:48. If I disable proxy_arp, it never
happens at all, but then I loose the ability to do what I have proxy_arp
enabled for in the first place.
Related to that problem, there is also the annoyance that any IP that
isn't part of either of the two subnets the router belongs to, have arp
requests answered by the router all the time, which it also should not
be answering, since it doesn't actually have a clue what those IP
addresses belong to and certainly has no idea where it should forward to
to reach them. I occasionally have other random subnets in use on the
network for running local test networks separate from everything else.
It would be great if the kernel would keep its nose out of those subnets
too.
So far I have seen this behavior with 2.6.8, 2.6.16, and 2.6.18 (being
the kernels I have run on this router).
So have I misunderstood something about what proxy_arp is supposed to
do, or is proxy_arp in the kernel simply broken, or is it perhaps
mis-designed? Are there some tuning parameters that could perhaps make
it actually do what one would expect it to be doing?
--
Len Sorensen
^ permalink raw reply
* Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()
From: Andrew Morton @ 2007-07-23 21:11 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: Linus Torvalds, linux-kernel, netdev
In-Reply-To: <20070723210153.GA5753@martell.zuzino.mipt.ru>
On Tue, 24 Jul 2007 01:01:53 +0400
Alexey Dobriyan <adobriyan@gmail.com> wrote:
> On Tue, Jul 24, 2007 at 12:40:45AM +0400, Alexey Dobriyan wrote:
> > > I had more complete info: http://article.gmane.org/gmane.linux.network/66966
> > >
> > > You're using DEBUG_PAGEALLOC, but I was not, so I think we can rule that out.
> > >
> > > I haven't worked out where that kmap_atomic() call is coming from yet.
> > > Both traces point up into the page allocator, but I _think_ that's stack
> > > gunk.
> >
> > Ahh, you suspect networking.
> >
> > Here, setup is 2 cheap-ass 100Mb realtek 8139 NICs, one to campus network
> > receiving ~20 junk packets per second, one gathering netconsole output
> > and ssh to it, no conntracks and fancy stuff.
> >
> > [reboots with cables physically unplugged]
>
> OK, I run gdb recompile, cat(1) every file in /usr/portage (shitload of
> small files) with both cables unplugged. It all went fine for ~5 minutes
> after that it crashed exactly same way after 10 secs after plugging one
> of them.
It'd be nice to get a clean trace. Are you able to obtain the full
trace with CONFIG_FRAME_POINTER=y?
^ permalink raw reply
* Re: [PATCH]: Resurrect napi_poll patch.
From: Stephen Hemminger @ 2007-07-23 21:14 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andi Kleen, David Miller, netdev, rusty, jgarzik
In-Reply-To: <20070723170642.GA13771@one.firstfloor.org>
On Mon, 23 Jul 2007 19:06:42 +0200
Andi Kleen <andi@firstfloor.org> wrote:
> On Mon, Jul 23, 2007 at 10:58:22AM +0100, Stephen Hemminger wrote:
> > On 21 Jul 2007 15:26:00 +0200
> > Andi Kleen <andi@firstfloor.org> wrote:
> >
> > > David Miller <davem@davemloft.net> writes:
> > > >
> > > > Good candidates for taking advantage of multi-napi are:
> > > >
> > > > 1) e1000
> > > > 2) ucc_geth
> > > > 3) ehea
> > > > 4) sunvnet
> > >
> > > s2io.c
> >
> > sky2.c could use it because of issues with dual-port that share
> > one napi for status.
>
> Sorry, I didn't parse the sentence. Did you mean "couldn't use it" ...?
> Also can you elaborate why it shouldn't work?
Sky2 would make a good case for decoupling because it can have:
device0 device1
\ /
napi poll
Right now both device's share the NAPI instance on device 0,
but it take some work to make sure that the core code doesn't
upset device1 when device0 is down.
Actually, dual port boards are rare, I have one but it is a PCI-E x4
board so a pain to find a system with a slot.
^ 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