X server will not start

[Capt J S McKenzie]

I have just created a new 5.1 system on an Alpha1000A but
I cannot get Xserver to start so I am defaulting to command line operation. I would really like a gui as I had it up until now running the Alpha Debian Linux port. The card is an old S3 Virge but I have followed the instructions in Xserver.conf putting in a low resolution of 800x600 after the -pn.

Additional info is that X tries to start three times before aborting. The screen turns to grey with many vertical columns of dashes.
The extra setting I put in Xserver.conf is:-

args <
-pn -bs -su
-screen0 800x600
-depth0 8
-vsync0 75
>

Changing the monitor from a 17" View Sonic to a 19" very modern flat screen Neoview makes no difference.

Changing the Xserver.conf extra definition from 800x600 to 640x480 which should be native for the card also makes no difference.

I cannot revert to the embedded Cirrus card as you need the ECU diskette to tell the system you want to use on-board VGA as well as move the board jumper, but I don't have the ECU floppy - and in any event I reckon the Cirrus is less capable than the S3 PCI card.

Any chance of help from an X man or the HP specialist video man giving me some pointers please?
stuart mckenzie

[Michael Schulte zur Sur]

Hi,

there is a log file for the Xserver. Have a look into that. I would try with 1280X1024 and 60 Hertz. My monitor won't accept anything else.

greetings,

Michael

[Capt J S McKenzie]

Hi Michael
I tried your suggestion and in fact several others and noted the results in the Xerrors file which lives in /var/cluster/members/member0/dt
All the configurations other than the native 640x480 gave illegal messages and then kill. Only the following gave no illegal messages but the error message itself repeated 4 times - presumably for each time it tried to start as

X connection to :0.0 broken (explicit kill or server shutdown).

This is with:
-pn -bs -su
-screen0 640x480
-depth0 4
-vsynch0 60

regards
stuart mckenzie

[Steven Schweda]

This is still with the odd-ball unsupported
graphics card, right? Which driver is being
selected? On my AlpSta 200 4/233 with the
ELSA GLoria Synergy-8 (ViVo), I see messages
like these at start-up:

Apr 9 18:42:27 urt vmunix: comet0: Card type 'Elsa GLoria' with 8MB framebuffer memory.
Apr 9 18:42:27 urt vmunix: comet0 at pci0 slot 13
Apr 9 18:42:27 urt vmunix: kernel console: comet0

What do you get that's comparable?

If the device is not of a known type, it
may be operated in some basic
VGA-compatible mode, which may not accept all
the setting values you've specified.

> many vertical columns of dashes

As in a scrambled display caused by bad
synchronization, aor an orderly display of a
lot of "-" characters?

[Capt J S McKenzie]

Hi Steven
kern.log has following entries:

vmunix: cirrus probe failed
vmunix: cirrus: attempting to use generic vga support
vmunix: cirrus0 at eisa0
vmunix: 640x480 VGA, 16 colours

(bearing in mind that on-board VGA is disabled by jumper)

about ten entries later...
vmunix: vga0 at pci1 slot 1
vmunix: 640x480 VGA, 16 colours
vmunix: vga0: generic VGA driver

five entries later
vmunix: kernel console: cirrus0

That seems to be all in kern.log that is relevant. I don't see how the console could be using the cirrus chip when a) it is disabled by jumper and b) the monitor is plugged into the PCI card and not the vga slot.


The vertical dashes on a grey background are ordered i.e like columns of vertical - (there is no key on the keyboard which gives a short vertical dash only a | and these dashes are half that size).

regards
stuart mckenzie

[Steven Schweda]

Bearing in mind that I don't actually know
anything...

> on-board VGA is disabled by jumper

I believe that this is done to prevent the
SRM console from becoming confused when the
system contains multiple graphics cards, all
of which can do the basic VGA stuff. I'd
expect the Xserver to be indifferent to this
setting.

