* Re: [PATCHv7 3/3] vhost_net: a kernel-level virtio server
From: Paul E. McKenney @ 2009-11-03 23:57 UTC (permalink / raw)
To: Gregory Haskins
Cc: Eric Dumazet, Michael S. Tsirkin, netdev, virtualization, kvm,
linux-kernel, mingo, linux-mm, akpm, hpa, Rusty Russell, s.hetze
In-Reply-To: <4AF072EE.9020202@gmail.com>
On Tue, Nov 03, 2009 at 01:14:06PM -0500, Gregory Haskins wrote:
> Gregory Haskins wrote:
> > Eric Dumazet wrote:
> >> Michael S. Tsirkin a écrit :
> >>> +static void handle_tx(struct vhost_net *net)
> >>> +{
> >>> + struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
> >>> + unsigned head, out, in, s;
> >>> + struct msghdr msg = {
> >>> + .msg_name = NULL,
> >>> + .msg_namelen = 0,
> >>> + .msg_control = NULL,
> >>> + .msg_controllen = 0,
> >>> + .msg_iov = vq->iov,
> >>> + .msg_flags = MSG_DONTWAIT,
> >>> + };
> >>> + size_t len, total_len = 0;
> >>> + int err, wmem;
> >>> + size_t hdr_size;
> >>> + struct socket *sock = rcu_dereference(vq->private_data);
> >>> + if (!sock)
> >>> + return;
> >>> +
> >>> + wmem = atomic_read(&sock->sk->sk_wmem_alloc);
> >>> + if (wmem >= sock->sk->sk_sndbuf)
> >>> + return;
> >>> +
> >>> + use_mm(net->dev.mm);
> >>> + mutex_lock(&vq->mutex);
> >>> + vhost_no_notify(vq);
> >>> +
> >> using rcu_dereference() and mutex_lock() at the same time seems wrong, I suspect
> >> that your use of RCU is not correct.
> >>
> >> 1) rcu_dereference() should be done inside a read_rcu_lock() section, and
> >> we are not allowed to sleep in such a section.
> >> (Quoting Documentation/RCU/whatisRCU.txt :
> >> It is illegal to block while in an RCU read-side critical section, )
> >>
> >> 2) mutex_lock() can sleep (ie block)
> >>
> >
> >
> > Michael,
> > I warned you that this needed better documentation ;)
> >
> > Eric,
> > I think I flagged this once before, but Michael convinced me that it
> > was indeed "ok", if but perhaps a bit unconventional. I will try to
> > find the thread.
> >
> > Kind Regards,
> > -Greg
> >
>
> Here it is:
>
> http://lkml.org/lkml/2009/8/12/173
What was happening in that case was that the rcu_dereference()
was being used in a workqueue item. The role of rcu_read_lock()
was taken on be the start of execution of the workqueue item, of
rcu_read_unlock() by the end of execution of the workqueue item, and
of synchronize_rcu() by flush_workqueue(). This does work, at least
assuming that flush_workqueue() operates as advertised, which it appears
to at first glance.
The above code looks somewhat different, however -- I don't see
handle_tx() being executed in the context of a work queue. Instead
it appears to be in an interrupt handler.
So what is the story? Using synchronize_irq() or some such?
Thanx, Paul
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [atl1-devel] [Bugme-new] [Bug 14431] New: atl1 eth0 link continuously down up
From: J. K. Cliburn @ 2009-11-04 0:19 UTC (permalink / raw)
To: Andrew Morton
Cc: atl1-devel, netdev, johan_vdp, bugzilla-daemon, bugme-daemon
In-Reply-To: <20091102224018.e306b12f.akpm@linux-foundation.org>
On Nov 3, 2009, at 12:40 AM, Andrew Morton wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not
> via the
> bugzilla web interface).
>
> On Sat, 17 Oct 2009 19:17:38 GMT bugzilla-
> daemon@bugzilla.kernel.org wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=14431
>>
>> Summary: atl1 eth0 link continuously down up
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 2.6.30.8-64.fc11.x86_64
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Network
>> AssignedTo: drivers_network@kernel-bugs.osdl.org
>> ReportedBy: johan_vdp@hotmail.com
>> Regression: No
>>
>>
>> /var/log/messages shows
>> ..
>> Oct 17 21:06:01 blauw kernel: atl1 0000:01:00.0: eth0 link is down
>> Oct 17 21:06:01 blauw kernel: atl1 0000:01:00.0: eth0 link is up
>> 100 Mbps full
>> duplex
Strange. This driver hasn't been changed in quite some time and it's
very stable. I'm running Fedora 11 and I don't see the problem at all.
I note that your NIC is autonegotiating to only 100 Mbps instead of
1000 Mbps; is your switch a 100 Mbps device?
Out of curiosity, are you running with or without NetworkManager active?
Increase the verbosity of driver messages and see if any additional
light is shed on the subject.
ethtool -s eth0 msglvl 0xffff
Jay Cliburn
^ permalink raw reply
* RE: Subject: [PATCH 1/6] bna: Brocade 10Gb Ethernet device driver
From: Joe Perches @ 2009-11-04 0:31 UTC (permalink / raw)
To: Rasesh Mody
Cc: netdev@vger.kernel.org, Adapter Linux Open SRC Team,
Greg Kroah-Hartman
In-Reply-To: <CBE1CC7A31453F4CA63C13EFCE6A0F6C05BAC64093@HQ-EXCH-7.corp.brocade.com>
On Tue, 2009-11-03 at 10:24 -0800, Rasesh Mody wrote:
> Joe,
> Thanks for your input. We are in the process addressing the comments that we are getting.
Hi Rasesh.
Thanks for bringing this out to netdev.
I think that with a few hours of cleanup, the code
would be more linux style conforming. But right now,
it looks a bit odd with too many indirections.
> Can you please give examples or elaborate your comment? It would be really helpful.
OS dependent includes? Most of them are senseless.
All of bfa_os_inc.h should go elsewhere or be dropped.
All of bna_os should go elsewhere or be dropped.
drop all bna_os_ prefixes
drop all bfa_os_ntohs, etc:
sed -r -i -e 's/\bbfa_os_(nh)to(nh)(sl)\b/\1to\2\3/g' *
Redefine true/false? why?
sed -r -i -e 's/\bbfa_boolean_t\b/bool/g' *
sed -r -i -e 's/\bBFA_TRUE\b/true/g' *
sed -r -i -e 's/\bBFA_FALSE\b/false/g' *
Don't suffix struct names with _s
sed -r -i -e 's/\bstruct\b\s+(\w+)\s+(\w+)_s/struct \1 \2/g' *
bfa_panic -> bfa_os_panic -> nothing
a laundry list like that...
I think it should go into staging for a few weeks, and then
it would be ready to be integrated into a mainline release.
cheers, Joe
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Alan Cox @ 2009-11-04 0:40 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Ivo van Doorn, linux-wireless, linux-kernel, netdev, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911040052.28323.bzolnier@gmail.com>
On Wed, 4 Nov 2009 00:52:28 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> On Wednesday 04 November 2009 00:48:35 Alan Cox wrote:
> > > > Yeah I know that. But like I said, I still needed to get around to do that,
> > > > and I am very happy you were interested in fixing it.
> > >
> > > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
> >
> > Really - you have a service and support contract with Ivo.. no i thought
> > not.
>
> Just today I got PM from somebody complaining to me about non-working
> pata_pdc2026x_old (pdc202xx_old works fine for him) simply because
> I fixed some bug there some time ago....
And didn't bother committing a patch to both sets of code bec
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-04 0:48 UTC (permalink / raw)
To: Alan Cox
Cc: Ivo van Doorn, linux-wireless, linux-kernel, netdev, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <20091104004015.23c4c1a3@lxorguk.ukuu.org.uk>
On Wednesday 04 November 2009 01:40:15 Alan Cox wrote:
> On Wed, 4 Nov 2009 00:52:28 +0100
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
>
> > On Wednesday 04 November 2009 00:48:35 Alan Cox wrote:
> > > > > Yeah I know that. But like I said, I still needed to get around to do that,
> > > > > and I am very happy you were interested in fixing it.
> > > >
> > > > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
> > >
> > > Really - you have a service and support contract with Ivo.. no i thought
> > > not.
> >
> > Just today I got PM from somebody complaining to me about non-working
> > pata_pdc2026x_old (pdc202xx_old works fine for him) simply because
> > I fixed some bug there some time ago....
>
> And didn't bother committing a patch to both sets of code bec
You misread my mail.
Because I also fixed bug in the PATA code though I was IDE Maintainer.
Also:
Did you have a service & support contract with me when you were complaining
about IDE to me? [ and I would strongly suggest you not to go there.. ]
Or reversing the initial question:
Does Ivo have a contract with me to contribute to rt2x00 project?
So please stop idiotic arguments.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Julian Calaby @ 2009-11-04 1:33 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Gertjan van Wingerde, Ivo van Doorn,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap, Luis Correia,
John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Pekka Enberg, David Miller
In-Reply-To: <200911040046.54247.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Nov 4, 2009 at 10:46, Bartlomiej Zolnierkiewicz
<bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> If you just want to continue with a hostile take-over of the rt2800
>> maintainership, then please
>> let us know that, so that we stop spending time on useless
>
> I fail to see why you see it as a hostile takeover.
Updating MAINTAINERS to replace the current developers with yourself
can be considered to be a hostile act.
If you want this for your own personal tree, then keep the patch
private - don't include it in pull requests, patch listings etc.
And if you genuinely want the maintainership of the rt28xx drivers,
then updating MAINTAINERS should be done as an afterthought after
clearly proving that you are capable of maintaining the driver and
working with the maintainers of the rt2x00 and wireless subsystems.
> I will be glad to cooperate with you or anyone else from rt2x00 project.
> However I will not spin in some stupid bureaucracy when I see that things
> can be done more effectively.
It's not "stupid bureaucracy" it's *how* *it's* *done*.
If I was going to submit a patch to the Marvell TOPDOG driver to add
support for another related chipset, I'd be going out of my way to
make sure that *everyone* involved was 100% happy so that the patch
can get out to the people who matter: the users.
Everyone has to do this, from big corporations like Intel, to you and
me. For example, I recall the Intel IWL developers being smacked down
a few months ago by John and David over exactly what constitutes a
post-merge window "bugfix".
The rules apply to everyone, just because you don't like them doesn't
mean you can ignore them.
Thanks,
--
Julian Calaby
Email: julian.calaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
.Plan: http://sites.google.com/site/juliancalaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] trivial: remove duplicated MIN macro from tehuti.
From: Yang Hongyang @ 2009-11-04 1:36 UTC (permalink / raw)
To: Thiago Farina
Cc: trivial, baum, andy, davem, shemminger, apkm, ben, netdev,
linux-kernel
In-Reply-To: <1257194714-5218-1-git-send-email-tfransosi@gmail.com>
Thiago Farina wrote:
> Since the kernel api already has the macro "min",
> just use it instead of declaring another one.
>
> Signed-off-by: Thiago Farina <tfransosi@gmail.com>
> ---
> drivers/net/tehuti.c | 4 ++--
> drivers/net/tehuti.h | 2 --
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/tehuti.c b/drivers/net/tehuti.c
> index ec9dfb2..8d116a9 100644
> --- a/drivers/net/tehuti.c
> +++ b/drivers/net/tehuti.c
> @@ -1878,7 +1878,7 @@ static void bdx_tx_push_desc_safe(struct bdx_priv *priv, void *data, int size)
> udelay(50); /* give hw a chance to clean fifo */
> continue;
> }
> - avail = MIN(avail, size);
> + avail = min(avail, size);
> DBG("about to push %d bytes starting %p size %d\n", avail,
> data, size);
> bdx_tx_push_desc(priv, data, avail);
> @@ -1889,7 +1889,7 @@ static void bdx_tx_push_desc_safe(struct bdx_priv *priv, void *data, int size)
> }
>
> static const struct net_device_ops bdx_netdev_ops = {
> - .ndo_open = bdx_open,
> + .ndo_open = bdx_open,
Why are you change TAB to SPACES here?
> .ndo_stop = bdx_close,
> .ndo_start_xmit = bdx_tx_transmit,
> .ndo_validate_addr = eth_validate_addr,
> diff --git a/drivers/net/tehuti.h b/drivers/net/tehuti.h
> index 4fc875e..1241419 100644
> --- a/drivers/net/tehuti.h
> +++ b/drivers/net/tehuti.h
> @@ -76,8 +76,6 @@
> #define FIFO_SIZE 4096
> #define FIFO_EXTRA_SPACE 1024
>
> -#define MIN(x, y) ((x) < (y) ? (x) : (y))
> -
> #if BITS_PER_LONG == 64
> # define H32_64(x) (u32) ((u64)(x) >> 32)
> # define L32_64(x) (u32) ((u64)(x) & 0xffffffff)
--
Regards
Yang Hongyang
^ permalink raw reply
* kernel WARNING/BUG with IOMMU + skb_dma_map/unmap + pktgen
From: Alexander Duyck @ 2009-11-04 1:44 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Tantilov, Emil S, davem@davemloft.net, dwmw2
It looks like skb_dma_map/unmap plus trying to transmit multiple copies
of the same skb via pktgen doesn't work when a hardware IOMMU is enabled.
We first saw this on igb doing a loopback test partially due to the fact
that I had copied the approach used by pktgen of just incrementing the
user count and sending the same skb into the transmit path multiple
times. However we did some testing to verify that this is reproducible
on other NICs using skb_dma_map/unmap and pktgen and generated the
traces below on a tg3 w/ pktgen configured to clone_skb several times.
The issue seems to be due to the fact that skb_dma_map assumes that
dma_map_single/page should return the same value every time it is
called, however in the case of having a hardware iommu enabled this is
not so and as a result we end up leaking dma mappings and then attempt
multiple unmaps on the last dma mapping we received.
I'm wondering if this is a valid issue since I am not sure how many
different situations will result in a skb being cloned and sent either
to the same device multiple times or to multiple devices. Also I am
looking for suggestions on how best to address this without negatively
impacting TX performance.
Thanks,
Alex
DRHD: handling fault status reg 2
DMAR:[DMA Read] Request device [05:00.0] fault addr ffb9c000
DMAR:[fault reason 06] PTE Read access is not set
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:798 check_unmap+0x158/0x5bf()
Hardware name: S5520HC
tg3 0000:05:00.0: DMA-API: device driver tries to free DMA memory it has
not allocated [device address=0x00000000ffb9c822] [size=1200 bytes]
Modules linked in: pktgen tg3 ipv6 autofs4 sunrpc cpufreq_ondemand
acpi_cpufreq freq_table video output sbs sbshc joydev shpchp iTCO_wdt
i2c_i801 i2c_core pcspkr iTCO_vendor_support usb_storage [last unloaded:
igb]
Pid: 8701, comm: kpktgend_0 Not tainted
2.6.32-rc3-net-next-igb-tag110309 #12
Call Trace:
<IRQ> [<ffffffff811c2500>] ? check_unmap+0x158/0x5bf
[<ffffffff81046006>] warn_slowpath_common+0x77/0x8f
[<ffffffff810460ce>] warn_slowpath_fmt+0x9f/0xa1
[<ffffffff8137fca5>] ? _spin_lock_irqsave+0x44/0x50
[<ffffffff811c182f>] ? get_hash_bucket+0x28/0x33
[<ffffffff8106c648>] ? register_lock_class+0x20/0x29f
[<ffffffff811c2500>] check_unmap+0x158/0x5bf
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffff8100e020>] ? do_IRQ+0x97/0xae
[<ffffffff811c2b11>] debug_dma_unmap_page+0x80/0x92
[<ffffffff811dcea8>] ? intel_unmap_page+0xf6/0x103
[<ffffffff812e1dd9>] dma_unmap_single_attrs+0x5c/0x68
[<ffffffff812e2043>] skb_dma_unmap+0x3f/0x78
[<ffffffffa01a8890>] tg3_poll+0x172/0x77d [tg3]
[<ffffffff812e2f84>] ? rcu_read_lock+0x0/0x3a
[<ffffffff812e7ff1>] net_rx_action+0xbc/0x19f
[<ffffffff8104bcf1>] __do_softirq+0xd5/0x19d
[<ffffffff8100cc9c>] call_softirq+0x1c/0x34
<EOI> [<ffffffff8100e2d8>] do_softirq+0x33/0x6b
[<ffffffff8104b541>] _local_bh_enable_ip+0x78/0xa7
[<ffffffff8104b579>] local_bh_enable_ip+0x9/0xb
[<ffffffff8137f9a2>] _spin_unlock_bh+0x39/0x3d
[<ffffffffa004a2c3>] pktgen_xmit+0xf5f/0xfe3 [pktgen]
[<ffffffffa01a65f7>] ? tg3_start_xmit_dma_bug+0x0/0x7cd [tg3]
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffffa004a3e5>] ? pktgen_thread_worker+0x9e/0x660 [pktgen]
[<ffffffffa004a4ed>] pktgen_thread_worker+0x1a6/0x660 [pktgen]
[<ffffffff8103236b>] ? need_resched+0x1e/0x28
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffffa004a347>] ? pktgen_thread_worker+0x0/0x660 [pktgen]
[<ffffffff8105e459>] kthread+0x69/0x71
[<ffffffff8100cb9a>] child_rip+0xa/0x20
[<ffffffff8105e3f0>] ? kthread+0x0/0x71
[<ffffffff8100cb90>] ? child_rip+0x0/0x20
---[ end trace 39dadbc5c44cf3fd ]---
------------[ cut here ]------------
WARNING: at drivers/pci/intel-iommu.c:2719 intel_unmap_page+0x8e/0x103()
Hardware name: S5520HC
Driver unmaps unmatched page at PFN ffb9c822
Modules linked in: pktgen tg3 ipv6 autofs4 sunrpc cpufreq_ondemand
acpi_cpufreq freq_table video output sbs sbshc joydev shpchp iTCO_wdt
i2c_i801 i2c_core pcspkr iTCO_vendor_support usb_storage [last unloaded:
igb]
Pid: 8701, comm: kpktgend_0 Tainted: G W
2.6.32-rc3-net-next-igb-tag110309 #12
Call Trace:
<IRQ> [<ffffffff811dce40>] ? intel_unmap_page+0x8e/0x103
[<ffffffff81046006>] warn_slowpath_common+0x77/0x8f
[<ffffffff810460ce>] warn_slowpath_fmt+0x9f/0xa1
[<ffffffff811dac28>] ? find_iova+0x18/0x66
[<ffffffff8137fa55>] ? _spin_unlock_irqrestore+0x57/0x5c
[<ffffffff811dac6b>] ? find_iova+0x5b/0x66
[<ffffffff811dce40>] intel_unmap_page+0x8e/0x103
[<ffffffff812e1dc3>] dma_unmap_single_attrs+0x46/0x68
[<ffffffff812e2043>] skb_dma_unmap+0x3f/0x78
[<ffffffffa01a8890>] tg3_poll+0x172/0x77d [tg3]
[<ffffffff812e2f84>] ? rcu_read_lock+0x0/0x3a
[<ffffffff812e7ff1>] net_rx_action+0xbc/0x19f
[<ffffffff8104bcf1>] __do_softirq+0xd5/0x19d
[<ffffffff8100cc9c>] call_softirq+0x1c/0x34
<EOI> [<ffffffff8100e2d8>] do_softirq+0x33/0x6b
[<ffffffff8104b541>] _local_bh_enable_ip+0x78/0xa7
[<ffffffff8104b579>] local_bh_enable_ip+0x9/0xb
[<ffffffff8137f9a2>] _spin_unlock_bh+0x39/0x3d
[<ffffffffa004a2c3>] pktgen_xmit+0xf5f/0xfe3 [pktgen]
[<ffffffffa01a65f7>] ? tg3_start_xmit_dma_bug+0x0/0x7cd [tg3]
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffffa004a3e5>] ? pktgen_thread_worker+0x9e/0x660 [pktgen]
[<ffffffffa004a4ed>] pktgen_thread_worker+0x1a6/0x660 [pktgen]
[<ffffffff8103236b>] ? need_resched+0x1e/0x28
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffffa004a347>] ? pktgen_thread_worker+0x0/0x660 [pktgen]
[<ffffffff8105e459>] kthread+0x69/0x71
[<ffffffff8100cb9a>] child_rip+0xa/0x20
[<ffffffff8105e3f0>] ? kthread+0x0/0x71
[<ffffffff8100cb90>] ? child_rip+0x0/0x20
---[ end trace 39dadbc5c44cf3fe ]---
------------[ cut here ]------------
kernel BUG at drivers/pci/iova.c:155!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
last sysfs file:
/sys/devices/pci0000:00/0000:00:1e.0/0000:0a:00.0/local_cpus
CPU 0
Modules linked in: pktgen tg3 ipv6 autofs4 sunrpc cpufreq_ondemand
acpi_cpufreq freq_table video output sbs sbshc joydev shpchp iTCO_wdt
i2c_i801 i2c_core pcspkr iTCO_vendor_support usb_storage [last unloaded:
igb]
Pid: 8701, comm: kpktgend_0 Tainted: G W
2.6.32-rc3-net-next-igb-tag110309 #12 S5520HC
RIP: 0010:[<ffffffff811db065>] [<ffffffff811db065>] alloc_iova+0x174/0x1d7
RSP: 0018:ffff88036570fac0 EFLAGS: 00010046
RAX: 00000000000ffb9b RBX: ffff8801e78d4180 RCX: 0000000000000000
RDX: ffff8801e73ba710 RSI: ffff8801e73ba700 RDI: 0000000000000001
RBP: ffff88036570fb20 R08: 0000000000000000 R09: ffff880100000000
R10: ffffffff811daf48 R11: 0000fffffffff000 R12: 00000000000ffb9b
R13: 0000000000000001 R14: ffff8801e5cad520 R15: ffff8801e73ba700
FS: 0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00007fef515530a0 CR3: 0000000001001000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kpktgend_0 (pid: 8701, threadinfo ffff88036570e000, task
ffff8803661d3fc0)
Stack:
ffffffff81e5a328 ffffffff81e5a310 00000000000fffff 0000000000000286
<0> 01ff8801e88de890 ffffffff81e5a310 ffff8801e78d4180 ffff8801e88de890
<0> 0000fffffffff000 ffff8801e5cad500 0000000000000001 ffff8801e88de890
Call Trace:
[<ffffffff811dd992>] intel_alloc_iova+0x68/0xb4
[<ffffffff811ddc3a>] __intel_map_single+0x7d/0x152
[<ffffffff811ddd0f>] ? intel_map_page+0x0/0x3e
[<ffffffff811ddd4b>] intel_map_page+0x3c/0x3e
[<ffffffff812e1e77>] skb_dma_map+0x92/0x21f
[<ffffffff81039012>] ? finish_task_switch+0x7c/0x9e
[<ffffffffa01a6976>] tg3_start_xmit_dma_bug+0x37f/0x7cd [tg3]
[<ffffffffa004a1ef>] ? pktgen_xmit+0xe8b/0xfe3 [pktgen]
[<ffffffffa004a230>] pktgen_xmit+0xecc/0xfe3 [pktgen]
[<ffffffffa01a65f7>] ? tg3_start_xmit_dma_bug+0x0/0x7cd [tg3]
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffffa004a3e5>] ? pktgen_thread_worker+0x9e/0x660 [pktgen]
[<ffffffffa004a4ed>] pktgen_thread_worker+0x1a6/0x660 [pktgen]
[<ffffffff8103236b>] ? need_resched+0x1e/0x28
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffffa004a347>] ? pktgen_thread_worker+0x0/0x660 [pktgen]
[<ffffffff8105e459>] kthread+0x69/0x71
[<ffffffff8100cb9a>] child_rip+0xa/0x20
[<ffffffff8105e3f0>] ? kthread+0x0/0x71
[<ffffffff8100cb90>] ? child_rip+0x0/0x20
Code: 05 ff 49 89 47 18 48 83 7d d0 00 75 04 49 8d 56 30 31 c0 eb 1d 48
8b 46 20 48 8d 56 10 49 39 47 20 72 0c 76 06 48 8d 56 08 eb 04 <0f> 0b
eb fe 48 89 f0 48 8b 32 48 85 f6 75 db 48 89 c6 4c 89 ff
RIP [<ffffffff811db065>] alloc_iova+0x174/0x1d7
RSP <ffff88036570fac0>
---[ end trace 39dadbc5c44cf3ff ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 8701, comm: kpktgend_0 Tainted: G D W
2.6.32-rc3-net-next-igb-tag110309 #12
Call Trace:
[<ffffffff810461c4>] panic+0xe5/0x195
[<ffffffff8137fa4c>] ? _spin_unlock_irqrestore+0x4e/0x5c
[<ffffffff81046860>] ? release_console_sem+0x19e/0x1ab
[<ffffffff81046a8b>] ? console_unblank+0x65/0x69
[<ffffffff81045e36>] ? print_oops_end_marker+0x1e/0x20
[<ffffffff81380d8f>] oops_end+0xaa/0xba
[<ffffffff8100f41d>] die+0x55/0x5e
[<ffffffff813806b2>] do_trap+0x110/0x11f
[<ffffffff8100d4bb>] do_invalid_op+0x91/0x9a
[<ffffffff811db065>] ? alloc_iova+0x174/0x1d7
[<ffffffff8137faa4>] ? _spin_unlock+0x4a/0x57
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffff8100c935>] invalid_op+0x15/0x20
[<ffffffff811daf48>] ? alloc_iova+0x57/0x1d7
[<ffffffff811db065>] ? alloc_iova+0x174/0x1d7
[<ffffffff811dd992>] intel_alloc_iova+0x68/0xb4
[<ffffffff811ddc3a>] __intel_map_single+0x7d/0x152
[<ffffffff811ddd0f>] ? intel_map_page+0x0/0x3e
[<ffffffff811ddd4b>] intel_map_page+0x3c/0x3e
[<ffffffff812e1e77>] skb_dma_map+0x92/0x21f
[<ffffffff81039012>] ? finish_task_switch+0x7c/0x9e
[<ffffffffa01a6976>] tg3_start_xmit_dma_bug+0x37f/0x7cd [tg3]
[<ffffffffa004a1ef>] ? pktgen_xmit+0xe8b/0xfe3 [pktgen]
[<ffffffffa004a230>] pktgen_xmit+0xecc/0xfe3 [pktgen]
[<ffffffffa01a65f7>] ? tg3_start_xmit_dma_bug+0x0/0x7cd [tg3]
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffffa004a3e5>] ? pktgen_thread_worker+0x9e/0x660 [pktgen]
[<ffffffffa004a4ed>] pktgen_thread_worker+0x1a6/0x660 [pktgen]
[<ffffffff8103236b>] ? need_resched+0x1e/0x28
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffffa004a347>] ? pktgen_thread_worker+0x0/0x660 [pktgen]
[<ffffffff8105e459>] kthread+0x69/0x71
[<ffffffff8100cb9a>] child_rip+0xa/0x20
[<ffffffff8105e3f0>] ? kthread+0x0/0x71
[<ffffffff8100cb90>] ? child_rip+0x0/0x20
------------[ cut here ]------------
WARNING: at arch/x86/kernel/smp.c:117 native_smp_send_reschedule+0x25/0x43()
Hardware name: S5520HC
Modules linked in: pktgen tg3 ipv6 autofs4 sunrpc cpufreq_ondemand
acpi_cpufreq freq_table video output sbs sbshc joydev shpchp iTCO_wdt
i2c_i801 i2c_core pcspkr iTCO_vendor_support usb_storage [last unloaded:
igb]
Pid: 8701, comm: kpktgend_0 Tainted: G D W
2.6.32-rc3-net-next-igb-tag110309 #12
Call Trace:
<IRQ> [<ffffffff81034a05>] ? __enqueue_entity+0x74/0x76
[<ffffffff8101eefc>] ? native_smp_send_reschedule+0x25/0x43
[<ffffffff81046006>] warn_slowpath_common+0x77/0x8f
[<ffffffff8104602d>] warn_slowpath_null+0xf/0x11
[<ffffffff8101eefc>] native_smp_send_reschedule+0x25/0x43
[<ffffffff8102ff5d>] smp_send_reschedule+0xa/0xc
[<ffffffff810324ea>] resched_task+0x67/0x6c
[<ffffffff81032585>] check_preempt_curr_idle+0x10/0x12
[<ffffffff81030056>] check_preempt_curr+0x12/0x14
[<ffffffff8103dfbf>] try_to_wake_up+0x249/0x2b2
[<ffffffff8103e035>] default_wake_function+0xd/0xf
[<ffffffff8105e6a4>] autoremove_wake_function+0x11/0x38
[<ffffffff81030bad>] __wake_up_common+0x41/0x74
[<ffffffff810341d8>] __wake_up+0x38/0x4f
[<ffffffff810468c0>] printk_tick+0x53/0x58
[<ffffffff81051f13>] update_process_times+0x3e/0x54
[<ffffffff8106b278>] tick_sched_timer+0x70/0x99
[<ffffffff8106b208>] ? tick_sched_timer+0x0/0x99
[<ffffffff81061101>] __run_hrtimer+0xba/0x121
[<ffffffff8106125e>] hrtimer_interrupt+0xf6/0x152
[<ffffffff81096d71>] ? rcu_irq_enter+0x15/0x63
[<ffffffff81020124>] smp_apic_timer_interrupt+0x73/0x87
[<ffffffff8100c673>] apic_timer_interrupt+0x13/0x20
<EOI> [<ffffffff81382434>] ? __atomic_notifier_call_chain+0x0/0xb2
[<ffffffff81382434>] ? __atomic_notifier_call_chain+0x0/0xb2
[<ffffffff81046252>] ? panic+0x173/0x195
[<ffffffff810461e6>] ? panic+0x107/0x195
[<ffffffff8137fa4c>] ? _spin_unlock_irqrestore+0x4e/0x5c
[<ffffffff81046860>] ? release_console_sem+0x19e/0x1ab
[<ffffffff81046a8b>] ? console_unblank+0x65/0x69
[<ffffffff81045e36>] ? print_oops_end_marker+0x1e/0x20
[<ffffffff81380d8f>] ? oops_end+0xaa/0xba
[<ffffffff8100f41d>] ? die+0x55/0x5e
[<ffffffff813806b2>] ? do_trap+0x110/0x11f
[<ffffffff8100d4bb>] ? do_invalid_op+0x91/0x9a
[<ffffffff811db065>] ? alloc_iova+0x174/0x1d7
[<ffffffff8137faa4>] ? _spin_unlock+0x4a/0x57
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffff8100c935>] ? invalid_op+0x15/0x20
[<ffffffff811daf48>] ? alloc_iova+0x57/0x1d7
[<ffffffff811db065>] ? alloc_iova+0x174/0x1d7
[<ffffffff811dd992>] ? intel_alloc_iova+0x68/0xb4
[<ffffffff811ddc3a>] ? __intel_map_single+0x7d/0x152
[<ffffffff811ddd0f>] ? intel_map_page+0x0/0x3e
[<ffffffff811ddd4b>] ? intel_map_page+0x3c/0x3e
[<ffffffff812e1e77>] ? skb_dma_map+0x92/0x21f
[<ffffffff81039012>] ? finish_task_switch+0x7c/0x9e
[<ffffffffa01a6976>] ? tg3_start_xmit_dma_bug+0x37f/0x7cd [tg3]
[<ffffffffa004a1ef>] ? pktgen_xmit+0xe8b/0xfe3 [pktgen]
[<ffffffffa004a230>] ? pktgen_xmit+0xecc/0xfe3 [pktgen]
[<ffffffffa01a65f7>] ? tg3_start_xmit_dma_bug+0x0/0x7cd [tg3]
[<ffffffff8106ccb9>] ? __lock_acquire+0x20d/0x3ce
[<ffffffffa004a3e5>] ? pktgen_thread_worker+0x9e/0x660 [pktgen]
[<ffffffffa004a4ed>] ? pktgen_thread_worker+0x1a6/0x660 [pktgen]
[<ffffffff8103236b>] ? need_resched+0x1e/0x28
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffff8105e693>] ? autoremove_wake_function+0x0/0x38
[<ffffffffa004a347>] ? pktgen_thread_worker+0x0/0x660 [pktgen]
[<ffffffff8105e459>] ? kthread+0x69/0x71
[<ffffffff8100cb9a>] ? child_rip+0xa/0x20
[<ffffffff8105e3f0>] ? kthread+0x0/0x71
[<ffffffff8100cb90>] ? child_rip+0x0/0x20
---[ end trace 39dadbc5c44cf400 ]---
^ permalink raw reply
* Re: [PATCH] sch_htb.c consume the classes's tokens bellow the HTB_CAN_SEND level
From: Changli Gao @ 2009-11-04 1:53 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Jamal Hadi Salim, devik, netdev
In-Reply-To: <20091103230035.GA2352@ami.dom.local>
On Wed, Nov 4, 2009 at 7:00 AM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> On Tue, Nov 03, 2009 at 09:18:49PM +0800, Changli Gao wrote:
>> On Tue, Nov 3, 2009 at 6:05 PM, Jarek Poplawski <jarkao2@gmail.com> wrote:
>> >
>> > The ceil specification is controlled only by ctokens, which are always
>> > updated, so no such risk.
>> >
>> Nevertheless, updating tokens is necessary too.
>
> If it's really necessary you should present some test case fixed by
> your patch, I guess.
>
> In the meantime let's consider what could be broken:
> class 1:1 (parent) rate 10 packets/sec
> class 1:2 rate 5 packets/sec ceil 10 packets/sec
> class 1:3 rate 5 packets/sec ceil 10 packets/sec
>
> class 1:2 doesn't use all its rate, and sends every other second
> (in even seconds)
> class 1:3 sends 10 packets during the first second, so with your
> patch it will use its tokens for 2 seconds
> class 1:2 uses its rate in the second second..., so class 1:1
> can't lend anything
> class 1:3 can only borrow, so it won't be able to send during
> this second anything
>
> So, the effect would be class 1:3 sending every odd second 10 packets
> while every even second - nothing...
class 1:3 can send, as its parent rate is 10, but class 1:2 only uses
half of it, and class 1:1 is still in HTB_CAN_SEND mode.
The result is, hasn't any difference with or without my patch :
class 1:1 sends 10 packets in odd seconds, and 5 packets in even seconds.
class 1:2 sends 5 packets in even seconds.
class 1:1 (parent) sends 10 packets in every second.
Let's think this case in another way: which class sends packets in
even seconds first, class 1:2 or class 1:3.
With my patch, as 1:3 in HTB_MAY_BORROW mode, and 1:2 in HTB_CAN_SEND
mode, so 1:2 sends all its 5 packets first.
Without my patch, as 1:2 and 1:3 are both in HTB_CAN_SEND mode, the
sequence is undetermined. In other word, 1:2 and 1:3 are treated
fairly, and it isn't fair for 1:2, because 1:2 sends nothing in odd
seconds, and has no deficit in rate as 1:3.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: 2.6.32-rc5-mmotm1101 - kernel BUG at net/ipv4/tcp_input.c:3707!
From: Valdis.Kletnieks @ 2009-11-04 2:01 UTC (permalink / raw)
To: Ilpo JÀrvinen
Cc: Gilad Ben-Yossef, Eric Dumazet, Andrew Morton, linux-kernel,
netdev, Ori Finkelman
In-Reply-To: <Pine.LNX.4.64.0911032330090.3488@melkinkari.cs.Helsinki.FI>
[-- Attachment #1: Type: text/plain, Size: 3428 bytes --]
On Tue, 03 Nov 2009 23:34:19 +0200, Ilpo JÀrvinen said:
> On Tue, 3 Nov 2009, Gilad Ben-Yossef wrote:
>
> > Eric Dumazet wrote:
> >
> > > Valdis.Kletnieks@vt.edu a écrit :
> > >
> > > > Seen right after I started 'fetchmail'. Reproducible - 3 out of 3.
> > > > I'll bisect this tonight if nobody jumps up and yells they know what it
> > > > is...
> > > >
> > Bah... this is most probably my fault. Sorry about that.
> >
> > Can you please try the patch in the next email?
Tried while at home, machine panic'ed. No netconsole here at the moment, sorry.
> > But also, can you please send me the route table in effect when this happened
> > and the fetchmail command line/config (removing any passwords or account
> > details of course)? I want to understand better when this happens.
% route -n -A inet
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
128.173.12.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
0.0.0.0 128.173.12.1 0.0.0.0 UG 0 0 0 eth0
% route -n -A inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::1/128 :: U 0 687 1 lo
2001:468:c80:2103:215:c5ff:fec8:334e/128 :: U 0 53533 1 lo
2001:468:c80:2103::/64 :: UA 256 316 0 eth0
fe80::215:c5ff:fec8:334e/128 :: U 0 176 1 lo
fe80::218:deff:fe9c:24e0/128 :: U 0 0 1 lo
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 wlan0
ff02::1/128 ff02::1 UC 0 451 0 eth0
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 wlan0
::/0 fe80::20f:35ff:fe3e:d41a UGDA 1024 2082 1 eth0
Command line was just 'fetchmail'. Relevant .fetchmailrc:
set postmaster "valdis"
set bouncemail
set no spambounce
set properties ""
set daemon 240
poll imap.vt.edu with proto IMAP and options
user 'valdis' there with password 'redacted' is 'valdis' here ssl fetchsizelimit 0 smtpaddress turing-police.cc.vt.edu
(imap.vt.edu is 198.82.183.77 - so off the local subnet)
> According to the stacktrace, it came from ipv6 side which doesn't have any
> null checking what so ever atm (you only handled ipv4 correctly). ...You
> should be a bit more careful next time when adding any BUG_ONs...
Why was this blowing chunks in the IPv6 when I was making an IPv4 connection
then? I just noticed that. My fetchmail can't make an IPv6 TCP connection to
our IMAP server because the server isn't v6-enabled yet. And although I
contact our DNS over IPv6, but that's UDP not TCP.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Karol Lewandowski @ 2009-11-04 2:03 UTC (permalink / raw)
To: Mel Gorman
Cc: Karol Lewandowski, Frans Pop, Jiri Kosina, Sven Geggus,
Tobias Oetiker, Rafael J. Wysocki, David Miller, Reinette Chatre,
Kalle Valo, David Rientjes, KOSAKI Motohiro, Mohamed Abbas,
Jens Axboe, John W. Linville, Pekka Enberg,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman,
Stephan von Krawczynski, Kernel Testers List,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
In-Reply-To: <20091102203034.GC22046-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
On Mon, Nov 02, 2009 at 08:30:34PM +0000, Mel Gorman wrote:
> Does applying the following on top make any difference?
>
> ==== CUT HERE ====
> PM: Shrink memory before suspend
No, this patch didn't change anything either.
IIRC I get failures while free(1) shows as much as 20MB free RAM
(ie. without buffers/caches). Additionaly nr_free_pages (from
/proc/vmstat) stays at about 800-1000 under heavy memory pressure
(gitk on full linux repository).
--- babbling follows ---
Hmm, I wonder if it's really timing issue then wouldn't be the case
that lowering swappiness sysctl would make problem more visible?
I've vm.swappiness=15, would testing with higher value make any sense?
Thanks.
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-04 2:28 UTC (permalink / raw)
To: Julian Calaby
Cc: Gertjan van Wingerde, Ivo van Doorn, linux-wireless, linux-kernel,
netdev, Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <646765f40911031733u1641c0dr5d4eec30031e7cea@mail.gmail.com>
On Wednesday 04 November 2009 02:33:52 Julian Calaby wrote:
> On Wed, Nov 4, 2009 at 10:46, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> >> If you just want to continue with a hostile take-over of the rt2800
> >> maintainership, then please
> >> let us know that, so that we stop spending time on useless
> >
> > I fail to see why you see it as a hostile takeover.
>
> Updating MAINTAINERS to replace the current developers with yourself
> can be considered to be a hostile act.
>
> If you want this for your own personal tree, then keep the patch
> private - don't include it in pull requests, patch listings etc.
This is not pull request etc. but since the change in question has been
stirring needless controversies and distracting people from reading patches
it has been dropped for now.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: kernel WARNING/BUG with IOMMU + skb_dma_map/unmap + pktgen
From: David Miller @ 2009-11-04 2:32 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, emil.s.tantilov, dwmw2
In-Reply-To: <4AF0DC81.10305@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue, 03 Nov 2009 17:44:33 -0800
> It looks like skb_dma_map/unmap plus trying to transmit multiple
> copies of the same skb via pktgen doesn't work when a hardware IOMMU
> is enabled.
This is just the tip of the iceburg as to why pktgen's scheme
to send the same SKB over and over again doesn't really work.
If it's referenced by a transmit, you really can't reuse it
again in the transmit path, even TCP has code that copies
when a SKB has a device reference on the transmit path.
I think we've just been lucky until now about this, as pktgen
doesn't usually attach other forms of shared state such as
netfilter conntrack info, and it doesn't care about the header
being mangled by the driver (since it emits pure UDP frames
this isn't likely to happen anyways).
But not with the SKB DMA map/unmap this becomes a real visible bug and
must be fixed.
^ permalink raw reply
* Re: 2.6.32-rc5-mmotm1101 - kernel BUG at net/ipv4/tcp_input.c:3707!
From: David Miller @ 2009-11-04 2:34 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: ilpo.jarvinen, gilad, eric.dumazet, akpm, linux-kernel, netdev,
ori
In-Reply-To: <7916.1257300093@turing-police.cc.vt.edu>
From: Valdis.Kletnieks@vt.edu
Date: Tue, 03 Nov 2009 21:01:33 -0500
> Why was this blowing chunks in the IPv6 when I was making an IPv4 connection
> then? I just noticed that. My fetchmail can't make an IPv6 TCP connection to
> our IMAP server because the server isn't v6-enabled yet. And although I
> contact our DNS over IPv6, but that's UDP not TCP.
Many things IPV6 capable will go through the IPV4 compat
path of the IPV6 stack, depending upon how listening sockets
configure themselves etc.
^ permalink raw reply
* Re: HTB accuracy on 10GbE
From: Ryousei Takano @ 2009-11-04 3:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Patrick McHardy, Linux Netdev List, takano-ryousei
In-Reply-To: <20091102125345.3c39c42e@nehalam>
Hi Patrick and Stephen,
Thanks for your comments.
I retried on the newer kernel and iproute2, and added the experimental result
on my page. Please see 'Experimental result 2':
http://code.google.com/p/pspacer/wiki/HTBon10GbE
The accuracy improves compared with the previous experiment.
The difference reduces from +810 Mbps to +430 Mbps.
It is because the timer resolution improves from 1 usec to 1/64 usec.
But it is not perfect.
Best regards,
Ryousei Takano
On Tue, Nov 3, 2009 at 5:53 AM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Mon, 02 Nov 2009 16:43:42 +0100
> Patrick McHardy <kaber@trash.net> wrote:
>
>> Ryousei Takano wrote:
>> > Hi Stephen and all,
>> >
>> > I have observed a HTB accuracy problem on the Linux kernel 2.6.30 and
>> > the Myri-10G 10 GbE NIC.
>> > HTB can control the transmission rate at Gigabit speed, however it can
>> > not work well at 10 Gigabit speed.
>> >
>> > I asked Stephen this problem at Japan Linux Symposium. He mentioned a
>> > HTB bug related to the timer granularity.
>> > I want to know what is happen, and what should be do for fixing it.
>> >
>> > Any comments and suggestions will be welcome.
>> >
>> > For more detail, please see the following page:
>> > http://code.google.com/p/pspacer/wiki/HTBon10GbE
>>
>> This is not an easy problem to fix. Userspace, the kernel and the
>> netlink API use 32 bit for timing related values, which is too small
>> to use more than microsecond resolution. All of them need to be
>> converted to use bigger types, additionally some kind of compatibility
>> handling to deal with old iproute versions still using microsecond
>> resolution is required.
>
> The existing API is a legacy mish-mash. The field is limited to 32 bits,
> but it might be possible to use a finer scale.
>
> Maybe if kernel advertised finer resolution through /proc/net/psched
> then table could be finer grained. This would maintain compatibility
> between kernel and user space. You would need to have new kernel and
> new iproute to get nanosecond resolution but older combinations would
> still work.
>
> The downside is that by using nanosecond resolution the rates are upper
> bounded at 4.2seconds / packet.
>
>
^ permalink raw reply
* Re: [PATCH] usbnet: Do not implement ethtool get_link() if link state is unknown
From: Ben Hutchings @ 2009-11-04 3:20 UTC (permalink / raw)
To: David Miller; +Cc: david-b, greg, jacmet, steve.glendinning, netdev
In-Reply-To: <20091103.020444.120631587.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
On Tue, 2009-11-03 at 02:04 -0800, David Miller wrote:
> From: David Brownell <david-b@pacbell.net>
> Date: Tue, 3 Nov 2009 02:41:27 -0700
>
> > On Tuesday 03 November 2009, David Miller wrote:
> >> All kidding aside, I think the alternative is for the USB network
> >> driver to call ethtool_op_get_link() if it cannot determine the
> >> link state in hardware.
> >
> > There's usbnet_get_link() which does just that. But
> > there may be some ancient debris confusing things.
>
> It's perfect, and Ben's patch is completely unnecessary.
I don't see how it's 'perfect' since it reports the link as up where it
is really unknown. Still, this is a fairly minor bug.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: HTB accuracy on 10GbE
From: Ryousei Takano @ 2009-11-04 3:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Patrick McHardy, Linux Netdev List, takano-ryousei
In-Reply-To: <b30d1c3b0911031913k2c922935vc9605b76ac43168f@mail.gmail.com>
On Wed, Nov 4, 2009 at 12:13 PM, Ryousei Takano <ryousei@gmail.com> wrote:
> Hi Patrick and Stephen,
>
> Thanks for your comments.
>
> I retried on the newer kernel and iproute2, and added the experimental result
> on my page. Please see 'Experimental result 2':
> http://code.google.com/p/pspacer/wiki/HTBon10GbE
>
> The accuracy improves compared with the previous experiment.
> The difference reduces from +810 Mbps to +430 Mbps.
> It is because the timer resolution improves from 1 usec to 1/64 usec.
> But it is not perfect.
>
Oops, not 1/64 usec but 1/16 usec.
> Best regards,
> Ryousei Takano
>
>
> On Tue, Nov 3, 2009 at 5:53 AM, Stephen Hemminger <shemminger@vyatta.com> wrote:
>> On Mon, 02 Nov 2009 16:43:42 +0100
>> Patrick McHardy <kaber@trash.net> wrote:
>>
>>> Ryousei Takano wrote:
>>> > Hi Stephen and all,
>>> >
>>> > I have observed a HTB accuracy problem on the Linux kernel 2.6.30 and
>>> > the Myri-10G 10 GbE NIC.
>>> > HTB can control the transmission rate at Gigabit speed, however it can
>>> > not work well at 10 Gigabit speed.
>>> >
>>> > I asked Stephen this problem at Japan Linux Symposium. He mentioned a
>>> > HTB bug related to the timer granularity.
>>> > I want to know what is happen, and what should be do for fixing it.
>>> >
>>> > Any comments and suggestions will be welcome.
>>> >
>>> > For more detail, please see the following page:
>>> > http://code.google.com/p/pspacer/wiki/HTBon10GbE
>>>
>>> This is not an easy problem to fix. Userspace, the kernel and the
>>> netlink API use 32 bit for timing related values, which is too small
>>> to use more than microsecond resolution. All of them need to be
>>> converted to use bigger types, additionally some kind of compatibility
>>> handling to deal with old iproute versions still using microsecond
>>> resolution is required.
>>
>> The existing API is a legacy mish-mash. The field is limited to 32 bits,
>> but it might be possible to use a finer scale.
>>
>> Maybe if kernel advertised finer resolution through /proc/net/psched
>> then table could be finer grained. This would maintain compatibility
>> between kernel and user space. You would need to have new kernel and
>> new iproute to get nanosecond resolution but older combinations would
>> still work.
>>
>> The downside is that by using nanosecond resolution the rates are upper
>> bounded at 4.2seconds / packet.
>>
>>
>
^ permalink raw reply
* Re: HTB accuracy on 10GbE
From: Eric Dumazet @ 2009-11-04 5:03 UTC (permalink / raw)
To: Ryousei Takano
Cc: Stephen Hemminger, Patrick McHardy, Linux Netdev List,
takano-ryousei
In-Reply-To: <b30d1c3b0911031913k2c922935vc9605b76ac43168f@mail.gmail.com>
Ryousei Takano a écrit :
> Hi Patrick and Stephen,
>
> Thanks for your comments.
>
> I retried on the newer kernel and iproute2, and added the experimental result
> on my page. Please see 'Experimental result 2':
> http://code.google.com/p/pspacer/wiki/HTBon10GbE
>
> The accuracy improves compared with the previous experiment.
> The difference reduces from +810 Mbps to +430 Mbps.
> It is because the timer resolution improves from 1 usec to 1/64 usec.
> But it is not perfect.
>
Hmm, do you know part of the error comes from the user tool itself ?
If you check iperf results at sender and receiver you'll see different
values, sender lies a bit.
Tried here on a Gbit link (I dont have 10Gbe yet)
$ ./iperf.bench.sh
.100 104
.200 206
.300 307
.400 413
.500 515
.600 610
.700 715
.800 822
.900 913
1.000 945
while on receiver :
[ 4] 0.0- 5.3 sec 62.8 MBytes 100 Mbits/sec
[ 5] 0.0- 5.1 sec 123 MBytes 202 Mbits/sec
[ 4] 0.0- 5.1 sec 183 MBytes 303 Mbits/sec
[ 5] 0.0- 5.1 sec 246 MBytes 409 Mbits/sec
[ 4] 0.0- 5.0 sec 307 MBytes 511 Mbits/sec
[ 5] 0.0- 5.0 sec 364 MBytes 607 Mbits/sec
[ 4] 0.0- 5.0 sec 427 MBytes 711 Mbits/sec
[ 5] 0.0- 5.0 sec 490 MBytes 818 Mbits/sec
[ 4] 0.0- 5.0 sec 545 MBytes 909 Mbits/sec
[ 5] 0.0- 5.0 sec 565 MBytes 941 Mbits/sec
You might use longer intervals to reduce this error (10 secs instead of 5 secs)
$./iperf.bench.sh
.100 102
.200 204
.300 305
.400 410
.500 513
.600 608
.700 713
.800 820
.900 911
1.000 943
^ permalink raw reply
* Re: HTB accuracy on 10GbE
From: Eric Dumazet @ 2009-11-04 5:27 UTC (permalink / raw)
To: Ryousei Takano
Cc: Stephen Hemminger, Patrick McHardy, Linux Netdev List,
takano-ryousei
In-Reply-To: <4AF10B1D.4050604@gmail.com>
Eric Dumazet a écrit :
>
> Hmm, do you know part of the error comes from the user tool itself ?
>
> If you check iperf results at sender and receiver you'll see different
> values, sender lies a bit.
>
> Tried here on a Gbit link (I dont have 10Gbe yet)
>
> $ ./iperf.bench.sh
> .100 104
> .200 206
> .300 307
> .400 413
> .500 515
> .600 610
> .700 715
> .800 822
> .900 913
> 1.000 945
>
(that was with standard 1500 MTU)
Now, with 9000 MTU and 50 seconds samples (instead of 5 s) I get :
$ ./iperf.bench.sh
.100 101
.200 200
.300 301
.400 401
.500 500
.600 601
.700 700
.800 803
.900 903
1.000 991
Not too bad :)
^ permalink raw reply
* Re: 2.6.32-rc5-mmotm1101 - kernel BUG at net/ipv4/tcp_input.c:3707!
From: Gilad Ben-Yossef @ 2009-11-04 6:27 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Valdis.Kletnieks, Eric Dumazet, Andrew Morton, linux-kernel,
netdev, Ori Finkelman
In-Reply-To: <Pine.LNX.4.64.0911032330090.3488@melkinkari.cs.Helsinki.FI>
Ilpo Järvinen wrote:
> On Tue, 3 Nov 2009, Gilad Ben-Yossef wrote:
>
>
>> Eric Dumazet wrote:
>>
>>
>>> Valdis.Kletnieks@vt.edu a écrit :
>>>
>>>
>>>> Seen right after I started 'fetchmail'. Reproducible - 3 out of 3.
>>>> I'll bisect this tonight if nobody jumps up and yells they know what it
>>>> is...
>>>>
>>>>
>> Bah... this is most probably my fault. Sorry about that.
>>
>> Can you please try the patch in the next email?
>>
>> But also, can you please send me the route table in effect when this happened
>> and the fetchmail command line/config (removing any passwords or account
>> details of course)? I want to understand better when this happens.
>>
>
> According to the stacktrace, it came from ipv6 side which doesn't have any
> null checking what so ever atm (you only handled ipv4 correctly). ...You
> should be a bit more careful next time when adding any BUG_ONs...
>
I agree, but for my defense I should add this was not just plain
carelessness, I believed
that the dst_entry cannot be NULL at that location. That was obviously
wrong. :-(
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker & CTO
Codefidence Ltd.
Web: http://codefidence.com
Cell: +972-52-8260388
Skype: gilad_codefidence
Tel: +972-8-9316883 ext. 201
Fax: +972-8-9316884
Email: gilad@codefidence.com
Check out our Open Source technology and training blog - http://tuxology.net
"The biggest risk you can take it is to take no risk."
-- Mark Zuckerberg and probably others
^ permalink raw reply
* Re: 2.6.32-rc5-mmotm1101 - kernel BUG at net/ipv4/tcp_input.c:3707!
From: Gilad Ben-Yossef @ 2009-11-04 6:38 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Ilpo Järvinen, Eric Dumazet, Andrew Morton, linux-kernel,
netdev, Ori Finkelman
In-Reply-To: <7916.1257300093@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu wrote:
> On Tue, 03 Nov 2009 23:34:19 +0200, Ilpo JÀrvinen said:
>
>
>> On Tue, 3 Nov 2009, Gilad Ben-Yossef wrote:
>>
>>
>>> Eric Dumazet wrote:
>>>
>>>
>>>> Valdis.Kletnieks@vt.edu a écrit :
>>>>
>>>>
>>>>> Seen right after I started 'fetchmail'. Reproducible - 3 out of 3.
>>>>> I'll bisect this tonight if nobody jumps up and yells they know what it
>>>>> is...
>>>>>
>>>>>
>>> Bah... this is most probably my fault. Sorry about that.
>>>
>>> Can you please try the patch in the next email?
>>>
>
> Tried while at home, machine panic'ed. No netconsole here at the moment, sorry.
>
Ok, thanks.That is ... strange.
I didn't manage to recreate this here with a simple IPv6 set and netcat
as server client but I will try further, but if there is any way to send me
the crash location that would be a big help. Thanks.
>
>
> Why was this blowing chunks in the IPv6 when I was making an IPv4 connection
> then? I just noticed that. My fetchmail can't make an IPv6 TCP connection to
> our IMAP server because the server isn't v6-enabled yet. And although I
> contact our DNS over IPv6, but that's UDP not TCP.
>
>
I don't think the chunk blowing occurred due to the connection to the IMAP
server. That codes deals with incoming SYNs. I guess it happened when
fetchmail
tried to connect to the local mail daemon and this should be happening
over the loopback interface...
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker & CTO
Codefidence Ltd.
Web: http://codefidence.com
Cell: +972-52-8260388
Skype: gilad_codefidence
Tel: +972-8-9316883 ext. 201
Fax: +972-8-9316884
Email: gilad@codefidence.com
Check out our Open Source technology and training blog - http://tuxology.net
"The biggest risk you can take it is to take no risk."
-- Mark Zuckerberg and probably others
^ permalink raw reply
* REGRESSION: On 2.6.32-rc5 the firmware hangs, and the nic is unusable.
From: Eric W. Biederman @ 2009-11-04 7:40 UTC (permalink / raw)
To: Dhananjay Phadke; +Cc: netdev
On 2.6.31.5 I get:
ethtool -i eth0
driver: netxen_nic
version: 4.0.30
firmware-version: 4.0.305
bus-info: 0000:06:00.0
And everything works except bonding.
On 2.6.32-rc5 I dhcp I get an IP
there is a sanity test ping.
Then the driver reports a firmware hang and
the interface goes down and I am dead in the water.
I'm a bit frustrated with this as it seems with each kernel release
the driver gets a little bit less usable.
Have I given you enough information to track this down?
Eric
^ permalink raw reply
* Re: HTB accuracy on 10GbE
From: Ryousei Takano @ 2009-11-04 8:19 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, Patrick McHardy, Linux Netdev List,
takano-ryousei
In-Reply-To: <4AF110CE.8070701@gmail.com>
Hi Eric,
On Wed, Nov 4, 2009 at 2:27 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Eric Dumazet a écrit :
>>
>> Hmm, do you know part of the error comes from the user tool itself ?
>>
>> If you check iperf results at sender and receiver you'll see different
>> values, sender lies a bit.
>>
>> Tried here on a Gbit link (I dont have 10Gbe yet)
>>
>> $ ./iperf.bench.sh
>> .100 104
>> .200 206
>> .300 307
>> .400 413
>> .500 515
>> .600 610
>> .700 715
>> .800 822
>> .900 913
>> 1.000 945
>>
> (that was with standard 1500 MTU)
>
> Now, with 9000 MTU and 50 seconds samples (instead of 5 s) I get :
>
> $ ./iperf.bench.sh
> .100 101
> .200 200
> .300 301
> .400 401
> .500 500
> .600 601
> .700 700
> .800 803
> .900 903
> 1.000 991
>
> Not too bad :)
>
I tried iperf with 60 seconds samples. I got the almost same result.
Here is the result:
sender receiver
1.000 1.00 1.00
2.000 2.01 2.01
3.000 3.03 3.02
4.000 4.07 4.07
5.000 5.05 5.05
6.000 6.16 6.16
7.000 7.22 7.22
8.000 8.15 8.15
9.000 9.23 9.23
9.900 9.69 9.69
Best regards,
Ryousei Takano
^ permalink raw reply
* Re: [PATCH] sch_htb.c consume the classes's tokens bellow the HTB_CAN_SEND level
From: Jarek Poplawski @ 2009-11-04 8:28 UTC (permalink / raw)
To: Changli Gao; +Cc: Jamal Hadi Salim, devik, netdev
In-Reply-To: <412e6f7f0911031753m4af1467fn1b0326bdf17fe48b@mail.gmail.com>
On Wed, Nov 04, 2009 at 09:53:52AM +0800, Changli Gao wrote:
> On Wed, Nov 4, 2009 at 7:00 AM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> > On Tue, Nov 03, 2009 at 09:18:49PM +0800, Changli Gao wrote:
> >> On Tue, Nov 3, 2009 at 6:05 PM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> >> >
> >> > The ceil specification is controlled only by ctokens, which are always
> >> > updated, so no such risk.
> >> >
> >> Nevertheless, updating tokens is necessary too.
> >
> > If it's really necessary you should present some test case fixed by
> > your patch, I guess.
> >
> > In the meantime let's consider what could be broken:
> > class 1:1 (parent) rate 10 packets/sec
> > class 1:2 rate 5 packets/sec ceil 10 packets/sec
> > class 1:3 rate 5 packets/sec ceil 10 packets/sec
> >
> > class 1:2 doesn't use all its rate, and sends every other second
> > (in even seconds)
> > class 1:3 sends 10 packets during the first second, so with your
> > patch it will use its tokens for 2 seconds
> > class 1:2 uses its rate in the second second..., so class 1:1
> > can't lend anything
> > class 1:3 can only borrow, so it won't be able to send during
> > this second anything
> >
> > So, the effect would be class 1:3 sending every odd second 10 packets
> > while every even second - nothing...
>
> class 1:3 can send, as its parent rate is 10, but class 1:2 only uses
> half of it, and class 1:1 is still in HTB_CAN_SEND mode.
>
> The result is, hasn't any difference with or without my patch :
> class 1:1 sends 10 packets in odd seconds, and 5 packets in even seconds.
I guess you meant class 1:3, and there is a difference: it sends 5
packets in even seconds only if it manages to borrow from 1:1, but
it's not _guaranteed_ at all. In this particular case it's quite
probable class 1:2 will send 10 packets in even seconds instead, or
with some finer borrowing control it could be: class 1:2 8 packets,
class 1:3 2 packets, as well.
> class 1:2 sends 5 packets in even seconds.
> class 1:1 (parent) sends 10 packets in every second.
>
> Let's think this case in another way: which class sends packets in
> even seconds first, class 1:2 or class 1:3.
> With my patch, as 1:3 in HTB_MAY_BORROW mode, and 1:2 in HTB_CAN_SEND
> mode, so 1:2 sends all its 5 packets first.
> Without my patch, as 1:2 and 1:3 are both in HTB_CAN_SEND mode, the
> sequence is undetermined. In other word, 1:2 and 1:3 are treated
> fairly, and it isn't fair for 1:2, because 1:2 sends nothing in odd
> seconds, and has no deficit in rate as 1:3.
The token bucket (cl->buffer) is just to account distinctly when a
class is entitled to send and when it actually does send within its
rate. The fairness is controlled by classes itself with HTB_CAN_SEND
state. Using this bucket to account for borrowed sending deprives us
of this precise information. "The fairness" would be controlled by
priorities of borrowing instead (see above).
Regards,
Jarek P.
^ permalink raw reply
* Re: [PATCH] usbnet: Do not implement ethtool get_link() if link state is unknown
From: David Miller @ 2009-11-04 8:36 UTC (permalink / raw)
To: ben; +Cc: david-b, greg, jacmet, steve.glendinning, netdev
In-Reply-To: <1257304800.3136.452.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 04 Nov 2009 03:20:00 +0000
> I don't see how it's 'perfect' since it reports the link as up where it
> is really unknown. Still, this is a fairly minor bug.
That is the policy we enforce for all drivers, especially virtual
ones. If you can't tell, you specify that the link is up.
Otherwise automated tools like NetworkManager et al. will not even
attempt to bring do DHCP and bring the network device online.
^ 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