I recently upgraded to a m/board using the KT400 chipset - specifically
an Abit KD7-G - and now find that I can't load agpgart. The relevant
kernel messages:
agpgart: Maximum main memory to use for agp memory: 941M
agpgart: Detected Via Apollo Pro KT400 chipset
agpgart: unable to determine aperture size.
This results in my inability to load XFree86, using the proprietary ATI
drivers, which appear to require AGP support. Note that the same
problem appears using ATI's "internal agpgart module", just to show I
know the difference. The regular XFree86 drivers probably work without
AGP - I haven't bothered trying yet.
NB: I tried sending this to Jeff Hartmann, but his address at
precisioninsight.com is dead. Please CC me, I'm not subscribed to the
list. Better still, refer me to someone who actually knows what to do
about it.
The BIOS is set up for either a 256MB or 64MB AGP aperture - whichever
of the two settings makes no difference. The video card is a Radeon
9700 Pro, 128MB. The kernel configuration includes ACPI and
HIGHMEM-4GB support, if that is at all relevant.
This problem is identically present in 2.4.21 and 2.4.22-rc2.
I can provide extra information as needed, just ask. I have a feeling
someone's going to ask me for lspci output, but I'll leave that until
someone who knows what they're doing asks me.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [email protected]
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
On Thu, Aug 14, 2003 at 07:38:15PM +0100, Jonathan Morton wrote:
> I recently upgraded to a m/board using the KT400 chipset - specifically
> an Abit KD7-G - and now find that I can't load agpgart. The relevant
> kernel messages:
>
> agpgart: Maximum main memory to use for agp memory: 941M
> agpgart: Detected Via Apollo Pro KT400 chipset
> agpgart: unable to determine aperture size.
>
> This results in my inability to load XFree86, using the proprietary ATI
> drivers, which appear to require AGP support. Note that the same
> problem appears using ATI's "internal agpgart module", just to show I
> know the difference. The regular XFree86 drivers probably work without
> AGP - I haven't bothered trying yet.
>
> NB: I tried sending this to Jeff Hartmann, but his address at
> precisioninsight.com is dead. Please CC me, I'm not subscribed to the
> list. Better still, refer me to someone who actually knows what to do
> about it.
>
> The BIOS is set up for either a 256MB or 64MB AGP aperture - whichever
> of the two settings makes no difference. The video card is a Radeon
> 9700 Pro, 128MB. The kernel configuration includes ACPI and
> HIGHMEM-4GB support, if that is at all relevant.
>
> This problem is identically present in 2.4.21 and 2.4.22-rc2.
For 2.4, you're stuck. It needs AGP3 support. The KT400 stuff in
2.4 only works if you shove an AGP2.x gfx card in the slot.
As soon as you put a 3.x capable card in there the chipset changes
mode, and as there's no AGP3 support in 2.4 yet, you're pooched.
The code in 2.6test should work, but before you (or anyone else) asks,
no, it won't work without a bit of bending in 2.4, and I don't have
a backport, or plans to do so any time soon.
Sorry,
Dave
--
Dave Jones http://www.codemonkey.org.uk
>> agpgart: unable to determine aperture size.
> For 2.4, you're stuck. It needs AGP3 support. The KT400 stuff in
> 2.4 only works if you shove an AGP2.x gfx card in the slot.
> As soon as you put a 3.x capable card in there the chipset changes
> mode, and as there's no AGP3 support in 2.4 yet, you're pooched.
Damn.
Maybe I'd better try and see how well 2.6 works for me. I'm guessing
it's at least semistable, since the version number has changed.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [email protected]
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
Dave Jones wrote:
> On Thu, Aug 14, 2003 at 07:38:15PM +0100, Jonathan Morton wrote:
> > I recently upgraded to a m/board using the KT400 chipset - specifically
> > an Abit KD7-G - and now find that I can't load agpgart. The relevant
> > kernel messages:
> >
> > agpgart: Maximum main memory to use for agp memory: 941M
> > agpgart: Detected Via Apollo Pro KT400 chipset
> > agpgart: unable to determine aperture size.
> >
> > This results in my inability to load XFree86, using the proprietary ATI
> > drivers, which appear to require AGP support. Note that the same
> > problem appears using ATI's "internal agpgart module", just to show I
> > know the difference. The regular XFree86 drivers probably work without
> > AGP - I haven't bothered trying yet.
> >
> > NB: I tried sending this to Jeff Hartmann, but his address at
> > precisioninsight.com is dead. Please CC me, I'm not subscribed to the
> > list. Better still, refer me to someone who actually knows what to do
> > about it.
> >
> > The BIOS is set up for either a 256MB or 64MB AGP aperture - whichever
> > of the two settings makes no difference. The video card is a Radeon
> > 9700 Pro, 128MB. The kernel configuration includes ACPI and
> > HIGHMEM-4GB support, if that is at all relevant.
> >
> > This problem is identically present in 2.4.21 and 2.4.22-rc2.
>
> For 2.4, you're stuck. It needs AGP3 support. The KT400 stuff in
> 2.4 only works if you shove an AGP2.x gfx card in the slot.
> As soon as you put a 3.x capable card in there the chipset changes
> mode, and as there's no AGP3 support in 2.4 yet, you're pooched.
>
> The code in 2.6test should work, but before you (or anyone else) asks,
> no, it won't work without a bit of bending in 2.4, and I don't have
> a backport, or plans to do so any time soon.
>
> Sorry,
>
> Dave
>
Dave,
I'd like to apologise in advance if I seem too pushy, and I know you all
have more than enough to do:
But this seems to be a pretty big thing to leave out of the production
Kernel. Unless Red Hat and other distros are planning to use 2.6 in
their next release, there are a lot of these KT400 MBs out there. My
local computer reseller was selling 10 to 20 of these boards for every
one of any other AMD chipset right up until VIA released the KT600.
I am actually using the KT-400-A variant of this board, which has no
option to use anything but agp 3.0 even with a 4X card. (straight from
the mouths of Giga-byte tech support)
Yes, I could use 2.6-x and help test that, but like so many people, I
need to have something reliable so I can get some work done.
If I knew anything at all about writing code, I would be more than happy
to help, but since I don't, I'd like to offer my time to help test any
patches or backports someone could come up with.
Thanks,
--
Robert Toole
[email protected]
> But this seems to be a pretty big thing to leave out of the production
> Kernel. Unless Red Hat and other distros are planning to use 2.6 in
> their next release, there are a lot of these KT400 MBs out there. My
> local computer reseller was selling 10 to 20 of these boards for every
> one of any other AMD chipset right up until VIA released the KT600.
This, I think, is a pretty good point.
Surely it's not too big a job to get basic, generic AGP3 support into
2.4, even if it's not optimised? If it's non-trivial to make all AGP3
features work in 2.4, then it's reasonable to require 2.6 for "better
performance".
To be honest, I'd at least expect a fallback to AGP2 for hardware that
can support it, such as KT400. The Windows drivers for my ATI card can
tell the hardware to drop to "AGP 4x" (which I believe implies AGP2 - I
could be wrong), and the card *did* work correctly with the KT266A
chipset I was using before.
> Yes, I could use 2.6-x and help test that, but like so many people, I
> need to have something reliable so I can get some work done.
FWIW, I installed 2.6.0-test3 and it seems to work well. After
grabbing a later version of the ATI drivers (which are needed for 2.6
compatibility), the AGP was set up correctly and I'm back in X. I'm
not seeing any stability problems so far.
However, I did encounter a compilation problem with one of the USB
device drivers - not a major problem at present since that particular
device is attached to a different machine - but it does show that 2.6
isn't ready for primetime yet. The major distros aren't going to make
that switch for a while.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [email protected]
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
>> However, I did encounter a compilation problem with one of the USB
>> device drivers - not a major problem at present since that particular
>> device is attached to a different machine - but it does show that 2.6
>> isn't ready for primetime yet. The major distros aren't going to make
>> that switch for a while.
>
> Which device driver?
> What was the error?
> Did you report it anywhere?
OV511 - it looks like it's an "old driver, new kernel" compatibility
thing. I haven't reported it yet, got other things on my plate,
including what appear to be routing loops within my ISP.
Since I know who the maintainer is, I'll probably report it directly to
him when I get a chance.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [email protected]
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
On Fri, Aug 15, 2003 at 02:42:33AM +0100, Jonathan Morton wrote:
>
> However, I did encounter a compilation problem with one of the USB
> device drivers - not a major problem at present since that particular
> device is attached to a different machine - but it does show that 2.6
> isn't ready for primetime yet. The major distros aren't going to make
> that switch for a while.
Which device driver?
What was the error?
Did you report it anywhere?
greg k-h
On Fri, Aug 15, 2003 at 02:42:33AM +0100, Jonathan Morton wrote:
> Surely it's not too big a job to get basic, generic AGP3 support into
> 2.4, even if it's not optimised? If it's non-trivial to make all AGP3
> features work in 2.4, then it's reasonable to require 2.6 for "better
> performance".
It's more a maintenance burden. The 2.4 code is *shit*.
If I was to be doing any amount of work on that code, I'd want the
cleanups that came with the work I did in 2.6 too.
Bending all the infrastructure in 2.6 to fit 2.4, testing, debugging etc
is at least a few evenings work. I'm just one guy. Unless Red Hat
decide that AGP3 is something they really really must have for some
future 2.4 release, it isn't going to happen by me. Period.
I'm just up to my eyes in other work.
> To be honest, I'd at least expect a fallback to AGP2 for hardware that
> can support it, such as KT400. The Windows drivers for my ATI card can
> tell the hardware to drop to "AGP 4x" (which I believe implies AGP2 - I
> could be wrong), and the card *did* work correctly with the KT266A
> chipset I was using before.
Nope. You can do X4 in AGP3 mode, which is different from X4 in AGP2.
> However, I did encounter a compilation problem with one of the USB
> device drivers - not a major problem at present since that particular
> device is attached to a different machine - but it does show that 2.6
> isn't ready for primetime yet. The major distros aren't going to make
> that switch for a while.
Several distros (Red Hat included) have 2.6 based kernel packages for
people to test with, which takes the pain off of compilation issues
for most users.
Dave
--
Dave Jones http://www.codemonkey.org.uk
On Fri, Aug 15, 2003 at 11:57:33AM +0100, Dave Jones wrote:
> is at least a few evenings work. I'm just one guy. Unless Red Hat
> decide that AGP3 is something they really really must have for some
> future 2.4 release, it isn't going to happen by me. Period.
> I'm just up to my eyes in other work.
Red Hat has merged the crap AGP3 patches for 2.4 in AS3.0 at least..
On Fri, Aug 15, 2003 at 12:40:55PM +0100, Christoph Hellwig wrote:
> On Fri, Aug 15, 2003 at 11:57:33AM +0100, Dave Jones wrote:
> > is at least a few evenings work. I'm just one guy. Unless Red Hat
> > decide that AGP3 is something they really really must have for some
> > future 2.4 release, it isn't going to happen by me. Period.
> > I'm just up to my eyes in other work.
>
> Red Hat has merged the crap AGP3 patches for 2.4 in AS3.0 at least..
*nod*. It doesn't buy you anything for AGP3 chipsets other than
Intel E7x05 however, and as history has shown in 2.5, it wasn't
the 'generic' be-all-end-all answer to AGP3 support.
Dave
--
Dave Jones http://www.codemonkey.org.uk
>>> Yes, I could use 2.6-x and help test that, but like so many people, I
>>> need to have something reliable so I can get some work done.
>>
>> FWIW, I installed 2.6.0-test3 and it seems to work well. After
>> grabbing a later version of the ATI drivers (which are needed for 2.6
>> compatibility), the AGP was set up correctly and I'm back in X. I'm
>> not seeing any stability problems so far.
>
> How did you get the ATI drivers to build with the 2.6 kernel?
> I got all kinds of nasty errors when I tried them. Are you
> using the Schneider drivers, which version?
Dunno what they're called, but I'm using Gentoo Linux, which has
reached 4.3.0-3.2.0 in terms of ATI fglrx drivers. The tarball can be
downloaded from Gentoo mirrors, but apparently not from ATI themselves.
That version compiles and works with 2.6, although I'm seeing some
unclean behaviour that really should be fixed.
I'm copying this to the list, because this is at least the second
request I've had on this subject.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [email protected]
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
On Fri, Aug 15, 2003 at 05:55:50AM +0100, Jonathan Morton wrote:
> >>However, I did encounter a compilation problem with one of the USB
> >>device drivers - not a major problem at present since that particular
> >>device is attached to a different machine - but it does show that 2.6
> >>isn't ready for primetime yet. The major distros aren't going to make
> >>that switch for a while.
> >
> >Which device driver?
> >What was the error?
> >Did you report it anywhere?
>
> OV511 - it looks like it's an "old driver, new kernel" compatibility
> thing. I haven't reported it yet, got other things on my plate,
> including what appear to be routing loops within my ISP.
>
> Since I know who the maintainer is, I'll probably report it directly to
> him when I get a chance.
Look at the latest -bk tree, it has an updated for this driver.
thanks,
greg k-h