Note, for example, that the only apparent
difference (beyond the labels) between a
plain ELSA GLoria Synergy-8 card and an
official PBXGK-BB ELSA GLoria
Synergy-8-Compaq card is the installation of
the "VGA disable" switch. I assume that PC
BIOS stuff deals with this problem
differently from the way SRM does it.

Have you tried hooking a display to the
built-in display connector when X is
(supposed to be) running? Perhaps with more
default-like "args"? Perhaps (first) with
the PCI graphics card pulled?

I have no experience with multiple graphics
cards in one system with Tru64, but I'd
expect the X server to be able to cope to
some extent. (On VMS, it's common for the
DECwindows X software to demand that multiple
graphics cards all be the same type. I also
have no experience with multiple graphics
cards in one system with VMS, but I've read a
little more there.)

If only the built-in card gets mentioned
during start-up, it's possible that no one is
making a serious attempt to use the PCI card.

"man Xserver" does discuss "Multiscreen
configurations". In particular, it does
offer this hope-inspiring line:

Multiscreen configurations may contain any configuration display devices.

> X man or the HP specialist video man

Don't give up hope. One may yet appear.

[Rick Retterer]

Xman here.

Your Elsa ViVo card will not work in the 1000a. There are no drivers outside of the standard VGA driver to support it.

To install a Graphics Card upgrade, you will need to disable the on-board Graphics card by moving the VGA jumper on the mother board to the OFF position. (Check your hardware manual for the pin location)

Then you will need to run the EISA Config utility to disable the on-board graphics option within the bios.

Only after doing this will you be able to get another graphics card to be recognized by the system.

Note: you will need to install a HP "Supported" graphics card for this system. This would be the Compaq S3 Trio64 graphics card. (PB2GA-JD)

Note, with the PB2GA-JD, you MUST have the boot_reset environment variable set to OFF.

IF you attempt to use any non-HP/Compaq qualified card, the correct driver for the system will not be found by the generic kernel when you boot it, and thus you will still be using the 640x480 graphics resolution that you had with the Cirrus on-board graphics option.

Sorry to be the bearer of disappointing news, but that's just the way this system is.


Here is a little more information that may help you...


Disabling the Cirrus Chip:
--------------------------

NOTE:
If you want to use a different graphics card, you
must disable the Cirrus GD5422 graphics chip prior to
adding the new graphics card to the system.

The following steps describe how to disable the
built-in graphics chip in the saved system
configuration:

1. Make sure the EISA Configuration Utility diskette
is loaded. From the SRM console, enter the
"runecu" command to invoke the EISA Configuration Utility.

A message is displayed indicating that you have
invoked the EISA Configuration Utility.

2. Press the Enter key to continue.

3. Use the arrow keys to select Step 3, View or edit
details, and press the Enter key.

4. Use the arrow keys to highlight the VGA Graphic
Controller option. Press the Enter key to edit
the function.

5. Disable the VGA Graphic Controller by using the
arrow keys and pressing the F10 key.

6. Press the F10 key to exit from Step 3, View or
edit details.

7. Use the arrow keys to go to Step 5, Save and exit,
and press the Enter key.

8. Verify that the Save the configuration and restart
the computer line is highlighted, and press the
Enter key.
The configuration is now saved.

9. Press the Enter key to exit from the EISA
Configuration Utility.

10.When the Boot menu is displayed, turn off the
system.

While the system is off, add the new graphics option
card.

Also disable the built-in Cirrus GD5422 graphics
hardware while the system is turned off. Refer to
the hardware documentation that came with your system
for instructions on adding option cards and disabling
the Cirrus GD5422 graphics hardware.

This involves moving the VGA Jumper from the ENABLE
position to the DISABLE position on the AlphaServer 1000
Mother board. The Jumper is located along the top edge
of the System Mother board near the rear of the system.
The System Mother board is positioned vertically near the center
of the system enclosure and the jumper faces the left side as
viewed from the front.

Once the built-in graphics chip is disabled and the
optional graphics card added, turn on the system

[Capt J S McKenzie]

