PLEASE HELP - Very odd kernel panic problem

cpptutor2000 · External Since: Jul 15, 2007 Posts: 1

I am trying to debug some kernel software and running into a kernel
panic problem. The OS is Linux 2.6.18 and I am running on a PMC-Sierra
processor.

When the kernel panic occurs, there is a call trace. Now as this is an
embedded system application, my only debugging option is to apply
debug print statements at appropriate locations and find out how many
of them get printed out before the panic occurs.

I am starting from the function at the top of the stack, which is
where the panic was supposed to have been triggered.

I have found that if I comment out all the code in the function at the
top of the call trace, with the function just returning an integer,
the panic still occurs at the function that was supposed to have been
called before the function at the top of the call trace.

I am very confused. Could someone please point out if I am doing
something terribly wrong, or is there something wrong with my
debugging method, or if there is a more efficient way to tackle the
problem, given that there is no debugger.

Any hints, suggestions would be greatly appreciated. Thanks in advance
for your help.

I have attached a good part of the stack trace for reference:

CPU 0 Unable to handle kernel paging request at virtual address
00000064, epc == c0d6c864, ra == c0d6c83c
Oops[#1]:
Cpu 0
$ 0 : 00000000 00000000 00000006 0000d8f4
$ 4 : 85db9884 00000000 85db9870 00000005
$ 8 : 00000014 8022ed9c 00000001 74683a20
$12 : 0000000d ffffffee 00000001 00000001
$16 : 85d94d80 86618000 85dceb80 8669c38a
$20 : 85d92400 00000000 ffffffff 8022ecc0
$24 : 00000001 c0d4cdc0
$28 : 85db8000 85db9818 00000004 c0d6c83c
Hi : 00000001
Lo : 9999999a
epc : c0d6c864 SipAlgsoPrvTranslateSip+0x1f4/0x7c4 [bisga]
Tainted: P
ra : c0d6c83c SipAlgsoPrvTranslateSip+0x1cc/0x7c4 [bisga]
Status: 11005c03 KERNEL EXL IE
Cause : 00800008
BadVA : 00000064
PrId : 00019522
Modules linked in: bisga
Process Ip4sHmoAsyncRec (pid: 297, threadinfo=85db8000, task=85ce5568)
Stack : 80230000 c0d90000 c0d8bf60 00000020 00000001 00000003 8669ce80
c0d8be0c
00000001 00000000 c0d7a254 c0d7a18c 8669ce80 8661806c 00000020
865a3400
00000001 c0d7bc1c 8669c500 c0f81834 86618070 865a3400 00000000
c0a80061
1100d8f4 d8f40000 00000006 c0f84d40 0a0a0216 00000000 00000000
85dce500
86694500 0000d8f4 c0a80061 8669c380 00000000 86618000 85d92400
86618000
...
Call Trace:
[<c0d6c864>] SipAlgsoPrvTranslateSip+0x1f4/0x7c4 [bisga]

ellis · External Since: Apr 02, 2004 Posts: 193

In article <1184540415.452781.241150.RemoveThis@k79g2000hse.googlegroups.com>,
cpptutor2000.RemoveThis@yahoo.com <cpptutor2000.RemoveThis@yahoo.com> wrote:

>CPU 0 Unable to handle kernel paging request at virtual address

Do you know what that one means?

--
http://www.spinics.net/lists/kernel/

guru · External Since: Jul 20, 2007 Posts: 9

Hi,

The some of the problems for the kernel panic i used to encounter are

1. referring NULL pointer inside the kernel(trying to access it).
2. Trying to free the memory allocated inside the kernel twice.

After debugging the code, we corrected these bugs.. then it never
paniced again. Just check your code once for the logic and memory
handling.

Regards
Gururaja

cpptutor2000.RemoveThis@yahoo.com wrote:
> I am trying to debug some kernel software and running into a kernel
> panic problem. The OS is Linux 2.6.18 and I am running on a PMC-Sierra
> processor.
>
> When the kernel panic occurs, there is a call trace. Now as this is an
> embedded system application, my only debugging option is to apply
> debug print statements at appropriate locations and find out how many
> of them get printed out before the panic occurs.
>
> I am starting from the function at the top of the stack, which is
> where the panic was supposed to have been triggered.
>
> I have found that if I comment out all the code in the function at the
> top of the call trace, with the function just returning an integer,
> the panic still occurs at the function that was supposed to have been
> called before the function at the top of the call trace.
>
> I am very confused. Could someone please point out if I am doing
> something terribly wrong, or is there something wrong with my
> debugging method, or if there is a more efficient way to tackle the
> problem, given that there is no debugger.
>
> Any hints, suggestions would be greatly appreciated. Thanks in advance
> for your help.
>
> I have attached a good part of the stack trace for reference:
>
> CPU 0 Unable to handle kernel paging request at virtual address
> 00000064, epc == c0d6c864, ra == c0d6c83c
> Oops[#1]:
> Cpu 0
> $ 0 : 00000000 00000000 00000006 0000d8f4
> $ 4 : 85db9884 00000000 85db9870 00000005
> $ 8 : 00000014 8022ed9c 00000001 74683a20
> $12 : 0000000d ffffffee 00000001 00000001
> $16 : 85d94d80 86618000 85dceb80 8669c38a
> $20 : 85d92400 00000000 ffffffff 8022ecc0
> $24 : 00000001 c0d4cdc0
> $28 : 85db8000 85db9818 00000004 c0d6c83c
> Hi : 00000001
> Lo : 9999999a
> epc : c0d6c864 SipAlgsoPrvTranslateSip+0x1f4/0x7c4 [bisga]
> Tainted: P
> ra : c0d6c83c SipAlgsoPrvTranslateSip+0x1cc/0x7c4 [bisga]
> Status: 11005c03 KERNEL EXL IE
> Cause : 00800008
> BadVA : 00000064
> PrId : 00019522
> Modules linked in: bisga
> Process Ip4sHmoAsyncRec (pid: 297, threadinfo=85db8000, task=85ce5568)
> Stack : 80230000 c0d90000 c0d8bf60 00000020 00000001 00000003 8669ce80
> c0d8be0c
> 00000001 00000000 c0d7a254 c0d7a18c 8669ce80 8661806c 00000020
> 865a3400
> 00000001 c0d7bc1c 8669c500 c0f81834 86618070 865a3400 00000000
> c0a80061
> 1100d8f4 d8f40000 00000006 c0f84d40 0a0a0216 00000000 00000000
> 85dce500
> 86694500 0000d8f4 c0a80061 8669c380 00000000 86618000 85d92400
> 86618000
> ...
> Call Trace:
> [<c0d6c864>] SipAlgsoPrvTranslateSip+0x1f4/0x7c4 [bisga]