X server will not start

[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.