Re: [BUG] bad address in twothirdsMD4Transform
On Mon, 2008-02-11 at 20:29 +0100, Jiri Slaby wrote: > Hi, > > I get this with 32 bit Firefox 3b2 and java 1.6.0_03 on 64 bit: > > BUG: unable to handle kernel paging request at 8102366213f8 > IP: [] twothirdsMD4Transform+0xc4/0x3b0 You should mention what kernel you're using. This bug is only in -mm (you didn't cc: Andrew), and it's fixed here: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24/2.6.24-mm1/hot-fixes/random-clean-up-checkpatch-complaints-fix.patch -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RESENDING] netconsole: register cmdline netconsole configs to configfs
On Mon, 2008-02-11 at 18:08 +0900, Joonwoo Park wrote: > This patch intorduces cmdline netconsole configs to register to > configfs > with dynamic netconsole. Satyam Sharma who designed shiny dynamic > reconfiguration for netconsole, mentioned about this issue already. > (http://lkml.org/lkml/2007/7/29/360) > But I think, without separately managing of two kind of netconsole > target > objects, it's possible by using config_group instead of > config_item in the netconsole_target and default_groups feature of > configfs. > > Patch was tested with configuration creation/destruction by kernel and > module. > And it makes possible to enable/disable, modify and review netconsole > target configs from cmdline. I'm afraid I'm going to have to leave review of this to someone who is clueful about configfs. But it seems reasonable. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.24-mm1] TCP/IPv6 connect() oopses at twothirdsMD4Transform()
On Mon, 2008-02-04 at 17:36 -0800, Andrew Morton wrote: > On Tue, 05 Feb 2008 10:28:43 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote: > > > Hello. > > > > Kernel config is at http://I-love.SAKURA.ne.jp/tmp/config-2.6.24-mm1 > > > > 2.6.24 works fine. > err, Matt? random: revert braindamage that snuck into checkpatch cleanup Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> diff -r 50a6e531a9f2 drivers/char/random.c --- a/drivers/char/random.c Mon Feb 04 20:23:02 2008 -0600 +++ b/drivers/char/random.c Mon Feb 04 20:28:08 2008 -0600 @@ -1306,7 +1306,7 @@ * Rotation is separate from addition to prevent recomputation */ #define ROUND(f, a, b, c, d, x, s) \ - (a += f(b, c, d) + in[x], a = (a << s) | (a >> (32 - s))) + (a += f(b, c, d) + x, a = (a << s) | (a >> (32 - s))) #define K1 0 #define K2 013240474631UL #define K3 015666365641UL -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/4] dst: Distributed storage documentation.
On Thu, Nov 29, 2007 at 03:53:23PM +0300, Evgeniy Polyakov wrote: > > Distributed storage documentation. > > Algorithms used in the system, userspace interfaces > (sysfs dirs and files), design and implementation details > are described here. Can you give us a summary of how this differs from using device mapper with NBD? -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
Simon, can you test this patch? I think it's the most straightforward
2.6.24 fix.
diff -r c60016ba6237 net/core/netpoll.c
--- a/net/core/netpoll.cTue Nov 13 09:09:36 2007 -0800
+++ b/net/core/netpoll.cFri Nov 23 13:10:28 2007 -0600
@@ -203,6 +203,12 @@ static void refill_skbs(void)
spin_unlock_irqrestore(&skb_pool.lock, flags);
}
+/* used to mark an skb as owned by netpoll */
+static void netpoll_skb_destroy(struct sk_buff *skb)
+{
+ return;
+}
+
static void zap_completion_queue(void)
{
unsigned long flags;
@@ -219,10 +225,12 @@ static void zap_completion_queue(void)
while (clist != NULL) {
struct sk_buff *skb = clist;
clist = clist->next;
- if (skb->destructor)
+ if (skb->destructor == netpoll_skb_destroy) {
+ skb->destructor = NULL;
+ __kfree_skb(skb);
+ }
+ else
dev_kfree_skb_any(skb); /* put this one back */
- else
- __kfree_skb(skb);
}
}
@@ -252,6 +260,7 @@ repeat:
atomic_set(&skb->users, 1);
skb_reserve(skb, reserve);
+ skb->destructor = netpoll_skb_destroy;
return skb;
}
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 10:54:11PM +0300, Evgeniy Polyakov wrote: > On Fri, Nov 23, 2007 at 01:41:39PM -0600, Matt Mackall ([EMAIL PROTECTED]) > wrote: > > Here's another thought: move all this logic into the networking core, > > unify it with current softirq zapper, then allow it to be called from > > various other places (like atomic allocators). Then it'll all be in > > central maintained place with more users. > > This can be done quite easily - put a check into __kfree_skb() if > netpoll is compiled-in and we are in hardirq context, then put skb > into softirq freeing queue. Then zap_completion_queue() can free > anything without ever knowing about nature of the packet, since this > will be checked in __kfree_skb() anyway. What I had in mind was moving the whole zap_completion_queue concept into net/core/skbuff. So that netpoll (and, say, atomic kmalloc) can simply call something like "clean_completion_queue". -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 10:32:22PM +0300, Evgeniy Polyakov wrote: > On Fri, Nov 23, 2007 at 01:11:20PM -0600, Matt Mackall ([EMAIL PROTECTED]) > wrote: > > On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote: > > > On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL > > > PROTECTED]) wrote: > > > > On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL > > > > PROTECTED]) wrote: > > > > > Stop, we are trying to free skb without destructor and catch > > > > > connection > > > > > tracking, so it is not a solution. To fix the problem we need to check > > > > > if it is not netfilter related, kind of this (not tested), Simon > > > > > please > > > > > give it a try: > > > > > > > > And to be really cool we need to bypass skbs with xfrm attached, since > > > > its freeing also assumes BH context. > > > > > > What about compile options? > > > > What about my original suggestion that we mark skbs owned by netpoll > > and free only those. Much safer, no? Untested: > > This should work if there are netpoll's skbs, but if we are under memory > pressure we want to free not only netpoll skbs, but at least one, and > what if there are no netpoll skbs in the queue? Yeah, that's a concern (but note that we do have a private reserve and we only really need the zap when our reserve is depleted). But I worry that it's too fragile and if we add a new unsafe case, it won't be noticed for a long time. This is the first report I've seen of this particular problem, so this has been a latent bug for three or four years now. Here's another thought: move all this logic into the networking core, unify it with current softirq zapper, then allow it to be called from various other places (like atomic allocators). Then it'll all be in central maintained place with more users. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 10:15:24PM +0300, Evgeniy Polyakov wrote: > On Fri, Nov 23, 2007 at 12:59:43PM -0600, Matt Mackall ([EMAIL PROTECTED]) > wrote: > > So I'd be surprised if that was a problem. But I can imagine having > > problems for skbs without destructors which run into one of these in > > __kfree_skb: > > > > dst_release > > secpath_put > > nf_conntrack_put > > nf_conntrack_put_reasm > > nf_bridge_put > > > > ..some or all of which assume a softirq context. > > bridging is ok, others require softirq context. > I've sent a patch (the last one should be ok) to guard against xfrm and > connection tracking. > > > > No matter if we are under memory pressure or whatever - it is not > > > allowed - a lot of skbs are supposed to be freed in softirq context, > > > that is why dev_kfree_skb_any() exists. > > > > Some skbs we definitely -can- free in irq context. The only ones we > > care about are the ones generated by netpoll. If there's a reason you > > think netpoll's own skbs can't be freed, please describe it. > > Only some and to distinguish them we can not use destructor - if it is > set (even empty function) it will fire an alarm. Yep, please look at the patch I just posted. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
> > On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL
> > PROTECTED]) wrote:
> > > Stop, we are trying to free skb without destructor and catch connection
> > > tracking, so it is not a solution. To fix the problem we need to check
> > > if it is not netfilter related, kind of this (not tested), Simon please
> > > give it a try:
> >
> > And to be really cool we need to bypass skbs with xfrm attached, since
> > its freeing also assumes BH context.
>
> What about compile options?
What about my original suggestion that we mark skbs owned by netpoll
and free only those. Much safer, no? Untested:
diff -r c60016ba6237 net/core/netpoll.c
--- a/net/core/netpoll.cTue Nov 13 09:09:36 2007 -0800
+++ b/net/core/netpoll.cFri Nov 23 13:10:28 2007 -0600
@@ -203,6 +203,12 @@ static void refill_skbs(void)
spin_unlock_irqrestore(&skb_pool.lock, flags);
}
+/* used to mark an skb as owned by netpoll */
+static void netpoll_skb_destroy(struct sk_buff *skb)
+{
+ return;
+}
+
static void zap_completion_queue(void)
{
unsigned long flags;
@@ -219,10 +225,12 @@ static void zap_completion_queue(void)
while (clist != NULL) {
struct sk_buff *skb = clist;
clist = clist->next;
- if (skb->destructor)
+ if (skb->destructor == netpoll_skb_destroy) {
+ skb->destructor = NULL;
+ __kfree_skb(skb);
+ }
+ else
dev_kfree_skb_any(skb); /* put this one back */
- else
- __kfree_skb(skb);
}
}
@@ -252,6 +260,7 @@ repeat:
atomic_set(&skb->users, 1);
skb_reserve(skb, reserve);
+ skb->destructor = netpoll_skb_destroy;
return skb;
}
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 08:57:57PM +0300, Evgeniy Polyakov wrote: > On Fri, Nov 23, 2007 at 11:07:56AM -0600, Matt Mackall ([EMAIL PROTECTED]) > wrote: > > On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote: > > > On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL > > > PROTECTED]) wrote: > > > > > [2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at > > > > > kernel/softirq.c:139 local_bh_enable() > > > > > [2059664.620535] [<80120364>] local_bh_enable+0x3c/0x97 > > > > > > > > [2059664.620657] [<8011c205>] __call_console_drivers+0x61/0x6d > > > > > [2059664.620669] [<8011c3fc>] release_console_sem+0x164/0x1bf > > > > > [2059664.620679] [<8011c81f>] vprintk+0x27a/0x2ff > > > > > > > If that trace is to be beieved we're doing nefilter stuff on packets > > > > which > > > > were sent across netconsole. > > > > > > > > This probably isn't anything the netfilter guys have thought about. And > > > > probably we don't want them to. Is there some simple way in which we > > > > can > > > > exempt netconsole from netfilter processing? > > > > > > This is not about netfilter, but about freeing skb in interrupt context, > > > which is not allowed, and in interrupt skbs are queued to be freed in > > > softirq, > > > but netcnsole wants to flush softirq freeing queue. That is a question: > > > why? > > > > My memory here is hazy, but I think this exists to rescue netconsole > > in low-memory situations. This bit originated with Ingo, so maybe he > > can recall. > > > > Netpoll can process an arbitrary number of skbs inside a single > > interrupt. Think sysrq-t at one packet per line or kgdboe where the > > entire trace session can happen inside one very long interrupt. > > > > Perhaps we can refine this to mark netpoll's skbs (perhaps with > > ->destructor?) and delete only skbs we own. As these are never passed > > through any of the other route/xfrm/filter code, they should be safe > > to delete even in irq context, yes? > > > > > Removing zap_completion_queue() from find_skb() will fix the warning, > > > but I'm not sure this is a correct fix. I've added Matt to the Cc list. > > > > Care to try the sysrq-t or OOM message tests? > > We basically can not free skbs there - if it is interrupt context and > we are freeing some skb with destructor we will catch the warning anyway. Perhaps I'm missing some context here. We don't free skbs with destructors in irq context in zap_completion_queue. We reinsert them on the completion list. We do this by calling dev_kfree_skb_any. So I'd be surprised if that was a problem. But I can imagine having problems for skbs without destructors which run into one of these in __kfree_skb: dst_release secpath_put nf_conntrack_put nf_conntrack_put_reasm nf_bridge_put ..some or all of which assume a softirq context. > No matter if we are under memory pressure or whatever - it is not > allowed - a lot of skbs are supposed to be freed in softirq context, > that is why dev_kfree_skb_any() exists. Some skbs we definitely -can- free in irq context. The only ones we care about are the ones generated by netpoll. If there's a reason you think netpoll's own skbs can't be freed, please describe it. > I think we can drop skbs _without_ destructor from the queue though in > that conditions given that we actually need only one. Huh? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23 WARNING: at kernel/softirq.c:139 local_bh_enable()
On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote: > On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL PROTECTED]) > wrote: > > > [2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at > > > kernel/softirq.c:139 local_bh_enable() > > > [2059664.620535] [<80120364>] local_bh_enable+0x3c/0x97 > > > > [2059664.620657] [<8011c205>] __call_console_drivers+0x61/0x6d > > > [2059664.620669] [<8011c3fc>] release_console_sem+0x164/0x1bf > > > [2059664.620679] [<8011c81f>] vprintk+0x27a/0x2ff > > > If that trace is to be beieved we're doing nefilter stuff on packets which > > were sent across netconsole. > > > > This probably isn't anything the netfilter guys have thought about. And > > probably we don't want them to. Is there some simple way in which we can > > exempt netconsole from netfilter processing? > > This is not about netfilter, but about freeing skb in interrupt context, > which is not allowed, and in interrupt skbs are queued to be freed in softirq, > but netcnsole wants to flush softirq freeing queue. That is a question: why? My memory here is hazy, but I think this exists to rescue netconsole in low-memory situations. This bit originated with Ingo, so maybe he can recall. Netpoll can process an arbitrary number of skbs inside a single interrupt. Think sysrq-t at one packet per line or kgdboe where the entire trace session can happen inside one very long interrupt. Perhaps we can refine this to mark netpoll's skbs (perhaps with ->destructor?) and delete only skbs we own. As these are never passed through any of the other route/xfrm/filter code, they should be safe to delete even in irq context, yes? > Removing zap_completion_queue() from find_skb() will fix the warning, > but I'm not sure this is a correct fix. I've added Matt to the Cc list. Care to try the sysrq-t or OOM message tests? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole and logging everything from /dev/console
On Fri, Nov 16, 2007 at 06:43:15PM +0100, Martin Michlmayr wrote: > I'm supporting a number of consumer devices (e.g. small NAS devices) > in Debian. They typically don't export the serial console and don't > have any other output devices. We perform the installation via SSH > on such devices and start SSH automatically when the system boots so > people can login. This works pretty well but sometimes a device stops > to boot for no good reason. This is usually really hard to debug > since we don't have any logs at all. > > I could activate netconsole in order to see kernel messages but then I > still wouldn't see anything that's printed by the ramdisk and later > when services are started. Ideally, I'd like to have an option for > netconsole to show every message that is also shown on the console. > > Do you think that would be possible? It is, definitely, you just need to wire up a tty struct's write method to netconsole's and add it to the console registration. But I haven't had any time to work on this in a while. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] net: avoid race between netpoll and network fast path
On Mon, Oct 29, 2007 at 09:26:11PM -0700, David Miller wrote: > From: Tina Yang <[EMAIL PROTECTED]> > Date: Tue, 16 Oct 2007 22:46:30 -0700 > > > The precise race is > > 1) net_rx_action get the dev from poll_list > > 2) at the same time, netpoll poll_napi() get a hold of the poll lock > >and calls ->poll(), remove dev from the poll list > > 3) after it finishes, net_rx_action get the poll lock, and calls > >->poll() the second time, and panic when trying to remove (again) > >the dev from the poll list. > > This is trivial to fix. > > I'll check the following into 2.6.14 and backport it to > the -stable trees. > > [NET]: Fix race between poll_napi() and net_rx_action() > > netpoll_poll_lock() synchronizes the ->poll() invocation > code paths, but once we have the lock we have to make > sure that NAPI_STATE_SCHED is still set. Otherwise we > get: > > cpu 0 cpu 1 > > net_rx_action() poll_napi() > netpoll_poll_lock() ... spin on ->poll_lock > ->poll() > netif_rx_complete > netpoll_poll_unlock() acquire ->poll_lock() > ->poll() >netif_rx_complete() >CRASH > > Based upon a bug report from Tina Yang. > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> Thanks, Dave. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] remove netpoll receive code
[annoyed as ever about never being cc:ed on this stuff] On Wed, Oct 17, 2007 at 01:21:31PM -0700, Stephen Hemminger wrote: > The netpoll receive code is: > 1. Not used by any in-tree features, it is used by kgdb-over-ether. And various crashdump over network tools. > 2. A nice hook for people doing nasty things like private binary network > stacks or rootkits. It's a completely useless hook for a binary network stack. It only supports UDP and only point to point. And it will have crap performance. It's much less useful here than, say, TUN/TAP. It doesn't buy anything for a rootkit either, which will continue to trivially hide servers in userspace as they already do. This point is completely FUD. > 3. Unsecured by any of the normal firewalling code. This is correct. It also applies to the TX side of things. The point, of course, is to bypass as much of the stack as possible so that when the kernel crashes, we're more likely to actually get our netpoll data. > I propose that we take out all the whole netpoll rx path. If/when > kgdb gets submitted a better and alternative receive path can be > added. Let's hear about this better alternative first, shall we? I for one am a little skeptical of its existence. Going through a larger fraction of the network stack, running softirqs, etc., are all big (potentially fatal) steps backward from the point of view of a debugger. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netconsole problems
On Thu, Oct 04, 2007 at 10:59:38AM -0700, Tina Yang wrote: > We recently run into a few problems with netconsole > in at least 2.6.9, 2.6.18 and 2.6.23. It either panicked > at netdevice.h:890 or hung the system, and sometimes depending > on which NIC we are using, the following console message, > e1000: > "e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang" > tg3: > "NETDEV WATCHDOG: eth4: transmit timed out" > "tg3: eth4: transmit timed out, resetting" > > The postmortem vmcore analysis indicated race between normal > network stack (net_rx_action) and netpoll, and disabling the > following code segment cures all the problems. That doesn't tell us much. Can you provide any more details? Like the call chains on both sides? > netpoll.c >178 /* Process pending work on NIC */ >179 np->dev->poll_controller(np->dev); >180 if (np->dev->poll) >181 poll_napi(np); There are a couple different places this gets called, and for different reasons. If we have a -large- netconsole dump (like sysrq-t), we'll swallow up all of our SKB pool and may get stuck waiting for the NIC to send them (because it's waiting to hand packets back to the kernel and has no free buffers for outgoing packets). > Big or small, there seems to be several race windows in the code, > and fixing them probably has consequence on overall system performance. Yes, the networking layer goes to great lengths to avoid having any locking in its fast paths and we don't want to undo any of that effort. > Maybe this code should only run when the machine is single-threaded ? In the not-very-distant future, such machines will be extremely rare. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc8: cannot make netconsole work
On Fri, Sep 28, 2007 at 01:27:55PM +0400, Andrey Borzenkov wrote:
> I finally decided to try netconsole in attempt to get some more information
> why my system does not resume (but that is different story). But I cannot
> make it work - it does load but I see no traffic flowing ever. This is
> notebook with e100 driver and it works just fine for normal traffic.
> netconsole is currently compiled as module, loading it I get:
>
> sudo modprobe netconsole netconsole=@/eth0,@/
>
> [ 2395.838094] netconsole: local port 6665
> [ 2395.838126] netconsole: interface eth0
> [ 2395.838132] netconsole: remote port
> [ 2395.838140] netconsole: remote IP 0.0.0.0
> [ 2395.838150] netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
> [ 2395.838175] netconsole: local IP 192.168.1.8
> [ 2395.843798] console [netcon0] enabled
> [ 2395.844722] netconsole: network logging started
>
> but I cannot see any packet flowing via eth0 not can I catch anything on
> remote side using netcat. This does not work when I add explicitly source and
> target addresses either:
>
> pts/0}% sudo modprobe netconsole [EMAIL PROTECTED]/eth0,@192.168.1.5/
> {pts/0}% dmesg | tail
> [ 2427.128947] device eth0 left promiscuous mode
> [ 2427.129005] audit(1190970818.972:5): dev=eth0 prom=0 old_prom=256
> auid=4294967295
> [ 2541.831721] netconsole: local port 6665
> [ 2541.831756] netconsole: local IP 192.168.1.8
> [ 2541.831763] netconsole: interface eth0
> [ 2541.831769] netconsole: remote port
> [ 2541.831776] netconsole: remote IP 192.168.1.5
> [ 2541.831787] netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
> [ 2541.838832] console [netcon0] enabled
> [ 2541.839964] netconsole: network logging started
What is your console log level set to? If the messages don't come out
on the local console, they won't get sent out the network either.
Fedora at least defaults to hiding most messages. Adding 'debug' to
your kernel command line will change that.
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
On Thu, Aug 02, 2007 at 11:00:08AM +0200, Jarek Poplawski wrote: > On Wed, Aug 01, 2007 at 09:02:19PM -0500, Matt Mackall wrote: > > On Wed, Aug 01, 2007 at 11:59:21AM +0200, Jarek Poplawski wrote: > > > On Tue, Jul 31, 2007 at 05:05:00PM +0200, Gabriel C wrote: > > > > Jarek Poplawski wrote: > > > > > On Tue, Jul 31, 2007 at 12:14:36PM +0200, Gabriel C wrote: > > > > >> Jarek Poplawski wrote: > > > > >>> On 28-07-2007 20:42, Gabriel C wrote: > > > > >>>> Andrew Morton wrote: > > > > >>>>> On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <[EMAIL PROTECTED]> > > > > >>>>> wrote: > ... > > > > >>>>>> net/core/netpoll.c:155: error: 'struct net_device' has no member > > > > >>>>>> named 'poll_controller' > ... > > > > >>>>>> I think is because KGDBOE selects just NETPOLL. > > > > >>>>>> > > > > >>>>> Looks like it. > > > > >>>>> > > > > >>>>> Select went and selected NETPOLL and NETPOLL_TRAP but things like > > > > >>>>> CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. > > > > >>>>> `select' > > > > >>>>> remains evil. > ... > > > seems to select NET_POLL_CONTROLLER after selecting NETPOLL, but > > > still doesn't check for NETDEVICES dependency. > > > > That's odd. Adding Sam to the cc:. > > Looks right, but after reading Andrew's opinion about select I'd be > astonished if he doesn't know this problem already. > > > > > > > >> Now KGDBOE just selects NETPOLL and NETPOLL_TRAP. > > > > >> Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but > > > > >> the question is does it work without any ethernet card ? > > > > > > > > > > Why kgdboe should care what netpoll needs? So, I hope, you are adding > > > > > this select under config NETPOLL. On the other hand, if NETPOLL should > > > > > depend on NET_POLL_CONTROLLER there is probably no reason to have them > > > > > both. > > > > > > > > NET_POLL_CONTROLLER has def_bool NETPOLL if NETDEVICES . > > > > > > > > Net peoples ping ?:) > > > > How about cc:ing the netpoll maintainer? > > Is there a new one or do you suggest possibility of abusing the > authority of the netpoll's author with such trifles...?! I'm just subtly suggesting that if you're going to have a discussion about netpoll, you ought to cc: me. > There are some notions about "other diagnostic tools" in some > net drivers, eg. 3c509.c, so there would be a little bit of > work if, after changing this, they really exist (and even if > not - maybe it's reasonable to save such possibility for the > future?). I created it for netpoll, only netpoll clients have ever cared. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
On Wed, Aug 01, 2007 at 11:59:21AM +0200, Jarek Poplawski wrote: > On Tue, Jul 31, 2007 at 05:05:00PM +0200, Gabriel C wrote: > > Jarek Poplawski wrote: > > > On Tue, Jul 31, 2007 at 12:14:36PM +0200, Gabriel C wrote: > > >> Jarek Poplawski wrote: > > >>> On 28-07-2007 20:42, Gabriel C wrote: > > Andrew Morton wrote: > > > On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <[EMAIL PROTECTED]> > > > wrote: > > > > > >> Hi, > > >> > > >> I got this compile error with a randconfig ( > > >> http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ). > > >> > > >> ... > > >> > > >> net/core/netpoll.c: In function 'netpoll_poll': > > >> net/core/netpoll.c:155: error: 'struct net_device' has no member > > >> named 'poll_controller' > > >> net/core/netpoll.c:159: error: 'struct net_device' has no member > > >> named 'poll_controller' > > >> net/core/netpoll.c: In function 'netpoll_setup': > > >> net/core/netpoll.c:670: error: 'struct net_device' has no member > > >> named 'poll_controller' > > >> make[2]: *** [net/core/netpoll.o] Error 1 > > >> make[1]: *** [net/core] Error 2 > > >> make: *** [net] Error 2 > > >> make: *** Waiting for unfinished jobs > > >> > > >> ... > > >> > > >> > > >> I think is because KGDBOE selects just NETPOLL. > > >> > > > Looks like it. > > > > > > Select went and selected NETPOLL and NETPOLL_TRAP but things like > > > CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. > > > `select' > > > remains evil. > > >>> ... > > I think there may be a logical issue ( again if I got it right ). > > We need some ethernet card to work with kgdboe right ? but we don't > > have any if !NETDEVICES && !NET_ETHERNET. > > > > So maybe some ' depends on ... && NETDEVICES!=n && NET_ETHERNET!=n ' > > is needed too ? > > >>> IMHO, the only logical issue here is netpoll.c mustn't use > > >>> CONFIG_NET_POLL_CONTROLLER code without #ifdef if it doesn't > > >>> add this dependency itself. > > >>> > > >> Well it does if NETDEVICES && if NET_ETHERNET which booth are N when > > >> !NETDEVICES is why KGDBOE uses select and not depends on. > > > > > > "does if XXX" means may "use if XXX". > > > > From what I know means only use "if xxx" on !xxx everything inside the "if > > xxx" is n and "depends on > > does not work. > > > > ... > > > > menuconfig FOO > > bool "FOO" > > depends on BAR > > default y > > -- help -- > > something > > if FOO > > > > config BAZ > > depends on WHATEVR && !NOT_THIS > > > > menuconfig SOMETHING_ELSE > > > > if SOMETHING_ELSE > > > > config BLUBB > > depends on PCI && WHATNOT > > > > endif # SOMETHING_ELSE > > > > config NETPOLL > > def_bool NETCONSOLE > > > > config NETPOLL_TRAP > > bool "Netpoll traffic trapping" > > default n > > depends on NETPOLL > > > > config NET_POLL_CONTROLLER > > def_bool NETPOLL > > > > endif # FOO > > > > Now if you set FOO=n all is gone and your driver have to select whatever it > > needs from there. > > Probably not exactly so... > > >From drivers/net/Kconfig: > > > # All the following symbols are dependent on NETDEVICES - do not repeat > > # that for each of the symbols. > > if NETDEVICES > > So, according to this netpoll could presume NETDEVICES and > NET_POLL_CONTROLLER are always on. > > But, as you've found, it's possible to select NETPOLL and !NETDEVICES, > so this comment is at least not precise. > > On the other side something like this: > > ... > endif # NETDEVICES > > config NETPOLL > depends on NETDEVICES > def_bool NETCONSOLE > > config NETPOLL_TRAP > bool "Netpoll traffic trapping" > default n > depends on NETPOLL > > config NET_POLL_CONTROLLER > def_bool NETPOLL > depends on NETPOLL > > > seems to select NET_POLL_CONTROLLER after selecting NETPOLL, but > still doesn't check for NETDEVICES dependency. That's odd. Adding Sam to the cc:. > > >> Now KGDBOE just selects NETPOLL and NETPOLL_TRAP. > > >> Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but the > > >> question is does it work without any ethernet card ? > > > > > > Why kgdboe should care what netpoll needs? So, I hope, you are adding > > > this select under config NETPOLL. On the other hand, if NETPOLL should > > > depend on NET_POLL_CONTROLLER there is probably no reason to have them > > > both. > > > > NET_POLL_CONTROLLER has def_bool NETPOLL if NETDEVICES . > > > > Net peoples ping ?:) How about cc:ing the netpoll maintainer? > OK, I wasn't right here: there is no visible reason for both in the > kernel code, but I can imagine there could be some external users of > NET_POLL_CONTROLLER without NETPOLL. I don't know of any. As far as I can tell at this point, NET_POLL_CONTROLLER == NETPOLL.
Re: [PATCH v2 (updated) -mm 4/9] netconsole: Add some useful tips to documentation
On Wed, Jul 11, 2007 at 03:49:29AM +0530, Satyam Sharma wrote: > [4/9 (updated)] netconsole: Add some useful tips to documentation > > Add some useful general-purpose tips. Also suggest solution for the frequent > problem of console_loglevel set too low numerically (i.e. for high priority > messages only) on the sender. > > Cc: Matt Mackall <[EMAIL PROTECTED]> > Cc: Jesper Juhl <[EMAIL PROTECTED]> > Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> Thanks. Acked-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.23 PATCH 13/18] dm: netlink
On Wed, Jul 11, 2007 at 02:27:12PM -0700, Andrew Morton wrote: > On Wed, 11 Jul 2007 22:01:37 +0100 > Alasdair G Kergon <[EMAIL PROTECTED]> wrote: > > > From: Mike Anderson <[EMAIL PROTECTED]> > > > > This patch adds a dm-netlink skeleton support to the Makefile, and the dm > > directory. > > > > ... > > > > +config DM_NETLINK > > + bool "DM netlink events (EXPERIMENTAL)" > > + depends on BLK_DEV_DM && EXPERIMENTAL > > + ---help--- > > + Generate netlink events for DM events. > > Need a dependency on NET there? It's really sad to make DM dependent on the network layer. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 -mm 4/9] netconsole: Add some useful tips to documentation
On Tue, Jul 10, 2007 at 02:49:41PM +0530, Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [4/9] netconsole: Add some useful tips to documentation > > Add some useful general-purpose tips. > > Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> > Cc: Keiichi Kii <[EMAIL PROTECTED]> Acked-by: Matt Mackall <[EMAIL PROTECTED]> As long as we're on the subject, I've been meaning to add a note telling people to set their console log level to something useful, as having that set too low is the most common problem people encounter. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 -mm 3/9] netconsole: Simplify boot/module option setup logic
On Tue, Jul 10, 2007 at 02:49:36PM +0530, Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [3/9] netconsole: Simplify boot/module option setup logic Acked-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 -mm 2/9] netconsole: Remove bogus check
On Tue, Jul 10, 2007 at 02:49:30PM +0530, Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [2/9] netconsole: Remove bogus check > > The (!np.dev) check in write_msg() is bogus (always false), because: > np.dev is set by netpoll_setup(), which is called by the target init > code in init_netconsole() _before_ register_console() => write_msg() cannot > be triggered unless netpoll_setup() returns with success. And that will not > happen if netpoll_setup() failed to set np.dev. Also np.dev cannot go from > under us while netconsole is loaded. This is because netpoll_setup() grabs > a reference for us on that dev. So let's remove the pointless check. > > Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> > Cc: Keiichi Kii <[EMAIL PROTECTED]> Acked-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 -mm 1/9] netconsole: Cleanups, codingstyle, prettyfication
On Tue, Jul 10, 2007 at 02:49:25PM +0530, Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [1/9] netconsole: Cleanups, codingstyle, prettyfication > > (1) Remove unwanted headers. > (2) Mark __init and __exit as appropriate. > (3) Various trivial codingstyle and prettification stuff. I don't much like what you've done in (3) because I personally think tabs should never appear anywhere but at the beginning of a line. Which is why we consistently ask for people not to mix codingstyle bits with substantive changes. But what the hell.. Acked-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -mm 6/9] netconsole: Update documentation for multiple target support
On Wed, Jul 04, 2007 at 04:38:09PM +0530, Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [6/9] netconsole: Update documentation for multiple target support > > ... and add a few useful general purpose tips as well while we're at it. The tips are fine and should go in their own patch at the beginning of the series. The docs for multiple interfaces should go either in the patch that adds that (ideally) or after. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -mm 4/9] netconsole: Introduce netconsole_netdev_notifier
On Wed, Jul 04, 2007 at 04:37:59PM +0530, Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [4/9] netconsole: Introduce netconsole_netdev_notifier > > To update fields of underlying netpoll structure at runtime on > corresponding NETDEV_CHANGEADDR or NETDEV_CHANGENAME notifications. It's not obvious that we want to do that. I can have a host with DHCP that uses netconsole to log to a private network address. This breaks that. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -mm 5/9] netconsole: Introduce dev_status member
On Wed, Jul 04, 2007 at 04:38:04PM +0530, Satyam Sharma wrote:
> From: Satyam Sharma <[EMAIL PROTECTED]>
>
> [5/9] netconsole: Introduce dev_status member
>
> Introduce a new member in netconsole_target that tracks the status (up or
> down) of the underlying interface network device that the specific logging
> target netpoll is attached to.
>
> We then join this up with the just-introduced net_device notifier, and
> introduce NETDEV_UP and NETDEV_DOWN notifications. By disabling the target
> when the corresponding local interface is down, we save the overhead of
> unnecessarily disabling interrupts and calling into the netpoll stack in
> console->write().
Yuck.
> +/*
> + * Why no net_dev_is_up() in netdevice.h? The kernel could lose a lot of
> + * weight if only netdevice.h had the good sense to export such a function.
> + * Oh well ...
> + */
> +static inline int net_dev_is_up(struct net_device *net_dev)
> +{
> + return ((net_dev->flags & IFF_UP) == IFF_UP);
> +}
Why editorialize? Why not just add this to netdevice.h?
> + if (nt->dev_status) {
Why not simply call net_dev_is_up?
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -mm 2/9] netconsole: Code simplification
On Wed, Jul 04, 2007 at 04:37:49PM +0530, Satyam Sharma wrote: > From: Satyam Sharma <[EMAIL PROTECTED]> > > [2/9] netconsole: Code simplification > > (1) Extract netpoll_parse_options() out of option_setup(), and into > init_netconsole() itself. So "configured" variable is redundant and > can be removed. > > (2) With this change, option_setup() is not required for modular netconsole. How is this a simplification? You've taken code with no #ifdefs and added one! Please have both modular and nonmodular continue to use the same paths. > > (3) The (!np.dev) check in write_msg() is bogus (always false), because: > np.dev is set by netpoll_setup(), which is called by the target init > code in init_netconsole() _before_ register_console() => write_msg() cannot > be triggered unless netpoll_setup() returns with success. And that will not > happen if netpoll_setup() failed to set np.dev. Also np.dev cannot go from > under us while netconsole is loaded. This is because netpoll_setup() grabs > a reference for us on that dev. So let's remove the pointless check. This ought to be a separate patch. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] use a dynamic pool of sk_buffs to keep up with fast targets
On Mon, Jul 02, 2007 at 09:40:36PM -0700, David Miller wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Mon, 2 Jul 2007 21:36:36 -0700 > > > My initial thought is that if there is a legitimate need for this > > new capability then it should be made available to other parts of > > the kernel rather than being private to the AEO driver. > > Absolutely. > > We even used to have something like this on a per-cpu basis but using > generic SLAB is so much better for caching and NUMA that we got rid of > that. > > Every sk_buff private "quicklist" pool implementation you > see should essentially be NAK'd from the get go, it's > meaningless and if it's really needed one should investigate > why SKB allocations become such a problem instead of papering > over the issue. :-) This is in the VM write-back path. SLAB is insufficient to avoid deadlock. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH -mm take5 1/7] marking __init
On Wed, Jun 13, 2007 at 07:25:55PM +0900, Keiichi KII wrote: > From: Keiichi KII <[EMAIL PROTECTED]> > > This patch contains the following cleanups. > - add __init for initialization functions(option_setup() and >init_netconsole()). > > Acked-by: Matt Mackall <[EMAIL PROTECTED]> > Signed-off-by: Keiichi KII <[EMAIL PROTECTED]> > Signed-off-by: Takayoshi Kochi <[EMAIL PROTECTED]> Dave, please take this one. Not sure what to do about the rest, sigh. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] Make net watchdog timers 1 sec jiffy aligned
On Wed, May 30, 2007 at 03:29:39PM -0700, David Miller wrote: > From: Matt Mackall <[EMAIL PROTECTED]> > Date: Wed, 30 May 2007 17:10:39 -0500 > > > Are you agreeing that "it seems wasteful to add per-packet overhead"? > > This patch is not doing that. > > Yes, and I know that :-) Is there a real reason for watchdog_timeo to be all over the map? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] Make net watchdog timers 1 sec jiffy aligned
On Wed, May 30, 2007 at 12:55:51PM -0700, David Miller wrote:
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Wed, 30 May 2007 20:42:32 +0200
>
> > Stephen Hemminger wrote:
> > >>>Index: linux-2.6.22-rc-mm/net/sched/sch_generic.c
> > >>>===
> > >>>--- linux-2.6.22-rc-mm.orig/net/sched/sch_generic.c 2007-05-24
> > >>>11:16:03.0 -0700
> > >>>+++ linux-2.6.22-rc-mm/net/sched/sch_generic.c 2007-05-25
> > >>>15:10:02.0 -0700
> > >>>@@ -224,7 +224,8 @@
> > >>> if (dev->tx_timeout) {
> > >>> if (dev->watchdog_timeo <= 0)
> > >>> dev->watchdog_timeo = 5*HZ;
> > >>>-if (!mod_timer(&dev->watchdog_timer, jiffies +
> > >>>dev->watchdog_timeo))
> > >>>+if (!mod_timer(&dev->watchdog_timer,
> > >>>+ round_jiffies(jiffies +
> > >>>dev->watchdog_timeo)))
> > >>> dev_hold(dev);
> > >>> }
> > >>> }
> > >>
> > >>Please cc netdev on net patches.
> > >>
> > >>Again, I worry that if people set the watchdog timeout to, say, 0.1
> > >>seconds
> > >>then they will get one second, which is grossly different.
> > >>
> > >>And if they were to set it to 1.5 seconds, they'd get 2.0 which is pretty
> > >>significant, too.
> > >
> > >
> > > Alternatively, we could change to a timer that is pushed forward after
> > > each
> > > TX, maybe using hrtimer and hrtimer_forward(). That way the timer would
> > > never run in normal case.
> >
> >
> > It seems wasteful to add per-packet overhead for tx timeouts, which
> > should be an exception. Do drivers really care about the exact
> > timeout value? Compared to a packet transmission time its incredibly
> > long anyways ..
>
> I agree, this change is absolutely rediculious and is just a blind
> cookie-cutter change made without consideration of what the code is
> doing and what it's requirements are.
What are you agreeing with, Dave?
Are you agreeing that "it seems wasteful to add per-packet overhead"?
This patch is not doing that.
A quick grep shows that most things are using multi-second timeouts
here. Of the ones that aren't, a number are using .4s, and many more
aren't even in units of HZ. Makes me wonder if the various boards
using 50ms are being overzealous.
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH repost] netpoll: trapping fix/cleanup
On Sat, Apr 28, 2007 at 04:56:23PM +0400, Sergei Shtylyov wrote: > Hello. > > Matt Mackall wrote: > > >>CONFIG_NETPOLL_TRAP causes the TX queue controls to be completely > >>bypassed in > >>the netpoll's "trapped" mode which easily causes overflows in the drivers > >>with > >>short TX queues (most notably, in 8139too with its 4-deep queue). > >>Make this option more sensible by only bypassing TX softirq wakeup and > >>remove > >>CONFIG_NETPOLL_RX option completely since there is *no* code depending on > >>it. > > >You've got two unrelated patches here, so that's an automatic NAK. > > Come on, killing a long ago no-op option doesn't worth the sepearte > patch. :-) > > >I suppose we can kill the config option. > > I've even posted the refs to the commits introducing and killing the > #ifdef's. > > >What did you test the NETPOLL_TRAP test with? > > KGDBoE (and maybe also netconsole -- don't remember already). Ok, KGDBoE is a pretty good test here. Netconsole isn't. Please resend as two separate patches and add: Acked-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH repost] netpoll: trapping fix/cleanup
On Fri, Apr 27, 2007 at 11:44:00PM +0400, Sergei Shtylyov wrote: > CONFIG_NETPOLL_TRAP causes the TX queue controls to be completely bypassed in > the netpoll's "trapped" mode which easily causes overflows in the drivers with > short TX queues (most notably, in 8139too with its 4-deep queue). > Make this option more sensible by only bypassing TX softirq wakeup and remove > CONFIG_NETPOLL_RX option completely since there is *no* code depending on it. You've got two unrelated patches here, so that's an automatic NAK. I suppose we can kill the config option. What did you test the NETPOLL_TRAP test with? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH -mm take4 2/6] support multiple logging
On Fri, Apr 20, 2007 at 11:15:26AM -0700, Andrew Morton wrote: > On Fri, 20 Apr 2007 18:51:13 +0900 > Keiichi KII <[EMAIL PROTECTED]> wrote: > > > > I started to do some cleanups and fixups here, but abandoned it when it > > > was > > > all getting a bit large. > > > > > > Here are some fixes against this patch: > > > > I'm going to fix my patches by following your reviews and send new patches > > on the LKML and the netdev ML in a few days. > > > > Well.. before you can finish this work we need to decide upon what the > interface to userspace will be. > > - The miscdev isn't appropriate > > - netlink remains a possibility > > - Stephen suggests an ioctl against a socket and davem suggests socket > options, but it's unclear to me how that socket will get bound to > netconsole? Yeah, that's a bit of a head-scratcher. > either way, I agree with the overall thrust of this work: netconsole is > useful in production environments, can become more useful and will need > runtime configurability. > > > I wonder if we're approaching this in the right way, however... > > At a high level, netconsole is just a flow of UDP packets between two > machines. The kernel already has rich and well-understood ways of creating > and configuring such flows. > > So... instead of creating a brand new way of configuring such a flow via > sysfs and ioctl, could we instead create a flow using the existing > mechanisms (presumably the socket API) and then "transfer" the information > from that flow over to netconsole by some means?? We don't really have anything that corresponds to netpoll's connections at higher levels. I'm tempted to say we should make this work more like the dummy network device. ie: modprobe netconsole -o netcon1 [params] modprobe netconsole -o netcon2 [params] -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] netconsole hangs machine 2.6.20
[cc:ed to netdev] On Sun, Apr 15, 2007 at 10:45:37PM -0700, Mike Mattie wrote: > Hello, > > netconsole is hanging my box during IDE init. > > I am running 2.6.20.7, config is attached from /proc > > Without using netconsole the kernel boots fine. I am writing this message > from it. > > When I do enable net-console I get from the linux banner to a couple of lines > after > "sanitize end" on the logging client ( Mac OS X 10.4 , simple nc listener ) > > The boot continues until hde (handled by the HPT366 driver, hdg is the last > drive ) > and then the kernel just hangs. I don't really have a theory for that. What NIC are you using? Looks like VIA Rhine? Is it sharing an IRQ with your IDE interface? Please post your boot messages with "debug" on the kernel command line. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
On Tue, Mar 20, 2007 at 03:08:19PM -0800, Zachary Amsden wrote: > Matt Mackall wrote: > >I don't know that you need an xchg there. If you're still on the same > >CPU, it should all be nice and causal even across an interrupt handler. > >So it could be: > > > > pda.intr_mask = 0; /* intr_pending can't get set after this */ > > > > Why not? Oh, I see. intr_mask is inverted form of EFLAGS_IF. It's not even that. There are two things that can happen: case 1: intr_mask = 1; intr_mask = 0; /* intr_pending is already set and CLI is in effect */ if(intr_pending) case 2: intr_mask = 1; intr_mask = 0; /* intr_pending remains cleared */ if(intr_pending) As this is all about local interrupts, it's all on a single CPU and out of order issues aren't visible.. > >(This would actually need a C barrier, but I'll ignore that as this'd > >end up being asm...) ..unless the compiler is doing the reordering, of course. > >But other interesting things could happen. If we never did a real CLI > >and we get preempted and switched to another CPU between clearing > >intr_mask and checking intr_pending, we get a little confused. > > I think Jeremy's idea was to have interrupt handlers leave interrupts > disabled on exit if pda.intr_mask was set. In which case, they would > bypass all work and we could never get preempted. I was actually worrying about the case where the interrupt came in "late". But I don't think it's a problem there either. > I don't think leaving > hardware interrupts disabled for such a long time is good though. It can only be worse than the current situation by the amount of time it takes to defer an interrupt once. On average, it'll be a lot better as most critical sections are -tiny-. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
On Tue, Mar 20, 2007 at 09:31:58AM -0700, Jeremy Fitzhardinge wrote:
> Linus Torvalds wrote:
> > On Tue, 20 Mar 2007, Eric W. Biederman wrote:
> >
> >> If that is the case. In the normal kernel what would
> >> the "the oops, we got an interrupt code do?"
> >> I assume it would leave interrupts disabled when it returns?
> >> Like we currently do with the delayed disable of normal interrupts?
> >>
> >
> > Yeah, disable interrupts, and set a flag that the fake "sti" can test, and
> > just return without doing anything.
> >
> > (You may or may not also need to do extra work to Ack the hardware
> > interrupt etc, which may be irq-controller specific. Once the CPU has
> > accepted the interrupt, you may not be able to just leave it dangling)
> >
>
> So it would be something like:
>
> pda.intr_mask = 1;/* disable interrupts */
> ...
> pda.intr_mask = 0;/* enable interrupts */
> if (xchg(&pda.intr_pending, 0)) /* check pending */
> asm("sti"); /* was pending; isr left cpu interrupts masked
> */
I don't know that you need an xchg there. If you're still on the same
CPU, it should all be nice and causal even across an interrupt handler.
So it could be:
pda.intr_mask = 0; /* intr_pending can't get set after this */
if (unlikely(pda.intr_pending)) {
pda.intr_pending = 0;
asm("sti");
}
(This would actually need a C barrier, but I'll ignore that as this'd
end up being asm...)
But other interesting things could happen. If we never did a real CLI
and we get preempted and switched to another CPU between clearing
intr_mask and checking intr_pending, we get a little confused.
But perhaps that doesn't matter because we'd by definition have no
pending interrupts on either processor?
Is it expensive to do an STI if interrupts are already enabled?
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH -mm take3 1/6][resend] marking __init
On Tue, Mar 20, 2007 at 09:24:18PM +0900, Keiichi KII wrote:
> From: Keiichi KII <[EMAIL PROTECTED]>
>
> This patch contains the following cleanups.
> - add __init for initialization functions(option_setup() and
>init_netconsole()).
>
> Signed-off-by: Keiichi KII <[EMAIL PROTECTED]>
> Signed-off-by: Takayoshi Kochi <[EMAIL PROTECTED]>
> ---
> Index: linux-mm/drivers/net/netconsole.c
> ===
> --- linux-mm.orig/drivers/net/netconsole.c
> +++ linux-mm/drivers/net/netconsole.c
> @@ -91,7 +91,7 @@ static struct console netconsole = {
> .write = write_msg
> };
>
> -static int option_setup(char *opt)
> +static int __init option_setup(char *opt)
> {
> configured = !netpoll_parse_options(&np, opt);
> return 1;
> @@ -99,7 +99,7 @@ static int option_setup(char *opt)
>
> __setup("netconsole=", option_setup);
>
> -static int init_netconsole(void)
> +static int __init init_netconsole(void)
> {
> int err;
This is fine.
Acked-by: Matt Mackall <[EMAIL PROTECTED]>
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netconsole system freeze when cable unplugged
On Fri, Mar 09, 2007 at 09:42:43PM +0100, Francois Romieu wrote: > Simon Arlott <[EMAIL PROTECTED]> : > > When I unplug the cable the system just stops responding to anything, > > at all. No message is printed to the console when the cable is plugged > > back in. > > rtl8139_interrupt (spin_lock(&tp->lock)) > -> rtl8139_weird_interrupt >-> rtl_check_media > -> mii_check_media (printk(KERN_INFO "%s: link down\n", ...)) > [netpoll stuff here] > -> rtl8139_poll_controller > -> rtl8139_interrupt >*deadlock* Probably the best thing that can be done here aside from moving mii_check_media outside interrupt handling is to add netpoll_plug/unplug(dev) methods that push work off to netpoll's queue for drivers that have a netpoll recursion problem. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: net-2.6.20 patch] remove unused exports
On Wed, Mar 07, 2007 at 11:40:59PM +0100, Adrian Bunk wrote: > This patch removes the following not or no longer used exports: > - drivers/char/random.c: secure_tcp_sequence_number This part looks reasonable. Acked-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED
On Mon, Mar 05, 2007 at 08:03:50PM -0800, Greg KH wrote:
> On Mon, Mar 05, 2007 at 09:39:47PM -0600, Matt Mackall wrote:
> > On Mon, Mar 05, 2007 at 06:48:50PM -0800, Greg KH wrote:
> > > If so, can you disable the option and strace it to see what program is
> > > trying to access what? That will put the
> > > HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty
> > > quickly :)
> >
> > Ok, I've got straces of both good and bad (>5M each). Filtered out
> > random pointer values and the like, diffed, and filtered for /sys/,
> > and the result's still 1.5M. What should I be looking for?
>
> Failures when trying to read from /sys/class/net/
>
> Or opening the directory and iterating over the subdirs in there. Or
> something like that.
>
> But the /sys/class/net/ stuff should hopefully help narrow it down.
Works:
6857 open("/sys/class/net",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13
6857 fstat64(13, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
6857 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0
6857 getdents64(13, /* 5 entries */, 4096) = 120
6857 readlink("/sys/class/net/eth1", 0x80a2450, 256) = -1 EINVAL
(Invalid argument)
6857 readlink("/sys/class/net/eth1/device",
"../../../devices/pci:00/:00:1e.0/:02:02.0", 256) = 53
6857 readlink("/sys/class/net/lo", 0x80a2450, 256) = -1 EINVAL
(Invalid argument)
6857 readlink("/sys/class/net/lo/device", 0x80a2450, 256) = -1 ENOENT
(No such
file or directory)
6857 readlink("/sys/class/net/eth0", 0x80a2450, 256) = -1 EINVAL
(Invalid argument)
6857 readlink("/sys/class/net/eth0/device",
"../../../devices/pci:00/:00:1e.0/:02:01.0", 256) = 53
6857 getdents64(13, /* 0 entries */, 4096) = 0
6857 close(13) = 0
Breaks:
3620 open("/sys/class/net",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13
3620 fstat64(13, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
3620 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0
3620 getdents64(13, /* 5 entries */, 4096) = 120
3620 readlink("/sys/class/net/eth1",
"../../devices/pci:00/:00:1e.0/00\00:02:02.0/eth1", 256) = 55
3620
readlink("/sys/devices/pci:00/:00:1e.0/:02:02.0/eth1/device",
0x809e910, 256) = -1 ENOENT (No such file or directory)
3620 readlink("/sys/class/net/lo", "../../devices/virtual/net/lo",
256) = 28
3620 readlink("/sys/devices/virtual/net/lo/device", 0x809e960, 256) =
-1 ENOEN\T (No such file or directory)
3620 readlink("/sys/class/net/eth0",
"../../devices/pci:00/:00:1e.0/00\00:02:01.0/eth0", 256) = 55
3620
readlink("/sys/devices/pci:00/:00:1e.0/:02:01.0/eth0/device",
0x809e960, 256) = -1 ENOENT (No such file or directory)
3620 getdents64(13, /* 0 entries */, 4096) = 0
3620 close(13) = 0
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED
On Mon, Mar 05, 2007 at 06:48:50PM -0800, Greg KH wrote: > If so, can you disable the option and strace it to see what program is > trying to access what? That will put the > HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty > quickly :) Ok, I've got straces of both good and bad (>5M each). Filtered out random pointer values and the like, diffed, and filtered for /sys/, and the result's still 1.5M. What should I be looking for? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED
On Mon, Mar 05, 2007 at 06:48:50PM -0800, Greg KH wrote: > Wait, have confirmed that if you enable this config option, > NetworkManager starts back up again and works properly? Yep, probably should have mentioned that. > If so, can you disable the option and strace it to see what program is > trying to access what? That will put the > HAL/NetworkManager/libsysfs/distro script finger pointing to rest pretty > quickly :) Did that a few hours ago, got a very large dump from both programs. No smoking guns to my eye, but I'll send you the logs later. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.21 patch] unconditionally enable SYSFS_DEPRECATED
On Mon, Mar 05, 2007 at 04:07:22PM -0800, Greg KH wrote: > On Tue, Mar 06, 2007 at 12:40:52AM +0100, Adrian Bunk wrote: > > On Mon, Mar 05, 2007 at 10:58:13AM -0800, Greg KH wrote: > > > > > > Ok, how about the following patch. Is it acceptable to everyone? > > > > > > thanks, > > > > > > greg k-h > > > > > > --- > > > init/Kconfig | 13 +++-- > > > 1 file changed, 11 insertions(+), 2 deletions(-) > > > > > > --- gregkh-2.6.orig/init/Kconfig > > > +++ gregkh-2.6/init/Kconfig > > > @@ -290,8 +290,17 @@ config SYSFS_DEPRECATED > > > that belong to a class, back into the /sys/class heirachy, in > > > order to support older versions of udev. > > > > > > - If you are using a distro that was released in 2006 or later, > > > - it should be safe to say N here. > > > + If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora > > > + release from 2007 or later, it should be safe to say N here. > > > + > > > + If you are using Debian or other distros that are slow to > > > + update HAL, please say Y here. > > >... > > > > The sane solution seems to be to enable SYSFS_DEPRECATED unconditionally > > for all users, and schedule it's removal for mid-2008 (or later). > > > > 12 months after the first _release_ of a HAL that can live without seems > > to be the first time when we can consider getting rid of it, since all > > distributions with at least one release a year should ship it by then. > > > > Currently, SYSFS_DEPRECATED is only a trap for users. > > Huh? > > No, again, I've been using this just fine for about 6 months now. > > And what about all of the servers not using HAL/NetworkManager? > And what about all of the embedded systems not using either? > > So to not allow this to be turned off by people who might want to (we > want this for OpenSuSE 10.3, and Fedora 7 also will want this, as will > other distros released this year), is pretty heavy-handed. > > It also will work in OpenSuSE 10.2 which is already released, and I > think Fedora 6, but I've only limited experience with these. > > Oh, and Gentoo works just fine, and has been for the past 6 months. > > I would just prefer to come up with an acceptable set of wording that > will work to properly warn people. > > I proposed one such wording which some people took as a slam against > Debian, which it really was not at all. > > Does someone else want to propose some other wording instead? Back up a bit. Let's review: Problem: NetworkManager stopped working with my ipw2200 on Debian/unstable Theory A: It broke because I'm not running an as-yet-unreleased HAL. Then we should revert the patch pronto because it's an unqualified regression. Theory B: It broke because I'm not running relatively recent HAL. By all accounts I'm running the latest and greatest HAL and Network Manager, more than recent enough to work. Theory C: It broke because I've got some goofy config. My setup passes no arguments to either. The HAL config file is completely bare-bones and there's no sign of any configuration files for Network Manager. Theory D: It broke for some nebulous Debian-related reason. That's a bunch of unhelpful crap. Can we come up with an actual theory for what's wrong with my setup, please? Like, perhaps: Theory E: There's some undiagnosed new breakage that this introduces that no else hit until it went into mainline. Hmmm, this one sounds more promising. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Mon, Mar 05, 2007 at 04:46:09PM +0100, Tomasz Torcz wrote: > > That's not the point. The point is that Debian/unstable as of _this > > morning_ doesn't work. For reference, I'm running both the latest > > releases of both hal (0.5.8.1-6.1) and network-manager (0.6.4-6). And > > there are people telling me I need a copy of HAL out of git that > > hasn't even been released for Debian to package. Debian isn't the > > problem here. > > hal 0.5.9-rc1 (released, not from git) should work. It will be > problably released soon and picked by sane distributions. Debian is very > irritating corner case. Presumably the -rc1 stands for "release candidate". Which means "not yet released". And when did it show up? 04-Mar-2007 at 18:31. That's right, YESTERDAY. Almost a full month after Greg's commit. For the last time, DEBIAN IS NOT THE PROBLEM. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Mon, Mar 05, 2007 at 10:58:13AM -0800, Greg KH wrote: > Ok, how about the following patch. Is it acceptable to everyone? > > - If you are using a distro that was released in 2006 or later, > - it should be safe to say N here. > + If you are using an OpenSuSE, Gentoo, Ubuntu, or Fedora > + release from 2007 or later, it should be safe to say N here. > + > + If you are using Debian or other distros that are slow to > + update HAL, please say Y here. What HAL version do you think Debian ought to have, pray tell? And what the hell version do those other distros have? The last HAL release was 0.5.8 on 11-Sep-2006. It showed up in Debian/unstable on 2-Oct. There have been six Debian bugfix releases, the most recent on 12-Feb. http://people.freedesktop.org/~david/dist/ http://packages.debian.org/changelogs/pool/main/h/hal/hal_0.5.8.1-6.1/changelog The last NetworkManager is 0.6.4 released 13-Jul-2006. It showed up in Debian/unstable on 8-Aug. There have been five bugfix releases, the most recent on 30-Nov. http://ftp.gnome.org/pub/GNOME/sources/NetworkManager/0.6/ http://packages.debian.org/changelogs/pool/main/n/network-manager/network-manager_0.6.4-6/changelog Debian is NOT the problem. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Sun, Mar 04, 2007 at 11:02:48PM -0800, Greg KH wrote: > On Mon, Mar 05, 2007 at 12:42:29AM -0600, Matt Mackall wrote: > > On Sun, Mar 04, 2007 at 05:16:25PM -0800, Greg KH wrote: > > > On Sun, Mar 04, 2007 at 04:08:57PM -0600, Matt Mackall wrote: > > > > Recent kernels are having troubles with wireless for me. Two seemingly > > > > related problems: > > > > > > > > a) NetworkManager seems oblivious to the existence of my IPW2200 > > > > b) Manual iwconfig waits for 60s and then reports: > > > > > > > > Error for wireless request "Set Encode" (8B2A) : > > > > SET failed on device eth1 ; Operation not supported. > > > > > > Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that > > > will keep you from having to change any userspace code. > > > > No, it's disabled. Will test once I'm done tracking down the iwconfig > > problem. From the help text for SYSFS_DEPRECATED: > > > > If you are using a distro that was released in 2006 or > > later, it should be safe to say N here. > > > > If we need an as-yet-unreleased HAL without it, I would say the above > > should be changed to 2008 or so. If Debian actually cuts a release in > > the next few months, you might make that 2010. > > Well, just because Debian has such a slow release cycle, should the rest > of the world be forced to follow suit? :) > > When I originally wrote that, I thought Debian would have already done > their release, my mistake... That's not the point. The point is that Debian/unstable as of _this morning_ doesn't work. For reference, I'm running both the latest releases of both hal (0.5.8.1-6.1) and network-manager (0.6.4-6). And there are people telling me I need a copy of HAL out of git that hasn't even been released for Debian to package. Debian isn't the problem here. If it is indeed the case that HAL needs to be upgraded here, the clock on deprecating these features can't even start counting until a usable HAL version is released. And then you need to give it at least a year after that before you can start recommending people disable it. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Sun, Mar 04, 2007 at 05:16:25PM -0800, Greg KH wrote: > On Sun, Mar 04, 2007 at 04:08:57PM -0600, Matt Mackall wrote: > > Recent kernels are having troubles with wireless for me. Two seemingly > > related problems: > > > > a) NetworkManager seems oblivious to the existence of my IPW2200 > > b) Manual iwconfig waits for 60s and then reports: > > > > Error for wireless request "Set Encode" (8B2A) : > > SET failed on device eth1 ; Operation not supported. > > Do you have CONFIG_SYSFS_DEPRECATED enabled? If not, please do as that > will keep you from having to change any userspace code. No, it's disabled. Will test once I'm done tracking down the iwconfig problem. From the help text for SYSFS_DEPRECATED: If you are using a distro that was released in 2006 or later, it should be safe to say N here. If we need an as-yet-unreleased HAL without it, I would say the above should be changed to 2008 or so. If Debian actually cuts a release in the next few months, you might make that 2010. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
On Mon, Mar 05, 2007 at 12:39:24AM +0100, Johannes Berg wrote: > [adding linux-wireless to CC] > > On Sun, 2007-03-04 at 16:08 -0600, Matt Mackall wrote: > > Recent kernels are having troubles with wireless for me. Two seemingly > > related problems: > > I don't think they are related actually. > > > a) NetworkManager seems oblivious to the existence of my IPW2200 > > This is due to the recent sysfs restructuring I think. IIRC the fix is > to upgrade hal to a current git version. If that's the cause, the fix is to back out whatever was done to break userspace. Breaking userspace is not ok. Upgrading from 2.6.x to 2.6.x+1 should not entail replacing substantial parts of userspace, especially with NOT-EVEN-FRAKKING-RELEASED-YET CODE. I will try a new HAL when it shows up in Debian/unstable and not a moment sooner. > > b) Manual iwconfig waits for 60s and then reports: > > That one's strange. > > > A second attempt to enable WEP via iwconfig succeeds and network > > connectivity is normal. However, NetworkManager still ignores the > > device at this point. > > I'd think it's a ipw bug but I have no idea if that was even touched > during this time. > > > Bisect with Mercurial points to this patch: > > > > $ hg bisect bad > > The first bad revision is: > > changeset: 46985:f701b96bb2f7 > > user:Greg Kroah-Hartman <[EMAIL PROTECTED]> > > date:Wed Feb 07 10:37:11 2007 -0800 > > summary: Network: convert network devices to use struct device > > instead of class_device > > > > which corresponds to 43cb76d91ee85f579a69d42bc8efc08bac560278 in git. > > Yup, sysfs breakage/hal stuff. Can you try with a recent hal? And maybe > try to bisect the iwconfig stop thing if you've got enough time... Will double-check the iwconfig tests. It's been masked by NetworkManager for a while. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Recent wireless breakage (ipw2200, iwconfig, NetworkManager)
Recent kernels are having troubles with wireless for me. Two seemingly related problems: a) NetworkManager seems oblivious to the existence of my IPW2200 b) Manual iwconfig waits for 60s and then reports: Error for wireless request "Set Encode" (8B2A) : SET failed on device eth1 ; Operation not supported. During this time, my keyboard in X is unresponsive, but everything else seems to be functioning properly. Queued keypresses eventually show up. Alt-sysrq-w gives: ieee80211_crypt: registered algorithm 'WEP' SysRq : Show Blocked State freesibling task PCstack pid father child younger older events/0 D C0102D3C 0 4 1 5 3 (L-TLB) c1d0bf1c 0046 c1d0ac20 c0102d3c c1d0aa70 0022 000a c1d0aa70 ca8ed618 0034 0cd3 c1d0ab7c 0287 0002 f581f040 0002 c1d0bf34 0246 f7b5cb04 c1d0aa70 c038224e c0102c3a Call Trace: [] __switch_to+0x11b/0x143 [] __mutex_lock_slowpath+0xfb/0x1e2 [] __switch_to+0x19/0x143 [] ipw_bg_link_down+0x19/0xbd [ipw2200] [] ipw_bg_link_down+0x0/0xbd [ipw2200] [] run_workqueue+0x97/0x156 [] worker_thread+0x105/0x12e [] default_wake_function+0x0/0xc [] worker_thread+0x0/0x12e [] kthread+0xa0/0xc9 [] kthread+0x0/0xc9 [] kernel_thread_helper+0x7/0x10 === ipw2200/0 D 0020 0 1985 6 2260 1983 (L-TLB) f7981f24 0046 0001 0020 c1cdf8c0 000a f7d09030 e1fdc8c3 0034 093a f7d0913c 0086 0020 f7c4a740 0086 f7981f3c 0246 f7b5cb04 f7d09030 c038224e f7d09030 c0496550 Call Trace: [] __mutex_lock_slowpath+0xfb/0x1e2 [] __sched_text_start+0x4b3/0x56b [] ipw_bg_gather_stats+0x0/0x27 [ipw2200] [] ipw_bg_gather_stats+0x17/0x27 [ipw2200] [] run_workqueue+0x97/0x156 [] worker_thread+0x105/0x12e [] default_wake_function+0x0/0xc [] worker_thread+0x0/0x12e [] kthread+0xa0/0xc9 [] kthread+0x0/0xc9 [] kernel_thread_helper+0x7/0x10 === ieee80211_crypt_wep: could not allocate crypto API arc4 eth1: could not initialize WEP: load module ieee80211_crypt_wep ADDRCONF(NETDEV_UP): eth1: link is not ready A second attempt to enable WEP via iwconfig succeeds and network connectivity is normal. However, NetworkManager still ignores the device at this point. Bisect with Mercurial points to this patch: $ hg bisect bad The first bad revision is: changeset: 46985:f701b96bb2f7 user:Greg Kroah-Hartman <[EMAIL PROTECTED]> date:Wed Feb 07 10:37:11 2007 -0800 summary: Network: convert network devices to use struct device instead of class_device which corresponds to 43cb76d91ee85f579a69d42bc8efc08bac560278 in git. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2.6.19 take2 1/5] marking __init and remove drop initialization
On Thu, Dec 21, 2006 at 07:03:23PM +0900, Keiichi KII wrote: > - remove "drop" initialization in the netpoll structure. Why? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] e1000: fixes for 7.1.9-k2
On Fri, Jul 14, 2006 at 05:15:18PM -0700, Jeff Kirsher wrote: > Matt, > The patch you are referring to is in patch set emails that Auke sent out. Doesn't look like it made it here. > I have also copied the patch below: I'm going to assume all the tab damage here is an artifact. Otherwise, looks good. Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] e1000: fixes for 7.1.9-k2
On Fri, Jul 14, 2006 at 04:24:52PM -0700, Kok, Auke wrote: > > Jeff, > > Please pull the following patches from > > git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes-jgarzik > (based on 22e1170310ec6afa41e0dc7ac9dfac735d82dcab) > > To receive the following fixes for e1000: > > [01]: Redo netpoll fix Have I seen this patch? Is there a way to browse it? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17: networking bug??
On Tue, Jun 13, 2006 at 05:49:21PM -0400, Mark Lord wrote: > > > David Miller wrote: > >.. > >First, you are getting window scaling by default with the older > >kernel too. It's just a smaller window scale, using a shift > >value of say 1 or 2. > > > >What these broken middle boxes do is ignore the window scale > >entirely. > > > >So they don't apply a window scale to the advertised windows in each > >packet. Therefore, they think a smaller amount of window space is > >being advertised than really is. So they will silently drop packets > >they think is outside of this bogus window they've calculated. > > > >Now, when the window scale is smaller, the connection can still limp > >along, albeit slowly, making forward progress even in the face of such > >broken devices because half or a quarter of the window is still > >available. It will retransmit a lot, and the congestion window won't > >grow at all. > > > >When the window scale is larger, this middle box bug makes it such > >that not even one packet can fit into the miscalculated window and > >things wedge. The box thinks that your window is "94" instead of > >"94 << WINDOW_SCALE". > .. > > Unilaterally following the standard is all well and good > for those who know how to get around it when a site becomes > inaccessible, but not for Joe User. We had very similar issues with ECN. But unlike ECN, window scaling is not something we can just shrug our shoulders and say "oh well" about. We will have to deal with it eventually. It might as well be sooner. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] netpoll: don't spin forever sending to stopped queues
On Mon, Jun 12, 2006 at 01:57:58PM -0700, Jeremy Fitzhardinge wrote: > Matt Mackall wrote: > >On Thu, Jun 08, 2006 at 07:15:50PM -0700, Jeremy Fitzhardinge wrote: > > > >>Here's a patch. I haven't tested it beyond compiling it, and I don't > >>know if it is actually correct. In this case, it seems pointless to > >>spin waiting for an even which will never happen. Should > >>netif_poll_disable() cause netpoll_send_skb() (or something) to not even > >>bother trying to send? netif_poll_disable seems mysteriously simple to > >>me. > >> > >> J > >> > > > >Did this work for you at all? > > > > No, it didn't appear to help; I get the same symptom. I think fix is > correct (in that its better than what was there before), but there's > probably more going on in my case. I haven't looked into it more deeply > yet. I suspect there's another netpoll code path which is spinning > forever on an XOFFed queue. > > >>When transmitting a skb in netpoll_send_skb(), only retry a limited > >>number of times if the device queue is stopped. > >> > > > >Where limited = once? > > > > No, it reuses the existing retry logic. It retries 2 times with a > 50us pause between attempts, so up to a second. This seems excessive to > me; I don't know where those original numbers came from. I tried 5000 > retries, but it didn't make any difference to my case. Ahh, right. I forgot that I'd done that. Can you resend? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netpoll: break recursive loop in netpoll rx path
On Mon, Jun 12, 2006 at 11:40:29AM -0400, Neil Horman wrote: > Hey there- > the netpoll system currently has a rx to tx path via: > netpoll_rx > __netpoll_rx > arp_reply >netpoll_send_skb > dev->hard_start_tx > > This rx->tx loop places network drivers at risk of > inadvertently causing a deadlock or BUG halt by recursively trying > to acquire a spinlock that is used in both their rx and tx paths > (this problem was origionally reported to me in the 3c59x driver, > which shares a spinlock between the boomerang_interrupt and > boomerang_start_xmit routines). Grumble. > This patch breaks this loop, by queueing arp frames, so that they > can be responded to after all receive operations have been > completed. Tested by myself and the reported with successful > results. Tested how? kgdb? > + if (likely(npi)) > + while ((skb = skb_dequeue(&npi->arp_tx)) != NULL) > + arp_reply(skb); > + Assignment inside tests is frowned upon. I'd prefer pulling this out to its own function too. Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] netpoll: don't spin forever sending to stopped queues
On Thu, Jun 08, 2006 at 07:15:50PM -0700, Jeremy Fitzhardinge wrote:
> Matt Mackall wrote:
> >That's odd. Netpoll holds a reference to the device, of course, but so
> >does a normal "up" interface. So that shouldn't be the problem.
> >Another possibility is that outgoing packets from printks in the
> >driver are causing difficulty. Not sure what can be done about that.
> >
> Here's a patch. I haven't tested it beyond compiling it, and I don't
> know if it is actually correct. In this case, it seems pointless to
> spin waiting for an even which will never happen. Should
> netif_poll_disable() cause netpoll_send_skb() (or something) to not even
> bother trying to send? netif_poll_disable seems mysteriously simple to me.
>
>J
Did this work for you at all?
> When transmitting a skb in netpoll_send_skb(), only retry a limited
> number of times if the device queue is stopped.
Where limited = once?
> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
>
> diff -r aac813f54617 net/core/netpoll.c
> --- a/net/core/netpoll.c Wed Jun 07 14:53:40 2006 -0700
> +++ b/net/core/netpoll.c Thu Jun 08 19:00:29 2006 -0700
> @@ -280,15 +280,10 @@ static void netpoll_send_skb(struct netp
>* network drivers do not expect to be called if the queue is
>* stopped.
>*/
> - if (netif_queue_stopped(np->dev)) {
> - np->dev->xmit_lock_owner = -1;
> - spin_unlock(&np->dev->xmit_lock);
> - netpoll_poll(np);
> - udelay(50);
> - continue;
> - }
> -
> - status = np->dev->hard_start_xmit(skb, np->dev);
> + status = NETDEV_TX_BUSY;
> + if (!netif_queue_stopped(np->dev))
> + status = np->dev->hard_start_xmit(skb, np->dev);
> +
> np->dev->xmit_lock_owner = -1;
> spin_unlock(&np->dev->xmit_lock);
>
>
>
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using netconsole for debugging suspend/resume
On Fri, Jun 09, 2006 at 07:50:25AM +0200, Andi Kleen wrote: > On Friday 09 June 2006 07:23, David Miller wrote: > > From: Auke Kok <[EMAIL PROTECTED]> > > Date: Thu, 08 Jun 2006 22:13:48 -0700 > > > > > netconsole should retry. There is no timeout programmed here since that > > > might > > > lose important information, and you rather want netconsole to survive an > > > odd > > > unplugged cable then to lose vital debugging information when the system > > > is > > > busy for instance. (losing link will cause the interface to be down and > > > thus > > > the queue to be stopped) > > > > I completely disagree that netpoll should loop when the ethernet > > cable is plugged out. > > Currently it is a bit dumb and doesn't distingush the various cases > well. > > I submitted a patch to loop to be a bit more clever at some point. It can be > still > found in the netdev archives. Agreed that timeouts should happen. IIRC, the trouble with your patch was that it a) timed out on far too short a timescale and b) locked up on my box. Unfortunately, so did my own patch, which made timeouts approximately 1ms. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using netconsole for debugging suspend/resume
On Thu, Jun 08, 2006 at 10:50:57AM -0700, Jeremy Fitzhardinge wrote: > I've been trying to get suspend/resume working well on my new laptop. > In general, netconsole has been pretty useful for extracting oopses and > other messages, but it is of more limited help in debugging the actual > suspend/resume cycle. The problem looks like the e1000 driver won't > suspend while netconsole is using it, so I have to rmmod/modprobe > netconsole around the actual suspend/resume. That's odd. Netpoll holds a reference to the device, of course, but so does a normal "up" interface. So that shouldn't be the problem. Another possibility is that outgoing packets from printks in the driver are causing difficulty. Not sure what can be done about that. > This is a big problem during resume because the screen is also blank, so > I get no useful clue as to what went wrong when things go wrong. I'm > wondering if there's some way to keep netconsole alive to the last > possible moment during suspend, and re-woken as soon as possible during > resume. It would be nice to have a clean solution, but I'm willing to > use a bletcherous hack if that's what it takes. It's generally going to suck, because unlike a polled serial port, the device needs to be put to sleep. But if you're doing suspend to RAM, you might be able to do something like this: - unhook net device from suspend machinery (possibly just return success) - bounce out of suspend before the final call to ACPI is made Net effect is you do OS-level suspend and resume of everything but the NIC without actually powering down the core. Which should let you debug just about everything. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] e1000: fix netpoll with NAPI
On Wed, Jun 07, 2006 at 11:05:22AM -0400, Neil Horman wrote: > > > > > Matt, any ideas on this? > > > > Not at the moment. > > how about this for a solution? It doesn't make netpoll any more robust, but I > think in the interests of efficiency it would be fair to require that, when > netpolled, a driver must receive frames on the same net device for which it > was > polled. With this patch we detect that condition and handle it accordingly in > e1000_intr. This eliminates the need for us to call the clean_rx method from > the poll_controller when napi is configured, instead allowing the poll method > to > be called from napi_poll, as the netpoll model currently does. This fixes the > netdump regression, and eliminates the layering violation and the potential > race > that we've been discussing. I've just tested it with netdump here and it > works > quite well. > > Thoughts appreciated. This looks pretty reasonable, mostly from the perspective that it doesn't put any further ugliness in netpoll. We might want to add a comment somewhere in netpoll of the new rule we're now observing. I'll let the e1000 guys comment on the particulars of the driver change. > Signed-off-by: Neil Horman <[EMAIL PROTECTED]> Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] e1000: fix netpoll with NAPI
On Tue, Jun 06, 2006 at 01:42:59PM -0400, Jeff Moyer wrote: > ==> Regarding Re: [PATCH 1/2] e1000: fix netpoll with NAPI; Auke Kok <[EMAIL > PROTECTED]> adds: > > auke-jan.h.kok> Jeff Moyer wrote: > >> ==> Regarding Re: [PATCH 1/2] e1000: fix netpoll with NAPI; Auke Kok > >> <[EMAIL PROTECTED]> adds: > auke-jan.h.kok> Neil Horman wrote: > On Tue, Jun 06, 2006 at 09:39:25AM -0700, Mitch Williams wrote: > > On Tue, 2006-06-06 at 09:52 -0400, Neil Horman wrote: > auke-jan.h.kok> [snip] > >> > > However, just for the sake of correctness (and paranoia), I'll whip up > > another patch that does this check. > > > Thanks for the quick feedback! > Regards > Neil > > > Jeff, please do not commit this patch. > auke-jan.h.kok> Jeff, > auke-jan.h.kok> I've popped the patch off from our gitserver, so you can > >> pull the two > auke-jan.h.kok> outstanding patches while we revamp this one. > >> Would you please send patches to this list? I'd certainly like to review > >> them. I don't think the problem needs solving in the e1000 driver. I > >> think it is an issue that should be handled properly by netpoll. > > auke-jan.h.kok> ??? > > auke-jan.h.kok> that message was directed to Jeff Garzik, perhaps that was > too confusing. > > I figured it was directed at Jeff G. > > auke-jan.h.kok> They were sent here in the first place: > > auke-jan.h.kok> > http://marc.theaimsgroup.com/?l=linux-netdev&m=114954878711789&w=2 > > Thanks for the pointer. > > As you noted, e1000 now uses a separate device for polling. Netpoll should > be able to deal with this, though. I'd like to solicit mpm's input on > this, as I'm having difficulties coming up with a clean solution. It's a bit ad-hoc at the moment, but it might be a step towards a cleaner model. > For some background, the netpoll_poll_lock calls were introduced to prevent > recursion in a device driver's ->poll routine. By essentially calling the > poll routine from the poll_controller routine, you are no longer prevented > from such recursion. > > It would be best if the poll_controller routine was kept simple. It should > do the equivalent of the interrupt processing portion of the work, and > leave the delivery to the network stack for a call to the ->poll routine. > > Solving this at the netpoll layer will be a bit difficult, since we have no > insight into the driver design (as your driver illustrates). Up until now, > our model worked well. That's probably an overstatement. > We could, potentially, walk the list of devices scheduled for a poll much > the same as net_rx_action does. However, we don't want to process work > pending on other network adapters, only the one associated with the netpoll > net device. I can think of at least one way to make this distinction, but > it feels too much like a hack. Processing work on other devices may not be completely wrong. > Matt, any ideas on this? Not at the moment. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] drivers/char/random.c: unexport secure_ipv6_port_ephemeral
On Sun, Apr 09, 2006 at 05:58:22PM +0200, Adrian Bunk wrote: > This patch removes the unused EXPORT_SYMBOL(secure_ipv6_port_ephemeral). > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Acked-by: Matt Mackall <[EMAIL PROTECTED]> Adrian appears to be correct that this doesn't break modular ipv6. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netconsole: no IP address for eth0, aborting
On Tue, Mar 14, 2006 at 09:31:08AM -0800, Randy.Dunlap wrote: > On Mon, 13 Mar 2006 22:29:12 -0600 Matt Mackall wrote: > > > On Sun, Mar 12, 2006 at 04:27:51PM -0800, Randy.Dunlap wrote: > > > > > > hardware: e1000 NIC in ThinkPad T42 > > > kernel: 2.6.16-rc5-mm3 > > > > > > I always get $subject message. I changed the delay in > > > net/core/netpoll.c from 4 seconds to 9 seconds, but it > > > doesn't matter, the e1000 always finds Link is Up immediately > > > after $subject message. > > > > > > I suppose this is a consequence of e1000 using a workqueue for > > > some of its init code. Maybe it would work better on an MP > > > machine instead of UP (giving e1000 a CPU to init on?). > > > I guess I'll have to switch from netconsole built-in to use a > > > loadable module instead. That could work for some non-kernel-init > > > debugging, but this really needs to work for kernel init-time > > > debugging as well IMO. > > > > That's an odd message. Are you specifying an IP address on the command > > line? > > Yes, I am specifying a target IP address and a target MAC address. > Is that OK or should I not specify the IP address? That's fine, but you also need to specify a _source_ IP address. If the interface is up and configured, we can use its IP address, but that obviously doesn't work at boot time. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netconsole: no IP address for eth0, aborting
On Sun, Mar 12, 2006 at 04:27:51PM -0800, Randy.Dunlap wrote: > > hardware: e1000 NIC in ThinkPad T42 > kernel: 2.6.16-rc5-mm3 > > I always get $subject message. I changed the delay in > net/core/netpoll.c from 4 seconds to 9 seconds, but it > doesn't matter, the e1000 always finds Link is Up immediately > after $subject message. > > I suppose this is a consequence of e1000 using a workqueue for > some of its init code. Maybe it would work better on an MP > machine instead of UP (giving e1000 a CPU to init on?). > I guess I'll have to switch from netconsole built-in to use a > loadable module instead. That could work for some non-kernel-init > debugging, but this really needs to work for kernel init-time > debugging as well IMO. That's an odd message. Are you specifying an IP address on the command line? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism
On Wed, Dec 14, 2005 at 09:23:09PM -0800, David S. Miller wrote: > From: Matt Mackall <[EMAIL PROTECTED]> > Date: Wed, 14 Dec 2005 21:02:50 -0800 > > > There needs to be two rules: > > > > iff global memory critical flag is set > > - allocate from the global critical receive pool on receive > > - return packet to global pool if not destined for a socket with an > > attached send mempool > > This shuts off a router and/or firewall just because iSCSI or NFS peed > in it's pants. Not really acceptable. That'll happen now anyway. > > I think this will provide the desired behavior > > It's not desirable. > > What if iSCSI is protected by IPSEC, and the key management daemon has > to process a security assosciation expiration and negotiate a new one > in order for iSCSI to further communicate with it's peer when this > memory shortage occurs? It needs to send packets back and forth with > the remove key management daemon in order to do this, but since you > cut it off with this critical receive pool, the negotiation will never > succeed. Ok, encapsulation completely ruins the idea. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism
On Wed, Dec 14, 2005 at 08:30:23PM -0800, David S. Miller wrote: > From: Matt Mackall <[EMAIL PROTECTED]> > Date: Wed, 14 Dec 2005 19:39:37 -0800 > > > I think we need a global receive pool and per-socket send pools. > > Mind telling everyone how you plan to make use of the global receive > pool when the allocation happens in the device driver and we have no > idea which socket the packet is destined for? What should be done for > non-local packets being routed? The device drivers allocate packets > for the entire system, long before we know who the eventually received > packets are for. It is fully anonymous memory, and it's easy to > design cases where the whole pool can be eaten up by non-local > forwarded packets. There needs to be two rules: iff global memory critical flag is set - allocate from the global critical receive pool on receive - return packet to global pool if not destined for a socket with an attached send mempool I think this will provide the desired behavior, though only probabilistically. That is, we can fill the global receive pool with uninteresting packets such that we're forced to drop critical ACKs, but the boring packets will eventually be discarded as we walk up the stack and we'll eventually have room to receive retried ACKs. > I truly dislike these patches being discussed because they are a > complete hack, and admittedly don't even solve the problem fully. I > don't have any concrete better ideas but that doesn't mean this stuff > should go into the tree. Agreed. I'm fairly convinced a full fix is doable, if you make a couple assumptions (limited fragmentation), but will unavoidably be less than pretty as it needs to cross some layers. > I think GFP_ATOMIC memory pools are more powerful than they are given > credit for. There is nothing preventing the implementation of dynamic > GFP_ATOMIC watermarks, and having "critical" socket behavior "kick in" > in response to hitting those water marks. There are two problems with GFP_ATOMIC. The first is that its users don't pre-state their worst-case usage, which means sizing the pool to reliably avoid deadlocks is impossible. The second is that there aren't any guarantees that GFP_ATOMIC allocations are actually critical in the needed-to-make-forward-VM-progress sense or will be returned to the pool in a timely fashion. So I do think we need a distinct pool if we want to tackle this problem. Though it's probably worth mentioning that Linus was rather adamantly against even trying at KS. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism
On Wed, Dec 14, 2005 at 09:55:45AM -0800, Sridhar Samudrala wrote: > On Wed, 2005-12-14 at 10:22 +0100, Andi Kleen wrote: > > > I would appreciate any feedback or comments on this approach. > > > > Maybe I'm missing something but wouldn't you need an own critical > > pool (or at least reservation) for each socket to be safe against deadlocks? > > > > Otherwise if a critical sockets needs e.g. 2 pages to finish something > > and 2 critical sockets are active they can each steal the last pages > > from each other and deadlock. > > Here we are assuming that the pre-allocated critical page pool is big enough > to satisfy the requirements of all the critical sockets. Not a good assumption. A system can have between 1-1000 iSCSI connections open and we certainly don't want to preallocate enough room for 1000 connections to make progress when we might only have one in use. I think we need a global receive pool and per-socket send pools. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole Patches
On Tue, Nov 22, 2005 at 09:53:08PM +0100, Michael Frank wrote: > Hi Matt, > > I sent 3 patches to you and cc to netdev@vger.kernel.org but > the patches did not show up on netdev. > > Have you received them? No, but I got two copies of this email. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] move some code to net/ipx/af_ipx.c
On Fri, Nov 18, 2005 at 06:22:52AM +0100, Adrian Bunk wrote: > > > > This patch isn't bad, but looking closer we could move the contents of > > p8023.c as well as the contents of at least p8022.c and pe2.c into > > af_ipx.c. > > > > Is the contents of any of these three files expected to be used > > outside IPX (closest candidate would be appletalk)? > > Below is a patch implementing what I was thinking of. Looks reasonable. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] netpoll is unable to handle skb's using packet split
On Mon, Nov 14, 2005 at 09:41:30PM -0800, David S. Miller wrote: > From: "David S. Miller" <[EMAIL PROTECTED]> > Date: Mon, 14 Nov 2005 21:39:22 -0800 (PST) > > > From: Matt Mackall <[EMAIL PROTECTED]> > > Date: Mon, 14 Nov 2005 21:23:58 -0800 > > > > > What is "packet split" in this context? > > > > It's a mode of buffering used by the e1000 driver. > > BTW, the issue is that in packet split mode, the e1000 driver is > feeding paged based non-linear SKBs into the stack on receive which is > completely legal but aparently netpoll or something parsing netpoll RX > packets does not handle it properly. The bug is in netpoll. It's non-linear ignorant. We probably can't call skb_linearize because it wants to kmalloc, but we probably can follow the fragment. Or, worst case, we can manually linearize into an SKB in our private pool. Can we make any assumptions about the size and position of fragments. For instance, will the first N data bytes of a UDP packet all be in the same fragment? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] netpoll is unable to handle skb's using packet split
On Mon, Nov 14, 2005 at 01:15:38PM -0800, Jeff Kirsher wrote: > When using packet split, netpoll times out when doing a netdump. What is "packet split" in this context? You ought to cc: the netdump people as well, as it's not part of the mainline kernel. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Wed, Sep 07, 2005 at 12:17:01PM -0700, Ben Greear wrote: > Francois Romieu wrote: > >Stephen Hemminger <[EMAIL PROTECTED]> : > >[...] > > > >>It really sounds like netconsole needs to have a different device hook > >>instead of start_xmit. It also probably doesn't want to have allocate > >>an skb. What you want is a synchronous way to send one packet with > >>interrupts disabled: > >> > >>(dev->netpoll_send)(dev, packet, len) > > > > > >I do not see how it will solve the issue raised by David: > > > >hard_start_xmit does not disable irq and takes nearly no lock, > >thus it can be interrupted if a random irq event happens on a > >different device. Assume that the driver of the said different > >device issues a printk through netconsole and the game is over. > > > >Without extra locking, netpoll_send can not know that the > >interrupted hard_start_xmit has left the device/driver in a sane > >state. > > You could do some horrible kludge like make netpoll register itself > as active and then enable locking in both netpoll_send and hard_start_xmit. We can probably get away with something much lighter weight, as we only need to exclude netpoll from calling into the driver when it's already doing softirq processing. There's almost but not quite enough info for this already in the network scheduling flags. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Wed, Sep 07, 2005 at 11:19:42AM -0700, Stephen Hemminger wrote: > On Wed, 7 Sep 2005 10:19:33 -0700 > Matt Mackall <[EMAIL PROTECTED]> wrote: > > > On Tue, Sep 06, 2005 at 09:02:42PM -0700, Eugene Surovegin wrote: > > > I don't quite understand, you _already_ have deferred processing in > > > netpoll (btw, how good this will work with kgdboe?). > > > > Yes, it exists as a last ditch fallback for cases where we can detect > > deadlock. And it works not at all for kgdboe. Fortunately the fallback > > case rarely coincides with a breakpoint unless you're trying to debug > > the network stack itself (which is asking for trouble). > > > > > If some drivers cannot handle *additional* restriction (nowhere > > > documented, btw), ok, let's have a fallback mode for them, which you > > > _already_ have. > > > > If we have to use the fallback mode all the time on a particular device, > > netpoll has no value on that device. It can't catch the oopses you can't > > already catch most of with syslogd, and it can't be used for kgdb. > > At that point, why bother? > > > > > It's amazing, frankly, you insist that this feature "works just fine", > > > > I have in fact said since the first message in the thread that you > > guys are right, I'm breaking the rules. But I also claim it works fine > > for some hardware. These are not incompatible statements. The second > > is a reminder that this stuff is actually useful to people in its > > current form and that we shouldn't break that. > > > > It really sounds like netconsole needs to have a different device hook > instead of start_xmit. It also probably doesn't want to have allocate > an skb. What you want is a synchronous way to send one packet with > interrupts disabled: > > (dev->netpoll_send)(dev, packet, len) > > Yes, it means fixing lots of device drivers, or maybe a transitional > stub can be set in register_netdevice that uses start_xmit. That is > unsafe, but can used while you go about fixing the other devices. Netpoll already keeps a pool of skbs, so that's less of a problem. An interface like the above would be fine, and I could use hard_start_xmit for devices that haven't implemented it yet. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Wed, Sep 07, 2005 at 07:16:03PM +0200, Patrick McHardy wrote:
> Matt Mackall wrote:
> > If we move to softirq-only processing, it will not be a serial cable
> > replacement. It won't capture the tricky oopses you normally need a
> > serial cable for and it won't work with kgdb. It will be an awkward
> > syslogd and nothing more. I won't have any use for it and I suspect no
> > one else will either. It will be universally pointless.
>
> Not sure if its possible, but perhaps you could register the panic
> notifier to do whatever is necessary to get an oops out.
It's not really just about oopses.
Consider the case of:
printk("Starting subsystem X\n");
start_x();
printk("Starting subsystem Y\n");
start_y();
And we get:
Starting subsystem X
If we queue such messages, we get:
The first case has managed to localize the problem, the second tells
us nothing.
This is why serial console is polling for all printks. It's critical to
get any and all messages out immediately.
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Tue, Sep 06, 2005 at 09:02:42PM -0700, Eugene Surovegin wrote: > I don't quite understand, you _already_ have deferred processing in > netpoll (btw, how good this will work with kgdboe?). Yes, it exists as a last ditch fallback for cases where we can detect deadlock. And it works not at all for kgdboe. Fortunately the fallback case rarely coincides with a breakpoint unless you're trying to debug the network stack itself (which is asking for trouble). > If some drivers cannot handle *additional* restriction (nowhere > documented, btw), ok, let's have a fallback mode for them, which you > _already_ have. If we have to use the fallback mode all the time on a particular device, netpoll has no value on that device. It can't catch the oopses you can't already catch most of with syslogd, and it can't be used for kgdb. At that point, why bother? > It's amazing, frankly, you insist that this feature "works just fine", I have in fact said since the first message in the thread that you guys are right, I'm breaking the rules. But I also claim it works fine for some hardware. These are not incompatible statements. The second is a reminder that this stuff is actually useful to people in its current form and that we shouldn't break that. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Tue, Sep 06, 2005 at 08:42:39PM -0700, David S. Miller wrote: > You'll need to find a way to do netpoll without disabling hw IRQs > during these driver methods. Then netpoll would be universally > usable, as it would even work with drivers which are software tunnels > and which feed packets back into the networking stack once they > encapsulate, which currently netpoll cannot handle. Netpoll is intended to be a replacement for the requirement of serial cables for doing things like tricky oops capture and kgdb. If we move to softirq-only processing, it will not be a serial cable replacement. It won't capture the tricky oopses you normally need a serial cable for and it won't work with kgdb. It will be an awkward syslogd and nothing more. I won't have any use for it and I suspect no one else will either. It will be universally pointless. And no one cares about netconsole over tunnels (the first I've ever heard of that idea) if it can't capture oopses that syslogd can't already. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Tue, Sep 06, 2005 at 08:37:36PM -0700, Eugene Surovegin wrote: > On Tue, Sep 06, 2005 at 08:22:25PM -0700, Matt Mackall wrote: > > Which would I rather have: > > > > "netconsole never catches my oopses, it's useless." > > > > "netconsole didn't work with my driver, so I tried another card and it > > works great." > > Well, not all world which uses Linux is PC with PCI slots. In fact, > there are much more non-PC devices (where you have SoC with built-in > Ethernet) with Linux than PCs with Linux. Let me try that again: Which would I rather have: "netconsole never catches my oopses, it's useless." "netconsole didn't work with my driver, but it works with other drivers just fine." -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Tue, Sep 06, 2005 at 08:19:34PM -0700, David S. Miller wrote: > From: Matt Mackall <[EMAIL PROTECTED]> > Date: Tue, 6 Sep 2005 20:08:10 -0700 > > > Think upon the kgdb-over-ethernet case, please. The kernel hits a > > breakpoint, the kgdb stub stops everything, sends a packet to the > > debugging client, waits for a packet back.. This simply can't work if > > we delay send/receive to the next softirq processing. > > Networking is asynchronous, kgdb-over-ethernet wants synchronous > processing from an asynchronous subsystem. It is therefore no > surprise that these two sets of requirements are at odds with each > other and it simply isn't going to work very well. Serial is also asynchronous. And yet we have robust polling support for typical serial hardware that works great for both console and remote debugging support. Why? Because delivering kernel messages synchronously has been a requirement for the serial console since day one. Kgdboe simply wants the asynchronous subsystem to get out of the way. For most cards, it works just fine. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Tue, Sep 06, 2005 at 07:32:38PM -0700, Eugene Surovegin wrote: > On Tue, Sep 06, 2005 at 07:19:21PM -0700, Matt Mackall wrote: > > > or a') make this a per-driver feature (e.g. NETIF_F_NETPOLL_CHALENGED) > > > > > > In this case, even if driver cannot handle being called from IRQ > > > context, netconsole still can be used, although in a little more > > > limited fashion, but being safe and not causing lock ups, which, as > > > far as I understand you, it was designed to help debugging in the > > > first place :). > > > > Again, there's basically no point to this at all. It won't catch an > > appreciable number of diagnostics that are not already caught by > > syslog and it won't work with kgdb-over-ethernet, netdump, etc. > > Well, you're simplifying here. There are small embedded systems which > don't have syslogd, serial cable connected. For such systems even > softirq driven netpoll is useful. I'm fairly familiar with the requirements of embedded systems, thanks. If you're not getting significantly more functionality than the syslogd in, say, busybox (about 4k), then why put it in the kernel? > Anyway, it's much more easier for me to just say to my driver users > that netpoll is broken and isn't supported because of this, than > arguing here. For some reason, I have a wrong impression, that you > would want *more* users of your stuff. Which would I rather have: "netconsole never catches my oopses, it's useless." "netconsole didn't work with my driver, so I tried another card and it works great." -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Tue, Sep 06, 2005 at 07:37:45PM -0700, David S. Miller wrote: > From: Matt Mackall <[EMAIL PROTECTED]> > Date: Tue, 6 Sep 2005 18:03:38 -0700 > > > Option c) is obviously a big project but maybe we can get from here to > > there. One possible step in that direction would be exposing a > > standard driver lock that netpoll can see and switching drivers that > > have trouble (bnx2 and tg3 for starters) over to using it. > > If this means moving them over to hw IRQ locking, this I totally > cannot agree with. It's a non-starter. > > I worked way too hard to eliminate all of the hw IRQ locking from the > tg3 driver. There is no way we'll have it undone for something like > netpoll. My proposal is for drivers to expose enough internal state in a consistent fashion so that netpoll can avoid lock recursion deadlocks. I don't particularly care how. > And as I stated, you absolutely cannot call some drivers > ->hard_start_xmit() routine with hw IRQs disabled. It's just not > possible at all. I even tried this myself last year in order to deal > with a seperate locking issue, and it failed miserably. To reiterate: > > Drivers need to be able to let things like jiffies > advance in their ->hard_start_xmit() routine. Thus > disabling HW interrupts during ->hard_start_xmit()'s > execution cannot ever be allowed. That's sounds like a per-driver limitation, albeit likely a very hard one to work around. > All of this points to the fact that network stuff needs to be done > within software IRQ context. > > I also do not agree with your assertion that netpoll cannot be useful > if run from software IRQ context. Someone trying to implement block > device based core dumping would run into the same exact issue in the > SCSI layer, which runs command completion from sw IRQs and whose > locking totally depends upon it. ...And that's been tried and does indeed lose most of the time. Which is why it's been abandoned. Think upon the kgdb-over-ethernet case, please. The kernel hits a breakpoint, the kgdb stub stops everything, sends a packet to the debugging client, waits for a packet back.. This simply can't work if we delay send/receive to the next softirq processing. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Tue, Sep 06, 2005 at 06:37:40PM -0700, Eugene Surovegin wrote: > On Tue, Sep 06, 2005 at 06:03:38PM -0700, Matt Mackall wrote: > > On Tue, Sep 06, 2005 at 04:01:24PM -0700, David S. Miller wrote: > > > So you cannot call into these drivers with HW interrupts disabled or > > > even worse from HW interrupt context. These drivers use locking > > > strategies which are perfectly legal and work until you add netpoll. > > > > And again, I agree. > > > > What I disagree with is the claim that it's netpoll that's "broken". > > Again, I claim that netpoll is not doing something fundamentally > > unreasonable. Driving hardware by polling with interrupts disabled is > > nothing magic, it's just something the network stack to date has not > > been designed to cope with. > > Well, it's not driving hw in polling mode with hw IRQs disabled > (in fact, NAPI does exactly this), it's _calling_ driver entry > points from illegal context. IMHO this is not the same. The only reasonable way for core code to manipulate hardware is calling driver interfaces, so I think you're splitting hairs. > > So we can either: > > > > a) have a netpoll that's crippled to softirq-only > > b) live with some amount of localized brain damage here > > c) attempt to make the stack more netpoll-accomodating > > or a') make this a per-driver feature (e.g. NETIF_F_NETPOLL_CHALENGED) > > In this case, even if driver cannot handle being called from IRQ > context, netconsole still can be used, although in a little more > limited fashion, but being safe and not causing lock ups, which, as > far as I understand you, it was designed to help debugging in the > first place :). Again, there's basically no point to this at all. It won't catch an appreciable number of diagnostics that are not already caught by syslog and it won't work with kgdb-over-ethernet, netdump, etc. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Tue, Sep 06, 2005 at 04:01:24PM -0700, David S. Miller wrote: > So you cannot call into these drivers with HW interrupts disabled or > even worse from HW interrupt context. These drivers use locking > strategies which are perfectly legal and work until you add netpoll. And again, I agree. What I disagree with is the claim that it's netpoll that's "broken". Again, I claim that netpoll is not doing something fundamentally unreasonable. Driving hardware by polling with interrupts disabled is nothing magic, it's just something the network stack to date has not been designed to cope with. So we can either: a) have a netpoll that's crippled to softirq-only b) live with some amount of localized brain damage here c) attempt to make the stack more netpoll-accomodating Option a) is a non-starter. It's scarcely better than syslogd for logging purposes, and completely useless for things like kgdb-over-ethernet and the like. Option b) is what we have now. It's ugly as hell, agreed, but it does work for quite a few scenarios where nothing else suffices. Option c) is obviously a big project but maybe we can get from here to there. One possible step in that direction would be exposing a standard driver lock that netpoll can see and switching drivers that have trouble (bnx2 and tg3 for starters) over to using it. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Tue, Sep 06, 2005 at 03:42:07PM -0700, David S. Miller wrote: > Mentioning the latency of the serial console, in support of > netpoll's interrupt disabling, is quite a straw man. No, it's exactly to the point: latency is a secondary concern when we're printing an oops or other diagnostic. Otherwise it would be unacceptable in the serial console as well, where the problem is orders of magnitude worse. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Tue, Sep 06, 2005 at 03:36:27PM -0700, David S. Miller wrote: > From: Eugene Surovegin <[EMAIL PROTECTED]> > Date: Tue, 6 Sep 2005 15:04:17 -0700 > > > David, correct me if I'm wrong, but I think there is a major problem > > with current netconsole/netpoll approach. > > You're preaching to the choir. I think the whole netpoll > implementation is fundamentally flawed, and the locking problems we > keep bumping into are merely a symptom. > > People want this thing so badly, that I keep letting them continue to > patch this thing into quasi-working, even though it's foundations are > what are so problematic. Well I agree in some ways and disagree in others. > It's never going to work %100 reliably, I think, here's why: > > The core issue, and conflict, is that the desire is to have the > responses be immediate and come at the moment the event occurs. > Because the situation may be so dire that deferring into a more > appropriate software IRQ context may not be possible, and thus we'd > lose the log message or event. In the case of kgdb-over-ethernet or netdump or several others, deferring to an IRQ context doesn't even make sense. > So we try to spit out netconsole messages in hw IRQ context and stuff > like that, as you stated. The tg3 driver is susceptible to the > problem you mention, as is bnx2, because they use purely software > interrupt spinlocking, and thus their timers will deadlock if any hw > IRQ context netpoll operations occur. I'm not aware of the tg3 problem, please describe it in more detail. > There is a way to fix all of this, deferring all netpoll operations to > software IRQ context, but you sacrifice reliability when the system is > in such a bad state that software IRQs are not occuring any more > or are deadlocked. At that point, why bother? Just use syslogd. Or more likely, use a serial cable, which will actually work reliably. Where I disagree is this: what netpoll is trying to do is not fundamentally unreasonable. There's nothing magical about interrupts that should make it impossible to drive network hardware in polled mode with interrupts disabled. Instead, the problem is that the network stack has evolved in a direction that made a bunch of fairly reasonable assumptions that netpoll has now broken. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole violates dev->hard_start_xmit synch rules
On Tue, Sep 06, 2005 at 02:47:14PM -0700, David S. Miller wrote: > From: Eugene Surovegin <[EMAIL PROTECTED]> > Date: Tue, 6 Sep 2005 00:40:01 -0700 > > > According to Documentation/networking/netdevices.txt > > dev->hard_start_xmit must be called with interrupts *enabled*. > > > > Unfortunately, current netconsole code always calls netpoll with local > > interrupts disabled: > > > > write_msg (local_irq_save) > > netpoll_send_udp > > netpoll_send_skb > > np->dev->hard_start_xmit. > > > > I'm not sure this can cause any problems, but quick grep has showed > > that some drivers indeed rely on the documented behavior. > > > > Also, it'd be nice if netpoll author updated netdevices.txt with info > > about dev->poll_controller sync rules :) (in fact, I stumbled upon > > this inconsistency when I was trying to figure out locking for > > dev->poll_controller implementation in my driver). > > Yes, several drivers rely on interrupts being enabled, I learned this > the hard way in the past. Also, disabling interrupts during this > potentially expensive function call can kill your interrupt latency > sensitive devices (such as serial ports) and allow them to overflow. We already have a similar latency problem but much worse with serial console. It does blocking polled I/O at serial rates, so printks have ~1ms latency _per character_ at 9600bps. Even at 115200bps, we're still looking at ~4ms to send half a line of text. > I don't immediately see how this can be fixed, because the console > code does really need to disable interrupts in order to not try > to recursively take it's locks. Unfortunately, netpoll fundamentally requires everything to work with interrupts off. This can't be changed. It could be called from the context of an oops, or worse, by the kgdb stub at a breakpoint. If drivers require interrupts enabled for hard_start_xmit, they simply can't work with netpoll. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netpoll can lock up on low memory.
On Sat, Aug 06, 2005 at 05:57:20AM -0400, Steven Rostedt wrote: > On Sat, 2005-08-06 at 02:46 -0700, David S. Miller wrote: > > Can you guys stop peeing your pants over this, put aside > > your differences, and work on a mutually acceptable fix > > for these bugs? > > > > Much appreciated, thanks :-) > > In my last email, I stated that this discussion seems to have > demonstrated that the e1000 driver's netpoll is indeed broken, and needs > to be fixed. I submitted eariler a patch for this, but it's untested > and someone who owns an e1000 needs to try it. I've got your e1000 change in my queue and I'll try to test it tomorrow (realized I've got e1000 in my laptop). > As for all the netpoll issues, I'm satisfied with whatever you guys > decide. But I've seen lots of problems posted over the netpoll and > e1000, where people send in patches that do everything but fix the > e1000, and that's where I chimed in. Andi's patch looks like it fixes a related but slightly different problem. I'm working on a variant. And I'll try to make the skb allocation code eventually give up too. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netpoll can lock up on low memory.
On Sat, Aug 06, 2005 at 09:58:27AM +0200, Ingo Molnar wrote: > > btw., the current NR_SKBS 32 in netpoll.c seems quite low, especially > e1000 can have a whole lot more skbs queued at once. Might be more > robust to increase it to 128 or 256? Not sure that the card's queueing really makes a difference. It either eventually releases the queued SKBs or it doesn't. What's more important is that we be able to survive bursts like the output of sysrq-t. This seems to work already. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 08:23:55PM -0400, Steven Rostedt wrote: > On Fri, 2005-08-05 at 14:28 -0700, Matt Mackall wrote: > > > > Netpoll generally must assume it won't get a second chance, as it's > > being called by things like oops() and panic() and used by things like > > kgdb. If netpoll fails, the box is dead anyway. > > But it is also being called by every printk in the kernel. What happens > when the printk that causes this lock up is not a panic but just some > info print. One would use netconsole when they turn on more verbose > printing, to keep the output fast, right? So if the system gets a > little memory tight, but not to the point of failing, this will cause a > lock up and no one would know why. This doesn't happen, or if it does, it happens far less often than genuine crashes. This can only happen when netpoll's burned through its entire pool of SKBs in a single interrupt and the card never releases them, despite repeated prodding. In other words, you'll get most of a dump out of the box, but you're probably screwed no matter what you do. Also note that _any_ printk can be the kernel's dying breath. This is why for both serial and video we do polled I/O to be sure we actually get our message out. Netconsole is no different. > If you need to really get the data out, then the design should be > changed. Have some return value showing the failure, check for > oops_in_progress or whatever, and try again after turning interrupts > back on, and getting to a point where the system can free up memory > (write to swap, etc). Just a busy loop without ever getting a skb is > just bad. Why, pray tell, do you think there will be a second chance after re-enabling interrupts? How does this work when we're panicking or oopsing where we most care? How does this work when the netpoll client is the kernel debugger and the machine is completely stopped because we're tracing it? As for busy loops, let me direct you to the "poll" part of the name. It is in fact the whole point. > > > So even a long timeout would not do? So you don't even get a message to > > > the console? > > > > In general, there's no way to measure time here. And if we're > > using netconsole, what makes you think there's any other console? > > Why assume that there isn't another console? The screen may be used > with netconsole, you just lose whatever has been scrolled too far. Yes, there may be another console, but we should by no means depend on that being the case. We should in fact assume it's not. > > > > > Also, as Andi told me, the printk here would probably not show up > > > > > anyway if this happens with netconsole. > > > > > > > > That's fine. But in fact, it does show up occassionally - I've seen > > > > it. > > > > > > Then maybe what Andi told me is not true ;-) > > > > > > Oh, and did your machine crash when you saw it? Have you seen it with > > > the e1000 driver? > > > > No and no. Most of my own testing is done with tg3. > > > > If you saw the message and the system didn't crash, then that's proof > that if the driver is not working properly, you would have lock up the > system, and the system was _not_ in a state that it _had_ to get the > message out. Let me be more precise. I've seen it in the middle of an oops dump, where it complained, then made further progress, and then died. In other words, the code works. And I've since upped the pool size. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lockups with netconsole on e1000 on media insertion
On Sat, Aug 06, 2005 at 01:51:22AM +0200, Andi Kleen wrote: > > But why are we in a hurry to dump the backlog on the floor? Why are we > > worrying about the performance of netpoll without the cable plugged in > > at all? We shouldn't be optimizing the data loss case. > > Because a system shouldn't stall for minutes (or forever like right now) > at boot just because the network cable isn't plugged in. Using netconsole without a network cable could well be classified as a serious configuration error. NFS also is a bit sluggish without a network cable. I've already agreed that forever is a problem. Can we work towards agreeing on a non-trivial timeout, please? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 11:51:18PM +0200, Andi Kleen wrote: > > > If that was the policy it would be a quite dumb one and make netpoll > > > totally unsuitable for production use. I hope it is not. > > > > Suggest you rip __GFP_NOFAIL out of JBD before complaining about this. > > So you're suggesting we should become as bad at handling networking > errors as we are at handling IO errors? No, I'm suggesting that the machine will hang forever sometimes and no amount of patching up netpoll or JBD, etc. will fix that. A hardware watchdog is a requirement for robust failover anyway and if you think otherwise, you're dreaming. And for reference, both are examples of theoretical should-never-happen memory allocation failures. > > > Dave, can you please apply the timeout patch anyways? > > > > Yes, let's go right over the maintainer's objections almost > > immediately after he chimes into the thread. I'll spare the list the > > colorful language this inspires. > > Sure when the maintainer has a unreasonable position on something > I think that's justified. Yours in this case is clearly unreasonable. What's clear is that you didn't like my position from my very first post in this thread and immediately went for the nuclear option without even trying to discuss it. Are you even aware that the patch we're discussing here is for a problem that has yet to be observed and that Steven's initial analysis had missed a couple things? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lockups with netconsole on e1000 on media insertion
On Fri, Aug 05, 2005 at 11:56:50PM +0200, Andi Kleen wrote: > > I still don't like this fix. Yes, you're right, it should eventually > > give up. But here it gives up way too easily - 5 could easily > > translate to 5 microseconds. This is analogous to giving up on serial > > transmit if CTS is down for 5 loops. > > > > I'd be much happier if there were some udelay or the like in here so > > that we're not giving up on such a short timeframe. > > Problem is that it could translate to a long aggregate delay > e.g. when the kernel tries to dump the backlog after console_init. > That is why I made the delay so short. But why are we in a hurry to dump the backlog on the floor? Why are we worrying about the performance of netpoll without the cable plugged in at all? We shouldn't be optimizing the data loss case. My primary concern here is that the loop have a non-negligible extent in time. 5 loops is effectively equal to none. I'd be very surprised if it was even enough for deglitching. With serial console, we do polled I/O that runs at the serial rate - milliseconds per line of output. > Longer delay would be possible, but then it would need some logic > to detect down links and don't delay on them and then retry later etc. > Would be all far more complicated. I think we could probably have subsequent failures be much shorter without too much added complexity. But I'm not sure it matters. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 11:26:10PM +0200, Andi Kleen wrote: > On Fri, Aug 05, 2005 at 01:01:57PM -0700, Matt Mackall wrote: > > The netpoll philosophy is to assume that its traffic is an absolute > > priority - it is better to potentially hang trying to deliver a panic > > message than to give up and crash silently. > > That would be ok if netpoll was only used to deliver panics. But > it is not. It delivers all messages, and you cannot hang the > kernel during that. Actually even for panics it is wrong, because often > it is more important to reboot in a panic than (with a panic timeout) > to actually deliver the panic. That's needed e.g. in a failover cluster. > > If that was the policy it would be a quite dumb one and make netpoll > totally unsuitable for production use. I hope it is not. Suggest you rip __GFP_NOFAIL out of JBD before complaining about this. > Dave, can you please apply the timeout patch anyways? Yes, let's go right over the maintainer's objections almost immediately after he chimes into the thread. I'll spare the list the colorful language this inspires. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 04:57:00PM -0400, Steven Rostedt wrote: > On Fri, 2005-08-05 at 13:01 -0700, Matt Mackall wrote: > > On Fri, Aug 05, 2005 at 10:36:31AM -0400, Steven Rostedt wrote: > > > Looking at the netpoll routines, I noticed that the find_skb could > > > lockup if the memory is low. This is because the allocations are > > > called with GFP_ATOMIC (since this is in interrupt context) and if > > > it fails, it will continue to fail. This is just by observing the > > > code, I didn't have this actually happen. So if this is not the > > > case, please let me know how it can get out. Otherwise, please > > > accept this patch. > > > > By netpoll_poll() tickling the driver enough to free the currently > > queued outgoing SKBs. > > I believe that the e1000 wont free up any outgoing packets since the > netpoll call doesn't seem to get to the e1000_clean_tx part of the > e1000_intr, otherwise the system wouldn't lock under the > netpoll_send_skb when one disconnects the wire and puts it back in. The > disconnect would lock it up anyway (with Andi's patch it now doesn't) > but since it won't come back up after the link is back up, there seems > to be something wrong with the e1000 netpoll driver. This is because > the e1000_netpoll doesn't seem to be cleaning up the tx buffer and start > the queue back up. That does seem like a driver problem. > > Also note that by the time we're in this loop, we're ready to take > > desperate measures. We've already exhausted our private queue of SKBs > > so we have no alternative but to keep kicking the driver until > > something happens. > > OK, the system is under heavy memory load and starts eating up the > netpoll packets. When the last packet is gone, and you have something > like the e1000 that doesn't clean up its packets with netpoll, then you > just locked up the system. > > The scary part of this loop is that if the netpoll doesn't come up with > the goods, its game over. Say we are at desperate measures but it could > be a case where we need to output more information and lockup here > before we can go out and free some memory. Realistically, we were probably going to crash anyway at this point as we're apparently failing to recycle SKBs. Netpoll generally must assume it won't get a second chance, as it's being called by things like oops() and panic() and used by things like kgdb. If netpoll fails, the box is dead anyway. > > The netpoll philosophy is to assume that its traffic is an absolute > > priority - it is better to potentially hang trying to deliver a panic > > message than to give up and crash silently. > > So even a long timeout would not do? So you don't even get a message to > the console? In general, there's no way to measure time here. And if we're using netconsole, what makes you think there's any other console? > > > Also, as Andi told me, the printk here would probably not show up > > > anyway if this happens with netconsole. > > > > That's fine. But in fact, it does show up occassionally - I've seen > > it. > > Then maybe what Andi told me is not true ;-) > > Oh, and did your machine crash when you saw it? Have you seen it with > the e1000 driver? No and no. Most of my own testing is done with tg3. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lockups with netconsole on e1000 on media insertion
On Fri, Aug 05, 2005 at 01:45:55PM +0200, Andi Kleen wrote: > John B?ckstrand <[EMAIL PROTECTED]> writes: > > > I've been trying to hunt down a hard lockup issue with some hardware > > of mine, but I've possibly hit a kernel bug instead. When using > > netconsole on my e1000, if I unplug the cable and then re-plug it, the > > machine locks up hard. It manages to print the "link up" message on > > the screen, but nothing after that. Now, I wonder if this is supposed > > to be so? I tried this on 4 different configurations, 2.6.13-rc5 and > > 2.6.12 with and without "noapic acpi=off", same result on all of > > them. I've tried with 1 and 3 other NICs in the machine at the same > > time. > > I ran into the same problem some time ago on e1000. The problem was > that if the link doesn't come up netconsole ends up waiting forever > for it. I still don't like this fix. Yes, you're right, it should eventually give up. But here it gives up way too easily - 5 could easily translate to 5 microseconds. This is analogous to giving up on serial transmit if CTS is down for 5 loops. I'd be much happier if there were some udelay or the like in here so that we're not giving up on such a short timeframe. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netpoll can lock up on low memory.
On Fri, Aug 05, 2005 at 10:36:31AM -0400, Steven Rostedt wrote: > Looking at the netpoll routines, I noticed that the find_skb could > lockup if the memory is low. This is because the allocations are > called with GFP_ATOMIC (since this is in interrupt context) and if > it fails, it will continue to fail. This is just by observing the > code, I didn't have this actually happen. So if this is not the > case, please let me know how it can get out. Otherwise, please > accept this patch. By netpoll_poll() tickling the driver enough to free the currently queued outgoing SKBs. Also note that by the time we're in this loop, we're ready to take desperate measures. We've already exhausted our private queue of SKBs so we have no alternative but to keep kicking the driver until something happens. The netpoll philosophy is to assume that its traffic is an absolute priority - it is better to potentially hang trying to deliver a panic message than to give up and crash silently. > Also, as Andi told me, the printk here would probably not show up > anyway if this happens with netconsole. That's fine. But in fact, it does show up occassionally - I've seen it. NAK'ed. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atheros driver (1/8)
Some initial comments: - you should include a description of each patch in the message - you should use more descriptive subjects, eg [PATCH 1/8] atheros: Kconfig bits -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netconsole Driver
On Fri, Jul 29, 2005 at 12:13:06PM -0500, Paul Vinson wrote: > >> > Are you sure eth1 is an e1000? From e1000_main.c: > >> > > >> > #ifdef CONFIG_NET_POLL_CONTROLLER > >> > netdev->poll_controller = e1000_netpoll; > >> > #endif > >> > > >> > That's been there for 17 months. > >> > >> Yep, it's an e1000: > >> > >> [EMAIL PROTECTED] cat /proc/modules > >> e1000 82612 0 - Live 0xf88f2000 > >> > >> It's quite a mystery. I've been racking my brains. > >> > >> Please holler if anything else comes to mind. > > > > Send me your full dmesg output. > > -- > > Matt, > > I had compiled the kernel with 'CONFIG_E1000_NAPI=y'. Once I disabled > that netconsole worked fine. Odd. I don't see any reason why netconsole should fail to work with that switch on. The original report indicated netdev->poll_controller wasn't set, but that doesn't seem to be affected by the NAPI config. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] NETCONSOLE must depend on INET
On Wed, Jul 27, 2005 at 01:19:00PM -0700, David S. Miller wrote: > From: Matt Mackall <[EMAIL PROTECTED]> > Date: Tue, 26 Jul 2005 19:36:37 -0700 > > > # HG changeset patch > > # User [EMAIL PROTECTED] > > # Node ID 6cdd6f36d53678a016cfbf5ce667cbd91504d538 > > # Parent 75716ae25f9d87ee2a5ef7c4df2d8f86e0f3f762 > > Move in_aton from net/ipv4/utils.c to net/core/utils.c > > This patch doesn't apply, in the current 2.6.x GIT tree > NETCONSOLE does not depend on NETDEVICES. Odd, gitweb of Linus' tree seems to disagree. I see it depends on NETDEVICES && INET && EXPERIMENTAL. NETDEVICES has been there since the beginning of git history and according to my Mercurial import from BKCVS, it's been dependent on NETDEVICES since I first submitted it. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] NETCONSOLE must depend on INET
[sch added to cc: as I think he's the effective pktgen maintainer]
On Tue, Jul 26, 2005 at 05:03:49PM -0700, David S. Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Tue, 26 Jul 2005 16:58:24 -0700
>
> > On Tue, Jul 26, 2005 at 04:32:02PM -0700, David S. Miller wrote:
> > > More seriously, please submit a version of whatever you
> > > believe to be the more correct fix so it can be reviewed
> > > and integrated.
> >
> > Do you have a preferred location to put this function or
> > shall I invent one?
>
> I actually can't wait to see where you're going to
> to put a function that transforms "IPV4 addresses"
> from ascii other than some place protected by CONFIG_INET.
> :-)
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 6cdd6f36d53678a016cfbf5ce667cbd91504d538
# Parent 75716ae25f9d87ee2a5ef7c4df2d8f86e0f3f762
Move in_aton from net/ipv4/utils.c to net/core/utils.c
Move in_aton to allow netpoll and pktgen to work without the rest of
the IPv4 stack. Fix whitespace and add comment for the odd placement.
Delete now-empty net/ipv4/utils.c
Re-enable netpoll/netconsole without CONFIG_INET
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
diff -r 75716ae25f9d -r 6cdd6f36d536 drivers/net/Kconfig
--- a/drivers/net/Kconfig Tue Jul 26 23:21:24 2005
+++ b/drivers/net/Kconfig Wed Jul 27 02:31:24 2005
@@ -2544,7 +2544,7 @@
config NETCONSOLE
tristate "Network console logging support (EXPERIMENTAL)"
- depends on NETDEVICES && INET && EXPERIMENTAL
+ depends on NETDEVICES && EXPERIMENTAL
---help---
If you want to log kernel messages over the network, enable this.
See for details.
diff -r 75716ae25f9d -r 6cdd6f36d536 net/core/utils.c
--- a/net/core/utils.c Tue Jul 26 23:21:24 2005
+++ b/net/core/utils.c Wed Jul 27 02:31:24 2005
@@ -23,9 +23,9 @@
#include
#include
+#include
#include
#include
-
/*
This is a maximally equidistributed combined Tausworthe generator
@@ -153,3 +153,38 @@
EXPORT_SYMBOL(net_random);
EXPORT_SYMBOL(net_ratelimit);
EXPORT_SYMBOL(net_srandom);
+
+/*
+ * Convert an ASCII string to binary IP.
+ * This is outside of net/ipv4/ because various code that uses IP addresses
+ * is otherwise not dependent on the TCP/IP stack.
+ */
+
+__u32 in_aton(const char *str)
+{
+ unsigned long l;
+ unsigned int val;
+ int i;
+
+ l = 0;
+ for (i = 0; i < 4; i++)
+ {
+ l <<= 8;
+ if (*str != '\0')
+ {
+ val = 0;
+ while (*str != '\0' && *str != '.')
+ {
+ val *= 10;
+ val += *str - '0';
+ str++;
+ }
+ l |= val;
+ if (*str != '\0')
+ str++;
+ }
+ }
+ return(htonl(l));
+}
+
+EXPORT_SYMBOL(in_aton);
diff -r 75716ae25f9d -r 6cdd6f36d536 net/ipv4/Makefile
--- a/net/ipv4/Makefile Tue Jul 26 23:21:24 2005
+++ b/net/ipv4/Makefile Wed Jul 27 02:31:24 2005
@@ -2,7 +2,7 @@
# Makefile for the Linux TCP/IP (INET) layer.
#
-obj-y := utils.o route.o inetpeer.o protocol.o \
+obj-y := route.o inetpeer.o protocol.o \
ip_input.o ip_fragment.o ip_forward.o ip_options.o \
ip_output.o ip_sockglue.o \
tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o \
diff -r 75716ae25f9d -r 6cdd6f36d536 net/ipv4/utils.c
--- a/net/ipv4/utils.c Tue Jul 26 23:21:24 2005
+++ /dev/null Wed Jul 27 02:31:24 2005
@@ -1,59 +0,0 @@
-/*
- * INETAn implementation of the TCP/IP protocol suite for the
LINUX
- * operating system. INET is implemented using the BSD Socket
- * interface as the means of communication with the user level.
- *
- * Various kernel-resident INET utility functions; mainly
- * for format conversion and debugging output.
- *
- * Version:$Id: utils.c,v 1.8 2000/10/03 07:29:01 anton Exp $
- *
- * Author: Fred N. van Kempen, <[EMAIL PROTECTED]>
- *
- * Fixes:
- * Alan Cox: verify_area check.
- * Alan Cox: removed old debugging.
- * Andi Kleen : add net_ratelimit()
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include
-#include
-#include
-
-/*
- * Convert an ASCII string to binary IP.
- */
-
