[SMAUG] Re: Caldera Workstation 3.1

[Rick Moen]

Calvin --

You've done some good and impressive diagnostic work, but I _believe_
the basic PCMCIA problem you're seeing is that Card Services just 
isn't recognising your laptop motherboard's PCMCIA chipset.   The fact that 
"modprobe 3c589_cs" causes the link-status LED to light just means that
that named driver is now talking to the card -- _but_ the driver seems
not to be talking to the kernel, for lack of Card Services functionality.
(I'm surmising, a bit.  I'm no PCMCIA expert.  I could be wrong.)

So, you've loaded the right ethernet driver.  You probably have it
configured in /etc/pcmcia/config correctly.  And you could presumably
force startup of the daemon that is support to furnish Card Services.
_But_ it seems likely that, for whatever reason, the Card Services daemon
you have currently installed isn't recognising the motherboard PCMCIA
chipset.

What I'm getting at is that, although you _might_ be able to clear the final
hurdle by stubbornly plugging away at the problem, trying to tweak Card 
Services so that, upon its startup, it recognises that PCMCIA chipset (and
beeps to so indicate), it might be a better use of your time to either (1)
try to reinstall, paying really, _really_ close attention to PCMCIA setup, 
or (2) try installing a different distribution.

It's a question of the Law of Diminishing Returns.  Sometimes, the problem
can be solved in the straight-ahead stubborn manner, but it's just not 
worth it.  For example, one of the recent releases of Linux-Mandrake just
seemed unable to install onto all-SCSI systems.  Could that be worked
around?  I'm sure it could, but I advised the people I tried to help solve
it that it's _much_ easier to just try a different distribution.

> Is it still necessary to muck around with the rc files?  The question is:
> is adding the alias inside the modules.conf file a hack or is it more
> properly done in the rc files?

A shrewd question.

Conventionally, it's traditional to specify what kernel modules you want
unconditionally loaded at boot time through "alias" lines in modules.conf --
but I suppose it _is_ arguably a hack.  Certainly, it would be quite
possible to put equivalent "modprobe" lines into rc.sysinit.  But that 
is not conventionally done.

> The /dev/mouse is linked to psaux.  If I cat the file, the system will
> lock down tight (no keyboard response, no control-alt-delete, no mouse
> screen response, no screen blank capability.. nothing...).

(1) That is normal:  In Linux, things in /dev are binary devices; with
rare exceptions, you do not want to cat their contents to stdout.  

(2) Having /dev/mouse be a symlink to /dev/psaux is absolutely correct for
your system -- since your trackball is absolutely a PS/2-type pointing
device.  Guaranteed.  

Certain files in the /dev directory -- /dev/mouse, /dev/cdrom, and
/dev/modem come to mind -- are traditionally created for your personal
convenience, as a level of abstraction, by either the OS installer or by 
you manually.  The fact that /dev/mouse has been pointed to whatever is the
correct port for the system's pointing device means you can use that
filename as a generic way to refer to the system pointing device -- for
example, in /etc/X11/XF86Config (v. 3.x) or /etc/X11/XF86Config-4 (v. 4.x).

> Using SuperProbe verified that I have a C&T 655554 chipset....

This contradicts what you quoted kxconfig as determining, earlier, of 
it being a "S3 Trio64V+" (S3 model 764 or possibly M65).  But I tend to
believe SuperProbe, as it's rarely wrong.

This sheds some light on that aspect of your Caldera-installer problem:
If kxconfig thought you had a C&T, then presumably it set up a completely 
wrong /etc/X11/XF86Config (v. 3.x) or /etc/X11/XF86Config-4 (v. 4.x) file.
Which would explain why X went completely out to lunch, when you typed
"startx".

> ...and I used xf86config to set up a initial configuration file.  I went
> through and pulled the horizontal/vertical sync and memory size from
> various places...  I set up a 2 button microsoft compatible mouse with
> (and later, without) third button emulation.  startx will in both cases
> lock up the same exact way.

Well....

(1) The file xf86config creates is inevitably somewhat brain-damaged in that
it's poorly optimised:  Its "screen" section is written in inverted order,
such that the system favours low resolutions and low colour depths.  But 
it pretty reliably produces something that _works_, for unambitions values
of "work".

But I notice:

> I set up a 2 button microsoft compatible mouse with (and later, without)
> third button emulation.

This is obviously _wrong_.  You have a PS/2-protocol mouse on a PS/2-type
port.  For XFree86 4.x, you would end up with something like this:

   Section "InputDevice"
       Identifier "Mouse0"
       Driver "mouse"
       Option "device" "/dev/mouse"
       "Protocol" "PS/2"
       "Emulate3Buttons" "on"
       "ZAxisMapping" "4 5"
   EndSection

For XFree86 3.x, you'd have something like this:

   Section "Pointer"
       Protocol "PS/2"
       Device "/dev/mouse"
       ZAxisMapping "4 5"
       Emulate3Buttons
       Emulate3Timeout 50
   EndSection

> To Rick:  When I said 640x480 vs 800x600 console, I mean the TEXT console,
> so I don't think this has to do with an X11 configuration.  

Sorry I misread.

> Any clue as to where the console configuration is?

1.  Part of this, the console typeface, is almost certainly in
/etc/rc.d/sysinit, as some form of invocation of the /bin/setsysfont 
The system keymap is probably also set there, using loadkeys.

2.  However, what you're talking about is the console video mode.  That is 
set as an option fed to the booting kernel, e.g., by lilo.  If you're 
using lilo to load the Linux kernel (and you probably are), then you'll 
want to look at /etc/lilo.conf.  (That file is a sort of set of instructions
to a "lilo compiler" called the map installer, /sbin/lilo .)


Anyhow, please consider whether you might be best off either reloading or
trying a different distribution.  See:
http://linuxmafia.com/~rick/faq/#cheaplinux  (and the two essays after that)

-- Rick M.