usb/107642: [patch]Ralink Technology RT2501USB/RT2601USB chipset
driver
Valery V.Chikalov
valera at chikalov.dp.ua
Mon Apr 30 16:42:03 UTC 2007
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!
I will test other my usb devices under the new USB stack and will report
you if I reveal something.
Thank you again.
Valery.
>
> --HPS
>
> http://www.turbocat.net/~hselasky/usb4bsd
More information about the freebsd-usb
mailing list