21. 重啟log分析
阿新 • • 發佈：2019-01-30
案例一 : kernel重啟 - mt6580.dtsi 現象 : 平臺 : androidN,MTK6580 排查過程: 1. 打串列埠log，發現如下： [ 1.607970] <2>.(2)[1:swapper/0]musb-hdrc musb-hdrc.0.auto: Cannot find usb pinctrl iddig_irq_init [ 1.609094] <2>.(2)[1:swapper/0]Unable to handle kernel paging request at virtual address fffffff9 [ 1.610245] <2>.(2)[1:swapper/0]pgd = c0004000 [ 1.610794] [fffffff9] *pgd=9fffd821, *pte=00000000, *ppte=00000000 [ 1.611581] <2>-(2)[1:swapper/0]Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 2.612481] <2>-(2)[1:swapper/0]Non-crashing CPUs did not react to IPI [ 2.613303] <2>-(2)[1:swapper/0]CPU: 2 PID: 1 Comm: swapper/0 Tainted: G W 3.18.35 #2 [ 2.614409] <2>-(2)[1:swapper/0]task: df060000 ti: df04a000 task.ti: df04a000 [ 2.615304] <2>-(2)[1:swapper/0]PC is at pinctrl_select_state+0x84/0x154 【// 重啟log可以看【PC】停在哪兒】 [ 2.616140] <2>-(2)[1:swapper/0]LR is at otg_int_init+0x64/0x154 ... [ 3.000390] <2>-(2)[1:swapper/0][<c038e374>] (pinctrl_select_state) from [<c0451ba0>] (otg_int_init+0x64/0x154) 【// 重啟log可以根據這條log看停在哪個【函式】】 [ 3.001803] r9:60000113 r8:60000113 r7:c1151d70 r6:c1151e30 r5:c109a408 r4:c1151db0 [ 3.003408] <2>-(2)[1:swapper/0][<c0451b3c>] (otg_int_init) from [<c0451db0>] (mt_usb_otg_init+0x120/0x230) [ 3.004777] r6:c1151e30 r5:c1151db0 r4:df182140 [ 3.005816] <2>-(2)[1:swapper/0][<c0451c90>] (mt_usb_otg_init) from [<c044d2f8>] (mt_usb_init+0x1d8/0x6d0) [ 3.007176] r6:e1700000 r5:c1151d70 r4:df182140 r3:c12ecaa0 [ 3.008417] <2>-(2)[1:swapper/0][<c044d120>] (mt_usb_init) from [<c0458608>] (musb_probe+0x2d0/0xb24) [ 3.009720] r10:00000088 r9:e1700000 r8:de918700 r7:de915000 r6:c1151df8 r5:df182140 [ 3.011218] r4:df182000 [ 3.011861] <2>-(2)[1:swapper/0][<c0458338>] (musb_probe) from [<c03c45c8>] (platform_drv_probe+0x38/0x90) [ 3.013218] r10:00000000 r9:df212a00 r8:c10501c0 r7:c10501c0 r6:fffffdfb r5:de915010 [ 3.014714] r4:ffffffed [ 3.015361] <2>-(2)[1:swapper/0][<c03c4590>] (platform_drv_probe) from [<c03c2c58>] (driver_probe_device+0x1d8/0x43c) [ 3.016841] r7:c113cdbc r6:c1094378 r5:de915010 r4:c113cdb0 [ 3.018096] <2>-(2)[1:swapper/0][<c03c2a80>] (driver_probe_device) from [<c03c2f9c>] (__driver_attach+0x94/0x98) [ 3.019521] r10:00000000 r9:df212a00 r8:c0f00600 r7:00000000 r6:de915044 r5:c10501c0 [ 3.021013] r4:de915010 [ 3.021646] <2>-(2)[1:swapper/0][<c03c2f08>] (__driver_attach) from [<c03c108c>] (bus_for_each_dev+0x68/0x9c) [ 3.023037] r6:c03c2f08 r5:c10501c0 r4:00000000 r3:00000000 [ 3.024278] <2>-(2)[1:swapper/0][<c03c1024>] (bus_for_each_dev) from [<c03c304c>] (driver_attach+0x24/0x28) [ 3.025649] r6:c1040f40 r5:df211d00 r4:c10501c0 [ 3.026690] <2>-(2)[1:swapper/0][<c03c3028>] (driver_attach) from [<c03c1a64>] (bus_add_driver+0x15c/0x218) [ 3.028185] <2>-(2)[1:swapper/0][<c03c1908>] (bus_add_driver) from [<c03c39c4>] (driver_register+0x80/0x100) [ 3.029567] r7:df04a030 r6:c0f2efb8 r5:c0f617d8 r4:c10501c0 [ 3.030840] <2>-(2)[1:swapper/0][<c03c3944>] (driver_register) from [<c03c50c8>] (__platform_driver_register+0x5c/0x64) [ 3.032341] r5:c0f617d8 r4:00000000 [ 3.033203] <2>-(2)[1:swapper/0][<c03c506c>] (__platform_driver_register) from [<c0f2efec>] (musb_init+0x34/0x48) [ 3.034790] <2>-(2)[1:swapper/0][<c0f2efb8>] (musb_init) from [<c0f00e74>] (do_one_initcall+0x140/0x200) [ 3.036128] r4:c0f617d8 r3:00000000 [ 3.037016] <2>-(2)[1:swapper/0][<c0f00d34>] (do_one_initcall) from [<c0f01078>] (kernel_init_freeable+0x144/0x1e8) [ 3.038474] r10:c0f6200c r9:00000141 r8:c0f00600 r7:c10dc7c0 r6:c10dc7c0 r5:c0f62000 [ 3.039968] r4:00000006 [ 3.040635] <2>-(2)[1:swapper/0][<c0f00f34>] (kernel_init_freeable) from [<c0a80e5c>] (kernel_init+0x10/0x100) [ 3.042036] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0a80e4c [ 3.043523] r4:00000000 [ 3.044170] <2>-(2)[1:swapper/0][<c0a80e4c>] (kernel_init) from [<c01070a0>] (ret_from_fork+0x14/0x34) [ 3.045483] r4:00000000 r3:df04a000 ... [ 7.201650] Rebooting in 1 seconds.. 2. 根據log分析：由usb20_host.c中的函式otg_int_init()呼叫pinctrl_select_state()時出錯導致重啟 往前找到:Cannot find usb pinctrl iddig_irq_init; 到此問題明瞭：重啟是由於mt6580.dtsi裡缺少了一個pin屬性：“iddig_irq_init” 3. 檢視log：在mt6580.dtsi中刪掉了這一屬性 --> 還原這一屬性，ok。 處理方案: 明天特意刪掉嘗試一下 --> 嘗試刪掉之後編譯報錯！【存疑】 總結 : 案例二 : 開機重啟 - kernel無法啟動 - 懷疑是kernel所在分割槽有壞塊 - 【最後換了塊屏就好了】 現象 : 開機還在log介面就重啟 ，只有一臺機器重啟 平臺 : androidN,MTK6737 排查過程: 1. 抓取串列埠log： [7360] cmdline: console=tty0 console=ttyMT0,921600n1 root=/dev/ram vmalloc=496M androidboot.hardware=mt6735 slub_max_order=0 slub_debug=O androidboot.verifiedbootstate=green bootopt=64S3,32N2,64N2 printk.disable_uart=1 bootprof.pl_t=1809 bootprof.lk_t=3748 boot_reason=0 androidboot.serialno=0123456789ABCDEF androidboot.bootreason=power_key gpt=1 [7360] lk boot time = 3748 ms [7360] lk boot mode = 0 [7360] lk boot reason = power_key [7360] lk finished --> jump to linux kernel 64Bit 【// 由lk進入kernel】 [7360] [LK]jump to K64 0x40080000 [7360] smc jump [ATF](0)[0.0]save kernel info [ATF](0)[0.0]Kernel_EL2 [ATF](0)[0.0]Kernel is 64Bit [ATF](0)[0.0]pc=0x40080000, r0=0x4e000000, r1=0x0 INFO: BL3-1: Preparing for EL3 exit to normal world, Kernel INFO: BL3-1: Next image address = 0x40080000 INFO: BL3-1: Next image spsr = 0x3c9 [ATF](0)[0.0]el3_exit 【// 以下為重啟後】 [ATF](0)[30.162857]aee_wdt_dump: on cpu0 [ATF](0)[30.163290](0) pc:<ffffffc00034a5d4> lr:<ffffffc00034cafc> sp:<ffffffc000dffea0> pstate: 600000c5 [ATF](0)[30.164452](0) x29: ffffffc000dffea0 x28: 0000004040000000 x27: ffffffc000080270 [ATF](0)[30.165430](0) x26: ffffffc000e94a00 x25: 0000000000000003 x24: 0000000704c2eee5 [ATF](0)[30.166406](0) x23: 0000000000000000 x22: ffffffc000eced08 x21: ffffffc03f738d48 [ATF](0)[30.167382](0) x20: ffffffc000eced08 x19: 0000000000000000 x18: 0000000000000070 [ATF](0)[30.168359](0) x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ATF](0)[30.169335](0) x14: 0000000000000007 x13: 0000000000000000 x12: 0000000000000078 [ATF](0)[30.170311](0) x11: 000000000000000f x10: 000000000000000c x09: 00000000ffffffff [ATF](0)[30.171287](0) x08: 0000000000000007 x07: 0000000000035f48 x06: 00000000000006de [ATF](0)[30.172263](0) x05: 00405f7e0099cf00 x04: 0000000000000019 x03: 0000000099d89d8a [ATF](0)[30.173239](0) x02: 0000000000085b0c x01: ffffffc000fb4000 x00: 0000000000000000 [pmic_init] Preloader Start,MT6328 CHIP Code = 0x2820 3. 由log分析 ： 在lk進入kernel時重啟，可能的原因為：flash有壞塊，kernel剛好在該壞塊 -> 重新格式化下載幾次 -> 一樣 4. 換塊flash -> 一樣 -> 再換一塊 -> 結果未知（詢問專案程工） 5. 最後換了塊屏就好了 案例三 : 開機過一會兒重啟（約5分鐘） - 死鎖 現象 : 平臺 : androidO,MTK6737 排查過程: 1. 匯出mtklog, 檢視last_kmsg.log // 檢視PC指標停在哪裡 [ 121.420261] -(2)[816:system_server]PC is at spin_bug+0x1d8/0x220 [ 121.420614] -(2)[816:system_server]LR is at spin_bug+0x1cc/0x220 [ 121.420915] -(2)[816:system_server]pc : [<ffffffc0000f9c1c>] lr : [<ffffffc0000f9c10>] pstate: 800001c5 [ 121.421198] -(2)[816:system_server]sp : ffffffc05c0138c0 // 呼叫蹤跡 [ 121.640932] -(2)[816:system_server][<ffffffc0000f9c1c>] spin_bug+0x1d8/0x220 [ 121.641310] -(2)[816:system_server][<ffffffc0000f9d70>] do_raw_spin_lock+0x58/0x338 [ 121.641660] -(2)[816:system_server][<ffffffc000b65788>] _raw_spin_lock_irqsave+0x5c/0x84 [ 121.642001] -(2)[816:system_server][<ffffffc0000ef608>] down_interruptible+0x18/0x60 [ 121.642368] -(2)[816:system_server][<ffffffc00041e3dc>] mc3xxx_mutex_lock+0x18/0x2c // 猜測是鎖導致，先把gsensor去掉看是否重啟 -> 去掉後正常 [ 121.642744] -(2)[816:system_server][<ffffffc000421284>] mc3xxx_suspend+0x8c/0xec [ 121.643096] -(2)[816:system_server][<ffffffc00086cfd8>] i2c_legacy_suspend+0x38/0x48 [ 121.643457] -(2)[816:system_server][<ffffffc00086f2a8>] i2c_device_pm_suspend+0x34/0x38 2. 由於是8.0臨時版本，未繼續深究 案例四 : 開機重啟 - 溫度檢測NTC電阻異常 現象 : 平臺 : androidL,MTK6580 排查過程: 1. 抓取串列埠log： [ 16.177681] <1>-(1)[345:thermal_manager]PC is at tspa_sysrst_set_cur_state+0x6c/0xd0 [ 16.178644] <1>-(1)[345:thermal_manager]LR is at mtk_cooling_wrapper_set_cur_state+0x190/0x4d0 // 呼叫蹤跡 - 根據“thermal_cdev_update” 推測是溫度檢測導致 [ 16.316470] <1>-(1)[345:thermal_manager][<c05a645c>] (tspa_sysrst_set_cur_state) from [<c059df54>] (mtk_cooling_wrapper_set_cur_state+0x190/0x4d0) [ 16.318097] r4:dcd28b80 r3:c05a645c [ 16.318554] <1>-(1)[345:thermal_manager][<c059ddc4>] (mtk_cooling_wrapper_set_cur_state) from [<c068a784>] (thermal_cdev_update+0xa0/0x18c) [ 16.320105] r10:dcdc4a18 r9:dcdc4b28 r8:c0dbcff8 r7:dcdc4b40 r6:dcdc4a00 r5:00000001 [ 16.321081] r4:dcdc4ae4 [ 16.321404] <1>-(1)[345:thermal_manager][<c068a6e4>] (thermal_cdev_update) from [<c068bca0>] (backward_compatible_throttle+0x94/0xbc) [ 16.322892] r10:00000048 r9:dc571a00 r8:00000001 r7:00000000 r6:00000000 r5:dc571b54 [ 16.323868] r4:dc9e6900 [ 16.324191] <1>-(1)[345:thermal_manager][<c068bc0c>] (backward_compatible_throttle) from [<c0689400>] (handle_thermal_trip+0x68/0x1e4) [ 16.325691] r9:c0d56530 r8:dc571a18 r7:00000000 r6:00000000 r5:00000000 r4:dc571a00 [ 16.326665] <1>-(1)[345:thermal_manager][<c0689398>] (handle_thermal_trip) from [<c06899c0>] (thermal_zone_device_update+0x9c/0x158) 2. kernel-3.18/drivers/misc/mediatek/thermal/common/thermal_zones/mtk_ts_pa.c static int tspa_sysrst_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state) { cl_dev_sysrst_state = state; if (cl_dev_sysrst_state == 1) { ... *(unsigned int *)0x0 = 0xdead; // 懷疑是這裡導致重啟，註釋掉本行 -> 不重啟 } 3. 開機後抓取mtklog中的kernel_log， 顯示溫度異常:125攝氏度(事實上問題沒這麼高) Line 18718: <7>[ 306.833625] (0)[57:kworker/0:1][name:mtk_ts_bts&][Power/BTS_Thermal] T_AP=125000 Line 18831: <7>[ 307.833641] (0)[57:kworker/0:1][name:mtk_ts_bts&][Power/BTS_Thermal] T_AP=125000 Line 18969: <7>[ 308.833733] (0)[57:kworker/0:1][name:mtk_ts_bts&][Power/BTS_Thermal] T_AP=125000 Line 19063: <7>[ 309.833632] (0)[57:kworker/0:1][name:mtk_ts_bts&][Power/BTS_Thermal] T_AP=125000 Line 19155: <7>[ 310.834030] (0)[57:kworker/0:1][name:mtk_ts_bts&][Power/BTS_Thermal] T_AP=125000 Line 19218: <7>[ 311.833597] (0)[57:kworker/0:1][name:mtk_ts_bts&][Power/BTS_Thermal] T_AP=125000 4. 懷疑是溫度檢測NTC電阻異常，經檢查，NTC電阻短路（焊錫過多） 處理方案: 總結 : 主機板上有多個NTC電阻檢測溫度(pa、電池等)，boot啟動會檢測溫度，過高則reboot 案例五 : 開機重啟 - 溫度檢測 現象 : 平臺 : androidN,MTK6737 排查過程: 1. 抓取串列埠log： [ 4.864498].(4)[68:bat_thread_kthr][Power/BatMeter] [force_get_tbat] 0,108,0,0,0,60 [ 4.865459].(4)[68:bat_thread_kthr][Power/BatMeter] [oam_run_inf] 4045, 4045, 4010, 2592, 2592, 135, 135, 2, 2, 1782, 60, 16 [ 4.866864].(4)[68:bat_thread_kthr][Power/BatMeter] [oam_result_inf] 16, 16, 16, 16, 16, 0 [ 4.867902].(4)[68:bat_thread_kthr][Power/Battery] AvgVbat=(4010),bat_vol=(4010),AvgI=(0),I=(0),VChr=(359),AvgT=(60),T=(60),pre_SOC=(84),SOC=(84),ZCV=(4044) [ 4.869657].(4)[68:bat_thread_kthr][Power/Battery] [Battery] Tbat(60)>=60, system need power down. [ 4.871358].(4)[68:bat_thread_kthr][Power/Battery] charging_set_power_off=0 [ 4.872229].(4)[68:bat_thread_kthr]mt_power_off 2. 根據log，關燈溫度過高保護，還是無法開機 kernel-3.18/drivers/power/mediatek/battery_common.c - if(BMT_status.temperature >= 60) + if(0) 3. 再次抓取串列埠log： [ 7.837171].(7)[191:thermal_manager]Power/battery_Thermal: reset, reset,[email protected]@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@*****************************************@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ [ 7.839444]-(7)[191:thermal_manager]------------[ cut here ]------------ [ 7.840299]-(7)[191:thermal_manager]kernel BUG at kernel/drivers/thermal/mtk_ts_battery.c:394! [ 7.842208]-(7)[191:thermal_manager]Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM 4. 臨時關閉檢測，可以開機 kernel-3.18/drivers/misc/mediatek/thermal/common/thermal_zones/mtk_ts_battery.c int mtktsbattery_register_cooler(void) { /* cooling devices */ - cl_dev_sysrst = mtk_thermal_cooling_device_register("mtktsbattery-sysrst", NULL, - &mtktsbattery_cooling_sysrst_ops); return 0; } 處理方案: 總結 : 案例六 : 開機休眠後重啟 - mxc400x_resume()死鎖引起 - 未深究 現象 : 平臺 : androidN,MTK6737 排查過程: 1. 檢視mtklog中的last_kmsg，可知由mxc400x_resume()函式中的死鎖導致 [ 194.487798] -(0)[719:system_server]PC is at __list_add+0x40/0xe0 [ 194.488102] -(0)[719:system_server]LR is at mutex_lock_nested+0x1ac/0x678 [ 194.639589] Backtrace: [ 194.640103] -(0)[719:system_server][<c04231e4>] (__list_add) from [<c0a6b2bc>] (mutex_lock_nested+0x1ac/0x678) [ 194.640325] r7:00000000 r6:c17b7668 r5:60070013 r4:c17b7664 [ 194.641259] -(0)[719:system_server][<c0a6b110>] (mutex_lock_nested) from [<c04e1d70>] (mxc400x_resume+0x28/0x64) [ 194.641488] r10:c1126378 r9:c0dda8d7 r8:00000010 r7:c0773000 [ 194.642407] -(0)[719:system_server][<c04e1d48>] (mxc400x_resume) from [<c0771654>] (i2c_legacy_resume+0x38/0x44) [ 194.642638] r5:c11b4164 r4:00000001 [ 194.643273] -(0)[719:system_server][<c077161c>] (i2c_legacy_resume) from [<c0773038>] (i2c_device_pm_resume+0x38/0x3c) [ 194.643664] -(0)[719:system_server][<c0773000>] (i2c_device_pm_resume) from [<c0476584>] (dpm_run_callback+0x120/0x234) [ 194.644051] -(0)[719:system_server][<c0476464>] (dpm_run_callback) from [<c0476a94>] (device_resume+0xb4/0x198) 2. 註釋掉mxc400x_resume()中的鎖-->不重啟 static int mxc400x_resume(struct i2c_client *client) { struct mxc400x_i2c_data *obj = i2c_get_clientdata(client); int err = 0; if(obj == NULL) { GSE_ERR("null mxc400x!!\n"); return -EINVAL; } - mutex_lock(&mxc400x_mutex); err = mxc400x_init_client(client, 0); if(err) { GSE_ERR("initialize client fail!!\n"); - mutex_unlock(&mxc400x_mutex); return -EINVAL; } atomic_set(&obj->suspend, 0); - mutex_unlock(&mxc400x_mutex); return err; } 處理方案: 總結 : 案例七 : dtsi裡缺少node，在preloader階段重啟 - 新增node 現象 : 屏不亮 平臺 : androidO,MTK6737 排查過程: 1. 列印串列埠log： [175] Copy DTB from 0x41f07086 to 0x4e000000(size: 0xb442) [176] [LK] fdt setup addr:0x4e000000 status:1!!! [176] [partition_get_index]find odmdtbo index 20 [178] Multiple ODM DTBO. [178] ODM mdtbo_index: 0, dtbo_offset: 1024, dtbo_size: 48768 [179] [partition_get_index]find odmdtbo index 20 ata start bit at rising edge [28] [SD0]e80 ERROR: ufdt_overlay_do_fixups():Couldn't find 'strobe' symbol in main dtb // 顯示缺少node"strobe" ERROR: ufdt_overlay_apply():failed to perform fixups in overlay [189] ufdt_apply_overlay() failed! [189] <ASSERT> app/mt_boot/mt_boot.c:line 407 0 ==> 在mt6735m.dts中新增node 2.還是重啟，再打log: [176] [LK] fdt setup addr:0x4e000000 status:1!!! [176] [partition_get_index]find odmdtbo index 20 [178] Multiple ODM DTBO. [179] ODM mdtbo_index: 0, dtbo_offset: 1024, dtbo_size: 48768 [179] [partition_get_index]find odmdtbo index 20 [182] blob_len: 0x80000, overlay_len: 0xbe80 ERROR: ufdt_overlay_do_fixups():Couldn't find 'leds' symbol in main dtb // 顯示缺少node"leds" ERROR: ufdt_overlay_apply():failed to perform fixups in overlay [189] ufdt_apply_overlay() failed! [190] <ASSERT> app/mt_boot/mt_boot.c:line 407 0 ==> 在mt6735m.dts中新增node 3. 不再重啟 4. 分析：由於在dts中引用了節點，追加屬性，以達到dts控制gpio口，preloader階段解析dtb的時候，就會出錯: &strobe { pinctrl-names = "default", "main_strobe_oh", "main_strobe_ol", "main_strobe_flash_oh", "main_strobe_flash_ol", "sub_strobe_oh", "sub_strobe_ol", "psel_pinctrl_oh", "psel_pinctrl_ol", "charger_enable_pinctrl_oh", "charger_enable_pinctrl_ol"; pinctrl-0 = <&strobe_intpin_default>; pinctrl-1 = <&main_strobe_oh>; pinctrl-2 = <&main_strobe_ol>; pinctrl-3 = <&main_strobe_flash_oh>; 5. 注：電池電量不足(電壓過低)，也會導致無法開機: [911] mtk detect 3130 [985] [AUXADC] ch=0 raw=18999 data=3130 [985] [mt65xx_bat_init] check VBAT=3130 mV with 3450 mV [986] [BATTERY] battery voltage(3130mV) <= CLV ! Can not Boot Linux Kernel !! 案例八 : 現象 : 平臺 : androidN,MTK6737 排查過程: 1. 2. 3. 4. 處理方案: 總結 : 案例九 : 現象 : 平臺 : androidN,MTK6737 排查過程: 1. 2. 3. 4. 處理方案: 總結 : 案例七 : 現象 : 平臺 : androidN,MTK6737 排查過程: 1. 2. 3. 4. 處理方案: 總結 : 案例七 : 現象 : 平臺 : androidN,MTK6737 排查過程: 1. 2. 3. 4. 處理方案: 總結 :
相關推薦
21. 重啟log分析
案例一 : kernel重啟 - mt6580.dtsi 現象 : 平臺 : androidN,MTK6580 排查過程: 1. 打串列埠log，發現如下： [ 1.607970] <2>.(2)[1:swapper/0]musb-hdrc
彈出SD卡導致的重啟問題分析
2018-10-10 在Android8.0上，安裝SD卡，設定為內部儲存，然後把安裝的應用move到SD卡上，開啟應用，然後在setting裡彈出（reject）SD卡，會發生重啟。 log 01-01 21:04:55.321858 1050 1081 D Pack
Android patch後重啟問題分析
在合入Android patch過程中會遇到Crash重啟的情況，在logcat日誌也只會列印一些崩潰的堆疊，這些資訊很難 幫助我們定位問題。 首先先看一下我遇到的一個logcat關於Crash的列印資訊： 如: 952 555
android展訊平臺 重啟案例分析（二）
./0000.log watchdog重啟 01-02 02:01:02.458 551 1010 W Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in monitor com.android.s
notification使用不當導致的宕機重啟問題分析（Could not copy bitmap to parcel blob. ）
前言 前段時間遇到了一個宕機重啟問題，比較複雜，涉及到多方面的知識，我也分析了很長的時間，期間學到了很多東西，現在把分析的過程整理一下，希望可以給大家一點幫助和啟發，同時也幫助自己再鞏固一下。 一、問題的復現 首先說一下問題最開始的分析思路以及復現的過程，log 中最核心的部
Android重啟原因分析
重啟原因分類 1.上層造成重啟 system_server被殺watchdog重啟重要執行緒阻塞2.kernel造成重啟 空指標非法地址3.kernel watchdog造成重啟，原因不確定 記憶體原因nand驅動log檢視步驟及關鍵字 1. 重啟後的kernel.log或
golang的facebookgo grace優雅重啟原理分析
從原理上來說是這樣一個過程： 1）釋出新的bin檔案去覆蓋老的bin檔案 2）傳送一個訊號量，告訴正在執行的程序，進行重啟 3）正在執行的程序收到訊號後，會以子程序的方式啟動新的bin檔案 4）新程序接受新請求，並處理 5）老程序不再
JNI引用溢位導致的重啟問題分析
問題描述 JNI全域性引用異常導致的重啟問題JNI ERROR (app bug): global reference table overflow (max=51200)' Log pid: 1279, tid: 2518, name: Binder:1279_9
Android 系統（74）--Android重啟原因分析
重啟原因分類1.上層造成重啟system_server被殺watchdog重啟重要執行緒阻塞2.kernel造成重啟空指標非法地址3.kernel watchdog造成重啟，原因不確定記憶體原因nand驅動log檢視步驟及關鍵字1. 重啟後的kernel.log或misc/cmdline.log在log最前面
Android 系統（126）---Android的宕機、重啟問題分析方法
Android的宕機、重啟問題分析方法當手機長時間無法再被使用者控制操作時，我們稱為宕機。在這裡我們強調長時間，如果是短時間，歸結為效能問題。* 使用者操作手機無任何響應，如觸控式螢幕幕，按鍵操作等。* 手機螢幕黑屏，無法點亮螢幕。* 手機介面顯示內容和使用者輸入不相干。1. 系統簡圖當用戶對手機進行操作時，
MySQL無限重啟原因分析
最近在CentOS配置LAMP環境，裝完MySQL執行/usr/local/mysql/bin/mysqld_safe --user=mysql &，MySQL無限重啟： “number of
android 重啟log
以下幾個地方會儲存一些 系統出錯log /proc/bootinfo: 最後一次開機/重啟原因 /proc/last_kmsg: 這個為什麼我這裡沒有呢？ /data/tombstones/: 每個native 程式 掛掉，這裡就會多一個檔案 /data/dontpani
重啟rsyslog服務時出現問題（誤刪/var/log/messages解決方案）
exc direct 解決 state track 出現 span article logging 今天修改了/etc/rsyslog.conf中的內容後，想著要通過systemctl restart rsyslog重啟服務，但是執行完命令後，總感覺/etc/rsyslo
1.報出問題： Please change caller according to com.intellij.openapi.project. IndexNotReadyException documentation 2.分析問題： 提示資訊，不影響編譯 3.解決方案： 重啟AS
1.報出問題： Please change caller according to com.intellij.openapi.project. IndexNotReadyException documentation 2.分析問題： 提示資訊，不影響編譯 3.解
Spring Developer Tools 原始碼分析：三、重啟自動配置'
接上文 Spring Developer Tools 原始碼分析：二、類路徑監控，接下來看看前面提到的這些類是如何配置，如何啟動的。 spring-boot-devtools 使用了 Spring Boot 的自動配置方式，我們先關注本地開發環境中自動重啟的部分。 在 LocalDevToolsAut
VS2012 啟動效能分析導致電腦重啟問題解決方法
貌似是隻有Intel 的 cpu會這樣。。一點啟動效能分析，電腦重啟。。。 解決方法，cmd執行，添加註冊表： reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Man
[Android][FWK]一個system_server 重啟的案例分析
android 8.1 上，報了一個手機重啟。 檢視android event log， 查詢關鍵字 am_crash, 發現問題出現的時間點上有個 NullPointerException 16:16:12.278 1000 3277 3456 I
故障分析：核心引數設定不當導致資料庫異常重啟
編輯手記：資料庫中每一個不起眼的引數，都有其內部的原理，不可隨意更改。今天分享一則因核心引數SEMOPM設定太小，加上在業務高併發時段LGWR寫入太慢，系統呼叫失敗，最終資料庫異常宕機的案例。 故障現象 資料庫CRASH，在CRASH前，ALERT中顯示如下的日誌內容 我們看到中間有27300和2
Linux關機重啟停機(shutdown reboot halt)流程分析
由於本人水平相當有限，不當之處還望大家多多指教。 涉及的核心原始碼，基於linux-3.10.102。 首先，對於使用者態發起的這類操作請求，最終都是通過sys_reboot系統呼叫（原始碼在kernel/sys.c）實現的。 其程式碼如下。如其註釋所言，他除了可以重啟關機
MySQL設定log-bin後伺服器重啟失敗的解決辦法和說明
問題描述： MySQL中二進位制日誌功能預設是關閉的，檢視各種開啟方式後，確定在配置檔案中加入如下配置來開啟該功能： [mysqld] log-bin=mysql 之後使用 “systemctl start mysql” 重啟伺服器，報錯“Job fo