Hi Xman
Thank you for your advice.
Could I first say that the Cirrus chip was disabled a long time ago and I have been using the Alpha with the S3 Virge card on Debian Linux Alpha port quite successfully.
I would point out that the monitor is plugged in to the card and not the VGA port so some driver must be working!

Browsing for details on graphics cards and Alphas resulted in posts saying that most S3 cards would work under Tru64 albeit at low resoultion but as you see from my previous posts I have resorted to native 640x480 depth 4 i.e 16 colours.

Are you saying that the driver and the card are not making contact? If so then how am I getting anything on a monitor plugged into the card??

Puzzled.....
stuart mckenzie

[Steven Schweda]

> Cirrus chip was disabled a long time ago

Being disabled as a VGA console device may
differ from being disabled completely. Have
you performed the ECU ritual yet?

Every PC-oriented graphics card has a generic
VGA mode in addition to its fancy individual
mode(s). This allows any such card to be
used (in VGA mode) in any PC without needing
a proprietary device driver. (Of course, if
you want the full feature set, you need the
real driver.) Similarly, the SRM console can
probably deal with any (one) such card in its
VGA mode. Q: If multiple such cards (or
built-in interfaces) exist, which one should
the SRM console use? A: Not the one(s) whose
VGA mode has been disabled. But disabling
the VGA mode may not completely disable the
card. (Am I repeating myself enough yet?)

> S3 Virge card on Debian Linux Alpha port
> quite successfully

Tru64 may differ from Debian Linux in its
graphics device support.

> so some driver must be working!

You can tell this because the display looked
so good? Have you checked the output from
the built-in graphics port?

For a good time, I swapped the ELSA GLoria
Synergy-8 ViVo card in my AlpSta 200 4/233
for an old (circa 1996) Number Nine card with
an S3 Trio64 chip. The SRM console "show
config" included:

Bus 00 Slot 13: Digital S3 TRIO 64 Graphics Controller

Making no changes to any X configuration
files, I first simply rebooted. Console
output (as recorded in /var/adm/messages)
included:

Apr 11 15:56:03 urt vmunix: vga0 at pci0 slot 13
Apr 11 15:56:03 urt vmunix: 640x480 VGA, 16 colors
Apr 11 15:56:03 urt vmunix: vga0: generic VGA driver
Apr 11 15:56:03 urt vmunix: kernel console: vga0

and X started with a resolution so low that
it could easily have been 640x480. (Not all
of the HP Tru64 UNIX logo fit on the
display, for example.)

Next, I shut down, and then booted the
generic kernel ("boot -file genvmunix").
This time, the console output included:

Apr 11 16:10:32 urt vmunix: s3trio0: S3 Trio64 (SVGA) Plug-N-Play, 2.0 Mb
Apr 11 16:10:32 urt vmunix: s3trio0 at pci0 slot 13
Apr 11 16:10:32 urt vmunix: kernel console: s3trio0

("2.0 Mb" is why I replaced the card when I
got the system. The previous owner was
running some Linux or other, probably Red
Hat, but no bets. I think that even VMS
supported (or, at least, tolerated) this
card, too.)

This time, X started at a higher resolution.
Output from "xdpyinfo" included:

screen #0:
dimensions: 1024x768 pixels (280x235 millimeters)
resolution: 93x83 dots per inch
depths (2): 1, 8

A "doconfig" created a non-generic kernel,
and it seemed to work as expected (again, X
started with 1024x768 resolution.)

My test display for all this was a Sony
Multiscan 15sf (CRT). (Nothing fancy.)

I'd suggest _really_ disabling the on-board
graphics chip (if it's not already been
done), then booting the generic kernel to see
if it can puzzle out the device better.


> Your Elsa ViVo card will not work in the
> 1000a. There are no drivers outside of the
> standard VGA driver to support it.

Does the SRM console need more than standard
VGA? Clearly, Tru64 can deal with the card.

> you will need to install a HP "Supported"
> graphics card

