linux 内核错误

在centOS上利用makebzImage编译内核出错，config文件用的是centos自带的/boot/config-2.6.32-358.el6.i686文件，无论是编译2.6.32.67，还是3.2.71版本，都出现如下的错误：make[4]:***没有规则可以创建“/home/dadi/test/linux-3.2.71/usr/include/lin

作为高性能WEB服务器，只调整Nginx本身的参数是不行的，因为Nginx服务依赖于高性能的 *** 作系统。

以下为常见的几个Linux内核参数优化方法。

net.ipv4.tcp_max_tw_buckets

对于tcp连接，服务端和客户端通信完后状态变为timewait，假如某台服务器非常忙，连接数特别多的话，那么这个timewait数量就会越来越大。

毕竟它也是会占用一定的资源，所以应该有一个最大值，当超过这个值，系统就会删除最早的连接，这样始终保持在一个数量级。

这个数值就是由net.ipv4.tcp_max_tw_buckets这个参数来决定的。

CentOS7系统，你可以使用sysctl -a |grep tw_buckets来查看它的值，默认为32768，

你可以适当把它调低，比如调整到8000，毕竟这个状态的连接太多也是会消耗资源的。

但你不要把它调到几十、几百这样，因为这种状态的tcp连接也是有用的，

如果同样的客户端再次和服务端通信，就不用再次建立新的连接了，用这个旧的通道，省时省力。

net.ipv4.tcp_tw_recycle = 1

该参数的作用是快速回收timewait状态的连接。上面虽然提到系统会自动删除掉timewait状态的连接，但如果把这样的连接重新利用起来岂不是更好。

所以该参数设置为1就可以让timewait状态的连接快速回收，它需要和下面的参数配合一起使用。

net.ipv4.tcp_tw_reuse = 1

该参数设置为1，将timewait状态的连接重新用于新的TCP连接，要结合上面的参数一起使用。

net.ipv4.tcp_syncookies = 1

tcp三次握手中，客户端向服务端发起syn请求，服务端收到后，也会向客户端发起syn请求同时连带ack确认，

假如客户端发送请求后直接断开和服务端的连接，不接收服务端发起的这个请求，服务端会重试多次，

这个重试的过程会持续一段时间（通常高于30s），当这种状态的连接数量非常大时，服务器会消耗很大的资源，从而造成瘫痪，

正常的连接进不来，这种恶意的半连接行为其实叫做syn flood攻击。

设置为1，是开启SYN Cookies，开启后可以避免发生上述的syn flood攻击。

开启该参数后，服务端接收客户端的ack后，再向客户端发送ack+syn之前会要求client在短时间内回应一个序号，

如果客户端不能提供序号或者提供的序号不对则认为该客户端不合法，于是不会发ack+syn给客户端，更涉及不到重试。

net.ipv4.tcp_max_syn_backlog

该参数定义系统能接受的最大半连接状态的tcp连接数。客户端向服务端发送了syn包，服务端收到后，会记录一下，

该参数决定最多能记录几个这样的连接。在CentOS7，默认是256，当有syn flood攻击时，这个数值太小则很容易导致服务器瘫痪，

实际上此时服务器并没有消耗太多资源（cpu、内存等），所以可以适当调大它，比如调整到30000。

net.ipv4.tcp_syn_retries

该参数适用于客户端，它定义发起syn的最大重试次数，默认为6，建议改为2。

net.ipv4.tcp_synack_retries

该参数适用于服务端，它定义发起syn+ack的最大重试次数，默认为5，建议改为2，可以适当预防syn flood攻击。

net.ipv4.ip_local_port_range

该参数定义端口范围，系统默认保留端口为1024及以下，以上部分为自定义端口。这个参数适用于客户端，

当客户端和服务端建立连接时，比如说访问服务端的80端口，客户端随机开启了一个端口和服务端发起连接，

这个参数定义随机端口的范围。默认为32768 61000，建议调整为1025 61000。

net.ipv4.tcp_fin_timeout

tcp连接的状态中，客户端上有一个是FIN-WAIT-2状态，它是状态变迁为timewait前一个状态。

该参数定义不属于任何进程的该连接状态的超时时间，默认值为60，建议调整为6。

net.ipv4.tcp_keepalive_time

tcp连接状态里，有一个是established状态，只有在这个状态下，客户端和服务端才能通信。正常情况下，当通信完毕，

客户端或服务端会告诉对方要关闭连接，此时状态就会变为timewait，如果客户端没有告诉服务端，

并且服务端也没有告诉客户端关闭的话（例如，客户端那边断网了），此时需要该参数来判定。

比如客户端已经断网了，但服务端上本次连接的状态依然是established，服务端为了确认客户端是否断网，

就需要每隔一段时间去发一个探测包去确认一下看看对方是否在线。这个时间就由该参数决定。它的默认值为7200秒，建议设置为30秒。

net.ipv4.tcp_keepalive_intvl

该参数和上面的参数是一起的，服务端在规定时间内发起了探测，查看客户端是否在线，如果客户端并没有确认，

此时服务端还不能认定为对方不在线，而是要尝试多次。该参数定义重新发送探测的时间，即第一次发现对方有问题后，过多久再次发起探测。

默认值为75秒，可以改为3秒。

net.ipv4.tcp_keepalive_probes

第10和第11个参数规定了何时发起探测和探测失败后再过多久再发起探测，但并没有定义一共探测几次才算结束。

该参数定义发起探测的包的数量。默认为9，建议设置2。

设置和范例

在Linux下调整内核参数，可以直接编辑配置文件/etc/sysctl.conf，然后执行sysctl -p命令生效。

第一次把自己编译的驱动模块加载进开发板，就出现问题，还好没花费多长时间，下面列举出现的问题及解决方案

