DBarker@system-m.phx.bull.com ( Deryk Barker) (06/11/90)
Maybe someone has some idea what's going on here. When I boot my SCO UNIX V
3.2 on my 386 I have a problem that appears maybe 8 times out of 10. As the
system comes up it obviously does some sort of equipment initialisation which,
among other things, turns NumLock off on my AT keyboard (which is how I know
it's doing the keyboard init). The problem is that frequently after this init
process the system will not respond to my keyboard at all and I am dead in the
water. If I get past the init with the keyboard working then everything is
fine from that point on; until I reboot, at which time I run the gauntlet
again and probably lose. I am convinced that it is probably some sort of
hardware problem but it NEVER happens with DOS. Can someone suggest what sort
of init UNIX does to my hardware that DOS doesn't do?
Answers by mail please.
"Send Lawyers Guns and Money,
Dad, get me out of this!"
Deryk Barker
Jupiter Software
Victoria, BCR022JR3H@vb.cc.cmu.edu (Joseph A. Rafail [CMU-CC]) (06/12/90)
Please unsubscribe: r022jr3h@vb.cc.cmu.edu wizard@pittvms.bitnet Thank You, jr3h
david@csource.OZ.AU (david nugent) (06/13/90)
In <23600@adm.BRL.MIL> DBarker@system-m.phx.bull.com ( Deryk Barker) writes: >Maybe someone has some idea what's going on here. When I boot >my SCO UNIX V 3.2 on my 386 I have a problem that appears maybe >8 times out of 10. As the system comes up it obviously does some >sort of equipment initialisation which, among other things, turns >NumLock off on my AT keyboard (which is how I know it's doing the >keyboard init). The problem is that frequently after this init >process the system will not respond to my keyboard at all and I >am dead in the water. I should preface this and state that I've had no direct experience with SCO's Unix product. But with Xenix, I often came across this; the release notes mentioned it specifically and explained a patch that could be made to the kernel using adb which fixed it. The problem is related to handling of the LED's on the keyboard; and after the patch, they no longer work. Well, at least the keyboard doesn't lock up any more. :-) On a machine which this used to happen to, I've since upgraded to ISC's product, and I often have something similar happen - usually a keyboard lockup except it occurs more frequently when running an app on one of the terminal consoles which does plenty of termio and messing with keyboard modes. I found that unplugging the keyboard briefly and plugging it back in achieved the same result as the SCO patch - the LED's no longer functioned, and the keyboard became operative again. Anything is preferable to bringing down the system ungraciously... Hope this helps; I'd suggest looking in SCO's release notes to see if you can find anything useful in there. david -- Unique Computing Pty Ltd, Melbourne, Aust. david@csource.oz.au 3:632/348@fidonet 28:4100/1@signet
DBarker@system-m.phx.bull.com ( Deryk Barker) (06/15/90)
Further to my original message: I had several discussions with SCO tech support who could shed no light on this whatsoever. One thing I did notice, quite serendipitously, was that the locking/non-locking of the keyboard seemed to be related to the moment when I first tried to press a key. There is a brief window which lasts approximately from the point at which the system announces its copyright notices to the point at which it announces the bootload device: touch a key during that window and YOU'RE DEAD. The system comes up OK and will run quite happily as long as you don't wish to use the keyboard. As long as you keep your ****ing paws off the keyboard during this window everything is AOK. SCO tech support confirm that this also happens on one of their in-house systems, but it doesn't happen with Xenix. You have been warned... Deryk Barker, Jupiter Software, Victoria, BC "Send Lawyers, guns and money, Dad, get me out of this"