From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 16:03:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5500B1065670; Wed, 1 Aug 2012 16:03:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E08A38FC0A; Wed, 1 Aug 2012 16:03:27 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q71G3aiY026500; Wed, 1 Aug 2012 19:03:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q71G3NZr073885; Wed, 1 Aug 2012 19:03:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q71G3Nfj073884; Wed, 1 Aug 2012 19:03:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 1 Aug 2012 19:03:23 +0300 From: Konstantin Belousov To: current@freebsd.org Message-ID: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K21AJ9EWb/UqY1dh" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: ed@freebsd.org Subject: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:03:28 -0000 --K21AJ9EWb/UqY1dh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Long story, the summary is in last two paragraphs] I use several APC UPS some of which are connected by the USB<->serial dongle. Said USBs very much like to drop from the USB bus on a smallest power glitch. Today I noted that a machine dropped UPS serial USB device, and did not reattached it. More, attempt to show the list of the USB devices resulted in usbconfig locking hard: tom% sudo usbconfig list ~ load: 0.00 cmd: usbconfig 76210 [USB config SX lock] 4.63r 0.00u 0.00s 1% 1000k ^C^C load: 0.07 cmd: usbconfig 76210 [USB config SX lock] 33.87r 0.00u 0.00s 0% 1000k Quick inspection of the said sx revealed that the owner of the lock is the kernel thread, with the backtrace 84 100089 usb usbus3 mi_switch+0x184 sleepq_wait+0x42 _cv_wait+0x11e ucom_detach+0x142 uplcom_detach+0x20 device_detach+0x74 usb_detach_device+0x4a usb_unconfigure+0x34 usb_free_device+0x166 uhub_explore+0x12e usb_bus_explore+0xd2 usb_process+0x9b fork_exit+0x11f fork_trampoline+0xe Apparently, in ucom_detach_tty(), the condition sc->sc_ttyfreed == 0 was not satisfied because apcupsd has a thread inside a tty devsw method, which prevented the destroy_dev_sched from succeeding and the wait hang almost forever. More, the Giant taskqueue was stopped due to stuck job. Killing apcupsd, which slept interruptible, allowed the tty destruction to proceed and freed USB config SX. This unwedged the USB subsystem and machine become fully functional again. I would blame tty subsystem rather then USB subsystem. The d_purge method of the ttydev_cdevsw is not implemented, but it is the only measure that can break the deadlocks like the one I described. The d_purge shall wake up threads sleeping inside devsw methods, which was specifically added to notify driver about device gone events. I am sorry for not catching the backtrace for the apcupsd itself, since it was only afterthought that apcupsd is interesting part of the deadlock. I am sure that it was not poll() which was entered by apcupsd, most likely it was read/write or some termios ioctl. --K21AJ9EWb/UqY1dh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAZU0oACgkQC3+MBN1Mb4hviACcDU8f2SUrI7ghu0033uSrvfq7 QacAnR8/H4tkKnYXyJRDr8NZDo+2KX3B =dfle -----END PGP SIGNATURE----- --K21AJ9EWb/UqY1dh--