Re: netbsd-8 crash in ixg driver during booting

[6bone]

On Thu, 16 Nov 2017, Masanobu SAITOH wrote:


This problem is different from ixg(4)'s problem. I'll now
working to fix this softint related problem.

This problem is caused by some devices which uses a lot of
softint, could you tell me the machine's spec? e.g.:

number of port of wm(4) and/or ixg(4)
number of nvme(4)
etc.


Hello,

the hardware is an HP G5 with two dual-port Intel 10GE network cards. The 
server is used as a router.


Here is the dmesg output from the netbsd-8 kernel.

Thank you for your efforts

Regards
Uwe


Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017
The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 8.0_BETA (MYCONF8.gdb) #0: Mon Aug 28 22:51:59 CEST 2017

r...@gate.ipv6.uni-leipzig.de:/usr/obj/sys/arch/amd64/compile/MYCONF8.gdb
total memory = 24565 MB
avail memory = 23830 MB
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
running cgd selftest aes-xts-256 aes-xts-512 done
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
HP ProLiant DL380 G7
mainbus0 (root)
ACPI: RSDP 0x000F4F00 24 (v02 HP)
ACPI: XSDT 0xDF630340 BC (v01 HP ProLiant 0002 ??   
162E)
ACPI: FACP 0xDF630440 F4 (v03 HP ProLiant 0002 ??   
162E)
ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, using 
default 16 (20170303/tbfadt-745)
ACPI BIOS Warning (bug): Invalid length for FADT/Pm2ControlBlock: 32, using 
default 8 (20170303/tbfadt-745)
ACPI: DSDT 0xDF630540 0020BD (v01 HP DSDT 0001 INTL 
20030228)
ACPI: FACS 0xDF62F100 40
ACPI: FACS 0xDF62F100 40
ACPI: SPCR 0xDF62F140 50 (v01 HP SPCRRBSU 0001 ??   
162E)
ACPI: MCFG 0xDF62F1C0 3C (v01 HP ProLiant 0001  
)
ACPI: HPET 0xDF62F200 38 (v01 HP ProLiant 0002 ??   
162E)
ACPI:  0xDF62F240 64 (v02 HP ProLiant 0002 ??   
162E)
ACPI: SPMI 0xDF62F2C0 40 (v05 HP ProLiant 0001 ??   
162E)
ACPI: ERST 0xDF62F300 0001D0 (v01 HP ProLiant 0001 ??   
162E)
ACPI: APIC 0xDF62F500 00015E (v01 HP ProLiant 0002  
)
ACPI: SRAT 0xDF62F680 000570 (v01 HP Proliant 0001 ??   
162E)
ACPI:  0xDF62FC00 000176 (v01 HP ProLiant 0001 ??   
162E)
ACPI: BERT 0xDF62FD80 30 (v01 HP ProLiant 0001 ??   
162E)
ACPI: HEST 0xDF62FDC0 BC (v01 HP ProLiant 0001 ??   
162E)
ACPI: DMAR 0xDF62FE80 00017C (v01 HP ProLiant 0001 ??   
162E)
ACPI: SSDT 0xDF632600 000125 (v03 HP CRSPCI0  0002 HP   
0001)
ACPI: SSDT 0xDF632740 000255 (v03 HP riser1a  0002 INTL 
20061109)
ACPI: SSDT 0xDF6329C0 00025D (v03 HP riser2a  0002 INTL 
20061109)
ACPI: SSDT 0xDF632C40 0003BB (v01 HP pcc  0001 INTL 
20090625)
ACPI: SSDT 0xDF633000 000377 (v01 HP pmab 0001 INTL 
20090625)
ACPI: SSDT 0xDF633380 002B64 (v01 INTEL  PPM RCM  0001 INTL 
20061109)
ACPI: 7 ACPI AML tables successfully acquired and loaded
ioapic0 at mainbus0 apid 8: pa 0xfec0, version 0x20, 24 pins
ioapic1 at mainbus0 apid 0: pa 0xfec8, version 0x20, 24 pins
cpu0 at mainbus0 apid 0
cpu0: Intel(R) Xeon(R) CPU   E5630  @ 2.53GHz, id 0x206c2
cpu0: package 0, core 0, smt 0
cpu1 at mainbus0 apid 32
cpu1: Intel(R) Xeon(R) CPU   E5630  @ 2.53GHz, id 0x206c2
cpu1: package 1, core 0, smt 0
cpu2 at mainbus0 apid 20
cpu2: Intel(R) Xeon(R) CPU   E5630  @ 2.53GHz, id 0x206c2
cpu2: package 0, core 10, smt 0
cpu3 at mainbus0 apid 52
cpu3: Intel(R) Xeon(R) CPU   E5630  @ 2.53GHz, id 0x206c2
cpu3: package 1, core 10, smt 0
cpu4 at mainbus0 apid 2
cpu4: Intel(R) Xeon(R) CPU   E5630  @ 2.53GHz, id 0x206c2
cpu4: package 0, core 1, smt 0
cpu5 at mainbus0 apid 34
cpu5: Intel(R) Xeon(R) CPU   E5630  @ 2.53GHz, id 0x206c2
cpu5: package 1, core 1, smt 0
cpu6 at mainbus0 apid 18
cpu6: Intel(R) Xeon(R) CPU   E5630  @ 2.53GHz, id 0x206c2
cpu6: package 0, core 9, smt 0
cpu7 at mainbus0 apid 50
cpu7: Intel(R) Xeon(R) CPU   E5630  @ 2.53GHz, id 0x206c2
cpu7: package 1, core 9, smt 0
cpu8 at mainbus0 apid 1
cpu8: Intel(R) Xeon(R) CPU   E5630  @ 2.53GHz, id 0x206c2
cpu8: package 0, core 0, smt 1
cpu9 at mainbus0 apid 33
cpu9: Intel(R) Xeon(R) CPU   E5630  @ 2.53GHz, id 0x206c2
cpu9: package 1, core 0, smt 1
cpu10 at mainbus0 apid 21
cpu10: Intel(R) Xeon(R) CPU   E5630  @ 2.53GHz, id 0x206c2
cpu10: package 0, core 10, smt 1
cpu11 at mainbus0 apid 53
cpu11: Intel(R) Xeon(R) CPU   E5630  @ 

