Exact Kernel version: 2.5.47-ac1 Kernel command line: ro root=/dev/hdc1 agp_try_unsupported=1 video=matrox:vesa:0x11B,fh:96,fv:160 Distribution: Red Hat Rawhide Hardware Environment: Gigabyte GA -7VAX http://www.giga-byte.com/products/7vax.htm Northbridge : VIA KT400 Southbridge : VIA 8235 latest bios + mga G400 On boot : Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 439M agpgart: Unsupported Via chipset (device id: 3189), you might want to try agp_try_unsupported=1. agpgart: no supported devices found. [drm:drm_init] *ERROR* Cannot initialize the agpgart module. Uninitialised timer! This is just a warning. Your computer is OK function=0x00000000, data=0x0 Call Trace: [<c0122ce4>] check_timer_failed+0x64/0x70 [<c0122fe1>] del_timer+0x21/0x90 [<c01e0e20>] mga_takedown+0x60/0x380 [<c01e58e2>] mga_stub_unregister+0x32/0x11d [<c010508d>] init+0x3d/0x160 [<c0105050>] init+0x0/0x160 [<c0107435>] kernel_thread_helper+0x5/0x10
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. ***