Path: utzoo!attcan!uunet!cs.utexas.edu!natinst!bigtex!texbell!ssbn!bill From: bill@ssbn.WLK.COM (Bill Kennedy) Newsgroups: comp.unix.i386 Subject: X11 under 386/ix 2.0.2 Message-ID: <1246@ssbn.WLK.COM> Date: 25 Nov 89 13:20:40 GMT Distribution: na Organization: W.L. Kennedy Jr. & Associates, Pipe Creek, TX Lines: 61 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