Re: netbsd-8 crash in ixg driver during booting

[Masanobu SAITOH]

Hi, Uwe.

On 2017/11/15 15:41, 6b...@6bone.informatik.uni-leipzig.de wrote:


Does your machine boot with the latest -current?


I have tested the current sources from tonight.

https://suse.uni-leipzig.de/crash/crash-current1.jpg
https://suse.uni-leipzig.de/crash/crash-current2.jpg

Regards
Uwe


 Thank you for the report.

 This problem is different from ixg(4)'s problem. I'll now
working to fix this softint related problem.

 This problem is caused by some devices which uses a lot of
softint, could you tell me the machine's spec? e.g.:

number of port of wm(4) and/or ixg(4)
number of nvme(4)
etc.

Thanks in advance.

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

daily CVS update output

[NetBSD source update]

Updating src tree:
P src/bin/sh/mkoptions.sh
P src/bin/sh/redir.c
P src/bin/sh/sh.1
P src/distrib/atari/floppies/common/dot.profile
P src/distrib/atari/floppies/install/list
P src/etc/etc.macppc/MAKEDEV.conf
P src/etc/etc.sparc64/MAKEDEV.conf
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/alpha/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/arm/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/armeb/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earm/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmeb/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmhf/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmhfeb/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv4/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv4eb/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6eb/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6hf/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv6hfeb/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7eb/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7hf/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/earmv7hfeb/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/hppa/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/i386/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/ia64/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/m68k/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/mips64eb/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/mips64el/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/mipseb/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/mipsel/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/powerpc/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/powerpc64/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/sh3eb/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/sh3el/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/sparc/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/sparc64/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/vax/c++config.h
P src/external/gpl3/gcc/lib/libstdc++-v3/arch/x86_64/c++config.h
P src/external/gpl3/gcc/usr.bin/common/Makefile
P src/external/gpl3/gcc/usr.bin/frontend/Makefile
P src/external/gpl3/gcc/usr.bin/gcc/arch/alpha/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/arm/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/armeb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earm/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmeb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhf/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhfeb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4eb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6eb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6hf/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6hfeb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7eb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7hf/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7hfeb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/hppa/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/i386/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/ia64/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/m68000/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/m68k/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/mips64eb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/mips64el/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/mipseb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/mipsel/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/powerpc/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/powerpc64/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/sh3eb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/sh3el/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/sparc/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/sparc64/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/vax/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/x86_64/configargs.h
P src/external/gpl3/gcc.old/usr.bin/common/Makefile
P src/external/gpl3/gcc.old/usr.bin/frontend/Makefile
P src/share/dict/web2
P src/sys/arch/amd64/conf/Makefile.amd64
P src/sys/arch/amd64/stand/prekern/elf.c
P src/sys/arch/amd64/stand/prekern/mm.c
P src/sys/arch/amd64/stand/prekern/prekern.h
P src/sys/arch/arm/sunxi/sunxi_mmc.c
P src/sys/arch/x86/x86/pmap.c
P src/sys/dev/audio.c
P src/sys/dev/audiovar.h
P 

Re: dump -X of large LVM based FFSv2 with WAPBL panics

[Jaromír Doleček]

Hi,

can you try if doing full forced fsck (fsck -f) would resolve this?

