Hi.
Its my own compilation, and it's basically the same .config as
2.4.19, I just felt it would be nicer with 2.4.20.
And btw, 2.4.20 has been working without any (known?) problems
for some time now, these errors have been started about 8 days ago.
Martin
> Do you have OEM kernel or is it your own compilation?
>
> Try another kernel? (Since it obviously isn't the hard drive).
>
> ----- Original Message -----
> From: "Martin Östlund" <mo@microsaft.nu>
> To: <security-discuss@linuxsecurity.com>
> Sent: Wednesday, January 15, 2003 5:14 AM
> Subject: Re: Unable to handle kernel paging
>
>
> > Hi again list.
> >
> > my error happened again, this time the errormessage is:
> >
> > Jan 14 21:58:24 lysithea kernel: *pde = 00000000
> > Jan 14 21:59:26 lysithea kernel: *pde = 00000000
> >
> > then it totally hangs and is unavaible :(
> >
> > Anyone knows what this can be? I tried the earlier suggestion from the
> > list by disabling the swap, and it has been without swap for about 2 days.
> > (no, the swap didn't ran out).
> >
> > Cheers,
> > Martin
> >
> >
> > > 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.
> >
> >
> >
>
>
> ------------------------------------------------------------------------
> 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.
