From owner-freebsd-usb@FreeBSD.ORG Sun Oct 31 15:11:41 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6B71065672; Sun, 31 Oct 2010 15:11:41 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 8650B8FC0C; Sun, 31 Oct 2010 15:11:40 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=5o9ETn4JDi4A:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=I9t67j24wRIK5ayr5iIA:9 a=yF99CFNFJJJYSbHfWScrEzui1W0A:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42174207; Sun, 31 Oct 2010 15:08:37 +0100 From: Hans Petter Selasky To: Weongyo Jeong Date: Sun, 31 Oct 2010 15:09:49 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20101030231901.GA83161@weongyo> In-Reply-To: <20101030231901.GA83161@weongyo> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010311509.49138.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: [CFR] add usb_sleepout.[ch] X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 15:11:41 -0000 On Sunday 31 October 2010 01:19:01 Weongyo Jeong wrote: > Hello USB guys, > > The following patch is to add a implementation, called `sleepout'. > Please reviews. I'd like to commit it into HEAD if no objections. > > Adds `sleepout' prototype which is a comic combination of callout(9) and > taskqueue(8) only for USB drivers to implement one step timer. In > current USB drivers using callout(9) interface they all have two step > execution flow as follows: > > 1. callout callback is fired by the interrupt context. Then it needs > to pass it to USB process context because it could sleep(!) while > callout(9) don't allow it. > 2. In the USB process context it operates USB commands that most of > times it'd be blocked at least 125 us (it'd be always true for USB) > > In a view of driver developer it'd be more convenient if USB stack has a > feature like this (timer supporting blocking). > Hi, I think this is a good idea too. However, there are some atomic issues I think you need to fix first. 1) All the sleepout_xxx() functions need mutex asserts. 2) Is it allowed to call callout_stop() / callout_reset() unlocked at all? What are the concequences if the mutex associated with the sleepout is NULL ? 3) As per the current implementation it can happen that the task'ed timeout is called after that sleepout_stop() is used. The code should have a check in the task function to see if the sleepout() has been cancelled or not, when the mutex associated with the sleepout is locked. 4) Should the functions be prefixed by usb_ ? 5) In drain you should drain the callout first, then drain the tasqueue. Else the timer can trigger after the taskqueue is drained. --HPS From owner-freebsd-usb@FreeBSD.ORG Sun Oct 31 21:47:11 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29551106566B; Sun, 31 Oct 2010 21:47:11 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B37538FC08; Sun, 31 Oct 2010 21:47:10 +0000 (UTC) Received: by vws12 with SMTP id 12so2952574vws.13 for ; Sun, 31 Oct 2010 14:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent:organization:x-operation-sytem; bh=R1E9JAqanbqwNYCJtcpDnTh3ZmCa5qM9ISV+JYs5Msc=; b=WsOM0qMFJhkzIhqfqZNgIEbHgBwkbPs4QGa1ml6t7FXXBRRwcvDsaC24gwaQKHqru/ GYrd7AkkrYLx3S1YwwCVOqAs9Fh5JE18uj1XXH29HSwmV44vTSnDgiW8YkdERcmwkqRT V8VzyNwv97HOtegQxM3RP3ZLHNZIzD9DHEm24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition:user-agent:organization :x-operation-sytem; b=xP6yfE8mSswGmyxyQ6hIQUPY7pMqwTXMOn0mG/MMEbVJMVRLTvSfKcrD665aASklbb sht7xegFLLg1NQbixA+K80+PPbz9etsPtIF73lCZfL56WjUQzy1mXx/GnCmBIWuTPkwM 8V/3QHApybPqEe9PJbPs/F/ZHZcxtuI8jiPsc= Received: by 10.229.96.136 with SMTP id h8mr7249440qcn.184.1288561629695; Sun, 31 Oct 2010 14:47:09 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id nb14sm4341254qcb.36.2010.10.31.14.47.06 (version=SSLv3 cipher=RC4-MD5); Sun, 31 Oct 2010 14:47:08 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Sun, 31 Oct 2010 14:47:04 -0700 From: Weongyo Jeong Date: Sun, 31 Oct 2010 14:47:04 -0700 To: freebsd-usb@freebsd.org Message-ID: <20101031214704.GA3918@weongyo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Subject: [CFR 2/n] removes uther dependency of aue(4) X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 21:47:11 -0000 Hello, The following patch is to remove uether(4) dependency of aue(4) and change logs would be as follows: - removes uether module dependency of aue(4) that finally uether module would be gone. The reasons why I'm trying to remove uether module are that I discussed with USB ethernet maintainers about whether it's useful or not. yongari@ answered that it's not helpful, not straight forward to understand and make code complex. - adds newly two uether APIs, uether_alloc_unr and uether_free_unr for backward compatibility because current interface names for each ethernet devices are linux-style `ue[0-9]+'. The naming rule would be kept at STABLE_8 but not sure at STABLE_9. If no objections I'd like to see this patch at HEAD. regards, Weongyo Jeong Index: usb_ethernet.c =================================================================== --- usb_ethernet.c (revision 214568) +++ usb_ethernet.c (working copy) @@ -597,5 +597,19 @@ uether_rxflush(struct usb_ether *ue) } } +int +uether_alloc_unr(void) +{ + + return (alloc_unr(ueunit)); +} + +void +uether_free_unr(int unit) +{ + + free_unr(ueunit, unit); +} + DECLARE_MODULE(uether, uether_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); MODULE_VERSION(uether, 1); Index: if_aue.c =================================================================== --- if_aue.c (revision 214568) +++ if_aue.c (working copy) @@ -81,6 +81,8 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include +#include #include #include #include @@ -88,6 +90,19 @@ __FBSDID("$FreeBSD$"); #include #include +#include +#include +#include +#include +#include +#include +#include + +#include "miibus_if.h" + +#include +#include + #include #include #include @@ -96,6 +111,7 @@ __FBSDID("$FreeBSD$"); #define USB_DEBUG_VAR aue_debug #include #include +#include #include #include @@ -197,14 +213,6 @@ static usb_callback_t aue_intr_callback; static usb_callback_t aue_bulk_read_callback; static usb_callback_t aue_bulk_write_callback; -static uether_fn_t aue_attach_post; -static uether_fn_t aue_init; -static uether_fn_t aue_stop; -static uether_fn_t aue_start; -static uether_fn_t aue_tick; -static uether_fn_t aue_setmulti; -static uether_fn_t aue_setpromisc; - static uint8_t aue_csr_read_1(struct aue_softc *, uint16_t); static uint16_t aue_csr_read_2(struct aue_softc *, uint16_t); static void aue_csr_write_1(struct aue_softc *, uint16_t, uint8_t); @@ -217,6 +225,20 @@ static void aue_reset_pegasus_II(struct aue_softc static int aue_ifmedia_upd(struct ifnet *); static void aue_ifmedia_sts(struct ifnet *, struct ifmediareq *); +static int aue_ioctl(struct ifnet *, u_long, caddr_t); +static void aue_start(struct ifnet *); +static void aue_start_locked(struct ifnet *); +static void aue_init(void *); +static void aue_stop_locked(struct aue_softc *); +static void aue_setmulti(void *, int); +static void aue_setmulti_locked(struct aue_softc *); +static void aue_rxflush(struct aue_softc *); +static int aue_rxbuf(struct aue_softc *, struct usb_page_cache *, + unsigned int, unsigned int); +static void aue_setpromisc(void *, int); +static void aue_setpromisc_locked(struct aue_softc *); +static void aue_init_locked(struct aue_softc *); +static void aue_watchdog(void *); static const struct usb_config aue_config[AUE_N_TRANSFER] = { @@ -283,24 +305,19 @@ MODULE_DEPEND(aue, ether, 1, 1, 1); MODULE_DEPEND(aue, miibus, 1, 1, 1); MODULE_VERSION(aue, 1); -static const struct usb_ether_methods aue_ue_methods = { - .ue_attach_post = aue_attach_post, - .ue_start = aue_start, - .ue_init = aue_init, - .ue_stop = aue_stop, - .ue_tick = aue_tick, - .ue_setmulti = aue_setmulti, - .ue_setpromisc = aue_setpromisc, - .ue_mii_upd = aue_ifmedia_upd, - .ue_mii_sts = aue_ifmedia_sts, -}; - #define AUE_SETBIT(sc, reg, x) \ aue_csr_write_1(sc, reg, aue_csr_read_1(sc, reg) | (x)) #define AUE_CLRBIT(sc, reg, x) \ aue_csr_write_1(sc, reg, aue_csr_read_1(sc, reg) & ~(x)) +static void +aue_pause(struct aue_softc *sc, unsigned int _ticks) +{ + + usb_pause_mtx(&sc->sc_mtx, _ticks); +} + static uint8_t aue_csr_read_1(struct aue_softc *sc, uint16_t reg) { @@ -314,7 +331,8 @@ aue_csr_read_1(struct aue_softc *sc, uint16_t reg) USETW(req.wIndex, reg); USETW(req.wLength, 1); - err = uether_do_request(&sc->sc_ue, &req, &val, 1000); + err = usbd_do_request_flags(sc->sc_udev, &sc->sc_mtx, &req, &val, 0, + NULL, 1000); if (err) return (0); return (val); @@ -333,7 +351,8 @@ aue_csr_read_2(struct aue_softc *sc, uint16_t reg) USETW(req.wIndex, reg); USETW(req.wLength, 2); - err = uether_do_request(&sc->sc_ue, &req, &val, 1000); + err = usbd_do_request_flags(sc->sc_udev, &sc->sc_mtx, &req, &val, 0, + NULL, 1000); if (err) return (0); return (le16toh(val)); @@ -351,9 +370,9 @@ aue_csr_write_1(struct aue_softc *sc, uint16_t reg USETW(req.wIndex, reg); USETW(req.wLength, 1); - if (uether_do_request(&sc->sc_ue, &req, &val, 1000)) { - /* error ignored */ - } + /* XXX error ignored */ + (void)usbd_do_request_flags(sc->sc_udev, &sc->sc_mtx, &req, &val, 0, + NULL, 1000); } static void @@ -369,9 +388,9 @@ aue_csr_write_2(struct aue_softc *sc, uint16_t reg val = htole16(val); - if (uether_do_request(&sc->sc_ue, &req, &val, 1000)) { - /* error ignored */ - } + /* XXX error ignored */ + (void)usbd_do_request_flags(sc->sc_udev, &sc->sc_mtx, &req, &val, 0, + NULL, 1000); } /* @@ -389,12 +408,11 @@ aue_eeprom_getword(struct aue_softc *sc, int addr, for (i = 0; i != AUE_TIMEOUT; i++) { if (aue_csr_read_1(sc, AUE_EE_CTL) & AUE_EECTL_DONE) break; - if (uether_pause(&sc->sc_ue, hz / 100)) - break; + aue_pause(sc, hz / 100); } if (i == AUE_TIMEOUT) - device_printf(sc->sc_ue.ue_dev, "EEPROM read timed out\n"); + device_printf(sc->sc_dev, "EEPROM read timed out\n"); word = aue_csr_read_2(sc, AUE_EE_DATA); *dest = word; @@ -446,12 +464,11 @@ aue_miibus_readreg(device_t dev, int phy, int reg) for (i = 0; i != AUE_TIMEOUT; i++) { if (aue_csr_read_1(sc, AUE_PHY_CTL) & AUE_PHYCTL_DONE) break; - if (uether_pause(&sc->sc_ue, hz / 100)) - break; + aue_pause(sc, hz / 100); } if (i == AUE_TIMEOUT) - device_printf(sc->sc_ue.ue_dev, "MII read timed out\n"); + device_printf(sc->sc_dev, "MII read timed out\n"); val = aue_csr_read_2(sc, AUE_PHY_DATA); @@ -482,12 +499,11 @@ aue_miibus_writereg(device_t dev, int phy, int reg for (i = 0; i != AUE_TIMEOUT; i++) { if (aue_csr_read_1(sc, AUE_PHY_CTL) & AUE_PHYCTL_DONE) break; - if (uether_pause(&sc->sc_ue, hz / 100)) - break; + aue_pause(sc, hz / 100); } if (i == AUE_TIMEOUT) - device_printf(sc->sc_ue.ue_dev, "MII write timed out\n"); + device_printf(sc->sc_dev, "MII write timed out\n"); if (!locked) AUE_UNLOCK(sc); @@ -533,12 +549,21 @@ aue_miibus_statchg(device_t dev) AUE_UNLOCK(sc); } +static void +aue_setmulti(void *arg, int npending) +{ + struct aue_softc *sc = arg; + + AUE_LOCK(sc); + aue_setmulti_locked(sc); + AUE_UNLOCK(sc); +} + #define AUE_BITS 6 static void -aue_setmulti(struct usb_ether *ue) +aue_setmulti_locked(struct aue_softc *sc) { - struct aue_softc *sc = uether_getsc(ue); - struct ifnet *ifp = uether_getifp(ue); + struct ifnet *ifp = sc->sc_ifp; struct ifmultiaddr *ifma; uint32_t h = 0; uint32_t i; @@ -572,6 +597,7 @@ static void static void aue_reset_pegasus_II(struct aue_softc *sc) { + /* Magic constants taken from Linux driver. */ aue_csr_write_1(sc, AUE_REG_1D, 0); aue_csr_write_1(sc, AUE_REG_7B, 2); @@ -593,12 +619,11 @@ aue_reset(struct aue_softc *sc) for (i = 0; i != AUE_TIMEOUT; i++) { if (!(aue_csr_read_1(sc, AUE_CTL1) & AUE_CTL1_RESETMAC)) break; - if (uether_pause(&sc->sc_ue, hz / 100)) - break; + aue_pause(sc, hz / 100); } if (i == AUE_TIMEOUT) - device_printf(sc->sc_ue.ue_dev, "reset failed\n"); + device_printf(sc->sc_dev, "reset failed\n"); /* * The PHY(s) attached to the Pegasus chip may be held @@ -625,21 +650,9 @@ aue_reset(struct aue_softc *sc) aue_reset_pegasus_II(sc); /* Wait a little while for the chip to get its brains in order: */ - uether_pause(&sc->sc_ue, hz / 100); + aue_pause(sc, hz / 100); } -static void -aue_attach_post(struct usb_ether *ue) -{ - struct aue_softc *sc = uether_getsc(ue); - - /* reset the adapter */ - aue_reset(sc); - - /* get station address from the EEPROM */ - aue_read_eeprom(sc, ue->ue_eaddr, 0, 3); -} - /* * Probe for a Pegasus chip. */ @@ -676,7 +689,7 @@ aue_attach(device_t dev) { struct usb_attach_arg *uaa = device_get_ivars(dev); struct aue_softc *sc = device_get_softc(dev); - struct usb_ether *ue = &sc->sc_ue; + struct ifnet *ifp; uint8_t iface_index; int error; @@ -688,7 +701,16 @@ aue_attach(device_t dev) } device_set_usb_desc(dev); + sc->sc_dev = dev; + sc->sc_udev = uaa->device; + sc->sc_unit = uether_alloc_unr(); + mtx_init(&sc->sc_mtx, device_get_nameunit(dev), NULL, MTX_DEF); + sx_init(&sc->sc_sx, "aue sxlock"); + sleepout_create(&sc->sc_sleepout, "aue sleepout"); + sleepout_init_mtx(&sc->sc_sleepout, &sc->sc_watchdog, &sc->sc_mtx, 0); + TASK_INIT(&sc->sc_setmulti, 0, aue_setmulti, sc); + TASK_INIT(&sc->sc_setpromisc, 0, aue_setpromisc, sc); iface_index = AUE_IFACE_IDX; error = usbd_transfer_setup(uaa->device, &iface_index, @@ -699,19 +721,42 @@ aue_attach(device_t dev) goto detach; } - ue->ue_sc = sc; - ue->ue_dev = dev; - ue->ue_udev = uaa->device; - ue->ue_mtx = &sc->sc_mtx; - ue->ue_methods = &aue_ue_methods; + AUE_LOCK(sc); + /* reset the adapter */ + aue_reset(sc); + /* get station address from the EEPROM */ + aue_read_eeprom(sc, sc->sc_eaddr, 0, 3); + AUE_UNLOCK(sc); - error = uether_ifattach(ue); + sc->sc_ifp = ifp = if_alloc(IFT_ETHER); + if (ifp == NULL) { + device_printf(sc->sc_dev, "could not allocate ifnet\n"); + goto detach; + } + + ifp->if_softc = sc; + if_initname(ifp, "ue", sc->sc_unit); + ifp->if_mtu = ETHERMTU; + ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; + ifp->if_ioctl = aue_ioctl; + ifp->if_start = aue_start; + ifp->if_init = aue_init; + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); + ifp->if_snd.ifq_drv_maxlen = ifqmaxlen; + IFQ_SET_READY(&ifp->if_snd); + + error = mii_attach(sc->sc_dev, &sc->sc_miibus, ifp, + aue_ifmedia_upd, aue_ifmedia_sts, + BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, 0); if (error) { - device_printf(dev, "could not attach interface\n"); + device_printf(sc->sc_dev, "MII without any PHY\n"); goto detach; } - return (0); /* success */ + if_printf(ifp, " on %s\n", + device_get_nameunit(sc->sc_dev)); + ether_ifattach(ifp, sc->sc_eaddr); + return (0); detach: aue_detach(dev); return (ENXIO); /* failure */ @@ -721,11 +766,26 @@ static int aue_detach(device_t dev) { struct aue_softc *sc = device_get_softc(dev); - struct usb_ether *ue = &sc->sc_ue; + struct ifnet *ifp = sc->sc_ifp; + sleepout_drain(&sc->sc_watchdog); + SLEEPOUT_DRAINTASK(&sc->sc_sleepout, &sc->sc_setpromisc); + SLEEPOUT_DRAINTASK(&sc->sc_sleepout, &sc->sc_setmulti); usbd_transfer_unsetup(sc->sc_xfer, AUE_N_TRANSFER); - uether_ifdetach(ue); + + if (sc->sc_miibus != NULL) + device_delete_child(sc->sc_dev, sc->sc_miibus); + if (ifp != NULL) { + AUE_LOCK(sc); + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; + AUE_UNLOCK(sc); + ether_ifdetach(ifp); + if_free(ifp); + } + sleepout_free(&sc->sc_sleepout); + sx_destroy(&sc->sc_sx); mtx_destroy(&sc->sc_mtx); + uether_free_unr(sc->sc_unit); return (0); } @@ -734,7 +794,7 @@ static void aue_intr_callback(struct usb_xfer *xfer, usb_error_t error) { struct aue_softc *sc = usbd_xfer_softc(xfer); - struct ifnet *ifp = uether_getifp(&sc->sc_ue); + struct ifnet *ifp = sc->sc_ifp; struct aue_intrpkt pkt; struct usb_page_cache *pc; int actlen; @@ -743,10 +803,8 @@ aue_intr_callback(struct usb_xfer *xfer, usb_error switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: - if ((ifp->if_drv_flags & IFF_DRV_RUNNING) && actlen >= sizeof(pkt)) { - pc = usbd_xfer_get_frame(xfer, 0); usbd_copy_out(pc, 0, &pkt, sizeof(pkt)); @@ -762,7 +820,6 @@ tr_setup: usbd_xfer_set_frame_len(xfer, 0, usbd_xfer_max_len(xfer)); usbd_transfer_submit(xfer); return; - default: /* Error */ if (error != USB_ERR_CANCELLED) { /* try to clear stall first */ @@ -777,8 +834,7 @@ static void aue_bulk_read_callback(struct usb_xfer *xfer, usb_error_t error) { struct aue_softc *sc = usbd_xfer_softc(xfer); - struct usb_ether *ue = &sc->sc_ue; - struct ifnet *ifp = uether_getifp(ue); + struct ifnet *ifp = sc->sc_ifp; struct aue_rxpkt stat; struct usb_page_cache *pc; int actlen; @@ -791,13 +847,11 @@ aue_bulk_read_callback(struct usb_xfer *xfer, usb_ DPRINTFN(11, "received %d bytes\n", actlen); if (sc->sc_flags & AUE_FLAG_VER_2) { - if (actlen == 0) { ifp->if_ierrors++; goto tr_setup; } } else { - if (actlen <= sizeof(stat) + ETHER_CRC_LEN) { ifp->if_ierrors++; goto tr_setup; @@ -817,16 +871,14 @@ aue_bulk_read_callback(struct usb_xfer *xfer, usb_ /* No errors; receive the packet. */ actlen -= (sizeof(stat) + ETHER_CRC_LEN); } - uether_rxbuf(ue, pc, 0, actlen); - + aue_rxbuf(sc, pc, 0, actlen); /* FALLTHROUGH */ case USB_ST_SETUP: tr_setup: usbd_xfer_set_frame_len(xfer, 0, usbd_xfer_max_len(xfer)); usbd_transfer_submit(xfer); - uether_rxflush(ue); + aue_rxflush(sc); return; - default: /* Error */ DPRINTF("bulk read error, %s\n", usbd_errstr(error)); @@ -844,7 +896,7 @@ static void aue_bulk_write_callback(struct usb_xfer *xfer, usb_error_t error) { struct aue_softc *sc = usbd_xfer_softc(xfer); - struct ifnet *ifp = uether_getifp(&sc->sc_ue); + struct ifnet *ifp = sc->sc_ifp; struct usb_page_cache *pc; struct mbuf *m; uint8_t buf[2]; @@ -857,7 +909,6 @@ aue_bulk_write_callback(struct usb_xfer *xfer, usb case USB_ST_TRANSFERRED: DPRINTFN(11, "transfer of %d bytes complete\n", actlen); ifp->if_opackets++; - /* FALLTHROUGH */ case USB_ST_SETUP: tr_setup: @@ -874,13 +925,10 @@ tr_setup: if (m->m_pkthdr.len > MCLBYTES) m->m_pkthdr.len = MCLBYTES; if (sc->sc_flags & AUE_FLAG_VER_2) { - usbd_xfer_set_frame_len(xfer, 0, m->m_pkthdr.len); usbd_m_copy_in(pc, 0, m, 0, m->m_pkthdr.len); - } else { - usbd_xfer_set_frame_len(xfer, 0, (m->m_pkthdr.len + 2)); /* @@ -908,7 +956,6 @@ tr_setup: usbd_transfer_submit(xfer); return; - default: /* Error */ DPRINTFN(11, "transfer error, %s\n", usbd_errstr(error)); @@ -925,9 +972,8 @@ tr_setup: } static void -aue_tick(struct usb_ether *ue) +aue_tick(struct aue_softc *sc) { - struct aue_softc *sc = uether_getsc(ue); struct mii_data *mii = GET_MII(sc); AUE_LOCK_ASSERT(sc, MA_OWNED); @@ -937,15 +983,27 @@ static void && mii->mii_media_status & IFM_ACTIVE && IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { sc->sc_flags |= AUE_FLAG_LINK; - aue_start(ue); + aue_start_locked(sc->sc_ifp); } } static void -aue_start(struct usb_ether *ue) +aue_start(struct ifnet *ifp) { - struct aue_softc *sc = uether_getsc(ue); + struct aue_softc *sc = ifp->if_softc; + AUE_LOCK(sc); + aue_start_locked(ifp); + AUE_UNLOCK(sc); +} + +static void +aue_start_locked(struct ifnet *ifp) +{ + struct aue_softc *sc = ifp->if_softc; + + AUE_LOCK_ASSERT(sc, MA_OWNED); + /* * start the USB transfers, if not already started: */ @@ -955,10 +1013,21 @@ static void } static void -aue_init(struct usb_ether *ue) +aue_init(void *arg) { - struct aue_softc *sc = uether_getsc(ue); - struct ifnet *ifp = uether_getifp(ue); + struct aue_softc *sc = arg; + + AUE_SXLOCK(sc); + AUE_LOCK(sc); + aue_init_locked(sc); + AUE_UNLOCK(sc); + AUE_SXUNLOCK(sc); +} + +static void +aue_init_locked(struct aue_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; int i; AUE_LOCK_ASSERT(sc, MA_OWNED); @@ -973,10 +1042,10 @@ static void aue_csr_write_1(sc, AUE_PAR0 + i, IF_LLADDR(ifp)[i]); /* update promiscuous setting */ - aue_setpromisc(ue); + aue_setpromisc_locked(sc); /* Load the multicast filter. */ - aue_setmulti(ue); + aue_setmulti_locked(sc); /* Enable RX and TX */ aue_csr_write_1(sc, AUE_CTL0, AUE_CTL0_RXSTAT_APPEND | AUE_CTL0_RX_ENB); @@ -986,15 +1055,25 @@ static void usbd_xfer_set_stall(sc->sc_xfer[AUE_BULK_DT_WR]); ifp->if_drv_flags |= IFF_DRV_RUNNING; - aue_start(ue); + sleepout_reset(&sc->sc_watchdog, hz, aue_watchdog, sc); + aue_start_locked(sc->sc_ifp); } static void -aue_setpromisc(struct usb_ether *ue) +aue_setpromisc(void *arg, int npending) { - struct aue_softc *sc = uether_getsc(ue); - struct ifnet *ifp = uether_getifp(ue); + struct aue_softc *sc = arg; + AUE_LOCK(sc); + aue_setpromisc_locked(sc); + AUE_UNLOCK(sc); +} + +static void +aue_setpromisc_locked(struct aue_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + AUE_LOCK_ASSERT(sc, MA_OWNED); /* if we want promiscuous mode, set the allframes bit: */ @@ -1013,8 +1092,7 @@ aue_ifmedia_upd(struct ifnet *ifp) struct aue_softc *sc = ifp->if_softc; struct mii_data *mii = GET_MII(sc); - AUE_LOCK_ASSERT(sc, MA_OWNED); - + AUE_LOCK(sc); sc->sc_flags &= ~AUE_FLAG_LINK; if (mii->mii_instance) { struct mii_softc *miisc; @@ -1023,6 +1101,7 @@ aue_ifmedia_upd(struct ifnet *ifp) mii_phy_reset(miisc); } mii_mediachg(mii); + AUE_UNLOCK(sc); return (0); } @@ -1047,11 +1126,21 @@ aue_ifmedia_sts(struct ifnet *ifp, struct ifmediar * RX and TX lists. */ static void -aue_stop(struct usb_ether *ue) +aue_stop(struct aue_softc *sc) { - struct aue_softc *sc = uether_getsc(ue); - struct ifnet *ifp = uether_getifp(ue); + AUE_SXLOCK(sc); + AUE_LOCK(sc); + aue_stop_locked(sc); + AUE_UNLOCK(sc); + AUE_SXUNLOCK(sc); +} + +static void +aue_stop_locked(struct aue_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + AUE_LOCK_ASSERT(sc, MA_OWNED); ifp->if_drv_flags &= ~IFF_DRV_RUNNING; @@ -1068,3 +1157,125 @@ static void aue_csr_write_1(sc, AUE_CTL1, 0); aue_reset(sc); } + +static int +aue_ioctl(struct ifnet *ifp, u_long command, caddr_t data) +{ + struct aue_softc *sc = ifp->if_softc; + struct ifreq *ifr = (struct ifreq *)data; + struct mii_data *mii = GET_MII(sc); + int error = 0, drv_flags, flags; + + switch (command) { + case SIOCSIFFLAGS: + /* Avoids race and LOR between mutex and sx lock. */ + AUE_LOCK(sc); + flags = ifp->if_flags; + drv_flags = ifp->if_drv_flags; + AUE_UNLOCK(sc); + /* device up and down is synchronous using sx(9) lock */ + if (flags & IFF_UP) { + if (drv_flags & IFF_DRV_RUNNING) + SLEEPOUT_RUNTASK(&sc->sc_sleepout, + &sc->sc_setpromisc); + else + aue_init(sc); + } else + aue_stop(sc); + break; + case SIOCADDMULTI: + case SIOCDELMULTI: + /* To avoid LOR by in_multi_mtx (netinet/in_mcast.c) */ + if (ifp->if_flags & IFF_UP && + ifp->if_drv_flags & IFF_DRV_RUNNING) + SLEEPOUT_RUNTASK(&sc->sc_sleepout, &sc->sc_setmulti); + break; + case SIOCGIFMEDIA: + case SIOCSIFMEDIA: + error = ifmedia_ioctl(ifp, ifr, &mii->mii_media, command); + break; + default: + error = ether_ioctl(ifp, command, data); + break; + } + return (error); +} + +static void +aue_rxflush(struct aue_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + struct mbuf *m; + + AUE_LOCK_ASSERT(sc, MA_OWNED); + + for (;;) { + _IF_DEQUEUE(&sc->sc_rxq, m); + if (m == NULL) + break; + + /* + * The USB xfer has been resubmitted so its safe to unlock now. + */ + AUE_UNLOCK(sc); + ifp->if_input(ifp, m); + AUE_LOCK(sc); + } +} + +static struct mbuf * +aue_newbuf(void) +{ + struct mbuf *m_new; + + m_new = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR); + if (m_new == NULL) + return (NULL); + m_new->m_len = m_new->m_pkthdr.len = MCLBYTES; + + m_adj(m_new, ETHER_ALIGN); + return (m_new); +} + +static int +aue_rxbuf(struct aue_softc *sc, struct usb_page_cache *pc, + unsigned int offset, unsigned int len) +{ + struct ifnet *ifp = sc->sc_ifp; + struct mbuf *m; + + AUE_LOCK_ASSERT(sc, MA_OWNED); + + if (len < ETHER_HDR_LEN || len > MCLBYTES - ETHER_ALIGN) + return (1); + + m = aue_newbuf(); + if (m == NULL) { + ifp->if_ierrors++; + return (ENOMEM); + } + + usbd_copy_out(pc, offset, mtod(m, uint8_t *), len); + + /* finalize mbuf */ + ifp->if_ipackets++; + m->m_pkthdr.rcvif = ifp; + m->m_pkthdr.len = m->m_len = len; + + /* enqueue for later when the lock can be released */ + _IF_ENQUEUE(&sc->sc_rxq, m); + return (0); +} + +static void +aue_watchdog(void *arg) +{ + struct aue_softc *sc = arg; + struct ifnet *ifp = sc->sc_ifp; + + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) + return; + + aue_tick(sc); + sleepout_reset(&sc->sc_watchdog, hz, aue_watchdog, sc); +} Index: if_auereg.h =================================================================== --- if_auereg.h (revision 214568) +++ if_auereg.h (working copy) @@ -183,7 +183,7 @@ enum { #define AUE_RXSTAT_DRIBBLE 0x10 #define AUE_RXSTAT_MASK 0x1E -#define GET_MII(sc) uether_getmii(&(sc)->sc_ue) +#define GET_MII(sc) (device_get_softc(sc->sc_miibus)) struct aue_intrpkt { uint8_t aue_txstat0; @@ -202,10 +202,16 @@ struct aue_rxpkt { } __packed; struct aue_softc { - struct usb_ether sc_ue; + struct ifnet *sc_ifp; + device_t sc_dev; + device_t sc_miibus; + struct usb_device *sc_udev; /* used by uether_do_request() */ + struct usb_xfer *sc_xfer[AUE_N_TRANSFER]; struct mtx sc_mtx; - struct usb_xfer *sc_xfer[AUE_N_TRANSFER]; - + struct sx sc_sx; + struct ifqueue sc_rxq; + /* ethernet address from eeprom */ + uint8_t sc_eaddr[ETHER_ADDR_LEN]; int sc_flags; #define AUE_FLAG_LSYS 0x0001 /* use Linksys reset */ #define AUE_FLAG_PNA 0x0002 /* has Home PNA */ @@ -213,8 +219,16 @@ struct aue_softc { #define AUE_FLAG_LINK 0x0008 /* wait for link to come up */ #define AUE_FLAG_VER_2 0x0200 /* chip is version 2 */ #define AUE_FLAG_DUAL_PHY 0x0400 /* chip has two transcivers */ + int sc_unit; + + struct sleepout sc_sleepout; + struct sleepout_task sc_watchdog; + struct task sc_setmulti; + struct task sc_setpromisc; }; +#define AUE_SXLOCK(_sc) sx_xlock(&(_sc)->sc_sx) +#define AUE_SXUNLOCK(_sc) sx_xunlock(&(_sc)->sc_sx) #define AUE_LOCK(_sc) mtx_lock(&(_sc)->sc_mtx) #define AUE_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx) #define AUE_LOCK_ASSERT(_sc, t) mtx_assert(&(_sc)->sc_mtx, t) Index: usb_ethernet.h =================================================================== --- usb_ethernet.h (revision 214568) +++ usb_ethernet.h (working copy) @@ -119,4 +119,7 @@ int uether_rxbuf(struct usb_ether *, unsigned int, unsigned int); void uether_rxflush(struct usb_ether *); uint8_t uether_is_gone(struct usb_ether *); +int uether_alloc_unr(void); +void uether_free_unr(int); + #endif /* _USB_ETHERNET_H_ */ From owner-freebsd-usb@FreeBSD.ORG Sun Oct 31 21:50:09 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCDF1106566C; Sun, 31 Oct 2010 21:50:09 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 44B388FC08; Sun, 31 Oct 2010 21:50:06 +0000 (UTC) Received: by wyb42 with SMTP id 42so4890634wyb.13 for ; Sun, 31 Oct 2010 14:50:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.157.85 with SMTP id a21mr99513wbx.99.1288561805936; Sun, 31 Oct 2010 14:50:05 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.227.146.67 with HTTP; Sun, 31 Oct 2010 14:50:05 -0700 (PDT) In-Reply-To: <20101031214704.GA3918@weongyo> References: <20101031214704.GA3918@weongyo> Date: Mon, 1 Nov 2010 10:50:05 +1300 X-Google-Sender-Auth: yYbipCgr-C_5Oq2C21GuuPfuxJE Message-ID: From: Andrew Thompson To: Weongyo Jeong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org Subject: Re: [CFR 2/n] removes uther dependency of aue(4) X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 21:50:09 -0000 On 1 November 2010 10:47, Weongyo Jeong wrote: > Hello, > > The following patch is to remove uether(4) dependency of aue(4) and > change logs would be as follows: > > =A0- removes uether module dependency of aue(4) that finally uether > =A0 =A0module would be gone. =A0The reasons why I'm trying to remove ueth= er > =A0 =A0module are that > =A0 =A0 =A0I discussed with USB ethernet maintainers about whether it's > =A0 =A0 =A0useful or not. =A0yongari@ answered that it's not helpful, not > =A0 =A0 =A0straight forward to understand and make code complex. > =A0- adds newly two uether APIs, uether_alloc_unr and uether_free_unr for > =A0 =A0backward compatibility because current interface names for each > =A0 =A0ethernet devices are linux-style `ue[0-9]+'. =A0The naming rule wo= uld > =A0 =A0be kept at STABLE_8 but not sure at STABLE_9. > > If no objections I'd like to see this patch at HEAD. No objections here. From owner-freebsd-usb@FreeBSD.ORG Sun Oct 31 22:43:09 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B587A106564A; Sun, 31 Oct 2010 22:43:09 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7398FC08; Sun, 31 Oct 2010 22:43:09 +0000 (UTC) Received: by vws12 with SMTP id 12so3002173vws.13 for ; Sun, 31 Oct 2010 15:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent:organization:x-operation-sytem; bh=p0SKQsPHZHPMDrD+yI/baAokqVVA0a43FmCNR+If4PI=; b=kN3NIDHZJwWlfM3kvGT69bt3+TX/SutFd56IylF92/2EucsYZ7wBfalsvadPrzRD8w u6BdOvViyfeLDjZmmFFpWCGv2yUmKqFwuRLGXmRsztpOBOamo0UOJv1Xtwq1S9ndRi/5 yuBa37dPc+ntc75zobM5uSSkQnX2adubtlWrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition:user-agent:organization :x-operation-sytem; b=UYKff4VG91EleSqkhhQs2EzL2kEDgb/QiJ8/SUtzSqtmM21sZCrpGFdEqrRE3DmVKC jzYSURlu327SIL01D7gP+BxzAimp9CKx2pbb/c0HXb/MQmTb2DAbLyGZY6/nJljeySdh t9QCuIJatgZ3m4/sqlLQ7BpEBc1kTMzsHEBko= Received: by 10.229.224.82 with SMTP id in18mr498406qcb.262.1288564988705; Sun, 31 Oct 2010 15:43:08 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id s28sm4386950qcp.21.2010.10.31.15.43.05 (version=SSLv3 cipher=RC4-MD5); Sun, 31 Oct 2010 15:43:07 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Sun, 31 Oct 2010 15:43:04 -0700 From: Weongyo Jeong Date: Sun, 31 Oct 2010 15:43:04 -0700 To: freebsd-usb@freebsd.org Message-ID: <20101031224304.GB3918@weongyo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Subject: [CFR 3/n] removes uther dependency of axe(4) X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 22:43:09 -0000 Hello, As one of patch series it's for patching axe(4) without dependency of uether module. The change log would be almost same like the previous patch log. regards, Weongyo Jeong Index: if_axereg.h =================================================================== --- if_axereg.h (revision 214604) +++ if_axereg.h (working copy) @@ -185,7 +185,7 @@ struct axe_sframe_hdr { uint16_t ilen; } __packed; -#define GET_MII(sc) uether_getmii(&(sc)->sc_ue) +#define GET_MII(sc) (device_get_softc(sc->sc_miibus)) /* The interrupt endpoint is currently unused by the ASIX part. */ enum { @@ -195,20 +195,35 @@ enum { }; struct axe_softc { - struct usb_ether sc_ue; + struct ifnet *sc_ifp; + device_t sc_dev; + device_t sc_miibus; + struct usb_device *sc_udev; /* used by uether_do_request() */ struct mtx sc_mtx; - struct usb_xfer *sc_xfer[AXE_N_TRANSFER]; + struct sx sc_sx; + struct usb_xfer *sc_xfer[AXE_N_TRANSFER]; + + /* ethernet address from eeprom */ + uint8_t sc_eaddr[ETHER_ADDR_LEN]; + struct ifqueue sc_rxq; + + struct sleepout sc_sleepout; + struct sleepout_task sc_watchdog; + struct task sc_setmulti; + struct task sc_setpromisc; + + int sc_unit; int sc_phyno; - int sc_flags; #define AXE_FLAG_LINK 0x0001 #define AXE_FLAG_772 0x1000 /* AX88772 */ #define AXE_FLAG_178 0x2000 /* AX88178 */ - uint8_t sc_ipgs[3]; uint8_t sc_phyaddrs[2]; }; +#define AXE_SXLOCK(_sc) sx_xlock(&(_sc)->sc_sx) +#define AXE_SXUNLOCK(_sc) sx_xunlock(&(_sc)->sc_sx) #define AXE_LOCK(_sc) mtx_lock(&(_sc)->sc_mtx) #define AXE_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx) #define AXE_LOCK_ASSERT(_sc, t) mtx_assert(&(_sc)->sc_mtx, t) Index: if_axe.c =================================================================== --- if_axe.c (revision 214604) +++ if_axe.c (working copy) @@ -89,6 +89,8 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include +#include #include #include #include @@ -96,6 +98,19 @@ __FBSDID("$FreeBSD$"); #include #include +#include +#include +#include +#include +#include +#include +#include + +#include "miibus_if.h" + +#include +#include + #include #include #include @@ -104,6 +119,7 @@ __FBSDID("$FreeBSD$"); #define USB_DEBUG_VAR axe_debug #include #include +#include #include #include @@ -178,23 +194,26 @@ static miibus_readreg_t axe_miibus_readreg; static miibus_writereg_t axe_miibus_writereg; static miibus_statchg_t axe_miibus_statchg; -static uether_fn_t axe_attach_post; -static uether_fn_t axe_init; -static uether_fn_t axe_stop; -static uether_fn_t axe_start; -static uether_fn_t axe_tick; -static uether_fn_t axe_setmulti; -static uether_fn_t axe_setpromisc; - static int axe_ifmedia_upd(struct ifnet *); static void axe_ifmedia_sts(struct ifnet *, struct ifmediareq *); static int axe_cmd(struct axe_softc *, int, int, int, void *); static void axe_ax88178_init(struct axe_softc *); static void axe_ax88772_init(struct axe_softc *); static int axe_get_phyno(struct axe_softc *, int); +static void axe_watchdog(void *); +static void axe_init(void *); +static void axe_init_locked(struct axe_softc *); +static int axe_ioctl(struct ifnet *, u_long, caddr_t); +static void axe_start(struct ifnet *); +static void axe_start_locked(struct ifnet *); +static void axe_tick(struct axe_softc *); +static void axe_stop(struct axe_softc *); +static void axe_stop_locked(struct axe_softc *); +static void axe_setmulti_locked(struct axe_softc *); +static void axe_setpromisc(void *, int); +static void axe_setpromisc_locked(struct axe_softc *); static const struct usb_config axe_config[AXE_N_TRANSFER] = { - [AXE_BULK_DT_WR] = { .type = UE_BULK, .endpoint = UE_ADDR_ANY, @@ -250,18 +269,14 @@ MODULE_DEPEND(axe, ether, 1, 1, 1); MODULE_DEPEND(axe, miibus, 1, 1, 1); MODULE_VERSION(axe, 1); -static const struct usb_ether_methods axe_ue_methods = { - .ue_attach_post = axe_attach_post, - .ue_start = axe_start, - .ue_init = axe_init, - .ue_stop = axe_stop, - .ue_tick = axe_tick, - .ue_setmulti = axe_setmulti, - .ue_setpromisc = axe_setpromisc, - .ue_mii_upd = axe_ifmedia_upd, - .ue_mii_sts = axe_ifmedia_sts, -}; +static uint8_t +axe_pause(struct axe_softc *sc, unsigned int _ticks) +{ + usb_pause_mtx(&sc->sc_mtx, _ticks); + return (0); +} + static int axe_cmd(struct axe_softc *sc, int cmd, int index, int val, void *buf) { @@ -278,7 +293,8 @@ axe_cmd(struct axe_softc *sc, int cmd, int index, USETW(req.wIndex, index); USETW(req.wLength, AXE_CMD_LEN(cmd)); - err = uether_do_request(&sc->sc_ue, &req, buf, 1000); + err = usbd_do_request_flags(sc->sc_udev, &sc->sc_mtx, &req, buf, 0, + NULL, 1000); return (err); } @@ -354,7 +370,7 @@ axe_miibus_statchg(device_t dev) if (!locked) AXE_LOCK(sc); - ifp = uether_getifp(&sc->sc_ue); + ifp = sc->sc_ifp; if (mii == NULL || ifp == NULL || (ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) goto done; @@ -418,8 +434,7 @@ axe_ifmedia_upd(struct ifnet *ifp) struct mii_data *mii = GET_MII(sc); int error; - AXE_LOCK_ASSERT(sc, MA_OWNED); - + AXE_LOCK(sc); if (mii->mii_instance) { struct mii_softc *miisc; @@ -427,6 +442,7 @@ axe_ifmedia_upd(struct ifnet *ifp) mii_phy_reset(miisc); } error = mii_mediachg(mii); + AXE_UNLOCK(sc); return (error); } @@ -447,10 +463,19 @@ axe_ifmedia_sts(struct ifnet *ifp, struct ifmediar } static void -axe_setmulti(struct usb_ether *ue) +axe_setmulti(void *arg, int npending) { - struct axe_softc *sc = uether_getsc(ue); - struct ifnet *ifp = uether_getifp(ue); + struct axe_softc *sc = arg; + + AXE_LOCK(sc); + axe_setmulti_locked(sc); + AXE_UNLOCK(sc); +} + +static void +axe_setmulti_locked(struct axe_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; struct ifmultiaddr *ifma; uint32_t h = 0; uint16_t rxmode; @@ -509,17 +534,15 @@ axe_get_phyno(struct axe_softc *sc, int sel) #define AXE_GPIO_WRITE(x, y) do { \ axe_cmd(sc, AXE_CMD_WRITE_GPIO, 0, (x), NULL); \ - uether_pause(ue, (y)); \ + axe_pause(sc, (y)); \ } while (0) static void axe_ax88178_init(struct axe_softc *sc) { - struct usb_ether *ue; int gpio0, phymode; uint16_t eeprom, val; - ue = &sc->sc_ue; axe_cmd(sc, AXE_CMD_SROM_WR_ENABLE, 0, 0, NULL); /* XXX magic */ axe_cmd(sc, AXE_CMD_SROM_READ, 0, 0x0017, &eeprom); @@ -536,7 +559,7 @@ axe_ax88178_init(struct axe_softc *sc) } if (bootverbose) - device_printf(sc->sc_ue.ue_dev, "EEPROM data : 0x%04x\n", + device_printf(sc->sc_dev, "EEPROM data : 0x%04x\n", eeprom); /* Program GPIOs depending on PHY hardware. */ switch (phymode) { @@ -580,15 +603,15 @@ axe_ax88178_init(struct axe_softc *sc) AXE_GPIO_WRITE(val | AXE_GPIO2_EN, hz / 4); AXE_GPIO_WRITE(val | AXE_GPIO2 | AXE_GPIO2_EN, hz / 32); if (phymode == AXE_PHY_MODE_REALTEK_8211CL) { - axe_miibus_writereg(ue->ue_dev, sc->sc_phyno, + axe_miibus_writereg(sc->sc_dev, sc->sc_phyno, 0x1F, 0x0005); - axe_miibus_writereg(ue->ue_dev, sc->sc_phyno, + axe_miibus_writereg(sc->sc_dev, sc->sc_phyno, 0x0C, 0x0000); - val = axe_miibus_readreg(ue->ue_dev, sc->sc_phyno, + val = axe_miibus_readreg(sc->sc_dev, sc->sc_phyno, 0x0001); - axe_miibus_writereg(ue->ue_dev, sc->sc_phyno, + axe_miibus_writereg(sc->sc_dev, sc->sc_phyno, 0x01, val | 0x0080); - axe_miibus_writereg(ue->ue_dev, sc->sc_phyno, + axe_miibus_writereg(sc->sc_dev, sc->sc_phyno, 0x1F, 0x0000); } break; @@ -599,14 +622,14 @@ axe_ax88178_init(struct axe_softc *sc) /* soft reset */ axe_cmd(sc, AXE_CMD_SW_RESET_REG, 0, AXE_SW_RESET_CLEAR, NULL); - uether_pause(ue, hz / 4); + axe_pause(sc, hz / 4); axe_cmd(sc, AXE_CMD_SW_RESET_REG, 0, AXE_SW_RESET_PRL | AXE_178_RESET_MAGIC, NULL); - uether_pause(ue, hz / 4); + axe_pause(sc, hz / 4); /* Enable MII/GMII/RGMII interface to work with external PHY. */ axe_cmd(sc, AXE_CMD_SW_PHY_SELECT, 0, 0, NULL); - uether_pause(ue, hz / 4); + axe_pause(sc, hz / 4); axe_cmd(sc, AXE_CMD_RXCTL_WRITE, 0, 0, NULL); } @@ -615,23 +638,24 @@ axe_ax88178_init(struct axe_softc *sc) static void axe_ax88772_init(struct axe_softc *sc) { + axe_cmd(sc, AXE_CMD_WRITE_GPIO, 0, 0x00b0, NULL); - uether_pause(&sc->sc_ue, hz / 16); + axe_pause(sc, hz / 16); if (sc->sc_phyno == AXE_772_PHY_NO_EPHY) { /* ask for the embedded PHY */ axe_cmd(sc, AXE_CMD_SW_PHY_SELECT, 0, 0x01, NULL); - uether_pause(&sc->sc_ue, hz / 64); + axe_pause(sc, hz / 64); /* power down and reset state, pin reset state */ axe_cmd(sc, AXE_CMD_SW_RESET_REG, 0, AXE_SW_RESET_CLEAR, NULL); - uether_pause(&sc->sc_ue, hz / 16); + axe_pause(sc, hz / 16); /* power down/reset state, pin operating state */ axe_cmd(sc, AXE_CMD_SW_RESET_REG, 0, AXE_SW_RESET_IPPD | AXE_SW_RESET_PRL, NULL); - uether_pause(&sc->sc_ue, hz / 4); + axe_pause(sc, hz / 4); /* power up, reset */ axe_cmd(sc, AXE_CMD_SW_RESET_REG, 0, AXE_SW_RESET_PRL, NULL); @@ -642,14 +666,14 @@ axe_ax88772_init(struct axe_softc *sc) } else { /* ask for external PHY */ axe_cmd(sc, AXE_CMD_SW_PHY_SELECT, 0, 0x00, NULL); - uether_pause(&sc->sc_ue, hz / 64); + axe_pause(sc, hz / 64); /* power down internal PHY */ axe_cmd(sc, AXE_CMD_SW_RESET_REG, 0, AXE_SW_RESET_IPPD | AXE_SW_RESET_PRL, NULL); } - uether_pause(&sc->sc_ue, hz / 4); + axe_pause(sc, hz / 4); axe_cmd(sc, AXE_CMD_RXCTL_WRITE, 0, 0, NULL); } @@ -659,34 +683,33 @@ axe_reset(struct axe_softc *sc) struct usb_config_descriptor *cd; usb_error_t err; - cd = usbd_get_config_descriptor(sc->sc_ue.ue_udev); + cd = usbd_get_config_descriptor(sc->sc_udev); - err = usbd_req_set_config(sc->sc_ue.ue_udev, &sc->sc_mtx, + err = usbd_req_set_config(sc->sc_udev, &sc->sc_mtx, cd->bConfigurationValue); if (err) DPRINTF("reset failed (ignored)\n"); /* Wait a little while for the chip to get its brains in order. */ - uether_pause(&sc->sc_ue, hz / 100); + axe_pause(sc, hz / 100); } static void -axe_attach_post(struct usb_ether *ue) +axe_attach_post(struct axe_softc *sc) { - struct axe_softc *sc = uether_getsc(ue); /* * Load PHY indexes first. Needed by axe_xxx_init(). */ axe_cmd(sc, AXE_CMD_READ_PHYID, 0, 0, sc->sc_phyaddrs); if (bootverbose) - device_printf(sc->sc_ue.ue_dev, "PHYADDR 0x%02x:0x%02x\n", + device_printf(sc->sc_dev, "PHYADDR 0x%02x:0x%02x\n", sc->sc_phyaddrs[0], sc->sc_phyaddrs[1]); sc->sc_phyno = axe_get_phyno(sc, AXE_PHY_SEL_PRI); if (sc->sc_phyno == -1) sc->sc_phyno = axe_get_phyno(sc, AXE_PHY_SEL_SEC); if (sc->sc_phyno == -1) { - device_printf(sc->sc_ue.ue_dev, + device_printf(sc->sc_dev, "no valid PHY address found, assuming PHY address 0\n"); sc->sc_phyno = 0; } @@ -700,9 +723,9 @@ static void * Get station address. */ if (sc->sc_flags & (AXE_FLAG_178 | AXE_FLAG_772)) - axe_cmd(sc, AXE_178_CMD_READ_NODEID, 0, 0, ue->ue_eaddr); + axe_cmd(sc, AXE_178_CMD_READ_NODEID, 0, 0, sc->sc_eaddr); else - axe_cmd(sc, AXE_172_CMD_READ_NODEID, 0, 0, ue->ue_eaddr); + axe_cmd(sc, AXE_172_CMD_READ_NODEID, 0, 0, sc->sc_eaddr); /* * Fetch IPG values. @@ -728,6 +751,19 @@ axe_probe(device_t dev) return (usbd_lookup_id_by_uaa(axe_devs, sizeof(axe_devs), uaa)); } +static void +axe_watchdog(void *arg) +{ + struct axe_softc *sc = arg; + struct ifnet *ifp = sc->sc_ifp; + + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) + return; + + axe_tick(sc); + sleepout_reset(&sc->sc_watchdog, hz, axe_watchdog, sc); +} + /* * Attach the interface. Allocate softc structures, do ifmedia * setup and ethernet/BPF attach. @@ -737,15 +773,23 @@ axe_attach(device_t dev) { struct usb_attach_arg *uaa = device_get_ivars(dev); struct axe_softc *sc = device_get_softc(dev); - struct usb_ether *ue = &sc->sc_ue; + struct ifnet *ifp; uint8_t iface_index; int error; sc->sc_flags = USB_GET_DRIVER_INFO(uaa); + sc->sc_dev = dev; + sc->sc_udev = uaa->device; + sc->sc_unit = uether_alloc_unr(); device_set_usb_desc(dev); mtx_init(&sc->sc_mtx, device_get_nameunit(dev), NULL, MTX_DEF); + sx_init(&sc->sc_sx, "axe sxlock"); + sleepout_create(&sc->sc_sleepout, "axe sleepout"); + sleepout_init_mtx(&sc->sc_sleepout, &sc->sc_watchdog, &sc->sc_mtx, 0); + TASK_INIT(&sc->sc_setmulti, 0, axe_setmulti, sc); + TASK_INIT(&sc->sc_setpromisc, 0, axe_setpromisc, sc); iface_index = AXE_IFACE_IDX; error = usbd_transfer_setup(uaa->device, &iface_index, sc->sc_xfer, @@ -755,19 +799,39 @@ axe_attach(device_t dev) goto detach; } - ue->ue_sc = sc; - ue->ue_dev = dev; - ue->ue_udev = uaa->device; - ue->ue_mtx = &sc->sc_mtx; - ue->ue_methods = &axe_ue_methods; + AXE_LOCK(sc); + axe_attach_post(sc); + AXE_UNLOCK(sc); - error = uether_ifattach(ue); - if (error) { - device_printf(dev, "could not attach interface\n"); + sc->sc_ifp = ifp = if_alloc(IFT_ETHER); + if (ifp == NULL) { + device_printf(sc->sc_dev, "could not allocate ifnet\n"); goto detach; } - return (0); /* success */ + ifp->if_softc = sc; + if_initname(ifp, "ue", sc->sc_unit); + ifp->if_mtu = ETHERMTU; + ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; + ifp->if_ioctl = axe_ioctl; + ifp->if_start = axe_start; + ifp->if_init = axe_init; + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); + ifp->if_snd.ifq_drv_maxlen = ifqmaxlen; + IFQ_SET_READY(&ifp->if_snd); + + error = mii_attach(sc->sc_dev, &sc->sc_miibus, ifp, + axe_ifmedia_upd, axe_ifmedia_sts, + BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, 0); + if (error) { + device_printf(sc->sc_dev, "MII without any PHY\n"); + goto error2; + } + + if_printf(ifp, " on %s\n", + device_get_nameunit(sc->sc_dev)); + ether_ifattach(ifp, sc->sc_eaddr); + return (0); detach: axe_detach(dev); return (ENXIO); /* failure */ @@ -777,15 +841,96 @@ static int axe_detach(device_t dev) { struct axe_softc *sc = device_get_softc(dev); - struct usb_ether *ue = &sc->sc_ue; + struct ifnet *ifp = sc->sc_ifp; + sleepout_drain(&sc->sc_watchdog); + SLEEPOUT_DRAINTASK(&sc->sc_sleepout, &sc->sc_setpromisc); + SLEEPOUT_DRAINTASK(&sc->sc_sleepout, &sc->sc_setmulti); usbd_transfer_unsetup(sc->sc_xfer, AXE_N_TRANSFER); - uether_ifdetach(ue); + + if (sc->sc_miibus != NULL) + device_delete_child(sc->sc_dev, sc->sc_miibus); + if (ifp != NULL) { + AXE_LOCK(sc); + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; + AXE_UNLOCK(sc); + ether_ifdetach(ifp); + if_free(ifp); + } + sleepout_free(&sc->sc_sleepout); + sx_destroy(&sc->sc_sx); mtx_destroy(&sc->sc_mtx); + uether_free_unr(sc->sc_unit); return (0); } +static void +axe_rxflush(struct axe_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + struct mbuf *m; + + AXE_LOCK_ASSERT(sc, MA_OWNED); + + for (;;) { + _IF_DEQUEUE(&sc->sc_rxq, m); + if (m == NULL) + break; + + /* + * The USB xfer has been resubmitted so its safe to unlock now. + */ + AXE_UNLOCK(sc); + ifp->if_input(ifp, m); + AXE_LOCK(sc); + } +} + +static struct mbuf * +axe_newbuf(void) +{ + struct mbuf *m_new; + + m_new = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR); + if (m_new == NULL) + return (NULL); + m_new->m_len = m_new->m_pkthdr.len = MCLBYTES; + + m_adj(m_new, ETHER_ALIGN); + return (m_new); +} + +static int +axe_rxbuf(struct axe_softc *sc, struct usb_page_cache *pc, + unsigned int offset, unsigned int len) +{ + struct ifnet *ifp = sc->sc_ifp; + struct mbuf *m; + + AXE_LOCK_ASSERT(sc, MA_OWNED); + + if (len < ETHER_HDR_LEN || len > MCLBYTES - ETHER_ALIGN) + return (1); + + m = axe_newbuf(); + if (m == NULL) { + ifp->if_ierrors++; + return (ENOMEM); + } + + usbd_copy_out(pc, offset, mtod(m, uint8_t *), len); + + /* finalize mbuf */ + ifp->if_ipackets++; + m->m_pkthdr.rcvif = ifp; + m->m_pkthdr.len = m->m_len = len; + + /* enqueue for later when the lock can be released */ + _IF_ENQUEUE(&sc->sc_rxq, m); + return (0); +} + #if (AXE_BULK_BUF_SIZE >= 0x10000) #error "Please update axe_bulk_read_callback()!" #endif @@ -794,8 +939,7 @@ static void axe_bulk_read_callback(struct usb_xfer *xfer, usb_error_t error) { struct axe_softc *sc = usbd_xfer_softc(xfer); - struct usb_ether *ue = &sc->sc_ue; - struct ifnet *ifp = uether_getifp(ue); + struct ifnet *ifp = sc->sc_ifp; struct axe_sframe_hdr hdr; struct usb_page_cache *pc; int err, pos, len; @@ -832,24 +976,22 @@ axe_bulk_read_callback(struct usb_xfer *xfer, usb_ err = EINVAL; break; } - uether_rxbuf(ue, pc, pos, len); + err = axe_rxbuf(sc, pc, pos, len); pos += len + (len % 2); } } else - uether_rxbuf(ue, pc, 0, actlen); + err = axe_rxbuf(sc, pc, 0, actlen); if (err != 0) ifp->if_ierrors++; - /* FALLTHROUGH */ case USB_ST_SETUP: tr_setup: usbd_xfer_set_frame_len(xfer, 0, usbd_xfer_max_len(xfer)); usbd_transfer_submit(xfer); - uether_rxflush(ue); + axe_rxflush(sc); return; - default: /* Error */ DPRINTF("bulk read error, %s\n", usbd_errstr(error)); @@ -859,7 +1001,6 @@ tr_setup: goto tr_setup; } return; - } } @@ -872,7 +1013,7 @@ axe_bulk_write_callback(struct usb_xfer *xfer, usb { struct axe_softc *sc = usbd_xfer_softc(xfer); struct axe_sframe_hdr hdr; - struct ifnet *ifp = uether_getifp(&sc->sc_ue); + struct ifnet *ifp = sc->sc_ifp; struct usb_page_cache *pc; struct mbuf *m; int pos; @@ -896,7 +1037,6 @@ tr_setup: pc = usbd_xfer_get_frame(xfer, 0); while (1) { - IFQ_DRV_DEQUEUE(&ifp->if_snd, m); if (m == NULL) { @@ -904,11 +1044,9 @@ tr_setup: break; /* send out data */ return; } - if (m->m_pkthdr.len > MCLBYTES) { + if (m->m_pkthdr.len > MCLBYTES) m->m_pkthdr.len = MCLBYTES; - } if (sc->sc_flags & (AXE_FLAG_772 | AXE_FLAG_178)) { - hdr.len = htole16(m->m_pkthdr.len); hdr.ilen = ~hdr.len; @@ -961,7 +1099,6 @@ tr_setup: usbd_transfer_submit(xfer); ifp->if_drv_flags |= IFF_DRV_OACTIVE; return; - default: /* Error */ DPRINTFN(11, "transfer error, %s\n", usbd_errstr(error)); @@ -975,31 +1112,41 @@ tr_setup: goto tr_setup; } return; - } } static void -axe_tick(struct usb_ether *ue) +axe_tick(struct axe_softc *sc) { - struct axe_softc *sc = uether_getsc(ue); struct mii_data *mii = GET_MII(sc); AXE_LOCK_ASSERT(sc, MA_OWNED); mii_tick(mii); if ((sc->sc_flags & AXE_FLAG_LINK) == 0) { - axe_miibus_statchg(ue->ue_dev); + axe_miibus_statchg(sc->sc_dev); if ((sc->sc_flags & AXE_FLAG_LINK) != 0) - axe_start(ue); + axe_start_locked(sc->sc_ifp); } } static void -axe_start(struct usb_ether *ue) +axe_start(struct ifnet *ifp) { - struct axe_softc *sc = uether_getsc(ue); + struct axe_softc *sc = ifp->if_softc; + AXE_LOCK(sc); + axe_start_locked(ifp); + AXE_UNLOCK(sc); +} + +static void +axe_start_locked(struct ifnet *ifp) +{ + struct axe_softc *sc = ifp->if_softc; + + AXE_LOCK_ASSERT(sc, MA_OWNED); + /* * start the USB transfers, if not already started: */ @@ -1008,16 +1155,27 @@ static void } static void -axe_init(struct usb_ether *ue) +axe_init(void *arg) { - struct axe_softc *sc = uether_getsc(ue); - struct ifnet *ifp = uether_getifp(ue); + struct axe_softc *sc = arg; + + AXE_SXLOCK(sc); + AXE_LOCK(sc); + axe_init_locked(sc); + AXE_UNLOCK(sc); + AXE_SXUNLOCK(sc); +} + +static void +axe_init_locked(struct axe_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; uint16_t rxmode; AXE_LOCK_ASSERT(sc, MA_OWNED); /* Cancel pending I/O */ - axe_stop(ue); + axe_stop_locked(sc); /* Set MAC address. */ if (sc->sc_flags & (AXE_FLAG_178 | AXE_FLAG_772)) @@ -1047,9 +1205,8 @@ static void */ rxmode |= AXE_178_RXCMD_MFB_16384; #endif - } else { + } else rxmode |= AXE_172_RXCMD_UNICAST; - } /* If we want promiscuous mode, set the allframes bit. */ if (ifp->if_flags & IFF_PROMISC) @@ -1061,44 +1218,65 @@ static void axe_cmd(sc, AXE_CMD_RXCTL_WRITE, 0, rxmode, NULL); /* Load the multicast filter. */ - axe_setmulti(ue); + axe_setmulti_locked(sc); usbd_xfer_set_stall(sc->sc_xfer[AXE_BULK_DT_WR]); ifp->if_drv_flags |= IFF_DRV_RUNNING; - axe_start(ue); + sleepout_reset(&sc->sc_watchdog, hz, axe_watchdog, sc); + axe_start_locked(sc->sc_ifp); } static void -axe_setpromisc(struct usb_ether *ue) +axe_setpromisc(void *arg, int npending) { - struct axe_softc *sc = uether_getsc(ue); - struct ifnet *ifp = uether_getifp(ue); + struct axe_softc *sc = arg; + + AXE_LOCK(sc); + axe_setpromisc_locked(sc); + AXE_UNLOCK(sc); +} + +static void +axe_setpromisc_locked(struct axe_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; uint16_t rxmode; axe_cmd(sc, AXE_CMD_RXCTL_READ, 0, 0, &rxmode); rxmode = le16toh(rxmode); - if (ifp->if_flags & IFF_PROMISC) { + if (ifp->if_flags & IFF_PROMISC) rxmode |= AXE_RXCMD_PROMISC; - } else { + else rxmode &= ~AXE_RXCMD_PROMISC; - } axe_cmd(sc, AXE_CMD_RXCTL_WRITE, 0, rxmode, NULL); - axe_setmulti(ue); + axe_setmulti_locked(sc); } static void -axe_stop(struct usb_ether *ue) +axe_stop(struct axe_softc *sc) { - struct axe_softc *sc = uether_getsc(ue); - struct ifnet *ifp = uether_getifp(ue); + AXE_SXLOCK(sc); + AXE_LOCK(sc); + axe_stop_locked(sc); + AXE_UNLOCK(sc); + AXE_SXUNLOCK(sc); +} + +static void +axe_stop_locked(struct axe_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + AXE_LOCK_ASSERT(sc, MA_OWNED); + sleepout_stop(&sc->sc_watchdog); + ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); sc->sc_flags &= ~AXE_FLAG_LINK; @@ -1110,3 +1288,46 @@ static void axe_reset(sc); } + +static int +axe_ioctl(struct ifnet *ifp, u_long command, caddr_t data) +{ + struct axe_softc *sc = ifp->if_softc; + struct ifreq *ifr = (struct ifreq *)data; + struct mii_data *mii = GET_MII(sc); + int error = 0, drv_flags, flags; + + switch (command) { + case SIOCSIFFLAGS: + /* Avoids race and LOR between mutex and sx lock. */ + AXE_LOCK(sc); + flags = ifp->if_flags; + drv_flags = ifp->if_drv_flags; + AXE_UNLOCK(sc); + /* device up and down is synchronous using sx(9) lock */ + if (flags & IFF_UP) { + if (drv_flags & IFF_DRV_RUNNING) + SLEEPOUT_RUNTASK(&sc->sc_sleepout, + &sc->sc_setpromisc); + else + axe_init(sc); + } else + axe_stop(sc); + break; + case SIOCADDMULTI: + case SIOCDELMULTI: + /* To avoid LOR by in_multi_mtx (netinet/in_mcast.c) */ + if (ifp->if_flags & IFF_UP && + ifp->if_drv_flags & IFF_DRV_RUNNING) + SLEEPOUT_RUNTASK(&sc->sc_sleepout, &sc->sc_setmulti); + break; + case SIOCGIFMEDIA: + case SIOCSIFMEDIA: + error = ifmedia_ioctl(ifp, ifr, &mii->mii_media, command); + break; + default: + error = ether_ioctl(ifp, command, data); + break; + } + return (error); +} From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 00:36:05 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EF9F1065670; Mon, 1 Nov 2010 00:36:05 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1FBD38FC15; Mon, 1 Nov 2010 00:36:04 +0000 (UTC) Received: by gya6 with SMTP id 6so3142694gya.13 for ; Sun, 31 Oct 2010 17:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent:organization:x-operation-sytem; bh=r4BHQYmkdh0vZhmlSZucFgPKBGO1whu7i6jcYRh9xkM=; b=bm8DUfAR7mZ7mCAlb9tRRSgx2ywxSK6m1tHg11eIJCi+P4QCH8/P33wvNq6u15Gve5 G2aOnnw54ISBN6/w3Za8m3gNyxKgAuQJSTx0sa1Lqrpnn2E+sI3VMPG0lPP+QybcAwQ9 VOiSy22LxYKhLiujha25I7EuqO+92X3/DLGMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition:user-agent:organization :x-operation-sytem; b=CqpNeZ/K1o1LLhWrqplXFQPhV9yGX449TZrrBcTHTEm4jgOSY2FztXJmLHdDZCEC0G DXyBPapC6phrqLR243HSuCkUXq0icQma8MQIWkueGRAeybsYV6JjyFC5/HQl5jpBguum pmf6fo0kJPceIOu8LWe4C9Ef6o7a7KvoUG2yc= Received: by 10.229.224.81 with SMTP id in17mr9560071qcb.81.1288571764226; Sun, 31 Oct 2010 17:36:04 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id u2sm4485903qcq.7.2010.10.31.17.36.00 (version=SSLv3 cipher=RC4-MD5); Sun, 31 Oct 2010 17:36:02 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Sun, 31 Oct 2010 17:35:59 -0700 From: Weongyo Jeong Date: Sun, 31 Oct 2010 17:35:59 -0700 To: freebsd-usb@freebsd.org Message-ID: <20101101003559.GC3918@weongyo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Subject: [CFR 4/n] removes uether dependency of cdce(4) X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 00:36:05 -0000 Hello, This patch is to remove a uether dependency of cdce(4) and some style(9) changes. The change logs would be as follows: o removes uether dependency. o defines CDCE_DEV to clean up the supported device list. o uses bzero instead of memset. o style(9) - get rid of extra spaces and parentheses. Please reviews. regards, Weongyo Jeong Index: if_cdce.c =================================================================== --- if_cdce.c (revision 214604) +++ if_cdce.c (working copy) @@ -61,6 +61,8 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include +#include #include #include #include @@ -68,6 +70,14 @@ __FBSDID("$FreeBSD$"); #include #include +#include +#include +#include +#include +#include +#include +#include + #include #include #include @@ -77,6 +87,7 @@ __FBSDID("$FreeBSD$"); #define USB_DEBUG_VAR cdce_debug #include #include +#include #include "usb_if.h" #include @@ -99,14 +110,16 @@ static usb_callback_t cdce_ncm_bulk_write_callback static usb_callback_t cdce_ncm_bulk_read_callback; #endif -static uether_fn_t cdce_attach_post; -static uether_fn_t cdce_init; -static uether_fn_t cdce_stop; -static uether_fn_t cdce_start; -static uether_fn_t cdce_setmulti; -static uether_fn_t cdce_setpromisc; - static uint32_t cdce_m_crc32(struct mbuf *, uint32_t, uint32_t); +static int cdce_ioctl(struct ifnet *, u_long, caddr_t); +static void cdce_start(struct ifnet *); +static void cdce_start_locked(struct ifnet *); +static void cdce_init(void *); +static void cdce_init_locked(struct cdce_softc *); +static void cdce_stop_locked(struct cdce_softc *); +static int cdce_rxmbuf(struct cdce_softc *, struct mbuf *, unsigned int); +static struct mbuf *cdce_newbuf(void); +static void cdce_rxflush(struct cdce_softc *); #ifdef USB_DEBUG static int cdce_debug = 0; @@ -120,7 +133,6 @@ SYSCTL_INT(_hw_usb_cdce, OID_AUTO, interval, CTLFL #endif static const struct usb_config cdce_config[CDCE_N_TRANSFER] = { - [CDCE_BULK_RX] = { .type = UE_BULK, .endpoint = UE_ADDR_ANY, @@ -174,7 +186,6 @@ static const struct usb_config cdce_config[CDCE_N_ #if CDCE_HAVE_NCM static const struct usb_config cdce_ncm_config[CDCE_N_TRANSFER] = { - [CDCE_BULK_RX] = { .type = UE_BULK, .endpoint = UE_ADDR_ANY, @@ -255,29 +266,21 @@ MODULE_DEPEND(cdce, uether, 1, 1, 1); MODULE_DEPEND(cdce, usb, 1, 1, 1); MODULE_DEPEND(cdce, ether, 1, 1, 1); -static const struct usb_ether_methods cdce_ue_methods = { - .ue_attach_post = cdce_attach_post, - .ue_start = cdce_start, - .ue_init = cdce_init, - .ue_stop = cdce_stop, - .ue_setmulti = cdce_setmulti, - .ue_setpromisc = cdce_setpromisc, -}; - static const struct usb_device_id cdce_devs[] = { - {USB_VPI(USB_VENDOR_ACERLABS, USB_PRODUCT_ACERLABS_M5632, CDCE_FLAG_NO_UNION)}, - {USB_VPI(USB_VENDOR_AMBIT, USB_PRODUCT_AMBIT_NTL_250, CDCE_FLAG_NO_UNION)}, - {USB_VPI(USB_VENDOR_COMPAQ, USB_PRODUCT_COMPAQ_IPAQLINUX, CDCE_FLAG_NO_UNION)}, - {USB_VPI(USB_VENDOR_GMATE, USB_PRODUCT_GMATE_YP3X00, CDCE_FLAG_NO_UNION)}, - {USB_VPI(USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)}, - {USB_VPI(USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN2, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)}, - {USB_VPI(USB_VENDOR_NETCHIP, USB_PRODUCT_NETCHIP_ETHERNETGADGET, CDCE_FLAG_NO_UNION)}, - {USB_VPI(USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2501, CDCE_FLAG_NO_UNION)}, - {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5500, CDCE_FLAG_ZAURUS)}, - {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5600, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)}, - {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLA300, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)}, - {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLC700, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)}, - {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLC750, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)}, +#define CDCE_DEV(v,p,i) { USB_VPI(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, i) } + CDCE_DEV(ACERLABS, M5632, CDCE_FLAG_NO_UNION), + CDCE_DEV(AMBIT, NTL_250, CDCE_FLAG_NO_UNION), + CDCE_DEV(COMPAQ, IPAQLINUX, CDCE_FLAG_NO_UNION), + CDCE_DEV(GMATE, YP3X00, CDCE_FLAG_NO_UNION), + CDCE_DEV(MOTOROLA2, USBLAN, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION), + CDCE_DEV(MOTOROLA2, USBLAN2, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION), + CDCE_DEV(NETCHIP, ETHERNETGADGET, CDCE_FLAG_NO_UNION), + CDCE_DEV(PROLIFIC, PL2501, CDCE_FLAG_NO_UNION), + CDCE_DEV(SHARP, SL5500, CDCE_FLAG_ZAURUS), + CDCE_DEV(SHARP, SL5600, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION), + CDCE_DEV(SHARP, SLA300, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION), + CDCE_DEV(SHARP, SLC700, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION), + CDCE_DEV(SHARP, SLC750, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION), {USB_IF_CSI(UICLASS_CDC, UISUBCLASS_ETHERNET_NETWORKING_CONTROL_MODEL, 0)}, {USB_IF_CSI(UICLASS_CDC, UISUBCLASS_MOBILE_DIRECT_LINE_MODEL, 0)}, @@ -301,7 +304,7 @@ cdce_ncm_init(struct cdce_softc *sc) uint8_t value[8]; int err; - ufd = usbd_find_descriptor(sc->sc_ue.ue_udev, NULL, + ufd = usbd_find_descriptor(sc->sc_udev, NULL, sc->sc_ifaces_index[1], UDESC_CS_INTERFACE, 0 - 1, UCDC_NCM_FUNC_DESC_SUBTYPE, 0 - 1); @@ -320,14 +323,13 @@ cdce_ncm_init(struct cdce_softc *sc) req.wIndex[1] = 0; USETW(req.wLength, sizeof(temp)); - err = usbd_do_request_flags(sc->sc_ue.ue_udev, NULL, &req, + err = usbd_do_request_flags(sc->sc_udev, NULL, &req, &temp, 0, NULL, 1000 /* ms */); if (err) return (1); /* Read correct set of parameters according to device mode */ - - if (usbd_get_mode(sc->sc_ue.ue_udev) == USB_MODE_HOST) { + if (usbd_get_mode(sc->sc_udev) == USB_MODE_HOST) { sc->sc_ncm.rx_max = UGETDW(temp.dwNtbInMaxSize); sc->sc_ncm.tx_max = UGETDW(temp.dwNtbOutMaxSize); sc->sc_ncm.tx_remainder = UGETW(temp.wNdpOutPayloadRemainder); @@ -344,7 +346,6 @@ cdce_ncm_init(struct cdce_softc *sc) } /* Verify maximum receive length */ - if ((sc->sc_ncm.rx_max < 32) || (sc->sc_ncm.rx_max > CDCE_NCM_RX_MAXLEN)) { DPRINTFN(1, "Using default maximum receive length\n"); @@ -352,7 +353,6 @@ cdce_ncm_init(struct cdce_softc *sc) } /* Verify maximum transmit length */ - if ((sc->sc_ncm.tx_max < 32) || (sc->sc_ncm.tx_max > CDCE_NCM_TX_MAXLEN)) { DPRINTFN(1, "Using default maximum transmit length\n"); @@ -388,7 +388,6 @@ cdce_ncm_init(struct cdce_softc *sc) } /* Verify that the payload remainder */ - if ((sc->sc_ncm.tx_remainder >= sc->sc_ncm.tx_modulus)) { DPRINTFN(1, "Using default transmit remainder: 0 bytes\n"); sc->sc_ncm.tx_remainder = 0; @@ -414,7 +413,6 @@ cdce_ncm_init(struct cdce_softc *sc) } /* Additional configuration, will fail in device side mode, which is OK. */ - req.bmRequestType = UT_WRITE_CLASS_INTERFACE; req.bRequest = UCDC_NCM_SET_NTB_INPUT_SIZE; USETW(req.wValue, 0); @@ -430,9 +428,9 @@ cdce_ncm_init(struct cdce_softc *sc) } else { USETW(req.wLength, 4); USETDW(value, sc->sc_ncm.rx_max); - } + } - err = usbd_do_request_flags(sc->sc_ue.ue_udev, NULL, &req, + err = usbd_do_request_flags(sc->sc_udev, NULL, &req, &value, 0, NULL, 1000 /* ms */); if (err) { DPRINTFN(1, "Setting input size " @@ -446,11 +444,10 @@ cdce_ncm_init(struct cdce_softc *sc) req.wIndex[1] = 0; USETW(req.wLength, 0); - err = usbd_do_request_flags(sc->sc_ue.ue_udev, NULL, &req, + err = usbd_do_request_flags(sc->sc_udev, NULL, &req, NULL, 0, NULL, 1000 /* ms */); - if (err) { + if (err) DPRINTFN(1, "Setting CRC mode to off failed.\n"); - } req.bmRequestType = UT_WRITE_CLASS_INTERFACE; req.bRequest = UCDC_NCM_SET_NTB_FORMAT; @@ -459,11 +456,10 @@ cdce_ncm_init(struct cdce_softc *sc) req.wIndex[1] = 0; USETW(req.wLength, 0); - err = usbd_do_request_flags(sc->sc_ue.ue_udev, NULL, &req, + err = usbd_do_request_flags(sc->sc_udev, NULL, &req, NULL, 0, NULL, 1000 /* ms */); - if (err) { + if (err) DPRINTFN(1, "Setting NTB format to 16-bit failed.\n"); - } return (0); /* success */ } @@ -477,18 +473,11 @@ cdce_probe(device_t dev) return (usbd_lookup_id_by_uaa(cdce_devs, sizeof(cdce_devs), uaa)); } -static void -cdce_attach_post(struct usb_ether *ue) -{ - /* no-op */ - return; -} - static int cdce_attach(device_t dev) { struct cdce_softc *sc = device_get_softc(dev); - struct usb_ether *ue = &sc->sc_ue; + struct ifnet *ifp; struct usb_attach_arg *uaa = device_get_ivars(dev); struct usb_interface *iface; const struct usb_cdc_union_descriptor *ud; @@ -500,18 +489,21 @@ cdce_attach(device_t dev) uint8_t data_iface_no; char eaddr_str[5 * ETHER_ADDR_LEN]; /* approx */ + sc->sc_dev = dev; + sc->sc_udev = uaa->device; sc->sc_flags = USB_GET_DRIVER_INFO(uaa); - sc->sc_ue.ue_udev = uaa->device; + sc->sc_unit = uether_alloc_unr(); device_set_usb_desc(dev); mtx_init(&sc->sc_mtx, device_get_nameunit(dev), NULL, MTX_DEF); + sx_init(&sc->sc_sx, "cdce sxlock"); ud = usbd_find_descriptor (uaa->device, NULL, uaa->info.bIfaceIndex, UDESC_CS_INTERFACE, 0 - 1, UDESCSUB_CDC_UNION, 0 - 1); - if ((ud == NULL) || (ud->bLength < sizeof(*ud)) || + if (ud == NULL || ud->bLength < sizeof(*ud) || (sc->sc_flags & CDCE_FLAG_NO_UNION)) { DPRINTFN(1, "No union descriptor!\n"); sc->sc_ifaces_index[0] = uaa->info.bIfaceIndex; @@ -521,17 +513,16 @@ cdce_attach(device_t dev) data_iface_no = ud->bSlaveInterface[0]; for (i = 0;; i++) { - iface = usbd_get_iface(uaa->device, i); if (iface) { - id = usbd_get_interface_descriptor(iface); if (id && (id->bInterfaceNumber == data_iface_no)) { sc->sc_ifaces_index[0] = i; sc->sc_ifaces_index[1] = uaa->info.bIfaceIndex; - usbd_set_parent_iface(uaa->device, i, uaa->info.bIfaceIndex); + usbd_set_parent_iface(uaa->device, i, + uaa->info.bIfaceIndex); break; } } else { @@ -568,13 +559,12 @@ alloc_transfers: pcfg = cdce_config; /* Default Configuration */ for (i = 0; i != 32; i++) { - error = usbd_set_alt_interface_index(uaa->device, sc->sc_ifaces_index[0], i); if (error) break; #if CDCE_HAVE_NCM - if ((i == 0) && (cdce_ncm_init(sc) == 0)) + if (i == 0 && cdce_ncm_init(sc) == 0) pcfg = cdce_ncm_config; #endif error = usbd_transfer_setup(uaa->device, @@ -595,28 +585,23 @@ alloc_transfers: (uaa->device, NULL, uaa->info.bIfaceIndex, UDESC_CS_INTERFACE, 0 - 1, UDESCSUB_CDC_ENF, 0 - 1); - if ((ued == NULL) || (ued->bLength < sizeof(*ued))) { + if (ued == NULL || ued->bLength < sizeof(*ued)) error = USB_ERR_INVAL; - } else { + else { error = usbd_req_get_string_any(uaa->device, NULL, eaddr_str, sizeof(eaddr_str), ued->iMacAddress); } if (error) { - /* fake MAC address */ - device_printf(dev, "faking MAC address\n"); - sc->sc_ue.ue_eaddr[0] = 0x2a; - memcpy(&sc->sc_ue.ue_eaddr[1], &ticks, sizeof(uint32_t)); - sc->sc_ue.ue_eaddr[5] = device_get_unit(dev); - + sc->sc_eaddr[0] = 0x2a; + memcpy(&sc->sc_eaddr[1], &ticks, sizeof(uint32_t)); + sc->sc_eaddr[5] = device_get_unit(dev); } else { + bzero(sc->sc_eaddr, sizeof(sc->sc_eaddr)); - memset(sc->sc_ue.ue_eaddr, 0, sizeof(sc->sc_ue.ue_eaddr)); - for (i = 0; i != (ETHER_ADDR_LEN * 2); i++) { - char c = eaddr_str[i]; if ('0' <= c && c <= '9') @@ -630,30 +615,38 @@ alloc_transfers: if ((i & 1) == 0) c <<= 4; - sc->sc_ue.ue_eaddr[i / 2] |= c; + sc->sc_eaddr[i / 2] |= c; } if (uaa->usb_mode == USB_MODE_DEVICE) { /* * Do not use the same MAC address like the peer ! */ - sc->sc_ue.ue_eaddr[5] ^= 0xFF; + sc->sc_eaddr[5] ^= 0xFF; } } - ue->ue_sc = sc; - ue->ue_dev = dev; - ue->ue_udev = uaa->device; - ue->ue_mtx = &sc->sc_mtx; - ue->ue_methods = &cdce_ue_methods; - - error = uether_ifattach(ue); - if (error) { - device_printf(dev, "could not attach interface\n"); + sc->sc_ifp = ifp = if_alloc(IFT_ETHER); + if (ifp == NULL) { + device_printf(sc->sc_dev, "could not allocate ifnet\n"); goto detach; } - return (0); /* success */ + ifp->if_softc = sc; + if_initname(ifp, "ue", sc->sc_unit); + ifp->if_mtu = ETHERMTU; + ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; + ifp->if_ioctl = cdce_ioctl; + ifp->if_start = cdce_start; + ifp->if_init = cdce_init; + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); + ifp->if_snd.ifq_drv_maxlen = ifqmaxlen; + IFQ_SET_READY(&ifp->if_snd); + + if_printf(ifp, " on %s\n", + device_get_nameunit(sc->sc_dev)); + ether_ifattach(ifp, sc->sc_eaddr); + return (0); detach: cdce_detach(dev); return (ENXIO); /* failure */ @@ -663,21 +656,40 @@ static int cdce_detach(device_t dev) { struct cdce_softc *sc = device_get_softc(dev); - struct usb_ether *ue = &sc->sc_ue; + struct ifnet *ifp = sc->sc_ifp; /* stop all USB transfers first */ usbd_transfer_unsetup(sc->sc_xfer, CDCE_N_TRANSFER); - uether_ifdetach(ue); + if (ifp != NULL) { + CDCE_LOCK(sc); + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; + CDCE_UNLOCK(sc); + ether_ifdetach(ifp); + if_free(ifp); + } + sx_destroy(&sc->sc_sx); mtx_destroy(&sc->sc_mtx); - + uether_free_unr(sc->sc_unit); return (0); } static void -cdce_start(struct usb_ether *ue) +cdce_start(struct ifnet *ifp) { - struct cdce_softc *sc = uether_getsc(ue); + struct cdce_softc *sc = ifp->if_softc; + CDCE_LOCK(sc); + cdce_start_locked(ifp); + CDCE_UNLOCK(sc); +} + +static void +cdce_start_locked(struct ifnet *ifp) +{ + struct cdce_softc *sc = ifp->if_softc; + + CDCE_LOCK_ASSERT(sc, MA_OWNED); + /* * Start the USB transfers, if not already started: */ @@ -701,7 +713,7 @@ static void cdce_bulk_write_callback(struct usb_xfer *xfer, usb_error_t error) { struct cdce_softc *sc = usbd_xfer_softc(xfer); - struct ifnet *ifp = uether_getifp(&sc->sc_ue); + struct ifnet *ifp = sc->sc_ifp; struct mbuf *m; struct mbuf *mt; uint32_t crc; @@ -726,7 +738,6 @@ cdce_bulk_write_callback(struct usb_xfer *xfer, us case USB_ST_SETUP: tr_setup: for (x = 0; x != CDCE_FRAMES_MAX; x++) { - IFQ_DRV_DEQUEUE(&ifp->if_snd, m); if (m == NULL) @@ -756,9 +767,8 @@ tr_setup: } m = mt; } - if (m->m_pkthdr.len > MCLBYTES) { + if (m->m_pkthdr.len > MCLBYTES) m->m_pkthdr.len = MCLBYTES; - } sc->sc_tx_buf[x] = m; usbd_xfer_set_frame_data(xfer, x, m->m_data, m->m_len); @@ -774,7 +784,6 @@ tr_setup: usbd_transfer_submit(xfer); } break; - default: /* Error */ DPRINTFN(11, "transfer error, %s\n", usbd_errstr(error)); @@ -814,11 +823,22 @@ cdce_m_crc32(struct mbuf *m, uint32_t src_offset, } static void -cdce_init(struct usb_ether *ue) +cdce_init(void *arg) { - struct cdce_softc *sc = uether_getsc(ue); - struct ifnet *ifp = uether_getifp(ue); + struct cdce_softc *sc = arg; + CDCE_SXLOCK(sc); + CDCE_LOCK(sc); + cdce_init_locked(sc); + CDCE_UNLOCK(sc); + CDCE_SXUNLOCK(sc); +} + +static void +cdce_init_locked(struct cdce_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + CDCE_LOCK_ASSERT(sc, MA_OWNED); ifp->if_drv_flags |= IFF_DRV_RUNNING; @@ -831,15 +851,25 @@ static void usbd_xfer_set_stall(sc->sc_xfer[CDCE_BULK_TX]); /* start data transfers */ - cdce_start(ue); + cdce_start_locked(sc->sc_ifp); } static void -cdce_stop(struct usb_ether *ue) +cdce_stop(struct cdce_softc *sc) { - struct cdce_softc *sc = uether_getsc(ue); - struct ifnet *ifp = uether_getifp(ue); + CDCE_SXLOCK(sc); + CDCE_LOCK(sc); + cdce_stop_locked(sc); + CDCE_UNLOCK(sc); + CDCE_SXUNLOCK(sc); +} + +static void +cdce_stop_locked(struct cdce_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + CDCE_LOCK_ASSERT(sc, MA_OWNED); ifp->if_drv_flags &= ~IFF_DRV_RUNNING; @@ -853,20 +883,6 @@ static void usbd_transfer_stop(sc->sc_xfer[CDCE_INTR_TX]); } -static void -cdce_setmulti(struct usb_ether *ue) -{ - /* no-op */ - return; -} - -static void -cdce_setpromisc(struct usb_ether *ue) -{ - /* no-op */ - return; -} - static int cdce_suspend(device_t dev) { @@ -893,11 +909,9 @@ cdce_bulk_read_callback(struct usb_xfer *xfer, usb switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: - DPRINTF("received %u bytes in %u frames\n", actlen, aframes); for (x = 0; x != aframes; x++) { - m = sc->sc_rx_buf[x]; sc->sc_rx_buf[x] = NULL; len = usbd_xfer_frame_len(xfer, x); @@ -911,9 +925,8 @@ cdce_bulk_read_callback(struct usb_xfer *xfer, usb continue; } /* queue up mbuf */ - uether_rxmbuf(&sc->sc_ue, m, len); + cdce_rxmbuf(sc, m, len); } - /* FALLTHROUGH */ case USB_ST_SETUP: /* @@ -922,13 +935,12 @@ cdce_bulk_read_callback(struct usb_xfer *xfer, usb */ for (x = 0; x != 1; x++) { if (sc->sc_rx_buf[x] == NULL) { - m = uether_newbuf(); + m = cdce_newbuf(); if (m == NULL) goto tr_stall; sc->sc_rx_buf[x] = m; - } else { + } else m = sc->sc_rx_buf[x]; - } usbd_xfer_set_frame_data(xfer, x, m->m_data, m->m_len); } @@ -936,9 +948,8 @@ cdce_bulk_read_callback(struct usb_xfer *xfer, usb usbd_xfer_set_frames(xfer, x); usbd_transfer_submit(xfer); /* flush any received frames */ - uether_rxflush(&sc->sc_ue); + cdce_rxflush(sc); break; - default: /* Error */ DPRINTF("error = %s\n", usbd_errstr(error)); @@ -967,18 +978,15 @@ cdce_intr_read_callback(struct usb_xfer *xfer, usb switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: - DPRINTF("Received %d bytes\n", actlen); /* TODO: decode some indications */ - /* FALLTHROUGH */ case USB_ST_SETUP: tr_setup: usbd_xfer_set_frame_len(xfer, 0, usbd_xfer_max_len(xfer)); usbd_transfer_submit(xfer); break; - default: /* Error */ if (error != USB_ERR_CANCELLED) { /* start clear stall */ @@ -998,7 +1006,6 @@ cdce_intr_write_callback(struct usb_xfer *xfer, us switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: - DPRINTF("Transferred %d bytes\n", actlen); /* FALLTHROUGH */ @@ -1009,7 +1016,6 @@ tr_setup: usbd_transfer_submit(xfer); #endif break; - default: /* Error */ if (error != USB_ERR_CANCELLED) { /* start clear stall */ @@ -1045,7 +1051,7 @@ static uint8_t cdce_ncm_fill_tx_frames(struct usb_xfer *xfer, uint8_t index) { struct cdce_softc *sc = usbd_xfer_softc(xfer); - struct ifnet *ifp = uether_getifp(&sc->sc_ue); + struct ifnet *ifp = sc->sc_ifp; struct usb_page_cache *pc = usbd_xfer_get_frame(xfer, index); struct mbuf *m; uint32_t rem; @@ -1073,14 +1079,11 @@ cdce_ncm_fill_tx_frames(struct usb_xfer *xfer, uin retval = 2; for (n = 0; n != sc->sc_ncm.tx_nframe; n++) { - /* check if end of transmit buffer is reached */ - if (offset >= sc->sc_ncm.tx_max) break; /* compute maximum buffer size */ - rem = sc->sc_ncm.tx_max - offset; IFQ_DRV_DEQUEUE(&(ifp->if_snd), m); @@ -1129,11 +1132,9 @@ cdce_ncm_fill_tx_frames(struct usb_xfer *xfer, uin BPF_MTAP(ifp, m); /* Free mbuf */ - m_freem(m); /* Pre-increment interface counter */ - ifp->if_opackets++; } @@ -1198,7 +1199,7 @@ static void cdce_ncm_bulk_write_callback(struct usb_xfer *xfer, usb_error_t error) { struct cdce_softc *sc = usbd_xfer_softc(xfer); - struct ifnet *ifp = uether_getifp(&sc->sc_ue); + struct ifnet *ifp = sc->sc_ifp; uint16_t x; uint8_t temp; int actlen; @@ -1206,12 +1207,11 @@ cdce_ncm_bulk_write_callback(struct usb_xfer *xfer switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: - usbd_xfer_status(xfer, &actlen, NULL, &aframes, NULL); DPRINTFN(10, "transfer complete: " "%u bytes in %u frames\n", actlen, aframes); - + /* FALLTHROUGH */ case USB_ST_SETUP: for (x = 0; x != CDCE_NCM_TX_FRAMES_MAX; x++) { temp = cdce_ncm_fill_tx_frames(xfer, x); @@ -1231,7 +1231,6 @@ cdce_ncm_bulk_write_callback(struct usb_xfer *xfer usbd_transfer_submit(xfer); } break; - default: /* Error */ DPRINTFN(10, "Transfer error: %s\n", usbd_errstr(error)); @@ -1254,7 +1253,7 @@ cdce_ncm_bulk_read_callback(struct usb_xfer *xfer, { struct cdce_softc *sc = usbd_xfer_softc(xfer); struct usb_page_cache *pc = usbd_xfer_get_frame(xfer, 0); - struct ifnet *ifp = uether_getifp(&sc->sc_ue); + struct ifnet *ifp = sc->sc_ifp; struct mbuf *m; int sumdata; int sumlen; @@ -1267,7 +1266,6 @@ cdce_ncm_bulk_read_callback(struct usb_xfer *xfer, switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: - usbd_xfer_status(xfer, &actlen, &sumlen, &aframes, NULL); DPRINTFN(1, "received %u bytes in %u frames\n", @@ -1281,10 +1279,10 @@ cdce_ncm_bulk_read_callback(struct usb_xfer *xfer, usbd_copy_out(pc, 0, &(sc->sc_ncm.hdr), sizeof(sc->sc_ncm.hdr)); - if ((sc->sc_ncm.hdr.dwSignature[0] != 'N') || - (sc->sc_ncm.hdr.dwSignature[1] != 'C') || - (sc->sc_ncm.hdr.dwSignature[2] != 'M') || - (sc->sc_ncm.hdr.dwSignature[3] != 'H')) { + if (sc->sc_ncm.hdr.dwSignature[0] != 'N' || + sc->sc_ncm.hdr.dwSignature[1] != 'C' || + sc->sc_ncm.hdr.dwSignature[2] != 'M' || + sc->sc_ncm.hdr.dwSignature[3] != 'H') { DPRINTFN(1, "invalid HDR signature: " "0x%02x:0x%02x:0x%02x:0x%02x\n", sc->sc_ncm.hdr.dwSignature[0], @@ -1307,10 +1305,10 @@ cdce_ncm_bulk_read_callback(struct usb_xfer *xfer, usbd_copy_out(pc, temp, &(sc->sc_ncm.dpt), sizeof(sc->sc_ncm.dpt)); - if ((sc->sc_ncm.dpt.dwSignature[0] != 'N') || - (sc->sc_ncm.dpt.dwSignature[1] != 'C') || - (sc->sc_ncm.dpt.dwSignature[2] != 'M') || - (sc->sc_ncm.dpt.dwSignature[3] != '0')) { + if (sc->sc_ncm.dpt.dwSignature[0] != 'N' || + sc->sc_ncm.dpt.dwSignature[1] != 'C' || + sc->sc_ncm.dpt.dwSignature[2] != 'M' || + sc->sc_ncm.dpt.dwSignature[3] != '0') { DPRINTFN(1, "invalid DPT signature" "0x%02x:0x%02x:0x%02x:0x%02x\n", sc->sc_ncm.dpt.dwSignature[0], @@ -1344,13 +1342,12 @@ cdce_ncm_bulk_read_callback(struct usb_xfer *xfer, sumdata = 0; for (x = 0; x != nframes; x++) { - offset = UGETW(sc->sc_ncm.dp[x].wFrameIndex); temp = UGETW(sc->sc_ncm.dp[x].wFrameLength); - if ((offset == 0) || - (temp < sizeof(struct ether_header)) || - (temp > (MCLBYTES - ETHER_ALIGN))) { + if (offset == 0 || + temp < sizeof(struct ether_header) || + temp > (MCLBYTES - ETHER_ALIGN)) { DPRINTFN(1, "NULL frame detected at %d\n", x); m = NULL; /* silently ignore this frame */ @@ -1361,11 +1358,10 @@ cdce_ncm_bulk_read_callback(struct usb_xfer *xfer, m = NULL; /* silently ignore this frame */ continue; - } else if (temp > (MHLEN - ETHER_ALIGN)) { + } else if (temp > (MHLEN - ETHER_ALIGN)) m = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR); - } else { + else m = m_gethdr(M_DONTWAIT, MT_DATA); - } DPRINTFN(16, "frame %u, offset = %u, length = %u \n", x, offset, temp); @@ -1377,24 +1373,22 @@ cdce_ncm_bulk_read_callback(struct usb_xfer *xfer, usbd_copy_out(pc, offset, m->m_data, temp); /* enqueue */ - uether_rxmbuf(&sc->sc_ue, m, temp); + cdce_rxmbuf(sc, m, temp); sumdata += temp; - } else { + } else ifp->if_ierrors++; - } } DPRINTFN(1, "Efficiency: %u/%u bytes\n", sumdata, actlen); - + /* FALLTHROUGH */ case USB_ST_SETUP: tr_setup: usbd_xfer_set_frame_len(xfer, 0, sc->sc_ncm.rx_max); usbd_xfer_set_frames(xfer, 1); usbd_transfer_submit(xfer); - uether_rxflush(&sc->sc_ue); /* must be last */ + cdce_rxflush(sc); /* must be last */ break; - default: /* Error */ DPRINTFN(1, "error = %s\n", usbd_errstr(error)); @@ -1410,3 +1404,83 @@ tr_stall: } } #endif + +static int +cdce_rxmbuf(struct cdce_softc *sc, struct mbuf *m, unsigned int len) +{ + struct ifnet *ifp = sc->sc_ifp; + + CDCE_LOCK_ASSERT(sc, MA_OWNED); + + /* finalize mbuf */ + ifp->if_ipackets++; + m->m_pkthdr.rcvif = ifp; + m->m_pkthdr.len = m->m_len = len; + + /* enqueue for later when the lock can be released */ + _IF_ENQUEUE(&sc->sc_rxq, m); + return (0); +} + +static struct mbuf * +cdce_newbuf(void) +{ + struct mbuf *m_new; + + m_new = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR); + if (m_new == NULL) + return (NULL); + m_new->m_len = m_new->m_pkthdr.len = MCLBYTES; + + m_adj(m_new, ETHER_ALIGN); + return (m_new); +} + +static void +cdce_rxflush(struct cdce_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + struct mbuf *m; + + CDCE_LOCK_ASSERT(sc, MA_OWNED); + + for (;;) { + _IF_DEQUEUE(&sc->sc_rxq, m); + if (m == NULL) + break; + + /* + * The USB xfer has been resubmitted so its safe to unlock now. + */ + CDCE_UNLOCK(sc); + ifp->if_input(ifp, m); + CDCE_LOCK(sc); + } +} + +static int +cdce_ioctl(struct ifnet *ifp, u_long command, caddr_t data) +{ + struct cdce_softc *sc = ifp->if_softc; + int error = 0, drv_flags, flags; + + switch (command) { + case SIOCSIFFLAGS: + /* Avoids race and LOR between mutex and sx lock. */ + CDCE_LOCK(sc); + flags = ifp->if_flags; + drv_flags = ifp->if_drv_flags; + CDCE_UNLOCK(sc); + /* device up and down is synchronous using sx(9) lock */ + if (flags & IFF_UP) { + if ((drv_flags & IFF_DRV_RUNNING) == 0) + cdce_init(sc); + } else + cdce_stop(sc); + break; + default: + error = ether_ioctl(ifp, command, data); + break; + } + return (error); +} Index: if_cdcereg.h =================================================================== --- if_cdcereg.h (revision 214604) +++ if_cdcereg.h (working copy) @@ -77,24 +77,31 @@ struct cdce_ncm { }; struct cdce_softc { - struct usb_ether sc_ue; + struct ifnet *sc_ifp; + device_t sc_dev; + struct usb_device *sc_udev; /* used by uether_do_request() */ struct mtx sc_mtx; + struct sx sc_sx; + struct usb_xfer *sc_xfer[CDCE_N_TRANSFER]; + struct ifqueue sc_rxq; + /* ethernet address from eeprom */ + uint8_t sc_eaddr[ETHER_ADDR_LEN]; #if CDCE_HAVE_NCM struct cdce_ncm sc_ncm; #endif - struct usb_xfer *sc_xfer[CDCE_N_TRANSFER]; struct mbuf *sc_rx_buf[CDCE_FRAMES_MAX]; struct mbuf *sc_tx_buf[CDCE_FRAMES_MAX]; - int sc_flags; #define CDCE_FLAG_ZAURUS 0x0001 #define CDCE_FLAG_NO_UNION 0x0002 #define CDCE_FLAG_RX_DATA 0x0010 - - uint8_t sc_eaddr_str_index; - uint8_t sc_ifaces_index[2]; + int sc_unit; + uint8_t sc_eaddr_str_index; + uint8_t sc_ifaces_index[2]; }; +#define CDCE_SXLOCK(_sc) sx_xlock(&(_sc)->sc_sx) +#define CDCE_SXUNLOCK(_sc) sx_xunlock(&(_sc)->sc_sx) #define CDCE_LOCK(_sc) mtx_lock(&(_sc)->sc_mtx) #define CDCE_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx) #define CDCE_LOCK_ASSERT(_sc, t) mtx_assert(&(_sc)->sc_mtx, t) From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 01:20:10 2010 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFBC81065672 for ; Mon, 1 Nov 2010 01:20:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 63FE48FC1C for ; Mon, 1 Nov 2010 01:20:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA11K8t9069927 for ; Mon, 1 Nov 2010 01:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA11K8Mv069926; Mon, 1 Nov 2010 01:20:08 GMT (envelope-from gnats) Resent-Date: Mon, 1 Nov 2010 01:20:08 GMT Resent-Message-Id: <201011010120.oA11K8Mv069926@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-usb@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, HIROSHI OOTA Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3528A1065670 for ; Mon, 1 Nov 2010 01:18:59 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 096548FC12 for ; Mon, 1 Nov 2010 01:18:59 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id oA11Iwl6098490 for ; Mon, 1 Nov 2010 01:18:58 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id oA11IwKO098488; Mon, 1 Nov 2010 01:18:58 GMT (envelope-from nobody) Message-Id: <201011010118.oA11IwKO098488@www.freebsd.org> Date: Mon, 1 Nov 2010 01:18:58 GMT From: HIROSHI OOTA To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: usb/151851: libusb(3) libusb_control_transfer() return value is incorrect X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 01:20:10 -0000 >Number: 151851 >Category: usb >Synopsis: libusb(3) libusb_control_transfer() return value is incorrect >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Mon Nov 01 01:20:08 UTC 2010 >Closed-Date: >Last-Modified: >Originator: HIROSHI OOTA >Release: 9-current >Organization: >Environment: FreeBSD aries 9.0-CURRENT FreeBSD 9.0-CURRENT #102 r214602M: Mon Nov 1 03:06:42 JST 2010 root@localhost amd64 >Description: In the libusb(3) man page the return value of libusb_control_transfer is: > Returns 0 on success but, it's returns the number of bytes actually transferred. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 02:03:54 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB7C81065693; Mon, 1 Nov 2010 02:03:54 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB7D8FC29; Mon, 1 Nov 2010 02:03:53 +0000 (UTC) Received: by gxk9 with SMTP id 9so3133603gxk.13 for ; Sun, 31 Oct 2010 19:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:organization :x-operation-sytem; bh=dGWfNCNewvAMxcsed2FK4dqGodVcTEo3VaQOeRWAUkU=; b=KY9vwycs08AoX+jlJrAdSyasAlsXTa+nsg6B1f4z3nlqxqMLTlceBeWE6TCVBa3Uzn EoPGN5gR85IIB8MKLf3F0yFuFxw2VxY/s74STB/3ynZBD4rzvZhxfVwECmQA8ja58SLW ve7nZT/SEIPuz/sR9TcaltzTlQqbcr2qx/2e0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :organization:x-operation-sytem; b=qx/eDD+K+Z5uCzQ1xScR3yk8AuY553nJnIM5wRT+k0Ob5V2GxnehG+YWoePbWwdwuo 2smFLdOapdDmnIKc4Skj2SG8teU2Fi7PLFABtKa7BAxRE2XYKKaDnFUjQK6N9deSSdsc kiaUEav9AS6xnO4ZmVW8fNUXsrsZTK7UFp6rI= Received: by 10.229.191.85 with SMTP id dl21mr4110776qcb.260.1288577033267; Sun, 31 Oct 2010 19:03:53 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id k15sm4560429qcu.11.2010.10.31.19.03.50 (version=SSLv3 cipher=RC4-MD5); Sun, 31 Oct 2010 19:03:52 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Sun, 31 Oct 2010 19:03:48 -0700 From: Weongyo Jeong Date: Sun, 31 Oct 2010 19:03:48 -0700 To: Hans Petter Selasky Message-ID: <20101101020348.GD3918@weongyo> References: <20101030231901.GA83161@weongyo> <201010311509.49138.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010311509.49138.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-usb@freebsd.org Subject: Re: [CFR] add usb_sleepout.[ch] X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 02:03:55 -0000 On Sun, Oct 31, 2010 at 03:09:49PM +0100, Hans Petter Selasky wrote: > On Sunday 31 October 2010 01:19:01 Weongyo Jeong wrote: > > Hello USB guys, > > > > The following patch is to add a implementation, called `sleepout'. > > Please reviews. I'd like to commit it into HEAD if no objections. > > > > Adds `sleepout' prototype which is a comic combination of callout(9) and > > taskqueue(8) only for USB drivers to implement one step timer. In > > current USB drivers using callout(9) interface they all have two step > > execution flow as follows: > > > > 1. callout callback is fired by the interrupt context. Then it needs > > to pass it to USB process context because it could sleep(!) while > > callout(9) don't allow it. > > 2. In the USB process context it operates USB commands that most of > > times it'd be blocked at least 125 us (it'd be always true for USB) > > > > In a view of driver developer it'd be more convenient if USB stack has a > > feature like this (timer supporting blocking). > > > > Hi, > > I think this is a good idea too. > > However, there are some atomic issues I think you need to fix first. > > 1) All the sleepout_xxx() functions need mutex asserts. It looks it don't need it because callout(9) does it instead of sleepout routines. Moreover sleepout don't create any mutexes in itself. > 2) Is it allowed to call callout_stop() / callout_reset() unlocked at all? Yes as long as it doesn't have side effects. It seems no drivers hold a lock to call callout_stop() / callout_reset(). > What are the concequences if the mutex associated with the sleepout is NULL ? I added KASSERT macro to check this case at below. However the sleepout pointer normally never be NULL because the intention of usage was as follows: struct _softc { struct sleepout sleepout; struct sleepout_task sleepout_task; }; sleepout_create(&sc->sleepout, "blah"); Only it could be happen if `struct sleepout' is allocated by dynamically though it's not my first purpose. > 3) As per the current implementation it can happen that the task'ed timeout is > called after that sleepout_stop() is used. The code should have a check in the > task function to see if the sleepout() has been cancelled or not, when the > mutex associated with the sleepout is locked. Yes it's true but it'd better to implement first taskqueue_stop() than adding it sleepout routines directly. However no plans yet because I couldn't imagine a side effect due to lack of this feature. Please let me know if I missed the something important. > 4) Should the functions be prefixed by usb_ ? I don't have a preference for this. I think it's no problem to change it. It could happen soon. > 5) In drain you should drain the callout first, then drain the tasqueue. Else > the timer can trigger after the taskqueue is drained. It's fixed. Thank you for your review and the updated version is embedded at this email. regards, Weongyo Jeong Index: usb_sleepout.c =================================================================== --- usb_sleepout.c (revision 0) +++ usb_sleepout.c (revision 0) @@ -0,0 +1,149 @@ +/*- + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include +__FBSDID("$FreeBSD$"); +#include +#include +#include +#include +#include +#include + +#include + +void +sleepout_create(struct sleepout *s, const char *name) +{ + + KASSERT(s != NULL, ("sleepout ptr is NULL")); + + s->s_taskqueue = taskqueue_create(name, M_WAITOK, + taskqueue_thread_enqueue, &s->s_taskqueue); + /* XXX adjusts the priority. */ + taskqueue_start_threads(&s->s_taskqueue, 1, PI_NET, "%s sleepout", + name); +} + +void +sleepout_free(struct sleepout *s) +{ + + KASSERT(s != NULL, ("sleepout ptr is NULL")); + + taskqueue_free(s->s_taskqueue); +} + +static void +_sleepout_taskqueue_callback(void *arg, int pending) +{ + struct sleepout_task *st = arg; + + (void)pending; + + if (st->st_mtx != NULL) + mtx_lock(st->st_mtx); + + st->st_func(st->st_arg); + + if (st->st_mtx != NULL) + mtx_unlock(st->st_mtx); +} + +void +sleepout_init(struct sleepout *s, struct sleepout_task *st, int mpsafe) +{ + + KASSERT(s != NULL, ("sleepout ptr is NULL")); + + st->st_sleepout = s; + callout_init(&st->st_callout, mpsafe); + TASK_INIT(&st->st_task, 0, _sleepout_taskqueue_callback, st); + st->st_mtx = NULL; +} + +void +sleepout_init_mtx(struct sleepout *s, struct sleepout_task *st, struct mtx *mtx, + int flags) +{ + + KASSERT(s != NULL, ("sleepout ptr is NULL")); + + st->st_sleepout = s; + callout_init_mtx(&st->st_callout, mtx, flags); + TASK_INIT(&st->st_task, 0, _sleepout_taskqueue_callback, st); + st->st_mtx = mtx; +} + +static void +_sleepout_callout_callback(void *arg) +{ + struct sleepout_task *st = arg; + struct sleepout *s = st->st_sleepout; + + KASSERT(s != NULL, ("sleepout ptr is NULL")); + + taskqueue_enqueue(s->s_taskqueue, &st->st_task); +} + +int +sleepout_reset(struct sleepout_task *st, int to_ticks, sleepout_func_t ftn, + void *arg) +{ + + st->st_func = ftn; + st->st_arg = arg; + return (callout_reset(&st->st_callout, to_ticks, + _sleepout_callout_callback, st)); +} + +int +sleepout_pending(struct sleepout_task *st) +{ + + KASSERT(s != NULL, ("sleepout ptr is NULL")); + + return (callout_pending(&st->st_callout)); +} + +/* + * NB: please notice that even if callout_stop(9) is called successfully, + * the task queue which enqueued for this sleepout_task could be fired + * by races. + */ +int +sleepout_stop(struct sleepout_task *st) +{ + + KASSERT(s != NULL, ("sleepout ptr is NULL")); + + return (callout_stop(&st->st_callout)); +} + +int +sleepout_drain(struct sleepout_task *st) +{ + struct sleepout *s = st->st_sleepout; + int ret; + + KASSERT(s != NULL, ("sleepout ptr is NULL")); + + /* + * Drains the callout first before draining the taskqueue that + * The reversed order make a callout trigger during taskqueue draining. + */ + ret = callout_drain(&st->st_callout); + taskqueue_drain(s->s_taskqueue, &st->st_task); + return (ret); +} Property changes on: usb_sleepout.c ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + Id Added: svn:eol-style + native Index: usb_sleepout.h =================================================================== --- usb_sleepout.h (revision 0) +++ usb_sleepout.h (revision 0) @@ -0,0 +1,55 @@ +/*- + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + * + * $FreeBSD$ + */ + +#ifndef _USB_SLEEPOUT_H_ +#define _USB_SLEEPOUT_H_ + +#include +#include + +struct sleepout { + struct taskqueue *s_taskqueue; +}; + +typedef void (*sleepout_func_t)(void *); + +struct sleepout_task { + struct sleepout *st_sleepout; + struct callout st_callout; + struct task st_task; + struct mtx *st_mtx; + int st_flags; +#define SLEEPOUT_CANCELLED (1 << 0) + sleepout_func_t st_func; + void *st_arg; +}; + +#define SLEEPOUT_RUNTASK(_so, _task) \ + taskqueue_enqueue((_so)->s_taskqueue, (_task)) +#define SLEEPOUT_DRAINTASK(_so, _task) \ + taskqueue_drain((_so)->s_taskqueue, (_task)) + +void sleepout_create(struct sleepout *, const char *); +void sleepout_free(struct sleepout *); +void sleepout_init(struct sleepout *, struct sleepout_task *, int); +void sleepout_init_mtx(struct sleepout *, struct sleepout_task *, + struct mtx *, int); +int sleepout_reset(struct sleepout_task *, int, sleepout_func_t, void *); +int sleepout_pending(struct sleepout_task *); +int sleepout_stop(struct sleepout_task *); +int sleepout_drain(struct sleepout_task *); + +#endif Property changes on: usb_sleepout.h ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + Id Added: svn:eol-style + native From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 08:09:33 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6A6A106566C; Mon, 1 Nov 2010 08:09:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id D08F78FC19; Mon, 1 Nov 2010 08:09:32 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=5o9ETn4JDi4A:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=HYGeF8SLwlOEH9T6usgA:9 a=ns9OU_32NzLckYhYfvM_TQET-lgA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42771659; Mon, 01 Nov 2010 09:09:30 +0100 From: Hans Petter Selasky To: Weongyo Jeong Date: Mon, 1 Nov 2010 09:10:43 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20101030231901.GA83161@weongyo> <201010311509.49138.hselasky@c2i.net> <20101101020348.GD3918@weongyo> In-Reply-To: <20101101020348.GD3918@weongyo> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011010910.43121.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: [CFR] add usb_sleepout.[ch] X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 08:09:34 -0000 On Monday 01 November 2010 03:03:48 Weongyo Jeong wrote: > On Sun, Oct 31, 2010 at 03:09:49PM +0100, Hans Petter Selasky wrote: > > On Sunday 31 October 2010 01:19:01 Weongyo Jeong wrote: > > > Hello USB guys, > > > > 1) All the sleepout_xxx() functions need mutex asserts. > Hi, > It looks it don't need it because callout(9) does it instead of sleepout > routines. Moreover sleepout don't create any mutexes in itself. Ok. > > > 2) Is it allowed to call callout_stop() / callout_reset() unlocked at > > all? > > Yes as long as it doesn't have side effects. It seems no drivers hold a > lock to call callout_stop() / callout_reset(). All USB drivers do to ensure state coherency. > > > What are the concequences if the mutex associated with the sleepout is > > NULL ? > > I added KASSERT macro to check this case at below. However the sleepout > pointer normally never be NULL because the intention of usage was as > follows: > > struct _softc { > struct sleepout sleepout; > struct sleepout_task sleepout_task; > }; > > sleepout_create(&sc->sleepout, "blah"); > > Only it could be happen if `struct sleepout' is allocated by > dynamically though it's not my first purpose. > > > 3) As per the current implementation it can happen that the task'ed > > timeout is called after that sleepout_stop() is used. The code should > > have a check in the task function to see if the sleepout() has been > > cancelled or not, when the mutex associated with the sleepout is locked. > > Yes it's true but it'd better to implement first taskqueue_stop() than > adding it sleepout routines directly. However no plans yet because I > couldn't imagine a side effect due to lack of this feature. Please let > me know if I missed the something important. Maybe not when you are implementing a watchdog timer for ethernet, but then you are limiting the use of those functions to USB ethernet only. The problem happens when you are updating a state-machine in the callback and cannot trust that a stop cancelled the sleepout. All existing USB functions are written this way. I.E. no completion done callback after usbd_transfer_stop(). For example if your watchdog is calling if_start() somehow, and then you do an if_down() which stops the watchdog, and then you can end up triggering the if_start() after if_down(), which is incorrect. > > > 4) Should the functions be prefixed by usb_ ? > > I don't have a preference for this. I think it's no problem to change > it. It could happen soon. > > > 5) In drain you should drain the callout first, then drain the tasqueue. > > Else the timer can trigger after the taskqueue is drained. Have you considered using the USB sub-systems taskqueue, instead of the kernel one, so that jobs can be serialised among the two? Else you end up introducing SX-locks in all drivers? Is that on purpose? > It's fixed. Thank you for your review and the updated version is > embedded at this email. --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 08:29:16 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A3F2106566C; Mon, 1 Nov 2010 08:29:16 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 9885F8FC0A; Mon, 1 Nov 2010 08:29:15 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=4dE6tNKVm/0afO7MQGRPv7y2YwMo4emTIiDjbh74onY= c=1 sm=1 a=47Qj4_x6mI4A:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=Rr0R_xDqafomNP2zMC0A:9 a=XEVlvgEUUPTXRNKKEikA:7 a=-5gveJ-xTQQGrhZ7HWK8Wl3sap8A:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42913675; Mon, 01 Nov 2010 09:29:13 +0100 From: Hans Petter Selasky To: Weongyo Jeong Date: Mon, 1 Nov 2010 09:30:25 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20101031224304.GB3918@weongyo> In-Reply-To: <20101031224304.GB3918@weongyo> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011010930.26038.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: [CFR 2-3/n] removes uther dependency of axe(4) X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 08:29:16 -0000 On Sunday 31 October 2010 23:43:04 Weongyo Jeong wrote: > +static void > +axe_watchdog(void *arg) > +{ > + struct axe_softc *sc = arg; > + struct ifnet *ifp = sc->sc_ifp; > + > + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) > + return; > + Hi, Please explain what is wrong with the existing code regarding code synchronisation. Your patch is very big and is likely to introduce problems. I oppose the introduction of SX-locks. Please explain why you think SX-locks are better than the USB process taskqueue. Are you absolutely sure that all the IOCTL's that are called are allowed to block in the way you have programmed? The checks in xxx_watchdog() are not good enough. axe_tick() will execute synchronous USB functions, which sleep for many hundreds of microseconds. You should add this check before the sleepout_reset() too, and is this code called with any lock locked? I.E. Are you doing the clearing of IFF_DRV_RUNNING atomic to testing this flag? Else the result can be random? --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 08:41:52 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F306106566B; Mon, 1 Nov 2010 08:41:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id C5BF58FC15; Mon, 1 Nov 2010 08:41:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=yevn+QCjI6xy199BDvBOOiO14qYvyLq62he9tTtU3M8= c=1 sm=1 a=yDwUScyJ9MwA:10 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=xaX6kcLCyhMPPsF_Tx0A:9 a=Hh1pgLQjwXDtUsZPEWUA:7 a=V_GLK3_UeC4KKuohFtt2tTb5_-AA:4 a=PUjeQqilurYA:10 a=QZ86cGY-UPPgN3lL:21 a=toxKXpuxvxNmfR0f:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42883620; Mon, 01 Nov 2010 09:41:49 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Mon, 1 Nov 2010 09:43:02 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011010118.oA11IwKO098488@www.freebsd.org> In-Reply-To: <201011010118.oA11IwKO098488@www.freebsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011010943.02352.hselasky@c2i.net> Cc: freebsd-gnats-submit@freebsd.org, HIROSHI OOTA Subject: Re: usb/151851: libusb(3) libusb_control_transfer() return value is incorrect X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 08:41:52 -0000 On Monday 01 November 2010 02:18:58 HIROSHI OOTA wrote: > >Number: 151851 > >Category: usb > >Synopsis: libusb(3) libusb_control_transfer() return value is > >incorrect Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-usb > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: doc-bug > >Submitter-Id: current-users > >Arrival-Date: Mon Nov 01 01:20:08 UTC 2010 > >Closed-Date: > >Last-Modified: > >Originator: HIROSHI OOTA > >Release: 9-current > >Organization: > > >Environment: > FreeBSD aries 9.0-CURRENT FreeBSD 9.0-CURRENT #102 r214602M: Mon Nov 1 > 03:06:42 JST 2010 root@localhost amd64 > > >Description: > In the libusb(3) man page the return value of libusb_control_transfer is: > > Returns 0 on success > > but, it's returns the number of bytes actually transferred. > > >How-To-Repeat: > > > >Fix: > > > > > >Release-Note: > >Audit-Trail: > > >Unformatted: See USB P4 change 185296. --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 08:50:08 2010 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1660E106564A for ; Mon, 1 Nov 2010 08:50:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DE3628FC1E for ; Mon, 1 Nov 2010 08:50:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA18o7Fd071090 for ; Mon, 1 Nov 2010 08:50:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA18o7bE071089; Mon, 1 Nov 2010 08:50:07 GMT (envelope-from gnats) Date: Mon, 1 Nov 2010 08:50:07 GMT Message-Id: <201011010850.oA18o7bE071089@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Hans Petter Selasky Cc: Subject: Re: usb/151851: libusb(3) libusb_control_transfer() return value is incorrect X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Hans Petter Selasky List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 08:50:08 -0000 The following reply was made to PR usb/151851; it has been noted by GNATS. From: Hans Petter Selasky To: freebsd-usb@freebsd.org Cc: HIROSHI OOTA , freebsd-gnats-submit@freebsd.org Subject: Re: usb/151851: libusb(3) libusb_control_transfer() return value is incorrect Date: Mon, 1 Nov 2010 09:43:02 +0100 On Monday 01 November 2010 02:18:58 HIROSHI OOTA wrote: > >Number: 151851 > >Category: usb > >Synopsis: libusb(3) libusb_control_transfer() return value is > >incorrect Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-usb > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: doc-bug > >Submitter-Id: current-users > >Arrival-Date: Mon Nov 01 01:20:08 UTC 2010 > >Closed-Date: > >Last-Modified: > >Originator: HIROSHI OOTA > >Release: 9-current > >Organization: > > >Environment: > FreeBSD aries 9.0-CURRENT FreeBSD 9.0-CURRENT #102 r214602M: Mon Nov 1 > 03:06:42 JST 2010 root@localhost amd64 > > >Description: > In the libusb(3) man page the return value of libusb_control_transfer is: > > Returns 0 on success > > but, it's returns the number of bytes actually transferred. > > >How-To-Repeat: > > > >Fix: > > > > > >Release-Note: > >Audit-Trail: > > >Unformatted: See USB P4 change 185296. --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 11:07:08 2010 Return-Path: Delivered-To: freebsd-usb@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79478106564A for ; Mon, 1 Nov 2010 11:07:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 65D6F8FC1F for ; Mon, 1 Nov 2010 11:07:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA1B78ti019331 for ; Mon, 1 Nov 2010 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA1B77xG019329 for freebsd-usb@FreeBSD.org; Mon, 1 Nov 2010 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Nov 2010 11:07:07 GMT Message-Id: <201011011107.oA1B77xG019329@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-usb@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-usb@FreeBSD.org X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 11:07:08 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o usb/151851 usb libusb(3) libusb_control_transfer() return value is in o usb/151043 usb Please add USB device MELCO WLR-UC-G o usb/150989 usb [patch] Add Netgear WG111V2_2 support to upgt(4) o usb/150892 usb [zyd] Whenever network contacted in any shape, way or p usb/150546 usb libusb(3) libusb_control_transfer() prototype is incor o usb/150401 usb [umass] [usb8] Errors from USB drives mixed between UF o usb/150189 usb [run] [usb8] [patch] if_run appears to corrupt IP traf o usb/149934 usb [patch] [usb8] Transcend JetFlash V85 poor performance o usb/149900 usb [uftdi] [patch] FreeBSD 8.1 uftdi patch to support usb o usb/149764 usb [u3g] [patch] usbdevs update: Huawei K3765 3G modem o usb/149675 usb [uftdi] [usb_serial] doesn't react to break properly o usb/149528 usb [zyd] Wireless USB stick not detected - vendor id 0x08 o usb/149283 usb [uftdi] avrdude unable to talk to Arduino board (via u o usb/149162 usb [ural] ASUS WL-167g doesn't work in 8.1 (continue of 1 o usb/149039 usb [uhso] [patch] Binding problem with uhso s usb/148702 usb [usb8] [request] IO DATA USB-RSAQ5 support on FreeBSD- o usb/148080 usb usbconfig(8) sometimes does not turn off the device o usb/147516 usb [umass] [usb67] kernel unable to deal with Olympus USB o usb/146871 usb [usbdevs] [usb8] [patch] provide descriprive string fo o usb/146840 usb [hang] FreeBSD 7.2 / 7.3 / 8.0 hang at startup after e o usb/146153 usb [axe] [usb8] Hosts in network doesn't receive any pack o usb/146054 usb [urtw] [usb8] urtw driver potentially out of date f usb/145513 usb [usb8] New USB stack: no new devices after forced usb o usb/145455 usb [usb8] [patch] USB debug support cannot be disabled o usb/145415 usb [umass] [usb8] USB card reader does not create slices a usb/145184 usb GENERIC can't mount root from USB on Asus EEE o usb/145165 usb [keyboard] [usb8] ukbd_set_leds_callback: error=USB_ER f kern/144938 usb [keyboard] [boot] Boot Failure with Apple (MB869LL/A) o usb/144387 usb [run] [panic] if_run panic o usb/144043 usb [umass] [usb8] USB DLT tape drive throws random errors a usb/143790 usb [boot] [cam] can not boot from usb hdd f usb/143620 usb [cdce] [usb8] the module if_cdce doesn't support my Op f usb/143294 usb [usb8] copying process stops at some time (10 - 50 sec o usb/143286 usb [ukbd] [usb8] [boot] boot failures on RELENG_8 system f usb/143186 usb [usbdevs] [usb8] [patch] add USB device IDs for Google a usb/143139 usb [umass] [usb8] [patch] Quirk for Century EX35SW4_SB4 J o usb/143045 usb [umass] [usb8] [patch] mounting Fujitsu 2600Z camera d o usb/142991 usb [uftdi] [usb67] [patch] Patch to add Crystalfontz 533 f usb/142989 usb [usb8] canon eos 50D attaches but detaches after few s f usb/142957 usb [umass] [usb8] [patch] patch for USB disk SYNCHRONIZE o usb/142719 usb [urtw] [usb8] AirLive WL-1600USB (RTL8187L chipset) fa o usb/142713 usb [usb67] [panic] Kernel Panik when connecting an IPhone f usb/142276 usb [umass] [usb8] Cache Synchronization Error with Olympu o usb/142229 usb [ums] [usb8] [hang] connecting a USB mouse to a Dell P o usb/141680 usb [uath] [usb8] Netgear WG111T not working with uath dri o usb/141664 usb [pcm] [usb8] Logitech USB microphone failure [regressi o usb/141474 usb [boot] [usb8] FreeBSD 8.0 can not install from USB CDR o usb/141327 usb [ukbd] [usb67] USB kbd not working with 7.1+PAE on IBM o usb/141212 usb [ukbd] [usb8] ukbd_set_leds_callback:700: error=USB_ER o kern/141011 usb [usb] Encrypted root, geli password at boot; enter key o usb/140920 usb [install] [usb8] USB based install fails on 8.0-RELEAS o usb/140893 usb [urtw] [usb8] WPA2 not working on rtl8187b f usb/140883 usb [axe] [usb8] USB gigabit ethernet hangs after short pe o kern/140849 usb [ums] [usb8] USB mouse doesn't work under FreeBSD 8.0- a usb/140810 usb [uftdi] [usb8] 8.X copy and paste problem / tty overfl o usb/140477 usb [umass] [usb8] [patch] allow boot-time attachment of d o usb/140236 usb [msdosfs] [usb8] Labels wiped on external Journaled US o usb/140160 usb [usb8] [acpi] USB ports are no longer "active" after A s usb/139990 usb [panic] [patch] [usb67] Kernel frequently panics after a usb/139598 usb [umass] [usb8] CAM reports "xptioctl: put "device pass o usb/139243 usb [uhci] [usb67] unplug prolific USB serial -> uhci_abor a usb/138904 usb [rum] [panic] [usb67] unpluging USB wifi card panics s f usb/138882 usb [ohci] [panic] [usb67] Can't install FreeBSD 7.2 due t o usb/138798 usb [boot] [usb8] 8.0-BETA4 can't boot from USB flash driv o usb/138659 usb [usb8][uftdi] driver broken in RELENG_8/CURRENT o usb/138570 usb [usb] [panic] USB mass device panics current 7.2-STABL o usb/138548 usb [usb67] [usb8] usb devices periodically have unknown a o usb/138175 usb [usb67] [boot] System cannot boot, when USB reader wit o usb/138124 usb [snd_uaudio] [usb8] Axed uaudio functionality in the u o usb/138119 usb [usb67] [usb8] MultiBay CDROM (probably on USB bus) is o usb/137872 usb [usb67] [boot] slow booting on usb flash drive o usb/137806 usb [ukbd] [usb67] USB keyboard doesn't work until it's un o usb/137763 usb [usb67][ukbd] Logitech wireless keyboard media keys no o usb/137377 usb [usb8] request support for Huawei E180 o usb/137341 usb [usb8][rum] driver if_rum doesn't work at all and thro f usb/137190 usb [usb8][patch] inhibit spurious button releases for som o usb/137189 usb [usb8][patch] create and use sysctl nodes for HID repo p usb/137188 usb [usb8][patch] correctly handle USB report descriptors o usb/137129 usb [ums] [usb8] SteelSeries Ikari USB laser mouse not att p usb/136761 usb [usbdevs][usb67][patch] Teach usbdevs / u3g(4) about H o usb/135938 usb [aue] [usb67] aue driver only passes traffic in promis o usb/135542 usb [keyboard] boot loader does not work with a usb keyboa o usb/135348 usb [umass] [patch] USB Drive Hangs with ZFS (JMicron USB2 o usb/135206 usb machine reboots when inserted USB device o usb/135200 usb SAMSUNG i740 usb mass: Synchronize cache failed, statu o usb/135182 usb UMASS quirk - Olympus FE20 camera o usb/134950 usb Lowering DTR for USB-modem via ubsa is not possible o usb/134299 usb Kernel Panic plugging in MF626 USB UMTS Stick u3g o usb/134193 usb System freeze on usb MP3 player insertion o usb/134085 usb [umass] Adding usb quirk for Sony USB flash drive o usb/133989 usb [usb8] [ukbd] USB keyboard dead at mountroot> prompt o usb/133712 usb [ural] [patch] RE: Fixed an issue with ural(4) that wa o usb/133390 usb umass crashes system in 7.1 when Olympus D-540 attache o usb/133296 usb [rum] driver not working properly in hostap mode o usb/132594 usb USB subsystem causes page fault and crashes o usb/132312 usb [hang] Xorg 7.4 halts USB controller o usb/132080 usb [patch] [usb] [rum] [panic] Kernel panic after NOMEM c o usb/132066 usb [ukbd] Keyboard failure USB keyboard DELL 760 o usb/132036 usb [panic] page fault when connecting Olympus C740 camera o usb/131583 usb [umass] Failure when detaching umass Device o usb/131576 usb [aue] ADMtek USB To LAN Converter can't send data o usb/131521 usb Registering Belkin UPS to usb_quirks.c p usb/131123 usb [patch] [usb67] re-add UQ_ASSUME_CM_OVER_DATA USB quir o usb/131074 usb no run-time detection of usb devices plugged into exte o usb/130736 usb Page fault unplugging USB stick s usb/130230 usb [patch] [quirk] [usb67] [usb] [cam] [umass] Samsung El o usb/130208 usb Boot process severely hampered by umass0 error o usb/130122 usb [usb8] DVD drive detects as 'da' device o usb/129766 usb [usb] [panic] plugging in usb modem HUAWEI E226 panics o usb/129673 usb [uhci] uhci (uhub) confused on replugging USB 1.1 scan o usb/129500 usb [umass] [panic] FreeBSD Crashes when connecting SanDis o usb/129311 usb [usb] [panic] Instant crash with an USB card reader s usb/128990 usb [usb] u3g does not handle RTS/CTS available on for exa o usb/128977 usb [usb67] [patch] uaudio is not full duplex p usb/128803 usb [usbdevs] [patch] Quirk for I-Tuner Networks USBLCD4X2 o usb/128485 usb [umodem] [patch] Nokia N80 modem support o usb/128425 usb [umass] Cannot Connect Maxtor Onetouch 4 USB drive o usb/128418 usb [panic] [rum] loading if_rum causes panic, looks like o usb/127926 usb [boot] USB Timeout during bootup s usb/127453 usb [request] ubsa, uark, ubser, uftdi, and friends should p docs/127406 usb [patch] update umodem man page: Sony Ericsson W810i o usb/127342 usb [boot] [panic] enabling usb keyboard and mouse support o usb/127248 usb [ucom] panic while uplcom devices attach and detach o usb/127222 usb [ohci] Regression in 7.0 usb storage generic driver o usb/126884 usb [ugen] [patch] Bug in buffer handling in ugen.c o usb/126848 usb [usb]: USB Keyboard hangs during Installation o usb/126740 usb [ulpt] doesn't work on 7.0-RELEASE, 10 second stall be o usb/126519 usb [usb] [panic] panic when plugging in an iphone o kern/126396 usb [panic] kernel panic after unplug USB Bluetooth device o usb/125631 usb [ums] [panic] kernel panic during bootup while 'Logite o usb/125510 usb [panic] repeated plug and unplug of USB mass storage d o usb/125450 usb [panic] Removing USB flash card while being accessed c o usb/125238 usb [ums] Habu Mouse turns off in X o usb/125088 usb [keyboard] Touchpad not detected on Adesso AKB-430UG U o usb/124980 usb [panic] kernel panic on detaching unmounted umass devi o kern/124777 usb [ucom] USB cua devices don't revert to tty devices whe o usb/124758 usb [rum] [panic] rum panics SMP kernel o usb/124708 usb [panic] Kernel panic on USB KVM reattach f usb/124604 usb [ums] Microsoft combo wireless mouse doesn't work o kern/124130 usb [usb] gmirror fails to start usb devices that were pre o usb/123969 usb [usb] Supermicro H8SMi-2 usb problem: port reset faile o usb/123714 usb [usb] [panic] Panic when hald-storage-probe runs with o usb/123691 usb usbd(8): usbd hangs o usb/123690 usb [usb] [panic] Panic on USB device insertion when usb l o usb/123611 usb [usb] BBB reset failed, STALLED from Imation/Mitsumi U o usb/122992 usb [umass] [patch] MotoROKR Z6 Phone not recognised by um o usb/122936 usb [ucom] [ubsa] Device does not receive interrupt o usb/122905 usb [ubsa] [patch] add Huawei E220 to ubsa o usb/122819 usb [usb] [patch] Patch to provide dynamic additions to th o usb/122813 usb [udbp] [request] udbp driver should be removed in favo o usb/122547 usb [ehci] USB Printer not being recognized after reboot o usb/122539 usb [ohci] [panic] AnyDATA ADU-E1000D - kernel panic: ohci o usb/122483 usb [panic] [ulpt] Repeatable panic in 7.0-STABLE o usb/122119 usb [umass] umass device causes creation of daX but not da o usb/121755 usb [ohci] [patch] Fix panic after ohci/uhub cardbus devic o usb/121734 usb [ugen] ugen HP1022 printer device not working since up o usb/121708 usb [keyboard] nforce 650i mobo w/ usb keyboard infinite k o usb/121474 usb [cam] [patch] QUIRK: SAMSUNG HM250JI in LaCie usb hard o usb/121275 usb [boot] [panic] FreeBSD fails to boot with usb legacy s o usb/121232 usb [usb] [panic] USB CardBus card removal causes reboot s p usb/121184 usb [uipaq] [patch] add ids from linux ipaq driver (plus a o usb/121169 usb [umass] Issues with usb mp3 player o usb/121045 usb [uftdi] [patch] Add support for PC-OP-RS1 and KURO-RS o usb/120786 usb [usb] [panic] Kernel panic when forced umount of a det o usb/120729 usb [panic] fault while in kernel mode with connecting USB o usb/120572 usb [usb67] [umass] [patch] quirk to support ASUS P535 as o usb/120321 usb [hang] System hangs when transferring data to WD MyBoo o usb/120283 usb [panic] Automation reboot with wireless keyboard & mou o usb/120034 usb [hang] 6.2 & 6.3 hangs on boot at usb0: OHCI with 1.5 o usb/119977 usb [ums] Mouse does not work in a Cherry-USB keyboard/mou o usb/119653 usb [cam] [patch] iriver s7 player sync cache error patch o usb/119633 usb [umass] umass0: BBB reset failed, IOERROR [regression] o usb/119513 usb [irq] inserting dlink dwl-g630 wireless card results i o usb/119509 usb [usb] USB flaky on Dell Optiplex 755 o usb/119481 usb [hang] FreeBSD not responding after connecting USB-Mas o usb/119389 usb [umass] Sony DSC-W1 CBI reset failed, STALLED [regress o usb/119227 usb [ubsa] [patch] ubsa buffer is too small; should be tun o usb/119201 usb [cam] [patch] Quirks for Olympus FE-210 camera, LG and o usb/118480 usb [umass] Timeout in USB mass storage freezes vfs layer o usb/118353 usb [panic] [ppp] repeatable kernel panic during ppp(4) se o usb/118141 usb [ucom] usb serial and nokia phones ucomreadcb ucomread o usb/118140 usb [ucom] [patch] quick hack for ucom to get it behave wi o usb/118098 usb [umass] 6th gen iPod causes problems when disconnectin o usb/117955 usb [umass] [panic] inserting minolta dimage a2 crashes OS o usb/117946 usb [panic] D-Link DUB-E100 rev. B1 crashes FreeBSD 7.0-BE o usb/117938 usb [ums] [patch] Adding support for MS WL Natural and MS o usb/117911 usb [ums] [request] Mouse Gembird MUSWC not work o usb/117893 usb [umass] Lacie USB DVD writing failing o usb/117613 usb [uhci] [irq] uhci interrupt storm & USB leaked memory o usb/117598 usb [snd_uaudio] [patch] Not possible to record with Plant o usb/117313 usb [umass] [panic] panic on usb camera insertion o usb/117200 usb [ugen] ugen0 prints strange string on attach if detach o usb/117183 usb [panic] USB/fusefs -- panic while transferring large a p usb/116947 usb [ukbd] [patch] [regression] enable boot protocol on th o usb/116699 usb [usbhid] USB HID devices do not initialize at system b o usb/116561 usb [umodem] [panic] RELENG_6 umodem panic "trying to slee o usb/116282 usb [ulpt] Cannot print on USB HP LJ1018 or LJ1300 o usb/115935 usb [usbdevs] [patch] kernel counterproductively attaches o usb/115933 usb [uftdi] [patch] RATOC REX-USB60F (usb serial converter o usb/115400 usb [ehci] Problem with EHCI on ASUS M2N4-SLI o usb/115298 usb [ulpt] [panic] Turning off USB printer panics kernel o usb/114916 usb [umass] [patch] USB Maxtor drive (L300RO) requires qui o kern/114780 usb [uplcom] [panic] Panics while stress testing the uplco o usb/114682 usb [umass] generic USB media-card reader unusable o usb/114310 usb [libusb] [patch] [panic] USB hub attachment panics ker o usb/114068 usb [usb67] [usb8] [umass] [patch] Problem with connection o conf/114013 usb [patch] WITHOUT_USB allow to compil a lot of USB stuff s usb/113060 usb [usb67] [ulpt] [patch] Samsung printer not working in o usb/110856 usb [usb67] [ugen] [patch] interrupt in msgs are truncated s usb/108344 usb [usb67] [atausb] [panic] kernel with atausb panics whe o usb/107827 usb [usb67] [ohci] [panic] ohci_add_done addr not found o usb/107388 usb [usb67] [usb8] [new driver] [patch] add utoppy device o usb/106041 usb [usb67] [usb8] [request] FreeBSD does not recognise Mu o usb/105361 usb [usb67] [panic] Kernel panic during unmounting mass st s usb/103917 usb [usb67] [uhub] USB driver reports "Addr 0 should never o usb/103418 usb [usb67] [usb8] [patch] [request] usbhidctl(8) add abil o usb/103046 usb [usb67] [ulpt] [patch] ulpt event driven I/O with sele o usb/101775 usb [usb67] [usb8] [libusbhid] [patch] possible error in r o usb/101761 usb [usb67] [patch] [request] usb.h: increase maximal size o usb/100746 usb [usb67] [ukbd] system does not boot due to USB keyboar o usb/99431 usb [keyboard] FreeBSD on MSI 6566E (Intel 845E motherboar o kern/99200 usb [bluetooth] SMP-Kernel crashes reliably when Bluetooth o usb/98343 usb [boot] BBB reset failed errors with Creative Muvo MP3 o usb/97472 usb [cam] [patch] add support for Olympus C150,D390 s usb/97286 usb [mouse] [request] MS Wireless Intellimouse Explorer 2. o usb/97175 usb [umass] [hang] USB cardreader hangs system o usb/96457 usb [umass] [panic] fatback on umass = reboot o usb/96381 usb [cam] [patch] add a quirk table entry for a flash ram o usb/96224 usb [usb] [msdosfs] mount_msdosfs cause page fault in sync s usb/96120 usb [ums] [request] USB mouse not always detected s usb/95636 usb [umass] [boot] 5 minute delay at boot when using VT620 o usb/95562 usb [umass] Write Stress in USB Mass drive causes "vinvalb s usb/95348 usb [keyboard] USB keyboard unplug causes noise on screen o usb/95037 usb [umass] USB disk not recognized on hot-plug. o usb/94897 usb [panic] Kernel Panic when cleanly unmounting USB disk o usb/94717 usb [ulpt] Reading from /dev/ulpt can break work of a UHCI o usb/94384 usb [panic] kernel panic with usb2 hardware o usb/93872 usb [cam] [patch] SCSI quirk required for ELTA 8061 OL USB o usb/93828 usb [ohci] [panic] ohci causes panic on boot (HP Pavillion o usb/93389 usb [umass] [patch] Digital Camera Pentax S60 don't work o usb/92852 usb [ums] [patch] Vertical scroll not working properly on o usb/92171 usb [panic] panic unplugging Vodafone Mobile Connect (UMTS o usb/92142 usb [uhub] SET_ADDR_FAILED and SHORT_XFER errors from usb o usb/92083 usb [ural] [panic] panic using WPA on ural NIC in 6.0-RELE o usb/92052 usb [ulpt] usbd causes defunct process with busy file-hand o usb/91906 usb [ehci] [hang] FreeBSD hangs while booting with USB leg f usb/91896 usb camcontrol(8): Serial Number of USB Memory Sticks is n o usb/91811 usb [umass] Compact Flash in HP Photosmart 2610 return " o usb/91546 usb [umodem] [patch] Nokia 6630 mobile phone does not work o usb/91538 usb [ulpt] [patch] Unable to print to EPSON CX3500 o usb/91283 usb [boot] [regression] booting very slow with usb devices o usb/91238 usb [umass] USB tape unit fails to write a second tape fil o usb/90700 usb [umass] [panic] Kernel panic on connect/mount/use umas o usb/89954 usb [umass] [panic] USB Disk driver race condition? s usb/89003 usb [request] LaCie Firewire drive not properly supported o usb/88743 usb [hang] [regression] USB makes kernel hang at boot (reg o usb/88408 usb [axe] axe0 read PHY failed o usb/87648 usb [mouse] Logitech USB-optical mouse problem. o usb/87224 usb [usb] Cannot mount USB Zip750 o usb/86767 usb [umass] [patch] bogus "slice starts beyond end of the o usb/86298 usb [mouse] Known good USB mouse won't work with correct s s usb/85067 usb [uscanner] Cannot attach ScanJet 4300C to usb device s usb/84336 usb [usb] [reboot] instant system reboot when unmounting a o usb/83977 usb [ucom] [panic] ucom1: open bulk out error (addr 2): IN o usb/83863 usb [ugen] Communication problem between opensc/openct via o usb/83756 usb [ums] [patch] Microsoft Intellimouse Explorer 4.0A doe o usb/83563 usb [umass] [panic] Page Fault while detaching Mpman Usb d o usb/83504 usb [kernel] [patch] SpeedTouch USB stop working on recent o usb/82660 usb [ehci] [panic] EHCI: I/O stuck in state 'physrd'/panic s usb/82569 usb [umass] [panic] USB mass storage plug/unplug causes sy o usb/82520 usb [udbp] [reboot] Reboot when USL101 connected o usb/82350 usb [ucom] [panic] null pointer dereference in USB stack o usb/81621 usb [ehci] [hang] external hd hangs under load on ehci o usb/80935 usb [uvisor] [patch] uvisor.c is not work with CLIE TH55. o usb/80854 usb [patch] [request] suggestion for new iface-no-probe me s usb/80777 usb [request] usb_rem_task() should wait for callback to c s usb/80776 usb [udav] [request] UDAV device driver shouldn't use usb_ o usb/80774 usb [patch] have "usbd_find_desc" in line with the other " f usb/80361 usb [umass] [patch] mounting of Dell usb-stick fails f usb/80040 usb [sound] [hang] Use of sound mixer causes system freeze o usb/79723 usb [usb] [request] prepare for high speed isochronous tra o usb/78984 usb [umass] [patch] Creative MUVO umass failure f usb/77294 usb [ucom] [panic] ucom + ulpcom panic o usb/76732 usb [ums] Mouse problems with USB KVM Switch o usb/76653 usb [umass] [patch] Problem with Asahi Optical usb device o usb/76461 usb [umass] disklabel of umass(4)-CAM(4)-da(4) not used by f usb/76395 usb [uhci] USB printer does not work, usbdevs says "addr 0 s usb/75928 usb [umass] [request] Cytronix SmartMedia card (SMC) reade o usb/75800 usb [ucom] ucom1: init failed STALLED error in time of syn f usb/75797 usb [sound] [regression] 5.3-STABLE(2005 1/4) detect USB h o usb/75764 usb [umass] [patch] "umass0: Phase Error" - no device for f usb/75705 usb [umass] [panic] da0 attach / Optio S4 (with backtrace) f usb/74771 usb [umass] [hang] mounting write-protected umass device a s usb/74453 usb [umass] [patch] Q-lity CD-RW USB ECW-043 (ScanLogic SL o usb/74211 usb [umass] USB flash drive causes CAM status 0x4 on 4.10R o usb/73307 usb [panic] Kernel panics on USB disconnect s usb/72733 usb [ucom] [request] Kyocera 7135 Palm OS connection probl o usb/71455 usb [umass] Slow USB umass performance of 5.3 o usb/71417 usb [ugen] Cryptoflex e-gate USB token (ugen0) communicati o usb/71416 usb [ugen] Cryptoflex e-gate USB token (ugen0) detach is n o usb/71280 usb [aue] aue0 device (linksys usb100tx) doesn't work in 1 o usb/71155 usb [ulpt] misbehaving usb-printer hangs processes, causes o usb/70523 usb [umct] [patch] umct sending/receiving wrong characters o usb/69006 usb [usbdevs] [patch] Apple Cinema Display hangs USB ports o usb/68232 usb [ugen] [patch] ugen(4) isochronous handling correction o usb/67301 usb [uftdi] [panic] RTS and system panic o usb/66547 usb [ucom] Palm Tungsten T USB does not initialize correct o usb/63621 usb [umass] [panic] USB MemoryStick Reader stalls/crashes s usb/62257 usb [umass] [request] card reader UCR-61S2B is only half-s o usb/59698 usb [keyboard] [patch] Rework of ukbd HID to AT code trans s bin/57255 usb [patch] usbd(8) and multi-function devices s usb/52026 usb [usb] [request] umass driver support for InSystem ISD2 s usb/51958 usb [urio] [patch] update for urio driver o usb/40948 usb [umass] [request] USB HP CDW8200 does not work o usb/30929 usb [usb] [patch] use usbd to initialize USB ADSL modem 315 problems total. From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 13:20:09 2010 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C163C1065670 for ; Mon, 1 Nov 2010 13:20:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9DCBD8FC17 for ; Mon, 1 Nov 2010 13:20:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA1DK9mP059627 for ; Mon, 1 Nov 2010 13:20:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA1DK9Rv059626; Mon, 1 Nov 2010 13:20:09 GMT (envelope-from gnats) Resent-Date: Mon, 1 Nov 2010 13:20:09 GMT Resent-Message-Id: <201011011320.oA1DK9Rv059626@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-usb@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Alessandro de Manzano Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FD90106566C for ; Mon, 1 Nov 2010 13:16:57 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 43B988FC0C for ; Mon, 1 Nov 2010 13:16:57 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id oA1DGu34046725 for ; Mon, 1 Nov 2010 13:16:56 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id oA1DGu0r046724; Mon, 1 Nov 2010 13:16:56 GMT (envelope-from nobody) Message-Id: <201011011316.oA1DGu0r046724@www.freebsd.org> Date: Mon, 1 Nov 2010 13:16:56 GMT From: Alessandro de Manzano To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: usb/151862: adding support of USB GSM modem Falcom Twist X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 13:20:09 -0000 >Number: 151862 >Category: usb >Synopsis: adding support of USB GSM modem Falcom Twist >Confidential: no >Severity: non-critical >Priority: high >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Mon Nov 01 13:20:09 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Alessandro de Manzano >Release: FreeBSD 6.4-RELEASE-p10 >Organization: >Environment: FreeBSD bigblue.sunshine.ale 6.4-RELEASE-p10 FreeBSD 6.4-RELEASE-p10 #5: Thu May 27 14:35:55 CEST 2010 root@bigblue.sunshine.ale:/usr/obj/usr/src/sys/BIGBLUE i386 >Description: The Falcom Twist USB GSM/GPRS modem is not currently supported by FreeBSD, even latest 8.1-R does not support it. I 've made a very simple e short patch to add its vendor and product IDs to "uftdi.c" and "usbdevs" files. A quick test seems to confirm it works. Unfortunately my patch is just for FreeBSD 6.4-Rp10, but I guess it's not too much different on latest 8.x.. >How-To-Repeat: >Fix: Patch attached with submission follows: --- uftdi.c.old 2010-11-01 13:22:30.000000000 +0100 +++ uftdi.c 2010-11-01 13:29:48.000000000 +0100 @@ -175,6 +175,7 @@ if (uaa->vendor == USB_VENDOR_BBELECTRONICS && (uaa->product == USB_PRODUCT_BBELECTRONICS_USOTL4)) return (UMATCH_VENDOR_PRODUCT); + if (uaa->vendor == USB_VENDOR_FALCOM && + (uaa->product == USB_PRODUCT_FALCOM_TWIST)) return (UMATCH_VENDOR_PRODUCT); @@ -290,6 +291,18 @@ goto bad; } break; + case USB_VENDOR_FALCOM: + switch( uaa->product ){ + case USB_PRODUCT_FALCOM_TWIST: + sc->sc_type = UFTDI_TYPE_8U232AM; + sc->sc_hdrlen = 0; + break; + + default: /* Can't happen */ + goto bad; + } + break; default: /* Can't happen */ goto bad; --- usbdevs.old 2010-11-01 14:03:28.000000000 +0100 +++ usbdevs 2010-11-01 14:03:45.000000000 +0100 @@ -488,7 +488,7 @@ vendor NOVATECH 0x0eb0 NovaTech vendor EGALAX 0x0eef eGalax vendor MICROTUNE 0x0f4d Microtune +vendor FALCOM 0x0f94 Falcom vendor VTECH 0x0f88 VTech vendor QUALCOMM2 0x1004 Qualcomm vendor GIGABYTE 0x1044 GIGABYTE @@ -1295,8 +1295,8 @@ /* Microtune, Inc. products */ product MICROTUNE BT_DONGLE 0x1000 Bluetooth USB dongle +/* Falcom products */ +product FALCOM TWIST 0x0001 USB GSM/GPRS modem /* Midiman products */ product MIDIMAN MIDISPORT2X2 0x1001 Midisport 2x2 >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 14:38:38 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id C5CAC1065698; Mon, 1 Nov 2010 14:38:38 +0000 (UTC) Date: Mon, 1 Nov 2010 14:38:38 +0000 From: Alexander Best To: Alexander Motin Message-ID: <20101101143838.GA64120@freebsd.org> References: <20101020153040.GA3184@freebsd.org> <201010201955.56816.hselasky@c2i.net> <4CC529CF.8000304@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC529CF.8000304@FreeBSD.org> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: serious issue caused by usb device, stalling almost all operations X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 14:38:38 -0000 On Mon Oct 25 10, Alexander Motin wrote: > Hans Petter Selasky wrote: > > On Wednesday 20 October 2010 17:30:40 Alexander Best wrote: > >> hi there, > >> > >> i'm running HEAD (r213495; amd64). i stumbled upon this severe problem: > >> > >> after attaching my mobile phone, it simply resets without doing mount or > >> anything. however after letting the device come up again it won't show up > >> in the console. after detaching it the usb subsystem seemed to have > >> completely crashed. but that's not all. the following programs now simply > >> hang without producing any output C-C won't do anything: > >> > >> - dmesg > >> - top > >> - ps > >> - killall > >> - camcontrol devlist > >> - usbconfig > > > > That's most likely because USB's umass driver is waiting for cam to drain. > > Possibly some refcounting is not correct. I suspect this is not a USB problem. > > Try to enter into the debugger, and look for backtrace for function stuck in > > umass_detach. i set debug.kdb.panic=1, but didn't work, because writing the core dump stalled and watchdog came up. any advice? cheers. alex > > It is a bit suspicious that problem happens only when device dies during > request. Are you sure that running command was properly aborted when > device got detached? Every running command has own set of references, > denying detach. > > -- > Alexander Motin -- a13x From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 18:51:31 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44D681065672; Mon, 1 Nov 2010 18:51:31 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9AFAC8FC1B; Mon, 1 Nov 2010 18:51:29 +0000 (UTC) Received: by fxm17 with SMTP id 17so5391103fxm.13 for ; Mon, 01 Nov 2010 11:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:organization :x-operation-sytem; bh=kPGQleNt08cezlDRjX11DSh6BrAxX/4bxkEXuAS9cLE=; b=yGY5eYAcIFTZFeHqoA/Nkghrzy9E+eAXQTraTzBDyHbubAFDkvMxovIkq+d56tga4m zZ4ww+o2PX0XQ83tn4/URG0Lc97EnCgIIB8fZn7cCvMabZndprNx08Adt/BBPuwPYr+j T12sTmgCJ8BGiUEf1BGb1VEpa8G1+agc2G3WI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :organization:x-operation-sytem; b=RFpfvhqHAhfKNSvzLbRVBhiFqrx0yBA8Mf37l8CoLE0Dq7bXkWPADatCXcyCFbaVS/ BpeXvW+Wnfi9vDG+mg78z1vBCyZK3DxdiqRPowZ4F40zcwsNEjiaUSPf/v9NBllLlVOh siF8iSglgL8/yeJExcgynIl+SrzbAhOPb8ooc= Received: by 10.223.86.2 with SMTP id q2mr3903987fal.53.1288637489226; Mon, 01 Nov 2010 11:51:29 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id a25sm2621769fab.37.2010.11.01.11.51.24 (version=SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 11:51:27 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Mon, 01 Nov 2010 11:51:22 -0700 From: Weongyo Jeong Date: Mon, 1 Nov 2010 11:51:22 -0700 To: Hans Petter Selasky Message-ID: <20101101185122.GE3918@weongyo> References: <20101031224304.GB3918@weongyo> <201011010930.26038.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011010930.26038.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-usb@freebsd.org Subject: Re: [CFR 2-3/n] removes uther dependency of axe(4) X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 18:51:31 -0000 On Mon, Nov 01, 2010 at 09:30:25AM +0100, Hans Petter Selasky wrote: > On Sunday 31 October 2010 23:43:04 Weongyo Jeong wrote: > > +static void > > +axe_watchdog(void *arg) > > +{ > > + struct axe_softc *sc = arg; > > + struct ifnet *ifp = sc->sc_ifp; > > + > > + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) > > + return; > > + > > Hi, > > Please explain what is wrong with the existing code regarding code > synchronisation. Your patch is very big and is likely to introduce problems. Hello Hans, I think your approach to synchronize the multiple tasks isn't bad though the implementation of approach isn't familiar with me comparing the other task queue implementations. It seems to me that it's a customized task queue implementation only for USB subsystem. > I oppose the introduction of SX-locks. Please explain why you think SX-locks > are better than the USB process taskqueue. I'd like to say that I also don't like SX locks that the reason is mentioned at CONTEXT section of sx(9) man page. I think using SX lock and the USB process taskqueue are both bad that if I could avoid using it, I'll willing to avoid it to use it. But the problem is that it's inevitable. I think we could choice one of two approaches that one is using SX lock other is using USB process taskqueue. The result of both would same, serialization. Regarding to the approach there'll be pros and cons: Pros of using SX lock: - Don't need to create extra thread. - Simple to read. Other developers could catch writer's intention easily. Cons of using SX lock: - Unexpecting sleep with holding mutex according to CONTEXT section of sx(9) man page. It should be used carefully. - Adds another lock to the driver. Pros of using USB process taksqueue: - Please fill. Cons of using USB process taskqueue: - No atomic operation that it need to be drained explicitly with sleeping that adds extra quirk code. - Tasks would be merged into one if the task is enqueued multiple times during pending that it means the writer takes care extra exceptions. It could lead to unexpected device behavior depending on device characteristics. - At least two threads are involved. One is caller thread other would be worker thread (USB process). It makes weak to race conditions. It always make code complex. > Are you absolutely sure that all the IOCTL's that are called are allowed to > block in the way you have programmed? Of course not because I'm a human. Human always do a mistake. :-) But there are few cases which need to be atomic in USB devices. For example, device up and down. It means sx(9) lock would be used very limited places only. > The checks in xxx_watchdog() are not good enough. axe_tick() will execute > synchronous USB functions, which sleep for many hundreds of microseconds. You > should add this check before the sleepout_reset() too, and is this code called > with any lock locked? I.E. Are you doing the clearing of IFF_DRV_RUNNING > atomic to testing this flag? Else the result can be random? Maybe xxx_watchdog() would be called with holding the driver lock so at least ifp->if_drv_flags would be protected. regards, Weongyo Jeong From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 19:22:45 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D9E11065670; Mon, 1 Nov 2010 19:22:45 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E4ECD8FC14; Mon, 1 Nov 2010 19:22:44 +0000 (UTC) Received: by fxm17 with SMTP id 17so5425343fxm.13 for ; Mon, 01 Nov 2010 12:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:organization :x-operation-sytem; bh=IujDf+I0f1rVO24HwT/82eVFHBm/Bd6DL9HF1G4md08=; b=ne5LXuBsgL/eEUHbw1MpI2jFIXJAvJBphesTxEjVm7RkDW7kTAILRyTN+WmvMHnLmO LPif2no5Y+oaQV76vptRZ7mnl0xt3RoJrfugmxSCdh9gjZ6qOMr3vmt/uUOw6JzrK1W5 VYD7JLcNwcCj0FLmBi+C+pdJND3Mj++QKr+mA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :organization:x-operation-sytem; b=UH+Lkn8mLKpWiP9SQpqGIUfsgxZR0nwt8w2uvYRF5MLQY/wACMK4zX/nOI15cbX7pr Q8A+r07pPUHrfCD9juSJEutGGZKvDKABWRcGxuuafuXPcGDZn/inx8lR2HlxJbJhaYBi pcpYyBvmB2CiSt5RWT1yjO++9kOmoq+q9swso= Received: by 10.223.96.74 with SMTP id g10mr4436279fan.84.1288639363813; Mon, 01 Nov 2010 12:22:43 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id c25sm2637463fac.9.2010.11.01.12.22.39 (version=SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 12:22:42 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Mon, 01 Nov 2010 12:22:37 -0700 From: Weongyo Jeong Date: Mon, 1 Nov 2010 12:22:37 -0700 To: Hans Petter Selasky Message-ID: <20101101192237.GF3918@weongyo> References: <20101030231901.GA83161@weongyo> <201010311509.49138.hselasky@c2i.net> <20101101020348.GD3918@weongyo> <201011010910.43121.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011010910.43121.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: freebsd-usb@freebsd.org Subject: Re: [CFR] add usb_sleepout.[ch] X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 19:22:45 -0000 On Mon, Nov 01, 2010 at 09:10:43AM +0100, Hans Petter Selasky wrote: > On Monday 01 November 2010 03:03:48 Weongyo Jeong wrote: > > On Sun, Oct 31, 2010 at 03:09:49PM +0100, Hans Petter Selasky wrote: > > > On Sunday 31 October 2010 01:19:01 Weongyo Jeong wrote: > > > > Hello USB guys, > > > > > > 1) All the sleepout_xxx() functions need mutex asserts. > > > > Hi, > > > It looks it don't need it because callout(9) does it instead of sleepout > > routines. Moreover sleepout don't create any mutexes in itself. > > Ok. > > > > > > 2) Is it allowed to call callout_stop() / callout_reset() unlocked at > > > all? > > > > Yes as long as it doesn't have side effects. It seems no drivers hold a > > lock to call callout_stop() / callout_reset(). > > All USB drivers do to ensure state coherency. > > > > > > What are the concequences if the mutex associated with the sleepout is > > > NULL ? > > > > I added KASSERT macro to check this case at below. However the sleepout > > pointer normally never be NULL because the intention of usage was as > > follows: > > > > struct _softc { > > struct sleepout sleepout; > > struct sleepout_task sleepout_task; > > }; > > > > sleepout_create(&sc->sleepout, "blah"); > > > > Only it could be happen if `struct sleepout' is allocated by > > dynamically though it's not my first purpose. > > > > > 3) As per the current implementation it can happen that the task'ed > > > timeout is called after that sleepout_stop() is used. The code should > > > have a check in the task function to see if the sleepout() has been > > > cancelled or not, when the mutex associated with the sleepout is locked. > > > > Yes it's true but it'd better to implement first taskqueue_stop() than > > adding it sleepout routines directly. However no plans yet because I > > couldn't imagine a side effect due to lack of this feature. Please let > > me know if I missed the something important. > > Maybe not when you are implementing a watchdog timer for ethernet, but then > you are limiting the use of those functions to USB ethernet only. The problem > happens when you are updating a state-machine in the callback and cannot trust > that a stop cancelled the sleepout. All existing USB functions are written > this way. I.E. no completion done callback after usbd_transfer_stop(). > > For example if your watchdog is calling if_start() somehow, and then you do an > if_down() which stops the watchdog, and then you can end up triggering the > if_start() after if_down(), which is incorrect. OK that it makes sense to me. I'll try to make a patch, taskqueue_stop(). > > > 4) Should the functions be prefixed by usb_ ? > > > > I don't have a preference for this. I think it's no problem to change > > it. It could happen soon. > > > > > 5) In drain you should drain the callout first, then drain the tasqueue. > > > Else the timer can trigger after the taskqueue is drained. > > Have you considered using the USB sub-systems taskqueue, instead of the kernel > one, so that jobs can be serialised among the two? Else you end up introducing > SX-locks in all drivers? Is that on purpose? As mentioned at the previous email. I prefer to use SX lock than taskqueue. Please refer my email which sent just minutes ago. > > It's fixed. Thank you for your review and the updated version is > > embedded at this email. regards, Weongyo Jeong From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 19:53:52 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 346EA106566C; Mon, 1 Nov 2010 19:53:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id E0B038FC19; Mon, 1 Nov 2010 19:53:50 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=ZJKxzO8xKrIA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=oRQRuTlL4tF4YFdG0KEA:9 a=ObUINUouHsCKj4En9vAA:7 a=Fy61cc9Geugf3KA_8aKYKOD7WEoA:4 a=CjuIK1q_8ugA:10 a=Bv938iqYfvFtlDwxFssA:9 a=uM761qN_FhgtPHaD6xMA:7 a=J3rm2JEZ12vxksrYZHk5wOmsnpoA:4 a=2oojFnQ6c6Waurg1:21 a=ZqU7GHg2O_BuwJCW:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42649858; Mon, 01 Nov 2010 20:53:48 +0100 From: Hans Petter Selasky To: Andrew Thompson Date: Mon, 1 Nov 2010 20:54:59 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_TsxzMdRyDrUyIHv" Message-Id: <201011012054.59551.hselasky@c2i.net> Cc: freebsd-arch@freebsd.org, freebsd-usb@freebsd.org, freebsd-current@freebsd.org, Weongyo Jeong Subject: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 19:53:52 -0000 --Boundary-00=_TsxzMdRyDrUyIHv Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi! I've wrapped up an outline patch for what needs to be done to integrate the USB process framework into the kernel taskqueue system in a more direct way that to wrap it. The limitation of the existing taskqueue system is that it only guarantees execution at a given priority level. USB requires more. USB also requires a guarantee that the last task queued task also gets executed last. This is for example so that a deferred USB detach event does not happen before any pending deferred I/O for example in case of multiple occurring events. Mostly this new feature is targeted for GPIO-alike system using slow busses like the USB. Typical use case: 2 tasks to program GPIO on. 2 tasks to program GPIO off. Example: a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- >sc_task_on[1]); b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- >sc_task_off[1]); No matter how the call ordering of code-line a) and b), we are always guaranteed that the last queued state "on" or "off" is reached before the head of the taskqueue empties. In lack of a better name, the new function was called taskqueue_enqueue_odd [some people obviously think that USB processes are odd, but not taskqueues :-)] Manpage: .Ft int .Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "struct task *t1" .. The function .Fn taskqueue_enqueue_odd should be used if it is important that the last queued task is also executed last in the task queue at the given priority level. This function requires two valid task pointers. Depending on which of the tasks passed are queued at the calling moment, the last queued task of the two will get dequeued and put last in the task queue, while not touching the first queued task. If no tasks are queued at the calling moment, this function behaves like .Fn taskqueue_enqueue . This function returns zero if the first task was queued last, one if the second task was queued last. Preliminary patch - see e-mail attachment. Comments are welcome! --HPS More docs: Also see talk about the new USB stack in FreeBSD on Youtube. --Boundary-00=_TsxzMdRyDrUyIHv Content-Type: text/plain; charset="us-ascii"; name="hps_taskqueue_patch_v001.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hps_taskqueue_patch_v001.txt" === share/man/man9/taskqueue.9 ================================================================== --- share/man/man9/taskqueue.9 (revision 214211) +++ share/man/man9/taskqueue.9 (local) @@ -46,11 +46,15 @@ typedef void (*taskqueue_enqueue_fn)(void *context); struct task { - STAILQ_ENTRY(task) ta_link; /* link for queue */ - u_short ta_pending; /* count times queued */ - u_short ta_priority; /* priority of task in queue */ - task_fn_t ta_func; /* task handler */ - void *ta_context; /* argument for handler */ + TAILQ_ENTRY(task) ta_link; /* link for queue */ +#define TASKQUEUE_SEQUENCE_MAX 255 + u_char ta_sequence; /* sequence number */ +#define TASKQUEUE_PENDING_MAX 255 + u_char ta_pending; /* count times queued */ +#define TASKQUEUE_PRIORITY_MAX 65535U + u_short ta_priority; /* priority of task in queue */ + task_fn_t *ta_func; /* task handler */ + void *ta_context; /* argument for handler */ }; .Ed .Ft struct taskqueue * @@ -62,6 +66,8 @@ .Ft int .Fn taskqueue_enqueue "struct taskqueue *queue" "struct task *task" .Ft int +.Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "struct task *t1" +.Ft int .Fn taskqueue_enqueue_fast "struct taskqueue *queue" "struct task *task" .Ft void .Fn taskqueue_drain "struct taskqueue *queue" "struct task *task" @@ -134,6 +140,19 @@ if the queue is being freed. .Pp The function +.Fn taskqueue_enqueue_odd +should be used if it is important that the last queued task is also +executed last in the task queue at the given priority level. This +function requires two valid task pointers. Depending on which of the +tasks passed are queued at the calling moment, the last queued task of +the two will get dequeued and put last in the task queue, while not +touching the first queued task. If no tasks are queued at the calling +moment, this function behaves like +.Fn taskqueue_enqueue . +This function returns zero if the first task was queued last, one if +the second task was queued last. +.Pp +The function .Fn taskqueue_enqueue_fast should be used in place of .Fn taskqueue_enqueue === sys/sys/_task.h ================================================================== --- sys/sys/_task.h (revision 214433) +++ sys/sys/_task.h (local) @@ -44,9 +44,13 @@ typedef void task_fn_t(void *context, int pending); struct task { - STAILQ_ENTRY(task) ta_link; /* (q) link for queue */ - u_short ta_pending; /* (q) count times queued */ - u_short ta_priority; /* (c) Priority */ + TAILQ_ENTRY(task) ta_link; /* (q) link for queue */ +#define TASKQUEUE_SEQUENCE_MAX 255U + u_char ta_sequence; /* (q) sequence number */ +#define TASKQUEUE_PENDING_MAX 255U + u_char ta_pending; /* (q) count times queued */ +#define TASKQUEUE_PRIORITY_MAX 65535U + u_short ta_priority; /* (c) priority of task in queue */ task_fn_t *ta_func; /* (c) task handler */ void *ta_context; /* (c) argument for handler */ }; === sys/sys/taskqueue.h ================================================================== --- sys/sys/taskqueue.h (revision 214433) +++ sys/sys/taskqueue.h (local) @@ -54,6 +54,7 @@ int taskqueue_start_threads(struct taskqueue **tqp, int count, int pri, const char *name, ...) __printflike(4, 5); int taskqueue_enqueue(struct taskqueue *queue, struct task *task); +int taskqueue_enqueue_odd(struct taskqueue *queue, struct task *t0, struct task *t1); void taskqueue_drain(struct taskqueue *queue, struct task *task); void taskqueue_free(struct taskqueue *queue); void taskqueue_run(struct taskqueue *queue); @@ -71,6 +72,7 @@ * Initialise a task structure. */ #define TASK_INIT(task, priority, func, context) do { \ + (task)->ta_link.tqe_prev = NULL; \ (task)->ta_pending = 0; \ (task)->ta_priority = (priority); \ (task)->ta_func = (func); \ === sys/kern/subr_taskqueue.c ================================================================== --- sys/kern/subr_taskqueue.c (revision 214433) +++ sys/kern/subr_taskqueue.c (local) @@ -52,7 +52,7 @@ }; struct taskqueue { - STAILQ_HEAD(, task) tq_queue; + TAILQ_HEAD(task_head, task) tq_queue; const char *tq_name; taskqueue_enqueue_fn tq_enqueue; void *tq_context; @@ -62,12 +62,15 @@ int tq_tcount; int tq_spin; int tq_flags; + u_char tq_sequence; }; #define TQ_FLAGS_ACTIVE (1 << 0) #define TQ_FLAGS_BLOCKED (1 << 1) #define TQ_FLAGS_PENDING (1 << 2) +static void taskqueue_enqueue_locked(struct taskqueue *, struct task *); + static __inline void TQ_LOCK(struct taskqueue *tq) { @@ -106,7 +109,7 @@ if (!queue) return NULL; - STAILQ_INIT(&queue->tq_queue); + TAILQ_INIT(&queue->tq_queue); TAILQ_INIT(&queue->tq_active); queue->tq_name = name; queue->tq_enqueue = enqueue; @@ -155,48 +158,132 @@ int taskqueue_enqueue(struct taskqueue *queue, struct task *task) { - struct task *ins; - struct task *prev; - TQ_LOCK(queue); /* * Count multiple enqueues. */ if (task->ta_pending) { - task->ta_pending++; + if (task->ta_pending != TASKQUEUE_PENDING_MAX) + task->ta_pending++; TQ_UNLOCK(queue); - return 0; + return (0); } + KASSERT(task->ta_link.tqe_prev == NULL, ("Task already queued?")); + + /* Insert task in queue */ + + taskqueue_enqueue_locked(queue, task); + + TQ_UNLOCK(queue); + + return (0); +} + +/* Enqueue task ordered and dualed */ + +int +taskqueue_enqueue_odd(struct taskqueue *queue, struct task *t0, struct task *t1) +{ + struct task *tx; + uint8_t t; + uint8_t d; + + TQ_LOCK(queue); + /* + * Compute a number based on which of the two tasks passed as + * arguments to this function are queued. + */ + t = 0; + if (t0->ta_link.tqe_prev != NULL) + t |= 1; + if (t1->ta_link.tqe_prev != NULL) + t |= 2; + + if (t == 0) { + /* + * No entries are queued. Queue task "t0" last and use + * the existing sequence number. + */ + tx = t0; + } else if (t == 1) { + /* + * Check if we need to increment the sequence number. + */ + if (t0->ta_sequence == queue->tq_sequence) + queue->tq_sequence++; + + tx = t1; + } else if (t == 2) { + /* + * Check if we need to increment the sequence number. + */ + if (t1->ta_sequence == queue->tq_sequence) + queue->tq_sequence++; + + tx = t0; + } else { + /* + * Both tasks are queued. Re-queue the task closest to + * the end which is computed by looking at the + * sequence number. + */ + d = (t1->ta_sequence - t0->ta_sequence); + + /* Check sign after subtraction */ + if (d & 0x80) + tx = t0; + else + tx = t1; + + TAILQ_REMOVE(&queue->tq_queue, tx, ta_link); + } + + /* Insert task in queue */ + + taskqueue_enqueue_locked(queue, tx); + + TQ_UNLOCK(queue); + + if (tx == t1) + return (1); + + return (0); +} + +static void +taskqueue_enqueue_locked(struct taskqueue *queue, struct task *task) +{ + struct task *ins; + struct task *prev; + + /* * Optimise the case when all tasks have the same priority. */ - prev = STAILQ_LAST(&queue->tq_queue, task, ta_link); + prev = TAILQ_LAST(&queue->tq_queue, task_head); if (!prev || prev->ta_priority >= task->ta_priority) { - STAILQ_INSERT_TAIL(&queue->tq_queue, task, ta_link); + TAILQ_INSERT_TAIL(&queue->tq_queue, task, ta_link); } else { prev = NULL; - for (ins = STAILQ_FIRST(&queue->tq_queue); ins; - prev = ins, ins = STAILQ_NEXT(ins, ta_link)) + for (ins = TAILQ_FIRST(&queue->tq_queue); ins; + prev = ins, ins = TAILQ_NEXT(ins, ta_link)) if (ins->ta_priority < task->ta_priority) break; if (prev) - STAILQ_INSERT_AFTER(&queue->tq_queue, prev, task, ta_link); + TAILQ_INSERT_AFTER(&queue->tq_queue, prev, task, ta_link); else - STAILQ_INSERT_HEAD(&queue->tq_queue, task, ta_link); + TAILQ_INSERT_HEAD(&queue->tq_queue, task, ta_link); } + task->ta_sequence = queue->tq_sequence; task->ta_pending = 1; if ((queue->tq_flags & TQ_FLAGS_BLOCKED) == 0) queue->tq_enqueue(queue->tq_context); else queue->tq_flags |= TQ_FLAGS_PENDING; - - TQ_UNLOCK(queue); - - return 0; } void @@ -232,13 +319,14 @@ tb.tb_running = NULL; TAILQ_INSERT_TAIL(&queue->tq_active, &tb, tb_link); - while (STAILQ_FIRST(&queue->tq_queue)) { + while ((task = TAILQ_FIRST(&queue->tq_queue)) != NULL) { /* - * Carefully remove the first task from the queue and - * zero its pending count. + * Carefully remove the first task from the queue, + * clear the previous next pointer and zero its + * pending count. */ - task = STAILQ_FIRST(&queue->tq_queue); - STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_link); + TAILQ_REMOVE(&queue->tq_queue, task, ta_link); + task->ta_link.tqe_prev = NULL; pending = task->ta_pending; task->ta_pending = 0; tb.tb_running = task; --Boundary-00=_TsxzMdRyDrUyIHv-- From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 20:07:55 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A0E01065703; Mon, 1 Nov 2010 20:07:55 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 8DC7A8FC1A; Mon, 1 Nov 2010 20:07:54 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=gl0LPzB4YDQuuzpDoHYit7deEV0cOo++Sg28kyvF6vg= c=1 sm=1 a=47Qj4_x6mI4A:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=-OUsx_i8YlbCSPlRq5wA:9 a=Y4ltlOA5M-v0C9s5x8gA:7 a=XpTxSsOgxbl0scfWVmEU7cVyhkUA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 43009492; Mon, 01 Nov 2010 21:07:52 +0100 From: Hans Petter Selasky To: Weongyo Jeong Date: Mon, 1 Nov 2010 21:09:03 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20101031224304.GB3918@weongyo> <201011010930.26038.hselasky@c2i.net> <20101101185122.GE3918@weongyo> In-Reply-To: <20101101185122.GE3918@weongyo> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011012109.04021.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: [CFR 2-3/n] removes uther dependency of axe(4) X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 20:07:55 -0000 On Monday 01 November 2010 19:51:22 Weongyo Jeong wrote: > On Mon, Nov 01, 2010 at 09:30:25AM +0100, Hans Petter Selasky wrote: > > On Sunday 31 October 2010 23:43:04 Weongyo Jeong wrote: > > > > Hi, > > > > Please explain what is wrong with the existing code regarding code > > synchronisation. Your patch is very big and is likely to introduce > > problems. > > Hello Hans, Hi Weongyo, > > I think your approach to synchronize the multiple tasks isn't bad though > the implementation of approach isn't familiar with me comparing the > other task queue implementations. It seems to me that it's a customized > task queue implementation only for USB subsystem. Yes. I'm going to change that now, so that we get all the benefits of the taskqueue system. Please see other e-mail posted today. > > I oppose the introduction of SX-locks. Please explain why you think > > SX-locks are better than the USB process taskqueue. > > I'd like to say that I also don't like SX locks that the reason is > mentioned at CONTEXT section of sx(9) man page. > > I think using SX lock and the USB process taskqueue are both bad that if > I could avoid using it, I'll willing to avoid it to use it. But the > problem is that it's inevitable. I think we could choice one of two > approaches that one is using SX lock other is using USB process > taskqueue. The result of both would same, serialization. > > Regarding to the approach there'll be pros and cons: > > Pros of using SX lock: > - Don't need to create extra thread. > - Simple to read. Other developers could catch writer's intention > easily. > > Cons of using SX lock: > - Unexpecting sleep with holding mutex according to CONTEXT section > of sx(9) man page. It should be used carefully. > - Adds another lock to the driver. > > Pros of using USB process taksqueue: The USB process taskqueue is a temporary solution until the taskqueue system is updated to support the "USB requirements". Are kernel taskqueues any better than USB process'es? > Cons of using USB process taskqueue: > - No atomic operation that it need to be drained explicitly with > sleeping that adds extra quirk code. > - Tasks would be merged into one if the task is enqueued multiple > times during pending that it means the writer takes care extra > exceptions. It could lead to unexpected device behavior depending > on device characteristics. > - At least two threads are involved. One is caller thread other > would be worker thread (USB process). It makes weak to race > conditions. It always make code complex. > > > Are you absolutely sure that all the IOCTL's that are called are allowed > > to block in the way you have programmed? > > Of course not because I'm a human. Human always do a mistake. :-) But > there are few cases which need to be atomic in USB devices. For > example, device up and down. It means sx(9) lock would be used very > limited places only. Ok. My intention was not to completely tear apart your patches :-) What I can say is that I've tried to keep all corner cases tight, and maybe it's not directly obvious to everyone how everything is working inside the USB stack like you write. Sometimes I even forget all of the small things I've fixed, and then it takes some time until I remember and can point out to you exactly why. If a USB task/process gets stuck (starts having USB timeouts), then it's easier to recover than if we are using a SX lock. Because if we are using an SX lock, the caller can get stuck for a substantial amount of time, whilst if we do it via task queue, we have the possibility to recover from the USB explore thread which runs the detach of the USB device. > > The checks in xxx_watchdog() are not good enough. axe_tick() will execute > > synchronous USB functions, which sleep for many hundreds of microseconds. > > You should add this check before the sleepout_reset() too, and is this > > code called with any lock locked? I.E. Are you doing the clearing of > > IFF_DRV_RUNNING atomic to testing this flag? Else the result can be > > random? > > Maybe xxx_watchdog() would be called with holding the driver lock so > at least ifp->if_drv_flags would be protected. That's also a solution. --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 20:14:06 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D296106564A; Mon, 1 Nov 2010 20:14:06 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA7F8FC1F; Mon, 1 Nov 2010 20:14:05 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=fSevNTtoN4QgcqRp2OYA:9 a=stlMNjSOas5fGyG6P3UA:7 a=6G91sS9h5Cx9rxYMxB0z_FDb4doA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42657199; Mon, 01 Nov 2010 21:14:04 +0100 From: Hans Petter Selasky To: Matthew Fleming Date: Mon, 1 Nov 2010 21:15:15 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011012115.15261.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 20:14:06 -0000 On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky wrote: > > Hi! > > > > I've wrapped up an outline patch for what needs to be done to integrate > > the USB process framework into the kernel taskqueue system in a more > > direct way that to wrap it. > > > > The limitation of the existing taskqueue system is that it only > > guarantees execution at a given priority level. USB requires more. USB > > also requires a guarantee that the last task queued task also gets > > executed last. This is for example so that a deferred USB detach event > > does not happen before any pending deferred I/O for example in case of > > multiple occurring events. > > > > Mostly this new feature is targeted for GPIO-alike system using slow > > busses like the USB. Typical use case: > > > > 2 tasks to program GPIO on. > > 2 tasks to program GPIO off. > > > > Example: > > > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > > > >>sc_task_on[1]); > >> > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > > > >>sc_task_off[1]); > >> > > No matter how the call ordering of code-line a) and b), we are always > > guaranteed that the last queued state "on" or "off" is reached before the > > head of the taskqueue empties. > > > > > > In lack of a better name, the new function was called > > taskqueue_enqueue_odd [some people obviously think that USB processes > > are odd, but not taskqueues > > > > :-)] > > I'd like to make sure I understand the USB requirements. > > (1) does USB need the task priority field? Many taskqueue(9) consumers do > not. No, USB does not need a task priority field, but a sequence field associated with the task and task queue head to figure out which task was queued first without having to scan all the tasks queued. > (2) if there was a working taskqueue_remove(9) that removed the task > if pending or returned error if the task was currently running, would > that be sufficient to implement the required USB functionality? > (assuming that taskqueue_enqueue(9) put all tasks with equal priority > in order of queueing). No, not completely. See comment above. I also need information about which task was queued first, or else I have to keep this information separately, which again, confuse people. The more layers the more confusion? --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 20:39:00 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E97A1065670; Mon, 1 Nov 2010 20:39:00 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C9BA48FC1C; Mon, 1 Nov 2010 20:38:59 +0000 (UTC) Received: by iwn39 with SMTP id 39so7508248iwn.13 for ; Mon, 01 Nov 2010 13:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RWRcEYFem6yf3fFJORN9++0ZAcVpKD8bEdU3c+Br+K0=; b=nYzGF19PZHbdY+6HSGUtgeRe15B//XOSLLcRdlApiCEsfJDl804+TwBLyLFdoS3565 bIr7IkDd6DL6e6Y23BDHqLfx6hclDaqfm8mAQKsod3osYKL2lsfipRU+antc2F23hu5U JvVUWLMMAjFiHE6vZtY1BCaXoq5t1ZlFuJx0Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FgzmYJefrCOF1QzDICxSxu1Ir7bgCDwQO1m0ULj6dYR3JNFbNqr+3mcKzt/01yg6Ch xi6P56kzYuLvAR5VkxZXSdd69O4odBl5dQnRpwfrr88GJcxZs1CjtYZdz/eN39tOlom5 8W+2qmZrQ8mgws3IO4FHcDHwMuhVEU756za4k= MIME-Version: 1.0 Received: by 10.231.36.11 with SMTP id r11mr3331721ibd.58.1288642049448; Mon, 01 Nov 2010 13:07:29 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Mon, 1 Nov 2010 13:07:29 -0700 (PDT) In-Reply-To: <201011012054.59551.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> Date: Mon, 1 Nov 2010 13:07:29 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 20:39:00 -0000 On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky wro= te: > Hi! > > I've wrapped up an outline patch for what needs to be done to integrate t= he > USB process framework into the kernel taskqueue system in a more direct w= ay > that to wrap it. > > The limitation of the existing taskqueue system is that it only guarantee= s > execution at a given priority level. USB requires more. USB also requires= a > guarantee that the last task queued task also gets executed last. This is= for > example so that a deferred USB detach event does not happen before any pe= nding > deferred I/O for example in case of multiple occurring events. > > Mostly this new feature is targeted for GPIO-alike system using slow buss= es > like the USB. Typical use case: > > 2 tasks to program GPIO on. > 2 tasks to program GPIO off. > > Example: > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- >>sc_task_on[1]); > > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- >>sc_task_off[1]); > > > No matter how the call ordering of code-line a) and b), we are always > guaranteed that the last queued state "on" or "off" is reached before the= head > of the taskqueue empties. > > > In lack of a better name, the new function was called taskqueue_enqueue_o= dd > [some people obviously think that USB processes are odd, but not taskqueu= es > :-)] I'd like to make sure I understand the USB requirements. (1) does USB need the task priority field? Many taskqueue(9) consumers do = not. (2) if there was a working taskqueue_remove(9) that removed the task if pending or returned error if the task was currently running, would that be sufficient to implement the required USB functionality? (assuming that taskqueue_enqueue(9) put all tasks with equal priority in order of queueing). Thanks, matthew > Manpage: > > .Ft int > .Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "st= ruct > task *t1" > > .. > > The function > .Fn taskqueue_enqueue_odd > should be used if it is important that the last queued task is also > executed last in the task queue at the given priority level. This > function requires two valid task pointers. Depending on which of the > tasks passed are queued at the calling moment, the last queued task of > the two will get dequeued and put last in the task queue, while not > touching the first queued task. If no tasks are queued at the calling > moment, this function behaves like > .Fn taskqueue_enqueue . > This function returns zero if the first task was queued last, one if > the second task was queued last. > > Preliminary patch - see e-mail attachment. > > Comments are welcome! > > --HPS > > More docs: Also see talk about the new USB stack in FreeBSD on Youtube. > > =3D=3D=3D share/man/man9/taskqueue.9 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- share/man/man9/taskqueue.9 =A0(revision 214211) > +++ share/man/man9/taskqueue.9 =A0(local) > @@ -46,11 +46,15 @@ > =A0typedef void (*taskqueue_enqueue_fn)(void *context); > > =A0struct task { > - =A0 =A0 =A0 STAILQ_ENTRY(task) =A0 =A0 =A0ta_link; =A0 =A0 =A0 =A0/* li= nk for queue */ > - =A0 =A0 =A0 u_short =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ta_pending; =A0 =A0= /* count times queued */ > - =A0 =A0 =A0 u_short =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ta_priority; =A0 = =A0/* priority of task in queue */ > - =A0 =A0 =A0 task_fn_t =A0 =A0 =A0 =A0 =A0 =A0 =A0 ta_func; =A0 =A0 =A0 = =A0/* task handler */ > - =A0 =A0 =A0 void =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*ta_context; = =A0 =A0/* argument for handler */ > + =A0 =A0 =A0 TAILQ_ENTRY(task) ta_link; =A0 =A0 =A0/* link for queue */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_SEQUENCE_MAX =A0255 > + =A0 =A0 =A0 u_char =A0ta_sequence; =A0 =A0 =A0 =A0 =A0 =A0/* sequence n= umber */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_PENDING_MAX =A0 255 > + =A0 =A0 =A0 u_char =A0ta_pending; =A0 =A0 =A0 =A0 =A0 =A0 /* count time= s queued */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_PRIORITY_MAX =A065535U > + =A0 =A0 =A0 u_short ta_priority; =A0 =A0 =A0 =A0 =A0 =A0/* priority of = task in queue */ > + =A0 =A0 =A0 task_fn_t *ta_func; =A0 =A0 =A0 =A0 =A0 =A0 /* task handler= */ > + =A0 =A0 =A0 void =A0 =A0*ta_context; =A0 =A0 =A0 =A0 =A0 =A0/* argument= for handler */ > =A0}; > =A0.Ed > =A0.Ft struct taskqueue * > @@ -62,6 +66,8 @@ > =A0.Ft int > =A0.Fn taskqueue_enqueue "struct taskqueue *queue" "struct task *task" > =A0.Ft int > +.Fn taskqueue_enqueue_odd "struct taskqueue *queue" "struct task *t0" "s= truct task *t1" > +.Ft int > =A0.Fn taskqueue_enqueue_fast "struct taskqueue *queue" "struct task *tas= k" > =A0.Ft void > =A0.Fn taskqueue_drain "struct taskqueue *queue" "struct task *task" > @@ -134,6 +140,19 @@ > =A0if the queue is being freed. > =A0.Pp > =A0The function > +.Fn taskqueue_enqueue_odd > +should be used if it is important that the last queued task is also > +executed last in the task queue at the given priority level. This > +function requires two valid task pointers. Depending on which of the > +tasks passed are queued at the calling moment, the last queued task of > +the two will get dequeued and put last in the task queue, while not > +touching the first queued task. If no tasks are queued at the calling > +moment, this function behaves like > +.Fn taskqueue_enqueue . > +This function returns zero if the first task was queued last, one if > +the second task was queued last. > +.Pp > +The function > =A0.Fn taskqueue_enqueue_fast > =A0should be used in place of > =A0.Fn taskqueue_enqueue > =3D=3D=3D sys/sys/_task.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/sys/_task.h =A0 =A0 (revision 214433) > +++ sys/sys/_task.h =A0 =A0 (local) > @@ -44,9 +44,13 @@ > =A0typedef void task_fn_t(void *context, int pending); > > =A0struct task { > - =A0 =A0 =A0 STAILQ_ENTRY(task) ta_link; =A0 =A0 /* (q) link for queue *= / > - =A0 =A0 =A0 u_short ta_pending; =A0 =A0 =A0 =A0 =A0 =A0 /* (q) count ti= mes queued */ > - =A0 =A0 =A0 u_short ta_priority; =A0 =A0 =A0 =A0 =A0 =A0/* (c) Priority= */ > + =A0 =A0 =A0 TAILQ_ENTRY(task) ta_link; =A0 =A0 =A0/* (q) link for queue= */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_SEQUENCE_MAX =A0255U > + =A0 =A0 =A0 u_char =A0ta_sequence; =A0 =A0 =A0 =A0 =A0 =A0/* (q) sequen= ce number */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_PENDING_MAX =A0 255U > + =A0 =A0 =A0 u_char =A0ta_pending; =A0 =A0 =A0 =A0 =A0 =A0 /* (q) count = times queued */ > +#define =A0 =A0 =A0 =A0TASKQUEUE_PRIORITY_MAX =A065535U > + =A0 =A0 =A0 u_short ta_priority; =A0 =A0 =A0 =A0 =A0 =A0/* (c) priority= of task in queue */ > =A0 =A0 =A0 =A0task_fn_t *ta_func; =A0 =A0 =A0 =A0 =A0 =A0 /* (c) task ha= ndler */ > =A0 =A0 =A0 =A0void =A0 =A0*ta_context; =A0 =A0 =A0 =A0 =A0 =A0/* (c) arg= ument for handler */ > =A0}; > =3D=3D=3D sys/sys/taskqueue.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/sys/taskqueue.h (revision 214433) > +++ sys/sys/taskqueue.h (local) > @@ -54,6 +54,7 @@ > =A0int =A0 =A0taskqueue_start_threads(struct taskqueue **tqp, int count, = int pri, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const char= *name, ...) __printflike(4, 5); > =A0int =A0 =A0taskqueue_enqueue(struct taskqueue *queue, struct task *tas= k); > +int =A0 =A0taskqueue_enqueue_odd(struct taskqueue *queue, struct task *t= 0, struct task *t1); > =A0void =A0 taskqueue_drain(struct taskqueue *queue, struct task *task); > =A0void =A0 taskqueue_free(struct taskqueue *queue); > =A0void =A0 taskqueue_run(struct taskqueue *queue); > @@ -71,6 +72,7 @@ > =A0* Initialise a task structure. > =A0*/ > =A0#define TASK_INIT(task, priority, func, context) do { =A0\ > + =A0 =A0 =A0 (task)->ta_link.tqe_prev =3D NULL; =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0\ > =A0 =A0 =A0 =A0(task)->ta_pending =3D 0; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ > =A0 =A0 =A0 =A0(task)->ta_priority =3D (priority); =A0 =A0 =A0 =A0 =A0 = =A0 =A0 \ > =A0 =A0 =A0 =A0(task)->ta_func =3D (func); =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 \ > =3D=3D=3D sys/kern/subr_taskqueue.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/subr_taskqueue.c =A0 (revision 214433) > +++ sys/kern/subr_taskqueue.c =A0 (local) > @@ -52,7 +52,7 @@ > =A0}; > > =A0struct taskqueue { > - =A0 =A0 =A0 STAILQ_HEAD(, task) =A0 =A0 tq_queue; > + =A0 =A0 =A0 TAILQ_HEAD(task_head, task) =A0 =A0 tq_queue; > =A0 =A0 =A0 =A0const char =A0 =A0 =A0 =A0 =A0 =A0 =A0*tq_name; > =A0 =A0 =A0 =A0taskqueue_enqueue_fn =A0 =A0tq_enqueue; > =A0 =A0 =A0 =A0void =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*tq_context; > @@ -62,12 +62,15 @@ > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tq_tcount; > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tq_spin; > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tq_flags; > + =A0 =A0 =A0 u_char =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tq_sequence; > =A0}; > > =A0#define =A0 =A0 =A0 =A0TQ_FLAGS_ACTIVE =A0 =A0 =A0 =A0 (1 << 0) > =A0#define =A0 =A0 =A0 =A0TQ_FLAGS_BLOCKED =A0 =A0 =A0 =A0(1 << 1) > =A0#define =A0 =A0 =A0 =A0TQ_FLAGS_PENDING =A0 =A0 =A0 =A0(1 << 2) > > +static void taskqueue_enqueue_locked(struct taskqueue *, struct task *); > + > =A0static __inline void > =A0TQ_LOCK(struct taskqueue *tq) > =A0{ > @@ -106,7 +109,7 @@ > =A0 =A0 =A0 =A0if (!queue) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NULL; > > - =A0 =A0 =A0 STAILQ_INIT(&queue->tq_queue); > + =A0 =A0 =A0 TAILQ_INIT(&queue->tq_queue); > =A0 =A0 =A0 =A0TAILQ_INIT(&queue->tq_active); > =A0 =A0 =A0 =A0queue->tq_name =3D name; > =A0 =A0 =A0 =A0queue->tq_enqueue =3D enqueue; > @@ -155,48 +158,132 @@ > =A0int > =A0taskqueue_enqueue(struct taskqueue *queue, struct task *task) > =A0{ > - =A0 =A0 =A0 struct task *ins; > - =A0 =A0 =A0 struct task *prev; > - > =A0 =A0 =A0 =A0TQ_LOCK(queue); > > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * Count multiple enqueues. > =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0if (task->ta_pending) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending++; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (task->ta_pending !=3D TASKQUEUE_PENDING= _MAX) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending++; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TQ_UNLOCK(queue); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (0); > =A0 =A0 =A0 =A0} > > + =A0 =A0 =A0 KASSERT(task->ta_link.tqe_prev =3D=3D NULL, ("Task already = queued?")); > + > + =A0 =A0 =A0 /* Insert task in queue */ > + > + =A0 =A0 =A0 taskqueue_enqueue_locked(queue, task); > + > + =A0 =A0 =A0 TQ_UNLOCK(queue); > + > + =A0 =A0 =A0 return (0); > +} > + > +/* Enqueue task ordered and dualed */ > + > +int > +taskqueue_enqueue_odd(struct taskqueue *queue, struct task *t0, struct t= ask *t1) > +{ > + =A0 =A0 =A0 struct task *tx; > + =A0 =A0 =A0 uint8_t t; > + =A0 =A0 =A0 uint8_t d; > + > + =A0 =A0 =A0 TQ_LOCK(queue); > + > =A0 =A0 =A0 =A0/* > + =A0 =A0 =A0 =A0* Compute a number based on which of the two tasks passe= d as > + =A0 =A0 =A0 =A0* arguments to this function are queued. > + =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 t =3D 0; > + =A0 =A0 =A0 if (t0->ta_link.tqe_prev !=3D NULL) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 t |=3D 1; > + =A0 =A0 =A0 if (t1->ta_link.tqe_prev !=3D NULL) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 t |=3D 2; > + > + =A0 =A0 =A0 if (t =3D=3D 0) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* No entries are queued. Queue task "t0"= last and use > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the existing sequence number. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t0; > + =A0 =A0 =A0 } else if (t =3D=3D 1) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Check if we need to increment the sequ= ence number. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (t0->ta_sequence =3D=3D queue->tq_sequen= ce) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 queue->tq_sequence++; > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t1; > + =A0 =A0 =A0 } else if (t =3D=3D 2) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Check if we need to increment the sequ= ence number. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (t1->ta_sequence =3D=3D queue->tq_sequen= ce) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 queue->tq_sequence++; > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t0; > + =A0 =A0 =A0 } else { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Both tasks are queued. Re-queue the ta= sk closest to > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the end which is computed by looking a= t the > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* sequence number. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 d =3D (t1->ta_sequence - t0->ta_sequence); > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Check sign after subtraction */ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (d & 0x80) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx =3D t1; > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_REMOVE(&queue->tq_queue, tx, ta_link)= ; > + =A0 =A0 =A0 } > + > + =A0 =A0 =A0 /* Insert task in queue */ > + > + =A0 =A0 =A0 taskqueue_enqueue_locked(queue, tx); > + > + =A0 =A0 =A0 TQ_UNLOCK(queue); > + > + =A0 =A0 =A0 if (tx =3D=3D t1) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (1); > + > + =A0 =A0 =A0 return (0); > +} > + > +static void > +taskqueue_enqueue_locked(struct taskqueue *queue, struct task *task) > +{ > + =A0 =A0 =A0 struct task *ins; > + =A0 =A0 =A0 struct task *prev; > + > + =A0 =A0 =A0 /* > =A0 =A0 =A0 =A0 * Optimise the case when all tasks have the same priority= . > =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 prev =3D STAILQ_LAST(&queue->tq_queue, task, ta_link); > + =A0 =A0 =A0 prev =3D TAILQ_LAST(&queue->tq_queue, task_head); > =A0 =A0 =A0 =A0if (!prev || prev->ta_priority >=3D task->ta_priority) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_INSERT_TAIL(&queue->tq_queue, task, = ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_INSERT_TAIL(&queue->tq_queue, task, t= a_link); > =A0 =A0 =A0 =A0} else { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prev =3D NULL; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (ins =3D STAILQ_FIRST(&queue->tq_queue)= ; ins; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prev =3D ins, ins =3D STAILQ_NEX= T(ins, ta_link)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 for (ins =3D TAILQ_FIRST(&queue->tq_queue);= ins; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prev =3D ins, ins =3D TAILQ_NEXT= (ins, ta_link)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (ins->ta_priority < tas= k->ta_priority) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (prev) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_INSERT_AFTER(&queue-= >tq_queue, prev, task, ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_INSERT_AFTER(&queue->= tq_queue, prev, task, ta_link); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_INSERT_HEAD(&queue->= tq_queue, task, ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_INSERT_HEAD(&queue->t= q_queue, task, ta_link); > =A0 =A0 =A0 =A0} > > + =A0 =A0 =A0 task->ta_sequence =3D queue->tq_sequence; > =A0 =A0 =A0 =A0task->ta_pending =3D 1; > =A0 =A0 =A0 =A0if ((queue->tq_flags & TQ_FLAGS_BLOCKED) =3D=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0queue->tq_enqueue(queue->tq_context); > =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0queue->tq_flags |=3D TQ_FLAGS_PENDING; > - > - =A0 =A0 =A0 TQ_UNLOCK(queue); > - > - =A0 =A0 =A0 return 0; > =A0} > > =A0void > @@ -232,13 +319,14 @@ > =A0 =A0 =A0 =A0tb.tb_running =3D NULL; > =A0 =A0 =A0 =A0TAILQ_INSERT_TAIL(&queue->tq_active, &tb, tb_link); > > - =A0 =A0 =A0 while (STAILQ_FIRST(&queue->tq_queue)) { > + =A0 =A0 =A0 while ((task =3D TAILQ_FIRST(&queue->tq_queue)) !=3D NULL) = { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Carefully remove the first task from t= he queue and > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* zero its pending count. > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Carefully remove the first task from t= he queue, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* clear the previous next pointer and ze= ro its > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* pending count. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 task =3D STAILQ_FIRST(&queue->tq_queue); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_lin= k); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 TAILQ_REMOVE(&queue->tq_queue, task, ta_lin= k); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_link.tqe_prev =3D NULL; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pending =3D task->ta_pending; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0task->ta_pending =3D 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tb.tb_running =3D task; > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 21:25:41 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 823C61065673; Mon, 1 Nov 2010 21:25:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4E99E8FC13; Mon, 1 Nov 2010 21:25:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D174246B85; Mon, 1 Nov 2010 17:25:40 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B40998A009; Mon, 1 Nov 2010 17:25:35 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 1 Nov 2010 17:14:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> In-Reply-To: <201011012054.59551.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011011714.50121.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 01 Nov 2010 17:25:35 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 21:25:41 -0000 On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote: > Hi! > > I've wrapped up an outline patch for what needs to be done to integrate the > USB process framework into the kernel taskqueue system in a more direct way > that to wrap it. > > The limitation of the existing taskqueue system is that it only guarantees > execution at a given priority level. USB requires more. USB also requires a > guarantee that the last task queued task also gets executed last. This is for > example so that a deferred USB detach event does not happen before any pending > deferred I/O for example in case of multiple occurring events. > > Mostly this new feature is targeted for GPIO-alike system using slow busses > like the USB. Typical use case: > > 2 tasks to program GPIO on. > 2 tasks to program GPIO off. > > Example: > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > >sc_task_on[1]); > > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > >sc_task_off[1]); > > > No matter how the call ordering of code-line a) and b), we are always > guaranteed that the last queued state "on" or "off" is reached before the head > of the taskqueue empties. > > > In lack of a better name, the new function was called taskqueue_enqueue_odd > [some people obviously think that USB processes are odd, but not taskqueues > :-)] It feels like this should be something you could manage with a state machine internal to USB rather than forcing that state into the taskqueue code itself. If you wanted a simple barrier task (where a barrier task is always queued at the tail of the list and all subsequent tasks are queued after the barrier task) then I would be fine with adding that. You could manage this without having to alter the task KBI by having the taskqueue maintain a separate pointer to the current "barrier" task and always enqueue entries after that task (the barrier would be NULL before a barrier is queued, and set to NULL when a barrier executes). I think this sort of semantic is a bit simpler and also used in other parts of the tree (e.g. in bio queues). -- John Baldwin From owner-freebsd-usb@FreeBSD.ORG Mon Nov 1 21:59:26 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97FD61065672 for ; Mon, 1 Nov 2010 21:59:26 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 28F4F8FC1A for ; Mon, 1 Nov 2010 21:59:25 +0000 (UTC) Received: by bwz3 with SMTP id 3so5081447bwz.13 for ; Mon, 01 Nov 2010 14:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=AlUNczdvyEd/MKs8oSDrkzBGj4fMDOgu/2t89+P0VXg=; b=mujQG2rgVHLfMc3nXJCnQzSUeMoSZOaVsnlyiNbEOEC4E98LV4urNE1cO4Gx4KI0j6 Krr5sHQsloKuuYEQu5IvddinjnQra1AYYUo6ojjwuYgKP8vNgP99LuZUUuC0EsZC59N7 j3I/BgxmsqrJpcCyyikHX7i2WZQyjP44+VzpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fJvGmGi5N7o15M/mSiqOq+9GIVfA1H1pFzmJBrJYLwl6GKOJF7MqQ3N9oomkPInjI+ gleqAw5NmZPb5eJEvNRyillBOtSngRVhwAj0hd7XR/UDvy0rytxMCSRTjJuY1u82Ge6j 77ad2ub+KObPHZuZTC48wCQ6prPcfXi+E3Og0= MIME-Version: 1.0 Received: by 10.204.113.196 with SMTP id b4mr4204784bkq.176.1288647066138; Mon, 01 Nov 2010 14:31:06 -0700 (PDT) Received: by 10.204.142.133 with HTTP; Mon, 1 Nov 2010 14:31:06 -0700 (PDT) Date: Tue, 2 Nov 2010 00:31:06 +0300 Message-ID: From: Alexander Churanov To: freebsd-usb@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: USB camera not detected by 8.1, was working in 7 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 21:59:26 -0000 Hi folks! My USB camera is not detected by FreeBSD 8.1. In 7.1 it was working flawlessly. In my case even no /dev/da* device is created. Google does not provide answers, since people mainly discuss inability to work with /dev/da* which is absent on my system. In 7.1 the "da" device and slice "da0s1" were created automatically. Is it possible to make it working as before? /var/log/messages: Nov 2 00:14:12 homebsd root: Unknown USB device: vendor 0x054c product 0x0010 bus uhub3 Nov 2 00:14:12 homebsd kernel: ugen3.2: at usbus3 Nov 2 00:14:12 homebsd kernel: umass0: on usbus3 Nov 2 00:14:23 homebsd kernel: (probe0:umass-sim0:0:0:0): AutoSense failed Output of some commands: homebsd > sudo camcontrol devlist at scbus2 target 0 lun 0 (pass0,cd0) at scbus2 target 1 lun 0 (pass1,cd1) homebsd > sudo camcontrol reset all Reset of bus 0 returned error 0x6 Reset of bus 1 was successful Reset of bus 2 was successful Reset of bus 3 returned error 0x3a homebsd > sudo camcontrol rescan all Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful homebsd > sudo camcontrol devlist -v scbus0 on sbp0 bus 0: <> at scbus0 target -1 lun -1 () scbus1 on ata0 bus 0: <> at scbus1 target -1 lun -1 () scbus2 on ata1 bus 0: at scbus2 target 0 lun 0 (pass0,cd0) at scbus2 target 1 lun 0 (pass1,cd1) <> at scbus2 target -1 lun -1 () scbus3 on umass-sim0 bus 0: scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun -1 (xpt0) Alexander Churanov From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 07:29:22 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E9AD106564A for ; Tue, 2 Nov 2010 07:29:22 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 2B48A8FC0C for ; Tue, 2 Nov 2010 07:29:21 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=3qpjzGKB6kwA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=iHbxvNv3OI5aUJjQaV4A:9 a=VCzFNUATVvSKqL9Br9sA:7 a=R9AmBIoygbZc48GASbVJEzB9Mm4A:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42803401; Tue, 02 Nov 2010 08:29:20 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Tue, 2 Nov 2010 08:30:31 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011020830.31701.hselasky@c2i.net> Cc: Alexander Churanov Subject: Re: USB camera not detected by 8.1, was working in 7 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 07:29:22 -0000 On Monday 01 November 2010 22:31:06 Alexander Churanov wrote: > Hi folks! > > My USB camera is not detected by FreeBSD 8.1. In 7.1 it was working > flawlessly. In my case even no /dev/da* device is created. Google does not > provide answers, since people mainly discuss inability to work with > /dev/da* which is absent on my system. > > In 7.1 the "da" device and slice "da0s1" were created automatically. > Is it possible to make it working as before? > > /var/log/messages: > > Nov 2 00:14:12 homebsd root: Unknown USB device: vendor 0x054c > product 0x0010 bus uhub3 > Nov 2 00:14:12 homebsd kernel: ugen3.2: at usbus3 > Nov 2 00:14:12 homebsd kernel: umass0: 2.00/6.00, addr 2> on usbus3 > Nov 2 00:14:23 homebsd kernel: (probe0:umass-sim0:0:0:0): AutoSense failed > > Output of some commands: > > homebsd > sudo camcontrol devlist > at scbus2 target 0 lun 0 (pass0,cd0) > at scbus2 target 1 lun 0 (pass1,cd1) > > homebsd > sudo camcontrol reset all > Reset of bus 0 returned error 0x6 > Reset of bus 1 was successful > Reset of bus 2 was successful > Reset of bus 3 returned error 0x3a > > homebsd > sudo camcontrol rescan all > Re-scan of bus 0 was successful > Re-scan of bus 1 was successful > Re-scan of bus 2 was successful > Re-scan of bus 3 was successful > > homebsd > sudo camcontrol devlist -v > scbus0 on sbp0 bus 0: > <> at scbus0 target -1 lun -1 () > scbus1 on ata0 bus 0: > <> at scbus1 target -1 lun -1 () > scbus2 on ata1 bus 0: > at scbus2 target 0 lun 0 (pass0,cd0) > at scbus2 target 1 lun 0 (pass1,cd1) > <> at scbus2 target -1 lun -1 () > scbus3 on umass-sim0 bus 0: > scbus-1 on xpt0 bus 0: > <> at scbus-1 target -1 lun -1 (xpt0) > Maybe a SCSI issue. Does not look USB related. --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 07:38:37 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4C79106564A; Tue, 2 Nov 2010 07:38:37 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 816238FC18; Tue, 2 Nov 2010 07:38:35 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=gl0LPzB4YDQuuzpDoHYit7deEV0cOo++Sg28kyvF6vg= c=1 sm=1 a=FberXtVRn-wA:10 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=WktskUVpHMbtOkM2tRUA:9 a=1nZNbYgAICjbbIhLnOsA:7 a=fXf6KUqNvkir4ELthc67aDRHUWIA:4 a=PUjeQqilurYA:10 a=QLp5_XDAv1VEkvBO:21 a=9dnm0tSLCu5UgOgx:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 43160988; Tue, 02 Nov 2010 08:38:34 +0100 From: Hans Petter Selasky To: John Baldwin Date: Tue, 2 Nov 2010 08:39:45 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011011714.50121.jhb@freebsd.org> In-Reply-To: <201011011714.50121.jhb@freebsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011020839.45839.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 07:38:37 -0000 On Monday 01 November 2010 22:14:49 John Baldwin wrote: > On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote: > > Hi! > > > > I've wrapped up an outline patch for what needs to be done to integrate > > the USB process framework into the kernel taskqueue system in a more > > direct way that to wrap it. > > > > The limitation of the existing taskqueue system is that it only > > guarantees execution at a given priority level. USB requires more. USB > > also requires a guarantee that the last task queued task also gets > > executed last. This is for example so that a deferred USB detach event > > does not happen before any pending deferred I/O for example in case of > > multiple occurring events. > > > > Mostly this new feature is targeted for GPIO-alike system using slow > > busses like the USB. Typical use case: > > > > 2 tasks to program GPIO on. > > 2 tasks to program GPIO off. > > > > Example: > > > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > > > > >sc_task_on[1]); > > > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > > > > >sc_task_off[1]); > > > > No matter how the call ordering of code-line a) and b), we are always > > guaranteed that the last queued state "on" or "off" is reached before the > > head of the taskqueue empties. > > > > > > In lack of a better name, the new function was called > > taskqueue_enqueue_odd [some people obviously think that USB processes > > are odd, but not taskqueues > > > > :-)] > > It feels like this should be something you could manage with a state > machine internal to USB rather than forcing that state into the taskqueue > code itself. Hi John, No, this is not possible without keeping my own queue, which I want to avoid. By state-machine you mean remembering the last state as a separate variable and checking that in the task-callback, right? Yes, I do that in addition to the new queuing mechanism. A task barrier does not solve my problem. The barrier in my case is always last in the queue. I need to pull out previously queued tasks and put them last. That is currently not supported. I do this because I don't want to have a FIFO signalling model, and a neither want the pure taskqueue, which only ensures execution, not order of execution when at the same priority. Another issue: Won't the barrier model lead to blocking the caller once the task in question is being issued the second time? --HPS > If you wanted a simple barrier task (where a barrier task is > always queued at the tail of the list and all subsequent tasks are queued > after the barrier task) then I would be fine with adding that. You could > manage this without having to alter the task KBI by having the taskqueue > maintain a separate pointer to the current "barrier" task and always > enqueue entries after that task (the barrier would be NULL before a > barrier is queued, and set to NULL when a barrier executes). > > I think this sort of semantic is a bit simpler and also used in other parts > of the tree (e.g. in bio queues). From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 07:42:52 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADD75106566C; Tue, 2 Nov 2010 07:42:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id B1BA18FC0C; Tue, 2 Nov 2010 07:42:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=88e7-T71Oz4A:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=2gous0I8H8juMTWfAzwA:9 a=5tgEV1_38apm88RSqo-W6wGdNakA:4 a=wPNLvfGTeEIA:10 a=ntJSdXeiMXs7de4o:21 a=wlr35HWB0y9YUtxd:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42884173; Tue, 02 Nov 2010 08:42:49 +0100 From: Hans Petter Selasky To: Alexander Best Date: Tue, 2 Nov 2010 08:44:00 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20101020153040.GA3184@freebsd.org> <4CC529CF.8000304@FreeBSD.org> <20101101143838.GA64120@freebsd.org> In-Reply-To: <20101101143838.GA64120@freebsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011020844.00600.hselasky@c2i.net> Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: serious issue caused by usb device, stalling almost all operations X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 07:42:52 -0000 On Monday 01 November 2010 15:38:38 Alexander Best wrote: > On Mon Oct 25 10, Alexander Motin wrote: > > Hans Petter Selasky wrote: > > > On Wednesday 20 October 2010 17:30:40 Alexander Best wrote: > > >> hi there, > > >> > > >> i'm running HEAD (r213495; amd64). i stumbled upon this severe > > >> problem: > > >> > > >> after attaching my mobile phone, it simply resets without doing mount > > >> or anything. however after letting the device come up again it won't > > >> show up in the console. after detaching it the usb subsystem seemed > > >> to have completely crashed. but that's not all. the following > > >> programs now simply hang without producing any output C-C won't do > > >> anything: > > >> > > >> - dmesg > > >> - top > > >> - ps > > >> - killall > > >> - camcontrol devlist > > >> - usbconfig > > > > > > That's most likely because USB's umass driver is waiting for cam to > > > drain. Possibly some refcounting is not correct. I suspect this is not > > > a USB problem. Try to enter into the debugger, and look for backtrace > > > for function stuck in umass_detach. > > i set debug.kdb.panic=1, but didn't work, because writing the core dump > stalled and watchdog came up. > Maybe you could manually run: bt all And look for "cam" and "usb" keywords. And write down the backtraces. --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 09:32:20 2010 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07C8A106566C for ; Tue, 2 Nov 2010 09:32:20 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 921038FC1F for ; Tue, 2 Nov 2010 09:32:19 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3A76A.dip.t-dialin.net [87.179.167.106]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 57F2684400D; Tue, 2 Nov 2010 10:32:14 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id E4CF71445; Tue, 2 Nov 2010 10:32:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1288690331; bh=vFQez4rS7PtbiYUyf1mLArh6qMStlNsEwjzgqUuSzVw=; h=Message-ID:Date:From:To:Cc:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=BMgSn9wGK4Kyw0IBozceziolxIYjfdetHxnyLKHz6duWdh0ZUjPxJu3ohqz7Je2At sjXuHpjtYUdAaO/pKL+Smjmd1qsO6BtVdWFNR/eSdKCPv+IioSCUdpYlQ7fJKgXz+y bwuplye9R2/xQXwOEmEG16uCGDCtORlS6NbVJajSHCEZK/eV9/Gxy4H7BkWpVkrBwN gJ+77gV++c1LPc3Ss+2vOwBbY042PI8hGcLgDZiaXjsixp7SikG67KnDdq1u4cMNw9 ye4LFwiBc2tl5kD4va6V00vV5+tqsBUlI7VjQoMyugkQf+oL3rFwtF92JuSNjpvzTQ +ZvPh/k+RO/PQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id oA29W9XL049222; Tue, 2 Nov 2010 10:32:09 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 02 Nov 2010 10:32:08 +0100 Message-ID: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> Date: Tue, 02 Nov 2010 10:32:08 +0100 From: Alexander Leidinger To: hselasky@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 57F2684400D.A6B82 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.854, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, J_CHICKENPOX_24 0.60, J_CHICKENPOX_32 0.60, J_CHICKENPOX_34 0.60, TW_UH 0.08, TW_XD 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1289295136.5941@lxqlIL+89hGk2onDU84AuQ X-EBL-Spam-Status: No Cc: usb@FreeBSD.org Subject: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 09:32:20 -0000 Hi, I have a memory stick which made problems (the stick is used as a ZFS cache and it moaned about 8xxM write problems) in 9-current r214509. I removed the device from the config, made a camcontrol reset all, camcontrol rescan all (-> device disappeared), and then tried an usbconfig reset ugen4.2 (relevant devlist part from before the call is below). The usbconfig reset does not return to the shell. I do not know if the problem with the USB memory stick is related to software or hardware. The stick survived just a weekend, I replaced it because the old one showed similar problems after surviving about 9 months... I updated -current just before the problems appeared (and then again after a week or two), but I do not remember from which revision of -current I was updating from. I will try to stress-test the memory sticks on a 8.1 system so see if it is some software problem. The big question I have for now is: shouldn't there be some kind of safety mechanism kicking in (timeout) with the usbconfig command (in this case the reset)? devlist: ---snip--- ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.2: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ---snip--- dmesg | grep -i usb: ---snip--- uhci0: port 0xdc00-0xdc1f irq 16 at device 29.0 on pci0 usbus0: on uhci0 uhci1: port 0xe000-0xe01f irq 19 at device 29.1 on pci0 usbus1: on uhci1 uhci2: port 0xe400-0xe41f irq 18 at device 29.2 on pci0 usbus2: on uhci2 uhci3: port 0xe800-0xe81f irq 16 at device 29.3 on pci0 usbus3: on uhci3 ehci0: mem 0xfe77fc00-0xfe77ffff irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4: on ehci0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 ugen4.2: at usbus4 umass0: on usbus4 Root mount waiting for: usbus4 pass3: Removable Direct Access SCSI-2 device da0: Removable Direct Access SCSI-2 device Root mount waiting for: usbus4 ugen1.2: at usbus1 ugen1.3: at usbus1 ulpt0: on usbus1 ugen2.2: at usbus2 uhub5: on usbus2 ugen2.3: at usbus2 ukbd0: on usbus2 ugen2.4: at usbus2 ums0: on usbus2 ---snip--- Bye, Alexander. -- The man who laughs has not yet been told the terrible news. -- Bertolt Brecht http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 09:35:32 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F17A7106566C; Tue, 2 Nov 2010 09:35:32 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 472F88FC18; Tue, 2 Nov 2010 09:35:31 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=9Utm1XU4gQEA:10 a=IkcTkHD0fZMA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=r3OI_ZcuDD6Hs32bSUgA:9 a=mHAyTAbXdDP7xdlc1W3ElQd-i3MA:4 a=QEXdDO2ut3YA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 42949311; Tue, 02 Nov 2010 10:35:30 +0100 Received-SPF: softfail receiver=mailfe05.swip.net; client-ip=188.126.198.129; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-usb@freebsd.org, Alexander Motin Date: Tue, 2 Nov 2010 10:36:41 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> In-Reply-To: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201011021036.41617.hselasky@freebsd.org> Cc: Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 09:35:33 -0000 On Tuesday 02 November 2010 10:32:08 Alexander Leidinger wrote: > Hi, > > I have a memory stick which made problems (the stick is used as a ZFS > cache and it moaned about 8xxM write problems) in 9-current r214509. I > removed the device from the config, made a camcontrol reset all, > camcontrol rescan all (-> device disappeared), and then tried an > usbconfig reset ugen4.2 (relevant devlist part from before the call is > below). The usbconfig reset does not return to the shell. > > I do not know if the problem with the USB memory stick is related to > software or hardware. The stick survived just a weekend, I replaced it > because the old one showed similar problems after surviving about 9 > months... I updated -current just before the problems appeared (and > then again after a week or two), but I do not remember from which > revision of -current I was updating from. I will try to stress-test > the memory sticks on a 8.1 system so see if it is some software problem. > > The big question I have for now is: shouldn't there be some kind of > safety mechanism kicking in (timeout) with the usbconfig command (in > this case the reset)? > > devlist: > ---snip--- > ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=SAVE > ugen4.2: at usbus4, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON > ---snip--- > > dmesg | grep -i usb: > ---snip--- > uhci0: port 0xdc00-0xdc1f > irq 16 at device 29.0 on pci0 > usbus0: on uhci0 > uhci1: port 0xe000-0xe01f > irq 19 at device 29.1 on pci0 > usbus1: on uhci1 > uhci2: port 0xe400-0xe41f > irq 18 at device 29.2 on pci0 > usbus2: on uhci2 > uhci3: port 0xe800-0xe81f > irq 16 at device 29.3 on pci0 > usbus3: on uhci3 > ehci0: mem > 0xfe77fc00-0xfe77ffff irq 23 at device 29.7 on pci0 > usbus4: EHCI version 1.0 > usbus4: on ehci0 > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 12Mbps Full Speed USB v1.0 > usbus4: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ugen4.1: at usbus4 > uhub4: on usbus4 > Root mount waiting for: usbus4 > Root mount waiting for: usbus4 > Root mount waiting for: usbus4 > Root mount waiting for: usbus4 > ugen4.2: at usbus4 > umass0: on usbus4 > Root mount waiting for: usbus4 > pass3: Removable Direct Access SCSI-2 device > da0: Removable Direct Access SCSI-2 device > Root mount waiting for: usbus4 > ugen1.2: at usbus1 > ugen1.3: at usbus1 > ulpt0: 3> on usbus1 > ugen2.2: at usbus2 > uhub5: addr 2> on usbus2 > ugen2.3: at usbus2 > ukbd0: addr 3> on usbus2 > ugen2.4: at usbus2 > ums0: addr 4> on usbus2 > ---snip--- Hi, If you dump all threads in this state I think you will see that USB is waiting somewhere in umass_detach(), which is preventing the usbconfig reset from grabbing the SX-lock associated with serialisation. Because umass_detach() is not returning we are stuck. --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 10:01:44 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0EA4106564A; Tue, 2 Nov 2010 10:01:44 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 575858FC13; Tue, 2 Nov 2010 10:01:44 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3A76A.dip.t-dialin.net [87.179.167.106]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id DBFE484400D; Tue, 2 Nov 2010 11:01:40 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id BC9FC144A; Tue, 2 Nov 2010 11:01:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1288692097; bh=CvQW7b80P98MMlY/PgwI+SeXDvRY+0dNH4l7JwhJkpk=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=d19eHTWV9Kz8mX/WqIF63du1L1tts5xJ6jGe8Dtb42cjRa+pywpDJBW7nTjkzJxYt ZvMumOVk7ltOdLYGDoMyhcwQqDF3zeBdkV/yktgfXA/Yv14MWJJXSaaAB0qKoETy1n KSD5YB2AdRhBimTYqKGIsZMd9xkkg0SOvdAxYYnRoZM2bVWG8O6Wp4g2TPrJD4W/Lb BbkZ7/68/ccxIuiZ/MEsWYOUSud5DduNiOusTw+meh0u5LPrtHjTCIVrFlT6t7bZkp j0s9Sl+m4KnYz4F9OiNSc5B/RJ0joSFNQvj5y0OnQeXP+24GXS9WF+ewohOVmftwjz 8cxqGxY18KsbA== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id oA2A1a54056232; Tue, 2 Nov 2010 11:01:36 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 02 Nov 2010 11:01:34 +0100 Message-ID: <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> Date: Tue, 02 Nov 2010 11:01:34 +0100 From: Alexander Leidinger To: Hans Petter Selasky References: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> <201011021036.41617.hselasky@freebsd.org> In-Reply-To: <201011021036.41617.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: DBFE484400D.A6C28 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.854, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, J_CHICKENPOX_24 0.60, J_CHICKENPOX_32 0.60, J_CHICKENPOX_34 0.60, TW_UH 0.08, TW_XD 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1289296901.91698@U+eXD96+huxJ8aK+glXuLA X-EBL-Spam-Status: No Cc: Alexander Motin , freebsd-usb@freebsd.org Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 10:01:44 -0000 Quoting Hans Petter Selasky (from Tue, 2 Nov 2010 10:36:41 +0100): > On Tuesday 02 November 2010 10:32:08 Alexander Leidinger wrote: >> Hi, >> >> I have a memory stick which made problems (the stick is used as a ZFS >> cache and it moaned about 8xxM write problems) in 9-current r214509. I >> removed the device from the config, made a camcontrol reset all, >> camcontrol rescan all (-> device disappeared), and then tried an >> usbconfig reset ugen4.2 (relevant devlist part from before the call is >> below). The usbconfig reset does not return to the shell. >> >> I do not know if the problem with the USB memory stick is related to >> software or hardware. The stick survived just a weekend, I replaced it >> because the old one showed similar problems after surviving about 9 >> months... I updated -current just before the problems appeared (and >> then again after a week or two), but I do not remember from which >> revision of -current I was updating from. I will try to stress-test >> the memory sticks on a 8.1 system so see if it is some software problem. >> >> The big question I have for now is: shouldn't there be some kind of >> safety mechanism kicking in (timeout) with the usbconfig command (in >> this case the reset)? >> >> devlist: >> ---snip--- >> ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=SAVE >> ugen4.2: at usbus4, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=ON >> ---snip--- >> >> dmesg | grep -i usb: >> ---snip--- >> uhci0: port 0xdc00-0xdc1f >> irq 16 at device 29.0 on pci0 >> usbus0: on uhci0 >> uhci1: port 0xe000-0xe01f >> irq 19 at device 29.1 on pci0 >> usbus1: on uhci1 >> uhci2: port 0xe400-0xe41f >> irq 18 at device 29.2 on pci0 >> usbus2: on uhci2 >> uhci3: port 0xe800-0xe81f >> irq 16 at device 29.3 on pci0 >> usbus3: on uhci3 >> ehci0: mem >> 0xfe77fc00-0xfe77ffff irq 23 at device 29.7 on pci0 >> usbus4: EHCI version 1.0 >> usbus4: on ehci0 >> usbus0: 12Mbps Full Speed USB v1.0 >> usbus1: 12Mbps Full Speed USB v1.0 >> usbus2: 12Mbps Full Speed USB v1.0 >> usbus3: 12Mbps Full Speed USB v1.0 >> usbus4: 480Mbps High Speed USB v2.0 >> ugen0.1: at usbus0 >> uhub0: on usbus0 >> ugen1.1: at usbus1 >> uhub1: on usbus1 >> ugen2.1: at usbus2 >> uhub2: on usbus2 >> ugen3.1: at usbus3 >> uhub3: on usbus3 >> ugen4.1: at usbus4 >> uhub4: on usbus4 >> Root mount waiting for: usbus4 >> Root mount waiting for: usbus4 >> Root mount waiting for: usbus4 >> Root mount waiting for: usbus4 >> ugen4.2: at usbus4 >> umass0: on usbus4 >> Root mount waiting for: usbus4 >> pass3: Removable Direct Access SCSI-2 device >> da0: Removable Direct Access SCSI-2 device >> Root mount waiting for: usbus4 >> ugen1.2: at usbus1 >> ugen1.3: at usbus1 >> ulpt0: > 3> on usbus1 >> ugen2.2: at usbus2 >> uhub5: > addr 2> on usbus2 >> ugen2.3: at usbus2 >> ukbd0: > addr 3> on usbus2 >> ugen2.4: at usbus2 >> ums0: > addr 4> on usbus2 >> ---snip--- > > Hi, > > If you dump all threads in this state I think you will see that USB > is waiting # procstat -kk 29213 PID TID COMM TDNAME KSTACK 29213 100291 usbconfig - mi_switch+0x188 sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30 usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21 > somewhere in umass_detach(), which is preventing the usbconfig reset from No umass_detach in there... > grabbing the SX-lock associated with serialisation. Because umass_detach() is > not returning we are stuck. And there is no way to use some kind of timeout for cases which cause problem reports (like umass_detach() and maybe this one)? I could imagine several possibilities: usbconfig tries a trylock first (maybe several times) and if it does not succeed in a specified timeperiode, it returns an error. Adidtionally there is maybe the possibility to determine if a command did not finish in a given timeperiode and print out a warning message (syslog) to have an indication, that somthing is not in a good condition. Bye, Alexander. -- I hate small towns because once you've seen the cannon in the park there's nothing else to do. -- Lenny Bruce http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 11:02:32 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 657AA106566B; Tue, 2 Nov 2010 11:02:32 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD3888FC12; Tue, 2 Nov 2010 11:02:31 +0000 (UTC) Received: by bwz3 with SMTP id 3so5481779bwz.13 for ; Tue, 02 Nov 2010 04:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=p1ulE2eYysFcEgbVLHl6lJPkw35PwlBGbT+e2n+dtGw=; b=u7EOugjTqE7gnepAfO4RkZUpTGC7349ydOjse5ZkoMvk6Ft8bZ54DE1IbkFkLCIULW 3Adl982RWDMzA9KdWQwgRZo2YndTe2a6DLrFdOX1bSv4ubP4EKzLCqrwCTxsW4mrkJat SkZ2bY4HEymQ9xL31j8I5fhovSFPOmymPzcBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=WPxC+epSl1y+NVED1CIK+RNakt+8UvfY/wyLvfLHw4awSvD92EP1pfKH1svSh2shuU ymrldXeFi+Yq9Wb+MrocD/pjJMCV1mdzDE451N/rqC0BAbZqhZWwFS4I8OsFouoV4dIc aYNybJzxTCXnvfSPivhcKHKHUBVSZdNdglaBA= Received: by 10.204.123.14 with SMTP id n14mr3735955bkr.33.1288695750699; Tue, 02 Nov 2010 04:02:30 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f21sm4440319bkf.12.2010.11.02.04.02.28 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Nov 2010 04:02:29 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CCFFDC9.1040002@FreeBSD.org> Date: Tue, 02 Nov 2010 14:02:17 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Leidinger References: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> <201011021036.41617.hselasky@freebsd.org> <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> In-Reply-To: <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Hans Petter Selasky , freebsd-usb@freebsd.org Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 11:02:32 -0000 Alexander Leidinger wrote: > > Quoting Hans Petter Selasky (from Tue, 2 Nov 2010 > 10:36:41 +0100): > >> On Tuesday 02 November 2010 10:32:08 Alexander Leidinger wrote: >>> Hi, >>> >>> I have a memory stick which made problems (the stick is used as a ZFS >>> cache and it moaned about 8xxM write problems) in 9-current r214509. I >>> removed the device from the config, made a camcontrol reset all, >>> camcontrol rescan all (-> device disappeared), and then tried an >>> usbconfig reset ugen4.2 (relevant devlist part from before the call is >>> below). The usbconfig reset does not return to the shell. >>> >>> I do not know if the problem with the USB memory stick is related to >>> software or hardware. The stick survived just a weekend, I replaced it >>> because the old one showed similar problems after surviving about 9 >>> months... I updated -current just before the problems appeared (and >>> then again after a week or two), but I do not remember from which >>> revision of -current I was updating from. I will try to stress-test >>> the memory sticks on a 8.1 system so see if it is some software problem. >>> >>> The big question I have for now is: shouldn't there be some kind of >>> safety mechanism kicking in (timeout) with the usbconfig command (in >>> this case the reset)? >>> >>> devlist: >>> ---snip--- >>> ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH >>> (480Mbps) pwr=SAVE >>> ugen4.2: at usbus4, cfg=0 md=HOST spd=HIGH >>> (480Mbps) pwr=ON >>> ---snip--- >>> >>> dmesg | grep -i usb: >>> ---snip--- >>> uhci0: port 0xdc00-0xdc1f >>> irq 16 at device 29.0 on pci0 >>> usbus0: on uhci0 >>> uhci1: port 0xe000-0xe01f >>> irq 19 at device 29.1 on pci0 >>> usbus1: on uhci1 >>> uhci2: port 0xe400-0xe41f >>> irq 18 at device 29.2 on pci0 >>> usbus2: on uhci2 >>> uhci3: port 0xe800-0xe81f >>> irq 16 at device 29.3 on pci0 >>> usbus3: on uhci3 >>> ehci0: mem >>> 0xfe77fc00-0xfe77ffff irq 23 at device 29.7 on pci0 >>> usbus4: EHCI version 1.0 >>> usbus4: on ehci0 >>> usbus0: 12Mbps Full Speed USB v1.0 >>> usbus1: 12Mbps Full Speed USB v1.0 >>> usbus2: 12Mbps Full Speed USB v1.0 >>> usbus3: 12Mbps Full Speed USB v1.0 >>> usbus4: 480Mbps High Speed USB v2.0 >>> ugen0.1: at usbus0 >>> uhub0: on usbus0 >>> ugen1.1: at usbus1 >>> uhub1: on usbus1 >>> ugen2.1: at usbus2 >>> uhub2: on usbus2 >>> ugen3.1: at usbus3 >>> uhub3: on usbus3 >>> ugen4.1: at usbus4 >>> uhub4: on usbus4 >>> Root mount waiting for: usbus4 >>> Root mount waiting for: usbus4 >>> Root mount waiting for: usbus4 >>> Root mount waiting for: usbus4 >>> ugen4.2: at usbus4 >>> umass0: on usbus4 >>> Root mount waiting for: usbus4 >>> pass3: Removable Direct Access SCSI-2 device >>> da0: Removable Direct Access SCSI-2 device >>> Root mount waiting for: usbus4 >>> ugen1.2: at usbus1 >>> ugen1.3: at usbus1 >>> ulpt0: >> 3> on usbus1 >>> ugen2.2: at usbus2 >>> uhub5: >> addr 2> on usbus2 >>> ugen2.3: at usbus2 >>> ukbd0: >> addr 3> on usbus2 >>> ugen2.4: at usbus2 >>> ums0: >> addr 4> on usbus2 >>> ---snip--- >> >> Hi, >> >> If you dump all threads in this state I think you will see that USB is >> waiting > > # procstat -kk 29213 > PID TID COMM TDNAME KSTACK > 29213 100291 usbconfig - mi_switch+0x188 > sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30 > usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d > ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21 > >> somewhere in umass_detach(), which is preventing the usbconfig reset from > > No umass_detach in there... umass_detach() (if there) should be in some other thread. >> grabbing the SX-lock associated with serialisation. Because >> umass_detach() is >> not returning we are stuck. > > And there is no way to use some kind of timeout for cases which cause > problem reports (like umass_detach() and maybe this one)? I could > imagine several possibilities: usbconfig tries a trylock first (maybe > several times) and if it does not succeed in a specified timeperiode, it > returns an error. Adidtionally there is maybe the possibility to > determine if a command did not finish in a given timeperiode and print > out a warning message (syslog) to have an indication, that somthing is > not in a good condition. Not sure what should it give. We should track the real problem, not the consequences. Possible reason could be that due to some error umass/CAM leaked some references, which made impossible to destroy CAM bus on stick disconnection. But to diagnose it we need much more info. -- Alexander Motin From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 11:24:20 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B34101065672; Tue, 2 Nov 2010 11:24:20 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 43ADD8FC1B; Tue, 2 Nov 2010 11:24:20 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3A76A.dip.t-dialin.net [87.179.167.106]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 1785984400D; Tue, 2 Nov 2010 12:24:17 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id BB1421453; Tue, 2 Nov 2010 12:24:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1288697053; bh=cxY4IIbBWTqZoFYjrpSMLobAmCwiR4CPs5aPtvt8akk=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=n+03Rv354v/mhXJ2GrToAHta/FwWLcgdxGuTa2ZuPm9C4nlJktbkm/+pcGVgmunPS /AKSEyzuCxwl0252f4B0fglu/Pcz2KfJP+zMF3AInLy/dLn18vqF1HSo57XkdrcAMb Q5m8I5/JrgV4OWwzAYdvua2WLF9WP7xfmG7gTo9pr3weLaZ6HBf/vIneAK1J+nFksO HUE5Yke3qToYZl9VoeqOnmKef0PGi15JjRqkQGDORhC7dHHFTx5AJL2KdN/OND2AKJ GNrcDUtaO7eGZ6wvZEmmm3MS00LzwIW7O8ChP35vj5GdXLPAVAAN3f/7w21KU76U22 4ghVKqeo8u4hA== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id oA2BOCwl075270; Tue, 2 Nov 2010 12:24:12 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 02 Nov 2010 12:24:10 +0100 Message-ID: <20101102122410.1227532bno09pfs4@webmail.leidinger.net> Date: Tue, 02 Nov 2010 12:24:10 +0100 From: Alexander Leidinger To: Alexander Motin References: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> <201011021036.41617.hselasky@freebsd.org> <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> <4CCFFDC9.1040002@FreeBSD.org> In-Reply-To: <4CCFFDC9.1040002@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 1785984400D.A7625 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.423, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, J_CHICKENPOX_45 0.60, TW_KD 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1289301857.70195@AVjC6746S8QygavbYjEHBg X-EBL-Spam-Status: No Cc: Hans Petter Selasky , freebsd-usb@FreeBSD.org Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 11:24:20 -0000 Quoting Alexander Motin (from Tue, 02 Nov 2010 14:02:17 +0200): > Alexander Leidinger wrote: >> >> Quoting Hans Petter Selasky (from Tue, 2 Nov 2010 >> 10:36:41 +0100): >>> If you dump all threads in this state I think you will see that USB is >>> waiting >> >> # procstat -kk 29213 >> PID TID COMM TDNAME KSTACK >> 29213 100291 usbconfig - mi_switch+0x188 >> sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30 >> usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d >> ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21 >> >>> somewhere in umass_detach(), which is preventing the usbconfig reset from >> >> No umass_detach in there... > > umass_detach() (if there) should be in some other thread. Not here: ---snip--- # procstat -kka | grep umass_detach ---snip--- >>> grabbing the SX-lock associated with serialisation. Because >>> umass_detach() is >>> not returning we are stuck. >> >> And there is no way to use some kind of timeout for cases which cause >> problem reports (like umass_detach() and maybe this one)? I could >> imagine several possibilities: usbconfig tries a trylock first (maybe >> several times) and if it does not succeed in a specified timeperiode, it >> returns an error. Adidtionally there is maybe the possibility to >> determine if a command did not finish in a given timeperiode and print >> out a warning message (syslog) to have an indication, that somthing is >> not in a good condition. > > Not sure what should it give. We should track the real problem, not the > consequences. Possible reason could be that due to some error umass/CAM > leaked some references, which made impossible to destroy CAM bus on > stick disconnection. But to diagnose it we need much more info. Something I could provide? Some kdb magic I could copy&paste? Bye, Alexander. -- Phosflink, v.: To flick a bulb on and off when it burns out (as if, somehow, that will bring it back to life). -- Rich Hall & Friends, "Sniglets" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 11:59:46 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 037C31065670; Tue, 2 Nov 2010 11:59:46 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 4E8A38FC15; Tue, 2 Nov 2010 11:59:44 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=9Utm1XU4gQEA:10 a=N659UExz7-8A:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=z9iG9sBOvv9S0LpHKkUA:9 a=dG-8SKSPQY573DP5lDDb8xp0f_oA:4 a=pILNOxqGKmIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 43390745; Tue, 02 Nov 2010 12:59:43 +0100 Received-SPF: softfail receiver=mailfe07.swip.net; client-ip=188.126.198.129; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: Alexander Leidinger Date: Tue, 2 Nov 2010 13:00:54 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011021036.41617.hselasky@freebsd.org> <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> In-Reply-To: <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201011021300.54515.hselasky@freebsd.org> Cc: Alexander Motin , "freebsd-usb@freebsd.org" Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 11:59:46 -0000 On Tuesday 02 November 2010 11:01:34 Alexander Leidinger wrote: > # procstat -kk 29213 > PID TID COMM TDNAME KSTACK > 29213 100291 usbconfig - mi_switch+0x188 > sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30 > usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d > ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21 > > > somewhere in umass_detach(), which is preventing the usbconfig reset from > > No umass_detach in there... Hi, The USB threads are joined into a single process and not visible from "ps". Not sure how you can get a list of all threads. You need to enter GDB or run GDB on /dev/mem and dump all threads there and look for USB and umass keywords. --HPS From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 12:14:16 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A96491065672; Tue, 2 Nov 2010 12:14:16 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4E99A8FC0C; Tue, 2 Nov 2010 12:14:16 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3A76A.dip.t-dialin.net [87.179.167.106]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 7AE8284400D; Tue, 2 Nov 2010 13:14:11 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 46A7F1459; Tue, 2 Nov 2010 13:14:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1288700048; bh=JxEF3kM5GOenqj6KHOKT3tZQtHqxuHxBapSpbo7rcDI=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ALDN9ppCsy+LMg5kdPjFbmcI/WryJYRmWgv+FI/PELsmuZpnqga0yJAjG+C60t+dB J1ZNYCLZaq639rHJKa/4eZiMNg4ywcnRaKcZQbfK9s8xjF179Rg/RODvhAAq5SwtKF bqelzubv7cIx294ogrKyesnGmTW/GgP92voeve2gSc/ec5uV2ts7qIf78CDm9BdfJ5 bNxeEJwj9Nx0pLk09BOFOiDgY5bWCoescmFNOStj8+hbBTwwX6xGLCvP4osTwtGHIY sXUQCSs3PnX6AILLsY1mCv7sU27MPXcyUdG3biKPDwhxhIJ3ftd5pR/cyTz0W88GIl L3XY/6uLybG8Q== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id oA2CE6CU086588; Tue, 2 Nov 2010 13:14:06 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 02 Nov 2010 13:14:05 +0100 Message-ID: <20101102131405.16163bkjh6ny62kg@webmail.leidinger.net> Date: Tue, 02 Nov 2010 13:14:05 +0100 From: Alexander Leidinger To: Hans Petter Selasky References: <201011021036.41617.hselasky@freebsd.org> <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> <201011021300.54515.hselasky@freebsd.org> In-Reply-To: <201011021300.54515.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 7AE8284400D.A393E X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1289304853.99964@PY97U5p37t2bIQgtTkTgqA X-EBL-Spam-Status: No Cc: Alexander Motin , "freebsd-usb@freebsd.org" Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 12:14:16 -0000 Quoting Hans Petter Selasky (from Tue, 2 Nov 2010 13:00:54 +0100): > On Tuesday 02 November 2010 11:01:34 Alexander Leidinger wrote: >> # procstat -kk 29213 >> PID TID COMM TDNAME KSTACK >> 29213 100291 usbconfig - mi_switch+0x188 >> sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30 >> usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d >> ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21 >> >> > somewhere in umass_detach(), which is preventing the usbconfig reset from >> >> No umass_detach in there... > > Hi, > > The USB threads are joined into a single process and not visible from "ps". Is there a special reason why it is not visible? Bye, Alexander. -- Killing is wrong. -- Losira, "That Which Survives", stardate unknown http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 12:44:55 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13605106566C; Tue, 2 Nov 2010 12:44:55 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 22EBC8FC16; Tue, 2 Nov 2010 12:44:53 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA12134; Tue, 02 Nov 2010 14:30:35 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CD0046A.1000801@icyb.net.ua> Date: Tue, 02 Nov 2010 14:30:34 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Hans Petter Selasky References: <201011021036.41617.hselasky@freebsd.org> <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> <201011021300.54515.hselasky@freebsd.org> In-Reply-To: <201011021300.54515.hselasky@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , "freebsd-usb@freebsd.org" Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 12:44:55 -0000 on 02/11/2010 14:00 Hans Petter Selasky said the following: > On Tuesday 02 November 2010 11:01:34 Alexander Leidinger wrote: >> # procstat -kk 29213 >> PID TID COMM TDNAME KSTACK >> 29213 100291 usbconfig - mi_switch+0x188 >> sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30 >> usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d >> ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21 >> >>> somewhere in umass_detach(), which is preventing the usbconfig reset from >> >> No umass_detach in there... > > Hi, > > The USB threads are joined into a single process and not visible from "ps". > Not sure how you can get a list of all threads. -H option would that for ps. But I am not why mentioned ps, because procstat shows the threads, e.g. procstat -k -a will show stacks of all non-running kernel threads. -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 13:03:24 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4638B106566B; Tue, 2 Nov 2010 13:03:24 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id C467E8FC14; Tue, 2 Nov 2010 13:03:23 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3A76A.dip.t-dialin.net [87.179.167.106]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id D355A84400F; Tue, 2 Nov 2010 14:03:18 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 80F732341; Tue, 2 Nov 2010 14:03:15 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id oA2D2tqQ005209; Tue, 2 Nov 2010 14:02:55 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 02 Nov 2010 14:02:54 +0100 Message-ID: <20101102140254.17056n3i8lr45okk@webmail.leidinger.net> Date: Tue, 02 Nov 2010 14:02:54 +0100 From: Alexander Leidinger To: Andriy Gapon References: <201011021036.41617.hselasky@freebsd.org> <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> <201011021300.54515.hselasky@freebsd.org> <4CD0046A.1000801@icyb.net.ua> In-Reply-To: <4CD0046A.1000801@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: D355A84400F.A6C21 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.351, required 6, autolearn=disabled, RDNS_NONE 1.27, TW_KD 0.08) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1289307800.67221@K6zO4C9eUWjMuiQV6OOBiA X-EBL-Spam-Status: No Cc: Alexander Motin , Hans Petter Selasky , "freebsd-usb@freebsd.org" Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 13:03:24 -0000 Quoting Andriy Gapon (from Tue, 02 Nov 2010 14:30:34 +0200): > on 02/11/2010 14:00 Hans Petter Selasky said the following: >> On Tuesday 02 November 2010 11:01:34 Alexander Leidinger wrote: >>> # procstat -kk 29213 >>> PID TID COMM TDNAME KSTACK >>> 29213 100291 usbconfig - mi_switch+0x188 >>> sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30 >>> usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d >>> ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21 >>> >>>> somewhere in umass_detach(), which is preventing the usbconfig reset from >>> >>> No umass_detach in there... >> >> Hi, >> >> The USB threads are joined into a single process and not visible from "ps". >> Not sure how you can get a list of all threads. > > -H option would that for ps. > But I am not why mentioned ps, because procstat shows the threads, > e.g. procstat > -k -a will show stacks of all non-running kernel threads. So withdraw my last question (the answer to HPS' message that it is not shown in ps), as I already provided the procstat -kka | grep umass_detach part (no trace of it). There is every half an hour a job which is polling an USB device. This job is not proceeding anymore (each instance started hangs), so it looks like the USB system is in a f*ed-up state (it does not matter to me if this is because of the "usbconfig reset ugen4.2" or not). I rebooted the system to get again the data flowing from this job. Looks like I'm able to trigger this situation within some days. If someone wants me to run some specific commands, be it in kdb or something else, please specify clearly (kdb commands / instructions) what you want and I try to provide this info by setting up the system in a way to get into the same situation again. Bye, Alexander. -- TOTD (T-shirt Of The Day): I'm the person your mother warned you about. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 13:05:06 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15DA1106564A; Tue, 2 Nov 2010 13:05:06 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id AE38B8FC0C; Tue, 2 Nov 2010 13:05:05 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3A76A.dip.t-dialin.net [87.179.167.106]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 26F0B84400D; Tue, 2 Nov 2010 14:05:00 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 5C82A2342; Tue, 2 Nov 2010 14:04:57 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id oA2D4afr005549; Tue, 2 Nov 2010 14:04:36 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 02 Nov 2010 14:04:36 +0100 Message-ID: <20101102140436.20255uuirfsbtxwc@webmail.leidinger.net> Date: Tue, 02 Nov 2010 14:04:36 +0100 From: Alexander Leidinger To: Andriy Gapon References: <201011021036.41617.hselasky@freebsd.org> <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> <201011021300.54515.hselasky@freebsd.org> <4CD0046A.1000801@icyb.net.ua> In-Reply-To: <4CD0046A.1000801@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 26F0B84400D.A4352 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (cached, score=1.351, required 6, autolearn=disabled, RDNS_NONE 1.27, TW_KD 0.08) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1289307903.90165@Z7Td2mFD7DZqAxMVQtufVg X-EBL-Spam-Status: No Cc: Alexander Motin , Hans Petter Selasky , "freebsd-usb@freebsd.org" Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 13:05:06 -0000 Quoting Andriy Gapon (from Tue, 02 Nov 2010 14:30:34 +0200): > on 02/11/2010 14:00 Hans Petter Selasky said the following: >> On Tuesday 02 November 2010 11:01:34 Alexander Leidinger wrote: >>> # procstat -kk 29213 >>> PID TID COMM TDNAME KSTACK >>> 29213 100291 usbconfig - mi_switch+0x188 >>> sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30 >>> usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d >>> ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21 >>> >>>> somewhere in umass_detach(), which is preventing the usbconfig reset from >>> >>> No umass_detach in there... >> >> Hi, >> >> The USB threads are joined into a single process and not visible from "ps". >> Not sure how you can get a list of all threads. > > -H option would that for ps. > But I am not why mentioned ps, because procstat shows the threads, > e.g. procstat > -k -a will show stacks of all non-running kernel threads. So withdraw my last question (the answer to HPS' message that it is not shown in ps), as I already provided the procstat -kka | grep umass_detach part (no trace of it). There is every half an hour a job which is polling an USB device. This job is not proceeding anymore (each instance started hangs), so it looks like the USB system is in a f*ed-up state (it does not matter to me if this is because of the "usbconfig reset ugen4.2" or not). I rebooted the system to get again the data flowing from this job. Looks like I'm able to trigger this situation within some days. If someone wants me to run some specific commands, be it in kdb or something else, please specify clearly (kdb commands / instructions) what you want and I try to provide this info by setting up the system in a way to get into the same situation again. Bye, Alexander. -- TOTD (T-shirt Of The Day): I'm the person your mother warned you about. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 21:44:40 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53FCA1065693 for ; Tue, 2 Nov 2010 21:44:40 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D51958FC1B for ; Tue, 2 Nov 2010 21:44:39 +0000 (UTC) Received: by bwz3 with SMTP id 3so6054983bwz.13 for ; Tue, 02 Nov 2010 14:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4um+GAdjCTp5SgNPIw6z6aO8AJbELeK6OroE1wO5J9o=; b=IIM1wsewOCcApsEvDv3Rl8UuvOV1swBkrh7wU7p9sbJnjVGXVPOx+PO8gHh9IW/4Mf XYm7WnmEd5MAjPD8vq4OP2HKtveFIzZ8v8SdKOZz7FdEN847DNr0C/YTG89aePDqraL+ RbcfzswRaNy/TnRn4Y3rQ7s3GKJaTYfbRp09g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FGY9uQQAmNXWOiFziXbP0nlnaZQYR1wiXQjSASuk5Tz0FS1/FBTZheCRlRimfF05uE Qqsq87C0cboESt7J/aFw0CVqgx3JQ4eSuOsWzeQmD9icNg8kfbftDxaMinnEMYTmajcF r1T+S7sGnxnGN0AupZ+C9D9PU17sm6A7eVOGc= MIME-Version: 1.0 Received: by 10.204.76.14 with SMTP id a14mr4025589bkk.14.1288734278708; Tue, 02 Nov 2010 14:44:38 -0700 (PDT) Received: by 10.204.142.133 with HTTP; Tue, 2 Nov 2010 14:44:38 -0700 (PDT) In-Reply-To: <201011020830.31701.hselasky@c2i.net> References: <201011020830.31701.hselasky@c2i.net> Date: Wed, 3 Nov 2010 00:44:38 +0300 Message-ID: From: Alexander Churanov To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-usb@freebsd.org Subject: Re: USB camera not detected by 8.1, was working in 7 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 21:44:40 -0000 pHans, Where should I look and whom to ask? Is freebsd-scsi a proper list for an issue like this? Sincerely, Alexander Churanov From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 22:25:44 2010 Return-Path: Delivered-To: freebsd-usb@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id D0C34106566B; Tue, 2 Nov 2010 22:25:44 +0000 (UTC) Date: Tue, 2 Nov 2010 22:25:44 +0000 From: Alexander Best To: Alexander Leidinger Message-ID: <20101102222544.GA30447@freebsd.org> References: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> <201011021036.41617.hselasky@freebsd.org> <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> <4CCFFDC9.1040002@FreeBSD.org> <20101102122410.1227532bno09pfs4@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101102122410.1227532bno09pfs4@webmail.leidinger.net> Cc: Alexander Motin , Hans Petter Selasky , freebsd-usb@FreeBSD.org Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 22:25:44 -0000 On Tue Nov 2 10, Alexander Leidinger wrote: > Quoting Alexander Motin (from Tue, 02 Nov 2010 > 14:02:17 +0200): > > >Alexander Leidinger wrote: > >> > >>Quoting Hans Petter Selasky (from Tue, 2 Nov 2010 > >>10:36:41 +0100): > > >>>If you dump all threads in this state I think you will see that USB is > >>>waiting > >> > >># procstat -kk 29213 > >> PID TID COMM TDNAME KSTACK > >>29213 100291 usbconfig - mi_switch+0x188 > >>sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30 > >>usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d > >>ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21 > >> > >>>somewhere in umass_detach(), which is preventing the usbconfig reset from > >> > >>No umass_detach in there... > > > >umass_detach() (if there) should be in some other thread. > > Not here: > ---snip--- > # procstat -kka | grep umass_detach > > ---snip--- > > >>>grabbing the SX-lock associated with serialisation. Because > >>>umass_detach() is > >>>not returning we are stuck. > >> > >>And there is no way to use some kind of timeout for cases which cause > >>problem reports (like umass_detach() and maybe this one)? I could > >>imagine several possibilities: usbconfig tries a trylock first (maybe > >>several times) and if it does not succeed in a specified timeperiode, it > >>returns an error. Adidtionally there is maybe the possibility to > >>determine if a command did not finish in a given timeperiode and print > >>out a warning message (syslog) to have an indication, that somthing is > >>not in a good condition. > > > >Not sure what should it give. We should track the real problem, not the > >consequences. Possible reason could be that due to some error umass/CAM > >leaked some references, which made impossible to destroy CAM bus on > >stick disconnection. But to diagnose it we need much more info. > > Something I could provide? Some kdb magic I could copy&paste? i believe you're experiencing the same i issue i have [1]. cheers. alex [1] http://www.mail-archive.com/freebsd-usb@freebsd.org/msg07599.html > > Bye, > Alexander. > > -- > Phosflink, v.: > To flick a bulb on and off when it burns out (as if, somehow, > that will bring it back to life). > -- Rich Hall & Friends, "Sniglets" > > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 -- a13x From owner-freebsd-usb@FreeBSD.ORG Wed Nov 3 07:48:25 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5A4B106564A; Wed, 3 Nov 2010 07:48:25 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 153428FC0A; Wed, 3 Nov 2010 07:48:24 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=3qpjzGKB6kwA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=FZpipyfk4kPYKNQ_bdMA:9 a=JmceI-lbvDL1P-n3zVu9EnZSB8wA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 43782594; Wed, 03 Nov 2010 08:48:23 +0100 From: Hans Petter Selasky To: Alexander Churanov Date: Wed, 3 Nov 2010 08:49:34 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011020830.31701.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011030849.34556.hselasky@c2i.net> Cc: Alexander Motin , freebsd-usb@freebsd.org Subject: Re: USB camera not detected by 8.1, was working in 7 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 07:48:25 -0000 On Tuesday 02 November 2010 22:44:38 Alexander Churanov wrote: > pHans, > > Where should I look and whom to ask? > Is freebsd-scsi a proper list for an issue like this? > > Sincerely, > Alexander Churanov Alexander, Can you answer this question. --HPS From owner-freebsd-usb@FreeBSD.ORG Wed Nov 3 08:04:03 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0587D106564A for ; Wed, 3 Nov 2010 08:04:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7BC838FC1D for ; Wed, 3 Nov 2010 08:04:02 +0000 (UTC) Received: by bwz3 with SMTP id 3so301790bwz.13 for ; Wed, 03 Nov 2010 01:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=AWtu6KQM0MDFEHG3XAxCxAUg8gDjR5RX3G6ngMj9niw=; b=Ics6NwUzMQqXVPfJIn95aJc8K2fERGVqCVtvxokW8EzuHYOBLUFdIhbpqsy6XMPu0D MxB9+4DOhH2eRjE24B88EIKN1ojteg5mMRxUCZnHRdsZwoHrpOJZF566nHlNK/G5Tz1c lHpPC0ulZXez+WaRImUWiafh8puaUO0j24dVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=iGs9BIIe/DbB2uHlTlfAlUQHyOPDaX+Umqn8np502xEiSr0+5GxY+Ga42GnpckrZ0A UaJRhLap+r2Sr1cxu/psLfRm6DD7wCODkTnAWyj7w508pTeBP+suQ+M3C45mav4xJxu1 rlliE0cE2KhaHpVAdKB/z4wWCf29f4KfYByps= Received: by 10.204.68.142 with SMTP id v14mr565810bki.106.1288771441339; Wed, 03 Nov 2010 01:04:01 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id d12sm5322127bkw.7.2010.11.03.01.03.58 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Nov 2010 01:03:59 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CD1176E.4060101@FreeBSD.org> Date: Wed, 03 Nov 2010 10:03:58 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Hans Petter Selasky References: <201011020830.31701.hselasky@c2i.net> <201011030849.34556.hselasky@c2i.net> In-Reply-To: <201011030849.34556.hselasky@c2i.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Churanov , freebsd-usb@freebsd.org Subject: Re: USB camera not detected by 8.1, was working in 7 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 08:04:03 -0000 Hans Petter Selasky wrote: > On Tuesday 02 November 2010 22:44:38 Alexander Churanov wrote: >> Where should I look and whom to ask? >> Is freebsd-scsi a proper list for an issue like this? It is related, though I am also not sure it is SCSI issue. "AutoSense failed" means that CAM and umass were unable to get detailed information about error. Without that information CAM subsystem can't adequately handle it. We need more information about the problem. Try to reproduce the problem after booting with verbose kernel messages or enabling it via debug.bootverbose sysctl. If it won't give much - you may rebuild kernel with `options CAMDEBUG` and enable some debugging via `camcontrol debug`. -- Alexander Motin From owner-freebsd-usb@FreeBSD.ORG Wed Nov 3 08:54:18 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63245106566C; Wed, 3 Nov 2010 08:54:18 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 11E148FC17; Wed, 3 Nov 2010 08:54:17 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3AAA2.dip.t-dialin.net [87.179.170.162]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 8599B84400D; Wed, 3 Nov 2010 09:54:14 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 3EC6B2403; Wed, 3 Nov 2010 09:54:11 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id oA38s6aK083963; Wed, 3 Nov 2010 09:54:06 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 03 Nov 2010 09:54:05 +0100 Message-ID: <20101103095405.12525u398eqxc30o@webmail.leidinger.net> Date: Wed, 03 Nov 2010 09:54:05 +0100 From: Alexander Leidinger To: Alexander Best References: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> <201011021036.41617.hselasky@freebsd.org> <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> <4CCFFDC9.1040002@FreeBSD.org> <20101102122410.1227532bno09pfs4@webmail.leidinger.net> <20101102222544.GA30447@freebsd.org> In-Reply-To: <20101102222544.GA30447@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 8599B84400D.A82A1 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.274, required 6, autolearn=disabled, RDNS_NONE 1.27) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1289379254.7452@a+hw1MmSEY5gNmR8T3wxNg X-EBL-Spam-Status: No Cc: Alexander Motin , Hans Petter Selasky , freebsd-usb@freebsd.org Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 08:54:18 -0000 Quoting Alexander Best (from Tue, 2 Nov 2010 22:25:44 +0000): > i believe you're experiencing the same i issue i have [1]. > > cheers. > alex > > [1] http://www.mail-archive.com/freebsd-usb@freebsd.org/msg07599.html I don't think it is exactly the same, I was able to do top/ps/dmesg. Bye, Alexander. -- I'm very old-fashioned. I believe that people should marry for life, like pigeons and Catholics. -- Woody Allen http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-usb@FreeBSD.ORG Wed Nov 3 11:16:03 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27E32106564A; Wed, 3 Nov 2010 11:16:03 +0000 (UTC) (envelope-from alexanderchuranov@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7EAF08FC0C; Wed, 3 Nov 2010 11:16:02 +0000 (UTC) Received: by bwz3 with SMTP id 3so422109bwz.13 for ; Wed, 03 Nov 2010 04:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=aqAokg9BKkpqKcAsco6bOGYkTh9E39bHfZUltYh4GG0=; b=iM8sqJv2cK9MI+OSyKTdEiN803m3Z5PnRSq7+qbXoAGGL9sqkuS7OhMMAwUIhzJkEj 8gut8x/aGBivi15Co/32eudzxVUGWZ4kjqn5y8drgurhAtM9k/7g5nWTWBDxz8YKJiCE c5kyrGjPwZXOeAvrrcFf4P0jd8ltWN8kjscak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hpk2yWsf3WXe/vbCjiYbqg3JnU8FjG8qC74RVNajZwKctoT77atiEdpZ8r1ZC0OkoI q4ycsyy6oRhhWhKyhHC4b+LhqBJW+3PmntJ0g2WjDPlCo0ovVTI9PrpsFgd/CXqU9JAo LV4cRR5neGfwsH6H3LgKCgXg9GSuJSSnHklO4= MIME-Version: 1.0 Received: by 10.204.113.196 with SMTP id b4mr6200057bkq.176.1288782961287; Wed, 03 Nov 2010 04:16:01 -0700 (PDT) Received: by 10.204.142.133 with HTTP; Wed, 3 Nov 2010 04:16:01 -0700 (PDT) In-Reply-To: <4CD1176E.4060101@FreeBSD.org> References: <201011020830.31701.hselasky@c2i.net> <201011030849.34556.hselasky@c2i.net> <4CD1176E.4060101@FreeBSD.org> Date: Wed, 3 Nov 2010 14:16:01 +0300 Message-ID: From: Alexander Churanov To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-usb@freebsd.org Subject: Re: USB camera not detected by 8.1, was working in 7 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 11:16:03 -0000 Alexander and other folks, Thank you for your attention. I'll enable debugging and provide you with data. Alexander Churanov From owner-freebsd-usb@FreeBSD.ORG Wed Nov 3 11:20:12 2010 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D58D1065679 for ; Wed, 3 Nov 2010 11:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5179F8FC15 for ; Wed, 3 Nov 2010 11:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA3BKCEj085381 for ; Wed, 3 Nov 2010 11:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA3BKCLn085380; Wed, 3 Nov 2010 11:20:12 GMT (envelope-from gnats) Date: Wed, 3 Nov 2010 11:20:12 GMT Message-Id: <201011031120.oA3BKCLn085380@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Alexander Best Cc: Subject: Re: usb/108344: [usb67] [atausb] [panic] kernel with atausb panics when unplugging USB Flash X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Best List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 11:20:12 -0000 The following reply was made to PR usb/108344; it has been noted by GNATS. From: Alexander Best To: bug-followup@freebsd.org Cc: Subject: Re: usb/108344: [usb67] [atausb] [panic] kernel with atausb panics when unplugging USB Flash Date: Wed, 3 Nov 2010 11:12:04 +0000 this pr can be closed once the 7.x branch goes EoL, since ata-usb support was removed in 8.x. cheers. alex -- a13x From owner-freebsd-usb@FreeBSD.ORG Wed Nov 3 12:31:22 2010 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D1281065675; Wed, 3 Nov 2010 12:31:22 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 535588FC13; Wed, 3 Nov 2010 12:31:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA3CVMdW066518; Wed, 3 Nov 2010 12:31:22 GMT (envelope-from mav@freefall.freebsd.org) Received: (from mav@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA3CVLwr066488; Wed, 3 Nov 2010 12:31:21 GMT (envelope-from mav) Date: Wed, 3 Nov 2010 12:31:21 GMT Message-Id: <201011031231.oA3CVLwr066488@freefall.freebsd.org> To: ggg_mail@inbox.ru, mav@FreeBSD.org, freebsd-usb@FreeBSD.org From: mav@FreeBSD.org Cc: Subject: Re: usb/108344: [usb67] [atausb] [panic] kernel with atausb panics when unplugging USB Flash X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 12:31:22 -0000 Synopsis: [usb67] [atausb] [panic] kernel with atausb panics when unplugging USB Flash State-Changed-From-To: suspended->closed State-Changed-By: mav State-Changed-When: Wed Nov 3 12:26:19 UTC 2010 State-Changed-Why: With FreeBSD 6.x closing to EoL, with atausb dropped and USB overhauled in 8.x this is highly unlikely to be addressed. http://www.freebsd.org/cgi/query-pr.cgi?pr=108344 From owner-freebsd-usb@FreeBSD.ORG Wed Nov 3 19:14:13 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 259901065675 for ; Wed, 3 Nov 2010 19:14:13 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from smtp103.rog.mail.re2.yahoo.com (smtp103.rog.mail.re2.yahoo.com [206.190.36.81]) by mx1.freebsd.org (Postfix) with SMTP id A28BA8FC12 for ; Wed, 3 Nov 2010 19:14:12 +0000 (UTC) Received: (qmail 35722 invoked from network); 3 Nov 2010 19:14:11 -0000 Received: from smtp.irbisnet.com (andriy@99.235.226.221 with login) by smtp103.rog.mail.re2.yahoo.com with SMTP; 03 Nov 2010 12:14:11 -0700 PDT X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- X-YMail-OSG: nV1lpMYVM1n482Ab4DWpkM9q0s1egh2UJU3R6rr.UXcOcuh gTZkJqHLKjtKoRCRoxjorosAV1Tqa1QZegd6aDpIdahIApm.Cy.h4FmA3SE9 fzkxVdVnpnZjNkIVkf54QwZkpC3BhkXe2ni9btp3ylsbrUreB9CdHIjuLojk a2f35lbij7UTeqtBqdq4InMIddVSefRnaAP6OwX13bNawXhEME3jw.4eCM.t C2hpfWJzHgvXjvMNw3ZtnIcC1CEygya4Q9oWGlSBDIb5fco_iuY7HCMym2sZ qNoO7m_cCeeFFbDK_XGeSEyuXb86ztk4NDtxIb5AIJZ36CpfdWkyRRiykY6s 0uO.DVhGN6cWwZCCQ0UH0qjqxKyd5KsiTJx2l.CkAL91Qekxv7lA7UNiFaM9 UPQlr7cpD12EZqm29 X-Yahoo-Newman-Property: ymail-3 Received: from [10.120.235.231] (unknown [74.198.28.200]) by smtp.irbisnet.com (Postfix) with ESMTPSA id E801125B5B; Wed, 3 Nov 2010 15:14:10 -0400 (EDT) References: From: Andriy Bakay Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (8B117) In-Reply-To: Message-Id: Date: Wed, 3 Nov 2010 15:14:25 -0400 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPhone Mail 8B117) Cc: "freebsd-usb@freebsd.org" , Jim Nasby Subject: Re: usb/150401: Errors from USB drives mixed between UFS and ZFS X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 19:14:13 -0000 On 2010-10-12, at 15:32, Andriy Bakay wrote: > Hi All, >=20 > I have same issue (see below link) on FreeBSD 8.1-RELEASE-p1 i386. Do you k= now what is root cause of it or how to fix it? >=20 > http://lists.freebsd.org/pipermail/freebsd-usb/2010-September/009283.html >=20 > Thanks, > Andriy >=20 > _______________________________________________ > freebsd-usb@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" I have Free Agent Pro and Go Flex external hard drives both of them connecte= d to same USB controller. After I disable power saving feature on both of th= em (Seagate tool for Windows was used) the issue seems go away. I did not no= tice it for three week for now. Andriy= From owner-freebsd-usb@FreeBSD.ORG Wed Nov 3 19:20:08 2010 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1F72106566B for ; Wed, 3 Nov 2010 19:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B5F3F8FC13 for ; Wed, 3 Nov 2010 19:20:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA3JK8gp084155 for ; Wed, 3 Nov 2010 19:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA3JK8UJ084154; Wed, 3 Nov 2010 19:20:08 GMT (envelope-from gnats) Date: Wed, 3 Nov 2010 19:20:08 GMT Message-Id: <201011031920.oA3JK8UJ084154@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Alessandro de Manzano Cc: Subject: Re: usb/151862: adding support of USB GSM modem Falcom Twist X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alessandro de Manzano List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2010 19:20:09 -0000 The following reply was made to PR usb/151862; it has been noted by GNATS. From: Alessandro de Manzano To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/151862: adding support of USB GSM modem Falcom Twist Date: Wed, 03 Nov 2010 19:46:18 +0100 Here is the even simpler patch for FreeBSD 8.1-RELEASE. Untested, unfortunately, but should not damage either.. --- usbdevs.orig 2010-11-03 19:31:15.000000000 +0100 +++ usbdevs 2010-11-03 19:33:26.000000000 +0100 @@ -1486,6 +1486,9 @@ /* Extended Systems products */ product EXTENDED XTNDACCESS 0x0100 XTNDAccess IrDA +/* Falcom products */ +product FALCOM TWIST 0x0001 USB GSM/GPRS Modem + /* FEIYA products */ product FEIYA 5IN1 0x1132 5-in-1 Card Reader --- serial/uftdi.c.orig 2010-11-03 19:34:02.000000000 +0100 +++ serial/uftdi.c 2010-11-03 19:35:07.000000000 +0100 @@ -255,6 +255,7 @@ UFTDI_DEV(MARVELL, SHEEVAPLUG, 8U232AM), UFTDI_DEV(MELCO, PCOPRS1, 8U232AM), UFTDI_DEV(RATOC, REXUSB60F, 8U232AM), + UFTDI_DEV(FALCOM, TWIST, 8U232AM), #undef UFTDI_DEV }; From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 08:37:17 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DEE4106566C; Thu, 4 Nov 2010 08:37:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id BCC7D8FC0C; Thu, 4 Nov 2010 08:37:15 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=FberXtVRn-wA:10 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=hbYBJcQZDcC0HrEwo7wA:9 a=rdHuChauiKYftlwAyukA:7 a=rp5_LUhrVUki9jaKdWBadY-w694A:4 a=PUjeQqilurYA:10 a=hc5yWR8y822bM0dV:21 a=_9LHc2Q8-2OudMNw:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44321807; Thu, 04 Nov 2010 09:37:13 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 09:38:25 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011011714.50121.jhb@freebsd.org> <201011020839.45839.hselasky@c2i.net> In-Reply-To: <201011020839.45839.hselasky@c2i.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011040938.25094.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org, John Baldwin , Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 08:37:17 -0000 On Tuesday 02 November 2010 08:39:45 Hans Petter Selasky wrote: > On Monday 01 November 2010 22:14:49 John Baldwin wrote: > > On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote: > > > Hi! > > > > > > I've wrapped up an outline patch for what needs to be done to integrate > > > the USB process framework into the kernel taskqueue system in a more > > > direct way that to wrap it. > > > > > > The limitation of the existing taskqueue system is that it only > > > guarantees execution at a given priority level. USB requires more. USB > > > also requires a guarantee that the last task queued task also gets > > > executed last. This is for example so that a deferred USB detach event > > > does not happen before any pending deferred I/O for example in case of > > > multiple occurring events. > > > > > > Mostly this new feature is targeted for GPIO-alike system using slow > > > busses like the USB. Typical use case: > > > > > > 2 tasks to program GPIO on. > > > 2 tasks to program GPIO off. > > > > > > Example: > > > > > > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > > > > > > >sc_task_on[1]); > > > > > > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > > > > > > >sc_task_off[1]); > > > > > > No matter how the call ordering of code-line a) and b), we are always > > > guaranteed that the last queued state "on" or "off" is reached before > > > the head of the taskqueue empties. > > > > > > > > > In lack of a better name, the new function was called > > > taskqueue_enqueue_odd [some people obviously think that USB processes > > > are odd, but not taskqueues > > > > > > :-)] > > > > It feels like this should be something you could manage with a state > > machine internal to USB rather than forcing that state into the taskqueue > > code itself. > > Hi John, > > No, this is not possible without keeping my own queue, which I want to > avoid. By state-machine you mean remembering the last state as a separate > variable and checking that in the task-callback, right? Yes, I do that in > addition to the new queuing mechanism. > > A task barrier does not solve my problem. The barrier in my case is always > last in the queue. I need to pull out previously queued tasks and put them > last. That is currently not supported. I do this because I don't want to > have a FIFO signalling model, and a neither want the pure taskqueue, which > only ensures execution, not order of execution when at the same priority. > > Another issue: Won't the barrier model lead to blocking the caller once the > task in question is being issued the second time? > > --HPS > > > If you wanted a simple barrier task (where a barrier task is > > always queued at the tail of the list and all subsequent tasks are queued > > after the barrier task) then I would be fine with adding that. You > > could manage this without having to alter the task KBI by having the > > taskqueue maintain a separate pointer to the current "barrier" task and > > always enqueue entries after that task (the barrier would be NULL before > > a barrier is queued, and set to NULL when a barrier executes). > > > > I think this sort of semantic is a bit simpler and also used in other > > parts of the tree (e.g. in bio queues). > Any more comments on this matter or someone still doing review? --HPS From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 13:55:12 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B482A1065679; Thu, 4 Nov 2010 13:55:12 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BD15E8FC12; Thu, 4 Nov 2010 13:55:10 +0000 (UTC) Received: by iwn39 with SMTP id 39so1442199iwn.13 for ; Thu, 04 Nov 2010 06:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rc6Kf9M4JbqxPQwsiLamXqjZv7hw7qPAbMGIlSL8Prc=; b=lhInRB7GhpdX3uDnyYrOVphBArMV2tL/Uyd60gDHexCc0bXEUPLArOOZgiPRa1Tw/Z OL6h6Vh4BK82OvnMVa2HnpY65OizkAZw9OAxbugup/eNIGmBj43kVwUV4tejVGwL7xjk ttInqLtFa5GrjknG6B8g9TvE0Bb5E9pB8RikA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=is+GRIxG7FlicA8x+7DoC0R9Po5VylH8eu3ln0WTPSFoslwaXPNqJm9he0jJ8/8okT ABuI7NcHTSztRM6vRgUI9YFBWEs7OKjjNKuZCkxzJyFKl1l/SOgiEJLznrln8f+rusZ7 HoR+lUKhuu3qSw++keX/shCIhz7yvui16KNNI= MIME-Version: 1.0 Received: by 10.231.33.203 with SMTP id i11mr490075ibd.8.1288878909370; Thu, 04 Nov 2010 06:55:09 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 06:55:09 -0700 (PDT) In-Reply-To: <201011012115.15261.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011012115.15261.hselasky@c2i.net> Date: Thu, 4 Nov 2010 06:55:09 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 13:55:12 -0000 On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky wrot= e: > On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: >> On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky > wrote: >> > Hi! >> > >> > I've wrapped up an outline patch for what needs to be done to integrat= e >> > the USB process framework into the kernel taskqueue system in a more >> > direct way that to wrap it. >> > >> > The limitation of the existing taskqueue system is that it only >> > guarantees execution at a given priority level. USB requires more. USB >> > also requires a guarantee that the last task queued task also gets >> > executed last. This is for example so that a deferred USB detach event >> > does not happen before any pending deferred I/O for example in case of >> > multiple occurring events. >> > >> > Mostly this new feature is targeted for GPIO-alike system using slow >> > busses like the USB. Typical use case: >> > >> > 2 tasks to program GPIO on. >> > 2 tasks to program GPIO off. >> > >> > Example: >> > >> > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- >> > >> >>sc_task_on[1]); >> >> >> > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- >> > >> >>sc_task_off[1]); >> >> >> > No matter how the call ordering of code-line a) and b), we are always >> > guaranteed that the last queued state "on" or "off" is reached before = the >> > head of the taskqueue empties. >> > >> > >> > In lack of a better name, the new function was called >> > taskqueue_enqueue_odd [some people obviously think that USB processes >> > are odd, but not taskqueues >> > >> > :-)] >> >> I'd like to make sure I understand the USB requirements. >> >> (1) does USB need the task priority field? =A0Many taskqueue(9) consumer= s do >> not. > > No, USB does not need a task priority field, but a sequence field associa= ted > with the task and task queue head to figure out which task was queued fir= st > without having to scan all the tasks queued. > >> (2) if there was a working taskqueue_remove(9) that removed the task >> if pending or returned error if the task was currently running, would >> that be sufficient to implement the required USB functionality? >> (assuming that taskqueue_enqueue(9) put all tasks with equal priority >> in order of queueing). > > No, not completely. See comment above. I also need information about whic= h > task was queued first, or else I have to keep this information separately= , > which again, confuse people. The more layers the more confusion? I don't follow why keeping the information about which task was queued first privately rather than having taskqueue(9) maintain it is confusing. So far, USB seems to be the only taskqueue consumer which needs this information, so it makes a lot more sense to me for it to be USB private. To my mind, there's primary operations, and secondary ones. A secondary operation can be built from the primary ones. It reads to me that, if there was a taskqueue_cancel(9) (and there is in Jeff's OFED branch) then you could build the functionality you want (and maybe you don't need cancel, even). While there is sometimes an argument for making secondary operations available in a library, in this case you need extra data which most other taskqueue consumers do not. That would break the KBI. That is another argument in favor of keeping the implementation private to USB. Thanks, matthew From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 15:08:52 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D81761065672; Thu, 4 Nov 2010 15:08:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id CAFDE8FC16; Thu, 4 Nov 2010 15:08:51 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=eBBTKOCzzS4ddj3yubgA:9 a=UVoTL3aoASoHr0WDeJkA:7 a=nXYsBsMJQ5gLzLLRCrZL-R1_Wg0A:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44175068; Thu, 04 Nov 2010 16:08:49 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 16:10:00 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011012115.15261.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041610.00736.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 15:08:53 -0000 On Thursday 04 November 2010 14:55:09 Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky wrote: > > On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: > >> On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky > > > > wrote: > >> > Hi! > >> > > >> > I've wrapped up an outline patch for what needs to be done to > >> > integrate the USB process framework into the kernel taskqueue system > >> > in a more direct way that to wrap it. > >> > > >> > The limitation of the existing taskqueue system is that it only > >> > guarantees execution at a given priority level. USB requires more. USB > >> > also requires a guarantee that the last task queued task also gets > >> > executed last. This is for example so that a deferred USB detach event > >> > does not happen before any pending deferred I/O for example in case of > >> > multiple occurring events. > >> > > >> > Mostly this new feature is targeted for GPIO-alike system using slow > >> > busses like the USB. Typical use case: > >> > > >> > 2 tasks to program GPIO on. > >> > 2 tasks to program GPIO off. > >> > > >> > Example: > >> > > >> > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > >> > > >> >>sc_task_on[1]); > >> >> > >> > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > >> > > >> >>sc_task_off[1]); > >> >> > >> > No matter how the call ordering of code-line a) and b), we are always > >> > guaranteed that the last queued state "on" or "off" is reached before > >> > the head of the taskqueue empties. > >> > > >> > > >> > In lack of a better name, the new function was called > >> > taskqueue_enqueue_odd [some people obviously think that USB processes > >> > are odd, but not taskqueues > >> > > >> > :-)] > >> > >> I'd like to make sure I understand the USB requirements. > >> > >> (1) does USB need the task priority field? Many taskqueue(9) consumers > >> do not. > > > > No, USB does not need a task priority field, but a sequence field > > associated with the task and task queue head to figure out which task > > was queued first without having to scan all the tasks queued. > > > >> (2) if there was a working taskqueue_remove(9) that removed the task > >> if pending or returned error if the task was currently running, would > >> that be sufficient to implement the required USB functionality? > >> (assuming that taskqueue_enqueue(9) put all tasks with equal priority > >> in order of queueing). > > > > No, not completely. See comment above. I also need information about > > which task was queued first, or else I have to keep this information > > separately, which again, confuse people. The more layers the more > > confusion? Hi, > > I don't follow why keeping the information about which task was queued > first privately rather than having taskqueue(9) maintain it is > confusing. So far, USB seems to be the only taskqueue consumer which > needs this information, so it makes a lot more sense to me for it to > be USB private. Probably I can check which task is pending when I queue them and store that in a separate variable. Still I need a way to remove a task from the queue, which becomes very slow due to the fact that STAILQ() is used. > To my mind, there's primary operations, and secondary ones. A > secondary operation can be built from the primary ones. That is right, if there is a way to remove a task from a queue without draining. > It reads to > me that, if there was a taskqueue_cancel(9) (and there is in Jeff's > OFED branch) then you could build the functionality you want (and > maybe you don't need cancel, even). While there is sometimes an > argument for making secondary operations available in a library, in > this case you need extra data which most other taskqueue consumers do > not. That would break the KBI. That is another argument in favor of > keeping the implementation private to USB. The only reason I want to break the KBI is because it is slow to remove a task from the taskqueue using STAILQ's when you don't know the previous task- element in the queue. --HPS From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 18:00:34 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 785B71065697; Thu, 4 Nov 2010 18:00:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 437AA8FC13; Thu, 4 Nov 2010 18:00:34 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CBBF946B5B; Thu, 4 Nov 2010 14:00:33 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BD7D78A009; Thu, 4 Nov 2010 14:00:32 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 10:29:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011012115.15261.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041029.51864.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 04 Nov 2010 14:00:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=4.2 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Matthew Fleming , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 18:00:34 -0000 On Thursday, November 04, 2010 9:55:09 am Matthew Fleming wrote: > On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky wrote: > > On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: > >> On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky > > wrote: > >> > Hi! > >> > > >> > I've wrapped up an outline patch for what needs to be done to integrate > >> > the USB process framework into the kernel taskqueue system in a more > >> > direct way that to wrap it. > >> > > >> > The limitation of the existing taskqueue system is that it only > >> > guarantees execution at a given priority level. USB requires more. USB > >> > also requires a guarantee that the last task queued task also gets > >> > executed last. This is for example so that a deferred USB detach event > >> > does not happen before any pending deferred I/O for example in case of > >> > multiple occurring events. > >> > > >> > Mostly this new feature is targeted for GPIO-alike system using slow > >> > busses like the USB. Typical use case: > >> > > >> > 2 tasks to program GPIO on. > >> > 2 tasks to program GPIO off. > >> > > >> > Example: > >> > > >> > a) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_on[0], &sc- > >> > > >> >>sc_task_on[1]); > >> >> > >> > b) taskqueue_enqueue_odd(&sc->sc_taskqueue, &sc->sc_task_off[0], &sc- > >> > > >> >>sc_task_off[1]); > >> >> > >> > No matter how the call ordering of code-line a) and b), we are always > >> > guaranteed that the last queued state "on" or "off" is reached before the > >> > head of the taskqueue empties. > >> > > >> > > >> > In lack of a better name, the new function was called > >> > taskqueue_enqueue_odd [some people obviously think that USB processes > >> > are odd, but not taskqueues > >> > > >> > :-)] > >> > >> I'd like to make sure I understand the USB requirements. > >> > >> (1) does USB need the task priority field? Many taskqueue(9) consumers do > >> not. > > > > No, USB does not need a task priority field, but a sequence field associated > > with the task and task queue head to figure out which task was queued first > > without having to scan all the tasks queued. > > > >> (2) if there was a working taskqueue_remove(9) that removed the task > >> if pending or returned error if the task was currently running, would > >> that be sufficient to implement the required USB functionality? > >> (assuming that taskqueue_enqueue(9) put all tasks with equal priority > >> in order of queueing). > > > > No, not completely. See comment above. I also need information about which > > task was queued first, or else I have to keep this information separately, > > which again, confuse people. The more layers the more confusion? > > I don't follow why keeping the information about which task was queued > first privately rather than having taskqueue(9) maintain it is > confusing. So far, USB seems to be the only taskqueue consumer which > needs this information, so it makes a lot more sense to me for it to > be USB private. > > To my mind, there's primary operations, and secondary ones. A > secondary operation can be built from the primary ones. It reads to > me that, if there was a taskqueue_cancel(9) (and there is in Jeff's > OFED branch) then you could build the functionality you want (and > maybe you don't need cancel, even). While there is sometimes an > argument for making secondary operations available in a library, in > this case you need extra data which most other taskqueue consumers do > not. That would break the KBI. That is another argument in favor of > keeping the implementation private to USB. My sense is that I certainly agree. The fact that you can't think of a good name for the operation certainly indicates that it is not generic. Unfortunately, I don't really understand the problem that is being solved. I do agree that due to the 'pending' feature and automatic-coalescing of task enqueue operations, taskqueues do not lend themselves to a barrier operation. -- John Baldwin From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 18:40:02 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8690E1065675; Thu, 4 Nov 2010 18:40:02 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 476438FC18; Thu, 4 Nov 2010 18:40:00 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5OBHFxb9I47YZ7HELXzI6cL6pwPTRnd5uxbD1DPQ4WY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=iww12FFwlFl3aLusVMYA:9 a=G2MUKtwv3xM2W6zJlr3T7OYMlNgA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44269867; Thu, 04 Nov 2010 19:40:00 +0100 From: Hans Petter Selasky To: John Baldwin Date: Thu, 4 Nov 2010 19:41:09 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011041029.51864.jhb@freebsd.org> In-Reply-To: <201011041029.51864.jhb@freebsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041941.09662.hselasky@c2i.net> Cc: Matthew Fleming , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 18:40:02 -0000 On Thursday 04 November 2010 15:29:51 John Baldwin wrote: > (and there is in Jeff's OFED branch) Is there a link to this branch? I would certainly have a look at his work and re-base my patch. --HPS From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 19:02:00 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11E3A106564A; Thu, 4 Nov 2010 19:02:00 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6778FC08; Thu, 4 Nov 2010 19:01:59 +0000 (UTC) Received: by ywh2 with SMTP id 2so1768476ywh.13 for ; Thu, 04 Nov 2010 12:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I1HBTmal4wdj7RoHcpK5ZAj42DF8gXyVmwLeiE2VbIg=; b=GQKlLEbUB+NgCPMZ8Sh3T1JaNUKdIdsBeAdRgeiixFoTHCPaOAilAoxFXIJIJwBNGS xISQXfnZgWh8Wpe5NYtrnNcyxL5+wduOohtvnZljsgjn/4z/OR8ZHXIXWQ3QUSwWFhDL 9EzEK6wfPqwJGuGpFwSHNy37uKGqa9eL0+xW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oElfcZT08ZfGcR0F3YxBLm5qIlWQ0b8xnZo4wi1DTHgglfJUyDZ4LUDE5pa+UlHpGG NQKkhF2l7TvTmzvckiYVyXnZ5Otb2ToXBJ647/yN1QL1AUXkay9uSoUDVl1Wd+suGeXs 30sT0OF9PcBxmM33I16NnvDVGUmzO+wN+VP9E= MIME-Version: 1.0 Received: by 10.42.97.67 with SMTP id m3mr657740icn.343.1288897317938; Thu, 04 Nov 2010 12:01:57 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 12:01:57 -0700 (PDT) In-Reply-To: <201011041941.09662.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011041029.51864.jhb@freebsd.org> <201011041941.09662.hselasky@c2i.net> Date: Thu, 4 Nov 2010 12:01:57 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: John Baldwin , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 19:02:00 -0000 On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky wro= te: > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: >> =A0(and there is in Jeff's OFED branch) > > Is there a link to this branch? I would certainly have a look at his work= and > re-base my patch. It's on svn.freebsd.org: http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_taskque= ue.c?view=3Dlog http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D209422 For the purpose of speed, I'm not opposed to breaking the KBI by using a doubly-linked TAILQ, but I don't think the difference will matter all that often (perhaps I'm wrong and some taskqueues have dozens of pending tasks?) Thanks, matthew From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 19:07:41 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CDCA106566B; Thu, 4 Nov 2010 19:07:41 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1AE618FC08; Thu, 4 Nov 2010 19:07:39 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=qRdCxWWPLfbE3fxGEroA:9 a=UEHWcmcm-zK5qilDy1FloXSCRVoA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45408163; Thu, 04 Nov 2010 20:07:38 +0100 From: Hans Petter Selasky To: Matthew Fleming Date: Thu, 4 Nov 2010 20:08:47 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011041941.09662.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011042008.47703.hselasky@c2i.net> Cc: John Baldwin , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 19:07:41 -0000 On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: > For the purpose of speed, I'm not opposed to breaking the KBI by using > a doubly-linked TAILQ, but I don't think the difference will matter > all that often (perhaps I'm wrong and some taskqueues have dozens of > pending tasks?) Hi, In my case we are talking about 10-15 tasks at maximum. But still (10*9) / 2 = 45 iterations is much more than 2 steps to do the unlink. Anyway. I will have a look at your work and suggest a new patch for my needs. --HPS From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 19:10:37 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99ABF106566C; Thu, 4 Nov 2010 19:10:37 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 618C08FC12; Thu, 4 Nov 2010 19:10:35 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=qVhn0TDvtfzDoSz3N8YA:9 a=8QUpVPaYN4w5MPYWOUqInMW9KUQA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45409098; Thu, 04 Nov 2010 20:10:35 +0100 From: Hans Petter Selasky To: Matthew Fleming Date: Thu, 4 Nov 2010 20:11:44 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011041941.09662.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011042011.44705.hselasky@c2i.net> Cc: John Baldwin , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 19:10:37 -0000 On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: > On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky wrote: > > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: > >> (and there is in Jeff's OFED branch) > > > > Is there a link to this branch? I would certainly have a look at his work > > and re-base my patch. > > It's on svn.freebsd.org: > > http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_taskque > ue.c?view=log > http://svn.freebsd.org/viewvc/base?view=revision&revision=209422 > > For the purpose of speed, I'm not opposed to breaking the KBI by using > a doubly-linked TAILQ, but I don't think the difference will matter > all that often (perhaps I'm wrong and some taskqueues have dozens of > pending tasks?) > > Thanks, > matthew At first look I see that I need a non-blocking version of: taskqueue_cancel( At the point in the code where these functions are called I cannot block. Is this impossible to implement? --HPS From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 19:36:14 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0455810657A9 for ; Thu, 4 Nov 2010 19:36:14 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 2A5958FC17 for ; Thu, 4 Nov 2010 19:36:12 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=gl0LPzB4YDQuuzpDoHYit7deEV0cOo++Sg28kyvF6vg= c=1 sm=1 a=teY7EFdY6K0A:10 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=ciQG63UtTagwGpE5F2MA:9 a=mp48nTCfHpkmygNuyyUA:7 a=sq-N36W3c7Onjl6QhiToB-omPicA:4 a=PUjeQqilurYA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44562742; Thu, 04 Nov 2010 20:36:11 +0100 From: Hans Petter Selasky To: Michael Martin Date: Thu, 4 Nov 2010 20:37:20 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <4CBFEBF5.30203@comcast.net> <201010230823.36449.hselasky@c2i.net> <4CC2E533.3010604@comcast.net> In-Reply-To: <4CC2E533.3010604@comcast.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011042037.20274.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: USB 3.0 Fails To Attach Western Digital My Book 3.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 19:36:14 -0000 On Saturday 23 October 2010 15:37:55 Michael Martin wrote: > On 10/23/2010 00:23, Hans Petter Selasky wrote: > > On Saturday 23 October 2010 02:07:59 Michael Martin wrote: > >> On 10/21/2010 01:29, Michael Martin wrote: > >>> Thanks for the new USB 3.0 effort! > >>> > >>> I'm testing it out on 9.0-CURRENT amd64. The controller seems to find > >>> a 2.0 usb stick fine. However, when I plug in a Western Digital 3.0 > >>> drive, the device fails to attach. The WD drive attaches fine when > >>> plugging into a 2.0 port on the motherboard. > >>> > >>> Controller info: > >>> > >>> xhci0@pci0:5:0:0: class=0x0c0330 card=0xffffffff chip=0x01941033 > >>> rev=0x03 hdr=0x00 > >>> > >>> vendor = 'NEC Electronics Hong Kong' > >>> class = serial bus > >>> subclass = USB > >>> bar [10] = type Memory, range 64, base 0xfbbfe000, size 8192, > >>> > >>> enabled > >>> > >>> cap 01[50] = powerspec 3 supports D0 D3 current D0 > >>> cap 05[70] = MSI supports 8 messages, 64 bit > >>> cap 11[90] = MSI-X supports 8 messages in map 0x10 > >>> cap 10[a0] = PCI-Express 2 endpoint max data 128(128) link x1(x1) > >>> > >>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected > >>> ecap 0003[140] = Serial 1 ffffffffffffffff > >>> ecap 0018[150] = unknown 1 > >>> > >>> WD 3.0 Drive Info ( while plugged into the 2.0 port ): > >>> > >>> ugen3.4: at usbus3, cfg=0 md=HOST > >>> spd=HIGH (480Mbps) pwr=ON > >>> > >>> bLength = 0x0012 > >>> bDescriptorType = 0x0001 > >>> bcdUSB = 0x0210 > >>> bDeviceClass = 0x0000 > >>> bDeviceSubClass = 0x0000 > >>> bDeviceProtocol = 0x0000 > >>> bMaxPacketSize0 = 0x0040 > >>> idVendor = 0x1058 > >>> idProduct = 0x1123 > >>> bcdDevice = 0x1010 > >>> iManufacturer = 0x0001 > >>> iProduct = 0x0002 > >>> iSerialNumber = 0x0003 > >>> bNumConfigurations = 0x0001 > >>> > >>> Output when plugging in the Western Digital 3.0 into the 3.0 port: > >>> > >>> Oct 21 01:03:54 gandalf root: Unknown USB device: vendor 0x1058 > >>> product 0x1123 bus uhub4 > >>> Oct 21 01:03:54 gandalf kernel: ugen4.2: at usbus4 > >>> Oct 21 01:03:54 gandalf kernel: umass0: >>> class 0/0, rev 3.00/10.10, addr 1> on usbus4 > >>> Oct 21 01:03:54 gandalf kernel: umass0: SCSI over Bulk-Only; quirks = > >>> 0x0000 > >>> Oct 21 01:03:55 gandalf kernel: umass0:9:0:-1: Attached to scbus9 > >>> Oct 21 01:03:57 gandalf root: ZFS: zpool I/O failure, zpool=wd3.1 > >>> error=28 > >>> Oct 21 01:03:57 gandalf last message repeated 2 times > >>> Oct 21 01:03:57 gandalf root: ZFS: vdev I/O failure, zpool=wd3.1 path= > >>> offset= size= error= > >>> Oct 21 01:04:03 gandalf kernel: ugen4.2: at usbus4 > >>> (disconnected) > >>> Oct 21 01:04:03 gandalf kernel: umass0: at uhub4, port 2, addr 1 > >>> (disconnected) > >>> Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): lost device > >>> Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): got CAM status > >>> 0xa > >>> Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): fatal error, > >>> failed to attach to device > >>> Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0: > >>> Oct 21 01:04:03 gandalf kernel: 0:0): removing device entry > >>> Oct 21 01:04:14 gandalf root: ZFS: zpool I/O failure, zpool=wd3.1 > >>> error=28 > >>> Oct 21 01:04:14 gandalf last message repeated 2 times > >>> Oct 21 01:04:14 gandalf root: ZFS: vdev I/O failure, zpool=wd3.1 path= > >>> offset= size= error= > >>> > >>> Output when plugging in the WD 3.0 into the 2.0 port: > >>> > >>> Oct 21 01:15:20 gandalf root: Unknown USB device: vendor 0x1058 > >>> product 0x1123 bus uhub3 > >>> Oct 21 01:15:20 gandalf kernel: ugen3.4: at usbus3 > >>> Oct 21 01:15:20 gandalf kernel: umass0: >>> class 0/0, rev 2.10/10.10, addr 4> on usbus3 > >>> Oct 21 01:15:20 gandalf kernel: umass0: SCSI over Bulk-Only; quirks = > >>> 0x0000 > >>> Oct 21 01:15:21 gandalf kernel: umass0:9:0:-1: Attached to scbus9 > >>> Oct 21 01:15:28 gandalf kernel: da0 at umass-sim0 bus 0 scbus9 target > >>> 0 lun 0 > >>> Oct 21 01:15:28 gandalf kernel: da0: Fixed > >>> Direct Access SCSI-4 device > >>> Oct 21 01:15:28 gandalf kernel: da0: 40.000MB/s transfers > >>> Oct 21 01:15:28 gandalf kernel: da0: 953867MB (1953519616 512 byte > >>> sectors: 255H 63S/T 121600C) > >>> > >>> Output when plugging in 2.0 device into the 3.0 port: > >>> > >>> Oct 21 01:09:54 gandalf root: Unknown USB device: vendor 0x090c > >>> product 0x1000 bus uhub4 > >>> Oct 21 01:09:54 gandalf kernel: ugen4.2: at usbus4 > >>> Oct 21 01:09:54 gandalf kernel: umass1: >>> rev 2.00/11.00, addr 1> on usbus4 > >>> Oct 21 01:09:54 gandalf kernel: umass1: SCSI over Bulk-Only; quirks = > >>> 0x0000 > >>> Oct 21 01:09:55 gandalf kernel: umass1:10:1:-1: Attached to scbus10 > >>> Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): TEST UNIT > >>> READY. CDB: 0 0 0 0 0 0 > >>> Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): CAM status: > >>> SCSI Status Error > >>> Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): SCSI > >>> status: Check Condition > >>> Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): SCSI sense: > >>> UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have > >>> changed) > >>> Oct 21 01:09:56 gandalf kernel: da1 at umass-sim1 bus 1 scbus10 target > >>> 0 lun 0 > >>> Oct 21 01:09:56 gandalf kernel: da1: Fixed > >>> Direct Access SCSI-0 device > >>> Oct 21 01:09:56 gandalf kernel: da1: 40.000MB/s transfers > >>> Oct 21 01:09:56 gandalf kernel: da1: 956MB (1957888 512 byte sectors: > >>> 64H 32S/T 956C) > >>> > >>> --Michael > >> > >> ( I never got the last list email to this thread, so replying to my > >> own.) > >> > >> Hans, I added your suggestions and here's what I've found: > >> > >> There seems to be two issues. > >> > >> (1) > >> The first is initial recognition of the device. If I have umass > >> compiled in the kernel or as a module loaded by loader.conf, initial > >> load of xhci almost never finds the attached drive as the modules are > >> loaded. If I kldunload xhci then load it back in, umass finds the > >> drive. Re-loading or delaying the the load of xhci ( manual kldload or > >> in rc.local ) almost always finds the drive. Seems like order matters > >> here too. umass likes to be loaded first followed by xhci which then > >> triggers umass to see the drive. > >> > >> If both umass and xhci are compiled in the kernel, the drive is never > >> initialized. > >> > >> The good news is I can get the drive to be recognized by a > >> kldunload/kldload of xhci. > >> > >> (2) > >> One the drive is recognized I can see it and partition it using gpart. > >> However, when I start dumping data to the drive, the drive gets > >> disconnected. I was doing a dd if=/dev/zero of=/dev/da0 bs=1M > >> count=500. The initial dd would sometimes succeed. Running dd > >> imediately after the initial success would cause an error. > >> > >> Here's the tail output of umass debugging while the dd was running and > >> the device stopped: > >> > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_transfer_start: transfer > >> index = 4 > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_t_bbb_data_read_callback: > >> max_bulk=131072, data_rem=512 > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_t_bbb_data_read_callback: > >> max_bulk=131072, data_rem=0 > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_transfer_start: transfer > >> index = 8 > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_bbb_dump_csw: CSW 4049: sig > >> = 0x53425355 (valid), tag = 0x00000fd1, res = 0, status = 0x00 (good) > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_cam_action: > >> 7:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_bbb_dump_cbw: CBW 4050: cmd > >> = 10b (0x280000000000...), data = 512b, lun = 0, dir = in > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_transfer_start: transfer > >> index = 4 > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_t_bbb_data_read_callback: > >> max_bulk=131072, data_rem=512 > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_t_bbb_data_read_callback: > >> max_bulk=131072, data_rem=0 > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_transfer_start: transfer > >> index = 8 > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_bbb_dump_csw: CSW 4050: sig > >> = 0x53425355 (valid), tag = 0x00000fd2, res = 0, status = 0x00 (good) > >> Oct 22 17:44:19 gandalf kernel: umass0:umass_cam_action: > >> 7:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > >> Oct 22 17:44:23 gandalf kernel: umass0:umass_cam_action: > >> 7:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense > >> Oct 22 17:44:23 gandalf kernel: umass0:umass_bbb_dump_cbw: CBW 4051: cmd > >> = 10b (0x250000000000...), data = 8b, lun = 0, dir = in > >> Oct 22 17:44:23 gandalf kernel: ugen4.2: at usbus4 > >> (disconnected) > >> Oct 22 17:44:23 gandalf kernel: umass0: at uhub4, port 2, addr 1 > >> (disconnected) > >> Oct 22 17:44:23 gandalf kernel: umass0:umass_detach: > >> Oct 22 17:44:23 gandalf kernel: (da0:umass-sim0:0:0:0): AutoSense failed > >> Oct 22 17:44:23 gandalf kernel: (da0:umass-sim0:0:0:0): lost device > >> Oct 22 17:44:23 gandalf kernel: (da0:umass-sim0:0:0:0): removing device > >> entry > >> > >> I've saw there are quirks for the WESTERN MYBOOK . A added a specific > >> device into usbdevs and an entry into usb_quirk.c to mimic the same > >> quirks: > >> > >> USB_QUIRK(WESTERN, MYBOOK3, 0x0000, 0xffff, UQ_MSC_FORCE_WIRE_BBB, > >> > >> UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_NO_INQUIRY_EVPD, > >> UQ_MSC_NO_SYNC_CACHE), > >> > >> This didn't help, and I got the disconnect as shown above. > >> > >> --Michael > > > > Hi, > > > > Could you compile kernel with "options USB_DEBUG". > > > > Then run: > > > > sysctl hw.usb.uhub.debug=16 > > > > Then attach your drive. > > > > Maybe the USB stack is mistreating some event from the XHCI. Send the > > resulting dmesg. > > > > --HPS > > I set debug and plugged in the drive. Here's the output. > > --Michael Hi, Thanks for the debug output. Can you try to "svn up" to r214808. Then apply the following patch to: sys/dev/usb/usb_hub.c ================================================================== --- usb_hub.c (revision 214808) +++ usb_hub.c (local) @@ -609,6 +609,15 @@ case UPS_PORT_LS_U1: is_suspend = 0; break; + case UPS_PORT_LS_SS_INA: + /* Try a warm port reset to recover the port. */ + err = usbd_req_warm_reset_port(udev, NULL, portno); + if (err) { + DPRINTF("warm port reset failed.\n"); + goto done; + } + is_suspend = 0; + break; default: is_suspend = 1; break; Then build a new kernel. And send new debug output if your device does not work. --HPS From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 20:11:40 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F3E31065672; Thu, 4 Nov 2010 20:11:40 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A01588FC12; Thu, 4 Nov 2010 20:11:39 +0000 (UTC) Received: by yxl31 with SMTP id 31so1808006yxl.13 for ; Thu, 04 Nov 2010 13:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aMZNkIF9iVlGQqt1uYJpveDEPXRqgwgMV3juNw8lHVc=; b=bof83p7zSh8loU1jljLWlrzmnWbnZmGOVQTEWULbxFIBZ/7FTxByFe8Xp3bUpTggGj Dp+B/iyA5JsczjE4qBLn/CWoPzryt+RYwl49SoDVZoZJR7nQrmcdvxp9ahubeuWiD0Ad hHj2TI7ACzkVnAjaa/ZL8G6u5EVq9stEzeNWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=v36Ozpxmqlcl2vlCGYLLjRFENZR9EXPndpzn6FqP4TfXZ6kOEqPP5fnyT4ghyQ+ATQ mMa/e1drhQIi4LKuTwmigwjn6ZciO1RzZF38R6vhSZFJHFpM4SmUIqWva1qOwKMCMX7+ 59Yjgqdo49ABDSECfC//RUCJfANWoegPUlF6I= MIME-Version: 1.0 Received: by 10.42.97.67 with SMTP id m3mr731997icn.343.1288901498679; Thu, 04 Nov 2010 13:11:38 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 13:11:38 -0700 (PDT) In-Reply-To: <201011042011.44705.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011041941.09662.hselasky@c2i.net> <201011042011.44705.hselasky@c2i.net> Date: Thu, 4 Nov 2010 13:11:38 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 20:11:40 -0000 On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky wro= te: > On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: >> On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky > wrote: >> > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: >> >> =A0(and there is in Jeff's OFED branch) >> > >> > Is there a link to this branch? I would certainly have a look at his w= ork >> > and re-base my patch. >> >> It's on svn.freebsd.org: >> >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_task= que >> ue.c?view=3Dlog >> http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D209422 >> >> For the purpose of speed, I'm not opposed to breaking the KBI by using >> a doubly-linked TAILQ, but I don't think the difference will matter >> all that often (perhaps I'm wrong and some taskqueues have dozens of >> pending tasks?) >> >> Thanks, >> matthew > > At first look I see that I need a non-blocking version of: > > taskqueue_cancel( > > At the point in the code where these functions are called I cannot block.= Is > this impossible to implement? It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not possible to determine whether a task is running without taking the taskqueue lock. And it is certainly impossible to dequeue a task without the lock that was used to enqueue it. However, a variant that dequeued if the task was still pending, and returned failure otherwise (rather than sleeping) is definitely possible. Thanks, matthew From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 20:14:09 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 706F8106566B; Thu, 4 Nov 2010 20:14:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5ADBA8FC08; Thu, 4 Nov 2010 20:14:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=0QwtpmV1rXepT5CfuEUA:9 a=eS946g9CBUxHvd1zr24A:7 a=CZwjQWI-HvlaZHoSd6vtHMF60NkA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45433961; Thu, 04 Nov 2010 21:14:06 +0100 From: Hans Petter Selasky To: Matthew Fleming Date: Thu, 4 Nov 2010 21:15:16 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011042011.44705.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011042115.16187.hselasky@c2i.net> Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 20:14:09 -0000 On Thursday 04 November 2010 21:11:38 Matthew Fleming wrote: > On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky wrote: > > On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: > >> On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky > > > > wrote: > >> > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: > >> >> (and there is in Jeff's OFED branch) > >> > > >> > Is there a link to this branch? I would certainly have a look at his > >> > work and re-base my patch. > >> > >> It's on svn.freebsd.org: > >> > >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_task > >> que ue.c?view=log > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=209422 > >> > >> For the purpose of speed, I'm not opposed to breaking the KBI by using > >> a doubly-linked TAILQ, but I don't think the difference will matter > >> all that often (perhaps I'm wrong and some taskqueues have dozens of > >> pending tasks?) > >> > >> Thanks, > >> matthew > > > > At first look I see that I need a non-blocking version of: > > > > taskqueue_cancel( > > > > At the point in the code where these functions are called I cannot block. > > Is this impossible to implement? > > It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not > possible to determine whether a task is running without taking the > taskqueue lock. And it is certainly impossible to dequeue a task > without the lock that was used to enqueue it. > > However, a variant that dequeued if the task was still pending, and > returned failure otherwise (rather than sleeping) is definitely > possible. I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? --HPS From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 21:23:04 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AF90106564A; Thu, 4 Nov 2010 21:23:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 14DB98FC13; Thu, 4 Nov 2010 21:23:04 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AC24446B0D; Thu, 4 Nov 2010 17:23:03 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9BAD38A009; Thu, 4 Nov 2010 17:23:02 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 4 Nov 2010 17:22:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011042115.16187.hselasky@c2i.net> In-Reply-To: <201011042115.16187.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011041722.46673.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 04 Nov 2010 17:23:02 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 21:23:04 -0000 On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > On Thursday 04 November 2010 21:11:38 Matthew Fleming wrote: > > On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky > wrote: > > > On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: > > >> On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky > > > > > > wrote: > > >> > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: > > >> >> (and there is in Jeff's OFED branch) > > >> > > > >> > Is there a link to this branch? I would certainly have a look at his > > >> > work and re-base my patch. > > >> > > >> It's on svn.freebsd.org: > > >> > > >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_task > > >> que ue.c?view=log > > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=209422 > > >> > > >> For the purpose of speed, I'm not opposed to breaking the KBI by using > > >> a doubly-linked TAILQ, but I don't think the difference will matter > > >> all that often (perhaps I'm wrong and some taskqueues have dozens of > > >> pending tasks?) > > >> > > >> Thanks, > > >> matthew > > > > > > At first look I see that I need a non-blocking version of: > > > > > > taskqueue_cancel( > > > > > > At the point in the code where these functions are called I cannot block. > > > Is this impossible to implement? > > > > It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not > > possible to determine whether a task is running without taking the > > taskqueue lock. And it is certainly impossible to dequeue a task > > without the lock that was used to enqueue it. > > > > However, a variant that dequeued if the task was still pending, and > > returned failure otherwise (rather than sleeping) is definitely > > possible. > > I think that if a task is currently executing, then there should be a drain > method for that. I.E. two methods: One to stop and one to cancel/drain. Can > you implement this? I agree, this would also be consistent with the callout_*() API if you had both "stop()" and "drain()" methods. -- John Baldwin From owner-freebsd-usb@FreeBSD.ORG Thu Nov 4 21:49:24 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 176771065701; Thu, 4 Nov 2010 21:49:24 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 730798FC14; Thu, 4 Nov 2010 21:49:23 +0000 (UTC) Received: by gwj16 with SMTP id 16so1890883gwj.13 for ; Thu, 04 Nov 2010 14:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=y5OWkyV0yWOgrJoXXzsMGOw+u+lerBuuB68hIWvCy20=; b=RImZJ053F2jMX3McwHgNha06a1oquosW3mUcVyDYtk3SSbExv0r6H7sWE9HTrmY8hM 66kLZO3FaPGPL1CwwLiCYgqjSGV5bIKLzNpjVCe3JPIgdd4nvaedznesRut/FQs/M06z igr8n4IMQYYZKc+4VwjGP0QPY8ryZBE5y3KCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qWa94M36Byq7C0OS+BuSi8WSfDGJHFlkPcQ5jZi23oDSqRXS0nDgDT4yTjJ3EMmvpX hk/6EJN4C0A5ZsePlAGE5z7DWTiZIe2gXq4WNHmTFYJgqVRvwip6K4TgLXnkjH6ZpB/E sv8lof1UM+BhXYDrgAfDgLm9qeSFaADQTCCdE= MIME-Version: 1.0 Received: by 10.42.193.17 with SMTP id ds17mr926521icb.276.1288907362527; Thu, 04 Nov 2010 14:49:22 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Thu, 4 Nov 2010 14:49:22 -0700 (PDT) In-Reply-To: <201011041722.46673.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011042115.16187.hselasky@c2i.net> <201011041722.46673.jhb@freebsd.org> Date: Thu, 4 Nov 2010 14:49:22 -0700 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-usb@freebsd.org, freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 21:49:24 -0000 On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: >> I think that if a task is currently executing, then there should be a drain >> method for that. I.E. two methods: One to stop and one to cancel/drain. Can >> you implement this? > > I agree, this would also be consistent with the callout_*() API if you had > both "stop()" and "drain()" methods. Here's my proposed code. Note that this builds but is not yet tested. Implement a taskqueue_cancel(9), to cancel a task from a queue. Requested by: hps Original code: jeff MFC after: 1 week http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff Thanks, matthew From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 13:02:49 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB301106566C; Fri, 5 Nov 2010 13:02:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 97F968FC15; Fri, 5 Nov 2010 13:02:49 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 44EFF46B03; Fri, 5 Nov 2010 09:02:49 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 13C648A009; Fri, 5 Nov 2010 09:02:48 -0400 (EDT) From: John Baldwin To: Matthew Fleming Date: Fri, 5 Nov 2010 08:58:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011041722.46673.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011050858.33568.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 09:02:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 13:02:50 -0000 On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: > On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > >> I think that if a task is currently executing, then there should be a drain > >> method for that. I.E. two methods: One to stop and one to cancel/drain. Can > >> you implement this? > > > > I agree, this would also be consistent with the callout_*() API if you had > > both "stop()" and "drain()" methods. > > Here's my proposed code. Note that this builds but is not yet tested. > > > Implement a taskqueue_cancel(9), to cancel a task from a queue. > > Requested by: hps > Original code: jeff > MFC after: 1 week > > > http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I would prefer that it follow the semantics of callout_stop() and return true if it stopped the task and false otherwise. The Linux wrapper for taskqueue_cancel() can convert the return value. I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) for this blocking flag. In the case of callout(9) we just have two functions that pass an internal boolean to the real routine (callout_stop() and callout_drain() are wrappers for _callout_stop_safe()). It is a bit unfortunate that taskqueue_drain() already exists and has different semantics than callout_drain(). It would have been nice to have the two APIs mirror each other instead. Hmm, I wonder if the blocking behavior cannot safely be provided by just doing: if (!taskqueue_cancel(queue, task, M_NOWAIT) taskqueue_drain(queue, task); If that works ok (I think it does), I would rather have taskqueue_cancel() always be non-blocking. Even though there is a "race" where the task could be rescheduled by another thread in between cancel and drain, the race still exists since if the task could be scheduled between the two, it could also be scheduled just before the call to taskqueue_cancel() (in which case a taskqueue_cancel(queue, task, M_WAITOK) would have blocked to wait for it matching the taskqueue_drain() above). The caller still always has to provide synchronization for preventing a task's execution outright via their own locking. -- John Baldwin From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 13:50:11 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFF81106564A; Fri, 5 Nov 2010 13:50:11 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3829D8FC16; Fri, 5 Nov 2010 13:50:11 +0000 (UTC) Received: by gxk9 with SMTP id 9so2227881gxk.13 for ; Fri, 05 Nov 2010 06:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yIl7S6Pklw/SCH6aYHWJXvN1x24XuLiY+mRktHJI5+4=; b=B/d0MBW2L/87bSreHOi3atmmuFVloL1pVxaxy5j95LuTPr2Qna9mmEz8a6B6sNc/am wFaAnFP49R4HlckuKsZwR+vyUW1IvX1FG7WUV3GrUjnBKnkAylx8K6UedAf3W3+nn874 Ab/uuQEaD93oxKb+UItcowNAp/te7CFMjvVco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MUXkDTTBUlNY4H2xPpUDjbHUCB5wzujANiIZx0H+szwh/fLMoBgl6vMEEJ1fX56+fb AIW1hL81CByB+uxarwwycFNjXyDwVGfLu6qiBag2mSwzIhfwwA8cVYyilsg9KJx516N1 B0Dlol/aUiAEUF13b3pUrQlQ/4Tx8haFpre7w= MIME-Version: 1.0 Received: by 10.42.22.69 with SMTP id n5mr1088729icb.477.1288965010417; Fri, 05 Nov 2010 06:50:10 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 06:50:10 -0700 (PDT) In-Reply-To: <201011050858.33568.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011041722.46673.jhb@freebsd.org> <201011050858.33568.jhb@freebsd.org> Date: Fri, 5 Nov 2010 06:50:10 -0700 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 13:50:12 -0000 On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: >> >> I think that if a task is currently executing, then there should be a= drain >> >> method for that. I.E. two methods: One to stop and one to cancel/drai= n. Can >> >> you implement this? >> > >> > I agree, this would also be consistent with the callout_*() API if you= had >> > both "stop()" and "drain()" methods. >> >> Here's my proposed code. =A0Note that this builds but is not yet tested. >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. >> >> Requested by: =A0 =A0 =A0 hps >> Original code: =A0 =A0 =A0jeff >> MFC after: =A01 week >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff > > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. =A0Howeve= r, I > would prefer that it follow the semantics of callout_stop() and return tr= ue > if it stopped the task and false otherwise. =A0The Linux wrapper for > taskqueue_cancel() can convert the return value. I used -EBUSY since positive return values reflect the old pending count. ta_pending was zero'd, and I think needs to be to keep the task sane, because all of taskqueue(9) assumes a non-zero ta_pending means the task is queued. I don't know that the caller often needs to know the old value of ta_pending, but it seems simpler to return that as the return value and use -EBUSY than to use an optional pointer to a place to store the old ta_pending just so we can keep the error return positive. Note that phk (IIRC) suggested using -error in the returns for sbuf_drain to indicate the difference between success (> 0 bytes drained) and an error, so FreeBSD now has precedent. I'm not entirely sure that's a good thing, since I am not generally fond of Linux's use of -error, but for some cases it is convenient. But, I'll do this one either way, just let me know if the above hasn't convinced you. > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAI= TOK) > for this blocking flag. =A0In the case of callout(9) we just have two fun= ctions > that pass an internal boolean to the real routine (callout_stop() and > callout_drain() are wrappers for _callout_stop_safe()). =A0It is a bit > unfortunate that taskqueue_drain() already exists and has different seman= tics > than callout_drain(). =A0It would have been nice to have the two APIs mir= ror each > other instead. > > Hmm, I wonder if the blocking behavior cannot safely be provided by just > doing: > > =A0 =A0 =A0 =A0if (!taskqueue_cancel(queue, task, M_NOWAIT) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_drain(queue, task); This seems reasonable and correct. I will add a note to the manpage about = this. Thanks, matthew > > If that works ok (I think it does), I would rather have taskqueue_cancel(= ) > always be non-blocking. =A0Even though there is a "race" where the task c= ould > be rescheduled by another thread in between cancel and drain, the race st= ill > exists since if the task could be scheduled between the two, it could als= o > be scheduled just before the call to taskqueue_cancel() (in which case a > taskqueue_cancel(queue, task, M_WAITOK) would have blocked to wait for it > matching the taskqueue_drain() above). =A0The caller still always has to > provide synchronization for preventing a task's execution outright via th= eir > own locking. > > -- > John Baldwin > From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 14:22:17 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56EDB106564A; Fri, 5 Nov 2010 14:22:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA618FC15; Fri, 5 Nov 2010 14:22:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 84A0246B37; Fri, 5 Nov 2010 10:22:16 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 806658A009; Fri, 5 Nov 2010 10:22:15 -0400 (EDT) From: John Baldwin To: Matthew Fleming Date: Fri, 5 Nov 2010 10:18:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011050858.33568.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051018.28860.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 10:22:15 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 14:22:17 -0000 On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: > On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: > > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: > >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > >> >> I think that if a task is currently executing, then there should be a drain > >> >> method for that. I.E. two methods: One to stop and one to cancel/drain. Can > >> >> you implement this? > >> > > >> > I agree, this would also be consistent with the callout_*() API if you had > >> > both "stop()" and "drain()" methods. > >> > >> Here's my proposed code. Note that this builds but is not yet tested. > >> > >> > >> Implement a taskqueue_cancel(9), to cancel a task from a queue. > >> > >> Requested by: hps > >> Original code: jeff > >> MFC after: 1 week > >> > >> > >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff > > > > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I > > would prefer that it follow the semantics of callout_stop() and return true > > if it stopped the task and false otherwise. The Linux wrapper for > > taskqueue_cancel() can convert the return value. > > I used -EBUSY since positive return values reflect the old pending > count. ta_pending was zero'd, and I think needs to be to keep the > task sane, because all of taskqueue(9) assumes a non-zero ta_pending > means the task is queued. > > I don't know that the caller often needs to know the old value of > ta_pending, but it seems simpler to return that as the return value > and use -EBUSY than to use an optional pointer to a place to store the > old ta_pending just so we can keep the error return positive. > > Note that phk (IIRC) suggested using -error in the returns for > sbuf_drain to indicate the difference between success (> 0 bytes > drained) and an error, so FreeBSD now has precedent. I'm not entirely > sure that's a good thing, since I am not generally fond of Linux's use > of -error, but for some cases it is convenient. > > But, I'll do this one either way, just let me know if the above hasn't > convinced you. Hmm, I hadn't considered if callers would want to know the pending count of the cancelled task. > > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) > > for this blocking flag. In the case of callout(9) we just have two functions > > that pass an internal boolean to the real routine (callout_stop() and > > callout_drain() are wrappers for _callout_stop_safe()). It is a bit > > unfortunate that taskqueue_drain() already exists and has different semantics > > than callout_drain(). It would have been nice to have the two APIs mirror each > > other instead. > > > > Hmm, I wonder if the blocking behavior cannot safely be provided by just > > doing: > > > > if (!taskqueue_cancel(queue, task, M_NOWAIT) > > taskqueue_drain(queue, task); > > This seems reasonable and correct. I will add a note to the manpage about this. In that case, would you be fine with dropping the blocking functionality from taskqueue_cancel() completely and requiring code that wants the blocking semantics to use a cancel followed by a drain? -- John Baldwin From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 14:42:11 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2415C106564A; Fri, 5 Nov 2010 14:42:11 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 762578FC19; Fri, 5 Nov 2010 14:42:10 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3A3BC.dip.t-dialin.net [87.179.163.188]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 8877784400A; Fri, 5 Nov 2010 15:42:05 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 52DA325F2; Fri, 5 Nov 2010 15:42:02 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id oA5Efv9u044085; Fri, 5 Nov 2010 15:41:57 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 05 Nov 2010 15:41:56 +0100 Message-ID: <20101105154156.12764ne6zf5rahs0@webmail.leidinger.net> Date: Fri, 05 Nov 2010 15:41:56 +0100 From: Alexander Leidinger To: Hans Petter Selasky References: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> <201011021036.41617.hselasky@freebsd.org> In-Reply-To: <201011021036.41617.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 8877784400A.A64FC X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=3.228, required 6, autolearn=disabled, J_CHICKENPOX_24 0.60, J_CHICKENPOX_32 0.60, J_CHICKENPOX_34 0.60, RDNS_NONE 1.27, TW_UH 0.08, TW_XD 0.08) X-EBL-MailScanner-SpamScore: sss X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1289572926.37056@bbT0L77HQ6LPaBPgVBugBQ X-EBL-Spam-Status: No Cc: Alexander Motin , freebsd-usb@freebsd.org Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 14:42:11 -0000 Quoting Hans Petter Selasky (from Tue, 2 Nov 2010 10:36:41 +0100): > On Tuesday 02 November 2010 10:32:08 Alexander Leidinger wrote: >> Hi, >> >> I have a memory stick which made problems (the stick is used as a ZFS >> cache and it moaned about 8xxM write problems) in 9-current r214509. I >> removed the device from the config, made a camcontrol reset all, >> camcontrol rescan all (-> device disappeared), and then tried an >> usbconfig reset ugen4.2 (relevant devlist part from before the call is >> below). The usbconfig reset does not return to the shell. >> >> I do not know if the problem with the USB memory stick is related to >> software or hardware. The stick survived just a weekend, I replaced it >> because the old one showed similar problems after surviving about 9 >> months... I updated -current just before the problems appeared (and >> then again after a week or two), but I do not remember from which >> revision of -current I was updating from. I will try to stress-test >> the memory sticks on a 8.1 system so see if it is some software problem. >> >> The big question I have for now is: shouldn't there be some kind of >> safety mechanism kicking in (timeout) with the usbconfig command (in >> this case the reset)? >> >> devlist: >> ---snip--- >> ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=SAVE >> ugen4.2: at usbus4, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=ON >> ---snip--- >> >> dmesg | grep -i usb: >> ---snip--- >> uhci0: port 0xdc00-0xdc1f >> irq 16 at device 29.0 on pci0 >> usbus0: on uhci0 >> uhci1: port 0xe000-0xe01f >> irq 19 at device 29.1 on pci0 >> usbus1: on uhci1 >> uhci2: port 0xe400-0xe41f >> irq 18 at device 29.2 on pci0 >> usbus2: on uhci2 >> uhci3: port 0xe800-0xe81f >> irq 16 at device 29.3 on pci0 >> usbus3: on uhci3 >> ehci0: mem >> 0xfe77fc00-0xfe77ffff irq 23 at device 29.7 on pci0 >> usbus4: EHCI version 1.0 >> usbus4: on ehci0 >> usbus0: 12Mbps Full Speed USB v1.0 >> usbus1: 12Mbps Full Speed USB v1.0 >> usbus2: 12Mbps Full Speed USB v1.0 >> usbus3: 12Mbps Full Speed USB v1.0 >> usbus4: 480Mbps High Speed USB v2.0 >> ugen0.1: at usbus0 >> uhub0: on usbus0 >> ugen1.1: at usbus1 >> uhub1: on usbus1 >> ugen2.1: at usbus2 >> uhub2: on usbus2 >> ugen3.1: at usbus3 >> uhub3: on usbus3 >> ugen4.1: at usbus4 >> uhub4: on usbus4 >> Root mount waiting for: usbus4 >> Root mount waiting for: usbus4 >> Root mount waiting for: usbus4 >> Root mount waiting for: usbus4 >> ugen4.2: at usbus4 >> umass0: on usbus4 >> Root mount waiting for: usbus4 >> pass3: Removable Direct Access SCSI-2 device >> da0: Removable Direct Access SCSI-2 device >> Root mount waiting for: usbus4 >> ugen1.2: at usbus1 >> ugen1.3: at usbus1 >> ulpt0: > 3> on usbus1 >> ugen2.2: at usbus2 >> uhub5: > addr 2> on usbus2 >> ugen2.3: at usbus2 >> ukbd0: > addr 3> on usbus2 >> ugen2.4: at usbus2 >> ums0: > addr 4> on usbus2 >> ---snip--- > > Hi, > > If you dump all threads in this state I think you will see that USB > is waiting > somewhere in umass_detach(), which is preventing the usbconfig reset from > grabbing the SX-lock associated with serialisation. Because umass_detach() is > not returning we are stuck. I made some tests. I've used the initial stick in question on Solaris 10u9 (no ZFS errors for several postmark runs) and FreeBSD 9 (r214509, own zpool with only the stick, one postmark run and I get I/O errors -> any access to the stick hangs now due to 'failmode=wait'). On FreeBSD 9 as of r212247 I do not have problems with the second stick with which I experienced errors more quickly. I do not know yet if this is because of failed hardware, or because of a problem in the USB stack. As the first traces of this appeared after an update, I lean towards a regression... I will have a look at getting some time to update the older FreeBSD 9 system to something in between the working and not working version. Bye, Alexander. -- There must be at least 500,000,000 rats in the United States; of course, I never heard the story before. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 17:15:03 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DFBF1065670; Fri, 5 Nov 2010 17:15:03 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B19B58FC1B; Fri, 5 Nov 2010 17:15:02 +0000 (UTC) Received: by gya6 with SMTP id 6so2387413gya.13 for ; Fri, 05 Nov 2010 10:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VxEAITq6iW6923DUMnI8WPm53m8GXLHaC47ypEY4544=; b=gxfxLyi6WvH5ihTkco42ygIrz2EG4P/ZwoiYeHvS0mc0CB8idVzF/bapNukHxaLz/Z 7oibcCB3VaFyeQRbhnfCkoq8mD6RigqBAVGf2siUc+lIc19I7dyUJkV1EBhKAL/UWMvY 106XGEHuhaRaO1CDJL4Nk6gzlizfl8C+HEASw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B8WxiybCw03FjnlaDcMTTiGqADLtjDKTUBVe28XLTRcLfTiKa+cLAHEy2Lcvg98Trx ux0+BohG5auOALzhvha0pkXcqVVM3xMdjLSWA6rBMNPtJizjEnvDWMIpnV7dtOBxSijX YRtNFRAiG+i1+XyYKglBxxSVULP9MRLZFm+KI= MIME-Version: 1.0 Received: by 10.42.193.17 with SMTP id ds17mr1600934icb.276.1288977301642; Fri, 05 Nov 2010 10:15:01 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 10:15:01 -0700 (PDT) In-Reply-To: <201011051018.28860.jhb@freebsd.org> References: <201011012054.59551.hselasky@c2i.net> <201011050858.33568.jhb@freebsd.org> <201011051018.28860.jhb@freebsd.org> Date: Fri, 5 Nov 2010 10:15:01 -0700 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 17:15:03 -0000 On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote= : >> >> >> I think that if a task is currently executing, then there should b= e a drain >> >> >> method for that. I.E. two methods: One to stop and one to cancel/d= rain. Can >> >> >> you implement this? >> >> > >> >> > I agree, this would also be consistent with the callout_*() API if = you had >> >> > both "stop()" and "drain()" methods. >> >> >> >> Here's my proposed code. =A0Note that this builds but is not yet test= ed. >> >> >> >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. >> >> >> >> Requested by: =A0 =A0 =A0 hps >> >> Original code: =A0 =A0 =A0jeff >> >> MFC after: =A01 week >> >> >> >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff >> > >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. =A0How= ever, I >> > would prefer that it follow the semantics of callout_stop() and return= true >> > if it stopped the task and false otherwise. =A0The Linux wrapper for >> > taskqueue_cancel() can convert the return value. >> >> I used -EBUSY since positive return values reflect the old pending >> count. =A0ta_pending was zero'd, and I think needs to be to keep the >> task sane, because all of taskqueue(9) assumes a non-zero ta_pending >> means the task is queued. >> >> I don't know that the caller often needs to know the old value of >> ta_pending, but it seems simpler to return that as the return value >> and use -EBUSY than to use an optional pointer to a place to store the >> old ta_pending just so we can keep the error return positive. >> >> Note that phk (IIRC) suggested using -error in the returns for >> sbuf_drain to indicate the difference between success (> 0 bytes >> drained) and an error, so FreeBSD now has precedent. =A0I'm not entirely >> sure that's a good thing, since I am not generally fond of Linux's use >> of -error, but for some cases it is convenient. >> >> But, I'll do this one either way, just let me know if the above hasn't >> convinced you. > > Hmm, I hadn't considered if callers would want to know the pending count = of > the cancelled task. > >> > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_= WAITOK) >> > for this blocking flag. =A0In the case of callout(9) we just have two = functions >> > that pass an internal boolean to the real routine (callout_stop() and >> > callout_drain() are wrappers for _callout_stop_safe()). =A0It is a bit >> > unfortunate that taskqueue_drain() already exists and has different se= mantics >> > than callout_drain(). =A0It would have been nice to have the two APIs = mirror each >> > other instead. >> > >> > Hmm, I wonder if the blocking behavior cannot safely be provided by ju= st >> > doing: >> > >> > =A0 =A0 =A0 =A0if (!taskqueue_cancel(queue, task, M_NOWAIT) >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_drain(queue, task); >> >> This seems reasonable and correct. =A0I will add a note to the manpage a= bout this. > > In that case, would you be fine with dropping the blocking functionality = from > taskqueue_cancel() completely and requiring code that wants the blocking > semantics to use a cancel followed by a drain? New patch is at http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-cancel-= a-task-from-a.patch I'll try to set up something to test it today too. Thanks, matthew From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 17:35:34 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51B0E1065675; Fri, 5 Nov 2010 17:35:34 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 1015A8FC12; Fri, 5 Nov 2010 17:35:32 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=iBCGAMPDYtSF9sDXX85uHY3wcnYctfVT8vFpe3qPflY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=24NoxT-kmLX8QFLnx5MA:9 a=g0NIqYagmTlxspyxPIgA:7 a=LFkYILy1PJmkOeKz3kPsMjiUSV0A:4 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45334299; Fri, 05 Nov 2010 18:35:31 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 18:36:39 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051018.28860.jhb@freebsd.org> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051836.39697.hselasky@c2i.net> Cc: Matthew Fleming , freebsd-usb@freebsd.org, John Baldwin , Weongyo Jeong , freebsd-current@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 17:35:34 -0000 On Friday 05 November 2010 18:15:01 Matthew Fleming wrote: > On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: > > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: > >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: > >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: > >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > >> >> >> I think that if a task is currently executing, then there should > >> >> >> be a drain method for that. I.E. two methods: One to stop and one > >> >> >> to cancel/drain. Can you implement this? > >> >> > > >> >> > I agree, this would also be consistent with the callout_*() API if > >> >> > you had both "stop()" and "drain()" methods. > >> >> > >> >> Here's my proposed code. Note that this builds but is not yet > >> >> tested. > >> >> > >> >> > >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. > >> >> > >> >> Requested by: hps > >> >> Original code: jeff > >> >> MFC after: 1 week > >> >> > >> >> > >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff > >> > > >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. > >> > However, I would prefer that it follow the semantics of > >> > callout_stop() and return true if it stopped the task and false > >> > otherwise. The Linux wrapper for taskqueue_cancel() can convert the > >> > return value. > >> > >> I used -EBUSY since positive return values reflect the old pending > >> count. ta_pending was zero'd, and I think needs to be to keep the > >> task sane, because all of taskqueue(9) assumes a non-zero ta_pending > >> means the task is queued. > >> > >> I don't know that the caller often needs to know the old value of > >> ta_pending, but it seems simpler to return that as the return value > >> and use -EBUSY than to use an optional pointer to a place to store the > >> old ta_pending just so we can keep the error return positive. > >> > >> Note that phk (IIRC) suggested using -error in the returns for > >> sbuf_drain to indicate the difference between success (> 0 bytes > >> drained) and an error, so FreeBSD now has precedent. I'm not entirely > >> sure that's a good thing, since I am not generally fond of Linux's use > >> of -error, but for some cases it is convenient. > >> > >> But, I'll do this one either way, just let me know if the above hasn't > >> convinced you. > > > > Hmm, I hadn't considered if callers would want to know the pending count > > of the cancelled task. > > > >> > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / > >> > M_WAITOK) for this blocking flag. In the case of callout(9) we just > >> > have two functions that pass an internal boolean to the real routine > >> > (callout_stop() and callout_drain() are wrappers for > >> > _callout_stop_safe()). It is a bit unfortunate that > >> > taskqueue_drain() already exists and has different semantics than > >> > callout_drain(). It would have been nice to have the two APIs mirror > >> > each other instead. > >> > > >> > Hmm, I wonder if the blocking behavior cannot safely be provided by > >> > just doing: > >> > > >> > if (!taskqueue_cancel(queue, task, M_NOWAIT) > >> > taskqueue_drain(queue, task); > >> > >> This seems reasonable and correct. I will add a note to the manpage > >> about this. > > > > In that case, would you be fine with dropping the blocking functionality > > from taskqueue_cancel() completely and requiring code that wants the > > blocking semantics to use a cancel followed by a drain? > > New patch is at > http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-cancel- > a-task-from-a.patch I think the: + if (!task_is_running(queue, task)) { check needs to be omitted. Else you block the possibility of enqueue and cancel a task while it is actually executing/running ?? --HPS From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 18:13:10 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5515106566B; Fri, 5 Nov 2010 18:13:10 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1B68FC15; Fri, 5 Nov 2010 18:13:09 +0000 (UTC) Received: by iwn39 with SMTP id 39so3109127iwn.13 for ; Fri, 05 Nov 2010 11:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5a8cIMwwtaVrYIj5jLPK00hC6AwQ8rbk9A+Q73qydtc=; b=jY/EDRFqecOWlKMh55HRUBWcJU1hzIgxLugVhyKYA7bNHPkX09DDikZd+j0G8sFJm5 BaOB7dbZKkD408Z7J0UQ5/wlrTCwmin/TDhkFi2dZncS56btvbNhU5/KWMU3UcdbzjxT zqJWIf68niCB1rySdzag79K3FKU9LoZ2vcvyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Mp4QjUA4/DtYbCeAiL4z2FzdZaxYjqntgMNfpH8bW5uC6GqWv+c4oWX6wiwwdTc5G5 oyPrHf6y/OKA4QEBWqjrMkA8zWVSf8jA7IKIdbkTrEe4/sXdUI5ihXmafF3OWB+9z25X 1m1UGuyLuWuOgC6vDJFJ6BRDsHZv7Egi9CHro= MIME-Version: 1.0 Received: by 10.231.36.11 with SMTP id r11mr2010293ibd.58.1288980788700; Fri, 05 Nov 2010 11:13:08 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 11:13:08 -0700 (PDT) In-Reply-To: <201011051836.39697.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011051018.28860.jhb@freebsd.org> <201011051836.39697.hselasky@c2i.net> Date: Fri, 5 Nov 2010 11:13:08 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-usb@freebsd.org, John Baldwin , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:13:10 -0000 On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky wro= te: > On Friday 05 November 2010 18:15:01 Matthew Fleming wrote: >> On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: >> > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: >> >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: >> >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: >> >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wro= te: >> >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wr= ote: >> >> >> >> I think that if a task is currently executing, then there shoul= d >> >> >> >> be a drain method for that. I.E. two methods: One to stop and o= ne >> >> >> >> to cancel/drain. Can you implement this? >> >> >> > >> >> >> > I agree, this would also be consistent with the callout_*() API = if >> >> >> > you had both "stop()" and "drain()" methods. >> >> >> >> >> >> Here's my proposed code. =A0Note that this builds but is not yet >> >> >> tested. >> >> >> >> >> >> >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. >> >> >> >> >> >> Requested by: =A0 =A0 =A0 hps >> >> >> Original code: =A0 =A0 =A0jeff >> >> >> MFC after: =A01 week >> >> >> >> >> >> >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff >> >> > >> >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. >> >> > =A0However, I would prefer that it follow the semantics of >> >> > callout_stop() and return true if it stopped the task and false >> >> > otherwise. =A0The Linux wrapper for taskqueue_cancel() can convert = the >> >> > return value. >> >> >> >> I used -EBUSY since positive return values reflect the old pending >> >> count. =A0ta_pending was zero'd, and I think needs to be to keep the >> >> task sane, because all of taskqueue(9) assumes a non-zero ta_pending >> >> means the task is queued. >> >> >> >> I don't know that the caller often needs to know the old value of >> >> ta_pending, but it seems simpler to return that as the return value >> >> and use -EBUSY than to use an optional pointer to a place to store th= e >> >> old ta_pending just so we can keep the error return positive. >> >> >> >> Note that phk (IIRC) suggested using -error in the returns for >> >> sbuf_drain to indicate the difference between success (> 0 bytes >> >> drained) and an error, so FreeBSD now has precedent. =A0I'm not entir= ely >> >> sure that's a good thing, since I am not generally fond of Linux's us= e >> >> of -error, but for some cases it is convenient. >> >> >> >> But, I'll do this one either way, just let me know if the above hasn'= t >> >> convinced you. >> > >> > Hmm, I hadn't considered if callers would want to know the pending cou= nt >> > of the cancelled task. >> > >> >> > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / >> >> > M_WAITOK) for this blocking flag. =A0In the case of callout(9) we j= ust >> >> > have two functions that pass an internal boolean to the real routin= e >> >> > (callout_stop() and callout_drain() are wrappers for >> >> > _callout_stop_safe()). =A0It is a bit unfortunate that >> >> > taskqueue_drain() already exists and has different semantics than >> >> > callout_drain(). =A0It would have been nice to have the two APIs mi= rror >> >> > each other instead. >> >> > >> >> > Hmm, I wonder if the blocking behavior cannot safely be provided by >> >> > just doing: >> >> > >> >> > =A0 =A0 =A0 =A0if (!taskqueue_cancel(queue, task, M_NOWAIT) >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_drain(queue, task); >> >> >> >> This seems reasonable and correct. =A0I will add a note to the manpag= e >> >> about this. >> > >> > In that case, would you be fine with dropping the blocking functionali= ty >> > from taskqueue_cancel() completely and requiring code that wants the >> > blocking semantics to use a cancel followed by a drain? >> >> New patch is at >> http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-canc= el- >> a-task-from-a.patch > > I think the: > > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { > > check needs to be omitted. Else you block the possibility of enqueue and > cancel a task while it is actually executing/running ?? Huh? If the task is currently running, there's nothing to do except return failure. Task running means it can't be canceled, because... it's running. Thanks, matthew From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 18:29:32 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2C5B106566C; Fri, 5 Nov 2010 18:29:32 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id D42F58FC1A; Fri, 5 Nov 2010 18:29:31 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=FberXtVRn-wA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=Cw8rU7oRz3VboNDMIlAA:9 a=MUlSQjhuJp0JbwSJUxwIolEPeYMA:4 a=wPNLvfGTeEIA:10 a=FcgzJa1LcXe6IDLysl4A:9 a=XnCYU3IuQVv1LWxiYhsA:7 a=klG2om15o0QNuV1ZETSHBZYqC58A:4 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45156194; Fri, 05 Nov 2010 19:29:30 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 5 Nov 2010 19:30:38 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051836.39697.hselasky@c2i.net> In-Reply-To: <201011051836.39697.hselasky@c2i.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_O1E1M5DxgzaX2zh" Message-Id: <201011051930.38530.hselasky@c2i.net> Cc: Weongyo Jeong , Matthew Fleming , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:29:32 -0000 --Boundary-00=_O1E1M5DxgzaX2zh Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, In the patch attached to this e-mail I included Matthew Fleming's patch aswell. 1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles the words of the callout and USB API's terminology for doing the same. 2) I turns out I need to have code in subr_taskqueue.c to be able to make the operations atomic. 3) I did not update the manpage in this patch. Will do that before a commit. 4) My patch implements separate state keeping in "struct task_pair", which avoids having to change any KPI's for now, like suggested by John Baldwin I think. 5) In my implementation I hard-coded the priority argument to zero, so that enqueuing is fast. Comments are welcome! --HPS --Boundary-00=_O1E1M5DxgzaX2zh Content-Type: text/x-patch; charset="iso-8859-1"; name="0001-Implement-taskqueue_pair.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="0001-Implement-taskqueue_pair.patch" === kern/subr_taskqueue.c ================================================================== --- kern/subr_taskqueue.c (revision 214796) +++ kern/subr_taskqueue.c (local) @@ -275,6 +275,25 @@ return (0); } +int +taskqueue_stop(struct taskqueue *queue, struct task *task) +{ + int retval = 0; + + TQ_LOCK(queue); + + if (task->ta_pending != 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (task_is_running(queue, task)) + retval = EBUSY; + + TQ_UNLOCK(queue); + + return (retval); +} + void taskqueue_drain(struct taskqueue *queue, struct task *task) { @@ -288,6 +307,113 @@ TQ_UNLOCK(queue); } + +int +taskqueue_pair_enqueue(struct taskqueue *queue, struct task_pair *tp) +{ + struct task *task; + int retval; + int j; + + TQ_LOCK(queue); + + j = 0; + if (tp->tp_task[0].ta_pending > 0) + j |= 1; + if (tp->tp_task[1].ta_pending > 0) + j |= 2; + + if (j == 0) { + /* No entries are queued. Just pick a last task. */ + tp->tp_last = 0; + /* Re-queue the last queued task. */ + task = &tp->tp_task[0]; + } else if (j == 1) { + /* There is only one task pending and the other becomes last. */ + tp->tp_last = 1; + /* Re-queue the last queued task. */ + task = &tp->tp_task[1]; + } else if (j == 2) { + /* There is only one task pending and the other becomes last. */ + tp->tp_last = 0; + /* Re-queue the last queued task. */ + task = &tp->tp_task[0]; + } else { + /* Re-queue the last queued task. */ + task = &tp->tp_task[tp->tp_last]; + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + } + + STAILQ_INSERT_TAIL(&queue->tq_queue, task, ta_link); + + retval = tp->tp_last + 1; + /* store the actual order in the pending count */ + task->ta_pending = retval; + + if ((queue->tq_flags & TQ_FLAGS_BLOCKED) == 0) + queue->tq_enqueue(queue->tq_context); + else + queue->tq_flags |= TQ_FLAGS_PENDING; + + TQ_UNLOCK(queue); + + return (retval); +} + +int +taskqueue_pair_stop(struct taskqueue *queue, struct task_pair *tp) +{ + struct task *task; + int retval = 0; + + TQ_LOCK(queue); + + task = &tp->tp_task[0]; + if (task->ta_pending != 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (task_is_running(queue, task)) + retval = EBUSY; + + task = &tp->tp_task[1]; + if (task->ta_pending != 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (task_is_running(queue, task)) + retval = EBUSY; + + TQ_UNLOCK(queue); + + return (retval); +} + +void +taskqueue_pair_drain(struct taskqueue *queue, struct task_pair *tp) +{ + struct task *task; + + if (!queue->tq_spin) + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); + + TQ_LOCK(queue); +top: + task = &tp->tp_task[0]; + if (task->ta_pending != 0 || task_is_running(queue, task)) { + TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, "-", 0); + goto top; + } + + task = &tp->tp_task[1]; + if (task->ta_pending != 0 || task_is_running(queue, task)) { + TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, "-", 0); + goto top; + } + + TQ_UNLOCK(queue); +} + static void taskqueue_swi_enqueue(void *context) { === sys/_task.h ================================================================== --- sys/_task.h (revision 214796) +++ sys/_task.h (local) @@ -51,4 +51,9 @@ void *ta_context; /* (c) argument for handler */ }; +struct task_pair { + struct task tp_task[2]; + int tp_last; /* (q) index of last queued task */ +}; + #endif /* !_SYS__TASK_H_ */ === sys/taskqueue.h ================================================================== --- sys/taskqueue.h (revision 214796) +++ sys/taskqueue.h (local) @@ -53,7 +53,11 @@ void *context); int taskqueue_start_threads(struct taskqueue **tqp, int count, int pri, const char *name, ...) __printflike(4, 5); +int taskqueue_pair_enqueue(struct taskqueue *queue, struct task_pair *tp); +int taskqueue_pair_stop(struct taskqueue *queue, struct task_pair *tp); +void taskqueue_pair_drain(struct taskqueue *queue, struct task_pair *tp); int taskqueue_enqueue(struct taskqueue *queue, struct task *task); +int taskqueue_stop(struct taskqueue *queue, struct task *task); void taskqueue_drain(struct taskqueue *queue, struct task *task); void taskqueue_free(struct taskqueue *queue); void taskqueue_run(struct taskqueue *queue); @@ -78,6 +82,15 @@ } while (0) /* + * Initialise a task pair structure. + */ +#define TASK_PAIR_INIT(tp, func, context) do { \ + TASK_INIT(&(tp)->tp_task[0], 0, func, context); \ + TASK_INIT(&(tp)->tp_task[1], 0, func, context); \ + (tp)->tp_last = 0; \ +} while (0) + +/* * Declare a reference to a taskqueue. */ #define TASKQUEUE_DECLARE(name) \ --Boundary-00=_O1E1M5DxgzaX2zh-- From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 18:34:21 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D16E0106566B; Fri, 5 Nov 2010 18:34:21 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id C03C88FC16; Fri, 5 Nov 2010 18:34:20 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=NQlS8b5mwfIYmOo8uroA:9 a=E_rvnGVBWsNcG74Lc3UA:7 a=2RIT3NFf099GxrwdX1yFkcDJl_4A:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=SV7veod9ZcQA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44710663; Fri, 05 Nov 2010 19:34:19 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 19:35:27 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051836.39697.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051935.27579.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:34:22 -0000 On Friday 05 November 2010 19:13:08 Matthew Fleming wrote: > On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky wrote: > > On Friday 05 November 2010 18:15:01 Matthew Fleming wrote: > >> On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: > >> > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: > >> >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wrote: > >> >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: > >> >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin wrote: > >> >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: > >> >> >> >> I think that if a task is currently executing, then there > >> >> >> >> should be a drain method for that. I.E. two methods: One to > >> >> >> >> stop and one to cancel/drain. Can you implement this? > >> >> >> > > >> >> >> > I agree, this would also be consistent with the callout_*() API > >> >> >> > if you had both "stop()" and "drain()" methods. > >> >> >> > >> >> >> Here's my proposed code. Note that this builds but is not yet > >> >> >> tested. > >> >> >> > >> >> >> > >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. > >> >> >> > >> >> >> Requested by: hps > >> >> >> Original code: jeff > >> >> >> MFC after: 1 week > >> >> >> > >> >> >> > >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff > >> >> > > >> >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. > >> >> > However, I would prefer that it follow the semantics of > >> >> > callout_stop() and return true if it stopped the task and false > >> >> > otherwise. The Linux wrapper for taskqueue_cancel() can convert > >> >> > the return value. > >> >> > >> >> I used -EBUSY since positive return values reflect the old pending > >> >> count. ta_pending was zero'd, and I think needs to be to keep the > >> >> task sane, because all of taskqueue(9) assumes a non-zero ta_pending > >> >> means the task is queued. > >> >> > >> >> I don't know that the caller often needs to know the old value of > >> >> ta_pending, but it seems simpler to return that as the return value > >> >> and use -EBUSY than to use an optional pointer to a place to store > >> >> the old ta_pending just so we can keep the error return positive. > >> >> > >> >> Note that phk (IIRC) suggested using -error in the returns for > >> >> sbuf_drain to indicate the difference between success (> 0 bytes > >> >> drained) and an error, so FreeBSD now has precedent. I'm not > >> >> entirely sure that's a good thing, since I am not generally fond of > >> >> Linux's use of -error, but for some cases it is convenient. > >> >> > >> >> But, I'll do this one either way, just let me know if the above > >> >> hasn't convinced you. > >> > > >> > Hmm, I hadn't considered if callers would want to know the pending > >> > count of the cancelled task. > >> > > >> >> > I'm not sure I like reusing the memory allocation flags (M_NOWAIT / > >> >> > M_WAITOK) for this blocking flag. In the case of callout(9) we > >> >> > just have two functions that pass an internal boolean to the real > >> >> > routine (callout_stop() and callout_drain() are wrappers for > >> >> > _callout_stop_safe()). It is a bit unfortunate that > >> >> > taskqueue_drain() already exists and has different semantics than > >> >> > callout_drain(). It would have been nice to have the two APIs > >> >> > mirror each other instead. > >> >> > > >> >> > Hmm, I wonder if the blocking behavior cannot safely be provided by > >> >> > just doing: > >> >> > > >> >> > if (!taskqueue_cancel(queue, task, M_NOWAIT) > >> >> > taskqueue_drain(queue, task); > >> >> > >> >> This seems reasonable and correct. I will add a note to the manpage > >> >> about this. > >> > > >> > In that case, would you be fine with dropping the blocking > >> > functionality from taskqueue_cancel() completely and requiring code > >> > that wants the blocking semantics to use a cancel followed by a > >> > drain? > >> > >> New patch is at > >> http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-canc > >> el- a-task-from-a.patch > > > > I think the: > > > > + if (!task_is_running(queue, task)) { > > If it is running, it is dequeued from the the taskqueue, right? And while it is running it can be queued again, which your initial code didn't handle? --HPS From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 18:39:46 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C989F1065674; Fri, 5 Nov 2010 18:39:46 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 448228FC13; Fri, 5 Nov 2010 18:39:45 +0000 (UTC) Received: by yxl31 with SMTP id 31so2477722yxl.13 for ; Fri, 05 Nov 2010 11:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D29wDRntq2CSQZo7Nv6wTrGlpMMuFRkjaIAHLqmjLQA=; b=xF0WixRPSti32fB5rxhr9brs2sjVB9vN5YL0CFe3WDx4yvs/DEutQo6A2TmQ+QrwaD eQqzEASKZa+SQleMAlUKhLe3/iGQStfmXTfIpn0dXso9tRqyWxIbQTvYYXML3IW9+ItS aGAZOdBLnAJOdGHOe1dkabyMCPGJO+k2PgpcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WljFVibE0pGR8hNAZTYTdSu9rnEmS/16pWMhihuoVOHTeYxY4Ddh4sBoVNc4Fmxx+x 5dHW1z5YB6YEmWBNS9U4/JdPGAAON2nAfw6u9OqYijLS8XMitrp5AkYSP0vQRdNtR844 5MHJp6wS1/bBD/9jMPYUEBPdY32MYGCPdQxEI= MIME-Version: 1.0 Received: by 10.42.97.67 with SMTP id m3mr1524332icn.343.1288982385280; Fri, 05 Nov 2010 11:39:45 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 11:39:45 -0700 (PDT) In-Reply-To: <201011051935.27579.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011051836.39697.hselasky@c2i.net> <201011051935.27579.hselasky@c2i.net> Date: Fri, 5 Nov 2010 11:39:45 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:39:46 -0000 On Fri, Nov 5, 2010 at 11:35 AM, Hans Petter Selasky wro= te: > On Friday 05 November 2010 19:13:08 Matthew Fleming wrote: >> On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky > wrote: >> > On Friday 05 November 2010 18:15:01 Matthew Fleming wrote: >> >> On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin wrote: >> >> > On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: >> >> >> On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin wro= te: >> >> >> > On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: >> >> >> >> On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin > wrote: >> >> >> >> > On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky > wrote: >> >> >> >> >> I think that if a task is currently executing, then there >> >> >> >> >> should be a drain method for that. I.E. two methods: One to >> >> >> >> >> stop and one to cancel/drain. Can you implement this? >> >> >> >> > >> >> >> >> > I agree, this would also be consistent with the callout_*() A= PI >> >> >> >> > if you had both "stop()" and "drain()" methods. >> >> >> >> >> >> >> >> Here's my proposed code. =A0Note that this builds but is not ye= t >> >> >> >> tested. >> >> >> >> >> >> >> >> >> >> >> >> Implement a taskqueue_cancel(9), to cancel a task from a queue. >> >> >> >> >> >> >> >> Requested by: =A0 =A0 =A0 hps >> >> >> >> Original code: =A0 =A0 =A0jeff >> >> >> >> MFC after: =A01 week >> >> >> >> >> >> >> >> >> >> >> >> http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff >> >> >> > >> >> >> > For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. >> >> >> > =A0However, I would prefer that it follow the semantics of >> >> >> > callout_stop() and return true if it stopped the task and false >> >> >> > otherwise. =A0The Linux wrapper for taskqueue_cancel() can conve= rt >> >> >> > the return value. >> >> >> >> >> >> I used -EBUSY since positive return values reflect the old pending >> >> >> count. =A0ta_pending was zero'd, and I think needs to be to keep t= he >> >> >> task sane, because all of taskqueue(9) assumes a non-zero ta_pendi= ng >> >> >> means the task is queued. >> >> >> >> >> >> I don't know that the caller often needs to know the old value of >> >> >> ta_pending, but it seems simpler to return that as the return valu= e >> >> >> and use -EBUSY than to use an optional pointer to a place to store >> >> >> the old ta_pending just so we can keep the error return positive. >> >> >> >> >> >> Note that phk (IIRC) suggested using -error in the returns for >> >> >> sbuf_drain to indicate the difference between success (> 0 bytes >> >> >> drained) and an error, so FreeBSD now has precedent. =A0I'm not >> >> >> entirely sure that's a good thing, since I am not generally fond o= f >> >> >> Linux's use of -error, but for some cases it is convenient. >> >> >> >> >> >> But, I'll do this one either way, just let me know if the above >> >> >> hasn't convinced you. >> >> > >> >> > Hmm, I hadn't considered if callers would want to know the pending >> >> > count of the cancelled task. >> >> > >> >> >> > I'm not sure I like reusing the memory allocation flags (M_NOWAI= T / >> >> >> > M_WAITOK) for this blocking flag. =A0In the case of callout(9) w= e >> >> >> > just have two functions that pass an internal boolean to the rea= l >> >> >> > routine (callout_stop() and callout_drain() are wrappers for >> >> >> > _callout_stop_safe()). =A0It is a bit unfortunate that >> >> >> > taskqueue_drain() already exists and has different semantics tha= n >> >> >> > callout_drain(). =A0It would have been nice to have the two APIs >> >> >> > mirror each other instead. >> >> >> > >> >> >> > Hmm, I wonder if the blocking behavior cannot safely be provided= by >> >> >> > just doing: >> >> >> > >> >> >> > =A0 =A0 =A0 =A0if (!taskqueue_cancel(queue, task, M_NOWAIT) >> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_drain(queue, task); >> >> >> >> >> >> This seems reasonable and correct. =A0I will add a note to the man= page >> >> >> about this. >> >> > >> >> > In that case, would you be fine with dropping the blocking >> >> > functionality from taskqueue_cancel() completely and requiring code >> >> > that wants the blocking semantics to use a cancel followed by a >> >> > drain? >> >> >> >> New patch is at >> >> http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-c= anc >> >> el- a-task-from-a.patch >> > >> > I think the: >> > >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >> > > > If it is running, it is dequeued from the the taskqueue, right? And while= it > is running it can be queued again, which your initial code didn't handle? True, but no taskqueue(9) code can handle that. Only the caller can prevent a task from becoming enqueued again. The same issue exists with taskqueue_drain(). BTW, I planned to commit the patch I sent today after testing, assuming jhb@ has no more issues. Thanks, matthew From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 18:44:45 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D12A106564A; Fri, 5 Nov 2010 18:44:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 47BD58FC19; Fri, 5 Nov 2010 18:44:43 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=Hn5bgWAfYFTdbKXFfdsA:9 a=2En-A4nSjAFEL4h1BRZjkSm4QfUA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44714363; Fri, 05 Nov 2010 19:44:42 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 19:45:51 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051935.27579.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051945.51393.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:44:45 -0000 On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > True, but no taskqueue(9) code can handle that. Only the caller can > prevent a task from becoming enqueued again. The same issue exists > with taskqueue_drain(). I find that strange, because that means if I queue a task again while it is running, then I doesn't get run? Are you really sure? --HPS From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 18:48:06 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B18106564A; Fri, 5 Nov 2010 18:48:06 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 37DF58FC20; Fri, 5 Nov 2010 18:48:05 +0000 (UTC) Received: by ywh2 with SMTP id 2so2519496ywh.13 for ; Fri, 05 Nov 2010 11:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KkKNUrZJAdzo+uUSdLQ9ycvhki1H8jqlPpk2OKp8VME=; b=VaTx3IpJ/ApgbPCTxUeduldg5Du1ePvYOgX3M63B9hvANDSjlTcXc9A1zL0oUYZV+f S3RJeYAgDFots40uLm6kIpWZGkU2GYJ7MJL0iGTGybKF/U8HN+6CpqJf167X0+GldzdS Xv2qTGnwcSHXgMdQAaz657AnYt5DnyjThOLtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VE+PyPMPnqsTaDDlTO/p2JkkaBqAlP3fHzFlJa0/OQUn61a2Plp6/dgQQDIqVb036+ wJZKMIJG/6WQlHaJY6xbU8qNv2pMiQOnZ8tHK5SxEGd2LT+Fd5zvO0s4o3jrjROOO6Mw 9r+1HkSkO6bzY2TiMMyIg2lUMGfM5rs3Orgfs= MIME-Version: 1.0 Received: by 10.42.22.69 with SMTP id n5mr1388786icb.477.1288982885106; Fri, 05 Nov 2010 11:48:05 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Fri, 5 Nov 2010 11:48:05 -0700 (PDT) In-Reply-To: <201011051945.51393.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011051935.27579.hselasky@c2i.net> <201011051945.51393.hselasky@c2i.net> Date: Fri, 5 Nov 2010 11:48:05 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:48:06 -0000 On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky wro= te: > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: >> True, but no taskqueue(9) code can handle that. =A0Only the caller can >> prevent a task from becoming enqueued again. =A0The same issue exists >> with taskqueue_drain(). > > I find that strange, because that means if I queue a task again while it = is > running, then I doesn't get run? Are you really sure? If a task is currently running when enqueued, the task struct will be re-enqueued to the taskqueue. When that task comes up as the head of the queue, it will be run again. Thanks, matthew From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 18:59:31 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87FD3106566B; Fri, 5 Nov 2010 18:59:31 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6878FC20; Fri, 5 Nov 2010 18:59:30 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=7l0j79IZqt8iMOdoQ2YA:9 a=f3QMjJQtTtU01tPy7UiD68_cvEMA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45923574; Fri, 05 Nov 2010 19:59:28 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 20:00:37 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011051945.51393.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011052000.37188.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 18:59:31 -0000 On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky wrote: > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > >> True, but no taskqueue(9) code can handle that. Only the caller can > >> prevent a task from becoming enqueued again. The same issue exists > >> with taskqueue_drain(). > > > > I find that strange, because that means if I queue a task again while it > > is running, then I doesn't get run? Are you really sure? > > If a task is currently running when enqueued, the task struct will be > re-enqueued to the taskqueue. When that task comes up as the head of > the queue, it will be run again. Right, and the taskqueue_cancel has to cancel in that state to, but it doesn't because it only checks pending if !running() :-) ?? --HPS From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 19:07:56 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B43A106566B; Fri, 5 Nov 2010 19:07:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DB0298FC16; Fri, 5 Nov 2010 19:07:55 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 88C0F46B4C; Fri, 5 Nov 2010 15:07:55 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 80B0E8A01D; Fri, 5 Nov 2010 15:07:54 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 5 Nov 2010 15:06:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011052000.37188.hselasky@c2i.net> In-Reply-To: <201011052000.37188.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011051506.12643.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 05 Nov 2010 15:07:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Matthew Fleming , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 19:07:56 -0000 On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky > wrote: > > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > > >> True, but no taskqueue(9) code can handle that. Only the caller can > > >> prevent a task from becoming enqueued again. The same issue exists > > >> with taskqueue_drain(). > > > > > > I find that strange, because that means if I queue a task again while it > > > is running, then I doesn't get run? Are you really sure? > > > > If a task is currently running when enqueued, the task struct will be > > re-enqueued to the taskqueue. When that task comes up as the head of > > the queue, it will be run again. > > Right, and the taskqueue_cancel has to cancel in that state to, but it doesn't > because it only checks pending if !running() :-) ?? You can't close that race in taskqueue_cancel(). You have to manage that race yourself in your task handler. For the callout(9) API we are only able to close that race if you use callout_init_mtx() so that the code managing the callout wheel can make use of your lock to resolve the races. If you use callout_init() you have to explicitly manage these races in your callout handler. -- John Baldwin From owner-freebsd-usb@FreeBSD.ORG Sat Nov 6 01:18:02 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC6EE106566B for ; Sat, 6 Nov 2010 01:18:02 +0000 (UTC) (envelope-from mgmartin@comcast.net) Received: from mx.appliedtechnicalknowledge.com (portfolioframework.com [173.14.31.49]) by mx1.freebsd.org (Postfix) with ESMTP id 85A038FC08 for ; Sat, 6 Nov 2010 01:18:02 +0000 (UTC) Received: from [10.0.0.4] (gandalf.martins.home [10.0.0.4]) by mx.appliedtechnicalknowledge.com (Postfix) with ESMTPSA id 6D68E12E9F7; Fri, 5 Nov 2010 19:18:01 -0600 (MDT) Message-ID: <4CD4ACC9.8040405@comcast.net> Date: Fri, 05 Nov 2010 19:18:01 -0600 From: Michael Martin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101101 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hans Petter Selasky References: <4CBFEBF5.30203@comcast.net> <201010230823.36449.hselasky@c2i.net> <4CC2E533.3010604@comcast.net> <201011042037.20274.hselasky@c2i.net> In-Reply-To: <201011042037.20274.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: USB 3.0 Fails To Attach Western Digital My Book 3.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 01:18:03 -0000 On 11/04/2010 13:37, Hans Petter Selasky wrote: > On Saturday 23 October 2010 15:37:55 Michael Martin wrote: >> On 10/23/2010 00:23, Hans Petter Selasky wrote: >>> On Saturday 23 October 2010 02:07:59 Michael Martin wrote: >>>> On 10/21/2010 01:29, Michael Martin wrote: >>>>> Thanks for the new USB 3.0 effort! >>>>> >>>>> I'm testing it out on 9.0-CURRENT amd64. The controller seems to find >>>>> a 2.0 usb stick fine. However, when I plug in a Western Digital 3.0 >>>>> drive, the device fails to attach. The WD drive attaches fine when >>>>> plugging into a 2.0 port on the motherboard. >>>>> >>>>> Controller info: >>>>> >>>>> xhci0@pci0:5:0:0: class=0x0c0330 card=0xffffffff chip=0x01941033 >>>>> rev=0x03 hdr=0x00 >>>>> >>>>> vendor = 'NEC Electronics Hong Kong' >>>>> class = serial bus >>>>> subclass = USB >>>>> bar [10] = type Memory, range 64, base 0xfbbfe000, size 8192, >>>>> >>>>> enabled >>>>> >>>>> cap 01[50] = powerspec 3 supports D0 D3 current D0 >>>>> cap 05[70] = MSI supports 8 messages, 64 bit >>>>> cap 11[90] = MSI-X supports 8 messages in map 0x10 >>>>> cap 10[a0] = PCI-Express 2 endpoint max data 128(128) link x1(x1) >>>>> >>>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected >>>>> ecap 0003[140] = Serial 1 ffffffffffffffff >>>>> ecap 0018[150] = unknown 1 >>>>> >>>>> WD 3.0 Drive Info ( while plugged into the 2.0 port ): >>>>> >>>>> ugen3.4: at usbus3, cfg=0 md=HOST >>>>> spd=HIGH (480Mbps) pwr=ON >>>>> >>>>> bLength = 0x0012 >>>>> bDescriptorType = 0x0001 >>>>> bcdUSB = 0x0210 >>>>> bDeviceClass = 0x0000 >>>>> bDeviceSubClass = 0x0000 >>>>> bDeviceProtocol = 0x0000 >>>>> bMaxPacketSize0 = 0x0040 >>>>> idVendor = 0x1058 >>>>> idProduct = 0x1123 >>>>> bcdDevice = 0x1010 >>>>> iManufacturer = 0x0001 >>>>> iProduct = 0x0002 >>>>> iSerialNumber = 0x0003 >>>>> bNumConfigurations = 0x0001 >>>>> >>>>> Output when plugging in the Western Digital 3.0 into the 3.0 port: >>>>> >>>>> Oct 21 01:03:54 gandalf root: Unknown USB device: vendor 0x1058 >>>>> product 0x1123 bus uhub4 >>>>> Oct 21 01:03:54 gandalf kernel: ugen4.2: at usbus4 >>>>> Oct 21 01:03:54 gandalf kernel: umass0:>>>> class 0/0, rev 3.00/10.10, addr 1> on usbus4 >>>>> Oct 21 01:03:54 gandalf kernel: umass0: SCSI over Bulk-Only; quirks = >>>>> 0x0000 >>>>> Oct 21 01:03:55 gandalf kernel: umass0:9:0:-1: Attached to scbus9 >>>>> Oct 21 01:03:57 gandalf root: ZFS: zpool I/O failure, zpool=wd3.1 >>>>> error=28 >>>>> Oct 21 01:03:57 gandalf last message repeated 2 times >>>>> Oct 21 01:03:57 gandalf root: ZFS: vdev I/O failure, zpool=wd3.1 path= >>>>> offset= size= error= >>>>> Oct 21 01:04:03 gandalf kernel: ugen4.2: at usbus4 >>>>> (disconnected) >>>>> Oct 21 01:04:03 gandalf kernel: umass0: at uhub4, port 2, addr 1 >>>>> (disconnected) >>>>> Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): lost device >>>>> Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): got CAM status >>>>> 0xa >>>>> Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): fatal error, >>>>> failed to attach to device >>>>> Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0: >>>>> Oct 21 01:04:03 gandalf kernel: 0:0): removing device entry >>>>> Oct 21 01:04:14 gandalf root: ZFS: zpool I/O failure, zpool=wd3.1 >>>>> error=28 >>>>> Oct 21 01:04:14 gandalf last message repeated 2 times >>>>> Oct 21 01:04:14 gandalf root: ZFS: vdev I/O failure, zpool=wd3.1 path= >>>>> offset= size= error= >>>>> >>>>> Output when plugging in the WD 3.0 into the 2.0 port: >>>>> >>>>> Oct 21 01:15:20 gandalf root: Unknown USB device: vendor 0x1058 >>>>> product 0x1123 bus uhub3 >>>>> Oct 21 01:15:20 gandalf kernel: ugen3.4: at usbus3 >>>>> Oct 21 01:15:20 gandalf kernel: umass0:>>>> class 0/0, rev 2.10/10.10, addr 4> on usbus3 >>>>> Oct 21 01:15:20 gandalf kernel: umass0: SCSI over Bulk-Only; quirks = >>>>> 0x0000 >>>>> Oct 21 01:15:21 gandalf kernel: umass0:9:0:-1: Attached to scbus9 >>>>> Oct 21 01:15:28 gandalf kernel: da0 at umass-sim0 bus 0 scbus9 target >>>>> 0 lun 0 >>>>> Oct 21 01:15:28 gandalf kernel: da0: Fixed >>>>> Direct Access SCSI-4 device >>>>> Oct 21 01:15:28 gandalf kernel: da0: 40.000MB/s transfers >>>>> Oct 21 01:15:28 gandalf kernel: da0: 953867MB (1953519616 512 byte >>>>> sectors: 255H 63S/T 121600C) >>>>> >>>>> Output when plugging in 2.0 device into the 3.0 port: >>>>> >>>>> Oct 21 01:09:54 gandalf root: Unknown USB device: vendor 0x090c >>>>> product 0x1000 bus uhub4 >>>>> Oct 21 01:09:54 gandalf kernel: ugen4.2: at usbus4 >>>>> Oct 21 01:09:54 gandalf kernel: umass1:>>>> rev 2.00/11.00, addr 1> on usbus4 >>>>> Oct 21 01:09:54 gandalf kernel: umass1: SCSI over Bulk-Only; quirks = >>>>> 0x0000 >>>>> Oct 21 01:09:55 gandalf kernel: umass1:10:1:-1: Attached to scbus10 >>>>> Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): TEST UNIT >>>>> READY. CDB: 0 0 0 0 0 0 >>>>> Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): CAM status: >>>>> SCSI Status Error >>>>> Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): SCSI >>>>> status: Check Condition >>>>> Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): SCSI sense: >>>>> UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have >>>>> changed) >>>>> Oct 21 01:09:56 gandalf kernel: da1 at umass-sim1 bus 1 scbus10 target >>>>> 0 lun 0 >>>>> Oct 21 01:09:56 gandalf kernel: da1: Fixed >>>>> Direct Access SCSI-0 device >>>>> Oct 21 01:09:56 gandalf kernel: da1: 40.000MB/s transfers >>>>> Oct 21 01:09:56 gandalf kernel: da1: 956MB (1957888 512 byte sectors: >>>>> 64H 32S/T 956C) >>>>> >>>>> --Michael >>>> ( I never got the last list email to this thread, so replying to my >>>> own.) >>>> >>>> Hans, I added your suggestions and here's what I've found: >>>> >>>> There seems to be two issues. >>>> >>>> (1) >>>> The first is initial recognition of the device. If I have umass >>>> compiled in the kernel or as a module loaded by loader.conf, initial >>>> load of xhci almost never finds the attached drive as the modules are >>>> loaded. If I kldunload xhci then load it back in, umass finds the >>>> drive. Re-loading or delaying the the load of xhci ( manual kldload or >>>> in rc.local ) almost always finds the drive. Seems like order matters >>>> here too. umass likes to be loaded first followed by xhci which then >>>> triggers umass to see the drive. >>>> >>>> If both umass and xhci are compiled in the kernel, the drive is never >>>> initialized. >>>> >>>> The good news is I can get the drive to be recognized by a >>>> kldunload/kldload of xhci. >>>> >>>> (2) >>>> One the drive is recognized I can see it and partition it using gpart. >>>> However, when I start dumping data to the drive, the drive gets >>>> disconnected. I was doing a dd if=/dev/zero of=/dev/da0 bs=1M >>>> count=500. The initial dd would sometimes succeed. Running dd >>>> imediately after the initial success would cause an error. >>>> >>>> Here's the tail output of umass debugging while the dd was running and >>>> the device stopped: >>>> >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_transfer_start: transfer >>>> index = 4 >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_t_bbb_data_read_callback: >>>> max_bulk=131072, data_rem=512 >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_t_bbb_data_read_callback: >>>> max_bulk=131072, data_rem=0 >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_transfer_start: transfer >>>> index = 8 >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_bbb_dump_csw: CSW 4049: sig >>>> = 0x53425355 (valid), tag = 0x00000fd1, res = 0, status = 0x00 (good) >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_cam_action: >>>> 7:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_bbb_dump_cbw: CBW 4050: cmd >>>> = 10b (0x280000000000...), data = 512b, lun = 0, dir = in >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_transfer_start: transfer >>>> index = 4 >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_t_bbb_data_read_callback: >>>> max_bulk=131072, data_rem=512 >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_t_bbb_data_read_callback: >>>> max_bulk=131072, data_rem=0 >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_transfer_start: transfer >>>> index = 8 >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_bbb_dump_csw: CSW 4050: sig >>>> = 0x53425355 (valid), tag = 0x00000fd2, res = 0, status = 0x00 (good) >>>> Oct 22 17:44:19 gandalf kernel: umass0:umass_cam_action: >>>> 7:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense >>>> Oct 22 17:44:23 gandalf kernel: umass0:umass_cam_action: >>>> 7:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense >>>> Oct 22 17:44:23 gandalf kernel: umass0:umass_bbb_dump_cbw: CBW 4051: cmd >>>> = 10b (0x250000000000...), data = 8b, lun = 0, dir = in >>>> Oct 22 17:44:23 gandalf kernel: ugen4.2: at usbus4 >>>> (disconnected) >>>> Oct 22 17:44:23 gandalf kernel: umass0: at uhub4, port 2, addr 1 >>>> (disconnected) >>>> Oct 22 17:44:23 gandalf kernel: umass0:umass_detach: >>>> Oct 22 17:44:23 gandalf kernel: (da0:umass-sim0:0:0:0): AutoSense failed >>>> Oct 22 17:44:23 gandalf kernel: (da0:umass-sim0:0:0:0): lost device >>>> Oct 22 17:44:23 gandalf kernel: (da0:umass-sim0:0:0:0): removing device >>>> entry >>>> >>>> I've saw there are quirks for the WESTERN MYBOOK . A added a specific >>>> device into usbdevs and an entry into usb_quirk.c to mimic the same >>>> quirks: >>>> >>>> USB_QUIRK(WESTERN, MYBOOK3, 0x0000, 0xffff, UQ_MSC_FORCE_WIRE_BBB, >>>> >>>> UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_NO_INQUIRY_EVPD, >>>> UQ_MSC_NO_SYNC_CACHE), >>>> >>>> This didn't help, and I got the disconnect as shown above. >>>> >>>> --Michael >>> Hi, >>> >>> Could you compile kernel with "options USB_DEBUG". >>> >>> Then run: >>> >>> sysctl hw.usb.uhub.debug=16 >>> >>> Then attach your drive. >>> >>> Maybe the USB stack is mistreating some event from the XHCI. Send the >>> resulting dmesg. >>> >>> --HPS >> I set debug and plugged in the drive. Here's the output. >> >> --Michael > Hi, > > Thanks for the debug output. Can you try to "svn up" to r214808. > > Then apply the following patch to: > > sys/dev/usb/usb_hub.c > > ================================================================== > --- usb_hub.c (revision 214808) > +++ usb_hub.c (local) > @@ -609,6 +609,15 @@ > case UPS_PORT_LS_U1: > is_suspend = 0; > break; > + case UPS_PORT_LS_SS_INA: > + /* Try a warm port reset to recover the port. */ > + err = usbd_req_warm_reset_port(udev, NULL, portno); > + if (err) { > + DPRINTF("warm port reset failed.\n"); > + goto done; > + } > + is_suspend = 0; > + break; > default: > is_suspend = 1; > break; > > Then build a new kernel. And send new debug output if your device does not > work. > > --HPS I applied the patch to r214808. The drive is recognized better now--da0 is created most of the time. When I tried to access the drive via zfs import, the zfs import hung. I have two WD USB 3.0 drives ( same vendor/product id but different bcdDevice . One drive has better success being recognized than the other. I captured several debug outputs here: http://appliedtechnicalknowledge.com/freebsd/usb3-patch-214808/ . Maybe something in these can help. Let me know procedure wise how it's best to capture data for you--plugged in prior to boot or plugging in after boot. I tried to get both. mm From owner-freebsd-usb@FreeBSD.ORG Sat Nov 6 02:50:11 2010 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC039106564A for ; Sat, 6 Nov 2010 02:50:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C98158FC14 for ; Sat, 6 Nov 2010 02:50:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA62oBYZ081825 for ; Sat, 6 Nov 2010 02:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA62oBqY081809; Sat, 6 Nov 2010 02:50:11 GMT (envelope-from gnats) Date: Sat, 6 Nov 2010 02:50:11 GMT Message-Id: <201011060250.oA62oBqY081809@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Boris Kochergin Cc: Subject: Re: usb/130230: [quirk] [usb67] [usb] [cam] [umass] Samsung Electronics YP-U3 does not attach in 7.1-RELEASE X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Boris Kochergin List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 02:50:11 -0000 The following reply was made to PR usb/130230; it has been noted by GNATS. From: Boris Kochergin To: bug-followup@FreeBSD.org Cc: Subject: Re: usb/130230: [quirk] [usb67] [usb] [cam] [umass] Samsung Electronics YP-U3 does not attach in 7.1-RELEASE Date: Fri, 05 Nov 2010 22:13:24 -0400 Here is the output of "usbconfig dump_device_desc" relevant to the device: ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x04e8 idProduct = 0x507c bcdDevice = 0x0220 iManufacturer = 0x0001 iProduct = 0x0002 iSerialNumber = 0x0003 bNumConfigurations = 0x0001 It still doesn't work out of the box on any version of FreeBSD, but I am running CURRENT now, so the following makes it work: usbconfig -d 3.2 add_quirk UQ_MSC_NO_INQUIRY usbconfig -d 3.2 add_quirk UQ_MSC_NO_SYNC_CACHE usbconfig -d 3.2 reset usbconfig -d 3.2 reset From owner-freebsd-usb@FreeBSD.ORG Sat Nov 6 08:36:46 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DD941065670; Sat, 6 Nov 2010 08:36:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 23B178FC18; Sat, 6 Nov 2010 08:36:44 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=yevn+QCjI6xy199BDvBOOiO14qYvyLq62he9tTtU3M8= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=NeL9HQIyaxTiqRflnoYA:9 a=Jzdrks91--tz73bWEW4A:7 a=b0ip0QWF_mfza3iejVZCFHj2lVUA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45442018; Sat, 06 Nov 2010 09:36:42 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Sat, 6 Nov 2010 09:37:50 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011052000.37188.hselasky@c2i.net> <201011051506.12643.jhb@freebsd.org> In-Reply-To: <201011051506.12643.jhb@freebsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011060937.50639.hselasky@c2i.net> Cc: Matthew Fleming , John Baldwin , Weongyo Jeong , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 08:36:46 -0000 On Friday 05 November 2010 20:06:12 John Baldwin wrote: > On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: > > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: > > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky > > > > wrote: > > > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: > > > >> True, but no taskqueue(9) code can handle that. Only the caller can > > > >> prevent a task from becoming enqueued again. The same issue exists > > > >> with taskqueue_drain(). > > > > > > > > I find that strange, because that means if I queue a task again while > > > > it is running, then I doesn't get run? Are you really sure? > > > > > > If a task is currently running when enqueued, the task struct will be > > > re-enqueued to the taskqueue. When that task comes up as the head of > > > the queue, it will be run again. > > > > Right, and the taskqueue_cancel has to cancel in that state to, but it > > doesn't because it only checks pending if !running() :-) ?? > > You can't close that race in taskqueue_cancel(). You have to manage that > race yourself in your task handler. For the callout(9) API we are only > able to close that race if you use callout_init_mtx() so that the code > managing the callout wheel can make use of your lock to resolve the races. > If you use callout_init() you have to explicitly manage these races in your > callout handler. Hi, I think you are getting me wrong! In the initial "0001-Implement- taskqueue_cancel-9-to-cancel-a-task-from-a.patch" you have the following code- chunk: +int +taskqueue_cancel(struct taskqueue *queue, struct task *task) +{ + int rc; + + TQ_LOCK(queue); + if (!task_is_running(queue, task)) { + if ((rc = task->ta_pending) > 0) + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } else + rc = -EBUSY; + TQ_UNLOCK(queue); + return (rc); +} This code should be written like this, having the if (!task_is_running()) after checking the ta_pending variable. +int +taskqueue_cancel(struct taskqueue *queue, struct task *task) +{ + int rc; + + TQ_LOCK(queue); + if ((rc = task->ta_pending) > 0) { + STAILQ_REMOVE(&queue->tq_queue, task, task, ta_link); + task->ta_pending = 0; + } + if (!task_is_running(queue, task)) + rc = -EBUSY; + TQ_UNLOCK(queue); + return (rc); +} Or completely skip the !task_is_running() check. Else you are opening up a race in this function! Do I need to explain that more? Isn't it obvious? --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Nov 6 08:39:42 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B1891065670; Sat, 6 Nov 2010 08:39:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 838CF8FC08; Sat, 6 Nov 2010 08:39:41 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=5UXFHLfkiY5XrCDma5uYm2T9fyMGz6t0cyN4hLfZsqg= c=1 sm=1 a=7S7JGF67XxMA:10 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=lZVFkjqBO7oz9M9OSAUA:9 a=KVZgLuI044YZkzy5wjx4rFPP0-kA:4 a=PUjeQqilurYA:10 a=SV7veod9ZcQA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 44867248; Sat, 06 Nov 2010 09:39:39 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org, Boris Kochergin , freebsd-gnats-submit@freebsd.org Date: Sat, 6 Nov 2010 09:40:47 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011060250.oA62oBqY081809@freefall.freebsd.org> In-Reply-To: <201011060250.oA62oBqY081809@freefall.freebsd.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011060940.47455.hselasky@c2i.net> Cc: Subject: Re: usb/130230: [quirk] [usb67] [usb] [cam] [umass] Samsung Electronics YP-U3 does not attach in 7.1-RELEASE X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 08:39:42 -0000 On Saturday 06 November 2010 03:50:11 Boris Kochergin wrote: > The following reply was made to PR usb/130230; it has been noted by GNATS. > > From: Boris Kochergin > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: usb/130230: [quirk] [usb67] [usb] [cam] [umass] Samsung > Electronics YP-U3 does not attach in 7.1-RELEASE > Date: Fri, 05 Nov 2010 22:13:24 -0400 > > Here is the output of "usbconfig dump_device_desc" relevant to the device: > > ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x0000 > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0040 > idVendor = 0x04e8 > idProduct = 0x507c > bcdDevice = 0x0220 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0003 > bNumConfigurations = 0x0001 > > It still doesn't work out of the box on any version of FreeBSD, but I am > running CURRENT now, so the following makes it work: > > usbconfig -d 3.2 add_quirk UQ_MSC_NO_INQUIRY > usbconfig -d 3.2 add_quirk UQ_MSC_NO_SYNC_CACHE > usbconfig -d 3.2 reset > usbconfig -d 3.2 reset Hi, Can you create a quirk line for: /sys/dev/usb/quirk/usb_quirk.c ? And add any missing device ID's to usbdevs. Proably we should look at blacklisting using the idVendor and not just limit ourself to a single product. Thanks for reporting! --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Nov 6 08:40:13 2010 Return-Path: Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75C321065673 for ; Sat, 6 Nov 2010 08:40:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 48ED98FC19 for ; Sat, 6 Nov 2010 08:40:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA68eCpU075555 for ; Sat, 6 Nov 2010 08:40:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA68eCwu075541; Sat, 6 Nov 2010 08:40:12 GMT (envelope-from gnats) Date: Sat, 6 Nov 2010 08:40:12 GMT Message-Id: <201011060840.oA68eCwu075541@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Hans Petter Selasky Cc: Subject: Re: usb/130230: [quirk] [usb67] [usb] [cam] [umass] Samsung Electronics YP-U3 does not attach in 7.1-RELEASE X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Hans Petter Selasky List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 08:40:13 -0000 The following reply was made to PR usb/130230; it has been noted by GNATS. From: Hans Petter Selasky To: freebsd-usb@freebsd.org, Boris Kochergin , freebsd-gnats-submit@freebsd.org Cc: Subject: Re: usb/130230: [quirk] [usb67] [usb] [cam] [umass] Samsung Electronics YP-U3 does not attach in 7.1-RELEASE Date: Sat, 6 Nov 2010 09:40:47 +0100 On Saturday 06 November 2010 03:50:11 Boris Kochergin wrote: > The following reply was made to PR usb/130230; it has been noted by GNATS. > > From: Boris Kochergin > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: usb/130230: [quirk] [usb67] [usb] [cam] [umass] Samsung > Electronics YP-U3 does not attach in 7.1-RELEASE > Date: Fri, 05 Nov 2010 22:13:24 -0400 > > Here is the output of "usbconfig dump_device_desc" relevant to the device: > > ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x0000 > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0040 > idVendor = 0x04e8 > idProduct = 0x507c > bcdDevice = 0x0220 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0003 > bNumConfigurations = 0x0001 > > It still doesn't work out of the box on any version of FreeBSD, but I am > running CURRENT now, so the following makes it work: > > usbconfig -d 3.2 add_quirk UQ_MSC_NO_INQUIRY > usbconfig -d 3.2 add_quirk UQ_MSC_NO_SYNC_CACHE > usbconfig -d 3.2 reset > usbconfig -d 3.2 reset Hi, Can you create a quirk line for: /sys/dev/usb/quirk/usb_quirk.c ? And add any missing device ID's to usbdevs. Proably we should look at blacklisting using the idVendor and not just limit ourself to a single product. Thanks for reporting! --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Nov 6 09:30:34 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CEB2106564A for ; Sat, 6 Nov 2010 09:30:34 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id C67CA8FC12 for ; Sat, 6 Nov 2010 09:30:33 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=omSrwDgyMf70S47Fr5SNr0rQzcmIOo0IafWlB/wSLLo= c=1 sm=1 a=teY7EFdY6K0A:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=KPbmjg5OAAAA:8 a=XRaiuko2lMxwtP8Pe4QA:9 a=Z0xn6qAo_vVzdTbD-0zZhZzAn7oA:4 a=PUjeQqilurYA:10 a=QBVAwF9mRAkA:10 a=_-F24eGl5bsik_pZgkkA:9 a=KkmSBDNzQ_MqV3ngSOYA:7 a=HfB1V3pjwhSIJjL_-SBJJaOGREAA:4 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 46089929; Sat, 06 Nov 2010 10:30:26 +0100 From: Hans Petter Selasky To: Michael Martin Date: Sat, 6 Nov 2010 10:31:33 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <4CBFEBF5.30203@comcast.net> <201011042037.20274.hselasky@c2i.net> <4CD4ACC9.8040405@comcast.net> In-Reply-To: <4CD4ACC9.8040405@comcast.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_1BS1MPIyq+BfUSV" Message-Id: <201011061031.33986.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: USB 3.0 Fails To Attach Western Digital My Book 3.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 09:30:34 -0000 --Boundary-00=_1BS1MPIyq+BfUSV Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Hi, Can you revert the last patch I sent an apply the attached one? Then repeat the testing like last time. --HPS > > I captured several debug outputs here: > http://appliedtechnicalknowledge.com/freebsd/usb3-patch-214808/ . Maybe > something in these can help. --Boundary-00=_1BS1MPIyq+BfUSV Content-Type: text/plain; charset="iso-8859-15"; name="usb_30_hub_patch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="usb_30_hub_patch.txt" === usb_hub.c ================================================================== --- usb_hub.c (revision 214808) +++ usb_hub.c (local) @@ -126,9 +126,10 @@ static usb_callback_t uhub_intr_callback; -static void usb_dev_resume_peer(struct usb_device *udev); -static void usb_dev_suspend_peer(struct usb_device *udev); -static uint8_t usb_peer_should_wakeup(struct usb_device *udev); +static void usb_dev_resume_peer(struct usb_device *); +static void usb_dev_suspend_peer(struct usb_device *); +static uint8_t usb_peer_should_wakeup(struct usb_device *); +static uint8_t usb_device_20_compatible(struct usb_device *); static const struct usb_config uhub_config[UHUB_N_TRANSFER] = { @@ -394,13 +395,29 @@ usb_pause_mtx(NULL, USB_MS_TO_TICKS(USB_PORT_POWERUP_DELAY)); - /* reset port, which implies enabling it */ + if (usb_device_20_compatible(udev)) { + /* reset port, which implies enabling it */ + err = usbd_req_reset_port(udev, NULL, portno); + } else { + switch (UPS_PORT_LINK_STATE_GET(sc->sc_st.port_status)) { + case UPS_PORT_LS_U0: + case UPS_PORT_LS_U1: + case UPS_PORT_LS_U2: + case UPS_PORT_LS_U3: + /* no reset needed, link is already UP */ + break; + case UPS_PORT_LS_SS_INA: + /* try to recover link using a warm reset */ + goto error; + default: + /* reset port, which implies enabling it */ + err = usbd_req_reset_port(udev, NULL, portno); + break; + } + } - err = usbd_req_reset_port(udev, NULL, portno); - if (err) { - DPRINTFN(0, "port %d reset " - "failed, error=%s\n", + DPRINTFN(0, "port %d reset failed, error=%s\n", portno, usbd_errstr(err)); goto error; } @@ -517,17 +534,43 @@ usb_free_device(child, 0); child = NULL; } - if (err == 0) { + if (err) { + DPRINTFN(0, "device problem (%s), " + "port %u\n", usbd_errstr(err), portno); + goto error_ret; + } + if (usb_device_20_compatible(udev)) { + /* disable the port, if enabled */ if (sc->sc_st.port_status & UPS_PORT_ENABLED) { err = usbd_req_clear_port_feature( - sc->sc_udev, NULL, - portno, UHF_PORT_ENABLE); + udev, NULL, portno, UHF_PORT_ENABLE); } + } else { + /* get fresh status again */ + err = uhub_read_port_status(sc, portno); + if (err) + goto error_ret; + + switch (UPS_PORT_LINK_STATE_GET(sc->sc_st.port_status)) { + case UPS_PORT_LS_SS_INA: + /* Try a warm port reset to recover the port. */ + err = usbd_req_warm_reset_port(udev, NULL, portno); + if (err) { + DPRINTF("warm port reset failed.\n"); + goto error_ret; + } + break; + default: + /* disable the port, if enabled */ + if (sc->sc_st.port_status & UPS_PORT_ENABLED) { + err = usbd_req_clear_port_feature( + udev, NULL, portno, UHF_PORT_ENABLE); + } + break; + } } - if (err) { - DPRINTFN(0, "device problem (%s), " - "disabling port %d\n", usbd_errstr(err), portno); - } + +error_ret: return (err); } --Boundary-00=_1BS1MPIyq+BfUSV-- From owner-freebsd-usb@FreeBSD.ORG Sat Nov 6 13:57:51 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 537641065670; Sat, 6 Nov 2010 13:57:51 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E05B28FC0C; Sat, 6 Nov 2010 13:57:50 +0000 (UTC) Received: by iwn39 with SMTP id 39so4024936iwn.13 for ; Sat, 06 Nov 2010 06:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qneazsDNIHnT+FEsdzd/Vc6yhd1g6m4aAkCjeGHIAMw=; b=CFnhB3cCkSNfelW8UcFuxLarlS+3zZMlijDET3vxNkRySt9ibcgHRpjS7Om4X1K7/5 WR+P4/a1SOSG+F+qySywBouVWukTQfSpZarFVoXYlRR+vsxdXishRDf7Y11mFxC4xPbR BTt29+FPoWyra4/37TfiTOi2M/F2gJZ0YXSmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oZco27Wbk68/LY9YVT6k3pPpaQecIFIYOS9uT5ZdHrvfkRyXG7sYDcdWRuUUOSlgf+ ySk7pJPZh4nIrArxFMh36HqbQbgFkAWw3cqhpo3ZOnCurV1Lzcj5z8bC270IyWFeuX7p wC+EPwA8+NSTFkaxSnq9AKLOPb0ShcubMGC8c= MIME-Version: 1.0 Received: by 10.231.35.138 with SMTP id p10mr2659573ibd.33.1289051870364; Sat, 06 Nov 2010 06:57:50 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Sat, 6 Nov 2010 06:57:50 -0700 (PDT) In-Reply-To: <201011060937.50639.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011052000.37188.hselasky@c2i.net> <201011051506.12643.jhb@freebsd.org> <201011060937.50639.hselasky@c2i.net> Date: Sat, 6 Nov 2010 06:57:50 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 13:57:51 -0000 On Sat, Nov 6, 2010 at 1:37 AM, Hans Petter Selasky wrot= e: > On Friday 05 November 2010 20:06:12 John Baldwin wrote: >> On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: >> > On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: >> > > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky >> > >> > wrote: >> > > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: >> > > >> True, but no taskqueue(9) code can handle that. =A0Only the calle= r can >> > > >> prevent a task from becoming enqueued again. =A0The same issue ex= ists >> > > >> with taskqueue_drain(). >> > > > >> > > > I find that strange, because that means if I queue a task again wh= ile >> > > > it is running, then I doesn't get run? Are you really sure? >> > > >> > > If a task is currently running when enqueued, the task struct will b= e >> > > re-enqueued to the taskqueue. =A0When that task comes up as the head= of >> > > the queue, it will be run again. >> > >> > Right, and the taskqueue_cancel has to cancel in that state to, but it >> > doesn't because it only checks pending if !running() :-) ?? >> >> You can't close that race in taskqueue_cancel(). =A0You have to manage t= hat >> race yourself in your task handler. =A0For the callout(9) API we are onl= y >> able to close that race if you use callout_init_mtx() so that the code >> managing the callout wheel can make use of your lock to resolve the race= s. >> If you use callout_init() you have to explicitly manage these races in y= our >> callout handler. > > Hi, > > I think you are getting me wrong! In the initial "0001-Implement- > taskqueue_cancel-9-to-cancel-a-task-from-a.patch" you have the following = code- > chunk: > > +int > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > +{ > + =A0 =A0 =A0 int rc; > + > + =A0 =A0 =A0 TQ_LOCK(queue); > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&queue->tq_qu= eue, task, task, ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; > + =A0 =A0 =A0 } else > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; > + =A0 =A0 =A0 TQ_UNLOCK(queue); > + =A0 =A0 =A0 return (rc); > +} > > This code should be written like this, having the if (!task_is_running()) > after checking the ta_pending variable. > > +int > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > +{ > + =A0 =A0 =A0 int rc; > + > + =A0 =A0 =A0 TQ_LOCK(queue); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&queue->tq_qu= eue, task, task, ta_link); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->t= a_pending =3D 0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 if (!task_is_running(queue, task)) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; > + =A0 =A0 =A0 TQ_UNLOCK(queue); > + =A0 =A0 =A0 return (rc); > +} > > Or completely skip the !task_is_running() check. Else you are opening up = a > race in this function! Do I need to explain that more? Isn't it obvious? I think you're misunderstanding the existing taskqueue(9) implementation. As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, nor can the set of running tasks. So the order of checks is irrelevant. As John said, the taskqueue(9) implementation cannot protect consumers of it from re-queueing a task; that kind of serialization needs to happen at a higher level. taskqueue(9) is not quite like callout(9); the taskqueue(9) implementation drops all locks before calling the task's callback function. So once the task is running, taskqueue(9) can do nothing about it until the task stops running. This is why Jeff's implementation of taskqueue_cancel(9) slept if the task was running, and why mine returns an error code. The only way to know for sure that a task is "about" to run is to ask taskqueue(9), because there's a window where the TQ_LOCK is dropped before the callback is entered. Thanks, matthew From owner-freebsd-usb@FreeBSD.ORG Sat Nov 6 14:21:22 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D0D01065673; Sat, 6 Nov 2010 14:21:22 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4673E8FC0A; Sat, 6 Nov 2010 14:21:20 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=iBCGAMPDYtSF9sDXX85uHY3wcnYctfVT8vFpe3qPflY= c=1 sm=1 a=FberXtVRn-wA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=Z_5cUCg6Vf7GDme7dpcA:9 a=Ucnf10t7tCBU3dq19hQA:7 a=7vaHduFuufULc36w12w6ebi1-I0A:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45604739; Sat, 06 Nov 2010 15:21:19 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Sat, 6 Nov 2010 15:22:26 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011060937.50639.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011061522.26533.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Matthew Fleming , freebsd-usb@freebsd.org, Weongyo Jeong Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 14:21:22 -0000 Hi, On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: > > I think you're misunderstanding the existing taskqueue(9) implementation. > > As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, > nor can the set of running tasks. So the order of checks is > irrelevant. I agree that the order of checks is not important. That is not the problem. Cut & paste from suggested taskqueue patch from Fleming: > +int > > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > > +{ > > + int rc; > > + > > + TQ_LOCK(queue); > > + if (!task_is_running(queue, task)) { > > + if ((rc = task->ta_pending) > 0) > > + STAILQ_REMOVE(&queue->tq_queue, task, task, > > ta_link); + task->ta_pending = 0; > > + } else { > > + rc = -EBUSY; What happens in this case if ta_pending > 0. Are you saying this is not possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? > > + } > > + TQ_UNLOCK(queue); > > + return (rc); > > +} > > > As John said, the taskqueue(9) implementation cannot protect consumers > of it from re-queueing a task; that kind of serialization needs to > happen at a higher level. Agreed, but that is not what I'm pointing at. I'm pointing at what happens if you re-queue a task and then cancel while it is actually running. Will the task still be queued for execution after taskqueue_cancel()? > taskqueue(9) is not quite like callout(9); the taskqueue(9) > implementation drops all locks before calling the task's callback > function. So once the task is running, taskqueue(9) can do nothing > about it until the task stops running. This is not the problem. > > This is why Jeff's > implementation of taskqueue_cancel(9) slept if the task was running, > and why mine returns an error code. The only way to know for sure > that a task is "about" to run is to ask taskqueue(9), because there's > a window where the TQ_LOCK is dropped before the callback is entered. And if you re-queue and cancel in this window, shouldn't this also be handled like in the other cases? Cut & paste from kern/subr_taskqueue.c: task->ta_pending = 0; tb.tb_running = task; TQ_UNLOCK(queue); If a concurrent thread at exactly this point in time calls taskqueue_enqueue() on this task, then we re-add the task to the "queue->tq_queue". So far we agree. Imagine now that for some reason a following call to taskqueue_cancel() on this task at same point in time. Now, shouldn't taskqueue_cancel() also remove the task from the "queue->tq_queue" in this case aswell? Because in your implementation you only remove the task if we are not running, and that is not true when we are at exactly this point in time. task->ta_func(task->ta_context, pending); TQ_LOCK(queue); tb.tb_running = NULL; wakeup(task); Another issue I noticed is that the ta_pending counter should have a wrap protector. --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Nov 6 16:00:47 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CC8D106566B for ; Sat, 6 Nov 2010 16:00:47 +0000 (UTC) (envelope-from mgmartin@comcast.net) Received: from mx.appliedtechnicalknowledge.com (appliedtechnicalknowledge.com [173.14.31.49]) by mx1.freebsd.org (Postfix) with ESMTP id 290708FC08 for ; Sat, 6 Nov 2010 16:00:46 +0000 (UTC) Received: from [10.0.0.4] (gandalf.martins.home [10.0.0.4]) by mx.appliedtechnicalknowledge.com (Postfix) with ESMTPSA id 36DE012FF8C; Sat, 6 Nov 2010 10:00:46 -0600 (MDT) Message-ID: <4CD57BAE.2050402@comcast.net> Date: Sat, 06 Nov 2010 10:00:46 -0600 From: Michael Martin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101101 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hans Petter Selasky References: <4CBFEBF5.30203@comcast.net> <201011042037.20274.hselasky@c2i.net> <4CD4ACC9.8040405@comcast.net> <201011061031.33986.hselasky@c2i.net> In-Reply-To: <201011061031.33986.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: USB 3.0 Fails To Attach Western Digital My Book 3.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 16:00:47 -0000 On 11/06/2010 03:31, Hans Petter Selasky wrote: > Hi, > > Can you revert the last patch I sent an apply the attached one? > > Then repeat the testing like last time. > > --HPS > Here are the results: http://appliedtechnicalknowledge.com/freebsd/usb_30_hub_patch/ I used one drive/port for the testing. da0 not recognized on first boot, but came up after an unplug cable/plug cable. mm From owner-freebsd-usb@FreeBSD.ORG Sat Nov 6 16:25:41 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C382106564A for ; Sat, 6 Nov 2010 16:25:41 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6FB8FC1B for ; Sat, 6 Nov 2010 16:25:40 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=sEolSJAlcSxSMaOm1MQ0bvrIu+BNAN+OqG2UAUgC4Ok= c=1 sm=1 a=teY7EFdY6K0A:10 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=KPbmjg5OAAAA:8 a=x0CK8NteQSMHmu9Rw94A:9 a=bubUIP-3b6EbCvpru_puSsBncXgA:4 a=PUjeQqilurYA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 45437553; Sat, 06 Nov 2010 17:25:39 +0100 From: Hans Petter Selasky To: Michael Martin Date: Sat, 6 Nov 2010 17:26:46 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <4CBFEBF5.30203@comcast.net> <201011061031.33986.hselasky@c2i.net> <4CD57BAE.2050402@comcast.net> In-Reply-To: <4CD57BAE.2050402@comcast.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011061726.46655.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: USB 3.0 Fails To Attach Western Digital My Book 3.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 16:25:41 -0000 On Saturday 06 November 2010 17:00:46 Michael Martin wrote: > On 11/06/2010 03:31, Hans Petter Selasky wrote: > > Hi, > > > > Can you revert the last patch I sent an apply the attached one? > > > > Then repeat the testing like last time. > > > > --HPS > > Here are the results: > http://appliedtechnicalknowledge.com/freebsd/usb_30_hub_patch/ > > I used one drive/port for the testing. da0 not recognized on first > boot, but came up after an unplug cable/plug cable. Hi, I will have a closer look into this tomorrow. Does your device work when first recognized? What read/write speeds do you get? --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Nov 6 16:48:41 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC696106566B for ; Sat, 6 Nov 2010 16:48:41 +0000 (UTC) (envelope-from mgmartin@comcast.net) Received: from mx.appliedtechnicalknowledge.com (appliedtechnicalknowledge.com [173.14.31.49]) by mx1.freebsd.org (Postfix) with ESMTP id C72B08FC12 for ; Sat, 6 Nov 2010 16:48:41 +0000 (UTC) Received: from [10.0.0.4] (gandalf.martins.home [10.0.0.4]) by mx.appliedtechnicalknowledge.com (Postfix) with ESMTPSA id 2DF39137064; Sat, 6 Nov 2010 10:48:41 -0600 (MDT) Message-ID: <4CD586E9.4050109@comcast.net> Date: Sat, 06 Nov 2010 10:48:41 -0600 From: Michael Martin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101101 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hans Petter Selasky References: <4CBFEBF5.30203@comcast.net> <201011061031.33986.hselasky@c2i.net> <4CD57BAE.2050402@comcast.net> <201011061726.46655.hselasky@c2i.net> In-Reply-To: <201011061726.46655.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: USB 3.0 Fails To Attach Western Digital My Book 3.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 16:48:42 -0000 On 11/06/2010 10:26, Hans Petter Selasky wrote: > On Saturday 06 November 2010 17:00:46 Michael Martin wrote: >> On 11/06/2010 03:31, Hans Petter Selasky wrote: >>> Hi, >>> >>> Can you revert the last patch I sent an apply the attached one? >>> >>> Then repeat the testing like last time. >>> >>> --HPS >> Here are the results: >> http://appliedtechnicalknowledge.com/freebsd/usb_30_hub_patch/ >> >> I used one drive/port for the testing. da0 not recognized on first >> boot, but came up after an unplug cable/plug cable. > Hi, > > I will have a closer look into this tomorrow. Does your device work when first > recognized? What read/write speeds do you get? > > --HPS The device doesn't work when I try to import the zfs pool on the drive. The drive shows up in camcontrol ok. I initially exported the zfs file system to avoid attempts to mount it on boot. Once da0 is recognized by the kernel and camcontrol devlist shows it, I try a zpool import on the file system. The zpool import command hangs--sometimes the entire computer locks up, and I hard reboot the computer. I captured the usb logs during the zpool import for you there which captures some zfs i/o errors. mm From owner-freebsd-usb@FreeBSD.ORG Sat Nov 6 20:33:18 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC9EE10656C6; Sat, 6 Nov 2010 20:33:18 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 564398FC16; Sat, 6 Nov 2010 20:33:18 +0000 (UTC) Received: by iwn39 with SMTP id 39so4326861iwn.13 for ; Sat, 06 Nov 2010 13:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=teNB6EWR4XSnmTt3IQoFlxO0MPxY61lmOqo/4Vkkkyk=; b=QTPkZSxRVgIYuRNmcl7zm56VSwA4YHsYGLkAP5Zzxm+YGUV/JVgdkFox80Bm/5yitN a/4cjz6vRUTotF5kTuXrvWzK/ySR0YG5SnMPyJyDechgFruwITZ+ZED5bzsBbxyxXURV +6vVA6Gc13Pz4XAt0FsIwC3g8eQapIR0rs84c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HWJfT8+AdVD0tLl39v1yLP18AHJVCW2vEYrNUvQ393LQs+u8rJ9kEdYvdAhcjs3ysK G5Xcw5iBokYD3B7250ZWO0AnkFD/YsjUSZDG590duV3E//kR03mesaVn3XAvnWmnklJN r0hx8VDZ4LW/wMs7x/8YC2UzUHGBvTFrKZOGA= MIME-Version: 1.0 Received: by 10.42.97.67 with SMTP id m3mr502601icn.343.1289075597669; Sat, 06 Nov 2010 13:33:17 -0700 (PDT) Received: by 10.231.159.198 with HTTP; Sat, 6 Nov 2010 13:33:17 -0700 (PDT) In-Reply-To: <201011061522.26533.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011060937.50639.hselasky@c2i.net> <201011061522.26533.hselasky@c2i.net> Date: Sat, 6 Nov 2010 13:33:17 -0700 Message-ID: From: Matthew Fleming To: Hans Petter Selasky , John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Weongyo Jeong , freebsd-usb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 20:33:18 -0000 On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrot= e: > Hi, > > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: >> >> I think you're misunderstanding the existing taskqueue(9) implementation= . >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, >> nor can the set of running tasks. =A0So the order of checks is >> irrelevant. > > I agree that the order of checks is not important. That is not the proble= m. > > Cut & paste from suggested taskqueue patch from Fleming: > > =A0> +int >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >> > +{ >> > + =A0 =A0 =A0 int rc; >> > + >> > + =A0 =A0 =A0 TQ_LOCK(queue); >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0) >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&queue->tq= _queue, task, task, >> > ta_link); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; >> > + =A0 =A0 =A0 } else { >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; > > What happens in this case if ta_pending > 0. Are you saying this is not > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? Ah! I see what you mean. I'm not quite sure what the best thing to do here is; I agree it would be nice if taskqueue_cancel(9) dequeued the task, but I believe it also needs to indicate that the task is currently running. I guess the best thing would be to return the old pending count by reference parameter, and 0 or EBUSY to also indicate if there is a task currently running. Adding jhb@ to this mail since he has good thoughts on interfacing. Thanks, matthew > >> > + =A0 =A0 =A0 } >> > + =A0 =A0 =A0 TQ_UNLOCK(queue); >> > + =A0 =A0 =A0 return (rc); >> > +} >> > >> >> As John said, the taskqueue(9) implementation cannot protect consumers >> of it from re-queueing a task; that kind of serialization needs to >> happen at a higher level. > > Agreed, but that is not what I'm pointing at. I'm pointing at what happen= s if > you re-queue a task and then cancel while it is actually running. Will th= e > task still be queued for execution after taskqueue_cancel()? > >> taskqueue(9) is not quite like callout(9); the taskqueue(9) >> implementation drops all locks before calling the task's callback >> function. =A0So once the task is running, taskqueue(9) can do nothing >> about it until the task stops running. > > This is not the problem. > >> >> This is why Jeff's >> implementation of taskqueue_cancel(9) slept if the task was running, >> and why mine returns an error code. =A0The only way to know for sure >> that a task is "about" to run is to ask taskqueue(9), because there's >> a window where the TQ_LOCK is dropped before the callback is entered. > > And if you re-queue and cancel in this window, shouldn't this also be han= dled > like in the other cases? > > Cut & paste from kern/subr_taskqueue.c: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0task->ta_pending =3D 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tb.tb_running =3D task; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TQ_UNLOCK(queue); > > If a concurrent thread at exactly this point in time calls taskqueue_enqu= eue() > on this task, then we re-add the task to the "queue->tq_queue". So far we > agree. Imagine now that for some reason a following call to taskqueue_can= cel() > on this task at same point in time. Now, shouldn't taskqueue_cancel() als= o > remove the task from the "queue->tq_queue" in this case aswell? Because i= n > your implementation you only remove the task if we are not running, and t= hat > is not true when we are at exactly this point in time. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0task->ta_func(task->ta_context, pending); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TQ_LOCK(queue); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tb.tb_running =3D NULL; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wakeup(task); > > > Another issue I noticed is that the ta_pending counter should have a wrap > protector. > > --HPS >