From: Eric Dumazet <eric.dumazet@gmail.com>
To: Arturas <arturasl@res.lt>
Cc: netdev@vger.kernel.org
Subject: Re: BUG: unable to handle kernel paging request at 000041ed00000001
Date: Thu, 10 Jun 2010 18:00:09 +0200 [thread overview]
Message-ID: <1276185609.2448.12.camel@edumazet-laptop> (raw)
In-Reply-To: <9D7251E7-0EFD-4645-BC30-A96191D1046E@res.lt>
Le jeudi 10 juin 2010 à 16:45 +0300, Arturas a écrit :
> Hello,
>
> I'm not sure if i'm writing to right mailling list, but i hope I am. I'm doing
> bonding, bridging and traffic shaping on linux. With such setup i have no
> panics for a few days. But when I add ip address on br0, assign bridge
> interface and ip address to different routing table and using iptables n
> at REDIRECT I'm getting an oops (see attachment). An oops triggers only
> after some traffic. Dmesg and .config also attached. I don't know is it
> enough information for you, but if not, just say what I should do to get
> more information and i'll try. Older kernels have deadlocks for such setup
> except bridge routing, so I can't try older kernels (>=2.6.32). If someone is interested i can write call traces.
>
> Bonding is not multiqueue aware right now and someone promised to make it mq aware
> (not just patch bonding with netdev_alloc_mq). Maybe someone knows what is a status? I can test patches.
>
> Performance tips for .config are very welcome.
>
> --
> Arturas
>
>
>
This is right mailing list :)
I would try following patch for 2.6.34,
not blindly trusting sk_tx_queue_get(sk)
--- net/core/dev.c.orig 2010-06-10 17:52:17.000000000 +0200
+++ net/core/dev.c 2010-06-10 17:54:56.000000000 +0200
@@ -1958,12 +1958,10 @@
static inline u16 dev_cap_txqueue(struct net_device *dev, u16 queue_index)
{
if (unlikely(queue_index >= dev->real_num_tx_queues)) {
- if (net_ratelimit()) {
- WARN(1, "%s selects TX queue %d, but "
- "real number of TX queues is %d\n",
- dev->name, queue_index,
- dev->real_num_tx_queues);
- }
+ WARN_ONCE("%s selects TX queue %d, but "
+ "real number of TX queues is %d\n",
+ dev->name, queue_index,
+ dev->real_num_tx_queues);
return 0;
}
return queue_index;
@@ -1977,6 +1975,7 @@
if (sk_tx_queue_recorded(sk)) {
queue_index = sk_tx_queue_get(sk);
+ queue_index = dev_cap_txqueue(dev, queue_index);
} else {
const struct net_device_ops *ops = dev->netdev_ops;
next prev parent reply other threads:[~2010-06-10 16:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-10 13:45 BUG: unable to handle kernel paging request at 000041ed00000001 Arturas
2010-06-10 16:00 ` Eric Dumazet [this message]
2010-06-14 7:05 ` Arturas
2010-06-14 8:31 ` Eric Dumazet
2010-06-14 9:27 ` Arturas
2010-06-16 10:25 ` Arturas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1276185609.2448.12.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=arturasl@res.lt \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox