j
: Next unread message k
: Previous unread message j a
: Jump to all threads
j l
: Jump to MailingList overview
On Sat, Apr 6, 2013 at 11:07 AM, Blue Swirl blauwirbel@gmail.com wrote:
On Sat, Apr 6, 2013 at 1:50 AM, Artyom Tarasenko atar4qemu@gmail.com wrote:
On Fri, Apr 5, 2013 at 10:08 PM, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2013-Apr-5 15:40 , Artyom Tarasenko wrote:
[...]
OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00020000 OFMEM: ofmem_map_page_range ffc60000 -> 006f60000 00014000 mode 000000bc
^^^^ this one
Wherever that's coming from, that looks like an allocator doing descending addresses.
OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000 OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000 OFMEM: Non-free virtual memory claimed!
^^^^ overlaps with this one.
This allocator, whatever it is has been doing ascending addresses. This actually looks like you simply ran out of room.
Ops. Good catch! Mark, can we just allocate more RAM, or do we have serious problem?
You might change that patch rather than rounding up to the next 2^n, don't bother aligning to anything more than 0x2000.
You mean
} else if ( align > 0x2000) { align = 0x2000; } else {
This would probably break allocation for IOMMU table, it needs to be aligned (physically) to table size (like 32MB).
Hmm. The successful log in the previous mail was produced with this code... Will remove it and test again.
-- Regards, Artyom Tarasenko
linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu