Unix-PC crashing during uucico

[John McMillan]

In article <1990Jan31.170216.27161 at eci386.uucp> clewis at eci386.UUCP (Chris Lewis) writes:
:
>Well thanks a whole hell of a lot:

	Your attitude is contageous.

>	1) This isn't RS232, this is OBM - different driver.  The only
>	   thing I have on RS232 is a 300 baud diablo printer and the 3b1
>	   has *never* crashed during printing.

	Reconsider.  Only the phone-line polling and call setup
	software differ.  Your OBM is fed from the On Board RS232
	[sans line-drivers]!  Their shared hardware was so
	intertwined it took years to find some insidious the
	bugs resulting from the sharing.
	
	[Sorry, much as we'd like, we can't take credit for writing
	the original drivers: we were too busy planning to screw up
	your phone network calls -- ref: below.]

>	2) I've been asking this question every other month for quite a bit
>	   longer than you've been posting to this newsgroup, and have *never*
>	   gotten any response other than vague references to the power supply.
>	   (It can't be the powersupply, because the machine has been completely
>	   replaced and is still exhibiting the same problem at the same
>	   frequency, *AND* none of our other 6 machines have ever panicked
>	   in this fashion - some of which UUCP more per day than ecicrl
>	   does.  They're all the same version of the O/S.  So, it must be
>	   something environmental).

	Well... this shatters me.  While I've worked hard at answering
	questions though lacking adequate data, I've a ways to go.
	'Seems to me this is the 1st time I've caught references to
	your DUART activity.  [OK, I admit it: I stopped curling up
	with your notes at night, and I don't recall them all.]

:
>	5) It's worthy of note that people are *still* suggesting power supply
>	   problems - in particular, people as knowledgable as John Milton...
>	   So it ain't all that well known.

	As I stated: the problem is well understood and well documented.
	In the "brief" time -- compared to your contributions --
	that I've been posting to this group, I've described the
	problem several times.  I've also described it in technical
	conversations and memos within AT&T.

	If you present "crashes during DUART activites" to a sober,
	knowledgable 3B1-support person, they should recognize the
	strong possibility of illegally interleaved command sequences
	to a DUART chip.

	I'm *NOT* saying your problem *IS* the DUART problem: just
	that these are the symptoms of it.  I would ALSO consider
	power-supply problems and noise problems -- I would NOT be
	running this machine without Ruby(tm) [or analogous] line-
	conditioners.  I would NOT be running this with an ancient
	kernel that has not benefitted from at least the 3.51 fixes.
	
>	6) It's worthy of note that several very knowledgable people in AT&T
>	   have been consulted (outside of normal support channels) and *no*
>	   concrete suggestions or suspicions have ever been expressed.

	I'm hardly privy to the details you presented them, but
	I'll take your word they were ultra-knowledgable.  It's
	entirely possible that the Tier-II & Tier-IV staff I've
	explained the problem to have deliberately kept this matter
	a secret.  [After all, THEY don't get a chance to nobble
	the phone network as often as they'd LIKE!  So... they
	take it out in other directions.]

>	7) You might want to ask Lenny what happened to our 3.51 upgrade...
>	   (Though it's not his fault...)

	OK -- 'Fess up, Lenny.  We know you've got it and we're
	showing up tonight to take it or you're gonna regret it!

	Actually, in -- am I right Lenny? -- hundreds [seems like
	thousands] of communications with Lenny, he's failed to
	mention your upgrade.  [You sly bugger, Lenny.]

>American Telephone and Telegraph: one might make similar suggestions regarding
>your company's inability to keep the long distance telephone network running...

	Cute.  Trite, simplistic, and irrelevant... but cute!

>Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis
>Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list

john mcmillan -- att!mtune!jcm