usb/107642: [patch]Ralink Technology RT2501USB/RT2601USB chipset
driver
Valery V.Chikalov
valera at chikalov.dp.ua
Mon Apr 30 21:59:57 UTC 2007
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 at chikalov.dp.ua>
>>>>>>>>>>>>> To: bug-followup at FreeBSD.org, valera at 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 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-usb
> To unsubscribe, send any mail to "freebsd-usb-unsubscribe at 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.
More information about the freebsd-usb
mailing list