Dear all,
I'm attempting to get some sense from a Realtek 8191S device on
ARM linux. Using the latest kernel/drivers (3.0.4) I've had
great success on x86 linux, achieving 94Mbit throughput.
On ARM linux, however, the device is barely working. I can
bring up the firmware (using the 20110818 firmware package):
usb 1-1: new high speed USB device using musb-hdrc and address 2
usb 1-1: New USB device found, idVendor=0bda, idProduct=8172
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: RTL8191S WLAN Adapter
usb 1-1: Manufacturer: Manufacturer Realtek
usb 1-1: SerialNumber: 00e04c000001
r8712u: DriverVersion: v7_0.20100831
r8712u: register rtl8712_netdev_ops to netdev_ops
r8712u: USB_SPEED_HIGH with 4 endpoints
r8712u: Boot from EFUSE: Autoload OK
r8712u: CustomerID = 0x0000
r8712u: MAC Address from efuse = 00:02:72:a7:12:47
# ifconfig wlan0 up
r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
r8712u: 1 RCR=0x153f00e
r8712u: 2 RCR=0x553f00e
I then attempt some basic operations such as an SSID scan.
At this point, I occasionally get a result, but more often than not,
I get no results at all. There are 7 access points around me, so
it's surprising to get nothing.
Attempting to forcibly connect to anything is also fruitless.
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.
I'd appreciate any input and guidance as to what may be the issue here.
There doesn't appear to be a great deal of debug info to be enabled in
the driver, so I'm not sure what more I can add at this point to aid
with resolving the problem. I fear some long days of pain trying to
track down differences in operation for this device between ARM and x86.
Could I ask if anyone can actually confirm (or deny) this particular
driver/chipset works with an ARM host?
Very many thanks,
Ian.
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?
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.
Many thanks,
Ian.
--
Ian Jeffray [email protected] Tel: +44 (0) 141 221 8449
emobix Limited, Suite 5/5, 29 St Vincent Place, Glasgow, G1 2DT
Registered in Scotland; Company No. 371276 - VAT No. 983 4833 78
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?
>
> 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.
Regards,
Chr
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. Using the latest kernel/drivers (3.0.4) I've had
> great success on x86 linux, achieving 94Mbit throughput.
>
> On ARM linux, however, the device is barely working. I can
> bring up the firmware (using the 20110818 firmware package):
>
> usb 1-1: new high speed USB device using musb-hdrc and address 2
> usb 1-1: New USB device found, idVendor=0bda, idProduct=8172
> usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-1: Product: RTL8191S WLAN Adapter
> usb 1-1: Manufacturer: Manufacturer Realtek
> usb 1-1: SerialNumber: 00e04c000001
> r8712u: DriverVersion: v7_0.20100831
> r8712u: register rtl8712_netdev_ops to netdev_ops
> r8712u: USB_SPEED_HIGH with 4 endpoints
> r8712u: Boot from EFUSE: Autoload OK
> r8712u: CustomerID = 0x0000
> r8712u: MAC Address from efuse = 00:02:72:a7:12:47
>
> # ifconfig wlan0 up
> r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
> r8712u: 1 RCR=0x153f00e
> r8712u: 2 RCR=0x553f00e
>
> I then attempt some basic operations such as an SSID scan.
> At this point, I occasionally get a result, but more often than not,
> I get no results at all. There are 7 access points around me, so
> it's surprising to get nothing.
That is what one might expect if the probe messages for the scan are not being
sent, and you are ending up with effectively a passive scan.
> Attempting to forcibly connect to anything is also fruitless.
>
> 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.
>
> I'd appreciate any input and guidance as to what may be the issue here.
> There doesn't appear to be a great deal of debug info to be enabled in
> the driver, so I'm not sure what more I can add at this point to aid
> with resolving the problem. I fear some long days of pain trying to
> track down differences in operation for this device between ARM and x86.
>
> Could I ask if anyone can actually confirm (or deny) this particular
> driver/chipset works with an ARM host?
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.
Larry
On 01/10/2011 19:01, Christian Lamparter wrote:
> On Saturday 01 October 2011 19:52:37 Larry Finger wrote:
>> On 10/01/2011 11:22 AM, Christian Lamparter wrote:
>>> On Saturday 01 October 2011 18:01:08 Larry Finger wrote:
>>>> Ian,
>>>>
>>>> Most of the skb assignments in r8712u are aligned OK and most aligned on
>>>> 512-byte boundaries, but there was one that had the minimal offset of 14 bytes.
>>>> The attached patch should fix it. Does it help?
>>> Interesting, this "patch" goes in a completely different direction.
>>> Can you tell me where the driver aligns the frames which will be
>>> xmitted by the device [i.e.: which is passed to the usb subsystem
>>> by usb_submit_urb]? Because that's what actually matters.
>>
>> In this driver, all references are to _usb_submit_urb(), which is defined to be
>> usb_submit_urb() in one of the header files. That made it easy to insert a test
>> for misalignment of the DMA buffer as follows:
<snip>
>> +static inline int _usb_submit_urb(struct urb *urb, gfp_t mem_flags)
>> +{
>> + if (urb->transfer_dma& 3) {
<snip>
> I think you need to check transfer_buffer and not transfer_dma.
I tried checking both transfer_buffer and transfer_dma and all
were always word aligned. (At least on Blackfin)
Ian.
--
Ian Jeffray [email protected] Tel: +44 (0) 141 221 8449
emobix Limited, Suite 5/5, 29 St Vincent Place, Glasgow, G1 2DT
Registered in Scotland; Company No. 371276 - VAT No. 983 4833 78
On Saturday 01 October 2011 18:01:08 Larry Finger wrote:
> Ian,
>
> Most of the skb assignments in r8712u are aligned OK and most aligned on
> 512-byte boundaries, but there was one that had the minimal offset of 14 bytes.
> The attached patch should fix it. Does it help?
Interesting, this "patch" goes in a completely different direction.
Can you tell me where the driver aligns the frames which will be
xmitted by the device [i.e.: which is passed to the usb subsystem
by usb_submit_urb]? Because that's what actually matters.
Regards,
Chr
On 01/10/2011 17:01, Larry Finger wrote:
> Ian,
>
> Most of the skb assignments in r8712u are aligned OK and most aligned on
> 512-byte boundaries, but there was one that had the minimal offset of 14
> bytes. The attached patch should fix it. Does it help?
Hi Larry,
Very many thanks for looking at this - I tried to look in to it
myself but realised I don't have a good understanding about what's
going on.
I won't have access to my problematic ARM system until Monday, but
I've tried this on Blackfin with musb and there's no change in
operation unfortunately.
But - I added some printk() debug in this area of the code and it
seem amsdu_to_msdu() is never called, on Blackfin or on x86 - even
when the driver is fully active and transferring data on an x86 PC.
Ian
--
Ian Jeffray [email protected] Tel: +44 (0) 141 221 8449
emobix Limited, Suite 5/5, 29 St Vincent Place, Glasgow, G1 2DT
Registered in Scotland; Company No. 371276 - VAT No. 983 4833 78
On 01/10/2011 20:24, Larry Finger wrote:
> BTW, netperf shows that r8712u can transmit at ~80 and receive at ~60
> Mbps when connected to a 270 Mbps AP. As Realtek lists this as capable
> of 150 Mbps, x86_64 is getting the max transmit rate that we might expect.
On x86 32bit, I get a sustained 94Mbps transmit to a 300Mbps AP, which
seems pretty good - why I'm keen to get this to work for my ARM target.
> @Ian: Ali Bahar submitted a number of patches to GregKH updating the
> driver to the latest Realtek version. As the git repo is not available
> due to kernel.org, and I have not found an alternate location that Greg
> has established, I am attaching them here.
Many thanks for that.
I've applied all Ali's patches you attached, and tried on my Blackfin
host, both with and without musb DMA enabled - no improvement, sadly.
I had also tried the 2.6.6.0.20110401 driver from Realtek without
any change in behaviour.
May try adding some liberal debug trace next, to compare to operation
on x86.
Regards,
Ian.
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
Ian,
Most of the skb assignments in r8712u are aligned OK and most aligned on
512-byte boundaries, but there was one that had the minimal offset of 14 bytes.
The attached patch should fix it. Does it help?
Larry
On Saturday 01 October 2011 20:49:02 Larry Finger wrote:
> On 10/01/2011 01:10 PM, Ian Jeffray wrote:
> > On 01/10/2011 19:01, Christian Lamparter wrote:
> >> On Saturday 01 October 2011 19:52:37 Larry Finger wrote:
> >>> On 10/01/2011 11:22 AM, Christian Lamparter wrote:
> >>>> On Saturday 01 October 2011 18:01:08 Larry Finger wrote:
> >>>>> Ian,
> >>>>>
> >>>>> Most of the skb assignments in r8712u are aligned OK and most aligned on
> >>>>> 512-byte boundaries, but there was one that had the minimal offset of 14
> >>>>> bytes.
> >>>>> The attached patch should fix it. Does it help?
> >>>> Interesting, this "patch" goes in a completely different direction.
> >>>> Can you tell me where the driver aligns the frames which will be
> >>>> xmitted by the device [i.e.: which
>
> is passed to the usb subsystem
> >>>> by usb_submit_urb]? Because that's what actually matters.
> >>>
> >>> In this driver, all references are to _usb_submit_urb(), which is defined to be
> >>> usb_submit_urb() in one of the header files. That made it easy to insert a test
> >>> for misalignment of the DMA buffer as follows:
> >
> > <snip>
> >
> >>> +static inline int _usb_submit_urb(struct urb *urb, gfp_t mem_flags)
> >>> +{
> >>> + if (urb->transfer_dma& 3) {
> >
> > <snip>
> >
> >> I think you need to check transfer_buffer and not transfer_dma.
> >
> > I tried checking both transfer_buffer and transfer_dma and all
> > were always word aligned. (At least on Blackfin)
> The same with x86_64.
Sure, x86_64 and powerpc set in system.h
grep NET_IP_ALIGN * -R
microblaze/include/asm/system.h:#define NET_IP_ALIGN 2
powerpc/include/asm/system.h:#define NET_IP_ALIGN 0
x86/include/asm/system.h:#define NET_IP_ALIGN 0
well, it looks like Realtek did a better job then and unfortunately
your problem is related to something else.
Regards,
Chr
On 10/01/2011 11:22 AM, Christian Lamparter wrote:
> On Saturday 01 October 2011 18:01:08 Larry Finger wrote:
>> Ian,
>>
>> Most of the skb assignments in r8712u are aligned OK and most aligned on
>> 512-byte boundaries, but there was one that had the minimal offset of 14 bytes.
>> The attached patch should fix it. Does it help?
> Interesting, this "patch" goes in a completely different direction.
> Can you tell me where the driver aligns the frames which will be
> xmitted by the device [i.e.: which is passed to the usb subsystem
> by usb_submit_urb]? Because that's what actually matters.
In this driver, all references are to _usb_submit_urb(), which is defined to be
usb_submit_urb() in one of the header files. That made it easy to insert a test
for misalignment of the DMA buffer as follows:
Index: wireless-testing-new/drivers/staging/rtl8712/osdep_service.h
===================================================================
--- wireless-testing-new.orig/drivers/staging/rtl8712/osdep_service.h
+++ wireless-testing-new/drivers/staging/rtl8712/osdep_service.h
@@ -34,7 +34,7 @@
#include <linux/if_arp.h>
#include <linux/firmware.h>
#define _usb_alloc_urb(x, y) usb_alloc_urb(x, y)
-#define _usb_submit_urb(x, y) usb_submit_urb(x, y)
+//#define _usb_submit_urb(x, y) usb_submit_urb(x, y)
struct __queue {
struct list_head queue;
@@ -232,5 +232,13 @@ static inline u32 _RND512(u32 sz)
return ((sz >> 9) + ((sz & 511) ? 1 : 0)) << 9;
}
+static inline int _usb_submit_urb(struct urb *urb, gfp_t mem_flags)
+{
+ if (urb->transfer_dma & 3) {
+ pr_info("Transfer_dma 0x%x not on 4-byte boundary\n",
(uint)urb->transfer_dma);
+ dump_stack();
+ }
+ return usb_submit_urb(urb, mem_flags);
+}
#endif
I never hit the pr_info() and the associated dump_stack(). If that test is
sufficient, then buffer misalignment is not the source of the problem.
Larry
On 10/01/2011 01:54 PM, Christian Lamparter wrote:
> well, it looks like Realtek did a better job then and unfortunately
> your problem is related to something else.
>
> Regards,
> Chr
Onwards. Thanks Christian for your suggestions. At least we were able to
eliminate one source of the problem.
BTW, netperf shows that r8712u can transmit at ~80 and receive at ~60 Mbps when
connected to a 270 Mbps AP. As Realtek lists this as capable of 150 Mbps, x86_64
is getting the max transmit rate that we might expect.
@Ian: Ali Bahar submitted a number of patches to GregKH updating the driver to
the latest Realtek version. As the git repo is not available due to kernel.org,
and I have not found an alternate location that Greg has established, I am
attaching them here.
Larry
On Saturday 01 October 2011 19:52:37 Larry Finger wrote:
> On 10/01/2011 11:22 AM, Christian Lamparter wrote:
> > On Saturday 01 October 2011 18:01:08 Larry Finger wrote:
> >> Ian,
> >>
> >> Most of the skb assignments in r8712u are aligned OK and most aligned on
> >> 512-byte boundaries, but there was one that had the minimal offset of 14 bytes.
> >> The attached patch should fix it. Does it help?
> > Interesting, this "patch" goes in a completely different direction.
> > Can you tell me where the driver aligns the frames which will be
> > xmitted by the device [i.e.: which is passed to the usb subsystem
> > by usb_submit_urb]? Because that's what actually matters.
>
> In this driver, all references are to _usb_submit_urb(), which is defined to be
> usb_submit_urb() in one of the header files. That made it easy to insert a test
> for misalignment of the DMA buffer as follows:
>
> Index: wireless-testing-new/drivers/staging/rtl8712/osdep_service.h
> ===================================================================
> --- wireless-testing-new.orig/drivers/staging/rtl8712/osdep_service.h
> +++ wireless-testing-new/drivers/staging/rtl8712/osdep_service.h
> @@ -34,7 +34,7 @@
> #include <linux/if_arp.h>
> #include <linux/firmware.h>
> #define _usb_alloc_urb(x, y) usb_alloc_urb(x, y)
> -#define _usb_submit_urb(x, y) usb_submit_urb(x, y)
> +//#define _usb_submit_urb(x, y) usb_submit_urb(x, y)
>
> struct __queue {
> struct list_head queue;
> @@ -232,5 +232,13 @@ static inline u32 _RND512(u32 sz)
> return ((sz >> 9) + ((sz & 511) ? 1 : 0)) << 9;
> }
>
> +static inline int _usb_submit_urb(struct urb *urb, gfp_t mem_flags)
> +{
> + if (urb->transfer_dma & 3) {
> + pr_info("Transfer_dma 0x%x not on 4-byte boundary\n",
> (uint)urb->transfer_dma);
> + dump_stack();
> + }
> + return usb_submit_urb(urb, mem_flags);
> +}
> #endif
I think you need to check transfer_buffer and not transfer_dma.
Regards,
Christian
On 10/12/2011 10:30 AM, Ian Jeffray wrote:
> On 02/10/2011 00:24, Ian Jeffray wrote:
>> On 01/10/2011 20:24, Larry Finger wrote:
>>
>>> BTW, netperf shows that r8712u can transmit at ~80 and receive at ~60
>>> Mbps when connected to a 270 Mbps AP. As Realtek lists this as capable
>>> of 150 Mbps, x86_64 is getting the max transmit rate that we might
>>> expect.
>>
>> On x86 32bit, I get a sustained 94Mbps transmit to a 300Mbps AP, which
>> seems pretty good - why I'm keen to get this to work for my ARM target.
>
> Larry, just a little more info on this issue, FYI.
>
> It would seem the problem is certainly specific to the 'Inventra' mUSB
> host found in recent TI ARM products and ADI Blackfin devices.
>
> I have added a PCI express NEC USB 2.0 host controller card to my ARM
> Cortex A8 system, and the r8712u devices work just fine when connected
> via that host controller. (Albeit only at 20MBps rate, but that's
> because the host controller is rather poor in general).
>
> We have now raised this problem with TI USB experts.
Thanks for the update. Good luck with finding the real problem and let me know
if I can be of help.
Larry
On 10/01/2011 01:10 PM, Ian Jeffray wrote:
> On 01/10/2011 19:01, Christian Lamparter wrote:
>> On Saturday 01 October 2011 19:52:37 Larry Finger wrote:
>>> On 10/01/2011 11:22 AM, Christian Lamparter wrote:
>>>> On Saturday 01 October 2011 18:01:08 Larry Finger wrote:
>>>>> Ian,
>>>>>
>>>>> Most of the skb assignments in r8712u are aligned OK and most aligned on
>>>>> 512-byte boundaries, but there was one that had the minimal offset of 14
>>>>> bytes.
>>>>> The attached patch should fix it. Does it help?
>>>> Interesting, this "patch" goes in a completely different direction.
>>>> Can you tell me where the driver aligns the frames which will be
>>>> xmitted by the device [i.e.: which
is passed to the usb subsystem
>>>> by usb_submit_urb]? Because that's what actually matters.
>>>
>>> In this driver, all references are to _usb_submit_urb(), which is defined to be
>>> usb_submit_urb() in one of the header files. That made it easy to insert a test
>>> for misalignment of the DMA buffer as follows:
>
> <snip>
>
>>> +static inline int _usb_submit_urb(struct urb *urb, gfp_t mem_flags)
>>> +{
>>> + if (urb->transfer_dma& 3) {
>
> <snip>
>
>> I think you need to check transfer_buffer and not transfer_dma.
>
> I tried checking both transfer_buffer and transfer_dma and all
> were always word aligned. (At least on Blackfin)
The same with x86_64.
Larry
On 02/10/2011 00:24, Ian Jeffray wrote:
> On 01/10/2011 20:24, Larry Finger wrote:
>
>> BTW, netperf shows that r8712u can transmit at ~80 and receive at ~60
>> Mbps when connected to a 270 Mbps AP. As Realtek lists this as capable
>> of 150 Mbps, x86_64 is getting the max transmit rate that we might
>> expect.
>
> On x86 32bit, I get a sustained 94Mbps transmit to a 300Mbps AP, which
> seems pretty good - why I'm keen to get this to work for my ARM target.
Larry, just a little more info on this issue, FYI.
It would seem the problem is certainly specific to the 'Inventra' mUSB
host found in recent TI ARM products and ADI Blackfin devices.
I have added a PCI express NEC USB 2.0 host controller card to my ARM
Cortex A8 system, and the r8712u devices work just fine when connected
via that host controller. (Albeit only at 20MBps rate, but that's
because the host controller is rather poor in general).
We have now raised this problem with TI USB experts.
Regards,
Ian.