Note that nothing on my #9 S3 Trio64 card
suggests any connection to DEC, Compaq, or
HP. Of course, an S3 Virge probably differs
from an S3 Trio64 in more than just the name,
so there's no particular reason to expect it
to work with Tru64.

[Steven Schweda]

One clarification: I make no use of the
ViVo-specific features on the ViVo card
(with either Tru64 or VMS). I treat it as an
ordinary card which happens to have a bunch
of extra parts installed. Both the Tru64 and
VMS graphics drivers like it well enough.

Note that the VGA disable switch is not among
the extra parts on a ViVo. Also, I have
never tried to connect anything to the
additional ViVo inputs or outputs, so I have
no idea what, if anything, is happening there.

Of course, the fellow with the problem doesn't
have one of these cards. I offer it merely as
an example of a working graphics card.

[Capt J S McKenzie]

Steven
Your recent posting is very helpful and, taken together with Rick's input, has got me pondering. Did I really run the ECU when I disabled the on-board chip?? If so where's the diskette? As I cannot find it then perhaps I didnt and just because the Alpha ran fine from the S3 on Linux I didnt bother to follow up. It was so long ago that I really cannot remember.

As the code has Micro Systems proprietary stuff it is not freely available and so I went today to our friendly HP engineers to borrow one as it was obviously licensed for this machine previously, but unfortunately they were all out so I missed them.
I assume you can build a diskette from the code? Looking at the release notes I see that there seems to be a problem with the FD under TRu64 and it doesnt work but presumably it still is recognised under SRM (It fails during startup with the error fd internal driver error unsupported media).

I was fascinated that you took the trouble to put in an old card to see what happened and your output was useful. I immediately took the system to SRM to see what sho config gave for slot 1 of the PCI and it said "563153333" which can hardly be illuminating for UNIX!

I think the next step is to really, really disable Cirrus and try again so I will need the ECU.

I tried the reverse procedure on the assumption that the ECU has NOT been run and only the jumper moved but that is really weird because when I enabled the VGA and moved the monitor to the vga port the system would not even start. It gave fatal beep codes until I re-disabled the jumper and put the monitor back on the graphics card. Mind you I had not removed the card and perhaps I should have.

One last point' There has never been any output on the vga port under any of the scenarios so far. I have a second monitor which I plug in to that port from time to time but never a glimmer.

I am persevering because I like a challenge and have the time now I have retired. At work I would have given up or given in and moved on!
regards
stuart

[Steven Schweda]

> I assume you can build a diskette from the
> code?

I have an ECU diskette from an old (copyright
1993, 1997) Alpha Firmware Update V5.1 kit.
I also appear to have a VMS BACKUP /PHYSICAL
image of it, and a Zip archive of its
contents. One of those (or something else)
could be used to reconstruct a floppy.

> [...] it said "563153333" which can hardly
> be illuminating for UNIX!

You might be surprised. PCI cards have a
couple of ID numbers. According to
http://fxr.watson.org/fxr/source/bus/pci/pcidevs?v=DFBSD
for example,

[...]
product S3 VIRGE 0x5631 ViRGE
product S3 TRIO32 0x8810 Trio32
product S3 TRIO64 0x8811 Trio32/64
product S3 AURORA64P 0x8812 Aurora64V+
product S3 TRIO64UVP 0x8814 Trio64UV+
product S3 VIRGE_VX 0x883d ViRGE/VX
[...]

So, the "5631" part of that looks to be a
well-known value. (It also suggests that
your crappy graphics card is even crappier
than my crappy graphics card.) (I'll assume
that the "53333" part is really four digits,
not five, as that makes more sense for a hex
value.)

> so I will need the ECU.

As I said, send me some e-mail
(sms@antinode-org), and we can discuss the
doctrine of "fair use".

> [...] the system would not even start.

Multiple active VGA cards (or cards and
built-ins) could easily cause serious
trouble, I'd expect. I haven't tried it.

> [...] you took the trouble [...]

Some of us are easily entertained.

> I am persevering [...]

