Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rick From: rick@seismo.CSS.GOV (Rick Adams) Newsgroups: comp.unix.wizards Subject: Re: UUCP [ultrix] guru needed! Message-ID: <43032@beno.seismo.CSS.GOV> Date: Mon, 29-Dec-86 16:18:03 EST Article-I.D.: beno.43032 Posted: Mon Dec 29 16:18:03 1986 Date-Received: Mon, 29-Dec-86 21:52:09 EST References: <4333@mit-eddie.MIT.EDU> <1269@ncc.UUCP> <1176@cbmvax.cbmvax.cbm.UUCP> <1181@cbmvax.cbmvax.cbm.UUCP> Organization: Center for Seismic Studies, Arlington, VA Lines: 45 Keywords: fixed in 4.3 Summary: Yes it's a bug Yes, It's a bug. It was fixed in 4.3BSD. Here is a rough idea of how it was fixed (Jim Bloom found and fixed this one). I'm not sure that the test for Reacks need to wait for 4. I think 2 would probably be adequate. However, Jim may know of a case I don't. As a general rule, the 4.3bsd 'g' protocol driver is in better shape than ANY uucp available (including Honey DanBer, [gasp]). At a mimimum, it's at least readable (cryptic, but readable) ---rick 4.2BSD pk0.c: case RJ: pk->p_state |= RXMIT; pk->p_msg |= M_RR; case RR: pk->p_rpr = val; ! if (pksack(pk)==0) { ! WAKEUP(&pk->p_ps); } break; 4.3BSD pk0.c: case RJ: pk->p_state |= RXMIT; pk->p_msg |= M_RR; + pk->p_rpr = val; + (void) pksack(pk); + break; case RR: pk->p_rpr = val; ! if (pk->p_rpr == pk->p_ps) { ! DEBUG(9, "Reack count is %d\n", ++Reacks); ! if (Reacks >= 4) { ! DEBUG(6, "Reack overflow on %d\n", val); ! pk->p_state |= RXMIT; ! pk->p_msg |= M_RR; ! Reacks = 0; ! } ! } else { ! Reacks = 0; ! (void) pksack(pk); } break;