unable to handle paging request at c7200720

M.Stekelenburg (Max@student.utwente.nl)
Thu, 15 Feb 1996 12:32:40 +0000


This is a compilation of messages over some time.
I once mentioned I could create a oops by running strings -a * in
/usr/bin. It would result in a unable to handle paging request c7200720.

Modules and kerneld aren't needed to make it work.
My computer is something like this:
kernel: modules,kerneld,elf,386,ide,ext2
module: ne2,sound
386dx33,copro,5mb,20mb swap,tr9000 video

I guessed looking at my system and at the moment of the problem. It
would have to do something with my video card. 07200720 looks like two
spaces of white text on a black background in video memory. So I asked some
people which had a problem which looked like mine. But the machines are
complete different. A trident is slow, but a cirrus gd5428 should be quite
fast, and a ati mach 64 pci isn't also slow. Oh there's one about ncurses.
It seems that ncurses is able to trigger the problem.

I've this problem for a long time but resent changes in the kernel have made
it more common or more people post about this oops to the kernel list.
Hope someone else sees what could cause this...

From: Aaron Ucko <UCKO@VAX1.ROCKHURST.EDU>
Subject: Re: "Unable to handle kernel paging request" in
1.3.59+patchkit
doing "tar zxvvpf kbd-0.91.tar.gz" or something very similar
Unable to handle kernel paging request at virtual address c7200724
modules,kerneld,elf,486,ide,ext2,watchdog
module:slip,ppp,plip,sbpcd,printer,sound(mad16)
486 dx2 66,8M,24m swap,gd5428 video,redhat 2.1,libc 5.2.18

From: a.kruczkowski@ic.ac.uk (Mr A.M. Kruczkowski)
Subject: Busy low mem machine OOPS
Basically, I'm doing something in my first console, typically telneting
to a local mud server, or using minicom. In the second console, I do
a tar -zxvf <filename>. If the file is particularly long, I tend to
get problems, e.g. it stops some way through and gives me OOPSes. Below
are the ones I got this time.
EIP: 0010:[<07200720>]
4 Mb 486dx2 50,16mb swap

From: a.kruczkowski@ic.ac.uk (Mr A.M. Kruczkowski)
Subject: Cross terminal corruption
I quite frequently get corruption on consoles I am not using. 99% of
the time this occurs before I have logged in (agetty is running), and
takes the form of a line, maybe a couple of lines of random characters and
coloured blocks. Sometimes the corrupted screen blocks are each
separated by one uncorrupted block. I would guess that sometime is
writing to the wrong place (i.e. screen memory) but I can't be sure.

It occurs maybe every other time I use this machine (it is single user).
The chances of it occuring increase when I use a modem through minicom
(configured to use /dev/modem).

I have had two incidences when memory has been low that VTs I am working
on have become corrupted with material from other VTs (either current
stuff, or recent stuff that has just scrolled off).

This has happened with kernels since 1.3.2x (as far as I can remember).

From: Michael Meskes <meskes@informatik.rwth-aachen.de>
Subject: Re: Cross terminal corruption

No, it's not the hardware. I'm experiencing exactly the same on a system
that doesn't have any hardware problems (at least none I know of, it runs
well for nearly two years.

From: Curtiss <1CMC3466@ibm.mtsac.edu>
Subject: Re: Cross terminal corruption

I had this same exact problem sometime back and found ncurses
to be the culprit in this case due to a change in kernel 1.3.2* making
the default TERM be 'linux' instead of 'console' plus some incompatabil
ities with termcap. This problem fist showed up in ncurses 1.9.4 and
would randomly crash my machine, meaning it could have been up for
just a few minutes or some hours before a crash would hit. My soulution to
this was I ended up removing ncurses and the problem was fixed. I
have a copy the ncurses 1.9.8 sources but haven't compiled them yet to see
if the problem is still there.
Curtiss

From: David Monro <davidm@gh.cs.usyd.edu.au>
Subject: inet related oops in 1.3.58

Unable to handle kernel paging request at
eax: 00060018 ebx: 00000001 ecx: 00000000 edx: 07630765