I've seen several such persistent panics when I was debugging WAPBL. Even
after kernel fixes I had persistent panics around ffs_newvnode() due to
disk data corruption from previous runs. This is worth trying.

Some day I plan to add some counter, so that actually boot would actually
force fsck every X boots even when clean, similarily what Linux does with
ext3/4.

Jaromir

2017-11-15 12:56 GMT+01:00 Matthias Petermann :

> Hello,
>
> on my system I have observed a serious panic when doing FFSv2 dumps under
> certain conditions. I did some googling on my own and found some references
> regarding the lead symptom
>
> "ffs_newvnode: ino=113 on /p: gen 55fd2f1f/55fd2f1f has non zero
> blocks ff00 or size 0"
>
> but all of them ended up as solved back in 2016. So I wanted to share my
> observation here, in the hope somebody can give me some pointers how the
> issue could be narrowed down further.
>
> 1) Given:
>
> - NetBSD 8.0_BETA (Kernel built from branches/netbsd-8 around 2017-11-06)
>
> NetBSD nuc.local 8.0_BETA NetBSD 8.0_BETA (XEN3_DOM0_XHCI) #0: Mon
> Nov 6 14:31:17 CET 2017 
> admin@nuc.local:/s/src/sys/arch/amd64/compile/XEN3_DOM0_XHCI
> amd64
>
> - A large (392 GB) LVM volume hosting a FFSv2 filesystem with WAPBL enabled
>   (/dev/mapper/vg0-photo mounted at /p)
>
> - (An external USB 3.0 Drive)
>
> 2) What I tried:
>
> - make a dump of the aforementioned filesystem, using snapshots
>
> # dump -X -0auf /mnt/photo.0.dump /p
>
> 3) What happens then:
>
> - the System crashes, leaving a coredump with with the following
> indication:
>
> ffs_newvnode: ino=113 on /p: gen 55fd2f1f/55fd2f1f has non zero blocks
> ff00 or size 0
> fatal page fault in supervisor mode
> trap type 6 code 0x2 rip 0x8022c0cc cs 0x8 rflags 0x10246 cr2
> 0xfe82deaddf1d ilevel 0x3 rsp 0xfe810e6b1eb8
> curlwp 0xfe827f736000 pid 0.4 lowest kstack 0xfe810e6ae2c0
> panic: trap
> cpu0: Begin traceback...
> vpanic() at netbsd:vpanic+0x140
> snprintf() at netbsd:snprintf
> trap() at netbsd:trap+0xc6b
> --- trap (number 6) ---
> mutex_enter() at netbsd:mutex_enter+0xc
> biodone2() at netbsd:biodone2+0x9b
> biodone2() at netbsd:biodone2+0x9b
> biointr() at netbsd:biointr+0x3a
> softint_dispatch() at netbsd:softint_dispatch+0xd3
> DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfe810e6b1ff0
> Xsoftintr() at netbsd:Xsoftintr+0x4f
> --- interrupt ---
> 0:
> cpu0: End traceback...
>
> dumping to dev 0,1 (offset=168119, size=2076255):
> dump
>
> - gdb backtrace shows:
>
> (gdb) target kvm netbsd.3.core
> 0x80229545 in cpu_reboot ()
> (gdb) bt
> #0  0x80229545 in cpu_reboot ()
> #1  0x809a4afc in vpanic ()
> #2  0x809a4bb0 in panic ()
> #3  0x8022b176 in trap ()
> #4  0x8020113e in alltraps ()
> #5  0x8022c0cc in mutex_enter ()
> #6  0x80a029f5 in wapbl_biodone ()
> #7  0x809e2f20 in biodone2 ()
> #8  0x809e2f20 in biodone2 ()
> #9  0x809e303e in biointr ()
> #10 0x8097bc1d in softint_dispatch ()
> #11 0x80223eef in Xsoftintr ()
> (gdb)
>
> 4) What I tried afterwards:
>
> - make a dump of the aforementioned filesystem, using NO snapshots
>
> # dump -0auf /mnt/photo.0.dump /p
>
> -> works
>
> - umount the filesystem, enforcing a manual fsck
>
> -> no problems
>
> - dumpfs -s /dev/mapper/vg0-photo
>
> nuc# dumpfs -s /dev/mapper/vg0-photo
> file system: /dev/mapper/vg0-photo
> format  FFSv2
> endian  little-endian
> location 65536  (-b 128)
> magic   19540119timeWed Nov 15 12:26:52 2017
> superblock location 65536   id  [ 59f8026a 16319237 ]
> cylgrp  dynamic inodes  FFSv2   sblock  FFSv2   fslevel 5
> nbfree  4461561 ndir1865nifree  24770027nffree  2079
> ncg 530 size100663296   blocks  99102949
> bsize   32768   shift   15  mask0x8000
> fsize   4096shift   12  mask0xf000
> frag8   shift   3   fsbtodb 3
> bpg 23742   fpg 189936  ipg 46848
> minfree 5%  optim   timemaxcontig 2 maxbpg  4096
> symlinklen 120  contigsumsize 2
> maxfilesize 0x000800800805
> nindir  4096inopb   128
> avgfilesize 16384   avgfpdir 64
> sblkno  24  cblkno  32  iblkno  40  dblkno  2968
> sbsize  4096cgsize  32768
> csaddr  2968cssize  12288
> cgrotor 0   fmod0   ronly   0   clean   0x01
> wapbl version 0x1   location 2  flags 0x0
> wapbl loc0 402688128loc1 131072 loc2 512loc3 3
> flags   none
> fsmnt   /p
> volname swuid   0
>
> 5) Further 

