#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: | ||
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 , 14 years ago
comment:2 by , 14 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 , 14 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 , 14 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
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 , 14 years ago
Note that kqemu has been discontinued on the QEMU side, so this may well be a kqemu bug.
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.