A bombshell arrives...

[dlaird]

Good morning, Netizenz...

Quoted from the front page(s) of Linux dot com this morning:

"DistroWatch, which tracks more than 200 different flavors of Linux, lists
47 distros based on Debian. Debian's rep for being a tough install is belied
by the fact that distributions based on Debian are often the easiest of
Linux distributions to use and maintain. In the coming weeks, we're going to
take a look at several of the most interesting of Debian's descendants,
evaluating them on installation, connectivity, software maintenance,
security, and support. We'll begin the series with a look at LindowsOS 4.5."

New knowledge! New knowledge! Debian is the easiest to use and maintain.
James, it's time you stepped forward and tell us the straight scoop about
this statement. Is this *true*? 8-)

Dave

[James Vahn]

Post by dlaird
New knowledge! New knowledge! Debian is the easiest to use and maintain.
James, it's time you stepped forward and tell us the straight scoop about
this statement. Is this *true*? 8-)

Sometimes it makes me feel like the Maytag man.

--

[dlaird]

Good morning, O Maytag One...

Post by James Vahn

Post by dlaird
New knowledge! New knowledge! Debian is the easiest to use and maintain.
James, it's time you stepped forward and tell us the straight scoop about
this statement. Is this *true*? 8-)

Sometimes it makes me feel like the Maytag man.

Incredibly enough, without so much as a day to study the documentation, this
is day 6 of having Debian running as a server on an old Pentium box I had
laying around, and it hasn't *crashed* yet. What I did was actually follow
Rule #139 of the Bob-a-Doo list of rules and guidelines for running Linux,
to wit:

"when in doubt, simply load the operating system, the C compiler, a
reasonably good version of Make and the various other platform-independent
utilities necessary to make it work. Once you have it functional, as such,
then load *ONLY* the application-layer programs from source code which will
be used on the server, and then sit down and resist the temptation to add
more."

Well, that's what I finally did...with some embellishments, such as
installing X-Windows, but I quickly realized I had violated the Bob-a-doo
rules since running XWindows on a server is redundant and a waste of
valuable memory and disk resources. However, with the third reload of the
test bench server under Debian I simply loaded only those parts I needed,
per the above, and a copy of the sources for the most current OpenSSH,
OpenSSL, INN and Sendmail servers. Hell, it's a virtual work of art, and it
done 100% from scratch.

As I said, it hasn't crashed yet. Once in awhile I walk over and let it talk
to the network, which it does without revealing any faults, other than I
haven't been able to get it to load and run the 2.6.0 kernel yet. However,
in its defense, I haven't been able to do *THAT* with any distribution,
including RedHat, but that kernel does hold great promise.

I think I could almost get used to it. 8-)

Dave

[James Vahn]

Post by dlaird
"when in doubt, simply load the operating system, the C compiler, a
reasonably good version of Make and the various other platform-independent
utilities necessary to make it work. Once you have it functional, as such,
then load *ONLY* the application-layer programs from source code which will
be used on the server, and then sit down and resist the temptation to add
more."

And then remove the compiler. Get to know "debfoster".

Actually I have no idea why he suggests compiling them. I beg to
differ. With a proper distro, you would lose the advantage of package
management and having a uniform and easily maintainable system. People
who know more than you and I have put those packages together.

Post by dlaird
Well, that's what I finally did...with some embellishments, such as
installing X-Windows, but I quickly realized I had violated the Bob-a-doo
rules since running XWindows on a server is redundant and a waste of
valuable memory and disk resources. However, with the third reload of the
test bench server under Debian I simply loaded only those parts I needed,
per the above, and a copy of the sources for the most current OpenSSH,
OpenSSL, INN and Sendmail servers. Hell, it's a virtual work of art, and it
done 100% from scratch.

Have I mentioned these before?

apt-get build-dep inn2 -t unstable
apt-get -b source inn2 -t unstable

The first line installs everything needed to compile INN. The second
line downloads the source code, compiles and installs the packages.

Optionally, leave out the "-b" and it will just unpack the source and
allow you to enable/change <whatever>, then run