Re: Compile failure in nand.c

[bch]

On Wed, Nov 15, 2017 at 3:35 AM Chavdar Ivanov  wrote:

> Hi, Jared,
>
> Thanks, I suspected it was the obj tree, which I hadn't cleaned
> recently, I usually build incrementally. cleaning the obj tree
> whenever something similar pops out. I was about to start another
> build, but for some reason I can't get any cvs update from
> anoncvs.netbsd.org at the moment.
>

I had a similar thought (and experience, to an extent) - building modules
without the incremental switch seemed to solve the problem, though. After
running config on your kernel configuration : “./build.sh -j4 modules”

-bch


> Regards,
>
> Chavdar
>
>
> On 15 November 2017 at 00:19, Jared McNeill  wrote:
> > Hi Chavdar --
> >
> > This define is generated by config in locators.h (kernel obj directory)

current still unstable

[Thomas Klausner]

Hi!

I noticed that fixes for subr_pool.c and kern_exec.c had been
committed, so I updated and started a NetBSD build. The machine
rebooted in very few minutes.

Nov 15 15:15:34 yt syslogd[250]: restart
Nov 15 15:15:34 yt /netbsd: WARNING: SPL NOT LOWERED ON TRAP EXIT 6 0
Nov 15 15:15:34 yt syslogd[250]: last message repeated 2 times
Nov 15 15:15:34 yt /netbsd: WARNING: SPL NOT LOWuEvRmE_Df aOuNl TtR_AuPp 
pEeXrI_T e6n t0e
Nov 15 15:15:34 yt /netbsd: r.isra.4() at WARNING: SPL NOT LOWERED ON TRAP EXIT 
6 0
Nov 15 15:15:34 yt /netbsd: WARNING: SPL NOT LOWERED ON TRAP EXIT 6 0
Nov 15 15:15:34 yt syslogd[250]: last message repeated 4 times
Nov 15 15:15:34 yt /netbsd: netbsd:uvm_fault_upper_enter.isra.4+0xb4
Nov 15 15:15:34 yt /netbsd: WARNING: SPL NOT LOWERED ON TRAP EXIT 6 0
Nov 15 15:15:34 yt syslogd[250]: last message repeated 12 times
Nov 15 15:15:34 yt /netbsd: uvm_fault_internal() at WARNING: SPL NOT LOWERED ON 
TRAP EXIT 6 0
Nov 15 15:15:34 yt /netbsd: WARNING: SPL NOT LOWERED ON TRAP EXIT 6 0
Nov 15 15:15:34 yt syslogd[250]: last message repeated 2 times
Nov 15 15:15:34 yt /netbsd: netbsd:uvm_fault_internal+0x1692
Nov 15 15:15:34 yt /netbsd: WARNING: SPL NOT LOWERED ON TRAP EXIT 6 0
Nov 15 15:15:34 yt syslogd[250]: last message repeated 8 times
Nov 15 15:15:34 yt /netbsd: trap() at WARNING: SPL NOT LOWERED ON TRAP EXIT 6 0
Nov 15 15:15:34 yt /netbsd: WARNING: SPL NOT LOWERED ON TRAP EXIT 6 0
Nov 15 15:15:34 yt /netbsd: WARNING: SPL NOT LOWERED ON TRAP EXIT 6 0
Nov 15 15:15:34 yt /netbsd: netbsd:trap+0x3f0
Nov 15 15:15:34 yt /netbsd: WARNING: SPL NOT LOWERED ON TRAP EXIT 6 0
Nov 15 15:15:34 yt /netbsd: --- trap (number 6) ---
Nov 15 15:15:34 yt /netbsd: WARNING: SPL NOT LOWERED ON TRAP EXIT 6 0
Nov 15 15:15:34 yt syslogd[250]: last message repeated 4 times
Nov 15 15:15:34 yt /netbsd: 7f7f3d60096a:
Nov 15 15:15:34 yt /netbsd: WARNING: SPL NOT LOWERED ON TRAP EXIT 6 0
Nov 15 15:15:34 yt /netbsd: cpu6: End traceback...
Nov 15 15:15:34 yt /netbsd: WARNING: SPL NOT LOWERED ON TRAP EXIT 6 0
Nov 15 15:15:34 yt /netbsd: 

