LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Kernel (http://www.linuxquestions.org/questions/linux-kernel-70/)
-   -   Unable to handle kernel paging request at virtual address ff200200 (http://www.linuxquestions.org/questions/linux-kernel-70/unable-to-handle-kernel-paging-request-at-virtual-address-ff200200-611062/)

gdkool 01-04-2008 05:16 AM

Unable to handle kernel paging request at virtual address ff200200
 
Hi,

I am trying to boot Montavista linux on MIPS processor based board. Just when the kernel is trying to fork a new thread for the very first time in the boot sequence, I receive the "Unable to handle kernel paging request at virtual address ff200200" message which ends in kernel panic.

Following is the crash dump:

Unable to handle kernel paging request at virtual address ff200200, epc == 8010467c, ra == 80112fe0 >> This is the address of last but one statement of function kernel_thread.

Oops in fault.c::do_page_fault, line 213:
$0 : 00000000 10008401 00000000 00000001 00810f00 00000000 80267f40 00000000
$8 : 00008400 00008400 00000000 00000000 fffffff7 ffffffff 0000000a 00000004
$16: 00000000 00810f00 80100794 00000000 83edfeb8 00000002 00000000 83fd75c8
$24: 00000000 8029d5df 81072000 81073fe0 80268040 80112fe0
Hi : 00000000
Lo : 00000000
epc : 8010467c Not tainted >>> This is the address after the first syscall.
Status: 10008402
Cause : 50800008
Process swapper (pid: 1, stackpage=81072000)
Stack: 6ace8c00 02001645 67348144 143b089e 6e840292 800518b6 9c7f2116
020cef5d
Call Trace:

Code: 02202021 24021018 0000000c <10dd0006> 27bdffe0 0240f809 02002021 00402021 24020fa1
Kernel panic: Attempted to kill init!

Any help in this regard will be greatly appreciated.

jailbait 01-04-2008 09:57 PM

As I understand it MIPS comes in both 32 bit and 64 bit processors. Have you cross compiled the kernel for the correct processor? If you have the wrong processor a likely place for the kernel to die is when it switches from real mode addressing to virtual addressing which appears to be where your kernel died.

--------------------------
Steve Stites

gdkool 01-05-2008 02:02 AM

It was compiled correctly for MIPS32
 
Quote:

Originally Posted by jailbait (Post 3011862)
As I understand it MIPS comes in both 32 bit and 64 bit processors. Have you cross compiled the kernel for the correct processor? If you have the wrong processor a likely place for the kernel to die is when it switches from real mode addressing to virtual addressing which appears to be where your kernel died.

--------------------------
Steve Stites

Hi Steve,

Thanks for you response.... but I've cross-compiled the kernel for the correct processor which in my case is the 32-bit version. Had it been the case of wrong processor selection, hadn't it died earlier ?

You have mentioned here, kernel died at the place where it just switched from real mode addressing to virtual addressing. Can you please elaborate this point?

Regards
gdkool

jailbait 01-05-2008 11:58 AM

Quote:

Originally Posted by gdkool (Post 3012012)
Hi Steve,

Thanks for you response.... but I've cross-compiled the kernel for the correct processor which in my case is the 32-bit version. Had it been the case of wrong processor selection, hadn't it died earlier ?

You have mentioned here, kernel died at the place where it just switched from real mode addressing to virtual addressing. Can you please elaborate this point?

Regards
gdkool

Virtual addressing works by indirect addressing. There is a page table which indicates where that page is in real memory and the hardware uses the page table to indirectly address memory. Until the kernel gets the page table set up it runs in real mode where it uses the real address of memory locations.

So I read your symptoms and thought that maybe the kernel and the hardware disagreed on how to handle virtual memory, i.e. the kernel was compiled for the wrong cpu.

--------------------------
Steve Stites

gdkool 01-06-2008 01:26 AM

Quote:

Originally Posted by jailbait (Post 3012457)
Virtual addressing works by indirect addressing. There is a page table which indicates where that page is in real memory and the hardware uses the page table to indirectly address memory. Until the kernel gets the page table set up it runs in real mode where it uses the real address of memory locations.

So I read your symptoms and thought that maybe the kernel and the hardware disagreed on how to handle virtual memory, i.e. the kernel was compiled for the wrong cpu.

--------------------------
Steve Stites

Thanks a lot Steve. Since, the correct CPU type has been selected, can you think of some other reason of this happening?

FYI, On debugging the problem to reach the exact location, I found that there is a c0 MIPS instruction which was executed in a function called restore_all in response to syscall, where the invalid address 0xff200200 was floated as next instruction address. I know its not a great clue, but this is what I've in the box for the moment.

Regards,
gdkool

gdkool 01-07-2008 05:15 AM

Quote:

Originally Posted by gdkool (Post 3013004)
Thanks a lot Steve. Since, the correct CPU type has been selected, can you think of some other reason of this happening?

FYI, On debugging the problem to reach the exact location, I found that there is a c0 MIPS instruction which was executed in a function called restore_all in response to syscall, where the invalid address 0xff200200 was floated as next instruction address. I know its not a great clue, but this is what I've in the box for the moment.

Regards,
gdkool

Hi all,

The problem has been resolved. It was a hardware related software issue. Thanks for your support.

Regards
gdkool

laughaha 07-06-2008 09:54 PM

Ask gdkool for help!Thanks!
 
Quote:

Originally Posted by gdkool (Post 3014172)
Hi all,

The problem has been resolved. It was a hardware related software issue. Thanks for your support.

Regards
gdkool

Hi gdkool!I'm developing a embeded system on Au1500 which based on mips arch.The linux kernel is Montavista linux kernel2.4.20. I have met with the same problem with yours!Can you tell some details about solving the problem!Thanks a lot!

gdkool 07-07-2008 12:10 AM

Quote:

Originally Posted by laughaha (Post 3206083)
Hi gdkool!I'm developing a embeded system on Au1500 which based on mips arch.The linux kernel is Montavista linux kernel2.4.20. I have met with the same problem with yours!Can you tell some details about solving the problem!Thanks a lot!

Hi laughaha,

The issue of kernel unable to handle paging request at virtual address ... is somewhat generic and can be observed in various scenarios. So, it would be important to see that what is causing this in your case, and can be figured out by basic debugging.

Regards
gdkool

laughaha 07-07-2008 01:15 AM

Quote:

Originally Posted by gdkool (Post 3206179)
Hi laughaha,

The issue of kernel unable to handle paging request at virtual address ... is somewhat generic and can be observed in various scenarios. So, it would be important to see that what is causing this in your case, and can be figured out by basic debugging.

Regards
gdkool

Thanks for your so quick reply! The embeded system is a digital video recorder.The file system type is jffs2 and harddisk is based on ATA!Only when write the buffer data to harddisk for a short time(over 12 hours), It's easy to cause the kernel oops as the following! The buffer size is 256KBytes(any question with the buffer size?).

kernel oops :
===========================================================
BUG at jfs_dmap.c:2870 assert(n < 4)
kernel BUG at jfs_dmap.c:2870!
Unable to handle kernel paging request at virtual address 00000000, epc == 801c2ee4, ra == 801c2ee4
Oops in fault.c:do_page_fault, line 213:
$0 : 00000000 1000fc00 0000001f 00000000 8036e9d0 00000001 00000001 00000000
$8 : 00000001 0000314e 00004001 803a8f9d fffffff8 ffffffff 0000000a 00000003
$16: 00000004 00000001 00000059 00000000 00000059 845cd010 86cd5c30 85bb8380
$24: 86cd5b03 803a937f 86cd4000 86cd5be8 00000000 801c2ee4
Hi : ffff2e99
Lo : 000045cd
epc : 801c2ee4 Not tainted
Status: 1000fc03
Cause : 0080000c
Process edvr (pid: 297, stackpage=86cd4000)
Stack: 87fc0c28 8030f278 00000b36 00000000 00000000 00000000 845cd000
85af0000 00000001 00000000 00000000 801c1b2c 86cd5c20 00000000 00000000
00000000 00032020 00000000 00000005 85af0000 0000001c 00000000 0000001c
85af0000 00000001 801c0234 85af0000 87fc0bdc 00032020 00000000 86cd5cd0
00000000 86cd5cd0 00000000 845cd000 00000000 87fc0c28 80361aa8 00000001
00000000 ...
Call Trace: [<8030f278>] [<801c1b2c>] [<801c0234>] [<801cce50>] [<801cc7fc>]
[<801ccbb8>] [<801b12ec>] [<80146d8c>] [<80146f1c>] [<8014786c>] [<801b1198>]
[<801b14d8>] [<80223fd4>] [<80134058>] [<80134100>] [<801223d8>] [<801344dc>]
[<801564c8>] [<8014338c>] [<80107ba4>] [<80107ba4>]

Code: 24a5f278 0c04624b 24060b36 <ac000000> 02501021 00021080 2631ffff 1e20ffe1 24520001
Aborted
Rebooting...
==================================================================
Now I have no better way to debug the kernel and figure out the reason! Can you give me some suggestions from the above informations or some better way to continue to analysize? Thanks!

gdkool 07-08-2008 12:10 AM

Quote:

Originally Posted by laughaha (Post 3206211)
Thanks for your so quick reply! The embeded system is a digital video recorder.The file system type is jffs2 and harddisk is based on ATA!Only when write the buffer data to harddisk for a short time(over 12 hours), It's easy to cause the kernel oops as the following! The buffer size is 256KBytes(any question with the buffer size?).

kernel oops :
===========================================================
BUG at jfs_dmap.c:2870 assert(n < 4)
kernel BUG at jfs_dmap.c:2870!
Unable to handle kernel paging request at virtual address 00000000, epc == 801c2ee4, ra == 801c2ee4
Oops in fault.c:do_page_fault, line 213:
$0 : 00000000 1000fc00 0000001f 00000000 8036e9d0 00000001 00000001 00000000
$8 : 00000001 0000314e 00004001 803a8f9d fffffff8 ffffffff 0000000a 00000003
$16: 00000004 00000001 00000059 00000000 00000059 845cd010 86cd5c30 85bb8380
$24: 86cd5b03 803a937f 86cd4000 86cd5be8 00000000 801c2ee4
Hi : ffff2e99
Lo : 000045cd
epc : 801c2ee4 Not tainted
Status: 1000fc03
Cause : 0080000c
Process edvr (pid: 297, stackpage=86cd4000)
Stack: 87fc0c28 8030f278 00000b36 00000000 00000000 00000000 845cd000
85af0000 00000001 00000000 00000000 801c1b2c 86cd5c20 00000000 00000000
00000000 00032020 00000000 00000005 85af0000 0000001c 00000000 0000001c
85af0000 00000001 801c0234 85af0000 87fc0bdc 00032020 00000000 86cd5cd0
00000000 86cd5cd0 00000000 845cd000 00000000 87fc0c28 80361aa8 00000001
00000000 ...
Call Trace: [<8030f278>] [<801c1b2c>] [<801c0234>] [<801cce50>] [<801cc7fc>]
[<801ccbb8>] [<801b12ec>] [<80146d8c>] [<80146f1c>] [<8014786c>] [<801b1198>]
[<801b14d8>] [<80223fd4>] [<80134058>] [<80134100>] [<801223d8>] [<801344dc>]
[<801564c8>] [<8014338c>] [<80107ba4>] [<80107ba4>]

Code: 24a5f278 0c04624b 24060b36 <ac000000> 02501021 00021080 2631ffff 1e20ffe1 24520001
Aborted
Rebooting...
==================================================================
Now I have no better way to debug the kernel and figure out the reason! Can you give me some suggestions from the above informations or some better way to continue to analysize? Thanks!

Did you check where is the error PC pointing to? Also there is a failed assertion at jfs_dmap.c:2870. The bug seems to be application specific and its hard for me to comment on this at the moment.

Just try to analyze what the system is doing at the time it crashes and figure out the issue.

BaluM 07-22-2009 06:33 AM

Unable to handle kernel paging request at virtual address @XXXXX
 
Quote:

Originally Posted by gdkool (Post 3014172)
Hi all,

The problem has been resolved. It was a hardware related software issue. Thanks for your support.

Regards
gdkool

Hi,

Could you please share how you resolved this issue?, i am also strugglings for a couple of days. Either it's hardware or software related more information and quick response is highly appreciated.


Thanks in Advance,
Balu


All times are GMT -5. The time now is 07:49 AM.