Very Computer

[ Article crossposted from comp.os.linux.misc ]
[ Author was Fung Wai Keung ]
[ Posted on 25 Sep 1998 03:02:35 GMT ]

Hi,

        We have matrox meteor framegrabber in my Linux box.  Sometimes, we get
the following message saying that the kernel can't handle a paging request
when we access the meteor,

maemb1:/home/users/wkfung>Unable to handle kernel paging request at virtual
add7
current->tss.cr3 = 02320000, %cr3 = 02320000
*pde = 0009e067
*pte = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<04812abe>]
EFLAGS: 00010246
eax: 02cf2c0c   ebx: 0022b5e0   ecx: 00000000   edx: 04819000
esi: 0337d018   edi: 0000000c   ebp: 04817644   esp: 0338ff2c
ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 0018
Process vu4-color (pid: 1568, process nr: 53, stackpage=0338f000)
Stack: 0337d018 03a586e8 019e1500 00000003 00000000 0022b5de 048173a8 0337d018
       0337d018 00000000 03a586e8 001247f2 019e1500 03a586e8 03a586e8 00000000
       02317000 00122a4f 019e1500 03a586e8 00000000 00000003 4000a1f8 00000000
Call Trace: [<048173a8>] [<001247f2>] [<00122a4f>] [<00122b67>] [<0010a689>]
Code: 8a 42 67 a8 01 74 13 a1 20 c1 19 00 2b 44 24 14 83 f8 02 77
Meteor driver version 1.4c: device 0 ready
Meteor driver version 1.4c: device 1 ready

        What does the above indicate?  After this message popup, the program
seems to run fine.  How to fix the missing paging request?

--

Regards,
Wai Keung, Fung

Department of Mechanical and Automation Engineering,
The Chinese University of Hong Kong,
Shatin, N.T.,
Hong Kong.

Tel: (852)26098470      Fax: (852)26036002

--

Regards,
Wai Keung, Fung

Department of Mechanical and Automation Engineering,
The Chinese University of Hong Kong,
Shatin, N.T.,
Hong Kong.

Tel: (852)26098470      Fax: (852)26036002

Quote:> We have matrox meteor framegrabber in my Linux box.  Sometimes, we
> get the following message saying that the kernel can't handle a
> paging request when we access the meteor,
> maemb1:/home/users/wkfung>Unable to handle kernel paging request at virtual
> add7

This is called an Oops, and is the kernel equivalent of a segmentation
fault.  All those numbers are for debugging purposes.  In short, you
found a kernel bug.  Whether or not it's serious is another matter --
you say the driver seems to work OK.  Anyway, if you run that output
through the `ksymoops' command (read up on it) it'll figure out what
part of the kernel crapped out, and you can send the results to

list.  They'll handle it from there.

(If you don't run the Oops through `ksymoops', the numbers in the Oops
are specific to your particular kernel compilation.  Meaning that since
kernel developers don't have access to *your* kernel, the raw numbers
are useless to them.)

--
Peter Samuelson
<sampo.creighton.edu!psamuels>

Quote:> I have used linux for years, hacked on device drivers, heard lots about
> this ksymoops, searched the kernel install tree, numerous archives but
> was left with a simple question:
>    Where do I get ksymoops ?????

Comes with the kernel source:

  linux/scripts/ksymoops.cc

or something like that.  (I'm not on Linux right now, can't check.)

--
Peter Samuelson
<sampo.creighton.edu!psamuels>

Quote:> through the `ksymoops' command (read up on it) it'll figure out what
> part of the kernel crapped out, and you can send the results to

I have used linux for years, hacked on device drivers, heard lots about
this ksymoops, searched the kernel install tree, numerous archives but
was left with a simple question:

        Where do I get ksymoops ?????

Cheers

Rudi

--

         | | | | |
       \   _____   /      
          /     \                      B O R N
      -- | o   o |  --                   T O
      -- |       |  --                S L E E P
      -- | \___/ |  --                   I N
          \_____/                   T H E   S U N
        /          \    
         | | | | |

It is delivered with the kernel source in linux/scripts

Thanks to all who replied. I still don't understand why ksymoops doesn't get
compiled during a regular kernel build. I usually don't want to start
compiling when my system starts oopsing. Also, it wouldn't make the kernel
build take much longer, would it ?

Rudi

--

         | | | | |
       \   _____   /      
          /     \                      B O R N
      -- | o   o |  --                   T O
      -- |       |  --                S L E E P
      -- | \___/ |  --                   I N
          \_____/                   T H E   S U N
        /          \    
         | | | | |

Quote:> I still don't understand why ksymoops doesn't get compiled during a
> regular kernel build. I usually don't want to start compiling when my
> system starts oopsing. Also, it wouldn't make the kernel build take
> much longer, would it ?

Well, it's written in C++, so if it were compiled with the kernel it
would require that you have a C++ compiler installed to build a kernel.
Not something you want to assume about everybody.  Also, ksymoops
doesn't change between one kernel revision and the next -- it seems to
be pretty stable, and definitely doesn't have anything like builtin
symbol version dependencies or CONFIG_* options, like the kernel source
proper, so it doesn't really make sense to compile it more than once.
I guess it is assumed that anyone who uses ksymoops will compile it and
install it in /usr/bin or somewhere and then never worry about the
source again.

A version was posted to the linux-kernel list several months ago that
had been rewritten in C, the point being that ksymoops was the only bit
of C++ code in the whole kernel tree.  For anyone interested, look in
the linux-kernel archives.

--
Peter Samuelson
<sampo.creighton.edu!psamuels>

Then build it before your system starts oopsing ;-)

(You only need to build it once. I can't remember the last time it
changed in any way).

Quote:> Also, it wouldn't make the kernel build take much longer, would it ?

No, but on the other hand you can compile the rest of the kernel
without a C++ compiler.

Dave Wragg