竟然接连两次死机,请看屏幕记录

gydoesit

接连两次死机,请看屏幕记录

一台普通pc拿来当服务器,c1.2/815ept/384M/20G/8139网卡,操作系统是Fedora core 3.在电信机房,1月初放入,为一台私服提供NAT服务,相当

于一个简单的防火墙.在5月,提供web服务.
6月时,关机升级内存,原来只有128M,增加一条256M,共384M.一直没出过什么问题.但是,8月6日早上9点左右,服务器死机.去机房看,屏幕上满屏E

文,都是些难以理解的字串之类.键盘无响应.关机打开机箱,看cpu风扇正常.只好重启使用.结果8月8日早上2点,又不能访问服务器了,想来又是

死机了.这次怀疑是否风扇有问题,cpu热了?早上去看,果然死机,屏幕上依然是难懂的字幸好我早有准备,用笔抄下来了.没办法,

在/var/log/messages中根本没有记录,应该是那时I/O已经失效.然后关机,摸cpu温度低着哩.只好把内存取下来清理下,又插上.
记得在另一个地方当网关的一台fedora core 3也出现过类似问题.另外,在一个网吧的fedora core 3因为作了线路自动切换,出过几次不能加载

iptables模块情况.所以有些怀疑是OS不稳定.我在其他地方使用的redhat9似乎没出过,当然也可能是没给我反映,自己去启动了.

现在把屏幕上的记录发上来,大家分析下.第一行的www login中,www是我主机名.另外,上次的死机和这次的屏幕不同,但类似,反正都不是一下看

出原因那种.

www login:Unable to handle kernel NULL pointer dereference
at virtual address 00000050
printing eip:
022ce189
*pde = 00000000
Oops:0000[#1]
Modules linked in:ipt_state ipt_multiport ipt_limit
iptable_nat ip_conntrack iptable_filter ip_tables md5 ipv6
dm_mod button battery ac uhci_hcd hw_random 8139too mii
floppy ext3 jbd
EIP: 0060: [<022ce1897>;] Not tainted VLI
EFLAGS: 00010246 (2.6.9-1.667)
EIP is at tcp_time_to_recover+0x73/0x17+
eax:080930a3 abx:0dca3ce8 ecx:00000001 edx:00000000
esi:00000001 edi:0dca3a80 ebp:00000000 esp:023d4df4
ds:007b es:007b ss:0068
Process mysqld (pid:20866,threadinfo=023d4000 task=14cd79d0)
Stack:032331cb 0dca3ce8 ee2331cb 0dca3a80 00000000 022cefbb 032a4adg 00000000
      0000010e 00000003 ee233162 0dca3ce8 00000002 0000010e 022cefbb 032a4adg
      0000010e 0000000c 00000003 ee233162 0dca3a80 00001e56 00000001 0dca3ce8
Call Trace:
Stack pointer is garbage,not printing trace
Code:Bad EIP value
<0>;Kernel panic - not syncing:Fatal exception in interrupt

惠繪洋

看上去是內核出現錯誤引致系統掛掉的呢....

1. 
   
2. at virtual address 00000050
   
3. printing eip:
   
4. 022ce189
   
5. *pde = 00000000
   
6. Oops:0000[#1]
   

复制代码

在你未加那條256mb時, 出現過這問題嗎. 或可以你試試把那條256bm取下, 等系統行多一天半天, 再觀查情況, 可能是ram的問題...

gydoesit

这个?内存不够用呀,不敢吧(要不只上256,好象还可以考虑.

惠繪洋

你現在是在測試階段中, 要清楚知道是什麼問題, 是系統還是硬件問題? 128mb無錯是較少, 若你拿下那條256mb, 若系統能正常運行, 沒有再出現那當機情況那麼, 很大機會是那條256mb不相容了... 若換了128mb, 或256mb, 當機情況都會出現, 那就會是軟件問題了. 若現在不找出問題, 日後你的服務器想穩定地工作也很難了.

gydoesit

我的内存加上2个月了.
问了网友,他的也是,用fc3出现类似问题,换回rh9就正常了.看来os不行??
下次用什么?晕,不好想.
centos吧,似乎说不清,RHEL4吧,这个也不知道大家用起如何,没人说.
去查查bsd5.4吧,不支持我的串行阵列卡,想想也是,连FC4这么新潮的东东都认不得NF4上主板上的SATA阵列.所以我只有另外加一张siimage3112的卡,还没测试过,不知认得不.似乎网卡也不在bsd的支持列表中
而且不会bsd的nat,只会iptables

看样子还是硬着头皮用FC4?目前在另一台机上使用着哩.

这台FC3可能只有先把内核升下级,但是如何升,不会,我是在图形界面下升的,这会如何在shell中搞,教教我.只升内核吧

gydoesit

今天又死了.这次不去看了,直接打电话让机房重启.

上网又google了半天,
有网友也是FC3,常kernel panic.继续查.似乎是某些进程内核直接执行错误了.

在上面的信息中,如何看出是哪个进程引起的????


另外,有网友说可以在
/proc/sys/kernel/panic
中写入自动重启的等待秒数,听来也是一个办法.当然,下策,最好是不要出错

sakulagi

FC3是给大家“尝鲜”用的，即使不稳定也是可以理解的。如果真的希望做个稳定的服务器，还是不要用FC3比较好。

gydoesit

sakulagi,你说的本来也有道理,但我上网查时,有人在抱怨用AS4只跑Squid,也一样的kernel panic.
所以我们还是来找原因的好,看能不能在上面的错误信息中找出是哪个东东的问题.

我这会正在yum,什么都update

从这帖子来看,http://chinaunix.net/jh/36/116264.html
我们这个应该也是某个模块问题???

能否在上面看出??

EIP is at tcp_time_to_recover+0x73/0x17+

是不是这儿的tcp_time_to_recover 错了,这是什么的?是iptables的?
iptables只是netfilter的实用工具,那是内核本身不稳定?

下面又有进程mysqld字样,难道是mysqld错误????


大虾们看看

platinum

EIP is at tcp_time_to_recover+0x73/0x17+
Stack pointer is garbage,not printing trace
Code:Bad EIP value

如果没猜错的话，EIP 是一个 32 位寄存器，用来代表程序运行指针的（16 位里叫 IP）
我怀疑是你内存的问题，换个内存条试试？

sakulagi

我的建议是AS3 Update5，或者更新一些的update。相信会好很多，如果这个都不行，那Redhat就不用混了，嘿嘿。 其实每一款系统都会出很多bug，所以AS4的update都出来有些日子了。

看后边的信息EIP已经是一个错误的值了，所以没有call stack，也很难知道问题出在哪里，我只能判断是mysqld在做系统调用的时候kernel panic了。你现在这个服务器一定要用mysql么？如果不需要，把它停了。

tcp_time_to_recover是kernel的一个函数。你可以看一下/proc/ksyms或者System.map文件