From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacob Gorm Hansen Subject: Re: Failure to get memory for GATT table, again Date: Tue, 01 Feb 2005 00:59:23 -0800 Message-ID: <41FF44EB.5020707@diku.dk> References: <41FF3C81.3020406@diku.dk> <41FF41DE.2070000@diku.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <41FF41DE.2070000@diku.dk> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Jacob Gorm Hansen Cc: Ian Pratt , xen-devel List-Id: xen-devel@lists.xenproject.org Jacob Gorm Hansen wrote: > Jacob Gorm Hansen wrote: > I instrumented some more, apparently the page has the wrong owner, > causing the mmu update to fail. The page is almost at the top of memory, > probably outside of dom0s reservation. Remming out the ownership test in xen's get_page() made the intel-agp module load without errors. Unless someone beats me to it, I will try to figure out what makes the AGPGART code wish to exceed dom0s memory area tomorrow Seattle time. The fglrx module also loads fine, but attempting to start X ends up like this; Oops: 0000 [#1] DEBUG_PAGEALLOC Modules linked in: fglrx intel_agp agpgart CPU: 0 EIP: 0061:[] Tainted: P VLI EFLAGS: 00213206 (2.6.10-xen0) EIP is at remap_pfn_range+0x176/0x220 eax: c0523000 ebx: 000e0001 ecx: 00000027 edx: 000e0001 esi: 00062000 edi: f23e7188 ebp: 00162000 esp: f22efe8c ds: 007b es: 007b ss: 0069 Process X (pid: 6571, threadinfo=f22ee000 task=f6b63b20) Stack: 00162000 b7c00000 000dff9f 00062000 f23f6b7c f23f5ddc b7d62000 f23f6b7c b7c62000 f125ac70 f125ac70 f8921260 f88f5781 f125ac70 b7c62000 0002839f 00100000 00000027 f18e5f6c f89213fc f88f66ec f18e5f6c f125ac70 00000004 Call Trace: [] __ke_vm_map+0x191/0x250 [fglrx] [] firegl_mmap+0x1bc/0x460 [fglrx] [] do_mmap_pgoff+0x35f/0x730 [] old_mmap+0xd6/0x110 [] syscall_call+0x7/0xb Code: e0 05 01 d0 8b 00 f6 c4 08 74 2a 8b 44 24 44 89 d9 c1 e1 0c 09 c1 f6 c1 01 74 18 a1 80 c8 4e c0 89 ca c1 ea 0c 81 e1 ff 0f 00 00 <8b> 04 90 c1 e0 0c 09 c1 89 0f 43 83 c7 04 81 c6 00 10 00 00 74 -- however, I just blindly replaced all virt_to_phys calls with virt_to_machine in the wrapper code, and that is probably wrong. Problem is if there are similar address conversions inside the binary-only part of the module. 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