[SMAUG] RE: [off-list] Re: Caldera Workstation 3.1
Calvin Chu
cchu@flytecomm.com
Thu Aug 9 15:17:02 2001
The Caldera installer is pretty much nonexistent. When I get to the PCMCIA
devices it claims there are none, and it moves on and asks me if it found
all the devices. If I say no, it tells me about not being able to load up
certain modules and it gives up. So I have to say YES for the installer to
even move on.
Here's the situation:
/dev/mouse -> /dev/psaux
when I run gpm, it will instantly lock up the keyboard. I am now connected
to the machine externally through ssh so I know the machine is still
running. If I do a gpm -k to kill the gpm process it unhangs the console.
Next, I did a cat /dev/mouse
if I do not move the mouse, I can ctrl-c and break out of it, no lock up.
If I move the mouse, then the keyboard immediately stops responding. If I
hit return a lot of times.....
then from the external connection kill the "cat" process, the screen
immediately jumps and hits return a bunch of times. It's like it is
buffering the keyboard characters whenever the mouse device is accessed.
It seems when the mouse device is accessed, it locks up the mouse, then it
locks up the keyboard.
When I run X11 the same thing happens. X11 accesses the /dev/mouse (psaux)
device and that immediately locks the keyboard and mouse. This means I can
not switch to virtual terminals, or do anything.
It seems to me that X11 is probably configured correctly, but the /dev/mouse
device is causing the console to freeze.
If I follow your guide to setting up X, it will halt at step 5 because I
will not be able to switch between virtual terminals.
If anybody has a known working linux configuration, can someone stop X11 and
go to console mode only, and then cat /dev/mouse while moving the mouse and
verify if this locks up the console? The answer to this question will help
me diagnose whether there is a problem in the behavior of /dev/mouse or a
configuration problem in X.
Calvin
-----Original Message-----
From: Rick Moen [mailto:rick@linuxmafia.com]
Sent: Thursday, August 09, 2001 3:02 PM
To: Calvin Chu
Cc: rick@linuxmafia.com
Subject: [off-list] Re: Caldera Workstation 3.1
[Again, I'll probably post a version of this when I get home.]
> right now, I am bringing the network up manually using the following:
> cardmgr
> then
> ifconfig
> then some route commands.
> What is the proper way of configuring it so that when the pcmcia card is
> present, it will set up, when it is not, it will not? The rc scripts seem
> to have cardmgr in it, but it doesn't run automatically so I have to start
> manually.
Again, it seems likely that the Caldera installer has somehow fscked up
your configuration. You _might_ consider re-running it, paying particular
attention to PCMCIA setup -- or try loading a different distribution.
As I believe Rafael was saying, _sometimes_ services don't start correctly
because their startup order is wrong. E.g., the symlink in /etc/rc.d/rc3.d/
to start up sendmail is before the "network" one that initialises the
ethernet ports.
I do not know if something analogous is the case with your current system
configuration, but it's possible. Unfortunately, you would probably have
to chase it down, yourself, since the rest of us don't know what your
Sys V Init files (the scripts and symlinks) have in them.
> I was able to open an SSH connection into the machine from outside. And
now
> I verified that the machine continues to run despite the keyboard and
mouse
> locked up and unresponsive. I am able to kill the X process and get the
> machine back under control again.
>
> Any ideas on what to try?
First, you have to make sure you're trying to start the correct X server.
Since you (finally) seem to have confirmed having a Chips & Technologies
65554 video chipset, the SVGA server would definitely be the correct one
(under XFree86 v. 3.x).
Second, make sure your mouse port and mouse-protocol types are correct.
E.g., if XF86Config references /dev/mouse, then make double-sure that
that file is a symlink to /dev/psaux (your PS/2 port). And make sure
that the mouse-protocol line in your X config says "PS/2" -- _not_ Microsoft
protocol.
Third, make sure you are _not_ running gpm. Yes, it's possible to get
X to coexist with gpm, but you can deal with that after X is proven to
work properly in a simpler configuration.
Fourth, well, you need a generally appropriate XF86Config file (in XFree86
3.x; the 4.x equivalent being XF86Config-4, with a different format).
You can create an _unoptimised_ XF86Config file just by running xf86config
and giving minimally correct answers, reflecting correctly the nature of
your hardware. That _unoptimised_ XF86Config file should then allow you
to type "X > logfile 2>&1", have a really non-optimised bare X server
display come up, and let you successfull kill it with Ctrl-Alt-Bkspc,
without freezing your machine. If your machine freezes, then something
more fundamental is wrong.
I happen to have, once upon a time, reduced my never-fail XFree86 3.x
configuration method to FAQ format. Please note that this _only_ helps
to optimise a v. 3.x configuration file for a basically _working_ X
server. (It will not fix an X configuration that freezes your machine.)
I've now dredged it up, and here it is:
Q: How can I create an optimal XFree86 v. 3.x configuration for my video
card?
A: 1. Find out whether your video card requires the SVGA XFree86 server
engine software or one of the "accelerated" server binaries. You can
find this information in the on-line video-chipset data at
http://www.xfree86.org/ .
2. Run the xf86config utility, setting the horizontal and vertical frequency
limits to those show in your monitor's technical specifications. Your
VA-provided pointing device will be of type PS/2. Select the maximal set of
video modes allowed, at the maximal number of colour depths offered. Allow
the xf86config utility to write /etc/X11/XF86Config. Copy it to
/etc/X11/XF86Config-GENERATED, for safekeeping.
3. Open two root-user virtual terminals. In both, cd to /etc/X11. In one,
open XF86Config in your preferred editor program (e.g., vi or pico). Prune
out the superfluous (as detailed below) sections and comment lines. Save.
When you're done, there should be one each (only) of the following sections:
Files
Keyboard
Pointer
Monitor
Device
Screen
Delete all Device sections other than the ones most appropriate for your
video chipset. (The one you'll keep will be either the SVGA one or the Accel
one, depending on your video card.) Delete all Screen sections other than
the one for your monitor.
The only commented-out lines to leave are the VideoRAM and Clocks lines
you'll probably find already there, commented out, plus the comment line
that directly precedes each Modeline in the Screen section.
Delete the two Modelines and matching comment lines for 640x400, the entire
"low-res doublescan" section, and all Modelines (with matching comment
lines) for modes higher than you want to go. (E.g., delete all Modeline
pairs for modes higher than 1024x768i, if that's the maximum resolution you
want.) Save.
4. Go to the bottom of the file. Decide what default colour depth you want.
Hard-code it by either eliminating all other Subsection "Display"
subparagraphs, or by inserting (e.g.) "DefaultColorDepth 16" as a new line
near the top of the Screen section.
For any Subsection "Display" that is of interest, edit the Modes line to (1)
eliminate modes you won't ever use, and (2) reverse the order of the modes.
That is, xf86config, somewhat obstructively, writes them in
lowest-to-highest order, resulting in X defaulting to the lowest mode. Mine
initially said:
Modes "640x480" "800x600" "1024x768"
I changed it to
Modes "1024x768" "800x600" "640x480"
You may want to add "ViewPort 0 0" to any Subsection "Display" that is of
interest. Save.
5. In your other virtual terminal, type
X > xerrors 2>&1
Observe whether X (bare X, in this case, with no window manager) comes up or
not. If it comes up or partially does so, kill the X server using
Ctrl-Alt-Bkspc. Do "less xerrors". This is the complete stdout + stderrors
output of the X server at its default colour depth and best valid mode.
You'll see something like this. Note the part I've highlighted:
XFree86 Version 3.3.6 / X Window System (protocol Version
11, revision 0, vendor release 6300)
Release Date: January 8 2000
If the server is older than 6-12 months, or if your card
is newer than the above date, look for a newer version
before reporting problems. (see http://www.XFree86.Org/FAQ)
Operating System: Linux 2.2.15pre20 i686 [ELF]
Configured drivers: SVGA: server for SVGA graphics
adaptors (Patchlevel 1): NV1, STG2000, RIVA 128, RIVA
TNT, RIVA TNT2, RIVA ULTRA TNT2, RIVA VANTA, RIVA ULTRA
VANTA, RIVA INTEGRATED, GeForce 256, GeForce DDR, Quadro,
ET4000, ET4000W32, ET4000W32i, ET4000W32i_rev_b,
ET4000W32i_rev_c, ET4000W32p, ET4000W32p_rev_a,
ET4000W32p_rev_b, ET4000W32p_rev_c, ET4000W32p_rev_d,
ET6000, ET6100, et3000, pvga1, wd90c00, wd90c10, wd90c30,
wd90c24, wd90c31, wd90c33, gvga, r128, ati, sis86c201,
sis86c202, sis86c205, sis86c215, sis86c225, sis5597,
sis5598, sis6326, sis530, sis620, sis300, sis630, sis540,
tvga8200lx, tvga8800cs, tvga8900b, tvga8900c, tvga8900cl,
tvga8900d, tvga9000, tvga9000i, tvga9100b, tvga9200cxr,
tgui9400cxi, tgui9420, tgui9420dgi, tgui9430dgi,
tgui9440agi, cyber9320, tgui9660, tgui9680, tgui9682,
tgui9685, cyber9382, cyber9385, cyber9388, cyber9397,
cyber9520, cyber9525, 3dimage975, 3dimage985,
cyber9397dvd, blade3d, cyberblade, clgd5420, clgd5422,
clgd5424, clgd5426, clgd5428, clgd5429, clgd5430,
clgd5434, clgd5436, clgd5446, clgd5480, clgd5462,
clgd5464, clgd5465, clgd6205, clgd6215, clgd6225,
clgd6235, clgd7541, clgd7542, clgd7543, clgd7548,
clgd7555, clgd7556, ncr77c22, ncr77c22e, cpq_avga,
mga2064w, mga1064sg, mga2164w, mga2164w AGP, mgag200,
mgag100, mgag400, oti067, oti077, oti087, oti037c,
al2101, ali2228, ali2301, ali2302, ali2308, ali2401,
cl6410, cl6412, cl6420, cl6440, video7, ark1000vl,
ark1000pv, ark2000pv, ark2000mt, mx, realtek, s3_savage,
s3_virge, AP6422, AT24, AT3D, s3_svga, NM2070, NM2090,
NM2093, NM2097, NM2160, NM2200, ct65520, ct65525,
ct65530, ct65535, ct65540, ct65545, ct65546, ct65548,
ct65550, ct65554, ct65555, ct68554, ct69000, ct64200,
ct64300, mediagx, V1000, V2100, V2200, p9100, spc8110,
i740, i740_pci, i810, i810-dc100, i810e, Voodoo Banshee,
Voodoo3, smi, generic (using VT number 7)
XF86Config: /usr/X11R6/lib/X11/XF86Config
(**) stands for supplied, (--) stands for probed/default values
(**) XKB: keymap: "xfree86(us)" (overrides other XKB settings)
(**) Mouse: type: PS/2, device: /dev/psaux, buttons: 3
(**) Mouse: 3 button emulation (timeout: 50ms)
(**) SVGA: Graphics device ID: "NeoMagic 2160"
(**) SVGA: Monitor ID: "Sony LCD"
(**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/:unscaled,
/usr/X11R6/lib/X11/fonts/100dpi/:unscaled,
/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,
/usr/X11R6/lib/X11/fonts/Speedo/,
/usr/X11R6/lib/X11/fonts/Type1/,
/usr/X11R6/lib/X11/fonts/misc/,
/usr/X11R6/lib/X11/fonts/100dpi/,
/usr/X11R6/lib/X11/fonts/75dpi/,
usr/X11R6/lib/X11/fonts/freefont/"
(--) SVGA: PCI: NeoMagic NM2160 rev 1, Memory @ 0xfd000000, 0xfea00000
(--) SVGA: chipset: NM2160
(--) SVGA: videoram: 2048k
(**) SVGA: Using 16 bpp, Depth 16, Color weight: 565
(--) SVGA: Maximum allowed dot-clock: 90.000 MHz
(**) SVGA: Mode "1024x768": mode clock = 85.000
^^^^^^^^ ^^^^^^
(**) SVGA: Mode "800x600": mode clock = 50.000
^^^^^^^ ^^^^^^
(**) SVGA: Mode "640x480": mode clock = 45.800
^^^^^^^ ^^^^^^
(--) SVGA: Virtual resolution set to 1024x768
(--) SVGA: NeoMagic MagicGraph 128XD (NM2160) chip
(--) SVGA: NM2160: Panel is a 1024x768 color TFT display
(--) SVGA: NM2160: Internal LCD only display mode
(--) SVGA: NM2160: Video modes are displayed in the upper-left corner
(--) SVGA: NM2160: Low resolution video modes are stretched
(--) SVGA: NM2160: MMIO registers at 0xFEA00000
(--) SVGA: NM2160: Linear framebuffer at 0xFD000000
(--) SVGA: NM2160: Using hardware cursor
(--) SVGA: Using XAA (XFree86 Acceleration Architecture)
(--) SVGA: XAA: Solid filled rectangles
(--) SVGA: XAA: Screen-to-screen copy
(--) SVGA: XAA: 8x8 color expand pattern fill
(--) SVGA: XAA: CPU to screen color expansion (TE imagetext, TE polytext)
(--) SVGA: XAA: Using 8 128x128 areas for pixmap caching
(--) SVGA: XAA: Caching tiles and stipples
(--) SVGA: XAA: Horizontal and vertical lines and segments
System: `/usr/X11R6/lib/X11/xkb/xkbcomp -w 1
-R/usr/X11R6/lib/X11/xkb -xkm -m us -em1 "The XKEYBOARD
keymap compiler (xkbcomp) reports:" -emp "> " -eml
"Errors from xkbcomp are not fatal to the X server"
keymap/xfree86 compiled/xfree86.xkm'
The three lines I've highlighted identify the Modeline that X will attempt
to use for each cited mode. The Modeline you ended up using before killing X
(in the example, the one for 1024x768) either gave functional,
stable-looking, good-looking results on your monitor, or it didn't.
If it looks good, you'll want to keep that mode's Modeline, and delete all
other Modelines for the same mode (e.g., all other 1024x768 pairs). If it
doesn't look good, kill X immediately using Ctrl-Alt-Bkspc (if X comes up at
all), and then eliminate that Modeline, so you can go test the next
candidate.
In either case, switch back to the first virtual terminal (in which you're
editing XF86Config). Find the bottom of the Monitor section, just above the
Device one. Higher frequency Modelines ("better", if they work) are towards
the bottom; less-aggressive ones are towards the top of the section. X
always tries Modelines from the bottom of the section moving up. As
mentioned earlier, X parses "Modes" lines (in the "Screen" section at the
bottom) from left to right.
The "mode clock" figure I highlighted above will be the next number on each
Modeline immediately following the mode-numbers label. E.g., the "mode clock
= 85" one for 1024x768, on my system, is this one:
# 1024x768 @ 76 Hz, 62.5 kHz hsync
Modeline "1024x768" 85 1024 1032 1152 1360 768 784 787 823
If the monitor had not synchronised (shown a good display) using that
Modeline, I would now at least comment out the line, if not remove it along
with its comment line. I would then save, switch to the second virtual
terminal, re-run "X > xerrors 2>&1", and repeat the cycle, eliminating
1024x768 Modelines until one worked. That will logically be the best
1024x768 Modeline, so I would then stop there and (if I cared) optimise
800x600.
Since the monitor did synchronise, I eliminate all other 1024x768 entries,
and move on to 800x600.
In order to test the next-lower mode with minimal effort, I just duplicate
the "Modes" line I'm using, comment one copy out for safekeeping, and
eliminate modes I don't want to try:
#Modes "1024x768" "800x600" "640x480"
Modes "800x600" "640x480"
Save. Switch to the second virtual window. Do the previously-described
series of steps for 800x600, instead of 1024x768.
If you make errors and delete something you shouldn't have, you can revert
to XF86Config-GENERATED (your safety backup).
The above steps are NOT required for an acceptable X display, but will
reliably result in one optimised for top performance and XF86Config
legibility. Among other things, XF86Config will be trimmed to about 1/10 of
its usual length.
Further fine-tuning of the video frequences is possible using the xvidtune
utility.