Thanks to:
Jacques Demeulemeester <demeule_at_univ-lille3.fr>
William Flett <will_at_dcs.rhbnc.ac.uk>
alan_at_nabeth.cxo.dec.com
The original question is at the end of the message
I received varied suggestions on this one.
Alan suggests that I uninstall (setld -d) the subset containing the X
server while leaving other X-related subsets in place, so the server may
still be used by remote X-servers and clients programs.
Jacques points out that the SRM console command "set server" should be
set to on, thus preventing hardware checks to desperately try
initializing the non-existent keyboard. Alas, I could not (so far) halt
the server and verify the "set server" setting.
William presents a way to disable the startup of the X server:
[Begin William's]
If you don't have a need for an Xserver running on this machine you
can disable it by commenting out the local machine Xserver entry in
the /var/dt/xdm/Xserver file. Simply put a hash infront of the :0
entry and restart xdm. Try rebooting the system afterwards to ensure
that the change has been permanent.
Just one word of warning (this maybe why this has just started
happening
after your upgrade). There is a comment is the Xserver file header
which says:
# /usr/dt/config/Xservers is a factory-default file and will
# be unconditionally overwritten upon subsequent installation.
So you'll always have to check this entry is commented out after any
system patching, upgrades etc.
[End William's]
I'll definitely take a look at this last suggestion, since it is less
obtrusive than uninstalling subsets.
Once again, thank you guys!
#-#-#-#-#-#-#-#-#-#-#-#- Original question #-#-#-#-#-#-#-#-#-#-#-#-
Hello fellow DU-admins,
Yet another problem has cropped up with our DEC3000-M500. The server is
NOT equipped with a graphics display NOR an attached keyboard. Instead,
we use a serial VT420 console, and the "alternate console" switch on the
back of the machine is set accordingly. dtlogin is configured to run at
startup since X-terminals (Exceed PC emulator actually) are used to get
to the machine.
Upon bootup, we used to see a few messages like "unrecognized keyboard
ID (0xffffffff), defaulting to LK401" and "Mouse/Tablet has failed to
reset." displayed on the serial console before we could actually log on.
After a few seconds, the serial console is useable.
Now, some changes were applied to the system: went from DU4.0b to 4.0d,
jumbo patch 2 was applied, kernel has been recompiled to set some
semaphore values (required for the proper working of ArcInfo) and others
things also (NTP among others).
We the system was rebooted last friday night, instead of getting 1 or 2
messages, the system continually threw these messages at the screen for
about 10 minutes. I was able to succesfully rlogin to the machine from
another host, but observing extreme sluggishness. Firing up the top
utility, I could see that the Xdec process was taking 99.9% of the CPU
during this phase. Xdec eventually get tired of retrying to initialize
the keyboard and gives up. After then, the system is perfectly normal.
What could I have changed that affect the duration of the
keyboard-initialization phase? Any suggestions/comments are welcome.
Thank you.
--
Charles Vachon -- Administrateur de systhme
Fonds de la Riforme Cadastrale du Quibec
Ministhre des Ressources Naturelles du Quibec
cvachon2_at_mrn.gouv.qc.ca -- (418) 627-6355 x2760
Received on Wed Nov 11 1998 - 15:05:29 NZDT