Oops: kernel access of bad area

Oops: kernel access of bad area

[Suresh Chandra Mannava]

[-- Attachment #1.1: Type: text/plain, Size: 771 bytes --]

Hi,

I am working on porting Linux 2.6.19 on a custom board with MPC7410 and
CPC700 system controller.
I am using u-boot-1.1.6 for booting Linux. I found IBM spruce is also having
CPC700, I followed spruce related files and made modifications accordingly.
Board supports external 2MB L2 cache and 128MB SDRAM.

I am encountering kernel panic(serial console messages attached with this
mail). I traced the code by putting printk and found that kernel is crashing
after executing all functions in start_kernel.
Is this problem related to L2 cache?
I didn't enabled L2 cache in Linux as well as in u-boot.
I request you to provide me some pointers and suggestions for finding out
this problem. I am going to try with L2 cache enabled.

Thanks a lot.

Suresh Chandra Mannava

[-- Attachment #1.2: Type: text/html, Size: 821 bytes --]

[-- Attachment #2: CAPTURE.TXT --]
[-- Type: text/plain, Size: 3438 bytes --]

bootm 2000000
## Booting image at 02000000 ...
   Image Name:   Linux-2.6.19
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    705067 Bytes = 688.5 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Current stack ends at 0x07FB4CF0 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF13
memstart    = 0x00000000
memsize     = 0x08000000
flashstart  = 0xFFE00000
flashsize   = 0x00200000
flashoffset = 0x00000000
sramstart   = 0x00000000
sramsize    = 0x00000000
bootflags   = 0x00000001
intfreq     =    363 MHz
busfreq     =     66 MHz
ethaddr     = 64:36:00:00:00:01
eth1addr    = 64:36:00:00:00:02
IP addr     = 192.168.0.100
baudrate    =  57600 bps
No initrd
## Transferring control to Linux (at address 00000000) ...
Total memory = 128MB; using 256kB for hash table (at c0180000)
Linux version 2.6.19 (suresh@mannava) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #18 Thu Jan 11 10:34:36 IST 2007
System Identification: Cornet CSVG4 Linux Boot
Zone PFN ranges:
  DMA             0 ->    32768
  Normal      32768 ->    32768
early_node_map[1] active PFN ranges
    0:        0 ->    32768
Built 1 zonelists.  Total pages: 32512
Kernel command line: console=ttyS0,57600
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128128k available (1068k kernel code, 336k data, 92k init, 0k highmem)
Mount-cache hash table entries: 512
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C0011ADC LR: C0011B78 CTR: 00000005
REGS: c02edfb0 TRAP: 0300   Not tainted  (2.6.19)
MSR: 00001032 <ME,IR,DR>  CR: 24028022  XER: 20000000
DAR: 0000007D, DSISR: 42000000
TASK = c02e9b38[0] '' THREAD: 02dc5915
GPR00: 00200200 C02EE060 C02E9B38 C02E9B38 C0169DB4 00000000 C02EFFFC 00000044 
GPR08: 01C09000 00000078 C02E9B60 0000007D 00000000 04008C00 08003C00 007FFF13 
GPR16: 00000001 C01684C8 C0170000 C0170000 00000000 00000000 00880381 C0169980 
GPR24: C02EE000 C0169980 C02E9BF4 C02E9C48 00000000 C02E9B38 C02E9B38 C00CE818 
NIP [C0011ADC] dequeue_task+0x20/0x84
LR [C0011B78] deactivate_task+0x38/0x54
Call Trace:
Instruction dump:
90830028 91690004 912b0000 4e800020 81240000 39430028 3c000020 3929ffff 
60000200 91240000 816a0004 81230028 <912b0000> 91690004 39240018 900a0004 
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C0012934 LR: C00128B0 CTR: 00000000
REGS: c02edd90 TRAP: 0600   Not tainted  (2.6.19)
MSR: 00001032 <ME,IR,DR>  CR: 44028024  XER: 00000000
DAR: 02DC593D, DSISR: 00000140
TASK = c02e9b38[0] '' THREAD: 02dc5915
GPR00: 02DC593D C02EDE40 C02E9B38 00000000 19EED540 00000001 C0169540 00000000 
GPR08: 08F9C6A0 00000008 00000000 02DC5915 08F9C6A0 04008C00 08003C00 007FFF13 
GPR16: 00000001 C01684C8 C0170000 C0170000 00000000 C0170000 C01672C0 00000000 
GPR24: C0160000 C0170000 C0160000 C02EDEC0 C0170000 C0169DB4 C0169980 C02E9B38 
NIP [C0012934] scheduler_tick+0x9c/0x350
LR [C00128B0] scheduler_tick+0x18/0x350
Call Trace:
Instruction dump:
801e0024 907e0018 7f9f0000 909e001c 419e0030 83bf0030 801e002c 7f9d0000 
419e0048 817f0004 39200008 380b0028 <7d400028> 7d4a4b78 7d40012d 40a2fff4 
Badness in do_exit at kernel/exit.c:859
Call Trace:
Kernel panic - not syncing: Aiee, killing interrupt handler!
 <0>Rebooting in 180 seconds..

Oops: kernel access of bad area

[Suresh Chandra Mannava]

[-- Attachment #1.1: Type: text/plain, Size: 747 bytes --]

Hi,

I am working on porting Linux 2.6.19 on a custom board with MPC7410 and
CPC700 system controller.
I am using u-boot-1.1.6 for booting Linux. I found IBM spruce is also having
CPC700, I followed spruce related files and made modifications accordingly.
Board supports external 2MB L2 cache and 128MB SDRAM.

I am encountering kernel panic(serial console messages attached with this
mail). I traced the code by putting printk and found that kernel is crashing
after executing all functions in start_kernel.
Is this problem related to L2 cache?
I didn't enabled L2 cache in Linux as well as in u-boot.
I request you to provide me some pointers and suggestions for finding out
this problem. I am going to try with L2 cache enabled.

Thanks a lot.

[-- Attachment #1.2: Type: text/html, Size: 787 bytes --]

[-- Attachment #2: CAPTURE.TXT --]
[-- Type: text/plain, Size: 3438 bytes --]

bootm 2000000
## Booting image at 02000000 ...
   Image Name:   Linux-2.6.19
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    705067 Bytes = 688.5 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Current stack ends at 0x07FB4CF0 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF13
memstart    = 0x00000000
memsize     = 0x08000000
flashstart  = 0xFFE00000
flashsize   = 0x00200000
flashoffset = 0x00000000
sramstart   = 0x00000000
sramsize    = 0x00000000
bootflags   = 0x00000001
intfreq     =    363 MHz
busfreq     =     66 MHz
ethaddr     = 64:36:00:00:00:01
eth1addr    = 64:36:00:00:00:02
IP addr     = 192.168.0.100
baudrate    =  57600 bps
No initrd
## Transferring control to Linux (at address 00000000) ...
Total memory = 128MB; using 256kB for hash table (at c0180000)
Linux version 2.6.19 (suresh@mannava) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #18 Thu Jan 11 10:34:36 IST 2007
System Identification: Cornet CSVG4 Linux Boot
Zone PFN ranges:
  DMA             0 ->    32768
  Normal      32768 ->    32768
early_node_map[1] active PFN ranges
    0:        0 ->    32768
Built 1 zonelists.  Total pages: 32512
Kernel command line: console=ttyS0,57600
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128128k available (1068k kernel code, 336k data, 92k init, 0k highmem)
Mount-cache hash table entries: 512
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C0011ADC LR: C0011B78 CTR: 00000005
REGS: c02edfb0 TRAP: 0300   Not tainted  (2.6.19)
MSR: 00001032 <ME,IR,DR>  CR: 24028022  XER: 20000000
DAR: 0000007D, DSISR: 42000000
TASK = c02e9b38[0] '' THREAD: 02dc5915
GPR00: 00200200 C02EE060 C02E9B38 C02E9B38 C0169DB4 00000000 C02EFFFC 00000044 
GPR08: 01C09000 00000078 C02E9B60 0000007D 00000000 04008C00 08003C00 007FFF13 
GPR16: 00000001 C01684C8 C0170000 C0170000 00000000 00000000 00880381 C0169980 
GPR24: C02EE000 C0169980 C02E9BF4 C02E9C48 00000000 C02E9B38 C02E9B38 C00CE818 
NIP [C0011ADC] dequeue_task+0x20/0x84
LR [C0011B78] deactivate_task+0x38/0x54
Call Trace:
Instruction dump:
90830028 91690004 912b0000 4e800020 81240000 39430028 3c000020 3929ffff 
60000200 91240000 816a0004 81230028 <912b0000> 91690004 39240018 900a0004 
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C0012934 LR: C00128B0 CTR: 00000000
REGS: c02edd90 TRAP: 0600   Not tainted  (2.6.19)
MSR: 00001032 <ME,IR,DR>  CR: 44028024  XER: 00000000
DAR: 02DC593D, DSISR: 00000140
TASK = c02e9b38[0] '' THREAD: 02dc5915
GPR00: 02DC593D C02EDE40 C02E9B38 00000000 19EED540 00000001 C0169540 00000000 
GPR08: 08F9C6A0 00000008 00000000 02DC5915 08F9C6A0 04008C00 08003C00 007FFF13 
GPR16: 00000001 C01684C8 C0170000 C0170000 00000000 C0170000 C01672C0 00000000 
GPR24: C0160000 C0170000 C0160000 C02EDEC0 C0170000 C0169DB4 C0169980 C02E9B38 
NIP [C0012934] scheduler_tick+0x9c/0x350
LR [C00128B0] scheduler_tick+0x18/0x350
Call Trace:
Instruction dump:
801e0024 907e0018 7f9f0000 909e001c 419e0030 83bf0030 801e002c 7f9d0000 
419e0048 817f0004 39200008 380b0028 <7d400028> 7d4a4b78 7d40012d 40a2fff4 
Badness in do_exit at kernel/exit.c:859
Call Trace:
Kernel panic - not syncing: Aiee, killing interrupt handler!
 <0>Rebooting in 180 seconds..

Oops: Kernel access of bad area

[Christian Kujau]

Hi,

I started some x11 application (here: firefox) through an ssh connection 
on a remote host and it crashed somehow. OK, no biggie, killed the 
application and be done with it. However, I noticed that the load of the 
machine is now constantly at 7. It's an iBook G4, has nothing to do, 
disks, cpu, netwokr is idle and load is usually < 1. Now it's not
slow to work or anyhow sluggish, but only the load is at 7 after the 
application crashed. When I looked into dmesg I saw:

[84983.750977] Unable to handle kernel paging request for data at address 0x4815d000
[84983.751046] Faulting instruction address: 0xc0012090
[84983.751157] Oops: Kernel access of bad area, sig: 11 [#1]
[84983.751178] PREEMPT PowerMac
[84983.751214] Modules linked in: nls_iso8859_15 nls_cp850 vfat fat isofs nls_base zlib_inflate radeon drm snd_powermac snd_pcm snd_timer snd soundcore snd_page_alloc fuse firewire_ohci firewire_core crc_itu_t ide_cd cdrom ssb bcm43xx rng_core ieee80211softmac uninorth_agp ieee80211 ieee80211_crypt agpgart
[84983.751750] NIP: c0012090 LR: c00165fc CTR: 00000080
[84983.751786] REGS: cea65b30 TRAP: 0300   Not tainted  (2.6.24-rc5)
[84983.751805] MSR: 00009032 <EE,ME,IR,DR>  CR: 24822282  XER: 00000000
[84983.751946] DAR: 4815d000, DSISR: 40000000
[84983.751965] TASK = ee372670[9138] 'firefox-bin' THREAD: cea64000
[84983.751984] GPR00: e62b3a00 cea65be0 ee372670 4815d000 00000080 1bc0c181 4815d000 ffffffff
[84983.752148] GPR08: 00010008 e62b3a00 00000000 c045f000 24822288 1002ea3c cea67690 ce954000
[84983.752315] GPR16: c0420000 c03f6400 cea65cac cea65ca8 c0440000 ce974480 c07d7180 ceba2280
[84983.752468] GPR24: e62b3a00 e62b3a50 4815d000 00000574 ceba2280 4815d000 1bc0c181 c07d7180
[84983.752665] NIP [c0012090] __flush_dcache_icache+0x14/0x40
[84983.752716] LR [c00165fc] update_mmu_cache+0x11c/0x120
[...]

This is the first time that this happened on this iBook, and it was not 
reproducible so far (well, it happened just a few minutes ago). Is this 
something to worry about? Or should I file this under "well, shit 
happens"? Btw, this 2.6.24-rc5 is from Linus' -git tree (15.12.2007).

Details and .config: http://nerdbynature.de/bits/2.6.24-rc5/

Thanks,
Christian.
-- 
BOFH excuse #281:

The co-locator cannot verify the frame-relay gateway to the ISDN server.

Re: Oops: Kernel access of bad area

[Nathan Lynch]

Christian Kujau wrote:
> Hi,
> 
> I started some x11 application (here: firefox) through an ssh connection 
> on a remote host and it crashed somehow. OK, no biggie, killed the 
> application and be done with it. However, I noticed that the load of the 
> machine is now constantly at 7. It's an iBook G4, has nothing to do, 
> disks, cpu, netwokr is idle and load is usually < 1. Now it's not
> slow to work or anyhow sluggish, but only the load is at 7 after the 
> application crashed. When I looked into dmesg I saw:
> 
> [84983.750977] Unable to handle kernel paging request for data at address 0x4815d000
> [84983.751046] Faulting instruction address: 0xc0012090
> [84983.751157] Oops: Kernel access of bad area, sig: 11 [#1]
> [84983.751178] PREEMPT PowerMac
> [84983.751214] Modules linked in: nls_iso8859_15 nls_cp850 vfat fat isofs nls_base zlib_inflate radeon drm snd_powermac snd_pcm snd_timer snd soundcore snd_page_alloc fuse firewire_ohci firewire_core crc_itu_t ide_cd cdrom ssb bcm43xx rng_core ieee80211softmac uninorth_agp ieee80211 ieee80211_crypt agpgart
> [84983.751750] NIP: c0012090 LR: c00165fc CTR: 00000080
> [84983.751786] REGS: cea65b30 TRAP: 0300   Not tainted  (2.6.24-rc5)
> [84983.751805] MSR: 00009032 <EE,ME,IR,DR>  CR: 24822282  XER: 00000000
> [84983.751946] DAR: 4815d000, DSISR: 40000000
> [84983.751965] TASK = ee372670[9138] 'firefox-bin' THREAD: cea64000
> [84983.751984] GPR00: e62b3a00 cea65be0 ee372670 4815d000 00000080 1bc0c181 4815d000 ffffffff
> [84983.752148] GPR08: 00010008 e62b3a00 00000000 c045f000 24822288 1002ea3c cea67690 ce954000
> [84983.752315] GPR16: c0420000 c03f6400 cea65cac cea65ca8 c0440000 ce974480 c07d7180 ceba2280
> [84983.752468] GPR24: e62b3a00 e62b3a50 4815d000 00000574 ceba2280 4815d000 1bc0c181 c07d7180
> [84983.752665] NIP [c0012090] __flush_dcache_icache+0x14/0x40
> [84983.752716] LR [c00165fc] update_mmu_cache+0x11c/0x120

Better to include the full stack trace in such reports, but here it
is:

 NIP [c0012090] __flush_dcache_icache+0x14/0x40
 LR [c00165fc] update_mmu_cache+0x11c/0x120
 Call Trace:
 [cea65be0] [ce8c1000] 0xce8c1000 (unreliable)
 [cea65c00] [c0075868] handle_mm_fault+0x39c/0x7f8
 [cea65c50] [c0075dec] get_user_pages+0x128/0x398
 [cea65ca0] [c00c5e18] elf_core_dump+0xb64/0xc28
 [cea65d40] [c0091e64] do_coredump+0x754/0x788
 [cea65e50] [c003cb20] get_signal_to_deliver+0x2dc/0x3fc
 [cea65e80] [c000a678] do_signal+0x48/0x28c
 [cea65f40] [c0012cb4] do_user_signal+0x74/0xc4
 --- Exception: c00 at 0xfd36ea4
     LR = 0x10012018
 Instruction dump:
 4d820020 7c8903a6 7c001bac 38630020 4200fff8 7c0004ac 4e800020 60000000
 54630026 38800080 7c8903a6 7c661b78 <7c00186c> 38630020 4200fff8 7c0004ac

So it looks like the kernel oopsed while firefox was dumping core,
yuck.

> This is the first time that this happened on this iBook, and it was not 
> reproducible so far (well, it happened just a few minutes ago). Is this 
> something to worry about? Or should I file this under "well, shit 
> happens"?

It's a real bug.  Hopefully someone on the list can help...

Re: Oops: Kernel access of bad area

[Christian Kujau]

On Thu, 20 Dec 2007, Nathan Lynch wrote:
> Better to include the full stack trace in such reports,

Hm, I did not want to clutter the mail with all this stuff, but you're 
right, in this case it would've made sense...

> So it looks like the kernel oopsed while firefox was dumping core,
> yuck. It's a real bug.  Hopefully someone on the list can help...

As it's the first time this happened and I could not reproduce it so far 
(the only thing I can reproduce is the ffox crash :)), I doubt it'll be 
"fixable" somehow...

Thanks,
Christian.
-- 
BOFH excuse #247:

Due to Federal Budget problems we have been forced to cut back on the number of users able to access the system at one time. (namely none allowed....)