From owner-freebsd-questions@freebsd.org Sat Nov 18 16:16:49 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72655DBECED for ; Sat, 18 Nov 2017 16:16:49 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4D26274D6C for ; Sat, 18 Nov 2017 16:16:49 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4C0BDDBECEC; Sat, 18 Nov 2017 16:16:49 +0000 (UTC) Delivered-To: questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BA49DBECEB for ; Sat, 18 Nov 2017 16:16:49 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1DF074D6B for ; Sat, 18 Nov 2017 16:16:48 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lf0-x232.google.com with SMTP id k66so5798612lfg.3 for ; Sat, 18 Nov 2017 08:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=ooHbxg8MFHCxQ0Z5oaNLDvdv46DbRBflnkSfsPhCHEQ=; b=QMQuX2edcZrvT+t+vlVEx3cM11kkZxgOgm/qOpRZwWZ/yuxfiX2cpiJgavlaSfNhpA QBJc+N4JdxYfTwtMfuiiLRPYJm1ME7OXTGgiQ+i5iTRxnPeXIm8ruWbqG4nOGyru8wyS KQJ5RqOZo88K4MtrZasgrh6X+EynQeggFEI4EPE0zBC0T6V2ouPUL7aPYpA7z9nFjZmF ixm7qLlOiD6HDMG8zFLinuIOaSgeucrGwZeplPzU6MbtFSNBuup8PS6J+fmwdbGNag3B RtN69CqWcLXy8qhl736dkEU9mHr87j5pYfeN34PUYKauGDOmijoVKVFl2dEo3BZOGFbZ Lt8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=ooHbxg8MFHCxQ0Z5oaNLDvdv46DbRBflnkSfsPhCHEQ=; b=QNOGPwXArCWWu245hZMjNM1pCSztHaiXYsmVxg0ufP95rlhU5FJ/0b7TgCxas+1zG+ gaaMJN0qwOlAv6kZP1F3CIyQBL8VuMoef9BbK6g444Qx5xduHi720kBRY1mQLzCDiFrG zDaqB38mtzjV53cbuwN3PjEYcdhV6xfU4M5WVi7FoVtDYswvYJ+wnyk7qyvpRb+5aW3m R0OB0+HgZ0p8wTeBzRQF0XXlD5sspJsN7FIGKTvqNSf+yclUUfE49jJhGDblWjOsTIW3 HQ1ciK81CDTJX+pPpQ0fMepAy8Sao6DwLoNNisYDRdZjhqiTvZCT9WSRz5H349Q4PpPA 6TMw== X-Gm-Message-State: AJaThX5k+JEjyqZvU/SMvl/mxpJ1vVwukGfLJpZWq91SxtX6Z0vc0+Qv GkFkxkClJ0IEum+lzCTmf2MwJQ== X-Google-Smtp-Source: AGs4zMZPgmks1HAOOODT3Tv09AquXri/NRMAYVnCql4+o4cDMQG4hnJMuh7S+23J1LIKw92MrPb/AA== X-Received: by 10.46.42.134 with SMTP id q128mr2245484ljq.62.1511021806554; Sat, 18 Nov 2017 08:16:46 -0800 (PST) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id o23sm1116898lfb.68.2017.11.18.08.16.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Nov 2017 08:16:45 -0800 (PST) From: "Jukka A. Ukkonen" To: questions@freebsd.org Subject: 10.4-stable systematically crashing inside pselect() when a tun device is used Message-ID: Date: Sat, 18 Nov 2017 18:16:44 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 16:16:49 -0000 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 hardware. Any hints, pointers, helpful sophisticated guesses etc. would be welcome. —jau 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 MB:..2%..12%..21%..32%..41%..52%..61%..71%..82%..91%