10.4-stable systematically crashing inside pselect() when a tun device is used

Jukka A. Ukkonen jau789 at gmail.com
Sat Nov 18 16:16:49 UTC 2017

Hello all,

As briefly stated in the subject I have a 10-stable system on
which I have been testing a program which opens either a tun
device or a tap device, waits in pselect() for the descriptor
to become readable, and then proceeds to read the packet/frame.
When using a tun descriptor the pselect() call systematically
panics the kernel with the complaints shown in the text dump
snippet at the end of this message. When using a tap device
the same code works just fine.
After a little eyeballing I failed to notice any obvious reason
for this in the tun device code. I hope someone who knows the tun
device better might be able to tell me what should I see in this.

At the very minimum I would expect the pselect() call to fail
properly with an error code. Raising a panic and crashing the
whole kernel gives me the impression that there is something
very seriously wrong there. At least for now it just has not
dawned to me what that something is.
The system doing this is just another amd64 running 10-stable.
So, this should not be a hardware related issue on a rarely used
Any hints, pointers, helpful sophisticated guesses etc. would be


The following 12 lines were manually copied from a photo of the
console display after the panic was triggered...

Fatal trap 12: page fault while in kernel mode
cpuid = 10; apic id = 13
fault virtual address	= 0x8
fault code		= supervisor read data, page not present
instuction pointer	= 0x20:0xffffffff80b29699
stack pointer		= 0x28:0xfffffe03e72a8a70
frame pointer		= 0x28:0xfffffe03e72a8ab0
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor flags		= interrupt enabled, resume, IOPL = 0
current process		= 12 (swi6: task queue)
trap number		= 12

The rest have been pulled from the core.text.0 file, but
this is the apparently the exact same data that got dumped
to the console display as well...

trap number             = 12
panic: page fault
cpuid = 10
KDB: stack backtrace:
#0 0xffffffff80a97b60 at kdb_backtrace+0x60
#1 0xffffffff80a57d26 at vpanic+0x126
#2 0xffffffff80a57bf3 at panic+0x43
#3 0xffffffff80e8b84d at trap_fatal+0x35d
#4 0xffffffff80e8bb68 at trap_pfault+0x308
#5 0xffffffff80e8b1ca at trap+0x47a
#6 0xffffffff80e6f93c at calltrap+0x8
#7 0xffffffff80aaa645 at taskqueue_run_locked+0xf5
#8 0xffffffff80aaa4f3 at taskqueue_run+0x93
#9 0xffffffff80a1f209 at intr_event_execute_handlers+0xb9
#10 0xffffffff80a1f676 at ithread_loop+0x96
#11 0xffffffff80a1c93a at fork_exit+0x9a
#12 0xffffffff80e6fe7e at fork_trampoline+0xe
Uptime: 11m7s
Dumping 865 out of 16346 

More information about the freebsd-questions mailing list