Re: anoncvs.netbsd.org

[Patrick Welche]

On Wed, Nov 15, 2017 at 12:56:53PM +, Christos Zoulas wrote:
> In article <20171115115102.GG5815@quartz>,
> Patrick Welche   wrote:
> >On Wed, Nov 15, 2017 at 11:31:05AM +, Chavdar Ivanov wrote:
> >> This morning I am getting
> >> ...
> >> $ cvs up -dPA
> >> ssh_exchange_identification: Connection closed by remote host
> >> cvs [update aborted]: end of file from server (consult above messages if 
> >> any)
> >> ...
> >> 
> >> from anoncvs.netbsd.org, both for the current sources and for pkgsrc,
> >> from any of my netbsd machines. Yesterday I did a successful build, so
> >> it is something recent. The tcpdump trace doesn't tell me much.
> >> 
> >> Do I have some local problem, or perhaps my IP has fallen into some deep 
> >> hole?
> >
> >"me too" (and others) - so not a local problem...
> 
> Try it now.

Happy times - thanks!

Patrick

Re: anoncvs.netbsd.org

[Chavdar Ivanov]

Working. Thanks.

Chavdar

On 15 November 2017 at 12:56, Christos Zoulas  wrote:
> In article <20171115115102.GG5815@quartz>,
> Patrick Welche   wrote:
>>On Wed, Nov 15, 2017 at 11:31:05AM +, Chavdar Ivanov wrote:
>>> This morning I am getting
>>> ...
>>> $ cvs up -dPA
>>> ssh_exchange_identification: Connection closed by remote host
>>> cvs [update aborted]: end of file from server (consult above messages if 
>>> any)
>>> ...
>>>
>>> from anoncvs.netbsd.org, both for the current sources and for pkgsrc,
>>> from any of my netbsd machines. Yesterday I did a successful build, so
>>> it is something recent. The tcpdump trace doesn't tell me much.
>>>
>>> Do I have some local problem, or perhaps my IP has fallen into some deep 
>>> hole?
>>
>>"me too" (and others) - so not a local problem...
>
> Try it now.
>
> christos
>



-- 

Re: anoncvs.netbsd.org

[Christos Zoulas]

In article <20171115115102.GG5815@quartz>,
Patrick Welche   wrote:
>On Wed, Nov 15, 2017 at 11:31:05AM +, Chavdar Ivanov wrote:
>> This morning I am getting
>> ...
>> $ cvs up -dPA
>> ssh_exchange_identification: Connection closed by remote host
>> cvs [update aborted]: end of file from server (consult above messages if any)
>> ...
>> 
>> from anoncvs.netbsd.org, both for the current sources and for pkgsrc,
>> from any of my netbsd machines. Yesterday I did a successful build, so
>> it is something recent. The tcpdump trace doesn't tell me much.
>> 
>> Do I have some local problem, or perhaps my IP has fallen into some deep 
>> hole?
>
>"me too" (and others) - so not a local problem...

Try it now.

christos

Re: Possible regression in wm(4)?

[Bert Kiers]

On Wed, Nov 15, 2017 at 11:54:56AM +0100, Bert Kiers wrote:
> On Wed, Nov 15, 2017 at 11:31:59AM +0900, Kengo NAKAHARA wrote:
> > Hi,
> 
> Hi,
> 
> > > But still no traffic.
> > 
> > Oh, the dmesg is as expected, but the behavior is not.
> > Hmm, sorry, could you give me the following information?
> > + "intrctl list" result on NetBSD-8
> >   - before trying traffic and after it
> > - full dmesg on NetBSD-8 which boot with "-xv" option
> > - full dmesg on NetBSD-7 (which boot -xv if you can)
> > - "acpidump -dt" result
> 
> Most of this you can find in http://netbsd.itsx.net/kern52717/
> The n8 directory contains the output of the original NetBSD-8
> kernel, not with any of the patches.  If that was not your plan,
> please tell me.
> 
> Not the intrctl output yet, since I only have NetBSD-7 userland.
> Building that userland now, so that too will be there in a little
> while.

The ouput of intrctl list is now there.

By the way, ifconfig -v shows an increasing number of queue drops.
What are those?

root@yvresse:~# uptime
 1:44PM  up  2:04, 1 user, load averages: 0.00, 0.12, 2.49
