0.环境:arm CPU 带有IIC控制器作为slave端,带有调试串口. 1.bug表现:IIC slave 在系统启动后概率挂死,导致master无法detect到slave. 猜测1:认为IIC device程序有问题 检查1:查看程序发现有可能溢出的部分,使用IIC 工具刷过量数据到slave,未出问题. 猜测2:认为IIC device寄存器进入异常状态未能恢复 检查2:检查正常IIC寄存器和异常状态IIC寄存器,未能发现问题. 猜测3:时钟分频问题 检查3:询问同事,答固定分频. 猜

转自:https://blog.csdn.net/winitz/article/details/72460775 版权声明:本文为博主原创文章,未经博主允许不得转载. https://blog.csdn.net/winitz/article/details/72460775问题调试中遇到过这样一个问题,主芯片访问外部I2C设备时,市场出现I2C读写time out,而且一旦出现这个问题后,I2C访问会一直失败. 现象1) 从log看,第一次出现time out是在发送end命令时,之后一直访问失

STM32的IIC问题一直存在,在网上也被很多人吐槽,然而FAE告诉我,硬件IIC的问题在F1,F3,F4系列单片机存在,而在L0上已经解决了,然而这几天调试加密芯片和显示芯片,都是IIC芯片,却再一次证明,L0系列的IIC一样存在问题, FAE告诉我是我的配置问题,故写这篇文章,如果是我配置问题,希望得到高人指点,再次感激不尽. 配置代码: void MX_I2C1_Init(void) { hi2c1.Instance = I2C1; hi2c1.Init.Timing = 0x00707C

1. 环境: ubuntu 系统 + strace + vim 2.编写挂死程序:(参考博客) #include <stdio.h> #include <sys/types.h> #include <unistd.h> #include <string.h> int main(int argc, char** argv) { getpid(); if(argc < 2) { printf("pick one (user|system)\n&q

摘要:本次分享的是一次关于 MySQL 高可用问题的定位过程,其中曲折颇多但问题本身却比较有些代表性,遂将其记录以供参考. 一.背景 近期由测试反馈的问题有点多,其中关于系统可靠性测试提出的问题令人感到头疼,一来这类问题有时候属于"偶发"现象,难以在环境上快速复现:二来则是可靠性问题的定位链条有时候变得很长,极端情况下可能要从 A 服务追踪到 Z 服务,或者是从应用代码追溯到硬件层面. 本次分享的是一次关于 MySQL 高可用问题的定位过程,其中曲折颇多但问题本身却比较有些代表性,遂将

声明:本文为博主原创文章,由于已授权部分平台发表该文章(知乎.云社区),可能造成发布时间方面的困扰. 一.背景 近期由测试反馈的问题有点多,其中关于系统可靠性测试提出的问题令人感到头疼,一来这类问题有时候属于"偶发"现象,难以在环境上快速复现:二来则是可靠性问题的定位链条有时候变得很长,极端情况下可能要从 A 服务追踪到 Z 服务,或者是从应用代码追溯到硬件层面. 本次分享的是一次关于 MySQL 高可用问题的定位过程,其中曲折颇多但问题本身却比较有些代表性,遂将其记录以供参考. 架构

工具出现挂死问题 1.问题描述 工具出现挂死问题,巡检IIS发现以下异常日志 现网系统日志: 事件类型:    错误 事件来源:    .NET Runtime 描述: Application: DiyRingSet30Tool.exe Framework Version: v4.0.30319 Description: The process was terminated due to an internal error in the .NET Runtime at IP 791F7E06 (

这两天为了定位JBOSS老是挂死的问题,学习了一下JAVA多线程方面的知识,在此总结一下 1.在Java程序中,JVM负责线程的调度.线程调度是指按照特定的机制为多个线程分配CPU的使用权. 调度的模式有两种:分时调度和抢占式调度.分时调度是所有线程轮流获得CPU使用权,并平均分配每个线程占用CPU的时间:抢占式调度是根据线程的优先级别来获取CPU的使用权.JVM的线程调度模式采用了抢占式模式. 2.Thread类实际上也是实现了Runnable接口的类. 在启动的多线程的时候,需要先通过Thr

方法1: 使用root用户:Oracle@NDMCDB05:~> su -Password: NDMCDB05:~ # cat /etc/mtab /dev/sda2 / reiserfs rw,acl,user_xattr 0 0proc /proc proc rw 0 0sysfs /sys sysfs rw 0 0debugfs /sys/kernel/debug debugfs rw 0 0udev /dev tmpfs rw 0 0devpts /dev/pts devpts rw,m

只做工作总结备忘之用. 正在烧镜像,稍总结一下进来改bug遇到的问题. 一个项目里要用到L3 switch的nat,vrrp功能,但实地测试中偶然出现write file挂死的情况,但不是必现.交付在即,于是加调试信息,反复跑配置的脚本,定位bug. 一,期初怀疑是vtysh与vrrpd进程通信出现阻塞(现象即是系统挂死). (1)因为在跑配置脚本时,出现了enable命令也挂死的情况,所以这么怀疑: (2)在vrrpd与vtysh命令传输的关键点加打印信息(注意vrrpd不要-d daemon

在实际的情况下,有时候会遇到设备无故重启的问题,这个时候,我们需要判断一下重启的根本原因是什么,是否有规避的方法等. 这里记录了几个N3K异常重启的问题. 案例1: 设备型号:N3K-C3048TP-1GE OS版本:6.0(2)U4(4) 阶段1:采集信息.我们需要采集的信息如下: 1.收集core文件 N3K# show core 2.收集tech文件 #tac-pac bootflash: 如此会在bootflash自动创建一个名为“show_tech_out.gz”的文件,然后可以通过f

一:背景 1. 讲故事 这几天看的 dump 有点多,有点伤神伤脑,晚上做梦都是dump,今天早上头晕晕的到公司就听到背后同事抱怨他负责的WPF程序挂死了,然后测试的小姑娘也跟着抱怨...嗨,也不知道是哪一个迭代改出来的问题,反正客户不起义问题都不大. 不过我听到程序无响应,内心深处真的是一拘灵...本能反应吧,给他发了一个 procdump 过去生成两个 dump 发过来. 话说回来,WPF这种带UI界面的挂死问题其实很好分析的,无非就是 UI线程 失去响应了,至于为啥失去响应了,肯定是做了什

原文的帖子无法访问,我只能粘贴内容 近期将之前的一个用Kubernetes 1.3.7的环境更换为最新发布的用kubeadm安装的Kubernetes 1.6.4 Dashboard无法访问的问题>一文中,我们通过把用户admin bind到cluster-admin这个clusterrole角色上使得dashboard得以正常访问.但访问几次后,我发现了一个问题:那就是用safari访问dashboard时,浏览器可以正常弹出鉴权对话框,让我输入用户名和密码:但用chrome访问时,总是无法弹

下面蓝队网络为大家介绍下windows server 2008 如何查看异常重启日志 开始->管理工具->时间查看器 windows日志->系统 筛选当前日志 选择Kernel-Powder 选?41 http://www.landui.com/help/show-2761.html

Redis实现了主从同步,但是主库挂死了,如何处理 方案:切换主库的身份 # 连接从库 [root@localhost redis-]# redis-cli -p # 取消从库身份 > slaveof no one # 连接从库 [root@localhost redis-]# redis-cli -p # 重新设置从库 > slaveof 切换完成!

问题描述:Linux VM异常重启,需要排查问题原因 排查结果: 查询Messages日志获取到的信息 虚拟机内核版本: Jun :: test01 kernel: Linux version -.el6.x86_64 (mockbuild@worker1.bsys.centos.org) ( (Red Hat -) (GCC) ) # SMP Tue May :: UTC 查看到虚拟机重启时间约为:2019/6/20 03:34 CST Jun :: test01 kernel: hv_uti

一:背景 1. 讲故事 上个月有位朋友加wx告知他的程序有挂死现象,询问如何进一步分析,截图如下: 看这位朋友还是有一定的分析基础,可能玩的少,缺乏一定的分析经验,当我简单分析之后,我发现这个dump挺有意思的, CPU,内存,挂死 三样全占,程序悲惨莫过于此... 既然找到我,我得想办法化解他的痛苦,由易到难我们逐一分析这三样都是因为什么原因所致? 二:三高分析 1. 挂死原因 根据 40+ 的dump分析经验,挂死大多是由于某种情况导致线程卡死,导致后续请求堆积在 threadpool 中,

一:背景 1. 讲故事 这个月中旬,有位朋友加我wx求助他的程序线程占有率很高,寻求如何解决,截图如下: 说实话,和不同行业的程序员聊天还是蛮有意思的,广交朋友,也能扩大自己的圈子,朋友说他因为这个bug还导致项目黄了一个... 哈哈,看样子是客户不买账,验收不了,害...早找到我,这客户不就捞回来啦,这也许就是技术的价值吧! 既然找到我,那就让这个挂死问题彻底消失吧,上windbg说话. 二:Windbg 分析 1. 查看线程情况 既然朋友说线程高,那就从线程入手,用 !t 命令即可. 0:0

前提背景: 生产环境上,服务器网络突然断链,ssh连接失败. 问题初步定位: 查找内核日志,得到网卡异常信息 Jan 24 11:52:43 localhost kernel: ixgbe 0000:84:00.0: eth0: RXDCTL.ENABLE on Rx queue 14 not cleared within the polling period Jan 24 11:52:43 localhost kernel: ixgbe 0000:84:00.0: eth0: RXDCTL.E

今天,在某个演示环境中,我们的产品经历过整个机房断电后,出现了mongodb二进制文件损坏,以下是故障的分析记录过程: 1.在客户处支撑的同事发现整个机房断电再恢复后,3个mongodb复制集中,有1个主机上的mongodb服务状态报错 2.登录后台发现复制集中每个mongodb主机上,mongod进程都在 3.在服务状态好着的mongodb主机上,通过mongo登录数据库,查询复制集状态,发现复制集状态正常,1个primary+2个secondary,并且optimeDate时间一致. 这个时