From owner-freebsd-hackers@freebsd.org Sat Mar 9 18:41:45 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C25F1531D8D for ; Sat, 9 Mar 2019 18:41:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF1B06D62B for ; Sat, 9 Mar 2019 18:41:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x841.google.com with SMTP id s1so882815qte.5 for ; Sat, 09 Mar 2019 10:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=24DamIhEtYgu9AJuB4aZZtn3WPvNEr/Wvg55cTkzOto=; b=ms6GynYaXuGJPP/9M/LM5u5zDF/yOhmzCgmkOPgBSwkGVhX5HTpGQc/X0/vRN/O9f3 kNCxVNWnvOmyokKRcsh7e3RAcEzxXj6R6n0VNVseBYaU9E9GS0SL0+SPWcFVwSF+hvZL MQFVkf3+aD03xQM1i7SzJ8W3JI5CrWERhJGUNK3cUMjN86MRhWtll4FRcTf3f0vEJmIl RTqCiJivIx10cwQDJ0psSI18tVJhuQ2GoR1ZW/WinPsntyP+nzv2ho/TwRHRti7o0W2H VT0iCG6MrPjH2nEvC1MWbsMS3NvRODf6M+/1iIJSDYDP6qXkultYG4gO/rfJT5e4smy4 jpbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=24DamIhEtYgu9AJuB4aZZtn3WPvNEr/Wvg55cTkzOto=; b=HuLn4mBdPDTe6bbt8akE+3ZCx7ClhhG3mUeDrnvoQKxLVXy8S74uXKHfLHb6XMZ58j 3es7BTuQgHoduliSyzViZiNvsAwz1NoIxXfChmGN4AL7lB2o5TYLSRDZD3I2doq9u6XI 3mLds2qW/hXKK3nRbS8Pk9TyxGCEVRoq0ZPOclc00OLXF3GRxaDD4UVjP+JdZzRD30ej mHh8tsQv8xqC+Nu79F2b/Ui3qckqQUdMSb9HLxeSVGke/WJCqoDEDHlDkEx0zMF/KkrQ l9assGMp8DY1GwNymnNsK2r5WPLrUF8IOH8ZFAxJRzDp+85fzM3ySc5adFS9F48uojAC 8JEQ== X-Gm-Message-State: APjAAAW6MOjwoskq4jIhmm8ODC5K6VgQjrf2mAmSBhG2mW1O7euWBkm3 fNwQDYxro4ZQ5jvVPjHP8pkGsNozWcZXPgSqh++kKg== X-Google-Smtp-Source: APXvYqyp2msurvoc+LZPlRiHfBN/AHYoxsS4b6sfY8TzmeRCqr7j2rU40tWFDQ7yUfRMlKwuE6PtMDeeGqzjAMN5Ju8= X-Received: by 2002:a0c:9ba7:: with SMTP id o39mr19638971qve.153.1552156904308; Sat, 09 Mar 2019 10:41:44 -0800 (PST) MIME-Version: 1.0 References: <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <20190309162640.GN2492@kib.kiev.ua> In-Reply-To: <20190309162640.GN2492@kib.kiev.ua> From: Warner Losh Date: Sat, 9 Mar 2019 11:41:31 -0700 Message-ID: Subject: Re: USB stack getting confused To: Konstantin Belousov Cc: Hans Petter Selasky , FreeBSD Hackers , "O'Connor, Daniel" X-Rspamd-Queue-Id: CF1B06D62B X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 18:41:45 -0000 On Sat, Mar 9, 2019 at 11:25 AM Konstantin Belousov wrote: > On Sat, Mar 09, 2019 at 04:42:50PM +0100, Hans Petter Selasky wrote: > > On 3/9/19 4:26 PM, Konstantin Belousov wrote: > > > On Sat, Mar 09, 2019 at 08:59:30PM +1030, O'Connor, Daniel wrote: > > >> > > >> > > >>> On 9 Mar 2019, at 19:30, Hans Petter Selasky > wrote: > > >>> On 3/9/19 12:08 AM, O'Connor, Daniel wrote: > > >>>> My program normally runs continually doing acquisitions of data for > N seconds, doing some checks and restarting. After a while (~30 1 minute > acquisitions or ~8 30 minute ones) my program can't 'see' the device (it > uses libusb10) any more (it reconnects each acquisition for $REASONS). Also > pretty weirdly usbconfig can't see it either(!). > > >>> > > >>> What is printed in dmesg? Maybe the device has a problem. > > >> > > >> There is nothing in dmesg - no disconnect / reconnect etc. > > >> > > >> If I hold the user space process in gdb 'forever' (eg over night) > usbconfig doesn't see the device, but the moment I quit the user space > process it can be seen again. > > > > > > Does it mean that the file descriptor opened for ugen has a chance to > > > be closed ? > > > > The USB stack will wait for all FDs to be closed during detach also via > > destroy_dev(). > So my guess was correct. Do you agree that this behaviour is wrong ? > > In fact I saw something similar with apcupsd and either usb/com adapters > or native usb control card for APC UPSes. For reasons I do not understand, > these devices are often disconnected. For older versions of apcupsd, > it required restart for newly reattached device to be recreated in /dev. > Sometimes it hangs whole usb stack. > > Newer apcupsd seems to open /dev/ugen only for the duration of the query, > which makes the erratic behaviour is much less likely, but could still > cause > breakage when device disappear while apcupsd has it opened. > Is there a form of destroy_dev() that does a revoke on all open instances? Eg, this is gone, you can't use it anymore, and all further attempts to use the device will generate an error, but in the mean time we destroy the device and let the detach routine get on with life. waiting may make sense when you are merely unloading the driver (and getting to the detach routine that way), but when the device is gone, I've come around to the point of view that we should just destroy it w/o waiting for closes and anybody that touches it afterwards gets an error and has to cope with the error. But even in the unload case, we maybe we shouldn't get to the detach routine unless we're forcing and/or the detach routine just returns EBUSY since the only one that knows what dev_t's are associated with the device_t is the driver itself. Warner > > > > > > > I suspect that usb subsystem tried to destroy the device but some > internal > > > refcounting prevents it. Proper use of destroy_dev(_cb)(9) avoids > > > the issue. > > > > --HPS > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >