硬體平台：mtk6797
軟體版本：android6.0
問題描述：我司的硬體方案比較個別，採用了6797，具體是應用了usb轉乙太網口作為伺服器的功能。由於硬體方案商的疏忽，我們的usb1.0接了亞信千兆的usb轉乙太網的晶元，雖然usb1.0很大程度上限制了網絡卡晶元的效能，但是時間考慮，就先這樣使用了，但是，從此，開始了修復usb問題的漫漫道路。。。
下邊先貼出一部分崩潰日誌：
可以看到在觸發崩潰之前，cpu負載均衡演算法在頻繁被呼叫。負載均衡機制簡單理解為系統為了均衡多核處理器中各個核子的任務繁重程度，而啟動的排程機制。說明在傳輸中的任務是很多的，核子的任務需要頻頻被調整，這裡我們就聯想到了網路傳輸中的中斷事件，是因為網路傳輸時，usb轉eth的中斷會被高頻觸發，這個中斷的名稱如下：
root@aeon6797_6c_m:/ # cat /proc/interrupts | grep musbfsh
105: 72286999 gicv3 105 musbfsh
此中斷每秒會被觸發數萬次，由於usb1.0承載能力有限，在處理如此高頻的中斷事件時，難免出現busy之類的情況，而此時系統出於安全考慮，會呼叫自己設定好的bug_on介面，bug_on的作用如下：
bug_on作用：一些核心呼叫可以用來方便標記bug，提供斷言並輸出資訊。最常用的兩個是bug()和bug_on()。
當被呼叫的時候，它們會引發oops，導致棧的回溯和錯誤資訊的列印。為什麼這些宣告會導致 oops跟硬體的體系結構
是相關的。大部分體系結構把bug()和bug_on()定義成某種非法操作，這樣自然會產生需要的oops。你可以把這些呼叫當作斷言使用，想要斷言某種情況不該發生：
if (bad_thing)
bug(); //需要linux 核心開啟general setup->configure standard kernel features->bug() support
或者使用更好的形式：
bug_on(bad_thing);
可以用panic()引發更嚴重的錯誤。呼叫panic()不但會列印錯誤訊息(oops)而且還會掛起整個系統。顯然，你只應該在極端惡劣的情況下使用它：
if (terrible_thing)
panic("foo is %ld\n", foo);
而觸發該事件的**段如下：
--- a/kernel-3.18/drivers/misc/mediatek/usb11/musbfsh_hsdma.c
+++ b/kernel-3.18/drivers/misc/mediatek/usb11/musbfsh_hsdma.c
@@ -191,8 +191,8 @@ static int dma_channel_program(struct dma_channel *channel,
musbfsh_channel->transmit ? "tx" : "rx", packet_sz,
(unsigned int)dma_addr, len, mode);
- bug_on(channel->status == musbfsh_dma_status_unknown ||
- channel->status == musbfsh_dma_status_busy);
+ //bug_on(channel->status == musbfsh_dma_status_unknown ||
+ // channel->status == musbfsh_dma_status_busy);
channel->actual_len = 0;
musbfsh_channel->start_addr = dma_addr;
按上述修改，即可遮蔽busy或者unknow的情況下的bugon觸發，針對這一問題，亞信官方給出的解釋是：usb1.0連線他們的usb轉eth晶元的原因，usb1.0處理能力有限，在使用usb2.0以上的連線方式的時候，就沒有該問題。
至此，洋洋灑灑，usb問題久攻不下的局面被徹底扭轉了。。。。
修復問題數十載，最終兩行定乾坤。
MTK平台 prelader的插入usb裝置開機慢
200217 10 02 42.868 bldr seclib brom meta mode 200217 10 02 42.868 hw set cc 450 200217 10 02 42.868 hw set cc done 200217 10 02 42.868 step a2 standa...
Jsoup引發的異常java異常
今天在使用jsoup的時候發現了乙個由jsoup引發的異常具體提示如下 illegalargumentexception request must be executed with execute get or post before getting response body 這個異常其實是由於j...
MTK平台學習 對MTK按鍵事件的簡單分析
主要簡單分析一下左右軟體的事件,以左軟鍵事件為例 牽涉到的常用函式 void setkeyhandler funcptr funcptr,u16 keycode,u16 keytype void setleftsoftkeyfunction void f void mmi key event typ...