From owner-freebsd-usb@FreeBSD.ORG Mon Apr 30 21:59:57 2007 Return-Path: X-Original-To: freebsd-usb@freebsd.org Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 947C316A400; Mon, 30 Apr 2007 21:59:57 +0000 (UTC) (envelope-from valera@chikalov.dp.ua) Received: from halik.com.ua (halik.com.ua [193.178.146.121]) by mx1.freebsd.org (Postfix) with ESMTP id E0A5913C45E; Mon, 30 Apr 2007 21:59:56 +0000 (UTC) (envelope-from valera@chikalov.dp.ua) Received: from [192.168.1.103] (unknown [213.227.219.58]) by halik.com.ua (Postfix) with ESMTP id 111645C06D; Tue, 1 May 2007 00:59:56 +0300 (EEST) Message-ID: <463666D3.4050900@chikalov.dp.ua> Date: Tue, 01 May 2007 00:59:47 +0300 From: "Valery V.Chikalov" User-Agent: Thunderbird 1.5.0.9 (X11/20070315) MIME-Version: 1.0 References: <200704272330.l3RNU94X078095@freefall.freebsd.org> <200704302057.27212.hselasky@freebsd.org> <46364142.1070108@chikalov.dp.ua> <200704302125.34381.hselasky@freebsd.org> <46364CB6.9050401@chikalov.dp.ua> In-Reply-To: <46364CB6.9050401@chikalov.dp.ua> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: Hans Petter Selasky , freebsd-usb@freebsd.org Subject: Re: usb/107642: [patch]Ralink Technology RT2501USB/RT2601USB chipset driver 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, 30 Apr 2007 21:59:57 -0000 Valery V.Chikalov wrote: > Hans Petter Selasky wrote: >> On Monday 30 April 2007 21:19, Valery V.Chikalov wrote: >>> Hans Petter Selasky wrote: >>>> On Monday 30 April 2007 18:41, Valery V.Chikalov wrote: >>>>> Hans Petter Selasky wrote: >>>>>> On Monday 30 April 2007 14:34, Valery V.Chikalov wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>> >>>>>>> Kevin Lo пишет: >>>>>>>> Valery V.Chikalov wrote: >>>>>>>>> Hans Petter Selasky wrote: >>>>>>>>>> On Sunday 29 April 2007 15:02, Valery V.Chikalov wrote: >>>>>>>>>>> Kevin Lo wrote: >>>>>>>>>>>> Valery V.Chikalov wrote: >>>>>>>>>>>>> The following reply was made to PR usb/107642; it has been >>>>>>>>>>>>> noted >>>>>>>>>>>>> by GNATS. >>>>>>>>>>>>> >>>>>>>>>>>>> From: "Valery V.Chikalov" >>>>>>>>>>>>> To: bug-followup@FreeBSD.org, valera@chikalov.dp.ua >>>>>>>>>>>>> Cc: >>>>>>>>>>>>> Subject: Re: usb/107642: [patch]Ralink Technology >>>>>>>>>>>>> RT2501USB/RT2601USB chipset driver >>>>>>>>>>>>> Date: Sun, 22 Apr 2007 11:32:18 +0300 >>>>>>>>>>>>> >>>>>>>>>>>>> This is a multi-part message in MIME format. >>>>>>>>>>>>> --------------030900090303000507070905 >>>>>>>>>>>>> Content-Type: text/plain; charset=UTF-8 >>>>>>>>>>>>> Content-Transfer-Encoding: 7bit >>>>>>>> if_rum(4) for 7.0-CURRENT >>>>>>>> >>>>>>>> replaced amrr_* functions by "standard" ones already existed in >>>>>>>> net80211/ieee80211_amrr.c >>>>>>>> >>>>>>>>>>>> Hi Valery, >>>>>>>>>>>> >>>>>>>>>>>> I guess you wasn't aware that I've already ported rum(4) to >>>>>>>>>>>> FreeBSD. The patch is available at: >>>>>>>>>>>> http://people.freebsd.org/~kevlo/patch-rum Maybe you can >>>>>>>>>>>> test my >>>>>>>>>>>> patch? Thanks. >>>>>>>>>>>> >>>>>>>>>>>> Kevin >>>>>>>>>>> Hi, Kevin, >>>>>>>>>>> >>>>>>>>>>> Your driver not working for me. Fortunately, the errors that >>>>>>>>>>> I see >>>>>>>>>>> exactly the same which i fight when I made my driver. >>>>>>>>>>> >>>>>>>>>>> $ uname -a >>>>>>>>>>> FreeBSD tiger.novakom.dp.ua 7.0-CURRENT FreeBSD 7.0-CURRENT #6: >>>>>>>>>>> Sun Apr 29 13:58:48 EEST 2007 >>>>>>>>>>> root@tiger.novakom.dp.ua:/usr/obj/usr/src/sys/TIGER64 amd64 >>>>>>>>>>> >>>>>>>>>>> $ sysctl kern.osreldate >>>>>>>>>>> kern.osreldate: 700037 >>>>>>>>>>> >>>>>>>>>>> cvsup'ed 29.04.2007 >>>>>>>>>>> >>>>>>>>>>> kernel with: >>>>>>>>>>> >>>>>>>>>>> makeoptions DEBUG=-g >>>>>>>>>>> >>>>>>>>>>> options KDB >>>>>>>>>>> >>>>>>>>>>> options DDB >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> options INVARIANTS >>>>>>>>>>> >>>>>>>>>>> options INVARIANT_SUPPORT >>>>>>>>>>> >>>>>>>>>>> options WITNESS >>>>>>>>>>> >>>>>>>>>>> At first, when I make kldload if_rum, I get kernel panic. >>>>>>>>>>> But I cant get saved core, as ddb just hangs during "call >>>>>>>>>>> doadump" >>>>>>>>>> I have a solution for all of this locking stuff! >>>>>>>>>> >>>>>>>>>>> So I add >>>>>>>>>>> >>>>>>>>>>> #define RUM_LOCK(sc) do { ((sc) = (sc)); mtx_lock(&Giant); } >>>>>>>>>>> while (0) >>>>>>>>>>> #define RUM_UNLOCK(sc) mtx_unlock(&Giant) >>>>>>>>>>> >>>>>>>>>>> in if_rumvar.h >>>>>>>>>>> >>>>>>>>>>> I spend a lot of time in attempts get rid of Giant ant always >>>>>>>>>>> got >>>>>>>>>>> only panics. >>>>>>>>>> You _cannot_ do that with the old USB stack, because you must >>>>>>>>>> lock >>>>>>>>>> Giant before calling into the usbxxx functions. Then in the USB >>>>>>>>>> callback, Giant is locked, and then you cannot lock RUM_LOCK()! >>>>>>>>>> That means you will most likely end up with a deadlock pretty >>>>>>>>>> soon, >>>>>>>>>> if you see that. >>>>>>>>> Thanks, for explanations. I suspected that thing are like that, >>>>>>>>> and >>>>>>>>> I have tried make porting by analogue with other drivers which >>>>>>>>> I can >>>>>>>>> find in dev/usb, but I was not can find the description of doing >>>>>>>>> "right way" locking before. >>>>>>>> Firstly, thanks for taking the time to test my patch. >>>>>>>> I think your issue is related to watchdog timers. The revised patch >>>>>>>> is at http://people.freebsd.org/~kevlo/patch-rum >>>>>>>> >>>>>>>> Besides, I don't get a panic during high load when getting a file >>>>>>>> about 400MB via ftp. >>>>>>> Sorry, but the error that I see the same, just after inserting >>>>>>> dongle, >>>>>>> or if it was inserted before - after kldload if_rum: >>>>>>> >>>>>>> panic: sleeping without a lock >>>>>>> >>>>>>> the top of stack: >>>>>>> at usbd_transfer +0x1fe >>>>>>> .... >>>>>>> rum_ioctl >>>>>>> >>>>>>> And I cant get saved kernel coredump at the end. >>>>>>> >>>>>>> I have not serial console configured so it was just subscribed by >>>>>>> hand. Of course I can reproduce it again and subscribe what you will >>>>>>> ask. >>>>>>> >>>>>>> I have SMP kernel and use AMD64 architecture, maybe this are the >>>>>>> reasons why we are getting different results. >>>>>>> >>>>>>> Can you please, explain me in two words(or give a reference) why you >>>>>>> are dropping mtx_lock(&Giant). Yes I have seen the same in if_ural.c >>>>>>> and as i have wrote before unsuccessfully have tried repeat it in >>>>>>> if_rum. I know that current USB stack is not Giant free, and Hans >>>>>>> noted that this is impossible (if I understand him right). Maybe >>>>>>> exists some tunable or kernel option or another trick that allows >>>>>>> drivers working without the Giant under current USB stack, which I >>>>>>> must use. >>>>>>> >>>>>>> Thank you for your time and patience. >>>>>>> Sorry for my english. >>>>>>> >>>>>>> Valery. >>>>>>> >>>>>>>>>>> After that I get hangs, >>>>>>>>>>> which i resolved by modifying rum_ioctl: >>>>>>>>>> I'm almost finished converting "if_rum.c()" to the new USB stack. >>>>>>>>>> >>>>>>>>>> In some hours I will update it with support for "if_rum". >>>>>>>>>> >>>>>>>>>> If you can test that and forget about the old USB stack, I >>>>>>>>>> will be >>>>>>>>>> very happy :-) >>>>>>>>> I will do it with pleasure. I was almost ready to do it >>>>>>>>> (converting >>>>>>>>> to new USB stack) by myself, but I was stopped by the fact that I >>>>>>>>> cant make it compiled under CURRENT. I have seen your mail that >>>>>>>>> your >>>>>>>>> are working on this. Is new the USB stack ready for CURRENT now? >>>>>>>>> >>>>>>>>> Valery. >>>>>>>>> >>>>>>>>>> --HPS >>>>>>>>>> >>>>>>>>>> http://www.turbocat.net/~hselasky/usb4bsd >>>>>>>> Kevin >>>>>> Hi, >>>>>> >>>>>> I have just imported "if_rum.c" to SVN and my P4 tree. >>>>>> >>>>>> Just do a SVN update. Build a new USB package install that. >>>>>> >>>>>> cp -r i4b/trunk/i4b/src/sys/modules/rum /usr/src/sys/modules/rum >>>>>> >>>>>> make -C /usr/src/sys/modules/rum all install >>>>>> >>>>>> Hope it works. >>>>> If you can read this message, then it definitely works :-) >>>>> Thank you, great work! >>>>> >>>>> Only one issue: >>>>> during kernel load, and later after kldload if_rum I got a bunch of >>>>> messages >>>>> >>>>> usbd_fill_iface_data: invalid wMaxPacketSize=0x0000, addr=125! >>>>> usbd_fill_iface_data: invalid wMaxPacketSize=0x0000, addr=125! >>>>> usbd_fill_iface_data: invalid wMaxPacketSize=0x0000, addr=125! >>>>> usbd_fill_iface_data: invalid wMaxPacketSize=0x0000, addr=125! >>>> Ok. Do you have USB Bluetooth devices ? >>>> >>>> --HPS >>> Yes. >>> >>> tiger# usbdevs >>> addr 127: UHCI root hub, Intel >>> addr 127: UHCI root hub, Intel >>> addr 127: UHCI root hub, Intel >>> addr 127: UHCI root hub, Intel >>> addr 124: 802.11 bg WLAN, Ralink >>> addr 125: TrueMobile 350 Bluetooth USB Adapter, Dell >>> addr 126: product 0xa005, Dell >>> addr 125: TrueMobile 350 Bluetooth USB Adapter, Dell >>> addr 127: EHCI root hub, Intel >>> addr 126: product 0xa005, Dell >>> addr 125: TrueMobile 350 Bluetooth USB Adapter, Dell >>> addr 124: 802.11 bg WLAN, Ralink >>> >>> of course I have only /one/ USB Adapter, not three. >>> >>> Valery. >> >> The warnings you get can just be ignored. They come from a dummy >> alternate setting on your USB Bluetooth adapter. >> >> --HPS >> > > First regression. > Inserting any of umass devices(I have tried three different ones) lead to > > panic: mutex UMASS lock not owned at /usr/src/sys/cam/cam_xpt.c:4329 > > Part of backtrace, i have coredump with debug symbols included, so I can > give you more information if you need. Situation 100% reproducible. > > #11 0xffffffff80289f8a in panic ( > fmt=0xffffffff8050f820 "mutex %s not owned at %s:%d") > at /usr/src/sys/kern/kern_shutdown.c:547 > #12 0xffffffff8027d878 in _mtx_assert (m=0xffffff0017816010, what=1, > file=0xffffffff804e2801 "/usr/src/sys/cam/cam_xpt.c", line=4329) > at /usr/src/sys/kern/kern_mutex.c:607 > #13 0xffffffff801557ab in xpt_bus_register (sim=0xffffff0014faa300, bus=0) > at /usr/src/sys/cam/cam_xpt.c:4329 > #14 0xffffffff808e40dd in umass_attach (dev=0xffffff0014faac00) > at /usr/src/sys/modules/umass/../../dev/usb/umass.c:2289 > #15 0xffffffff802b161b in DEVICE_ATTACH (dev=0xffffff0014faac00) > at device_if.h:178 > #16 0xffffffff802b150e in device_attach (dev=0xffffff0014faac00) > at /usr/src/sys/kern/subr_bus.c:2379 > #17 0xffffffff802b143f in device_probe_and_attach (dev=0xffffff0014faac00) > at /usr/src/sys/kern/subr_bus.c:2347 > #18 0xffffffff804819cb in usbd_probe_and_attach (parent=0xffffff0000d29200, > port=4, up=0xffffff001e276898) at /usr/src/sys/dev/usb/usb_subr.c:1071 > #19 0xffffffff804823ab in usbd_new_device (parent=0xffffff0000d29200, > bus=0xffffffff80a48030, depth=1, speed=3, port=4, > up=0xffffff001e276898) > at /usr/src/sys/dev/usb/usb_subr.c:1388 > #20 0xffffffff8020e319 in uhub_explore (udev=0xffffff0000c11800) > at /usr/src/sys/dev/usb/uhub.c:293 > ---Type to continue, or q to quit--- > #21 0xffffffff8047d407 in usb_discover (bus=0xffffffff80a48030) > at /usr/src/sys/dev/usb/usb.c:165 > #22 0xffffffff8047d489 in usb_event_thread (bus=0xffffffff80a48030) > at /usr/src/sys/dev/usb/usb.c:195 > #23 0xffffffff80268d78 in fork_exit ( > callout=0xffffffff8047d43e , arg=0xffffffff80a48030, > frame=0xffffffff91947c80) at /usr/src/sys/kern/kern_fork.c:814 > > Valery. > _______________________________________________ > freebsd-usb@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" > Just for the record. This issue was successfully resolved in SVN revision 482 of the new USB stack. Thanks to Hans Petter Selasky. Valery.