root@yvresse:~# while true ; do ifconfig -v wm1 |grep drops ; sleep 10 ; done
input: 50 packets, 7200 bytes, 20062 queue drops
input: 50 packets, 7200 bytes, 20079 queue drops
input: 50 packets, 7200 bytes, 20101 queue drops
input: 50 packets, 7200 bytes, 20111 queue drops
input: 50 packets, 7200 bytes, 20136 queue drops
input: 50 packets, 7200 bytes, 20165 queue drops
input: 50 packets, 7200 bytes, 20192 queue drops
input: 50 packets, 7200 bytes, 20201 queue drops
input: 50 packets, 7200 bytes, 20219 queue drops
input: 50 packets, 7200 bytes, 20235 queue drops
input: 50 packets, 7200 bytes, 20246 queue drops
input: 50 packets, 7200 bytes, 20252 queue drops
input: 50 packets, 7200 bytes, 20273 queue drops

Tcpdump -i wm1 -n does not show them.  I think that is about the number
of incoming packets I would expect.  I double verified ipf is disabled.

Grtnx,
-- 
B*E*R*T

Re: current kernel - Mutex problem in ACPI on shutdown

[Christos Zoulas]

On Nov 15, 11:14am, riccardo.mott...@libero.it (Riccardo Mottola) wrote:
-- Subject: Re: current kernel - Mutex problem in ACPI on shutdown

| Hi Christos,
| 
| Christos Zoulas wrote:
| > I just imported a new acpica, can you see if that makes a difference?
| >
| > Thanks,
| 
| It fixed it for me! Thanks
| 
| I wonder if it helps Kamil too.

Great, thanks for testing!

christos

dump -X of large LVM based FFSv2 with WAPBL panics

[Matthias Petermann]

Hello,

on my system I have observed a serious panic when doing FFSv2 dumps 
under certain conditions. I did some googling on my own and found some 
references regarding the lead symptom


	"ffs_newvnode: ino=113 on /p: gen 55fd2f1f/55fd2f1f has non zero blocks 
ff00 or size 0"


but all of them ended up as solved back in 2016. So I wanted to share my 
observation here, in the hope somebody can give me some pointers how the 
issue could be narrowed down further.


1) Given:

- NetBSD 8.0_BETA (Kernel built from branches/netbsd-8 around 2017-11-06)

	NetBSD nuc.local 8.0_BETA NetBSD 8.0_BETA (XEN3_DOM0_XHCI) #0: Mon Nov 
6 14:31:17 CET 2017 
admin@nuc.local:/s/src/sys/arch/amd64/compile/XEN3_DOM0_XHCI amd64


- A large (392 GB) LVM volume hosting a FFSv2 filesystem with WAPBL enabled
  (/dev/mapper/vg0-photo mounted at /p)

- (An external USB 3.0 Drive)

2) What I tried:

- make a dump of the aforementioned filesystem, using snapshots

# dump -X -0auf /mnt/photo.0.dump /p

3) What happens then:

- the System crashes, leaving a coredump with with the following indication:

ffs_newvnode: ino=113 on /p: gen 55fd2f1f/55fd2f1f has non zero 
blocks ff00 or size 0

fatal page fault in supervisor mode
trap type 6 code 0x2 rip 0x8022c0cc cs 0x8 rflags 0x10246 
cr2 0xfe82deaddf1d ilevel 0x3 rsp 0xfe810e6b1eb8

curlwp 0xfe827f736000 pid 0.4 lowest kstack 0xfe810e6ae2c0
panic: trap
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
snprintf() at netbsd:snprintf
trap() at netbsd:trap+0xc6b
--- trap (number 6) ---
mutex_enter() at netbsd:mutex_enter+0xc
biodone2() at netbsd:biodone2+0x9b
biodone2() at netbsd:biodone2+0x9b
biointr() at netbsd:biointr+0x3a
softint_dispatch() at netbsd:softint_dispatch+0xd3
DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfe810e6b1ff0
Xsoftintr() at netbsd:Xsoftintr+0x4f
--- interrupt ---
0:
cpu0: End traceback...

dumping to dev 0,1 (offset=168119, size=2076255):
dump

- gdb backtrace shows:

(gdb) target kvm netbsd.3.core
0x80229545 in cpu_reboot ()
(gdb) bt
#0  0x80229545 in cpu_reboot ()
#1  0x809a4afc in vpanic ()
#2  0x809a4bb0 in panic ()
#3  0x8022b176 in trap ()
#4  0x8020113e in alltraps ()
#5  0x8022c0cc in mutex_enter ()
#6  0x80a029f5 in wapbl_biodone ()
#7  0x809e2f20 in biodone2 ()
#8  0x809e2f20 in biodone2 ()
#9  0x809e303e in biointr ()
#10 0x8097bc1d in softint_dispatch ()
#11 0x80223eef in Xsoftintr ()
(gdb)

4) What I tried afterwards:

