Date: Mon, 11 Mar 2019 14:27:29 +1030 From: "O'Connor, Daniel" <darius@dons.net.au> To: Hans Petter Selasky <hps@selasky.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, Warner Losh <imp@bsdimp.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: USB stack getting confused Message-ID: <030A0C16-4508-4C7C-A87C-72B69B15EDF5@dons.net.au> In-Reply-To: <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org> References: <f3e6e30b-8b62-546b-2b51-e841f2e645bd@selasky.org> <3B29D870-41F9-46AF-B9F3-03106DEC417D@dons.net.au> <20190309152613.GM2492@kib.kiev.ua> <ea6e2690-1ad7-6c06-49e5-c528013f26c0@selasky.org> <20190309162640.GN2492@kib.kiev.ua> <CANCZdfr9jRcXQeZWMPKSMvUB5u7kE0eDvbuKrtGvuUDYOr=n4A@mail.gmail.com> <20190309192330.GO2492@kib.kiev.ua> <fd5038a4-406b-6e4b-bb52-b567b1954ad1@selasky.org> <20190310094758.GP2492@kib.kiev.ua> <35f69493-4bbb-4142-b61a-3e90adc8777b@selasky.org> <20190310102629.GQ2492@kib.kiev.ua> <40bf77e0-47a5-6edc-b5d0-58e3c44988ac@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 10 Mar 2019, at 23:40, Hans Petter Selasky <hps@selasky.org> wrote: > On 3/10/19 11:26 AM, Konstantin Belousov wrote: >> On Sun, Mar 10, 2019 at 11:18:36AM +0100, Hans Petter Selasky wrote: >>> On 3/10/19 10:47 AM, Konstantin Belousov wrote: >>>>> Yes, I can do that if destroy_dev() ensures that d_close is called = for >>>>> all open file handles once and only once before it returns. I = think this >>>>> is where the problem comes from. >>>> See above. For d_close it is impossible, for cdevpriv dtr it is = already >>>> there by design. >>>>=20 >>>=20 >>> Yes, cdevpriv_dtr will wait for the final close() from user-space >>> unfortunately. Or am I mistaken? >> You are mistaken. Cdevpriv destructors are called either on the file = close >> (not the last close in d_close sense, just file close) OR during = destroy_dev(). >> Each destructor/file pair is called exactly once, regardless of the = cause. >=20 > Can you try the attached patch? I tried it but it didn't help the problem. I put a break point at ugen20_enumerate at libusb20_ugen20.c:149 I can = see it try and open /dev/ugenX.Y but 0.5 (my device) fails with errno = set to 12 (ENOMEM). I can dig into the kernel part if you want but will need some guidance = where to look.. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?030A0C16-4508-4C7C-A87C-72B69B15EDF5>