Changes between Initial Version and Version 7 of Ticket #344


Ignore:
Timestamp:
2011-05-31T13:38:44Z (14 years ago)
Author:
Martin Decky
Comment:

The ticket has been edited to talk only about the ppc32 issue, which has been already solved. A separate ticket for mips32 will be created.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #344

    • Property Owner changed from Jakub Jermář to Martin Decky
    • Property Status new → closed
    • Property Resolution → fixed
    • Property Summary as_area_destroy() broken on mips32, ppc32 → as_area_destroy() broken on ppc32

  • Ticket #344 – Description

    initial v7  
    1 The implementation of as_area_destroy() seems to be broken on mips32 and ppc32.
     1The implementation of as_area_destroy() seems to be broken on ppc32. The framebuffer server is killed due to various memory management problems. The user space heap allocator has been extensively examined and tested on other platforms and it doesn't seem to be the culprit.
    22
    3 On mips32 (in GXemul) the malloc3 test fails (heap structure gets corrupted), on ppc32 the framebuffer server is killed due to various memory management problems. The user space heap allocator has been extensively examined and tested on other platforms and it doesn't seem to be the culprit.
    4 
    5 On ppc32 the problem can be worked around by removing the memory sharing code in the framebuffer server. On both platforms the problem can be completely worked around by changing the kernel function sys_as_area_destroy() into a no-op.
    6 
    7 Both ppc32 and mips32 use hierarchical page tables (as_pt.c, page_pt.c) as the kernel memory management backend. This hints what might be the root cause (although other possibilities still cannot be eliminated yet).
     3The problem can be worked around by removing the memory sharing code in the framebuffer server. The problem can be completely worked around by changing the kernel function sys_as_area_destroy() into a no-op.