Date: Thu, 26 May 2005 14:21:52 +0200 From: Seb <sebastien.b@swissinfo.org> To: hselasky@c2i.net, freebsd-usb@freebsd.org Subject: Re: usbd_bulk_transfer returns 1 (USBD_IN_PROGRESS) ?! Message-ID: <200505261421.53060.sebastien.b@swissinfo.org> In-Reply-To: <200505261346.54260.hselasky@c2i.net> References: <200505252120.22408.sebastien.b@swissinfo.org> <200505261346.54260.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, On Thursday 26 May 2005 13:46, Hans Petter Selasky wrote: > Have you got a link to the tarball of your driver? Sure. http://lekernel.host.lya-network.biz/download/prism54u-bsd-0.1.tar.bz2 > I downloaded one of the files I found and had a look. > > When you detach, you have to stop the pipes/transfers you are using. Then > usbd_bulk_transfer will return USBD_CANCELLED and must not be called again! Ok, I'll add this, thanks for the info. But this won't solve the USBD_IN_PROGRESS problem... > Also you must make sure that transfers (xfer) are not started two times in > success, before the first call has returned transfer status. > > I'm not too familiar with swi_sched, but it might be that it runs the > interrupt handler in parallell. According to the ithread and swi_add manual pages, since I don't specify the INTR_MPSAFE flag the Giant mutex is acquired before the interrupt thread runs my code and is released right after my function returns. So there is no possibility for parallel USB transfers AFAIK. > Where are you tearing down your software interrupt handler? In p54u_netdev_free (netdev.c) : if(sc->update_state != NULL) ithread_remove_handler(sc->update_state); and in p54u_shutdown (usb_init.c) : if(sc->send_pending != NULL) ithread_remove_handler(sc->send_pending); if(sc->swi != NULL) ithread_destroy(sc->swi); The update_state handler is responsible for reconfiguring the device (LED status, frequency, RX filter) ; and send_pending handler sends the 802.11 frames. USB transfers also occur in the sc_stats_ch callout to update the network statistics, but since the mpsafe argument in callout_init is set to zero, the Giant mutex is held while the callout function executes ; therefore the USB transfers shouldn't race. > Does the same problem happen with my USB driver? I'll try. Regards, Sebastien
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200505261421.53060.sebastien.b>