From owner-freebsd-usb@FreeBSD.ORG Sun Dec 11 21:24:17 2011 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 A4646106564A; Sun, 11 Dec 2011 21:24:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BFBAB8FC08; Sun, 11 Dec 2011 21:24:16 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA07591; Sun, 11 Dec 2011 23:12:26 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RZqh7-000FE6-P7; Sun, 11 Dec 2011 23:12:25 +0200 Message-ID: <4EE51CB5.1060505@FreeBSD.org> Date: Sun, 11 Dec 2011 23:12:21 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: hackers@FreeBSD.org, usb@FreeBSD.org X-Enigmail-Version: undefined Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: kern_yield vs ukbd_yield 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, 11 Dec 2011 21:24:17 -0000 Does the following change do what I think that it does? Thank you! Author: Andriy Gapon Date: Thu Sep 1 16:50:13 2011 +0300 ukbd: drop local duplicate of kern_yield and use that instead diff --git a/sys/dev/usb/input/ukbd.c b/sys/dev/usb/input/ukbd.c index 086c178..8078cbb 100644 --- a/sys/dev/usb/input/ukbd.c +++ b/sys/dev/usb/input/ukbd.c @@ -399,33 +399,6 @@ ukbd_put_key(struct ukbd_softc *sc, uint32_t key) } static void -ukbd_yield(void) -{ - struct thread *td = curthread; - uint32_t old_prio; - - DROP_GIANT(); - - thread_lock(td); - - /* get current priority */ - old_prio = td->td_base_pri; - - /* set new priority */ - sched_prio(td, td->td_user_pri); - - /* cause a task switch */ - mi_switch(SW_INVOL | SWT_RELINQUISH, NULL); - - /* restore priority */ - sched_prio(td, old_prio); - - thread_unlock(td); - - PICKUP_GIANT(); -} - -static void ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) { @@ -439,7 +412,7 @@ ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) while (sc->sc_inputs == 0) { /* give USB threads a chance to run */ - ukbd_yield(); + kern_yield(-1); /* check if we should wait */ if (!wait) -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Sun Dec 11 22:14:55 2011 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 67708106564A; Sun, 11 Dec 2011 22:14:55 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3AD8F8FC08; Sun, 11 Dec 2011 22:14:55 +0000 (UTC) Received: by dakp5 with SMTP id p5so6230292dak.13 for ; Sun, 11 Dec 2011 14:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hGKvbBt7OTElgwthSin8lQtYXaR8pbn0yTH3esNC6Tk=; b=f8SY0RXP0Z42jq1HyAFLC+wVWOfAsEEmCpGMykDs40CkBkZeNVDFc4zDWamN50/VAz mgToxhepi2tICODyYh4cKQko42M9xlgOuWRh5GTHqRVm0LcKo/31MnV5c0bmCfRLyG45 yz+/EOiOSvhoHLIpzo/zem8w/FqggNZAyRzwc= MIME-Version: 1.0 Received: by 10.68.73.197 with SMTP id n5mr27911520pbv.102.1323640118897; Sun, 11 Dec 2011 13:48:38 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.197.198 with HTTP; Sun, 11 Dec 2011 13:48:38 -0800 (PST) In-Reply-To: <4EE51CB5.1060505@FreeBSD.org> References: <4EE51CB5.1060505@FreeBSD.org> Date: Sun, 11 Dec 2011 13:48:38 -0800 X-Google-Sender-Auth: CuN1Wy9vGWEcvAVA3vt0PIZGvIM Message-ID: From: mdf@FreeBSD.org To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: usb@freebsd.org, hackers@freebsd.org Subject: Re: kern_yield vs ukbd_yield 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, 11 Dec 2011 22:14:55 -0000 On Sun, Dec 11, 2011 at 1:12 PM, Andriy Gapon wrote: > > Does the following change do what I think that it does? > Thank you! > > Author: Andriy Gapon > Date: =A0 Thu Sep 1 16:50:13 2011 +0300 > > =A0 =A0ukbd: drop local duplicate of kern_yield and use that instead > > diff --git a/sys/dev/usb/input/ukbd.c b/sys/dev/usb/input/ukbd.c > index 086c178..8078cbb 100644 > --- a/sys/dev/usb/input/ukbd.c > +++ b/sys/dev/usb/input/ukbd.c > @@ -399,33 +399,6 @@ ukbd_put_key(struct ukbd_softc *sc, uint32_t key) > =A0} > > =A0static void > -ukbd_yield(void) > -{ > - =A0 =A0 =A0 struct thread *td =3D curthread; > - =A0 =A0 =A0 uint32_t old_prio; > - > - =A0 =A0 =A0 DROP_GIANT(); > - > - =A0 =A0 =A0 thread_lock(td); > - > - =A0 =A0 =A0 /* get current priority */ > - =A0 =A0 =A0 old_prio =3D td->td_base_pri; > - > - =A0 =A0 =A0 /* set new priority */ > - =A0 =A0 =A0 sched_prio(td, td->td_user_pri); > - > - =A0 =A0 =A0 /* cause a task switch */ > - =A0 =A0 =A0 mi_switch(SW_INVOL | SWT_RELINQUISH, NULL); > - > - =A0 =A0 =A0 /* restore priority */ > - =A0 =A0 =A0 sched_prio(td, old_prio); > - > - =A0 =A0 =A0 thread_unlock(td); > - > - =A0 =A0 =A0 PICKUP_GIANT(); > -} > - > -static void > =A0ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) > =A0{ > > @@ -439,7 +412,7 @@ ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while (sc->sc_inputs =3D=3D 0) { > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* give USB threads a chan= ce to run */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ukbd_yield(); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 kern_yield(-1); Not quite. 1) -1 should be spelled PRI_UNCHANGED, except ukbd_yield() uses td_user_pri, but then puts it back again, so I think UNCHANGED is what is meant. 2) kern_yield() calls it a SW_VOL rather than SW_INVOL, which seems the desired behaviour here anyways, since this is an explicit (i.e. voluntary) yield. Thanks, matthew From owner-freebsd-usb@FreeBSD.ORG Mon Dec 12 08:03:57 2011 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 CC9D3106564A; Mon, 12 Dec 2011 08:03:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B56BF8FC13; Mon, 12 Dec 2011 08:03:56 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA15030; Mon, 12 Dec 2011 10:03:55 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ra0ra-000Hye-Sz; Mon, 12 Dec 2011 10:03:54 +0200 Message-ID: <4EE5B56A.4000106@FreeBSD.org> Date: Mon, 12 Dec 2011 10:03:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: mdf@FreeBSD.org References: <4EE51CB5.1060505@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: usb@FreeBSD.org, hackers@FreeBSD.org Subject: Re: kern_yield vs ukbd_yield 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, 12 Dec 2011 08:03:57 -0000 on 11/12/2011 23:48 mdf@FreeBSD.org said the following: > On Sun, Dec 11, 2011 at 1:12 PM, Andriy Gapon wrote: >> >> Does the following change do what I think that it does? >> Thank you! >> >> Author: Andriy Gapon >> Date: Thu Sep 1 16:50:13 2011 +0300 >> >> ukbd: drop local duplicate of kern_yield and use that instead >> >> diff --git a/sys/dev/usb/input/ukbd.c b/sys/dev/usb/input/ukbd.c >> index 086c178..8078cbb 100644 >> --- a/sys/dev/usb/input/ukbd.c >> +++ b/sys/dev/usb/input/ukbd.c >> @@ -399,33 +399,6 @@ ukbd_put_key(struct ukbd_softc *sc, uint32_t key) >> } >> >> static void >> -ukbd_yield(void) >> -{ >> - struct thread *td = curthread; >> - uint32_t old_prio; >> - >> - DROP_GIANT(); >> - >> - thread_lock(td); >> - >> - /* get current priority */ >> - old_prio = td->td_base_pri; >> - >> - /* set new priority */ >> - sched_prio(td, td->td_user_pri); >> - >> - /* cause a task switch */ >> - mi_switch(SW_INVOL | SWT_RELINQUISH, NULL); >> - >> - /* restore priority */ >> - sched_prio(td, old_prio); >> - >> - thread_unlock(td); >> - >> - PICKUP_GIANT(); >> -} >> - >> -static void >> ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) >> { >> >> @@ -439,7 +412,7 @@ ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) >> while (sc->sc_inputs == 0) { >> >> /* give USB threads a chance to run */ >> - ukbd_yield(); >> + kern_yield(-1); > > Not quite. > > 1) -1 should be spelled PRI_UNCHANGED, except ukbd_yield() uses > td_user_pri, but then puts it back again, so I think UNCHANGED is what > is meant. > 2) kern_yield() calls it a SW_VOL rather than SW_INVOL, which seems > the desired behaviour here anyways, since this is an explicit (i.e. > voluntary) yield. Thank you for the explanation. So would you say that the patch is OK? -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Mon Dec 12 11:07:35 2011 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 31FDE106567F for ; Mon, 12 Dec 2011 11:07:35 +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 1F1318FC29 for ; Mon, 12 Dec 2011 11:07:35 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBCB7Zmn030183 for ; Mon, 12 Dec 2011 11:07:35 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBCB7Ysc030181 for freebsd-usb@FreeBSD.org; Mon, 12 Dec 2011 11:07:34 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Dec 2011 11:07:34 GMT Message-Id: <201112121107.pBCB7Ysc030181@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, 12 Dec 2011 11:07:35 -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/162712 usb added device on if_run. o usb/162306 usb usb devices cant get address asignation, no memories, o usb/162054 usb usbdump just hangs on 9.0-RC1 o usb/161793 usb poor EHCI usb2 i/o performance o usb/160911 usb The usb flash drive JetFlash Transcend 16GB 1100 doesn o usb/160436 usb ucom wedges machine on parity error ? o usb/160299 usb MicroSDHC-to-USB adapters do not work in FreeBSD 8.x o usb/160192 usb [install] Installation from USB-Stick doesn't find the o usb/159274 usb USB 3.0 Etron EJ168A does not work. f usb/159191 usb [fusefs-ntfs] write on fusefs-ntfs mounted partition r o usb/157376 usb LaCie USB disk not recognized o usb/157074 usb [boot] [usb8] vfs_mountroot_ask is called when no usb o usb/156898 usb [keyboard] usb keyboard does not work while boot (ps2 o usb/156735 usb Need Quirk for Goflex USB Disk Drives o usb/156725 usb USB stack stall cause complete system input loss o usb/156596 usb [ehci] Extremely high interrupt rate on ehci/uhci IRQ1 o usb/156000 usb rum(4) Fatal trap 18: integer divide fault while in ke o usb/155996 usb NanoBSD not booted as Disk o usb/155784 usb Problem with Transcend StoreJet 25M3 (2AJ1) on Asus M2 o usb/154710 usb [ugen] Conexant USB Modem is not working in 8.x. In 7. o usb/154506 usb [umass] Copying dir with large files makes FreeBSD loa o usb/154192 usb [umass] In Garmin Oregon GPS, only the first umass dev o i386/153851 usb [keyboard] keyboard issues on new Intel Mother boards. o usb/153703 usb [keyboard] My USB keyboard can not be used in 8-STABLE o usb/153609 usb [zyd] [panic] kernel: Fatal trap 12: page fault while o usb/153149 usb [umass] USB stick quirk regression [regression] o usb/152075 usb [usb8] [ehci] [request] Add quirk for CS5536 USB o usb/150892 usb [zyd] Whenever network contacted in any shape, way or o usb/150189 usb [run] [usb8] [patch] if_run appears to corrupt IP traf p usb/149934 usb [patch] [usb8] Transcend JetFlash V85 poor performance p usb/149900 usb [uftdi] [patch] FreeBSD 8.1 uftdi patch to support usb p usb/149764 usb [u3g] [patch] usbdevs update: Huawei K3765 3G modem 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 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 i386/147475 usb [install] FreeBSD 8.x does not install on ASUS K8N4-E p 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 f 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 p 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 p 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 p 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 f 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 [usb8] Encrypted root, geli password at boot; enter ke 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 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 o usb/139243 usb [uhci] [usb67] unplug prolific USB serial -> uhci_abor 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/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 f 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 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/135206 usb machine reboots when inserted USB device f usb/135200 usb SAMSUNG i740 usb mass: Synchronize cache failed, statu 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/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 o usb/131074 usb no run-time detection of usb devices plugged into exte o usb/130736 usb Page fault unplugging USB stick o 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 f usb/129766 usb [usb] [panic] plugging in usb modem HUAWEI E226 panics 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 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/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 f usb/125450 usb [panic] Removing USB flash card while being accessed c 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 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 s usb/122819 usb [usb67] [patch] Patch to provide dynamic additions to 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/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/121169 usb [umass] Issues with usb mp3 player o usb/121045 usb [uftdi] [patch] Add support for PC-OP-RS1 and KURO-RS f 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/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/119509 usb [usb] USB flaky on Dell Optiplex 755 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/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 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 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/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 [usb67] SMP-Kernel crashes reliably when Bluetooth con 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 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. f 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 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/83504 usb [kernel] [patch] SpeedTouch USB stop working on recent 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. 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 " o 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/76653 usb [umass] [patch] Problem with Asahi Optical usb device 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 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/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/69006 usb [usbdevs] [patch] Apple Cinema Display hangs USB ports 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 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 294 problems total. From owner-freebsd-usb@FreeBSD.ORG Mon Dec 12 15:55:39 2011 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 04603106568B; Mon, 12 Dec 2011 15:55:39 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C366A8FC16; Mon, 12 Dec 2011 15:55:38 +0000 (UTC) Received: by pbcc3 with SMTP id c3so1421804pbc.13 for ; Mon, 12 Dec 2011 07:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LVNI0dsH6t38MaDE8Bum3cfnK4RkvPdQP/TfyWG2fck=; b=cqiW3/lsb1ZNfh9tSbIDFSEiWFl3F3kCvKYEiZVs+doPAbpYqJWTSqLuks1t5T8Vzc LVznDMw/KcbZD388McItVbuqE6T3YkfH184te+8F9lOL4AC2uzjzlZ48pZZC6cTJFia9 Xo1TCLPaK2Ed3/iiuVR9Ugn98MsK3cG3uTL9I= MIME-Version: 1.0 Received: by 10.68.72.230 with SMTP id g6mr23147601pbv.119.1323705338115; Mon, 12 Dec 2011 07:55:38 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.197.198 with HTTP; Mon, 12 Dec 2011 07:55:38 -0800 (PST) In-Reply-To: <4EE5B56A.4000106@FreeBSD.org> References: <4EE51CB5.1060505@FreeBSD.org> <4EE5B56A.4000106@FreeBSD.org> Date: Mon, 12 Dec 2011 07:55:38 -0800 X-Google-Sender-Auth: JFKoPj31iT2LTiDvbOUmiyPW2Rg Message-ID: From: mdf@FreeBSD.org To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: usb@freebsd.org, hackers@freebsd.org Subject: Re: kern_yield vs ukbd_yield 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, 12 Dec 2011 15:55:39 -0000 On Mon, Dec 12, 2011 at 12:03 AM, Andriy Gapon wrote: > on 11/12/2011 23:48 mdf@FreeBSD.org said the following: >> On Sun, Dec 11, 2011 at 1:12 PM, Andriy Gapon wrote: >>> >>> Does the following change do what I think that it does? >>> Thank you! >>> >>> Author: Andriy Gapon >>> Date: =A0 Thu Sep 1 16:50:13 2011 +0300 >>> >>> =A0 =A0ukbd: drop local duplicate of kern_yield and use that instead >>> >>> diff --git a/sys/dev/usb/input/ukbd.c b/sys/dev/usb/input/ukbd.c >>> index 086c178..8078cbb 100644 >>> --- a/sys/dev/usb/input/ukbd.c >>> +++ b/sys/dev/usb/input/ukbd.c >>> @@ -399,33 +399,6 @@ ukbd_put_key(struct ukbd_softc *sc, uint32_t key) >>> =A0} >>> >>> =A0static void >>> -ukbd_yield(void) >>> -{ >>> - =A0 =A0 =A0 struct thread *td =3D curthread; >>> - =A0 =A0 =A0 uint32_t old_prio; >>> - >>> - =A0 =A0 =A0 DROP_GIANT(); >>> - >>> - =A0 =A0 =A0 thread_lock(td); >>> - >>> - =A0 =A0 =A0 /* get current priority */ >>> - =A0 =A0 =A0 old_prio =3D td->td_base_pri; >>> - >>> - =A0 =A0 =A0 /* set new priority */ >>> - =A0 =A0 =A0 sched_prio(td, td->td_user_pri); >>> - >>> - =A0 =A0 =A0 /* cause a task switch */ >>> - =A0 =A0 =A0 mi_switch(SW_INVOL | SWT_RELINQUISH, NULL); >>> - >>> - =A0 =A0 =A0 /* restore priority */ >>> - =A0 =A0 =A0 sched_prio(td, old_prio); >>> - >>> - =A0 =A0 =A0 thread_unlock(td); >>> - >>> - =A0 =A0 =A0 PICKUP_GIANT(); >>> -} >>> - >>> -static void >>> =A0ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) >>> =A0{ >>> >>> @@ -439,7 +412,7 @@ ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while (sc->sc_inputs =3D=3D 0) { >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* give USB threads a ch= ance to run */ >>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ukbd_yield(); >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 kern_yield(-1); >> >> Not quite. >> >> 1) -1 should be spelled PRI_UNCHANGED, except ukbd_yield() uses >> td_user_pri, but then puts it back again, so I think UNCHANGED is what >> is meant. >> 2) kern_yield() calls it a SW_VOL rather than SW_INVOL, which seems >> the desired behaviour here anyways, since this is an explicit (i.e. >> voluntary) yield. > > Thank you for the explanation. =A0So would you say that the patch is OK? As far as I know, yes. There may be a difference in behaviour, though, while yielding, if the priority of the thread remains high (as this change would make it) -- I'm not completely sure how the scheduler chooses threads, because I'm pretty sure I've seen it take threads with lower (higher numbered) priorities even when there's runnable threads with a higher (lower numbered) priority available. It has always seemed weird to me that the priorities in the kernel are strictly higher than user-space -- but only after a prio change like that done implicitly by many of the calls to sleep(9). So it may be that the better patch is to use PRI_USER, not PRI_UNCHANGED, which would revert any potentially changed thread prio (e.g. due to a sleep(9)) back to its user-space level, so that it contended as expected with other threads. hselasky@ or someone else familiar with the various usb threads would have to answer that. From owner-freebsd-usb@FreeBSD.ORG Mon Dec 12 16:11:03 2011 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 E0856106566B; Mon, 12 Dec 2011 16:11:02 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id EC1108FC0C; Mon, 12 Dec 2011 16:11:01 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 215800158; Mon, 12 Dec 2011 17:00:56 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Mon, 12 Dec 2011 16:58:22 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EE51CB5.1060505@FreeBSD.org> <4EE5B56A.4000106@FreeBSD.org> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112121658.22864.hselasky@c2i.net> Cc: usb@freebsd.org, mdf@freebsd.org, hackers@freebsd.org, Andriy Gapon Subject: Re: kern_yield vs ukbd_yield 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, 12 Dec 2011 16:11:03 -0000 On Monday 12 December 2011 16:55:38 mdf@freebsd.org wrote: > On Mon, Dec 12, 2011 at 12:03 AM, Andriy Gapon wrote: > > on 11/12/2011 23:48 mdf@FreeBSD.org said the following: > >> On Sun, Dec 11, 2011 at 1:12 PM, Andriy Gapon wrote: > >>> Does the following change do what I think that it does? > >>> Thank you! > >>> > >>> Author: Andriy Gapon > >>> Date: Thu Sep 1 16:50:13 2011 +0300 > >>> > >>> ukbd: drop local duplicate of kern_yield and use that instead > >>> > >>> diff --git a/sys/dev/usb/input/ukbd.c b/sys/dev/usb/input/ukbd.c > >>> index 086c178..8078cbb 100644 > >>> --- a/sys/dev/usb/input/ukbd.c > >>> +++ b/sys/dev/usb/input/ukbd.c > >>> @@ -399,33 +399,6 @@ ukbd_put_key(struct ukbd_softc *sc, uint32_t key) > >>> } > >>> > >>> static void > >>> -ukbd_yield(void) > >>> -{ > >>> - struct thread *td = curthread; > >>> - uint32_t old_prio; > >>> - > >>> - DROP_GIANT(); > >>> - > >>> - thread_lock(td); > >>> - > >>> - /* get current priority */ > >>> - old_prio = td->td_base_pri; > >>> - > >>> - /* set new priority */ > >>> - sched_prio(td, td->td_user_pri); > >>> - > >>> - /* cause a task switch */ > >>> - mi_switch(SW_INVOL | SWT_RELINQUISH, NULL); > >>> - > >>> - /* restore priority */ > >>> - sched_prio(td, old_prio); > >>> - > >>> - thread_unlock(td); > >>> - > >>> - PICKUP_GIANT(); > >>> -} > >>> - > >>> -static void > >>> ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) > >>> { > >>> > >>> @@ -439,7 +412,7 @@ ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) > >>> while (sc->sc_inputs == 0) { > >>> > >>> /* give USB threads a chance to run */ > >>> - ukbd_yield(); > >>> + kern_yield(-1); > >> > >> Not quite. > >> > >> 1) -1 should be spelled PRI_UNCHANGED, except ukbd_yield() uses > >> td_user_pri, but then puts it back again, so I think UNCHANGED is what > >> is meant. > >> 2) kern_yield() calls it a SW_VOL rather than SW_INVOL, which seems > >> the desired behaviour here anyways, since this is an explicit (i.e. > >> voluntary) yield. > > > > Thank you for the explanation. So would you say that the patch is OK? > > As far as I know, yes. There may be a difference in behaviour, > though, while yielding, if the priority of the thread remains high (as > this change would make it) -- I'm not completely sure how the > scheduler chooses threads, because I'm pretty sure I've seen it take > threads with lower (higher numbered) priorities even when there's > runnable threads with a higher (lower numbered) priority available. > > It has always seemed weird to me that the priorities in the kernel are > strictly higher than user-space -- but only after a prio change like > that done implicitly by many of the calls to sleep(9). So it may be > that the better patch is to use PRI_USER, not PRI_UNCHANGED, which > would revert any potentially changed thread prio (e.g. due to a > sleep(9)) back to its user-space level, so that it contended as > expected with other threads. > Hi, > hselasky@ or someone else familiar with the various usb threads would > have to answer that. The problem is only during init() where the init thread has highest priority and that doesn't allow other threads to run even if the scheduler is running! --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Dec 12 19:05:40 2011 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 0FEF41065672; Mon, 12 Dec 2011 19:05:40 +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 C88AF8FC14; Mon, 12 Dec 2011 19:05:39 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 75B2346B23; Mon, 12 Dec 2011 14:05:39 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 04A38B93A; Mon, 12 Dec 2011 14:05:39 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 12 Dec 2011 14:05:38 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EE51CB5.1060505@FreeBSD.org> <201112121658.22864.hselasky@c2i.net> In-Reply-To: <201112121658.22864.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112121405.38322.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 12 Dec 2011 14:05:39 -0500 (EST) Cc: usb@freebsd.org, mdf@freebsd.org, hackers@freebsd.org, Andriy Gapon Subject: Re: kern_yield vs ukbd_yield 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, 12 Dec 2011 19:05:40 -0000 On Monday, December 12, 2011 10:58:22 am Hans Petter Selasky wrote: > On Monday 12 December 2011 16:55:38 mdf@freebsd.org wrote: > > On Mon, Dec 12, 2011 at 12:03 AM, Andriy Gapon wrote: > > > on 11/12/2011 23:48 mdf@FreeBSD.org said the following: > > >> On Sun, Dec 11, 2011 at 1:12 PM, Andriy Gapon wrote: > > >>> Does the following change do what I think that it does? > > >>> Thank you! > > >>> > > >>> Author: Andriy Gapon > > >>> Date: Thu Sep 1 16:50:13 2011 +0300 > > >>> > > >>> ukbd: drop local duplicate of kern_yield and use that instead > > >>> > > >>> diff --git a/sys/dev/usb/input/ukbd.c b/sys/dev/usb/input/ukbd.c > > >>> index 086c178..8078cbb 100644 > > >>> --- a/sys/dev/usb/input/ukbd.c > > >>> +++ b/sys/dev/usb/input/ukbd.c > > >>> @@ -399,33 +399,6 @@ ukbd_put_key(struct ukbd_softc *sc, uint32_t key) > > >>> } > > >>> > > >>> static void > > >>> -ukbd_yield(void) > > >>> -{ > > >>> - struct thread *td = curthread; > > >>> - uint32_t old_prio; > > >>> - > > >>> - DROP_GIANT(); > > >>> - > > >>> - thread_lock(td); > > >>> - > > >>> - /* get current priority */ > > >>> - old_prio = td->td_base_pri; > > >>> - > > >>> - /* set new priority */ > > >>> - sched_prio(td, td->td_user_pri); > > >>> - > > >>> - /* cause a task switch */ > > >>> - mi_switch(SW_INVOL | SWT_RELINQUISH, NULL); > > >>> - > > >>> - /* restore priority */ > > >>> - sched_prio(td, old_prio); > > >>> - > > >>> - thread_unlock(td); > > >>> - > > >>> - PICKUP_GIANT(); > > >>> -} > > >>> - > > >>> -static void > > >>> ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) > > >>> { > > >>> > > >>> @@ -439,7 +412,7 @@ ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) > > >>> while (sc->sc_inputs == 0) { > > >>> > > >>> /* give USB threads a chance to run */ > > >>> - ukbd_yield(); > > >>> + kern_yield(-1); > > >> > > >> Not quite. > > >> > > >> 1) -1 should be spelled PRI_UNCHANGED, except ukbd_yield() uses > > >> td_user_pri, but then puts it back again, so I think UNCHANGED is what > > >> is meant. > > >> 2) kern_yield() calls it a SW_VOL rather than SW_INVOL, which seems > > >> the desired behaviour here anyways, since this is an explicit (i.e. > > >> voluntary) yield. > > > > > > Thank you for the explanation. So would you say that the patch is OK? > > > > As far as I know, yes. There may be a difference in behaviour, > > though, while yielding, if the priority of the thread remains high (as > > this change would make it) -- I'm not completely sure how the > > scheduler chooses threads, because I'm pretty sure I've seen it take > > threads with lower (higher numbered) priorities even when there's > > runnable threads with a higher (lower numbered) priority available. The scheduler generally should not do this with the following exceptions: 1) for timesharing threads, priorities are in bands, so effectively the pri / 4 is what is used for comparison and if two threads have the same pri / 4 the scheduler will round-robin among htem. 2) ULE might be a bit different because of the way it assigns threads to CPUs, so if a CPU has two high priority threads and another CPU only has a low priority thread, the second CPU will not run the second high priority thread. 4BSD handles this case more correctly. > > It has always seemed weird to me that the priorities in the kernel are > > strictly higher than user-space -- but only after a prio change like > > that done implicitly by many of the calls to sleep(9). So it may be > > that the better patch is to use PRI_USER, not PRI_UNCHANGED, which > > would revert any potentially changed thread prio (e.g. due to a > > sleep(9)) back to its user-space level, so that it contended as > > expected with other threads. Realtime priorities (for rtprio user threads) are higher than the kernel "sleep" priorities. Also, keep in mind that a thread does not get an automatic priority boost when it enters the kernel. It only gets a boost either temporarily from priority propagation, or a slightly longer (but still temporary) boost from a sleep(9) call. > Hi, > > > hselasky@ or someone else familiar with the various usb threads would > > have to answer that. > > The problem is only during init() where the init thread has highest priority > and that doesn't allow other threads to run even if the scheduler is running! Hmm, that should be fixed by lowering the relevant thread's priority. Do you mean thread0 (the one doing all the SYSINIT's or thread we create for init (pid 1) before it executes init? -- John Baldwin From owner-freebsd-usb@FreeBSD.ORG Mon Dec 12 19:11:49 2011 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 9C82E106564A; Mon, 12 Dec 2011 19:11:49 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 73B298FC0A; Mon, 12 Dec 2011 19:11:48 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 48773972; Mon, 12 Dec 2011 20:11:46 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org, Andriy Gapon Date: Mon, 12 Dec 2011 20:09:12 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EE51CB5.1060505@FreeBSD.org> <201112121658.22864.hselasky@c2i.net> <201112121405.38322.jhb@freebsd.org> In-Reply-To: <201112121405.38322.jhb@freebsd.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112122009.12557.hselasky@c2i.net> Cc: usb@freebsd.org, mdf@freebsd.org, John Baldwin Subject: Re: kern_yield vs ukbd_yield 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, 12 Dec 2011 19:11:49 -0000 On Monday 12 December 2011 20:05:38 John Baldwin wrote: > > Hi, > > > > > > > > > hselasky@ or someone else familiar with the various usb threads would > > > have to answer that. > > > > > > > > The problem is only during init() where the init thread has highest > > priority and that doesn't allow other threads to run even if the > > scheduler is > > running! > > Hmm, that should be fixed by lowering the relevant thread's priority. > Do you mean thread0 (the one doing all the SYSINIT's or thread we create > for init (pid 1) before it executes init? Yes, thread0. Correct! --HPS From owner-freebsd-usb@FreeBSD.ORG Mon Dec 12 19:13:50 2011 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 16C54106564A; Mon, 12 Dec 2011 19:13:50 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id C55998FC0A; Mon, 12 Dec 2011 19:13:49 +0000 (UTC) Received: by dakp5 with SMTP id p5so7351381dak.13 for ; Mon, 12 Dec 2011 11:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hZ8jPOrL9/CZdLmXWzfhaF0zRX46QB3ln3lyS4C1Nj4=; b=XsIk2CzLNkx75Vz5BI0J9APskBH6JnlnkLfF2lnpVB9y5R+ekfHu0Ygyp5stVQ2Idy ZASq6qD+/uIZE+EXuhkXN5URg1TEHwRRFffJH2fAXYk+zkiQlD1sQHs58OXfOOKgM+9c hl6q7h2Ih+ObuO8vYkiBnE9B4ye2RYennGADM= MIME-Version: 1.0 Received: by 10.68.73.197 with SMTP id n5mr36556308pbv.102.1323717229215; Mon, 12 Dec 2011 11:13:49 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.197.198 with HTTP; Mon, 12 Dec 2011 11:13:49 -0800 (PST) In-Reply-To: <201112121405.38322.jhb@freebsd.org> References: <4EE51CB5.1060505@FreeBSD.org> <201112121658.22864.hselasky@c2i.net> <201112121405.38322.jhb@freebsd.org> Date: Mon, 12 Dec 2011 11:13:49 -0800 X-Google-Sender-Auth: tA1WgJS5KaNFUvDe4pesRX4T_5A Message-ID: From: mdf@FreeBSD.org To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: usb@freebsd.org, freebsd-hackers@freebsd.org, hackers@freebsd.org, Andriy Gapon Subject: Re: kern_yield vs ukbd_yield 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, 12 Dec 2011 19:13:50 -0000 On Mon, Dec 12, 2011 at 11:05 AM, John Baldwin wrote: > On Monday, December 12, 2011 10:58:22 am Hans Petter Selasky wrote: >> On Monday 12 December 2011 16:55:38 mdf@freebsd.org wrote: >> > On Mon, Dec 12, 2011 at 12:03 AM, Andriy Gapon wrote= : >> > > on 11/12/2011 23:48 mdf@FreeBSD.org said the following: >> > >> On Sun, Dec 11, 2011 at 1:12 PM, Andriy Gapon wro= te: >> > >>> Does the following change do what I think that it does? >> > >>> Thank you! >> > >>> >> > >>> Author: Andriy Gapon >> > >>> Date: =A0 Thu Sep 1 16:50:13 2011 +0300 >> > >>> >> > >>> =A0 =A0ukbd: drop local duplicate of kern_yield and use that inste= ad >> > >>> >> > >>> diff --git a/sys/dev/usb/input/ukbd.c b/sys/dev/usb/input/ukbd.c >> > >>> index 086c178..8078cbb 100644 >> > >>> --- a/sys/dev/usb/input/ukbd.c >> > >>> +++ b/sys/dev/usb/input/ukbd.c >> > >>> @@ -399,33 +399,6 @@ ukbd_put_key(struct ukbd_softc *sc, uint32_t = key) >> > >>> =A0} >> > >>> >> > >>> =A0static void >> > >>> -ukbd_yield(void) >> > >>> -{ >> > >>> - =A0 =A0 =A0 struct thread *td =3D curthread; >> > >>> - =A0 =A0 =A0 uint32_t old_prio; >> > >>> - >> > >>> - =A0 =A0 =A0 DROP_GIANT(); >> > >>> - >> > >>> - =A0 =A0 =A0 thread_lock(td); >> > >>> - >> > >>> - =A0 =A0 =A0 /* get current priority */ >> > >>> - =A0 =A0 =A0 old_prio =3D td->td_base_pri; >> > >>> - >> > >>> - =A0 =A0 =A0 /* set new priority */ >> > >>> - =A0 =A0 =A0 sched_prio(td, td->td_user_pri); >> > >>> - >> > >>> - =A0 =A0 =A0 /* cause a task switch */ >> > >>> - =A0 =A0 =A0 mi_switch(SW_INVOL | SWT_RELINQUISH, NULL); >> > >>> - >> > >>> - =A0 =A0 =A0 /* restore priority */ >> > >>> - =A0 =A0 =A0 sched_prio(td, old_prio); >> > >>> - >> > >>> - =A0 =A0 =A0 thread_unlock(td); >> > >>> - >> > >>> - =A0 =A0 =A0 PICKUP_GIANT(); >> > >>> -} >> > >>> - >> > >>> -static void >> > >>> =A0ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) >> > >>> =A0{ >> > >>> >> > >>> @@ -439,7 +412,7 @@ ukbd_do_poll(struct ukbd_softc *sc, uint8_t wa= it) >> > >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while (sc->sc_inputs =3D=3D 0) { >> > >>> >> > >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* give USB threads= a chance to run */ >> > >>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ukbd_yield(); >> > >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 kern_yield(-1); >> > >> >> > >> Not quite. >> > >> >> > >> 1) -1 should be spelled PRI_UNCHANGED, except ukbd_yield() uses >> > >> td_user_pri, but then puts it back again, so I think UNCHANGED is w= hat >> > >> is meant. >> > >> 2) kern_yield() calls it a SW_VOL rather than SW_INVOL, which seems >> > >> the desired behaviour here anyways, since this is an explicit (i.e. >> > >> voluntary) yield. >> > > >> > > Thank you for the explanation. =A0So would you say that the patch is= OK? >> > >> > As far as I know, yes. =A0There may be a difference in behaviour, >> > though, while yielding, if the priority of the thread remains high (as >> > this change would make it) -- I'm not completely sure how the >> > scheduler chooses threads, because I'm pretty sure I've seen it take >> > threads with lower (higher numbered) priorities even when there's >> > runnable threads with a higher (lower numbered) priority available. > > The scheduler generally should not do this with the following exceptions: > > =A01) for timesharing threads, priorities are in bands, so effectively th= e > =A0 =A0pri / 4 is what is used for comparison and if two threads have the= same > =A0 =A0pri / 4 the scheduler will round-robin among htem. > > =A02) ULE might be a bit different because of the way it assigns threads = to > =A0 =A0CPUs, so if a CPU has two high priority threads and another CPU on= ly > =A0 =A0has a low priority thread, the second CPU will not run the second = high > =A0 =A0priority thread. =A04BSD handles this case more correctly. > >> > It has always seemed weird to me that the priorities in the kernel are >> > strictly higher than user-space -- but only after a prio change like >> > that done implicitly by many of the calls to sleep(9). =A0So it may be >> > that the better patch is to use PRI_USER, not PRI_UNCHANGED, which >> > would revert any potentially changed thread prio (e.g. due to a >> > sleep(9)) back to its user-space level, so that it contended as >> > expected with other threads. > > Realtime priorities (for rtprio user threads) are higher than the kernel > "sleep" priorities. =A0Also, keep in mind that a thread does not get an > automatic priority boost when it enters the kernel. =A0It only gets a boo= st > either temporarily from priority propagation, or a slightly longer (but > still temporary) boost from a sleep(9) call. I still don't understand why threads are boosting their priority while sleeping; if it's so they are woken preferentially, that makes some sense, but then they shouldn't be keeping the boosted priority after the thread is woken. If a thread really needs higher priority to do its work, that should be an explicit call to sched_prio(9), rather than implicitly only when/if it first sleeps. Thanks, matthew >> > hselasky@ or someone else familiar with the various usb threads would >> > have to answer that. >> >> The problem is only during init() where the init thread has highest prio= rity >> and that doesn't allow other threads to run even if the scheduler is > running! > > Hmm, that should be fixed by lowering the relevant thread's priority. > Do you mean thread0 (the one doing all the SYSINIT's or thread we create = for > init (pid 1) before it executes init? > > -- > John Baldwin From owner-freebsd-usb@FreeBSD.ORG Mon Dec 12 21:18:09 2011 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 951531065677; Mon, 12 Dec 2011 21:18:09 +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 59AC48FC1C; Mon, 12 Dec 2011 21:18:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 04E9A46B0D; Mon, 12 Dec 2011 16:18:09 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 795A7B948; Mon, 12 Dec 2011 16:18:08 -0500 (EST) From: John Baldwin To: mdf@freebsd.org Date: Mon, 12 Dec 2011 16:18:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EE51CB5.1060505@FreeBSD.org> <201112121405.38322.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112121618.07833.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 12 Dec 2011 16:18:08 -0500 (EST) Cc: usb@freebsd.org, freebsd-hackers@freebsd.org, hackers@freebsd.org, Andriy Gapon Subject: Re: kern_yield vs ukbd_yield 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, 12 Dec 2011 21:18:09 -0000 On Monday, December 12, 2011 2:13:49 pm mdf@freebsd.org wrote: > On Mon, Dec 12, 2011 at 11:05 AM, John Baldwin wrote: > > On Monday, December 12, 2011 10:58:22 am Hans Petter Selasky wrote: > >> On Monday 12 December 2011 16:55:38 mdf@freebsd.org wrote: > >> > On Mon, Dec 12, 2011 at 12:03 AM, Andriy Gapon wrote: > >> > > on 11/12/2011 23:48 mdf@FreeBSD.org said the following: > >> > >> On Sun, Dec 11, 2011 at 1:12 PM, Andriy Gapon wrote: > >> > >>> Does the following change do what I think that it does? > >> > >>> Thank you! > >> > >>> > >> > >>> Author: Andriy Gapon > >> > >>> Date: Thu Sep 1 16:50:13 2011 +0300 > >> > >>> > >> > >>> ukbd: drop local duplicate of kern_yield and use that instead > >> > >>> > >> > >>> diff --git a/sys/dev/usb/input/ukbd.c b/sys/dev/usb/input/ukbd.c > >> > >>> index 086c178..8078cbb 100644 > >> > >>> --- a/sys/dev/usb/input/ukbd.c > >> > >>> +++ b/sys/dev/usb/input/ukbd.c > >> > >>> @@ -399,33 +399,6 @@ ukbd_put_key(struct ukbd_softc *sc, uint32_t key) > >> > >>> } > >> > >>> > >> > >>> static void > >> > >>> -ukbd_yield(void) > >> > >>> -{ > >> > >>> - struct thread *td = curthread; > >> > >>> - uint32_t old_prio; > >> > >>> - > >> > >>> - DROP_GIANT(); > >> > >>> - > >> > >>> - thread_lock(td); > >> > >>> - > >> > >>> - /* get current priority */ > >> > >>> - old_prio = td->td_base_pri; > >> > >>> - > >> > >>> - /* set new priority */ > >> > >>> - sched_prio(td, td->td_user_pri); > >> > >>> - > >> > >>> - /* cause a task switch */ > >> > >>> - mi_switch(SW_INVOL | SWT_RELINQUISH, NULL); > >> > >>> - > >> > >>> - /* restore priority */ > >> > >>> - sched_prio(td, old_prio); > >> > >>> - > >> > >>> - thread_unlock(td); > >> > >>> - > >> > >>> - PICKUP_GIANT(); > >> > >>> -} > >> > >>> - > >> > >>> -static void > >> > >>> ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) > >> > >>> { > >> > >>> > >> > >>> @@ -439,7 +412,7 @@ ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait) > >> > >>> while (sc->sc_inputs == 0) { > >> > >>> > >> > >>> /* give USB threads a chance to run */ > >> > >>> - ukbd_yield(); > >> > >>> + kern_yield(-1); > >> > >> > >> > >> Not quite. > >> > >> > >> > >> 1) -1 should be spelled PRI_UNCHANGED, except ukbd_yield() uses > >> > >> td_user_pri, but then puts it back again, so I think UNCHANGED is what > >> > >> is meant. > >> > >> 2) kern_yield() calls it a SW_VOL rather than SW_INVOL, which seems > >> > >> the desired behaviour here anyways, since this is an explicit (i.e. > >> > >> voluntary) yield. > >> > > > >> > > Thank you for the explanation. So would you say that the patch is OK? > >> > > >> > As far as I know, yes. There may be a difference in behaviour, > >> > though, while yielding, if the priority of the thread remains high (as > >> > this change would make it) -- I'm not completely sure how the > >> > scheduler chooses threads, because I'm pretty sure I've seen it take > >> > threads with lower (higher numbered) priorities even when there's > >> > runnable threads with a higher (lower numbered) priority available. > > > > The scheduler generally should not do this with the following exceptions: > > > > 1) for timesharing threads, priorities are in bands, so effectively the > > pri / 4 is what is used for comparison and if two threads have the same > > pri / 4 the scheduler will round-robin among htem. > > > > 2) ULE might be a bit different because of the way it assigns threads to > > CPUs, so if a CPU has two high priority threads and another CPU only > > has a low priority thread, the second CPU will not run the second high > > priority thread. 4BSD handles this case more correctly. > > > >> > It has always seemed weird to me that the priorities in the kernel are > >> > strictly higher than user-space -- but only after a prio change like > >> > that done implicitly by many of the calls to sleep(9). So it may be > >> > that the better patch is to use PRI_USER, not PRI_UNCHANGED, which > >> > would revert any potentially changed thread prio (e.g. due to a > >> > sleep(9)) back to its user-space level, so that it contended as > >> > expected with other threads. > > > > Realtime priorities (for rtprio user threads) are higher than the kernel > > "sleep" priorities. Also, keep in mind that a thread does not get an > > automatic priority boost when it enters the kernel. It only gets a boost > > either temporarily from priority propagation, or a slightly longer (but > > still temporary) boost from a sleep(9) call. > > I still don't understand why threads are boosting their priority while > sleeping; if it's so they are woken preferentially, that makes some > sense, but then they shouldn't be keeping the boosted priority after > the thread is woken. If a thread really needs higher priority to do > its work, that should be an explicit call to sched_prio(9), rather > than implicitly only when/if it first sleeps. This is how the BSD scheduler traditionally boosted the priority of "interactive" threads to favor them over CPU-bound threads. That is, BSD assumed that interactive threads are going to be blocking in the kernel (on a socket, on a tty, etc.), then running for a little bit after waking before blocking again. The boost when you sleep is to let threads with that work pattern always have a higher priority than CPU-bound threads (which will always have priorities in the timeshare range). You have to keep the boost long enough to ensure you get some user time however, so the threads keep the raised priority out to the userland boundary where it is dropped in userret(), but it is intentionally done in a careful manner where the thread drops its priority but does not do a reschedule so it will still run out in userland with the "effective" priority from its boost until the next schedule event happens (timeslice expires, thread blocks, etc.). Preemption from ithreads makes scheduling events happen far more often though (prior to SMPng, interrupts didn't trigger a reschedule), so interactive threads perhaps don't get favored quite as much since 5. -- John Baldwin From owner-freebsd-usb@FreeBSD.ORG Mon Dec 12 22:21:13 2011 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 623181065672; Mon, 12 Dec 2011 22:21:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B7D458FC08; Mon, 12 Dec 2011 22:21:11 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA29084; Tue, 13 Dec 2011 00:21:06 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RaEF7-000Ibl-Pz; Tue, 13 Dec 2011 00:21:05 +0200 Message-ID: <4EE67E4F.3010906@FreeBSD.org> Date: Tue, 13 Dec 2011 00:21:03 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EE51CB5.1060505@FreeBSD.org> <201112121658.22864.hselasky@c2i.net> <201112121405.38322.jhb@freebsd.org> <201112122009.12557.hselasky@c2i.net> In-Reply-To: <201112122009.12557.hselasky@c2i.net> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: usb@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin , mdf@FreeBSD.org Subject: Re: kern_yield vs ukbd_yield 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, 12 Dec 2011 22:21:13 -0000 on 12/12/2011 21:09 Hans Petter Selasky said the following: > On Monday 12 December 2011 20:05:38 John Baldwin wrote: >>> Hi, >>> >>> >>> >>>> hselasky@ or someone else familiar with the various usb threads would >>>> have to answer that. >>> >>> >>> >>> The problem is only during init() where the init thread has highest >>> priority and that doesn't allow other threads to run even if the >>> scheduler is >> >> running! >> >> Hmm, that should be fixed by lowering the relevant thread's priority. >> Do you mean thread0 (the one doing all the SYSINIT's or thread we create >> for init (pid 1) before it executes init? > > Yes, thread0. Correct! Mmm, my short debugging session with qemu shows that it is actually pid 1: Breakpoint 1, ukbd_do_poll (sc=0xffffff8000764000, wait=0 '\0') at /usr/src/sys/dev/usb/input/ukbd.c:403 403 { (kgdb) bt #0 ukbd_do_poll (sc=0xffffff8000764000, wait=0 '\0') at /usr/src/sys/dev/usb/input/ukbd.c:403 #1 0xffffffff803ee57e in ukbd_check (kbd=Variable "kbd" is not available. ) at /usr/src/sys/dev/usb/input/ukbd.c:1418 #2 0xffffffff803ee674 in ukbd_check_char (kbd=0xffffff8000764000) at /usr/src/sys/dev/usb/input/ukbd.c:1450 #3 0xffffffff8035c794 in kbdmux_read_char (kbd=0xfffffe00021d2c00, wait=Variable "wait" is not available. ) at /usr/src/sys/dev/kbdmux/kbdmux.c:665 #4 0xffffffff803bf4aa in scgetc (sc=0xffffffff81835dc0, flags=Variable "flags" is not available. ) at /usr/src/sys/dev/syscons/syscons.c:3373 #5 0xffffffff803c2d03 in sc_cngetc (cd=Variable "cd" is not available. ) at /usr/src/sys/dev/syscons/syscons.c:1753 #6 0xffffffff804ae489 in cncheckc () at /usr/src/sys/kern/kern_cons.c:402 #7 0xffffffff804ae4c7 in cngetc () at /usr/src/sys/kern/kern_cons.c:383 #8 0xffffffff804ae9a7 in cngets (cp=0xffffff8000326aa0 "", size=80, visible=1) at /usr/src/sys/kern/kern_cons.c:421 #9 0xffffffff80594d4e in vfs_mountroot () at /usr/src/sys/kern/vfs_mountroot.c:490 #10 0xffffffff804a6e65 in start_init (dummy=Variable "dummy" is not available. ) at /usr/src/sys/kern/init_main.c:683 #11 0xffffffff804c5a9a in fork_exit (callout=0xffffffff804a6e00 , arg=0x0, frame=0xffffff8000326c50) at /usr/src/sys/kern/kern_fork.c:995 #12 0xffffffff806bb72e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 #13 0x0000000000000000 in ?? () (kgdb) p td->td_proc->p_pid $7 = 1 (kgdb) p td->td_proc->p_comm $8 = "kernel", '\0' (kgdb) p td->td_tid $9 = 100002 Also: (kgdb) p/d td->td_user_pri $10 = 139 (kgdb) p/d td->td_base_pri $11 = 84 -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Tue Dec 13 08:17:47 2011 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 35AA5106566B; Tue, 13 Dec 2011 08:17:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C870F8FC14; Tue, 13 Dec 2011 08:17:45 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA06506; Tue, 13 Dec 2011 10:17:38 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RaNYP-000LLp-EZ; Tue, 13 Dec 2011 10:17:37 +0200 Message-ID: <4EE70A1F.8040406@FreeBSD.org> Date: Tue, 13 Dec 2011 10:17:35 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EE51CB5.1060505@FreeBSD.org> <201112121658.22864.hselasky@c2i.net> <201112121405.38322.jhb@freebsd.org> <201112122009.12557.hselasky@c2i.net> <4EE67E4F.3010906@FreeBSD.org> In-Reply-To: <4EE67E4F.3010906@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: usb@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin , mdf@FreeBSD.org Subject: Re: kern_yield vs ukbd_yield 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, 13 Dec 2011 08:17:47 -0000 on 13/12/2011 00:21 Andriy Gapon said the following: > on 12/12/2011 21:09 Hans Petter Selasky said the following: >> On Monday 12 December 2011 20:05:38 John Baldwin wrote: >>>> Hi, >>>> >>>> >>>> >>>>> hselasky@ or someone else familiar with the various usb threads would >>>>> have to answer that. >>>> >>>> >>>> >>>> The problem is only during init() where the init thread has highest >>>> priority and that doesn't allow other threads to run even if the >>>> scheduler is >>> >>> running! >>> >>> Hmm, that should be fixed by lowering the relevant thread's priority. >>> Do you mean thread0 (the one doing all the SYSINIT's or thread we create >>> for init (pid 1) before it executes init? >> >> Yes, thread0. Correct! > > Mmm, my short debugging session with qemu shows that it is actually pid 1: And in the view of the below data I would like us to revisit this problem. I looked over usb code and it seems that all usb threads are created with priorities of either USB_PRI_MED or USB_PRI_HIGH, which translates to PI_SWI(SWI_CAMBIO) and PI_SWI(SWI_NET). These priorities should be in the ithread range, so it's kind of surprising that the init thread (with PVM priority) can cause troubles for them. > Breakpoint 1, ukbd_do_poll (sc=0xffffff8000764000, wait=0 '\0') at > /usr/src/sys/dev/usb/input/ukbd.c:403 > 403 { > (kgdb) bt > #0 ukbd_do_poll (sc=0xffffff8000764000, wait=0 '\0') at > /usr/src/sys/dev/usb/input/ukbd.c:403 > #1 0xffffffff803ee57e in ukbd_check (kbd=Variable "kbd" is not available. > ) at /usr/src/sys/dev/usb/input/ukbd.c:1418 > #2 0xffffffff803ee674 in ukbd_check_char (kbd=0xffffff8000764000) at > /usr/src/sys/dev/usb/input/ukbd.c:1450 > #3 0xffffffff8035c794 in kbdmux_read_char (kbd=0xfffffe00021d2c00, > wait=Variable "wait" is not available. > ) at /usr/src/sys/dev/kbdmux/kbdmux.c:665 > #4 0xffffffff803bf4aa in scgetc (sc=0xffffffff81835dc0, flags=Variable "flags" > is not available. > ) at /usr/src/sys/dev/syscons/syscons.c:3373 > #5 0xffffffff803c2d03 in sc_cngetc (cd=Variable "cd" is not available. > ) at /usr/src/sys/dev/syscons/syscons.c:1753 > #6 0xffffffff804ae489 in cncheckc () at /usr/src/sys/kern/kern_cons.c:402 > #7 0xffffffff804ae4c7 in cngetc () at /usr/src/sys/kern/kern_cons.c:383 > #8 0xffffffff804ae9a7 in cngets (cp=0xffffff8000326aa0 "", size=80, visible=1) > at /usr/src/sys/kern/kern_cons.c:421 > #9 0xffffffff80594d4e in vfs_mountroot () at /usr/src/sys/kern/vfs_mountroot.c:490 > #10 0xffffffff804a6e65 in start_init (dummy=Variable "dummy" is not available. > ) at /usr/src/sys/kern/init_main.c:683 > #11 0xffffffff804c5a9a in fork_exit (callout=0xffffffff804a6e00 , > arg=0x0, frame=0xffffff8000326c50) at /usr/src/sys/kern/kern_fork.c:995 > #12 0xffffffff806bb72e in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:602 > #13 0x0000000000000000 in ?? () > (kgdb) p td->td_proc->p_pid > $7 = 1 > (kgdb) p td->td_proc->p_comm > $8 = "kernel", '\0' > (kgdb) p td->td_tid > $9 = 100002 > > Also: > (kgdb) p/d td->td_user_pri > $10 = 139 > (kgdb) p/d td->td_base_pri > $11 = 84 > -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Wed Dec 14 08:53:11 2011 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 A1AC61065670 for ; Wed, 14 Dec 2011 08:53:11 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 2CFC48FC22 for ; Wed, 14 Dec 2011 08:53:10 +0000 (UTC) X-T2-Spam-Status: No, hits=0.5 required=5.0 tests=ALL_TRUSTED, BAYES_60 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 217336488 for freebsd-usb@freebsd.org; Wed, 14 Dec 2011 09:53:09 +0100 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Wed, 14 Dec 2011 09:50:35 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201112140950.35760.hselasky@c2i.net> Subject: Re: run(4) patch 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, 14 Dec 2011 08:53:11 -0000 On Wednesday 14 December 2011 02:53:23 PseudoCylon wrote: > fix random USB transfer time out Committed: http://svn.freebsd.org/changeset/base/228494 --HPS From owner-freebsd-usb@FreeBSD.ORG Wed Dec 14 15:37:58 2011 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 0589E106564A; Wed, 14 Dec 2011 15:37:58 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AD5558FC08; Wed, 14 Dec 2011 15:37:56 +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 RAA08219; Wed, 14 Dec 2011 17:37:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EE8C2CE.40909@FreeBSD.org> Date: Wed, 14 Dec 2011 17:37:50 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EE51CB5.1060505@FreeBSD.org> <201112121658.22864.hselasky@c2i.net> <201112121405.38322.jhb@freebsd.org> <201112122009.12557.hselasky@c2i.net> <4EE67E4F.3010906@FreeBSD.org> <4EE70A1F.8040406@FreeBSD.org> In-Reply-To: <4EE70A1F.8040406@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: usb@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin , mdf@FreeBSD.org Subject: Re: kern_yield vs ukbd_yield 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, 14 Dec 2011 15:37:58 -0000 on 13/12/2011 10:17 Andriy Gapon said the following: > on 13/12/2011 00:21 Andriy Gapon said the following: [snip] > And in the view of the below data I would like us to revisit this problem. > I looked over usb code and it seems that all usb threads are created with > priorities of either USB_PRI_MED or USB_PRI_HIGH, which translates to > PI_SWI(SWI_CAMBIO) and PI_SWI(SWI_NET). These priorities should be in the > ithread range, so it's kind of surprising that the init thread (with PVM > priority) can cause troubles for them. So, Hans Petter, do you recall any details of this problem? I am curious about which thread got starved by which. BTW, given your recent improvements to pause(9) what do you think about further extending it to also use DELAY(9) when kdb_active is set or when SCHEDULER_STOPPED() is true? Then, probably, pause(9) could be used for both branches in ukbd_do_poll and they could be collapsed together. >> Breakpoint 1, ukbd_do_poll (sc=0xffffff8000764000, wait=0 '\0') at >> /usr/src/sys/dev/usb/input/ukbd.c:403 >> 403 { >> (kgdb) bt >> #0 ukbd_do_poll (sc=0xffffff8000764000, wait=0 '\0') at >> /usr/src/sys/dev/usb/input/ukbd.c:403 >> #1 0xffffffff803ee57e in ukbd_check (kbd=Variable "kbd" is not available. >> ) at /usr/src/sys/dev/usb/input/ukbd.c:1418 >> #2 0xffffffff803ee674 in ukbd_check_char (kbd=0xffffff8000764000) at >> /usr/src/sys/dev/usb/input/ukbd.c:1450 >> #3 0xffffffff8035c794 in kbdmux_read_char (kbd=0xfffffe00021d2c00, >> wait=Variable "wait" is not available. >> ) at /usr/src/sys/dev/kbdmux/kbdmux.c:665 >> #4 0xffffffff803bf4aa in scgetc (sc=0xffffffff81835dc0, flags=Variable "flags" >> is not available. >> ) at /usr/src/sys/dev/syscons/syscons.c:3373 >> #5 0xffffffff803c2d03 in sc_cngetc (cd=Variable "cd" is not available. >> ) at /usr/src/sys/dev/syscons/syscons.c:1753 >> #6 0xffffffff804ae489 in cncheckc () at /usr/src/sys/kern/kern_cons.c:402 >> #7 0xffffffff804ae4c7 in cngetc () at /usr/src/sys/kern/kern_cons.c:383 >> #8 0xffffffff804ae9a7 in cngets (cp=0xffffff8000326aa0 "", size=80, visible=1) >> at /usr/src/sys/kern/kern_cons.c:421 >> #9 0xffffffff80594d4e in vfs_mountroot () at /usr/src/sys/kern/vfs_mountroot.c:490 >> #10 0xffffffff804a6e65 in start_init (dummy=Variable "dummy" is not available. >> ) at /usr/src/sys/kern/init_main.c:683 >> #11 0xffffffff804c5a9a in fork_exit (callout=0xffffffff804a6e00 , >> arg=0x0, frame=0xffffff8000326c50) at /usr/src/sys/kern/kern_fork.c:995 >> #12 0xffffffff806bb72e in fork_trampoline () at >> /usr/src/sys/amd64/amd64/exception.S:602 >> #13 0x0000000000000000 in ?? () >> (kgdb) p td->td_proc->p_pid >> $7 = 1 >> (kgdb) p td->td_proc->p_comm >> $8 = "kernel", '\0' >> (kgdb) p td->td_tid >> $9 = 100002 >> >> Also: >> (kgdb) p/d td->td_user_pri >> $10 = 139 >> (kgdb) p/d td->td_base_pri >> $11 = 84 >> > > -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Wed Dec 14 21:59:10 2011 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 D5A78106564A; Wed, 14 Dec 2011 21:59:10 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 637A48FC0A; Wed, 14 Dec 2011 21:59:09 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 215899356; Wed, 14 Dec 2011 22:59:05 +0100 From: Hans Petter Selasky To: Andriy Gapon Date: Wed, 14 Dec 2011 22:56:32 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EE51CB5.1060505@FreeBSD.org> <4EE70A1F.8040406@FreeBSD.org> <4EE8C2CE.40909@FreeBSD.org> In-Reply-To: <4EE8C2CE.40909@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201112142256.32526.hselasky@c2i.net> Cc: usb@freebsd.org, freebsd-hackers@freebsd.org, John Baldwin , mdf@freebsd.org Subject: Re: kern_yield vs ukbd_yield 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, 14 Dec 2011 21:59:10 -0000 On Wednesday 14 December 2011 16:37:50 Andriy Gapon wrote: > on 13/12/2011 10:17 Andriy Gapon said the following: > > on 13/12/2011 00:21 Andriy Gapon said the following: > [snip] >=20 > > And in the view of the below data I would like us to revisit this > > problem. I looked over usb code and it seems that all usb threads are > > created with priorities of either USB_PRI_MED or USB_PRI_HIGH, which > > translates to PI_SWI(SWI_CAMBIO) and PI_SWI(SWI_NET). These priorities > > should be in the ithread range, so it's kind of surprising that the init > > thread (with PVM priority) can cause troubles for them. >=20 > So, Hans Petter, do you recall any details of this problem? > I am curious about which thread got starved by which. =46rom what I know this was 100% reproducible. Remove the ukbd_yield() when at the mountroot prompt. Result: cannot type a= ny=20 keys. No USB devices will enumerate! >=20 > BTW, given your recent improvements to pause(9) what do you think about > further extending it to also use DELAY(9) when kdb_active is set or when > SCHEDULER_STOPPED() is true?=20 I think this is a good idea. It already checks for "cold". USB usually does= n't=20 use this function though when polling. > Then, probably, pause(9) could be used for > both branches in ukbd_do_poll and they could be collapsed together. =2D-HPS From owner-freebsd-usb@FreeBSD.ORG Thu Dec 15 14:17:09 2011 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 A6DFC106566B; Thu, 15 Dec 2011 14:17:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF748FC0C; Thu, 15 Dec 2011 14:17:07 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA29161; Thu, 15 Dec 2011 16:17:03 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RbC7L-0002Lq-62; Thu, 15 Dec 2011 16:17:03 +0200 Message-ID: <4EEA015D.8020800@FreeBSD.org> Date: Thu, 15 Dec 2011 16:17:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EE51CB5.1060505@FreeBSD.org> <4EE70A1F.8040406@FreeBSD.org> <4EE8C2CE.40909@FreeBSD.org> <201112142256.32526.hselasky@c2i.net> In-Reply-To: <201112142256.32526.hselasky@c2i.net> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: usb@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin , mdf@FreeBSD.org Subject: Re: kern_yield vs ukbd_yield 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, 15 Dec 2011 14:17:09 -0000 on 14/12/2011 23:56 Hans Petter Selasky said the following: > On Wednesday 14 December 2011 16:37:50 Andriy Gapon wrote: >> So, Hans Petter, do you recall any details of this problem? >> I am curious about which thread got starved by which. > > From what I know this was 100% reproducible. > > Remove the ukbd_yield() when at the mountroot prompt. Result: cannot type any > keys. No USB devices will enumerate! This hasn't satisfied my curiosity :) >> >> BTW, given your recent improvements to pause(9) what do you think about >> further extending it to also use DELAY(9) when kdb_active is set or when >> SCHEDULER_STOPPED() is true? > > I think this is a good idea. It already checks for "cold". USB usually doesn't > use this function though when polling. > >> Then, probably, pause(9) could be used for >> both branches in ukbd_do_poll and they could be collapsed together. Hmm... I looked at the history of ukbd.c (which I should have done from the very start) and I see two relevant revisions: http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=199816&r2=203896&pathrev=203896 http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=223755&r2=223989&pathrev=223989 So, first use of pause(9) was introduced to work around current broken syscons polling mechanism. Then pause(9) was replaced with the hand-rolled yield to fix a problem at shutdown, which supposedly was caused by times being stopped. None of the commits seems to be directly related to thread priorities. I suspect that even DELAY(9) could have worked in the place of the pause/yield. Also, I do not see any mentioning of the mountroot context in the commits. Not sure why I even assumed that it was relevant. BTW, maybe we should have a 'cold again' flag for late stages of system shutdown? So, all in all, I believe in the following two things: 1. kern_yield can be used instead of ukbd_yield with any argument 1.1. DELAY() can be used instead of ukbd_yield too 2. all that special code should not be needed once I commit the patches that I have recently posted to arch@ (I do intend to commit them). In that case the keyboard drivers would be properly put into the polling mode instead of the current situation where the polling mode is repeatedly entered and exited when kernel needs some input. Maybe you recall/know more than you wrote above and I have missed something obvious that you can point out? -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Thu Dec 15 22:59:10 2011 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 4F0BB106564A; Thu, 15 Dec 2011 22:59:10 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.c2i.net [212.247.155.2]) by mx1.freebsd.org (Postfix) with ESMTP id C2A378FC18; Thu, 15 Dec 2011 22:59:08 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 43467472; Thu, 15 Dec 2011 23:59:06 +0100 From: Hans Petter Selasky To: Andriy Gapon Date: Thu, 15 Dec 2011 23:56:35 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EE51CB5.1060505@FreeBSD.org> <201112142256.32526.hselasky@c2i.net> <4EEA015D.8020800@FreeBSD.org> In-Reply-To: <4EEA015D.8020800@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112152356.35336.hselasky@c2i.net> Cc: usb@freebsd.org, freebsd-hackers@freebsd.org, John Baldwin , mdf@freebsd.org Subject: Re: kern_yield vs ukbd_yield 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, 15 Dec 2011 22:59:10 -0000 On Thursday 15 December 2011 15:17:01 Andriy Gapon wrote: > on 14/12/2011 23:56 Hans Petter Selasky said the following: > > On Wednesday 14 December 2011 16:37:50 Andriy Gapon wrote: > >> So, Hans Petter, do you recall any details of this problem? > >> I am curious about which thread got starved by which. > > > > From what I know this was 100% reproducible. > > > > Remove the ukbd_yield() when at the mountroot prompt. Result: cannot type > > any keys. No USB devices will enumerate! > > This hasn't satisfied my curiosity :) > > >> BTW, given your recent improvements to pause(9) what do you think about > >> further extending it to also use DELAY(9) when kdb_active is set or when > >> SCHEDULER_STOPPED() is true? > > > > I think this is a good idea. It already checks for "cold". USB usually > > doesn't use this function though when polling. > > > >> Then, probably, pause(9) could be used for > >> both branches in ukbd_do_poll and they could be collapsed together. > > Hmm... I looked at the history of ukbd.c (which I should have done from the > very start) and I see two relevant revisions: > http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=199816&r2=2 > 03896&pathrev=203896 > http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=223755&r2= > 223989&pathrev=223989 > > So, first use of pause(9) was introduced to work around current broken > syscons polling mechanism. Then pause(9) was replaced with the > hand-rolled yield to fix a problem at shutdown, which supposedly was > caused by times being stopped. > > None of the commits seems to be directly related to thread priorities. Not directly, but indirect. You know, if you pause thread 1 (which I thought was thread 0), then other thread will get a chance to run. It might also be that Giant is locked by syscons, and that unless you pause or yield, then Giant will block other parts of USB, like the callback thread, which is Giant locked for ukbd only to run. Maybe that is the explanation? > I > suspect that even DELAY(9) could have worked in the place of the > pause/yield. Also, I do not see any mentioning of the mountroot context in > the commits. Not sure why I even assumed that it was relevant. > > BTW, maybe we should have a 'cold again' flag for late stages of system > shutdown? > > So, all in all, I believe in the following two things: > > 1. kern_yield can be used instead of ukbd_yield with any argument > > 1.1. DELAY() can be used instead of ukbd_yield too No, it doesn't drop Giant, see above. > > 2. all that special code should not be needed once I commit the patches > that I have recently posted to arch@ (I do intend to commit them). In > that case the keyboard drivers would be properly put into the polling mode > instead of the current situation where the polling mode is repeatedly > entered and exited when kernel needs some input. Just make sure all the use-cases work. Then you can safely commit: 1) mountroot prompt 2) dump at shutdown 3) kernel debugger (enter and exit) keyboard should work before and after. > > Maybe you recall/know more than you wrote above and I have missed something > obvious that you can point out? --HPS From owner-freebsd-usb@FreeBSD.ORG Thu Dec 15 23:06:04 2011 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 828D8106566B; Thu, 15 Dec 2011 23:06:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2BA1C8FC12; Thu, 15 Dec 2011 23:06:02 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA06233; Fri, 16 Dec 2011 01:05:58 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RbKNC-0002gY-2b; Fri, 16 Dec 2011 01:05:58 +0200 Message-ID: <4EEA7D52.4000503@FreeBSD.org> Date: Fri, 16 Dec 2011 01:05:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EE51CB5.1060505@FreeBSD.org> <201112142256.32526.hselasky@c2i.net> <4EEA015D.8020800@FreeBSD.org> <201112152356.35336.hselasky@c2i.net> In-Reply-To: <201112152356.35336.hselasky@c2i.net> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: usb@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin , mdf@FreeBSD.org Subject: Re: kern_yield vs ukbd_yield 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, 15 Dec 2011 23:06:04 -0000 on 16/12/2011 00:56 Hans Petter Selasky said the following: > On Thursday 15 December 2011 15:17:01 Andriy Gapon wrote: >> Hmm... I looked at the history of ukbd.c (which I should have done from the >> very start) and I see two relevant revisions: >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=199816&r2=2 >> 03896&pathrev=203896 >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=223755&r2= >> 223989&pathrev=223989 >> >> So, first use of pause(9) was introduced to work around current broken >> syscons polling mechanism. Then pause(9) was replaced with the >> hand-rolled yield to fix a problem at shutdown, which supposedly was >> caused by times being stopped. >> >> None of the commits seems to be directly related to thread priorities. > > Not directly, but indirect. You know, if you pause thread 1 (which I thought > was thread 0), then other thread will get a chance to run. > > It might also be that Giant is locked by syscons, and that unless you pause or > yield, then Giant will block other parts of USB, like the callback thread, > which is Giant locked for ukbd only to run. > > Maybe that is the explanation? Maybe. Perhaps even. But let me quote the commit messages just in case. Commit message #1: Detect when we are polling from kernel via cngetc() in the boot process and reserve the keypresses so they do not get passed to syscons. Commit message #2: Fix for dump after shutdown with USB keyboard plugged in. It appears that the system timer is stopped during shutdown and that the pause() statement in ukbd causes infinite hang in this regard. The fix is to use mi_switch() instead of pause() to do the required task switch to ensure that the required USB processes get executed. So the reason I asked the above question was that the issues that we are discussing now were never mentioned before. So if you know that those issue really exist, then maybe it is worthwhile describing and documenting them in detail. As you can see the commit messages mention neither thread priorities nor Giant, instead they talk about other rather specific (and plausible) issues. -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Thu Dec 15 23:19:08 2011 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 39D201065672; Thu, 15 Dec 2011 23:19:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id E294F8FC12; Thu, 15 Dec 2011 23:19:06 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 216457661; Fri, 16 Dec 2011 00:19:04 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Fri, 16 Dec 2011 00:16:33 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EE51CB5.1060505@FreeBSD.org> <201112152356.35336.hselasky@c2i.net> <4EEA7D52.4000503@FreeBSD.org> In-Reply-To: <4EEA7D52.4000503@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112160016.33776.hselasky@c2i.net> Cc: usb@freebsd.org, mdf@freebsd.org, John Baldwin , Andriy Gapon Subject: Re: kern_yield vs ukbd_yield 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, 15 Dec 2011 23:19:08 -0000 On Friday 16 December 2011 00:05:54 Andriy Gapon wrote: > on 16/12/2011 00:56 Hans Petter Selasky said the following: > > On Thursday 15 December 2011 15:17:01 Andriy Gapon wrote: > >> Hmm... I looked at the history of ukbd.c (which I should have done from > >> the very start) and I see two relevant revisions: > >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=199816&r > >> 2=2 03896&pathrev=203896 > >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=223755&r > >> 2= 223989&pathrev=223989 > >> > >> So, first use of pause(9) was introduced to work around current broken > >> syscons polling mechanism. Then pause(9) was replaced with the > >> hand-rolled yield to fix a problem at shutdown, which supposedly was > >> caused by times being stopped. > >> > >> None of the commits seems to be directly related to thread priorities. > > > > Not directly, but indirect. You know, if you pause thread 1 (which I > > thought was thread 0), then other thread will get a chance to run. > > > > It might also be that Giant is locked by syscons, and that unless you > > pause or yield, then Giant will block other parts of USB, like the > > callback thread, which is Giant locked for ukbd only to run. > > > > Maybe that is the explanation? > > Maybe. Perhaps even. But let me quote the commit messages just in case. > > Commit message #1: > Detect when we are polling from kernel via cngetc() in the boot process and > reserve the keypresses so they do not get passed to syscons. > > Commit message #2: > Fix for dump after shutdown with USB keyboard plugged in. It appears that > the system timer is stopped during shutdown and that the pause() statement > in ukbd causes infinite hang in this regard. The fix is to use mi_switch() > instead of pause() to do the required task switch to ensure that the > required USB processes get executed. > > So the reason I asked the above question was that the issues that we are > discussing now were never mentioned before. So if you know that those > issue really exist, then maybe it is worthwhile describing and documenting > them in detail. As you can see the commit messages mention neither thread > priorities nor Giant, instead they talk about other rather specific (and > plausible) issues. Hi, I think I was not aware about the Giant locking maybe having something to do about this. I was just thinking about this recently, that syscons and all keyboard stuff, currently is Giant locked. Scary? I can always become better writing commit messages! What is your plan forward then with regard to the Giant lock problem? If one thread is like: while (1) { lock(Giant); c = get nonblocking key from console(); unlock(Giant); } And the other is like: if (callback complete) { lock(Giant); run callback(); unlock(Giant); } Who gets to run? --HPS From owner-freebsd-usb@FreeBSD.ORG Fri Dec 16 05:33:04 2011 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 DE5131065678; Fri, 16 Dec 2011 05:33:04 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6458FC17; Fri, 16 Dec 2011 05:33:03 +0000 (UTC) Received: by wgbds13 with SMTP id ds13so2412434wgb.1 for ; Thu, 15 Dec 2011 21:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=G0Z1SPKkqjUJAXMXpKk9KMNixzwCxvoAx60PldVxx/g=; b=eV6VWp9FaDLXsQ0KmY1LiQ6R0R+el9Jv70YPAw2/SnVhNTgM+APWeNOv4rRsL77XML sq0k2t1DUOx/2AMi3kjwrORP9S54cSj3EAoooaakSChT5QM18QMaxY/hpkdAX+GUBs5C 67redY0CM3wLmeXutJ4T00s1Yjp+RRLWHTG7o= MIME-Version: 1.0 Received: by 10.180.104.2 with SMTP id ga2mr12158931wib.33.1324012027630; Thu, 15 Dec 2011 21:07:07 -0800 (PST) Received: by 10.216.65.145 with HTTP; Thu, 15 Dec 2011 21:07:07 -0800 (PST) Date: Thu, 15 Dec 2011 23:07:07 -0600 Message-ID: From: Brandon Gooch To: freebsd-usb@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Hans Petter Selasky Subject: xhci_do_command: Command timeout! 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, 16 Dec 2011 05:33:05 -0000 I recently enabled the "USB 3.0" option in the BIOS of my notebook. This transforms two of my USB 2.0 ports into USB 3.0 ports -- I'm already a little leery of it in that regard. When I boot, I see xhci(4) attach. However, when I plug in a device (such as my HTC phone), I see the following: xhci_do_command: Command timeout! usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT xhci_do_command: Command timeout! xhci_do_command: Command timeout! usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT xhci_do_command: Command timeout! xhci_do_command: Command timeout! usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! xhci_do_command: Command timeout! usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT ugen1.2: at usbus1 (disconnected) xhci_do_command: Command timeout! uhub_reattach_port: could not allocate new device xhci_do_command: Command timeout! usb_alloc_device: device init 2 failed (USB_ERR_TIMEOUT, ignored) ugen1.2: at usbus1 (disconnected) uhub_reattach_port: could not allocate new device My kernel version: FreeBSD m6500.local 9.0-RC3 FreeBSD 9.0-RC3 #1 r228305M: Thu Dec 15 21:38:20 CST 2011 root@m6500.local:/usr/obj/usr/src/sys/DELL_M6500 amd64 I'm looking for some hints on where to start looking/hacking, or what further information may be useful (and where to get it). Again, I have to assume that since XHCI is an option in the BIOS, this must be some quirky piece of hardware I'm working with. Oh, and, I guess I need to know what I'm looking for when I try to identify the actual hardware (usbconfig?). Also, I tried and failed at this again with the following changes (gleaned from HEAD): Index: xhci.c =================================================================== --- xhci.c (revision 228305) +++ xhci.c (working copy) @@ -292,7 +292,7 @@ XWRITE4(sc, oper, XHCI_USBCMD, XHCI_CMD_HCRST); for (i = 0; i != 100; i++) { - usb_pause_mtx(NULL, hz / 1000); + usb_pause_mtx(NULL, hz / 100); temp = XREAD4(sc, oper, XHCI_USBCMD) & (XHCI_CMD_HCRST | XHCI_STS_CNR); if (!temp) @@ -453,7 +453,7 @@ XHCI_CMD_INTE | XHCI_CMD_HSEE); for (i = 0; i != 100; i++) { - usb_pause_mtx(NULL, hz / 1000); + usb_pause_mtx(NULL, hz / 100); temp = XREAD4(sc, oper, XHCI_USBSTS) & XHCI_STS_HCH; if (!temp) break; @@ -487,7 +487,7 @@ XWRITE4(sc, oper, XHCI_USBCMD, 0); for (i = 0; i != 100; i++) { - usb_pause_mtx(NULL, hz / 1000); + usb_pause_mtx(NULL, hz / 100); temp = XREAD4(sc, oper, XHCI_USBSTS) & XHCI_STS_HCH; if (temp) break; @@ -1127,7 +1127,7 @@ trb.dwTrb2 = 0; trb.dwTrb3 = htole32(XHCI_TRB_3_TYPE_SET(XHCI_TRB_TYPE_ENABLE_SLOT)); - err = xhci_do_command(sc, &trb, 50 /* ms */); + err = xhci_do_command(sc, &trb, 100 /* ms */); if (err) goto done; @@ -1154,7 +1154,7 @@ trb.dwTrb3 = htole32(temp); - return (xhci_do_command(sc, &trb, 50 /* ms */)); + return (xhci_do_command(sc, &trb, 100 /* ms */)); } static usb_error_t @@ -1310,7 +1310,7 @@ trb.dwTrb3 = htole32(temp); - return (xhci_do_command(sc, &trb, 50 /* ms */)); + return (xhci_do_command(sc, &trb, 100 /* ms */)); } static usb_error_t @@ -1328,7 +1328,7 @@ XHCI_TRB_3_SLOT_SET(slot_id); trb.dwTrb3 = htole32(temp); - return (xhci_do_command(sc, &trb, 50 /* ms */)); + return (xhci_do_command(sc, &trb, 100 /* ms */)); } static usb_error_t @@ -1351,7 +1351,7 @@ trb.dwTrb3 = htole32(temp); - return (xhci_do_command(sc, &trb, 50 /* ms */)); + return (xhci_do_command(sc, &trb, 100 /* ms */)); } static usb_error_t @@ -1373,7 +1373,7 @@ XHCI_TRB_3_EP_SET(ep_id); trb.dwTrb3 = htole32(temp); - return (xhci_do_command(sc, &trb, 50 /* ms */)); + return (xhci_do_command(sc, &trb, 100 /* ms */)); } static usb_error_t @@ -1396,7 +1396,7 @@ trb.dwTrb3 = htole32(temp); - return (xhci_do_command(sc, &trb, 50 /* ms */)); + return (xhci_do_command(sc, &trb, 100 /* ms */)); } static usb_error_t @@ -1414,7 +1414,7 @@ trb.dwTrb3 = htole32(temp); - return (xhci_do_command(sc, &trb, 50 /* ms */)); + return (xhci_do_command(sc, &trb, 100 /* ms */)); } /*------------------------------------------------------------------------* There seem to be other changes made as well, which I haven't had the time to try. Some of these changes are stated to be MFC'd -- will they make it into 9.0-RELEASE (or a Release Candidate for testing)? A few examples: http://svnweb.freebsd.org/base?view=revision&revision=227396 http://svnweb.freebsd.org/base?view=revision&revision=227401 http://svnweb.freebsd.org/base?view=revision&revision=227404 ...or a really good one: http://svnweb.freebsd.org/base?view=revision&revision=228483 -Brandon From owner-freebsd-usb@FreeBSD.ORG Fri Dec 16 06:20:10 2011 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 4F4161065670 for ; Fri, 16 Dec 2011 06:20:10 +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 2CA218FC18 for ; Fri, 16 Dec 2011 06:20:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBG6KAn4010698 for ; Fri, 16 Dec 2011 06:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBG6KABj010697; Fri, 16 Dec 2011 06:20:10 GMT (envelope-from gnats) Resent-Date: Fri, 16 Dec 2011 06:20:10 GMT Resent-Message-Id: <201112160620.pBG6KABj010697@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, Andrei Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 594C2106564A for ; Fri, 16 Dec 2011 06:11:32 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 2EDCF8FC12 for ; Fri, 16 Dec 2011 06:11:32 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id pBG6BV5G054057 for ; Fri, 16 Dec 2011 06:11:31 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id pBG6BV07054055; Fri, 16 Dec 2011 06:11:31 GMT (envelope-from nobody) Message-Id: <201112160611.pBG6BV07054055@red.freebsd.org> Date: Fri, 16 Dec 2011 06:11:31 GMT From: Andrei To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: usb/163328: Hardware 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, 16 Dec 2011 06:20:10 -0000 >Number: 163328 >Category: usb >Synopsis: Hardware >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Fri Dec 16 06:20:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Andrei >Release: 7.4 >Organization: The private person >Environment: FreeBSD 7.4-RELEASE FreeBSD 7.4-RELEASE #0: Thu Dec 15 23:50:54 IRKT 2011 root@:/usr/obj/usr/src/sys/D330 i386 >Description: не могу подключить TP-LINK 300Mbps Wireless N USB Adapter TL-WN821N нет драйверов, а во freeBSD данное оборудование не поддерживается. Очень хотелось бы подключить данный девайс, потому что все соседи ходят в интернет через меня (него)! >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-usb@FreeBSD.ORG Fri Dec 16 09:40:10 2011 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 9336B106566B for ; Fri, 16 Dec 2011 09:40:10 +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 825A88FC15 for ; Fri, 16 Dec 2011 09:40:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBG9eAjC025327 for ; Fri, 16 Dec 2011 09:40:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBG9eARE025324; Fri, 16 Dec 2011 09:40:10 GMT (envelope-from gnats) Date: Fri, 16 Dec 2011 09:40:10 GMT Message-Id: <201112160940.pBG9eARE025324@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: Volodymyr Kostyrko Cc: Subject: Re: usb/163328: Hardware X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Volodymyr Kostyrko List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 09:40:10 -0000 The following reply was made to PR usb/163328; it has been noted by GNATS. From: Volodymyr Kostyrko To: Andrei Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: usb/163328: Hardware Date: Fri, 16 Dec 2011 11:03:05 +0200 16.12.2011 08:11, Andrei wrote: > п╫п╣ п╪п╬пЁя┐ п©п╬п╢п╨п╩я▌я┤п╦я┌я▄ TP-LINK 300Mbps Wireless N USB Adapter TL-WN821N п╫п╣я┌ п╢я─п╟п╧п╡п╣я─п╬п╡, п╟ п╡п╬ freeBSD п╢п╟п╫п╫п╬п╣ п╬п╠п╬я─я┐п╢п╬п╡п╟п╫п╦п╣ п╫п╣ п©п╬п╢п╢п╣я─п╤п╦п╡п╟п╣я┌я│я▐. п·я┤п╣п╫я▄ я┘п╬я┌п╣п╩п╬я│я▄ п╠я▀ п©п╬п╢п╨п╩я▌я┤п╦я┌я▄ п╢п╟п╫п╫я▀п╧ п╢п╣п╡п╟п╧я│, п©п╬я┌п╬п╪я┐ я┤я┌п╬ п╡я│п╣ я│п╬я│п╣п╢п╦ я┘п╬п╢я▐я┌ п╡ п╦п╫я┌п╣я─п╫п╣я┌ я┤п╣я─п╣п╥ п╪п╣п╫я▐ (п╫п╣пЁп╬)! I'll translate that to English for a start. ===== I can't connect TP-LINK 300Mbps Wireless N USB Adapter TL-WN821N no drivers, and under FreeBSD this equipment is not supported. I'd love to connect this device, because all the neighbors use this for Internet access! === Now back to the point. Theoretically this should be rum, run, uath, upgt, ural, urtw or zyd. Can you at least post part of log where device attaches? usbconfig dump_device_desc? -- Sphinx of black quartz judge my vow. From owner-freebsd-usb@FreeBSD.ORG Sat Dec 17 14:57:32 2011 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 BA7AA1065672; Sat, 17 Dec 2011 14:57:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA3B8FC12; Sat, 17 Dec 2011 14:57:30 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA05434; Sat, 17 Dec 2011 16:57:25 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RbvhV-0009fe-ES; Sat, 17 Dec 2011 16:57:25 +0200 Message-ID: <4EECADD4.9040509@FreeBSD.org> Date: Sat, 17 Dec 2011 16:57:24 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EE51CB5.1060505@FreeBSD.org> <201112152356.35336.hselasky@c2i.net> <4EEA7D52.4000503@FreeBSD.org> <201112160016.33776.hselasky@c2i.net> In-Reply-To: <201112160016.33776.hselasky@c2i.net> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: usb@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin , mdf@FreeBSD.org Subject: Re: kern_yield vs ukbd_yield 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, 17 Dec 2011 14:57:32 -0000 on 16/12/2011 01:16 Hans Petter Selasky said the following: > I think I was not aware about the Giant locking maybe having something to do > about this. I was just thinking about this recently, that syscons and all > keyboard stuff, currently is Giant locked. Scary? Nope :-) I think that no syscons + keyboards code depends on the special properties of the Giant, most likely with the prominent exception of the ukbd. Also, the Giant is almost never acquired explicitly (again with the prominent exception of the ukbd), which actually leads to a consequence that no lock is acquired in the context where the kernel polls for input. Which is a good thing if we keep in mind that the kernel may poll for input in the context like panic or ddb where any lock may be already held by a thread that is not able to run. > I can always become better writing commit messages! What is your plan forward > then with regard to the Giant lock problem? > > If one thread is like: > > while (1) > { > lock(Giant); > c = get nonblocking key from console(); > unlock(Giant); > } > > And the other is like: > > if (callback complete) { > lock(Giant); > run callback(); > unlock(Giant); > } > > Who gets to run? First, there is no need to acquire the Giant in the first snippet. Second, "get nonblocking key from console" should not depend on the callback in a parallel thread. The polling routine should go all the way to hardware if needed. I see where all the complications in ukbd code come from. I think that they started as attempts to work around the current stupid behavior of syscons during polling: do { kbd_poll_enter(); try_to_get_one_char(); kbd_poll_exit(); } while (!got_a_char); For ukbd this means ugly races between the polling thread and the usb threads at the mountroot stage. And so you had to invent "polling autodetection" and add extra locking. But that lead to troubles in the contexts where no lock was previously held. And so on. So now ukbd resembles a big collection of hacks and crotches. For example consider the following scenario which does not occur very frequently in reality, but is quite possible. Thread T1 on CPU P1 holds the Giant, at the same time thread T2 on CPU P2 enters ddb. That means that T1 is "frozen" and won't be able to release Giant. ddb would try to interact with an operator and there would be a call-chain like this: ukbd_check_char scgetc sc_cngetc cncheckc cngetc db_readline ... And now the code in ukbd to which I referred above: /* check if char is waiting */ static int ukbd_check_char(keyboard_t *kbd) { struct ukbd_softc *sc = kbd->kb_data; if (!KBD_IS_ACTIVE(kbd)) return (0); if (sc->sc_flags & UKBD_FLAG_POLLING) { if (!mtx_owned(&Giant)) { /* XXX cludge */ int retval; mtx_lock(&Giant); retval = ukbd_check_char(kbd); mtx_unlock(&Giant); return (retval); So we are in a polling mode and Giant is not owned by us (T2) because it is owned by T1 and so mtx_lock would be called and then we would probably get into a recursion via mi_switch and kdb_reenter. -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Sat Dec 17 14:57:36 2011 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 E4321106566B; Sat, 17 Dec 2011 14:57:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 915FC8FC17; Sat, 17 Dec 2011 14:57:35 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA05440; Sat, 17 Dec 2011 16:57:31 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Rbvhb-0009fh-0a; Sat, 17 Dec 2011 16:57:31 +0200 Message-ID: <4EECADDA.4070704@FreeBSD.org> Date: Sat, 17 Dec 2011 16:57:30 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111206 Thunderbird/8.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4EE51CB5.1060505@FreeBSD.org> <201112142256.32526.hselasky@c2i.net> <4EEA015D.8020800@FreeBSD.org> <201112152356.35336.hselasky@c2i.net> In-Reply-To: <201112152356.35336.hselasky@c2i.net> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: usb@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin , mdf@FreeBSD.org Subject: Re: kern_yield vs ukbd_yield 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, 17 Dec 2011 14:57:37 -0000 Replying further... on 16/12/2011 00:56 Hans Petter Selasky said the following: > On Thursday 15 December 2011 15:17:01 Andriy Gapon wrote: >> Hmm... I looked at the history of ukbd.c (which I should have done from the >> very start) and I see two relevant revisions: >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=199816&r2=2 >> 03896&pathrev=203896 >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=223755&r2= >> 223989&pathrev=223989 >> >> So, first use of pause(9) was introduced to work around current broken >> syscons polling mechanism. Then pause(9) was replaced with the >> hand-rolled yield to fix a problem at shutdown, which supposedly was >> caused by times being stopped. >> >> None of the commits seems to be directly related to thread priorities. > > Not directly, but indirect. You know, if you pause thread 1 (which I thought > was thread 0), then other thread will get a chance to run. pause() could be a sufficient action to let other thread run, but it is not a required action. As we've already discusses earlier all the USB threads have sufficiently high priorities to get runnable while other kernel threads are runnable. Only certain interrupt threads could have prevented them from running, but that's definitely not the case. > It might also be that Giant is locked by syscons, and that unless you pause or > yield, then Giant will block other parts of USB, like the callback thread, > which is Giant locked for ukbd only to run. > > Maybe that is the explanation? Not sure if you are hypothesizing or if this is something that you experienced during development and testing. Let's consider a few observations. First, syscons doesn't acquire Giant anywhere in the path started from cngetc. Actually, I believe that the only place where Giant is now explicitly acquired in the whole syscons code can be safely replaced with an assert that the Giant is already held. Second, the polling mode is designed to be usable in situations where other threads are not running. So in general it should not depend on other threads being able to make any progress. -- Andriy Gapon From owner-freebsd-usb@FreeBSD.ORG Sat Dec 17 17:09:17 2011 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 0CDF11065691; Sat, 17 Dec 2011 17:09:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9F4CD8FC14; Sat, 17 Dec 2011 17:09:15 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 219011199; Sat, 17 Dec 2011 18:09:13 +0100 From: Hans Petter Selasky To: Andriy Gapon Date: Sat, 17 Dec 2011 18:06:43 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EE51CB5.1060505@FreeBSD.org> <201112160016.33776.hselasky@c2i.net> <4EECADD4.9040509@FreeBSD.org> In-Reply-To: <4EECADD4.9040509@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112171806.43764.hselasky@c2i.net> Cc: usb@freebsd.org, freebsd-hackers@freebsd.org, John Baldwin , mdf@freebsd.org Subject: Re: kern_yield vs ukbd_yield 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, 17 Dec 2011 17:09:17 -0000 On Saturday 17 December 2011 15:57:24 Andriy Gapon wrote: > on 16/12/2011 01:16 Hans Petter Selasky said the following: > > I think I was not aware about the Giant locking maybe having something to > > do about this. I was just thinking about this recently, that syscons and > > all keyboard stuff, currently is Giant locked. Scary? > > Nope :-) > I think that no syscons + keyboards code depends on the special properties > of the Giant, most likely with the prominent exception of the ukbd. > Also, the Giant is almost never acquired explicitly (again with the > prominent exception of the ukbd), which actually leads to a consequence > that no lock is acquired in the context where the kernel polls for input. > Which is a good thing if we keep in mind that the kernel may poll for > input in the context like panic or ddb where any lock may be already held > by a thread that is not able to run. > > > I can always become better writing commit messages! What is your plan > > forward then with regard to the Giant lock problem? > > > > If one thread is like: > > > > while (1) > > { > > lock(Giant); > > c = get nonblocking key from console(); > > unlock(Giant); > > } > > > > And the other is like: > > > > if (callback complete) { > > lock(Giant); > > run callback(); > > unlock(Giant); > > } > > > > Who gets to run? > Hi, > First, there is no need to acquire the Giant in the first snippet. > Second, "get nonblocking key from console" should not depend on the > callback in a parallel thread. The polling routine should go all the way > to hardware if needed. It can do that. This feature is usually only used in panic mode. > > I see where all the complications in ukbd code come from. I think that > they started as attempts to work around the current stupid behavior of > syscons during polling: > do { > kbd_poll_enter(); > try_to_get_one_char(); > kbd_poll_exit(); > } while (!got_a_char); > For ukbd this means ugly races between the polling thread and the usb > threads at the mountroot stage. And so you had to invent "polling > autodetection" and add extra locking. But that lead to troubles in the > contexts where no lock was previously held. And so on. So now ukbd > resembles a big collection of hacks and crotches. Right! You got it! > > For example consider the following scenario which does not occur very > frequently in reality, but is quite possible. Thread T1 on CPU P1 holds > the Giant, at the same time thread T2 on CPU P2 enters ddb. That means > that T1 is "frozen" and won't be able to release Giant. ddb would try to > interact with an operator and there would be a call-chain like this: > ukbd_check_char > scgetc > sc_cngetc > cncheckc > cngetc > db_readline > ... > > And now the code in ukbd to which I referred above: > /* check if char is waiting */ > static int > ukbd_check_char(keyboard_t *kbd) > { > struct ukbd_softc *sc = kbd->kb_data; > > if (!KBD_IS_ACTIVE(kbd)) > return (0); > > if (sc->sc_flags & UKBD_FLAG_POLLING) { > if (!mtx_owned(&Giant)) { > /* XXX cludge */ > int retval; > mtx_lock(&Giant); > retval = ukbd_check_char(kbd); > mtx_unlock(&Giant); > return (retval); > > So we are in a polling mode and Giant is not owned by us (T2) because it is > owned by T1 and so mtx_lock would be called and then we would probably get > into a recursion via mi_switch and kdb_reenter. That's true! If the problem is only in UKBD driver, I don't think this is a big problem to solve. The reason for the auto-magic locking, is that I've sometimes seen callers in non-polling mode call into UKBD without Giant locked. And this causes a panic when starting USB transfers, because the code expects Giant to be locked. Requirement: I would say that to use UKBD polling mode, the scheduler must be stopped. Else you should not use polling mode at all. I think that mountroot is getting characters the wrong way in this regard. --HPS From owner-freebsd-usb@FreeBSD.ORG Sat Dec 17 17:14:45 2011 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 9EAA41065670; Sat, 17 Dec 2011 17:14:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7868FC15; Sat, 17 Dec 2011 17:14:41 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 217175245; Sat, 17 Dec 2011 18:14:38 +0100 From: Hans Petter Selasky To: Andriy Gapon Date: Sat, 17 Dec 2011 18:12:09 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EE51CB5.1060505@FreeBSD.org> <201112152356.35336.hselasky@c2i.net> <4EECADDA.4070704@FreeBSD.org> In-Reply-To: <4EECADDA.4070704@FreeBSD.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112171812.09652.hselasky@c2i.net> Cc: usb@freebsd.org, freebsd-hackers@freebsd.org, John Baldwin , mdf@freebsd.org Subject: Re: kern_yield vs ukbd_yield 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, 17 Dec 2011 17:14:45 -0000 On Saturday 17 December 2011 15:57:30 Andriy Gapon wrote: > Replying further... > > > Not directly, but indirect. You know, if you pause thread 1 (which I > > thought was thread 0), then other thread will get a chance to run. > > pause() could be a sufficient action to let other thread run, but it is not > a required action. As we've already discusses earlier all the USB threads > have sufficiently high priorities to get runnable while other kernel > threads are runnable. Only certain interrupt threads could have prevented > them from running, but that's definitely not the case. > > > It might also be that Giant is locked by syscons, and that unless you > > pause or yield, then Giant will block other parts of USB, like the > > callback thread, which is Giant locked for ukbd only to run. > > Hi, > > Maybe that is the explanation? > > Not sure if you are hypothesizing or if this is something that you > experienced during development and testing. I have only observed that no key-presses are returned by the UKBD polling mechanism, if the ukbd_yield() is removed. I have not investigated this further. If you use pause() that will slowdown dumphandling which is also polling for key-presses, so this must be added conditionally. > > Let's consider a few observations. > > First, syscons doesn't acquire Giant anywhere in the path started from > cngetc. Actually, I believe that the only place where Giant is now > explicitly acquired in the whole syscons code can be safely replaced with > an assert that the Giant is already held. > > Second, the polling mode is designed to be usable in situations where other > threads are not running. So in general it should not depend on other > threads being able to make any progress. Sure, but it is not that simple to poll a key-press from USB like with AT keyboards. You need to go through a bunch of stuff, including busdma before you get the keypress. --HPS