Fine with me, but you may need to get a real
(that is, supported, more or less) graphics
card eventually. Hitting the thing with the
ECU sounds plausible as a next step,
however. (Only one way to find out...)

[Steven Schweda]

Oh, yeah. Same reference:

[...]
vendor S3 0x5333 S3
[...]

I like my typo hypothesis better all the time.

If your card said "88115333" instead of
"56315333", you might be in business by now.
If Tru64 does not see "56315333" in its list
of friends, you may never get any more than
the lame VGA behavior.

I assume that if the SRM firmware recognizes
the ID number, it'll show a name string (like
mine). If not, it'll show the number, which
is all it has (like yours). I've seen this
change from number to name for some card or
other (once upon a time) because of a
firmware update.

Speaking of which, is your firmware up to
date?

ftp://ftp.digital.com/pub/Digital/Alpha/firmware/
ftp://ftp.digital.com/pub/Digital/Alpha/firmware/archive/alpha1000a/

[Steven Schweda]

For hints as to acceptable (similar to
"supported") cards, see "/etc/sysconfigtab".

If you're feeling adventurous, you could try
adding an entry with the ID of your card.
You could get lucky. Perhaps that "trio"
driver (or "svision"?) has unsuspected
versatility.

On VMS, there's an official
SYS$SYSTEM:SYSCONFIG.DAT, and a
user-may-fiddle
SYS$SYSTEM:SYS$USER_CONFIG.DAT. On Tru64, I
didn't see a separate user-may-fiddle file,
so it'd probably be wise to save a pristine
copy of "/etc/sysconfigtab" before you start
wrecking it.

[Capt J S McKenzie]

Here is a status review after several hours more work.
I am very grateful for the help and comments so far but evidently need more if I am to resolve this issue.

Bearing in mind Xman's observations and Stevens agreement that it was really necessary to genuinely disable the on-board Cirrus chip before trying to get the PCI card to be tested, I built an ECU diskette from backup images as follows on a PC:-
W98 booted in MSDOS mode
format a:/s
label SYSTEMCFG (upper case as in Alpha 1000A user manual)
files copied to A:
files verified using wordpad to maintain formatting
all looked fine and check that cfg (5000) for 1000 and 1000A was present.
moved floppy to alpha
powered down and restarted
at >>>runecu
[answer] Loading Arc Firmware from Flash
Arc Firmware Loaded

Then nothing. Keyboard dead so no good. No lights on floppy drive.
Only a reset brings alpha back to life, and back to the srm chevrons.

I did this whole job three times with constant results.

As the floppy seems good I next tried test at SRM and results suggest floppy drive may be NBG but not absolute because the error given is that EVA0 file cannot be opened. As the only floppy I have that can be tested is the one that will not load as an ECU it could still be the floppy rather than the drive. However it should be noted that when UNIX is booting there is a constant error of
fd internal drive error [Unsupported media] whether there is a floppy in the drive or not. I don't know if this is a red herring or not.


OK, so if I can't run the ECU at present I tried another tack.
I removed the PCI card and re-enabled the on-board vga jumper, moving the monitor to the vga port. Ran test at >>> seemed OK.

Booted as normal and hey presto a gui appeared with Xserver apparently running as it should with a low resolution of 640x480. I tested this for a couple of hours and mouse etc worked fine with sysman actions all possible from the screen and netscape browsing world-wide.
Note well that the Xserver.conf file had not been changed from what it was while trying to get the PCI card working so the entries I noted earlier i.e
-screen0 640x480
etc etc were still in the conf file.
I reasoned that they should not be there for the default operation of the Cirrus chip and so edited the file (/var/X11/Xserver.conf) to remove the entries and rebooted.

Oh dear. No gui. No gui whatever I do. Putting the entries back and rechecking, rechecking. Taking them out. Powering down. Test and init. You name it I have tried it.

Clearly if Xserver started once with this physical configuration it should start again so what have I done to upset it??

The Xerrors file gives two errors each time e.g.
error (pid 1049): Server unexpectedly died
(5 seconds later)
error (pi 1049): Server for display :0 can't be started

