Bug 14

Sorry, 2.5.47-ac3 not 2.5.47-ac1

Does this work if you load the agpgart module with agp_try_unsupported=1
as the dmesg output suggests ?
If so, it's a simple matter of adding the ID's

So a 

modprobe agpgart agp_try_unsupported=1

is what you suggest ? Because I did add agp_try_unsupported=1 to the boot
options without any change.

And with the state of modules in 2.5 bk I wasn't too keen on trying modules.
(plus in my experience a good monolithic kernel is much friendlier than trying
to grok modules.conf:)

Would a test on a recent ac patch be ok (i.e. before module mess) ? What version
would you suggest I test ?

[ Rehash, didn't dj was not on this bug cc list yet ]

So a 

modprobe agpgart agp_try_unsupported=1

is what you suggest ? Because I did add agp_try_unsupported=1 to the boot
options without any change.

And with the state of modules in 2.5 bk I wasn't too keen on trying modules.
(plus in my experience a good monolithic kernel is much friendlier than trying
to grok modules.conf:)

Would a test on a recent ac patch be ok (i.e. before module mess) ? What version
would you suggest I test ?

Dave -- Would you like to be the owner of this bug?  If so, then one more
favor:  would you like to be the default owner for Video?  Thanks.

>So a modprobe agpgart agp_try_unsupported=1
> is what you suggest ? Because I did add agp_try_unsupported=1 to the boot
> options without any change.

Its not a bootflag (it should be, but thats a seperate bug)

> Would a test on a recent ac patch be ok (i.e. before module mess) ? What 
> version would you suggest I test ?

Given that modules are a bit 'flaky' right now, go for 2.5.47-ac

> Dave -- Would you like to be the owner of this bug?

Sure.

> If so, then one more favor:
> would you like to be the default owner for Video?

No thanks. I've a passing interest in agpgart (mostly due to having hacked on it
quite a bit in the last months, and lack of updates from actual maintainer), but
other video stuff probably belongs to James Simmons (framebuffer) and the DRI folks.

I will try latest -ac modular this evening then.

Thank you for taking a look at this bug.

It says (on 2.5.47-ac6) :

Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: Trying generic Via routines for device id: 3189
agpgart: AGP aperture is 128M @ 0xd0000000
[drm] AGP 0.99 on VIA @ 0xd0000000 128MB
[drm] Initialized mga 3.0.2 20010321 on minor 0
[drm] Module unloaded

And X seems to like agp afterwards :
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmGetBusid returned ''
(II) MGA(0): [drm] created "mga" driver at busid "PCI:1:0:0"
(II) MGA(0): [drm] added 8192 byte SAREA at 0xe08e1000
(II) MGA(0): [drm] mapped SAREA 0xe08e1000 to 0x40018000
(II) MGA(0): [drm] framebuffer handle = 0xd8000000
(II) MGA(0): [drm] added 1 reserved context for kernel
(II) MGA(0): [agp] Mode 0x1f000207 [AGP 0x1106/0x3189; Card 0x102b/0x0525]
(II) MGA(0): [agp] 12288 kB allocated with handle 0xe28e5000
(II) MGA(0): [agp] WARP microcode handle = 0xd0000000
(II) MGA(0): [agp] WARP microcode mapped at 0x4001a000
(II) MGA(0): [agp] Primary DMA handle = 0xd0008000
(II) MGA(0): [agp] Primary DMA mapped at 0x408e8000
(II) MGA(0): [agp] DMA buffers handle = 0xd0108000
(II) MGA(0): [agp] DMA buffers mapped at 0x409e8000
(II) MGA(0): [drm] Added 128 65536 byte DMA buffers
(II) MGA(0): [agp] agpTexture handle = 0xd0908000
(II) MGA(0): [agp] agpTexture size: 2816 kb
(II) MGA(0): [drm] Registers handle = 0xda000000
(II) MGA(0): [drm] Status handle = 0xe28ee000
(II) MGA(0): [agp] Status page mapped at 0x40022000
(II) MGA(0): [dri] visual configs initialized
(II) MGA(0): Memory manager initialized to (0,0) (1280,2047)
(II) MGA(0): Largest offscreen area available: 1280 x 1023
(II) MGA(0): Reserved back buffer at offset 0xa00000
(II) MGA(0): Reserved depth buffer at offset 0xf00000
(II) MGA(0): Reserved 12288 kb for textures at offset 0x1400000
(II) MGA(0): Using XFree86 Acceleration Architecture (XAA)

(didn't test it much, forgot to add vga console and broke the mga one when
modularizing it:)

So if I understand well one only need to add a pci id to a list somewhere to
build hassle-free kernels now ?

Looks Ok. If it really does work (try either a 3d app, or dig out testgart)
then yes, just adding the relevant IDs to the AGP driver would do the trick.

Created attachment 20 [details]
KT400 agp support patch

Since I'm of an optimistic nature (and have no love lost for modules) I wrote
this patch, rebooted and it seems to have just worked.

At least I couldn't find a GL screensaver that would lockup the system (using
xscreensaver-4.06-3, didn't realise there were so many of them, didn't get
superquadrics to work with this card dince the utah-glx days:)

Should I send this patch to someone in particular ? Or can you take care of it ?

Or maybe, I should try some other test before ?

patch looks good. Send it direct to Linus. Cc: Alan@redhat.com
I'll also pick it up in case it gets dropped.
Thanks for experimenting 8-)

In 2.5.49
(I've been asked to do the 2.4 patch as well)

Reopening this sucker just so I can see what I have on my plate.
The KT400 has two modes of operation.
It has an AGP 2.0 compatability mode (which works when you plug in a 2.0 card).
The 3.0 mode however is borked right now and needs work. I have the docs from
VIA,  and am waiting on a test board to play with.

The 2.4 patch needs going over at some point to abort nicely if agp 3.0 is detected.

There's some test code in 2.5 for a week or so now. I can't get my KT400 box
stable enough to actually test it. Please let me know how things are looking
these days..

I can't even confirm if it still works for agp2 since matrox handling is
currently broken in 2.5:(

Now tested on two different KT400 boxes. The code in agpgart bk tree
(bk://linux-dj.bkbits.net/agpgart) works fine in AGP3.0 mode.
This will go to Linus when he gets back.

The referenced KT400 code was incorporated into 2.5.62.  This bug is now closed.

*** Bug 15224 has been marked as a duplicate of this bug. ***