usb/107642: [patch]Ralink Technology RT2501USB/RT2601USB chipset
driver
Valery V.Chikalov
valera at chikalov.dp.ua
Mon Apr 30 20:08:33 UTC 2007
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.
More information about the freebsd-usb
mailing list