Paging Request Kernel problems

Paging Request Kernel problems

Post by Jon F. Garfunke » Tue, 28 Jan 1997 04:00:00



I've got RedHat 4.0 on an i486, and I'd had it up running for a couple of
weeks with few problems. Seemingly out of nowhere I am getting problems
similar to those I had while testing out 3.0.4. (The latest new thing to
sortof irritate the system is running an AppleTalk Daemon and letting the
program determine its own configuration. Gleefully fills up the message
logs.)

On the minute every minute for 40 minutes, the kernel would log errors
(this, and one of the log entries, suggest crond is the culprit). It reports:

Jan 26 02:08:00 spigot kernel: Unable to handle kernel paging request at
virtual address d0041d24
Jan 26 02:08:00 spigot kernel: current->tss.cr3 = 005ae000, 8r3 = 005ae000

and then dumps all of the register contents to the logs. I am racking my
brain on x86 assembly to try and guess what's out of the ordinary. These
are the last two logs per time:

Jan 26 02:08:00 spigot kernel: Call Trace: [system_call+85/128]
Jan 26 02:08:00 spigot kernel: Code: 08 8d 44 24 04 50 ff 74 24 10 e8 0f
9f 00 00 83 c4 08 85 c0

I am led to believe that this then causes the system to crash. But the
system also seems to be crashing without reporting anything to the logs,
which is far worse!

      _|  Jon Garfunkel '98
    _|       http://www.princeton.edu/~garfunkl
  _|            Visit us at the STAIRMASTER
_|                  or call at 609-258-STEP

 
 
 

Paging Request Kernel problems

Post by r.. » Mon, 10 Feb 1997 04:00:00


Quote:>On the minute every minute for 40 minutes, the kernel would log errors
>(this, and one of the log entries, suggest crond is the culprit). It reports:
>Jan 26 02:08:00 spigot kernel: Unable to handle kernel paging request at
>virtual address d0041d24
>Jan 26 02:08:00 spigot kernel: current->tss.cr3 = 005ae000, 8r3 = 005ae000
>and then dumps all of the register contents to the logs. I am racking my
>brain on x86 assembly to try and guess what's out of the ordinary. These
>are the last two logs per time:

        this may be totally un-related but i had a very similar problem, altho
much more ramdom. in my system, the paging problem was related to my
swapping to disk. seems my cpu was writing to the disk buffer faster
than it could read it reliably. in the cpu bios, i introduced one wait
state for writing to the h-drive. after doing this, the paging fault
went away.  the other obvious result of this prob was about weekly
corruption of the disk tables, and having to fdisk it.