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" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
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
[EMAIL PROTECTED]:/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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Just for the record.
This issue was successfully resolved in SVN revision 482 of the new USB
stack.
Thanks to Hans Petter Selasky.
Valery.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
