A Linux server (Slackware 4, kernel 2.2.12) had been running faultlessly and
had an uptime of over 40 days. Then on Saturday evening about 19:10 hours
it locked up. It still responded to ping's but was not allowing
connections.
After a reboot the log files were examined and the following kernel panics
were found:
syslog:Nov 13 13:42:48 pawprint kernel: Kernel panic: skput:under:
c017ac0a:33 put:32 dev:lo
syslog:Nov 13 13:42:48 pawprint kernel: Kernel panic: skput:under:
c017ac0a:33 put:32 dev:lo
Now this was about four and a half hours before the machine finally froze
A new kernel (2.2.13) was compiled up and installed but the machine was not
rebooted at this point. I was planning to examine the machine before
installing the new kernel.
At 9am on Sunday morning it was discovered that the machine had again
crashed, but was still reponding to pings. After a reboot several hours
later syslog again showed:
syslog:Nov 14 06:03:20 pawprint kernel: Kernel panic: skput:under:
c0173ee3:186 put:14 dev:lo
syslog:Nov 14 06:03:20 pawprint kernel: Kernel panic: skput:under:
c0173ee3:186 put:14 dev:lo
Apache logs now show that ever sine the first crash it's child processes are
regularly segfaulting and it has been noticed that ocassionally programs
will segfault duting normal use (i.e. 'su' and 'grep').
Another odd syslog entry this morning was:
Nov 15 04:40:02 pawprint kernel: kfree: Bad obj c449b8e0
Nov 15 04:40:02 pawprint kernel: kfree: Bad obj c449b8e0
Nov 15 04:40:02 pawprint kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
Nov 15 04:40:02 pawprint kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
Nov 15 04:40:02 pawprint kernel: current->tss.cr3 = 05010000, %cr3 =
05010000
Nov 15 04:40:02 pawprint kernel: current->tss.cr3 = 05010000, %cr3 =
05010000
Nov 15 04:40:02 pawprint kernel: *pde = 00000000
Nov 15 04:40:02 pawprint kernel: *pde = 00000000
Nov 15 04:40:02 pawprint kernel: Oops: 0002
Nov 15 04:40:02 pawprint kernel: CPU: 0
This appeared to be during a slocate database update. (Equiv of updatedb).
As I said the box was working fine up until this first crash, which came out
of the blue. No changes had been made to the configuration of the box just
prior to this.
And as I was typing this message in on the machine it died again. This time
it was running kernel 2.2.13. (Fortunatly copy still worked from the telnet
client :)
Does anyone have any idea:
a) What caused the original panics?
b) What could be causing the current segfaults?
c) How to fix it? :)
Many regards,
Neil Burrows
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/