Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#6254 closed bug (invalid)

PANIC: get_memory_map(): Address is greater 4 GB!

Reported by: mmadia Owned by: axeld
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/alpha2
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

Running hrev37262 gcc2hybrid + USE_SLAB_ALLOCATOR_FOR_MALLOC.

This repeatedly occurs when using QEMU 0.11.1 to load a default haiku image. This did not occur on hrev36983.

PANIC: get_memory_map(): Address is greater 4 GB!
Welcome to Kernel Debugging Land...
Thread 74000 "qemu_main" running on CPU 0
stack trace for thread 74000 "qemu_main"
    kernel stack: 0x81985000 to 0x81989000
      user stack: 0x70000000 to 0x70040000
frame               caller     <image>:function + offset
 0 81988a38 (+  32) 8010167e   <kernel_x86>:arch_debug_stack_trace + 0x0012
 1 81988a58 (+  16) 80074727   <kernel_x86> stack_trace_trampoline(NULL) + 0x000b
 2 81988a68 (+  12) 8010710a   <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b
 3 81988a74 (+  48) 8007614c   <kernel_x86>:debug_call_with_fault_handler + 0x0060
 4 81988aa4 (+  80) 80074943   <kernel_x86> kernel_debugger_loop(0x80142af7 "PANIC: ", 0x80154a20 "get_memory_map(): Address is greater 4 GB!", 0x81988b60 "", int32: 0) + 0x0217
 5 81988af4 (+  48) 80074cb8   <kernel_x86> kernel_debugger_internal(0x80142af7 "PANIC: ", 0x80154a20 "get_memory_map(): Address is greater 4 GB!", 0x81988b60 "", int32: 0) + 0x0048
 6 81988b24 (+  48) 800764ac   <kernel_x86>:panic + 0x0024
 7 81988b54 (+  64) 800ea58a   <kernel_x86>:__get_memory_map_beos + 0x005a
 8 81988b94 (+2120709228) 875c4114   </boot/home/config/add-ons/kernel/drivers/dev/misc/kqemu>:kqemu_lock_user_page + 0x0044
kdebug> 

Change History (5)

comment:1 by mmadia, 9 years ago

To note, qemu -hda /generated/x86gcc2/haiku.image -m 256 -enable-kqemu -name haiku was the offending command. Removing -enable-kqemu will allow it to run, without triggering a KDL.

comment:2 by bonefish, 9 years ago

I assume your machine does indeed have memory beyond the 4 GB address limit? If so, there's nothing the system can do here. Solutions:

  • Disable memory beyond 4 GB or
  • update qemu.

Please close, if my assumption is correct.

comment:3 by mmadia, 9 years ago

  • (Two) 2GB sticks + onboard video
  • When this KDL'd, the bios was allocating 64M for video. AboutSystem reported : 4031 MiB total, 1 MiB inaccessible
  • After upping that amount from 64M to 256M, AboutSystem reports: 3839 MiB total, 1 MiB. QEMU with -enable-kqemu doesn't KDL (it'll still crash, but at the application level with Abort \n Killed (by death)).inaccessible. QEMU without -enable-kqemu will still

comment:4 by bonefish, 9 years ago

Resolution: invalid
Status: newclosed

OK, so the machine has 4 GB of memory, i.e. some of it will be beyond the 32 bit address limit. When the qemu driver tries to get_memory_map() for memory mapped to that physical memory, the kernel panics. I'm not familiar with the qemu sources. In particular I don't know how qemu allocates the memory in question and why it calls get_memory_map(), but that's nothing the kernel can do anything about. Disabling the memory beyond 4 GB should solve the issue.

PS: Note that the panic is continuable, but depending on whether qemu recognizes the error code returned (which couldn't happen in BeOS) and what qemu does with the physical addresses it gets, it might corrupt memory, with unforeseeable effects.

comment:5 by andreasf, 9 years ago

Note that kqemu has been discontinued on the QEMU side, so this may well be a kqemu bug.

Note: See TracTickets for help on using tickets.