From owner-freebsd-hackers Wed Jul 7 15:55:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from spoon.beta.com (mcgovern.ne.mediaone.net [24.218.8.93]) by hub.freebsd.org (Postfix) with ESMTP id 2B96A14BFC for ; Wed, 7 Jul 1999 15:55:51 -0700 (PDT) (envelope-from mcgovern@spoon.beta.com) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.9.3/8.9.3) with ESMTP id SAA12143 for ; Wed, 7 Jul 1999 18:55:50 -0400 (EDT) (envelope-from mcgovern@spoon.beta.com) Message-Id: <199907072255.SAA12143@spoon.beta.com> To: hackers@freebsd.org Subject: Terminal CTRL-C processing... Date: Wed, 07 Jul 1999 18:55:50 -0400 From: "Brian J. McGovern" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a dumb question, but I've been trying to hack on it all day, and I'm getting frustrated, so I want throw this in the air for comment... I'm putting the finishing touches on a second revision of the Cyclades Z driver. Its pretty much there, except for when you hit CTRL-C with a shell.... I suspect the problem has to do with an ioctl() call that isn't completing properly, but I might be terribly wrong. In my first test scenario, when I hit CTRL-C, the application continues to write to the port (ie - the device driver write() routine continues to get called), but the data is basically garbage - rewrites of old data, command history - basically just junk output. I'm 99.9% sure its not the write half of the device drive, as I mentioned the write routine is actually being called repeatedly. On one run, I happened to catch some output (on screen, there doesn't appear to be anything in the logs) that a tiocsettr failed, so I suspected that maybe an IOCTL was getting called at too low of a priority, and the interrupt handler was just hosing it. So, I moved the spltty() call to the top of the routine, so baically the whole routine will run at the tty spl level. Then, on rerunning the test, the machine just hung. Any thoughts on what might be causing this when CTRL-C is hit? I'm expecting that SIGKILL is being sent to the ls command thats running, but I don't understand how that could hose the system so badly that everything else fails.... -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message