DeKay
December 30, 2014, 1:30am
1
Hi All
Back in September I posted about some problems I had getting wifi going on the BBB. I’ve taken another shot at it and I (think I) have something working now. This post also rolls in a few other assorted tidbits scattered around in other posts. Hope somebody finds this useful.
Read it here on my blog: Wifi On The Beaglebone Black With Systemd
This is on the Jessie snapshot. I first tried it on my TP-Link TL-WN722N dongle but was getting kernel crashes again like I was in September. Bad hardware or ??? Things seem to work OK with a ZD1211 based dongle (any chance of getting zd1211-firmware in the image snapshot?), though I do see a few DUP! pings sometimes when the network has been idle for a while e.g.
PING www.google.com (216.58.216.228) 56(84) bytes of data.ord31s22-in-f4.1e100.net (216.58.216.228): icmp_seq=1 ttl=50 time=74.8 msord31s22-in-f4.1e100.net (216.58.216.228): icmp_seq=2 ttl=50 time=68.3 msord31s22-in-f4.1e100.net (216.58.216.228): icmp_seq=3 ttl=50 time=71.4 msord31s22-in-f4.1e100.net (216.58.216.228): icmp_seq=4 ttl=50 time=70.5 msord31s22-in-f4.1e100.net (216.58.216.228): icmp_seq=4 ttl=50 time=75.6 ms (DUP!)ord31s22-in-f4.1e100.net (216.58.216.228): icmp_seq=4 ttl=50 time=76.2 ms (DUP!)ord31s22-in-f4.1e100.net (216.58.216.228): icmp_seq=4 ttl=50 time=76.2 ms (DUP!)ord31s22-in-f4.1e100.net (216.58.216.228): icmp_seq=4 ttl=50 time=76.5 ms (DUP!)ord31s22-in-f4.1e100.net (216.58.216.228): icmp_seq=4 ttl=50 time=82.6 ms (DUP!)
Thoughts? Comments? Questions?
DeKay
December 30, 2014, 2:35am
2
Looks like I may have spoken too soon. I wasn’t even in the room when the connection died this time, after having run OK for hours. This with my ZD1211 dongle. I think I’m going to give up on this thing unless anyone has any ideas.
root@beaglebone:~# ping www.google.com www.google.com
root@beaglebone:~# iw wlan1 link
root@beaglebone:~# systemctl status NetworkManager -l
Dec 30 01:34:42 beaglebone NetworkManager[269]: Activation (wlan1) Stage 5 of 5 (IPv4 Commit) started…
root@beaglebone:~# journalctl -u NetworkManager --no-pager | less
Just added back for Jessie.
Regards,
DeKay
December 31, 2014, 4:50pm
4
Thanks Robert.
I think I have some good news with respect to the problem I was having with the TP-Link TL-WN722N locking up. Yesterday morning I set the cpu governor to “performance” and the connection has been solid ever since (unless you count the five power outages we had at our house yesterday). Unfortunately this didn’t fix the problem with the ZD1211 based stick - it would still report DUP packets and it then lost its connection after less than an hour. I’m sticking with the TP-Link going forward.
So, for future reference, here is a cut and paste from another post on this board.
Edit /etc/default/cpufrequtils (you might need to create it if it doesn’t exist). Specify the governor with the GOVERNOR variable:
nano /etc/default/cpufrequtils to contain the line
I’m going to update my blog post with this info. I would also suggest that this be made the default in your future images: I’m not the only person that has seen weird behavior with the default of “ondemand”.
I forget what the actual power draw numbers are, but we set default so
I haven't looked into it fully, but the pmic knows what mode we are in
Regards,
Humm... maybe i need another cup of coffee...
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/defconfig#L532
So on bootup it's using the performance governor till the usespace
Regards,
Robert,
Did the detection of the voltage in the PMIC and therefore the forcing of performance mode go any further at all?
We are powering via the header pins with 5V and see it drop to "ondemand" after boot.
Lee