上章链接入口: https://blog.csdn.net/qq_16933601/article/details/104327937 在上章里,我们分析了oops的PC值在哪个函数出错的
本文旨在介绍下几种常见的调试方法gdb、crash、kgdb and kdb 以及dynamic debug. 关于在 Linux 内核上使用debuggers,Linus Torvalds 长期以来对它们不太喜欢。简短地解释这种态度是,依赖调试器可能鼓励用权宜之计而非深思熟虑来解决问题,这会导致代码质量恶化。详细解释可以参考https://lwn.net/2000/0914/a/lt-debugger.php3
本文总结了通过分析ARM平台上的内核调试信息来定位程序错误的方法。首先介绍了调试信息和调试流程,然后详细描述了如何使用GDB来调试内核代码,包括设置断点、查看寄存器、分析堆栈信息等。最后,通过一个具体的例子来演示了如何使用GDB来调试内核程序,并分析了其中的错误和解决方法。
摘要总结:本文介绍了从驱动程序加载到内核的流程和原理,并通过实例详细阐述了驱动程序加载的具体过程、驱动程序与内核的交互以及驱动程序加载失败的原因和解决方法。
Android OS由3层组成,最底层是Kernel,上面是Native bin/lib,最上层是Java层:
图灵最先发明了栈,但没有给它取名字。德国人鲍尔也“发明”了栈,取名叫酒窖。澳大利亚人汉布林也“发明”了栈,取名叫弹夹。1959年,戴克斯特拉在度假时想到了Stack这个名字,后来被广泛使用。
廖威雄,就职于珠海全志科技股份有限公司,负责Linux IO全栈研发、性能优化、开源社区开发交流、Linux 内核开源社区pstore/blk,mtdpstore模块的作者、大客户存储技术支持、全志首个UBI存储方案主导人、全志首个RTOS NFTL主导人
我们在项目开发过程中,很多时候会出现由于某种原因经常会导致手机系统死机重启的情况(重启分Android重启跟kernel重启,而我们这里只讨论kernel重启也就是 kernel panic 的情况),死机重启基本算是影响最严重的系统问题了,有稳定复现的,也有概率出现的,解题难度也千差万别,出现问题后,通常我们会拿到类似这样的kernel log信息(下面log仅以调用BUG()为例,其它异常所致的死机log信息会有一些不同之处):
这里,你现在可以知道System.map文件是干什么用的了。 每当你编译一个新内核时,各种符号名的地址定会变化。 /proc/ksyms 是一个 "proc文件" 并且是在内核启动时创建的。实际上 它不是一个真实的文件;它只是内核数据的简单表示形式,呈现出象一个磁盘文件似 的。如果你不相信我,那么就试试找出/proc/ksyms的文件大小来。因此, 对于当前运行的内核来说,它总是正确的.. 然而,System.map却是文件系统上的一个真实文件。当你编译一个新内核时,你原 来的System.map中的符号信息就不正确了。随着每次内核的编译,就会产生一个新的 System.map文件,并且需要用该文件取代原来的文件。
操作系统堪称是IT皇冠上的明珠,Linux阅码场专注Linux操作系统内核研究, 它的文章云集了国内众多知名企业一线工程师的心得,畅销著作有《linux设备驱动开发详解 》等。
题目给了 bzImage,core.cpio,start.sh 以及 vmlinux 四个文件,接下来简单介绍一下。
本文主要服务于使用Tina软件平台的广大客户,帮助开发人员方便快速了解Tina平台系统调试工具。
适用范围: 本文适用于Tina3.5版本以上软件平台;对硬件环境没有要求,所有Allwinner硬件平台都适 用。 其中,注意linux-5.4内核上暂未支持pstore功能。
在工作中经常会遇到一些内核crash的情况,本文就是根据内核出现crash后的打印信息,对其进行了分析,使用的内核版本为:Linux2.6.32。
pstore文件系统(是的,这是个文件系统)是Persistent Storage的缩写,最早在2010年由 Tony Luck 设计并合入Linux主分支,设计的初衷是在内核Panic/Oops时能自动转存内核日志(log_buf),在Panic重启后,把转存的日志以文件形式呈现到用户空间以分析内核崩溃问题。
编写代码只是程序员的工作之一,调试代码的时间甚至会超过编写代码,之前为大家讲解了很多关于系统、架构、编程等方面的内容,这篇文章就为大家全方位展示一次涉及到内核的 bug 排查过程。
这里能够简要的告诉是什么问题触发了oops,显然是由于访问非法地址00000000异常。如果是由代码直接调用BUG()/BUG_ON()一类的,还能给出源代码中触发的行号。
内核的配置选项中包含了一些与内核调试相关的选项,都集中在”kernel hacking”菜单中。包括:
由于内核是一个不与特定进程相关的功能集合,所以内核代码无法轻易地放在调试器中执行,而且也很难跟踪跟踪,本章节将介绍监视内核代码并跟踪错误的技术。
在一个我们谈到了如何编写一个简单的字符设备驱动程序,我们不是神,编写肯定会失败的代码,在这个过程中,我们需要继续写代码调试。在普通c应用。我们经常使用printf输出信息。或者使用gdb要调试程序,然后司机如何调试它?的问题,在应用程序中执行这样的程序就会报segmentation fault的错误,而因为驱动程序的特殊性,出现此类情况后往往会直接造成系统宕机。并会抛出oops信息。那么我们怎样来分析oops信息呢,甚至依据oops信息来定位详细的出错的代码行呢?以下就依据一个简单的实例来说明怎样调试驱动程序。
我们对copy_{to,from}_user()接口的使用应该是再熟悉不过吧。基本Linux书籍都会介绍它的作用。毕竟它是kernel space和user space沟通的桥梁。所有的数据交互都应该使用类似这种接口。所以,我们没有理由不知道接口的作用。但是,我也曾经有过以下疑问。
转载请标明原址:linux驱动最新面试题(面试题整理,含答案)_不忘初心-CSDN博客_linux驱动面试题
方法一:最简单办法,看打印,通过反复调试,看是哪条语句造成造成了死机。这种方法效率低,而且有时不准确,比如一个系统中有多个进程,但A进程跑的B断点是,出现段错误,系统发出11号信号,造成B,C等进程接到11号信号反初始化而推出。实际当中可能不一定是A进程原因,因为此时B,C等进程也在并发执行,甚至A,B,c 三个进程都在访问某一共享资源(如共享内存等)。
现代处理器大部分都有MMU,除了一些小型嵌入式设备。MMU可以做虚拟地址到物理地址的转换,使用MMU我们就可以使用更多的内存空间,因为程序具有局部性原理,我们可以将暂时用不到的数据存放到磁盘,当访问到时会发生缺页中断,从磁盘中将所需要的数据加载到内存。所以我们可以通过mmu运行程序大小大于内存的程序和打开大于内存的文件。现代处理器通过分段分页机制实现虚拟地址到物理地址转换一般支持二级页表或四级页表。
Arm64有4种栈,分别是空增栈(Empty Ascendant Stack,EA)、空减栈(Empty Descendant Stack,ED)、满增栈(Full Ascendant Stack,FA)、满减栈(Full Descendant Stack,FD)。常用的是满减栈,Linux内核也使用满减栈。
KDUMP是Linux内核中的一项关键功能,用于在系统崩溃时生成内存转储(core dump)。这对于系统管理员和开发人员来说,分析和调试系统崩溃问题至关重要。本文将详细介绍KDUMP的工作原理、配置方法以及在实际操作中的应用。
来自Linus Torvalds的讨论: https://groups.google.com/group/linux.kernel/browse_thread/thread/b70bffe9015a8c41/ed9c0a0cfcd31111 又,http://kerneltrap.org/Linux/Further_Oops_Insights 例如这样的一个Oops: Oops: 0000 [#1] PREEMPT SMP Modules linked in: capidrv kernelcapi isdn slhc ipv6 loop dm_multipath snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd parport_pc floppy parport pcnet32 soundcore mii pcspkr snd_page_alloc ac i2c_piix4 i2c_core button power_supply sr_mod sg cdrom ata_piix libata dm_snapshot dm_zero dm_mirror dm_mod BusLogic sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd Pid: 1726, comm: kstopmachine Not tainted (2.6.24-rc3-module #2) EIP: 0060:[] EFLAGS: 00010092 CPU: 0 EIP is at list_del+0xa/0x61 EAX: e0c3cc04 EBX: 00000020 ECX: 0000000e EDX: dec62000 ESI: df6e8f08 EDI: 000006bf EBP: dec62fb4 ESP: dec62fa4 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process kstopmachine (pid: 1726, ti=dec62000 task=df8d2d40 task.ti=dec62000) Stack: 000006bf dec62fb4 c04276c7 00000020 dec62fbc c044ab4c dec62fd0 c045336c df6e8f08 c04532b4 00000000 dec62fe0 c043deb0 c043de75 00000000 00000000 c0405cdf df6e8eb4 00000000 00000000 00000000 00000000 00000000 Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9b/0xa3 [] show_registers+0xa3/0x1df [] die+0x11f/0x200 [] do_page_fault+0x533/0x61a [] error_code+0x72/0x78 [] __unlink_module+0xb/0xf [] do_stop+0xb8/0x108 [] kthread+0x3b/0x63 [] kernel_thread_helper+0x7/0x10 ======================= Code: 6b c0 e8
wq = create_singlethread_workqueue("mydrv");
在at91rm9200下写了一个spi的驱动,加载后,运行测试程序时,蹦出这么个吓人的东西: Unable to handle kernel paging request at virtual address 000e0000 pgd = c1f9c000 [000e0000] *pgd=20315801, *pmd = 20315801, *pte = 00000000, *ppte = 00000000 Internal error: Oops: 7 CPU: 0 pc : [] lr : [] Tainted: P sp : c1fa3f50 ip : 00000001 fp : c1fa3f78 r10: 401421e4 r9 : c1fa2000 r8 : bffffe1c r7 : 00000000 r6 : ffffffea r5 : c0282a20 r4 : 00000001 r3 : 00000000 r2 : 00000001 r1 : 000e0000 r0 : bffffe1c Flags: Nzcv IRQs on FIQs on Mode SVC_32 Segment user Control: C000317F Table: 21F9C000 DAC: 00000015 Process addrv_test (pid: 73, stack limit = 0xc1fa2374) Stack: (0xc1fa3f50 to 0xc1fa4000) 3f40: 00000001 00000001 c0282a20 ffffffea 3f60: 00000000 c34a61f4 00000001 c1fa3fa4 c1fa3f7c c0044040 c34a6194 c1fa3f88 3f80: c0043a18 4001d9cc bffffe54 00008330 00000003 c0017644 00000000 c1fa3fa8 3fa0: c00174a0 c0043f74 4001d9cc c001d5bc 00000003 bffffe1c 00000001 bffffe1c 3fc0: 4001d9cc bffffe54 00008330 4000c85c 00000001 000084d4 401421e4 bffffe34 3fe0: 400e40d0 bffffe1c 0000856c 400e40d4 60000010 00000003 00000000 20000040 Backtrace: Function entered at [] from [] r4 = 00000001 Function entered at [] from [] r8 = C0017644 r7 = 00000003 r6 = 00008330 r5 = BFFFFE54 r4 = 4001D9CC
在原来配置的基础上,make menuconfig选中如下选项重新配置Linux,使之携带调试信息
就是这样一个常见的问题,面试过的大部分同学都未能很好地回答,这里希望能够做很彻底地解答。
科技圈今天炸裂!Phoronix 报道了一个诡异的 Linux 内核崩溃错误,而罪魁祸首竟然是罗技鼠标的 USB 接收器!接下来我们一起看看这个奇葩的 bug。罗技鼠标USB接收器如下图所示:
内核稳定性问题复杂多样,最常见的莫过于“kernel panic”,意为“内核恐慌,不知所措”。这种情况下系统自然无法正常运转,只能自我结束生命,留下死亡信息。诸如:
上一篇我们大概聊了如何写一个简单的字符设备驱动,我们不是神,写代码肯定会出现问题,我们需要在编写代码的过程中不断调试。在普通的c应用程序中,我们经常使用printf来输出信息,或者使用gdb来调试程序,那么驱动程序如何调试呢?我们知道在调试程序时经常遇到的问题就是野指针或者数组越界带来的问题,在应用程序中运行这种程序就会报segmentation fault的错误,而由于驱动程序的特殊性,出现此类情况后往往会直接造成系统宕机,并会抛出oops信息。那么我们如何来分析oops信息呢,甚至根据oops信息来定位
垃圾回收机制最早诞生于Lisp编程语言,但Lisp的作者McCathy在第一次现场演示Lisp时却因中途耗尽全部32KB内存以及一些其他原因只能草草收场。60年后的今天,垃圾回收技术再也不是一个笑话,它俨然成为诸如Java、C#、Python、Erlang、Golang编程语言的核心组件。
网上很多人提问为什么一定要copy_from_user,也有人解答。比如百度一下:
本文以Linux3.14版本源码为例分析其启动流程。各版本启动代码略有不同,但核心流程与思想万变不离其宗。
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/huangweiqing80/article/details/83088465
crash 是目前广泛使用的 linux 内核崩溃转储文件的分析工具,掌握 crash 的使用技巧,对于分析定位内核崩溃的问题,有着非常重要的作用。本文首先介绍了 crash 的基本概念和安装方法,其次详细介绍了如何使用 crash 工具分析内核崩溃转储文件,包括各种常用调试命令的使用方法,最后以几个实际工作中遇到的真实案例向读者展示了 crash 的强大功能。在这篇文章中,既有详细的工具使用方法,又有丰富的实际案例分析,相信您读过以后定会受益匪浅。
有客户反馈机器频繁出现重启,查看每次的堆栈都是virtio_check_driver_offered_feature访问非法地址的gpf报错,比较像是某个内核bug导致。
有客户机器频繁出现重启,查看每次的堆栈都是virtio_check_driver_offered_feature访问非法地址的gpf报错,比较像是某个内核bug导致。
本节我们将从linux启动的第一个进程说起,以及后面第一个进程是如何启动1号进程,然后启动2号进程。然后系统中所有的进程关系图做个简单的介绍
[1] ES Configuration: https://www.elastic.co/guide/en/elasticsearch/reference/2.1/setup-configuration.html#vm-max-map-count [2] root cause kernel soft lockups · Issue #37853 · kubernetes/kubernetes (github.com): https://github.com/kubernetes/kubernetes/issues/37853 [3] service-node-port-range and ip_local_port_range collision · Issue #6342 · kubernetes/kops (github.com): https://github.com/kubernetes/kops/issues/6342 [4] Image: We should tweak our sysctls · Issue #261 · kubernetes-retired/kube-deploy (github.com): https://github.com/kubernetes-retired/kube-deploy/issues/261 [5] Upgrading docker 1.13 on nodes causes outbound container traffic to stop working · Issue #40182 · kubernetes/kubernetes (github.com): https://github.com/kubernetes/kubernetes/issues/40182 [6] arp_cache: neighbor table overflow! · Issue #4533 · kubernetes/kops (github.com): https://github.com/kubernetes/kops/issues/4533
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
解决每一类问题都需要消耗大量的时间,特别是重新编译内核这种事情。于是,每一个Linux内核程序员或多或少都会掌握一些Hack技巧,以节省时间提高工作效率。
前言: GuestOS中如果发生了一些错误,GuestOS还活着,shell已经hung住了,如何获取到GuestOS中的关键log信息呢? 分析: 1,keyboard interrupt QE
在内核开发这块,基本工作都是:打补丁,调补丁,调bug。最耗神的就是调bug,调bug的过程最花时间的一步是定位问题,基本上只要定位到问题,解决起来就容易些了(目前我遇到的bug大部分是这样)。所以调试方法很重要,接下来就分享一点如何快速定位并解决bug的一丢丢小经验。抛砖引玉,大佬们见笑。
领取专属 10元无门槛券
手把手带您无忧上云