I''ve just started toying with xen and noticed the lack of support for agpgart. It looks like the reasons for this lack have changed between 1.2 and 2.0 and It looks like it''s a lot closer to working now. I unfortunately do not have much experience doing VM programming, so my understanding of what''s needed may be a little lacking. I was wondering if someone with a little more knowledge of VM''s and Xen than I could comment before I start digging further into it on what work needs to be done in Xen to make agpgart/drm/etc. work in Xen. Thanks in advance. -- Gerald ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
The answer may well be "nothing" if you just want GART/DRI in DOM0. Probably those source driectories haven''t been enabled in the Xen arachitecture for 2.6 - if you can do that then try compiling teh drivers and see what happens! -- Keir> I''ve just started toying with xen and noticed the lack of support for > agpgart. It looks like the reasons for this lack have changed between 1.2 > and 2.0 and It looks like it''s a lot closer to working now. I unfortunately > do not have much experience doing VM programming, so my understanding of > what''s needed may be a little lacking. I was wondering if someone with a > little more knowledge of VM''s and Xen than I could comment before I start > digging further into it on what work needs to be done in Xen to make > agpgart/drm/etc. work in Xen. Thanks in advance. > > -- Gerald > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
That was actually my initial attempt. The first problem I ran into was it
attempting to do a cache flush:
#define flush_agp_cache() asm volatile("wbinvd":::"memory")
Which causes a general protection fault. Ignoring that for the moment and
then working forward, it allocates a page of memory with __get_free_page()
and attempts to ioremap_nocache() it to presumably generate a completely
uncached page in memory. This results in a strange oops attempting to
fiddle with the page tables changing the page attributes on that piece
of memory.
My goal at the moment is to have the machine''s head running in dom0
(and
on the i830-ish machine I have as a target, this is going to require the
agpgart working to have any reasonable X on it).
-- Gerald
On Sat, Sep 04, 2004 at 02:11:20AM +0100, Keir Fraser
wrote:> The answer may well be "nothing" if you just want GART/DRI in
> DOM0. Probably those source driectories haven''t been enabled in
the
> Xen arachitecture for 2.6 - if you can do that then try compiling teh
> drivers and see what happens!
>
> -- Keir
>
> > I''ve just started toying with xen and noticed the lack of
support for
> > agpgart. It looks like the reasons for this lack have changed between
1.2
> > and 2.0 and It looks like it''s a lot closer to working now.
I unfortunately
> > do not have much experience doing VM programming, so my understanding
of
> > what''s needed may be a little lacking. I was wondering if
someone with a
> > little more knowledge of VM''s and Xen than I could comment
before I start
> > digging further into it on what work needs to be done in Xen to make
> > agpgart/drm/etc. work in Xen. Thanks in advance.
> >
> > -- Gerald
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by BEA Weblogic Workshop
> > FREE Java Enterprise J2EE developer tools!
> > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
>
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
> That was actually my initial attempt. The first problem I ran into was it > attempting to do a cache flush: > > #define flush_agp_cache() asm volatile("wbinvd":::"memory")We can fix this by virtualising the instruction. But we can ignore it for now.> Which causes a general protection fault. Ignoring that for the moment and > then working forward, it allocates a page of memory with __get_free_page() > and attempts to ioremap_nocache() it to presumably generate a completely > uncached page in memory. This results in a strange oops attempting to > fiddle with the page tables changing the page attributes on that piece > of memory.Hmmmm.... I think the problem is people using virt_to_phys() instead of virt_to_bus(). I would have expected the latter to be correct really. I''ll take a look at uses of ioremap() and ioremap_nocache() throughout Linux. It may be there''s a simple fix that will work for all uses... You could try manually changing the address passed in to virt_to_bus() and see if you get fiurther. -- Keir> My goal at the moment is to have the machine''s head running in dom0 (and > on the i830-ish machine I have as a target, this is going to require the > agpgart working to have any reasonable X on it). > > -- Gerald > > On Sat, Sep 04, 2004 at 02:11:20AM +0100, Keir Fraser wrote: > > The answer may well be "nothing" if you just want GART/DRI in > > DOM0. Probably those source driectories haven''t been enabled in the > > Xen arachitecture for 2.6 - if you can do that then try compiling teh > > drivers and see what happens! > > > > -- Keir > > > > > I''ve just started toying with xen and noticed the lack of support for > > > agpgart. It looks like the reasons for this lack have changed between 1.2 > > > and 2.0 and It looks like it''s a lot closer to working now. I unfortunately > > > do not have much experience doing VM programming, so my understanding of > > > what''s needed may be a little lacking. I was wondering if someone with a > > > little more knowledge of VM''s and Xen than I could comment before I start > > > digging further into it on what work needs to be done in Xen to make > > > agpgart/drm/etc. work in Xen. Thanks in advance. > > > > > > -- Gerald > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by BEA Weblogic Workshop > > > FREE Java Enterprise J2EE developer tools! > > > Get your free copy of BEA WebLogic Workshop 8.1 today. > > > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/xen-devel > >------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Hmmmm.... I think the problem is people using virt_to_phys() instead > of virt_to_bus(). I would have expected the latter to be correct > really. I''ll take a look at uses of ioremap() and ioremap_nocache() > throughout Linux. It may be there''s a simple fix that will work for all > uses... You could try manually changing the address passed in to > virt_to_bus() and see if you get fiurther.Ok. I''ve gone through and tweaked a little to see if I could make some more forward progress. I''ve basically done s/virt_to_page/virt_to_bus/ and have gotten the system to initialize, when X starts though, I run into another one of those pagetable tweaking oopses (below). The code which is executing here is pretty straightforward: #define map_page_into_agp(page) change_page_attr(page, 1, PAGE_KERNEL_NOCACHE) void *agp_generic_alloc_page(void) { struct page * page; page = alloc_page(GFP_KERNEL); if (page == NULL) return NULL; map_page_into_agp(page); get_page(page); SetPageLocked(page); atomic_inc(&agp_bridge->current_memory_agp); return page_address(page); } With the code blowing up inside the change_page_attr(). Oops detail below. -- Gerald Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected an Intel 855PM Chipset. agpgart: Maximum main memory to use for agp memory: 440M agpgart: AGP aperture is 256M @ 0xd0000000 [drm] Initialized radeon 1.11.0 20020828 on minor 0: ioperm not fully supported - set iopl to 3 ioperm not fully supported - ignore resource release ioperm not fully supported - ignore resource release agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode Unable to handle kernel paging request at virtual address c0102d64 printing eip: c0117ff8 *pde = ma 0308b067 pa 0048b067 *pte = ma 02c02061 pa 00002061 [<c01181c2>] __change_page_attr+0x14e/0x21e [<c011830c>] change_page_attr+0x7a/0x8f [<e110f58e>] agp_generic_alloc_page+0x3c/0x65 [agpgart] [<e110e7e7>] agp_allocate_memory+0x72/0xd2 [agpgart] [<e1179a45>] radeon_agp_allocate_memory+0x22/0x2a [radeon] [<e11795e3>] radeon_agp_alloc+0xb9/0x1a2 [radeon] [<c0106434>] inflate_dynamic+0x428/0x5f5 [<e117dc49>] radeon_ioctl+0xc9/0x13f [radeon] [<c0106434>] inflate_dynamic+0x428/0x5f5 [<c0106434>] inflate_dynamic+0x428/0x5f5 [<e117db80>] radeon_ioctl+0x0/0x13f [radeon] [<c016366f>] sys_ioctl+0xf7/0x24c [<c0106434>] inflate_dynamic+0x428/0x5f5 [<c010d2d3>] syscall_call+0x7/0xb [<c0106434>] inflate_dynamic+0x428/0x5f5 Oops: 0003 [#1] PREEMPT Modules linked in: radeon intel_agp agpgart ds yenta_socket pcmcia_core ip_tables vfat fat ehci_hcd uhci_hcd CPU: 0 EIP: 0061:[<c0117ff8>] Not tainted EFLAGS: 00013202 (2.6.8.1-xen0) EIP is at set_pmd_pte+0xe/0x8a eax: c0102d64 ebx: 190000e3 ecx: d66c0000 edx: d66c0000 esi: c05e4b00 edi: 191c0063 ebp: c1109c80 esp: d3565eb0 ds: 0069 es: 0069 ss: 0069 Process X (pid: 2354, threadinfo=d3564000 task=df8091e0) Stack: c0102d64 c05e4b00 c01181c2 c0102d64 d66c0000 190000e3 d66c0000 c13cb800 00000000 00000000 00000000 c011830c c13cb800 00000073 c13cb800 00000000 00000800 00000000 e110f58e c13cb800 00000001 00000073 e00f5500 e110e7e7 Call Trace: [<c01181c2>] __change_page_attr+0x14e/0x21e [<c011830c>] change_page_attr+0x7a/0x8f [<e110f58e>] agp_generic_alloc_page+0x3c/0x65 [agpgart] [<e110e7e7>] agp_allocate_memory+0x72/0xd2 [agpgart] [<e1179a45>] radeon_agp_allocate_memory+0x22/0x2a [radeon] [<e11795e3>] radeon_agp_alloc+0xb9/0x1a2 [radeon] [<c0106434>] inflate_dynamic+0x428/0x5f5 [<e117dc49>] radeon_ioctl+0xc9/0x13f [radeon] [<c0106434>] inflate_dynamic+0x428/0x5f5 [<c0106434>] inflate_dynamic+0x428/0x5f5 [<e117db80>] radeon_ioctl+0x0/0x13f [radeon] [<c016366f>] sys_ioctl+0xf7/0x24c [<c0106434>] inflate_dynamic+0x428/0x5f5 [<c010d2d3>] syscall_call+0x7/0xb [<c0106434>] inflate_dynamic+0x428/0x5f5 Code: 89 18 a1 40 87 3f c0 0f b6 70 01 c6 40 01 01 b8 00 e0 ff ff ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > Hmmmm.... I think the problem is people using virt_to_phys() instead > > of virt_to_bus(). I would have expected the latter to be correct > > really. I''ll take a look at uses of ioremap() and ioremap_nocache() > > throughout Linux. It may be there''s a simple fix that will work for all > > uses... You could try manually changing the address passed in to > > virt_to_bus() and see if you get fiurther. > > Ok. I''ve gone through and tweaked a little to see if I could make some > more forward progress. I''ve basically done s/virt_to_page/virt_to_bus/ > and have gotten the system to initialize, when X starts though, I run into > another one of those pagetable tweaking oopses (below). The code which > is executing here is pretty straightforward:Can you make your vmlinux file available that goes with that oops? If so I''ll take a look. -- Keir ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Sat, Sep 04, 2004 at 04:26:01AM +0100, Keir Fraser wrote:> Can you make your vmlinux file available that goes with that oops? > If so I''ll take a look.Sure. I''ve placed the vmlinux and related files here: http://sekrit.org/dist/xen/ The source changes I''ve made to get to this point were turning the cache flush operation into a noop and s/virt_to_phys/virt_to_bus/ in the agp drivers, and in arch/xen/i386/mm/ioremap.c. -- Gerald ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Somehow you are ending up in the following code in the following code
in __change_page_attr (arch/i386/mm/pageattr.c):
if (cpu_has_pse && (page_count(kpte_page) == 1)) {
list_add(&kpte_page->lru, &df_list);
revert_page(kpte_page, address);
}
This ought to be impossible, as cpu_has_pse should be 0.
Add some debug printing around that code -- e.g., print the value of
cpu_has_pse, and also the contents of e.g.,
boot_cpu_data.x86_capability[0], boot_cpu_data.x86_capability[1].
Perhaps the capability flags are getting corrupted - I think the value
must be correct at boot time or you would crash while booting!
Meanwhile I''ve checked in a fix for wbinvd. I''ve fixed the
wbinvd()
macro in system.h, but agp.h uses the instruction directly. You''ll
have to patch that file yourself -- really a patch ought to be sent to
the maintainer, but I''ll wait until I''ve fixed the broken uses
of
ioremap_nocache in various GART drivers.
-- Keir
> On Sat, Sep 04, 2004 at 04:26:01AM +0100, Keir Fraser wrote:
> > Can you make your vmlinux file available that goes with that oops?
> > If so I''ll take a look.
>
> Sure. I''ve placed the vmlinux and related files here:
>
> http://sekrit.org/dist/xen/
>
> The source changes I''ve made to get to this point were turning the
cache
> flush operation into a noop and s/virt_to_phys/virt_to_bus/ in the agp
> drivers, and in arch/xen/i386/mm/ioremap.c.
>
> -- Gerald
>
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
On Sat, Sep 04, 2004 at 05:47:36AM +0100, Keir Fraser wrote:> Somehow you are ending up in the following code in the following code > in __change_page_attr (arch/i386/mm/pageattr.c): > > if (cpu_has_pse && (page_count(kpte_page) == 1)) { > list_add(&kpte_page->lru, &df_list); > revert_page(kpte_page, address); > } > > This ought to be impossible, as cpu_has_pse should be 0. > Add some debug printing around that code -- e.g., print the value of > cpu_has_pse, and also the contents of e.g., > boot_cpu_data.x86_capability[0], boot_cpu_data.x86_capability[1].I''ve confirmed that this is infact the codepath that''s executing. I also catted /proc/cpuinfo and the "pse" flag is listed there. If it helps, my setup here is an IBM Thinkpad T40p which has a Pentium M 1600MHz in it (cpuinfo is included below).> Perhaps the capability flags are getting corrupted - I think the value > must be correct at boot time or you would crash while booting!I examined the values in /proc/cpuinfo after boot, I''ll dump the flags earlier in the boot process and see if it''s correct then... I tested for PSE immediately after the memcpy() at the top of setup_arch() and it is set there. Here is the cpuinfo from within Xen: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 9 model name : Intel(R) Pentium(R) M processor 1600MHz stepping : 5 cpu MHz : 1594.870 cache size : 1024 KB fdiv_bug : no hlt_bug : yes f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe tm2 est bogomips : 3185.04 Outside of Xen, the differences I see are "hlt_bug : no" instead of yes, and outside I lack the flags "apic sep"> Meanwhile I''ve checked in a fix for wbinvd. I''ve fixed the wbinvd() > macro in system.h, but agp.h uses the instruction directly. You''ll > have to patch that file yourself -- really a patch ought to be sent to > the maintainer, but I''ll wait until I''ve fixed the broken uses of > ioremap_nocache in various GART drivers.This sounds good to me. -- Gerald ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Sat, Sep 04, 2004 at 01:32:10AM -0400, Gerald Britton wrote:> I tested for PSE immediately after the memcpy() at the top of setup_arch() > and it is set there.The code which clears the bit is only run later in the same function. It''s in the ARCH_SETUP macro. But it seems that the changes we make there get lost after start_kernel calls check_bugs() which in turn calls identify_cpu() and resets boot_cpu_data. christian ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Sat, Sep 04, 2004 at 09:31:29AM +0100, Christian Limpach wrote:> The code which clears the bit is only run later in the same function. > It''s in the ARCH_SETUP macro. > > But it seems that the changes we make there get lost after start_kernel > calls check_bugs() which in turn calls identify_cpu() and resets > boot_cpu_data.Aha. Ok. I''ve done a quick hack to clear those bits in identify_cpu() and my system booted up and those flags properly remained disabled. I now nolonger Oops out starting X, instead.. I start X (after the agp and drm modules load successfully), I get a blank screen, my disk is accessed a few times, and the computer reboots. I unfortunately don''t have a serial port on my current test machine, and no crash information was logged, so it looks like this is going to be harder to debug from this point. -- Gerald ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> On Sat, Sep 04, 2004 at 09:31:29AM +0100, Christian Limpach wrote: > > The code which clears the bit is only run later in the same function. > > It''s in the ARCH_SETUP macro. > > > > But it seems that the changes we make there get lost after start_kernel > > calls check_bugs() which in turn calls identify_cpu() and resets > > boot_cpu_data. > > Aha. Ok. I''ve done a quick hack to clear those bits in identify_cpu() and > my system booted up and those flags properly remained disabled. I now > nolonger Oops out starting X, instead.. I start X (after the agp and drm > modules load successfully), I get a blank screen, my disk is accessed a few > times, and the computer reboots. I unfortunately don''t have a serial port > on my current test machine, and no crash information was logged, so it looks > like this is going to be harder to debug from this point. > > -- GeraldIs there anything logged to /var/log/messages? If not then you will definitely need to attach a serial line somehow, or it''ll be impossible to debug. I''ll fix Xen and Xen/Linux for the problems we''ve found so far, and create patches for the GART and DRM drivers. -- Keir ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Sat, Sep 04, 2004 at 09:08:57PM +0100, Keir Fraser wrote:> Is there anything logged to /var/log/messages?Nothing really there unfortunately.> If not then you will definitely need to attach a serial line somehow, > or it''ll be impossible to debug.Yeah. At the moment, my test machine is my laptop, i''ve gotten netconsole to work with it in the past but that would only endup getting me linux crash info, not any Xen info.> I''ll fix Xen and Xen/Linux for the problems we''ve found so far, and > create patches for the GART and DRM drivers.For reference, To get to this point, I''ve had to revert my changes to the agp drivers where i changed virt_to_phys() to virt_to_bus(), they''re not back at virt_to_phys() (it fails in the ioremap()''s otherwise). It''s possible I still have something in an inconsistant and broken state, I''ll have to take a closer look at all the code there. -- Gerald ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
I''ve checked in patches for AGPGART and DRM. You''ll need to apply them manually if you''re having problems (a.k.a. crashes :-) when starting X. To do this: cd linux-2.6.8.1-xen0 ; patch -p1 <../linux-2.6.8.1-patches/*.patch I''m really interested to know (a) if with the patch X works; (b) if not, why not [e.g., crash dump]; (c) if the patch works with Xen, does it also work with native Linux (i.e., have I broken the normal case!). Gerald: my patch has a better chance of working than yours as I also fixed the page-allocation call to definitely return a physically-contiguous extent of memory. If it doesn''t then I gues we''ll have to see whether anyone with a serial line can help. -- Keir> > I''ll fix Xen and Xen/Linux for the problems we''ve found so far, and > > create patches for the GART and DRM drivers. > > For reference, To get to this point, I''ve had to revert my changes to the > agp drivers where i changed virt_to_phys() to virt_to_bus(), they''re not back > at virt_to_phys() (it fails in the ioremap()''s otherwise). It''s possible > I still have something in an inconsistant and broken state, I''ll have to take > a closer look at all the code there. > > -- Gerald >------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Warning: This message has had one or more attachments removed Warning: (xorg.log.xen.agp). Warning: Please read the "FilterNotice.txt" attachment(s) for more information. On Sun, Sep 05, 2004 at 06:26:25AM +0100, Keir Fraser wrote:> I''m really interested to know (a) if with the patch X works; (b) if > not, why not [e.g., crash dump]; (c) if the patch works with Xen, does > it also work with native Linux (i.e., have I broken the normal case!).I needed to fix the asm-i386/agp.h wbinvd, as well as one in arch/i386/mm/pageattr.c After that, The module loaded, and I tried starting X. This resulted in my laptop rebooting (just as my test did). I setup netconsole to see if linux logged anything else before dieing: netconsole: network logging started Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected an Intel 855PM Chipset. agpgart: Maximum main memory to use for agp memory: 440M agpgart: AGP aperture is 256M @ 0xd0000000 [drm] Initialized radeon 1.11.0 20020828 on minor 0: << X starts here >> ioperm not fully supported - set iopl to 3 ioperm not fully supported - ignore resource release ioperm not fully supported - ignore resource release << logging to disk loses here >> agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode So I didn''t really learn much. Ok. I''ve mounted / sync in hopes of gaining more logs from X and I think i''ve made a little progress (attached are the complete xorg logs from a native run (with exec-shield disabled, i''m running fedora), and from within xen. The last few lines are probably the most interesting: diff -u xorg.log.native.no-exec-shield xorg.log.xen.agp . . . (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0" -(II) RADEON(0): [drm] added 8192 byte SAREA at 0x42879000 -(II) RADEON(0): [drm] mapped SAREA 0x42879000 to 0x59307000 +(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe10d4000 +(II) RADEON(0): [drm] mapped SAREA 0xe10d4000 to 0x44306000 (II) RADEON(0): [drm] framebuffer handle = 0xe0000000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f000201 [AGP 0x8086/0x3340; Card 0x1002/0x4c66] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x00000001 (II) RADEON(0): [agp] ring handle = 0xd0000000 -(II) RADEON(0): [agp] Ring mapped at 0x59309000 -(II) RADEON(0): [agp] ring read ptr handle = 0xd0101000 -(II) RADEON(0): [agp] Ring read ptr mapped at 0x5940a000 -(II) RADEON(0): [agp] vertex/indirect buffers handle = 0xd0102000 -(II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x5940b000 -(II) RADEON(0): [agp] GART texture map handle = 0xd0302000 -(II) RADEON(0): [agp] GART Texture map mapped at 0x5960b000 The +''s are Xen, the -''s are Native. The line: (II) RADEON(0): [agp] ring handle = 0xd0000000 Is the last line printed in Xen''s log. Which may suggest where it died. I also noticed the differences in the SAREA addresses. I have just built the same Xen kernel for native x86 and tested that. This seemed to work fine, X started and I had working 3d acceleration. The SAREA address here was a bit closer to what was there before: 2.6.8.1 native -> 2.6.8.1 xen -(II) RADEON(0): [drm] added 8192 byte SAREA at 0xf8834000 -(II) RADEON(0): [drm] mapped SAREA 0xf8834000 to 0x44306000 +(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe10d4000 +(II) RADEON(0): [drm] mapped SAREA 0xe10d4000 to 0x44306000> Gerald: my patch has a better chance of working than yours as I also > fixed the page-allocation call to definitely return a > physically-contiguous extent of memory. If it doesn''t then I gues > we''ll have to see whether anyone with a serial line can help.I''ll hopefully be able to do some testing on my workstation at work (which has a serial port), but I might not be able to do that for a week or so as we''re moving offices this week. -- Gerald
> I needed to fix the asm-i386/agp.h wbinvd, as well as one in > arch/i386/mm/pageattr.cOkay, I''ve fixed those now.> I''ll hopefully be able to do some testing on my workstation at work (which > has a serial port), but I might not be able to do that for a week or so as > we''re moving offices this week.Yes, this is essential to make more progress. It''s probably another silly ioremap() problem, but we can''t fix it if we can''t see it! -- Keir ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel