* Re: [PATCH v2] net/r8169: update the new parser for the new firmware
From: Ben Hutchings @ 2011-06-17 12:22 UTC (permalink / raw)
To: Francois Romieu; +Cc: hayeswang, netdev, linux-kernel
In-Reply-To: <20110617063948.GA2146@electric-eye.fr.zoreil.com>
On Fri, 2011-06-17 at 08:39 +0200, Francois Romieu wrote:
> hayeswang <hayeswang@realtek.com> :
> > Francois Romieu :
> [...]
> > > The new firmware format should be the same. The old
> > > r8168d-1.fw firmware proved usable when prefixed with :
> > >
> > > 0000000: 0000 0000 3031 0000 0000 0000 0000 0000 ....01..........
> > > 0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> > > 0000020: 0000 0000 3000 0000 7501 0000 a000 0000 ....0...u.......
> > >
> > > I realized after testing that netif_err could be abused with
> > > non-string fw_info.version. :o/
> > >
> >
> > Excuse me. I don't understand what you want to express. Do you mean the
> > situation of the old paser with the new firmware for checking the firmware?
>
> No. The code does a printk with a %s specifier on fw_info.version while there
> is no evidence that fw_info.version is 0 terminated.
I thought the idea of embedding a version here was to be able to report
in in get_drvinfo, not to print it on load.
Ben.
> > For the normal situation, the old paser would not use the new firmware.
> > And I put zero in front of the new firmware to prevent the old paser from
> > running it. That is all I do.
>
> It is fine.
>
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v2] net/r8169: update the new parser for the new firmware
From: Francois Romieu @ 2011-06-17 12:53 UTC (permalink / raw)
To: Ben Hutchings; +Cc: hayeswang, netdev, linux-kernel
In-Reply-To: <1308313364.11457.63.camel@localhost>
Ben Hutchings <bhutchings@solarflare.com> :
[...]
> I thought the idea of embedding a version here was to be able to report
> in in get_drvinfo, not to print it on load.
Reporting the version for the new firmware format through ethtool is
currently hacked on.
Do you want the load time version / format messages removed ?
I think they can be of some use - at least temporarily - but I won't mind
removing them now.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] net: Add sendmmsg socket system call
From: Brandon Black @ 2011-06-17 13:15 UTC (permalink / raw)
To: netdev; +Cc: Arnaldo Carvalho de Melo, anton
Re: the patch in http://lists.openwall.net/netdev/2011/05/03/12 ,
which is now in the 3.0-rc kernels
I was wondering if would it be possible / valid to add support to
sendmmsg() for skipping packets with a zero msg_iovlen? The use-case
I'm think of here is a daemon that's basically looping on recvmmsg() +
sendmmsg() to cut overhead. The simplest userspace approach in this
sort of case is to re-use the same mmsg_hdr and set of iov's for both
recvmmsg() and sendmmsg().
Consider this scenario though: It may, for example, receive 8 packets,
parse them in userspace, decide packet #5 is malformed, and then wish
to respond only to packets 1-4,6-8. However, in order to drop a
response packet from the set with the current sendmmsg()
implementation, the userspace code would have to shift all of the
mmsg_hdr entries down to close the gaps where no response was desired.
If sendmmsg() had code to simply skip the underlying sendmsg() on
msg_iovlen = 0, it becomes a lot simpler to handle this case. sendmsg
with a msg_iovlen of zero currently sends a packet with no data (just
UDP headers in the UDP case) it seems.
The arguments against this would be that some applications may have a
use for sending zero-data-bytes packets via this mechanism today
(although there's the alternate path for this with msg_iovlen = 1 and
a zero length for the actual iov within), and the overhead of adding
another branch in the sendmmsg() code. I suppose there's a middle
route too, where we add a custom flags for sendmmsg() to turn on this
behavior, and leave the default at today's behavior.
Anyone have any thoughts for/against this idea? Leaving this alone in
the kernel and doing the shifting in userspace isn't too bad a
solution either, but if nobody has a problem with patching in the
"skip on msg_iovlen == 0" behavior it does make the userspace code
cleaner and simpler.
-- Brandon
^ permalink raw reply
* [PATCH iproute2] ss: fix autobound filter
From: Eric Dumazet @ 2011-06-17 13:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Fixes following error. We currently provide garbage data to kernel, that
can abort the validation process or produce unexpected results.
$ ss -a autobound
State Recv-Q Send-Q Local Address:Port Peer Address:Port
TCPDIAG answers: Invalid argument
After patch:
$ misc/ss -a autobound
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:44624 *:*
ESTAB 0 0 192.168.1.21:47141 74.125.79.109:imaps
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
misc/ss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/misc/ss.c b/misc/ss.c
index 482b6bb..4033e92 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -803,7 +803,7 @@ static int ssfilter_bytecompile(struct ssfilter *f, char **bytecode)
{
if (!(*bytecode=malloc(4))) abort();
((struct inet_diag_bc_op*)*bytecode)[0] = (struct inet_diag_bc_op){ INET_DIAG_BC_AUTO, 4, 8 };
- return 8;
+ return 4;
}
case SSF_DCOND:
case SSF_SCOND:
^ permalink raw reply related
* Re: Netconf2011 slides...
From: Changli Gao @ 2011-06-17 13:21 UTC (permalink / raw)
To: Srinivasa T N; +Cc: David Miller, netdev
In-Reply-To: <4DF9D644.708@linux.vnet.ibm.com>
On Thu, Jun 16, 2011 at 6:09 PM, Srinivasa T N
<seenutn@linux.vnet.ibm.com> wrote:
> Were there some interesting topics which is useful for the community?
> (Few lines on each such topic would do).
>
netmap was mentioned by Tom. It is interesting for me.
http://info.iet.unipi.it/~luigi/netmap/
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [AX25] inconsistent lock state
From: Ralf Baechle @ 2011-06-17 13:28 UTC (permalink / raw)
To: f6bvp; +Cc: linux-kernel, Jarek Poplawski, Linux Netdev List, linux-hams
In-Reply-To: <4DFA662D.5030302@free.fr>
On Thu, Jun 16, 2011 at 10:23:09PM +0200, f6bvp wrote:
> When unpluging ethernet connector a few seconds I observed the
> following kernel message :
Can you describe your setup and what you did to trigger this?
Ralf
^ permalink raw reply
* Re: [AX25] inconsistent lock state
From: Arnd Bergmann @ 2011-06-17 13:36 UTC (permalink / raw)
To: f6bvp
Cc: linux-kernel, Jarek Poplawski, Linux Netdev List, Ralf Baechle,
linux-hams
In-Reply-To: <4DFA662D.5030302@free.fr>
On Thursday 16 June 2011 22:23:09 f6bvp wrote:
> Jun 16 12:03:34 f6bvp-9 kernel: =================================
> Jun 16 12:03:34 f6bvp-9 kernel: [ INFO: inconsistent lock state ]
> Jun 16 12:03:34 f6bvp-9 kernel: 2.6.39.1 #3
> Jun 16 12:03:34 f6bvp-9 kernel: ---------------------------------
> Jun 16 12:03:34 f6bvp-9 kernel: inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage.
> Jun 16 12:03:34 f6bvp-9 kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes:
> Jun 16 12:03:34 f6bvp-9 kernel: (disc_data_lock){+++?.-}, at: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss]
> Jun 16 12:03:34 f6bvp-9 kernel: {IN-SOFTIRQ-R} state was registered at:
> ...
> Is there something wrong in AX25 code or (more unlikely) is this
> operation not permitted ?
The message hints that disc_data_lock is aquired with softirqs disabled,
but does not itself disable softirqs, which can in rare circumstances
lead to a deadlock.
Does this fix it?
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
--- a/drivers/net/hamradio/mkiss.c
+++ b/drivers/net/hamradio/mkiss.c
@@ -708,11 +708,11 @@ static struct mkiss *mkiss_get(struct tty_struct *tty)
{
struct mkiss *ax;
- read_lock(&disc_data_lock);
+ read_lock_bh(&disc_data_lock);
ax = tty->disc_data;
if (ax)
atomic_inc(&ax->refcnt);
- read_unlock(&disc_data_lock);
+ read_unlock_bh(&disc_data_lock);
return ax;
}
@@ -813,10 +813,10 @@ static void mkiss_close(struct tty_struct *tty)
{
struct mkiss *ax;
- write_lock(&disc_data_lock);
+ write_lock_bh(&disc_data_lock);
ax = tty->disc_data;
tty->disc_data = NULL;
- write_unlock(&disc_data_lock);
+ write_unlock_bh(&disc_data_lock);
if (!ax)
return;
^ permalink raw reply
* [PATCH v2] net: rfs: enable RFS before first data packet is received
From: Eric Dumazet @ 2011-06-17 13:45 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, therbert, netdev, hadi
In-Reply-To: <20110616.233841.1893411919443027926.davem@davemloft.net>
Le jeudi 16 juin 2011 à 23:38 -0400, David Miller a écrit :
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Fri, 17 Jun 2011 00:50:46 +0100
>
> > On Wed, 2011-06-15 at 04:15 +0200, Eric Dumazet wrote:
> >> @@ -1594,6 +1594,7 @@ int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)
> >> goto discard;
> >>
> >> if (nsk != sk) {
> >> + sock_rps_save_rxhash(nsk, skb->rxhash);
> >> if (tcp_child_process(sk, nsk, skb)) {
> >> rsk = nsk;
> >> goto reset;
> >>
> >
> > I haven't tried this, but it looks reasonable to me.
> >
> > What about IPv6? The logic in tcp_v6_do_rcv() looks very similar.
>
> Indeed ipv6 side needs the same fix.
>
> Eric please add that part and resubmit. And in fact I might stick
> this into net-2.6 instead of net-next-2.6
>
OK, here is the net-2.6 based one then, thanks !
[PATCH v2] net: rfs: enable RFS before first data packet is received
First packet received on a passive tcp flow is not correctly RFS
steered.
One sock_rps_record_flow() call is missing in inet_accept()
But before that, we also must record rxhash when child socket is setup.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Tom Herbert <therbert@google.com>
CC: Ben Hutchings <bhutchings@solarflare.com>
CC: Jamal Hadi Salim <hadi@cyberus.ca>
---
V2: add ipv6 support, as Ben noticed.
net/ipv4/af_inet.c | 1 +
net/ipv4/tcp_ipv4.c | 1 +
net/ipv6/tcp_ipv6.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 9c19260..eae1f67 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -676,6 +676,7 @@ int inet_accept(struct socket *sock, struct socket *newsock, int flags)
lock_sock(sk2);
+ sock_rps_record_flow(sk2);
WARN_ON(!((1 << sk2->sk_state) &
(TCPF_ESTABLISHED | TCPF_CLOSE_WAIT | TCPF_CLOSE)));
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index a7d6671..708dc20 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1589,6 +1589,7 @@ int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)
goto discard;
if (nsk != sk) {
+ sock_rps_save_rxhash(nsk, skb->rxhash);
if (tcp_child_process(sk, nsk, skb)) {
rsk = nsk;
goto reset;
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index d1fd287..87551ca 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1644,6 +1644,7 @@ static int tcp_v6_do_rcv(struct sock *sk, struct sk_buff *skb)
* the new socket..
*/
if(nsk != sk) {
+ sock_rps_save_rxhash(nsk, skb->rxhash);
if (tcp_child_process(sk, nsk, skb))
goto reset;
if (opt_skb)
^ permalink raw reply related
* Re: [AX25] inconsistent lock state
From: Ralf Baechle @ 2011-06-17 13:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: f6bvp, linux-kernel, Linux Netdev List, linux-hams
In-Reply-To: <201106171536.15660.arnd@arndb.de>
On Fri, Jun 17, 2011 at 03:36:15PM +0200, Arnd Bergmann wrote:
(Removed Jarek from cc; his email bounces.)
> The message hints that disc_data_lock is aquired with softirqs disabled,
> but does not itself disable softirqs, which can in rare circumstances
> lead to a deadlock.
>
> Does this fix it?
If so, drivers/net/hamradio.c, function sp_get() would probably need the
equivalent fix. Same for drivers/net/ppp_async.c:ap_get() and sp_get() in
drivers/net/ppp_synctty.c.
Ralf
^ permalink raw reply
* [BUG] b43 / ssb: kernel BUG() in __queue_work()
From: Guennadi Liakhovetski @ 2011-06-17 14:08 UTC (permalink / raw)
To: Stefano Brivio, Michael Buesch; +Cc: netdev, linux-kernel
Hi
I'm getting reproducibly the below BUG() with recent kernels, e.g., next
of today. Occurs on ARM and SuperH with an SDIO b43 card. Using WPA2,
configure a network and start ping from outside, within a couple of
minutes (usually under 1 minute actually) the kernel crashes.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
[ 155.912000] ------------[ cut here ]------------
[ 155.912000] kernel BUG at /home/lyakh/software/project/24/src/linux-2.6/kernel/workqueue.c:1037!
[ 155.912000] Kernel BUG: 003e [#1]
[ 155.912000] Modules linked in: aes_generic arc4 mmc_block b43 ssb mac80211 cfg80211 sh_mobile_sdhi tmio_mmc_core mmc_core sh_mobile_ceu_camera videobuf2_dma_contig videobuf2_memops soc_camera videobuf_core videobuf2_core v4l2_common uio_pdrv_genirq videodev uio soc_mediabus shdma
[ 155.912000]
[ 155.912000] Pid : 1540, Comm: ksdioirqd/mmc0
[ 155.912000] CPU : 0 Not tainted (3.0.0-rc3-ecovec+ #332)
[ 155.912000]
[ 155.912000] PC is at __queue_work+0x1de/0x2ac
[ 155.912000] PR is at __queue_work+0x1d2/0x2ac
[ 155.912000] PC : 8802a5fa SP : 8d3719b0 SR : 400081f0 TEA : c000e6e0
[ 155.912000] R0 : 8d565000 R1 : 8d318f80 R2 : 8d565054 R3 : 00000000
[ 155.912000] R4 : 8d565000 R5 : 8d68ef00 R6 : 8d318f7c R7 : 000005a0
[ 155.912000] R8 : 8d318f7c R9 : 8d68ef00 R10 : 00000000 R11 : 8838e458
[ 155.912000] R12 : 8d68d20c R13 : 00000000 R14 : 8d3719b0
[ 155.912000] MACH: 00000064 MACL: 00000000 GBR : 00000000 PR : 8802a5ee
[ 155.912000]
[ 155.912000] Call trace:
[ 155.912000] [<c0294820>] ieee80211_duration+0x0/0x16c [mac80211]
[ 155.912000] [<8802a6e8>] queue_work_on+0x20/0x30
[ 155.912000] [<880036b4>] arch_local_irq_restore+0x0/0x2a
[ 155.912000] [<8802b53c>] queue_work+0x24/0x60
[ 155.912000] [<c0298904>] ieee80211_queue_work+0x20/0x34 [mac80211]
[ 155.912000] [<c02f512c>] b43_op_tx+0x40/0x5c [b43]
[ 155.912000] [<c029442e>] __ieee80211_tx+0x16e/0x1c0 [mac80211]
[ 155.912000] [<c029599e>] ieee80211_tx+0x76/0xc8 [mac80211]
[ 155.912000] [<c0295b4a>] ieee80211_xmit+0x15a/0x1b8 [mac80211]
[ 155.912000] [<88011efc>] sub_preempt_count+0x0/0x8c
[ 155.912000] [<881e0600>] skb_push+0x0/0x64
[ 155.912000] [<c0296a02>] ieee80211_subif_start_xmit+0x50e/0x55c [mac80211]
[ 155.912000] [<881e0600>] skb_push+0x0/0x64
[ 155.912000] [<881302b4>] memcpy+0x0/0x28c
[ 155.912000] [<881e85c2>] dev_hard_start_xmit+0x38a/0x49c
[ 155.912000] [<882034b6>] __ip_append_data+0x3da/0x6c4
[ 155.912000] [<881f8488>] sch_direct_xmit+0x60/0x1c0
[ 155.912000] [<881e88ac>] dev_queue_xmit+0x1d8/0x3f0
[ 155.912000] [<882053dc>] ip_finish_output+0x268/0x2b4
[ 155.912000] [<881302b4>] memcpy+0x0/0x28c
[ 155.912000] [<882054ae>] ip_output+0x86/0xac
[ 155.912000] [<88202e7c>] ip_local_out+0x5c/0x64
[ 155.912000] [<88202e90>] ip_send_skb+0xc/0x88
[ 155.912000] [<88203c52>] ip_push_pending_frames+0x22/0x38
[ 155.912000] [<88222856>] icmp_push_reply+0xce/0x104
[ 155.912000] [<88222a36>] icmp_reply+0x14a/0x1bc
[ 155.912000] [<88222bc6>] icmp_echo+0x3a/0x50
[ 155.912000] [<8821db68>] raw_local_deliver+0x0/0x1bc
[ 155.912000] [<8821db68>] raw_local_deliver+0x0/0x1bc
[ 155.912000] [<881e2b40>] __skb_checksum_complete+0x10/0x1c
[ 155.912000] [<88223050>] icmp_rcv+0xec/0x128
[ 155.912000] [<88200dee>] ip_local_deliver+0x86/0x13c
[ 155.912000] [<88200ce8>] ip_rcv+0x3d8/0x458
[ 155.912000] [<881e61d4>] __netif_receive_skb+0x298/0x2fc
[ 155.912000] [<881e636a>] netif_receive_skb+0x36/0x50
[ 155.912000] [<c02914f2>] ieee80211_deliver_skb+0xf6/0x158 [mac80211]
[ 155.912000] [<c02928a0>] ieee80211_rx_handlers+0xe16/0x124e [mac80211]
[ 155.912000] [<c01cff02>] mmc_wait_for_req+0xa6/0xd0 [mmc_core]
[ 155.912000] [<c01d59ca>] mmc_io_rw_extended+0x12a/0x1b0 [mmc_core]
[ 155.912000] [<881dff72>] skb_queue_tail+0x3e/0x74
[ 155.912000] [<c02933c0>] ieee80211_prepare_and_rx_handle+0x6e8/0x77c [mac80211]
[ 155.912000] [<c0293bda>] ieee80211_rx+0x786/0x818 [mac80211]
[ 155.912000] [<c01d0450>] mmc_wait_done+0x0/0x18 [mmc_core]
[ 155.912000] [<c0304e56>] b43_rx+0x4a2/0x510 [b43]
[ 155.912000] [<c030a6d6>] b43_pio_rx+0x2d6/0x35c [b43]
[ 155.912000] [<c02f864c>] b43_do_interrupt_thread+0x5b4/0x758 [b43]
[ 155.912000] [<c02f8852>] b43_sdio_interrupt_handler+0x26/0x48 [b43]
[ 155.912000] [<c030b370>] b43_sdio_interrupt_dispatcher+0x30/0x54 [b43]
[ 155.912000] [<c01d7368>] sdio_irq_thread+0x7c/0x274 [mmc_core]
[ 155.912000] [<c01d72ec>] sdio_irq_thread+0x0/0x274 [mmc_core]
[ 155.912000] [<8802f172>] kthread+0x4a/0x7c
[ 155.912000] [<8802f184>] kthread+0x5c/0x7c
[ 155.912000] [<c01d72ec>] sdio_irq_thread+0x0/0x274 [mmc_core]
[ 155.912000] [<88003d5c>] kernel_thread_helper+0x8/0x14
[ 155.912000] [<8802f128>] kthread+0x0/0x7c
[ 155.912000] [<88003d54>] kernel_thread_helper+0x0/0x14
[ 155.912000]
[ 155.912000] Code:
[ 155.912000] 8802a5f4: cmp/eq r1, r2
[ 155.912000] 8802a5f6: bt.s 8802a5fc
[ 155.912000] 8802a5f8: mov r0, r4
[ 155.912000] ->8802a5fa: trapa #62
[ 155.912000] 8802a5fc: mov.l @(8,r4), r7
[ 155.912000] 8802a5fe: mov r7, r1
[ 155.912000] 8802a600: add #4, r1
[ 155.912000] 8802a602: shll2 r1
[ 155.912000] 8802a604: add r4, r1
[ 155.912000]
[ 155.912000] Process: ksdioirqd/mmc0 (pid: 1540, stack limit = 8d370001)
[ 155.912000] Stack: (0x8d3719b0 to 0x8d372000)
[ 155.912000] 19a0: c0294820 8802a6e8 8d3719d4 00000000
[ 155.912000] 19c0: 8d68d20c 880036b4 8d68d000 8d68ef00 8d318f7c 8802b53c 8d3719dc c0298904
[ 155.912000] 19e0: 8d3719ec 8d371a38 8d31833c 8d318f7c c02f512c 8d3719fc 8d318ea0 c029442e
[ 155.912000] 1a00: 8d371a08 8d3182c0 00000000 00000000 8d339ae0 00000000 c029599e 8d371a38
[ 155.912000] 1a20: 8d506850 8f1e13c0 00000000 8d3182c0 8d339afc 8d339ae0 8d339ae0 8d3182c0
[ 155.912000] 1a40: 8f1e13c0 8d68d000 8d2e9200 c03123c0 00000800 00000002 c0295b4a 8d371a74
[ 155.912000] 1a60: 000003bc 88011efc 8d3182c0 8f1e13c0 8d339ae0 881e0600 8d339af8 8d371aa0
[ 155.912000] 1a80: c0296a02 8d371aa0 8d506850 881e0600 881302b4 8d506864 8f1e13c0 8d339ae0
[ 155.912000] 1aa0: 00000000 0000000c 0000001c 8d506850 8d506864 8d506842 8d3182c0 c0236b98
[ 155.912000] 1ac0: 8f1e1000 01081ad8 24000000 a5f335fe 02100e00 0200b772 0ece6872 8d370000
[ 155.912000] 1ae0: 8d2ecf20 881e85c2 8d371b04 8834278c 8f1e1000 8d68eea0 8834276c 00006000
[ 155.912000] 1b00: 8d339ae0 00000000 882034b6 c029b384 8834278c 881f8488 8d371b34 8d68eea0
[ 155.912000] 1b20: 00000010 8d68eea0 8f1e1000 8d2ed600 8d339ae0 881e88ac 8d371b54 8d2ed640
[ 155.912000] 1b40: 00000000 8d2ed600 8f1e1000 8d339ae0 8d2ed65c 882053dc 8d371b74 8d2bd74a
[ 155.912000] 1b60: 8d339b5c 00000000 0000000e 8d2bd740 8d339ae0 881302b4 fffffff0 8d2bd754
[ 155.912000] 1b80: 8d2bd750 882054ae 8d371ba4 8834270c 8d371bec 8d506866 8d339b20 8f1e1000
[ 155.912000] 1ba0: 8d339ae0 88202e7c 8d371bb4 8d371c38 8f0b5b80 88202e90 8d371bbc 88203c52
[ 155.912000] 1bc0: 8d371bc8 8f0b5b80 88222856 8d371bd0 88222a36 8d371bec 00000008 8d371be0
[ 155.912000] 1be0: 8d2da75c 8d3738c0 8d371c38 00000000 00000000 00000000 00010000 00000000
[ 155.912000] 1c00: 15b2a8c0 1bb2a8c0 00000000 15b2a8c0 00003810 00000000 c0349300 00000000
[ 155.912000] 1c20: 88222bc6 8d371c38 8821db68 88342bd8 8d373f01 3900a76f 8d2da6e0 00000000
[ 155.912000] 1c40: 00000038 00000000 3900a76f 15b2a8c0 00000200 00000100 00000008 0669ae33
[ 155.912000] 1c60: 00000000 00000000 00000000 00000000 8834270c 00000008 8821db68 88342bd8
[ 155.912000] 1c80: 8d2da720 8d2da6e0 881e2b40 8d371c9c 88342bd8 8d373f01 88223050 8d371ca4
[ 155.912000] 1ca0: 8d2da6e0 88200dee 8d371cb4 88342bdc 8d2da6e0 88200ce8 8d371ccc 00000000
[ 155.912000] 1cc0: 8d506c50 8d2da6f8 8d2da6e0 881e61d4 8d371ce4 00000000 8f1e1000 8d371cb4
[ 155.912000] 1ce0: 883426ec 0000009c 00000001 8d2da6e0 8834270c 881e636a 8d371d14 8f1e1000
[ 155.912000] 1d00: 8d2da6f8 8d3182c0 8d2da75c 00000000 8d2da6e0 8d2da6e0 c02914f2 8d371d20
[ 155.912000] 1d20: c02928a0 8d371d40 8f1e13c0 8f1e107c 8d3182c0 00000000 00004208 8d371dec
[ 155.912000] 1d40: 8d371dcc c01cff02 8d371d4c 00000000 8d371d50 00000000 c01d59ca 8d371d6c
[ 155.912000] 1d60: 00000004 8d371da0 8d43ec00 8d371de4 00000035 00000000 00001000 00001000
[ 155.912000] 1d80: 00005000 00001000 881dff72 c02933c0 8d371dac 8f1e177c 8d3182c0 8d2da6e0
[ 155.912000] 1da0: 8d506c28 0000002b 8d371dec 00000001 8d3182c0 8f1e13c0 c0293bda 8d371dd8
[ 155.912000] 1dc0: 8d2da6e0 8d371dec 8d68d000 00000000 8d68d000 8d3182c0 00000000 8d371d4c
[ 155.912000] 1de0: c01d0450 8d506c32 8d506c28 8d2da6e0 8d3182c0 8f1e13c0 8d68d000 8d2e9200
[ 155.912000] 1e00: 00000000 00000010 00000000 00000000 00000000 c0304e56 8d371e34 00007499
[ 155.912000] 1e20: 0000012a 00000002 8d2da6e0 8d3182c0 8d32f400 0000000f 00000002 00000000
[ 155.912000] 1e40: 8d2da720 8d506c22 8d2da75c 00000000 00000000 00000000 00000985 ffffffc7
[ 155.912000] 1e60: 00000000 0000000b 00000000 00000000 c030a6d6 8d371e90 8d32f400 0000008e
[ 155.912000] 1e80: 8d319009 8d2da75c 8d4ca424 8d4ca420 00000002 00000000 8d318ea0 8d2da6e0
[ 155.912000] 1ea0: 8d318f98 c02f864c 8d371ec4 00000001 8d3aa9bc 8d3aa93c 00010000 00008000
[ 155.912000] 1ec0: 8d32f400 8d32f000 00010000 00000000 00000000 00000000 00000000 00000000
[ 155.912000] 1ee0: 00008000 8d32f47c 8d32f400 c02f8852 8d371f0c 00000001 8d3aa9bc 8d3aa93c
[ 155.912000] 1f00: 8d32f400 8d32f400 8d318ea8 c030b370 8d371f1c 8d32f2fc 8d2e7000 c01d7368
[ 155.912000] 1f20: 8d371f30 8d43ec00 7fffffff 8d3aa800 8d4a5da4 c01d72ec 00000000 8d3aa8fc
[ 155.912000] 1f40: 8d3aaa44 00000003 00000001 8802f172 8802f184 8d371f70 00000000 00000000
[ 155.912000] 1f60: c01d72ec 8d3aa800 8d4a5d94 00000000 00000000 8d3aa800 00000000 8d371f7c
[ 155.912000] 1f80: 8d371f7c 88003d5c 8d371f9c 00000000 00000000 00000000 00000000 00000000
[ 155.912000] 1fa0: 00000000 00000000 00000000 00000000 00000000 8d4a5d94 8802f128 00000000
[ 155.912000] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 155.912000] 1fe0: 8d371fa4 88003d54 00000000 40008000 00000000 00000000 00000000 00000000
[ 155.916000] ---[ end trace d5cca8a145e4559d ]---
^ permalink raw reply
* Re: Netconf2011 slides...
From: Hagen Paul Pfeifer @ 2011-06-17 14:08 UTC (permalink / raw)
To: Changli Gao; +Cc: Srinivasa T N, David Miller, netdev
In-Reply-To: <BANLkTi=Vk__TbiGGrUkqexoJ1=mGh8a1gw@mail.gmail.com>
On Fri, 17 Jun 2011 21:21:34 +0800, Changli Gao <xiaosuo@gmail.com> wrote:
> netmap was mentioned by Tom. It is interesting for me.
> http://info.iet.unipi.it/~luigi/netmap/
Looks like PF_RING
http://www.ntop.org/PF_RING.html
Hagen
^ permalink raw reply
* Re: Netconf2011 slides...
From: Changli Gao @ 2011-06-17 14:10 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: Srinivasa T N, David Miller, netdev
In-Reply-To: <d76074192634f7584707555905e43013@localhost>
On Fri, Jun 17, 2011 at 10:08 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
>
> On Fri, 17 Jun 2011 21:21:34 +0800, Changli Gao <xiaosuo@gmail.com> wrote:
>
>> netmap was mentioned by Tom. It is interesting for me.
>
>> http://info.iet.unipi.it/~luigi/netmap/
>
> Looks like PF_RING
>
> http://www.ntop.org/PF_RING.html
>
Yea, it is much like PF_RING works in DNA mode, but more secure and
NIC independent.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [AX25] inconsistent lock state
From: Arnd Bergmann @ 2011-06-17 14:11 UTC (permalink / raw)
To: Ralf Baechle; +Cc: f6bvp, linux-kernel, Linux Netdev List, linux-hams
In-Reply-To: <20110617135147.GA3470@linux-mips.org>
On Friday 17 June 2011 15:51:48 Ralf Baechle wrote:
> On Fri, Jun 17, 2011 at 03:36:15PM +0200, Arnd Bergmann wrote:
>
> (Removed Jarek from cc; his email bounces.)
>
> > The message hints that disc_data_lock is aquired with softirqs disabled,
> > but does not itself disable softirqs, which can in rare circumstances
> > lead to a deadlock.
> >
> > Does this fix it?
>
> If so, drivers/net/hamradio.c, function sp_get() would probably need the
> equivalent fix. Same for drivers/net/ppp_async.c:ap_get() and sp_get() in
> drivers/net/ppp_synctty.c.
It seems that ppp_synctty.c is ok, it uses write_lock_irq() already,
sixpack.c looks like it has the same bug as mkiss. I also realized
after sending out the patch that only the write_lock needs to be
changed to write_lock_bh, while read_lock can leave softirqs enabled
because it can be called recursively.
Arnd
^ permalink raw reply
* Re: [PATCH net-next V2] drivers/net: Remove casts of void *
From: David Dillow @ 2011-06-17 14:14 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, linux-kernel
In-Reply-To: <3bea9d0803a4ebfee2bb0f6e42defbf76126dc86.1308287030.git.joe@perches.com>
On Thu, 2011-06-16 at 22:08 -0700, Joe Perches wrote:
> Unnecessary casts of void * clutter the code.
>
> These are the remainder casts after several specific
> patches to remove netdev_priv and dev_priv.
> diff --git a/drivers/net/typhoon.c b/drivers/net/typhoon.c
> index 3de4283..1d5091a 100644
> --- a/drivers/net/typhoon.c
> +++ b/drivers/net/typhoon.c
> @@ -2367,7 +2367,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>
> dev->irq = pdev->irq;
> tp = netdev_priv(dev);
> - tp->shared = (struct typhoon_shared *) shared;
> + tp->shared = shared;
> tp->shared_dma = shared_dma;
> tp->pdev = pdev;
> tp->tx_pdev = pdev;
Acked-by: David Dillow <dave@thedillows.org>
^ permalink raw reply
* Re: [PATCH 05/14] SIWv2: User interface: siw_verbs.h, siw_verbs.c, siw_user.h, siw_ae.c
From: Bernard Metzler @ 2011-06-17 14:14 UTC (permalink / raw)
To: Steve Wise; +Cc: linux-rdma, linux-rdma-owner, netdev
In-Reply-To: <4DFA26FC.5040902@opengridcomputing.com>
Steve,
we currently do not support inline data for kernel clients since
we copy those data into a malloc'd buffer, where kmalloc()
might block. Using an explicit buffer comes from experiments
to allow for larger blocks of inlined data.
I could put the inline data directly into the wqe restricting it
to some 200 bytes or less (dependent on wqe size which
is mainly determined by numer of sge's supported).
would that make sense? maybe it would better reflect the
intended nature of inline data - put some bytes out w/o
doing memory registration...
thanks,
Bernard
linux-rdma-owner@vger.kernel.org wrote on 06/16/2011 05:53:32 PM:
>
> <snip>
>
> > +
> > +/*
> > + * siw_create_qp()
> > + *
> > + * Create QP of requested size on given device.
> > + *
> > + * @ofa_pd: OFA PD contained in siw PD
> > + * @attrs: Initial QP attributes.
> > + * @udata: used to provide QP ID, SQ and RQ size back to user.
> > + */
> > +
> > +struct ib_qp *siw_create_qp(struct ib_pd *ofa_pd,
> > + struct ib_qp_init_attr *attrs,
> > + struct ib_udata *udata)
> > +{
> > + struct siw_qp *qp = NULL;
> > + struct siw_pd *pd = siw_pd_ofa2siw(ofa_pd);
> > + struct ib_device *ofa_dev = ofa_pd->device;
> > + struct siw_dev *dev = siw_dev_ofa2siw(ofa_dev);
> > + struct siw_cq *scq = NULL, *rcq = NULL;
> > + struct siw_iwarp_tx *c_tx;
> > + struct siw_iwarp_rx *c_rx;
> > + struct siw_uresp_create_qp uresp;
> > +
> > + unsigned long flags;
> > + int kernel_verbs = ofa_pd->uobject ? 0 : 1;
> > + int rv = 0;
> > +
> > + dprint(DBG_OBJ|DBG_CM, ": new QP on device %s\n",
> > + ofa_dev->name);
> > +
> > + if (atomic_inc_return(&dev->num_qp)> SIW_MAX_QP) {
> > + dprint(DBG_ON, ": Out of QP's\n");
> > + rv = -ENOMEM;
> > + goto err_out;
> > + }
> > + if (attrs->qp_type != IB_QPT_RC) {
> > + dprint(DBG_ON, ": Only RC QP's supported\n");
> > + rv = -EINVAL;
> > + goto err_out;
> > + }
> > + if ((attrs->cap.max_send_wr> SIW_MAX_QP_WR) ||
> > + (attrs->cap.max_recv_wr> SIW_MAX_QP_WR) ||
> > + (attrs->cap.max_send_sge> SIW_MAX_SGE) ||
> > + (attrs->cap.max_recv_sge> SIW_MAX_SGE)) {
> > + dprint(DBG_ON, ": QP Size!\n");
> > + rv = -EINVAL;
> > + goto err_out;
> > + }
> > + if (attrs->cap.max_inline_data> SIW_MAX_INLINE ||
> > + (kernel_verbs&& attrs->cap.max_inline_data != 0)) {
> > + dprint(DBG_ON, ": Max Inline Send %d> %d!\n",
> > + attrs->cap.max_inline_data, SIW_MAX_INLINE);
> > + rv = -EINVAL;
> > + goto err_out;
>
> Why no inline support for kernel users?
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 14/14] SIWv2: Documentation: siw.txt
From: Bernard Metzler @ 2011-06-17 14:17 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110616091044.217d0524.rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
Randy,
many thanks, i'll change accordingly.
and sorry for the typo - 'isynchronous' is just 'synchronous'
typed in vi and doing the insert command twice ;)
thanks,
Bernard.
Randy Dunlap <rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org> wrote on 06/16/2011 06:10:44 PM:
> On Thu, 16 Jun 2011 14:42:54 +0200 Bernard Metzler wrote:
>
> > ---
> > Documentation/networking/siw.txt | 156
> ++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 156 insertions(+), 0 deletions(-)
> > create mode 100644 Documentation/networking/siw.txt
> >
> > diff --git a/Documentation/networking/siw.txt
> b/Documentation/networking/siw.txt
> > new file mode 100644
> > index 0000000..805e21b
> > --- /dev/null
> > +++ b/Documentation/networking/siw.txt
> > @@ -0,0 +1,156 @@
> > +SoftiWARP: Software iWARP kernel driver module.
> > +
> > +General
> > +-------
> > +SoftiWARP (siw) implements the iWARP protocol suite (MPA/DDP/RDMAP,
> > +IETF-RFC 5044/5041/5040) completely in software as a Linux kernel
module.
> > +siw runs on top of TCP kernel sockets and exports the Linux kernel
ibverbs
> > +RDMA interface. siw interfaces with the iwcm connection manager.
> > +
> > +
> > +Transmit Path
> > +-------------
> > +If a send queue (SQ) work queue element gets posted, siw tries to send
> > +it directly out of the application context. If the SQ was non-empty,
> > +SQ processing is done asynchronously by a kernel worker thread. This
> > +thread gets scheduled if the TCP socket signals new write space to
>
> s/gets/is/
>
> > +be available. If during send operation the socket send space becomes
> > +exhausted, SQ processing is abandoned until new socket write space
> > +becomes available.
> > +
> > +
> > +Receive Path
> > +------------
> > +All application data is placed into target buffers within softirq
> > +socket callback. Application notification is asynchronous.
> > +
> > +
> > +User Interface
> > +--------------
> > +All user space fast path operations such as posting of work requests
and
> > +reaping of work completions currently involve a isynchronous call into
>
> If you really mean "isynchronous", then it should be: an isynchronous
call
>
> but what is isynchronous?
>
> > +the siw kernel module via ib_uverbs interface. Kernel/user-mapped send
> > +and receive as well as completion queues are not part of the current
code.
> > +In particular, mapped completion queues may improve performance,
> > +since reaping completion queue entries as well as re-arming
> > +the completion queue could be done more efficiently.
> > +
> > +
> > +Kernel Client Support
> > +---------------------
> > +To guarantee non-blocking fast path operations, for kernel clients
> > +all work queue elements (send/receive/shared-receive queue) are
> > +pre-allocated during connection resource setup.
> > +
> > +
> > +Memory Management
> > +-----------------
> > +siw currently uses the ib_umem_get() function of the ib_core module
> > +to pin memory for later use in data transfer operations. Transmit
> > +and receive memory are checked against correct access permissions only
> > +in the moment of access by the network input path or before pushing it
>
> at the moment
>
> > +to the TCP socket for transmission.
> > +ib_umem_get() provides DMA mappings for the requested address space
which
> > +are not used by siw.
> > +
> > +
> > +Module Parameters
> > +-----------------
> > +The following siw module parameters are recognized.
> > +
> > +loopback_enabled:
> > + If set, siw attaches also to the looback device. Checked only
> > + during module insertion.
> > +
> > +mpa_crc_required:
> > + If set, the MPA CRC gets generated and checked both in tx and rx
>
> s/gets/is/
>
> > + path. Without hardware support, setting this flag will severely
> > + hurt throughput. Default setting is 0 (off).
> > +
> > +mpa_crc_strict:
> > + If set, MPA CRC will not be enabled, even if peer requests
> > + it. If the peer requests CRC generation, the connection setup
> > + will be aborted. Default setting is 1 (on).
> > +
> > +zcopy_tx:
> > + If set, payload of non-signalled work requests
>
> payloads ... are transferred
>
> > + (such as non-signalled WRITE or SEND as well as all READ
> > + responses) are transferred using the TCP sockets
> > + sendpage interface. This parameter can be switched on and
> > + off dynamically (echo 1 >> /sys/module/siw/parameters/zcopy_tx
> > + for enablement, 0 for disabling). System load may benefits from
>
> may benefit
>
> > + using 0copy data transmission. 0copy is not enabled if
>
> "0copy" is fugly (IMO).
>
> > + mpa_crc_enabled is set. Default setting is 1 (on).
> > +
> > +tcp_nodelay:
> > + If set, on the TCP socket the TCP_NODELAY option is set.
> > + Default setting is 1 (on).
> > +
> > +iface_list:
> > + Comma separated list of interfaces siw should attach to.
>
> Comma-separated
>
> > + If no list is given, siw attaches to all available devices.
> > + If a list is given, siw skips those devices not listed.
> > + Currently, the list is restricted to 12 entries. If needed,
> > + the 'SIW_MAX_IF' #define in siw_main.c can be adaped.
>
> adapted. ? (or
modified)
>
> > + This parameter might be usefull to skip devices which are
>
> useful
>
> > + attached to a real RNIC device. Default setting is an empty list.
> > +
> > +
> > +Compile Time Flags:
> > +-------------------
> > +-DCHECK_DMA_CAPABILITIES
> > + Checks if the device siw wants to attach to provides
> > + DMA capabilities. While DMA capabilities are currently not
> > + needed (siw works on top of a kernel TCP socket), siw
> > + uses ib_umem_get() which performs a (not used) DMA address
> > + translation. Writing a siw private memory reservation and
> > + pinning routine would solve the issue.
> > +
> > +-DSIW_TX_FULLSEGS
> > + Experimental, not enabled by default. If set,
> > + siw tries not to overrun the socket (not sending until
> > + -EAGAIN return), but stops sending if the current segment
> > + would not fit into the socket's estimated tx buffer. With that,
> > + wire FPDUs may get truncated by the TCP stack far less often.
> > + Since this feature manipulates the sock's SOCK_NOSPACE
> > + bit, it violates strict layering and is therefore considered
> > + proprietary.
> > + Since TCP is a byte stream protocol, no guarantee can be given
> > + if FPDU's are not fragmented.
>
> or FPDUs
>
> > +
> > +
> > +Debugging SIW:
> > +--------------
> > +The siw_debug.h file defines a 'dprint' macro which is used to debug
> > +siw at runtime. Verbosity of debugging is controlled at compile time
> > +via setting the 'DPRINT_MASK' to a or'd list of know value as defined
>
> to an or'd list of known value
>
>
> > +in siw_debug.h, e.g. '#define DPRINT_MASK (DBG_ON|DBG_CM)' to debug
> > +errors and connection management. Defining DPRINT_MASK to '0' avoids
> > +to compile any runtime debugging code.
>
> compiling any
>
> > +
> > +To track siw's useage of its objects (connection endpoints, tcp
sockets,
>
> usage
>
> > +protection domains, queue pairs, shared receive queues, completion
queues,
> > +memory registrations, work queue elements),
the /sys/class/infiniband/siw*
> > +directory contains siw interface specific objects, which can be read
to
> > +gather simple statistics:
> > +
> > +/sys/class/infiniband/siw*/stats:
> > + Summary of allocated WQE's, PD's, QP's, CQ's, SRQ's, MR's, CEP's.
>
> All of those single quote/apostrophe marks are not needed.
>
> > + WQE statistics are not gathered if 'DPRINT_MASK' is set to '0'
> > + (see above).
> > +
> > +/sys/class/infiniband/siw*/qp:
> > + Summary of allocated queue pairs. If queue pairs are allocated,
> > + after reading 'qp' a more detailed status of all queue pairs has
> > + been printed to the kernel syslog and can be retrieved via
> > + 'dmesg' command.
> > +
> > +/sys/class/infiniband/siw*/cep:
> > + Summary of allocated connection end points. If connection endpoints
> > + are allocated, after reading 'cep' a more detailed status of all
> > + CEP's is printed to the kernel syslog and can be retrieved via
>
> ditto
>
> > + 'dmesg' command.
> > +
> > +Using the sysfs to gather siw's object allocations is considered a
> > +tentative aid during further driver development and should disappear
> > +in a stable version of siw.
> > --
>
>
> HTH.
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code
***
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 05/14] SIWv2: User interface: siw_verbs.h, siw_verbs.c, siw_user.h, siw_ae.c
From: Steve Wise @ 2011-06-17 14:20 UTC (permalink / raw)
To: Bernard Metzler
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <OF7426A1EE.BBD67937-ONC12578B2.003B466D-C12578B2.004E3647-Xeyd2O9EBijQT0dZR+AlfA@public.gmane.org>
On 06/17/2011 09:14 AM, Bernard Metzler wrote:
> Steve,
> we currently do not support inline data for kernel clients since
> we copy those data into a malloc'd buffer, where kmalloc()
> might block. Using an explicit buffer comes from experiments
> to allow for larger blocks of inlined data.
> I could put the inline data directly into the wqe restricting it
> to some 200 bytes or less (dependent on wqe size which
> is mainly determined by numer of sge's supported).
> would that make sense? maybe it would better reflect the
> intended nature of inline data - put some bytes out w/o
> doing memory registration...
I assume the intention of SEND_INLINE was precisely to allow putting the data into the HW WQE to avoid an additional DMA
fetch of small payloads for HW RDMA devices. For SWIW, this is not really an issue.
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: software iwarp stack update
From: Bernard Metzler @ 2011-06-17 14:23 UTC (permalink / raw)
To: Bart Van Assche; +Cc: linux-rdma, linux-rdma-owner, netdev, Roland Dreier
In-Reply-To: <BANLkTikE-oc2qWZec+2BfWuUy-oNdf-opg@mail.gmail.com>
Ok, let me put in all the -ENOSYS functions.
I did not know about that distinction between user
and kernel level clients.
Thanks,
Bernard.
linux-rdma-owner@vger.kernel.org wrote on 06/16/2011 08:06:44 PM:
> On Thu, Jun 16, 2011 at 7:20 PM, Roland Dreier <roland@purestorage.com>
wrote:
> > It does seem we are missing an IB_MANDATORY_FUNC
> > entry for modify_port in ib_device_check_mandatory; or on
> > the flip side we are missing a check of modify_port and a
> > -ENOSYS return... I guess modify_port does not really make
> > sense for iWARP so probably the second option is better.
>
> It's not just ib_modify_port() - there are several other functions in
> the amso and cxgb* drivers that do nothing more than returning either
> -ENOSYS or ERR_PTR(-ENOSYS).
>
> Bart.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 05/14] SIWv2: User interface: siw_verbs.h, siw_verbs.c, siw_user.h, siw_ae.c
From: Bernard Metzler @ 2011-06-17 14:26 UTC (permalink / raw)
To: Steve Wise
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4DFB62B3.5050108-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org wrote on 06/17/2011 04:20:35 PM:
> On 06/17/2011 09:14 AM, Bernard Metzler wrote:
> > Steve,
> > we currently do not support inline data for kernel clients since
> > we copy those data into a malloc'd buffer, where kmalloc()
> > might block. Using an explicit buffer comes from experiments
> > to allow for larger blocks of inlined data.
> > I could put the inline data directly into the wqe restricting it
> > to some 200 bytes or less (dependent on wqe size which
> > is mainly determined by numer of sge's supported).
> > would that make sense? maybe it would better reflect the
> > intended nature of inline data - put some bytes out w/o
> > doing memory registration...
>
> I assume the intention of SEND_INLINE was precisely to allow putting
> the data into the HW WQE to avoid an additional DMA
> fetch of small payloads for HW RDMA devices. For SWIW, this is not
> really an issue.
>
>
but we have to provide a non-blocking fast path for kernel clients,
which forces me to do the same.
Thanks,
Bernard.
> Steve.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [BUG] b43 / ssb: kernel BUG() in __queue_work()
From: John W. Linville @ 2011-06-17 14:42 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Stefano Brivio, Michael Buesch, netdev, linux-kernel,
linux-wireless
In-Reply-To: <Pine.LNX.4.64.1106171602330.27141@axis700.grange>
You probably should send this to linux-wireless@vger.kernel.org...
On Fri, Jun 17, 2011 at 04:08:04PM +0200, Guennadi Liakhovetski wrote:
> Hi
>
> I'm getting reproducibly the below BUG() with recent kernels, e.g., next
> of today. Occurs on ARM and SuperH with an SDIO b43 card. Using WPA2,
> configure a network and start ping from outside, within a couple of
> minutes (usually under 1 minute actually) the kernel crashes.
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
> [ 155.912000] ------------[ cut here ]------------
> [ 155.912000] kernel BUG at /home/lyakh/software/project/24/src/linux-2.6/kernel/workqueue.c:1037!
> [ 155.912000] Kernel BUG: 003e [#1]
> [ 155.912000] Modules linked in: aes_generic arc4 mmc_block b43 ssb mac80211 cfg80211 sh_mobile_sdhi tmio_mmc_core mmc_core sh_mobile_ceu_camera videobuf2_dma_contig videobuf2_memops soc_camera videobuf_core videobuf2_core v4l2_common uio_pdrv_genirq videodev uio soc_mediabus shdma
> [ 155.912000]
> [ 155.912000] Pid : 1540, Comm: ksdioirqd/mmc0
> [ 155.912000] CPU : 0 Not tainted (3.0.0-rc3-ecovec+ #332)
> [ 155.912000]
> [ 155.912000] PC is at __queue_work+0x1de/0x2ac
> [ 155.912000] PR is at __queue_work+0x1d2/0x2ac
> [ 155.912000] PC : 8802a5fa SP : 8d3719b0 SR : 400081f0 TEA : c000e6e0
> [ 155.912000] R0 : 8d565000 R1 : 8d318f80 R2 : 8d565054 R3 : 00000000
> [ 155.912000] R4 : 8d565000 R5 : 8d68ef00 R6 : 8d318f7c R7 : 000005a0
> [ 155.912000] R8 : 8d318f7c R9 : 8d68ef00 R10 : 00000000 R11 : 8838e458
> [ 155.912000] R12 : 8d68d20c R13 : 00000000 R14 : 8d3719b0
> [ 155.912000] MACH: 00000064 MACL: 00000000 GBR : 00000000 PR : 8802a5ee
> [ 155.912000]
> [ 155.912000] Call trace:
> [ 155.912000] [<c0294820>] ieee80211_duration+0x0/0x16c [mac80211]
> [ 155.912000] [<8802a6e8>] queue_work_on+0x20/0x30
> [ 155.912000] [<880036b4>] arch_local_irq_restore+0x0/0x2a
> [ 155.912000] [<8802b53c>] queue_work+0x24/0x60
> [ 155.912000] [<c0298904>] ieee80211_queue_work+0x20/0x34 [mac80211]
> [ 155.912000] [<c02f512c>] b43_op_tx+0x40/0x5c [b43]
> [ 155.912000] [<c029442e>] __ieee80211_tx+0x16e/0x1c0 [mac80211]
> [ 155.912000] [<c029599e>] ieee80211_tx+0x76/0xc8 [mac80211]
> [ 155.912000] [<c0295b4a>] ieee80211_xmit+0x15a/0x1b8 [mac80211]
> [ 155.912000] [<88011efc>] sub_preempt_count+0x0/0x8c
> [ 155.912000] [<881e0600>] skb_push+0x0/0x64
> [ 155.912000] [<c0296a02>] ieee80211_subif_start_xmit+0x50e/0x55c [mac80211]
> [ 155.912000] [<881e0600>] skb_push+0x0/0x64
> [ 155.912000] [<881302b4>] memcpy+0x0/0x28c
> [ 155.912000] [<881e85c2>] dev_hard_start_xmit+0x38a/0x49c
> [ 155.912000] [<882034b6>] __ip_append_data+0x3da/0x6c4
> [ 155.912000] [<881f8488>] sch_direct_xmit+0x60/0x1c0
> [ 155.912000] [<881e88ac>] dev_queue_xmit+0x1d8/0x3f0
> [ 155.912000] [<882053dc>] ip_finish_output+0x268/0x2b4
> [ 155.912000] [<881302b4>] memcpy+0x0/0x28c
> [ 155.912000] [<882054ae>] ip_output+0x86/0xac
> [ 155.912000] [<88202e7c>] ip_local_out+0x5c/0x64
> [ 155.912000] [<88202e90>] ip_send_skb+0xc/0x88
> [ 155.912000] [<88203c52>] ip_push_pending_frames+0x22/0x38
> [ 155.912000] [<88222856>] icmp_push_reply+0xce/0x104
> [ 155.912000] [<88222a36>] icmp_reply+0x14a/0x1bc
> [ 155.912000] [<88222bc6>] icmp_echo+0x3a/0x50
> [ 155.912000] [<8821db68>] raw_local_deliver+0x0/0x1bc
> [ 155.912000] [<8821db68>] raw_local_deliver+0x0/0x1bc
> [ 155.912000] [<881e2b40>] __skb_checksum_complete+0x10/0x1c
> [ 155.912000] [<88223050>] icmp_rcv+0xec/0x128
> [ 155.912000] [<88200dee>] ip_local_deliver+0x86/0x13c
> [ 155.912000] [<88200ce8>] ip_rcv+0x3d8/0x458
> [ 155.912000] [<881e61d4>] __netif_receive_skb+0x298/0x2fc
> [ 155.912000] [<881e636a>] netif_receive_skb+0x36/0x50
> [ 155.912000] [<c02914f2>] ieee80211_deliver_skb+0xf6/0x158 [mac80211]
> [ 155.912000] [<c02928a0>] ieee80211_rx_handlers+0xe16/0x124e [mac80211]
> [ 155.912000] [<c01cff02>] mmc_wait_for_req+0xa6/0xd0 [mmc_core]
> [ 155.912000] [<c01d59ca>] mmc_io_rw_extended+0x12a/0x1b0 [mmc_core]
> [ 155.912000] [<881dff72>] skb_queue_tail+0x3e/0x74
> [ 155.912000] [<c02933c0>] ieee80211_prepare_and_rx_handle+0x6e8/0x77c [mac80211]
> [ 155.912000] [<c0293bda>] ieee80211_rx+0x786/0x818 [mac80211]
> [ 155.912000] [<c01d0450>] mmc_wait_done+0x0/0x18 [mmc_core]
> [ 155.912000] [<c0304e56>] b43_rx+0x4a2/0x510 [b43]
> [ 155.912000] [<c030a6d6>] b43_pio_rx+0x2d6/0x35c [b43]
> [ 155.912000] [<c02f864c>] b43_do_interrupt_thread+0x5b4/0x758 [b43]
> [ 155.912000] [<c02f8852>] b43_sdio_interrupt_handler+0x26/0x48 [b43]
> [ 155.912000] [<c030b370>] b43_sdio_interrupt_dispatcher+0x30/0x54 [b43]
> [ 155.912000] [<c01d7368>] sdio_irq_thread+0x7c/0x274 [mmc_core]
> [ 155.912000] [<c01d72ec>] sdio_irq_thread+0x0/0x274 [mmc_core]
> [ 155.912000] [<8802f172>] kthread+0x4a/0x7c
> [ 155.912000] [<8802f184>] kthread+0x5c/0x7c
> [ 155.912000] [<c01d72ec>] sdio_irq_thread+0x0/0x274 [mmc_core]
> [ 155.912000] [<88003d5c>] kernel_thread_helper+0x8/0x14
> [ 155.912000] [<8802f128>] kthread+0x0/0x7c
> [ 155.912000] [<88003d54>] kernel_thread_helper+0x0/0x14
> [ 155.912000]
> [ 155.912000] Code:
> [ 155.912000] 8802a5f4: cmp/eq r1, r2
> [ 155.912000] 8802a5f6: bt.s 8802a5fc
> [ 155.912000] 8802a5f8: mov r0, r4
> [ 155.912000] ->8802a5fa: trapa #62
> [ 155.912000] 8802a5fc: mov.l @(8,r4), r7
> [ 155.912000] 8802a5fe: mov r7, r1
> [ 155.912000] 8802a600: add #4, r1
> [ 155.912000] 8802a602: shll2 r1
> [ 155.912000] 8802a604: add r4, r1
> [ 155.912000]
> [ 155.912000] Process: ksdioirqd/mmc0 (pid: 1540, stack limit = 8d370001)
> [ 155.912000] Stack: (0x8d3719b0 to 0x8d372000)
> [ 155.912000] 19a0: c0294820 8802a6e8 8d3719d4 00000000
> [ 155.912000] 19c0: 8d68d20c 880036b4 8d68d000 8d68ef00 8d318f7c 8802b53c 8d3719dc c0298904
> [ 155.912000] 19e0: 8d3719ec 8d371a38 8d31833c 8d318f7c c02f512c 8d3719fc 8d318ea0 c029442e
> [ 155.912000] 1a00: 8d371a08 8d3182c0 00000000 00000000 8d339ae0 00000000 c029599e 8d371a38
> [ 155.912000] 1a20: 8d506850 8f1e13c0 00000000 8d3182c0 8d339afc 8d339ae0 8d339ae0 8d3182c0
> [ 155.912000] 1a40: 8f1e13c0 8d68d000 8d2e9200 c03123c0 00000800 00000002 c0295b4a 8d371a74
> [ 155.912000] 1a60: 000003bc 88011efc 8d3182c0 8f1e13c0 8d339ae0 881e0600 8d339af8 8d371aa0
> [ 155.912000] 1a80: c0296a02 8d371aa0 8d506850 881e0600 881302b4 8d506864 8f1e13c0 8d339ae0
> [ 155.912000] 1aa0: 00000000 0000000c 0000001c 8d506850 8d506864 8d506842 8d3182c0 c0236b98
> [ 155.912000] 1ac0: 8f1e1000 01081ad8 24000000 a5f335fe 02100e00 0200b772 0ece6872 8d370000
> [ 155.912000] 1ae0: 8d2ecf20 881e85c2 8d371b04 8834278c 8f1e1000 8d68eea0 8834276c 00006000
> [ 155.912000] 1b00: 8d339ae0 00000000 882034b6 c029b384 8834278c 881f8488 8d371b34 8d68eea0
> [ 155.912000] 1b20: 00000010 8d68eea0 8f1e1000 8d2ed600 8d339ae0 881e88ac 8d371b54 8d2ed640
> [ 155.912000] 1b40: 00000000 8d2ed600 8f1e1000 8d339ae0 8d2ed65c 882053dc 8d371b74 8d2bd74a
> [ 155.912000] 1b60: 8d339b5c 00000000 0000000e 8d2bd740 8d339ae0 881302b4 fffffff0 8d2bd754
> [ 155.912000] 1b80: 8d2bd750 882054ae 8d371ba4 8834270c 8d371bec 8d506866 8d339b20 8f1e1000
> [ 155.912000] 1ba0: 8d339ae0 88202e7c 8d371bb4 8d371c38 8f0b5b80 88202e90 8d371bbc 88203c52
> [ 155.912000] 1bc0: 8d371bc8 8f0b5b80 88222856 8d371bd0 88222a36 8d371bec 00000008 8d371be0
> [ 155.912000] 1be0: 8d2da75c 8d3738c0 8d371c38 00000000 00000000 00000000 00010000 00000000
> [ 155.912000] 1c00: 15b2a8c0 1bb2a8c0 00000000 15b2a8c0 00003810 00000000 c0349300 00000000
> [ 155.912000] 1c20: 88222bc6 8d371c38 8821db68 88342bd8 8d373f01 3900a76f 8d2da6e0 00000000
> [ 155.912000] 1c40: 00000038 00000000 3900a76f 15b2a8c0 00000200 00000100 00000008 0669ae33
> [ 155.912000] 1c60: 00000000 00000000 00000000 00000000 8834270c 00000008 8821db68 88342bd8
> [ 155.912000] 1c80: 8d2da720 8d2da6e0 881e2b40 8d371c9c 88342bd8 8d373f01 88223050 8d371ca4
> [ 155.912000] 1ca0: 8d2da6e0 88200dee 8d371cb4 88342bdc 8d2da6e0 88200ce8 8d371ccc 00000000
> [ 155.912000] 1cc0: 8d506c50 8d2da6f8 8d2da6e0 881e61d4 8d371ce4 00000000 8f1e1000 8d371cb4
> [ 155.912000] 1ce0: 883426ec 0000009c 00000001 8d2da6e0 8834270c 881e636a 8d371d14 8f1e1000
> [ 155.912000] 1d00: 8d2da6f8 8d3182c0 8d2da75c 00000000 8d2da6e0 8d2da6e0 c02914f2 8d371d20
> [ 155.912000] 1d20: c02928a0 8d371d40 8f1e13c0 8f1e107c 8d3182c0 00000000 00004208 8d371dec
> [ 155.912000] 1d40: 8d371dcc c01cff02 8d371d4c 00000000 8d371d50 00000000 c01d59ca 8d371d6c
> [ 155.912000] 1d60: 00000004 8d371da0 8d43ec00 8d371de4 00000035 00000000 00001000 00001000
> [ 155.912000] 1d80: 00005000 00001000 881dff72 c02933c0 8d371dac 8f1e177c 8d3182c0 8d2da6e0
> [ 155.912000] 1da0: 8d506c28 0000002b 8d371dec 00000001 8d3182c0 8f1e13c0 c0293bda 8d371dd8
> [ 155.912000] 1dc0: 8d2da6e0 8d371dec 8d68d000 00000000 8d68d000 8d3182c0 00000000 8d371d4c
> [ 155.912000] 1de0: c01d0450 8d506c32 8d506c28 8d2da6e0 8d3182c0 8f1e13c0 8d68d000 8d2e9200
> [ 155.912000] 1e00: 00000000 00000010 00000000 00000000 00000000 c0304e56 8d371e34 00007499
> [ 155.912000] 1e20: 0000012a 00000002 8d2da6e0 8d3182c0 8d32f400 0000000f 00000002 00000000
> [ 155.912000] 1e40: 8d2da720 8d506c22 8d2da75c 00000000 00000000 00000000 00000985 ffffffc7
> [ 155.912000] 1e60: 00000000 0000000b 00000000 00000000 c030a6d6 8d371e90 8d32f400 0000008e
> [ 155.912000] 1e80: 8d319009 8d2da75c 8d4ca424 8d4ca420 00000002 00000000 8d318ea0 8d2da6e0
> [ 155.912000] 1ea0: 8d318f98 c02f864c 8d371ec4 00000001 8d3aa9bc 8d3aa93c 00010000 00008000
> [ 155.912000] 1ec0: 8d32f400 8d32f000 00010000 00000000 00000000 00000000 00000000 00000000
> [ 155.912000] 1ee0: 00008000 8d32f47c 8d32f400 c02f8852 8d371f0c 00000001 8d3aa9bc 8d3aa93c
> [ 155.912000] 1f00: 8d32f400 8d32f400 8d318ea8 c030b370 8d371f1c 8d32f2fc 8d2e7000 c01d7368
> [ 155.912000] 1f20: 8d371f30 8d43ec00 7fffffff 8d3aa800 8d4a5da4 c01d72ec 00000000 8d3aa8fc
> [ 155.912000] 1f40: 8d3aaa44 00000003 00000001 8802f172 8802f184 8d371f70 00000000 00000000
> [ 155.912000] 1f60: c01d72ec 8d3aa800 8d4a5d94 00000000 00000000 8d3aa800 00000000 8d371f7c
> [ 155.912000] 1f80: 8d371f7c 88003d5c 8d371f9c 00000000 00000000 00000000 00000000 00000000
> [ 155.912000] 1fa0: 00000000 00000000 00000000 00000000 00000000 8d4a5d94 8802f128 00000000
> [ 155.912000] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 155.912000] 1fe0: 8d371fa4 88003d54 00000000 40008000 00000000 00000000 00000000 00000000
> [ 155.916000] ---[ end trace d5cca8a145e4559d ]---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
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: [PATCH v2] net/r8169: update the new parser for the new firmware
From: Ben Hutchings @ 2011-06-17 14:50 UTC (permalink / raw)
To: Francois Romieu; +Cc: hayeswang, netdev, linux-kernel
In-Reply-To: <20110617125300.GA2193@electric-eye.fr.zoreil.com>
On Fri, 2011-06-17 at 14:53 +0200, Francois Romieu wrote:
> Ben Hutchings <bhutchings@solarflare.com> :
> [...]
> > I thought the idea of embedding a version here was to be able to report
> > in in get_drvinfo, not to print it on load.
>
> Reporting the version for the new firmware format through ethtool is
> currently hacked on.
>
> Do you want the load time version / format messages removed ?
>
> I think they can be of some use - at least temporarily - but I won't mind
> removing them now.
I don't care one way or the other. But it's more important to report
the version through get_drvinfo.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [RFC 1/2] ethtool: Add DMA Coalescing adapter feature to ethtool.
From: Wyborny, Carolyn @ 2011-06-17 14:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, bhutchings@solarflare.com
In-Reply-To: <20110616.233239.2238723246132860968.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Thursday, June 16, 2011 8:33 PM
>To: Wyborny, Carolyn
>Cc: netdev@vger.kernel.org; bhutchings@solarflare.com
>Subject: Re: [RFC 1/2] ethtool: Add DMA Coalescing adapter feature to
>ethtool.
>
>From: Carolyn Wyborny <carolyn.wyborny@intel.com>
>Date: Tue, 14 Jun 2011 10:12:36 -0700
>
>> This RFC patch adds support for DMA Coalescing device feature
>> configuration via ethtool.
>>
>> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
> ...
>> static struct cmdline_info cmdline_offload[] = {
>> - { "rx", CMDL_BOOL, &off_csum_rx_wanted, NULL },
>> - { "tx", CMDL_BOOL, &off_csum_tx_wanted, NULL },
>> - { "sg", CMDL_BOOL, &off_sg_wanted, NULL },
>
>Can you please not destroy the existing formatting of every single
>table and piece of code you are modifying?
Yes, this is an error, I'm already redoing the patch.
Thanks,
Carolyn
Carolyn Wyborny
Linux Development
LAN Access Division
Intel Corporation
^ permalink raw reply
* Re: [AX25] inconsistent lock state
From: f6bvp @ 2011-06-17 15:26 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Arnd Bergmann, linux-kernel, Linux Netdev List, linux-hams
In-Reply-To: <20110617135147.GA3470@linux-mips.org>
Hi Ralf,
I wanted to check FPAC ROSE application behaviour when Ethernet link was
shutdown.
To do this I removed the ethernet connector !
I agree this was a very agressive action.
73s de Bernard, f6bvp
Le 17/06/2011 15:51, Ralf Baechle a écrit :
> On Fri, Jun 17, 2011 at 03:36:15PM +0200, Arnd Bergmann wrote:
>
> (Removed Jarek from cc; his email bounces.)
>
>> The message hints that disc_data_lock is aquired with softirqs disabled,
>> but does not itself disable softirqs, which can in rare circumstances
>> lead to a deadlock.
>>
>> Does this fix it?
> If so, drivers/net/hamradio.c, function sp_get() would probably need the
> equivalent fix. Same for drivers/net/ppp_async.c:ap_get() and sp_get() in
> drivers/net/ppp_synctty.c.
>
> Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" 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: bnx2 udp multicast packet loss and jtter
From: Eric Dumazet @ 2011-06-17 15:30 UTC (permalink / raw)
To: Kieran Kunhya; +Cc: netdev
In-Reply-To: <BANLkTimCgWSANaje4aBE5gQdwKWNRJX40A@mail.gmail.com>
Le samedi 11 juin 2011 à 15:32 +0100, Kieran Kunhya a écrit :
> Hello,
>
> I get some bad packet loss and high jitter on a BCM5709. This is on
> kernel 2.6.38-8 - unfortunately using a newer kernel isn't an option
> right now.
> The bnx2 driver is version v2.0.23b.
>
> I've tried a lot of kenel types such as -lowlatency, -ck and vanilla.
> The thread doing the udp output is at realtime priority and the same
> thing happens with different applications.
>
> Example of jitter
> http://dl.dropbox.com/u/2701213/jitter.png
>
> Is there anything I can do to further diagnose this problem?
>
Hi
How is this jitter measured ?
Is the link otherwise idle, or do you have a particular qdisc setup to
make sure packets from other flow wont have an effect ?
^ permalink raw reply
* Re: [AX25] inconsistent lock state
From: f6bvp @ 2011-06-17 15:31 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Ralf Baechle, linux-kernel, Linux Netdev List, linux-hams
In-Reply-To: <201106171611.10655.arnd@arndb.de>
Hi Arnd,
I will apply your patch with write_lock_bh only following your
remark about recursive call.
I agree that the error message did not appear systematically
when doing what I did i.e. unpluging the ethernet cable from
the computer interface.
However, I will perform the same a few times and see what happens.
Many thanks.
Bernard
Le 17/06/2011 16:11, Arnd Bergmann a écrit :
> On Friday 17 June 2011 15:51:48 Ralf Baechle wrote:
>> On Fri, Jun 17, 2011 at 03:36:15PM +0200, Arnd Bergmann wrote:
>>
>> (Removed Jarek from cc; his email bounces.)
>>
>>> The message hints that disc_data_lock is aquired with softirqs disabled,
>>> but does not itself disable softirqs, which can in rare circumstances
>>> lead to a deadlock.
>>>
>>> Does this fix it?
>> If so, drivers/net/hamradio.c, function sp_get() would probably need the
>> equivalent fix. Same for drivers/net/ppp_async.c:ap_get() and sp_get() in
>> drivers/net/ppp_synctty.c.
> It seems that ppp_synctty.c is ok, it uses write_lock_irq() already,
> sixpack.c looks like it has the same bug as mkiss. I also realized
> after sending out the patch that only the write_lock needs to be
> changed to write_lock_bh, while read_lock can leave softirqs enabled
> because it can be called recursively.
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" 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
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