From owner-freebsd-bugs@freebsd.org Tue Apr 4 15:38:40 2017 Return-Path: Delivered-To: freebsd-bugs@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 46C9BD2E04C for ; Tue, 4 Apr 2017 15:38:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 369A7B83 for ; Tue, 4 Apr 2017 15:38:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v34Fcd8O056189 for ; Tue, 4 Apr 2017 15:38:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 218252] VIMAGE + ppp over uplcom or vboxnet = panic Date: Tue, 04 Apr 2017 15:38:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 15:38:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218252 --- Comment #2 from Bjoern A. Zeeb --- vboxnet is not too unsurprising to me; I am not expecting the kernel modul= e to be vnet-aware (unless someone fixed it), so simply loading it and possibly getting the interface up, or triggering an ioctl, might be enough to panic = the kernel. External (from ports) kernel modules are a well known issue. As to when it comes to the mpd case, can you say a bit more: (1) at the time of running the recipe to reproduce, is it enough to do that just on the base system or are there jails/vnets running at that time? (2) also are all USB bits compiled into the kernel for you or loaded as modules? If the latter, could you try to see if compiling them into the ke= rnel makes a difference? --=20 You are receiving this mail because: You are the assignee for the bug.=