From owner-freebsd-bugs@FreeBSD.ORG Wed Feb 14 08:40:19 2007 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48A1316A409 for ; Wed, 14 Feb 2007 08:40:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1DD13C4A5 for ; Wed, 14 Feb 2007 08:40:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l1E8eIKj004541 for ; Wed, 14 Feb 2007 08:40:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l1E8eIIZ004540; Wed, 14 Feb 2007 08:40:18 GMT (envelope-from gnats) Date: Wed, 14 Feb 2007 08:40:18 GMT Message-Id: <200702140840.l1E8eIIZ004540@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: leres@ee.lbl.gov (Craig Leres) Cc: Subject: Re: kern/109152: [rp] RocketPort panic from device_unbusy() X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Craig Leres List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2007 08:40:19 -0000 The following reply was made to PR kern/109152; it has been noted by GNATS. From: leres@ee.lbl.gov (Craig Leres) To: Remko Lodder Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/109152: [rp] RocketPort panic from device_unbusy() Date: Wed, 14 Feb 2007 00:34:11 -0800 > This does not really feel like a bug but rather a configuration > failure from the administrator (you in this case). (Not a bug? Seriously?) Here's some additional info. I ran the scenario with a sio port; the system does not crash, /dev/modem does not go away and tip can still communicate with the modem after devfs is updated. (As expected.) I also ran the scenario with an puc port which worked the same as with the sio port. Finally, I reran the scenario with the RocketPort and found it's not necessary to make any changes to devfs.conf to induce a panic. You can simply: tip to a rocketport line run "/etc/rc.d/devfs restart" exit tip (wait for the system to reboot) I think the issue is a side effect of refreshing the devfs layout is that the state is getting reset. The rp driver seems to be the only one using device_busy/device_unbusy in a manner that's sensitive to the dev state. > What we need prior to continueing is a dump of > the panic, I used a crash dump to create the kgdb stack trace. Craig