Beaglebone Black + FreeBSD + USB WiFi = WAP?

[Russell Haley]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221845#c3

I've been following the code through and wound up at
sys/arm/ti/cpsw/if_cpsw.c. cpsw_intr_rx [which] is defined on line
1554. The function uses a macro called CPSW_RX_LOCK which is defined
on line 349. The macro contains an assert on a transmit lock
(tx.lock). I theorise the statement on line 350 is causing my
exception? I also wonder if the lock being held between lines 1561 and
1570 is causing the delay in the bridge interface that is causing the
original posters' slow throughput. Is it necessary to hold the lock
until after the cpsw_write_4 on line 1569 or could it be performed
outside the lock?


zzz,
Russ

On Wed, Sep 6, 2017 at 5:13 PM, Russell Haley <russ.haley at gmail.com> wrote:
> On Wed, Sep 6, 2017 at 3:30 PM, Chris Gordon <freebsd at theory14.net> wrote:
>> Russ,
>>
>>> Have you monitored your system on a serial console or direct console
>>> (i.e. via hdmi/keyboard)? Is the system still responding to other
>>> commands after you run the speed test? My thought is that the really
>>> really low bandwidth belies a kernel panic on the main terminal that
>>> you are not seeing.
>>
>> I have a serial console connected the entire time along with ssh sessions (via wired NIC) into the BBB.  There is no panic other other messages on the console.  The devices remains responsive to user input/actions via ssh. In a previous reply to my initial inquiry, Ilya Bakulin asked about output from "top -Sa” thinking the CPU was overwhelmed.  The system stays at >90% idle through the entire test (upload and download).  I see 2-4% WCPU for interrupts and 1-2% for USB.
>
> Good, thanks for clarifying.
>
>>> If you would like to do some further testing, you could perhaps help
>>> me answer these things:
>>
>> It won’t be until next week when I can look at any of these.  I’m one of the organizers at vBSDcon and will be at the Dev Summit and conference through the weekend.  If anyone is interested, I’m happy to bring my BBB there for debugging/testing on site.
>
> Argh! I was just in Maryland and we flew home from Dulles!!! I made
> the client push the date forward to last week so I could be home for
> Labour Day.
>
> Have fun! (sob, sob, sob). ;)
>
>>> - Can you find a command line way of measuring throughput and latency
>>> separately that can be run on a host and on the bbb? I'm sure there
>>> are lots of ways to do so. I will leave it up to you to decide and
>>> will adopt the same tests so we can compare results.
>>
>> I just have to find another device -- I have everything wired here other than i-devices.  I used nuttcp for testing the wired connection, so I would plan to use that for the Wifi.
>
> nuttcp. Got it, I'll start playing with it.
>
>>> - Can you run the bbb as a standard device (not an access point) and
>>> test the performance of the wlan0 interface using the method of
>>> measurement pointed above? I will do the same at some point with my
>>> wi-fi dongle.
>>
>> Yes, that should be easy to do, but will be next week before I have a chance.
>>
>>> Some tests I would like to do:
>>> - Get DTrace involved as a debugging tool. I have rudimentary DTrace
>>> skills but will need to consult my books on how to measure throughput
>>> and latency. There are some examples early in the DTrace book of
>>> logging system calls made by a process and I will review that again
>>> when time permits.
>>> - Run the system through the kernel debugger. I think this is going to
>>> be difficult though as pausing the kernel in the middle of TCP traffic
>>> might invalidate any results I get. I know how difficult it can be to
>>> debug threaded applications, I can't see a kernel being any easier. ;)
>>
>> I was thinking along the same lines and hampered only by lack of time and specific knowledge of what to start poking (of course, this is a great wqy to learn!).
>
> My random thought of the day is that the "down/receive" from eth0 to
> wlan0 is working somewhat correctly, but the "up/send" from wlan0 to
> eth0 is causing issues. This is coming from your throughput notes, and
> the fact I got a whole page downloaded, but received a panic when I
> was trying to request another page. My thought is to start looking at
> the send commands for wlan0 and USB.
>
>> Thanks for your help.  I’ll get some info as soon as I can.  Anything important I’ll add to the bug report.
>
> Thanks for having a fun problem to play with! Good luck with the
> conference and don't worry about time, I have 3 other things that I
> started this week alone. Anyone want to test a prototype Lua database?
> lolz.
>
> Russ