[comp.unix.i386] X11 under 386/ix 2.0.2

bill@ssbn.WLK.COM (Bill Kennedy) (11/25/89)

I have had a number of problems bringing up 2.0.2, I'm pretty sure
that they are all hardware related since I have two neighbors who
haven't had the same problems.  This is probably hardware related
too, but maybe someone has seen it as well and can suggest a fix or
better approach.

Equipment:  Micronics original 16MHz, 6MB RAM, Computone AT-8 serial
card, Everex 60Mb cartridge tape (IRQ5), Logitech bus mouse (IRQ4),
generic cloneware I/O card (LPTB on IRQ7, both serials disabled),
WD1007 controller with two CDC 150Mb's, Orchid ProDesigner Plus VGA.
The drives/controller were mentioned last because they were added
for the 1.0.6->2.0.2 upgrade, everything else worked fine in 1.0.6.
I had to upgrade the motherboard BIOS to Phoenix 1.10 10 to get the
ESDI's to work.

One of the nagging problems on the way to having X11r3 1.0 not work
might be related.  From time to time and for no apparent reason, I
would make a new kernel that when booted, would report that getty
to the concole (and any enabled vt's) was spawning too rapidly and
stall until I rebooted.  No recovery effort short of a complete
re-install would cure that.  I tried booting from the floppy and
restoring all of /dev, init, and the stuff you'd think about, but
the symptom was the same, even when running the second level install
/tmp/-sh < /tmp/dev/console > /tmp/dev/console.  A complete "new"
install (the count is up to nine) seemed to handle it until it
happened again.  Suspecting bad media (there were two manufacturing
errors in my diskettes), I borrowed a known-to-work set of diskettes
and they did the same thing.  I'm curious to hear any suggestions
regarding this and opinions as to whether or not it's related to the
(finally! whew!) problem with X-windows.

The problem is that xinit can not get anything started.  At first I
got a rather prompt message (other than the no socket warning) that
reports XIO error 32, suspecting a broken pipe or something that got
cancelled by KillClient.  I thought that there might be something
wrong with streams, so I removed streams and X11, built another
kernel, added them back in and built another.  Now xinit clears the
screen (no cursor) and stalls until a vt switch is started from vt01
to vt00 and the same error message appears on vt01.  A subsequent
switch to vt00 works.  I checked from another terminal while xinit
was stalled and it appears that everything was normal.  The /tmp/,X11-unix
directory was there and the X0 entry was in it.  The ps showed xinit
running from vt01 and X0 on the next available vt.  I tried with
/tmp on a different file system (it's normally on drive 1) and
in the root file system, same behavior.  I changed the number of vt's
with gettys and X0 seemed to correctly acquire the new one.

I have not yet moved the Orchid to an 8 bit slot or set it for 8 bit
mode (someone said they had fixed a similar problem that way), but
I will try that today.  I have tried an 84 and 101 key keyboard,
someone else said that they got theirs to work doing that.  Any ideas
of what might be happening?  Any suggestions for a workaround?

Finally (mercifully), has anyone gotten VP/ix to quit gracefully from
an Orchid VGA?  It seems to come up OK, but when I quit, the display
freezes and I have to switch, in the blind, to the console vt and
run a shutdown to recover.  Flames welcome too if there's something
stupid that I just overlooked or didn't do.  I'm stumped...
-- 
Bill Kennedy  usenet      {attctc,att,cs.utexas.edu,sun!daver}!ssbn!bill
              internet    bill@ssbn.WLK.COM   or attmail!ssbn!bill

jlg@odicon.UUCP (John L. Grzesiak) (12/03/89)

Interactive and most other IX386 systems respawn too quickly if there
are duplicate inittab labels:

|| -- These character positions
------------------------------------------------------------------------
01:23:respawn:		/etc/getty tty000 9600
01:23:respawn:		/etc/getty tty00 9600

the 01 header is /etc/init 's label for spawning. If there are two entries
the same , init will start them both and then scan the process table. When
it finds two entries for the same label it freaks out. I saw this problem
first when installing an Anvil terminal subsystem. It seems when placing its
init file in /etc/conf/init.d , they did'nt place init labels in front of
each entry. So when I would rebuild the kernel and it did an environment
setup, the setup would assign labels to entries that did'nt have them.
Guess what! , the anvil lines were assigned labels duplicating the internal
serial boards, and thereby causing init to go nuts. The fix was to simply
assign unique labels in the appropriate init.d file.


	*-----------------------------------------------------------------*
	* John Grzesiak @ Omega Dynamics :  Specializing in UNIX/XENIX    *
	* Meriden Ct USA                 :    Consulting . . .            *
        * jlg@odicon or spock!odicon!jlg : gaboon!odicon!jlg              *
	*-----------------------------------------------------------------*