cnrdean@topaz.berkeley.edu (12/03/86)
Every once in a while, a "login" process runs forever on our Zilog 8000/31 computer. I cannot kill this process, and nobody can use that port. The only solution is to reboot the whole system, which is a drag. I know the cause of the problem (ie. what causes the login to get stuck). But, assuming that I can't make that go away, I need to find out how to kill this process. Any ideas? Thanks. Sam Scalise
jrw@hropus.UUCP (Jim Webb) (12/09/86)
> Every once in a while, a "login" process runs forever on our Zilog > 8000/31 computer. I cannot kill this process, and nobody can use > that port. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv > I know the cause of the problem (ie. what causes the login to get > stuck). But, assuming that I can't make that go away, I need to > find out how to kill this process. Care to let us in on it? Usually, non-killable processes are sleeping on an event at a priority that does not recognize signals, so you have to cause the wakeup. If on a terminal, sometimes the brute force method of plugging and unplugging the cable causes the hardware to awaken the process. -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw "Make sure comments and code agree. If not, write a man page..."
grr@cbmvax.cbm.UUCP (George Robbins) (12/10/86)
In article <818@hropus.UUCP> jrw@hropus.UUCP (Jim Webb) writes: >> Every once in a while, a "login" process runs forever on our Zilog >> 8000/31 computer. I cannot kill this process, and nobody can use >> that port. > > vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv >> I know the cause of the problem (ie. what causes the login to get >> stuck). But, assuming that I can't make that go away, I need to >> find out how to kill this process. > >Care to let us in on it? Usually, non-killable processes are sleeping >on an event at a priority that does not recognize signals, so you have >to cause the wakeup. If on a terminal, sometimes the brute force method >of plugging and unplugging the cable causes the hardware to awaken the >process. >-- >Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw > "Make sure comments and code agree. If not, write a man page..." I assume that this is the XON/XOFF race problem with Zilogs's ICP "intelligent" communications processor board. Call it firmware confusion. It was added to Zilog's known problem list maybe a year ago, but unfortunatly Zilog never caught on to the idea that bugs, especially gross, embarrassing/must reboot type bugs are supposed to be fixed! Perhaps that's one reason the systems division is all but down the tubes... People interested in Zilog S8000/ZEUS issues are invited to join the mail-zilog mailing list - {seismo|ihnp4|rutgers|allegra}!cbmvax!mail-zilog-request -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)