| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
RE: [Xen-ia64-devel] FYI: gcc segfault also meet with as
>From: Magenheimer,
>Dan (HP Labs Fort Collins)
>Yes this problem has been with us for several months and
>anybody who exercises Xen/ia64 heavily will probably see it
>occur. It is definitely not specific to gcc... it may even
>be occuring in ltp, but since it is not repeatable (the
>failure appears almost randomly), it is hard to link a
>single ltp test failure to the "gcc segfault" problem.
>
>Based on what I have seen, I suspect it has something
>to do with a stale translation... perhaps some flush/purge
>is not working properly or maybe a region id is being
>incorrectly re-used.
>
>Isolating this problem will take a lot of effort and
>some sophisticated debug tools/hardware. However, I
>would not recommend Xen/ia64 be "released" to customers
>until it is found/fixed.
>
I also saw gcc segmentation on dom0 recently, and I got chance to debug this,
I caught this issue once,and I found this gcc segmentation is due to process
access
a address which is not belong to this process.
I also found the machine address of this fault address belongs to the high
memory block(16M), which is used to avoid VIRTUAL_MEMMAP issue.
I looked into the code, and found xen uses this 16M just below max_page.
and this 16M can't be guaranteed not used by box firmware.
But I didn't find the area was used by firmware from memmap dumped in efi
shell.
Though, I still dropped down this 16M from dom0, and run kernel build,
I haven't see gcc segmentation fault since then.
I'm not sure if it is the root cause, just FYI.
Thanks,
Anthony
>Dan
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home