If its a harddrive error, there is no utility necessary.
Just make a backup on a new harddrive.
And try "to make" the old concerning harddrive "new" with:
dd if=/dev/zero of=/dev/harddrive
If this fails, then it will show the address of
harddrive, which is malfunctioning.
cheers.
Tino.
Am Mon, 2003-01-13 um 16.34 schrieb Nick Thompson:
> ----- Original Message -----
> From: "Martin Östlund" <mo@microsaft.nu>
> To: <security-discuss@linuxsecurity.com>
> Sent: Monday, January 13, 2003 9:22 AM
> Subject: Unable to handle kernel paging
>
>
> > Hello listpeople.
> >
> > Recently my server has been getting this in the syslog:
> >
> > Jan 9 00:30:38 lysithea kernel: Unable to handle kernel paging request at
> virtual address c72674ca
> > Jan 9 00:30:38 lysithea kernel: *pde = 00000000
> >
> > Then it becomes unavaible through ssh, telnet and ftp (proftpd).
> >
> > the www is avaible, and an ircbouncer.
> >
> > The server is an AMD-K6, 128Mb ram, 334Mb swap, running Slackware Linux
> > 8.1 with 2.4.20 kernel. I upgraded to 2.4.20 about 1 - 1.5 month ago, and
> > these problems have started the last 2 weeks. A reboot fixes it, then it
> > happens again after 24-36 hours.
> >
> > Any ideas?
>
> What kind of hard drive? If the hard drive is having a read error when
> attempting to grab a chunk of virtual memory stored on the swap partition,
> that is a critical error which will freeze any process or thread relying on
> that chunk of memory. Your WWW server may be running just fine because it's
> currently retained in RAM and not swapped out.
>
> Download a hard drive utility from the hard drive manufacturer and boot to
> an old DOS disk to run it.
>
> You could alternately boot Linux to single user mode, unmount the swap
> partition and try to run an extensive fsck check against it.
>
> I would try this both now and right after the problem occurs.
>
> You could also disable your swap partition (/etc/fstab) since you have a
> fair amount of RAM just to prove if it's the hard drive or other problem. I
> disagree with earlier posting that your RAM could be the problem. That would
> show other critical errors that would be unrelated to virtual memory. While
> waiting to see if a problem occurs, keep another machine telnetted into your
> server running the "top" process so that you get a snapshot of the RAM and
> process running just before the freeze occurs.
>
>
>
>
>
> ------------------------------------------------------------------------
> To unsubscribe email security-discuss-request@linuxsecurity.com
> with "unsubscribe" in the subject of the message.
>
------------------------------------------------------------------------
To unsubscribe email security-discuss-request@linuxsecurity.com
with "unsubscribe" in the subject of the message.
