From owner-freebsd-arm@freebsd.org Sun Sep 24 04:32:29 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6967E1EAF2 for ; Sun, 24 Sep 2017 04:32:29 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 570F069486 for ; Sun, 24 Sep 2017 04:32:29 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id m199so4060675lfe.3 for ; Sat, 23 Sep 2017 21:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DjyrRBsMQoHMLgW58bP8SuhNS8wKuH/eOpE3OmzE3rQ=; b=GFK5aM3SYyL3exRJ+Dx2dUdX06wqruvzxh93gxhvBojqvlnhZRSjKUwz2rjvnmPuO8 b2hJJUVDcVg4+Ce0oUFwXgHzZzFID8OAy99ZEdhamOTWmI/sl7HdbK0zkmOge5CcLzzt 666cU5W2l+tgH4t0js0xVhh1eXhqeMMznM6zAid6QoWOdagmnAsZMWswd0o1HfM/yAFq +aw/8AqS2LE6/o3umOS/xLjEC3Um7DmPawQzq7ILIM72dpV2xqMretEM2B/z+8Cg9Roa vkVsHxdsX8RFfK1YBamF6hhuLsbFbPffFl7mpFKMzlSweI2I8VZ7NExO7qee++LMXP2z pA+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DjyrRBsMQoHMLgW58bP8SuhNS8wKuH/eOpE3OmzE3rQ=; b=T8KQksDOnRKLps9VvrPciKM2NSWrPamMOwE/h7em40Sh7PzKxbkHGycxdcwCP7dzPf QseXZNNjUE8PbHqgBMl/jUN0q6Enk6qAya2sQutEqMC4jx+Uy+cTeI4DkHqDNhwkf7+S LvVBY/5OyWnQsW/WRU4SfHPnooUSW5w7UOCgfFcUdlu/XrUytHmutzqIoFNNf/2YdzAZ vcqeFQ4rhwuBNHyKPev2eOBiIXs7sYhdPMr+TQVe11q9b6QJnzyzpCGgMJH5np4uEYhD SFo4TpecAraPwCV+5yRLprzeFcTu52oczBI3lEUpkDUMEugZrYG3uPFynFSYgO0nDY/q I9vA== X-Gm-Message-State: AHPjjUi0/xxyYvGmiPvAg19gMq3hfUiwdDz8NtfsDcah/L3lDFihUkd/ 5TbMMEg/u3mDtjNGmWRhOwAXQMV/xgZ1UspIx5MehA== X-Google-Smtp-Source: AOwi7QBx1LCfHtR2c55LfXPXgXJUGRrwRTrv5uuV2P9dPbjsaUWHTafBFzENkaUDyfAFmPPJT4HkOzg3AlxL1/VT/rM= X-Received: by 10.25.202.12 with SMTP id a12mr1185545lfg.54.1506227547052; Sat, 23 Sep 2017 21:32:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.81.65 with HTTP; Sat, 23 Sep 2017 21:32:26 -0700 (PDT) In-Reply-To: References: <40EA308E-489D-4A0B-B75A-2CA5A4EC474E@theory14.net> <685d0eed3532a34f239e7ff893f817db@bakulin.de> <20170905141711.6545490.14963.31294@gmail.com> <656A5193-7389-476C-AF58-EB013E9155F3@theory14.net> From: Russell Haley Date: Sat, 23 Sep 2017 21:32:26 -0700 Message-ID: Subject: Re: Beaglebone Black + FreeBSD + USB WiFi = WAP? To: Chris Gordon Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 04:32:29 -0000 On Thu, Sep 7, 2017 at 12:03 AM, Russell Haley 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] [] (unwind_backtrace+0x1/0x9c) from [] (panic+0x59/0x15c) [ 480.562746] [] (panic+0x59/0x15c) from [] (watchdog+0x19d/0x1c0) [ 480.570972] [] (watchdog+0x19d/0x1c0) from [] (kthread+0x6b/0x78) [ 480.579294] [] (kthread+0x6b/0x78) from [] (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 wrot= e: >> On Wed, Sep 6, 2017 at 3:30 PM, Chris Gordon 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