This is then followed be an oops with a nonsense EIP of 07200720, followed by
another one with an EIP in die_if_kernel. After this the machine continued to
function but attepmting to use inet services failed (0010:[<07200720>]ie I
could log on on the console, but couldn't telnet in).

From: "Jeremy T. Bouse" <jnl9352@tam2000.tamu.edu>
Subject: Mystery oops

It occurr'd while I had 2 irc clients runnin and had just started a 'tar xvfz'
on the new sendmail upgrade I had just DL'd.

Jan 28 00:40:19 UnderGrid kernel: Oops: 0002
Jan 28 00:40:19 UnderGrid kernel: eax: 07200720 ebx: 00069200
ecx: 07200720 edx: 001e3000

From: Brian M Grunkemeyer <bg2k+@andrew.cmu.edu>
Subject: Oops in 1.3.59 + small Kswap patch

I got this oops while running X and a kernel compile under 1.3.59 +
Steven Tweedie's little fix (I think there was a buffer fix, among others)
for the kswapII code + Jered Floyd's 4-line networking typo-fix. (I
didn't get the mini-patch from Alan to work - I was trying to compile
the new one when my machine oops'ed)

This was a 486 w/ 16 MB RAM + 16 MB swap. I am pretty sure I should
have had at least 12 megs of virtual memory free when this occurred.

Before this oops, I switched from one text console to another and
noticed video corruption (screen was filled w/ randomly colored characters,
etc). I switched to my X console and the screen redraw was pathetically
slow-like 4 seconds at least for something that's usually instantaneous.
These are probably just symptoms, not problems, but I thought I'd
mention them.

Oops: 0002
eax: 07200720 ebx: fffff000 ecx: 00000000 edx: 07200720

From: Michael Meskes <meskes@informatik.rwth-aachen.de>
Subject: Oops in 1.3.62

Unable to handle kernel paging request at virtual address c763072e

From: Scott Johnston <root@odin.iac.net>
Subject: Uh-oh

Got this while reading my Linux kernel mail in Pine. Eight megs of RAM,
16 megs of swap. Lots of free memory, too... Odd. BTW, GPM stopped
responding when these messages ran: (oh yeah, kernel 1.3.57):
This seems to have killed off GPM and 'tail -f /var/adm/messages >/dev/tty6 &'
which I had been running. This was during a barrage of megabytes of mail
that had queued up while my link was down for just 20 hours.

Jan 23 16:44:49 odin kernel: Oops: 0000
Jan 23 16:44:49 odin kernel: EIP: 0010:[<07200720>]

From: Michael Meskes <meskes@informatik.rwth-aachen.de>
Subject: Re: Uh-oh

For the rare cases where I get a log it's not at the same position at
all. The machine that had this problems is an AMD 486DX40, 8MB Ram, 405MB
Western Digital disk.

kernel: modules,kerneld,pci(optimize),elf,pentium,ide(cmd640),3com(el3),ext2,
watchdog
module:ppp

Note that the problem also appeared when using CONFIG_M486. I hope we
can track this down. It's really annoying.

From: Scott Johnston <root@odin.iac.net>
Subject: Re: Uh-oh

When I ran with 8 megs, I did LOTS of swap, especially in X, but with
16 megs, I rarely have to swap, although sometimes if I'm running lots
of X programs, it swaps. I have an ATI Mach64 PCI video card, which I
would consider to be fairly fast.

Sorry, but I re-compile my kernel so often that I don't have the same
configuration running for more than a week <grin>. Although I =can=
tell you that I have an Intel 75 MHz Pentium, a 635 MB EIDE drive with an
ext2fs filesystem, and at that time I had 8 megs of RAM (I now have
16). I have not been able to reproduce the problem with 16 megs of RAM.

From: Michael Meskes <meskes@informatik.rwth-aachen.de>
Subject: Re: Uh-oh

I got similar crashes for several months now. Most of the time they
were so serious my software watchdog rebooted the system. No logging
performed at all. And everytime it's when a long output goes to a non-active VC.