From owner-freebsd-arch@FreeBSD.ORG Mon Mar 17 08:53:53 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35A3B106564A for ; Mon, 17 Mar 2008 08:53:53 +0000 (UTC) (envelope-from Arthur.Hartwig@nokia.com) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by mx1.freebsd.org (Postfix) with ESMTP id 94C2C8FC15 for ; Mon, 17 Mar 2008 08:53:52 +0000 (UTC) (envelope-from Arthur.Hartwig@nokia.com) Received: from mgw-mx03.nokia.com (mgw-mx03.nokia.com [192.100.122.230]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2H8SfGv014908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 Mar 2008 10:28:46 +0200 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2H8SWS9026220 for ; Mon, 17 Mar 2008 10:28:34 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Mar 2008 10:28:27 +0200 Received: from syebe101.NOE.Nokia.com ([172.30.128.65]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Mar 2008 10:28:27 +0200 Received: from [172.30.67.77] ([172.30.67.77]) by syebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Mar 2008 19:28:23 +1100 Message-ID: <47DE2BA6.7080002@nokia.com> Date: Mon, 17 Mar 2008 18:28:22 +1000 From: Arthur Hartwig User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: FreeBSD Arch References: <20080315124008.GF80576@hoeg.nl> In-Reply-To: <20080315124008.GF80576@hoeg.nl> X-OriginalArrivalTime: 17 Mar 2008 08:28:23.0414 (UTC) FILETIME=[DD4F5960:01C88808] X-Nokia-AV: Clean Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Some devfs and tty issues X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 08:53:53 -0000 I'm developing a driver for a USB hardware modem. I want to allow dialup logins from the modem. The driver currently allows me to use cu to set and examine modem parameters, make outgoing calls and converse with the called system. I'm more interested in allowing logins over an incoming call to the modem. The driver is modeled on the uplcom driver. If I plugin the modem and start getty on the ttyU0 device (# /usr/libexec/getty std.9600 ttyU0) and then pull the adapter out of the USB socket a crash follows. I'm happy to file a PR and supply stack traces or otherwise assist in debugging. A recent message to this list and its replies suggest others have also found the interactions between the tty driver and devfs to be somewhat obscure so I'm posting this in the hope that some other eyes or old hands might be able to point to point me to something I've missed. These remarks apply to FreeBSD 6.3 RELEASE. In destroy_devl() in kern_conf.c I think the call to devfs_destroy() appears too early in the function. The following scenario in destroy_devl() is possible: 1. in process A, devfs_destroy() in fs/devfs/devfs_devs.c called, clearing CDP_ACTIVE. 2. msleep() called; devmtx released 3. context switch to process B which issues an open() which results in a call to devfs_populate() which calls devfs_populate_loop() which finds CDP_ACTIVE clear and calls dev_rel() which results in the device structure getting freed. 4. sleep time expires and process A resumes, but retains pointer to now freed device structure. The devfs_destroy() call would be better moved to somewhere towards the end of destroy_devl(), say after SI_ALIAS is cleared. The dev structure is still safe to reference after calling devfs_destroy() because the devmtx mutex is still held preveneting the freeing of the dev structure After I moved the devfs_destroy() call down past the msleep() call I could still provoke a problem by the following 1. Plug in USB modem 2. # cu -l cuaU0 to set modem parameters to auto answer 3. kill cu 4. dial in from PSTN 5. remove USB modem from USB socket. Now kernel repeatedly reports: Purging 4294967245 threads from cuaU0 I expect it will take a long while to purge that many threads :-) At least longer than I was prepared to wait. When this message was being output, the si_threadcount field of the cuaU0 cdev structure contained 0xffffffcd while much of the rest of the structure contained sensible looking values. On repeating the scenario I observed: All threads purged from cuaU0 Purging 4294967232 threads from ttyU0 Purging 4294967231 threads from ttyU0 On a second repeat of the same scenario, the cuaU0 cdev structure had 0xffffffd3 in the si_threadcount field when it was passed to destroy_devl(). Tomorrow I'll set hardware watchpoints on the si_threadcount field of the cdev structures for both ttyU0 and cuaU0 in an attempt to catch where they are being modified to these extravagant values. Arthur