- make a dump of the aforementioned filesystem, using NO snapshots

# dump -0auf /mnt/photo.0.dump /p

-> works

- umount the filesystem, enforcing a manual fsck

-> no problems

- dumpfs -s /dev/mapper/vg0-photo

nuc# dumpfs -s /dev/mapper/vg0-photo
file system: /dev/mapper/vg0-photo
format  FFSv2
endian  little-endian
location 65536  (-b 128)
magic   19540119timeWed Nov 15 12:26:52 2017
superblock location 65536   id  [ 59f8026a 16319237 ]
cylgrp  dynamic inodes  FFSv2   sblock  FFSv2   fslevel 5
nbfree  4461561 ndir1865nifree  24770027nffree  2079
ncg 530 size100663296   blocks  99102949
bsize   32768   shift   15  mask0x8000
fsize   4096shift   12  mask0xf000
frag8   shift   3   fsbtodb 3
bpg 23742   fpg 189936  ipg 46848
minfree 5%  optim   timemaxcontig 2 maxbpg  4096
symlinklen 120  contigsumsize 2
maxfilesize 0x000800800805
nindir  4096inopb   128
avgfilesize 16384   avgfpdir 64
sblkno  24  cblkno  32  iblkno  40  dblkno  2968
sbsize  4096cgsize  32768
csaddr  2968cssize  12288
cgrotor 0   fmod0   ronly   0   clean   0x01
wapbl version 0x1   location 2  flags 0x0
wapbl loc0 402688128loc1 131072 loc2 512loc3 3
flags   none
fsmnt   /p
volname swuid   0

5) Further observations:

- dump -X of other FSs on the same machine seem to work fine, but
  these FSs are smaller

I'd be glad to help identifying the root cause further.

Best regards,
Matthias

--
Matthias Petermann  | www.petermann-it.de
GnuPG: 0x5C3E6D75 | 5930 86EF 7965 2BBA 6572  C3D7 7B1D A3C3 5C3E 6D75

Re: anoncvs.netbsd.org

[Patrick Welche]

On Wed, Nov 15, 2017 at 11:31:05AM +, Chavdar Ivanov wrote:
> This morning I am getting
> ...
> $ cvs up -dPA
> ssh_exchange_identification: Connection closed by remote host
> cvs [update aborted]: end of file from server (consult above messages if any)
> ...
> 
> from anoncvs.netbsd.org, both for the current sources and for pkgsrc,
> from any of my netbsd machines. Yesterday I did a successful build, so
> it is something recent. The tcpdump trace doesn't tell me much.
> 
> Do I have some local problem, or perhaps my IP has fallen into some deep hole?

"me too" (and others) - so not a local problem...

Cheers,

Patrick

Re: anoncvs.netbsd.org

[Chavdar Ivanov]

Thanks, I thought I had messed up something...

Chavdar


On 15 November 2017 at 11:46, Paul Goyette  wrote:
> Others have reported similar issues.  Waiting for admins to investigate.
>
>
>
> On Wed, 15 Nov 2017, Chavdar Ivanov wrote:
>
>> Hi,
>>
>> This morning I am getting
>> ...
>> $ cvs up -dPA
>> ssh_exchange_identification: Connection closed by remote host
>> cvs [update aborted]: end of file from server (consult above messages if
>> any)
>> ...
>>
>> from anoncvs.netbsd.org, both for the current sources and for pkgsrc,
>> from any of my netbsd machines. Yesterday I did a successful build, so
>> it is something recent. The tcpdump trace doesn't tell me much.
>>
>> Do I have some local problem, or perhaps my IP has fallen into some deep
>> hole?
>>
>> Chavdar Ivanov
>> --
>> 
>>
>> !DSPAM:5a0c25a329931092916434!
>>
>>
>
> +--+--++
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
> | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
> | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
> +--+--++



-- 

Re: anoncvs.netbsd.org

[Paul Goyette]

Others have reported similar issues.  Waiting for admins to investigate.


On Wed, 15 Nov 2017, Chavdar Ivanov wrote:


Hi,

This morning I am getting
...
$ cvs up -dPA
ssh_exchange_identification: Connection closed by remote host
cvs [update aborted]: end of file from server (consult above messages if any)
...

from anoncvs.netbsd.org, both for the current sources and for pkgsrc,
from any of my netbsd machines. Yesterday I did a successful build, so
it is something recent. The tcpdump trace doesn't tell me much.

Do I have some local problem, or perhaps my IP has fallen into some deep hole?

Chavdar Ivanov
--


!DSPAM:5a0c25a329931092916434!




+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++

Re: Compile failure in nand.c

[Chavdar Ivanov]

Hi, Jared,