1：出现insmod: error inserting 'hello.ko': -1 Invalid module format

法一（网上的）：是因为内核模块生成的环境与运行的环境不一致，用linux-2.6.27内核源代码生成的模块，可能就不能在linux-2.6.32.2内核的linux环境下加载，需要在linux-2.6.27内核的linux环境下加载。

a.执行 uname -r //查看内核版本

b.一般出错信息被记录在文件/var/log/messages中，执行下面命令看错误信息

# cat /var/log/messages |tail

若出现类似下面：

Jun 4 22:07:54 localhost kernel:hello: version magic '2.6.35.6-45.fc14.i686.PAE

' should be '2.6.35.13-92.fc14.i686.PAE'

则把 Makefile里的KDIR ：=/lib/modules/2.6.35.6-45.fc14.i686.PAE/build1 改为

KDIR :=/lib/modules/2.6.35.13-92.fc14.i686.PAE/build1 //改成自己内核源码路径

（这里的build1是一个文件链接，链接到/usr/src/kernels/2.6.35.6-45.fc14.i686.PAE和13-92的）

然并卵，我的fedora 14 /usr/src/kernels下并没有2.6.35.13-92.fc14.i686.PAE，只有2.6.35.13-92.fc14.i686，虽然不知道两者有什么区别，但改成2.6.35.13-92.fc14.i686还是不行，照样这个问题，还好后来在看教学视频的到启发

法二：改的还是那个位置

KDIR ：=/opt/FriendlyARM/linux-2.6.32.2 //把这里改成你编译生成kernel的那个路径

all:

$ (MAKE) -C $ (KDIR) M = $ (PWD) modules ARCH=arm CROSS_COMPILE=arm-linux- //加这句

2. [70685.298483] hello: module license 'unspecified' taints kernel.

[70685.298673] Disabling lock debugging due to kernel taint

方法：在模块程序中加入： MODULE_LICENSE("GPL")

3. rmmod: chdir(2.6.32.2-FriendlyARM): No such file or directory 错误解决

方法：lsmod 可查看模块信息

即无法删除对应的模块。

就是必须在/lib/modules下建立错误提示的对应的目录（(2.6.32.2）即可。

必须创建/lib/modules/2.6.32.2这样一个空目录,否则不能卸载ko模块.

# rmmod nls_cp936

rmmod: chdir(/lib/modules): No such file or directory

但是这样倒是可以卸载nls_cp936,不过会一直有这样一个提示：

rmmod: module 'nls_cp936' not found

初步发现,原来这是编译kernel时使用make modules_install生成的一个目录,

但是经测试得知，rmmod: module 'nls_cp936' not found来自于busybox,并不是来自kernel

1).创建/lib/modules/2.6.32.2空目录

2).使用如下源码生成rmmod命令,就可以没有任何提示的卸载ko模块了[luther.gliethttp]

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <fcntl.h>

#include <string.h>

#include <errno.h>

int main(int argc, char *argv[])

{

const char *modname = argv[1]

int ret = -1

int maxtry = 10

while (maxtry-- >0) {

ret = delete_module(modname, O_NONBLOCK | O_EXCL)//系统调用sys_delete_module

if (ret <0 &&errno == EAGAIN)

usleep(500000)

else

break

}

if (ret != 0)

printf("Unable to unload driver module \"%s\": %s\n",

modname, strerror(errno))

}

3).把生成的命令复制到文件系统

# arm-linux-gcc -static -o rmmod rmmod.c

# arm-linux-strip -s rmmod

# cp rmmod /nfs/

cp /nfs/rmmod /sbin

代码如下：

proc.c

[html] view plain copy

<span style="font-size:18px">#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/init.h>

#include <linux/proc_fs.h>/* Necessary because we use the proc fs */

#define procfs_name "proctest"

MODULE_LICENSE("GPL")

struct proc_dir_entry *Our_Proc_File

int procfile_read(char *buffer,char **buffer_location,off_t offset, int buffer_length, int *eof, void *data)

{int ret

ret = sprintf(buffer, "HelloWorld!\n")

return ret

}

int proc_init()

{Our_Proc_File = create_proc_entry(procfs_name, 0644, NULL)

if (Our_Proc_File == NULL) {

remove_proc_entry(procfs_name, NULL)

printk(KERN_ALERT "Error: Could not initialize /proc/%s\n",procfs_name)

return -ENOMEM }

Our_Proc_File->read_proc = procfile_read//

// Our_Proc_File->owner = THIS_MODULE

Our_Proc_File->mode = S_IFREG | S_IRUGO

Our_Proc_File->uid = 0

Our_Proc_File->gid = 0

Our_Proc_File->size = 37

printk("/proc/%s created\n", procfs_name)

return 0

}

void proc_exit()

{remove_proc_entry(procfs_name, NULL)

printk(KERN_INFO "/proc/%s removed\n", procfs_name)

}

module_init(proc_init)

module_exit(proc_exit)</span></span></span></span></span>

[html] view plain copy

<span style="font-size:18px">

ifneq ($(KERNELRELEASE),)

obj-m :=proc.o

else

KDIR :=/opt/FriendlyARM/linux-2.6.32.2

#KDIR :=/lib/modules/2.6.35.13-92.fc14.i686.PAE/build1

PWD :=$(shell pwd)

all:

$(MAKE) -C $(KDIR) M=$(PWD) modules ARCH=arm CROSS_COMPILE=arm-linux-

clean:

rm -f *.ko *.o *.mod.o *.mod.c *.symvers

endif</span></span></span></span></span>

make后生成proc.ko，再在开发板上insmod proc.ko即可

执行 dmesg 就可以看到 产生的内核信息啦

---