which is not terribly helpful.

Perhaps Xman can come back now that we are looking at a bog standard cirrus low res chip which has worked once so showing that it can!

Baffled.
stuart mckenzie

[Capt J S McKenzie]

One additional error info to above.
I have endeavoured to start xdm from a running system and consistently get the following info from /usr/var/X11/xdm/xdm-errors

error binding socket address 177
fatal server error
failed to establish all listening sockets
server unexpectedly died
server for display :0 cant be started session disabled.
stuart mckenzie

[Steven Schweda]

> error binding socket address 177

I'd guess that that's caused by port 177
(xdm) being already in use. Perhaps because
someone's trying to start multiple X/xdm/???
servers?

(Time for a fresh OS installation? Not
classy, but it might be faster than trying to
find the problem in the start-up scripts.)

[Capt J S McKenzie]

Steven
Yes of course. That is why the error message is not quite the same. The startup has assigned socket 177 even though the Xserver failed so to try xdm in the system when running gives the extra socket errors. Just checked with netstat after boot and see an entry
udp 0 0 *.177 *.*

I am reluctant to go right back to a new OS because the patch kit 3 took hours to install and who is to say it will go right 2nd go?

I would do that if I had not had a successful start once. Surely there has to be some simple explanation why only once????
stuart mckenzie

[Capt J S McKenzie]

Update

Still trying :)

Obtained a Compaq V90 monitor just in case of compatibility but no difference.

Posted to TRU64-unix newsgroup just in case somebody there does not read the HP forums but no joy.

I wonder whether it is worth doing a sizer and trying to build a new kernel with doconfig might help. Certainly genvmunix on its own makes no difference.

stuart mckenzie

[Capt J S McKenzie]

Hello again. This thread was not closed because no resolution was ever achieved.

I have now obtained a Permedia 2 8mb PCI video card shipped in from States which I am assured by Island computers is an own brand Gloria Synergy 8mb card.

I still cannot get Xserver to start although the messages file looks more promising after putting the card in pci0 slot 13 as it says comet0 unknown card with 8mb frame buffer and then says console is comet0

However X server still has same errors in /var/X11/xdm/xdm-errors.


I will come back to that later as previous posts insisted that it was necessary to ensure that the ECU diskette was run to instruct the system that the Cirrus was not to be used (the vga J27 has already been put to disable). I cannot get this to work at all. I have the correct diskette with the correct label and the files look OK if you examine them on a pc with loads of .cfg files. Also test at SRM gives no errors on DVA0 after ten minutes run.

The system is brought up to SRM from power off and ecu entered at chevrons
The screen says Loading Arc Firmware from Flash
Arc Firmware loaded

The floppy drive appears to read from the diskette for about 20 seconds and then the light goes out but system is hung and no menu comes up.

What do I do to ensure that the Eisa config is correct please? It seems silly to continue to try and get the graphics card working if the problem lies with the Cirrus chip.

[Steven Schweda]

> [...] no menu comes up.

You checked _all_ the graphics outputs?

I don't know any more than I did some months
ago, but I think that you may be chasing off
in the wrong direction.

If the console stuff is appearing on the
ELSA-like card ("comet0"), then it would
seem that the VGA capability of the built-in
chip is being ignored about as much as you
could hope for. If all the ECU-related
activity is intended to disable its VGA
capability, then I'd say you're beating a
dead horse.

Of course, disabling the VGA capability of
the built-in chip is not the same as
completely disabling the chip (which is
probably not possible/practical, as desirable
as it might seem to be).

> [...] X server still has same errors in
> /var/X11/xdm/xdm-errors.

Same as what?

I did recently replace an ELSA card with an
ATI Radeon 7500 in an XP1000. That involved
changing the "args" section of
/var/X11/Xserver.conf (->
../cluster/members/{memb}/X11/Xserver.conf)
to get the resolution, depth, and other
display properties set as I wished.

