|
xen-devel
Re: [Xen-devel] Failure to get memory for GATT table, again
Ian Pratt wrote:
Just to recap, this seems like a bug in Xen or Xenlinux.
MMUEXT_SET_FOREIGNDOM seems to expect the granted pages to be
owned by
the grantee already, instead of the granter. I've disabled
the check in
Xen, and fglrx now proceeds to take down the machine when I start X.
Perhaps it would be better to spend the time on the open drivers at
http://r300.sourceforge.net/ , or wait for ATI to discover Xen.
It sounds rather more like an agp driver that's taking liberties to me.
The fact that disabling the check takes the machine down seems to
suggest its there for a purpose :-)
Could you explain what MMUEXT_SET_FOREIGNDOM is supposed to do, and in
particular who should own the pages before and after the call? Still,
this check fail _before_ fglrx is loaded. Right now intel-agp refuses to
load on my machine with an ATI card inside, and all the software on the
machine at that point comes from the xen-tree.
What happens is:
1) the xen_contig_mem function frees some mem.
2) the xen_contig_mem function allocs some other mem instead. dom0 now
owns that mem.
3) dom0 tries to give that mem away to some mysterious other domain
using MMU_SET_FOREIGNDOM (if I understand the purpose of that call
correctly).
4) Xen complains because the to-be-given-away mem is owned by dom0
rather than the mysterious foreign domain.
I agree that fglrx is also buggy, but the failing ownership check has
nothing to do with that.
Thanks,
Jacob
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
Home