From owner-freebsd-usb@FreeBSD.ORG Fri Feb 29 08:11:14 2008 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8091106566B for ; Fri, 29 Feb 2008 08:11:14 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 5EF308FC15 for ; Fri, 29 Feb 2008 08:11:14 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id C6F7E74400B for ; Fri, 29 Feb 2008 10:11:12 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id qB10x0G-uGtC for ; Fri, 29 Feb 2008 10:11:12 +0200 (EET) Received: from [91.193.172.111] (unknown [91.193.172.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id D456F43F5C3 for ; Fri, 29 Feb 2008 10:11:11 +0200 (EET) Message-ID: <47C7BE0A.5050600@icyb.net.ua> Date: Fri, 29 Feb 2008 10:10:50 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-usb@freebsd.org References: <47C7294B.6020306@icyb.net.ua> In-Reply-To: <47C7294B.6020306@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: ucom: orphaned ttyUX ? X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Feb 2008 08:11:15 -0000 on 28/02/2008 23:36 Andriy Gapon said the following: > I recently had a bad experience with ucom. I didn't try to reproduce it > in a controlled way, so that I could fully document it. So, here's my > recollection and impression/understanding of it with couple of facts on top. > > The bad experience: system crash with the following info: > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x4 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc4611c2b > stack pointer = 0x28:0xd1d3395c > frame pointer = 0x28:0xd1d33974 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 8979 (pppd) > trap number = 12 > panic: page fault > KDB: stack backtrace: > db_trace_self_wrapper(c06b76ef,d1d337fc,c04f577a,c06b4e67,c0d9f6e0,...) > at 0xc0437e56 = db_trace_self_wrapper+0x26 > kdb_backtrace(c06b4e67,c0d9f6e0,c06a7d40,d1d33808,d1d33808,...) at > 0xc051ad69 = kdb_backtrace+0x29 > panic(c06a7d40,c06cf0ab,c4219cd4,1,1,...) at 0xc04f577a = panic+0xaa > trap_fatal(c4219b40,0,c06ceeff,31b,4,...) at 0xc067e5d3 = trap_fatal+0x353 > trap_pfault(c06bc33a,d1d338c4,c04e9fc9,8,c,...) at 0xc067e7bb = > trap_pfault+0x1db > trap(d1d3391c) at 0xc067f182 = trap+0x3c2 > calltrap() at 0xc066e2db = calltrap+0x6 > --- trap 0xc, eip = 0xc4611c2b, esp = 0xd1d3395c, ebp = 0xd1d33974 --- > ucommodem(c28f6400,3,0,c06b41c5,0,...) at 0xc4611c2b = ucommodem+0xab > ttyopen(c345ed00,7,2000,c3468a50,c06ee960,...) at 0xc0535b10 = ttyopen+0x180 > giant_open(c345ed00,7,2000,c3468a50,7,...) at 0xc04ca70f = giant_open+0x4f > devfs_open(d1d33a70,c06d1f98,1e2,c06d267e,c3a1caa0,...) at 0xc04968c8 = > devfs_open+0x1d8 > VOP_OPEN_APV(c06dfee0,d1d33a70,8eb,c0558155,c3a1caa0,...) at 0xc0696062 > = VOP_OPEN_APV+0x42 > vn_open_cred(d1d33b64,d1d33c5c,0,c33c8800,c3823900,...) at 0xc0570b2d = > vn_open_cred+0x45d > vn_open(d1d33b64,d1d33c5c,0,c3823900,8,...) at 0xc0570c33 = vn_open+0x33 > kern_open(c3468a50,8063280,0,7,0,...) at 0xc056f873 = kern_open+0xf3 > open(c3468a50,d1d33cfc,3fe,c06cef20,c3468a50,...) at 0xc056fd70 = open+0x30 > syscall(d1d33d38) at 0xc067eb03 = syscall+0x323 > Xint0x80_syscall() at 0xc066e340 = Xint0x80_syscall+0x20 > --- syscall (5, FreeBSD ELF32, open), eip = 0x283123fb, esp = > 0xbfbfe71c, ebp = 0xbfbfe7f8 --- > > Apparently, this is a "null pointer dereferencing" crash. (tried to > dereference a field of structure pointed to with NULL). > What happened before: > connected a device recognized by ucom, /dev/ttyU0 appeared > disconnected the device, ucom noticed that, but ttyU0 did not disappear > re-connected the device > (I believe that this time ttyU1 was created for it, but I haven't checked) > by mistake used ttyU0 again > got the crash Well, it wasn't ttyU1, it was ttyU0: $ ls -l /dev/ttyU0 crw------- 1 root wheel 0, 132 28 Feb 22:37 /dev/ttyU0 $ ls -l /dev/ttyU0* crw------- 1 root wheel 0, 132 28 Feb 22:37 /dev/ttyU0 crw------- 1 root wheel 0, 132 28 Feb 22:37 /dev/ttyU0 crw------- 1 root wheel 0, 132 28 Feb 22:37 /dev/ttyU0 crw------- 1 root wheel 0, 132 28 Feb 22:37 /dev/ttyU0 crw------- 1 root wheel 0, 133 28 Feb 12:33 /dev/ttyU0.init crw------- 1 root wheel 0, 133 28 Feb 12:33 /dev/ttyU0.init crw------- 1 root wheel 0, 133 28 Feb 12:33 /dev/ttyU0.init crw------- 1 root wheel 0, 133 28 Feb 12:33 /dev/ttyU0.init crw------- 1 root wheel 0, 134 28 Feb 12:33 /dev/ttyU0.lock crw------- 1 root wheel 0, 134 28 Feb 12:33 /dev/ttyU0.lock crw------- 1 root wheel 0, 134 28 Feb 12:33 /dev/ttyU0.lock crw------- 1 root wheel 0, 134 28 Feb 12:33 /dev/ttyU0.lock So there are multiple ttyU0, and I guess that only one of them is "good". So opening ttyU0 is almost like playing russian roulette. > I believe that this is another example of a bad use of our device > cloning, but I can be very wrong here. > -- Andriy Gapon