* Re: wanPMC-CxT1E1
From: Greg KH @ 2009-10-29 1:05 UTC (permalink / raw)
To: Bob Beers; +Cc: netdev
In-Reply-To: <4f6ba3b0910271048n10ff37fek9af191b133892e1e@mail.gmail.com>
On Tue, Oct 27, 2009 at 01:48:53PM -0400, Bob Beers wrote:
> On Mon, Oct 26, 2009 at 4:41 PM, Greg KH <greg@kroah.com> wrote:
> > Getting it to build on 2.6.31 is more important than RHEL5, we can't do
> > anything with an old kernel like that.
>
> ok, so where do I start, I have a system ready to start
> git cloning, and creating patches. I googled for a while
> but didn't find a nice recipe for participating in the -staging
> process.
Ick, this isn't going to be easy, a lot of work needs to be done on the
driver to get it just to build on the latest kernel tree. I personally
don't have the time to do it right now, but will gladly accept patches
that add it to the staging tree if someone else wants to do it.
sorry,
greg k-h
^ permalink raw reply
* Re: [PATCH] hso: fix debug routines
From: Andrew Morton @ 2009-10-28 23:16 UTC (permalink / raw)
To: Antti Kaijanmäki; +Cc: Greg KH, linux-kernel, netdev, Jan Dumon
In-Reply-To: <1256653615.3591.113.camel@nomovok.homedomain>
On Tue, 27 Oct 2009 16:26:55 +0200
Antti Kaijanmäki <antti.kaijanmaki@nomovok.com> wrote:
> On Mon, 2009-10-26 at 12:40 -0700, Greg KH wrote:
> > Yes, that should be a new patch, especially as it would not be needed
> > to fix older kernels for the original bug.
> >
> > So, care to send 2 patches? The debug one isn't needed to be sent to
> > the stable@kernel.org address.
>
>
> Signed-off-by: Antti Kaijanmäki <antti.kaijanmaki@nomovok.com>
> ---
> drivers/net/usb/hso.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> index fa4e581..746839b 100644
> --- a/drivers/net/usb/hso.c
> +++ b/drivers/net/usb/hso.c
> @@ -378,7 +378,7 @@ static void dbg_dump(int line_count, const char *func_name, unsigned char *buf,
> }
>
> #define DUMP(buf_, len_) \
> - dbg_dump(__LINE__, __func__, buf_, len_)
> + dbg_dump(__LINE__, __func__, (unsigned char *)buf_, len_)
>
> #define DUMP1(buf_, len_) \
> do { \
> @@ -1527,7 +1527,7 @@ static void tiocmget_intr_callback(struct urb *urb)
> dev_warn(&usb->dev,
> "hso received invalid serial state notification\n");
> DUMP(serial_state_notification,
> - sizeof(hso_serial_state_notifation))
> + sizeof(struct hso_serial_state_notification));
> } else {
>
> UART_state_bitmap = le16_to_cpu(serial_state_notification->
This patch has no changelog, and I'm not seeing any description of what
it fixes and how it fixes it up-thread.
^ permalink raw reply
* Congratulation!!!
From: Mr. Parris Williams @ 2009-10-28 22:49 UTC (permalink / raw)
To: info
£1,350,000.00 Pounds has been awarded to your E-mail do send us your Name Age Tel Address contery.
^ permalink raw reply
* Congratulation!!!
From: Mr. Parris Williams @ 2009-10-28 22:48 UTC (permalink / raw)
To: info
£1,350,000.00 Pounds has been awarded to your E-mail do send us your Name Age Tel Address contery.
^ permalink raw reply
* Congratulation!!!
From: Mr. Parris Williams @ 2009-10-28 22:48 UTC (permalink / raw)
To: info
£1,350,000.00 Pounds has been awarded to your E-mail do send us your Name Age Tel Address contery.
^ permalink raw reply
* Re: Fw: [Bug 14470] New: freez in TCP stack
From: Denys Fedoryschenko @ 2009-10-28 22:27 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
In-Reply-To: <20091028151313.ba4a4d23.akpm@linux-foundation.org>
>
> Twice a day on six separate machines. That ain't no hardware glitch.
>
> Vaclav, are you able to say whether this is a regression? Did those
> machines run 2.6.30 (for example)?
>
> Thanks.
I had issues on Dell also. On one fixed by bios update, another only after
tuning some voodoo settings in sysctl (i was in hurry, no redundancy for this
server, and it was rebooting each day 1-3 times). It happens also in 32 and
64bit kernels (32bit userspace), also "heavy" tcp workload, both of them act
as proxy.
But my issue probably different, on both Dell servers i had bnx2 with IPMI.
It was very weird, nmi_watchdog, panic on reboot / on oops, detect
softlockups, detect deadlocks, detect hang tasks, hangcheck timer - didn't
help, only hardware watchdog (IPMI or iTCO) able to catch hang and reboot
server. Because i didn't had anything useful to report(remote server and
netconsole didn't give anything), i didn't fill bugzilla report.
Not sure my post useful in this case, but sharing experience anyway.
>
> > We had to put serial console on these servers to catch the oops. Is there
> > anything else We can do to debug this?
> > The RIP is always the same:
> >
> > RIP: 0010:[<ffffffff814203cc>] [<ffffffff814203cc>]
> > tcp_xmit_retransmit_queue+0x8c/0x290
> >
> > rest of the oops always differs a litle ... here is an example:
> >
> > RIP: 0010:[<ffffffff814203cc>] [<ffffffff814203cc>]
> > tcp_xmit_retransmit_queue+0x8c/0x290
> > RSP: 0018:ffffc90000003a40 EFLAGS: 00010246
> > RAX: ffff8807e7420678 RBX: ffff8807e74205c0 RCX: 0000000000000000
> > RDX: 000000004598a105 RSI: 0000000000000000 RDI: ffff8807e74205c0
> > RBP: ffffc90000003a80 R08: 0000000000000003 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > R13: ffff8807e74205c0 R14: ffff8807e7420678 R15: 0000000000000000
> > FS: 0000000000000000(0000) GS:ffffc90000000000(0000)
> > knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> > CR2: 0000000000000000 CR3: 0000000001001000 CR4: 00000000000006f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Process swapper (pid: 0, threadinfo ffffffff81608000, task
> > ffffffff81631440) Stack:
> > ffffc90000003a60 0000000000000000 4598a105e74205c0 000000004598a101
> > <0> 000000000000050e ffff8807e74205c0 0000000000000003 0000000000000000
> > <0> ffffc90000003b40 ffffffff8141ae4a ffff8807e7420678 0000000000000000
> > Call Trace:
> > <IRQ>
> > [<ffffffff8141ae4a>] tcp_ack+0x170a/0x1dd0
> > [<ffffffff8141c362>] tcp_rcv_state_process+0x122/0xab0
> > [<ffffffff81422c6c>] tcp_v4_do_rcv+0xac/0x220
> > [<ffffffff813fd02f>] ? nf_iterate+0x5f/0x90
> > [<ffffffff81424b26>] tcp_v4_rcv+0x586/0x6b0
> > [<ffffffff813fd0c5>] ? nf_hook_slow+0x65/0xf0
> > [<ffffffff81406b70>] ? ip_local_deliver_finish+0x0/0x120
> > [<ffffffff81406bcf>] ip_local_deliver_finish+0x5f/0x120
> > [<ffffffff8140715b>] ip_local_deliver+0x3b/0x90
> > [<ffffffff81406971>] ip_rcv_finish+0x141/0x340
> > [<ffffffff8140701f>] ip_rcv+0x24f/0x350
> > [<ffffffff813e7ced>] netif_receive_skb+0x20d/0x2f0
> > [<ffffffff813e7e90>] napi_skb_finish+0x40/0x50
> > [<ffffffff813e82f4>] napi_gro_receive+0x34/0x40
> > [<ffffffff8133e0c8>] e1000_receive_skb+0x48/0x60
> > [<ffffffff81342342>] e1000_clean_rx_irq+0xf2/0x330
> > [<ffffffff813410a1>] e1000_clean+0x81/0x2a0
> > [<ffffffff81054ce1>] ? ktime_get+0x11/0x50
> > [<ffffffff813eaf1c>] net_rx_action+0x9c/0x130
> > [<ffffffff81046940>] ? get_next_timer_interrupt+0x1d0/0x210
> > [<ffffffff81041bd7>] __do_softirq+0xb7/0x160
> > [<ffffffff8100c27c>] call_softirq+0x1c/0x30
> > [<ffffffff8100e04d>] do_softirq+0x3d/0x80
> > [<ffffffff81041b0b>] irq_exit+0x7b/0x90
> > [<ffffffff8100d613>] do_IRQ+0x73/0xe0
> > [<ffffffff8100bb13>] ret_from_intr+0x0/0xa
> > <EOI>
> > [<ffffffff81296e6c>] ? acpi_idle_enter_bm+0x245/0x271
> > [<ffffffff81296e62>] ? acpi_idle_enter_bm+0x23b/0x271
> > [<ffffffff813c7a08>] ? cpuidle_idle_call+0x98/0xf0
> > [<ffffffff8100a104>] ? cpu_idle+0x94/0xd0
> > [<ffffffff81468db6>] ? rest_init+0x66/0x70
> > [<ffffffff816a082f>] ? start_kernel+0x2ef/0x340
> > [<ffffffff8169fd54>] ? x86_64_start_reservations+0x84/0x90
> > [<ffffffff8169fe32>] ? x86_64_start_kernel+0xd2/0x100
> > Code: 00 eb 28 8b 83 d0 03 00 00 41 39 44 24 40 0f 89 00 01 00 00 41 0f
> > b6 cd 41 bd 2f 00 00 00 83 e1 03 0f 84 fc 00 00 00 4d 8b 24 24 <49> 8b 04
> > 24 4d 39 f4 0f 18 08 0f 84 d9 00 00 00 4c 3b a3 b8 01
> > RIP [<ffffffff814203cc>] tcp_xmit_retransmit_queue+0x8c/0x290
> > RSP <ffffc90000003a40>
> > CR2: 0000000000000000
> > ---[ end trace d97d99c9ae1d52cc ]---
> > Kernel panic - not syncing: Fatal exception in interrupt
> > Pid: 0, comm: swapper Tainted: G D 2.6.31 #2
> > Call Trace:
> > <IRQ> [<ffffffff8103cab0>] panic+0xa0/0x170
> > [<ffffffff8100bb13>] ? ret_from_intr+0x0/0xa
> > [<ffffffff8103c74e>] ? print_oops_end_marker+0x1e/0x20
> > [<ffffffff8100f38e>] oops_end+0x9e/0xb0
> > [<ffffffff81025b9a>] no_context+0x15a/0x250
> > [<ffffffff81025e2b>] __bad_area_nosemaphore+0xdb/0x1c0
> > [<ffffffff813e89e9>] ? dev_hard_start_xmit+0x269/0x2f0
> > [<ffffffff81025fae>] bad_area_nosemaphore+0xe/0x10
> > [<ffffffff8102639f>] do_page_fault+0x17f/0x260
> > [<ffffffff8147eadf>] page_fault+0x1f/0x30
> > [<ffffffff814203cc>] ? tcp_xmit_retransmit_queue+0x8c/0x290
> > [<ffffffff8141ae4a>] tcp_ack+0x170a/0x1dd0
> > [<ffffffff8141c362>] tcp_rcv_state_process+0x122/0xab0
> > [<ffffffff81422c6c>] tcp_v4_do_rcv+0xac/0x220
> > [<ffffffff813fd02f>] ? nf_iterate+0x5f/0x90
> > [<ffffffff81424b26>] tcp_v4_rcv+0x586/0x6b0
> > [<ffffffff813fd0c5>] ? nf_hook_slow+0x65/0xf0
> > [<ffffffff81406b70>] ? ip_local_deliver_finish+0x0/0x120
> > [<ffffffff81406bcf>] ip_local_deliver_finish+0x5f/0x120
> > [<ffffffff8140715b>] ip_local_deliver+0x3b/0x90
> > [<ffffffff81406971>] ip_rcv_finish+0x141/0x340
> > [<ffffffff8140701f>] ip_rcv+0x24f/0x350
> > [<ffffffff813e7ced>] netif_receive_skb+0x20d/0x2f0
> > [<ffffffff813e7e90>] napi_skb_finish+0x40/0x50
> > [<ffffffff813e82f4>] napi_gro_receive+0x34/0x40
> > [<ffffffff8133e0c8>] e1000_receive_skb+0x48/0x60
> > [<ffffffff81342342>] e1000_clean_rx_irq+0xf2/0x330
> > [<ffffffff813410a1>] e1000_clean+0x81/0x2a0
> > [<ffffffff81054ce1>] ? ktime_get+0x11/0x50
> > [<ffffffff813eaf1c>] net_rx_action+0x9c/0x130
> > [<ffffffff81046940>] ? get_next_timer_interrupt+0x1d0/0x210
> > [<ffffffff81041bd7>] __do_softirq+0xb7/0x160
> > [<ffffffff8100c27c>] call_softirq+0x1c/0x30
> > [<ffffffff8100e04d>] do_softirq+0x3d/0x80
> > [<ffffffff81041b0b>] irq_exit+0x7b/0x90
> > [<ffffffff8100d613>] do_IRQ+0x73/0xe0
> > [<ffffffff8100bb13>] ret_from_intr+0x0/0xa
> > <EOI> [<ffffffff81296e6c>] ? acpi_idle_enter_bm+0x245/0x271
> > [<ffffffff81296e62>] ? acpi_idle_enter_bm+0x23b/0x271
> > [<ffffffff813c7a08>] ? cpuidle_idle_call+0x98/0xf0
> > [<ffffffff8100a104>] ? cpu_idle+0x94/0xd0
> > [<ffffffff81468db6>] ? rest_init+0x66/0x70
> > [<ffffffff816a082f>] ? start_kernel+0x2ef/0x340
> > [<ffffffff8169fd54>] ? x86_64_start_reservations+0x84/0x90
> > [<ffffffff8169fe32>] ? x86_64_start_kernel+0xd2/0x100
>
> --
> 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: Fw: [Bug 14470] New: freez in TCP stack
From: Andrew Morton @ 2009-10-28 22:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, kolo, bugzilla-daemon
In-Reply-To: <20091026084132.57bc3d07@nehalam>
On Mon, 26 Oct 2009 08:41:32 -0700
Stephen Hemminger <shemminger@linux-foundation.org> wrote:
>
>
> Begin forwarded message:
>
> Date: Mon, 26 Oct 2009 12:47:22 GMT
> From: bugzilla-daemon@bugzilla.kernel.org
> To: shemminger@linux-foundation.org
> Subject: [Bug 14470] New: freez in TCP stack
>
Stephen, please retain the bugzilla and reporter email cc's when
forwarding a report to a mailing list.
> http://bugzilla.kernel.org/show_bug.cgi?id=14470
>
> Summary: freez in TCP stack
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.31
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: kolo@albatani.cz
> Regression: No
>
>
> We are hiting kernel panics on Dell R610 servers with e1000e NICs; it apears
> usualy under a high network trafic ( around 100Mbit/s) but it is not a rule it
> has happened even on low trafic.
>
> Servers are used as reverse http proxy (varnish).
>
> On 6 equal servers this panic happens aprox 2 times a day depending on network
> load. Machine completly freezes till the management watchdog reboots.
>
Twice a day on six separate machines. That ain't no hardware glitch.
Vaclav, are you able to say whether this is a regression? Did those
machines run 2.6.30 (for example)?
Thanks.
> We had to put serial console on these servers to catch the oops. Is there
> anything else We can do to debug this?
> The RIP is always the same:
>
> RIP: 0010:[<ffffffff814203cc>] [<ffffffff814203cc>]
> tcp_xmit_retransmit_queue+0x8c/0x290
>
> rest of the oops always differs a litle ... here is an example:
>
> RIP: 0010:[<ffffffff814203cc>] [<ffffffff814203cc>]
> tcp_xmit_retransmit_queue+0x8c/0x290
> RSP: 0018:ffffc90000003a40 EFLAGS: 00010246
> RAX: ffff8807e7420678 RBX: ffff8807e74205c0 RCX: 0000000000000000
> RDX: 000000004598a105 RSI: 0000000000000000 RDI: ffff8807e74205c0
> RBP: ffffc90000003a80 R08: 0000000000000003 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8807e74205c0 R14: ffff8807e7420678 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffffc90000000000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000001001000 CR4: 00000000000006f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper (pid: 0, threadinfo ffffffff81608000, task ffffffff81631440)
> Stack:
> ffffc90000003a60 0000000000000000 4598a105e74205c0 000000004598a101
> <0> 000000000000050e ffff8807e74205c0 0000000000000003 0000000000000000
> <0> ffffc90000003b40 ffffffff8141ae4a ffff8807e7420678 0000000000000000
> Call Trace:
> <IRQ>
> [<ffffffff8141ae4a>] tcp_ack+0x170a/0x1dd0
> [<ffffffff8141c362>] tcp_rcv_state_process+0x122/0xab0
> [<ffffffff81422c6c>] tcp_v4_do_rcv+0xac/0x220
> [<ffffffff813fd02f>] ? nf_iterate+0x5f/0x90
> [<ffffffff81424b26>] tcp_v4_rcv+0x586/0x6b0
> [<ffffffff813fd0c5>] ? nf_hook_slow+0x65/0xf0
> [<ffffffff81406b70>] ? ip_local_deliver_finish+0x0/0x120
> [<ffffffff81406bcf>] ip_local_deliver_finish+0x5f/0x120
> [<ffffffff8140715b>] ip_local_deliver+0x3b/0x90
> [<ffffffff81406971>] ip_rcv_finish+0x141/0x340
> [<ffffffff8140701f>] ip_rcv+0x24f/0x350
> [<ffffffff813e7ced>] netif_receive_skb+0x20d/0x2f0
> [<ffffffff813e7e90>] napi_skb_finish+0x40/0x50
> [<ffffffff813e82f4>] napi_gro_receive+0x34/0x40
> [<ffffffff8133e0c8>] e1000_receive_skb+0x48/0x60
> [<ffffffff81342342>] e1000_clean_rx_irq+0xf2/0x330
> [<ffffffff813410a1>] e1000_clean+0x81/0x2a0
> [<ffffffff81054ce1>] ? ktime_get+0x11/0x50
> [<ffffffff813eaf1c>] net_rx_action+0x9c/0x130
> [<ffffffff81046940>] ? get_next_timer_interrupt+0x1d0/0x210
> [<ffffffff81041bd7>] __do_softirq+0xb7/0x160
> [<ffffffff8100c27c>] call_softirq+0x1c/0x30
> [<ffffffff8100e04d>] do_softirq+0x3d/0x80
> [<ffffffff81041b0b>] irq_exit+0x7b/0x90
> [<ffffffff8100d613>] do_IRQ+0x73/0xe0
> [<ffffffff8100bb13>] ret_from_intr+0x0/0xa
> <EOI>
> [<ffffffff81296e6c>] ? acpi_idle_enter_bm+0x245/0x271
> [<ffffffff81296e62>] ? acpi_idle_enter_bm+0x23b/0x271
> [<ffffffff813c7a08>] ? cpuidle_idle_call+0x98/0xf0
> [<ffffffff8100a104>] ? cpu_idle+0x94/0xd0
> [<ffffffff81468db6>] ? rest_init+0x66/0x70
> [<ffffffff816a082f>] ? start_kernel+0x2ef/0x340
> [<ffffffff8169fd54>] ? x86_64_start_reservations+0x84/0x90
> [<ffffffff8169fe32>] ? x86_64_start_kernel+0xd2/0x100
> Code: 00 eb 28 8b 83 d0 03 00 00 41 39 44 24 40 0f 89 00 01 00 00 41 0f b6 cd
> 41 bd 2f 00 00 00 83 e1 03 0f 84 fc 00 00 00 4d 8b 24 24 <49> 8b 04 24 4d 39 f4
> 0f 18 08 0f 84 d9 00 00 00 4c 3b a3 b8 01
> RIP [<ffffffff814203cc>] tcp_xmit_retransmit_queue+0x8c/0x290
> RSP <ffffc90000003a40>
> CR2: 0000000000000000
> ---[ end trace d97d99c9ae1d52cc ]---
> Kernel panic - not syncing: Fatal exception in interrupt
> Pid: 0, comm: swapper Tainted: G D 2.6.31 #2
> Call Trace:
> <IRQ> [<ffffffff8103cab0>] panic+0xa0/0x170
> [<ffffffff8100bb13>] ? ret_from_intr+0x0/0xa
> [<ffffffff8103c74e>] ? print_oops_end_marker+0x1e/0x20
> [<ffffffff8100f38e>] oops_end+0x9e/0xb0
> [<ffffffff81025b9a>] no_context+0x15a/0x250
> [<ffffffff81025e2b>] __bad_area_nosemaphore+0xdb/0x1c0
> [<ffffffff813e89e9>] ? dev_hard_start_xmit+0x269/0x2f0
> [<ffffffff81025fae>] bad_area_nosemaphore+0xe/0x10
> [<ffffffff8102639f>] do_page_fault+0x17f/0x260
> [<ffffffff8147eadf>] page_fault+0x1f/0x30
> [<ffffffff814203cc>] ? tcp_xmit_retransmit_queue+0x8c/0x290
> [<ffffffff8141ae4a>] tcp_ack+0x170a/0x1dd0
> [<ffffffff8141c362>] tcp_rcv_state_process+0x122/0xab0
> [<ffffffff81422c6c>] tcp_v4_do_rcv+0xac/0x220
> [<ffffffff813fd02f>] ? nf_iterate+0x5f/0x90
> [<ffffffff81424b26>] tcp_v4_rcv+0x586/0x6b0
> [<ffffffff813fd0c5>] ? nf_hook_slow+0x65/0xf0
> [<ffffffff81406b70>] ? ip_local_deliver_finish+0x0/0x120
> [<ffffffff81406bcf>] ip_local_deliver_finish+0x5f/0x120
> [<ffffffff8140715b>] ip_local_deliver+0x3b/0x90
> [<ffffffff81406971>] ip_rcv_finish+0x141/0x340
> [<ffffffff8140701f>] ip_rcv+0x24f/0x350
> [<ffffffff813e7ced>] netif_receive_skb+0x20d/0x2f0
> [<ffffffff813e7e90>] napi_skb_finish+0x40/0x50
> [<ffffffff813e82f4>] napi_gro_receive+0x34/0x40
> [<ffffffff8133e0c8>] e1000_receive_skb+0x48/0x60
> [<ffffffff81342342>] e1000_clean_rx_irq+0xf2/0x330
> [<ffffffff813410a1>] e1000_clean+0x81/0x2a0
> [<ffffffff81054ce1>] ? ktime_get+0x11/0x50
> [<ffffffff813eaf1c>] net_rx_action+0x9c/0x130
> [<ffffffff81046940>] ? get_next_timer_interrupt+0x1d0/0x210
> [<ffffffff81041bd7>] __do_softirq+0xb7/0x160
> [<ffffffff8100c27c>] call_softirq+0x1c/0x30
> [<ffffffff8100e04d>] do_softirq+0x3d/0x80
> [<ffffffff81041b0b>] irq_exit+0x7b/0x90
> [<ffffffff8100d613>] do_IRQ+0x73/0xe0
> [<ffffffff8100bb13>] ret_from_intr+0x0/0xa
> <EOI> [<ffffffff81296e6c>] ? acpi_idle_enter_bm+0x245/0x271
> [<ffffffff81296e62>] ? acpi_idle_enter_bm+0x23b/0x271
> [<ffffffff813c7a08>] ? cpuidle_idle_call+0x98/0xf0
> [<ffffffff8100a104>] ? cpu_idle+0x94/0xd0
> [<ffffffff81468db6>] ? rest_init+0x66/0x70
> [<ffffffff816a082f>] ? start_kernel+0x2ef/0x340
> [<ffffffff8169fd54>] ? x86_64_start_reservations+0x84/0x90
> [<ffffffff8169fe32>] ? x86_64_start_kernel+0xd2/0x100
>
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-28 21:56 UTC (permalink / raw)
To: John W. Linville; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20091028211031.GF2856@tuxdriver.com>
On Wednesday 28 October 2009 22:10:32 John W. Linville wrote:
> Dave,
>
> I let my patches pile-up! Yikes!!
>
> This request includes the usual ton of stuff for -next -- driver
> updates, fixes for some earlier -next stuff, a few cfg80211 changes to
> accomodate the libertas driver, etc. Of note is the rt2800pci support
> added to the rt2x00 family.
Unfortunately rt2800pci support is non-functioning at the moment... :(
> Pleaset let me know if there are problems!
I find it rather disappointing that all my review comments regarding
rt2800pci support were just completely ignored and then the initial
patch was merged just as it was..
The way rt2800usb and rt2800pci drivers are designed really results
in making the task of adding working support for RT28x0 and RT30x0
chipsets to rt2x00 infrastructure more difficult and time consuming
than it should be... :(
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* dev_flags definitions in broadcom.c
From: Matt Carlson @ 2009-10-28 21:25 UTC (permalink / raw)
To: Nate Case; +Cc: Maciej W. Rozycki, Jeff Garzik, netdev@vger.kernel.org
Nate, On May 17, 2008 you submitted a patch titled
"PHYLIB: Add 1000Base-X support for Broadcom bcm5482". In that patch
you defined several dev_flags definitions for the broadcom module. I
only see the PHY_BCM_FLAGS_MODE_1000BX being used in the code though. I
quickly scanned through the phy_connect calls in drivers/net and didn't
see any caller using this preprocessor definition or an equivalent
hardcoded constant. Perhaps I missed something though. Can you tell me
where these flags are set?
My interest in this is several-fold. First, I'd like to move the
definitions to include/linux/brcmphy.h so that the same preprocessor
definitons can be used at both ends. But more important than that, I'd
like to get a handle on how many of these definitions are actually used
and how many are just placeholders. With only 32-bits to use, the flags
might become a precious resource. I have plans for a few of these bits
myself, and I'd like reviewers to take note of how they are used.
^ permalink raw reply
* Re: [RFC] multiqueue changes
From: Jarek Poplawski @ 2009-10-28 21:23 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, David S. Miller, Linux Netdev List
In-Reply-To: <4AE87EEE.4020703@trash.net>
On Wed, Oct 28, 2009 at 06:27:10PM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> > On Thu, Oct 08, 2009 at 09:03:44AM +0000, Jarek Poplawski wrote:
> > ...
> >> num_tx_queues. But it seems we should rather use more often
> >> real_num_tx_queue in schedulers code like dumps and maybe more
> >> (like e.g. sch_multiq does).
> >
> > ...i.e. probably everywhere between dev_activate and dev_deactivate
> > all qdisc operations could use real_num_tx_queues (including a test
> > like: netif_is_real_multique), unless I miss something.
>
> We don't seem to be supporting changing real_num_tx_queues for
> registered devices currently (at least I couldn't find it).
> So I guess it depends on how this would be implemented.
>
> Simply changing the dev->real_num_tx_queues value while the
> device is down would require qdisc operations to operate on
> all possible queues since the amount of queues in use could
> be changed after the qdisc is created/configured, but before
> the device is set up. This approach has more complications
> like switching between mq and non-mq root qdiscs, taking care
> of non-default root qdisc (cloning them to the new queues), etc.
>
> A simpler alternative would be to destroy the existing root
> qdisc on any change to real_num_tx_queues and have dev_activate()
> set it up from scratch. In this case, we could (as you suggested)
> use real_num_tx_queues, which should fix the problem Eric reported.
Actually, I changed my mind after Eric's and especially David's
explanations. Probably there will be needed some changes in handling
the real_num_tx_queues, but there is no reason to misuse them for
masking a totally useless num_tx_queues value, like in this case. So,
IMHO, its mainly about the driver(s) (and maybe a bit of API change)
here.
Jarek P.
^ permalink raw reply
* pull request: wireless-next-2.6 2009-10-28
From: John W. Linville @ 2009-10-28 21:10 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
I let my patches pile-up! Yikes!!
This request includes the usual ton of stuff for -next -- driver
updates, fixes for some earlier -next stuff, a few cfg80211 changes to
accomodate the libertas driver, etc. Of note is the rt2800pci support
added to the rt2x00 family.
Pleaset let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit b37b62fea1d1bf68ca51818f8eb1035188efd030:
Ben Hutchings (1):
sfc: Rename 'xfp' file and functions to reflect reality
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Abhijeet Kolekar (5):
iwlwifi/iwl3945: unify rts_tx_cmd_flag
iwl3945: rename tx to tx_cmd
iwlwifi/iwl3945: remove data_retry_limit
iwl3945: rearrange the code.
iwl3945: disable all tx fifos
Amitkumar Karwar (1):
libertas: Check return status of command functions
Ben M Cahill (8):
iwl3945: update iwl3945_apm_init()
iwlwifi: turn off device when not used.
iwl3945: remove unnecessary call to apm_ops.reset()
iwlagn, iwl3945: remove apm_reset() functions
iwl3945: streamline iwl3945_rfkill_poll()
iwl3945: move iwl_power_initialize()
iwlwifi: consolidate apm_init() functions
iwlwifi: make sure device is reset when unloading driver
Benoit PAPILLAULT (1):
zd1211rw: Fix TX status reporting in order to have proper rate control
Bob Copeland (1):
ath5k: use noise calibration from madwifi hal
Christian Lamparter (3):
ar9170: atomic pending A-MPDU counter
ar9170usb: atomic pending urbs counter
ar9170: don't filter BlockACK frames
David Kilroy (1):
orinoco: use cfg80211 ethtool ops
David-John Willis (1):
wl1251: add support for PG11 chips.
Holger Schurig (22):
cfg80211: no cookies in cfg80211_send_XXX()
cfg80211: remove warning in deauth case
libertas: make __lbs_cmd_async() non-static
libertas: cleanup host.h and hostcmd.h
libertas: harmonize cmd.h
libertas: make lbs_get_channel() static
libertas: remove unused lbs_cmd_802_11_inactivity_timeout()
libertas: remove unused 11d code
libertas: remove unused 11d.h as well, priv->countryinfo
libertas: change IW_ESSID_MAX_SIZE -> IEEE80211_MAX_SSID_LEN
libertas: move scan/assoc related stuff
libertas: sort variables in struct lbs_private
libertas: get current channel out of priv->curbssparams
libertas: move association related commands into assoc.c
libertas: move lbs_send_iwevcustom_event() to wext.c
libertas: remove handling for CMD_802_11_LED_GPIO_CTRL
libertas: remove handling for CMD_GET_TSF
libertas: remove "struct cmd_ds_gen"
libertas: move SIOCGIWAP calls to wext.c
libertas: move mic failure event to wext.c
libertas: sort and categorize entries in decl.h
libertas: remove some references to IW_MODE_abc
Ivo van Doorn (2):
rt2x00: Add rt2x00soc bus module
rt2x00: Implement support for rt2800pci
Javier Cardona (1):
mac80211: Learn about mesh portals from multicast traffic
Jay Sternberg (1):
iwlwifi: add missing commands to syslog messages
John W. Linville (3):
mac80211: replace netif_tx_{start,stop,wake}_all_queues
b43: use ieee80211_rx_ni()
wl1251: re-disable PG10 chips
Juuso Oikarinen (44):
wl1271: Correction to TX block allocation calculation
wl1271: Security sequence number handling for TX (for WPA)
wl1271: Correct TKIP header space handling in TX path
wl1271: Implement delayed entry into ELP
wl1271: mask aid bits 14 and 15 in ps-poll template
wl1271: Implementation for SPI busy word checking
wl1271: Configure rate policies based on AP rates
wl1271: Update join usage
wl1271: Corrections to TX path
wl1271: use workqueue provided by mac80211 instead of the default
wl1271: Clear probe-request template after scan
wl1271: Multicast filtering configuration
wl1271: Use vmalloc to allocate memory for firmware
wl1271: Add connection monitoring configuration
wl1271: Enable beacon filtering with the stack
wl1271: Configure beacon filtering on if PSM used
wl1271: Mask unneeded events from firmware to conserve power
wl1271: Update memory mapping for firmware revision 6.1.0.0.241
wl1271: Remove RX workaround
wl1271: Add top-register access functions
wl1271: RefClk configuration
wl1271: Update interrupt handling by removing an extra SPI read
wl1271: Enable ELP
wl1271: Enable smart reflex
wl1271: Update TX path block calucation algo
wl1271: Remove outdated SPI functions
wl1271: Update boot time configuration for the new firmware
wl1271: Workaround for reference clock setting on boot.
wl1271: Add structure for firmware configuration values
wl1271: Add config structure for RX path parameters
wl1271: Add config structure for TX path parameters
wl1271: Add config structure for connection management parameters
wl1271: Add config structure for FW init parameters
wl1271: Move default FW config struct away from stack
wl1271: Fix IRQ enable handling on FW init failure
wl1271: Implement beacon early termination support
wl1271: Remove busy-word checking
wl1271: Fix multicast list handling
wl1271: Fix event handling mechanism
wl1271: Support for IPv4 ARP filtering
wl1271: Remove unnecessary rx_descriptor memory allocation
wl1271: Correct memory handling for FW boot
wl1271: Fix filter configuration
wl1271: Set IEEE80211_FCTL_TODS in the null data template
Kalle Valo (3):
wl1251: rename spi device to wl1251
mac80211: add ieee80211_rx_ni()
wl1251: use ieee80211_rx_ni()
Luciano Coelho (15):
wl1271: remove unecessary qual parameter from rx status
wl1271: added Juuso Oikarinen as module author
wl1271: hack to disable filters
wl1271: implement cmd_disconnect
wl1271: workaround to send a disconnect before rejoining
wl1271: add workaround to avoid distortion due to excessive tx power
wl1271: enable HW_AVAILABLE interrupt to fix ELP
wl1271: use acx_rx_config instead of join when updating filters
wl1271: remove unnecessary joins and join only when the bssid changes
wl1271: make sure PS is disabled in PLT
wl1271: fix sparse warnings about undeclared functions
wl1271: added missing packed modifier in some acx structs
wl1271: fix endianess issues
wl1271: added missing packed modifier in some cmd structs
wl1271: use ieee80211_rx_ni()
Luis R. Rodriguez (2):
ath9k_hw: run the carrier leakage calibration fix for ar9271 as well
ath9k_hw: run ath9k_hw_9271_pa_cal() initial calibration
Marek Lindner (1):
ath9k: adjust ahb callbacks to new struct layout to avoid compile errors
Matthieu CASTET (1):
airo : allow supend with card without power management
Michael Buesch (4):
b43/legacy: Fix usage of host_pci pointer
ssb: Put host pointers into a union
b43: Remove me as maintainer
b43: Optimize PIO scratchbuffer usage
Reinette Chatre (5):
iwlwifi: fix userspace setting of sleep_level_override
iwlwifi: move iwl_setup_mac to iwlagn
iwlwifi: move rate scaling structures to header file
iwlagn: store station rate scale information in mac80211 station structure
iwlwifi: remove duplicate defines
Rui Paulo (1):
mesh: use set_bit() to set MESH_WORK_HOUSEKEEPING.
Samuel Ortiz (13):
iwmc3200wifi: WPS support
iwmc3200wifi: CT kill support
iwmc3200wifi: Profile flags can be WPA1 or WPA2 not both
iwmc3200wifi: Improve rx debug
iwmc3200wifi: Update statistics notification structure
iwmc3200wifi: Update fixed size config definitions
iwmc3200wifi: Tx power setting
iwmc3200wifi: SDIO disable race fix
iwmc3200wifi: Check for cmd pointer before dereferencing it
iwmc3200wifi: Do not handle wifi command if the interface is not ready
iwmc3200wifi: Try shared auth when open WEP fails
iwmc3200wifi: Support unexpected reboot barker
iwmc3200wifi: Set wiphy firmware version
Sujith (1):
ath9k: Fix TX hang poll routine
Teemu Paasikivi (5):
wl1271: Added 5 GHz parameters for wl1273
wl1271: Scan only enabled channels
wl1271: Added support to scan on 5 GHz band
wl1271: Added 5 GHz support to join and rx
wl1271: Checking of rx descriptor status fixed
Vivek Natarajan (1):
ath: Updates for regulatory and country codes.
Wey-Yi Guy (23):
iwlwifi: remove duplicated/unused definition
iwlwifi: additional items in sensitivity range table
iwlwifi: dynamic allocate tx queue structure
iwlwifi: showing accumulative ucode statistics counters
iwlwifi: update channel switch command API
iwlwifi: show current power save status reported by uCode
iwlwifi: identify eeprom version for 6x50 series NIC
iwlwifi: fix incorrect otp blocks number for 6x50 series
iwlwifi: set auto clock gate disable bit for 6x00/6x50 series
iwlwifi: no chain noise support for 6x50 series
iwlwifi: rework for static power save
iwlwifi: fix gain computation for 5000 series and up
iwlwifi: separate led function from statistic notification
iwlwifi: update bt co-exit configuration parameter
iwlwifi: specify the valid tx/rx chain in device config structure
iwlwifi: increase max tfd payload size
iwlwifi: choose thermal throttle method based on device config
iwlwifi: issue ct_kill host command based on device config
iwlwifi: add channel switch support to 5000 series and up
iwlwifi: remove unused parameters
iwlwifi: remove duplicated define
iwlwifi: update lowest API version support for 6x00 & 6x50 series
iwlwifi: minor comments changes for wimax co-exist command
Zhu Yi (6):
iwlwifi: use paged Rx
iwmc3200wifi: add BGN sdio device id
iwmc3200wifi: allow joining an existed IBSS network
iwmc3200wifi: handle coexistence radio notification
iwlwifi: fix use after free bug for paged rx
iwlwifi: reuse page for notification packets
MAINTAINERS | 1 -
drivers/net/wireless/airo.c | 3 +-
drivers/net/wireless/ath/ar9170/ar9170.h | 2 +-
drivers/net/wireless/ath/ar9170/hw.h | 4 +-
drivers/net/wireless/ath/ar9170/main.c | 11 +-
drivers/net/wireless/ath/ar9170/usb.c | 12 +-
drivers/net/wireless/ath/ar9170/usb.h | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 13 +
drivers/net/wireless/ath/ath5k/attach.c | 2 +
drivers/net/wireless/ath/ath5k/phy.c | 185 +-
drivers/net/wireless/ath/ath5k/reg.h | 11 +-
drivers/net/wireless/ath/ath5k/reset.c | 17 +-
drivers/net/wireless/ath/ath9k/ahb.c | 6 +-
drivers/net/wireless/ath/ath9k/calib.c | 28 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +
drivers/net/wireless/ath/regd.h | 8 +
drivers/net/wireless/ath/regd_common.h | 32 +-
drivers/net/wireless/b43/b43.h | 16 +-
drivers/net/wireless/b43/main.c | 4 +-
drivers/net/wireless/b43/pio.c | 79 +-
drivers/net/wireless/b43/xmit.c | 7 +-
drivers/net/wireless/b43legacy/main.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 17 +-
drivers/net/wireless/iwlwifi/iwl-3945-hw.h | 12 -
drivers/net/wireless/iwlwifi/iwl-3945.c | 237 +-
drivers/net/wireless/iwlwifi/iwl-3945.h | 8 -
drivers/net/wireless/iwlwifi/iwl-4965-hw.h | 3 -
drivers/net/wireless/iwlwifi/iwl-4965.c | 172 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 219 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 172 ++-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 108 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.h | 101 +
drivers/net/wireless/iwlwifi/iwl-agn.c | 154 +-
drivers/net/wireless/iwlwifi/iwl-calib.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-commands.h | 79 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 260 ++-
drivers/net/wireless/iwlwifi/iwl-core.h | 24 +-
drivers/net/wireless/iwlwifi/iwl-csr.h | 11 +-
drivers/net/wireless/iwlwifi/iwl-debug.h | 1 +
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 676 ++++--
drivers/net/wireless/iwlwifi/iwl-dev.h | 82 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 8 +
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 5 +-
drivers/net/wireless/iwlwifi/iwl-hcmd.c | 23 +-
drivers/net/wireless/iwlwifi/iwl-power.c | 83 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 177 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 20 +-
drivers/net/wireless/iwlwifi/iwl-spectrum.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 62 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 45 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 266 ++-
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 47 +-
drivers/net/wireless/iwmc3200wifi/commands.c | 31 +-
drivers/net/wireless/iwmc3200wifi/commands.h | 70 +-
drivers/net/wireless/iwmc3200wifi/fw.c | 9 +
drivers/net/wireless/iwmc3200wifi/iwm.h | 6 +
drivers/net/wireless/iwmc3200wifi/lmac.h | 8 +
drivers/net/wireless/iwmc3200wifi/main.c | 46 +
drivers/net/wireless/iwmc3200wifi/netdev.c | 1 +
drivers/net/wireless/iwmc3200wifi/rx.c | 84 +-
drivers/net/wireless/iwmc3200wifi/sdio.c | 10 +-
drivers/net/wireless/iwmc3200wifi/umac.h | 5 +
drivers/net/wireless/libertas/11d.c | 696 ------
drivers/net/wireless/libertas/11d.h | 105 -
drivers/net/wireless/libertas/Makefile | 1 -
drivers/net/wireless/libertas/assoc.c | 445 ++++-
drivers/net/wireless/libertas/assoc.h | 141 ++-
drivers/net/wireless/libertas/cmd.c | 482 +----
drivers/net/wireless/libertas/cmd.h | 127 +-
drivers/net/wireless/libertas/cmdresp.c | 104 +-
drivers/net/wireless/libertas/debugfs.c | 27 +-
drivers/net/wireless/libertas/decl.h | 62 +-
drivers/net/wireless/libertas/defs.h | 1 -
drivers/net/wireless/libertas/dev.h | 424 +---
drivers/net/wireless/libertas/host.h | 960 +++++++--
drivers/net/wireless/libertas/hostcmd.h | 800 -------
drivers/net/wireless/libertas/main.c | 202 +--
drivers/net/wireless/libertas/persistcfg.c | 8 +-
drivers/net/wireless/libertas/rx.c | 2 +-
drivers/net/wireless/libertas/scan.c | 250 ++-
drivers/net/wireless/libertas/scan.h | 30 +
drivers/net/wireless/libertas/tx.c | 2 +-
drivers/net/wireless/libertas/types.h | 4 +-
drivers/net/wireless/libertas/wext.c | 144 +-
drivers/net/wireless/libertas/wext.h | 8 +
drivers/net/wireless/orinoco/hw.c | 33 +-
drivers/net/wireless/orinoco/hw.h | 3 +-
drivers/net/wireless/orinoco/main.c | 33 +-
drivers/net/wireless/orinoco/orinoco.h | 1 -
drivers/net/wireless/rt2x00/Kconfig | 30 +
drivers/net/wireless/rt2x00/Makefile | 2 +
drivers/net/wireless/rt2x00/rt2800pci.c | 3323 ++++++++++++++++++++++++++
drivers/net/wireless/rt2x00/rt2800pci.h | 1960 +++++++++++++++
drivers/net/wireless/rt2x00/rt2x00.h | 7 +
drivers/net/wireless/rt2x00/rt2x00soc.c | 159 ++
drivers/net/wireless/rt2x00/rt2x00soc.h | 52 +
drivers/net/wireless/wl12xx/wl1251_main.c | 7 +-
drivers/net/wireless/wl12xx/wl1251_rx.c | 2 +-
drivers/net/wireless/wl12xx/wl1251_spi.c | 2 +-
drivers/net/wireless/wl12xx/wl1271.h | 92 +-
drivers/net/wireless/wl12xx/wl1271_acx.c | 369 +++-
drivers/net/wireless/wl12xx/wl1271_acx.h | 586 ++---
drivers/net/wireless/wl12xx/wl1271_boot.c | 215 +-
drivers/net/wireless/wl12xx/wl1271_boot.h | 22 +-
drivers/net/wireless/wl12xx/wl1271_cmd.c | 329 ++-
drivers/net/wireless/wl12xx/wl1271_cmd.h | 115 +-
drivers/net/wireless/wl12xx/wl1271_conf.h | 911 +++++++
drivers/net/wireless/wl12xx/wl1271_event.c | 64 +-
drivers/net/wireless/wl12xx/wl1271_event.h | 30 +-
drivers/net/wireless/wl12xx/wl1271_init.c | 155 +-
drivers/net/wireless/wl12xx/wl1271_init.h | 53 +-
drivers/net/wireless/wl12xx/wl1271_main.c | 963 ++++++--
drivers/net/wireless/wl12xx/wl1271_ps.c | 68 +-
drivers/net/wireless/wl12xx/wl1271_ps.h | 2 +-
drivers/net/wireless/wl12xx/wl1271_reg.h | 47 +-
drivers/net/wireless/wl12xx/wl1271_rx.c | 86 +-
drivers/net/wireless/wl12xx/wl1271_rx.h | 4 +-
drivers/net/wireless/wl12xx/wl1271_spi.c | 311 ++--
drivers/net/wireless/wl12xx/wl1271_spi.h | 65 +-
drivers/net/wireless/wl12xx/wl1271_tx.c | 76 +-
drivers/net/wireless/wl12xx/wl1271_tx.h | 18 +-
drivers/net/wireless/wl12xx/wl12xx_80211.h | 4 +-
drivers/net/wireless/zd1211rw/zd_chip.c | 4 +-
drivers/net/wireless/zd1211rw/zd_chip.h | 18 +-
drivers/net/wireless/zd1211rw/zd_mac.c | 202 ++-
drivers/net/wireless/zd1211rw/zd_mac.h | 25 +-
drivers/net/wireless/zd1211rw/zd_usb.c | 4 +-
drivers/ssb/driver_pcicore.c | 4 +-
include/linux/ssb/ssb.h | 20 +-
include/net/cfg80211.h | 31 +-
include/net/mac80211.h | 32 +-
net/mac80211/iface.c | 4 +-
net/mac80211/mesh.c | 4 +-
net/mac80211/mlme.c | 22 +-
net/mac80211/rx.c | 21 +-
net/mac80211/scan.c | 10 +-
net/wireless/mlme.c | 45 +-
137 files changed, 13469 insertions(+), 6003 deletions(-)
delete mode 100644 drivers/net/wireless/libertas/11d.c
delete mode 100644 drivers/net/wireless/libertas/11d.h
delete mode 100644 drivers/net/wireless/libertas/hostcmd.h
create mode 100644 drivers/net/wireless/rt2x00/rt2800pci.c
create mode 100644 drivers/net/wireless/rt2x00/rt2800pci.h
create mode 100644 drivers/net/wireless/rt2x00/rt2x00soc.c
create mode 100644 drivers/net/wireless/rt2x00/rt2x00soc.h
create mode 100644 drivers/net/wireless/wl12xx/wl1271_conf.h
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-10-28.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [Fwd: Re: [PATCH] Multicast packet reassembly can fail]
From: Steve Chen @ 2009-10-28 21:11 UTC (permalink / raw)
To: David Stevens; +Cc: Eric Dumazet, mhuth, netdev, netdev-owner
In-Reply-To: <OFF3C0AE1C.0C392C88-ON8825765D.006F8D81-8825765D.006FF4C0@us.ibm.com>
On Wed, 2009-10-28 at 13:22 -0700, David Stevens wrote:
> netdev-owner@vger.kernel.org wrote on 10/28/2009 11:25:39 AM:
>
> > I see the point you are making. I assumed, probably incorrectly, that
> > since eth0 and eth1 have different IP address. I would get a complete
> > series of fragments for each interface. Perhaps, I should really be
> > looking up the stack to see why packets were dropped. Please correct me
> > if I'm mistaken. The normal behavior is that application should be
> > receiving either 2 (scenario 1) or 1 (scenario 2) packets.
>
> Steve,
> If you didn't join the group on both interfaces, you won't receive
> two copies in the first place; the unjoined NIC won't deliver anything
> up the stack that isn't in it's multicast address filter.
>
> +-DLS
Thanks for the inputs. I'll revisit the issue.
Steve
^ permalink raw reply
* Re: [PATCH] AF_RAW: Augment raw_send_hdrinc to expand skb to fit iphdr->ihl (v2)
From: Eric Dumazet @ 2009-10-28 21:01 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, davem
In-Reply-To: <20091028185947.GA12675@hmsreliant.think-freely.org>
Neil Horman a écrit :
>
>> I believe we should drop the request, since padding it is not what was expected by user.
>
> Yeah, I had a feeling. Ok, version 2, this time drop the invalid frame and
> report it to user space, instead of expanding it:
>
>
> Augment raw_send_hdrinc to correct for incorrect ip header length values
>
> A series of oopses was reported to me recently. Apparently when using AF_RAW
> sockets to send data to peers that were reachable via ipsec encapsulation,
> people could panic or BUG halt their systems.
>
> I've tracked the problem down to user space sending an invalid ip header over an
> AF_RAW socket with IP_HDRINCL set to 1.
>
> Basically what happens is that userspace sends down an ip frame that includes
> only the header (no data), but sets the ip header ihl value to a large number,
> one that is larger than the total amount of data passed to the sendmsg call. In
> raw_send_hdrincl, we allocate an skb based on the size of the data in the msghdr
> that was passed in, but assume the data is all valid. Later during ipsec
> encapsulation, xfrm4_tranport_output moves the entire frame back in the skbuff
> to provide headroom for the ipsec headers. During this operation, the
> skb->transport_header is repointed to a spot computed by
> skb->network_header + the ip header length (ihl). Since so little data was
> passed in relative to the value of ihl provided by the raw socket, we point
> transport header to an unknown location, resulting in various crashes.
>
> This fix for this is pretty straightforward, simply validate the value of of
> iph->ihl when sending over a raw socket. If (iph->ihl*4U) > user data buffer
> size, drop the frame and return -EINVAL. I just confirmed this fixes the
> reported crashes.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* pull request: wireless-2.6 2009-10-28
From: John W. Linville @ 2009-10-28 20:53 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Dave,
Here is a collection of fixes (mostly (almost-)one-liners) intended
for 2.6.32. There are a couple of fixes relating to behavior when an
association failes, as well as spelling fixes, simply endian fixes,
a MAINTAINERS change...I don't think there is anything controversial
here...
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit 66ed1e5ec1d979e572554643063734a7664261bb:
Eric Dumazet (1):
pktgen: Dont leak kernel memory
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Andrey Yurovsky (1):
mac80211: trivial: fix spelling in mesh_hwmp
Bartlomiej Zolnierkiewicz (1):
MAINTAINERS: rt2x00 list is moderated
Benoit PAPILLAULT (1):
rt2x00: Fix crypto in TX frame for rt2800usb
Björn Smedman (1):
mac80211: fix for incorrect sequence number on hostapd injected frames
Holger Schurig (1):
libertas spi: fix sparse errors
Johannes Berg (2):
mac80211: keep auth state when assoc fails
cfg80211: sme: deauthenticate on assoc failure
Larry Finger (1):
b43: Fix Bugzilla #14181 and the bug from the previous 'fix'
Miguel Boton (1):
b43: add 'struct b43_wl' missing declaration
Reinette Chatre (1):
mac80211: fix ibss joining
Roel Kluin (1):
airo: Reorder tests, check bounds before element
MAINTAINERS | 2 +-
drivers/net/wireless/airo.c | 5 ++---
drivers/net/wireless/b43/leds.h | 1 +
drivers/net/wireless/b43/main.c | 1 -
drivers/net/wireless/b43/rfkill.c | 3 ++-
drivers/net/wireless/libertas/if_spi.c | 10 +++++-----
drivers/net/wireless/rt2x00/rt2800usb.c | 2 +-
net/mac80211/ibss.c | 6 ++----
net/mac80211/mesh_hwmp.c | 2 +-
net/mac80211/mlme.c | 3 +--
net/mac80211/tx.c | 2 +-
net/wireless/core.h | 1 +
net/wireless/mlme.c | 9 +++++++++
net/wireless/sme.c | 21 +++++++++++++++++++--
14 files changed, 46 insertions(+), 22 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 70bc7de..cdbbaf5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4280,7 +4280,7 @@ F: drivers/video/aty/aty128fb.c
RALINK RT2X00 WIRELESS LAN DRIVER
P: rt2x00 project
L: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-L: users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H@public.gmane.org
+L: users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H@public.gmane.org (moderated for non-subscribers)
W: http://rt2x00.serialmonkey.com/
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ivd/rt2x00.git
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 7116a1a..abf896a 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -4790,9 +4790,8 @@ static int proc_stats_rid_open( struct inode *inode,
static int get_dec_u16( char *buffer, int *start, int limit ) {
u16 value;
int valid = 0;
- for( value = 0; buffer[*start] >= '0' &&
- buffer[*start] <= '9' &&
- *start < limit; (*start)++ ) {
+ for (value = 0; *start < limit && buffer[*start] >= '0' &&
+ buffer[*start] <= '9'; (*start)++) {
valid = 1;
value *= 10;
value += buffer[*start] - '0';
diff --git a/drivers/net/wireless/b43/leds.h b/drivers/net/wireless/b43/leds.h
index 4c56187..32b66d5 100644
--- a/drivers/net/wireless/b43/leds.h
+++ b/drivers/net/wireless/b43/leds.h
@@ -1,6 +1,7 @@
#ifndef B43_LEDS_H_
#define B43_LEDS_H_
+struct b43_wl;
struct b43_wldev;
#ifdef CONFIG_B43_LEDS
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index df6b26a..86f3582 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -4501,7 +4501,6 @@ static void b43_op_stop(struct ieee80211_hw *hw)
cancel_work_sync(&(wl->beacon_update_trigger));
- wiphy_rfkill_stop_polling(hw->wiphy);
mutex_lock(&wl->mutex);
if (b43_status(dev) >= B43_STAT_STARTED) {
dev = b43_wireless_core_stop(dev);
diff --git a/drivers/net/wireless/b43/rfkill.c b/drivers/net/wireless/b43/rfkill.c
index 7a3218c..ffdce6f 100644
--- a/drivers/net/wireless/b43/rfkill.c
+++ b/drivers/net/wireless/b43/rfkill.c
@@ -33,7 +33,8 @@ bool b43_is_hw_radio_enabled(struct b43_wldev *dev)
& B43_MMIO_RADIO_HWENABLED_HI_MASK))
return 1;
} else {
- if (b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
+ if (b43_status(dev) >= B43_STAT_STARTED &&
+ b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
& B43_MMIO_RADIO_HWENABLED_LO_MASK)
return 1;
}
diff --git a/drivers/net/wireless/libertas/if_spi.c b/drivers/net/wireless/libertas/if_spi.c
index cb8be8d..5b3672c 100644
--- a/drivers/net/wireless/libertas/if_spi.c
+++ b/drivers/net/wireless/libertas/if_spi.c
@@ -134,7 +134,7 @@ static void spu_transaction_finish(struct if_spi_card *card)
static int spu_write(struct if_spi_card *card, u16 reg, const u8 *buf, int len)
{
int err = 0;
- u16 reg_out = cpu_to_le16(reg | IF_SPI_WRITE_OPERATION_MASK);
+ __le16 reg_out = cpu_to_le16(reg | IF_SPI_WRITE_OPERATION_MASK);
struct spi_message m;
struct spi_transfer reg_trans;
struct spi_transfer data_trans;
@@ -166,7 +166,7 @@ static int spu_write(struct if_spi_card *card, u16 reg, const u8 *buf, int len)
static inline int spu_write_u16(struct if_spi_card *card, u16 reg, u16 val)
{
- u16 buff;
+ __le16 buff;
buff = cpu_to_le16(val);
return spu_write(card, reg, (u8 *)&buff, sizeof(u16));
@@ -188,7 +188,7 @@ static int spu_read(struct if_spi_card *card, u16 reg, u8 *buf, int len)
{
unsigned int delay;
int err = 0;
- u16 reg_out = cpu_to_le16(reg | IF_SPI_READ_OPERATION_MASK);
+ __le16 reg_out = cpu_to_le16(reg | IF_SPI_READ_OPERATION_MASK);
struct spi_message m;
struct spi_transfer reg_trans;
struct spi_transfer dummy_trans;
@@ -235,7 +235,7 @@ static int spu_read(struct if_spi_card *card, u16 reg, u8 *buf, int len)
/* Read 16 bits from an SPI register */
static inline int spu_read_u16(struct if_spi_card *card, u16 reg, u16 *val)
{
- u16 buf;
+ __le16 buf;
int ret;
ret = spu_read(card, reg, (u8 *)&buf, sizeof(buf));
@@ -248,7 +248,7 @@ static inline int spu_read_u16(struct if_spi_card *card, u16 reg, u16 *val)
* The low 16 bits are read first. */
static int spu_read_u32(struct if_spi_card *card, u16 reg, u32 *val)
{
- u32 buf;
+ __le32 buf;
int err;
err = spu_read(card, reg, (u8 *)&buf, sizeof(buf));
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index a084077..9fe770f 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1994,7 +1994,7 @@ static void rt2800usb_write_tx_desc(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(&word, TXWI_W1_BW_WIN_SIZE, txdesc->ba_size);
rt2x00_set_field32(&word, TXWI_W1_WIRELESS_CLI_ID,
test_bit(ENTRY_TXD_ENCRYPT, &txdesc->flags) ?
- (skbdesc->entry->entry_idx + 1) : 0xff);
+ txdesc->key_idx : 0xff);
rt2x00_set_field32(&word, TXWI_W1_MPDU_TOTAL_BYTE_COUNT,
skb->len - txdesc->l2pad);
rt2x00_set_field32(&word, TXWI_W1_PACKETID,
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 6eaf698..ca8ecce 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -538,13 +538,12 @@ static void ieee80211_sta_find_ibss(struct ieee80211_sub_if_data *sdata)
WLAN_CAPABILITY_PRIVACY,
capability);
+ if (bss) {
#ifdef CONFIG_MAC80211_IBSS_DEBUG
- if (bss)
printk(KERN_DEBUG " sta_find_ibss: selected %pM current "
"%pM\n", bss->cbss.bssid, ifibss->bssid);
#endif /* CONFIG_MAC80211_IBSS_DEBUG */
- if (bss && !memcmp(ifibss->bssid, bss->cbss.bssid, ETH_ALEN)) {
printk(KERN_DEBUG "%s: Selected IBSS BSSID %pM"
" based on configured SSID\n",
sdata->dev->name, bss->cbss.bssid);
@@ -552,8 +551,7 @@ static void ieee80211_sta_find_ibss(struct ieee80211_sub_if_data *sdata)
ieee80211_sta_join_ibss(sdata, bss);
ieee80211_rx_bss_put(local, bss);
return;
- } else if (bss)
- ieee80211_rx_bss_put(local, bss);
+ }
#ifdef CONFIG_MAC80211_IBSS_DEBUG
printk(KERN_DEBUG " did not try to join ibss\n");
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index e12a786..29b82e9 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -259,7 +259,7 @@ static u32 airtime_link_metric_get(struct ieee80211_local *local,
* @hwmp_ie: hwmp information element (PREP or PREQ)
*
* This function updates the path routing information to the originator and the
- * transmitter of a HWMP PREQ or PREP fram.
+ * transmitter of a HWMP PREQ or PREP frame.
*
* Returns: metric to frame originator or 0 if the frame should not be further
* processed
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 8d26e9b..dc5049d 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1457,8 +1457,7 @@ ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
if (status_code != WLAN_STATUS_SUCCESS) {
printk(KERN_DEBUG "%s: AP denied association (code=%d)\n",
sdata->dev->name, status_code);
- list_del(&wk->list);
- kfree(wk);
+ wk->state = IEEE80211_MGD_STATE_IDLE;
return RX_MGMT_CFG80211_ASSOC;
}
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index db4bda6..eaa4118 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1445,7 +1445,7 @@ static void ieee80211_xmit(struct ieee80211_sub_if_data *sdata,
if (tmp_sdata->vif.type != NL80211_IFTYPE_AP)
continue;
if (compare_ether_addr(tmp_sdata->dev->dev_addr,
- hdr->addr2)) {
+ hdr->addr2) == 0) {
dev_hold(tmp_sdata->dev);
dev_put(sdata->dev);
sdata = tmp_sdata;
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 2a33d8b..68b3219 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -358,6 +358,7 @@ int cfg80211_mgd_wext_connect(struct cfg80211_registered_device *rdev,
struct wireless_dev *wdev);
void cfg80211_conn_work(struct work_struct *work);
+void cfg80211_sme_failed_assoc(struct wireless_dev *wdev);
bool cfg80211_sme_failed_reassoc(struct wireless_dev *wdev);
/* internal helpers */
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 79d2eec..0a6b7a0 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -62,6 +62,7 @@ void cfg80211_send_rx_assoc(struct net_device *dev, const u8 *buf, size_t len)
u8 *ie = mgmt->u.assoc_resp.variable;
int i, ieoffs = offsetof(struct ieee80211_mgmt, u.assoc_resp.variable);
struct cfg80211_internal_bss *bss = NULL;
+ bool need_connect_result = true;
wdev_lock(wdev);
@@ -94,6 +95,14 @@ void cfg80211_send_rx_assoc(struct net_device *dev, const u8 *buf, size_t len)
}
WARN_ON(!bss);
+ } else if (wdev->conn) {
+ cfg80211_sme_failed_assoc(wdev);
+ need_connect_result = false;
+ /*
+ * do not call connect_result() now because the
+ * sme will schedule work that does it later.
+ */
+ goto out;
}
if (!wdev->conn && wdev->sme_state == CFG80211_SME_IDLE) {
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 93c3ed3..ece378d 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -26,6 +26,7 @@ struct cfg80211_conn {
CFG80211_CONN_AUTHENTICATING,
CFG80211_CONN_ASSOCIATE_NEXT,
CFG80211_CONN_ASSOCIATING,
+ CFG80211_CONN_DEAUTH_ASSOC_FAIL,
} state;
u8 bssid[ETH_ALEN], prev_bssid[ETH_ALEN];
u8 *ie;
@@ -148,6 +149,12 @@ static int cfg80211_conn_do_work(struct wireless_dev *wdev)
NULL, 0,
WLAN_REASON_DEAUTH_LEAVING);
return err;
+ case CFG80211_CONN_DEAUTH_ASSOC_FAIL:
+ __cfg80211_mlme_deauth(rdev, wdev->netdev, params->bssid,
+ NULL, 0,
+ WLAN_REASON_DEAUTH_LEAVING);
+ /* return an error so that we call __cfg80211_connect_result() */
+ return -EINVAL;
default:
return 0;
}
@@ -158,6 +165,7 @@ void cfg80211_conn_work(struct work_struct *work)
struct cfg80211_registered_device *rdev =
container_of(work, struct cfg80211_registered_device, conn_work);
struct wireless_dev *wdev;
+ u8 bssid[ETH_ALEN];
rtnl_lock();
cfg80211_lock_rdev(rdev);
@@ -173,10 +181,10 @@ void cfg80211_conn_work(struct work_struct *work)
wdev_unlock(wdev);
continue;
}
+ memcpy(bssid, wdev->conn->params.bssid, ETH_ALEN);
if (cfg80211_conn_do_work(wdev))
__cfg80211_connect_result(
- wdev->netdev,
- wdev->conn->params.bssid,
+ wdev->netdev, bssid,
NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
false, NULL);
@@ -337,6 +345,15 @@ bool cfg80211_sme_failed_reassoc(struct wireless_dev *wdev)
return true;
}
+void cfg80211_sme_failed_assoc(struct wireless_dev *wdev)
+{
+ struct wiphy *wiphy = wdev->wiphy;
+ struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
+
+ wdev->conn->state = CFG80211_CONN_DEAUTH_ASSOC_FAIL;
+ schedule_work(&rdev->conn_work);
+}
+
void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
const u8 *req_ie, size_t req_ie_len,
const u8 *resp_ie, size_t resp_ie_len,
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
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 related
* Re: [PATCH 4/6] vlan: Optimize multiple unregistration
From: Eric Dumazet @ 2009-10-28 20:47 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4AE8A425.1000600@trash.net>
Patrick McHardy a écrit :
> Eric Dumazet wrote:
>> Use unregister_netdevice_many() to speedup master device unregister.
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> ---
>> include/linux/if_vlan.h | 1
>> net/8021q/vlan.c | 49 +++++++++++++++++++++++++-------------
>> net/core/dev.c | 1
>> 3 files changed, 35 insertions(+), 16 deletions(-)
>>
>> diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
>> index 8898cbe..71a4870 100644
>> --- a/include/linux/if_vlan.h
>> +++ b/include/linux/if_vlan.h
>> @@ -85,6 +85,7 @@ struct vlan_group {
>> * the vlan is attached to.
>> */
>> unsigned int nr_vlans;
>> + int killall;
>> struct hlist_node hlist; /* linked list */
>> struct net_device **vlan_devices_arrays[VLAN_GROUP_ARRAY_SPLIT_PARTS];
>> struct rcu_head rcu;
>> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
>> index 6b5c9dd..511afe7 100644
>> --- a/net/8021q/vlan.c
>> +++ b/net/8021q/vlan.c
>> @@ -159,11 +159,12 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
>> if (real_dev->features & NETIF_F_HW_VLAN_FILTER)
>> ops->ndo_vlan_rx_kill_vid(real_dev, vlan_id);
>>
>> - vlan_group_set_device(grp, vlan_id, NULL);
>> grp->nr_vlans--;
>>
>> - synchronize_net();
>> -
>> + if (!grp->killall) {
>> + vlan_group_set_device(grp, vlan_id, NULL);
>> + synchronize_net();
>> + }
>> unregister_netdevice_queue(dev, head);
>>
>> /* If the group is now empty, kill off the group. */
>> @@ -183,6 +184,34 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
>> dev_put(real_dev);
>> }
>>
>> +void unregister_vlan_dev_alls(struct vlan_group *grp)
>
> This could be static.
>
>> +{
>> + LIST_HEAD(list);
>> + int i;
>> + struct net_device *vlandev;
>> + struct vlan_group save;
>> +
>> + memcpy(&save, grp, sizeof(save));
>> + memset(&grp->vlan_devices_arrays, 0, sizeof(grp->vlan_devices_arrays));
>
> This shouldn't be necessary since the lower device is already in the
> process of being unregistered. If it was necessary, it could cause
> crashes since the individual pointers are not set to zero atomically.
> Or maybe I'm misunderstanding the purpose entirely :)
Very good point indeed, even if in practice memset() use long word transferts
I'll make a cleanup patch, or do you want to do it ?
^ permalink raw reply
* Re: iproute uses too small of a receive buffer
From: Eric Dumazet @ 2009-10-28 20:38 UTC (permalink / raw)
To: Ben Greear; +Cc: Patrick McHardy, Stephen Hemminger, NetDev
In-Reply-To: <4AE89927.9090405@candelatech.com>
Ben Greear a écrit :
> Second: Why bail on ENOBUFS at all? I don't see how it helps the user
> since they will probably just have to start it again, and will miss more
> messages than keeping going would have.
>
> And, even 1MB may not be enough for some scenarios. So, probably best to
> let users over-ride the initial setting on cmd-line. If not, then use
> a large value to start with.
>
In this case, just dont call setsockopt() at all in "ip" and let system use the
standard/default value (/proc/sys/net/core/rmem_default) that an admin can change
if he wants to handle one million devices :)
^ permalink raw reply
* Re: [Fwd: Re: [PATCH] Multicast packet reassembly can fail]
From: David Stevens @ 2009-10-28 20:22 UTC (permalink / raw)
To: Steve Chen; +Cc: Eric Dumazet, mhuth, netdev, netdev-owner
In-Reply-To: <1256754339.3153.481.camel@linux-1lbu>
netdev-owner@vger.kernel.org wrote on 10/28/2009 11:25:39 AM:
> I see the point you are making. I assumed, probably incorrectly, that
> since eth0 and eth1 have different IP address. I would get a complete
> series of fragments for each interface. Perhaps, I should really be
> looking up the stack to see why packets were dropped. Please correct me
> if I'm mistaken. The normal behavior is that application should be
> receiving either 2 (scenario 1) or 1 (scenario 2) packets.
Steve,
If you didn't join the group on both interfaces, you won't receive
two copies in the first place; the unjoined NIC won't deliver anything
up the stack that isn't in it's multicast address filter.
+-DLS
^ permalink raw reply
* Re: iproute uses too small of a receive buffer
From: Ben Greear @ 2009-10-28 20:21 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, Stephen Hemminger, NetDev
In-Reply-To: <4AE8A48A.1060407@trash.net>
On 10/28/2009 01:07 PM, Patrick McHardy wrote:
> Ben Greear wrote:
>> On 10/28/2009 12:50 PM, Patrick McHardy wrote:
>>
>>>> And, even 1MB may not be enough for some scenarios. So, probably
>>>> best to
>>>> let users over-ride the initial setting on cmd-line. If not, then use
>>>> a large value to start with.
>>>
>>> How about this? It uses 1MB as receive buf limit by default (without
>>> increasing /proc/sys/net/core/rmem_max it will be limited by less
>>> however) and allows to specify the size manually using "-rcvbuf X"
>>> (-r is already used, so you need to specify at least -rc).
>>>
>>> Additionally rtnl_listen() continues on ENOBUFS after printing the
>>> error message.
>>
>> Looks good..except:
>>
>> If rmem_max is smaller than 1M, will that cause setsocktopt to
>> fail and thus fail early out of rtnl_open_byproto?
>
> No, the kernel takes the value as a hint and only uses the
> maximum allowable value:
Sweet. No complaints from me then.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* nfs broken in net-next?
From: Yinghai Lu @ 2009-10-28 20:13 UTC (permalink / raw)
To: David Miller; +Cc: Linux Kernel Mailing List, NetDev
pk12-3214-189-102:~ # mount -t nfs 10.6.75.100:/data/shared/pxeboot /x
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
using opensuse11.1
YH
^ permalink raw reply
* Re: [PATCH] Multicast packet reassembly can fail
From: David Stevens @ 2009-10-28 20:12 UTC (permalink / raw)
To: Steve Chen; +Cc: netdev, netdev-owner
In-Reply-To: <1256683583.3153.389.camel@linux-1lbu>
I haven't gone through the entire thread yet, but I should point
out that this appears to break regular IP fragmentation for
unicast packets. There is no restriction whatsoever that
fragments from a remote destination that are actually for
the same datagram need to be routed on the same paths
and received on the same input interface.
For the multicast case, if they are from the same datagram,
it doesn't matter how you got them. If it's a different datagram
with the same ID, which can happen anyway, the checksum
should fail (at least (64K-1) of 64K cases). I don't see a special
case here, other than that you can tell by the interface if it was
actually a distinct datagram with the same ID in the multicast
case (and only in multicast and only if the different interfaces
are not in the same multicast routing domain).
NACK.
+-DLS
^ permalink raw reply
* Re: [PATCH 1/7] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
From: Andrew Morton @ 2009-10-28 20:11 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-kernel, FUJITA Tomonori, David S. Miller, sparclinux,
Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Greg Kroah-Hartman, Lothar Wassmann, linux-usb, Roland Dreier,
Yevgeny Petrilin, netdev, Tony Luck, Fenghua Yu, linux-ia64,
linux-altix, Joerg Roedel
In-Reply-To: <1256719397-4258-1-git-send-email-akinobu.mita@gmail.com>
Why were these patches resent? What changed?
Everybody who is going to review these patches has already reviewed
them and now they need to review them all again?
^ permalink raw reply
* Re: iproute uses too small of a receive buffer
From: Patrick McHardy @ 2009-10-28 20:07 UTC (permalink / raw)
To: Ben Greear; +Cc: Eric Dumazet, Stephen Hemminger, NetDev
In-Reply-To: <4AE8A3C3.1070003@candelatech.com>
Ben Greear wrote:
> On 10/28/2009 12:50 PM, Patrick McHardy wrote:
>
>>> And, even 1MB may not be enough for some scenarios. So, probably
>>> best to
>>> let users over-ride the initial setting on cmd-line. If not, then use
>>> a large value to start with.
>>
>> How about this? It uses 1MB as receive buf limit by default (without
>> increasing /proc/sys/net/core/rmem_max it will be limited by less
>> however) and allows to specify the size manually using "-rcvbuf X"
>> (-r is already used, so you need to specify at least -rc).
>>
>> Additionally rtnl_listen() continues on ENOBUFS after printing the
>> error message.
>
> Looks good..except:
>
> If rmem_max is smaller than 1M, will that cause setsocktopt to
> fail and thus fail early out of rtnl_open_byproto?
No, the kernel takes the value as a hint and only uses the
maximum allowable value:
case SO_RCVBUF:
/* Don't error on this BSD doesn't and if you think
about it this is right. Otherwise apps have to
play 'guess the biggest size' games. RCVBUF/SNDBUF
are treated in BSD as hints */
if (val > sysctl_rmem_max)
val = sysctl_rmem_max;
> Maybe we should only print errors but not return in that method
> when setsockopt fails?
>
> In another project, I ended up trying ever smaller values until one
> worked in order to get near what the user wanted even if rmem_max
> was configured smaller. Not sure if that is worth doing here or not.
I think it should be fine this way.
^ permalink raw reply
* Re: [PATCH 4/6] vlan: Optimize multiple unregistration
From: Patrick McHardy @ 2009-10-28 20:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4AE728A9.2080209@gmail.com>
Eric Dumazet wrote:
> Use unregister_netdevice_many() to speedup master device unregister.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> include/linux/if_vlan.h | 1
> net/8021q/vlan.c | 49 +++++++++++++++++++++++++-------------
> net/core/dev.c | 1
> 3 files changed, 35 insertions(+), 16 deletions(-)
>
> diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
> index 8898cbe..71a4870 100644
> --- a/include/linux/if_vlan.h
> +++ b/include/linux/if_vlan.h
> @@ -85,6 +85,7 @@ struct vlan_group {
> * the vlan is attached to.
> */
> unsigned int nr_vlans;
> + int killall;
> struct hlist_node hlist; /* linked list */
> struct net_device **vlan_devices_arrays[VLAN_GROUP_ARRAY_SPLIT_PARTS];
> struct rcu_head rcu;
> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
> index 6b5c9dd..511afe7 100644
> --- a/net/8021q/vlan.c
> +++ b/net/8021q/vlan.c
> @@ -159,11 +159,12 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
> if (real_dev->features & NETIF_F_HW_VLAN_FILTER)
> ops->ndo_vlan_rx_kill_vid(real_dev, vlan_id);
>
> - vlan_group_set_device(grp, vlan_id, NULL);
> grp->nr_vlans--;
>
> - synchronize_net();
> -
> + if (!grp->killall) {
> + vlan_group_set_device(grp, vlan_id, NULL);
> + synchronize_net();
> + }
> unregister_netdevice_queue(dev, head);
>
> /* If the group is now empty, kill off the group. */
> @@ -183,6 +184,34 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
> dev_put(real_dev);
> }
>
> +void unregister_vlan_dev_alls(struct vlan_group *grp)
This could be static.
> +{
> + LIST_HEAD(list);
> + int i;
> + struct net_device *vlandev;
> + struct vlan_group save;
> +
> + memcpy(&save, grp, sizeof(save));
> + memset(&grp->vlan_devices_arrays, 0, sizeof(grp->vlan_devices_arrays));
This shouldn't be necessary since the lower device is already in the
process of being unregistered. If it was necessary, it could cause
crashes since the individual pointers are not set to zero atomically.
Or maybe I'm misunderstanding the purpose entirely :)
> + grp->killall = 1;
> +
> + synchronize_net();
> +
> + /* Delete all VLANs for this dev. */
> + for (i = 0; i < VLAN_GROUP_ARRAY_LEN; i++) {
> + vlandev = vlan_group_get_device(&save, i);
> + if (!vlandev)
> + continue;
> +
> + unregister_vlan_dev(vlandev, &list);
> + if (grp->nr_vlans == 0)
> + break;
> + }
> + unregister_netdevice_many(&list);
> + for (i = 0; i < VLAN_GROUP_ARRAY_SPLIT_PARTS; i++)
> + kfree(save.vlan_devices_arrays[i]);
> +}
> +
> static void vlan_transfer_operstate(const struct net_device *dev,
> struct net_device *vlandev)
> {
> @@ -524,19 +553,7 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
> break;
>
> case NETDEV_UNREGISTER:
> - /* Delete all VLANs for this dev. */
> - for (i = 0; i < VLAN_GROUP_ARRAY_LEN; i++) {
> - vlandev = vlan_group_get_device(grp, i);
> - if (!vlandev)
> - continue;
> -
> - /* unregistration of last vlan destroys group, abort
> - * afterwards */
> - if (grp->nr_vlans == 1)
> - i = VLAN_GROUP_ARRAY_LEN;
> -
> - unregister_vlan_dev(vlandev, NULL);
> - }
> + unregister_vlan_dev_alls(grp);
> break;
> }
>
^ permalink raw reply
* Re: iproute uses too small of a receive buffer
From: Ben Greear @ 2009-10-28 20:04 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, Stephen Hemminger, NetDev
In-Reply-To: <4AE8A098.8040207@trash.net>
On 10/28/2009 12:50 PM, Patrick McHardy wrote:
>> And, even 1MB may not be enough for some scenarios. So, probably best to
>> let users over-ride the initial setting on cmd-line. If not, then use
>> a large value to start with.
>
> How about this? It uses 1MB as receive buf limit by default (without
> increasing /proc/sys/net/core/rmem_max it will be limited by less
> however) and allows to specify the size manually using "-rcvbuf X"
> (-r is already used, so you need to specify at least -rc).
>
> Additionally rtnl_listen() continues on ENOBUFS after printing the
> error message.
Looks good..except:
If rmem_max is smaller than 1M, will that cause setsocktopt to
fail and thus fail early out of rtnl_open_byproto?
Maybe we should only print errors but not return in that method
when setsockopt fails?
In another project, I ended up trying ever smaller values until one
worked in order to get near what the user wanted even if rmem_max
was configured smaller. Not sure if that is worth doing here or not.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: iproute uses too small of a receive buffer
From: Patrick McHardy @ 2009-10-28 19:50 UTC (permalink / raw)
To: Ben Greear; +Cc: Eric Dumazet, Stephen Hemminger, NetDev
In-Reply-To: <4AE89927.9090405@candelatech.com>
[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]
Ben Greear wrote:
> On 10/28/2009 12:05 PM, Patrick McHardy wrote:
>> Eric Dumazet wrote:
>>> Stephen Hemminger a écrit :
>>>> Just having larger buffer isn't guarantee of success. Allocating
>>>> a huge buffer is not going to work on embedded.
>>>>
>>>
>>> Please note we do not allocate a big buffer, only allow more small skbs
>>> to be queued on socket receive queue.
>>>
>>> If memory is not available, skb allocation will eventually fail
>>> and be reported as well, embedded or not.
>>>
>>> I vote for allowing 1024*1024 bytes instead of 32768,
>>> and eventually user should be warned that it is capped by
>>> /proc/sys/net/core/rmem_max
>>
>> How about this? It will double the receive queue limit on ENOBUFS
>> up to 1024 * 1024b, then bail out with the normal error message on
>> further ENOBUFS.
>>
>> Signed-off-by: Patrick McHardy<kaber@trash.net>
>
> First: This still pretty much guarantees that messages will be lost when
> the program starts (when messages are coming in too large of chunks for
> small buffers)
> If you are debugging something tricky, having lost messages will be
> very annoying!
Yeah, on second thought the probing also doesn't make too much sense
since the memory is only used when its really needed anyways. And its
capped by rmem_max.
> Second: Why bail on ENOBUFS at all? I don't see how it helps the user
> since they will probably just have to start it again, and will miss more
> messages than keeping going would have.
Agreed.
> And, even 1MB may not be enough for some scenarios. So, probably best to
> let users over-ride the initial setting on cmd-line. If not, then use
> a large value to start with.
How about this? It uses 1MB as receive buf limit by default (without
increasing /proc/sys/net/core/rmem_max it will be limited by less
however) and allows to specify the size manually using "-rcvbuf X"
(-r is already used, so you need to specify at least -rc).
Additionally rtnl_listen() continues on ENOBUFS after printing the
error message.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 2170 bytes --]
diff --git a/include/libnetlink.h b/include/libnetlink.h
index 0e02468..61da15b 100644
--- a/include/libnetlink.h
+++ b/include/libnetlink.h
@@ -17,6 +17,8 @@ struct rtnl_handle
__u32 dump;
};
+extern int rcvbuf;
+
extern int rtnl_open(struct rtnl_handle *rth, unsigned subscriptions);
extern int rtnl_open_byproto(struct rtnl_handle *rth, unsigned subscriptions, int protocol);
extern void rtnl_close(struct rtnl_handle *rth);
diff --git a/ip/ip.c b/ip/ip.c
index 2bd54b2..b4c076a 100644
--- a/ip/ip.c
+++ b/ip/ip.c
@@ -50,7 +50,8 @@ static void usage(void)
" tunnel | maddr | mroute | monitor | xfrm }\n"
" OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |\n"
" -f[amily] { inet | inet6 | ipx | dnet | link } |\n"
-" -o[neline] | -t[imestamp] | -b[atch] [filename] }\n");
+" -o[neline] | -t[imestamp] | -b[atch] [filename] |\n"
+" -rc[vbuf] [size]}\n");
exit(-1);
}
@@ -213,6 +214,19 @@ int main(int argc, char **argv)
if (argc <= 1)
usage();
batch_file = argv[1];
+ } else if (matches(opt, "-rcvbuf") == 0) {
+ unsigned int size;
+
+ argc--;
+ argv++;
+ if (argc <= 1)
+ usage();
+ if (get_unsigned(&size, argv[1], 0)) {
+ fprintf(stderr, "Invalid rcvbuf size '%s'\n",
+ argv[1]);
+ exit(-1);
+ }
+ rcvbuf = size;
} else if (matches(opt, "-help") == 0) {
usage();
} else {
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index b68e2fd..5c716ab 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -25,6 +25,8 @@
#include "libnetlink.h"
+int rcvbuf = 1024 * 1024;
+
void rtnl_close(struct rtnl_handle *rth)
{
if (rth->fd >= 0) {
@@ -38,7 +40,6 @@ int rtnl_open_byproto(struct rtnl_handle *rth, unsigned subscriptions,
{
socklen_t addr_len;
int sndbuf = 32768;
- int rcvbuf = 32768;
memset(rth, 0, sizeof(*rth));
@@ -409,6 +410,8 @@ int rtnl_listen(struct rtnl_handle *rtnl,
continue;
fprintf(stderr, "netlink receive error %s (%d)\n",
strerror(errno), errno);
+ if (errno == ENOBUFS)
+ continue;
return -1;
}
if (status == 0) {
^ permalink raw reply related
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