debian/rules build
debian/rules binary
dpkg -i ../*.deb

Put a hold on those with "echo inn2 hold | dpkg --set-selections" and
they won't be automatically upgraded on down the road.

Post by dlaird
As I said, it hasn't crashed yet.

Why would it crash? Debian "testing" and "unstable" are nouns, not
verbs. What usually happens are packaging errors - failed dependancies
and that sort of thing.

Post by dlaird
Once in awhile I walk over and let it talk to the network, which it
does without revealing any faults, other than I haven't been able to
get it to load and run the 2.6.0 kernel yet.

I don't think that 2.6.0 kernel has a whole lot going for it anyway,
same old VIA IDE-DMA bugs, SiS AGP omissions, bandwidth hogging, poor
drive remapping, etc etc etc.


--

[dlaird]

Good evening, James...

Post by James Vahn
And then remove the compiler. Get to know "debfoster".

But I have a somewhat "customized" version of the Jed Editor which I use,
both here at home and at the office. It looks and plays just like using
Wordstar complete with a working thesaurus. It took me nearly six weeks to
get the thesaurus working with Jed's command line, but now that I've got it
working, I can't let go. So I need gcc to compile the source.

Post by James Vahn
Actually I have no idea why he suggests compiling them. I beg to
differ. With a proper distro, you would lose the advantage of package
management and having a uniform and easily maintainable system. People
who know more than you and I have put those packages together.

I think that rule comes from back when the RPM packaging was a bit more
unstable than what we have now. I remember that he uses packages now,
instead of compiling from source all the time. I would sure hate to try to
compile KDE, including all its gadgets, from source. The dependency list
alone would drive me bonkers!

Post by James Vahn
Have I mentioned these before?
apt-get build-dep inn2 -t unstable
apt-get -b source inn2 -t unstable
The first line installs everything needed to compile INN. The second
line downloads the source code, compiles and installs the packages.
Optionally, leave out the "-b" and it will just unpack the source and
allow you to enable/change <whatever>, then run
debian/rules build
debian/rules binary
dpkg -i ../*.deb
Put a hold on those with "echo inn2 hold | dpkg --set-selections" and
they won't be automatically upgraded on down the road.

Wow. I have a *lot* of reading to do, but I can see where Debian could
easily replace Red Hat as the premiere server system. I'll have to "tinker"
with it a bit to get the SSL and SSH hooks working, because I just tried,
but what is even better, it is the *current* release of INN, which I needed
to convert to sometime soon, anyway. It makes the standard INN format files
much more stable than before.

Post by James Vahn
Why would it crash? Debian "testing" and "unstable" are nouns, not
verbs. What usually happens are packaging errors - failed dependancies
and that sort of thing.

<wry grin> I got *those* all the time with Red Hat packages, so I'm not
worried. I simply have to learn the new commands, is all. Time to RTFM, I
guess.

Post by James Vahn

Post by dlaird
Once in awhile I walk over and let it talk to the network, which it
does without revealing any faults, other than I haven't been able to
get it to load and run the 2.6.0 kernel yet.

I don't think that 2.6.0 kernel has a whole lot going for it anyway,
same old VIA IDE-DMA bugs, SiS AGP omissions, bandwidth hogging, poor
drive remapping, etc etc etc.

It's been *really* unstable for me, but I managed to get the video and sound
both working better than either have ever run under RedHat. I had to dink
with AGP to get it working, and the SiS motherboard memory allocations were
all screwy, including things as ordinary as the COM ports. However, I found
an excellent web site that had most of the patches for those. However, it
has a tendency to be slightly worse than a BETA, not something I
particularly would trust in a server. However, with experimentation, I was
able to save a whopping chunk of memory with a modular kernel.

It will be interesting once they get the bugs out. The support for video,
movies and TV cards, as I said, was better than ever.

Dave

[James Vahn]

Post by dlaird
But I have a somewhat "customized" version of the Jed Editor which I use,
both here at home and at the office. It looks and plays just like using
Wordstar complete with a working thesaurus. It took me nearly six weeks to
get the thesaurus working with Jed's command line, but now that I've got it
working, I can't let go. So I need gcc to compile the source.

But you don't need to keep gcc on the server, do you?

Post by dlaird
I had to dink with AGP to get it working, and the SiS motherboard
memory allocations were

I have the SiS 5591/5592 AGP chipset, know anything about it?
The kernels just say "unsupported" at boot time. Boo-hiss on SiS.


--

[dlaird]

Good afternoon, James...

Post by James Vahn
But you don't need to keep gcc on the server, do you?

No, but just about the time I remove it entirely, I'm going to find another
command line editor that I simply cannot live without. <grin>

Post by James Vahn

Post by dlaird
I had to dink with AGP to get it working, and the SiS motherboard
memory allocations were

I have the SiS 5591/5592 AGP chipset, know anything about it?
The kernels just say "unsupported" at boot time. Boo-hiss on SiS.

Well, I did some looking just a minute ago, as I was certain the current
kernel under Mandrake "sees" my 5592 chipset as Intel-compatible, so I went
and looked it up to see whether it is directly supported. Here's what came
back in the hardware compatibility listings at Red Hat:

==========================================================================

This includes most of the chipsets SiS produces, which include the IDE
controller functionality in the south bridge of the chipset. Examples
include 600/5595, 620/5595, 530/5595, 5598, 5591/5595, 5596/5513, 5582,
5571, 5511, etc.

Supported 100%

=========================================================================

Is it the kernel that's complaining? I don't understand, because it works
with both 2.4.x, 2.5.x and (with the bugs) in 2.6.x. Now you've got me
puzzled. Let me do a full reboot to get a fresh dmesg and let me see just
what it is seeing and why...

Dave

[James Vahn]

Post by dlaird

Post by James Vahn
I have the SiS 5591/5592 AGP chipset, know anything about it?
The kernels just say "unsupported" at boot time. Boo-hiss on SiS.

Well, I did some looking just a minute ago, as I was certain the current
kernel under Mandrake "sees" my 5592 chipset as Intel-compatible, so I went
and looked it up to see whether it is directly supported.

Just the 530 AGP gizmo, the rest works fine. From "dmesg":

Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 28M
agpgart: Unsupported SiS chipset (device id: 5591), you might want to
boot with agp=try_unsupported
agpgart: no supported devices found.
[drm:r128_init] *ERROR* Cannot initialize agpgart module.

If I append "app=try_unsupported" to the boot prompt things look okay
until the X logs show nothing there for DRI.

"lspci" says this:

00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5591/5592 Host(rev 02)
00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (revd0)
00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev01)
00:01.1 Class ff00: Silicon Integrated Systems [SiS] ACPI
00:02.0 PCI bridge: Silicon Integrated Systems [SiS] SiS 530 Virtual
PCI-to-PCI bridge (AGP)


--

[dlaird]

Evening, James...

Post by James Vahn
If I append "app=try_unsupported" to the boot prompt things look okay
until the X logs show nothing there for DRI.
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5591/5592 Host(rev
02) 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
(revd0) 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
(rev01) 00:01.1 Class ff00: Silicon Integrated Systems [SiS] ACPI
00:02.0 PCI bridge: Silicon Integrated Systems [SiS] SiS 530 Virtual
PCI-to-PCI bridge (AGP)

Oh doodoo! It was right there in front of me all along. My AGP works but DRI
bombs, just like you described. I thought DRI was working because, in my
hardware vanity, I had a working television card. That's why I can't do
screen clips like I used to do. <muttering>

Dave

[James Vahn]

Post by dlaird
Oh doodoo! It was right there in front of me all along. My AGP works but DRI
bombs, just like you described. I thought DRI was working because, in my
hardware vanity, I had a working television card. That's why I can't do
screen clips like I used to do. <muttering>

Did you find the DRI instructions buried in the documentation section
at xfree86.org?


--

[dlaird]

Good evening, James...

Post by James Vahn
Did you find the DRI instructions buried in the documentation section
at xfree86.org?

Yes, and it reads about like the original XFree86 Frame Buffer driver
commands that didn't work for the ATI Radeon card I run, and what's even
funnier, it is only available from sourceforge.net. ;-{ I finally nudged
their public chat area a few times and ended up using a new Sourceforge
driver for the Radeon which seems to have solved the Frame Buffer problems,
and cleaned up V41 while it was at it. However the DRI instruction statement
in XFree86.0.log says "hardware not found", which is pretty funny when you
stop to think of it, since DRI is supposedly used to handle 3D Mesa, which,
the last time I looked, is stable and works right out of the box.

However, if you *really* want to see Linux double-talk at its finest, go to
the following URL:

http://dri.sourceforge.net/cgi-bin/moin.cgi/ATI

Then carefully consider the following:

1. The only drivers that allow TV to work on the Radeons that have => 32 M
of
video memory are written (in ATI's words) specifically for the Rage series
of video cards, including the 8 Meg All-in-Wonder TV cards. <snort!> I guess
I shouldn't have bothered buying the hot Radeon with 32 M of video RAM, huh?

2. The Ramdac and DRI drivers for the Radeon TV cards also break the drivers
for the Rage cards, which currently are the only TV drivers that will run
either Xawtv or ATITV, the two TV applications that seem to work the best.

3. The VIA chipsets included on some Radeons won't even run in simple
accelerated modes yet, let alone 3D or TV. The Ramdac on those cards (like
the one I sent back to ATI) won't initialize under any kernel, which
basically makes it function like a VGA card with tons of video memory that
cannot be used. I did notice when they sent me a replacement card it no
longer had the VIA chipset. Guess it works under Windows XP, but nowhere
else, from what I've read. 8-)

4. In reading the technical documentation for the Mesa 2D/3D standard, it
does seem as if Mesa initializes, as mine does (see below) then it stands to
reason that the kernel should detect and initialize the DRI driver. However,
it doesn't. Here...

(II) LoadModule: "glx"
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.a
(II) Module glx: vendor="The XFree86 Project"
compiled for 4.3.0, module version = 1.0.0
ABI class: XFree86 Server Extension, version 0.2
(II) Loading sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) Module GLcore: vendor="The XFree86 Project"
compiled for 4.3.0, module version = 1.0.0
ABI class: XFree86 Server Extension, version 0.2
(II) Loading extension GLX

(II) LoadModule: "dri"
(II) Loading /usr/X11R6/lib/modules/extensions/dri.a
ERROR: Hardware not found

This is all stock XFree86 stuff. But where the break seems, to my way of
thinking is when, after loading the GLX modes into place, and successfully
loading V41 from the default drivers, then it loads the ATI driver which I
obtained from ATI with the replacement card. Hey, at least they admit in
public that Linux users *like* the Radeon cards. 8-)

(II) ATI: ATI driver (version 6.4.18) for chipsets: ati, ativga
(II) R128: Driver for ATI Rage 128 chipsets:

However, instead of seeing the 32 M Radeon TV card, it sees a Rage 128 and
various forms of the Radeon card, but none of them with the TV card.
However, because V41 and GLX are both loaded and primed, it goes ahead and
uses the 32 M of video RAM, and loads the ATI driver for the All-in-Wonder
card, which makes sense to someone, I suppose.

Since, although I'm running a Radeon with an ATI chipset that is sensed as
an ATI Mach64, the only thing they seem to say about the problem is thus:

The ATI Mach64 (Rage Pro) is undergoing heavy development.

ATI says the Radeon card series is undergoing analysis.

I guess that means we're stuck in Gamma-level code until somebody fixes the
DRI driver in the Linux kernel. At least I have a working TV, and really
crispy video refresh speeds from the 3D driver(s); I even have a frame
buffer driver, but without the DRI driver, I can't make screen prints as I
once used to do under the 4.3 kernels and XFree86 3.x. <sigh>

Hey, at least it works. Besides, look at all the really COOL acronyms I've
learned just from figuring out the driver issues. <cackling>

Dave

[James Vahn]

Post by dlaird
(II) LoadModule: "dri"
(II) Loading /usr/X11R6/lib/modules/extensions/dri.a
ERROR: Hardware not found

BIG problem. Even my disfunctional ATI Rage Pro + SiS 530 AGP chipset
doesn't complain like that:

(II) LoadModule: "dri"
(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
(II) Module dri: vendor="The XFree86 Project"
compiled for 4.2.1.1, module version = 1.0.0
ABI class: XFree86 Server Extension, version 0.1

From there it goes merrily on its way, but never once reporting the
much sought-after string that says: "[DRI] installation complete".

Post by dlaird
I guess that means we're stuck in Gamma-level code until somebody fixes the
DRI driver in the Linux kernel.

The kernel... or X11. What does dmesg say about "agpgart"?

What version of X11 are you running? Did I read 4.2.2 was just around
the corner? You could always try crossing your fingers. ;-)

--

[dlaird]

Good afternoon, James...

Post by James Vahn
BIG problem. Even my disfunctional ATI Rage Pro + SiS 530 AGP chipset

The biggest problem of all is that, other than being able to do screen
clips, the damned thing works FINE. Plenty of speed, plenty of quality in
the TV image and no discernible problems anywhere else. Go figger...

Post by James Vahn
From there it goes merrily on its way, but never once reporting the
much sought-after string that says: "[DRI] installation complete".

Nope, I don't have that either, and according to Gerd Knorr, the guy who
wrote the V41-Video4Linux code, it's supposed to go through a whole lot of
loading of modules and then announce that DRI is loaded.

Post by James Vahn

Post by dlaird
I guess that means we're stuck in Gamma-level code until somebody fixes
the DRI driver in the Linux kernel.

The kernel... or X11. What does dmesg say about "agpgart"?

<roaring on the floor laughing myself senseless> Oh, I forgot to tell you.
Neither insmod or modprobe can find apgart, and the kernel apparently
doesn't have a problem with it, because by some mysterious means, XFree86
has logged how it has "discovered" an AGP card and loaded the apgart module
to match. That seemed like a pretty nifty trick, to me.

Post by James Vahn
What version of X11 are you running? Did I read 4.2.2 was just around
the corner? You could always try crossing your fingers. ;-)

XFree86 Version 4.3.0
Release Date: 9 May 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.19-36mdkenterprise i686 [ELF]
Build Date: 10 December 2003

Go figger, just like I said. 8-) Think it could be something Mandrake
dragged out of the closet?

Dave

[James Vahn]

Post by dlaird
Good afternoon, James...

article dated ... Sun, 11 Jan 2004 08:53:18

Is your clock skewed?

--

[dlaird]

Good evening, James...

Post by James Vahn

Post by dlaird
Good afternoon, James...

article dated ... Sun, 11 Jan 2004 08:53:18
Is your clock skewed?

Huh. Yeah, I guess it is. That sux.

Dave

[James Vahn]

Post by dlaird
The biggest problem of all is that, other than being able to do screen
clips, the damned thing works FINE. Plenty of speed, plenty of quality in
the TV image and no discernible problems anywhere else. Go figger...

"glxinfo" will say what the renderer is - "Mesa GLX Indirect" is the
software emulation. Bad.

Post by dlaird

Post by James Vahn
The kernel... or X11. What does dmesg say about "agpgart"?

<roaring on the floor laughing myself senseless> Oh, I forgot to tell you.
Neither insmod or modprobe can find apgart, and the kernel apparently
doesn't have a problem with it, because by some mysterious means, XFree86
has logged how it has "discovered" an AGP card and loaded the apgart module
to match. That seemed like a pretty nifty trick, to me.

<chuckle> So what does dmesg say? Should be a message like this:

[drm] AGP 0.99 on Unknown @ 0xf8000000 64MB
[drm] Initialized r128 2.2.0 20010917 on minor 0

I think that would narrow it down the either the kernel or X as the
problem.

Post by dlaird
XFree86 Version 4.3.0

Debian lags behind. Any chance that it worked in 4.2 ?


--

[dlaird]

Evening, James...

Post by James Vahn
"glxinfo" will say what the renderer is - "Mesa GLX Indirect" is the
software emulation. Bad.

<sigh> It's broke, too...

display: :0 screen: 0
direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.3 Mesa 4.0.4
OpenGL extensions:
GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_lod_bias
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

Post by James Vahn
[drm] Initialized r128 2.2.0 20010917 on minor 0
I think that would narrow it down the either the kernel or X as the
problem.

Nope, neither of the above. It's the kernel, just as I was thinking all
along. There is this interesting entry in dmesg at the very bottom, which is
probably why the TV video card works at all. It's using the old bttv
standard, which by the author's own words, has been deprecated in favor of
video4linux...

i2c-core.o: i2c core module version 2.8.0 (20030714)
Linux video capture interface: v1.00
bttv: driver version 0.7.107 loaded
bttv: using 4 buffers with 2080k (8320k total) for capture
bttv: Host bridge is Silicon Integrated Systems [SiS] 730 Host
i2c-core.o: i2c core module version 2.8.0 (20030714)
Linux video capture interface: v1.00
bttv: driver version 0.7.107 loaded
bttv: using 4 buffers with 2080k (8320k total) for capture
bttv: Host bridge is Silicon Integrated Systems [SiS] 730 Host

Post by James Vahn

Post by dlaird
XFree86 Version 4.3.0

Debian lags behind. Any chance that it worked in 4.2 ?

Yes, but that was a different kernel, under RedHat. I think I'll see if I
can find a different kernel for Mandrake and try my luck another shot. What
do you think? Right now at least my TV works, although it's one screwed-up
mess as to why. However, I knew that. The GLX surprise really caught me
flat-footed, though.

Dave

[James Vahn]

Post by dlaird
Yes, but that was a different kernel, under RedHat. I think I'll see if I
can find a different kernel for Mandrake and try my luck another shot. What
do you think?

Look at your current kernel config (in /boot/ ?) and make sure that
the AGP is configured for the motherboard. You can see below that I have
AGP + AMD + DRM + R128 enabled in 2.4.22.

This enables agpgart at boot time, that way I didn't have to wait
until X11 started up to see if it was loading properly (booting up
in text mode).

These are selected from the "Character Devices" in menuconfig, this
list is clipped from /usr/src/linux/.config ..

CONFIG_AGP=y
CONFIG_AGP_AMD=y
# CONFIG_AGP_SIS is not set

CONFIG_DRM=y
CONFIG_DRM_NEW=y
CONFIG_DRM_R128=y
# CONFIG_DRM_RADEON is not set


--

[dlaird]

Good afternoon, James...

Since our last communications, I recompiled the kernel from source, and
wasn't terribly surprised to find its default settings were a bit off: most
notably AGP was not selected, but was a module-only, the SiS drivers were
not loaded at all, although they were selected/auto-detected for
Video4Linux, and it had selected every network driver since the dawn of man.

It certainly cut down on the memory load cleaning things up.

Post by James Vahn
CONFIG_AGP=y
CONFIG_AGP_AMD=y
# CONFIG_AGP_SIS is not set
CONFIG_DRM=y
CONFIG_DRM_NEW=y
CONFIG_DRM_R128=y
# CONFIG_DRM_RADEON is not set

<grin> Recompiled kernel sez:

CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_I810=y
CONFIG_AGP_VIA=y
CONFIG_AGP_AMD=y
# CONFIG_AGP_AMD_8151 is not set
CONFIG_AGP_SIS=y

What is even better, AGP shows up in dmesg now, just like it was built to.
PLUS it shows up in XFree86.0.log as an AGP card. Interesting thing, though,
which I'm not *even* going to mess with:

Before it detected my hot rod Sylvania TF74 monitor as a plug 'n pray
monitor. Now it auto-detects it by name and allocates the video segments,
like it is supposed to do. I can't help but wonder why.

However, XFree86 it still has trouble with GL-Render, but it is noticeably
improved over yesterday. <wry grin> I don't know if I dare dink with it
further, as now everything is working. I put RENDER in XFree86-4.config and
it doesn't complain, but it doesn't show it as having loaded.

Since I kept the old kernel, in switching back and forth, I noticed that the
module for SiS AGP never loaded at all, as there was an error.

I guess it's fixed, at least well enough to work. 8-)

Dave
--
Dave Laird (***@kharma.net)
Systems Admin /CBWT (Certified Baling Wire Technician)
The Used Kharma Lot / The Phoenix Project
Usenet News Server: news.kharma.net

An automatic & random Fortune cookie :
I think the world is ready for the story of an ugly duckling, who grew up to
remain an ugly duckling, and lived happily ever after.
-- Chick

[James Vahn]

Post by dlaird
I guess it's fixed, at least well enough to work. 8-)

Give "glxgears" a run, see what the frame rate is before and after.
Find out which pixel depth works best- 8bpp||16||24||32. Then get to
the point of all this and see if "foobillard" is playable. :-)

http://packages.debian.org/foobillard

(it's back!)

--

[dlaird]

Good evening, James...

Post by James Vahn
I think that would narrow it down the either the kernel or X as the
problem.

I just did a bit more digging, and I am going to download the kernel source
from Mandrake and see what other "surprises" I find laying in wait for me. I
also allowed XFree86 to use its own "pick" of the video cards, and that
didn't make any difference, which I didn't think it would.

All the time it wants to detect an ATI Rage Pro, which it is *not*. It is an
ATI All-in-Wonder AGP 32 M card disguised as a Radeon, which may be where
the rub starts, since the kernel never has detected the AGP from the
beginning with *this* kernel. It is also having trouble making the
conversion from the Duron processor to an Intel-conversion, something else
that may or may not be part of the problem.

Post by James Vahn

Post by dlaird
XFree86 Version 4.3.0

Debian lags behind. Any chance that it worked in 4.2 ?

I'm going to trust that if I get the bugs worked out of the Mandrake kernel,
perhaps everything in XFree86 4.3.0 will work just fine. If not, I may drop
back to 4.2, but only after I've worked out the kernel bugs, and at least
initialize the AGP in dmesg.

Dave