Bug 14 - No dri : unsupported Via chipset (device id: 3189)
Summary: No dri : unsupported Via chipset (device id: 3189)
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(AGP) (show other bugs)
Hardware: IA-32 Linux
: P2 normal
Assignee: Dave Jones
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-11-14 12:11 UTC by Nicolas Mailhot
Modified: 2010-02-04 19:34 UTC (History)
3 users (show)

See Also:
Kernel Version:
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
KT400 agp support patch (1.61 KB, text/plain)
2002-11-20 14:39 UTC, Nicolas Mailhot
Details

Description Nicolas Mailhot 2002-11-14 12:11:29 UTC
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
Comment 1 Nicolas Mailhot 2002-11-14 12:20:09 UTC
Sorry, 2.5.47-ac3 not 2.5.47-ac1
Comment 2 Dave Jones 2002-11-19 07:05:39 UTC
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
Comment 3 Nicolas Mailhot 2002-11-19 07:52:08 UTC
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 ?
Comment 4 Nicolas Mailhot 2002-11-19 08:01:27 UTC
[ 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 ?
Comment 5 Khoa Huynh 2002-11-19 09:11:57 UTC
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.
Comment 6 Dave Jones 2002-11-20 07:47:15 UTC
>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.
Comment 7 Nicolas Mailhot 2002-11-20 08:09:43 UTC
I will try latest -ac modular this evening then.

Thank you for taking a look at this bug.
Comment 8 Nicolas Mailhot 2002-11-20 11:19:21 UTC
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 ?
Comment 9 Dave Jones 2002-11-20 11:41:06 UTC
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.
Comment 10 Nicolas Mailhot 2002-11-20 14:39:19 UTC
Created attachment 20 [details]
KT400 agp support patch
Comment 11 Nicolas Mailhot 2002-11-20 14:45:23 UTC
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 ?
Comment 12 Dave Jones 2002-11-20 15:48:59 UTC
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-)
Comment 13 Nicolas Mailhot 2002-11-23 03:27:24 UTC
In 2.5.49
(I've been asked to do the 2.4 patch as well)
Comment 14 Dave Jones 2002-12-19 02:32:13 UTC
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.
Comment 15 Dave Jones 2003-01-13 11:59:20 UTC
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..
Comment 16 Nicolas Mailhot 2003-01-15 02:13:48 UTC
I can't even confirm if it still works for agp2 since matrox handling is
currently broken in 2.5:(
Comment 17 Dave Jones 2003-01-21 07:31:02 UTC
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.
Comment 18 Thomas Molina 2003-02-21 04:14:07 UTC
The referenced KT400 code was incorporated into 2.5.62.  This bug is now closed.
Comment 19 Rafael J. Wysocki 2010-02-04 19:34:40 UTC
*** Bug 15224 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.