Forum Replies Created
-
Posts
-
Some authoritive information:
From http://elinux.org/Beagleboard:BeagleBoneBlack
“`
Improper Power Down….All RevisionsWe have been noticing a very small number of boards that are experiencing power issues, where the LED flashes and the board does not power up. We have been chasing this for a while now and due to the small number of boards that have the issue and the fact that the issue can also be caused by having things connected to IO pins not powered correctly, it has been hard to nail down. Our initial take was that it was a manufacturing issue on some boards, but we could never prove that. Based on the latest information we have gathered, this appears to be an instance where the PMIC does not power down the processor in the right order due to the violent removal of the power cables, either USB or DC. So, we are recommending that the power button be used to power off the board or by issuing the Halt command. After that you can remove the power cable. If everyone follows this process, we should see a decrease in these issues, but it will take a while for the results, either good or bad, to show up. This will also help prevent the contamination of the eMMC and the SD cards by allowing the kernel to shutdown properly before power is removed.
“`It’s going to be hard to follow these instructions with my system living in a Hunter outside enclosure.
I’m going to look more closely at the battery support on the BBB board.
Steve
The failures were coincident with thunderstorms and dimming lights. The unit has been outside and difficult to instrument. It’s now inside, hooked up to a serial cable and am awaiting the next thunderstorm. Being SW Florida and this time of year, it shouldn’t be long.
Searching found lots of complaints about recovering from low line voltage. Some of the discussion involved hooking up a LiIon and LiPo battery to the charger that is already on the board. Others suggested that the problem was noise on the serial rx line during bootup that caused redboot to stop booting and wait for console input. I’ll post a followup when I know more.
I am using a wifi usb dongle and the RTL8192CU driver. The driver has been rock solid since I shut off aggregation. I still haven’t heard anything from the linux-wireless list.
No reply to my post on linux-wireless yet.
I built a kernel from here: https://github.com/RobertCNelson/bb-kernel.git
to test the work-around.I also found the same problem with the driver. After sniffing from another pc running wireshark, it appeared that the aggregation sessions between the ap and the usb radio would deadlock. I tried running in non-ht mode and the problem disappeared. Next, I modified the driver to report no hardware aggregation support and the problem disappeared too. The latter allows you to run at ht speeds.
The problem seems to be that the AP starts an aggregation session and the STA starts one also before the AP session terminates. This seems to hang the driver.
I reported the problem to the linux-wireless list.
A patch is below. It’s not a fix, just a workaround until somebody more knowledgable has time to deal with it.
Steve
==========— a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -59,6 +59,9 @@ static int rtl92cu_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
int err;+ /* disable aggregation until the deadlock is fixed */
+ hw->flags &= ~IEEE80211_HW_AMPDU_AGGREGATION;
+
rtlpriv->dm.dm_initialgain_enable = true;
rtlpriv->dm.dm_flag = 0;
rtlpriv->dm.disable_framebursting = false;