Thanks, I suspected it was the obj tree, which I hadn't cleaned
recently, I usually build incrementally. cleaning the obj tree
whenever something similar pops out. I was about to start another
build, but for some reason I can't get any cvs update from
anoncvs.netbsd.org at the moment.

Regards,

Chavdar


On 15 November 2017 at 00:19, Jared McNeill  wrote:
> Hi Chavdar --
>
> This define is generated by config in locators.h (kernel obj directory).
> Make sure you have sys/dev/flash/files.flash rev 1.4 and that you've run
> config on your kernel since updating.
>
> Cheers,
> Jared
>
>
> On Tue, 14 Nov 2017, Chavdar Ivanov wrote:
>
>> Hi,
>>
>> I am getting:
>> ...
>> #   compile  nand/nand.o
>> /home/sysbuild/amd64/tools/bin/x86_64--netbsd-gcc -O2 -g   -std=gnu99
>>  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
>> -Wno-sign-
>> compare  -Wsystem-headers   -Wno-traditional   -Wa,--fatal-warnings
>> -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
>> -Wno-unus
>> ed-parameter -Wno-sign-compare -Werror   -ffreestanding
>> -fno-strict-aliasing -Wno-pointer-sign -mno-red-zone -mno-mmx -mno-sse
>> -mno-avx -msoft-fl
>> oat -mcmodel=kernel -fno-omit-frame-pointer
>> -I/home/sysbuild/src/common/include
>> --sysroot=/home/sysbuild/amd64/destdir -I/home/sysbuild/src/commo
>> n/include  -nostdinc -I. -I/home/sysbuild/src/sys/modules/nand
>> -isystem /home/sysbuild/src/sys -isystem /home/sysbuild/src/sys/arch
>> -isystem /home
>> /sysbuild/src/sys/../common/include -D_KERNEL -D_LKM -D_MODULE
>> -DSYSCTL_INCLUDE_DESCR -c/home/sysbuild/src/sys/dev/nand/nand.c
>> /home/sysbuild/src/sys/dev/nand/nand.c: In function 'nand_search':
>> /home/sysbuild/src/sys/dev/nand/nand.c:191:17: error:
>> 'FLASHBUSCF_DYNAMIC' undeclared (first use in this function)
>>  if (cf->cf_loc[FLASHBUSCF_DYNAMIC] != 0)
>> ^
>> /home/sysbuild/src/sys/dev/nand/nand.c:191:17: note: each undeclared
>> identifier is reported only once for each function it appears in
>> *** [nand.o] Error code 1
>> ...
>>
>> in my last few builds; I couldn't locate the missing symbol elsewhere.
>>
>> I am building now with the offending line #if-ed out.
>>
>> Chavdar Ivanov
>>
>> --
>> 
>>
>>
>



-- 

anoncvs.netbsd.org

[Chavdar Ivanov]

Hi,

This morning I am getting
...
$ cvs up -dPA
ssh_exchange_identification: Connection closed by remote host
cvs [update aborted]: end of file from server (consult above messages if any)
...

from anoncvs.netbsd.org, both for the current sources and for pkgsrc,
from any of my netbsd machines. Yesterday I did a successful build, so
it is something recent. The tcpdump trace doesn't tell me much.

Do I have some local problem, or perhaps my IP has fallen into some deep hole?

Chavdar Ivanov
-- 

Re: Possible regression in wm(4)?

[Bert Kiers]

On Wed, Nov 15, 2017 at 11:31:59AM +0900, Kengo NAKAHARA wrote:
> Hi,

Hi,

> > But still no traffic.
> 
> Oh, the dmesg is as expected, but the behavior is not.
> Hmm, sorry, could you give me the following information?
> + "intrctl list" result on NetBSD-8
>   - before trying traffic and after it
> - full dmesg on NetBSD-8 which boot with "-xv" option
> - full dmesg on NetBSD-7 (which boot -xv if you can)
> - "acpidump -dt" result

Most of this you can find in http://netbsd.itsx.net/kern52717/
The n8 directory contains the output of the original NetBSD-8
kernel, not with any of the patches.  If that was not your plan,
please tell me.

Not the intrctl output yet, since I only have NetBSD-7 userland.
Building that userland now, so that too will be there in a little
while.

Grtnx,
-- 
B*E*R*T

Re: Automated report: NetBSD-current/i386 test failure

[Riccardo Mottola]

Hi,

Martin Husemann wrote:

This was fallout fromt the gcc import, it should be fixed now.


 suppose they caused the build failure of tools the 13th forme. Build 
fine again yesterday. Rebuilding distribution currently.


Riccardo

Re: current kernel - Mutex problem in ACPI on shutdown

[Riccardo Mottola]

Hi Christos,

Christos Zoulas wrote:

I just imported a new acpica, can you see if that makes a difference?

Thanks,


It fixed it for me! Thanks

I wonder if it helps Kamil too.

Riccardo