From owner-freebsd-usb@FreeBSD.ORG Wed Nov 20 23:59:37 2013 Return-Path: Delivered-To: freebsd-usb@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E06CCA9F for ; Wed, 20 Nov 2013 23:59:37 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3E232304 for ; Wed, 20 Nov 2013 23:59:37 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id rAKNxLcW005292; Wed, 20 Nov 2013 15:59:25 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201311202359.rAKNxLcW005292@gw.catspoiler.org> Date: Wed, 20 Nov 2013 15:59:21 -0800 (PST) From: Don Lewis Subject: Re: U3GINIT_SCSIEJECT quirk To: hps@bitfrost.no MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-usb@FreeBSD.org X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 23:59:37 -0000 On 19 Nov, Don Lewis wrote: > I did figure out why the eject isn't happening the first time that the > device is plugged in. The problem is that u3g_driver_loaded() isn't > getting called (to register the event handler) until the u3g device > appears. This device first shows up as a umass device, and the u3g > device doesn't appear until I do "camcontrol eject". > > It works the next time the device is plugged in because the event > handler is already registered. > > I've got u3g built into my kernel. I don't know if it might work better > if I was using u3g as a module, but I think it would be racy. Plugging > in the device would cause devd to kldload the module, which would then > register the event handler. I don't know if that would happen before > usb_probe_and_attach() called EVENT_HANDLER_INVOKE(), but that sounds > unlikely. > > If u3g is built in, I think the best fix would be to somehow register > the event handler during the boot sequence before we start attaching the > USB devices. Mystery solved! I had assumed that u3g was built into my kernel because I had assumed that it was included in the GENERIC kernel config file, which I include in my kernel config. That turns out to be incorrect. The u3g driver was getting kldloaded by devd after I did the "camcontrol eject". It turns out that was happening even before I added the new PID because the device changes its PID to a value that was already compiled into the driver when it switches from umass to u3g mode. If the driver is compiled into the kernel, there is a SYSINIT that should register the event handler during boot. In the case of a module, adding this to /boot/loader.conf makes all the right things happen, even on the first insertion of the device: u3g_load="YES" The SCSI quirk is still an open issue, but it's sort of academic because the eject happens before the cd device even appears, so the problem that I think are occurring during geom tasting don't get triggered. There is also the hard to trigger CAM panic that I stumbled across, but the fast automatic eject should avoid that problem as well. It's something that should be tracked down and fixed though.