From owner-freebsd-usb@FreeBSD.ORG Mon Apr 30 20:08:33 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 BFB2016A402; Mon, 30 Apr 2007 20:08:33 +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 D6C8013C457; Mon, 30 Apr 2007 20:08:32 +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 538B45C06D; Mon, 30 Apr 2007 23:08:31 +0300 (EEST) Message-ID: <46364CB6.9050401@chikalov.dp.ua> Date: Mon, 30 Apr 2007 23:08:22 +0300 From: "Valery V.Chikalov" User-Agent: Thunderbird 1.5.0.9 (X11/20070315) MIME-Version: 1.0 To: Hans Petter Selasky References: <200704272330.l3RNU94X078095@freefall.freebsd.org> <200704302057.27212.hselasky@freebsd.org> <46364142.1070108@chikalov.dp.ua> <200704302125.34381.hselasky@freebsd.org> In-Reply-To: <200704302125.34381.hselasky@freebsd.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: 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 20:08:33 -0000 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.