kernel panic during shutdown on armv7
I've just encountered this panic on an armv7 sabre lite board while playing around with a CURRENT snapshot from Aug, 17th. The panic occurred for a single time at system shutdown via ``halt''. I couldn't reproduce it yet. login: boot: howto=0008 curproc=0xca2c99c8 syncing disks... panic: unmount: dangling vnode Stopped at $d: ldrbr15, [r15, r15, ror r15]! TIDPIDUID PRFLAGS PFLAGS CPU COMMAND *42015 42015 0 0x3 00 halt panic+0x18 scp=0xc03c6890 rlv=0xc03f48c8 ($d) rsp=0xcc468e94 rfp=0xcc468eb8 dounmount+0xc scp=0xc03f475c rlv=0xc03f0028 (vfs_unmountall+0x74) rsp=0xcc468ebc rfp=0xcc468ee0 r8=0xc0705abc r7=0x0001 r6=0x r5=0xc5504c00 r4=0xc5504800 vfs_unmountall+0xc scp=0xc03effc0 rlv=0xc03f0110 (vfs_shutdown+0x78) rsp=0xcc468ee4 rfp=0xcc468ef4 r8=0x0037 r7=0xca2c99c8 r6=0xcc468fb0 r5=0xc06a0660 r4=0x0008 vfs_shutdown+0xc scp=0xc03f00a4 rlv=0xc0531940 (bootsync+0x3c) rsp=0xcc468ef8 rfp=0xcc468f0c bootsync+0x10 scp=0xc0531914 rlv=0xc053cebc (boot+0xf0) rsp=0xcc468f10 rfp=0xcc468f20 r4=0x0008 boot+0x10 scp=0xc053cddc rlv=0xc03b9c08 (reboot+0x2c) rsp=0xcc468f24 rfp=0xcc468f34 reboot+0x10 scp=0xc03b9bec rlv=0xc03b9c54 (sysctl_hwperfpolicy) rsp=0xcc468f38 rfp=0xcc468f4c sys_reboot+0xc scp=0xc03b9c34 rlv=0xc05311e8 (swi_handler+0x174) rsp=0xcc468f50 rfp=0xcc468fac r4=0xcc468fb4 swi_handler+0xc scp=0xc0531080 rlv=0xc0533754 (swi_entry+0x28) rsp=0xcc468fb0 rfp=0xbfff271c r10=0x r9=0x r8=0x0004da28 r7=0x r6=0x0008 r5=0x0001 r4=0x ddb> show uvm Current UVM status: pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12 255078 VM pages: 127 active, 2376 inactive, 0 wired, 244200 free (30522 zero) min 10% (25) anon, 10% (25) vnode, 5% (12) vtext pages 0 anon, 0 vnode, 0 vtext freemin=8502, free-target=11336, inactive-target=0, wired-max=85026 faults=71510, traps=128865, intrs=0, ctxswitch=16229 fpuswitch=0 softint=10733, syscalls=122247, kmapent=22 fault counts: noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0 ok relocks(total)=3301(3301), anget(retries)=35576(0), amapcopy=35597 neighbor anon/obj pg=1898/30651, gets(lock/unlock)=13718/3301 cases: anon=28870, anoncow=6706, obj=12544, prcopy=1174, przero=22216 daemon and swap counts: woke=0, revs=0, scans=0, obscans=0, anscans=0 busy=0, freed=0, reactivate=0, deactivate=0 pageouts=0, pending=0, nswget=0 nswapdev=1, nanon=0, nanonneeded=0 nfreeanon=0 swpages=327679, swpginuse=0, swpgonly=0 paging=0 kernel pointers: objs(kern)=0xc06dda34 ddb> show bcstats Current Buffer Cache status: numbufs 1692 busymapped 0, delwri 5 kvaslots 409 avail kva slots 409 bufpages 6720, dirtypages 20 pendingreads 0, pendingwrites 0 ddb> ps TID PPID PGRPUID S FLAGS WAIT COMMAND *42015 1 42015 0 7 0x3halt 4697 0 0 0 2 0x14200zerothread 51247 0 0 0 3 0x14200 aiodoned aiodoned 71675 0 0 0 3 0x14200 syncerupdate 6617 0 0 0 3 0x14200 cleaner cleaner 5960 0 0 0 3 0x14200 reaperreaper 23257 0 0 0 3 0x14200 pgdaemon pagedaemon 99170 0 0 0 3 0x14200 bored crynlk 67974 0 0 0 3 0x14200 bored crypto 6664 0 0 0 3 0x14200 pftm pfpurge 37024 0 0 0 3 0x14200 mmctsksdmmc1 11066 0 0 0 3 0x14200 mmctsksdmmc0 22963 0 0 0 3 0x14200 usbtskusbtask 61880 0 0 0 3 0x14200 usbatsk usbatsk 4551 0 0 0 3 0x14200 bored sensors 44508 0 0 0 3 0x14200 bored softnet 89762 0 0 0 3 0x14200 bored systqmp 51826 0 0 0 3 0x14200 bored systq 88293 0 0 0 3 0x40014200idle0 58927 0 0 0 3 0x14200 kmalloc kmthread 1 0 1 0 30x82 wait init 0 -1 0 0 3 0x10200 scheduler swapper From the live system: # mount /dev/sd0a on / type ffs (local, noatime, softdep) /dev/sd0l on /home type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd0d on /tmp type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd0f on /usr type ffs (local, noatime, nodev, softdep) /dev/sd0g on /usr/X11R6 type ffs (local, noatime, nodev, softdep) /dev/sd0h on /usr/local type ffs (local, noatime, nodev, wxallowed, softdep) /dev/sd0k on /usr/obj type ffs (local, noatime, nodev, nosuid, sof
relayd's icmp check only works for a small number of hosts
>Synopsis: relayd's icmp check only works for a small number of hosts >Category: relayd >Environment: System : OpenBSD 5.9 Details : OpenBSD 5.9 (GENERIC.MP) #10: Wed Aug 3 13:46:07 CEST 2016 r...@stable-59-amd64.mtier.org:/binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: relayd says 70 out of 104 hosts are not reachable via icmp. But ping on the same host where relayd runs can reach all hosts with a rtt below 1ms. In the logs I see "210ms,icmp read timeout". But in relayd.conf a timeout of 1000 is set. Could this be related to the problem mentioned in the commit message of src/usr.sbin/relayd/check_icmp.c rev 1.41? The latest errata patches for 5.9 are applied via the mtier pkgs. relayd.conf: # Global Options interval 10 timeout 1000 log updates # Tables table { 192.168.63.32 } table { 192.168.63.33 } table { 192.168.63.32 } table { 192.168.63.33 } table { 192.168.63.35 } table { 192.168.63.36 } table { 192.168.63.35 } table { 192.168.63.36 } table { 192.168.63.38 } table { 192.168.63.39 } table { 192.168.63.38 } table { 192.168.63.39 } table { 192.168.63.41 } table { 192.168.63.42 } table { 192.168.63.41 } table { 192.168.63.42 } table { 192.168.63.44 } table { 192.168.63.45 } table { 192.168.63.44 } table { 192.168.63.45 } table { 192.168.63.47 } table { 192.168.63.48 } table { 192.168.63.47 } table { 192.168.63.48 } table { 192.168.63.50 } table { 192.168.63.51 } table { 192.168.63.50 } table { 192.168.63.51 } table { 192.168.63.84 } table { 192.168.63.85 } table { 192.168.63.84 } table { 192.168.63.85 } table { 192.168.63.84 } table { 192.168.63.85 } table { 192.168.63.84 } table { 192.168.63.85 } table { 192.168.63.104 } table { 192.168.63.105 } table { 192.168.63.104 } table { 192.168.63.105 } table { 192.168.63.124 } table { 192.168.63.125 } table { 192.168.63.124 } table { 192.168.63.125 } table { 192.168.63.124 } table { 192.168.63.125 } table { 192.168.63.124 } table { 192.168.63.125 } table { 192.168.63.114 } table { 192.168.63.115 } table { 192.168.63.114 } table { 192.168.63.115 } table { 192.168.63.114 } table { 192.168.63.115 } table { 192.168.63.114 } table { 192.168.63.115 } table { 192.168.63.132 } table { 192.168.63.133 } table { 192.168.63.132 } table { 192.168.63.133 } table { 192.168.63.135 } table { 192.168.63.136 } table { 192.168.63.135 } table { 192.168.63.136 } table { 192.168.63.138 } table { 192.168.63.139 } table { 192.168.63.138 } table { 192.168.63.139 } table { 192.168.63.141 } table { 192.168.63.142 } table { 192.168.63.141 } table { 192.168.63.142 } table { 192.168.63.184 } table { 192.168.63.185 } table { 192.168.63.184 } table { 192.168.63.185 } table { 192.168.63.184 } table { 192.168.63.185 } table { 192.168.63.184 } table { 192.168.63.185 } table { 192.168.63.184 } table { 192.168.63.185 } table { 192.168.63.224 } table { 192.168.63.225 } table { 192.168.63.224 } table { 192.168.63.225 } table { 192.168.63.224 } table { 192.168.63.225 } table { 192.168.63.224 } table { 192.168.63.225 } table { 192.168.63.224 } table { 192.168.63.225 } table { 192.168.63.204 } table { 192.168.63.205 } table { 192.168.63.204 } table { 192.168.63.205 } table { 192.168.63.214 } table { 192.168.63.215 } table { 192.168.63.214 } table { 192.168.63.215 } table { 192.168.63.214 } table { 192.168.63.215 } table { 192.168.63.214 } table { 192.168.63.215 } # Redirects redirect test_acc_a_443 { listen on 192.168.62.2 tcp port 443 session timeout 600 forward to check icmp forward to check icmp match pftag test_acc_a } redirect test_acc_a_9727 { listen on 192.168.62.2 tcp port 9727 session timeout 600 forward to check icmp forward to check icmp match pftag test_acc_a } redirect test_acc_b_443 { listen on 192.168.62.3 tcp port 443 session timeout 600 forward to check icmp forward to chec
Re: USB Issues [0/4]
> > On 2 Aug 2016, at 19:19, Binyamin Sharet (bsharet) wrote: > > Hi All, > > I have used Umap2 to scan OpenBSD 5.9 on i386 for supported USB devices, > and during this scan I have found 4 issues with the USB stack. > Umap2 can be downloaded from github [1]. > > The scanning requires some hardware - facedancer/beaglebone board, > and consists of emulating USB devices with single configuration, > single interface and multiple (5 IN, 5 OUT) endpoints on this interface. > Each time the VID (vendor ID) and PID (product ID) of the emulated USB > device are changed to match one of 155 known USB VID/PID that are > currently in a DB in Umap2. It aims on triggering the specific driver > for that VID/PID combination in order to detect support for it in the OS. > > I would refer to the issues by their VID/PID tuple from now. > > The first two issues - 13d3_3346 and 0cf3_9170 (handling devices with > VID/PID 0x13d3/0x3346 and 0x0cf3/0x9170) cause a kernel panic due to > kernel diagnostic assertion in the usbtask (file dev/usb/ehci.c, > line 1654). > > The third issue - 50c2_4013 - is a page fault, caused when trying to > read from invalid address in ehci_check_intr (movzbl 0x3(%eax), %eax). > > The fourth issue - 04bb_0904 - does not cause a crash, but it seems to > cause the USB stack to hang, and so it does not communicate with any > device that is inserted after this one, even if it was removed. > I was not able to find any more information about this one. > > All issues were reproduced on my machine multiple times. > > In the next 4 emails I will send the details regarding each of the > issues, as this is my first encounter with OpenBSD, I am not very > familiar with debugging and analyzing the system, and I'll surely > miss some required information. > If so, please let me know what's missing and I will try my best to > provide it. > Most of the information is based on pictures, as I couldn't copy > the data from the computer in any other way. If there is - please > let me know. > > Regards, > Binyamin Sharet > Cisco, STARE-C > > [1]: https://github.com/nccgroup/umap2 > Some information that was missed before: The Umap2 command line detailed in each of the bugs was issued on a BeagleBone black running linux, which is able to emulate a USB device using the gadgetfs driver. While the device descriptor is pretty standard, each time containing different VID/PID, the configuration descriptor is rather long and unconventional, and contain 10 endpoint descriptors within it. Below are the descriptors sent to the host during the scan. They are always the same (for all 4 issues) except for VID/PID. in the device descriptor, is a placeholder for VID (little endian) and is a placeholder for PID. Device descriptor: 12010200ff010140010001020301 1st Configuration descriptor: 09025800010104c032 2nd Configuration descriptor (3 next lines are a single descriptor): 09025800010104c03209040aff01010007058103410705010341070582 02000201070502020002010705830141070503014107058402000201070504 02000201070585011107050502000201 Binyamin Sharet Cisco, STARE-C
Re: USB Issues - 13d3_3346 [1/4]
> On 19 Aug 2016, at 10:39, Martin Pieuchot wrote: > > On 02/08/16(Tue) 19:20, Binyamin Sharet wrote: >> Bug: kernel panic in handling of VID 0x13d3 PID 0x3346 > > What funky descriptor are you using? > >> uname -a: OpenBSD <> 5.9 GENERIC.MP#1616 i386 >> Umap2 command line: umap2vsscan -P gadgetfs -s 13d3:3346 > > Could you describe your setup? Is the command line issued in the host > or are you using some virtualisation solution? I have described the setup used for testing in the first mail (e.g. USB Issues [0/4]) because it is the same for all of the 4 issues. I will shortly send the descriptors in a reply for the first mail, as they are the same, except for VID/PID, in all cases. Binyamin Sharet Cisco, STARE-C
Re: USB Issues - 13d3_3346 [1/4]
On 02/08/16(Tue) 19:20, Binyamin Sharet wrote: > Bug: kernel panic in handling of VID 0x13d3 PID 0x3346 What funky descriptor are you using? > uname -a: OpenBSD <> 5.9 GENERIC.MP#1616 i386 > Umap2 command line: umap2vsscan -P gadgetfs -s 13d3:3346 Could you describe your setup? Is the command line issued in the host or are you using some virtualisation solution?