* [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses [not found] ` <4B507FAA.8010007@free.fr> @ 2010-01-15 20:36 ` Jarek Poplawski 2010-01-16 9:04 ` David Miller ` (3 more replies) 0 siblings, 4 replies; 24+ messages in thread From: Jarek Poplawski @ 2010-01-15 20:36 UTC (permalink / raw) To: David S. Miller Cc: Bernard Pidoux, Bernard Pidoux, linux-kernel, Linux Netdev List, Ralf Baechle, linux-hams, Rafael J. Wysocki On Fri, Jan 15, 2010 at 03:46:02PM +0100, Bernard Pidoux wrote: > Hi Jarek, Hi Bernard, > > Congratulation. With your patch I did not see any more kernel panics > since my last post. > I think it should be commited. > Many thanks. > > Wishing you a happy new year 2010. > Happy new year to you as well. Thanks, Jarek P. --------------------> Wrong ax25_cb refcounting in ax25_send_frame() and by its callers can cause timer oopses (first reported with 2.6.29.6 kernel). Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14905 Reported-by: Bernard Pidoux <bpidoux@free.fr> Tested-by: Bernard Pidoux <bpidoux@free.fr> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> --- include/net/netrom.h | 2 ++ net/ax25/ax25_out.c | 6 ++++++ net/netrom/nr_route.c | 11 ++++++----- net/rose/rose_link.c | 8 ++++++++ net/rose/rose_route.c | 5 +++++ 5 files changed, 27 insertions(+), 5 deletions(-) diff --git a/include/net/netrom.h b/include/net/netrom.h index 15696b1..ab170a6 100644 --- a/include/net/netrom.h +++ b/include/net/netrom.h @@ -132,6 +132,8 @@ static __inline__ void nr_node_put(struct nr_node *nr_node) static __inline__ void nr_neigh_put(struct nr_neigh *nr_neigh) { if (atomic_dec_and_test(&nr_neigh->refcount)) { + if (nr_neigh->ax25) + ax25_cb_put(nr_neigh->ax25); kfree(nr_neigh->digipeat); kfree(nr_neigh); } diff --git a/net/ax25/ax25_out.c b/net/ax25/ax25_out.c index bf706f8..1491260 100644 --- a/net/ax25/ax25_out.c +++ b/net/ax25/ax25_out.c @@ -92,6 +92,12 @@ ax25_cb *ax25_send_frame(struct sk_buff *skb, int paclen, ax25_address *src, ax2 #endif } + /* + * There is one ref for the state machine; a caller needs + * one more to put it back, just like with the existing one. + */ + ax25_cb_hold(ax25); + ax25_cb_add(ax25); ax25->state = AX25_STATE_1; diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c index aacba76..e2e2d33 100644 --- a/net/netrom/nr_route.c +++ b/net/netrom/nr_route.c @@ -843,12 +843,13 @@ int nr_route_frame(struct sk_buff *skb, ax25_cb *ax25) dptr = skb_push(skb, 1); *dptr = AX25_P_NETROM; - ax25s = ax25_send_frame(skb, 256, (ax25_address *)dev->dev_addr, &nr_neigh->callsign, nr_neigh->digipeat, nr_neigh->dev); - if (nr_neigh->ax25 && ax25s) { - /* We were already holding this ax25_cb */ + ax25s = nr_neigh->ax25; + nr_neigh->ax25 = ax25_send_frame(skb, 256, + (ax25_address *)dev->dev_addr, + &nr_neigh->callsign, + nr_neigh->digipeat, nr_neigh->dev); + if (ax25s) ax25_cb_put(ax25s); - } - nr_neigh->ax25 = ax25s; dev_put(dev); ret = (nr_neigh->ax25 != NULL); diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c index bd86a63..5ef5f69 100644 --- a/net/rose/rose_link.c +++ b/net/rose/rose_link.c @@ -101,13 +101,17 @@ static void rose_t0timer_expiry(unsigned long param) static int rose_send_frame(struct sk_buff *skb, struct rose_neigh *neigh) { ax25_address *rose_call; + ax25_cb *ax25s; if (ax25cmp(&rose_callsign, &null_ax25_address) == 0) rose_call = (ax25_address *)neigh->dev->dev_addr; else rose_call = &rose_callsign; + ax25s = neigh->ax25; neigh->ax25 = ax25_send_frame(skb, 260, rose_call, &neigh->callsign, neigh->digipeat, neigh->dev); + if (ax25s) + ax25_cb_put(ax25s); return (neigh->ax25 != NULL); } @@ -120,13 +124,17 @@ static int rose_send_frame(struct sk_buff *skb, struct rose_neigh *neigh) static int rose_link_up(struct rose_neigh *neigh) { ax25_address *rose_call; + ax25_cb *ax25s; if (ax25cmp(&rose_callsign, &null_ax25_address) == 0) rose_call = (ax25_address *)neigh->dev->dev_addr; else rose_call = &rose_callsign; + ax25s = neigh->ax25; neigh->ax25 = ax25_find_cb(rose_call, &neigh->callsign, neigh->digipeat, neigh->dev); + if (ax25s) + ax25_cb_put(ax25s); return (neigh->ax25 != NULL); } diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c index 795c4b0..70a0b3b 100644 --- a/net/rose/rose_route.c +++ b/net/rose/rose_route.c @@ -235,6 +235,8 @@ static void rose_remove_neigh(struct rose_neigh *rose_neigh) if ((s = rose_neigh_list) == rose_neigh) { rose_neigh_list = rose_neigh->next; + if (rose_neigh->ax25) + ax25_cb_put(rose_neigh->ax25); kfree(rose_neigh->digipeat); kfree(rose_neigh); return; @@ -243,6 +245,8 @@ static void rose_remove_neigh(struct rose_neigh *rose_neigh) while (s != NULL && s->next != NULL) { if (s->next == rose_neigh) { s->next = rose_neigh->next; + if (rose_neigh->ax25) + ax25_cb_put(rose_neigh->ax25); kfree(rose_neigh->digipeat); kfree(rose_neigh); return; @@ -812,6 +816,7 @@ void rose_link_failed(ax25_cb *ax25, int reason) if (rose_neigh != NULL) { rose_neigh->ax25 = NULL; + ax25_cb_put(ax25); rose_del_route_by_neigh(rose_neigh); rose_kill_by_neigh(rose_neigh); ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses 2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski @ 2010-01-16 9:04 ` David Miller 2011-06-16 20:23 ` [AX25] inconsistent lock state f6bvp ` (2 subsequent siblings) 3 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2010-01-16 9:04 UTC (permalink / raw) To: jarkao2 Cc: bpidoux, bernard.pidoux, linux-kernel, netdev, ralf, linux-hams, rjw From: Jarek Poplawski <jarkao2@gmail.com> Date: Fri, 15 Jan 2010 21:36:54 +0100 > Wrong ax25_cb refcounting in ax25_send_frame() and by its callers can > cause timer oopses (first reported with 2.6.29.6 kernel). > > Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14905 > > Reported-by: Bernard Pidoux <bpidoux@free.fr> > Tested-by: Bernard Pidoux <bpidoux@free.fr> > Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> Applied, thanks everyone. ^ permalink raw reply [flat|nested] 24+ messages in thread
* [AX25] inconsistent lock state 2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski 2010-01-16 9:04 ` David Miller @ 2011-06-16 20:23 ` f6bvp 2011-06-17 13:28 ` Ralf Baechle 2011-06-17 13:36 ` Arnd Bergmann 2011-06-16 20:40 ` f6bvp 2011-07-07 13:31 ` Question with axudp Bernard, f6bvp 3 siblings, 2 replies; 24+ messages in thread From: f6bvp @ 2011-06-16 20:23 UTC (permalink / raw) To: linux-kernel; +Cc: Jarek Poplawski, Linux Netdev List, Ralf Baechle, linux-hams Hi, When unpluging ethernet connector a few seconds I observed the following kernel message : Jun 16 12:03:25 f6bvp-9 kernel: e1000e: eth1 NIC Link is Down Jun 16 12:03:25 f6bvp-9 ifplugd(eth1)[1541]: Link beat lost. Jun 16 12:03:31 f6bvp-9 ifplugd(eth1)[1541]: Executing '/etc/ifplugd/ifplugd.action eth1 down'. Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Withdrawing address record for 192.168.0.66 on eth1. Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.0.66. Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Interface eth1.IPv4 no longer relevant for mDNS. Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Withdrawing address record for fe80::21c:c0ff:fe36:723e on eth1. Jun 16 12:03:31 f6bvp-9 vnstatd[2022]: SIGHUP received, flushing data to disk and reloading config. Jun 16 12:03:31 f6bvp-9 ifplugd(eth1)[1541]: client: Rechargement de la configuration de vnstatd : #033[65G[#033[1;32m OK #033[0;39m]#015 Jun 16 12:03:31 f6bvp-9 ifplugd(eth1)[1541]: Program executed successfully. Jun 16 12:03:31 f6bvp-9 kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready Jun 16 12:03:34 f6bvp-9 kernel: 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: Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8109484e>] __lock_acquire+0x57e/0x14c0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81095836>] lock_acquire+0xa6/0x160 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f64f4>] _raw_read_lock+0x34/0x50 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa01850ed>] mkiss_get+0x1d/0x50 [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018517e>] mkiss_write_wakeup+0x1e/0xb0 [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129457e>] tty_wakeup+0x6e/0x80 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129f243>] pty_write+0x73/0x80 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0185d2e>] ax_xmit+0x27e/0x5e0 [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81339dac>] dev_hard_start_xmit+0x34c/0x6f0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81358b4d>] sch_direct_xmit+0xdd/0x260 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133cc8f>] dev_queue_xmit+0x1af/0x8a0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0325072>] ax25_queue_xmit+0x52/0x60 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa032516f>] ax25_transmit_buffer+0xef/0x130 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0325238>] ax25_send_iframe+0x88/0xe0 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa032536e>] ax25_kick+0xde/0x220 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0326715>] ax25_std_frame_in+0x65/0x920 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa03241da>] ax25_rcv+0x3aa/0x9a0 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa032486f>] ax25_kiss_rcv+0x9f/0xb0 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133bba5>] __netif_receive_skb+0x205/0x6d0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133c144>] process_backlog+0xd4/0x1e0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133c995>] net_rx_action+0x125/0x270 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810618f1>] __do_softirq+0xc1/0x210 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813ffa9c>] call_softirq+0x1c/0x30 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810627db>] local_bh_enable_ip+0xeb/0xf0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f6594>] _raw_spin_unlock_bh+0x34/0x40 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0186522>] mkiss_receive_buf+0x2e2/0x3dc [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129e122>] flush_to_ldisc+0x1b2/0x1d0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810762c0>] process_one_work+0x1a0/0x510 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81078ba2>] worker_thread+0x172/0x400 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8107d816>] kthread+0xb6/0xc0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813ff9a4>] kernel_thread_helper+0x4/0x10 Jun 16 12:03:34 f6bvp-9 kernel: irq event stamp: 76635461 Jun 16 12:03:34 f6bvp-9 kernel: hardirqs last enabled at (76635461): [<ffffffff813f6620>] _raw_spin_unlock_irqrestore+0x40/0x70 Jun 16 12:03:34 f6bvp-9 kernel: hardirqs last disabled at (76635460): [<ffffffff813f5f1e>] _raw_spin_lock_irqsave+0x2e/0x70 Jun 16 12:03:34 f6bvp-9 kernel: softirqs last enabled at (76635394): [<ffffffff81329337>] sk_common_release+0x67/0xd0 Jun 16 12:03:34 f6bvp-9 kernel: softirqs last disabled at (76635392): [<ffffffff813f60f6>] _raw_write_lock_bh+0x16/0x50 Jun 16 12:03:34 f6bvp-9 kernel: Jun 16 12:03:34 f6bvp-9 kernel: other info that might help us debug this: Jun 16 12:03:34 f6bvp-9 kernel: 2 locks held by ax25ipd/2813: Jun 16 12:03:34 f6bvp-9 kernel: #0: (big_tty_mutex){+.+.+.}, at: [<ffffffff813f67ce>] tty_lock+0x2e/0x4f Jun 16 12:03:34 f6bvp-9 kernel: #1: (&tty->ldisc_mutex){+.+.+.}, at: [<ffffffff8129d597>] tty_ldisc_hangup+0xe7/0x250 Jun 16 12:03:34 f6bvp-9 kernel: Jun 16 12:03:34 f6bvp-9 kernel: stack backtrace: Jun 16 12:03:34 f6bvp-9 kernel: Pid: 2813, comm: ax25ipd Not tainted 2.6.39.1 #3 Jun 16 12:03:34 f6bvp-9 kernel: Call Trace: Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81092dc0>] print_usage_bug+0x170/0x180 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093a81>] mark_lock+0x211/0x3f0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810948c4>] __lock_acquire+0x5f4/0x14c0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093ccb>] ? mark_held_locks+0x6b/0xa0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f65d0>] ? _raw_spin_unlock_irq+0x30/0x40 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093fcd>] ? trace_hardirqs_on_caller+0x13d/0x180 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81095836>] lock_acquire+0xa6/0x160 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018552b>] ? mkiss_close+0x1b/0x90 [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093ccb>] ? mark_held_locks+0x6b/0xa0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f6221>] _raw_write_lock+0x31/0x40 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018552b>] ? mkiss_close+0x1b/0x90 [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8113775e>] ? kmem_cache_alloc_trace+0x7e/0x140 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129c84b>] tty_ldisc_close+0x4b/0x70 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129ce90>] tty_ldisc_reinit+0x40/0x80 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129d5b4>] tty_ldisc_hangup+0x104/0x250 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129588c>] __tty_hangup+0x15c/0x3e0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8109401d>] ? trace_hardirqs_on+0xd/0x10 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81295b3e>] tty_vhangup+0xe/0x10 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129f37e>] pty_close+0x10e/0x160 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81295ceb>] tty_release+0x16b/0x640 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8113920a>] ? kmem_cache_free+0x11a/0x160 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81142f9a>] fput+0xea/0x230 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8113ee03>] filp_close+0x63/0x90 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105dab1>] put_files_struct+0x171/0x190 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105d978>] ? put_files_struct+0x38/0x190 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105db22>] exit_files+0x52/0x60 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105deb9>] do_exit+0x189/0x860 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81142cc0>] ? fget+0xd0/0xd0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f69b9>] ? retint_swapgs+0x13/0x1b Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105e5eb>] do_group_exit+0x5b/0xd0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105e677>] sys_exit_group+0x17/0x20 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813fe812>] system_call_fastpath+0x16/0x1b Kernel is 2.6.39.1 Is there something wrong in AX25 code or (more unlikely) is this operation not permitted ? Thanks for help. Bernard Pidoux -- 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 [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-16 20:23 ` [AX25] inconsistent lock state f6bvp @ 2011-06-17 13:28 ` Ralf Baechle 2011-06-17 13:36 ` Arnd Bergmann 1 sibling, 0 replies; 24+ messages in thread From: Ralf Baechle @ 2011-06-17 13:28 UTC (permalink / raw) To: f6bvp; +Cc: linux-kernel, Jarek Poplawski, Linux Netdev List, linux-hams 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 [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-16 20:23 ` [AX25] inconsistent lock state f6bvp 2011-06-17 13:28 ` Ralf Baechle @ 2011-06-17 13:36 ` Arnd Bergmann 2011-06-17 13:51 ` Ralf Baechle 1 sibling, 1 reply; 24+ messages in thread 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 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 [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-17 13:36 ` Arnd Bergmann @ 2011-06-17 13:51 ` Ralf Baechle 2011-06-17 14:11 ` Arnd Bergmann 2011-06-17 15:26 ` [AX25] inconsistent lock state f6bvp 0 siblings, 2 replies; 24+ messages in thread From: Ralf Baechle @ 2011-06-17 13:51 UTC (permalink / raw) To: Arnd Bergmann; +Cc: f6bvp, linux-kernel, Linux Netdev List, linux-hams 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 [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-17 13:51 ` Ralf Baechle @ 2011-06-17 14:11 ` Arnd Bergmann 2011-06-17 15:31 ` f6bvp 2011-06-25 15:51 ` f6bvp 2011-06-17 15:26 ` [AX25] inconsistent lock state f6bvp 1 sibling, 2 replies; 24+ messages in thread From: Arnd Bergmann @ 2011-06-17 14:11 UTC (permalink / raw) To: Ralf Baechle; +Cc: f6bvp, linux-kernel, Linux Netdev List, linux-hams 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 [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-17 14:11 ` Arnd Bergmann @ 2011-06-17 15:31 ` f6bvp 2011-06-25 15:51 ` f6bvp 1 sibling, 0 replies; 24+ messages in thread From: f6bvp @ 2011-06-17 15:31 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Ralf Baechle, linux-kernel, Linux Netdev List, linux-hams 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 [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-17 14:11 ` Arnd Bergmann 2011-06-17 15:31 ` f6bvp @ 2011-06-25 15:51 ` f6bvp 2011-06-25 16:39 ` Ralf Baechle DL5RB 2012-10-21 15:18 ` [NetRom] possible circular locking dependency detected Bernard f6bvp 1 sibling, 2 replies; 24+ messages in thread From: f6bvp @ 2011-06-25 15:51 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Ralf Baechle, linux-kernel, Linux Netdev List, linux-hams Hi, I applied the patch and since then I could not reproduce the inconsistent lock state. Thus mkiss patch fixed it. 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 [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-25 15:51 ` f6bvp @ 2011-06-25 16:39 ` Ralf Baechle DL5RB 2011-07-01 13:00 ` Bernard F6BVP 2012-10-21 15:18 ` [NetRom] possible circular locking dependency detected Bernard f6bvp 1 sibling, 1 reply; 24+ messages in thread From: Ralf Baechle DL5RB @ 2011-06-25 16:39 UTC (permalink / raw) To: f6bvp; +Cc: Arnd Bergmann, linux-kernel, Linux Netdev List, linux-hams On Sat, Jun 25, 2011 at 05:51:39PM +0200, f6bvp wrote: > I applied the patch and since then I could not reproduce the > inconsistent lock state. > Thus mkiss patch fixed it. I also think the patch is the right thing, so Acked-by: Ralf Baechle <ralf@linux-mips.org> Ralf ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-25 16:39 ` Ralf Baechle DL5RB @ 2011-07-01 13:00 ` Bernard F6BVP 2011-07-01 21:28 ` [PATCH] 6pack,mkiss: fix lock inconsistency Arnd Bergmann 0 siblings, 1 reply; 24+ messages in thread From: Bernard F6BVP @ 2011-07-01 13:00 UTC (permalink / raw) To: Ralf Baechle DL5RB Cc: Arnd Bergmann, linux-kernel, Linux Netdev List, linux-hams Hi all, Now, who is going to commit this mkiss patch and the equivalent one for sixpack.c ? Bernard, f6bvp Le 25/06/2011 18:39, Ralf Baechle DL5RB a écrit : > On Sat, Jun 25, 2011 at 05:51:39PM +0200, f6bvp wrote: > >> I applied the patch and since then I could not reproduce the >> inconsistent lock state. >> Thus mkiss patch fixed it. > > I also think the patch is the right thing, so > > Acked-by: Ralf Baechle<ralf@linux-mips.org> > > 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 [flat|nested] 24+ messages in thread
* [PATCH] 6pack,mkiss: fix lock inconsistency 2011-07-01 13:00 ` Bernard F6BVP @ 2011-07-01 21:28 ` Arnd Bergmann 2011-07-02 0:30 ` David Miller 0 siblings, 1 reply; 24+ messages in thread From: Arnd Bergmann @ 2011-07-01 21:28 UTC (permalink / raw) To: Bernard F6BVP, David Miller Cc: Ralf Baechle DL5RB, linux-kernel, Linux Netdev List, linux-hams Lockdep found a locking inconsistency in the mkiss_close function: > kernel: [ INFO: inconsistent lock state ] > kernel: 2.6.39.1 #3 > kernel: --------------------------------- > kernel: inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage. > kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes: > kernel: (disc_data_lock){+++?.-}, at: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss] > kernel: {IN-SOFTIRQ-R} state was registered at: 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. The same problem is present in the 6pack driver, this patch fixes both by using write_lock_bh instead of write_lock. Reported-by: Bernard F6BVP <f6bvp@free.fr> Tested-by: Bernard F6BVP <f6bvp@free.fr> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ralf Baechle<ralf@linux-mips.org> Cc: stable@kernel.org --- On Friday 01 July 2011 15:00:35 Bernard F6BVP wrote: > > Now, who is going to commit this mkiss patch and the equivalent one for > sixpack.c ? Here's a formal patch with all the right tags, I assume that David Miller will apply that to the netdev tree. diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c index 9624cbf..fea7cb4 100644 --- a/drivers/net/hamradio/6pack.c +++ b/drivers/net/hamradio/6pack.c @@ -694,10 +694,10 @@ static void sixpack_close(struct tty_struct *tty) { struct sixpack *sp; - write_lock(&disc_data_lock); + write_lock_bh(&disc_data_lock); sp = tty->disc_data; tty->disc_data = NULL; - write_unlock(&disc_data_lock); + write_unlock_bh(&disc_data_lock); if (!sp) return; diff --git a/drivers/net/hamradio/mkiss.c b/drivers/net/hamradio/mkiss.c index 9f84c83..324f7bf 100644 --- a/drivers/net/hamradio/mkiss.c +++ b/drivers/net/hamradio/mkiss.c @@ -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 related [flat|nested] 24+ messages in thread
* Re: [PATCH] 6pack,mkiss: fix lock inconsistency 2011-07-01 21:28 ` [PATCH] 6pack,mkiss: fix lock inconsistency Arnd Bergmann @ 2011-07-02 0:30 ` David Miller 0 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2011-07-02 0:30 UTC (permalink / raw) To: arnd; +Cc: f6bvp, ralf, linux-kernel, netdev, linux-hams From: Arnd Bergmann <arnd@arndb.de> Date: Fri, 1 Jul 2011 23:28:46 +0200 > Lockdep found a locking inconsistency in the mkiss_close function: > >> kernel: [ INFO: inconsistent lock state ] >> kernel: 2.6.39.1 #3 >> kernel: --------------------------------- >> kernel: inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage. >> kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes: >> kernel: (disc_data_lock){+++?.-}, at: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss] >> kernel: {IN-SOFTIRQ-R} state was registered at: > > 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. > The same problem is present in the 6pack driver, this patch fixes both > by using write_lock_bh instead of write_lock. > > Reported-by: Bernard F6BVP <f6bvp@free.fr> > Tested-by: Bernard F6BVP <f6bvp@free.fr> > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > Acked-by: Ralf Baechle<ralf@linux-mips.org> > Cc: stable@kernel.org Applied, thanks! ^ permalink raw reply [flat|nested] 24+ messages in thread
* [NetRom] possible circular locking dependency detected 2011-06-25 15:51 ` f6bvp 2011-06-25 16:39 ` Ralf Baechle DL5RB @ 2012-10-21 15:18 ` Bernard f6bvp 1 sibling, 0 replies; 24+ messages in thread From: Bernard f6bvp @ 2012-10-21 15:18 UTC (permalink / raw) Cc: Ralf Baechle, linux-kernel, Linux Netdev List, linux-hams, Bernard Pidoux [-- Attachment #1: Type: text/plain, Size: 191 bytes --] Hi, When shutting down my dual core system, there was a possible circular locking dependency detected that is related to NetRom. Here is the syslog report. Regards, Bernard, f6bvp [-- Attachment #2: ax25ipd_not_tainted.txt --] [-- Type: text/plain, Size: 13728 bytes --] Oct 21 12:10:35 f6bvp-8 aprslist[1773]: terminating on SIGTERM Oct 21 12:10:35 f6bvp-8 fpacstat: terminating on SIGTERM Oct 21 12:10:35 f6bvp-8 netromd[1653]: terminating on SIGTERM Oct 21 12:10:35 f6bvp-8 ax25ipd: Oct 21 12:10:35 f6bvp-8 ax25ipd: socket udp on port 10094 Oct 21 12:10:35 f6bvp-8 ax25ipd: mode tnc Oct 21 12:10:35 f6bvp-8 ax25ipd: device /dev/ptmx Oct 21 12:10:35 f6bvp-8 ax25ipd: speed 115200 Oct 21 12:10:35 f6bvp-8 ax25ipd: loglevel 1 Oct 21 12:10:35 f6bvp-8 ax25ipd: Oct 21 12:10:35 f6bvp-8 ax25ipd: K4GBB 184.4.148.122 udp 10094 1 Oct 21 12:10:35 f6bvp-8 ax25ipd: F8COJ 0.0.0.0 udp 10093 1 Oct 21 12:10:35 f6bvp-8 ax25ipd: F3KT 62.147.189.164 udp 10093 1 Oct 21 12:10:35 f6bvp-8 ax25ipd: F6BVP-12 192.168.0.68 udp 10093 4 Oct 21 12:10:35 f6bvp-8 ax25ipd: F6BVP-11 192.168.0.115 udp 10093 4 Oct 21 12:10:35 f6bvp-8 ax25ipd: F6BVP-10 192.168.0.115 udp 10093 5 Oct 21 12:10:35 f6bvp-8 ax25ipd: VA2BBS 24.212.252.110 udp 10093 1 Oct 21 12:10:35 f6bvp-8 ax25ipd: ON4HU 81.243.88.115 udp 10093 1 Oct 21 12:10:35 f6bvp-8 ax25ipd: IZ3LSV 88.149.155.158 udp 10094 5 Oct 21 12:10:35 f6bvp-8 ax25ipd: Oct 21 12:10:35 f6bvp-8 nfs-server[27474]: Arrêt de NFS kernel daemon Oct 21 12:10:36 f6bvp-8 kernel: [522519.150299] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150313] ====================================================== Oct 21 12:10:36 f6bvp-8 kernel: [522519.150317] [ INFO: possible circular locking dependency detected ] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150321] 3.6.1 #1 Not tainted Oct 21 12:10:36 f6bvp-8 kernel: [522519.150325] ------------------------------------------------------- Oct 21 12:10:36 f6bvp-8 kernel: [522519.150329] ax25ipd/1580 is trying to acquire lock: Oct 21 12:10:36 f6bvp-8 kernel: [522519.150333] (nr_node_list_lock){+.....}, at: [<ffffffffa06775ec>] nr_rt_device_down+0x7c/0x240 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150352] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150352] but task is already holding lock: Oct 21 12:10:36 f6bvp-8 kernel: [522519.150356] (nr_neigh_list_lock){+.-.-.}, at: [<ffffffffa0677596>] nr_rt_device_down+0x26/0x240 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150373] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150373] which lock already depends on the new lock. Oct 21 12:10:36 f6bvp-8 kernel: [522519.150373] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150378] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150378] the existing dependency chain (in reverse order) is: Oct 21 12:10:36 f6bvp-8 kernel: [522519.150382] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150382] -> #2 (nr_neigh_list_lock){+.-.-.}: Oct 21 12:10:36 f6bvp-8 kernel: [522519.150396] [<ffffffff810b6452>] lock_acquire+0x92/0x120 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150409] [<ffffffff81482b76>] _raw_spin_lock_bh+0x36/0x50 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150418] [<ffffffffa06769eb>] nr_remove_neigh+0x1b/0xb0 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150429] [<ffffffffa0677c20>] nr_rt_ioctl+0x2b0/0xa60 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150438] [<ffffffffa0673fa1>] nr_ioctl+0x51/0x1d0 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150445] [<ffffffff813973e0>] sock_do_ioctl+0x30/0x70 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150454] [<ffffffff813976f9>] sock_ioctl+0x79/0x2f0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150460] [<ffffffff8118dd08>] do_vfs_ioctl+0x98/0x560 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150468] [<ffffffff8118e261>] sys_ioctl+0x91/0xa0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150477] [<ffffffff8148b6b9>] system_call_fastpath+0x16/0x1b Oct 21 12:10:36 f6bvp-8 kernel: [522519.150486] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150486] -> #1 (&(&nr_node->node_lock)->rlock){+.....}: Oct 21 12:10:36 f6bvp-8 kernel: [522519.150498] [<ffffffff810b6452>] lock_acquire+0x92/0x120 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150505] [<ffffffff81482b76>] _raw_spin_lock_bh+0x36/0x50 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150512] [<ffffffffa0676acc>] nr_node_show+0x4c/0x150 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150522] [<ffffffff8119da5c>] seq_read+0x26c/0x420 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150529] [<ffffffff811e1046>] proc_reg_read+0x86/0xc0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150537] [<ffffffff8117b01c>] vfs_read+0xac/0x180 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150546] [<ffffffff8117b13a>] sys_read+0x4a/0x90 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150552] [<ffffffff8148b6b9>] system_call_fastpath+0x16/0x1b Oct 21 12:10:36 f6bvp-8 kernel: [522519.150559] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150559] -> #0 (nr_node_list_lock){+.....}: Oct 21 12:10:36 f6bvp-8 kernel: [522519.150571] [<ffffffff810b5c41>] __lock_acquire+0x1a91/0x1ce0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150578] [<ffffffff810b6452>] lock_acquire+0x92/0x120 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150586] [<ffffffff81482b76>] _raw_spin_lock_bh+0x36/0x50 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150592] [<ffffffffa06775ec>] nr_rt_device_down+0x7c/0x240 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150601] [<ffffffffa0674b4d>] nr_device_event+0x7d/0xa0 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150608] [<ffffffff81487388>] notifier_call_chain+0x58/0xb0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150617] [<ffffffff810810c6>] raw_notifier_call_chain+0x16/0x20 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150625] [<ffffffff813ae526>] call_netdevice_notifiers+0x36/0x60 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150633] [<ffffffff813ae71f>] dev_close_many+0xbf/0x100 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150639] [<ffffffff813ae838>] rollback_registered_many+0xd8/0x250 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150645] [<ffffffff813aea4d>] rollback_registered+0x2d/0x40 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150653] [<ffffffff813b17a8>] unregister_netdevice_queue+0x68/0xc0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150659] [<ffffffff813b1820>] unregister_netdev+0x20/0x30 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150666] [<ffffffffa05df4e7>] mkiss_close+0x57/0x90 [mkiss] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150674] [<ffffffff81309ed1>] tty_ldisc_close.isra.2+0x41/0x60 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150683] [<ffffffff8130a0d0>] tty_ldisc_reinit+0x40/0x80 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150689] [<ffffffff8130a850>] tty_ldisc_hangup+0x190/0x340 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150695] [<ffffffff81301f8a>] __tty_hangup+0x10a/0x3c0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150703] [<ffffffff8130226e>] tty_vhangup+0xe/0x10 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150709] [<ffffffff8130c66e>] pty_close+0x10e/0x180 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150716] [<ffffffff81303212>] tty_release+0x182/0x5c0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150724] [<ffffffff8117bf9e>] __fput+0xae/0x230 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150734] [<ffffffff8117c12e>] ____fput+0xe/0x10 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150740] [<ffffffff81076fb9>] task_work_run+0x69/0x90 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150748] [<ffffffff8105abef>] do_exit+0x87f/0x900 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150756] [<ffffffff8105afce>] do_group_exit+0x4e/0xc0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150763] [<ffffffff8105b057>] sys_exit_group+0x17/0x20 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150770] [<ffffffff8148b6b9>] system_call_fastpath+0x16/0x1b Oct 21 12:10:36 f6bvp-8 kernel: [522519.150778] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150778] other info that might help us debug this: Oct 21 12:10:36 f6bvp-8 kernel: [522519.150778] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150782] Chain exists of: Oct 21 12:10:36 f6bvp-8 kernel: [522519.150782] nr_node_list_lock --> &(&nr_node->node_lock)->rlock --> nr_neigh_list_lock Oct 21 12:10:36 f6bvp-8 kernel: [522519.150782] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150799] Possible unsafe locking scenario: Oct 21 12:10:36 f6bvp-8 kernel: [522519.150799] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150803] CPU0 CPU1 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150806] ---- ---- Oct 21 12:10:36 f6bvp-8 kernel: [522519.150809] lock(nr_neigh_list_lock); Oct 21 12:10:36 f6bvp-8 kernel: [522519.150819] lock(&(&nr_node->node_lock)->rlock); Oct 21 12:10:36 f6bvp-8 kernel: [522519.150826] lock(nr_neigh_list_lock); Oct 21 12:10:36 f6bvp-8 kernel: [522519.150834] lock(nr_node_list_lock); Oct 21 12:10:36 f6bvp-8 kernel: [522519.150842] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150842] *** DEADLOCK *** Oct 21 12:10:36 f6bvp-8 kernel: [522519.150842] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150847] 4 locks held by ax25ipd/1580: Oct 21 12:10:36 f6bvp-8 kernel: [522519.150851] #0: (big_tty_mutex){+.+.+.}, at: [<ffffffff814832d7>] tty_lock+0x17/0x19 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150867] #1: (&tty->ldisc_mutex){+.+.+.}, at: [<ffffffff8130a7d7>] tty_ldisc_hangup+0x117/0x340 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150885] #2: (rtnl_mutex){+.+.+.}, at: [<ffffffff813c11c7>] rtnl_lock+0x17/0x20 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150901] #3: (nr_neigh_list_lock){+.-.-.}, at: [<ffffffffa0677596>] nr_rt_device_down+0x26/0x240 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150921] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150921] stack backtrace: Oct 21 12:10:36 f6bvp-8 kernel: [522519.150927] Pid: 1580, comm: ax25ipd Not tainted 3.6.1 #1 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150930] Call Trace: Oct 21 12:10:36 f6bvp-8 kernel: [522519.150938] [<ffffffff81479b5a>] print_circular_bug+0x289/0x29a Oct 21 12:10:36 f6bvp-8 kernel: [522519.150945] [<ffffffff810b5c41>] __lock_acquire+0x1a91/0x1ce0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150954] [<ffffffffa06775ec>] ? nr_rt_device_down+0x7c/0x240 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150960] [<ffffffff810b6452>] lock_acquire+0x92/0x120 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150969] [<ffffffffa06775ec>] ? nr_rt_device_down+0x7c/0x240 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150976] [<ffffffff81482b76>] _raw_spin_lock_bh+0x36/0x50 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150984] [<ffffffffa06775ec>] ? nr_rt_device_down+0x7c/0x240 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.150990] [<ffffffff810b6ec5>] ? trace_hardirqs_on_caller+0x105/0x190 Oct 21 12:10:36 f6bvp-8 kernel: [522519.150997] [<ffffffffa0674b41>] ? nr_device_event+0x71/0xa0 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.151005] [<ffffffffa06775ec>] nr_rt_device_down+0x7c/0x240 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.151011] [<ffffffff8105d1a7>] ? local_bh_enable_ip+0x97/0x100 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151019] [<ffffffffa0674b4d>] nr_device_event+0x7d/0xa0 [netrom] Oct 21 12:10:36 f6bvp-8 kernel: [522519.151026] [<ffffffff81487388>] notifier_call_chain+0x58/0xb0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151033] [<ffffffff810810c6>] raw_notifier_call_chain+0x16/0x20 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151038] [<ffffffff813ae526>] call_netdevice_notifiers+0x36/0x60 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151044] [<ffffffff813ae71f>] dev_close_many+0xbf/0x100 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151050] [<ffffffff813ae838>] rollback_registered_many+0xd8/0x250 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151055] [<ffffffff813aea4d>] rollback_registered+0x2d/0x40 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151061] [<ffffffff813b17a8>] unregister_netdevice_queue+0x68/0xc0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151068] [<ffffffff813b1820>] unregister_netdev+0x20/0x30 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151077] [<ffffffffa05df4e7>] mkiss_close+0x57/0x90 [mkiss] Oct 21 12:10:36 f6bvp-8 kernel: [522519.151083] [<ffffffff81309ed1>] tty_ldisc_close.isra.2+0x41/0x60 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151089] [<ffffffff8130a0d0>] tty_ldisc_reinit+0x40/0x80 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151094] [<ffffffff8130a850>] tty_ldisc_hangup+0x190/0x340 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151101] [<ffffffff81301f8a>] __tty_hangup+0x10a/0x3c0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151107] [<ffffffff810b6f5d>] ? trace_hardirqs_on+0xd/0x10 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151114] [<ffffffff8130226e>] tty_vhangup+0xe/0x10 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151120] [<ffffffff8130c66e>] pty_close+0x10e/0x180 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151126] [<ffffffff81303212>] tty_release+0x182/0x5c0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151132] [<ffffffff81192d92>] ? dput+0x62/0x1b0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151138] [<ffffffff8117bf9e>] __fput+0xae/0x230 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151144] [<ffffffff8117c12e>] ____fput+0xe/0x10 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff81076fb9>] task_work_run+0x69/0x90 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff8105abef>] do_exit+0x87f/0x900 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff81483495>] ? retint_swapgs+0x13/0x1b Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff8105afce>] do_group_exit+0x4e/0xc0 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff8105b057>] sys_exit_group+0x17/0x20 Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff8148b6b9>] system_call_fastpath+0x16/0x1b ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-17 13:51 ` Ralf Baechle 2011-06-17 14:11 ` Arnd Bergmann @ 2011-06-17 15:26 ` f6bvp 1 sibling, 0 replies; 24+ messages in thread From: f6bvp @ 2011-06-17 15:26 UTC (permalink / raw) To: Ralf Baechle; +Cc: Arnd Bergmann, linux-kernel, Linux Netdev List, linux-hams 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 [flat|nested] 24+ messages in thread
* [AX25] inconsistent lock state 2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski 2010-01-16 9:04 ` David Miller 2011-06-16 20:23 ` [AX25] inconsistent lock state f6bvp @ 2011-06-16 20:40 ` f6bvp 2022-01-25 11:46 ` [AX25] ipv6 incompatible with AX.25 Bernard Pidoux 2011-07-07 13:31 ` Question with axudp Bernard, f6bvp 3 siblings, 1 reply; 24+ messages in thread From: f6bvp @ 2011-06-16 20:40 UTC (permalink / raw) To: linux-kernel; +Cc: Linux Netdev List, Ralf Baechle, linux-hams Hi, When unpluging ethernet connector a few seconds I observed the following kernel message : Jun 16 12:03:25 f6bvp-9 kernel: e1000e: eth1 NIC Link is Down Jun 16 12:03:25 f6bvp-9 ifplugd(eth1)[1541]: Link beat lost. Jun 16 12:03:31 f6bvp-9 ifplugd(eth1)[1541]: Executing '/etc/ifplugd/ifplugd.action eth1 down'. Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Withdrawing address record for 192.168.0.66 on eth1. Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.0.66. Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Interface eth1.IPv4 no longer relevant for mDNS. Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Withdrawing address record for fe80::21c:c0ff:fe36:723e on eth1. Jun 16 12:03:31 f6bvp-9 vnstatd[2022]: SIGHUP received, flushing data to disk and reloading config. Jun 16 12:03:31 f6bvp-9 ifplugd(eth1)[1541]: client: Rechargement de la configuration de vnstatd : #033[65G[#033[1;32m OK #033[0;39m]#015 Jun 16 12:03:31 f6bvp-9 ifplugd(eth1)[1541]: Program executed successfully. Jun 16 12:03:31 f6bvp-9 kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready Jun 16 12:03:34 f6bvp-9 kernel: 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: Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8109484e>] __lock_acquire+0x57e/0x14c0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81095836>] lock_acquire+0xa6/0x160 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f64f4>] _raw_read_lock+0x34/0x50 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa01850ed>] mkiss_get+0x1d/0x50 [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018517e>] mkiss_write_wakeup+0x1e/0xb0 [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129457e>] tty_wakeup+0x6e/0x80 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129f243>] pty_write+0x73/0x80 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0185d2e>] ax_xmit+0x27e/0x5e0 [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81339dac>] dev_hard_start_xmit+0x34c/0x6f0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81358b4d>] sch_direct_xmit+0xdd/0x260 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133cc8f>] dev_queue_xmit+0x1af/0x8a0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0325072>] ax25_queue_xmit+0x52/0x60 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa032516f>] ax25_transmit_buffer+0xef/0x130 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0325238>] ax25_send_iframe+0x88/0xe0 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa032536e>] ax25_kick+0xde/0x220 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0326715>] ax25_std_frame_in+0x65/0x920 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa03241da>] ax25_rcv+0x3aa/0x9a0 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa032486f>] ax25_kiss_rcv+0x9f/0xb0 [ax25] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133bba5>] __netif_receive_skb+0x205/0x6d0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133c144>] process_backlog+0xd4/0x1e0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133c995>] net_rx_action+0x125/0x270 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810618f1>] __do_softirq+0xc1/0x210 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813ffa9c>] call_softirq+0x1c/0x30 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810627db>] local_bh_enable_ip+0xeb/0xf0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f6594>] _raw_spin_unlock_bh+0x34/0x40 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0186522>] mkiss_receive_buf+0x2e2/0x3dc [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129e122>] flush_to_ldisc+0x1b2/0x1d0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810762c0>] process_one_work+0x1a0/0x510 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81078ba2>] worker_thread+0x172/0x400 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8107d816>] kthread+0xb6/0xc0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813ff9a4>] kernel_thread_helper+0x4/0x10 Jun 16 12:03:34 f6bvp-9 kernel: irq event stamp: 76635461 Jun 16 12:03:34 f6bvp-9 kernel: hardirqs last enabled at (76635461): [<ffffffff813f6620>] _raw_spin_unlock_irqrestore+0x40/0x70 Jun 16 12:03:34 f6bvp-9 kernel: hardirqs last disabled at (76635460): [<ffffffff813f5f1e>] _raw_spin_lock_irqsave+0x2e/0x70 Jun 16 12:03:34 f6bvp-9 kernel: softirqs last enabled at (76635394): [<ffffffff81329337>] sk_common_release+0x67/0xd0 Jun 16 12:03:34 f6bvp-9 kernel: softirqs last disabled at (76635392): [<ffffffff813f60f6>] _raw_write_lock_bh+0x16/0x50 Jun 16 12:03:34 f6bvp-9 kernel: Jun 16 12:03:34 f6bvp-9 kernel: other info that might help us debug this: Jun 16 12:03:34 f6bvp-9 kernel: 2 locks held by ax25ipd/2813: Jun 16 12:03:34 f6bvp-9 kernel: #0: (big_tty_mutex){+.+.+.}, at: [<ffffffff813f67ce>] tty_lock+0x2e/0x4f Jun 16 12:03:34 f6bvp-9 kernel: #1: (&tty->ldisc_mutex){+.+.+.}, at: [<ffffffff8129d597>] tty_ldisc_hangup+0xe7/0x250 Jun 16 12:03:34 f6bvp-9 kernel: Jun 16 12:03:34 f6bvp-9 kernel: stack backtrace: Jun 16 12:03:34 f6bvp-9 kernel: Pid: 2813, comm: ax25ipd Not tainted 2.6.39.1 #3 Jun 16 12:03:34 f6bvp-9 kernel: Call Trace: Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81092dc0>] print_usage_bug+0x170/0x180 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093a81>] mark_lock+0x211/0x3f0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810948c4>] __lock_acquire+0x5f4/0x14c0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093ccb>] ? mark_held_locks+0x6b/0xa0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f65d0>] ? _raw_spin_unlock_irq+0x30/0x40 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093fcd>] ? trace_hardirqs_on_caller+0x13d/0x180 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81095836>] lock_acquire+0xa6/0x160 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018552b>] ? mkiss_close+0x1b/0x90 [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093ccb>] ? mark_held_locks+0x6b/0xa0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f6221>] _raw_write_lock+0x31/0x40 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018552b>] ? mkiss_close+0x1b/0x90 [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8113775e>] ? kmem_cache_alloc_trace+0x7e/0x140 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss] Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129c84b>] tty_ldisc_close+0x4b/0x70 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129ce90>] tty_ldisc_reinit+0x40/0x80 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129d5b4>] tty_ldisc_hangup+0x104/0x250 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129588c>] __tty_hangup+0x15c/0x3e0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8109401d>] ? trace_hardirqs_on+0xd/0x10 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81295b3e>] tty_vhangup+0xe/0x10 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129f37e>] pty_close+0x10e/0x160 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81295ceb>] tty_release+0x16b/0x640 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8113920a>] ? kmem_cache_free+0x11a/0x160 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81142f9a>] fput+0xea/0x230 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8113ee03>] filp_close+0x63/0x90 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105dab1>] put_files_struct+0x171/0x190 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105d978>] ? put_files_struct+0x38/0x190 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105db22>] exit_files+0x52/0x60 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105deb9>] do_exit+0x189/0x860 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81142cc0>] ? fget+0xd0/0xd0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f69b9>] ? retint_swapgs+0x13/0x1b Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105e5eb>] do_group_exit+0x5b/0xd0 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105e677>] sys_exit_group+0x17/0x20 Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813fe812>] system_call_fastpath+0x16/0x1b Kernel is 2.6.39.1 Is there something wrong in AX25 code or (more unlikely) is this operation not permitted ? Thanks for help. Bernard Pidoux -- 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 [flat|nested] 24+ messages in thread
* [AX25] ipv6 incompatible with AX.25 2011-06-16 20:40 ` f6bvp @ 2022-01-25 11:46 ` Bernard Pidoux 2022-01-25 18:14 ` David Ranch 2022-02-06 21:12 ` [AX25] unreleased sockets after disconnecting Bernard Pidoux , f6bvp 0 siblings, 2 replies; 24+ messages in thread From: Bernard Pidoux @ 2022-01-25 11:46 UTC (permalink / raw) To: linux-hams; +Cc: List for the LINUX version of FBB, fpac, F3KT, F6BVP Hi, Recently installing a new node for kernel rose module debugging (...) I experienced a few connexion troubles. Some are already known AX.25 bug and rose bug that I wanted to investigate taking advantage of kernel Ubuntu 5.4.151 source availability that can be patched and module recompiled. Here is a new feature interfering with AX.25 connexions as displayed in /var/log/syslog : Jan 25 12:16:31 f6bvp-Ubuntu kernel: [ 6942.400016] IPv6: ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready After some investigations I added the following four lines in /etc/sysctl.conf and rebooted : # Disable ipv6 net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.default.disable_ipv6=1 net.ipv6.conf.lo.disable_ipv6=1 Then no more ipv6 are shown by ifconfig and AX25 connexions via LAN are now ok ! enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 44.168.19.21 netmask 255.255.255.240 broadcast 44.168.19.31 ether 00:23:54:8d:41:e9 txqueuelen 1000 (Ethernet) RX packets 44907 bytes 60439240 (60.4 MB) RX errors 0 dropped 53 overruns 0 frame 0 TX packets 16668 bytes 2115347 (2.1 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Looking at my ROSE/FPAC nodes I found that I could perform the same changes on my RaspBerry Pis nodes for better results. I hope this will help and I have a question. Shall this line be uncommented in sysctl.conf ? # Uncomment the next line to enable packet forwarding for IPv4 #net.ipv4.ip_forward=1 I actually have the following in my ax25start script : ax25start:echo 1 > /proc/sys/net/ipv4/ip_forward ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] ipv6 incompatible with AX.25 2022-01-25 11:46 ` [AX25] ipv6 incompatible with AX.25 Bernard Pidoux @ 2022-01-25 18:14 ` David Ranch 2022-01-31 12:04 ` [ROSE] rose socket destination address empty in connect tests Bernard Pidoux , f6bvp [not found] ` <724d87c5-3029-702a-32c9-b64677a2da0e@free.fr> 2022-02-06 21:12 ` [AX25] unreleased sockets after disconnecting Bernard Pidoux , f6bvp 1 sibling, 2 replies; 24+ messages in thread From: David Ranch @ 2022-01-25 18:14 UTC (permalink / raw) To: f6bvp, linux-hams; +Cc: List for the LINUX version of FBB, fpac, F3KT Hey Bernard, When you saw the lines: -- Jan 25 12:16:31 f6bvp-Ubuntu kernel: [ 6942.400016] IPv6: ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready -- was the AX25 interface not up and usable for classic packet regardless of it's IPv6 state? Generally speaking, I had been been disabling IPv6 for the longest time but I've been leaving it enabled as all of us need to start embracing IPv6. Anyway, on my Ubuntu 20.04 machine, I have IPv6 enabled with AX25 interfaces present though I only have a link local address on my primary Ethernet interface (no IPv6 on ax0). It should be noted I do NOT use AXIPv4 and it wouldn't surprised me if AXIPv6 doesn't work. There are a lot of tools in modern Linuxes that don't even support all aspects of AX25, NETROM, ROSE, etc. in modern tools like "ip", etc. Many of us have to resort to installing legacy tools like ifconfig and route to get the job done. -- $ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff altname enp0s31f6 inet 192.168.0.25/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0 valid_lft 66471sec preferred_lft 66471sec inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link valid_lft forever preferred_lft forever 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff altname wlp4s0 4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 11: ax0: <BROADCAST,UP,LOWER_UP> mtu 255 qdisc fq_codel state UNKNOWN group default qlen 10 link/ax25 xx:xx:xx:xx:xx:xx:xx brd a2:a6:a8:40:40:40:00 inet 44.128.0.1/24 scope global ax0 valid_lft forever preferred_lft forever -- > I hope this will help and I have a question. Shall this line be > uncommented in sysctl.conf ? > > # Uncomment the next line to enable packet forwarding for IPv4 > #net.ipv4.ip_forward=1 I question if you really want this on as this should only be enabled if you what your LInux device to be a router (aka.. forwarding packets between one interface and another). This is NOT used if remote stations just want to reach your machine via IP. Fyi, this kernel /proc command alone isn't enough to get routing working. You also need to setup forwarding policies using tools like iptables (legacy) or nftables (newest way). > I actually have the following in my ax25start script : > > ax25start:echo 1 > /proc/sys/net/ipv4/ip_forward Same point as above. --David KI6ZHD ^ permalink raw reply [flat|nested] 24+ messages in thread
* [ROSE] rose socket destination address empty in connect tests 2022-01-25 18:14 ` David Ranch @ 2022-01-31 12:04 ` Bernard Pidoux , f6bvp [not found] ` <724d87c5-3029-702a-32c9-b64677a2da0e@free.fr> 1 sibling, 0 replies; 24+ messages in thread From: Bernard Pidoux , f6bvp @ 2022-01-31 12:04 UTC (permalink / raw) To: David Ranch, linux-hams; +Cc: F3KT [-- Attachment #1: Type: text/plain, Size: 1096 bytes --] I noticed and already reported elsewhere that rose protocol had been broken since kernel 5.4.83. The symptom is a very long delay during some connect requests terminating after a connection timed out. As suggested by David, using "rose_call" utility from ax25tools package, I finally found that the reason of failure is an empty destination address as shown in rose sockets displayed by netstat. By the way, I am glad rose protocol dump patch I committed a while ago is now incorporated into netstat, despite --rose option is still undocumented in netstat manual and help. Only --ax25 and --netrom are documented. In attached file I demonstrate that rose socket destination address is correctly populated when rose_call is used in kernel 5.4.79 but unfortunately the address field is empty in kernel 5.4.83 and following kernels. I added netrom_call for comparison. This explains clearly why connect request stays in a waiting loop with rose protocole ! Now, one has to find where rose socket destination address is erased or forgotten in rose module or libc ! Bernard, f6bvp [-- Attachment #2: Rose_call_comparison.txt --] [-- Type: text/plain, Size: 3079 bytes --] Linux f6bvp-Ubuntu 5.4.0-96-generic #109-Ubuntu SMP Wed Jan 12 16:49:16 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux netrom_call netnod f6bvp f6bvp-14 netrom_call netnod f6bvp f6bvp-2 rose_call rose0 f6bvp f6bvp-4 2080175524 rose_call rose0 f6bvp f6bvp-8 2080175520 netstat --rose --netrom Active NET/ROM sockets at f6bvp-4 (Ubuntu 5.4.0-96) User Dest Source Device State Vr/Vs Send-Q Recv-Q F6BVP-0 F6BVP-14 F6BVP-2 nr0 CONN SENT 000/000 0 0 F6BVP-0 F6BVP-2 F6BVP-2 nr0 ESTABLISHED 000/001 0 0 F6BVP-0 F6BVP-2 F6BVP-2 nr0 ESTABLISHED 001/000 0 0 * * F6BVP-2 nr0 LISTENING 000/000 0 0 * * F6BVP-2 nr0 LISTENING 000/000 0 0 ------------------------------------------------------------------------------ Active ROSE sockets at f6bvp-4 (Ubuntu 5.4.0-96) dest_addr dest_call src_addr src_call dev lci neigh state F6BVP-8 2080175524 F6BVP-0 rose0 1 2 ESTABLISHED F6BVP-4 2080175524 F6BVP-0 rose0 2 1 DISC SENT * 2080175524 FPAD-0 rose0 0 0 LISTENING * 2080175524 ??????-? rose0 0 0 LISTENING ------------------------------------------------------------------------------ rose node f6bvp-4 connected by a rose_call from f6bvp at remote node f6bvp-8 rose_call rose0 f6bvp f6bvp-4 2080175524 rose_call rose0 f6bvp f6bvp-8 2080175520 Active NET/ROM sockets at f6bvp-8 (kernel 5.4.79) User Dest Source Device State Vr/Vs Send-Q Recv-Q * * F6BVP-2 nr0 LISTENING 000/000 0 0 * * F6BVP-2 nr0 LISTENING 000/000 0 0 ------------------------------------------------------------------------------ netrom_call netnod f6bvp BVPN8:f6bvp-14 netrom_call netnod f6bvp BVPN4:F6BVP-2 sockets NET/ROM actives at f6bvp-8 (kernel 5.4.79) Utilisatr Dest Source Periph Etat Vr/Vs Send-Q Recv-Q F6BVP-0 F6BVP-2 F6BVP-14 nr0 CONN SENT 000/000 0 0 F6BVP-0 F6BVP-14 F6BVP-14 nr0 ESTABLISHED 000/001 0 0 F6BVP-0 F6BVP-14 F6BVP-14 nr0 ESTABLISHED 001/000 0 0 * * F6BVP-14 nr0 LISTENING 000/000 0 0 * * F6BVP-14 nr0 LISTENING 000/000 0 0 ------------------------------------------------------------------------------- rose node f6bvp-8 connected by a rose_call from f6bvp-8 rose_call rose0 f6bvp f6bvp-8 2080175520 Active ROSE sockets at f6bvp-8 (kernel 5.4.79) dest_addr dest_call src_addr src_call dev lci neigh state 2080175524 F6BVP-4 2080175520 F6BVP-0 rose0 32 23 ESTABLISHED 2080175520 F6BVP-0 2080175520 F6BVP-8 rose0 31 1 ESTABLISHED * * 2080175520 F6BVP-1 rose0 0 0 LISTENING ------------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <724d87c5-3029-702a-32c9-b64677a2da0e@free.fr>]
* Re: [AX25] ipv6 incompatible with AX.25 [not found] ` <724d87c5-3029-702a-32c9-b64677a2da0e@free.fr> @ 2022-01-31 17:36 ` Bernard Pidoux , f6bvp 0 siblings, 0 replies; 24+ messages in thread From: Bernard Pidoux , f6bvp @ 2022-01-31 17:36 UTC (permalink / raw) To: David Ranch, linux-hams; +Cc: List for the LINUX version of FBB [-- Attachment #1: Type: text/plain, Size: 515 bytes --] Hello David, To answer more precisely your question I prefere to include the listing of an ./ax25up script initializing AX.25 on my Ubuntu PC followed by dmesg and ifconfig messages. Without disabling IPv6 I confirm that my LAN AX.25 was not behaving correctly as I wrote before. It is strange that there are still two messages about IPv6 while Ethernet device had previously been disabled in Ubuntu as shown. Then ifconfig shows that IPv6 is also disabled by command in the script. 73 de Bernard, f6bvp [-- Attachment #2: IPv6.txt --] [-- Type: text/plain, Size: 1383 bytes --] 11.020470] IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0: link becomes ready ....... [ 77.279872] NET: Registered protocol family 3 [ 77.282810] mkiss: AX.25 Multikiss, Hans Albas PE1AYX [ 77.283391] mkiss: ax0: crc mode is auto. [ 77.283542] IPv6: ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready [ 79.303742] NET: Registered protocol family 6 [ 95.504868] mkiss: ax0: Trying crc-smack [ 95.505128] mkiss: ax0: Trying crc-flexnet ./ax25up net.ipv6.conf.all.disable_ipv6 = 1 /bin/rm: cannot remove '/var/ax25/fbb/*.res': No such file or directory Installing ax25ipd Unix98 master pseudo tty Installing a KISS link on ethernet port Port axudp attached to ax0 Starting NetRom... Init Netrom NET/ROM port netnod bound to device nr0 NET: Registered protocol family 3 [ 65.032811] mkiss: AX.25 Multikiss, Hans Albas PE1AYX [ 65.033552] mkiss: ax0: crc mode is auto. [ 65.033739] IPv6: ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready [ 67.060544] NET: Registered protocol family 6 [ 83.265806] mkiss: ax0: Trying crc-smack [ 83.265970] mkiss: ax0: Trying crc-flexnet ax0: flags=67<UP,BROADCAST,RUNNING> mtu 253 ax25 F6BVP-4 txqueuelen 10 (AMPR AX.25) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 6 bytes 307 (307.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [AX25] unreleased sockets after disconnecting 2022-01-25 11:46 ` [AX25] ipv6 incompatible with AX.25 Bernard Pidoux 2022-01-25 18:14 ` David Ranch @ 2022-02-06 21:12 ` Bernard Pidoux , f6bvp 2022-02-20 9:18 ` Thomas Osterried 1 sibling, 1 reply; 24+ messages in thread From: Bernard Pidoux , f6bvp @ 2022-02-06 21:12 UTC (permalink / raw) To: linux-hams [-- Attachment #1: Type: text/plain, Size: 610 bytes --] For long time it as been reported by many AX.25 users that connexions were precluded after terminating a connexion with a remote station. Some hamradio maintainers have been pretending not to be aware of such issue for lacking proofs. I must restart my packet radio FPAC node (AX.25, ROSE and NetRom protocoles) every other hour in order to let connexions available again for neighbours. Here are some evidence from cat /proc/net/ax25 showing old remnants of connexions presumably there for ax25 sockets were not released. 73 de Bernard, f6bvp http://radiotelescope-lavillette.fr/ http://f6bvp.org [-- Attachment #2: proc_net_ax25.txt --] [-- Type: text/plain, Size: 18868 bytes --] pi@F6BVP-8:~ $ cat /proc/net/ax25 5003cece ax0 F6BVP-14 CT1ENI-8 3 0 0 0 0 10 0 3 289 300 0 0 0 10 5 2 256 * * * 6cc44439 ax0 F6BVP-8* F6BVP-1,F6BVP-8* 1 0 0 0 34 40 0 3 0 300 0 0 3 10 5 2 256 0 0 146395 f5133389 ax0 F6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 150738 d66d172a ax0 F6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 150177 69126716 ax0 F6BVP-9 F6BVP-7 3 5 6 5 0 7 0 3 208 300 0 0 0 10 3 2 256 * * * b369f029 ax0 F6BVP-9 VE3XPG-9 1 0 0 0 46 50 0 3 0 300 0 0 4 10 5 2 256 * * * 766f8f9e ax0 F6BVP-9 K4GBB-9 1 0 0 0 46 50 0 3 0 300 0 0 4 10 5 2 256 * * * 6a2b78e8 ax0 F6BVP-9 F6KKR-9 3 3 4 3 0 7 0 3 204 300 0 0 0 10 3 2 256 * * * b421ffed ax0 F6BVP-9 F6CNB-9 1 0 0 0 46 50 0 3 0 300 0 0 4 10 5 2 256 * * * a9bcab73 ax0 F6BVP-9 F3KT-11 3 3 3 3 0 7 0 3 204 300 0 0 0 10 3 2 256 * * * cd3ca2e2 ax0 F6BVP-9 F5KTR-11 3 3 3 3 0 7 0 3 204 300 0 0 0 10 3 2 256 * * * b2786e19 ax0 F6BVP-9 F6BVP-11 3 6 6 6 0 7 0 3 208 300 0 0 0 10 3 2 256 * * * e76acc60 ax0 F6BVP-9 F6CNB-11 1 0 0 0 46 50 0 3 0 300 0 0 4 10 5 2 256 * * * b7916c4d ax0 F6BVP-9 F6BVP-5 1 0 0 0 46 50 0 3 0 300 0 0 4 10 5 2 256 * * * c524e5e2 ax0 F6BVP-9 SV2HRT-9 3 3 4 3 0 7 0 3 206 300 0 0 0 10 3 2 256 * * * 37e9dec5 ax0 F6BVP-9 NA7KR-9 1 0 0 0 46 50 0 3 0 300 0 0 4 10 5 2 256 * * * 5df12c98 ??? F6BVP-15* * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 146297 5c22f399 ??? F6BVP-15 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 146296 12b99fab ??? F6BVP-8 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 150118 f8390732 ??? F6BVP-8* * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 150117 da72643f ??? F6BVP-9* * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 150116 8bcdc6af ax0 F6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 147235 2f401d3f ??? F6BVP-9 F3KT-11 0 7 3 7 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 25d1fc26 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 2e9a4094 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 9e33e87e ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * bb7f5961 ??? F6BVP-9 SV2HRT-9 0 5 2 5 0 5 0 3 0 300 0 0 0 10 2 2 256 * * * f1ffdabd ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * bc41856c ??? F6BVP-9 F6BVP-7 0 0 0 0 0 5 0 3 0 300 0 0 0 10 2 2 256 * * * 815fc9a0 ??? F6BVP-9 F6BVP-11 0 3 2 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * db5a5ecd ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 2b4612f8 ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 0c01c5a6 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 1454c25e ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * ee032b7b ??? F6BVP-9 F6KKR-9 0 5 7 5 0 6 0 3 0 300 0 0 0 10 3 2 256 * * * 29e476ec ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * f64f0c0a ??? F6BVP-9 F3KT-11 0 7 3 7 0 3 0 3 0 300 0 0 0 10 1 2 256 * * * a141c42b ??? F6BVP-9 F5KTR-11 0 7 7 7 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 236bd0e7 ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * * 1cdabd88 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 329a294b ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * ad7d5817 ??? F6BVP-9 SV2HRT-9 0 1 3 1 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 3faef81e ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 2c1200f5 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * a4e01182 ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 7c8bfddd ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 91a654b0 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * aae8b3c0 ??? F6BVP-9 F6KKR-9 0 4 6 4 0 7 0 3 0 300 0 0 0 10 3 2 256 * * * ac2c0d0b ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 7102605f ??? F6BVP-9 F3KT-11 0 6 1 6 0 3 0 3 0 300 0 0 0 10 1 2 256 * * * 09da8a86 ??? F6BVP-9 F5KTR-11 0 5 5 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 32e82168 ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * * e2ab507d ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 5f5ab697 ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 4e11b6d2 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 5 0 3 0 300 0 0 0 10 2 2 256 * * * 580ca5d8 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * c4fb6d80 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * e5b82c26 ??? F6BVP-9 F6BVP-7 0 3 2 3 0 3 0 3 0 300 0 0 0 10 1 2 256 * * * 787f7d2a ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * f4cf53af ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * fbc448d8 ??? F6BVP-9 F6KKR-9 0 4 6 4 0 7 0 3 0 300 0 0 0 10 3 2 256 * * * 205a459b ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 7427f903 ??? F6BVP-9 F3KT-11 0 0 3 0 0 3 0 3 0 300 0 0 0 10 1 2 256 * * * 6e8f2c70 ??? F6BVP-9 F5KTR-11 0 6 6 6 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 333b1672 ??? F6BVP-9 F6BVP-11 0 4 4 4 0 8 0 3 0 300 0 0 0 10 4 2 256 * * * 57a731d5 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 4a62dd32 ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 1ad9c71b ??? F6BVP-9 SV2HRT-9 0 1 3 1 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * fe8b8732 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * e40a2287 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 9f399c0e ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 17691e12 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * d057ea1f ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 7fdddaf1 ??? F6BVP-9 F6KKR-9 0 5 7 5 0 6 0 3 0 300 0 0 0 10 3 2 256 * * * 0838d276 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 56f94d7c ??? F6BVP-9 F3KT-11 0 5 1 5 0 3 0 3 0 300 0 0 0 10 1 2 256 * * * 87bfd797 ??? F6BVP-9 F5KTR-11 0 3 3 3 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 92c1daa6 ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * * 8e7b67d3 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * cbda6426 ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 43c3ba0f ??? F6BVP-9 SV2HRT-9 0 5 6 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * f8496df4 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 179ad97f ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 0db4eb8a ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 2b286aed ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 22b2e8d3 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * c6a97925 ??? F6BVP-9 F6KKR-9 0 4 6 4 0 6 0 3 0 300 0 0 0 10 3 2 256 * * * 81bb2072 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * e24ffe27 ??? F6BVP-9 F3KT-11 0 4 0 4 0 3 0 3 0 300 0 0 0 10 1 2 256 * * * 011fdac8 ??? F6BVP-9 F5KTR-11 0 7 7 7 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 2c233acb ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * * 28f0eef0 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * a13dbae2 ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * caa16fa8 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 38014152 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 981df63d ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * f5e00e0f ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * fc0f242f ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 3cca8e30 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 17cbd0be ??? F6BVP-9 F6KKR-9 0 4 6 4 0 7 0 3 0 300 0 0 0 10 3 2 256 * * * c5088ba1 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 9baa33fc ??? F6BVP-9 F3KT-11 0 3 0 3 0 3 0 3 0 300 0 0 0 10 1 2 256 * * * 819d4eb9 ??? F6BVP-9 F5KTR-11 0 3 0 3 0 3 0 3 0 300 0 0 0 10 1 2 256 * * * d2b68e0d ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * * ddfa546c ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * b0f953bc ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * b8a94f0e ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * a8f267fb ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * b8bf7081 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * c14eee27 ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 41bcde27 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 342b49e7 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 0832dbdf ??? F6BVP-9 F6KKR-9 0 5 7 5 0 6 0 3 0 300 0 0 0 10 3 2 256 * * * 97376b88 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * a53b0ac2 ??? F6BVP-9 F3KT-11 0 5 2 5 0 3 0 3 0 300 0 0 0 10 1 2 256 * * * 5e77d1d0 ??? F6BVP-9 F5KTR-11 0 7 7 7 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * f895195f ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * * d76b4443 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * c225807b ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * fed88d20 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 9aff6a70 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * f4b09f9f ??? F6BVP-9 F3KT-11 0 5 2 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * a32d1e88 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 6fbf5998 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 1ef30ff2 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 34a12cea ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 0a40cbd9 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * fc1ba6af ??? F6BVP-9 F6BVP-7 0 0 0 0 0 5 0 3 0 300 0 0 0 10 2 2 256 * * * 349f44e1 ??? F6BVP-9 F6BVP-11 0 3 2 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * e41aab46 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * e0ece209 ??? F6BVP-9 F6BVP-7 0 3 2 3 0 3 0 3 0 300 0 0 0 10 1 2 256 * * * 3b7d9f0c ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * b7f26df3 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * eb70a53f ??? F6BVP-9 F6KKR-9 0 5 7 5 0 6 0 3 0 300 0 0 0 10 3 2 256 * * * c08704c9 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * e0389589 ??? F6BVP-9 F3KT-11 0 0 3 0 0 3 0 3 0 300 0 0 0 10 1 2 256 * * * 32d9a149 ??? F6BVP-9 F5KTR-11 0 0 6 0 0 0 0 3 0 300 0 0 0 10 0 2 256 * * * 81b23fa0 ??? F6BVP-9 F6BVP-11 0 4 4 4 0 9 0 3 0 300 0 0 0 10 4 2 256 * * * 630884e1 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * ca370221 ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * ba7bc312 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * c5bad46d ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * d9da749f ??? F6BVP-9 F3KT-11 0 6 3 6 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 18fa6edb ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 9a6662c2 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 160cde41 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 29ed5a63 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * dbbb85f3 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 1b52032c ??? F6BVP-9 F6BVP-11 0 6 6 6 0 6 0 3 0 300 0 0 0 10 3 2 256 * * * d2e88f83 ??? F6BVP-9 F6BVP-7 0 0 7 0 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 1261ac60 ??? F6BVP-14 F3KT-12 0 0 1 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 2656b02d ??? F6BVP-9 SV1HCC-9 0 0 2 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * c6c095ab ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * d7aed580 ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 1464b07c ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 6168a84f ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * fd05f264 ??? F6BVP-9 F6KKR-9 0 4 6 4 0 7 0 3 0 300 0 0 0 10 3 2 256 * * * 41e07126 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * b8702c35 ??? F6BVP-9 F3KT-11 0 6 7 6 0 2 0 3 0 300 0 0 0 10 1 2 256 * * * 66c54f7d ??? F6BVP-9 F5KTR-11 0 6 7 6 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * f016d485 ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * * 85b42058 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * d4cd2eaa ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 7f389c3c ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 0107be95 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * d88d3b3e ??? F6BVP-9 F3KT-11 0 5 2 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * d6dd98e6 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 675ad4a5 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 10508c69 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 3cb64e7f ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 06448390 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 75f99020 ??? F6BVP-9 F6BVP-7 0 0 0 0 0 5 0 3 0 300 0 0 0 10 2 2 256 * * * b09fa08b ??? F6BVP-9 F6BVP-11 0 2 2 1 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 91ae7293 ??? F6BVP-9 F3KT-11 0 6 3 6 0 5 0 3 0 300 0 0 0 10 1 2 256 * * * 889bb771 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * eb011bee ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 4b1f807e ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 6125892f ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 941f47b0 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * ecd2734d ??? F6BVP-9 F6BVP-7 0 7 7 7 0 1 0 3 0 300 0 0 0 10 0 2 256 * * * 52c7dcf8 ??? F6BVP-9 F6BVP-11 0 3 2 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 060f21d8 ??? F6BVP-9 F3KT-11 0 5 2 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 44caff01 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 8099c5f8 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * f359beb8 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 134f8d50 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 7fe32198 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 1ea2ecbe ??? F6BVP-9 F6BVP-7 0 0 0 0 0 5 0 3 0 300 0 0 0 10 2 2 256 * * * 834fa3d0 ??? F6BVP-9 F6BVP-11 0 2 2 1 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 34ece46f ??? F6BVP-9 F3KT-11 0 5 2 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 0dfb3266 ??? F6BVP-9 F6KKR-9 0 1 1 1 0 6 0 3 0 300 0 0 0 10 3 2 256 * * * 94c93b07 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 432f60fa ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * db00d30e ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 2e751dfe ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * db386684 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * bf737dfe ??? F6BVP-9 F6BVP-7 0 3 4 3 0 5 0 3 0 300 0 0 0 10 2 2 256 * * * 836d3f41 ??? F6BVP-9 F6BVP-11 0 3 2 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 6fb25b79 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 5357051b ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * ca09254d ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * cb81c016 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 9bb1b538 ??? F6BVP-9 F6KKR-9 0 5 6 5 0 5 0 3 0 300 0 0 0 10 2 2 256 * * * 8b88c1a1 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 0f7dbb2e ??? F6BVP-9 F3KT-11 0 4 0 4 0 3 0 3 0 300 0 0 0 10 1 2 256 * * * 74c6ea65 ??? F6BVP-9 F5KTR-11 0 5 5 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * fa7e1029 ??? F6BVP-9 F6BVP-11 0 7 6 6 0 6 0 3 0 300 0 0 0 10 3 2 256 * * * 20168113 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 8156ed6c ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 5d657704 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * da5c3ca8 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 8e447fe2 ??? F6BVP-14 G1GXB-10 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * ee72bea4 ??? F6BVP-14 CT1ENI-8 0 0 6 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 114816ce ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * aca3f37c ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * e02c8339 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 280308c6 ??? F6BVP-9 F6KKR-9 0 5 7 5 0 6 0 3 0 300 0 0 0 10 3 2 256 * * * 55370f0d ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * da367dc2 ??? F6BVP-9 F3KT-11 0 5 2 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * ac6f0248 ??? F6BVP-9 F5KTR-11 0 4 5 4 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * 55e140aa ??? F6BVP-9 F6BVP-11 0 7 6 6 0 6 0 3 0 300 0 0 0 10 3 2 256 * * * b5e7d48c ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * e195779f ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 91a8f1b1 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 5c998a3e ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 9d9c3799 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 427e912a ??? F6BVP-9 F5KTR-11 0 4 5 4 0 8 0 3 0 300 0 0 0 10 4 2 256 * * * 5885374e ??? F6BVP-9 F3KT-11 0 6 4 6 0 5 0 3 0 300 0 0 0 10 2 2 256 * * * c7cd8534 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * * 40f74703 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * effabcd9 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 20fea5d5 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 59cbd839 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 1a92eda8 ??? F6BVP-9 F6BVP-7 0 0 7 0 0 1 0 3 0 300 0 0 0 10 0 2 256 * * * 3062b2fa ??? F6BVP-9 F6BVP-11 0 3 2 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * * d8a3dcfd ??? F6BVP-14 CT1ENI-8 0 0 0 0 0 90 0 3 0 300 0 0 8 10 5 2 256 * * * 658e7e31 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 222589d0 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 78ceae6f ??? F6BVP-9 F6KKR-9 0 6 4 4 0 77 0 3 0 300 0 0 10 10 3 2 256 * * * 1f46d0f6 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 90ceefe7 ??? F6BVP-9 F3KT-11 0 5 1 3 0 68 0 3 0 300 0 0 10 10 3 2 256 * * * 94b532f7 ??? F6BVP-9 F5KTR-11 0 6 5 4 0 77 0 3 0 300 0 0 10 10 3 2 256 * * * 85e79959 ??? F6BVP-9 F6BVP-11 0 3 4 3 0 6 0 3 0 300 0 0 0 10 3 2 256 * * * af5671b0 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * e0308fce ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 322a8470 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * 3958cc59 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * * ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] unreleased sockets after disconnecting 2022-02-06 21:12 ` [AX25] unreleased sockets after disconnecting Bernard Pidoux , f6bvp @ 2022-02-20 9:18 ` Thomas Osterried 0 siblings, 0 replies; 24+ messages in thread From: Thomas Osterried @ 2022-02-20 9:18 UTC (permalink / raw) To: Bernard Pidoux , f6bvp; +Cc: linux-hams > Am 06.02.2022 um 22:12 schrieb Bernard Pidoux , f6bvp <f6bvp@free.fr>: > > For long time it as been reported by many AX.25 users that connexions were precluded after terminating a connexion with a remote station. > > Some hamradio maintainers have been pretending not to be aware of such issue for lacking proofs. The problem is known. Iirc correctly, we have seen some approaches over the years to fix this issue. The last one I'd like to discuss is by YO2LOJ (Subject "NET/ROM bug fix from YO2LOJ?" in this list): That patch is against the problem, that disconnected sessions still are listet, in "LISTENING" state'. I'm not sure if it is exactly your problem, because in your /proc/net/ax25 example, those sessions seem to belong to iface "???" instead of "ax0". I can reproduce (testet last week) is the following: boot configure ax25 iface no userspace process started connect from outside disconnect from outside -> netstat --ax25 shows that session in LISTEN state. In contrast to your output, it refers to the interface (not to "???"). The problem with the patch is, we observed a new, in my opinion unliked, behavior: now a new connection is disconnected instantly (as long as no userspace daemon is listening). But there are protocols like "IP mode VC" need to be able to connect, even when no userspace daemon is running. > I must restart my packet radio FPAC node (AX.25, ROSE and NetRom protocoles) every other hour in order to let connexions available again for neighbours. Perhaps you could try YO2LOJ's kernel patch and test if it helps for your urgent problem, or if there's another problem in the session-cleanup code. > Here are some evidence from cat /proc/net/ax25 showing old remnants of connexions presumably there for ax25 sockets were not released. > > 73 de Bernard, f6bvp vy 73, - Thomas dl9sau ^ permalink raw reply [flat|nested] 24+ messages in thread
* Question with axudp 2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski ` (2 preceding siblings ...) 2011-06-16 20:40 ` f6bvp @ 2011-07-07 13:31 ` Bernard, f6bvp 2011-07-07 21:43 ` Robert Thoelen 3 siblings, 1 reply; 24+ messages in thread From: Bernard, f6bvp @ 2011-07-07 13:31 UTC (permalink / raw) To: Robert Thoelen; +Cc: linux-hams Hello Robert, You have probably noticed that you can define different routes in ax25ipd.conf according to SSIDs values with SSID zero as a wild card, i.e. all SSIDs destinations will be routed via this address. For example : # route f6bvp-9 192.168.0.64 udp 10094 b route f6bvp-8 192.168.0.64 udp 10094 route f6bvp-14 192.168.0.64 udp 10094 # F4BWT-0 = joker route f4bwt-0 62.147.157.243 udp 10093 b route kd4yal-0 kd4yal.servebbs.org udp 10093 b route f6gov-0 f6gov.no-ip.org udp 10093 b Note that parameter b will allow NetRom broadcast through this route. You may also play with the verbose and min_obs parameter values in /etc/ax25/nrbroadcast With min_obs equal to 255 and verbose = 0 for a specific HF port there will be minimal broadcast. 73 de Bernard, f6bvp > List: linux-hams > Subject: Question with axudp > From: Robert Thoelen <kd1zd () rtcubed ! org> > Date: 2011-07-05 23:30:55 > Message-ID: CAAynhLMhGVDiVsAugsWSOLTRkrw6OeXRYeyKJEdUVaHMmE0rZQ () mail ! gmail ! com I have a system running UROnode, and I have a couple of internet links. I want to create a virtual machine in a data center to run UROnode and have my internet axudp links connect to that system. Then, I can use one connection from my home station via axudp to connect to the virtual machine. The purpose behind this is among other reasons to keep netrom broadcasts from cluttering my RF node. Anyway, the virtual machine seems to be working well and is broadcasting its netrom node to the home system. I'm having trouble getting the home system to send packets back to the virtual machine. My question is: if I use a few ssids with my callsign, will that cause ax25ipd from routing another ssid with my call? The virtual machine is kd1zd-9, and the home system uses kd1zd-3 to kd1zd-7. What could be causing the home system to not send packets out to the virtual machine? The other axudp links in the .conf file work fine. Thanks, Bob ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Question with axudp 2011-07-07 13:31 ` Question with axudp Bernard, f6bvp @ 2011-07-07 21:43 ` Robert Thoelen 0 siblings, 0 replies; 24+ messages in thread From: Robert Thoelen @ 2011-07-07 21:43 UTC (permalink / raw) To: linux-hams I've got beyond my problem of my system not sending out packets. The trouble I have now is that people can connect to my node, which only has one link. When I or they try to connect to another station off of it, we get disconnected. For example, if my station is "A", the node I setup is "B", and another person linking on the internet is "C", both "A" and "C" can connect to "B", but when trying to connect beyond "B", a disconnect occurs. I've tried using "listen" to see if there are any clues, but I can't see any. On Thu, Jul 7, 2011 at 9:31 AM, Bernard, f6bvp <f6bvp@free.fr> wrote: > Hello Robert, > > You have probably noticed that you can define different routes in > ax25ipd.conf according to SSIDs values with SSID zero as a wild card, i.e. > all SSIDs destinations will be routed via this address. For example : > > # > route f6bvp-9 192.168.0.64 udp 10094 b > route f6bvp-8 192.168.0.64 udp 10094 > route f6bvp-14 192.168.0.64 udp 10094 > # F4BWT-0 = joker > route f4bwt-0 62.147.157.243 udp 10093 b > route kd4yal-0 kd4yal.servebbs.org udp 10093 b > route f6gov-0 f6gov.no-ip.org udp 10093 b > > Note that parameter b will allow NetRom broadcast through this route. > > You may also play with the verbose and min_obs parameter values in > /etc/ax25/nrbroadcast > With min_obs equal to 255 and verbose = 0 for a specific HF port there will > be minimal broadcast. > > 73 de Bernard, f6bvp > > >> List: linux-hams >> Subject: Question with axudp >> From: Robert Thoelen <kd1zd () rtcubed ! org> >> Date: 2011-07-05 23:30:55 >> Message-ID: CAAynhLMhGVDiVsAugsWSOLTRkrw6OeXRYeyKJEdUVaHMmE0rZQ () mail ! >> gmail ! com > > I have a system running UROnode, and I have a couple of internet > links. I want to create a virtual machine in a data center to run > UROnode and have my internet axudp links connect to that system. > Then, I can use one connection from my home station via axudp to > connect to the virtual machine. The purpose behind this is among > other reasons to keep netrom broadcasts from cluttering my RF node. > > Anyway, the virtual machine seems to be working well and is > broadcasting its netrom node to the home system. I'm having trouble > getting the home system to send packets back to the virtual machine. > > My question is: if I use a few ssids with my callsign, will that > cause ax25ipd from routing another ssid with my call? The virtual > machine is kd1zd-9, and the home system uses kd1zd-3 to kd1zd-7. > > What could be causing the home system to not send packets out to the > virtual machine? The other axudp links in the .conf file work fine. > > Thanks, > Bob > -- Robert Thoelen, III KD1ZD Station phone: (860) 849-1101 Check out the KD1ZD Amateur TCP/IP Radio page at http://www.rtcubed.org/kd1zd -- 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 [flat|nested] 24+ messages in thread
end of thread, other threads:[~2022-02-20 9:18 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4B2CD772.1030106@upmc.fr>
[not found] ` <4B2D1025.1020106@gmail.com>
[not found] ` <4B2E6729.1090102@free.fr>
[not found] ` <4B507FAA.8010007@free.fr>
2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski
2010-01-16 9:04 ` David Miller
2011-06-16 20:23 ` [AX25] inconsistent lock state f6bvp
2011-06-17 13:28 ` Ralf Baechle
2011-06-17 13:36 ` Arnd Bergmann
2011-06-17 13:51 ` Ralf Baechle
2011-06-17 14:11 ` Arnd Bergmann
2011-06-17 15:31 ` f6bvp
2011-06-25 15:51 ` f6bvp
2011-06-25 16:39 ` Ralf Baechle DL5RB
2011-07-01 13:00 ` Bernard F6BVP
2011-07-01 21:28 ` [PATCH] 6pack,mkiss: fix lock inconsistency Arnd Bergmann
2011-07-02 0:30 ` David Miller
2012-10-21 15:18 ` [NetRom] possible circular locking dependency detected Bernard f6bvp
2011-06-17 15:26 ` [AX25] inconsistent lock state f6bvp
2011-06-16 20:40 ` f6bvp
2022-01-25 11:46 ` [AX25] ipv6 incompatible with AX.25 Bernard Pidoux
2022-01-25 18:14 ` David Ranch
2022-01-31 12:04 ` [ROSE] rose socket destination address empty in connect tests Bernard Pidoux , f6bvp
[not found] ` <724d87c5-3029-702a-32c9-b64677a2da0e@free.fr>
2022-01-31 17:36 ` [AX25] ipv6 incompatible with AX.25 Bernard Pidoux , f6bvp
2022-02-06 21:12 ` [AX25] unreleased sockets after disconnecting Bernard Pidoux , f6bvp
2022-02-20 9:18 ` Thomas Osterried
2011-07-07 13:31 ` Question with axudp Bernard, f6bvp
2011-07-07 21:43 ` Robert Thoelen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).