agp and framebuffer (intelfb) - your milage may vary

agp and framebuffer (intelfb) - your milage may vary

[B.G. Bruce]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

Hi,

with the patches/linux-2.6.9/{agpgart,drm}.patch patches applied
(shouldn't there be a symlink to linux-2.6.10?) and this ultrasimplitic
(and probably WRONG!) patch, I have agp and the intelfb working in
dom0.  I'll try other domains later today an post my results.  I would
appreciate it if someone who knows the xen agp subsystem (in particular
the agp_acquire_backend) better would look over the intelfb.patch and
post any improvements (I don't like taking out the checks made on
agp_acquire_backend(), but with them left in, I get "intelfb: cannot
acquire agp").

Thanks,
B.

[-- Attachment #2: intelfb.patch --]
[-- Type: text/x-patch, Size: 691 bytes --]

diff -Naur linux-xen/drivers/video/intelfb.orig/intelfbdrv.c linux-xen/drivers/video/intelfb/intelfbdrv.c
--- linux-xen/drivers/video/intelfb.orig/intelfbdrv.c	2005-01-26 12:04:02.000000000 -0400
+++ linux-xen/drivers/video/intelfb/intelfbdrv.c	2005-01-26 12:49:28.000000000 -0400
@@ -605,11 +605,12 @@
 	}
 
 	/* Use agpgart to manage the GATT */
-	if (agp_backend_acquire()) {
-		ERR_MSG("cannot acquire agp\n");
-		cleanup(dinfo);
-		return -ENODEV;
-	}
+	agp_backend_acquire();
+/*	if (agp_backend_acquire()) {
+*		ERR_MSG("cannot acquire agp\n");
+*		cleanup(dinfo);
+*		return -ENODEV;
+*	} */
 
 	/* get the current gatt info */
 	if (agp_copy_info(&gtt_info)) {

RE: agp and framebuffer (intelfb) - your milage may vary

[Ian Pratt]

> with the patches/linux-2.6.9/{agpgart,drm}.patch patches applied
> (shouldn't there be a symlink to linux-2.6.10?) 

There's an argument that we should automatically apply these patches and
build AGP and DRM support as modules for our xen0 kernels. It would be
good to know which drivers have actually been tested and work.

Rik: did you have any luck feeding the agpgart and drm patches up
stream? 

> I would
> appreciate it if someone who knows the xen agp subsystem (in 
> particular
> the agp_acquire_backend) better would look over the intelfb.patch and
> post any improvements (I don't like taking out the checks made on
> agp_acquire_backend(), but with them left in, I get "intelfb: cannot
> acquire agp").

Which of the error codes is it returning? There's nothing special about
AGP support on arch xen, its just that Xen is rather stricter about what
drivers are allowed to get away with, requring some fixes.

int agp_backend_acquire(void)
{
        if (agp_bridge->type == NOT_SUPPORTED)
                return -EINVAL;
        if (atomic_read(&agp_bridge->agp_in_use))
                return -EBUSY;
        atomic_inc(&agp_bridge->agp_in_use);
        return 0;
}

Ian


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

RE: agp and framebuffer (intelfb) - your milage may vary

[B.G. Bruce]

On Fri, 2005-01-28 at 04:43, Ian Pratt wrote:
> > with the patches/linux-2.6.9/{agpgart,drm}.patch patches applied
> > (shouldn't there be a symlink to linux-2.6.10?) 
> 
> There's an argument that we should automatically apply these patches and
> build AGP and DRM support as modules for our xen0 kernels. It would be
> good to know which drivers have actually been tested and work.
> 
> Rik: did you have any luck feeding the agpgart and drm patches up
> stream? 
> 
> > I would
> > appreciate it if someone who knows the xen agp subsystem (in 
> > particular
> > the agp_acquire_backend) better would look over the intelfb.patch and
> > post any improvements (I don't like taking out the checks made on
> > agp_acquire_backend(), but with them left in, I get "intelfb: cannot
> > acquire agp").
> 
> Which of the error codes is it returning? There's nothing special about
> AGP support on arch xen, its just that Xen is rather stricter about what
> drivers are allowed to get away with, requring some fixes.
> 
> int agp_backend_acquire(void)
> {
>         if (agp_bridge->type == NOT_SUPPORTED)
>                 return -EINVAL;
>         if (atomic_read(&agp_bridge->agp_in_use))
>                 return -EBUSY;
>         atomic_inc(&agp_bridge->agp_in_use);
>         return 0;
> }
> 
> Ian

Yes, it it - which is why I'm confused why the intelfb (unpateched)
works fine on a non xen environment, but fails under xen.  Obviously,
what is being returned from agp_backend_acquire() is different, however
if the test on the return is removed, the driver loads and functions
normally.  With the tests in place, the driver still loads, but reports
"cannot acquire agp" and you cannot "use" the intelfb even though a
lsmod shows it hooked in.

+/*     if (agp_backend_acquire()) {
+*              ERR_MSG("cannot acquire agp\n");
+*              cleanup(dinfo);
+*              return -ENODEV;
+*      } */

Obviously, what agp_backen_acquire is returning has changed, but it can
only be one of (-EINVAL,-EBUSY,0).  Which one will xen be feeding it?

B.

> 
> -------------------------------------------------------
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 


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

RE: agp and framebuffer (intelfb) - your milage may vary

[B.G. Bruce]

Well, you can forget the patch - ti's not needed.  I don't know what I
was doing wrong, but a rebuild from scratch today (same versions of
everything) and it works correctly WITHOUT the patch.  Wednesday, when I
did this (again from scratch)I needed the patch.  I must be losing my
mind, however you can add the intelfb with a 865g chipset to your list
of known working.  It didn't make much sense to me from the start, so
I'll write it off to user error/stupidity on my part.

B.


On Fri, 2005-01-28 at 04:43, Ian Pratt wrote:
> > with the patches/linux-2.6.9/{agpgart,drm}.patch patches applied
> > (shouldn't there be a symlink to linux-2.6.10?) 
> 
> There's an argument that we should automatically apply these patches and
> build AGP and DRM support as modules for our xen0 kernels. It would be
> good to know which drivers have actually been tested and work.
> 
> Rik: did you have any luck feeding the agpgart and drm patches up
> stream? 
> 
> > I would
> > appreciate it if someone who knows the xen agp subsystem (in 
> > particular
> > the agp_acquire_backend) better would look over the intelfb.patch and
> > post any improvements (I don't like taking out the checks made on
> > agp_acquire_backend(), but with them left in, I get "intelfb: cannot
> > acquire agp").
> 
> Which of the error codes is it returning? There's nothing special about
> AGP support on arch xen, its just that Xen is rather stricter about what
> drivers are allowed to get away with, requring some fixes.
> 
> int agp_backend_acquire(void)
> {
>         if (agp_bridge->type == NOT_SUPPORTED)
>                 return -EINVAL;
>         if (atomic_read(&agp_bridge->agp_in_use))
>                 return -EBUSY;
>         atomic_inc(&agp_bridge->agp_in_use);
>         return 0;
> }
> 
> Ian
> 
> 
> -------------------------------------------------------
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 


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

Re: agp and framebuffer (intelfb) - your milage may vary

[Jacob Gorm Hansen]

Ian Pratt wrote:
>>with the patches/linux-2.6.9/{agpgart,drm}.patch patches applied
>>(shouldn't there be a symlink to linux-2.6.10?) 
> 
> 
> There's an argument that we should automatically apply these patches and
> build AGP and DRM support as modules for our xen0 kernels. It would be
> good to know which drivers have actually been tested and work.
> 
> Rik: did you have any luck feeding the agpgart and drm patches up
> stream? 

After applying the agp patch (apparently no drm patch in the unstable 
tree?), I have both kernel framebuffer and X with opengl running on my 
Intel-845G testbox. I am getting an ATI Radeon card one of these days, 
and will see if that works also.

I would like to link the domU framebuffer to an OpenGL surface in dom0. 
Is anyone working on something similar?

I suppose I need to set up an event channel for update notifications, 
and find a way of negotiating some shared memory between the domains.

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

RE: agp and framebuffer (intelfb) - your milage may vary

[Ian Pratt]

If you apply the agp.patch, I'd be interested to know if this issue is
now fixed.

I think there's a pretty good argument for applying the patch be default
now...

Ian

> with the patches/linux-2.6.9/{agpgart,drm}.patch patches applied
> (shouldn't there be a symlink to linux-2.6.10?) and this 
> ultrasimplitic
> (and probably WRONG!) patch, I have agp and the intelfb working in
> dom0.  I'll try other domains later today an post my results.  I would
> appreciate it if someone who knows the xen agp subsystem (in 
> particular
> the agp_acquire_backend) better would look over the intelfb.patch and
> post any improvements (I don't like taking out the checks made on
> agp_acquire_backend(), but with them left in, I get "intelfb: cannot
> acquire agp").
> 
> Thanks,
> B.
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

RE: agp and framebuffer (intelfb) - your milage may vary

[B.G. Bruce]

Yes, my issue has disappeared and at least for me the agp patch works
great.

B.

On Tue, 2005-02-08 at 21:18, Ian Pratt wrote:
> If you apply the agp.patch, I'd be interested to know if this issue is
> now fixed.
> 
> I think there's a pretty good argument for applying the patch be default
> now...
> 
> Ian
> 
> > with the patches/linux-2.6.9/{agpgart,drm}.patch patches applied
> > (shouldn't there be a symlink to linux-2.6.10?) and this 
> > ultrasimplitic
> > (and probably WRONG!) patch, I have agp and the intelfb working in
> > dom0.  I'll try other domains later today an post my results.  I would
> > appreciate it if someone who knows the xen agp subsystem (in 
> > particular
> > the agp_acquire_backend) better would look over the intelfb.patch and
> > post any improvements (I don't like taking out the checks made on
> > agp_acquire_backend(), but with them left in, I get "intelfb: cannot
> > acquire agp").
> > 
> > Thanks,
> > B.
> > 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: agp and framebuffer (intelfb) - your milage may vary

[Jacob Gorm Hansen]

Ian Pratt wrote:
> If you apply the agp.patch, I'd be interested to know if this issue is
> now fixed.
> 
> I think there's a pretty good argument for applying the patch be default
> now...

I agree, my machine has been running an OpenGL demo on top of this for 
24+ hours now :-)

Jacob


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click