From owner-freebsd-stable@FreeBSD.ORG Mon Dec 15 09:30:23 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA65C1065675; Mon, 15 Dec 2008 09:30:23 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD118FC19; Mon, 15 Dec 2008 09:30:23 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180131180.adsl.alicedsl.de [85.180.131.180]) by acme.spoerlein.net (8.14.2/8.14.2) with ESMTP id mBF9ULI6062752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Dec 2008 10:30:21 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.3/8.14.3) with ESMTP id mBF9UJOo002877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 10:30:20 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.3/8.14.3/Submit) id mBF9UJtO002876; Mon, 15 Dec 2008 10:30:19 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Mon, 15 Dec 2008 10:30:19 +0100 From: Ulrich Spoerlein To: stable@freebsd.org Message-ID: <20081215093019.GB1496@roadrunner.spoerlein.net> Mail-Followup-To: stable@freebsd.org, philip@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: philip@freebsd.org Subject: moused(8) ate my umass(4) devices, it's true! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2008 09:30:23 -0000 Hey all, I've observed a very weird behaviour with my USB stick for quite a while now (probably 4 months; sadly, I don't have any dates handy). Anyway, I have this weird SUN Keyboard -> USB adapter, which offers an ukbd(4) and ums(4) device to the system, although there is no mouse attached to the Sun keyboard I'm using. ukbd0: on uhub4 kbd2 at ukbd0 ums0: on uhub4 ums0: 3 buttons. This worked fine on RELENG_7 till somewhere around summer. Now, whenever there is a moused(8) listening on this fake ums(4) port, the umass(4) device will get stuck somewhere in CAM-land. It probes fine: Dec 14 10:24:49 roadrunner kernel: umass0: on uhub4 but then only BBB bulk transfer timeout messages follow every so often. The da0 device never shows up. Dec 14 10:26:59 roadrunner kernel: umass0: BBB reset failed, TIMEOUT Dec 14 10:27:04 roadrunner kernel: umass0: BBB bulk-in clear stall failed, IOERROR Dec 14 10:27:04 roadrunner kernel: umass0: BBB bulk-out clear stall failed, IOERROR Dec 14 10:28:09 roadrunner kernel: umass0: BBB reset failed, IOERROR Dec 14 10:28:09 roadrunner kernel: umass0: BBB bulk-in clear stall failed, IOERROR Dec 14 10:28:09 roadrunner kernel: umass0: BBB bulk-out clear stall failed, IOERROR Dec 14 10:29:14 roadrunner kernel: umass0: BBB reset failed, IOERROR Dec 14 10:29:14 roadrunner kernel: umass0: BBB bulk-in clear stall failed, IOERROR Dec 14 10:29:14 roadrunner kernel: umass0: BBB bulk-out clear stall failed, IOERROR Dec 14 10:30:19 roadrunner kernel: umass0: BBB reset failed, IOERROR Dec 14 10:30:19 roadrunner kernel: umass0: BBB bulk-in clear stall failed, IOERROR Dec 14 10:30:19 roadrunner kernel: umass0: BBB bulk-out clear stall failed, IOERROR Dec 14 10:31:24 roadrunner kernel: umass0: BBB reset failed, IOERROR Dec 14 10:31:24 roadrunner kernel: umass0: BBB bulk-in clear stall failed, IOERROR Dec 14 10:31:24 roadrunner kernel: umass0: BBB bulk-out clear stall failed, IOERROR I cannot unplug the USB stick (instant panic) and kldunloading umass is also bad (instant panic). I have to reboot the system and remove the device then. Today, I figured out that it depends wholly on moused(8) running on that unpopulated mouse port. Killing the moused process, which will start automatically when ums0 attaches, before plugging in the umass device and everybody is happy. I'm glad I found this workaround, but the situation sucks anyway. Other than binary searching the offending commit, what debugging could I do? Would a ktrace of the moused(8) be helpful when attaching umass? Is it perhaps polling the port too often waiting for a mouse to appear? Also, can I somehow blacklist the mouse-port of this adapter? I do not intend to use a 3 button Sun mouse, ever. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt.