?在技術(shù)支持群，看到有用戶報(bào)了一個(gè)不明原因的重啟問題。 重啟現(xiàn)象是 ——有極個(gè)別設(shè)備在工作中不定時(shí)反復(fù)異常重啟，大部分設(shè)備正常；反復(fù)重啟設(shè)備，有時(shí)候又能持續(xù)正常工作。

隔著屏幕都感覺到了客戶的著急和無奈，我決定和這位用戶一起揪出這個(gè)“搗蛋鬼”。

?

一、查找線索

按常規(guī)流程先詢問用戶開發(fā)模塊、開發(fā)方式，并要求提供對應(yīng)日志。經(jīng)確認(rèn)如下：

開發(fā)模塊：Air780E

最新資料：www.air780e.cn

開發(fā)方式：LuatOS

開發(fā)教程：

https://doc.openluat.com/wiki/26?wiki_page_id=3020

客戶提供日志反饋：

腳本日志沒報(bào)錯(cuò)誤，就是不定時(shí)卡住一會，然后就重啟了。

?

第一反應(yīng)：不會是死循環(huán)導(dǎo)致的重啟吧？

用戶反饋：“沒有死循環(huán)，任務(wù)里面都有延時(shí)的，而且大部分設(shè)備是正常的。且重啟的時(shí)間也不定，最短4秒，最長是三分多鐘，看起來不符合20秒的看門狗重啟呀，而且設(shè)備昨天有正常工作一天，然后異常的時(shí)候就持續(xù)一直異常。但是這個(gè)固件的絕大部分設(shè)備是正常工作，不會異常重啟的。”

看來不是死循環(huán)導(dǎo)致的看門狗重啟問題。

為了進(jìn)行一步排查重啟原因，我讓用戶用pm.lastReson()這個(gè)接口打印開機(jī)原因值。

客戶反饋：“我們有平臺上傳數(shù)據(jù)， pm.lastReson()是006異常重啟 ”。

根據(jù)接口文檔相關(guān)說明來看，確實(shí)不是內(nèi)部看門狗導(dǎo)致的重啟，是異常重啟導(dǎo)致的。

接口文檔詳見：

https://wiki.luatos.com/api/pm.html#pm-lastreson

?

二、了解背景

心想看不出啥具體原因，先了解一下客戶使用背景吧，說不定會有啥線索。

我問：“之前正常，現(xiàn)在是用不了，一直在重啟嗎？”

客戶反饋：“也不是吧，一開始是好的，然后掛了幾個(gè)月一直重啟，最近發(fā)現(xiàn)，昨天我拿過來掛了一天又正常，然后今天又重啟，老化區(qū)就這個(gè)設(shè)備會重啟，其他同固件是正常的?！?/p>

我又問：“換DEMO會重啟嗎？ 確認(rèn)一下是硬件問題，還是軟件問題。 ”

客戶反饋：“ 今天測試過，只下載腳本是一定會出問題。 然后我剛剛重新下載底層和腳本，目前五分鐘沒有重啟。”

看上去應(yīng)該不是硬件問題，可能是軟件引起的。心想讓客戶用最新版本試一下吧，確認(rèn)一下還會不會出現(xiàn)問題。

客戶反饋：“我們是因?yàn)橛幸粋€(gè)設(shè)備到客戶手上有這個(gè)問題是V1108的，然后老化區(qū)只有這個(gè)設(shè)備也是異常重啟，是V1106的，然后就看的這個(gè)，后面重新燒錄1106的底層也是正常的，這設(shè)備挺難出現(xiàn)這個(gè)問題的，只能我們這邊掛著測一下。”

看來又是一個(gè)令人頭大的重啟問題，要等客戶提供底層日志來進(jìn)一步排除問題了。

三、重要線索

客戶把掛測的底層日志提供過來了，打開后確實(shí)看到了RamDumpData開頭的死機(jī)信息。

?

打開上面的RamDumpData出現(xiàn)如下信息：

?

我趕緊和研發(fā)大佬確認(rèn)，可能是啥情況。大佬問答大概率是FLASH壞掉了，讓和客戶確認(rèn)不是有KV相關(guān)的操作。

客戶回答，確實(shí)有KV的操作。

本文提到的KV：

KV數(shù)據(jù)庫 ——指的是LuatOS中的FSKV庫，提供鍵值對數(shù)據(jù)庫功能，數(shù)據(jù)持久化在Flash上，使用獨(dú)立的KV分區(qū)，使用LuaTools刷機(jī)時(shí)可選擇清空，默認(rèn)是不清空。由Flash的特性決定了，寫入次數(shù)是有限的，頻繁寫入導(dǎo)致超限后，將無法設(shè)置/更新數(shù)據(jù)，導(dǎo)致系統(tǒng)異常。

為了進(jìn)一步驗(yàn)證猜測，讓客戶做了如下測試：

問：“死機(jī)重啟后，燒錄不清除KV試試看還會不會重啟，或者去除KV相關(guān)操作看還會不會重啟。”

答：“KV操作挺多的，不好清除，我試下燒錄不清除KV，有時(shí)候斷電過一會就好了，不是很好復(fù)現(xiàn)，我先試試燒錄不清除KV。”

客戶反饋：“不清除KV也會有重啟?！?/p>

問：“重新燒錄底層的時(shí)候，有沒有清理KV?！?/p>

答：“有”…

根據(jù)此前客戶反饋和當(dāng)前測試來看，應(yīng)該是FALSH模塊有些區(qū)域壞掉了。

四、確認(rèn)猜測

至此，可以說這個(gè)重啟的原因基本是確認(rèn)了，導(dǎo)致模塊令人琢磨不透的重啟問題的“搗蛋鬼”也基礎(chǔ)上算是給揪出來了。但是，還是需做進(jìn)一步的測試來確定猜測。

研發(fā)大佬給了一下測試固件，來確認(rèn)猜測是否正確。

?

經(jīng)過測試驗(yàn)證后，確定是FALSH部分區(qū)域壞掉引起的重啟。

至此這個(gè)“重啟案件”算是偵破了。

給客戶的建議：

要改腳本，需要大幅度減少寫KV的次數(shù)，防止破壞模塊重啟的“搗蛋鬼”再次出來搗亂。

溫馨提示：

KV的寫壽命是10萬次，過于頻繁操作可能會導(dǎo)致FLASH壞掉，引起設(shè)備反復(fù)重啟。

因此，在寫代碼的時(shí)候要盡量減少寫KV的次數(shù)。

審核編輯 黃宇