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 *
*-----------------------------------------------------------------*