* 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
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Ingo Molnar @ 2009-11-04 8:37 UTC (permalink / raw)
To: Ivo van Doorn
Cc: Bartlomiej Zolnierkiewicz, linux-wireless, linux-kernel, netdev,
Randy Dunlap, Luis Correia, John W. Linville, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911032200.04516.IvDoorn@gmail.com>
* Ivo van Doorn <ivdoorn@gmail.com> wrote:
> > MAINTAINERS: add rt2800 entry
>
> I see you decided to take over the maintainership? Doesn't that need
> the current maintainer to move away, or was this part of the "going
> over other peoples head" plan?
>
> [...]
>
> These are too much (and too big) patches for me to review at once,
> I'll look at them later.
Frankly, having read through the recent discussions related to the
rt2800pci/usb drivers, the subtle (and largely undeserved) group
violence and abuse you are inflicting on Bart is stomach-turning.
The non-working rt2800pci driver has been pending in your private tree
for how long, 1.5 _years_?
Look at the diffstat of Bart's driver:
15 files changed, 4036 insertions(+), 7158 deletions(-)
He reduced your 5.2 KLOC non-working driver into a 1.8 KLOC _working_
driver.
And _still_ your complaint about Bart's series is that he updated the
MAINTAINERS entry and added an entry for rt2800? Heck _sure_ he should
update it, he is the one doing the hard work of trying to bring it to
users, trying to clean up a messy driver space, trying to turn crap into
gold.
The thing is, if you dont have the time or interest to listen to and act
upon review feedback, be constructive about it and fix (obvious)
structural problems in your rt2800 code, you should just step aside and
let Bart maintain what he is apparently more capable of maintaining than
you are.
What you are doing here is a thinly veiled land-grab: you did a minimal
token driver for rt2800 that doesnt work, kept it in your private tree
for _1.5 years_, and the moment someone _else_ came along and did
something better and more functional in drivers/staging/, you discovered
your sudden interest for it and moved the crappy driver upstream at
lightning's speed (it is already in net-next AFAICS, despite negative
test and review feedback) - ignoring and throwing away all the work that
Bart has done.
Such behavior wouldnt fly in _any_ other Linux subsystem, but apparently
there is one set of rules for upstream kernel maintainers and then
there's another, different set of rules for upstream wireless driver
maintainers.
Really, you should listen to contrary opinion and _you_ should work
_hard_ to integrate Bart socially and open up your close circle of
wireless insiders instead of fighting his 'outsider' contributions every
which way. We dont care if people are rough, express displeasure and
show strong opinion about crappy code - but the moment you are
_excluding_ capable people and playing petty office politics (like you
are very clearly doing it with Bart here) everyone loses.
Guys, show some minimal amount of honesty, openness and critical
thinking please ...
Ingo
^ permalink raw reply
* Re: [Bugme-new] [Bug 14427] New: ipv6 forward cause strange route
From: Pekka Savola @ 2009-11-04 8:01 UTC (permalink / raw)
To: YOSHIFUJI Hideaki
Cc: Andrew Morton, green, netdev, bugzilla-daemon, bugme-daemon,
davem
In-Reply-To: <4AF011A6.1070903@linux-ipv6.org>
On Tue, 3 Nov 2009, YOSHIFUJI Hideaki wrote:
>> RFC 2526: Reserved IPv6 Subnet Anycast Addresses
>> RFC 3627: Use of /127 Prefix Length Between Routers Considered Harmful
>
> I should say "Subnet-router anycast address" and
> RFC3513: Internet Protocol Version 6 (IPv6) Addressing
> Architecture".
FWIW, please note that commercial vendors haven't implemented this
very extensively, and there's also some recent activity arguing this
is not very useful:
http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-00
We'll likely get better idea how folks react to this during the next
week's IETF.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
^ 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 9:16 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Jamal Hadi Salim, devik, netdev
In-Reply-To: <20091104082808.GA6224@ff.dom.local>
On Wed, Nov 4, 2009 at 4:28 PM, Jarek Poplawski <jarkao2@gmail.com> wrote:
>> >
>> > 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.
You are right. :)
> 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.
It is just correct. You focus on 1 second fairness, while I focus on 2
seconds fairness.
>
>> 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).
>
The token bucket and ctoken bucket both use cl->mbuffer to control
rate granularities. If we don't account token bucket when the
corresponding class in HTB_MAY_BORROW mode, the cl->mbuffer will
become useless.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [Patch] net: fix incorrect counting in __scm_destroy()
From: Amerigo Wang @ 2009-11-04 10:04 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, Amerigo Wang, David S. Miller
It seems that in __scm_destroy() we forgot to decrease
the ->count after fput(->fp[i]), this may cause some
problem when we recursively call fput() again.
Signed-off-by: WANG Cong <amwang@redhat.com>
Cc: David S. Miller <davem@davemloft.net>
---
diff --git a/net/core/scm.c b/net/core/scm.c
index b7ba91b..fa53219 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -120,8 +120,10 @@ void __scm_destroy(struct scm_cookie *scm)
fpl = list_first_entry(&work_list, struct scm_fp_list, list);
list_del(&fpl->list);
- for (i=fpl->count-1; i>=0; i--)
+ for (i = fpl->count-1; i >= 0; i--) {
fput(fpl->fp[i]);
+ fpl->count--;
+ }
kfree(fpl);
}
^ permalink raw reply related
* Re: [PATCH] e1000: the power down when running ifdown command
From: Naohiro Ooiwa @ 2009-11-04 10:23 UTC (permalink / raw)
To: Stephen Hemminger
Cc: jeffrey.t.kirsher, jesse.brandeburg, peter.p.waskiewicz.jr,
john.ronciak, davem, Andrew Morton, netdev, svaidy, e1000-devel
In-Reply-To: <4AEE35D2.4000503@miraclelinux.com>
Naohiro Ooiwa wrote:
> Stephen Hemminger wrote:
>> On Sat, 31 Oct 2009 18:39:52 +0900
>> Naohiro Ooiwa <nooiwa@miraclelinux.com> wrote:
>>
>> Does this work with Wake On Lan?
>
> Yes, it works WOL.
Sorry, I made a mistake.
The WOL doesn't work when my patch applied to kernel.
I wasn't myself.
I consider the WOL and I will resent the patch.
Thank you for your point.
thanks,
Naohiro Ooiwa
> But I worry that my test is enough.
>
> They are following:
> - simple data transmission after ifdown;ifup.
> - enable wol, ifup network device, system shutdown, and make sure wol work.
> - enable wol, ifdown network device, system shutdown, and make sure wol work.
> - while [ 0 ] ; do ifdown eth0 ; ifup eth0 ; done
> - while [ 0 ] ; do modprobe e1000 ; rmmod e1000 ; done
>
>
>> @@ -1265,6 +1287,7 @@ static int e1000_open(struct net_device *netdev)
>> goto err_setup_rx;
>>
>> e1000_power_up_phy(adapter);
>> + e1000_reset(adapter);
>>
>> adapter->mng_vlan_id = E1000_MNG_VLAN_NONE;
>> if ((hw->mng_cookie.status &
>
> This code fix problem that e1000 driver doesn't work to auto-negotiation
> once in a while.
> Maybe, the cause is that set state to D0 just before it.
> I found it by repeat of ifup and ifdown.
>
> If you find out other points and any necessary tests from my patch,
> please tell me. I will make sure them.
>
> Thanks you.
> Naohiro Ooiwa
>
> --
> 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
>
^ permalink raw reply
* Re: [PATCH] e1000: the power down when running ifdown command
From: Naohiro Ooiwa @ 2009-11-04 10:27 UTC (permalink / raw)
To: Jeff Kirsher
Cc: jesse.brandeburg, peter.p.waskiewicz.jr, john.ronciak, davem,
Andrew Morton, netdev, svaidy, e1000-devel
In-Reply-To: <9929d2390911031337p6115fef0wc1b94e5141ead341@mail.gmail.com>
Jeff Kirsher wrote:
> 2009/11/3 Naohiro Ooiwa <nooiwa@miraclelinux.com>:
>> Jeff Kirsher wrote:
>>> 2009/10/31 Naohiro Ooiwa <nooiwa@miraclelinux.com>:
>>>
>>> I have added this patch to my tree for testing. This patch requires a
>>> fair amount of regression testing, so once its passed testing I will
>>> push the patch to David/netdev.
>> I appreciate the marge your tree.
>> If there is anything I can do, please let me know.
>>
>> And I know this patch is good for e100 driver too.
>> I would really like to create patch for it.
>> How do you think about e100 driver.
>>
>>
>> Thanks,
>> Naohiro Ooiwa
>>
>
> Patches are always welcome (referring to a e100 patch).
I am happy that you should say that.
I will try to create a patch for e100, e1000e, igb and ixgbe.
Before that, I should fix the following problems.
> As far as the e1000 patch goes, it has a number of issues which were
> found in testing. Here are just a few problems we saw:
> 1. ethtool -t - crashes the system
> 2. ethtool eth0 - always shows link/speed as 1000/Full even when there
> is no cable
> 3. ethtool -s eth0 autoneg on/off - system hang. Sometimes a copper
> interface will show up as fiber after this.
> 4. ethtool -d/-S/-g etc - will corrupt the stats of the interface
> while doing ifup/down
Thank you for your tests.
Oh, My patch is full of problem.
The rest is my work.
I will resend the patch after test of all ethtool's options.
At that time, I will tell you contents of my tests.
And I sad WOL works on my patch in previous mail.
But WOL doesn't work. Sorry, I wasn't myself.
I will fix it too.
>
> So it appears that more needs to be done to the driver to get this to
> work as expected.
>
> NAK
>
^ 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