robert@CSUStan.EDU (Robert Zeff) (04/22/89)
I have an AT&T 6386 which hangs in uucico when the call is aborted.
The uucico process cannot be killed, even from root. I also have had cu
hang this way. AT&T has not offered any useful advice. Seems to me that
root should be able to kill any process. We're using a Telebit Plus.
Anyone else having this problem or have a solution?
(Ant tips on how to handshake with the Telebit would be appreciated, also)
Thanks,
--
Robert Zeff (209) 577-4268 work, 577-8548 FAX
ZAPCO
2549 Yosemite Blvd Ste. E {lll-lcc,lll-crg}!csustan!zhome!robert
Modesto, Ca. 95354 {lll-lcc,lll-crg}!csustan!robertles@chinet.chi.il.us (Leslie Mikesell) (04/23/89)
In article <1055@koko.CSUStan.EDU> robert@CSUStan.EDU (Robert Zeff) writes: >I have an AT&T 6386 which hangs in uucico when the call is aborted. >The uucico process cannot be killed, even from root. I also have had cu >hang this way. AT&T has not offered any useful advice. Seems to me that >root should be able to kill any process. We're using a Telebit Plus. >Anyone else having this problem or have a solution? See if you can duplicate the problem this way: Get a connection, send an XOFF to the port from the remote side and drop the line. If this leaves the line locked, try to reconnect and send an XON at the same speed. I had trouble with this years ago on the 3B2s - perhaps they haven't learned anything. Is this on the built-in serial port or an IPC board? Les Mikesell
pat@mslanpar (Pat R. Calhoun) (04/25/89)
In article <1055@koko.CSUStan.EDU>, robert@CSUStan.EDU (Robert Zeff) writes: > I have an AT&T 6386 which hangs in uucico when the call is aborted. > The uucico process cannot be killed, even from root. I also have had cu > hang this way. AT&T has not offered any useful advice. Seems to me that > root should be able to kill any process. We're using a Telebit Plus. > Anyone else having this problem or have a solution? > (Ant tips on how to handshake with the Telebit would be appreciated, also) If you happen to have the driver source, you will more than likely find that the priority to sleep is less than PZERO. This means that a signal will not kill (or wakeup) the process. This is the reason why the process is unkillable. By exec'ing a ps(1) - 'laef', you will find the process' priority will be <26, this means if that process is hung, you can kill it by executing an init 0 (probably not what you want:-). I need more information regarding your problem. First, are you using the standard serial port?? or are you adding a multi-port board (such as CTC's GEMINI-10)?? I also need to know what BIOS PROM version is in your system(the 386 obviously:-). Right now I'm making the assumption that you are using ATT SYS V, and not XENIX, so you might want to specify you OS!! -- "The statements above does not necessarily reflect the views of the writer, the President of the United States, or the cleaning staff." _^_ ||| Pat "King of the Trenches" Calhoun <o o> | Technical Support Group, Lanpar Technologies /\/\/\/\/\ UUCP: ...!attcan!nebulus!tslanpar!mslanpar DISCLAIMER: "Read the DAMN manual, I don't need this SHIT!!"
root@nebulus.UUCP (Dennis S. Breckenridge) (04/27/89)
In article <138@mslanpar>, pat@mslanpar (Pat R. Calhoun) writes: > In article <1055@koko.CSUStan.EDU>, robert@CSUStan.EDU (Robert Zeff) writes: > > I have an AT&T 6386 which hangs in uucico when the call is aborted. > > The uucico process cannot be killed, even from root. I also have had cu > > hang this way. AT&T has not offered any useful advice. Seems to me that > > root should be able to kill any process. We're using a Telebit Plus. > > Anyone else having this problem or have a solution? > > (Ant tips on how to handshake with the Telebit would be appreciated, also) > > If you happen to have the driver source, you will more than likely find > that the priority to sleep is less than PZERO. This means that a signal > will not kill (or wakeup) the process. This is the reason why the process > is unkillable. By exec'ing a ps(1) - 'laef', you will find the process' > priority will be <26, this means if that process is hung, you can kill > it by executing an init 0 (probably not what you want:-). > > I need more information regarding your problem. First, are you using the > standard serial port?? or are you adding a multi-port board (such as > CTC's GEMINI-10)?? I also need to know what BIOS PROM version is in ^^^^^^^^^^^^^^^^^ Is this the IPC-802 sold by AT&T I don't think so. > your system(the 386 obviously:-). Right now I'm making the assumption > that you are using ATT SYS V, and not XENIX, so you might want to > specify you OS!! > Pat writes about driver source. The rest of us do not have access to the source of the drivers but I do know that AT&T does support the "final" release of a binary for the ports card. The release is 2.1 and it fixed a whole bunch of bugs with the IPC-802. Getting a telebit to talk to ANY port (IPC or integral) on the 6386 requires some non-standard cabling. What I had to do was take pin-6 from the TB+ and move it to pin 8 on the port and then I programmed the TB+ to drop that signal on a disconnect. I tried various settings on the TB+ to get carrier to present itself on dial and drop on disconnect but I did not have much success. Making the change in hardware eliminated most of the problems I had. I have included my settups for the Telebit modem here. Try it and let me know if it works for you (after you move DSR to DCD) ERROR at&n E1 F1 M1 Q6 T V1 X1 Version BA4.00 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=007 S11=070 S12=050 S45=000 S47=004 S48=000 S49=000 S50=000 S51=005 S52=002 S53=004 S54=003 S55=000 S56=017 S57=019 S58=002 S59=000 S60=000 S61=045 S62=003 S63=001 S64=000 S65=000 S66=001 S67=000 S68=255 S90=000 S91=000 S92=000 S95=002 S100=000 S101=000 S102=000 S104=000 S110=001 S111=030 S112=001 S121=000 This has been tested on the integral serial port and the IPC-802 without hangups. What Pat failed to say was the driver was sleeping at a PZERO < 25 because the driver was hung trying to close the port without the hardware signaling to allow the close to complete. (TCSETAW hangs if DCD is not lit) This causes both cu(1) and uucico(1) to hang on a close. -- ============================================================================== "A mind is a terrible thing to MAIL: Dennis S. Breckenridge waste!" 206 Poyntz Ave North York, Ontario M2N1J6 (416) 733-1696 UUCP: uunet!attcan!nebulus!dennis ICBM: 79 28 05 W / 43 45 01 N 50 megatons should do! ==============================================================================
lenny@icus.islp.ny.us (Lenny Tropiano) (04/28/89)
In article <828@nebulus.UUCP> root@nebulus.UUCP (Dennis S. Breckenridge) writes: |>In article <138@mslanpar>, pat@mslanpar (Pat R. Calhoun) writes: ... |>> I need more information regarding your problem. First, are you using the |>> standard serial port?? or are you adding a multi-port board (such as |>> CTC's GEMINI-10)?? I also need to know what BIOS PROM version is in |> ^^^^^^^^^^^^^^^^^ |> Is this the IPC-802 sold by AT&T I don't think so. |> The CTC GEMINI-10 is identical to the IPC-802 except for the housing on the outside. AT&T has "IPC-802" written on the cover, of course, and CTC has "GEMINI-10". The IPC-802 port board is made by CTC for AT&T. -Lenny -- Lenny Tropiano ICUS Software Systems [w] +1 (516) 582-5525 lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576 {talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny attmail!icus!lenny ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752
root@nebulus.UUCP (Dennis S. Breckenridge) (04/30/89)
In article <685@icus.islp.ny.us>, lenny@icus.islp.ny.us (Lenny Tropiano) writes: > The CTC GEMINI-10 is identical to the IPC-802 except for the housing on > the outside. AT&T has "IPC-802" written on the cover, of course, and > CTC has "GEMINI-10". The IPC-802 port board is made by CTC for AT&T. Wrong! The CTC Gemini-10 has a driver developed by CTC Systems and the AT&T IPC-802 has a driver written by AT&T Bell Labs. You can check the driver version by doing a displaypkg. AT&T 2.1 is the current release for IPC-802 and what second of the year mod10 is the current CTC Systems Driver. Sooner or later someone will get right. -- ============================================================================== "A mind is a terrible thing to MAIL: Dennis S. Breckenridge waste!" 206 Poyntz Ave North York, Ontario M2N1J6 (416) 733-1696 UUCP: uunet!attcan!nebulus!dennis ICBM: 79 28 05 W / 43 45 01 N 50 megatons should do! ==============================================================================
les@chinet.chi.il.us (Leslie Mikesell) (05/02/89)
In article <834@nebulus.UUCP> root@nebulus.UUCP (Dennis S. Breckenridge) writes: >Wrong! > The CTC Gemini-10 has a driver developed by CTC Systems and the AT&T IPC-802 > has a driver written by AT&T Bell Labs. You can check the driver version by > doing a displaypkg. AT&T 2.1 is the current release for IPC-802 and what > second of the year mod10 is the current CTC Systems Driver. Sooner or later > someone will get right. How about the driver for the serial port on the motherboard? If flow control is enabled, receiving an xoff from the remote will make the attached process unkillable even by root doing a kill -9. If I didn't know better I might think this stuff was written by a company that *wanted* people to lock up their machines forever on long distance calls. Les Mikesell