BPF NULL pointer deref + processes hang on sparc64
Tried todays git on Sun V445 (sparc64). It booted up fine but userspace hangs during apt upgrade setup triggers. Linux version 5.2.0-rc5-00224-gbed3c0d84e7e (mroos@v445) (gcc version 8.3.0 (Debian 8.3.0-7)) #33 SMP Wed Jun 19 11:26:36 EEST 2019 Dmesg has this: [ 3511.042187] Unable to handle kernel NULL pointer dereference [ 3511.123518] tsk->{mm,active_mm}->context = 0001 [ 3511.203493] tsk->{mm,active_mm}->pgd = fff000323cde [ 3511.278491] \|/ \|/ [ 3511.278491] "@'/ .. \`@" [ 3511.278491] /_| \__/ |_\ [ 3511.278491] \__U_/ [ 3511.489775] systemd(1): Oops [#1] [ 3511.537256] CPU: 1 PID: 1 Comm: systemd Not tainted 5.2.0-rc5-00224-gbed3c0d84e7e #33 [ 3511.649758] TSTATE: 004411001603 TPC: 00926bb4 TNPC: 00926bb8 Y: Not tainted [ 3511.791036] TPC: [ 3511.853510] g0: 00e1 g1: 00523188 g2: g3: 0072 [ 3511.978518] g4: fff000323c0e g5: fff000323ee26000 g6: fff000323c084000 g7: 0200 [ 3512.103531] o0: 0001 o1: o2: 0001 o3: [ 3512.228530] o4: fff000323f90afc0 o5: 00523170 sp: fff000323c0872b1 ret_pc: 004fe5c8 [ 3512.358559] RPC: <__bpf_prog_put+0x8/0x80> [ 3512.417286] l0: 1000 l1: l2: l3: [ 3512.542349] l4: 00720101 l5: 00730101 l6: l7: fff000322a8e3500 [ 3512.667337] i0: 000100034000 i1: 0001 i2: fff000322a8e3cc0 i3: fff000322a8e3cc0 [ 3512.792311] i4: 0001 i5: 00210d00 i6: fff000323c087361 i7: 00523188 [ 3512.917322] I7: <__cgroup_bpf_detach+0xe8/0x160> [ 3512.983573] Call Trace: [ 3513.018568] [00523188] __cgroup_bpf_detach+0xe8/0x160 [ 3513.102327] [004e0298] cgroup_bpf_detach+0x18/0x40 [ 3513.182321] [005234ac] cgroup_bpf_prog_detach+0x4c/0x100 [ 3513.269838] [00500460] sys_bpf+0xe80/0x2140 [ 3513.341091] [00406254] linux_sparc_syscall+0x34/0x44 [ 3513.423584] Disabling lock debugging due to kernel taint [ 3513.499842] Caller[00523188]: __cgroup_bpf_detach+0xe8/0x160 [ 3513.591102] Caller[004e0298]: cgroup_bpf_detach+0x18/0x40 [ 3513.678604] Caller[005234ac]: cgroup_bpf_prog_detach+0x4c/0x100 [ 3513.773605] Caller[00500460]: sys_bpf+0xe80/0x2140 [ 3513.852360] Caller[00406254]: linux_sparc_syscall+0x34/0x44 [ 3513.942361] Caller[fff10073dee0]: 0xfff10073dee0 [ 3514.018611] Instruction DUMP: [ 3514.018614] 106fffee [ 3514.061109] 952ab001 [ 3514.094863] 94102001 [ 3514.128619] [ 3514.162367] 8e204008 [ 3514.196117] cfe25001 [ 3514.229869] 80a04007 [ 3514.263619] 1244 [ 3514.297370] 82204008 [ 3514.331124] [ 3514.390087] Unable to handle kernel NULL pointer dereference [ 3514.471365] tsk->{mm,active_mm}->context = 0024 [ 3514.551358] tsk->{mm,active_mm}->pgd = fff000323d084000 [ 3514.626351] \|/ \|/ [ 3514.626351] "@'/ .. \`@" [ 3514.626351] /_| \__/ |_\ [ 3514.626351] \__U_/ [ 3514.837625] systemd(1): Oops [#2] [ 3514.885117] CPU: 3 PID: 1 Comm: systemd Tainted: G D 5.2.0-rc5-00224-gbed3c0d84e7e #33 [ 3515.017623] TSTATE: 004411001604 TPC: 00926bb4 TNPC: 00926bb8 Y: 0013Tainted: G D [ 3515.178894] TPC: [ 3515.241376] g0: fff000323c3adae0 g1: 004fe660 g2: fff000322b6b1dd0 g3: 0800 [ 3515.366385] g4: fff000323c0e g5: fff000323f026000 g6: fff000323c084000 g7: 0003 [ 3515.491395] o0: 0001 o1: o2: 0001 o3: [ 3515.616395] o4: fff000323b5d8598 o5: 0059abdc sp: fff000323c086b91 ret_pc: 004fe5c8 [ 3515.746412] RPC: <__bpf_prog_put+0x8/0x80> [ 3515.805151] l0: fff000323fb0aff0 l1: l2: l3: [ 3515.930168] l4: 013402ab l5: 013502ab l6: l7: fff000323c266408 [ 3516.055170] i0: 000100034000 i1: 0001 i2: fff000323c266d08 i3: fff000323c266d08 [ 3516.180173] i4: 0001 i5: 00210d00 i6: fff000323c086c41 i7: 004fe66c [ 3516.305179] I7: [ 3516.365180] Call Trace: [ 3516.400179] [004fe66c] bpf_prog_release+0xc/0x20 [ 3516.477687] [0059ab70] __fput+0x90/0x220 [ 3516.545195] [0047cfa0] task_work_run+0x80/0xc0 [ 3516.620199] [004642f8] do_exit+0x2d8/0xaa0 [ 3516.690197] [0042b220] die_if_kernel+0x258/0x2c0 [ 3516.767706] [0044edc4] unhandled_fault+0x84/0xa0 [ 3516.845199] [0044ed34] do_sparc64_fault+0x774/0x780 [ 3516.926466] [004076f4] sparc64_realfault_common+0x10/0x20 [ 3517.015210] [00926bb4] atomic_sub_return+0x4/0x54 [ 3517.093969] [00523188] __cgroup_bpf_detach+0xe8/0x
Re: bpf VM_FLUSH_RESET_PERMS breaks sparc64 boot
I'm having trouble getting Debian Buster up and running on qemu-system- sparc64 and so haven't been able to reproduce. Is this currently working for people? I just reinstalled the machine from https://cdimage.debian.org/cdimage/ports/2019-05-09/debian-10.0-sparc64-NETINST-1.iso and there's a even newer build upe one directory level. This patch involves re-setting memory permissions when freeing executable memory. It looks like Sparc64 Linux doesn't have support for the set_memory_() functions so that part shouldn't be changing anything. The main other thing that is changed here is always doing a TLB flush in vfree when the BPF JITs are freed. It will already sometimes happen so that shouldn't be too different either. That part I do not know. So it doesn't seem extra especially likely to cause a sparc specific problem that I can see. Is there any chance this is an intermittent issue? So far it seemed 100% reproducible, at least in the bisect that led here. The only variation I saw was if it just sat there for newer git snapshot or spew out RCU and workqueue lockup warnings soon like I posed. I can do some tests and boot the same kernel some more times. -- Meelis Roos
bpf VM_FLUSH_RESET_PERMS breaks sparc64 boot
I tested yesterdays 5.2 devel git and it failed to boot on my Sun Fire V445 (4x UltraSparc III). Init is started and it hangs there: [ 38.414436] Run /sbin/init as init process [ 38.530711] random: fast init done [ 39.580678] systemd[1]: Inserted module 'autofs4' [ 39.721577] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid) [ 40.028068] systemd[1]: Detected architecture sparc64. Welcome to Debian GNU/Linux 10 (buster)! [ 40.168713] systemd[1]: Set hostname to . [ 61.318034] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 61.403039] rcu: 1-...!: (0 ticks this GP) idle=602/1/0x4000 softirq=85/85 fqs=1 [ 61.526780] rcu: (detected by 3, t=5252 jiffies, g=-967, q=228) [ 61.613037] CPU[ 1]: TSTATE[80001602] TPC[0043f2b8] TNPC[0043f2bc] TASK[systemd-fstab-g:90] [ 61.766828] TPC[smp_synchronize_tick_client+0x18/0x180] O7[__do_munmap+0x204/0x3e0] I7[xcall_sync_tick+0x1c/0x2c] RPC[page_evictable+0x4/0x60] [ 61.966807] rcu: rcu_sched kthread starved for 5250 jiffies! g-967 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=2 [ 62.113058] rcu: RCU grace-period kthread stack dump: [ 62.185558] rcu_sched I010 2 0x0600 [ 62.264312] Call Trace: [ 62.299316] [0092a1fc] schedule+0x1c/0x80 [ 62.368071] [0092d3fc] schedule_timeout+0x13c/0x280 [ 62.449328] [004b6c64] rcu_gp_kthread+0x4c4/0xa40 [ 62.528077] [0047e95c] kthread+0xfc/0x120 [ 62.596833] [004060a4] ret_from_fork+0x1c/0x2c [ 62.671831] [] (null) 5.1.0 worked fine. I bisected it to the following commit: d53d2f78ceadba081fc7785570798c3c8d50a718 is the first bad commit commit d53d2f78ceadba081fc7785570798c3c8d50a718 Author: Rick Edgecombe Date: Thu Apr 25 17:11:38 2019 -0700 bpf: Use vmalloc special flag Use new flag VM_FLUSH_RESET_PERMS for handling freeing of special permissioned memory in vmalloc and remove places where memory was set RW before freeing which is no longer needed. Don't track if the memory is RO anymore because it is now tracked in vmalloc. Signed-off-by: Rick Edgecombe Signed-off-by: Peter Zijlstra (Intel) Cc: Cc: Cc: Cc: Cc: Cc: Cc: Cc: Alexei Starovoitov Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Daniel Borkmann Cc: Dave Hansen Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Nadav Amit Cc: Rik van Riel Cc: Thomas Gleixner Link: https://lkml.kernel.org/r/20190426001143.4983-19-na...@vmware.com Signed-off-by: Ingo Molnar :04 04 58066de53107eab0705398b5d0c407424c138a86 7a1345d43c4cacee60b9135899b775ecdb54ea7e M include :04 04 d02692cf57a359056b34e636d0f102d37de5b264 81c4c2c6408b68eb555673bd3f0bc3071db1f7ed M kernel -- Meelis Roos
sparc64 mystery with Cheetah+ D-cache parity error (n_tty_set_termios, bpf_check, cheetah_copy_page_insn)
0: c0 f0 4b e2 stxa %g0, [ %g1 + %g2 ] #ASI_DMMU_DEMAP 860fd4: 81 43 e0 40 membar #Sync 860fd8: 81 c3 e0 08 retl 860fdc: d8 21 a0 30 st %o4, [ %g6 + 0x30 ] -- Meelis Roos
bpfilter compile failure on parisc
Tried enabling bpfilter on parisc, got this: HOSTCC net/bpfilter/main.o net/bpfilter/main.c:3:21: fatal error: sys/uio.h: No such file or directory #include ^ compilation terminated. -- Meelis Roos (mr...@linux.ee)
4.17.0-10146-gf0dc7f9c6dd9: hw csum failure on powerpc+sungem
I am seeing this on PowerMac G4 with sungem ethernet driver. 4.17 was OK, 4.17.0-10146-gf0dc7f9c6dd9 is problematic. [ 140.518664] eth0: hw csum failure [ 140.518699] CPU: 0 PID: 1237 Comm: postconf Not tainted 4.17.0-10146-gf0dc7f9c6dd9 #83 [ 140.518707] Call Trace: [ 140.518734] [effefd90] [c03d6db8] __skb_checksum_complete+0xd8/0xdc (unreliable) [ 140.518759] [effefdb0] [c04c1284] icmpv6_rcv+0x248/0x4ec [ 140.518775] [effefdd0] [c049a448] ip6_input_finish.constprop.0+0x11c/0x5f4 [ 140.518786] [effefe10] [c049b1c0] ip6_mc_input+0xcc/0x100 [ 140.518807] [effefe20] [c03e110c] __netif_receive_skb_core+0x310/0x944 [ 140.518820] [effefe70] [c03e76ec] napi_gro_receive+0xd0/0xe8 [ 140.518845] [effefe80] [f3e1f66c] gem_poll+0x618/0x1274 [sungem] [ 140.518856] [effeff30] [c03e6f0c] net_rx_action+0x198/0x374 [ 140.518872] [effeff90] [c0501a88] __do_softirq+0x120/0x278 [ 140.518890] [effeffe0] [c0036188] irq_exit+0xd8/0xdc [ 140.518908] [effefff0] [c000f478] call_do_irq+0x24/0x3c [ 140.518925] [d05a5d30] [c0007120] do_IRQ+0x74/0xf0 [ 140.518941] [d05a5d50] [c0012474] ret_from_except+0x0/0x14 [ 140.518960] --- interrupt: 501 at copy_page+0x40/0x90 LR = copy_user_page+0x18/0x30 [ 140.518973] [d05a5e10] [d058cd80] 0xd058cd80 (unreliable) [ 140.518989] [d05a5e20] [c00fa2bc] wp_page_copy+0xec/0x654 [ 140.519002] [d05a5e60] [c00fd3a4] do_wp_page+0xa8/0x5b4 [ 140.519013] [d05a5e90] [c00fe934] handle_mm_fault+0x564/0xa84 [ 140.519025] [d05a5f00] [c0016230] do_page_fault+0x1bc/0x7e8 [ 140.519037] [d05a5f40] [c0012300] handle_page_fault+0x14/0x40 [ 140.519048] --- interrupt: 301 at 0xb78b6864 LR = 0xb78b6c54 -- Meelis Roos (mr...@linux.ee)
Re: 4.9-rc7: (forcedeth?) BUG: sleeping function called from invalid context at kernel/irq/manage.c:110
> On Nov 29, 2016 11:58 AM, "Eric Dumazet" wrote: > > > > nv_do_nic_poll() is simply buggy and needs a fix. > > > > synchronize_irq() can sleep. > > Yes, but why did it start showing up now? None of this has changed as far as > I can see? Found one thing that changed - compiler from 6.2.0-9 to 6.2.1-5 and binutils too in debian unstable (explicitly upgraded to get fix to the binutils bug that broke 64-bit kernels). > Is it just timing and the transmit queue being busy? Perhaps due to the sheer > size of messages? Meelis does seem to have a ton of debugging enabled.. Well, the dmesg is not too verbose but when I debugged some earlier problem, netconsole and many other debugging options were left on. -- Meelis Roos (mr...@linux.ee)
Re: 4.9-rc7: (forcedeth?) BUG: sleeping function called from invalid context at kernel/irq/manage.c:110
> On Tue, Nov 29, 2016 at 12:26 PM, Meelis Roos wrote: > > This is 4.9-rc7 on Sun Ultra 20 (Opteron 175 on NVidia chipset PC with > > NVidia ethernet). > > > > BUG: sleeping function called from invalid context at > > kernel/irq/manage.c:110 > > Hmm. No changes in either forcedeth or in the synchronize_irq() debugging. [...] > But none of this looks new. I don't see _anything_ in any of these > areas that has changed since 4.8. > > Which is why I suspect you changed something in your setup wrt > netconsole or your kernel config? No changes that I could see. Only answered oldconfig questions, diff below. /etc/default/grub is from May so not changed recently. Just verified that 4.8.0 dmesg did not contain these warnings. Conf diff and current config are below: --- .config.old 2016-10-05 14:36:03.978924440 +0300 +++ .config 2016-11-29 15:04:00.423127638 +0200 @@ -1,6 +1,6 @@ # # Automatically generated file; DO NOT EDIT. -# Linux/x86 4.8.0 Kernel Configuration +# Linux/x86 4.9.0-rc7 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y @@ -45,6 +45,7 @@ CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y +CONFIG_THREAD_INFO_IN_TASK=y # # General setup @@ -274,6 +275,8 @@ CONFIG_OLD_SIGSUSPEND3=y CONFIG_COMPAT_OLD_SIGACTION=y # CONFIG_CPU_NO_EFFICIENT_FFS is not set +CONFIG_HAVE_ARCH_VMAP_STACK=y +CONFIG_VMAP_STACK=y # # GCOV-based kernel profiling @@ -288,7 +291,6 @@ CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y -# CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_MODULE_SIG is not set # CONFIG_MODULE_COMPRESS is not set @@ -325,6 +327,7 @@ # CONFIG_SYSV68_PARTITION is not set # CONFIG_CMDLINE_PARTITION is not set CONFIG_BLOCK_COMPAT=y +CONFIG_BLK_MQ_PCI=y # # IO Schedulers @@ -597,7 +600,7 @@ CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m -CONFIG_CPU_FREQ_GOV_SCHEDUTIL=m +CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y # # CPU frequency scaling drivers @@ -648,6 +651,7 @@ CONFIG_PCIEASPM_PERFORMANCE=y CONFIG_PCIE_PME=y # CONFIG_PCIE_DPC is not set +# CONFIG_PCIE_PTM is not set CONFIG_PCI_BUS_ADDR_T_64BIT=y CONFIG_PCI_MSI=y CONFIG_PCI_MSI_IRQ_DOMAIN=y @@ -666,6 +670,7 @@ # PCI host controller drivers # # CONFIG_PCIE_DW_PLAT is not set +# CONFIG_VMD is not set CONFIG_ISA_DMA_API=y CONFIG_AMD_NB=y # CONFIG_PCCARD is not set @@ -692,7 +697,6 @@ CONFIG_KEYS_COMPAT=y CONFIG_X86_DEV_DMA_OPS=y CONFIG_PMC_ATOM=y -# CONFIG_VMD is not set CONFIG_NET=y CONFIG_NET_INGRESS=y @@ -834,9 +838,10 @@ CONFIG_NF_TABLES_NETDEV=m CONFIG_NFT_EXTHDR=m CONFIG_NFT_META=m +CONFIG_NFT_NUMGEN=m CONFIG_NFT_CT=m -CONFIG_NFT_RBTREE=m -CONFIG_NFT_HASH=m +CONFIG_NFT_SET_RBTREE=m +CONFIG_NFT_SET_HASH=m CONFIG_NFT_COUNTER=m CONFIG_NFT_LOG=m CONFIG_NFT_LIMIT=m @@ -844,9 +849,11 @@ CONFIG_NFT_REDIR=m CONFIG_NFT_NAT=m CONFIG_NFT_QUEUE=m +CONFIG_NFT_QUOTA=m CONFIG_NFT_REJECT=m CONFIG_NFT_REJECT_INET=m CONFIG_NFT_COMPAT=m +CONFIG_NFT_HASH=m CONFIG_NF_DUP_NETDEV=m CONFIG_NFT_DUP_NETDEV=m CONFIG_NFT_FWD_NETDEV=m @@ -958,7 +965,6 @@ # CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_CONNTRACK_IPV4=m -CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_NF_TABLES_IPV4=m CONFIG_NFT_CHAIN_ROUTE_IPV4=m CONFIG_NFT_REJECT_IPV4=m @@ -1123,6 +1129,7 @@ # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set # CONFIG_AF_KCM is not set +# CONFIG_STREAM_PARSER is not set CONFIG_FIB_RULES=y # CONFIG_WIRELESS is not set # CONFIG_WIMAX is not set @@ -1159,6 +1166,7 @@ CONFIG_ALLOW_DEV_COREDUMP=y # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set +# CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_GENERIC_CPU_DEVICES is not set CONFIG_GENERIC_CPU_AUTOPROBE=y @@ -1237,7 +1245,6 @@ # CONFIG_SENSORS_APDS990X is not set # CONFIG_HMC6352 is not set # CONFIG_DS1682 is not set -# CONFIG_BMP085_I2C is not set # CONFIG_USB_SWITCH_FSA9480 is not set # CONFIG_SRAM is not set # CONFIG_PANEL is not set @@ -1387,6 +1394,7 @@ CONFIG_SCSI_MPT2SAS_MAX_SGE=128 CONFIG_SCSI_MPT3SAS_MAX_SGE=128 CONFIG_SCSI_MPT2SAS=m +# CONFIG_SCSI_SMARTPQI is not set # CONFIG_SCSI_UFSHCD is not set # CONFIG_SCSI_HPTIOP is not set CONFIG_SCSI_BUSLOGIC=m @@ -1542,7 +1550,6 @@ # CONFIG_NET_FC is not set # CONFIG_NET_TEAM is not set # CONFIG_MACVLAN is not set -# CONFIG_IPVLAN is not set # CONFIG_VXLAN is not set # CONFIG_MACSEC is not set CONFIG_NETCONSOLE=y @@ -1568,6 +1575,7 @@ # CONFIG_NET_VENDOR_AGERE is not set # CONFIG_NET_VENDOR_ALTEON is not set # CONFIG_ALTERA_TSE is not set +# CONFIG_NET_VENDOR_AMAZON is not set # CONFIG_NET_VENDOR_AMD is not set # CONFIG_NET_VENDOR_ARC is not set # CONFIG_NET_VENDOR_ATHEROS is not set @@ -1654,37 +1662,43 @@ CONFIG_PHYLIB=m # +# MDIO bus device drivers +# +# CONFIG_MDIO_BCM_UNIMAC is n
4.9-rc7: (forcedeth?) BUG: sleeping function called from invalid context at kernel/irq/manage.c:110
This is 4.9-rc7 on Sun Ultra 20 (Opteron 175 on NVidia chipset PC with NVidia ethernet). BUG: sleeping function called from invalid context at kernel/irq/manage.c:110 appears twice during bootup - once during usb init when nvidia ethernet irq(?) comes in, and orher time during amd64_edac init when nv irq comes in. This is the only kernel so far after 4.8.0 that I have tested so I do not know when exactly this started. Full dmesg: [0.00] Linux version 4.9.0-rc7-7-g88abd82 (mroos@u20) (gcc version 6.2.1 20161124 (Debian 6.2.1-5) ) #12 SMP Tue Nov 29 16:40:15 EET 2016 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-rc7-7-g88abd82 root=/dev/sda1 ro netconsole=1980@192.168.78.12/eth0,1975@192.168.78.2/00:16:3e:67:55:38 [0.00] x86/fpu: Legacy x87 FPU detected. [0.00] x86/fpu: Using 'eager' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x000977ff] usable [0.00] BIOS-e820: [mem 0x00097800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbfed] usable [0.00] BIOS-e820: [mem 0xbfee-0xbfee2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbfee3000-0xbfee] ACPI data [0.00] BIOS-e820: [mem 0xbfef-0xbfef] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00013fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.3 present. [0.00] DMI: Sun Microsystems Sun Ultra 20 Workstation/2864, BIOS 2.3.0 05/15/2008 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] AGP: No AGP bridge found [0.00] e820: last_pfn = 0x14 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C7FFF write-protect [0.00] C8000-F uncachable [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask FF8000 write-back [0.00] 1 base 008000 mask FFC000 write-back [0.00] 2 base 00BFF0 mask F0 uncachable [0.00] 3 base 01 mask FFC000 write-back [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] total RAM covered: 4095M [0.00] Found optimal setting for mtrr clean up [0.00] gran_size: 64K chunk_size: 2M num_reg: 4 lose cover RAM: 0G [0.00] e820: update [mem 0xbff0-0x] usable ==> reserved [0.00] e820: last_pfn = 0xbfee0 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000f3a10-0x000f3a1f] mapped at [880f3a10] [0.00] Base memory trampoline at [88091000] 91000 size 24576 [0.00] BRK [0x0245a000, 0x0245afff] PGTABLE [0.00] BRK [0x0245b000, 0x0245bfff] PGTABLE [0.00] BRK [0x0245c000, 0x0245cfff] PGTABLE [0.00] BRK [0x0245d000, 0x0245dfff] PGTABLE [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F7BC0 14 (v00 SUNW ) [0.00] ACPI: RSDT 0xBFEE3040 34 (v01 SUNW AWRDACPI 42302E31 AWRD ) [0.00] ACPI: FACP 0xBFEE30C0 74 (v01 SUNW AWRDACPI 42302E31 AWRD ) [0.00] ACPI: DSDT 0xBFEE3180 00611A (v01 SUNW AWRDACPI 1000 MSFT 010E) [0.00] ACPI: FACS 0xBFEE 40 [0.00] ACPI: SSDT 0xBFEE93C0 0001CA (v01 PTLTD POWERNOW 0001 LTP 0001) [0.00] ACPI: SRAT 0xBFEE9600 C8 (v01 AMDHAMMER 0001 AMD 0001) [0.00] ACPI: APIC 0xBFEE9300 72 (v01 SUNW AWRDACPI 42302E31 AWRD ) [0.00] ACPI: Local APIC address 0xfee0 [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x0001-0x00013fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x00096fff] [0.00] node 0: [mem 0x0010-0xbfed] [0.00] node 0: [mem 0x0001-0x00013fff] [0.00] Initmem setup node 0 [mem 0x1000-0x000
Re: tg3 BUG: spinlock lockup suspected
> Can you please share the Linux Distribution information along with sparc > machine specification. Sun Fire V210 (dual UltraSPARC IIIi), onboard NICs with tg3 driver. Debian unstable snapshot (as last seen in Debian): deb http://snapshot.debian.org/archive/debian/20150725T121538Z/ unstable main contrib non-free except for udev and libudev1 that are 218-8 (older) because the latest udev at that moment was broken. This implies gcc version 4.9.3 (Debian 4.9.3-2). > Regards, > Deepak Khungar > > On Wed, Oct 19, 2016 at 10:18 AM, Siva Reddy Kallam > wrote: > On Mon, Oct 17, 2016 at 6:35 PM, Meelis Roos wrote: > >> > Now I reproduced the bug even with 4.7-rc1 so it is older than > 4.7. Will > >> > test further. > >> > >> It gets stranger and stranger - my old 4.7 image worked fine, freshly > >> compiled 4.7 exhibits the same problem. > >> > >> Toolchain has not changed, that I know for sure. > >> > >> What may have changed is kernel .config. My old conf was with > whatever I > >> had during 4.7. Then I upgraded to 4.8-rc3 and then 4.8 and selected > >> values for "make oldconfig" new entries. Then went back to 4.7-rc1 > and > >> then to 4.7 with this config, answering quiestion about new options > when > >> any appeared. Diff is not available since I do not have the old > configs > >> archived. > > > > I did some more digging. Found an older configuration that is working > > and recreated a newer one that is bad, for the same 4.7 kernel. This > is > > reproducible now, from "make clean" state. > > > > Working config from 4.7-rc4 attached as config-4.7, broken config from > > 4.7 attached as config-4.7-bad. > > > > Will try to bisect the configs as time permits. But looking at the > > stack traces, the issue is probably timing related, when ip and > dhclient > > do something with the same lock. seq_read that outputs stats could be > > reading /proc/net/dev that reads counters from each interface. > > > > ifupdown seems to use the following for dhcp interfaces: > > up > > [[/bin/ip link set dev %iface% address %hwaddress%]] > > /sbin/dhclient -v -pf /run/dhclient.%iface%.pid -lf > /var/lib/dhcp/dhclient.%iface%.leases -I -df > /var/lib/dhcp/dhclient6.%iface%.leases %iface% \ > > ... > > > > so ip link is setting link up, this creates some work for the > > background, and the dhclient goes adn reads /proc/net/dev, and lockup > is > > suspected but not proven? > > > > I started a loop for test, doing cat /proc/net/dev in a loop and at > the > > same link link up and down from console, but up and down is slow > process > > and the loop did not seem to trigger the warning over night, so it was > > not so simple. > > > I am busy with other priority tasks. One of my colleague Deepak will > work this with you. > I added him to CC list. > Thanks. > > > >> > > [ 83.716570] BUG: spinlock lockup suspected on CPU#0, > dhclient/1014 > >> > > [ 83.797819] lock: 0xfff000123c8e4a08, .magic: dead4ead, > .owner: ip/1001, .owner_cpu: 1 > >> > > [ 83.903130] CPU: 0 PID: 1014 Comm: dhclient Not tainted 4.8.0 > #4 > >> > > [ 83.982129] Call Trace: > >> > > [ 84.014160] [004b7220] spin_dump+0x60/0xa0 > >> > > [ 84.078203] [004b73a0] do_raw_spin_lock+0xa0/0x120 > >> > > [ 84.106344] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > >> > > [ 84.107193] ip (1001) used greatest stack depth: 2168 bytes > left > >> > > [ 84.306955] [0092c0d0] _raw_spin_lock_bh+0x30/0x40 > >> > > [ 84.380188] [100822cc] tg3_get_stats64+0xc/0x80 [tg3] > >> > > [ 84.456885] [007fac8c] dev_get_stats+0x2c/0xc0 > >> > > [ 84.525506] [0081a4e8] dev_seq_printf_stats+0x8/0xe0 > >> > > [ 84.600986] [0081a5e4] dev_seq_show+0x24/0x40 > >> > > [ 84.668467] [005cb6c4] seq_read+0x2c4/0x440 > >> > > [ 84.733656] [0060b97c] proc_reg_read+0x3c/0x80 > >> > > [ 84.802282] [005a219c] __vfs_read+0x1c
Re: tg3 BUG: spinlock lockup suspected
> git bisect bad 4c5773f9f5462dcb372857813918bbfe8c0cdcdd > > # first bad commit: [4c5773f9f5462dcb372857813918bbfe8c0cdcdd] dt-bindings: > > clock: Add license and reformat Exynos5410 clock IDs > > > > > > > > > > [ 74.123859] tg3.c:v3.137 (May 11, 2014) > > > [ 74.123880] PCI: Enabling device: (:00:02.0), cmd 2 > > > [ 74.315794] tg3 :00:02.0 (unnamed net_device) (uninitialized): > > > Cannot get nvram lock, tg3_nvram_init failed > > > [ 74.656152] tg3 :00:02.0 eth0: Tigon3 [partno(none) rev 2003] > > > (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:85 > > > [ 74.656160] tg3 :00:02.0 eth0: attached PHY is 5704 > > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) > > > [ 74.656167] tg3 :00:02.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] > > > ASF[0] TSOcap[1] > > > [ 74.656172] tg3 :00:02.0 eth0: dma_rwctrl[763f] > > > dma_mask[32-bit] > > > [ 74.656322] PCI: Enabling device: (:00:02.1), cmd 2 > > > [ 74.845325] tg3 :00:02.1 (unnamed net_device) (uninitialized): > > > Cannot get nvram lock, tg3_nvram_init failed > > > [ 75.184539] tg3 :00:02.1 eth1: Tigon3 [partno(none) rev 2003] > > > (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:86 > > > [ 75.184546] tg3 :00:02.1 eth1: attached PHY is 5704 > > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) > > > [ 75.184551] tg3 :00:02.1 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] > > > ASF[0] TSOcap[1] > > > [ 75.184557] tg3 :00:02.1 eth1: dma_rwctrl[763f] > > > dma_mask[32-bit] > > > [ 75.184708] PCI: Enabling device: (0003:00:02.0), cmd 2 > > > [ 75.375322] tg3 0003:00:02.0 (unnamed net_device) (uninitialized): > > > Cannot get nvram lock, tg3_nvram_init failed > > > [ 75.714681] tg3 0003:00:02.0 eth2: Tigon3 [partno(none) rev 2003] > > > (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:87 > > > [ 75.714688] tg3 0003:00:02.0 eth2: attached PHY is 5704 > > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) > > > [ 75.714694] tg3 0003:00:02.0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] > > > ASF[0] TSOcap[1] > > > [ 75.714699] tg3 0003:00:02.0 eth2: dma_rwctrl[763f] > > > dma_mask[32-bit] > > > [ 75.714819] PCI: Enabling device: (0003:00:02.1), cmd 2 > > > [ 75.905278] tg3 0003:00:02.1 (unnamed net_device) (uninitialized): > > > Cannot get nvram lock, tg3_nvram_init failed > > > [ 76.244470] tg3 0003:00:02.1 eth3: Tigon3 [partno(none) rev 2003] > > > (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:88 > > > [ 76.244477] tg3 0003:00:02.1 eth3: attached PHY is 5704 > > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) > > > [ 76.244482] tg3 0003:00:02.1 eth3: RXcsums[1] LinkChgREG[0] MIirq[0] > > > ASF[0] TSOcap[1] > > > [ 76.244488] tg3 0003:00:02.1 eth3: dma_rwctrl[763f] > > > dma_mask[32-bit] > > > [ 83.643317] tg3 :00:02.0 eth0: No firmware running > > > [...] > > > [ 83.716570] BUG: spinlock lockup suspected on CPU#0, dhclient/1014 > > > [ 83.797819] lock: 0xfff000123c8e4a08, .magic: dead4ead, .owner: > > > ip/1001, .owner_cpu: 1 > > > [ 83.903130] CPU: 0 PID: 1014 Comm: dhclient Not tainted 4.8.0 #4 > > > [ 83.982129] Call Trace: > > > [ 84.014160] [004b7220] spin_dump+0x60/0xa0 > > > [ 84.078203] [004b73a0] do_raw_spin_lock+0xa0/0x120 > > > [ 84.106344] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > > > [ 84.107193] ip (1001) used greatest stack depth: 2168 bytes left > > > [ 84.306955] [0092c0d0] _raw_spin_lock_bh+0x30/0x40 > > > [ 84.380188] [100822cc] tg3_get_stats64+0xc/0x80 [tg3] > > > [ 84.456885] [007fac8c] dev_get_stats+0x2c/0xc0 > > > [ 84.525506] [0081a4e8] dev_seq_printf_stats+0x8/0xe0 > > > [ 84.600986] [0081a5e4] dev_seq_show+0x24/0x40 > > > [ 84.668467] [005cb6c4] seq_read+0x2c4/0x440 > > > [ 84.733656] [0060b97c] proc_reg_read+0x3c/0x80 > > > [ 84.802282] [005a219c] __vfs_read+0x1c/0x140 > > > [ 84.868613] [005a2310] vfs_read+0x50/0x100 > > > [ 84.932662] [005a265c] SyS_read+0x3c/0xa0 > > > [ 84.995573] [004061d4] linux_sparc_syscall32+0x34/0x60 > > > [ 85.073748] * CPU[ 0]: TSTATE[0044f0001a22] TPC[f79a16b0] > > > TNPC[f79a16b4] TASK[dhclient:1014] > > > [ 85.208732] TPC[f79a16b0] O7[f79405c8] I7[0] RPC[0] > > > [ 85.287633] CPU[ 1]: TSTATE[004480001605] TPC[004b26f0] > > > TNPC[004d0b0c] TASK[swapper/1:0] > > > [ 85.420338] TPC[trace_hardirqs_off+0x10/0x20] > > > O7[rcu_idle_enter+0x64/0xa0] I7[cpu_startup_entry+0x1b0/0x240] > > > RPC[rest_init+0x178/0x1a0] > > > [ 85.664600] tg3 :00:02.0 eth0: Link is up at 100 Mbps, full duplex > > > [ 85.750515] tg3 :00:02.0 eth0: Flow control is off for TX and off > > > for RX > > > [ 85.843994] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > > > > > > > > > > > -- Meelis Roos (mr...@linux.ee)
Re: tg3 BUG: spinlock lockup suspected
> On Sat, Oct 8, 2016 at 10:15 PM, Meelis Roos wrote: > >> That did not go well - bisect found the following commit but that does > >> not seem to be related at all. So probably the reproducibility is not > >> 100% but more random. > > > > Now I reproduced the bug even with 4.7-rc1 so it is older than 4.7. Will > > test further. > > > Thanks for reporting this. We will look into this. > Any specific steps to reproduce this? I just boot up my Sun Fire V210 and I get the warning during bootup. Net is working fine after that. Config below. # # Automatically generated file; DO NOT EDIT. # Linux/sparc64 4.7.0 Kernel Configuration # CONFIG_64BIT=y CONFIG_SPARC=y # CONFIG_SPARC32 is not set CONFIG_SPARC64=y CONFIG_ARCH_DEFCONFIG="arch/sparc/configs/sparc64_defconfig" CONFIG_ARCH_PROC_KCORE_TEXT=y CONFIG_IOMMU_HELPER=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_AUDIT_ARCH=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_PREFLOW_FASTEOI=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_CLOCKEVENTS=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_EXPEDITE_BOOT is not set # CONFIG_BUILD_BIN2C is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_NMI_LOG_BUF_SHIFT=13 CONFIG_CGROUPS=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_SWAP_ENABLED=y CONFIG_BLK_CGROUP=y CONFIG_DEBUG_BLK_CGROUP=y CONFIG_CGROUP_WRITEBACK=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y CONFIG_RT_GROUP_SCHED=y CONFIG_CGROUP_PIDS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_HUGETLB=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_DEBUG is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set CONFIG_PID_NS=y CONFIG_NET_NS=y # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_BPF=y # CONFIG_EXPERT is not set CONFIG_UID16=y CONFIG_MULTIUSER=y CONFIG_SGETMASK_SYSCALL=y CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_ABSOLUTE_PERCPU is not set CONFIG_KALLSYMS_BASE_RELATIVE=y CONFIG_PRINTK=y CONFIG_PRINTK_NMI=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y # CONFIG_BPF_SYSCALL is not set CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_ADVISE_SYSCALLS=y CONFIG_USERFAULTFD=y CONFIG_PCI_QUIRKS=y CONFIG_MEMBARRIER=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y CONFIG_SLUB_CPU_PARTIAL=y # CONFIG_SYSTEM_DATA_VERIFICATION is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_JUMP_LABEL=y # CONFIG_STATIC_KEYS_SELFTEST is not set # CONFIG_UPROBES is not set CONFIG_HAVE_64BIT_ALIGNED_ACCESS=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_NMI=y CONFIG_HAVE_NMI_WATCHDOG=y CONFIG_HA
Re: tg3 BUG: spinlock lockup suspected
evice: (:00:02.1), cmd 2 > > [ 74.845325] tg3 :00:02.1 (unnamed net_device) (uninitialized): > > Cannot get nvram lock, tg3_nvram_init failed > > [ 75.184539] tg3 :00:02.1 eth1: Tigon3 [partno(none) rev 2003] > > (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:86 > > [ 75.184546] tg3 :00:02.1 eth1: attached PHY is 5704 > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) > > [ 75.184551] tg3 :00:02.1 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] > > ASF[0] TSOcap[1] > > [ 75.184557] tg3 :00:02.1 eth1: dma_rwctrl[763f] dma_mask[32-bit] > > [ 75.184708] PCI: Enabling device: (0003:00:02.0), cmd 2 > > [ 75.375322] tg3 0003:00:02.0 (unnamed net_device) (uninitialized): > > Cannot get nvram lock, tg3_nvram_init failed > > [ 75.714681] tg3 0003:00:02.0 eth2: Tigon3 [partno(none) rev 2003] > > (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:87 > > [ 75.714688] tg3 0003:00:02.0 eth2: attached PHY is 5704 > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) > > [ 75.714694] tg3 0003:00:02.0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] > > ASF[0] TSOcap[1] > > [ 75.714699] tg3 0003:00:02.0 eth2: dma_rwctrl[763f] dma_mask[32-bit] > > [ 75.714819] PCI: Enabling device: (0003:00:02.1), cmd 2 > > [ 75.905278] tg3 0003:00:02.1 (unnamed net_device) (uninitialized): > > Cannot get nvram lock, tg3_nvram_init failed > > [ 76.244470] tg3 0003:00:02.1 eth3: Tigon3 [partno(none) rev 2003] > > (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:88 > > [ 76.244477] tg3 0003:00:02.1 eth3: attached PHY is 5704 > > (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) > > [ 76.244482] tg3 0003:00:02.1 eth3: RXcsums[1] LinkChgREG[0] MIirq[0] > > ASF[0] TSOcap[1] > > [ 76.244488] tg3 0003:00:02.1 eth3: dma_rwctrl[763f] dma_mask[32-bit] > > [ 83.643317] tg3 :00:02.0 eth0: No firmware running > > [...] > > [ 83.716570] BUG: spinlock lockup suspected on CPU#0, dhclient/1014 > > [ 83.797819] lock: 0xfff000123c8e4a08, .magic: dead4ead, .owner: > > ip/1001, .owner_cpu: 1 > > [ 83.903130] CPU: 0 PID: 1014 Comm: dhclient Not tainted 4.8.0 #4 > > [ 83.982129] Call Trace: > > [ 84.014160] [004b7220] spin_dump+0x60/0xa0 > > [ 84.078203] [004b73a0] do_raw_spin_lock+0xa0/0x120 > > [ 84.106344] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > > [ 84.107193] ip (1001) used greatest stack depth: 2168 bytes left > > [ 84.306955] [0092c0d0] _raw_spin_lock_bh+0x30/0x40 > > [ 84.380188] [100822cc] tg3_get_stats64+0xc/0x80 [tg3] > > [ 84.456885] [007fac8c] dev_get_stats+0x2c/0xc0 > > [ 84.525506] [0081a4e8] dev_seq_printf_stats+0x8/0xe0 > > [ 84.600986] [0081a5e4] dev_seq_show+0x24/0x40 > > [ 84.668467] [005cb6c4] seq_read+0x2c4/0x440 > > [ 84.733656] [0060b97c] proc_reg_read+0x3c/0x80 > > [ 84.802282] [005a219c] __vfs_read+0x1c/0x140 > > [ 84.868613] [005a2310] vfs_read+0x50/0x100 > > [ 84.932662] [005a265c] SyS_read+0x3c/0xa0 > > [ 84.995573] [004061d4] linux_sparc_syscall32+0x34/0x60 > > [ 85.073748] * CPU[ 0]: TSTATE[0044f0001a22] TPC[f79a16b0] > > TNPC[f79a16b4] TASK[dhclient:1014] > > [ 85.208732] TPC[f79a16b0] O7[f79405c8] I7[0] RPC[0] > > [ 85.287633] CPU[ 1]: TSTATE[004480001605] TPC[004b26f0] > > TNPC[004d0b0c] TASK[swapper/1:0] > > [ 85.420338] TPC[trace_hardirqs_off+0x10/0x20] > > O7[rcu_idle_enter+0x64/0xa0] I7[cpu_startup_entry+0x1b0/0x240] > > RPC[rest_init+0x178/0x1a0] > > [ 85.664600] tg3 :00:02.0 eth0: Link is up at 100 Mbps, full duplex > > [ 85.750515] tg3 :00:02.0 eth0: Flow control is off for TX and off > > for RX > > [ 85.843994] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > > > > > -- Meelis Roos (mr...@linux.ee)
Re: tg3 BUG: spinlock lockup suspected
1000Base-T > Ethernet) (WireSpeed[1], EEE[0]) > [ 75.184551] tg3 :00:02.1 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] > ASF[0] TSOcap[1] > [ 75.184557] tg3 :00:02.1 eth1: dma_rwctrl[763f] dma_mask[32-bit] > [ 75.184708] PCI: Enabling device: (0003:00:02.0), cmd 2 > [ 75.375322] tg3 0003:00:02.0 (unnamed net_device) (uninitialized): Cannot > get nvram lock, tg3_nvram_init failed > [ 75.714681] tg3 0003:00:02.0 eth2: Tigon3 [partno(none) rev 2003] > (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:87 > [ 75.714688] tg3 0003:00:02.0 eth2: attached PHY is 5704 (10/100/1000Base-T > Ethernet) (WireSpeed[1], EEE[0]) > [ 75.714694] tg3 0003:00:02.0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] > ASF[0] TSOcap[1] > [ 75.714699] tg3 0003:00:02.0 eth2: dma_rwctrl[763f] dma_mask[32-bit] > [ 75.714819] PCI: Enabling device: (0003:00:02.1), cmd 2 > [ 75.905278] tg3 0003:00:02.1 (unnamed net_device) (uninitialized): Cannot > get nvram lock, tg3_nvram_init failed > [ 76.244470] tg3 0003:00:02.1 eth3: Tigon3 [partno(none) rev 2003] > (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:88 > [ 76.244477] tg3 0003:00:02.1 eth3: attached PHY is 5704 (10/100/1000Base-T > Ethernet) (WireSpeed[1], EEE[0]) > [ 76.244482] tg3 0003:00:02.1 eth3: RXcsums[1] LinkChgREG[0] MIirq[0] > ASF[0] TSOcap[1] > [ 76.244488] tg3 0003:00:02.1 eth3: dma_rwctrl[763f] dma_mask[32-bit] > [ 83.643317] tg3 :00:02.0 eth0: No firmware running > [...] > [ 83.716570] BUG: spinlock lockup suspected on CPU#0, dhclient/1014 > [ 83.797819] lock: 0xfff000123c8e4a08, .magic: dead4ead, .owner: ip/1001, > .owner_cpu: 1 > [ 83.903130] CPU: 0 PID: 1014 Comm: dhclient Not tainted 4.8.0 #4 > [ 83.982129] Call Trace: > [ 84.014160] [004b7220] spin_dump+0x60/0xa0 > [ 84.078203] [004b73a0] do_raw_spin_lock+0xa0/0x120 > [ 84.106344] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > [ 84.107193] ip (1001) used greatest stack depth: 2168 bytes left > [ 84.306955] [0092c0d0] _raw_spin_lock_bh+0x30/0x40 > [ 84.380188] [100822cc] tg3_get_stats64+0xc/0x80 [tg3] > [ 84.456885] [007fac8c] dev_get_stats+0x2c/0xc0 > [ 84.525506] [0081a4e8] dev_seq_printf_stats+0x8/0xe0 > [ 84.600986] [0081a5e4] dev_seq_show+0x24/0x40 > [ 84.668467] [005cb6c4] seq_read+0x2c4/0x440 > [ 84.733656] [0060b97c] proc_reg_read+0x3c/0x80 > [ 84.802282] [005a219c] __vfs_read+0x1c/0x140 > [ 84.868613] [005a2310] vfs_read+0x50/0x100 > [ 84.932662] [005a265c] SyS_read+0x3c/0xa0 > [ 84.995573] [004061d4] linux_sparc_syscall32+0x34/0x60 > [ 85.073748] * CPU[ 0]: TSTATE[0044f0001a22] TPC[f79a16b0] > TNPC[f79a16b4] TASK[dhclient:1014] > [ 85.208732] TPC[f79a16b0] O7[f79405c8] I7[0] RPC[0] > [ 85.287633] CPU[ 1]: TSTATE[004480001605] TPC[004b26f0] > TNPC[004d0b0c] TASK[swapper/1:0] > [ 85.420338] TPC[trace_hardirqs_off+0x10/0x20] > O7[rcu_idle_enter+0x64/0xa0] I7[cpu_startup_entry+0x1b0/0x240] > RPC[rest_init+0x178/0x1a0] > [ 85.664600] tg3 :00:02.0 eth0: Link is up at 100 Mbps, full duplex > [ 85.750515] tg3 :00:02.0 eth0: Flow control is off for TX and off for > RX > [ 85.843994] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > -- Meelis Roos (mr...@linux.ee)
tg3 BUG: spinlock lockup suspected
I am testing 4.8 on my sparcs and got this on Sun V210 (sparc64). This is reproducible. 4.8.0-rc3-00013 did not have this problem, will bisect when I get some time. [ 74.123859] tg3.c:v3.137 (May 11, 2014) [ 74.123880] PCI: Enabling device: (:00:02.0), cmd 2 [ 74.315794] tg3 :00:02.0 (unnamed net_device) (uninitialized): Cannot get nvram lock, tg3_nvram_init failed [ 74.656152] tg3 :00:02.0 eth0: Tigon3 [partno(none) rev 2003] (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:85 [ 74.656160] tg3 :00:02.0 eth0: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) [ 74.656167] tg3 :00:02.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] [ 74.656172] tg3 :00:02.0 eth0: dma_rwctrl[763f] dma_mask[32-bit] [ 74.656322] PCI: Enabling device: (:00:02.1), cmd 2 [ 74.845325] tg3 :00:02.1 (unnamed net_device) (uninitialized): Cannot get nvram lock, tg3_nvram_init failed [ 75.184539] tg3 :00:02.1 eth1: Tigon3 [partno(none) rev 2003] (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:86 [ 75.184546] tg3 :00:02.1 eth1: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) [ 75.184551] tg3 :00:02.1 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] [ 75.184557] tg3 :00:02.1 eth1: dma_rwctrl[763f] dma_mask[32-bit] [ 75.184708] PCI: Enabling device: (0003:00:02.0), cmd 2 [ 75.375322] tg3 0003:00:02.0 (unnamed net_device) (uninitialized): Cannot get nvram lock, tg3_nvram_init failed [ 75.714681] tg3 0003:00:02.0 eth2: Tigon3 [partno(none) rev 2003] (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:87 [ 75.714688] tg3 0003:00:02.0 eth2: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) [ 75.714694] tg3 0003:00:02.0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] [ 75.714699] tg3 0003:00:02.0 eth2: dma_rwctrl[763f] dma_mask[32-bit] [ 75.714819] PCI: Enabling device: (0003:00:02.1), cmd 2 [ 75.905278] tg3 0003:00:02.1 (unnamed net_device) (uninitialized): Cannot get nvram lock, tg3_nvram_init failed [ 76.244470] tg3 0003:00:02.1 eth3: Tigon3 [partno(none) rev 2003] (PCI:66MHz:64-bit) MAC address 00:03:ba:0a:f3:88 [ 76.244477] tg3 0003:00:02.1 eth3: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) [ 76.244482] tg3 0003:00:02.1 eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] [ 76.244488] tg3 0003:00:02.1 eth3: dma_rwctrl[763f] dma_mask[32-bit] [ 83.643317] tg3 :00:02.0 eth0: No firmware running [...] [ 83.716570] BUG: spinlock lockup suspected on CPU#0, dhclient/1014 [ 83.797819] lock: 0xfff000123c8e4a08, .magic: dead4ead, .owner: ip/1001, .owner_cpu: 1 [ 83.903130] CPU: 0 PID: 1014 Comm: dhclient Not tainted 4.8.0 #4 [ 83.982129] Call Trace: [ 84.014160] [004b7220] spin_dump+0x60/0xa0 [ 84.078203] [004b73a0] do_raw_spin_lock+0xa0/0x120 [ 84.106344] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 84.107193] ip (1001) used greatest stack depth: 2168 bytes left [ 84.306955] [0092c0d0] _raw_spin_lock_bh+0x30/0x40 [ 84.380188] [100822cc] tg3_get_stats64+0xc/0x80 [tg3] [ 84.456885] [007fac8c] dev_get_stats+0x2c/0xc0 [ 84.525506] [0081a4e8] dev_seq_printf_stats+0x8/0xe0 [ 84.600986] [0081a5e4] dev_seq_show+0x24/0x40 [ 84.668467] [005cb6c4] seq_read+0x2c4/0x440 [ 84.733656] [0060b97c] proc_reg_read+0x3c/0x80 [ 84.802282] [005a219c] __vfs_read+0x1c/0x140 [ 84.868613] [005a2310] vfs_read+0x50/0x100 [ 84.932662] [005a265c] SyS_read+0x3c/0xa0 [ 84.995573] [004061d4] linux_sparc_syscall32+0x34/0x60 [ 85.073748] * CPU[ 0]: TSTATE[0044f0001a22] TPC[f79a16b0] TNPC[f79a16b4] TASK[dhclient:1014] [ 85.208732] TPC[f79a16b0] O7[f79405c8] I7[0] RPC[0] [ 85.287633] CPU[ 1]: TSTATE[004480001605] TPC[004b26f0] TNPC[004d0b0c] TASK[swapper/1:0] [ 85.420338] TPC[trace_hardirqs_off+0x10/0x20] O7[rcu_idle_enter+0x64/0xa0] I7[cpu_startup_entry+0x1b0/0x240] RPC[rest_init+0x178/0x1a0] [ 85.664600] tg3 :00:02.0 eth0: Link is up at 100 Mbps, full duplex [ 85.750515] tg3 :00:02.0 eth0: Flow control is off for TX and off for RX [ 85.843994] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready -- Meelis Roos (mr...@linux.ee)
Re: Invalid sk_policy[] access (was Re: Recent spontaneous reboots on multiple machines)
0004 o3: 0001 [49484.991904] o4: fff014eb2000 o5: sp: fff00077ec21 ret_pc: 00522cc4 [49485.110966] RPC: [49485.177406] l0: fff000223d0b0268 l1: 009fa7a0 l2: 00030045 l3: fff0028d38a0 [49485.291906] l4: l5: 8000 l6: 0001 l7: 0008 [49485.406595] i0: 000c001ce018 i1: 000c002f10dc i2: 0008 i3: fff000223b9485f0 [49485.520994] i4: fff000223b9485f1 i5: 000c001ce018 i6: fff00077ecd1 i7: 005230fc [49485.635479] I7: [49485.685801] Call Trace: [49485.717828] [005230fc] rmap_walk+0x17c/0x400 [49485.784187] [0052374c] try_to_unmap+0x6c/0x180 [49485.852812] [00539fa8] migrate_pages+0x328/0x7e0 [49485.923742] [0050fb98] compact_zone+0x458/0x640 [49485.993612] [0050fdd8] compact_zone_order+0x58/0x80 [49486.067974] [00510430] try_to_compact_pages+0xd0/0x240 [49486.145859] [004f392c] __alloc_pages_direct_compact+0x2c/0x160 [49486.232789] [004f3e98] __alloc_pages_nodemask+0x438/0xa20 [49486.314007] [0053dd2c] do_huge_pmd_anonymous_page+0x10c/0x520 [49486.399812] [00518c34] handle_mm_fault+0xbb4/0x14e0 [49486.474268] [0044dd3c] do_sparc64_fault+0x43c/0x720 [49486.548713] [00407c30] sparc64_realfault_common+0x10/0x20 [49486.629931] Caller[005230fc]: rmap_walk+0x17c/0x400 [49486.703246] Caller[0052374c]: try_to_unmap+0x6c/0x180 [49486.778740] Caller[00539fa8]: migrate_pages+0x328/0x7e0 [49486.856521] Caller[0050fb98]: compact_zone+0x458/0x640 [49486.933164] Caller[0050fdd8]: compact_zone_order+0x58/0x80 [49487.014386] Caller[00510430]: try_to_compact_pages+0xd0/0x240 [49487.099029] Caller[004f392c]: __alloc_pages_direct_compact+0x2c/0x160 [49487.192824] Caller[004f3e98]: __alloc_pages_nodemask+0x438/0xa20 [49487.280913] Caller[0053dd2c]: do_huge_pmd_anonymous_page+0x10c/0x520 [49487.373664] Caller[00518c34]: handle_mm_fault+0xbb4/0x14e0 [49487.454883] Caller[0044dd3c]: do_sparc64_fault+0x43c/0x720 [49487.536103] Caller[00407c30]: sparc64_realfault_common+0x10/0x20 [49487.624366] Caller[f4fffbfc]: 0xf4fffbfc [49487.685011] Instruction DUMP: 0100 0100 10680007 c3f21002 80a08001 2268 90102001 c45a -- Meelis Roos (mr...@linux.ee)
Re: Invalid sk_policy[] access (was Re: Recent spontaneous reboots on multiple machines)
> I figured out what's the root-cause of my panics. Great! > sizeof 32-bit64-bit > --- > request_sock 256 312 > inet_request_sock 272 328 > sock 688 1216 > > And offsetof sk_policy[1] is 256 on the 32-bit v440, whereas > it is 520 on my 64-bit T5. Sorry, I do not understand - what is 32-bit on V440? The kernel should be 64-bit since it's sun4u. > so how is this supposed to work? (Evidently it worked for Meelis > before, but I dont know if that was before or after commit > 9e17f8a475). It might be related to my problem, yes (I have different kernel configs on different machines and the XFRM settings are varying at least). However, I have not succeeded in reproducing the problem at will - git checkout of another release + subsequent compile still does not trigger it. But if it is the same problem, it seems to go int triple fault or something similar for me to cause it reboot with no trace in the console. -- Meelis Roos (mr...@linux.ee)
inet_hashtables.c: warning: division by zero
Noticed this while compiling 4.2-rc7+git on i386 with gcc 4.9.2: CC net/ipv4/inet_hashtables.o In file included from include/linux/list.h:8:0, from include/linux/module.h:9, from net/ipv4/inet_hashtables.c:16: net/ipv4/inet_hashtables.c: In function ‘inet_ehash_locks_alloc’: net/ipv4/inet_hashtables.c:632:24: warning: division by zero [-Wdiv-by-zero] 2 * L1_CACHE_BYTES / sizeof(spinlock_t), ^ include/linux/kernel.h:769:17: note: in definition of macro ‘max_t’ type __max1 = (x); \ ^ -- Meelis Roos (mr...@linux.ee) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4.1 regression in resizable hashtable tests
> > [ 31.898697] Running resizable hashtable tests... > > [ 31.898915] Adding 2048 keys > > [ 31.952911] Traversal complete: counted=17, nelems=2048, entries=2048 > > [ 31.953004] Test failed: Total count mismatch ^^^ > > [ 32.022676] Traversal complete: counted=17, nelems=2048, entries=2048 > > [ 32.022788] Test failed: Total count mismatch ^^^ > > [ 32.022828] Deleting 2048 keys > > Thanks for the report. I think this is already fixed. Can you try with the > following commit: > > commit 246b23a7695bd5a457aa51a36a948cce53d1d477 Tried todays got, it's actually worse: [0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36' [0.00] PROMLIB: Root node compatible: [0.00] Linux version 4.1.0-12127-g4da3064 (mroos@u5) (gcc version 4.9.2 (Debian 4.9.2-20) ) #19 Thu Jul 2 21:09:48 EEST 2015 [0.00] bootconsole [earlyprom0] enabled [0.00] ARCH: SUN4U [0.00] Ethernet address: 08:00:20:f8:c7:72 [0.00] MM: PAGE_OFFSET is 0xf800 (max_phys_bits == 40) [0.00] MM: VMALLOC [0x0001 --> 0x0600] [0.00] MM: VMEMMAP [0x0600 --> 0x0c00] [0.00] Kernel: Using 10 locked TLB entries for main kernel image. [0.00] Remapping the kernel... done. [0.00] kmemleak: Kernel memory leak detector disabled [0.00] OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,40:a [0.00] PROM: Built device tree with 70266 bytes of memory. [0.00] Top of RAM: 0x1ff2c000, Total RAM: 0x1ff2a000 [0.00] Memory hole size: 0MB [0.00] Allocated 16384 bytes for kernel page tables. [0.00] Zone ranges: [0.00] Normal [mem 0x-0x1ff2bfff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x1fefdfff] [0.00] node 0: [mem 0x1ff0-0x1ff2bfff] [0.00] Initmem setup node 0 [mem 0x-0x1ff2bfff] [0.00] On node 0 totalpages: 65429 [0.00] Normal zone: 512 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 65429 pages, LIFO batch:15 [0.00] Booting Linux... [0.00] CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus] [0.00] CPU CAPS: [vis] [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64917 [0.00] Kernel command line: root=/dev/sda1 ro [0.00] PID hash table entries: 2048 (order: 1, 16384 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 524288 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 262144 bytes) [0.00] Sorting __ex_table... [0.00] Memory: 475912K/523432K available (5266K kernel code, 516K rwdata, 1672K rodata, 520K init, 30210K bss, 47520K reserved, 0K cma-reserved) [0.00] Running RCU self tests [0.00] Testing tracer nop: PASSED [0.00] NR_IRQS:2048 nr_irqs:2048 1 [ 26.997388] clocksource: tick: mask: 0x max_cycles: 0x5306eb473f, max_idle_ns: 440795213232 ns [ 27.101123] clocksource: mult[2c71c72] shift[24] [ 27.140662] clockevent: mult[5c28f5c3] shift[32] [ 27.182668] Console: colour dummy device 80x25 [ 27.218768] console [tty0] enabled [ 27.243489] bootconsole [earlyprom0] disabled [ 27.279960] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 27.280027] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 27.280070] ... MAX_LOCK_DEPTH: 48 [ 27.280114] ... MAX_LOCKDEP_KEYS:8191 [ 27.280159] ... CLASSHASH_SIZE: 4096 [ 27.280204] ... MAX_LOCKDEP_ENTRIES: 32768 [ 27.280250] ... MAX_LOCKDEP_CHAINS: 65536 [ 27.280295] ... CHAINHASH_SIZE: 32768 [ 27.280341] memory used by lock dependency info: 8159 kB [ 27.280392] per task-struct memory footprint: 1920 bytes [ 27.280443] [ 27.280480] | Locking API testsuite: [ 27.280518] [ 27.280584] | spin |wlock |rlock |mutex | wsem | rsem | [ 27.280650] -- [ 27.280755] A-A deadlock: ok | ok | ok | ok | ok | ok | [ 27.347473] A-B-B-A deadlock: ok | ok | ok | ok | ok | ok | [ 27.414742] A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok | [ 27.482380] A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok | [ 27.550106] A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok | ok | ok | [ 27.618220] A-B-C-D-B-D-D-A deadlock: ok | ok
4.1 regression in resizable hashtable tests
This is 4.1 on sparc64 - one of my boxes that happens to have most runtime test left on from some debugging effort. In 4.0 it was fine, 4.1 gives this in dmesg: [ 31.898697] Running resizable hashtable tests... [ 31.898915] Adding 2048 keys [ 31.952911] Traversal complete: counted=17, nelems=2048, entries=2048 [ 31.953004] Test failed: Total count mismatch ^^^ [ 32.022676] Traversal complete: counted=17, nelems=2048, entries=2048 [ 32.022788] Test failed: Total count mismatch ^^^ [ 32.022828] Deleting 2048 keys Full dmesg: [0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 2001/07/25 20:36' [0.00] PROMLIB: Root node compatible: [0.00] Linux version 4.1.0 (mroos@u5) (gcc version 4.9.2 (Debian 4.9.2-20) ) #18 Wed Jul 1 02:33:02 EEST 2015 [0.00] bootconsole [earlyprom0] enabled [0.00] ARCH: SUN4U [0.00] Ethernet address: 08:00:20:f8:c7:72 [0.00] MM: PAGE_OFFSET is 0xf800 (max_phys_bits == 40) [0.00] MM: VMALLOC [0x0001 --> 0x0600] [0.00] MM: VMEMMAP [0x0600 --> 0x0c00] [0.00] Kernel: Using 6 locked TLB entries for main kernel image. [0.00] Remapping the kernel... done. [0.00] kmemleak: Kernel memory leak detector disabled [0.00] OF stdout device is: /pci@1f,0/pci@1,1/ebus@1/se@14,40:a [0.00] PROM: Built device tree with 70282 bytes of memory. [0.00] Top of RAM: 0x1ff3e000, Total RAM: 0x1ff2e000 [0.00] Memory hole size: 0MB [0.00] Allocated 16384 bytes for kernel page tables. [0.00] Zone ranges: [0.00] Normal [mem 0x-0x1ff3dfff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x1fefdfff] [0.00] node 0: [mem 0x1ff0-0x1ff2bfff] [0.00] node 0: [mem 0x1ff3a000-0x1ff3dfff] [0.00] Initmem setup node 0 [mem 0x-0x1ff3dfff] [0.00] On node 0 totalpages: 65431 [0.00] Normal zone: 512 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 65431 pages, LIFO batch:15 [0.00] Booting Linux... [0.00] CPU CAPS: [flush,stbar,swap,muldiv,v9,mul32,div32,v8plus] [0.00] CPU CAPS: [vis] [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64919 [0.00] Kernel command line: root=/dev/sda1 ro [0.00] PID hash table entries: 2048 (order: 1, 16384 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 524288 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 262144 bytes) [0.00] Sorting __ex_table... [0.00] Memory: 491632K/523448K available (5216K kernel code, 509K rwdata, 1656K rodata, 520K init, 14578K bss, 31816K reserved, 0K cma-reserved) [0.00] Running RCU self tests [0.00] Testing tracer nop: PASSED [0.00] NR_IRQS:2048 nr_irqs:2048 1 [ 25.662551] clocksource tick: mask: 0x max_cycles: 0x5306eb473f, max_idle_ns: 440795213232 ns [ 25.765203] clocksource: mult[2c71c72] shift[24] [ 25.804735] clockevent: mult[5c28f5c3] shift[32] [ 25.846767] Console: colour dummy device 80x25 [ 25.882817] console [tty0] enabled [ 25.907574] bootconsole [earlyprom0] disabled [ 25.944044] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 25.944112] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 25.944151] ... MAX_LOCK_DEPTH: 48 [ 25.944190] ... MAX_LOCKDEP_KEYS:8191 [ 25.944229] ... CLASSHASH_SIZE: 4096 [ 25.944268] ... MAX_LOCKDEP_ENTRIES: 32768 [ 25.944308] ... MAX_LOCKDEP_CHAINS: 65536 [ 25.944349] ... CHAINHASH_SIZE: 32768 [ 25.944390] memory used by lock dependency info: 8159 kB [ 25.944437] per task-struct memory footprint: 1920 bytes [ 25.944483] [ 25.944516] | Locking API testsuite: [ 25.944550] [ 25.944615] | spin |wlock |rlock |mutex | wsem | rsem | [ 25.944678] -- [ 25.944780] A-A deadlock: ok | ok | ok | ok | ok | ok | [ 26.011037] A-B-B-A deadlock: ok | ok | ok | ok | ok | ok | [ 26.077813] A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok | [ 26.144938] A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok | [ 26.212077] A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok | ok | ok | [ 26.279658] A-B-C-D-B-D-D-A deadlock:
nouveau + netpoll: BUG: sleeping function called from invalid context at kernel/irq/manage.c:110
I recently activated netconsole on one of my computers to debug boot crash with big IOMMU size. Left netconsole on and got the BUG about sleeping function called from invalid context when netconsole is doing printk during nouveau initialization. Full dmesg and .configare below. [0.00] Linux version 4.1.0-rc6 (mroos@u20) (gcc version 4.9.2 (Debian 4.9.2-16) ) #54 SMP Mon Jun 1 15:28:41 EEST 2015 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.1.0-rc6 root=/dev/sda1 ro netconsole=1980@192.168.78.12/eth0,1975@192.168.78.2/00:16:3e:67:55:38 [0.00] tseg: 00bff0 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x000977ff] usable [0.00] BIOS-e820: [mem 0x00097800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbfed] usable [0.00] BIOS-e820: [mem 0xbfee-0xbfee2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbfee3000-0xbfee] ACPI data [0.00] BIOS-e820: [mem 0xbfef-0xbfef] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00013fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.3 present. [0.00] DMI: Sun Microsystems Sun Ultra 20 Workstation/2864, BIOS 2.3.0 05/15/2008 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] AGP: No AGP bridge found [0.00] e820: last_pfn = 0x14 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C7FFF write-protect [0.00] C8000-F uncachable [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask FF8000 write-back [0.00] 1 base 008000 mask FFC000 write-back [0.00] 2 base 00BFF0 mask F0 uncachable [0.00] 3 base 01 mask FFC000 write-back [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] PAT configuration [0-7]: WB WC UC- UC WB WC UC- UC [0.00] original variable MTRRs [0.00] reg 0, base: 0GB, range: 2GB, type WB [0.00] reg 1, base: 2GB, range: 1GB, type WB [0.00] reg 2, base: 3071MB, range: 1MB, type UC [0.00] reg 3, base: 4GB, range: 1GB, type WB [0.00] total RAM covered: 4095M [0.00] Found optimal setting for mtrr clean up [0.00] gran_size: 64K chunk_size: 2M num_reg: 4 lose cover RAM: 0G [0.00] New variable MTRRs [0.00] reg 0, base: 0GB, range: 2GB, type WB [0.00] reg 1, base: 2GB, range: 1GB, type WB [0.00] reg 2, base: 3071MB, range: 1MB, type UC [0.00] reg 3, base: 4GB, range: 1GB, type WB [0.00] e820: update [mem 0xbff0-0x] usable ==> reserved [0.00] e820: last_pfn = 0xbfee0 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000f3a10-0x000f3a1f] mapped at [880f3a10] [0.00] Base memory trampoline at [88091000] 91000 size 24576 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x019b3000, 0x019b3fff] PGTABLE [0.00] BRK [0x019b4000, 0x019b4fff] PGTABLE [0.00] BRK [0x019b5000, 0x019b5fff] PGTABLE [0.00] init_memory_mapping: [mem 0x13fe0-0x13fff] [0.00] [mem 0x13fe0-0x13fff] page 2M [0.00] BRK [0x019b6000, 0x019b6fff] PGTABLE [0.00] init_memory_mapping: [mem 0x12000-0x13fdf] [0.00] [mem 0x12000-0x13fdf] page 2M [0.00] init_memory_mapping: [mem 0x0010-0xbfed] [0.00] [mem 0x0010-0x001f] page 4k [0.00] [mem 0x0020-0xbfdf] page 2M [0.00] [mem 0xbfe0-0xbfed] page 4k [0.00] init_memory_mapping: [mem 0x1-0x11fff] [0.00] [mem 0x1-0x11fff] page 2M [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F7BC0 14 (v00 SUNW ) [0.00] ACPI: RSDT 0xBFEE3040 34 (v01 SUNW AWRDACPI 42302E31 AWRD ) [0.00] ACPI: FACP 0xBFEE30C0 74 (v01 SUNW AWRDACPI 42302E31 AWRD ) [0.00] ACPI: DSDT 0xBFEE3180 00611A (v01 SUNW AWRDACPI 1000 MSFT 010E) [0.00] ACPI: FACS 0xBFEE 40 [0.00] ACPI: SSDT 0x0
Re: [git patches] net driver fixes
> > Well, it's 2.6.24-rc7 already - any news? > > I put this into my net-2.6 tree last night since Jeff asked > me to look over critical networking driver stuff for a little > while. Thanks, they are upstream now and it did fix tulip in my PPC - network is stable again. -- Meelis Roos ([EMAIL PROTECTED]) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
> > JG> A couple [minorly] notable wireless bug fixes, and plenty of viro fixes > > JG> for obscure issues :) > > > > What about the tulip NAPI fix from Stephen Hemminger? Without this, my tulip > > is hosed easily. > > > > The thread where I reported it was "Badness at net/core/dev.c:2199", around > > Dec 16. > > That's going up in the first post-Xmas batch. Well, it's 2.6.24-rc7 already - any news? -- Meelis Roos ([EMAIL PROTECTED]) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
JG> A couple [minorly] notable wireless bug fixes, and plenty of viro fixes JG> for obscure issues :) What about the tulip NAPI fix from Stephen Hemminger? Without this, my tulip is hosed easily. The thread where I reported it was "Badness at net/core/dev.c:2199", around Dec 16. -- Meelis Roos ([EMAIL PROTECTED]) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Badness at net/core/dev.c:2199
> I already sendout a correct patch last week. It should pre-increment. Any hope getting it upstream? -- Meelis Roos ([EMAIL PROTECTED]) http://www.cs.ut.ee/~mroos/ -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Badness at net/core/dev.c:2199
Just got this trace from current 2.6.24-rc5+git running on 32-bit ppc (PReP subarch, tulip NIC's) during apt-get update (logged in via ssh so also ssh traffic): [ cut here ] Badness at net/core/dev.c:2199 NIP: c01ccf98 LR: c01ccf38 CTR: REGS: cfc8dce0 TRAP: 0700 Not tainted (2.6.24-rc5) MSR: 00029032 CR: 84004048 XER: 2000 TASK = cfd52db0[216] 'kjournald' THREAD: cfc8c000 GPR00: 0001 cfc8dd90 cfd52db0 0011 cbcfa4d4 cfcfc650 GPR08: 8ffcc010 cfcfc658 04e0 0006b6cf 84004022 GPR16: cfd2f214 c0295ef4 cfd51800 cfc8c000 cfd51800 0169 GPR24: c03473d8 c02d c03473d8 00a74b08 c03473b4 012c cfcfc9c4 0010 NIP [c01ccf98] net_rx_action+0x138/0x150 LR [c01ccf38] net_rx_action+0xd8/0x150 Call Trace: [cfc8dd90] [c01ccf38] net_rx_action+0xd8/0x150 (unreliable) [cfc8ddc0] [c00233f8] __do_softirq+0x88/0x110 [cfc8dde0] [c0009eb4] do_softirq+0x64/0x70 [cfc8ddf0] [c0023254] irq_exit+0x54/0x70 [cfc8de00] [c000a0f4] do_IRQ+0x64/0xe0 [cfc8de10] [c00046b4] ret_from_except+0x0/0x14 [cfc8ded0] [c00e31ec] __journal_file_buffer+0xbc/0x210 [cfc8def0] [c00e5c90] journal_commit_transaction+0x470/0x1250 [cfc8df80] [c00ea5b4] kjournald+0xc4/0x1f0 [cfc8dfd0] [c003628c] kthread+0x4c/0x90 [cfc8dff0] [c0006338] kernel_thread+0x44/0x60 Instruction dump: 9169 931e 6000 6000 813c0028 93dc0028 93c9 913e0004 4b18 801c01e4 7c34 5400d97e <0f00> 2f80 419effa0 3801 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc5 # Sat Dec 15 12:28:31 2007 # CONFIG_WORD_SIZE=32 CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor # CONFIG_6xx=y # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_8xx is not set # CONFIG_E200 is not set # CONFIG_E500 is not set CONFIG_PPC_FPU=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_ALTIVEC is not set # CONFIG_TAU is not set # CONFIG_KEXEC is not set # CONFIG_CPU_FREQ is not set # CONFIG_PPC601_SYNC_FIX is not set # CONFIG_WANT_EARLY_SERIAL is not set CONFIG_PPC_STD_MMU=y # # Platform options # CONFIG_PPC_PREP=y # CONFIG_KATANA is not set # CONFIG_WILLOW is not set # CONFIG_CPCI690 is not set # CONFIG_POWERPMC250 is not set # CONFIG_CHESTNUT is not set # CONFIG_SPRUCE is not set # CONFIG_HDPU is not set # CONFIG_EV64260 is not set # CONFIG_LOPEC is not set # CONFIG_MVME5100 is not set # CONFIG_PPLUS is not set # CONFIG_PRPMC750 is not set # CONFIG_PRPMC800 is not set # CONFIG_SANDPOINT is not set # CONFIG_RADSTONE_PPC7D is not set # CONFIG_PAL4 is not set # CONFIG_EST8260 is not set # CONFIG_SBC82xx is not set # CONFIG_SBS8260 is not set # CONFIG_RPX8260 is not set # CONFIG_TQM8260 is not set # CONFIG_ADS8272 is not set # CONFIG_PQ2FADS is not set # CONFIG_LITE5200 is not set # CONFIG_MPC834x_SYS is not set # CONFIG_EV64360 is not set CONFIG_PPCBU
b44 & ssb link errors on sparc
MODPOST 434 modules ERROR: "ioremap" [drivers/ssb/ssb.ko] undefined! ERROR: "iounmap" [drivers/ssb/ssb.ko] undefined! ERROR: "dma_alloc_coherent" [drivers/net/b44.ko] undefined! ERROR: "dma_get_cache_alignment" [drivers/net/b44.ko] undefined! ERROR: "dma_free_coherent" [drivers/net/b44.ko] undefined! ERROR: "dma_mapping_error" [drivers/net/b44.ko] undefined! ERROR: "dma_map_single" [drivers/net/b44.ko] undefined! ERROR: "dma_sync_single_for_cpu" [drivers/net/b44.ko] undefined! ERROR: "dma_sync_single_range_for_cpu" [drivers/net/b44.ko] undefined! ERROR: "dma_unmap_single" [drivers/net/b44.ko] undefined! Do SSB and B44 need to depend on DMA API? They can be selected on 32-bit sparc architecture but do not link. This is 2.6.24-rc1 + yesterdays git. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipv4_get_l4proto: Frag of proto 17
> I'm guessing that its ICMP errors containing UDP fragments. > > Could you add a WARN_ON(1) to ipv4_get_l4proto() in > net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c to verify > this? Yes, it seems to be an ICMP error: WARNING: at net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:93 ipv4_get_l4proto() [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x15/0x17 [] ipv4_get_l4proto+0x78/0xc0 [nf_conntrack_ipv4] [] nf_ct_get_tuplepr+0x45/0xae [nf_conntrack] [] icmp_error+0x185/0x1f6 [nf_conntrack_ipv4] [] nf_conntrack_in+0xc0/0x409 [nf_conntrack] [] ipv4_conntrack_in+0x11/0x13 [nf_conntrack_ipv4] [] nf_iterate+0x36/0x67 [] nf_hook_slow+0x57/0xd6 [] ip_rcv+0x1d9/0x489 [] netif_receive_skb+0x2c9/0x34a [] rtl8139_poll+0x2a5/0x410 [8139too] [] net_rx_action+0x56/0xd5 [] __do_softirq+0x38/0x7a [] do_softirq+0x41/0x91 === ipv4_get_l4proto: Frag of proto 17 -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipv4_get_l4proto: Frag of proto 17
> > Yesterdays git snapsot on a normal home PC spams dmesg with the following > > line: > > ipv4_get_l4proto: Frag of proto 17 > > In what situation does this happen? It happens some times every hour on the average. Seems to be some UDP traffic. Firewall allows in any UDP that is ESTABLISHEFD,RELATED, DHCP (some more UDP rules with counter 0 so not important). Additionally there is internal netowkr that sometimes has a laptop but usually not and the messages have appeared also when there is nothin in the internal network. Locally mldonkey is probably using UDP, and lsof -i | grep UDP tells that named, avahi-daemon, dhcpd, chronyd, nmbd and cupsd are listening on UDP sockets (most of them on internal network). But I have no idea what application is causing the messages. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ipv4_get_l4proto: Frag of proto 17
Yesterdays git snapsot on a normal home PC spams dmesg with the following line: ipv4_get_l4proto: Frag of proto 17 -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: b44 compile error on !PCI
> > CC [M] drivers/net/b44.o > > drivers/net/b44.c: In function 'b44_sync_dma_desc_for_device': > > drivers/net/b44.c:134: error: implicit declaration of function > > 'dma_sync_single_range_for_device' > > drivers/net/b44.c: In function 'b44_sync_dma_desc_for_cpu': > > drivers/net/b44.c:144: error: implicit declaration of function > > 'dma_sync_single_range_for_cpu' > > Are you sure this is related to !PCI ? > If I grep include/asm-sparc64/dma-mapping.h I don't > find dma_sync_single_range_for_* > So I'd rather call this a bug in the arch code of sparc64. Yes, now that Dave Miller added these functions to sparc64, b44 compiles fine. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
b44 compile error on !PCI
Tryng to compile todays git on SBus-only Sparc64 (Ultra 1), no PCI. b44 is selectable but fails to compile: CC [M] drivers/net/b44.o drivers/net/b44.c: In function 'b44_sync_dma_desc_for_device': drivers/net/b44.c:134: error: implicit declaration of function 'dma_sync_single_range_for_device' drivers/net/b44.c: In function 'b44_sync_dma_desc_for_cpu': drivers/net/b44.c:144: error: implicit declaration of function 'dma_sync_single_range_for_cpu' -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ipv4 conntrack module loading broken?
Hello, I tested 2.6.23-rc1 on my prep (arch=ppc) NAT firewall. iptables loaded rules fine (simplest test was with single SNAT rule in POSTROUTING chain in nat table) and iptables -L showed the rule was loaded. But no packets matched the rule and traffic passed un-NATed (just routed). Adding LOG rules showed that no packets reach POSTROUTING at all - and no packets read PREROUTING (didn't test more). However, after loading nf_conntrack_ipv4 module by hand, the existing rules started working. Is autoloading of nf_conntrack_ipv4 broken? -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Turn nfmark into generic mark
> The mark is already a bitfield, you may dividide it into separate > marks with the exception of routes which do not yet support a > mask. Just checked, now that we have --and-mask and --or-mask, this is much better than before. The bitmask is OK when up to 32 marks are needed (like, for classification). But a common setup is NAT+QoS that first hides the src IP and then has to do QoS and mark is the only usable carrier of this information. So the mark value needs to carry both classification info and IP address info and here things become very limited. Though using say 8 bits for host should be usually enough... Maybe just add original src and/ord DST for carrying this information through SNAT/DNAT? Or is it too much bloat for carrying around? -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Turn nfmark into generic mark
Another thought: sometimes a single mark makes rulesets inconvenient. What about several independent marks on a packet? -- Meelis Roos <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] warning in SCTP
Actually, I'm backing this one out, it creates new warnings because callers of this function pass in a "const" pointer. Yes, it now seems it's not so simple. Marking it non-const there would mark the it non-const in the whole family of sctp_state_fn_t and I'm not sure that's the best thing to do. I guess the maintainer has better bases for deciding what to do about it. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] warning in SCTP
Sure. Evenso, I did test full make after the single compile was fine (still have it in my scrollback so here it is). So did I do anything wrong here or do we have some dependencies broken somewhere or what? Never mind - I discovered the warning on one box with SCTP enabled in config and tried the fix on a faster machine that unfortunately had SCTP disabled. -- Meelis Roos ([EMAIL PROTECTED]) http://www.cs.ut.ee/~mroos/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] warning in SCTP
Actually, I'm backing this one out, it creates new warnings because callers of this function pass in a "const" pointer. OK, fair enough. Will have a look. Please test the complete build when doing warning fixes like this in the future, thanks. Sure. Evenso, I did test full make after the single compile was fine (still have it in my scrollback so here it is). So did I do anything wrong here or do we have some dependencies broken somewhere or what? Now that I read the transript again I can see that despite modifying include/net/sctp/sm.h nothing was really recompiled - should have noticed. [EMAIL PROTECTED]:~/compile/linux-2.6$ vi net/sctp/sm_make_chunk.c [EMAIL PROTECTED]:~/compile/linux-2.6$ !make make net/sctp/sm_make_chunk.o CHK include/linux/version.h CHK include/linux/utsrelease.h CC net/sctp/sm_make_chunk.o net/sctp/sm_make_chunk.c:1353: error: conflicting types for 'sctp_unpack_cookie' include/net/sctp/sm.h:279: error: previous declaration of 'sctp_unpack_cookie' was here make[1]: *** [net/sctp/sm_make_chunk.o] Error 1 make: *** [net/sctp/sm_make_chunk.o] Error 2 [EMAIL PROTECTED]:~/compile/linux-2.6$ vi include/net/sctp/sm.h [EMAIL PROTECTED]:~/compile/linux-2.6$ make net/sctp/sm_make_chunk.o CHK include/linux/version.h CHK include/linux/utsrelease.h CC net/sctp/sm_make_chunk.o [EMAIL PROTECTED]:~/compile/linux-2.6$ make CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h MODPOST vmlinux Kernel: arch/i386/boot/bzImage is ready (#274) Building modules, stage 2. MODPOST 511 modules [EMAIL PROTECTED]:~/compile/linux-2.6$ cg-diff > ~/sctppatch -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] warning in SCTP
There should only be one space before the "void" in the patch, your email client (or something else) put another space there. Also, your email client likes to turn lines containing only spaces into empty lines, which also corrupts the patch. cg-diff > file and in pine 4.61 ^R read a file. So I guess it's pine misbehaving... Have not heard complaints before but will try to remember to use mutt next time. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] warning in SCTP
CC [M] net/sctp/sm_make_chunk.o net/sctp/sm_make_chunk.c: In function 'sctp_unpack_cookie': net/sctp/sm_make_chunk.c:1358: warning: initialization discards qualifiers from pointer target type The reason is that sctp_unpack_cookie() takes a const struct sctp_endpoint and modifies the digest in it (digest being embedded in the struct, not a pointer). So sctp_unpack_cookie really does not use the argument as const, mark it as such. Signed-off-by: Meelis Roos <[EMAIL PROTECTED]> diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h index de313de..ef80489 100644 --- a/include/net/sctp/sm.h +++ b/include/net/sctp/sm.h @@ -272,7 +272,7 @@ void sctp_generate_heartbeat_event(unsig void sctp_ootb_pkt_free(struct sctp_packet *); -struct sctp_association *sctp_unpack_cookie(const struct sctp_endpoint *, +struct sctp_association *sctp_unpack_cookie(struct sctp_endpoint *, const struct sctp_association *, struct sctp_chunk *, gfp_t gfp, int *err, diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c index 507dff7..3d41a9c 100644 --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -1346,7 +1346,7 @@ nodata: /* Unpack the cookie from COOKIE ECHO chunk, recreating the association. */ struct sctp_association *sctp_unpack_cookie( - const struct sctp_endpoint *ep, + struct sctp_endpoint *ep, const struct sctp_association *asoc, struct sctp_chunk *chunk, gfp_t gfp, int *error, struct sctp_chunk **errp) -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] silence a warning in ebtables
net/bridge/netfilter/ebtables.c: In function 'ebt_dev_check': net/bridge/netfilter/ebtables.c:89: warning: initialization discards qualifiers from pointer target type So make the char* a const char * and the warning is gone. Signed-off-by: Meelis Roos <[EMAIL PROTECTED]> diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c index 3df55b2..9f85666 100644 --- a/net/bridge/netfilter/ebtables.c +++ b/net/bridge/netfilter/ebtables.c @@ -86,7 +86,7 @@ static inline int ebt_do_match (struct e static inline int ebt_dev_check(char *entry, const struct net_device *device) { int i = 0; - char *devname = device->name; + const char *devname = device->name; if (*entry == '\0') return 0; -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Wrong IPv4 source address selected
This is 2.6.17-rc6 running on a 32-bit ppc (the same ARC=ppc PReP machine that had the x_tables problem, so it has the x_tables alignment first fix too). The problem: IPv4 source addresses are sometimes selected wrong (packets are sent to the internal 172.30 network with external 193.40 source address). I have seen this with ARP requests for 172.30.0.x addresses and UDP multicast traffic (avahi query from 193.40.37.61:5353 to 224.0.0.251:5353 on eth1). I have 2 physical network interfaces (+ loopback + unconfiured sit0) 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 08:00:3e:28:c4:a2 brd ff:ff:ff:ff:ff:ff inet 193.40.37.61/23 brd 193.40.37.255 scope global eth0 inet6 2001:bb8:2002:2400:a00:3eff:fe28:c4a2/64 scope global dynamic valid_lft 2591964sec preferred_lft 604764sec inet6 fe80::a00:3eff:fe28:c4a2/64 scope link valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:00:94:7a:31:8c brd ff:ff:ff:ff:ff:ff inet 172.30.0.1/24 brd 172.30.0.255 scope global eth1 inet6 fe80::200:94ff:fe7a:318c/64 scope link valid_lft forever preferred_lft forever ip route ls: 172.30.0.0/24 dev eth1 proto kernel scope link src 172.30.0.1 193.40.36.0/23 dev eth0 proto kernel scope link src 193.40.37.61 default via 193.40.36.1 dev eth0 -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
Please enable DEBUG_IP_FIREWALL_USER in net/netfilter/x_tables.c as well and retry. Results of the raw or mangle table would also be interesting because they contain a different number of built-in chains. Sorry it took so long, I was away. Adding this define does not seem to do much (table->private->number prints only): On boot (1 nat rule): ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. ip_conntrack version 2.4 (1536 buckets, 12288 max) - 224 bytes per conntrack translate_table: size 632 Finished chain 0 Finished chain 3 Finished chain 4 table->private->number = 4 t->private->number = 4 translate_table: size 800 Bad offset cba528d4 modprobe iptable_nat succeeded in manual modprobe. modprobe iptable_filter: translate_table: size 632 Bad offset cbbd910c modprobe iptable_mangle: translate_table: size 936 Bad offset cbbd80dc modprobe iptable_raw: translate_table: size 480 Bad offset cb8abd44 Retrying ifup and ifdown that tried to do iptables -D and iptables -I: t->private->number = 4 t->private->number = 4 t->private->number = 4 translate_table: size 800 Bad offset cbbd80dc t->private->number = 4 And retrying it more (succeeded this time): t->private->number = 4 t->private->number = 4 translate_table: size 800 Finished chain 0 Finished chain 3 Finished chain 4 ip_tables: Translated table do_replace: oldnum=4, initnum=4, newnum=5 t->private->number = 5 -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
Very strange, this means that the initial table data must somehow be wrong, but for some reason it still seems to get past the size and offset checks for the filter table. I can't see how loading the filter table could fail after the "Finished chain .." messages without another message. Which kernel version did you perform these test on? Yesterdays 2.6.17-rc5+git. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
Then lets try something different. Please enable the DEBUG_IP_FIREWALL_USER define in net/ipv4/netfilter/ip_tables.c and post the results, if any. On bootup I get this in dmesg (one Bad offset has been added): ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. ip_conntrack version 2.4 (1536 buckets, 12288 max) - 224 bytes per conntrack translate_table: size 632 Bad offset cb437924 ip_nat_init: can't setup rules. And on iptables -t nat -L translate_table: size 632 Bad offset cb4368f4 ip_nat_init: can't setup rules. translate_table: size 632 Bad offset cb4368f4 ip_nat_init: can't setup rules. Seems iptable_nat does not load at all this time. Modprobe iptable_filter still fails, dmesg contains translate_table: size 632 Finished chain 1 Finished chain 2 Finished chain 3 Next modprobe iptable_nat gives translate_table: size 632 Bad offset c8e01944 ip_nat_init: can't setup rules. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
modprobe iptable_filter (errors out with Invalid Argument) iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -j SNAT --to 192.168.1.1 (usually errors out with Invalid Argument, sometimes succeeds, when succeeds then the rule works fine) Meelis, it would really help if you could try 2.6.16 and in case that doesn't work 2.6.15 to give an idea about whether this is a recent regression or an old problem. We had a number of changes in this area in the last two kernel versions that could be related. Have not gotten 2.6.15 to work with one evening of tinkering - the irq patch was not sufficent, there is something more broken in booting that I dodn't figure out yet. So no test results for 2.6.15 yet. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Safe remote kernel install howto (Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc))
Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out remotely at the moment. Here it my paranoid boot setup: Thanks, but it's not much use here, since the machine is a PReP powerpc machine that can boot one kernel from disk (directly loaded from boot partition, no fancy bootloader) or netboot via serial console for test kernels. However, if the test kernel hangs, it hangs and I would need remote power cycling device that I do not have. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipv6 routing broken in 2.6.17-rc3,4
The unreachable route works now but LAN routing still does not work. Locally generated ICMPv6 packets that should go to LAN interface still go to tun6to4. Please try this. This works for both unreachable and LAN routes, thanks! -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipv6 routing broken in 2.6.17-rc3,4
(To YOSHIFUJI Hideaki: this is about the http://comments.gmane.org/gmane.linux.network/35262 thread) : I guess rt6_select() is returning &ip6_null_entry and the caller is finding next best route; e.g. default route. Does this solve your problem? Sorry, typo... The unreachable route works now but LAN routing still does not work. Locally generated ICMPv6 packets that should go to LAN interface still go to tun6to4. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
Meelis, it would really help if you could try 2.6.16 and in case that doesn't work 2.6.15 to give an idea about whether this is a recent regression or an old problem. We had a number of changes in this area in the last two kernel versions that could be related. Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out remotely at the moment. Will see if I can find the boot cure - there used to be a Motorola Powerstack-specific patch to make it boot that Debian 2.6.18 and IIRC 2.6.12 packages included and that was integrated somewhere later - maybe it's missing fom 2.6.15. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipv6 routing broken in 2.6.17-rc3,4
(To YOSHIFUJI Hideaki: this is about the http://comments.gmane.org/gmane.linux.network/35262 thread) Tracked it down to IPV6 merge at 2006-03-21: commit cd85f6e2f58282186ad720fc18482be228f0b972 is good (right before the bunch of patches) commit b00055aacdb172c05067612278ba27265fcd05ce is bad (right after the bunch of changes) http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=shortlog;h=705af309505681f197f81618440954d10f120dc0;pg=44 shows the list of committs at that range. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipv6 routing broken in 2.6.17-rc3,4
On my home 6to4 gw, ipv6 routing seems to be broken and everything is sent to 6to4 tunnel (the default route). It worked with fine for a long time and with 2.6.17-rc2-g4d5c34ec and it's broken with vmlinuz-2.6.17-rc3-g3cd73eed and 2.6.17-rc4-g9be2f7c3 (yesterdays kernel). So far I have narrowed it down to break between 2.6.16 (working) and 2.6.17-rc1 (not working). -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
http://bugzilla.kernel.org/show_bug.cgi?id=6613 Meelis, it would really help if you could try 2.6.16 and in case that doesn't work 2.6.15 to give an idea about whether this is a recent regression or an old problem. We had a number of changes in this area in the last two kernel versions that could be related. 2.6.16 doesn't work either. Tried 2.6.8-3 from sarge package, it is working. Compiling 2.6.15 now... -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
Meelis, it would really help if you could try 2.6.16 and in case that doesn't work 2.6.15 to give an idea about whether this is a recent regression or an old problem. We had a number of changes in this area in the last two kernel versions that could be related. Yes, I'm still compiling 2.6.16, since just before sending the report. Will let you know ASAP. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
32-bit kernel, this is a Motorola Powerstack II macine with 604e. PReP subarch, only buildable from the old ARCH=ppc code (not yet migrated to ARCH=powerpc). Ah OK, I thought it was related to the new compat code, but that isn't the case. Your trace doesn't give much clues, except that it shows that iptables dies with a SIGSEGV, which might be a bug in userspace or in the kernel. Which was the last kernel that worked for you, and can you try that version again to rule out userspace bugs? Even worse. With yesterdays git iptable_nat loads but iptable_filter doesn't even load (Invalid argument). -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
Ah OK, I thought it was related to the new compat code, but that isn't the case. Your trace doesn't give much clues, except that it shows that iptables dies with a SIGSEGV, which might be a bug in userspace or in the kernel. Which was the last kernel that worked for you, and can you try that version again to rule out userspace bugs? It's a fresh install in the new role with a new HDD and 2 NICs for a firewall so I have not tried earlier kernels with iptables. I do have sarge's 2.6.8 also working on that machine but not the kernels from testing and unstable (2.5.15 and 2.6.16) because the lack of prep support at the moment. I could problably compile some intermediate kernels but I haven't tested even the working 2.6.8 first with iptables yet. I will be away tomorrow but can test some kernels the day after tomorrow. Only some of them because it's not a fast compile engine. It only SIGSEGVs when ptraced and just gets Invalid Argument errors when not traced so this SEGV may be something different (perhaps ptrace related). -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
This should already be fixed in -rc4. Unfortunately it was still there with yesterdays rc4+git. I may have misinterpreted your report - are you running a 32bit or 64bit kernel? 32-bit kernel, this is a Motorola Powerstack II macine with 604e. PReP subarch, only buildable from the old ARCH=ppc code (not yet migrated to ARCH=powerpc). -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipv6 routing broken in 2.6.17-rc3,4
vaarikas:~# ip -6 route 2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 You're using the wrong prefix length. The right one is /16. Does that work? Changed tun6to4 to 2002::/16, still the same (packets for eth0 and the unreachable destination still go to tun6to4). # ip -6 route ::/96 via :: dev tun6to4 metric 256 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295 unreachable 2001:7a8:1:5::14 dev lo metric 1024 expires 21334363sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 2002:5283:2811:2::/64 dev eth0 metric 256 expires 21334342sec mtu 1500 advmss 1440 hoplimit 4294967295 2002::/16 dev tun6to4 metric 256 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295 fe80::/64 dev eth0 metric 256 expires 21332676sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth1 metric 256 expires 21334336sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev tun6to4 metric 256 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295 ff00::/8 dev eth1 metric 256 expires 21334336sec mtu 1500 advmss 1440 hoplimit 4294967295 ff00::/8 dev tun6to4 metric 256 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295 ff00::/8 dev eth0 metric 256 expires 21332676sec mtu 1500 advmss 1440 hoplimit 4294967295 unreachable default dev lo proto none metric -1 error -101 hoplimit 255 -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipv6 routing broken in 2.6.17-rc3,4
vaarikas:~# ip -6 route 2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 You're using the wrong prefix length. The right one is /16. Does that work? Will try soon today. But the other routes had mor specific masks anyway - /64 and /128, so why should it change anything? -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
Iptables seems to be broken on ppc for me. Kernel 2.6.17-rc3 (currently compiling rc4+git). 32-bit ppc, ARCH=ppc with PReP target. Iptables userland binary is from the latest Debian unstable (1.3.3-2). The symptoms: iptables usually just tells Invalid Argument on any modification attempt. I'm trying to set up a simple one-rule NAT for test: iptables -t nat -A POSTROUTING -s 172.30.0.0/24 -j SNAT --to 10.0.0.1 and it usually fails but has succeeded 2 times (I now have 2 rules of this kind and they seem to just wotk once set up). Trying to delete the second rule (either by replacing -A with -D or using just -D 2) gives the same error. This should already be fixed in -rc4. Unfortunately it was still there with yesterdays rc4+git. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ipv6 routing broken in 2.6.17-rc3,4
On my home 6to4 gw, ipv6 routing seems to be broken and everything is sent to 6to4 tunnel (the default route). It worked with fine for a long time and with 2.6.17-rc2-g4d5c34ec and it's broken with vmlinuz-2.6.17-rc3-g3cd73eed and 2.6.17-rc4-g9be2f7c3 (yesterdays kernel). Example (I add an unreachable route to an ipv6 address to force going there by ipv4 and it still uses the route): vaarikas:~# ip -6 route add unreachable 2001:7a8:1:5::14 vaarikas:~# ping6 2001:7a8:1:5::14 PING 2001:7a8:1:5::14(2001:7a8:1:5::14) 56 data bytes 64 bytes from 2001:7a8:1:5::14: icmp_seq=1 ttl=55 time=56.7 ms 64 bytes from 2001:7a8:1:5::14: icmp_seq=2 ttl=55 time=55.5 ms --- 2001:7a8:1:5::14 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 55.573/56.155/56.738/0.628 ms vaarikas:~# ip -6 route ::/96 via :: dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 unreachable 2001:7a8:1:5::14 dev lo metric 1024 expires 21334221sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 2002:5283:297e:2::/64 dev eth0 metric 256 expires 21332659sec mtu 1500 advmss 1440 hoplimit 4294967295 2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 fe80::/64 dev eth0 metric 256 expires 21332650sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth1 metric 256 expires 21332654sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 ff00::/8 dev eth1 metric 256 expires 21332654sec mtu 1500 advmss 1440 hoplimit 4294967295 ff00::/8 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 ff00::/8 dev eth0 metric 256 expires 21332650sec mtu 1500 advmss 1440 hoplimit 4294967295 unreachable default dev lo proto none metric -1 error -101 hoplimit 255 Additional example: nothing goes in the direction of eth0, the packets that should go there also go to tun6to4 interface as confirmed by tcpdump. I have a laptop on eth0 and when I tracepath6 some external address, I get this from tun4to4 device on the gw: vaarikas:~# tcpdump -n -s 1500 -vv -i tun6to4 tcpdump: WARNING: tun6to4: no IPv4 address assigned tcpdump: listening on tun6to4, link-type RAW (Raw IP), capture size 1500 bytes 09:14:08.053137 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, time exceeded in-transit, length 1240 for 2001:ad0::10 09:14:09.050230 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, time exceeded in-transit, length 1240 for 2001:ad0::10 09:14:10.091294 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, time exceeded in-transit, length 1240 for 2001:ad0::10 09:14:11.090985 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 09:14:12.090354 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 09:14:13.090373 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 09:14:14.091355 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 > 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 ... -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
iptables broken on ppc (ptrace too?) (2.6.17-rc3)
20\0\25\204\320\0\25\204\320\0\0\236D\0\0\306\274\0\0\0\7\0\1\0\0\0\0\0\2\0\24\357\30\0\25\357\30\0\25\357\30\0\0\0\350\0\0\0\350\0\0\0\6\0\0\0\4\0\0\0\4\0\0\1t\0\0\1t\0\0\1t\0\0\0 \0\0\0 \0\0\0\4\0\0\0\4\0\0\0\7\0\24\331H\0\25\331H\0\25\331H\0\0\0\10\0\0\0([EMAIL PROTECTED]@\0\0\0\5\0\0\0\4\0\0\0\4\0\0\0\20\0\0\0\1GNU\0\0\0\0\0\0\0\0\2\0\0\0\6\0\0\0\0\0\0\3\377\0\0\10R\0\0\1\10\0\0\6z\0\0\0\0\0\0\0\323\0\0\6\341\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0! \6j\0\0\5\314\0\0\0\0\0\0\10\v\0\0\6s\0\0\2\25\0\0\2\243\0\0\10\37\0\0\4\37\0\0\10\23\0\0\0\0\0\0\1\373\0\0\2z\0\0\7\342\0\0\6\26\0\0\4\300", 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1390284, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3002 mmap(0xfe3, 1461132, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xfe3 mprotect(0xff79000, 113548, PROT_NONE) = 0 mmap(0xff88000, 45056, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x148000) = 0xff88000 mmap(0xff93000, 7052, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xff93000 close(3)= 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30021000 mprotect(0xff88000, 24576, PROT_READ) = 0 mprotect(0xffc8000, 4096, PROT_READ)= 0 mprotect(0xffee000, 4096, PROT_READ)= 0 mprotect(0x30028000, 4096, PROT_READ) = 0 munmap(0x3001a000, 21161) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ -- Meelis Roos ([EMAIL PROTECTED])
Re: [PATCH] IrDA: smcinit merged into smsc-ircc driver
Detected unconfigured Toshiba Satellite 1800 SMSC IrDA chip, pre-configuring device. SORRY: Toshiba Satellite 1800 has an unsupported bridge controller (ALi): not pre-configured. smsc-ircc2, Preconfiguration failed ! Yep we don't have support for ALi bridges yet, the Toshiba 1800 still needs tosh1800 smcinit. But if you're willing to test, I can make a try to create a 1800-compliant ALi initializer implementation out of the blue... I am willing to test patches. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IrDA: smcinit merged into smsc-ircc driver
SO> This patch integrates the smcinit code into the smsc-ircc driver. SO> Some laptops have their smsc-ircc chip not properly configured by the BIOS and needs some preconfiguration. Currently, this can be done from userspace with smcinit, a utility that comes with the irda-utils package. It messes with ioports and PCI settings, from userspace. SO> Now with this patch, if we happen to be on one of the known to be faulty laptops, we preconfigure the chip from the driver. Finally got around to trying it on a Toshiba Satellite 1800 model 314 and it did not work: Detected unconfigured Toshiba Satellite 1800 SMSC IrDA chip, pre-configuring device. SORRY: Toshiba Satellite 1800 has an unsupported bridge controller (ALi): not pre-configured. smsc-ircc2, Preconfiguration failed ! found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227 smsc_superio_flat(): IrDA not enabled smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02 It works using pnpbios but not with pnpacpi (seems to be a bios bug). With pnpbios, I can turn it on using install smc-ircc echo "auto" > /sys/bus/pnp/devices/00:0f/resources && echo "activate" > /sys/bus/pnp/devices/00:0f/resources && /sbin/modprobe smsc-ircc2 lspci output (without and with -n): :00:00.0 Host bridge: ALi Corporation M1644/M1644T Northbridge+Trident (rev 01) :00:01.0 PCI bridge: ALi Corporation PCI to AGP Controller :00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) :00:04.0 IDE interface: ALi Corporation M5229 IDE (rev c3) :00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 01) :00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV] :00:08.0 Bridge: ALi Corporation M7101 Power Management Controller [PMU] :00:11.0 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus Bridge with ZV Support (rev 32) :00:11.1 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus Bridge with ZV Support (rev 32) :01:00.0 VGA compatible controller: Trident Microsystems CyberBlade XPAi1 (rev 82) :06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) :00:00.0 0600: 10b9:1644 (rev 01) :00:01.0 0604: 10b9:5247 :00:02.0 0c03: 10b9:5237 (rev 03) :00:04.0 0101: 10b9:5229 (rev c3) :00:06.0 0401: 10b9:5451 (rev 01) :00:07.0 0601: 10b9:1533 :00:08.0 0680: 10b9:7101 :00:11.0 0607: 1179:0617 (rev 32) :00:11.1 0607: 1179:0617 (rev 32) :01:00.0 0300: 1023:8820 (rev 82) 0000:06:00.0 0200: 10ec:8139 (rev 10) -- Meelis Roos - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html