Date: Sat, 23 Sep 2017 21:32:26 -0700 From: Russell Haley <russ.haley@gmail.com> To: Chris Gordon <freebsd@theory14.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? Message-ID: <CABx9NuTt2Y0VQ4QUtgoXOuj3VjCGfu9Y8krp4KyuRUG4WX89Ww@mail.gmail.com> In-Reply-To: <CABx9NuTxS_Pc_tko3HZyCFhMLvQa8bVDGx308aLJaG_8JHhu-Q@mail.gmail.com> References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <685d0eed3532a34f239e7ff893f817db@bakulin.de> <EB1907C8-7A0A-4D45-AD21-B449DC4C0D7D@theory14.net> <CABx9NuQCrspSzcdXh0_cbO1QmexwQbrk1djaGyvKTp370AtxYA@mail.gmail.com> <CABx9NuQJWot9xgs1QtzJ87NfgZM=FPhZ%2B2a-RewDonvGG5LLKg@mail.gmail.com> <CABx9NuT1n8ZYPrZTB8vT2sBmT3U75E4UFgAGA3ZOPTotpsUWeg@mail.gmail.com> <CABx9NuQB=xBNt6%2BX=YKw4XVW5u1XysW%2Bo7pqO_9D2RC%2BF6bKug@mail.gmail.com> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> <CABx9NuQtXRbN6YPihotuLSnE5cFG-xvRRNYyFSLGxZNPBnKTKQ@mail.gmail.com> <E1992F2B-236D-467C-AAEE-B81A59EB1138@theory14.net> <CABx9NuTTewBiuesSxWsWsJg2HeRZFPeNU1WSRpqxEALxSUEhkw@mail.gmail.com> <CABx9NuTxS_Pc_tko3HZyCFhMLvQa8bVDGx308aLJaG_8JHhu-Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 7, 2017 at 12:03 AM, Russell Haley <russ.haley@gmail.com> wrote= : > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221845#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? Well, for what it's worth, Debian on my BBB doesn't think much of my wifi adapter much either: [ 480.532193] INFO: task ifconfig:1369 blocked for more than 60 seconds. [ 480.539231] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 480.547647] Kernel panic - not syncing: hung_task: blocked tasks [ 480.554065] [<c00114f1>] (unwind_backtrace+0x1/0x9c) from [<c04d0abd>] (panic+0x59/0x15c) [ 480.562746] [<c04d0abd>] (panic+0x59/0x15c) from [<c0073915>] (watchdog+0x19d/0x1c0) [ 480.570972] [<c0073915>] (watchdog+0x19d/0x1c0) from [<c00454ab>] (kthread+0x6b/0x78) [ 480.579294] [<c00454ab>] (kthread+0x6b/0x78) from [<c000c8fd>] (ret_from_fork+0x11/0x34) [ 480.587874] drm_kms_helper: panic occurred, switching back to text conso= le Russ > > zzz, > Russ > > On Wed, Sep 6, 2017 at 5:13 PM, Russell Haley <russ.haley@gmail.com> wrot= e: >> On Wed, Sep 6, 2017 at 3:30 PM, Chris Gordon <freebsd@theory14.net> wrot= e: >>> 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 sessio= ns (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 outpu= t from "top -Sa=E2=80=9D thinking the CPU was overwhelmed. The system stay= s at >90% idle through the entire test (upload and download). I see 2-4% W= CPU 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=E2=80=99t be until next week when I can look at any of these. I= =E2=80=99m one of the organizers at vBSDcon and will be at the Dev Summit a= nd conference through the weekend. If anyone is interested, I=E2=80=99m ha= ppy 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 othe= r than i-devices. I used nuttcp for testing the wired connection, so I wou= ld 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 c= hance. >>> >>>> 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 a= nd specific knowledge of what to start poking (of course, this is a great w= qy 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=E2=80=99ll get some info as soon as I can. An= ything important I=E2=80=99ll 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABx9NuTt2Y0VQ4QUtgoXOuj3VjCGfu9Y8krp4KyuRUG4WX89Ww>