If the X server software now sees two
available chips/cards (old Cirrus, new
ELSA-like), then you may need some special
multi-head X configuration stuff to get
things to work as you'd like. Naturally, I
know nothing about dealing with more than one
graphics interface.

Another random thought: In my fiddling, I
found this command sequence to be useful:

/sbin/init.d/xserver stop
/sbin/init.d/xserver start

[Capt J S McKenzie]

Hi Steven
Thanks for keeping faith and continuing to try!

The work with the ECU is in response to Xman's post. I quote from April 11

"To install a Graphics Card upgrade, you will need to disable the on-board Graphics card by moving the VGA jumper on the mother board to the OFF position. (Check your hardware manual for the pin location)

Then you will need to run the EISA Config utility to disable the on-board graphics option within the bios.

Only after doing this will you be able to get another graphics card to be recognized by the system."

As you say the VGA seems to be coming from the Elsa like card because the messages file says comet0 is console and yes I checked the other monitor output at the top of the cabinet and no output was present.

The error messages from Xserver in /var/X11/xdm/xdm-errors are:-

xdm error (pid 1205): error binding socket address 177

Fatal server error:
Failed to establish all listening sockets
xdm error (pid 1205): server unexpectedly died
xdm error (pid 1205): Server for disply :0 can't be started, session disbled.


Dave Turner of Island Computers suggested that I should reinstall Tru64 so I backed the current system up to DLT and first tried doconfig -a to build a new kernel. I did that twice, once with existing vmunix and once with genvmunix but no change.

I then started the installation from CD which must have all the drivers but it failed to start the Xserver and said if I wanted to continue I had to restart with 'restart nogui'.
After getting to the same point three times I aborted as I could not see the point of reinstallation if it could not create a working Xserver from the hardware as currently installed.

Perhaps Rick Retterer can re-post re the ECU??

stuart mckenzie

[Steven Schweda]

Ok. I had lost track of the idea that the
ECU stuff could _totally_ disable the Cirrus
chip, not just the VGA part.

Anything interesting in "/var/dt/Xerrors"?

Send some e-mail to me at sms@antinode-org
(more or less), and I can point you to my
collection of ECU stuff. Of course, my
actual ECU experience is nil, as my junk is
all non-EISA.

[Capt J S McKenzie]

OK Steven wilco.

No nothing in var/dt/Xerrors just a repeat of xerrors

failed to establish all listening sockets
server unexpectedly died
server cannot be started for display :0

[jim owens_1]

First a warning that all I know about tru64 xserver and graphics comes from beating my head on the desk trying to setup my workstation.

The recommended reinstall is one way that usually works for me but sometimes it is confused by the hardware and doesn't get all the options correct.

I never used a 1000A, but I think with J27 set OFF you should not need the ECU change for tru64. You should have the ELSA VGA switch ENABLED so the console works. I recommend being at the latest firmware 5.7 (SRM 5.7-83 will be displayed with "show config | more").

I (painfully) know that "doconfig -a" doesn't build in the correct driver for any graphics option board. This is because "all options" means just "kernel features" and not "hardware support".

You need to edit your config file and use "doconfig -c" to build the kernel. In the config file you should see:

# Static Driver Definitions

followed by "config_driver" lines.

You want to add the line:

config_driver comet

AND comment out or delete any lines with these other graphics drivers:

# config_driver ati64_vga
# config_driver s3trio
# config_driver vga
# config_driver cirrus
# config_driver qvision
# config_driver wd
# config_driver p3g
# config_driver radeon
# config_driver tga
# config_driver pvp

then build the kernel and copy it to /vmunix

... Now moving on to Xserver.conf

1) make sure it has

! device <
! >

(device is commented out) and not something like:

device <
< _dec_e3sc lib_dec_e3sc.so e3scInitProc p00e01091 >
>

which would be enabling different graphis.

I set these for ELSA to match my monitor:

args <
-pn -nice -2 -screen 1280x1024 -depth 24 -vsync 75
>

Note those are the highest settings that work together with the 8MB card.