Date: Tue, 01 May 2007 00:59:47 +0300 From: "Valery V.Chikalov" <valera@chikalov.dp.ua> Cc: Hans Petter Selasky <hselasky@freebsd.org>, freebsd-usb@freebsd.org Subject: Re: usb/107642: [patch]Ralink Technology RT2501USB/RT2601USB chipset driver Message-ID: <463666D3.4050900@chikalov.dp.ua> In-Reply-To: <46364CB6.9050401@chikalov.dp.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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" <valera@chikalov.dp.ua> >>>>>>>>>>>>> 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 <return> to continue, or q <return> 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 <usb_event_thread>, 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?463666D3.4050900>