[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
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.



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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.