kernel panic during shutdown on armv7

[Andreas Bartelt]

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, 

relayd's icmp check only works for a small number of hosts

[Remi Locherer]

>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  

Re: USB Issues [0/4]

[Binyamin Sharet (bsharet)]

> 
> 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]

[Binyamin Sharet (bsharet)]

> 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]

[Martin Pieuchot]

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?