* potentially kernel panic on lib/rbtree.c
From: slavon @ 2007-09-02 19:01 UTC (permalink / raw)
To: netdev
Sorry for prev. send =(
Hi all. Have some time panic from sch_htb.c
I see to gdb and see that panic at lib/rbtree.c:80
gparent == NULL
maybe add lines like this before IF
if (gparent == NULL){
WARN_ON(1);
// MAYBE need remove parrent that not have gparent at this place? But
i think that maybe its not have gparent becouse its lock? No so deep
look code.
continue;
}
Thanks
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* [PATCH -mm] sunrpc svc: Shut up bogus uninitialized variable warning
From: Satyam Sharma @ 2007-09-02 20:09 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Greg Banks, Olaf Kirch, David Miller, netdev
In-Reply-To: <alpine.LFD.0.999.0709022344550.27844@enigma.security.iitk.ac.in>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1467 bytes --]
net/sunrpc/svc.c: In function ‘__svc_create_thread’:
net/sunrpc/svc.c:550: warning: ‘oldmask.bits[0u]’ may be used uninitialized in this function
is a bogus warning, but gcc isn't smart enough to see why. We cannot just
reorganize the code in the function, because we want the set_cpus_allowed()
restore to happen only after the kernel_thread() is forked. Alas, we have
to use cpus_clear() to initialize oldmask instead to keep gcc happy.
Also add some comments to describe what's happening in the function.
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
net/sunrpc/svc.c | 7 +++++++
1 file changed, 7 insertions(+)
--- linux-2.6.23-rc4-mm1/net/sunrpc/svc.c~fix 2007-09-02 22:55:25.000000000 +0530
+++ linux-2.6.23-rc4-mm1/net/sunrpc/svc.c 2007-09-02 23:03:45.000000000 +0530
@@ -568,17 +568,24 @@ __svc_create_thread(svc_thread_fn func,
rqstp->rq_server = serv;
rqstp->rq_pool = pool;
+ /* Only to prevent gcc warning */
+ cpus_clear(oldmask);
+
+ /* Temporarily change CPU affinity before forking svc thread */
if (serv->sv_nrpools > 1)
have_oldmask = svc_pool_map_set_cpumask(pool->sp_id, &oldmask);
+ /* Will inherit current->cpus_allowed */
error = kernel_thread((int (*)(void *)) func, rqstp, 0);
+ /* Restore old cpus_allowed */
if (have_oldmask)
set_cpus_allowed(current, oldmask);
if (error < 0)
goto out_thread;
svc_sock_update_bufs(serv);
+
error = 0;
out:
return error;
^ permalink raw reply
* Re: potentially kernel panic on lib/rbtree.c
From: slavon @ 2007-09-02 20:18 UTC (permalink / raw)
To: slavon; +Cc: netdev
In-Reply-To: <20070902230126.bvcrzuiw1wogk40c@mail.himki.net>
Hm...
Not good.
After patch NETCONSOLE log:
---- THERE MANY MESSAGES LIKE DOWN ----
[16038.677029] WARNING: at net/sched/sch_htb.c:362 htb_safe_rb_erase()
[16038.677031] [<f8862a45>] htb_dequeue+0x13d/0x6d2 [sch_htb]
[16038.677038] [<c02a71af>] __qdisc_run+0x2a/0x16b
[16038.677043] [<c029cfc1>] dev_queue_xmit+0x18b/0x2a6
[16038.677048] [<c02b94e3>] ip_output+0x281/0x2ba
[16038.677054] [<c02b571c>] ip_forward_finish+0x0/0x2e
[16038.677059] [<c02b59b5>] ip_forward+0x26b/0x2c6
[16038.677064] [<c02b571c>] ip_forward_finish+0x0/0x2e
[16038.677070] [<c02b4729>] ip_rcv+0x484/0x4bd
[16038.677075] [<c029750b>] __netdev_alloc_skb+0x1c/0x35
[16038.677081] [<c029ab9c>] netif_receive_skb+0x2cd/0x340
[16038.677086] [<c0234ef1>] e1000_clean_rx_irq+0x379/0x448
[16038.677092] [<c0234b78>] e1000_clean_rx_irq+0x0/0x448
[16038.677097] [<c0233f8f>] e1000_clean+0x7a/0x249
[16038.677103] [<c029ccad>] net_rx_action+0x91/0x17f
[16038.677108] [<c01225e2>] __do_softirq+0x5d/0xc1
[16038.677114] [<c0122678>] do_softirq+0x32/0x36
[16038.677118] [<c010488a>] do_IRQ+0x7e/0x90
[16038.677123] [<c0111619>] smp_apic_timer_interrupt+0x74/0x80
[16038.677128] [<c02ea9d5>] __sched_text_start+0x54d/0x5ba
[16038.677134] [<c0100d65>] mwait_idle+0x0/0xa
[16038.677139] [<c01032eb>] common_interrupt+0x23/0x28
[16038.677144] [<c0100d61>] mwait_idle_with_hints+0x3b/0x3f
[16038.677149] [<c0100d65>] mwait_idle+0x0/0xa
[16038.677154] [<c0100ea4>] cpu_idle+0x91/0xaa
[16038.677159] =======================
[16038.677161] WARNING: at net/sched/sch_htb.c:362 htb_safe_rb_erase()
[16038.677163] [<f8862a45>] htb_dequeue+0x13d/0x6d2 [sch_htb]
[16038.677170] [<c02a71af>] __qdisc_run+0x2a/0x16b
[16038.677175] [<c029cfc1>] dev_queue_xmit+0x18b/0x2a6
[16038.677180] [<c02b94e3>] ip_output+0x281/0x2ba
[16038.677185] [<c02b571c>] ip_forward_finish+0x0/0x2e
[16038.677191] [<c02b59b5>] ip_forward+0x26b/0x2c6
[16038.677196] [<c02b571c>] ip_forward_finish+0x0/0x2e
[16038.677202] [<c02b4729>] ip_rcv+0x484/0x4bd
[16038.677207] [<c029750b>] __netdev_alloc_skb+0x1c/0x35
[16038.677212] [<c029ab9c>] netif_receive_skb+0x2cd/0x340
[16038.677218] [<c0234ef1>] e1000_clean_rx_irq+0x379/0x448
[16038.677224] [<c0234b78>] e1000_clean_rx_irq+0x0/0x448
[16038.677229] [<c0233f8f>] e1000_clean+0x7a/0x249
[16038.677234] [<c029ccad>] net_rx_action+0x91/0x17f
[16038.677240] [<c01225e2>] __do_softirq+0x5d/0xc1
[16038.677245] [<c0122678>] do_softirq+0x32/0x36
[16038.677250] [<c010488a>] do_IRQ+0x7e/0x90
[16038.677255] [<c0111619>] smp_apic_timer_interrupt+0x74/0x80
[16038.677260] [<c02ea9d5>] __sched_text_start+0x54d/0x5ba
[16038.677266] [<c0100d65>] mwait_idle+0x0/0xa
[16038.677270] [<c01032eb>] common_interrupt+0x23/0x28
[16038.677276] [<c0100d61>] mwait_idle_with_hints+0x3b/0x3f
[16038.677281] [<c0100d65>] mwait_idle+0x0/0xa
[16038.677285] [<c0100ea4>] cpu_idle+0x91/0xaa
[16038.677290] =======================
[16038.677293] WARNING: at net/sched/sch_htb.c:362 htb_safe_rb_erase()
[16038.677295] [<f8862a45>] htb_dequeue+0x13d/0x6d2 [sch_htb]
[16038.677301] [<c02a71af>] __qdisc_run+0x2a/0x16b
[16038.677306] [<c029cfc1>] dev_queue_xmit+0x18b/0x2a6
[16038.677312] [<c02b94e3>] ip_output+0x281/0x2ba
[16038.677317] [<c02b571c>] ip_forward_finish+0x0/0x2e
[16038.677323] [<c02b59b5>] ip_forward+0x26b/0x2c6
[16038.677328] [<c02b571c>] ip_forward_finish+0x0/0x2e
[16038.677333] [<c02b4729>] ip_rcv+0x484/0x4bd
[16038.677339] [<c029750b>] __netdev_alloc_skb+0x1c/0x35
[16038.677344] [<c029ab9c>] netif_receive_skb+0x2cd/0x340
[16038.677350] [<c0234ef1>] e1000_clean_rx_irq+0x379/0x448
[16038.677356] [<c0234b78>] e1000_clean_rx_irq+0x0/0x448
[16038.677361] [<c0233f8f>] e1000_clean+0x7a/0x249
[16038.677366] [<c029ccad>] net_rx_action+0x91/0x17f
[16038.677372] [<c01225e2>] __do_softirq+0x5d/0xc1
[16038.677377] [<c0122678>] do_softirq+0x32/0x36
[16038.677382] [<c010488a>] do_IRQ+0x7e/0x90
[16038.677387] [<c0111619>] smp_apic_timer_interrupt+0x74/0x80
[16038.677393] [<c02ea9d5>] __sched_text_start+0x54d/0x5ba
[16038.677398] [<c0100d65>] mwait_idle+0x0/0xa
[16038.677403] [<c01032eb>] common_interrupt+0x23/0x28
[16038.677408] [<c0100d61>] mwait_idle_with_hints+0x3b/0x3f
[16038.677413] [<c0100d65>] mwait_idle+0x0/0xa
[16038.677417] [<c0100ea4>] cpu_idle+0x91/0xaa
[16038.677422] =======================
[16038.677425] WARNING: at net/sched/sch_htb.c:362 htb_safe_rb_erase()
[16038.677427] [<f8862a45>] htb_dequeue+0x13d/0x6d2 [sch_htb]
[16038.677433] [<c02a71af>] __qdisc_run+0x2a/0x16b
[16038.677439] [<c029cfc1>] dev_queue_xmit+0x18b/0x2a6
[16038.677444] [<c02b94e3>] ip_output+0x281/0x2ba
[16038.677450] [<c02b571c>] ip_forward_finish+0x0/0x2e
[16038.677455] [<c02b59b5>] ip_forward+0x26b/0x2c6
[16038.677460] [<c02b571c>] ip_forward_finish+0x0/0x2e
[16038.677466] [<c02b4729>] ip_rcv+0x484/0x4bd
[16038.677471] [<c029750b>] __netdev_alloc_skb+0x1c/0x35
[16038.677476] [<c029ab9c>] netif_receive_skb+0x2cd/0x340
[16038.677482] [<c0234ef1>] e1000_clean_rx_irq+0x379/0x448
[16038.677488] [<c0234b78>] e1000_clean_rx_irq+0x0/0x448
[16038.677493] [<c0233f8f>] e1000_clean+0x7a/0x249
[16038.677498] [<c029ccad>] net_rx_action+0x91/0x17f
[16038.677504] [<c01225e2>] __do_softirq+0x5d/0xc1
[16038.677509] [<c0122678>] do_softirq+0x32/0x36
[16038.677514] [<c010488a>] do_IRQ+0x7e/0x90
[16038.677519] [<c0111619>] smp_apic_timer_interrupt+0x74/0x80
[16038.677524] [<c02ea9d5>] __sched_text_start+0x54d/0x5ba
[16038.677530] [<c0100d65>] mwait_idle+0x0/0xa
[16038.677534] [<c01032eb>] common_interrupt+0x23/0x28
[16038.677540] [<c0100d61>] mwait_idle_with_hints+0x3b/0x3f
[16038.677545] [<c0100d65>] mwait_idle+0x0/0xa
[16038.677551] [<c0100ea4>] cpu_idle+0x91/0xaa
[16038.677556] =======================
[16038.677558] WARNING: at net/sched/sch_htb.c:362 htb_safe_rb_erase()
[16038.677560] [<f8862a45>] htb_dequeue+0x13d/0x6d2 [sch_htb]
[16038.677567] [<c02a71af>] __qdisc_run+0x2a/0x16b
[16038.677573] [<c029cfc1>] dev_queue_xmit+0x18b/0x2a6
[16038.677578] [<c02b94e3>] ip_output+0x281/0x2ba
[16038.677583] [<c02b571c>] ip_forward_finish+0x0/0x2e
[16038.677589] [<c02b59b5>] ip_forward+0x26b/0x2c6
[16038.677594] [<c02b571c>] ip_forward_finish+0x0/0x2e
[16038.677599] [<c02b4729>] ip_rcv+0x484/0x4bd
--- SYSTEM IS REBOOT ---
now i try "return"
lib/rbtree.c:80
+if (gparent == NULL){
+ WARN_ON(1);
+ return;
+}
maybe "continue" not good idea....
> Sorry for prev. send =(
>
> Hi all. Have some time panic from sch_htb.c
>
> I see to gdb and see that panic at lib/rbtree.c:80
> gparent == NULL
>
> maybe add lines like this before IF
>
> if (gparent == NULL){
> WARN_ON(1);
> // MAYBE need remove parrent that not have gparent at this place? But i
> think that maybe its not have gparent becouse its lock? No so deep
> look code.
> continue;
> }
>
> Thanks
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: 2.6.23-rc4-mm1: unpingable box and NULL dereference at tcp_rto_min()
From: Andrew Morton @ 2007-09-02 20:52 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: linux-kernel, netdev, davem
In-Reply-To: <20070902023618.GA2537@martell.zuzino.mipt.ru>
> On Sun, 2 Sep 2007 06:36:19 +0400 Alexey Dobriyan <adobriyan@gmail.com> wrote:
> On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/
> > - dynticks-for-x86_64 has returned
>
> Good news is that, contary to popular belief, -mm is not horrible piece
> of crap and NO_HZ on x86_64 worked here straight away.
variable. It at least Works For Me before it goes out.
>
> The bad news is something knocked off box from the net, then panicked it:
Yeah, the net tree has been quite bad lately. Unusually bad - it's usually
one of the good ones.
It also breaks a lot of the net driver work in several other trees (I dropped
git-ixgbe.patch wholesale because of this). But there isn't a lot we can
do about that.
^ permalink raw reply
* Re: [PATCH 2/2]: [NET_SCHED]: Making rate table lookups more flexible.
From: Patrick McHardy @ 2007-09-02 21:16 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Jesper Dangaard Brouer, netdev@vger.kernel.org, David S. Miller
In-Reply-To: <Pine.LNX.4.61.0709022006380.20071@ask.diku.dk>
Jesper Dangaard Brouer wrote:
> On Sun, 2 Sep 2007, Patrick McHardy wrote:
>>
>>> This is not a ATM/ADSL only patch. This patch simply adds more
>>> flexibility to the rate tables. Afterwards we can start the discussion
>>> about how to use this new flexibility in tc/iproute2.
>>
>> I know, but that discussion should happen *before* merging any
>> changes to the kernel.
>
> Let not try to solve too many things at once. We need to do this in
> small steps. Please, lets not start long and borrowing discussion
> again, where we try to solve too many things at once.
We don't need many, but we do need *one* thing that actually
uses this and isn't controversial before merging.
>
>
>> Its pointless to add functionality that
>> won't be used afterwards or may need to be done differently.
>
> I believe that the functionality _will_ be used, also in the general
> case.
>
> Lets focus on the general case, where the functionality actually is
> needed right away.
>
> In the general case:
>
> - The rate table needs to be aligned (cell_align=-1).
> (currently, we miscalculates up to 7 bytes on every lookup)
We will always do that, thats a consequence of storing the
transmission times for multiples of 8b.
>
> - The existing tc overhead calc can be made more accurate.
> (by adding overhead before doing the lookup, instead of the
> current solution where the rate table is modified with its
> limited resolution)
Please demonstrate this with patches (one for the overhead
calculation, one for the cell_align thing), then we can
continue this discussion.
>
>
> Patrick, note that your STAB solution will _not_ work without the rate
> table alignment.
I can't argue about this without looking into it again first,
but it shouldn't really matter for now since we don't have
a patch to actually implement it.
^ permalink raw reply
* Re: 2.6.23-rc4-mm1: unpingable box and NULL dereference at tcp_rto_min()
From: Alexey Dobriyan @ 2007-09-02 21:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev, davem
In-Reply-To: <20070902135245.aed7c7a9.akpm@linux-foundation.org>
On Sun, Sep 02, 2007 at 01:52:45PM -0700, Andrew Morton wrote:
> > On Sun, 2 Sep 2007 06:36:19 +0400 Alexey Dobriyan <adobriyan@gmail.com> wrote:
> > The bad news is something knocked off box from the net, then panicked it:
>
> Yeah, the net tree has been quite bad lately. Unusually bad - it's usually
> one of the good ones.
>
> It also breaks a lot of the net driver work in several other trees (I dropped
> git-ixgbe.patch wholesale because of this). But there isn't a lot we can
> do about that.
OK, I'm currently running with "dst entry can be NULL" fix from net
tree, so far it's fine.
^ permalink raw reply
* Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
From: Michal Piotrowski @ 2007-09-02 22:15 UTC (permalink / raw)
To: Karl Meyer; +Cc: Francois Romieu, linux-kernel, netdev
In-Reply-To: <be1b757c0709011224tafebaaby697d03ab5377e20f@mail.gmail.com>
Hi,
On 01/09/07, Karl Meyer <adhocrocker@gmail.com> wrote:
> This is what happened today:
>
> Sep 1 21:08:01 frege NETDEV WATCHDOG: eth0: transmit timed out
> frege ~ # uname -r
> 2.6.22.5-cfs-v20.5
Can you reproduce this on 2.6.22 (not 2.6.22.x - it might be a -stable
regression)?
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
From: Karl Meyer @ 2007-09-02 22:21 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: Francois Romieu, linux-kernel, netdev
In-Reply-To: <6bffcb0e0709021515v586f078cjce04f877e2f27aa2@mail.gmail.com>
Hi,
am am looking for this issue for some time now, but there where no
errors in 2.6.22-r2 (gentoo speak, I guess this is 2.6.22.2
officially), I also ran git-bisect (for more information see the older
messages in this thread).
2007/9/3, Michal Piotrowski <michal.k.k.piotrowski@gmail.com>:
> Hi,
>
> On 01/09/07, Karl Meyer <adhocrocker@gmail.com> wrote:
> > This is what happened today:
> >
> > Sep 1 21:08:01 frege NETDEV WATCHDOG: eth0: transmit timed out
> > frege ~ # uname -r
> > 2.6.22.5-cfs-v20.5
>
> Can you reproduce this on 2.6.22 (not 2.6.22.x - it might be a -stable
> regression)?
>
> Regards,
> Michal
>
> --
> LOG
> http://www.stardust.webpages.pl/log/
>
^ permalink raw reply
* Re: BUG: scheduling while atomic: ifconfig/0x00000002/4170
From: Michal Piotrowski @ 2007-09-02 23:59 UTC (permalink / raw)
To: Florian Lohoff; +Cc: linux-kernel, Netdev, linux-wireless
In-Reply-To: <20070902184439.GA14306@paradigm.rfc822.org>
Hi,
[Adding netdev and wireless to CC]
On 02/09/07, Florian Lohoff <flo@rfc822.org> wrote:
>
> Hi,
> with current git i got this when "ifconfig eth1" down. eth1 had a mac
> address which looked really like an eth1394 ethernet although the module
> was not loaded. Something is really broken in 2.6.23-currentgit. I always get the
> sysfs rename issues which are discussed to be an udev issue. Then i see
> a eth1394 mac address on an interface which typically shouldn exist
> (udev should rename the wireless to eth1) and when issueing an
> ifconfig eth1 down i get a
>
> BUG: scheduling while atomic: ifconfig/0x00000002/4170
>
> On the next boot i see the eth1394 mac address on the wireless interface
> wmaster0_rename whereas eth1 is active (the wireless) and has the correct
> ip address. I dont get it - this all looks really messed up. udev is
> debian sid 114-2.
>
> eth0 Link encap:Ethernet HWaddr 00:17:42:13:45:8C
> UP BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
> Interrupt:19
>
> eth1 Link encap:Ethernet HWaddr 00:18:DE:63:F0:B3
> inet addr:195.71.97.208 Bcast:195.71.97.223 Mask:255.255.255.224
> inet6 addr: fe80::218:deff:fe63:f0b3/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:2079 errors:0 dropped:0 overruns:0 frame:0
> TX packets:2220 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:508959 (497.0 KiB) TX bytes:261123 (255.0 KiB)
>
> wmaster0_ Link encap:UNSPEC HWaddr 00-18-DE-63-F0-B3-30-3A-00-00-00-00-00-00-00-00
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
>
> [ 14.300736] VFS: Mounted root (ext3 filesystem) readonly.
> [ 14.300902] Freeing unused kernel memory: 216k freed
> [ 17.618804] irda_init()
> [ 17.618817] NET: Registered protocol family 23
> [ 17.636399] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 19
> [ 17.636588] PCI: Setting latency timer of device 0000:02:00.0 to 64
> [ 17.636619] sky2 0000:02:00.0: v1.17 addr 0xf0000000 irq 19 Yukon-EC Ultra (0xb4) rev 2
> [ 17.648081] parport_pc 00:0c: reported by Plug and Play ACPI
> [ 17.648206] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
> [ 17.653652] sky2 eth0: addr 00:17:42:13:45:8c
> [ 17.680848] input: Video Bus as /class/input/input6
> [ 17.680961] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
> [ 17.757019] usbcore: registered new interface driver usbfs
> [ 17.757139] usbcore: registered new interface driver hub
> [ 17.757264] usbcore: registered new device driver usb
> [ 17.824819] Yenta: CardBus bridge found at 0000:08:03.0 [10cf:131e]
> [ 17.824941] Yenta O2: res at 0x94/0xD4: 00/ea
> [ 17.825034] Yenta O2: enabling read prefetch/write burst
> [ 17.828363] hda: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
> [ 17.828838] Uniform CD-ROM driver Revision: 3.20
> [ 17.891481] USB Universal Host Controller Interface driver v3.0
> [ 17.891650] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 22
> [ 17.891840] PCI: Setting latency timer of device 0000:00:1d.0 to 64
> [ 17.891844] uhci_hcd 0000:00:1d.0: UHCI Host Controller
> [ 17.892155] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
> [ 17.892327] uhci_hcd 0000:00:1d.0: irq 22, io base 0x00001820
> [ 17.892571] usb usb1: configuration #1 chosen from 1 choice
> [ 17.892689] hub 1-0:1.0: USB hub found
> [ 17.892784] hub 1-0:1.0: 2 ports detected
> [ 17.924265] found SMC SuperIO Chip (devid=0x7a rev=00 base=0x002e): LPC47N227
> [ 17.924390] smsc_superio_flat(): fir: 0x6e8, sir: 0x2e8, dma: 03, irq: 3, mode: 0x0e
> [ 17.924526] smsc_ircc_present: can't get sir_base of 0x2e8
> [ 17.954918] Yenta: ISA IRQ mask 0x0c38, PCI irq 19
> [ 17.955009] Socket status: 30000006
> [ 17.955094] Yenta: Raising subordinate bus# of parent bus (#08) from #09 to #0c
> [ 17.955225] pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
> [ 17.955315] cs: IO port probe 0x3000-0x3fff: clean.
> [ 17.955773] pcmcia: parent PCI bridge Memory window: 0xf0200000 - 0xf02fffff
> [ 17.955864] pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x37ffffff
> [ 17.956497] Yenta: CardBus bridge found at 0000:08:03.1 [10cf:131e]
> [ 17.981605] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 0.1.14
> [ 17.981752] iwl3945: Copyright(c) 2003-2007 Intel Corporation
> [ 17.983847] sdhci: Secure Digital Host Controller Interface driver
> [ 17.983940] sdhci: Copyright(c) Pierre Ossman
> [ 17.998087] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 20 (level, low) -> IRQ 18
> [ 17.998299] PCI: Setting latency timer of device 0000:00:1d.1 to 64
> [ 17.998303] uhci_hcd 0000:00:1d.1: UHCI Host Controller
> [ 17.998428] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
> [ 17.998601] uhci_hcd 0000:00:1d.1: irq 18, io base 0x00001840
> [ 17.998811] usb usb2: configuration #1 chosen from 1 choice
> [ 17.998933] hub 2-0:1.0: USB hub found
> [ 17.999023] hub 2-0:1.0: 2 ports detected
> [ 18.082862] Yenta: ISA IRQ mask 0x0438, PCI irq 19
> [ 18.082956] Socket status: 30000410
> [ 18.083041] Yenta: Raising subordinate bus# of parent bus (#08) from #0c to #10
> [ 18.083169] pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
> [ 18.083255] cs: IO port probe 0x3000-0x3fff: clean.
> [ 18.083710] pcmcia: parent PCI bridge Memory window: 0xf0200000 - 0xf02fffff
> [ 18.083798] pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x37ffffff
> [ 18.105897] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 20
> [ 18.106097] PCI: Setting latency timer of device 0000:00:1d.2 to 64
> [ 18.106101] uhci_hcd 0000:00:1d.2: UHCI Host Controller
> [ 18.106218] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
> [ 18.106385] uhci_hcd 0000:00:1d.2: irq 20, io base 0x00001860
> [ 18.106594] usb usb3: configuration #1 chosen from 1 choice
> [ 18.106709] hub 3-0:1.0: USB hub found
> [ 18.106799] hub 3-0:1.0: 2 ports detected
> [ 18.213730] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 19
> [ 18.213932] PCI: Setting latency timer of device 0000:00:1d.3 to 64
> [ 18.213938] uhci_hcd 0000:00:1d.3: UHCI Host Controller
> [ 18.214052] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4
> [ 18.214210] uhci_hcd 0000:00:1d.3: irq 19, io base 0x00001880
> [ 18.214414] usb usb4: configuration #1 chosen from 1 choice
> [ 18.214529] hub 4-0:1.0: USB hub found
> [ 18.214620] hub 4-0:1.0: 2 ports detected
> [ 18.318020] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 22
> [ 18.324538] PCI: Setting latency timer of device 0000:00:1d.7 to 64
> [ 18.324544] ehci_hcd 0000:00:1d.7: EHCI Host Controller
> [ 18.324687] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
> [ 18.324857] ehci_hcd 0000:00:1d.7: debug port 1
> [ 18.324951] PCI: cache line size of 32 is not supported by device 0000:00:1d.7
> [ 18.324959] ehci_hcd 0000:00:1d.7: irq 22, io mem 0xf0644000
> [ 18.328914] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
> [ 18.329163] usb usb5: configuration #1 chosen from 1 choice
> [ 18.329282] hub 5-0:1.0: USB hub found
> [ 18.329374] hub 5-0:1.0: 8 ports detected
> [ 18.429643] ACPI: PCI Interrupt 0000:08:03.4[A] -> GSI 16 (level, low) -> IRQ 19
> [ 18.480534] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19] MMIO=[f0201000-f02017ff] Max Packet=[2048] IR/IT contexts=[8/8]
> [ 18.483902] ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 18 (level, low) -> IRQ 20
> [ 18.484135] PCI: Setting latency timer of device 0000:05:00.0 to 64
> [ 18.484153] iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
> [ 18.595000] sdhci: SDHCI controller found at 0000:08:03.2 [1217:7120] (rev 1)
> [ 18.595114] ACPI: PCI Interrupt 0000:08:03.2[A] -> GSI 16 (level, low) -> IRQ 19
> [ 18.595299] sdhci:slot0: Unknown controller version (16). You may experience problems.
> [ 18.595581] mmc0: SDHCI at 0xf0202800 irq 19 PIO
> [ 18.614800] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 17 (level, low) -> IRQ 23
> [ 18.614990] PCI: Setting latency timer of device 0000:00:1b.0 to 64
> [ 18.700659] iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> [ 18.701906] wmaster0: Selected rate control algorithm 'iwl-3945-rs'
> [ 18.721016] pccard: PCMCIA card inserted into slot 1
> [ 18.721131] cs: memory probe 0xf0200000-0xf02fffff: excluding 0xf0200000-0xf020ffff
> [ 18.739151] pcmcia: registering new device pcmcia1.0
> [ 18.740929] net eth1: device_rename: sysfs_create_symlink failed (-17)
> [ 18.741075] net wlan0_rename: device_rename: sysfs_create_symlink failed (-17)
> [ 18.741625] udev: renamed network interface wmaster0 to eth1
> [ 18.779425] cs: IO port probe 0x100-0x3af:<3>si3054: cannot initialize. EXT MID = 0000
> [ 18.783468] clean.
> [ 18.783592] cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7
> [ 18.784668] cs: IO port probe 0x820-0x8ff: clean.
> [ 18.785521] cs: IO port probe 0xc00-0xcf7: clean.
> [ 18.786456] cs: IO port probe 0xa00-0xaff: clean.
> [ 18.837550] cs: IO port probe 0x100-0x3af: clean.
> [ 18.839641] cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7
> [ 18.840664] cs: IO port probe 0x820-0x8ff: clean.
> [ 18.841501] cs: IO port probe 0xc00-0xcf7: clean.
> [ 18.842426] cs: IO port probe 0xa00-0xaff: clean.
> [ 18.964571] usb 4-2: new full speed USB device using uhci_hcd and address 2
> [ 19.141976] usb 4-2: configuration #1 chosen from 1 choice
> [ 19.214394] Bluetooth: Core ver 2.11
> [ 19.214546] NET: Registered protocol family 31
> [ 19.214640] Bluetooth: HCI device and connection manager initialized
> [ 19.214737] Bluetooth: HCI socket layer initialized
> [ 19.257180] Bluetooth: HCI USB driver ver 2.9
> [ 19.257349] usbcore: registered new interface driver hci_usb
> [ 19.751313] ieee1394: Host added: ID:BUS[0-00:1023] GUID[00000e10036532e4]
> [ 50.113619] Adding 979924k swap on /dev/sda5. Priority:-1 extents:1 across:979924k
> [ 50.163229] EXT3 FS on sda6, internal journal
> [ 64.870417] NET: Registered protocol family 10
> [ 64.870613] lo: Disabled Privacy Extensions
> [ 71.028607] Bluetooth: L2CAP ver 2.8
> [ 71.028615] Bluetooth: L2CAP socket layer initialized
> [ 71.168926] Bluetooth: RFCOMM socket layer initialized
> [ 71.169019] Bluetooth: RFCOMM TTY layer initialized
> [ 71.169054] Bluetooth: RFCOMM ver 1.8
> [ 71.539346] ADDRCONF(NETDEV_UP): wlan0_rename: link is not ready
> [ 71.737809] sky2 eth0: enabling interface
> [ 71.740794] sky2 eth0: ram buffer 0K
> [ 71.741733] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 142.968449] wlan0_rename: Initial auth_alg=0
> [ 142.968461] wlan0_rename: authenticate with AP 00:0c:41:de:12:e1
> [ 142.976883] wlan0_rename: RX authentication from 00:0c:41:de:12:e1 (alg=0 transaction=2 status=0)
> [ 142.976891] wlan0_rename: authenticated
> [ 142.976895] wlan0_rename: associate with AP 00:0c:41:de:12:e1
> [ 142.979389] wlan0_rename: authentication frame received from 00:0c:41:de:12:e1, but not in authenticate state - ignored
> [ 142.980404] wlan0_rename: RX AssocResp from 00:0c:41:de:12:e1 (capab=0x401 status=0 aid=1)
> [ 142.980412] wlan0_rename: associated
> [ 142.982914] ADDRCONF(NETDEV_CHANGE): wlan0_rename: link becomes ready
> [ 148.291754] ICMPv6 NA: someone advertises our address on wlan0_rename!
> [ 151.386585] wlan0_rename: duplicate address detected!
> [ 382.517007] BUG: scheduling while atomic: ifconfig/0x00000002/4170
> [ 382.517029] [<c032bf5c>] __sched_text_start+0x84/0x71c
> [ 382.517047] [<c032c5da>] __sched_text_start+0x702/0x71c
> [ 382.517065] [<c0174a6c>] link_path_walk+0xa9/0xb3
> [ 382.517079] [<c032c6ad>] wait_for_completion+0x65/0x9b
> [ 382.517090] [<c011f0a2>] default_wake_function+0x0/0xc
> [ 382.517103] [<c01334cf>] synchronize_rcu+0x2a/0x2f
> [ 382.517115] [<c0133091>] wakeme_after_rcu+0x0/0x8
> [ 382.517127] [<c02d5f4f>] dev_deactivate+0x89/0x9c
> [ 382.517138] [<c02c8abc>] dev_close+0x24/0x67
> [ 382.517150] [<e01f402b>] ieee80211_master_stop+0x4a/0x6d [mac80211]
> [ 382.517176] [<c02c8ae3>] dev_close+0x4b/0x67
> [ 382.517183] [<c02c7f47>] dev_change_flags+0x9d/0x14e
> [ 382.517193] [<c03058c8>] devinet_ioctl+0x224/0x532
> [ 382.517201] [<c02c9589>] dev_ifsioc+0x113/0x396
> [ 382.517208] [<c02c8d59>] dev_load+0x24/0x4b
> [ 382.517214] [<c02be61d>] sock_ioctl+0x0/0x1be
> [ 382.517233] [<c02be7bc>] sock_ioctl+0x19f/0x1be
> [ 382.517239] [<c011a993>] do_page_fault+0x269/0x58e
> [ 382.517246] [<c02be61d>] sock_ioctl+0x0/0x1be
> [ 382.517254] [<c0176787>] do_ioctl+0x1f/0x62
> [ 382.517263] [<c0176a01>] vfs_ioctl+0x237/0x249
> [ 382.517270] [<c016b7d8>] do_sys_open+0xbb/0xc5
> [ 382.517280] [<c0176a46>] sys_ioctl+0x33/0x4d
> [ 382.517288] [<c0103e52>] sysenter_past_esp+0x5f/0x85
> [ 382.517303] =======================
> [ 382.528958] BUG: scheduling while atomic: ifconfig/0x00000002/4170
> [ 382.528972] [<c032bf5c>] __sched_text_start+0x84/0x71c
> [ 382.528996] [<c032c6ad>] wait_for_completion+0x65/0x9b
> [ 382.529005] [<c011f0a2>] default_wake_function+0x0/0xc
> [ 382.529014] [<c01334cf>] synchronize_rcu+0x2a/0x2f
> [ 382.529021] [<c0133091>] wakeme_after_rcu+0x0/0x8
> [ 382.529031] [<c02d5f4f>] dev_deactivate+0x89/0x9c
> [ 382.529041] [<c02c8abc>] dev_close+0x24/0x67
> [ 382.529052] [<e01f402b>] ieee80211_master_stop+0x4a/0x6d [mac80211]
> [ 382.529077] [<c02c8ae3>] dev_close+0x4b/0x67
> [ 382.529088] [<c02c7f47>] dev_change_flags+0x9d/0x14e
> [ 382.529101] [<c03058c8>] devinet_ioctl+0x224/0x532
> [ 382.529111] [<c02c9589>] dev_ifsioc+0x113/0x396
> [ 382.529122] [<c02c8d59>] dev_load+0x24/0x4b
> [ 382.529132] [<c02be61d>] sock_ioctl+0x0/0x1be
> [ 382.529153] [<c02be7bc>] sock_ioctl+0x19f/0x1be
> [ 382.529164] [<c011a993>] do_page_fault+0x269/0x58e
> [ 382.529174] [<c02be61d>] sock_ioctl+0x0/0x1be
> [ 382.529187] [<c0176787>] do_ioctl+0x1f/0x62
> [ 382.529201] [<c0176a01>] vfs_ioctl+0x237/0x249
> [ 382.529211] [<c016b7d8>] do_sys_open+0xbb/0xc5
> [ 382.529224] [<c0176a46>] sys_ioctl+0x33/0x4d
> [ 382.529235] [<c0103e52>] sysenter_past_esp+0x5f/0x85
> [ 382.529253] =======================
> [ 382.530962] Freeing alive inet6 address cd98f600
> --
> Florian Lohoff flo@rfc822.org +49-171-2280134
> Those who would give up a little freedom to get a little
> security shall soon have neither - Benjamin Franklin
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFG2wSWUaz2rXW+gJcRAq/8AKCEqN8Vylr12kRU9es5Y0K6vPNIXwCg0AnS
> tqx3+KmEGpVapGtzj8z3r1M=
> =EYJK
> -----END PGP SIGNATURE-----
>
>
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* [PATCH 3/3] netxen: ethtool fixes
From: Dhananjay Phadke @ 2007-09-03 5:03 UTC (permalink / raw)
To: netdev; +Cc: jeff, rob
Resubmitting the patch.
This patch improves ethtool support for printing correct ring statistics,
segmentation offload status, etc.
Signed-off by: Dhananjay Phadke <dhananjay@netxen.com>
Index: netdev-2.6/drivers/net/netxen/netxen_nic.h
===================================================================
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic.h
+++ netdev-2.6/drivers/net/netxen/netxen_nic.h
@@ -918,7 +918,7 @@ struct netxen_adapter {
u16 link_duplex;
u16 state;
u16 link_autoneg;
- int rcsum;
+ int rx_csum;
int status;
spinlock_t stats_lock;
Index: netdev-2.6/drivers/net/netxen/netxen_nic_ethtool.c
===================================================================
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_ethtool.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_ethtool.c
@@ -518,17 +518,17 @@ netxen_nic_get_ringparam(struct net_devi
ring->rx_jumbo_pending = 0;
for (i = 0; i < MAX_RCV_CTX; ++i) {
ring->rx_pending += adapter->recv_ctx[i].
- rcv_desc[RCV_DESC_NORMAL_CTXID].rcv_pending;
+ rcv_desc[RCV_DESC_NORMAL_CTXID].max_rx_desc_count;
ring->rx_jumbo_pending += adapter->recv_ctx[i].
- rcv_desc[RCV_DESC_JUMBO_CTXID].rcv_pending;
+ rcv_desc[RCV_DESC_JUMBO_CTXID].max_rx_desc_count;
}
+ ring->tx_pending = adapter->max_tx_desc_count;
- ring->rx_max_pending = adapter->max_rx_desc_count;
- ring->tx_max_pending = adapter->max_tx_desc_count;
- ring->rx_jumbo_max_pending = adapter->max_jumbo_rx_desc_count;
+ ring->rx_max_pending = MAX_RCV_DESCRIPTORS;
+ ring->tx_max_pending = MAX_CMD_DESCRIPTORS_HOST;
+ ring->rx_jumbo_max_pending = MAX_JUMBO_RCV_DESCRIPTORS;
ring->rx_mini_max_pending = 0;
ring->rx_mini_pending = 0;
- ring->rx_jumbo_pending = 0;
}
static void
@@ -731,6 +731,19 @@ netxen_nic_get_ethtool_stats(struct net_
}
}
+static u32 netxen_nic_get_rx_csum(struct net_device *dev)
+{
+ struct netxen_adapter *adapter = netdev_priv(dev);
+ return adapter->rx_csum;
+}
+
+static int netxen_nic_set_rx_csum(struct net_device *dev, u32 data)
+{
+ struct netxen_adapter *adapter = netdev_priv(dev);
+ adapter->rx_csum = !!data;
+ return 0;
+}
+
struct ethtool_ops netxen_nic_ethtool_ops = {
.get_settings = netxen_nic_get_settings,
.set_settings = netxen_nic_set_settings,
@@ -755,4 +768,7 @@ struct ethtool_ops netxen_nic_ethtool_op
.get_strings = netxen_nic_get_strings,
.get_stats_count = netxen_nic_get_stats_count,
.get_ethtool_stats = netxen_nic_get_ethtool_stats,
+ .get_rx_csum = netxen_nic_get_rx_csum,
+ .set_rx_csum = netxen_nic_set_rx_csum,
+ .get_ufo = ethtool_op_get_ufo,
};
Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c
===================================================================
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c
@@ -408,6 +408,7 @@ netxen_nic_probe(struct pci_dev *pdev, c
/* This will be reset for mezz cards */
adapter->portnum = pci_func_id;
adapter->status &= ~NETXEN_NETDEV_STATUS;
+ adapter->rx_csum = 1;
netdev->open = netxen_nic_open;
netdev->stop = netxen_nic_close;
Index: netdev-2.6/drivers/net/netxen/netxen_nic_init.c
===================================================================
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_init.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_init.c
@@ -1118,10 +1118,13 @@ netxen_process_rcv(struct netxen_adapter
skb = (struct sk_buff *)buffer->skb;
- if (likely(netxen_get_sts_status(desc) == STATUS_CKSUM_OK)) {
+ if (likely(adapter->rx_csum &&
+ netxen_get_sts_status(desc) == STATUS_CKSUM_OK)) {
adapter->stats.csummed++;
skb->ip_summed = CHECKSUM_UNNECESSARY;
- }
+ } else
+ skb->ip_summed = CHECKSUM_NONE;
+
skb->dev = netdev;
if (desc_ctx == RCV_DESC_LRO_CTXID) {
/* True length was only available on the last pkt */
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Jarek Poplawski @ 2007-09-03 7:31 UTC (permalink / raw)
To: Badalian Vyacheslav; +Cc: netdev
In-Reply-To: <46D82AEC.5010404@bigtelecom.ru>
On Fri, Aug 31, 2007 at 06:51:24PM +0400, Badalian Vyacheslav wrote:
> I found that bug in this place
>
> (gdb) l *0xc01c8973
> 0xc01c8973 is in rb_insert_color (lib/rbtree.c:80).
...
> if i not wrong understand message "unable to handle kernel NULL pointer
> dereference at virtual address 00000008" its was known that "gparent ==
> Null"?
> Or i hope or i try find a mare's-nest?
Your errors trigger in rbtree, which does indexing for HTB, but since
it's something quite rare I think there is a very small probability
that it's caused by HTB class/level handling (but it's possible, too),
but more probable (to me) these indexes are corrupted by something e.g.
like accessing them without proper locking.
Below I attach a patch for testing: it adds some lock debugging (plus
one place: htb_put is locked). There is mainly checking of locks
needed for writing to rbtree, but it doesn't check all readings yet,
so there will be still something to check if this patch doesn't help
to find anything.
It should be applied to 2.6.23-rc4, but if you prefer 2.6.22.5 version
let me know (BTW, I hope you let us know if you have to apply any
other patches/changes to these kernels...).
>
> >Ok =) I hope in next week you found bug place and fix it!
> >
> >PS. if you ask where i can read "kernel panic dump logic" literature
> >and try find bugline in code.
> >I read dump and see that bug in function "rb_insert_color" + some
> >shift (in asm?) that called from htb_dequeue? But in htb_dequeue not
> >have calling rb_insert_color =( Or some nodes in trace was skipped?
> >
> >Its for change up my education ;)
I didn't learn much about this, but usually objdump is enough for me.
Here are some links for kernel education:
http://kernelnewbies.org/
http://www.tux.org/lkml/
http://en.tldp.org/LDP/khg/HyperNews/get/khg.html
http://www.stardust.webpages.pl/files/handbook/tmp-en/
Regards,
Jarek P.
---
diff -Nurp linux-2.6.23-rc4-/net/sched/sch_htb.c linux-2.6.23-rc4/net/sched/sch_htb.c
--- linux-2.6.23-rc4-/net/sched/sch_htb.c 2007-08-28 19:52:25.000000000 +0200
+++ linux-2.6.23-rc4/net/sched/sch_htb.c 2007-09-02 10:34:39.000000000 +0200
@@ -52,6 +52,7 @@
one less than their parent.
*/
+#define DEBUG_HTB
#define HTB_HSIZE 16 /* classid hash size */
#define HTB_HYSTERESIS 1 /* whether to use mode hysteresis for speedup */
#define HTB_VER 0x30011 /* major must be matched with number suplied by TC as version */
@@ -127,6 +128,9 @@ struct htb_class {
int prio; /* For parent to leaf return possible here */
int quantum; /* we do backup. Finally full replacement */
/* of un.leaf originals should be done. */
+#ifdef DEBUG_HTB
+ struct Qdisc *sch;
+#endif
};
static inline long L2T(struct htb_class *cl, struct qdisc_rate_table *rate,
@@ -175,6 +179,23 @@ struct htb_sched {
long direct_pkts;
};
+#ifdef DEBUG_HTB
+static inline int htb_queue_locked(struct htb_class *cl)
+{
+ if (cl->sch) {
+ if (!spin_is_locked(&cl->sch->dev->queue_lock) ||
+ !in_softirq()) {
+ cl->sch = NULL;
+ return 0;
+ }
+ }
+ return 1;
+}
+#define DEBUG_QUEUE_LOCKED(cl) WARN_ON(!htb_queue_locked(cl))
+#else
+#define DEBUG_QUEUE_LOCKED(dev) do { } while (0)
+#endif
+
/* compute hash of size HTB_HSIZE for given handle */
static inline int htb_hash(u32 h)
{
@@ -280,6 +301,7 @@ static void htb_add_to_id_tree(struct rb
{
struct rb_node **p = &root->rb_node, *parent = NULL;
+ DEBUG_QUEUE_LOCKED(cl);
while (*p) {
struct htb_class *c;
parent = *p;
@@ -306,6 +328,7 @@ static void htb_add_to_wait_tree(struct
{
struct rb_node **p = &q->wait_pq[cl->level].rb_node, *parent = NULL;
+ DEBUG_QUEUE_LOCKED(cl);
cl->pq_key = q->now + delay;
if (cl->pq_key == q->now)
cl->pq_key++;
@@ -378,6 +401,7 @@ static inline void htb_remove_class_from
{
int m = 0;
+ DEBUG_QUEUE_LOCKED(cl);
while (mask) {
int prio = ffz(~mask);
@@ -438,6 +462,7 @@ static void htb_deactivate_prios(struct
struct htb_class *p = cl->parent;
long m, mask = cl->prio_activity;
+ DEBUG_QUEUE_LOCKED(cl);
while (cl->cmode == HTB_MAY_BORROW && p && mask) {
m = mask;
mask = 0;
@@ -668,6 +693,7 @@ static void htb_charge_class(struct htb_
if (toks <= -cl->mbuffer) toks = 1-cl->mbuffer; \
cl->T = toks
+ DEBUG_QUEUE_LOCKED(cl);
while (cl) {
diff = psched_tdiff_bounded(q->now, cl->t_c, cl->mbuffer);
if (cl->level >= level) {
@@ -724,6 +750,7 @@ static psched_time_t htb_do_events(struc
if (cl->pq_key > q->now)
return cl->pq_key;
+ DEBUG_QUEUE_LOCKED(cl);
htb_safe_rb_erase(p, q->wait_pq + level);
diff = psched_tdiff_bounded(q->now, cl->t_c, cl->mbuffer);
htb_change_class_mode(q, cl, &diff);
@@ -822,6 +849,7 @@ static struct sk_buff *htb_dequeue_tree(
start = cl = htb_lookup_leaf(q->row[level] + prio, prio,
q->ptr[level] + prio,
q->last_ptr_id[level] + prio);
+ DEBUG_QUEUE_LOCKED(cl);
do {
next:
@@ -1197,6 +1225,7 @@ static void htb_destroy_class(struct Qdi
{
struct htb_sched *q = qdisc_priv(sch);
+ DEBUG_QUEUE_LOCKED(cl);
if (!cl->level) {
BUG_TRAP(cl->un.leaf.q);
qdisc_destroy(cl->un.leaf.q);
@@ -1291,8 +1320,11 @@ static void htb_put(struct Qdisc *sch, u
{
struct htb_class *cl = (struct htb_class *)arg;
- if (--cl->refcnt == 0)
+ if (--cl->refcnt == 0) {
+ sch_tree_lock(sch);
htb_destroy_class(sch, cl);
+ sch_tree_unlock(sch);
+ }
}
static int htb_change_class(struct Qdisc *sch, u32 classid,
@@ -1367,6 +1399,9 @@ static int htb_change_class(struct Qdisc
for (prio = 0; prio < TC_HTB_NUMPRIO; prio++)
RB_CLEAR_NODE(&cl->node[prio]);
+#ifdef DEBUG_HTB
+ cl->sch = sch;
+#endif
/* create leaf qdisc early because it uses kmalloc(GFP_KERNEL)
so that can't be used inside of sch_tree_lock
-- thanks to Karlis Peisenieks */
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Badalian Vyacheslav @ 2007-09-03 8:05 UTC (permalink / raw)
To: Jarek Poplawski, netdev
In-Reply-To: <20070903073059.GA1899@ff.dom.local>
> Your errors trigger in rbtree, which does indexing for HTB, but since
> it's something quite rare I think there is a very small probability
> that it's caused by HTB class/level handling (but it's possible, too),
> but more probable (to me) these indexes are corrupted by something e.g.
> like accessing them without proper locking.
>
> Below I attach a patch for testing: it adds some lock debugging (plus
> one place: htb_put is locked). There is mainly checking of locks
> needed for writing to rbtree, but it doesn't check all readings yet,
> so there will be still something to check if this patch doesn't help
> to find anything.
>
> It should be applied to 2.6.23-rc4, but if you prefer 2.6.22.5 version
> let me know (BTW, I hope you let us know if you have to apply any
> other patches/changes to these kernels...).
>
>
Ok... i was apply patch and see that its say... thanks...
Maybe you see bug 2 (wrong level calculation) and 3 (class not leaf but
have qdisc) at
http://bugzilla.kernel.org/show_bug.cgi?id=8971
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Badalian Vyacheslav @ 2007-09-03 8:31 UTC (permalink / raw)
To: Jarek Poplawski, netdev
In-Reply-To: <46DBC059.5020405@bigtelecom.ru>
May you also see that i need change to fix this:
qdisc handle can >= 10 000
i have more then 10 000 qdiscs =(
^ permalink raw reply
* Re: [Bugme-new] [Bug 8971] New: htb class delete causes kernelpanic and other htb bugs.
From: Andrew Morton @ 2007-09-03 8:34 UTC (permalink / raw)
To: netdev; +Cc: bugme-daemon, lavon
In-Reply-To: <bug-8971-10286@http.bugzilla.kernel.org/>
> On Mon, 3 Sep 2007 00:29:48 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8971
>
> Summary: htb class delete causes kernelpanic and other htb bugs.
> Product: Networking
> Version: 2.5
> KernelVersion: 2.6.18.* - 2.6.23-rc4
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@osdl.org
> ReportedBy: slavon@bigtelecom.ru
>
>
> 1. sometime get kernel panic on "htb class delete"
>
> 3931.002707] BUG: unable to handle kernel NULL pointer dereference at virtual
> address 00000008
> [ 3931.002846] printing eip:
> [ 3931.002906] c01c8973
> [ 3931.002967] *pde = 00000000
> [ 3931.003031] Oops: 0000 [#1]
> [ 3931.003093] SMP
> [ 3931.003160] Modules linked in: cls_u32 sch_sfq sch_htb netconsole xt_tcpudp
> iptable_filter ip_tables x_tables i2c_i801 i2c_core
> [ 3931.003327] CPU: 2
> [ 3931.003327] EIP: 0060:[<c01c8973>] Not tainted VLI
> [ 3931.003328] EFLAGS: 00010246 (2.6.23-rc4-testing #1)
> [ 3931.003526] EIP is at rb_insert_color+0x13/0xad
> [ 3931.003594] eax: 00000000 ebx: e9570324 ecx: e9570324 edx: f6deac48
> [ 3931.003663] esi: 00000000 edi: ef5c4124 ebp: f6dea8a0 esp: e25f5d6c
> [ 3931.003731] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
> [ 3931.003796] Process sh (pid: 6146, ti=e25f4000 task=c268b290
> task.ti=e25f4000)
> [ 3931.003866] Stack: f6deac48 00000569 00000000 ef5c4000 f6dea8a0 f8862a9d
> f881c5db e1fda780
> [ 3931.004016] 00000003 f6db6dc0 f6deac48 f6dea800 00000000 00000000
> dfc3e9b2 00000000
> [ 3931.004161] e25f5dd8 00000000 c02a774b 00000002 e25f5e70 f6dea930
> f6dea930 00000000
> [ 3931.004307] Call Trace:
> [ 3931.004434] [<f8862a9d>] htb_dequeue+0x195/0x6d2 [sch_htb]
> [ 3931.004510] [<f881c5db>] ipt_do_table+0x41f/0x47c [ip_tables]
> [ 3931.004584] [<c02a774b>] tc_classify+0x17/0x7c
> [ 3931.004658] [<f8861925>] htb_activate_prios+0x9b/0xa5 [sch_htb]
> [ 3931.004730] [<c02a71af>] __qdisc_run+0x2a/0x16b
> [ 3931.004798] [<c029cfc1>] dev_queue_xmit+0x18b/0x2a6
> [ 3931.004874] [<c02b94e3>] ip_output+0x281/0x2ba
> [ 3931.004947] [<c02b571c>] ip_forward_finish+0x0/0x2e
> [ 3931.005012] [<c02b59b5>] ip_forward+0x26b/0x2c6
> [ 3931.005081] [<c02b571c>] ip_forward_finish+0x0/0x2e
> [ 3931.005150] [<c02b4729>] ip_rcv+0x484/0x4bd
> [ 3931.005216] [<c013dcc5>] file_read_actor+0x0/0xdb
> [ 3931.005293] [<c029ab9c>] netif_receive_skb+0x2cd/0x340
> [ 3931.005362] [<c0234ef1>] e1000_clean_rx_irq+0x379/0x448
> [ 3931.005437] [<c0234b78>] e1000_clean_rx_irq+0x0/0x448
> [ 3931.005506] [<c0233f8f>] e1000_clean+0x7a/0x249
> [ 3931.005574] [<c029ccad>] net_rx_action+0x91/0x17f
> [ 3931.005642] [<c01225e2>] __do_softirq+0x5d/0xc1
> [ 3931.005714] [<c0122678>] do_softirq+0x32/0x36
> [ 3931.005779] [<c010488a>] do_IRQ+0x7e/0x90
> [ 3931.005849] [<c01032eb>] common_interrupt+0x23/0x28
> [ 3931.005923] =======================
> [ 3931.005986] Code: 56 04 eb 07 89 56 08 eb 02 89 17 8b 03 83 e0 03 09 d0 89
> 03 5b 5e 5f c3 55 57 89 c7 56 53 83 ec 04 89 14 24 eb 7e 89 c6 83 e6 fc <8b> 56
> 08 39 d3 75 34 8b 56 04 85 d2 74 06 8b 02 a8 01 74 31 8b
> [ 3931.006386] EIP: [<c01c8973>] rb_insert_color+0x13/0xad SS:ESP 0068:e25f5d6c
> [ 3931.006757] Kernel panic - not syncing: Fatal exception in interrupt
> [ 3931.006863] Rebooting in 3 seconds..
>
> its becouse
>
> (gdb) l *0xc01c8973
> 0xc01c8973 is in rb_insert_color (lib/rbtree.c:80).
> 75
> 76 while ((parent = rb_parent(node)) && rb_is_red(parent))
> 77 {
> 78 gparent = rb_parent(parent);
> 79
> 80 if (parent == gparent->rb_left)
> 81 {
> 82 {
> 83 register struct rb_node *uncle =
> gparent->rb_right;
> 84 if (uncle && rb_is_red(uncle))
>
> gparent == NULL
>
> 2. HTB levels wrong calculate!
> Try run
> tc qdisc add dev eth1 root handle 1 htb default 7
> tc class add dev eth1 parent 1: classid 1:2 htb rate 400mbit ceil 400mbit
> burst 50kb cburst 50kb prio 0
> # max prio ICMP - NOT USED
> tc class add dev eth1 parent 1:2 classid 1:3 htb rate 10mbit ceil
> 10mbit burst 1250b cburst 1250b prio 0
> tc qdisc add dev eth1 parent 1:3 handle 3 sfq perturb 10
> # corp - NOT USED
> tc class add dev eth1 parent 1:2 classid 1:4 htb rate 50mbit ceil
> 50mbit burst 6250b cburst 6250b prio 1
> tc qdisc add dev eth1 parent 1:4 handle 4 sfq perturb 10
> # general
> tc class add dev eth1 parent 1:2 classid 1:5 htb rate 340mbit ceil
> 400mbit burst 42500b cburst 50kb prio 2
> # LIDER
> tc class add dev eth1 parent 1:5 classid 1:6 htb rate 9mbit ceil
> 9mbit burst 1125b cburst 1125b prio 1
> #....
>
> # GENERAL
> tc class add dev eth1 parent 1:5 classid 1:7 htb rate 100mbit ceil
> 400mbit burst 12500b cburst 50kb prio 2
> tc qdisc add dev eth1 parent 1:7 handle 7 sfq perturb 10
>
> # limiting speed
> tc class add dev eth1 parent 1:5 classid 1:8 htb rate 231mbit ceil
> 400mbit burst 23100b cburst 50kb prio 1
> #....
>
>
> and see levels
> tc -d class show dev eth0
>
> 3. "tc -d class show dev eth0 | grep -v leaf" ask many rules without leaf, but
> QDISC for this classes is created. (run create_nodes.sh; sh tc_last_rules)
>
^ permalink raw reply
* possibly dead CONFIG variables, perhaps fixable for 2.6.23?
From: Robert P. J. Day @ 2007-09-03 8:34 UTC (permalink / raw)
To: netdev
profuse, grovelling apologies in advance:
normally, i would have waited until after the updates in the merge
window after 2.6.23 since i know cleanups for some of what follows are
in the queue, but there are at least a couple odd-looking variables
here that i thought i'd post the results of my scanning script, just
in case any of these represent actual errors or typoes someone might
want to fix and sneak in before 2.6.23.
(caveat: fairly dumb script that generates false positives, such as
when people use hard-coded macro names that begin with "CONFIG_", but
since it's not *obscenely* lengthy, i'll just post it as is. what
anyone chooses to do with this is entirely their call. enjoy.)
drivers/net/:
========== 440GR ==========
drivers/net/ibm_emac/ibm_emac_core.c:88: (defined(CONFIG_405EP) || defined(CONFIG_440EP) || defined(CONFIG_440GR))
drivers/net/ibm_emac/ibm_emac_core.c:101:#else /* CONFIG_440EP || CONFIG_440GR */
drivers/net/ibm_emac/ibm_emac_mal.h:35: defined(CONFIG_440EP) || defined(CONFIG_440GR) || defined(CONFIG_NP405H)
drivers/net/ibm_emac/ibm_emac.h:29: !defined(CONFIG_440GR)
drivers/net/Kconfig:1294: depends on IBM_EMAC && (405EP || 440GX || 440EP || 440GR)
drivers/net/ibm_emac/ibm_emac_core.c:91: * 440EP/440GR has more sane SDR0_MFR register implementation than 440GX, which
========== ARCH_INNOKOM ==========
drivers/net/smc91x.h:194:#elif defined(CONFIG_ARCH_INNOKOM) || \
arch/arm/tools/mach-types:275:innokom ARCH_INNOKOM INNOKOM 258
========== ARCH_PNX010X ==========
drivers/net/cs89x0.c:190:#elif defined(CONFIG_ARCH_PNX010X)
drivers/net/cs89x0.c:377:#elif defined(CONFIG_ARCH_PNX010X)
drivers/net/cs89x0.c:537:#ifdef CONFIG_ARCH_PNX010X
drivers/net/cs89x0.c:805:#if defined(CONFIG_MACH_IXDP2351) || defined(CONFIG_ARCH_IXDP2X01) || defined(CONFIG_ARCH_PNX010X)
drivers/net/cs89x0.c:1280:#if !defined(CONFIG_SH_HICOSH4) && !defined(CONFIG_ARCH_PNX010X) /* uses irq#1, so this won't work */
drivers/net/cs89x0.c:1311:#if !defined(CONFIG_MACH_IXDP2351) && !defined(CONFIG_ARCH_IXDP2X01) && !defined(CONFIG_ARCH_PNX010X)
drivers/net/cs89x0.c:1396:#ifdef CONFIG_ARCH_PNX010X
drivers/net/Kconfig:1499: depends on NET_PCI && (ISA || MACH_IXDP2351 || ARCH_IXDP2X01 || ARCH_PNX010X)
========== ARCH_RAMSES ==========
drivers/net/smc91x.h:197: defined(CONFIG_ARCH_RAMSES)
arch/arm/tools/mach-types:252:mnci ARCH_RAMSES RAMSES 235
========== CASSINI_MULTICAST_REG_WRITE ==========
drivers/net/cassini.c:3099:#ifdef CONFIG_CASSINI_MULTICAST_REG_WRITE
drivers/net/cassini.c:3169:#ifndef CONFIG_CASSINI_MULTICAST_REG_WRITE
========== CASSINI_NAPI ==========
drivers/net/cassini.c:107:#if defined(CONFIG_CASSINI_NAPI) && defined(HAVE_NETDEV_POLL)
========== CASSINI_QGE_DEBUG ==========
drivers/net/cassini.h:4362:#ifdef CONFIG_CASSINI_QGE_DEBUG
========== CHELSIO_T1_COUGAR ==========
drivers/net/chelsio/subr.c:188:#ifdef CONFIG_CHELSIO_T1_COUGAR
drivers/net/chelsio/subr.c:283:#if defined(CONFIG_CHELSIO_T1_1G) || defined(CONFIG_CHELSIO_T1_COUGAR)
drivers/net/chelsio/subr.c:323:#if defined(CONFIG_CHELSIO_T1_1G) || defined(CONFIG_CHELSIO_T1_COUGAR)
drivers/net/chelsio/subr.c:750:#ifdef CONFIG_CHELSIO_T1_COUGAR
drivers/net/chelsio/subr.c:1002:#ifdef CONFIG_CHELSIO_T1_COUGAR
drivers/net/chelsio/subr.c:1059:#ifdef CONFIG_CHELSIO_T1_COUGAR
drivers/net/chelsio/subr.c:1082:#ifdef CONFIG_CHELSIO_T1_COUGAR
========== DUET ==========
drivers/net/fs_enet/mac-fec.c:252:#ifdef CONFIG_DUET
drivers/net/fs_enet/mac-fec.c:329:#ifdef CONFIG_DUET
drivers/net/fec_8xx/fec_main.c:237:#ifdef CONFIG_DUET
drivers/net/fec_8xx/fec_main.c:363:#ifdef CONFIG_DUET
drivers/net/fec_8xx/fec_main.c:1087:#ifdef CONFIG_DUET
arch/powerpc/platforms/8xx/Kconfig:30: Also known as DUET.
arch/ppc/Kconfig:412: Also known as DUET.
drivers/net/fs_enet/mac-fec.c:327: * adjust to speed (only for DUET & RMII)
drivers/net/fec_8xx/fec_main.c:361: * adjust to speed (only for DUET & RMII)
include/asm-mips/pmc-sierra/msp71xx/msp_prom.h:50:#define MACHINE_TYPE_DUET "DUET"
include/asm-mips/pmc-sierra/msp71xx/msp_prom.h:60:#define MACHINE_TYPE_DUET_FPGA "DUET-FPGA"
include/asm-mips/pmc-sierra/msp71xx/msp_prom.h:114:#define TDM_DUET 'D' /* DUET TDMs might exist */
include/asm-mips/pmc-sierra/msp71xx/msp_prom.h:118:#define ZSP_DUET 'D' /* one DUET zsp engine */
include/asm-ppc/8xx_immap.h:530: /* The DUET family has a second FEC here */
========== ETRAX_NETWORK_RED_ON_NO_CONNECTION ==========
drivers/net/cris/eth_v10.c:1783:#if defined(CONFIG_ETRAX_NETWORK_RED_ON_NO_CONNECTION)
========== FIXED_MII_DUPLEX ==========
drivers/net/phy/fixed.c:339:#ifdef CONFIG_FIXED_MII_DUPLEX
========== GILBARCONAP ==========
drivers/net/fec.c:100:#elif defined(CONFIG_GILBARCONAP) || defined(CONFIG_SCALES)
========== LMC_IGNORE_HARDWARE_HANDSHAKE ==========
drivers/net/wan/lmc/lmc_media.c:32:#define CONFIG_LMC_IGNORE_HARDWARE_HANDSHAKE 1
drivers/net/wan/lmc/lmc_media.c:742:#ifdef CONFIG_LMC_IGNORE_HARDWARE_HANDSHAKE
========== MACH_LPD79520 ==========
drivers/net/smc91x.h:331:#elif defined(CONFIG_MACH_LPD79520) \
arch/arm/tools/mach-types:553:lpd79520 MACH_LPD79520 LPD79520 537
arch/arm/mach-lh7a40x/lcd-panel.h:40:#if defined (MACH_LPD79520)\
========== NETWINDER_RX_DMA_PROBLEMS ==========
drivers/net/irda/w83977af_ir.c:66:#define CONFIG_NETWINDER_RX_DMA_PROBLEMS /* Must have this one! */
drivers/net/irda/w83977af_ir.c:741:#ifdef CONFIG_NETWINDER_RX_DMA_PROBLEMS
drivers/net/irda/w83977af_ir.c:766:#ifdef CONFIG_NETWINDER_RX_DMA_PROBLEMS
drivers/net/irda/w83977af_ir.c:789:#ifdef CONFIG_NETWINDER_RX_DMA_PROBLEMS
========== NETWINDER_TX_DMA_PROBLEMS ==========
drivers/net/irda/w83977af_ir.c:65:#undef CONFIG_NETWINDER_TX_DMA_PROBLEMS /* Not needed */
drivers/net/irda/w83977af_ir.c:593:#ifdef CONFIG_NETWINDER_TX_DMA_PROBLEMS
drivers/net/irda/w83977af_ir.c:609:#ifdef CONFIG_NETWINDER_TX_DMA_PROBLEMS
drivers/net/irda/w83977af_ir.c:625:#ifdef CONFIG_NETWINDER_TX_DMA_PROBLEMS
========== SBMAC_COALESCE ==========
drivers/net/sb1250-mac.c:58:#define CONFIG_SBMAC_COALESCE
drivers/net/sb1250-mac.c:97:#ifdef CONFIG_SBMAC_COALESCE
drivers/net/sb1250-mac.c:201:#ifdef CONFIG_SBMAC_COALESCE
drivers/net/sb1250-mac.c:696:#ifdef CONFIG_SBMAC_COALESCE
drivers/net/sb1250-mac.c:787:#ifdef CONFIG_SBMAC_COALESCE
drivers/net/sb1250-mac.c:828:#ifdef CONFIG_SBMAC_COALESCE
drivers/net/sb1250-mac.c:975:#ifdef CONFIG_SBMAC_COALESCE
drivers/net/sb1250-mac.c:1070:#ifndef CONFIG_SBMAC_COALESCE
drivers/net/sb1250-mac.c:1164:#ifdef CONFIG_SBMAC_COALESCE
drivers/net/sb1250-mac.c:1706:#ifdef CONFIG_SBMAC_COALESCE
drivers/net/sb1250-mac.c:2898:#ifdef CONFIG_SBMAC_COALESCE
========== SH_HICOSH4 ==========
drivers/net/cs89x0.h:440:#ifdef CONFIG_SH_HICOSH4
drivers/net/cs89x0.c:178:#elif defined(CONFIG_SH_HICOSH4)
drivers/net/cs89x0.c:570:#ifdef CONFIG_SH_HICOSH4
drivers/net/cs89x0.c:641:#ifdef CONFIG_SH_HICOSH4
drivers/net/cs89x0.c:726:#ifdef CONFIG_SH_HICOSH4 /* no EEPROM on HiCO, don't hazzle with it here */
drivers/net/cs89x0.c:1280:#if !defined(CONFIG_SH_HICOSH4) && !defined(CONFIG_ARCH_PNX010X) /* uses irq#1, so this won't work */
========== SIS190_NAPI ==========
drivers/net/sis190.c:50:#ifdef CONFIG_SIS190_NAPI
drivers/net/sis190.c:61:#ifdef CONFIG_SIS190_NAPI
========== USE_INTERNAL_TIMER ==========
drivers/net/irda/w83977af_ir.c:68:#undef CONFIG_USE_INTERNAL_TIMER /* Just cannot make that timer work */
drivers/net/irda/w83977af_ir.c:536:#ifdef CONFIG_USE_INTERNAL_TIMER
drivers/net/irda/w83977af_ir.c:563:#ifdef CONFIG_USE_INTERNAL_TIMER
drivers/net/irda/w83977af_ir.c:879:#ifdef CONFIG_USE_INTERNAL_TIMER
========== USE_W977_PNP ==========
drivers/net/irda/w83977af_ir.c:69:#define CONFIG_USE_W977_PNP /* Currently needed */
drivers/net/irda/w83977af_ir.c:283:#ifdef CONFIG_USE_W977_PNP
drivers/net/irda/w83977af_ir.c:293:#endif /* CONFIG_USE_W977_PNP */
drivers/net/irda/w83977af_ir.c:323:#ifdef CONFIG_USE_W977_PNP
drivers/net/irda/w83977af_ir.c:349:#endif /* CONFIG_USE_W977_PNP */
net/:
========== BT_BNEP_DEBUG ==========
net/bluetooth/bnep/netdev.c:48:#ifndef CONFIG_BT_BNEP_DEBUG
net/bluetooth/bnep/sock.c:53:#ifndef CONFIG_BT_BNEP_DEBUG
net/bluetooth/bnep/core.c:59:#ifndef CONFIG_BT_BNEP_DEBUG
========== BT_CMTP_DEBUG ==========
net/bluetooth/cmtp/sock.c:46:#ifndef CONFIG_BT_CMTP_DEBUG
net/bluetooth/cmtp/capi.c:45:#ifndef CONFIG_BT_CMTP_DEBUG
net/bluetooth/cmtp/core.c:47:#ifndef CONFIG_BT_CMTP_DEBUG
========== BT_HCI_CORE_DEBUG ==========
net/bluetooth/hci_event.c:48:#ifndef CONFIG_BT_HCI_CORE_DEBUG
net/bluetooth/hci_conn.c:48:#ifndef CONFIG_BT_HCI_CORE_DEBUG
net/bluetooth/hci_sysfs.c:11:#ifndef CONFIG_BT_HCI_CORE_DEBUG
net/bluetooth/hci_core.c:50:#ifndef CONFIG_BT_HCI_CORE_DEBUG
========== BT_HCI_SOCK_DEBUG ==========
net/bluetooth/hci_sock.c:51:#ifndef CONFIG_BT_HCI_SOCK_DEBUG
========== BT_HIDP_DEBUG ==========
net/bluetooth/hidp/sock.c:42:#ifndef CONFIG_BT_HIDP_DEBUG
net/bluetooth/hidp/core.c:50:#ifndef CONFIG_BT_HIDP_DEBUG
========== BT_L2CAP_DEBUG ==========
net/bluetooth/l2cap.c:53:#ifndef CONFIG_BT_L2CAP_DEBUG
========== BT_RFCOMM_DEBUG ==========
net/bluetooth/rfcomm/tty.c:44:#ifndef CONFIG_BT_RFCOMM_DEBUG
net/bluetooth/rfcomm/sock.c:55:#ifndef CONFIG_BT_RFCOMM_DEBUG
net/bluetooth/rfcomm/core.c:51:#ifndef CONFIG_BT_RFCOMM_DEBUG
========== BT_SCO_DEBUG ==========
net/bluetooth/sco.c:51:#ifndef CONFIG_BT_SCO_DEBUG
========== BT_SOCK_DEBUG ==========
net/bluetooth/af_bluetooth.c:46:#ifndef CONFIG_BT_SOCK_DEBUG
========== IP_FIB_TRIE_STATS ==========
net/ipv4/fib_trie.c:84:#undef CONFIG_IP_FIB_TRIE_STATS
net/ipv4/fib_trie.c:138:#ifdef CONFIG_IP_FIB_TRIE_STATS
net/ipv4/fib_trie.c:160:#ifdef CONFIG_IP_FIB_TRIE_STATS
net/ipv4/fib_trie.c:571:#ifdef CONFIG_IP_FIB_TRIE_STATS
net/ipv4/fib_trie.c:612:#ifdef CONFIG_IP_FIB_TRIE_STATS
net/ipv4/fib_trie.c:878:#ifdef CONFIG_IP_FIB_TRIE_STATS
net/ipv4/fib_trie.c:1315:#ifdef CONFIG_IP_FIB_TRIE_STATS
net/ipv4/fib_trie.c:1320:#ifdef CONFIG_IP_FIB_TRIE_STATS
net/ipv4/fib_trie.c:1349:#ifdef CONFIG_IP_FIB_TRIE_STATS
net/ipv4/fib_trie.c:1372:#ifdef CONFIG_IP_FIB_TRIE_STATS
net/ipv4/fib_trie.c:1506:#ifdef CONFIG_IP_FIB_TRIE_STATS
net/ipv4/fib_trie.c:2157:#ifdef CONFIG_IP_FIB_TRIE_STATS
net/ipv4/fib_trie.c:2168:#endif /* CONFIG_IP_FIB_TRIE_STATS */
========== IP_PIMSM ==========
net/ipv4/ipmr.c:68:#define CONFIG_IP_PIMSM 1
net/ipv4/ipmr.c:176:#ifdef CONFIG_IP_PIMSM
net/ipv4/ipmr.c:272:#ifdef CONFIG_IP_PIMSM
net/ipv4/ipmr.c:406:#ifdef CONFIG_IP_PIMSM
net/ipv4/ipmr.c:462:#ifdef CONFIG_IP_PIMSM
net/ipv4/ipmr.c:556:#ifdef CONFIG_IP_PIMSM
net/ipv4/ipmr.c:566:#ifdef CONFIG_IP_PIMSM
net/ipv4/ipmr.c:953:#ifdef CONFIG_IP_PIMSM
net/ipv4/ipmr.c:999:#ifdef CONFIG_IP_PIMSM
net/ipv4/ipmr.c:1016:#ifdef CONFIG_IP_PIMSM
net/ipv4/ipmr.c:1161:#ifdef CONFIG_IP_PIMSM
========== IP_ROUTE_PERVASIVE ==========
net/ipv4/fib_semantics.c:525:#ifdef CONFIG_IP_ROUTE_PERVASIVE
========== IP_VS_DEBUG ==========
arch/mips/configs/ip22_defconfig:296:# CONFIG_IP_VS_DEBUG is not set
arch/mips/configs/malta_defconfig:330:# CONFIG_IP_VS_DEBUG is not set
arch/mips/configs/atlas_defconfig:335:# CONFIG_IP_VS_DEBUG is not set
arch/mips/defconfig:296:# CONFIG_IP_VS_DEBUG is not set
arch/arm/configs/ixp4xx_defconfig:264:CONFIG_IP_VS_DEBUG=y
arch/arm/configs/pnx4008_defconfig:258:# CONFIG_IP_VS_DEBUG is not set
include/net/ip_vs.h:260:#ifdef CONFIG_IP_VS_DEBUG
include/net/ip_vs.h:303:#ifdef CONFIG_IP_VS_DEBUG
net/ipv4/ipvs/ip_vs_ctl.c:85:#ifdef CONFIG_IP_VS_DEBUG
net/ipv4/ipvs/ip_vs_ctl.c:1408:#ifdef CONFIG_IP_VS_DEBUG
net/ipv4/ipvs/ip_vs_core.c:58:#ifdef CONFIG_IP_VS_DEBUG
net/ipv4/ipvs/Kconfig:27:config IP_VS_DEBUG
========== IP_VS_DH_TAB_BITS ==========
net/ipv4/ipvs/ip_vs_dh.c:58:#ifndef CONFIG_IP_VS_DH_TAB_BITS
net/ipv4/ipvs/ip_vs_dh.c:59:#define CONFIG_IP_VS_DH_TAB_BITS 8
net/ipv4/ipvs/ip_vs_dh.c:61:#define IP_VS_DH_TAB_BITS CONFIG_IP_VS_DH_TAB_BITS
net/ipv4/ipvs/ip_vs_dh.c:61:#define IP_VS_DH_TAB_BITS CONFIG_IP_VS_DH_TAB_BITS
net/ipv4/ipvs/ip_vs_dh.c:62:#define IP_VS_DH_TAB_SIZE (1 << IP_VS_DH_TAB_BITS)
========== IP_VS_LBLCR_DEBUG ==========
net/ipv4/ipvs/ip_vs_lblcr.c:550:#ifdef CONFIG_IP_VS_LBLCR_DEBUG
net/ipv4/ipvs/ip_vs_lblcr.c:652:#ifdef CONFIG_IP_VS_LBLCR_DEBUG
net/ipv4/ipvs/ip_vs_lblcr.c:845:#ifdef CONFIG_IP_VS_LBLCR_DEBUG
net/ipv4/ipvs/ip_vs_lblcr.c:854:#ifdef CONFIG_IP_VS_LBLCR_DEBUG
========== IP_VS_LBLCR_TAB_BITS ==========
net/ipv4/ipvs/ip_vs_lblcr.c:77:#ifndef CONFIG_IP_VS_LBLCR_TAB_BITS
net/ipv4/ipvs/ip_vs_lblcr.c:78:#define CONFIG_IP_VS_LBLCR_TAB_BITS 10
net/ipv4/ipvs/ip_vs_lblcr.c:80:#define IP_VS_LBLCR_TAB_BITS CONFIG_IP_VS_LBLCR_TAB_BITS
net/ipv4/ipvs/ip_vs_lblcr.c:80:#define IP_VS_LBLCR_TAB_BITS CONFIG_IP_VS_LBLCR_TAB_BITS
net/ipv4/ipvs/ip_vs_lblcr.c:81:#define IP_VS_LBLCR_TAB_SIZE (1 << IP_VS_LBLCR_TAB_BITS)
========== IP_VS_LBLC_TAB_BITS ==========
net/ipv4/ipvs/ip_vs_lblc.c:77:#ifndef CONFIG_IP_VS_LBLC_TAB_BITS
net/ipv4/ipvs/ip_vs_lblc.c:78:#define CONFIG_IP_VS_LBLC_TAB_BITS 10
net/ipv4/ipvs/ip_vs_lblc.c:80:#define IP_VS_LBLC_TAB_BITS CONFIG_IP_VS_LBLC_TAB_BITS
net/ipv4/ipvs/ip_vs_lblc.c:80:#define IP_VS_LBLC_TAB_BITS CONFIG_IP_VS_LBLC_TAB_BITS
net/ipv4/ipvs/ip_vs_lblc.c:81:#define IP_VS_LBLC_TAB_SIZE (1 << IP_VS_LBLC_TAB_BITS)
========== IP_VS_PROTO_AH ==========
arch/mips/configs/ip22_defconfig:305:CONFIG_IP_VS_PROTO_AH=y
arch/mips/configs/malta_defconfig:339:CONFIG_IP_VS_PROTO_AH=y
arch/mips/configs/atlas_defconfig:344:CONFIG_IP_VS_PROTO_AH=y
arch/mips/defconfig:305:CONFIG_IP_VS_PROTO_AH=y
arch/arm/configs/ixp4xx_defconfig:273:# CONFIG_IP_VS_PROTO_AH is not set
arch/arm/configs/pnx4008_defconfig:267:CONFIG_IP_VS_PROTO_AH=y
net/ipv4/ipvs/ip_vs_proto.c:213:#ifdef CONFIG_IP_VS_PROTO_AH
net/ipv4/ipvs/Makefile:10:ip_vs_proto-objs-$(CONFIG_IP_VS_PROTO_AH) += ip_vs_proto_ah.o
net/ipv4/ipvs/Kconfig:80:config IP_VS_PROTO_AH
========== IP_VS_PROTO_ESP ==========
arch/mips/configs/ip22_defconfig:304:CONFIG_IP_VS_PROTO_ESP=y
arch/mips/configs/malta_defconfig:338:CONFIG_IP_VS_PROTO_ESP=y
arch/mips/configs/atlas_defconfig:343:CONFIG_IP_VS_PROTO_ESP=y
arch/mips/defconfig:304:CONFIG_IP_VS_PROTO_ESP=y
arch/arm/configs/ixp4xx_defconfig:272:# CONFIG_IP_VS_PROTO_ESP is not set
arch/arm/configs/pnx4008_defconfig:266:CONFIG_IP_VS_PROTO_ESP=y
net/ipv4/ipvs/ip_vs_proto.c:216:#ifdef CONFIG_IP_VS_PROTO_ESP
net/ipv4/ipvs/Makefile:9:ip_vs_proto-objs-$(CONFIG_IP_VS_PROTO_ESP) += ip_vs_proto_esp.o
net/ipv4/ipvs/Kconfig:74:config IP_VS_PROTO_ESP
========== IP_VS_PROTO_TCP ==========
arch/mips/configs/ip22_defconfig:302:CONFIG_IP_VS_PROTO_TCP=y
arch/mips/configs/malta_defconfig:336:CONFIG_IP_VS_PROTO_TCP=y
arch/mips/configs/atlas_defconfig:341:CONFIG_IP_VS_PROTO_TCP=y
arch/mips/defconfig:302:CONFIG_IP_VS_PROTO_TCP=y
arch/arm/configs/ixp4xx_defconfig:270:# CONFIG_IP_VS_PROTO_TCP is not set
arch/arm/configs/pnx4008_defconfig:264:CONFIG_IP_VS_PROTO_TCP=y
net/ipv4/ipvs/ip_vs_ctl.c:1881:#ifdef CONFIG_IP_VS_PROTO_TCP
net/ipv4/ipvs/ip_vs_ctl.c:2161:#ifdef CONFIG_IP_VS_PROTO_TCP
net/ipv4/ipvs/ip_vs_core.c:54:#ifdef CONFIG_IP_VS_PROTO_TCP
net/ipv4/ipvs/ip_vs_proto.c:207:#ifdef CONFIG_IP_VS_PROTO_TCP
net/ipv4/ipvs/Makefile:7:ip_vs_proto-objs-$(CONFIG_IP_VS_PROTO_TCP) += ip_vs_proto_tcp.o
net/ipv4/ipvs/Kconfig:62:config IP_VS_PROTO_TCP
net/ipv4/ipvs/Kconfig:212: depends on IP_VS_PROTO_TCP
========== IP_VS_PROTO_UDP ==========
arch/mips/configs/ip22_defconfig:303:CONFIG_IP_VS_PROTO_UDP=y
arch/mips/configs/malta_defconfig:337:CONFIG_IP_VS_PROTO_UDP=y
arch/mips/configs/atlas_defconfig:342:CONFIG_IP_VS_PROTO_UDP=y
arch/mips/defconfig:303:CONFIG_IP_VS_PROTO_UDP=y
arch/arm/configs/ixp4xx_defconfig:271:# CONFIG_IP_VS_PROTO_UDP is not set
arch/arm/configs/pnx4008_defconfig:265:CONFIG_IP_VS_PROTO_UDP=y
net/ipv4/ipvs/ip_vs_ctl.c:1893:#ifdef CONFIG_IP_VS_PROTO_UDP
net/ipv4/ipvs/ip_vs_ctl.c:2167:#ifdef CONFIG_IP_VS_PROTO_UDP
net/ipv4/ipvs/ip_vs_proto.c:210:#ifdef CONFIG_IP_VS_PROTO_UDP
net/ipv4/ipvs/Makefile:8:ip_vs_proto-objs-$(CONFIG_IP_VS_PROTO_UDP) += ip_vs_proto_udp.o
net/ipv4/ipvs/Kconfig:68:config IP_VS_PROTO_UDP
========== IP_VS_SH_TAB_BITS ==========
net/ipv4/ipvs/ip_vs_sh.c:55:#ifndef CONFIG_IP_VS_SH_TAB_BITS
net/ipv4/ipvs/ip_vs_sh.c:56:#define CONFIG_IP_VS_SH_TAB_BITS 8
net/ipv4/ipvs/ip_vs_sh.c:58:#define IP_VS_SH_TAB_BITS CONFIG_IP_VS_SH_TAB_BITS
net/ipv4/ipvs/ip_vs_sh.c:58:#define IP_VS_SH_TAB_BITS CONFIG_IP_VS_SH_TAB_BITS
net/ipv4/ipvs/ip_vs_sh.c:59:#define IP_VS_SH_TAB_SIZE (1 << IP_VS_SH_TAB_BITS)
========== IRDA_DYNAMIC_WINDOW ==========
include/net/irda/irlap.h:41:#define CONFIG_IRDA_DYNAMIC_WINDOW 1
include/net/irda/irlap.h:181:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW
include/net/irda/irlap.h:184:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */
net/irda/irlap.c:1026:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW
net/irda/irlap.c:1035:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */
net/irda/irlap.c:1158:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW
net/irda/irlap.c:1162:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */
net/irda/qos.c:99:#ifndef CONFIG_IRDA_DYNAMIC_WINDOW
net/irda/qos.c:385:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW
net/irda/qos.c:409:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */
net/irda/qos.c:730:#ifndef CONFIG_IRDA_DYNAMIC_WINDOW
net/irda/irlap_frame.c:832:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW
net/irda/irlap_frame.c:842:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */
net/irda/irlap_frame.c:924:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW
net/irda/irlap_frame.c:927:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */
net/irda/irlap_event.c:994:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW
net/irda/irlap_event.c:1056:#else /* CONFIG_IRDA_DYNAMIC_WINDOW */
net/irda/irlap_event.c:1060:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */
net/irda/irlap_event.c:1101:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW
net/irda/irlap_event.c:1104:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */
net/irda/irlap_event.c:1745:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW
net/irda/irlap_event.c:1793:#else /* CONFIG_IRDA_DYNAMIC_WINDOW */
net/irda/irlap_event.c:1797:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */
========== IRLAN_SEND_GRATUITOUS_ARP ==========
net/irda/irlan/irlan_common.c:62:#undef CONFIG_IRLAN_SEND_GRATUITOUS_ARP
net/irda/irlan/irlan_common.c:398:#ifdef CONFIG_IRLAN_SEND_GRATUITOUS_ARP
========== WANPIPE_MULTPPP ==========
net/wanrouter/wanmain.c:568:#ifdef CONFIG_WANPIPE_MULTPPP
net/wanrouter/wanmain.c:589:#ifdef CONFIG_WANPIPE_MULTPPP
net/wanrouter/wanmain.c:662:#ifdef CONFIG_WANPIPE_MULTPPP
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Jarek Poplawski @ 2007-09-03 9:12 UTC (permalink / raw)
To: Badalian Vyacheslav; +Cc: netdev
In-Reply-To: <46DBC66B.1000003@bigtelecom.ru>
On Mon, Sep 03, 2007 at 12:31:39PM +0400, Badalian Vyacheslav wrote:
> May you also see that i need change to fix this:
>
> qdisc handle can >= 10 000
>
> i have more then 10 000 qdiscs =(
>
As far as I know qdisc handle is hex, so you can have e.g.:
handle 999a (or a999 too). But, does it mean your kernel has
any changes around this? If so, please, describe them all (or
send your patch).
I've read your bugzilla log with: "2. HTB levels wrong calculate!",
but can't check this now: could you add there what are these levels
you can see after: tc -d class show dev eth0 ?
Jarek P.
^ permalink raw reply
* Re: [PATCH 0/9 Rev3] Implement batching skb API and support in IPoIB
From: Krishna Kumar2 @ 2007-09-03 9:21 UTC (permalink / raw)
To: David Miller
Cc: gaagaan, general, hadi, herbert, jagana, jeff, johnpol, kaber,
kumarkr, mcarlson, mchan, netdev, peter.p.waskiewicz.jr, rdreier,
rick.jones2, Robert.Olsson, shemminger, sri, tgraf, xma
In-Reply-To: <20070828.215150.98552996.davem@davemloft.net>
Hi Dave,
David Miller <davem@davemloft.net> wrote on 08/29/2007 10:21:50 AM:
> From: Krishna Kumar2 <krkumar2@in.ibm.com>
> Date: Wed, 29 Aug 2007 08:53:30 +0530
>
> > I am scp'ng from 192.168.1.1 to 192.168.1.2 and captured at the send
> > side.
>
> Bad choice of test, this is cpu limited since the scp
> has to encrypt and MAC hash all the data it sends.
>
> Use something like straight ftp or "bw_tcp" from lmbench.
I used bw_tcp from lmbench-3. I transfered 500MB and captured
the tcpdump, and analysis at various points gave pipeline sizes:
26064, 27792, 22888, 23168, 23448, 20272, 23168, 4344, 10136,
164792, 35920, 26344, 24336, 24336, 23168, 25784, 23168,
There was one huge 164K, otherwise most were in smaller ranges
like 20-30K. I ran the following test script:
SERVER=192.168.1.2
BYTES=100m
BUFFERSIZES="4096 16384 65536 131072 262144"
PROCS="1 8"
ITERATIONS=5
for m in $BUFFERSIZES
do
for procs in $PROCS
do
echo TEST: Size:$m Procs:$procs
bw_tcp -N $ITERATIONS -m $m -M $BYTES -P $procs $SERVER
done
done
Result is:
Test without batching:
# Size Procs BW (MB/s)
1 4096 1 117.39
2 16384 1 117.49
3 65536 1 117.55
4 131072 1 117.55
5 262144 1 117.58
6 4096 8 117.18
7 16384 8 117.47
8 65536 8 117.54
9 131072 8 117.59
10 262144 8 117.55
Test with batching:
# Size Procs BW (MB/s)
1 4096 1 117.39
2 16384 1 117.48
3 65536 1 117.55
4 131072 1 117.58
5 262144 1 117.58
6 4096 8 117.19
7 16384 8 117.46
8 65536 8 117.53
9 131072 8 117.55
10 262144 8 117.60
So it doesn't seem to harm e1000.
Can someone give a link to the E1000E driver? I couldn't find it
after downloading Jeff's netdev-2.6 tree.
Thanks,
- KK
^ permalink raw reply
* Re: [0/7] [PPP]: Fix shared/cloned/non-linear skb bugs (was: malformed captured packets)
From: Toralf Förster @ 2007-09-03 9:32 UTC (permalink / raw)
To: Herbert Xu
Cc: James Chapman, David S. Miller, Michal Ostrowski, Paul Mackerras,
netdev
In-Reply-To: <20070831090625.GA28175@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]
Am Freitag, 31. August 2007 schrieb Herbert Xu:
> On Thu, Aug 30, 2007 at 09:51:31AM +0000, James Chapman wrote:
> >
> > The captured PPPoE stream seems to show incorrect data lengths in the
> > PPPoE header for some captured PPPoE packets. The kernel's PPPoE
> > datapath uses this length to extract the PPP frame and send it through
> > to the ppp interface. Since your ppp stream is fine, the actual PPPoE
> > header contents must be correct when it is parsed by the kernel PPPoE
> > code. It seems more likely that this is a wireshark bug to me.
>
> If he were using the kernel pppoe driver, then this is because
> PPP filtering is writing over a cloned skb without copying it.
>
> In fact, there seems to be quite a few bugs of this kind in
> the various ppp*.c files.
>
> Please try the following patches to see if they make a
> difference.
>
> I've audited ppp_generic.c and pppoe.c. I'll do pppol2tp
> tomorrow.
>
> Cheers,
I've applied the patch series onto a Gentoo-2.6.22-r5 kernel and use this kernel
now since some days w/o any problems both at work and at home.
Many thanks.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: some weird corruption in net-2.6.24
From: Thomas Graf @ 2007-09-03 9:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20070830.223910.70218812.davem@davemloft.net>
* David Miller <davem@davemloft.net> 2007-08-30 22:39
>
> Every so often some piece of userland dies, and often it's
> bad enough that my desktop session logs out.
>
> I've been trying to find some clues and it seems to happen
> about as often as openswan rekeys my VPN, so one suspect
> area is the netlink cleanups to xfrm_user.
>
> I plan to do some auditing of those changes looking for
> errors, but if someone can beat me to it... :-)
I've been trying to reproduce this, what happens on my system
is that when the ISAKMP SA lifetime is exceeded the rekeying
fails and my connection dies. I can reproduce this back to
2.6.22 and it doesn't seem related to my recent xfrm_user work.
It looks like this behaviour is hiding the bug you are seeing.
^ permalink raw reply
* Re: [3/4] 2.6.23-rc5: known regressions
From: Michal Piotrowski @ 2007-09-03 10:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, LKML, Netdev, Shish, Karl Meyer, Francois Romieu,
linux-wireless, Christian Casteyde, Martin Langer, Stefano Brivio,
Michael Buesch, Danny van Dyk, Andreas Jaggi, Daniel Drake,
Oliver Neukum, linux-usb-devel, Florian Lohoff
In-Reply-To: <46DBD982.3080102@googlemail.com>
Hi all,
Here is a list of some known regressions in 2.6.23-rc5.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
Name Regressions fixed since 21-Jun-2007
Adrian Bunk 9
Linus Torvalds 6
Andi Kleen 5
Hugh Dickins 5
Andrew Morton 4
Al Viro 3
Alan Stern 3
Alexey Starikovskiy 3
Cornelia Huck 3
Jens Axboe 3
Stephen Hemminger 3
Tejun Heo 3
Networking
Subject : ifconfig eth1 - scheduling while atomic: ifconfig/0x00000002/4170
References : http://lkml.org/lkml/2007/9/2/165
Last known good : ?
Submitter : Florian Lohoff <flo@rfc822.org>
Caused-By : ?
Handled-By : ?
Status : unknown
Subject : zd1211rw regression, device does not enumerate
References : http://marc.info/?l=linux-usb-devel&m=118854967709322&w=2
Last known good : ?
Submitter : Oliver Neukum <oliver@neukum.org>
Caused-By : Daniel Drake <dsd@gentoo.org>
commit 74553aedd46b3a2cae986f909cf2a3f99369decc
Handled-By : ?
Status : unknown
Subject : System freeze when restarting network connection with Broadcom driver
References : http://bugzilla.kernel.org/show_bug.cgi?id=8934
Last known good : ?
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Caused-By : ?
Handled-By : ?
Status : problem is being debugged
Subject : NETDEV WATCHDOG: eth0: transmit timed out
References : http://lkml.org/lkml/2007/8/13/737
Last known good : ?
Submitter : Karl Meyer <adhocrocker@gmail.com>
Caused-By : ?
Handled-By : Francois Romieu <romieu@fr.zoreil.com>
Status : problem is being debugged
Subject : Weird network problems with 2.6.23-rc2
References : http://lkml.org/lkml/2007/8/11/40
Last known good : ?
Submitter : Shish <shish@shishnet.org>
Caused-By : ?
Handled-By : ?
Status : unknown
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* Re: [2/2] 2.6.23-rc5: known regressions with patches
From: Michal Piotrowski @ 2007-09-03 10:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, LKML, kbuild-devel, Roman Zippel, Sam Ravnborg,
Hugh Dickins, Pierre Ossman, Christian Casteyde, Alan Stern,
linux-mtd, David Woodhouse, Ingo Molnar, David S. Miller, netdev,
Mark Hindley, linux-ide, Jeff Garzik, Grant Wilson, Ondrej Zary
In-Reply-To: <46DBDCF4.6040805@googlemail.com>
Hi all,
Here is a list of some known regressions in 2.6.23-rc5
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
Name Regressions fixed since 21-Jun-2007
Adrian Bunk 9
Linus Torvalds 6
Andi Kleen 5
Hugh Dickins 5
Andrew Morton 4
Al Viro 3
Alan Stern 3
Alexey Starikovskiy 3
Cornelia Huck 3
Jens Axboe 3
Stephen Hemminger 3
Tejun Heo 3
Kconfig
Subject : CONFIG_HOTPLUG_CPU: kconfig bug?
References : http://lkml.org/lkml/2007/8/27/204
Last known good : ?
Submitter : Hugh Dickins <hugh@veritas.com>
Caused-By : ?
Handled-By : Roman Zippel <zippel@linux-m68k.org>
Sam Ravnborg <sam@ravnborg.org>
Patch : http://lkml.org/lkml/2007/8/29/301
Status : patch available
MMC
Subject : Unable to access memory card reader anymore
References : http://bugzilla.kernel.org/show_bug.cgi?id=8885
Last known good : ?
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Caused-By : ?
Handled-By : Alan Stern <stern@rowland.harvard.edu>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=12438
Status : patch available
MTD
Subject : error: implicit declaration of function 'cfi_interleave'
References : http://lkml.org/lkml/2007/8/6/272
Last known good : ?
Submitter : Ingo Molnar <mingo@elte.hu>
Caused-By : ?
Handled-By : David Woodhouse <dwmw2@infradead.org>
Patch : http://lkml.org/lkml/2007/8/9/586
Status : patch available
Networking
Subject : [OOPS] 2.6.23-rc5 ? network/via-rhine
References : http://lkml.org/lkml/2007/9/2/58
Last known good : ?
Submitter : Mark Hindley <mark@hindley.org.uk>
Caused-By : ?
Handled-By : David S. Miller <davem@sunset.davemloft.net>
Patch : http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=5c127c58ae9bf196d787815b1bd6b0aec5aee816
Status : patch available
PATA/SATA
Subject : sata_via: write errors on PATA drive connected to VT6421
References : http://lkml.org/lkml/2007/8/20/248
Last known good : ?
Submitter : Ondrej Zary <linux@rainbow-software.org>
Caused-By : ?
Handled-By : Ondrej Zary <linux@rainbow-software.org>
Patch : http://lkml.org/lkml/2007/8/31/310
Status : patch available
Subject : NULL pointer dereference in ata_piix
References : http://lkml.org/lkml/2007/9/1/33
Last known good : ?
Submitter : Grant Wilson <grant.wilson@zen.co.uk>
Caused-By : ?
Handled-By : Jeff Garzik <jeff@garzik.org>
Patch : http://lkml.org/lkml/2007/9/1/46
Status : patch available
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* 82557/8/9 Ethernet Pro 100 interrupt mitigation support
From: Marc Sigler @ 2007-09-03 10:33 UTC (permalink / raw)
To: netdev, linux-net
[-- Attachment #1: Type: text/plain, Size: 509 bytes --]
Hello everyone,
I have several systems with three integrated Intel 82559 (I *think*).
Does someone know if these boards support hardware interrupt mitigation?
I.e. is it possible to configure them to raise an IRQ only if their
hardware buffer is full OR if some given time (say 1 ms) has passed and
packets are available in their hardware buffer.
I've been using the eepro100 driver up to now, but I'm about to try the
e100 driver. Would I have to use NAPI? Or is this an orthogonal feature?
Regards.
[-- Attachment #2: adlink.lspci --]
[-- Type: text/plain, Size: 2330 bytes --]
00:08.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 10
Region 0: Memory at e6400000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at d800 [size=64]
Region 2: Memory at e6100000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00:09.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at e6403000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at dc00 [size=64]
Region 2: Memory at e6200000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00:0a.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 12
Region 0: Memory at e6402000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at e000 [size=64]
Region 2: Memory at e6000000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
^ permalink raw reply
* 82557/8/9 Ethernet Pro 100 interrupt mitigation support
From: John Sigler @ 2007-09-03 10:36 UTC (permalink / raw)
To: netdev, linux-net
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
(Please ignore previous message, it was sent from the wrong account.)
Hello everyone,
I have several systems with three integrated Intel 82559 (I *think*).
Does someone know if these boards support hardware interrupt mitigation?
I.e. is it possible to configure them to raise an IRQ only if their
hardware buffer is full OR if some given time (say 1 ms) has passed and
packets are available in their hardware buffer.
I've been using the eepro100 driver up to now, but I'm about to try the
e100 driver. Would I have to use NAPI? Or is this an orthogonal feature?
Regards.
[-- Attachment #2: adlink.lspci --]
[-- Type: text/plain, Size: 2331 bytes --]
00:08.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 10
Region 0: Memory at e6400000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at d800 [size=64]
Region 2: Memory at e6100000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00:09.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at e6403000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at dc00 [size=64]
Region 2: Memory at e6200000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00:0a.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 12
Region 0: Memory at e6402000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at e000 [size=64]
Region 2: Memory at e6000000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
^ permalink raw reply
* Re: [-mm patch] IPV6 must select XFRM
From: Masahide NAKAMURA @ 2007-09-03 10:43 UTC (permalink / raw)
To: Adrian Bunk, David Miller; +Cc: Andrew Morton, linux-kernel, netdev, nakam
In-Reply-To: <20070902112557.GK16016@stusta.de>
[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]
Hello,
On Sun, 2 Sep 2007 13:25:57 +0200
Adrian Bunk <bunk@kernel.org> wrote:
> On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.23-rc3-mm1:
> >...
> > git-net.patch
> >...
> > git trees
> >...
>
> This patch fixes the following compile error:
>
> <-- snip -->
>
> ...
> LD .tmp_vmlinux1
> net/built-in.o: In function `inet6_csk_xmit':
> (.text+0x72b0f): undefined reference to `flow_cache_genid'
> net/built-in.o: In function `inet6_csk_xmit':
> (.text+0x72be5): undefined reference to `flow_cache_genid'
> make[1]: *** [.tmp_vmlinux1] Error 1
>
> <-- snip -->
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> ---
> --- a/net/ipv6/Kconfig
> +++ b/net/ipv6/Kconfig
> @@ -5,6 +5,7 @@
> # IPv6 as module will cause a CRASH if you try to unload it
> config IPV6
> tristate "The IPv6 protocol"
> + select XFRM
> default m
> ---help---
> This is complemental support for the IP version 6.
>
> -
Thank you for catching this. the issue is caused with patch
"[IPV6] XFRM: Fix connected socket to use transformation."
which I sent to netdev.
(a85d5450ddeb959bdf9e4603f9c06e9d79217cfa on net-2.6.24).
I'd prefer to modify the original patch to use "ifdef CONFIG_XFRM"
than changing kernel config depends. Does it make sense?
Please review the attached patch.
--
Masahide NAKAMURA
[-- Attachment #2: 0001-PATCH-IPV6-XFRM-Fix-dependency-issue-at-inet6_csk_xmit.txt --]
[-- Type: application/octet-stream, Size: 2113 bytes --]
From c9b0d15f8222de7854a6ad504c4562004b99e487 Mon Sep 17 00:00:00 2001
From: Masahide NAKAMURA <nakam@linux-ipv6.org>
Date: Mon, 3 Sep 2007 19:31:32 +0900
Subject: [PATCH] [IPV6] XFRM: Fix dependency issue at inet6_csk_xmit.
Signed-off-by: Masahide NAKAMURA <nakam@linux-ipv6.org>
---
include/net/ip6_fib.h | 2 ++
net/ipv6/inet6_connection_sock.c | 31 ++++++++++++++++++-------------
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 85d6d9f..8578213 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -106,7 +106,9 @@ struct rt6_info
u8 rt6i_protocol;
+#ifdef CONFIG_XFRM
u32 rt6i_flow_cache_genid;
+#endif
};
static inline struct inet6_dev *ip6_dst_idev(struct dst_entry *dst)
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index f389322..25b9317 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -143,29 +143,34 @@ static inline
void __inet6_csk_dst_store(struct sock *sk, struct dst_entry *dst,
struct in6_addr *daddr, struct in6_addr *saddr)
{
- struct rt6_info *rt = (struct rt6_info *)dst;
-
__ip6_dst_store(sk, dst, daddr, saddr);
- rt->rt6i_flow_cache_genid = atomic_read(&flow_cache_genid);
+
+#ifdef CONFIG_XFRM
+ if (dst) {
+ struct rt6_info *rt = (struct rt6_info *)dst;
+ rt->rt6i_flow_cache_genid = atomic_read(&flow_cache_genid);
+ }
+#endif
}
static inline
struct dst_entry *__inet6_csk_dst_check(struct sock *sk, u32 cookie)
{
struct dst_entry *dst;
- struct rt6_info *rt;
dst = __sk_dst_check(sk, cookie);
- if (!dst)
- goto end;
-
- rt = (struct rt6_info *)dst;
- if (rt->rt6i_flow_cache_genid != atomic_read(&flow_cache_genid)) {
- sk->sk_dst_cache = NULL;
- dst_release(dst);
- dst = NULL;
+
+#ifdef CONFIG_XFRM
+ if (dst) {
+ struct rt6_info *rt = (struct rt6_info *)dst;
+ if (rt->rt6i_flow_cache_genid != atomic_read(&flow_cache_genid)) {
+ sk->sk_dst_cache = NULL;
+ dst_release(dst);
+ dst = NULL;
+ }
}
- end:
+#endif
+
return dst;
}
--
1.4.4.2
^ permalink raw reply related
* Re: [patch 02/18] sundance: PHY address form 0, only for device I D 0x0200 (IP100A) (20070605)
From: Jeff Garzik @ 2007-09-03 10:42 UTC (permalink / raw)
To: 黃建興-Jesse; +Cc: akpm, netdev
In-Reply-To: <AA68EB0EBA29BA40A06B700C33343EEF018686BB@fileserver.icplus.com.tw>
黃建興-Jesse wrote:
> +++ a/drivers/net/sundance.c
> @@ -559,7 +559,11 @@ static int __devinit sundance_probe1 (st
> * It seems some phys doesn't deal well with address 0 being
> accessed
> * first, so leave address zero to the end of the loop (32 & 31).
> */
> - for (phy = 1; phy <= 32 && phy_idx < MII_CNT; phy++) {
> + if (sundance_pci_tbl[np->chip_id].device == 0x0200)
> + phy = 0;
> + else
> + phy = 1;
> + for (; phy <= 32 && phy_idx < MII_CNT; phy++) {
As I noted in the last email, this patch still has a bug:
In the above loop code being modified, you need to change two things:
1) Initial loop value
2) Loop terminating condition
Your patch only performs change #1.
Jeff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox