jbm@uncle.UUCP (John B. Milton) (06/14/88)
Well, I got tired of the phone junk crashing my system all the time, so
I took drastic measures:
I removed (deinstalled): phone manager, ate (async_main)
Lo and behold there was a problem: After all this I could only use line
two pulse. Grrrr
Part of the deinstall of ph change /etc/.phinit from "ph" to ".phclr"
The program .phclr is a stupid piece of trash. It is supposed to read the
.lineone and .linetwo files and use this info to tell /etc/phupd how to set
the phone lines. .phclr then sits there like a nice little doggie and makes
the phone manager window blank instead of grey.
Ahh yes, the trouble. Apparently .phclr only processes the first .linexxx
files it runs into and ignores the second. I have two phone lines, voice
on ph0 and data on ph1. Both are touch tone lines. When .phclr finds and
does .lineone, it quits. To get around this bug, I replaced phupd with a
program that prints it's parameters, then used the info to change
/etc/.phinit
-> from:
/etc/.phclr
-> to:
# /etc/.phclr HA HA HA
/etc/phupd ph0 VOICE YES NO NO
/etc/phupd ph1 DATA YES NO NO
Anybody else been through all this and came up with a better idea?
As many of you who are scratching your heads about why this doesn't
match your system, it's because I am running 3.51
I think its about time for us to write a replacement phone manager.
John
--
John Bly Milton IV, jbm@uncle.UUCP, {ihnp4|osu-cis}!n8emr!uncle!jbm
home: (614) 294-4823, work: (614) 459-7641; talk to me about fractalsgil@limbic.UUCP (Gil Kloepfer Jr.) (06/16/88)
In article <293@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: |>Well, I got tired of the phone junk crashing my system all the time, so |>I took drastic measures: |> |>I removed (deinstalled): phone manager, ate (async_main) |> Me too... see below... |>I think its about time for us to write a replacement phone manager. |> |>John Bly Milton IV, jbm@uncle.UUCP, {ihnp4|osu-cis}!n8emr!uncle!jbm |>home: (614) 294-4823, work: (614) 459-7641; talk to me about fractals Yes...but even more important -- examine the operation of the /dev/ph* phone DRIVERS. In the middle of an OS already stranger than many of the unices out there is a piece of bug-laden code which can and should be fixed once and for all. So far, the bugs I have experienced simply because either the driver or the phone management/uucp software (I believe it is the driver) is brain- damaged is: 1. sometimes the line that the handset becomes connected to misteriously becomes line2 (my data line) and reaks havoc with incoming calls, 2. my internal speaker will somehow remain (become) connected to my data line (line 2) and incoming modem signals will be heard (loudly) through the internal speaker. This usually happens when I am not at home, and annoys the folks in the apartment below, 3. processes associated with phone management die or become confused. I'm sure that there are more problems from various folks out there. One more point of clarification -- a lot of folks have been beating the OBM (on-board modem) to death on the net, as well as port tty000. Please folks, the hardware is not at fault. In fact, the hardware as I've seen it (through schematics, of course) is very flexible and has the capability to do what you want without problems. The problem as I see it is the SOFTWARE (ie. the OS). My belief (perhaps incorrect, anyone care to modify/add to this?) is that the /dev/ph* and the i8274 driver bugs need to be collected and fixed. Fixed means that they are debugged, no bugs. After these are fixed, I think that many folks would see a marked improvement in the performance of the phone management software. Of course, let's not stop here -- the net has been a good source of bugs which need to be fixed. If nobody else wants-to/is-able-to fix these bugs, I'd be the first volunteer. Send me the source code to unix :-). Can you believe that the OS in this machine is really written to act as a "safe" interface between user and hardware? +------------------------------------+----------------------------------------+ | Gil Kloepfer, Jr. | Net-Address: | | ICUS Software Systems | {boulder,talcott}!icus!limbic!gil | | P.O. Box 1 | Voice-net: (516) 968-6860 | | Islip Terrace, New York 11752 | Othernet: gil@limbic.UUCP | +------------------------------------+----------------------------------------+
rjg@sialis.mn.org (Robert J. Granvin) (06/18/88)
>One more point of clarification -- a lot of folks have been beating the >OBM (on-board modem) to death on the net, as well as port tty000. Please >folks, the hardware is not at fault. In fact, the hardware as I've seen >it (through schematics, of course) is very flexible and has the capability >to do what you want without problems. The problem as I see it is the >SOFTWARE (ie. the OS). tty000 problems are purely software. The driver(s) were brain damaged, but for the most part have been repaired. Expansion boards, if they have problems are predominantly hardware problems. Although the fix is incredibly trivial. Replace a chip. Of course, if you still have brain damaged drivers, then you'll still not be able to use the ports to full capabilities, even though your machine won't crash quite as seriously. The OBM is another issue altogether, though. Sure. The OBM has had its problems as well because of software. A lot of it was attributed it to a brain damaged (that term is getting used a lot :-) uucico. While not much more intelligent, the uucico fixes have made a marked improvement. But let's take it a step further... A lot of modems out there recognize the OBM as an 1200 baud MNP modem. Believe me. It's not. A lot of modems out there are also fully capable of connecting with any brand of modem providing any "legal" carrier tone. But wait a moment... Then there is the 3b1 and the OBM. All of a sudden you might have discovered a modem that you cannot connect to. This is not OS related, but is hardware related (of course, depending what you consider firmware, that point is debatable :-) Many modems will connect fine, but many will not. Even Telebit Trailblazers under one type of configuration will connect to every available modem (apparently :-) but will always fail on a 3b1 OBM. A different configuration which isn't necessarily as optimum or efficient, works in all cases. While the OBM may not be completely the guilty party, it is certainly at least an accomplice. Even the best hardware is only as good as how well it operates. In many ways the OBM works better than a lot of commercial modems, but in other ways, it leaves a lot to be desired. Anyways, that's all subtopics. There are a lot of software items that should be fixed or at least notably enhanced, but don't expect anything from it. ATT isn't going to put a lot of effort to fixing something that works (even if it doesn't work well, it still works), and source is practically impossible to obtain (even certain sections of ATT's 3b1 support groups weren't able to get the source for a long time...) (Although, not to be unfair - for the past several weeks, I've been keeping in touch with a very small subset of technicians, keeping tabs on the current state of some repairs and reporting new problems as they are made known. While not everything may be repaired, these techs are handling the items very well (surprisingly, at times. And no, these are not the "phone techs" which I have had some very frustrating experiences with). These people are taking serious issues with the seriousness it deserves, plus they perform what is normally considered a reasonable test period. The advantage is that the updates or fixes released are more than likely solid and complete. The disadvantage is that you have to wait, and normally can't find out what's being repaired...) -- "I've been trying for some time to Robert J. Granvin develop a life-style that doesn't National Information Systems, Inc. require my presence." rjg@sialis.mn.org -Garry Trudeau ...{{amdahl,hpda}!bungia,rosevax}!sialis!rjg