* kernel BUG at kernel/timer.c:951! @ 2009-12-19 13:38 Bernard Pidoux 2009-12-19 17:40 ` Jarek Poplawski 0 siblings, 1 reply; 37+ messages in thread From: Bernard Pidoux @ 2009-12-19 13:38 UTC (permalink / raw) To: linux-kernel, Linux Netdev List, David S. Miller, Bernard Pidoux [-- Attachment #1: Type: text/plain, Size: 1277 bytes --] I am experiencing a few kernel panics on my Linux system using 2.6.32 and 2.6.32.1 kernels with nosmp. Linux f6bvp-11 2.6.32.1-nosmp #4 Tue Dec 15 23:13:28 CET 2009 x86_64 Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz GNU/Linux Gnu C 4.3.2 Gnu make 3.81 binutils 2.19.51.0.2.20090204 util-linux 2.14.1 mount support module-init-tools 3.6 e2fsprogs 1.41.4 PPP 2.4.4 Linux C Library 2.9 Dynamic linker (ldd) 2.9 Procps 3.2.7 Net-tools 1.60 Kbd 1.15 Sh-utils 7.1 Modules Loaded netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 binfmt_misc loop ext3 jbd snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd i2c_viapro 8139cp i2c_core floppy sg sr_mod shpchp 8139too rtc_cmos soundcore pci_hotplug button via_agp mii evdev pata_via ata_generic ide_pci_generic sata_via libata sd_mod scsi_mod crc_t10dif The last kernel panic is reporting a kernel BUG at kernel/timer.c:951! Bernard Pidoux [-- Attachment #2: nc_u_l_p_6666 --] [-- Type: text/plain, Size: 21881 bytes --] ------------------------------- general protection fault: 0000 [#1] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq CPU 0 Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd soundcore shpchp 8139cp 8139too pci_hotplug sr_mod i2c_viapro i2c_core mii ipv6 binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table rtc_cmos floppy processor thermal via_agp button evdev sg pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif Pid: 0, comm: swapper Not tainted 2.6.32-nosmp #1 MS-7258 RIP: 0010:[<ffffffff81057c16>] [<ffffffff81057c16>] run_timer_softirq+0x176/0x300 RSP: 0018:ffffffff814fbe70 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff880049c6f040 RCX: 1bc0000000000000 RDX: ffffffff814fbeb0 RSI: 3a75ffe60e489c6f RDI: ffff880049c6f000 RBP: ffffffff814fbef0 R08: de00000000000000 R09: ffff880049c6f040 R10: ffffffff81506e60 R11: 0000000000000000 R12: ffffffff81610268 R13: ffffffff816104c0 R14: ffffffff814fbeb0 R15: ff0000fb001001f0 FS: 0000000000000000(0000) GS:ffffffff814f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00007f34976aa000 CR3: 000000002cbd4000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffffffff814da000, task ffffffff814ece40) Stack: ffffffff814dbfd8 ffffffff814dbfd8 00000100810178c6 ffff880049c6f000 <0> ffffffff816120d8 ffffffff81611cd8 ffffffff816118d8 ffffffff816114d8 <0> ffffffff814fbeb0 ffffffff814fbeb0 ffffffff81027d98 ffffffff814dbfd8 Call Trace: <IRQ> [<ffffffff81027d98>] ? lapic_next_event+0x18/0x20 [<ffffffff8104f642>] __do_softirq+0xd2/0x1b0 [<ffffffff81011e0a>] call_softirq+0x1a/0x30 [<ffffffff81013b55>] do_softirq+0x65/0xa0 [<ffffffff8104f22d>] irq_exit+0x3d/0x50 [<ffffffff81028869>] smp_apic_timer_interrupt+0x59/0x90 [<ffffffff81011933>] apic_timer_interrupt+0x13/0x20 <EOI> [<ffffffff81018880>] ? mwait_idle+0x80/0xc0 [<ffffffff81068851>] ? atomic_notifier_call_chain+0x11/0x20 [<ffffffff8101012c>] ? cpu_idle+0x8c/0xb0 [<ffffffff8135cfcb>] ? rest_init+0x5b/0x70 [<ffffffff8155bc9d>] ? start_kernel+0x3a6/0x46f [<ffffffff8155b2b9>] ? x86_64_start_reservations+0x99/0xb9 [<ffffffff8155b3df>] ? x86_64_start_kernel+0x106/0x121 [<ffffffff8155b140>] ? early_idt_handler+0x0/0x71 Code: 4c 8b 25 4e 62 4f 00 4d 85 e4 74 1b 49 8b 04 24 0f 1f 44 00 00 49 83 c4 08 48 89 df ff d0 49 8b 04 24 48 85 c0 75 ee 48 8b 7d 98 <41> ff d7 8b 05 49 62 4f 00 85 c0 74 27 4c 8b 25 56 62 4f 00 4d RIP [<ffffffff81057c16>] run_timer_softirq+0x176/0x300 RSP <ffffffff814fbe70> ---[ end trace b7400eefcee63331 ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 0, comm: swapper Tainted: G D 2.6.32-nosmp #1 Call Trace: <IRQ> [<ffffffff813640ab>] panic+0xa0/0x172 [<ffffffff812cf8c2>] ? __kfree_skb+0x42/0xb0 [<ffffffff810117d3>] ? ret_from_intr+0x0/0x10 [<ffffffff812cf8c2>] ? __kfree_skb+0x42/0xb0 [<ffffffff81014ea5>] ? oops_end+0xc5/0xe0 [<ffffffff81014eac>] oops_end+0xcc/0xe0 [<ffffffff81015076>] die+0x56/0x90 [<ffffffff81013138>] do_general_protection+0x158/0x160 [<ffffffff81366665>] general_protection+0x25/0x30 [<ffffffff81057c16>] ? run_timer_softirq+0x176/0x300 [<ffffffff81027d98>] ? lapic_next_event+0x18/0x20 [<ffffffff8104f642>] __do_softirq+0xd2/0x1b0 [<ffffffff81011e0a>] call_softirq+0x1a/0x30 [<ffffffff81013b55>] do_softirq+0x65/0xa0 [<ffffffff8104f22d>] irq_exit+0x3d/0x50 [<ffffffff81028869>] smp_apic_timer_interrupt+0x59/0x90 [<ffffffff81011933>] apic_timer_interrupt+0x13/0x20 <EOI> [<ffffffff81018880>] ? mwait_idle+0x80/0xc0 [<ffffffff81068851>] ? atomic_notifier_call_chain+0x11/0x20 [<ffffffff8101012c>] ? cpu_idle+0x8c/0xb0 [<ffffffff8135cfcb>] ? rest_init+0x5b/0x70 [<ffffffff8155bc9d>] ? start_kernel+0x3a6/0x46f [<ffffffff8155b2b9>] ? x86_64_start_reservations+0x99/0xb9 [<ffffffff8155b3df>] ? x86_64_start_kernel+0x106/0x121 [<ffffffff8155b140>] ? early_idt_handler+0x0/0x71 Rebooting in 60 seconds.. ------------------------------- ------------------------------- BUG: unable to handle kernel paging request at 00000000000075d0 IP: [<00000000000075d0>] 0x75d0 PGD 67cf2067 PUD 78b65067 PMD 0 Thread overran stack, or stack corrupted Oops: 0000 [#1] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq CPU 0 Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd 8139cp i2c_viapro 8139too shpchp soundcore i2c_core pci_hotplug mii sr_mod binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table floppy rtc_cmos processor via_agp button thermal evdev sg pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif Pid: 0, comm: swapper Not tainted 2.6.32-nosmp #1 MS-7258 RIP: 0010:[<00000000000075d0>] [<00000000000075d0>] 0x75d0 RSP: 0018:ffffffff814fbe68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff880003842618 RCX: 1080000000000000 RDX: ffff8800666ba910 RSI: 0a9dfff79ef83842 RDI: 0000000000000000 RBP: ffffffff814fbef0 R08: 8400000000000000 R09: ffff880003842618 R10: ffffffff81506e60 R11: 0000000000000000 R12: ffffffff81610268 R13: ffffffff816104c0 R14: ffffffff814fbeb0 R15: 00000000000075d0 FS: 0000000000000000(0000) GS:ffffffff814f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00000000000075d0 CR3: 0000000067cce000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffffffff814da000, task ffffffff814ece40) Stack: ffffffff81057c19 ffffffff814dbfd8 ffffffff814dbfd8 00000100810178c6 <0> 0000000000000000 ffffffff816120d8 ffffffff81611cd8 ffffffff816118d8 <0> ffffffff816114d8 ffff8800666ba910 ffff8800666ba910 ffffffff81027d98 Call Trace: <IRQ> [<ffffffff81057c19>] ? run_timer_softirq+0x179/0x300 [<ffffffff81027d98>] ? lapic_next_event+0x18/0x20 [<ffffffff8104f642>] __do_softirq+0xd2/0x1b0 [<ffffffff81011e0a>] call_softirq+0x1a/0x30 [<ffffffff81013b55>] do_softirq+0x65/0xa0 [<ffffffff8104f22d>] irq_exit+0x3d/0x50 [<ffffffff81028869>] smp_apic_timer_interrupt+0x59/0x90 [<ffffffff81011933>] apic_timer_interrupt+0x13/0x20 <EOI> [<ffffffff81018880>] ? mwait_idle+0x80/0xc0 [<ffffffff81068851>] ? atomic_notifier_call_chain+0x11/0x20 [<ffffffff8101012c>] ? cpu_idle+0x8c/0xb0 [<ffffffff8135cfcb>] ? rest_init+0x5b/0x70 [<ffffffff8155bc9d>] ? start_kernel+0x3a6/0x46f [<ffffffff8155b2b9>] ? x86_64_start_reservations+0x99/0xb9 [<ffffffff8155b3df>] ? x86_64_start_kernel+0x106/0x121 [<ffffffff8155b140>] ? early_idt_handler+0x0/0x71 Code: Bad RIP value. RIP [<00000000000075d0>] 0x75d0 RSP <ffffffff814fbe68> CR2: 00000000000075d0 ---[ end trace 1d821a4ff312041a ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 0, comm: swapper Tainted: G D 2.6.32-nosmp #1 Call Trace: <IRQ> [<ffffffff813640ab>] panic+0xa0/0x172 [<ffffffff812cf8c2>] ? __kfree_skb+0x42/0xb0 [<ffffffff810117d3>] ? ret_from_intr+0x0/0x10 [<ffffffff81014e3a>] ? oops_end+0x5a/0xe0 [<ffffffff81014eac>] oops_end+0xcc/0xe0 [<ffffffff81030c08>] no_context+0xe8/0x260 [<ffffffff812cf9d4>] ? kfree_skb+0x64/0x90 [<ffffffff81030eb5>] __bad_area_nosemaphore+0x135/0x200 [<ffffffff81045df6>] ? enqueue_task_fair+0x186/0x3a0 [<ffffffff8103a791>] ? activate_task+0x51/0x80 [<ffffffff81030f8e>] bad_area_nosemaphore+0xe/0x10 [<ffffffff8103138e>] do_page_fault+0x23e/0x2f0 [<ffffffff81366695>] page_fault+0x25/0x30 [<ffffffff81057c19>] ? run_timer_softirq+0x179/0x300 [<ffffffff81027d98>] ? lapic_next_event+0x18/0x20 [<ffffffff8104f642>] __do_softirq+0xd2/0x1b0 [<ffffffff81011e0a>] call_softirq+0x1a/0x30 [<ffffffff81013b55>] do_softirq+0x65/0xa0 [<ffffffff8104f22d>] irq_exit+0x3d/0x50 [<ffffffff81028869>] smp_apic_timer_interrupt+0x59/0x90 [<ffffffff81011933>] apic_timer_interrupt+0x13/0x20 <EOI> [<ffffffff81018880>] ? mwait_idle+0x80/0xc0 [<ffffffff81068851>] ? atomic_notifier_call_chain+0x11/0x20 [<ffffffff8101012c>] ? cpu_idle+0x8c/0xb0 [<ffffffff8135cfcb>] ? rest_init+0x5b/0x70 [<ffffffff8155bc9d>] ? start_kernel+0x3a6/0x46f [<ffffffff8155b2b9>] ? x86_64_start_reservations+0x99/0xb9 [<ffffffff8155b3df>] ? x86_64_start_kernel+0x106/0x121 [<ffffffff8155b140>] ? early_idt_handler+0x0/0x71 Rebooting in 60 seconds.. ------------------------------- ------------------------------- BUG: unable to handle kernel NULL pointer dereference at 0000000000000268 IP: [<ffffffff810ceb11>] bdi_register+0x31/0x190 PGD d563067 PUD d417067 PMD 0 Oops: 0000 [#1] last sysfs file: /sys/devices/pci0000:00/0000:00:00.0/modalias CPU 0 Modules linked in: loop(+) netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss 8139cp 8139too snd shpchp rtc_cmos i2c_viapro soundcore pci_hotplug i2c_core mii sr_mod binfmt_misc ext3 jbd via_agp evdev sg pata_via ata_generic ide_pci_generic sata_via libata sd_mod scsi_mod crc_t10dif Pid: 28774, comm: modprobe Tainted: G W 2.6.32-nosmp #2 MS-7258 RIP: 0010:[<ffffffff810ceb11>] [<ffffffff810ceb11>] bdi_register+0x31/0x190 RSP: 0018:ffff88000c6e3da8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000140 RCX: 0000000000000007 RDX: ffffffff81401845 RSI: 0000000000000000 RDI: 0000000000000140 RBP: ffff88000c6e3e98 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000010 R11: 0000000000000000 R12: ffff880061659000 R13: 0000000000100000 R14: 0000000000ce41b0 R15: 0000000000cdc388 FS: 00002ac71c305f90(0000) GS:ffffffff8148e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000268 CR3: 000000001da23000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process modprobe (pid: 28774, threadinfo ffff88000c6e2000, task ffff88007ece2d20) Stack: ffff88000c6e3dc8 0000000000000002 ffff88000c6e3e28 ffffffff8142d76c <0> 0000000000000000 0000000000cdc388 ffff88000c6e3de8 0000000000000007 <0> 0000000000000000 0000000000000001 ffffffff814876a7 ffffffff81076c4f Call Trace: [<ffffffff81076c4f>] ? print_modules+0x5f/0xc0 [<ffffffff811caa8a>] ? blk_register_queue+0xea/0xf0 [<ffffffff811caa8a>] ? blk_register_queue+0xea/0xf0 [<ffffffff810476dc>] ? warn_slowpath_common+0x9c/0xd0 [<ffffffff8104771f>] ? warn_slowpath_null+0xf/0x20 [<ffffffff811caa8a>] ? blk_register_queue+0xea/0xf0 [<ffffffff810cec93>] bdi_register_dev+0x23/0x30 [<ffffffff811cf761>] add_disk+0x121/0x160 [<ffffffffa00af834>] ? loop_alloc+0x144/0x180 [loop] [<ffffffffa00a0185>] loop_init+0x185/0x1e2 [loop] [<ffffffffa00a0000>] ? loop_init+0x0/0x1e2 [loop] [<ffffffff8100a037>] do_one_initcall+0x37/0x1a0 [<ffffffff8107aba0>] sys_init_module+0xe0/0x260 [<ffffffff81010e7f>] system_call_fastpath+0x16/0x1b Code: 48 81 ec f0 00 00 00 48 89 5d e8 4c 89 65 f0 48 89 fb 4c 89 6d f8 48 89 8d 48 ff ff ff 4c 89 85 50 ff ff ff 4c 89 8d 58 ff ff ff <48> 83 bf 28 01 00 00 00 74 15 48 8b 5d e8 4c 8b 65 f0 4c 8b 6d RIP [<ffffffff810ceb11>] bdi_register+0x31/0x190 RSP <ffff88000c6e3da8> CR2: 0000000000000268 ---[ end trace f6be10bc0c089fe3 ]--- Kernel panic - not syncing: Fatal exception Pid: 28774, comm: modprobe Tainted: G D W 2.6.32-nosmp #2 Call Trace: [<ffffffff8132246b>] panic+0xa0/0x172 [<ffffffff8107cac4>] ? crash_kexec+0x74/0x100 [<ffffffff8128e572>] ? __kfree_skb+0x42/0xb0 [<ffffffff8101192e>] ? apic_timer_interrupt+0xe/0x20 [<ffffffff81014e3a>] ? oops_end+0x5a/0xe0 [<ffffffff81014e77>] oops_end+0x97/0xe0 [<ffffffff8102f458>] no_context+0xe8/0x260 [<ffffffff8102f705>] __bad_area_nosemaphore+0x135/0x200 [<ffffffff811e38f7>] ? vsnprintf+0x217/0x600 [<ffffffff8102f828>] bad_area+0x48/0x60 [<ffffffff8102fc3c>] do_page_fault+0x29c/0x2f0 [<ffffffff81324a55>] page_fault+0x25/0x30 [<ffffffff810ceb11>] ? bdi_register+0x31/0x190 [<ffffffff81076c4f>] ? print_modules+0x5f/0xc0 [<ffffffff811caa8a>] ? blk_register_queue+0xea/0xf0 [<ffffffff811caa8a>] ? blk_register_queue+0xea/0xf0 [<ffffffff810476dc>] ? warn_slowpath_common+0x9c/0xd0 [<ffffffff8104771f>] ? warn_slowpath_null+0xf/0x20 [<ffffffff811caa8a>] ? blk_register_queue+0xea/0xf0 [<ffffffff810cec93>] bdi_register_dev+0x23/0x30 [<ffffffff811cf761>] add_disk+0x121/0x160 [<ffffffffa00af834>] ? loop_alloc+0x144/0x180 [loop] [<ffffffffa00a0185>] loop_init+0x185/0x1e2 [loop] [<ffffffffa00a0000>] ? loop_init+0x0/0x1e2 [loop] [<ffffffff8100a037>] do_one_initcall+0x37/0x1a0 [<ffffffff8107aba0>] sys_init_module+0xe0/0x260 [<ffffffff81010e7f>] system_call_fastpath+0x16/0x1b Rebooting in 60 seconds.. ------------------------------- ------------------------------- general protection fault: 0000 [#1] last sysfs file: /sys/devices/pci0000:00/0000:00:0f.1/host3/target3:0:1/3:0:1:0/model CPU 0 Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 binfmt_misc loop ext3 jbd snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd i2c_viapro 8139cp soundcore i2c_core floppy sr_mod sg shpchp pci_hotplug 8139too mii via_agp rtc_cmos button evdev pata_via ata_generic ide_pci_generic sata_via libata sd_mod scsi_mod crc_t10dif Pid: 0, comm: swapper Not tainted 2.6.32.1-nosmp #4 MS-7258 RIP: 0010:[<ffffffffa028fe4d>] [<ffffffffa028fe4d>] ax25_heartbeat_expiry+0xd/0x60 [ax25] RSP: 0018:ffffffff814fbe60 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff880059831a18 RCX: 0c40000000000000 RDX: ac846c8cff811900 RSI: 08e5ffe21f419831 RDI: ffff880059831800 RBP: ffffffff814fbe60 R08: 6200000000000000 R09: ffff880059831a18 R10: ffffffff81506dc0 R11: 0000000000000000 R12: ffffffff81607128 R13: ffffffff81607380 R14: ffffffff814fbeb0 R15: ffffffffa028fe40 FS: 0000000000000000(0000) GS:ffffffff814f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00007f156815c000 CR3: 00000000637e2000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffffffff814da000, task ffffffff814ece40) Stack: ffffffff814fbef0 ffffffff810574d9 ffffffff814dbfd8 ffffffff814dbfd8 <0> 0000010081017906 ffff880059831800 ffffffff81608f98 ffffffff81608b98 <0> ffffffff81608798 ffffffff81608398 ffffffff814fbeb0 ffffffff814fbeb0 Call Trace: <IRQ> [<ffffffff810574d9>] run_timer_softirq+0x179/0x300 [<ffffffff81027c08>] ? lapic_next_event+0x18/0x20 [<ffffffff8104ef02>] __do_softirq+0xd2/0x1b0 [<ffffffff81011e4a>] call_softirq+0x1a/0x30 [<ffffffff81013b95>] do_softirq+0x65/0xa0 [<ffffffff8104eaed>] irq_exit+0x3d/0x50 [<ffffffff810286d9>] smp_apic_timer_interrupt+0x59/0x90 [<ffffffff81011973>] apic_timer_interrupt+0x13/0x20 <EOI> [<ffffffff81018720>] ? mwait_idle+0x80/0xc0 [<ffffffff81068101>] ? atomic_notifier_call_chain+0x11/0x20 [<ffffffff8101012c>] ? cpu_idle+0x8c/0xb0 [<ffffffff813597fb>] ? rest_init+0x5b/0x70 [<ffffffff8155ac8d>] ? start_kernel+0x396/0x45f [<ffffffff8155a2b9>] ? x86_64_start_reservations+0x99/0xb9 [<ffffffff8155a3df>] ? x86_64_start_kernel+0x106/0x121 [<ffffffff8155a140>] ? early_idt_handler+0x0/0x71 Code: 80 7a 58 00 66 90 74 da c9 0f 1f 44 00 00 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 8b 57 28 48 89 e5 48 85 d2 74 0c <8b> 42 50 85 c0 78 11 83 f8 01 7f 17 0f 1f 80 00 00 00 00 e8 cb RIP [<ffffffffa028fe4d>] ax25_heartbeat_expiry+0xd/0x60 [ax25] RSP <ffffffff814fbe60> ---[ end trace 44c0364064d76fee ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 0, comm: swapper Tainted: G D 2.6.32.1-nosmp #4 Call Trace: <IRQ> [<ffffffff8136086b>] panic+0xa0/0x172 [<ffffffff812cc0f2>] ? __kfree_skb+0x42/0xb0 [<ffffffff81011813>] ? ret_from_intr+0x0/0x10 [<ffffffff81014e7a>] ? oops_end+0x5a/0xe0 [<ffffffff81014eec>] oops_end+0xcc/0xe0 [<ffffffff810150b6>] die+0x56/0x90 [<ffffffff81013178>] do_general_protection+0x158/0x160 [<ffffffff81362e25>] general_protection+0x25/0x30 [<ffffffffa028fe40>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25] [<ffffffffa028fe4d>] ? ax25_heartbeat_expiry+0xd/0x60 [ax25] [<ffffffff810574d9>] run_timer_softirq+0x179/0x300 [<ffffffff81027c08>] ? lapic_next_event+0x18/0x20 [<ffffffff8104ef02>] __do_softirq+0xd2/0x1b0 [<ffffffff81011e4a>] call_softirq+0x1a/0x30 [<ffffffff81013b95>] do_softirq+0x65/0xa0 [<ffffffff8104eaed>] irq_exit+0x3d/0x50 [<ffffffff810286d9>] smp_apic_timer_interrupt+0x59/0x90 [<ffffffff81011973>] apic_timer_interrupt+0x13/0x20 <EOI> [<ffffffff81018720>] ? mwait_idle+0x80/0xc0 [<ffffffff81068101>] ? atomic_notifier_call_chain+0x11/0x20 [<ffffffff8101012c>] ? cpu_idle+0x8c/0xb0 [<ffffffff813597fb>] ? rest_init+0x5b/0x70 [<ffffffff8155ac8d>] ? start_kernel+0x396/0x45f [<ffffffff8155a2b9>] ? x86_64_start_reservations+0x99/0xb9 [<ffffffff8155a3df>] ? x86_64_start_kernel+0x106/0x121 [<ffffffff8155a140>] ? early_idt_handler+0x0/0x71 Rebooting in 60 seconds.. ------------------------------- ------------[ cut here ]------------ kernel BUG at kernel/timer.c:951! invalid opcode: 0000 [#1] last sysfs file: /sys/devices/pci0000:00/0000:00:00.0/modalias CPU 0 Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 binfmt_misc loop ext3 jbd snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd 8139cp i2c_viapro i2c_core 8139too soundcore floppy sr_mod via_agp shpchp pci_hotplug mii sg rtc_cmos button evdev pata_via ata_generic ide_pci_generic sata_via libata sd_mod scsi_mod crc_t10dif Pid: 25429, comm: setiathome-5.28 Not tainted 2.6.32.1-nosmp #4 MS-7258 RIP: 0010:[<ffffffff810538cb>] [<ffffffff810538cb>] cascade+0x9b/0xa0 RSP: 0000:ffffffff814fbe30 EFLAGS: 00010082 RAX: 0000000000000000 RBX: ffff88005e5b6618 RCX: 0000000100c05204 RDX: ffffffff814fbe30 RSI: ffff88005e5b6618 RDI: ffffffff81607380 RBP: ffffffff814fbe60 R08: 0000000000000004 R09: ffffffff815090a0 R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff81607380 R13: ffffffff814fbe30 R14: 0000000000000012 R15: 0000000000000001 FS: 00000000422f4940(0063) GS:ffffffff814f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f448ac9a000 CR3: 00000000525aa000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process setiathome-5.28 (pid: 25429, threadinfo ffff880074ed0000, task ffff8800525b2d20) Stack: ffff880074c75970 ffff88005e5b6618 0000000000000000 ffffffff81607128 <0> ffffffff81607380 ffffffff814fbeb0 ffffffff814fbef0 ffffffff81057455 <0> ffff880074ed1fd8 ffff880074ed1fd8 ffffffff81017906 ffffffff814f4fa0 Call Trace: <IRQ> [<ffffffff81057455>] run_timer_softirq+0xf5/0x300 [<ffffffff81017906>] ? read_tsc+0x16/0x40 [<ffffffff81027c08>] ? lapic_next_event+0x18/0x20 [<ffffffff8104ef02>] __do_softirq+0xd2/0x1b0 [<ffffffff81011e4a>] call_softirq+0x1a/0x30 [<ffffffff81013b95>] do_softirq+0x65/0xa0 [<ffffffff8104eaed>] irq_exit+0x3d/0x50 [<ffffffff810286d9>] smp_apic_timer_interrupt+0x59/0x90 [<ffffffff81011973>] apic_timer_interrupt+0x13/0x20 <EOI> Code: 83 e0 fe 49 39 c4 75 23 48 89 d3 4c 89 e7 e8 7d fe ff ff 4c 39 eb 48 8b 13 75 dd 48 83 c4 10 44 89 f0 5b 41 5c 41 5d 41 5e c9 c3 <0f> 0b eb fe 90 55 48 8b 04 25 40 70 4f 81 48 8b 80 20 04 00 00 RIP [<ffffffff810538cb>] cascade+0x9b/0xa0 RSP <ffffffff814fbe30> ---[ end trace 5feab457f7d8d266 ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 25429, comm: setiathome-5.28 Tainted: G D 2.6.32.1-nosmp #4 Call Trace: <IRQ> [<ffffffff8136086b>] panic+0xa0/0x172 [<ffffffff8107ec14>] ? crash_kexec+0x74/0x100 [<ffffffff812cc0f2>] ? __kfree_skb+0x42/0xb0 [<ffffffff810491d5>] ? console_unblank+0x75/0x90 [<ffffffff81014eec>] oops_end+0xcc/0xe0 [<ffffffff810150b6>] die+0x56/0x90 [<ffffffff810129b6>] do_trap+0x146/0x170 [<ffffffff81068101>] ? atomic_notifier_call_chain+0x11/0x20 [<ffffffff81012e30>] do_invalid_op+0x90/0xb0 [<ffffffff810538cb>] ? cascade+0x9b/0xa0 [<ffffffffa0279f1d>] ? ax25_kiss_rcv+0x1ed/0x900 [ax25] [<ffffffff81011adb>] invalid_op+0x1b/0x20 [<ffffffff810538cb>] ? cascade+0x9b/0xa0 [<ffffffff81057455>] run_timer_softirq+0xf5/0x300 [<ffffffff81017906>] ? read_tsc+0x16/0x40 [<ffffffff81027c08>] ? lapic_next_event+0x18/0x20 [<ffffffff8104ef02>] __do_softirq+0xd2/0x1b0 [<ffffffff81011e4a>] call_softirq+0x1a/0x30 [<ffffffff81013b95>] do_softirq+0x65/0xa0 [<ffffffff8104eaed>] irq_exit+0x3d/0x50 [<ffffffff810286d9>] smp_apic_timer_interrupt+0x59/0x90 [<ffffffff81011973>] apic_timer_interrupt+0x13/0x20 <EOI> Rebooting in 60 seconds.. ------------------------------- ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: kernel BUG at kernel/timer.c:951! 2009-12-19 13:38 kernel BUG at kernel/timer.c:951! Bernard Pidoux @ 2009-12-19 17:40 ` Jarek Poplawski 2009-12-20 18:04 ` Bernard Pidoux 0 siblings, 1 reply; 37+ messages in thread From: Jarek Poplawski @ 2009-12-19 17:40 UTC (permalink / raw) To: Bernard Pidoux Cc: linux-kernel, Linux Netdev List, David S. Miller, Bernard Pidoux Bernard Pidoux wrote, On 12/19/2009 02:38 PM: > I am experiencing a few kernel panics on my Linux system using 2.6.32 and 2.6.32.1 kernels > with nosmp. Some of these oopses look similarly to those: http://markmail.org/message/scjov36zm2wf2ytv How about this patch I sent you for testing?: http://markmail.org/message/nymi7xyd5c43hyfu Jarek P. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: kernel BUG at kernel/timer.c:951! 2009-12-19 17:40 ` Jarek Poplawski @ 2009-12-20 18:04 ` Bernard Pidoux 2010-01-15 14:46 ` Bernard Pidoux 0 siblings, 1 reply; 37+ messages in thread From: Bernard Pidoux @ 2009-12-20 18:04 UTC (permalink / raw) To: Jarek Poplawski Cc: Bernard Pidoux, linux-kernel, Linux Netdev List, David S. Miller Hi Jarek, Your patch seemed to be working well until 2.6.31.6 kernel. I did not apply your patch to kernel 2.6.32. I agree that this may explain why these kernel panics are back. I will apply this patch to 2.6.32.2 and will report the results soon. Thanks. Bernard Pidoux Jarek Poplawski a écrit : > Bernard Pidoux wrote, On 12/19/2009 02:38 PM: > >> I am experiencing a few kernel panics on my Linux system using 2.6.32 and 2.6.32.1 kernels >> with nosmp. > > Some of these oopses look similarly to those: > http://markmail.org/message/scjov36zm2wf2ytv > > How about this patch I sent you for testing?: > http://markmail.org/message/nymi7xyd5c43hyfu > > Jarek P. > > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: kernel BUG at kernel/timer.c:951! 2009-12-20 18:04 ` Bernard Pidoux @ 2010-01-15 14:46 ` Bernard Pidoux 2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski 0 siblings, 1 reply; 37+ messages in thread From: Bernard Pidoux @ 2010-01-15 14:46 UTC (permalink / raw) To: Jarek Poplawski Cc: Bernard Pidoux, linux-kernel, Linux Netdev List, David S. Miller Hi Jarek, 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. Bernard Bernard Pidoux a écrit : > Hi Jarek, > > Your patch seemed to be working well until 2.6.31.6 kernel. > I did not apply your patch to kernel 2.6.32. > I agree that this may explain why these kernel panics are back. > I will apply this patch to 2.6.32.2 and will report the results soon. > Thanks. > > Bernard Pidoux > > Jarek Poplawski a écrit : >> Bernard Pidoux wrote, On 12/19/2009 02:38 PM: >> >>> I am experiencing a few kernel panics on my Linux system using 2.6.32 >>> and 2.6.32.1 kernels >>> with nosmp. >> >> Some of these oopses look similarly to those: >> http://markmail.org/message/scjov36zm2wf2ytv >> >> How about this patch I sent you for testing?: >> http://markmail.org/message/nymi7xyd5c43hyfu >> >> Jarek P. >> >> > > ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses 2010-01-15 14:46 ` Bernard Pidoux @ 2010-01-15 20:36 ` Jarek Poplawski 2010-01-16 9:04 ` David Miller ` (4 more replies) 0 siblings, 5 replies; 37+ 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] 37+ 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 2010-02-11 16:34 ` [PATCH 07/13] net: ax25: use seq_hlist_foo() helpers Bernard Pidoux 2011-06-16 20:23 ` f6bvp ` (3 subsequent siblings) 4 siblings, 1 reply; 37+ 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] 37+ messages in thread
* [PATCH 07/13] net: ax25: use seq_hlist_foo() helpers 2010-01-16 9:04 ` David Miller @ 2010-02-11 16:34 ` Bernard Pidoux 0 siblings, 0 replies; 37+ messages in thread From: Bernard Pidoux @ 2010-02-11 16:34 UTC (permalink / raw) To: Li Zefan; +Cc: David Miller, netdev, linux-kernel Hi Li Zefan, Your patches 1, 2, 3, 4, 6, 7, 9, 10/13 applied. kernel and modules compiled ok. AX25 and ROSE are working fine. Thanks. Bernard Simplify seq_file code. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> --- net/ax25/af_ax25.c | 18 +++--------------- net/ax25/ax25_uid.c | 25 ++++--------------------- 2 files changed, 7 insertions(+), 36 deletions(-) ^ permalink raw reply [flat|nested] 37+ messages in thread
* [AX25] inconsistent lock state 2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski @ 2011-06-16 20:23 ` f6bvp 2011-06-16 20:23 ` f6bvp ` (3 subsequent siblings) 4 siblings, 0 replies; 37+ 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] 37+ messages in thread
* [AX25] inconsistent lock state @ 2011-06-16 20:23 ` f6bvp 0 siblings, 0 replies; 37+ 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-16 20:23 ` f6bvp (?) @ 2011-06-17 13:28 ` Ralf Baechle -1 siblings, 0 replies; 37+ 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] 37+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-16 20:23 ` f6bvp (?) (?) @ 2011-06-17 13:36 ` Arnd Bergmann 2011-06-17 13:51 ` Ralf Baechle -1 siblings, 1 reply; 37+ 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] 37+ 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 ` f6bvp 0 siblings, 2 replies; 37+ 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] 37+ 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 ` f6bvp 1 sibling, 2 replies; 37+ 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] 37+ 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; 37+ 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] 37+ messages in thread
* Re: [AX25] inconsistent lock state @ 2011-06-17 15:31 ` f6bvp 0 siblings, 0 replies; 37+ 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-17 14:11 ` Arnd Bergmann @ 2011-06-25 15:51 ` f6bvp 2011-06-25 15:51 ` f6bvp 1 sibling, 0 replies; 37+ 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] 37+ messages in thread
* Re: [AX25] inconsistent lock state @ 2011-06-25 15:51 ` f6bvp 0 siblings, 0 replies; 37+ 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 ^ permalink raw reply [flat|nested] 37+ 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 -1 siblings, 1 reply; 37+ 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] 37+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-25 16:39 ` Ralf Baechle DL5RB @ 2011-07-01 13:00 ` Bernard F6BVP 0 siblings, 0 replies; 37+ 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] 37+ messages in thread
* Re: [AX25] inconsistent lock state @ 2011-07-01 13:00 ` Bernard F6BVP 0 siblings, 0 replies; 37+ 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 ^ permalink raw reply [flat|nested] 37+ 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 -1 siblings, 1 reply; 37+ 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] 37+ 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; 37+ 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] 37+ messages in thread
* [NetRom] possible circular locking dependency detected 2011-06-25 15:51 ` f6bvp @ 2012-10-21 15:18 ` Bernard f6bvp -1 siblings, 0 replies; 37+ 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] 37+ messages in thread
* [NetRom] possible circular locking dependency detected @ 2012-10-21 15:18 ` Bernard f6bvp 0 siblings, 0 replies; 37+ 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: 13574 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] 37+ messages in thread
* Re: [AX25] inconsistent lock state 2011-06-17 13:51 ` Ralf Baechle @ 2011-06-17 15:26 ` f6bvp 2011-06-17 15:26 ` f6bvp 1 sibling, 0 replies; 37+ 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] 37+ messages in thread
* Re: [AX25] inconsistent lock state @ 2011-06-17 15:26 ` f6bvp 0 siblings, 0 replies; 37+ 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* khubd [ INFO: possible circular locking dependency detected ] 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-16 20:29 ` f6bvp 2011-06-16 20:40 ` f6bvp 2011-07-07 13:31 ` Question with axudp Bernard, f6bvp 4 siblings, 0 replies; 37+ messages in thread From: f6bvp @ 2011-06-16 20:29 UTC (permalink / raw) To: linux-kernel; +Cc: Linux Netdev List Hi, Here is a kernel message dump reporting a possible circular locking : Jun 13 11:58:55 f6bvp-9 kernel: usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Jun 13 11:58:55 f6bvp-9 kernel: usb 5-2: Product: FUNcube Dongle V1.0 Jun 13 11:58:55 f6bvp-9 kernel: usb 5-2: Manufacturer: Hanlincrest Ltd. Jun 13 11:58:55 f6bvp-9 kernel: generic-usb 0003:04D8:FB56.0004: hiddev0,hidraw3: USB HID v1.11 Device [Hanlincrest Ltd. FUNcube Dongle V1.0 ] on usb-0000:00:1d.3-2/input2 Jun 13 11:58:56 f6bvp-9 kernel: usbcore: registered new interface driver snd-usb-audio Jun 13 11:58:56 f6bvp-9 udevd-work[11414]: symlink(snd/controlC1, /dev/FCD.udev-tmp) failed: File exists Jun 13 11:58:57 f6bvp-9 rtkit-daemon[3119]: Successfully made thread 11434 of process 3117 (/usr/bin/pulseaudio) owned by '500' RT at priority 5. Jun 13 11:59:18 f6bvp-9 kernel: usb 5-2: USB disconnect, device number 2 Jun 13 11:59:18 f6bvp-9 kernel: Jun 13 11:59:18 f6bvp-9 kernel: ======================================================= Jun 13 11:59:18 f6bvp-9 kernel: [ INFO: possible circular locking dependency detected ] Jun 13 11:59:18 f6bvp-9 kernel: 2.6.39 #2 Jun 13 11:59:18 f6bvp-9 kernel: ------------------------------------------------------- Jun 13 11:59:18 f6bvp-9 kernel: khubd/41 is trying to acquire lock: Jun 13 11:59:18 f6bvp-9 kernel: (sound_oss_mutex){+.+.+.}, at: [<ffffffffa02e134b>] snd_unregister_oss_device+0x4b/0x110 [snd] Jun 13 11:59:18 f6bvp-9 kernel: Jun 13 11:59:18 f6bvp-9 kernel: but task is already holding lock: Jun 13 11:59:18 f6bvp-9 kernel: (&chip->shutdown_mutex){+.+.+.}, at: [<ffffffffa05e3258>] usb_audio_disconnect+0x48/0x1b0 [snd_usb_audio] Jun 13 11:59:18 f6bvp-9 kernel: Jun 13 11:59:18 f6bvp-9 kernel: which lock already depends on the new lock. Jun 13 11:59:18 f6bvp-9 kernel: Jun 13 11:59:18 f6bvp-9 kernel: Jun 13 11:59:18 f6bvp-9 kernel: the existing dependency chain (in reverse order) is: Jun 13 11:59:18 f6bvp-9 kernel: Jun 13 11:59:18 f6bvp-9 kernel: -> #5 (&chip->shutdown_mutex){+.+.+.}: Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff810958d6>] lock_acquire+0xa6/0x160 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff813f469c>] __mutex_lock_common+0x4c/0x3c0 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff813f4ac5>] mutex_lock_nested+0x35/0x40 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffffa05ed874>] snd_usb_hw_free+0x44/0x70 [snd_usb_audio] Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffffa02f3523>] snd_pcm_release_substream+0x63/0xc0 [snd_pcm] Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffffa02f35d0>] snd_pcm_release+0x50/0xe0 [snd_pcm] Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff8114303a>] fput+0xea/0x230 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff811185e5>] remove_vma+0x45/0x90 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff8111a378>] do_munmap+0x318/0x3b0 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff8111a469>] sys_munmap+0x59/0x80 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff813fe5d2>] system_call_fastpath+0x16/0x1b Jun 13 11:59:18 f6bvp-9 kernel: Jun 13 11:59:18 f6bvp-9 kernel: -> #4 (&pcm->open_mutex){+.+.+.}: Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff810958d6>] lock_acquire+0xa6/0x160 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff813f469c>] __mutex_lock_common+0x4c/0x3c0 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff813f4ac5>] mutex_lock_nested+0x35/0x40 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffffa02f35c8>] snd_pcm_release+0x48/0xe0 [snd_pcm] Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff8114303a>] fput+0xea/0x230 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff811185e5>] remove_vma+0x45/0x90 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff8111a378>] do_munmap+0x318/0x3b0 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff8111a469>] sys_munmap+0x59/0x80 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff813fe5d2>] system_call_fastpath+0x16/0x1b Jun 13 11:59:18 f6bvp-9 kernel: Jun 13 11:59:18 f6bvp-9 kernel: -> #3 (&mm->mmap_sem){++++++}: Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff810958d6>] lock_acquire+0xa6/0x160 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff811106e2>] might_fault+0x72/0xa0 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff81153642>] filldir+0x82/0xf0 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff81165dee>] dcache_readdir+0x5e/0x260 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff81153848>] vfs_readdir+0xb8/0xe0 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff811539d9>] sys_getdents+0x89/0xf0 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff813fe5d2>] system_call_fastpath+0x16/0x1b Jun 13 11:59:18 f6bvp-9 kernel: Jun 13 11:59:18 f6bvp-9 kernel: -> #2 (&sb->s_type->i_mutex_key#3){+.+.+.}: Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff810958d6>] lock_acquire+0xa6/0x160 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff813f469c>] __mutex_lock_common+0x4c/0x3c0 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff813f4ac5>] mutex_lock_nested+0x35/0x40 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff812d0412>] devtmpfs_create_node+0x1f2/0x290 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff812c90a8>] device_add+0x218/0x6e0 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff812c958e>] device_register+0x1e/0x30 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff812c96b0>] device_create_vargs+0x110/0x120 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff812c96f1>] device_create+0x31/0x40 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff812bc392>] misc_register+0x92/0x140 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff817478c0>] vga_arb_device_init+0x13/0x77 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff81002043>] do_one_initcall+0x43/0x190 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff81713655>] kernel_init+0xb5/0x135 Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff813ff764>] kernel_thread_helper+0x4/0x10 Jun 13 11:59:18 f6bvp-9 kernel: Jun 13 11:59:18 f6bvp-9 kernel: -> #1 (&sb->s_type->i_mutex_key#2/1){+.+.+.}: Jun 13 11:59:18 f6bvp-9 kernel: [<ffffffff810958d6>] lock_acquire+0xa6/0x160 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813f469c>] __mutex_lock_common+0x4c/0x3c0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813f4ac5>] mutex_lock_nested+0x35/0x40 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff8114bcb2>] lookup_create+0x32/0xd0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812d032a>] devtmpfs_create_node+0x10a/0x290 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812c90a8>] device_add+0x218/0x6e0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812c958e>] device_register+0x1e/0x30 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812c96b0>] device_create_vargs+0x110/0x120 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812c96f1>] device_create+0x31/0x40 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa017c44c>] sound_insert_unit+0x29c/0x300 [soundcore] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa017c644>] register_sound_special_device+0xb4/0x240 [soundcore] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa02e152c>] snd_register_oss_device+0x11c/0x220 [snd] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa038103b>] 0xffffffffa038103b Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff81002043>] do_one_initcall+0x43/0x190 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff810a200a>] sys_init_module+0xba/0x200 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813fe5d2>] system_call_fastpath+0x16/0x1b Jun 13 11:59:19 f6bvp-9 kernel: Jun 13 11:59:19 f6bvp-9 kernel: -> #0 (sound_oss_mutex){+.+.+.}: Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff8109571d>] __lock_acquire+0x13ad/0x14c0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff810958d6>] lock_acquire+0xa6/0x160 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813f469c>] __mutex_lock_common+0x4c/0x3c0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813f4ac5>] mutex_lock_nested+0x35/0x40 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa02e134b>] snd_unregister_oss_device+0x4b/0x110 [snd] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa01de5dd>] snd_mixer_oss_notify_handler+0x11d/0x330 [snd_mixer_oss] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa02dae5f>] snd_card_disconnect+0x16f/0x250 [snd] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa05e32a0>] usb_audio_disconnect+0x90/0x1b0 [snd_usb_audio] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa000ccc0>] usb_unbind_interface+0x60/0x1a0 [usbcore] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812cb525>] __device_release_driver+0x75/0xe0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812cbacf>] device_release_driver+0x2f/0x50 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812ca564>] bus_remove_device+0xb4/0x100 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812c878f>] device_del+0x12f/0x1b0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa0009b1f>] usb_disable_device+0x6f/0x130 [usbcore] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa0003b99>] usb_disconnect+0x99/0x130 [usbcore] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa00044e1>] hub_thread+0x621/0x12d0 [usbcore] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff8107d816>] kthread+0xb6/0xc0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813ff764>] kernel_thread_helper+0x4/0x10 Jun 13 11:59:19 f6bvp-9 kernel: Jun 13 11:59:19 f6bvp-9 kernel: other info that might help us debug this: Jun 13 11:59:19 f6bvp-9 kernel: Jun 13 11:59:19 f6bvp-9 kernel: 5 locks held by khubd/41: Jun 13 11:59:19 f6bvp-9 kernel: #0: (&__lockdep_no_validate__){+.+.+.}, at: [<ffffffffa0003ff0>] hub_thread+0x130/0x12d0 [usbcore] Jun 13 11:59:19 f6bvp-9 kernel: #1: (&__lockdep_no_validate__){+.+.+.}, at: [<ffffffffa0003b5d>] usb_disconnect+0x5d/0x130 [usbcore] Jun 13 11:59:19 f6bvp-9 kernel: #2: (&__lockdep_no_validate__){+.+.+.}, at: [<ffffffff812cbac7>] device_release_driver+0x27/0x50 Jun 13 11:59:19 f6bvp-9 kernel: #3: (register_mutex#6){+.+.+.}, at: [<ffffffffa05e324e>] usb_audio_disconnect+0x3e/0x1b0 [snd_usb_audio] Jun 13 11:59:19 f6bvp-9 kernel: #4: (&chip->shutdown_mutex){+.+.+.}, at: [<ffffffffa05e3258>] usb_audio_disconnect+0x48/0x1b0 [snd_usb_audio] Jun 13 11:59:19 f6bvp-9 kernel: Jun 13 11:59:19 f6bvp-9 kernel: stack backtrace: Jun 13 11:59:19 f6bvp-9 kernel: Pid: 41, comm: khubd Not tainted 2.6.39 #2 Jun 13 11:59:19 f6bvp-9 kernel: Call Trace: Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff81093299>] print_circular_bug+0xe9/0xf0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff8109571d>] __lock_acquire+0x13ad/0x14c0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff810958d6>] lock_acquire+0xa6/0x160 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa02e134b>] ? snd_unregister_oss_device+0x4b/0x110 [snd] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff81093d6b>] ? mark_held_locks+0x6b/0xa0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813f469c>] __mutex_lock_common+0x4c/0x3c0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa02e134b>] ? snd_unregister_oss_device+0x4b/0x110 [snd] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa02e134b>] ? snd_unregister_oss_device+0x4b/0x110 [snd] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813f4403>] ? __mutex_unlock_slowpath+0xd3/0x170 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff8109406d>] ? trace_hardirqs_on_caller+0x13d/0x180 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813f4ac5>] mutex_lock_nested+0x35/0x40 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa02e134b>] snd_unregister_oss_device+0x4b/0x110 [snd] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa01de5dd>] snd_mixer_oss_notify_handler+0x11d/0x330 [snd_mixer_oss] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa02dadb8>] ? snd_card_disconnect+0xc8/0x250 [snd] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813f4403>] ? __mutex_unlock_slowpath+0xd3/0x170 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff8109406d>] ? trace_hardirqs_on_caller+0x13d/0x180 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa02dae5f>] snd_card_disconnect+0x16f/0x250 [snd] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa05e32a0>] usb_audio_disconnect+0x90/0x1b0 [snd_usb_audio] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa000ccc0>] usb_unbind_interface+0x60/0x1a0 [usbcore] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812cb525>] __device_release_driver+0x75/0xe0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812cbacf>] device_release_driver+0x2f/0x50 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812ca564>] bus_remove_device+0xb4/0x100 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff812c878f>] device_del+0x12f/0x1b0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa0009b1f>] usb_disable_device+0x6f/0x130 [usbcore] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa0003b99>] usb_disconnect+0x99/0x130 [usbcore] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa00044e1>] hub_thread+0x621/0x12d0 [usbcore] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813f6380>] ? _raw_spin_unlock_irq+0x30/0x40 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff8104acad>] ? finish_task_switch+0x7d/0x110 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff8104ac78>] ? finish_task_switch+0x48/0x110 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa0003ec0>] ? hub_disconnect+0x120/0x120 [usbcore] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff8107dd50>] ? wake_up_bit+0x40/0x40 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffffa0003ec0>] ? hub_disconnect+0x120/0x120 [usbcore] Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff8107d816>] kthread+0xb6/0xc0 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff8109406d>] ? trace_hardirqs_on_caller+0x13d/0x180 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813ff764>] kernel_thread_helper+0x4/0x10 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813f6794>] ? retint_restore_args+0x13/0x13 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff8107d760>] ? __init_kthread_worker+0x70/0x70 Jun 13 11:59:19 f6bvp-9 kernel: [<ffffffff813ff760>] ? gs_change+0x13/0x13 Jun 13 11:59:20 f6bvp-9 kernel: usb 5-1: new full speed USB device number 3 using uhci_hcd Jun 13 11:59:20 f6bvp-9 kernel: usb 5-1: New USB device found, idVendor=04d8, idProduct=fb56 Jun 13 11:59:20 f6bvp-9 kernel: usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Jun 13 11:59:20 f6bvp-9 kernel: usb 5-1: Product: FUNcube Dongle V1.0 Jun 13 11:59:20 f6bvp-9 kernel: usb 5-1: Manufacturer: Hanlincrest Ltd. Jun 13 11:59:20 f6bvp-9 kernel: generic-usb 0003:04D8:FB56.0005: hiddev0,hidraw3: USB HID v1.11 Device [Hanlincrest Ltd. FUNcube Dongle V1.0 ] on usb-0000:00:1d.3-1/input2 Jun 13 11:59:21 f6bvp-9 rtkit-daemon[3119]: Successfully made thread 12523 of process 3117 (/usr/bin/pulseaudio) owned by '500' RT at priority 5. Jun 13 11:59:22 f6bvp-9 kernel: hald-probe-hidd: page allocation failure. order:4, mode:0xc0d0 Jun 13 11:59:22 f6bvp-9 kernel: Pid: 12500, comm: hald-probe-hidd Not tainted 2.6.39 #2 Jun 13 11:59:22 f6bvp-9 kernel: Call Trace: Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff810f8482>] __alloc_pages_nodemask+0x612/0x820 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff8112d4af>] alloc_pages_current+0x8f/0xe0 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff810f757e>] __get_free_pages+0xe/0x50 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff8113549e>] kmalloc_order_trace+0x3e/0xb0 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffffa0000a80>] ? usb_find_interface+0x40/0x60 [usbcore] Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffffa005ecd4>] hiddev_open+0x74/0x1c0 [usbhid] Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff813f4e69>] ? down_read+0x39/0x50 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffffa000f464>] ? usb_open+0x44/0x1a0 [usbcore] Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffffa000f4e8>] usb_open+0xc8/0x1a0 [usbcore] Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff811452b7>] chrdev_open+0xf7/0x210 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff811451c0>] ? cdev_alloc+0x60/0x60 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff8113f146>] __dentry_open+0x146/0x310 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff8113f411>] nameidata_to_filp+0x71/0x80 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff8114e79c>] do_last+0x1ec/0x870 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff8114f980>] path_openat+0xd0/0x430 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff8114fdf9>] do_filp_open+0x49/0xa0 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff813f642b>] ? _raw_spin_unlock+0x2b/0x40 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff8115d8fa>] ? alloc_fd+0xfa/0x140 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff811407b7>] do_sys_open+0x107/0x1e0 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff811408d0>] sys_open+0x20/0x30 Jun 13 11:59:22 f6bvp-9 kernel: [<ffffffff813fe5d2>] system_call_fastpath+0x16/0x1b Jun 13 11:59:22 f6bvp-9 kernel: Mem-Info: Jun 13 11:59:22 f6bvp-9 kernel: Node 0 DMA per-cpu: Jun 13 11:59:22 f6bvp-9 kernel: CPU 0: hi: 0, btch: 1 usd: 0 Jun 13 11:59:22 f6bvp-9 kernel: CPU 1: hi: 0, btch: 1 usd: 0 Jun 13 11:59:22 f6bvp-9 kernel: Node 0 DMA32 per-cpu: Jun 13 11:59:22 f6bvp-9 kernel: CPU 0: hi: 186, btch: 31 usd: 0 Jun 13 11:59:22 f6bvp-9 kernel: CPU 1: hi: 186, btch: 31 usd: 0 Jun 13 11:59:22 f6bvp-9 kernel: active_anon:21438 inactive_anon:41165 isolated_anon:11 Jun 13 11:59:22 f6bvp-9 kernel: active_file:50805 inactive_file:93727 isolated_file:31 Jun 13 11:59:22 f6bvp-9 kernel: unevictable:0 dirty:19022 writeback:359 unstable:0 Jun 13 11:59:22 f6bvp-9 kernel: free:18969 slab_reclaimable:12604 slab_unreclaimable:4850 Jun 13 11:59:22 f6bvp-9 kernel: mapped:6458 shmem:849 pagetables:3938 bounce:0 Jun 13 11:59:22 f6bvp-9 kernel: Node 0 DMA free:4048kB min:60kB low:72kB high:88kB active_anon:0kB inactive_anon:72kB active_file:2656kB inactive_file:7768kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15624kB mlocked:0kB dirty:0kB writeback:0kB mapped:124kB shmem:0kB slab_reclaimable:1252kB slab_unreclaimable:48kB kernel_stack:0kB pagetables:4kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Jun 13 11:59:22 f6bvp-9 kernel: lowmem_reserve[]: 0 992 992 992 Jun 13 11:59:22 f6bvp-9 kernel: Node 0 DMA32 free:71828kB min:3996kB low:4992kB high:5992kB active_anon:85752kB inactive_anon:164588kB active_file:200564kB inactive_file:367140kB unevictable:0kB isolated(anon):44kB isolated(file):124kB present:1016072kB mlocked:0kB dirty:76088kB writeback:1436kB mapped:25708kB shmem:3396kB slab_reclaimable:49164kB slab_unreclaimable:19352kB kernel_stack:2312kB pagetables:15748kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Jun 13 11:59:22 f6bvp-9 kernel: lowmem_reserve[]: 0 0 0 0 Jun 13 11:59:22 f6bvp-9 kernel: Node 0 DMA: 114*4kB 45*8kB 14*16kB 6*32kB 8*64kB 2*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 4048kB Jun 13 11:59:22 f6bvp-9 kernel: Node 0 DMA32: 3925*4kB 3502*8kB 1643*16kB 55*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 71828kB Jun 13 11:59:22 f6bvp-9 kernel: 150823 total pagecache pages Jun 13 11:59:22 f6bvp-9 kernel: 5394 pages in swap cache Regards, Bernard Pidoux ^ permalink raw reply [flat|nested] 37+ messages in thread
* [AX25] inconsistent lock state 2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski @ 2011-06-16 20:40 ` f6bvp 2011-06-16 20:23 ` f6bvp ` (3 subsequent siblings) 4 siblings, 0 replies; 37+ 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] 37+ messages in thread
* [AX25] inconsistent lock state @ 2011-06-16 20:40 ` f6bvp 0 siblings, 0 replies; 37+ 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 ^ permalink raw reply [flat|nested] 37+ 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 -1 siblings, 2 replies; 37+ 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] 37+ 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; 37+ 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] 37+ 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; 37+ 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] 37+ 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; 37+ 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] 37+ 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; 37+ 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] 37+ 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; 37+ 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] 37+ messages in thread
* Question with axudp 2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski ` (3 preceding siblings ...) 2011-06-16 20:40 ` f6bvp @ 2011-07-07 13:31 ` Bernard, f6bvp 2011-07-07 21:43 ` Robert Thoelen 4 siblings, 1 reply; 37+ 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] 37+ 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; 37+ 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] 37+ messages in thread
end of thread, other threads:[~2022-02-20 9:18 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-19 13:38 kernel BUG at kernel/timer.c:951! Bernard Pidoux
2009-12-19 17:40 ` Jarek Poplawski
2009-12-20 18:04 ` Bernard Pidoux
2010-01-15 14:46 ` Bernard Pidoux
2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski
2010-01-16 9:04 ` David Miller
2010-02-11 16:34 ` [PATCH 07/13] net: ax25: use seq_hlist_foo() helpers Bernard Pidoux
2011-06-16 20:23 ` [AX25] inconsistent lock state f6bvp
2011-06-16 20:23 ` 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-17 15:31 ` f6bvp
2011-06-25 15:51 ` 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 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
2012-10-21 15:18 ` Bernard f6bvp
2011-06-17 15:26 ` [AX25] inconsistent lock state f6bvp
2011-06-17 15:26 ` f6bvp
2011-06-16 20:29 ` khubd [ INFO: possible circular locking dependency detected ] f6bvp
2011-06-16 20:40 ` [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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.