From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 15:13:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAF641065677; Mon, 19 Dec 2011 15:13:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id CB0F58FC0A; Mon, 19 Dec 2011 15:13:45 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 219701462; Mon, 19 Dec 2011 16:13:42 +0100 From: Hans Petter Selasky To: Andriy Gapon Date: Mon, 19 Dec 2011 16:11:15 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EEF2B11.6080802@FreeBSD.org> <201112191530.40526.hselasky@c2i.net> <4EEF52E5.8020102@FreeBSD.org> In-Reply-To: <4EEF52E5.8020102@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201112191611.15432.hselasky@c2i.net> Cc: FreeBSD current , "freebsd-usb@FreeBSD.org" Subject: Re: a few usb issues related to edge cases 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: Mon, 19 Dec 2011 15:13:47 -0000 On Monday 19 December 2011 16:06:13 Andriy Gapon wrote: > First replying just to couple of points where there seems to be a > misunderstanding. > > on 19/12/2011 16:30 Hans Petter Selasky said the following: > >> 2. Somewhat related to the above. I think that because the USB > >> subsystem implements the shutdown method and detaches all its drivers, > >> then the ukbd driver won't be able to properly handle the 'shutdown -h' > >> case where the kernel asks to "press any key to reboot" at the end. > >> Depending on which thread wins the race (the one that executes the > >> mainline shutdown code or the USB explore thread that detaches USB > >> devices) there will either an immediate reboot or a later crash when > >> any key is pressed. > >> This is not critical, but OTOH perhaps the USB subsystem doesn't have to > >> do the shutdown. As far as I can see a lot of the drivers just do > >> nothing for the shutdown, for better or for worth. > >> > >> A side note: perhaps it would be a good idea to pass the 'how' value as > >> an additional parameter to device_shutdown. > > > > The shutdown of USB is done to give USB devices at last chance to turn > > off or reduce their current consumption. > > > > In the old code the Host controller itself would be disabled, so keyboard > > wouldn't have worked I believe like you suggest. > > I am not sure about the old code, I have never checked it. But the atkbd > definitely works at this stage. ATKBD is no comparison to UKBD :-) > > > BTW: Shutdown should be executed after any "Press any key to reboot." and > > shutdown should be given time to complete, hence for USB this needs to > > happen in sync with the rest of the USB system. > > Have you actually ever done "shutdown -h"? In other words do you know what > the "system halt" is? :) No, I'm usually "shutdown -p now". > I am not sure if it would be a good idea to declare a system as "halted" > before shutdown_final hooks are executed. I would rather sacrifice the > whole "press a key" interactivity and simply executed hlt. That's because > I think that the system halt has a very limited usage, mostly in > combination with UPS, where interactivity via console/keyboard is not very > important. > > BTW, the reason that I suggested to pass 'how' to device_shutdown is to > give drivers some choice. E.g. USB could the whole shutdown thing for the > cases of poweroff and reboot, but keep the devices going for halt. I see. > > But probably right now we just need to make a decision whether ukbd is > going to support system halt or not. > If not, then I think that usb_shutdown() must wait until the explore_proc > terminates. > If yes, then usb_shutdown() should become a noop. Or it could become quite > smart to detach/poweroff other devices in such a way that ukbd still stays > usable. But that's probably harder to implement. I will fix that. I see a missing wait there. Can I assume that we are allowed to sleep from device_shutdown() and that system timers still work? > P.S. I've just looked at the code in stable/7 and it seems that it didn't > actually unconfigured USB and detached device drivers. At least > ohci_shutdown and ohci_shutdown are not called on FreeBSD. Hmm. --HPS