[unix-pc.general] Bug in FIXDISK 2?

tkacik@rphroy.UUCP (Tom Tkacik) (02/02/90)

I recieved FIXDISK 2 last night and installed them looking forward to
seeing what Lenny was talking about (Metermaid etc.).

After rebooting and playing a little bit, I managed to lose the ksh that
was running in a full screen window.  The working icon was lit, and nothing
else worked.

I opened a new window, and ran ps.  The ksh in the original window was
not listed.  Oh well,  may as well continue.  After some further playing,
that ksh also died.  Opening a yet another window and running ps showed
that again ksh had died, but the window was left behind.

I decided to see if the window was still active so I did something like
$ echo hello > /dev/w6

Sure enough hello was displayed in the dead window.
But I still could not get rid of the window.  Maybe logging out
will help, (so I did).

When I logged back in, what did I find but that same window just sitting
there.  It seemed that the kernel had somehow forgotten its existence.
Rebooting DID fix it.

I have never seen this happen before, so I can only assume that this is
a new bug introduced in 3.51m.  I do not know how to duplicate this.
Has anyone else seen this problem, or perhaps know its cause?

Also playing with the three-shift-key functions showed that they were
acting kinda' flakey as well.  (They would not always toggle properly.)
Maybe these problems are related, I do not know.

Any guesses?


-- 
Tom Tkacik		GM Research Labs,   Warren MI  48090
uunet!edsews!rphroy!megatron!tkacik		Work Ph: (313)986-1442
"Csh must go.  This is non-negotiable!"

jcm@mtune.ATT.COM (John McMillan) (02/06/90)

In article <21503@rphroy.UUCP> tkacik@rphroy.UUCP (Tom Tkacik) writes:
>I recieved FIXDISK 2 last night and installed them looking forward to
>seeing what Lenny was talking about (Metermaid etc.).
>
>After rebooting and playing a little bit, I managed to lose the ksh that
>was running in a full screen window.  The working icon was lit, and nothing
>else worked.

	Lots of folks are running 'm' with no such trouble.
	'Probably some local fluke in the way your system went
	down... or the way it's administered.

:
>I have never seen this happen before, so I can only assume that this is
>a new bug introduced in 3.51m.  I do not know how to duplicate this.

	Is this a COMPLAINT?-)  You have a MOMENTARY problem and you
	WANT it to recur?  ...  Geee... there are LOTS of kernels
	on the back shelf if you want THAT !!!

>Also playing with the three-shift-key functions showed that they were
>acting kinda' flakey as well.  (They would not always toggle properly.)

	The code is particularly sensative to the RATE at which you
	toggle the keys: normal typing rates will cause some confusion
	in the triple-key handler.
	
	Methinks it's associated with the RE-DISPLAY of the STATUS
	information:  you're toggling it faster than it can re-display
	and it becomes temporarily confused.  This is difficult
	to avoid IF re-displaying is to occur here, and re-displaying
	seems better than leaving an out-of-date status line.
	
	NOTE: this is done within the kernel and within the keyboard
	interrupt handler.  If a complex routine were demanded to
	unravel the diversity of state transitions, all this would
	have been discarded!  The simple code has its limitations.

>Maybe these problems are related, I do not know.

	Distant cousins... hardly know one another....

john mcmillan -- att!mtune!jcm -- muttering for self, not THEM