On 09/30/2011 02:06 PM, Christian Lamparter wrote:
On Friday 30 September 2011 20:39:23 Ian Jeffray wrote:
On 27/09/2011 17:24, Larry Finger wrote:
On 09/27/2011 10:36 AM, Ian Jeffray wrote:
Dear all,
I'm attempting to get some sense from a Realtek 8191S device on
ARM linux.
<SNIP>
My host is a TI DaVinci DM8168 (OMAP3+toys). The USB host is not
fantastic, but has been thrashed heavily with other devices and seems
to be reliable in those cases.
<SNIP>
I have not tried this chip on an ARM host as I have no hardware. My
testing has been with X86 and PPC - thus I know the endianess is OK, but
that is the extent of my platform testing.
The first thing I would try is wireshark on another host to verify that
packets are actually getting on the air.
Ok, so I've spent more more days working on this. The driver appears
to be fine on an ARM9 S3X board. I've contacted the TI support
team about the USB host and applied some patches from them which have
slightly improved the situation, but it's still horrible - I'm actually
getting "reliable" scans but only a pathetic 1Mbit or less of data
throughput.
I've also tried this driver (and the realtek upstream version) with
a Blackfin BF527 device, which has roughly the same 'musb' Inventra
USB host controller... and I see exactly the same problem there!
The firmware appears to load fine, but scans produce no results.
I'm not really sure about your comment about wireshark because,
as far as I understand, a 'iwlist wlan0 scan' command doesn't cause
any traffic which would be wireshark capturable on another host...
am I misunderstanding something?
@Ian: If iwlist scan is run as root, an active scan is done. If run as an
unprivileged user, then a passive scan is done. With the former, we would see an
outgoing probe packet on each channel.
So it appears as though there may be some general problem with this
driver and an 'musb' host controller. Very strange.
My next course of attack is to try comparing outputs of 'usbmon'
dumps between hosts which work and hosts which don't... but I can't
make a great deal of sense looking at them really.
I'd greatly appreciate any more advice you may be able to give.
Well, I'm not really in r8712u but I can tell you a few things about
carl9170 and musb.
You see I had a similar discussion a while ago:
http://www.spinics.net/lists/linux-wireless/msg68870.html
Apparently, musb can't do DMA with non 4-bytes aligned buffers
and falls back to PIO [which results in a much higher cpu utilization
and really bad usb throughput... so if timing is critical this "fact"
is pretty much a deal-breaker for the combination].
Now, you might ask, why this DMA vs. PIO is so importent... Well,
it's because the network stack has its own alignment ideas and
about the data/skbs. There's a comment in include/linux/skbuff.h
around line 1400 which explains the situation. The upshot is you
can choose between a penatly on the packet processing by the
stack, or a penatly on the driver/hardware site if r8712u does
not implement any additional techniques to counter the issues.
@Christian: Thanks for the pointer on the penalty associated with unaligned DMA
on ARM. I'll prepare a patch to see if using the skb_reserve() call hurts x86 or
PPC performance. If it does not, then the patch can be used for all architectures.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
