linux kill不能杀死shell脚本死循环？

使用ps aux|grep ”脚本名“这种方式查找时，查看grep ”脚本“以外行的PID。

ps -ef 能比较直观显示进程PID、PPID（当前PID的父进程），程序名（最后一列）。注意：你杀的应该是运行脚本时命令对应的PID，不是脚本里启动的额外程序的PID，否则可能产生僵死进程。

怎样将BIOS清零？

逻辑锁不是因为执行了MBR里的代码，是因为扩展分区表（注意是扩展分区表，不是MBR，每个逻辑分区前都有一个扩展分区表，结构和MBR类似）的链式结构被弄成了一个环，然后磁盘驱动在探测分区的时候就死循环了……开机的时候总是要自动探测一下分区的，就是这个时候会掉到死循环的坑里面去。

网上也不是搜不到解决办法，据说Linux系统就不会被逻辑锁卡住，进去后用dd命令把MBR清零（这一步也有点危险，千万别打错），然后再用DiskGenius、Testdisk之类软件扫描分区重建分区表就好。

线程进入阻塞时，线程会不会让出CPU？

那要看操作系统context switch的机制。一般windows linux ios都会给定每个线程指定的执行时间，如果时间到了会出现计时器中断信号（timer interrupt signal），而线程会被动丢失CPU的使用权。

而有些简单的嵌入式系统没有这个机制，context switch一般是要求线程主动放弃CPU使用权而交给kernel。

如果这时候当前线程被阻塞那就会导致死循环，这时候要主动的叫reschedule 或者 yield等函数给kernel发信号。

当然有timer的系统也可以叫这些函数要当前线程提早主动放弃CPU资源从而避免在循环里等待浪费时间。

linux程序systemcpu占用较高说明什么问题？

这说明你的程序在执行过程中，有如下几种情况中的一种或者多种情况发生：

1. 进入了一个死循环无法跳出来；

2. 也许是一直在等待一个信号，如从dbus上读取一个你需要的信息；

3. 有可能是你的程序在对一个非常大的内容进行分析和处理；

4. 有可能是你的程序要处理的问题比较多，所以在一个个慢慢的执行。大部分是由上面四种情况引起的，在这四种情况中，第一种情况坚决要避免，因为不如此，那么你的CPU资源将会被吃光。

第二种情况，我的想法是，你要修改一下，看看有没有什么更快，更高效的方法来获取到需要的信号，或者是不去获取信号，而是改用其他方式来处理。

第三和第四两种情况，就要根据你的实际需要来定了。如果是必须这样做，那么也只能够耐心的等待了。但是可以考虑优化代码，优化算法的方式来提高效率。Linux系统下有个很好的调试工具gdb。如果不知道自己的程序出现了什么问题，可以利用gdb工具逐步执行，去查找错误所在。