RE: [Xen-ia64-devel] FYI: gcc segfault also meet with as

["Xu, Anthony" <anthony.xu@xxxxxxxxx>]

>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