greenber@utoday.UUCP (Ross M. Greenberg) (08/11/89)
An odd problem has been hitting us here. We run with a Compaq 386, running the latest version of Xenix. Computone Serial card. About once per week, something is trashing the system. Not a panic. Instead, it kills the tty drivers in some magical and mystical way. First symptom is that the tty's (even the console) starts to drop characters. Then, it loses echo. Then, things like mail will say "not a character device". Occasioannly, an "stty sane" will bring things back to normal on that one port for a while, but it will screw up rapidly again. I'm pulling out hair trying to figure out what process is running before the screw-up. The only thing I can ascertain is that it almost always happens during a UUCP connection to a remote site. Has anyone else experienced a similar problem, and (if so) what did you do to resolve it? Thanks! -- Ross M. Greenberg UNIX TODAY! 594 Third Avenue New York New York 10016 Review Editor Voice:(212)-889-6431 BBS:(212)-889-6438 uunet!utoday!greenber BIX: greenber MCI: greenber CIS: 72461,3212
mel@fleet.UUCP (mel) (08/14/89)
Have you tried replacing the Computone board with another brand to see if your problem continues? Anvil Stallion cards seem to be pretty solid.
terry@eecea.eece.ksu.edu (Terry Hull) (08/14/89)
In article <14@fleet.UUCP> mel@.UUCP () writes: >Have you tried replacing the Computone board with another brand to see if >your problem continues? Anvil Stallion cards seem to be pretty solid. Several months ago, there was a problem with the Anvil boards reported to the net. It seems they cannot take high speed input from a Trailblazer uucp connection. Has this problem gone away? -- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: terry@tah386.manhattan.ks.us, rutgers!ksuvax1!eecea!tah386!terry
karl@ddsw1.MCS.COM (Karl Denninger) (08/21/89)
In article <767@eecea.eece.ksu.edu> terry@eecea.eece.ksu.edu (Terry Hull) writes: >In article <14@fleet.UUCP> mel@.UUCP () writes: >>Have you tried replacing the Computone board with another brand to see if >>your problem continues? Anvil Stallion cards seem to be pretty solid. > >Several months ago, there was a problem with the Anvil boards reported to >the net. It seems they cannot take high speed input from a Trailblazer >uucp connection. Has this problem gone away? They haven't solved the problems yet, although they keep telling me that they have. Now they're not calling me back again. It's as if we're being ignored. I told them I would keep my trap shut for a day or two in the middle of the week -- since they have seen fit to not return my call, here's the scoop. I am QUITE upset with these people. We have two boards here -- and neither one works right. It's a driver problem, that much we know. Here's a rundown of the problems with the various drivers we have tried: o 2.1.7 (what we use now, for reasons which will become apparent) Will only handle 20kbaud TOTAL ON THE BOARD for input. A single 19,200 baud incoming newsfeed causes output to drop to some 600 baud on a 2400 baud connection -- in short, performance is completely unacceptable. Two telebits on the same board end up being unusable; you will lose connections time after time with lost packets and characters. An attempt to use "rz" to receive at 19200 baud on this driver version will time out and puke after a few packets are sent -- it simply can't handle it. Their attempt to support 38,400 is a joke -- they can't even keep up with half that! To their credit, 9600 baud "rz"s do work most of the time, although they too drop packets here and there. TWO simultaneous 9600 baud rzs fail every time. o Will not reload the board properly on a soft (warm) reboot, this makes autoreboots impossible, and requires a power-cycle after a "haltsys" or "shutdown". o 2.4.1, 2.4.2 Hang at random times on 19200 and 9600 baud input. The port just "goes away", but can be restarted by killing the job on the port. Input performance is actually _worse_ than 2.1.7 (!). Anvil claims they have "no reports of trouble" with these drivers. o 2.5 (May 25 modification date, Jeff@anvilus confirmed that this is current last week) Does strange things, including: o Returns EOF to uucp input requests at random times (!) o Decides to close the port on it's own at random times during high-speed input, giving a "lost line" message from uucp (!). The line was NOT LOST -- DCD is still up at that point. The connection, though, is of course gone. o Refuses to drop DTR if you kill a job waiting on a modem control port (ie: "ungetty /dev/tty402" leaves DTR up!). Attempting to open the modem control port AGAIN, then ^Cing when it hangs (because there is no DSR there!) drops the DTR. o Dialing out on the non-modem control port after ungettying without doing the machinations above (with ^C and the like) appear to be operative in the first two anomolies noted above. This makes the board USELESS for shared dial in/out access on a single line, as uucp can't handle the maneuvers required. o Manually disabling a port, then dialing out on it using Xcomm appears to work but gives gross delays on input -- if I am watching the modem lights at 2400 baud the receive light on the modem goes off 1/2 - 1 second before output stops appearing on the screen! Anvil also claims to have no reports of problems with this version of the driver...... We've been putting up with missed deadlines, excuses and other nonsense for more than seven months. The problems, even after all this time, are NOT fixed. Anvil also has a philosophy problem -- they think that their model (ie: high speed output only) is what their customers all need, and that those of us who want to run high speed modems for input are such a minority that we can be safely ignored. Needless to say, we at MCS (and I'm sure anyone on the net feeding news!) disagree. Anvil has been offered our assistance in resolving these problems -- we asked for source, told 'em we'd be happy to sign a non-disclosure, and that they would be free to use our fixes once they were complete. They refused. Their advertisements used to say "160,000 kb/s throughput (or something similar)". What they don't tell you is that their throughput claims only apply to output, and only if you are doing no input at all! 2.1.7, which is the only driver set we have (and we've got FIVE!) that is stable enough to use, can barely do 1/8th of that for input, 1/16th on a reliable and steady basis. CPU offloading is fine, but not at the expense of reliability and overall usability. When confronted with this obvious error of omission from their ad copy, they said "but we never claimed 160kb/s on input". My contention is that absent a qualification I should be able to get 160kb/s through that card in ANY COMBINATION I CHOOSE -- not some special case that they have concocted to enhance their claims. Anvil's 160kb/s claim is like an automaker saying "this car will do 130 mph" -- what they don't tell you is that it will only do 130 mph on a 60% grade from 9,000 feet, and only for the last 1000 feet of the run! All I want now is a refund for the boards or FIXED DRIVERS >NOW<, although I have a stinking suspicion we are going to end up eating them. (To their credit they did at one point offer to allow us to return the boards -- verbally. We have not, as of this date, been given an RA number or a formal, written offer of a refund). We'd love to buy something else that works, from a vendor that actually returns calls when they say they will, and works to keep customers happy. Digiboard comes to mind; we've begun using their cards, and are very happy with both their performance and support... They actually listen to their customer base. Our current installations on the PC/16 are very happy, and throughput for input is _excellent_. Arnet also has excellent input capabilities. Digiboard did have some initial problems with the PC/16 drivers, but I got a diskette in the mail FIVE DAYS AFTER REPORTING THE PROBLEM, and what do you know - the trouble was actually FIXED! I would have kept my mouth shut if Anvil had returned my calls as promised. They had 48 hours in which to do so, and failed. Here it is folks. Caveat Emptor. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
mel@fleet.UUCP (mel) (08/22/89)
In article <941@utoday.UUCP> greenber@utoday.UUCP (Ross M. Greenberg) writes: >An odd problem has been hitting us here. We run with a Compaq 386, >running the latest version of Xenix. Computone Serial card. > >About once per week, something is trashing the system. Not a panic. >Instead, it kills the tty drivers in some magical and mystical way. >First symptom is that the tty's (even the console) starts to drop characters. >Ross M. Greenberg >UNIX TODAY! 594 Third Avenue New York New York 10016 A friend of mine had the same problem running on an ALR Flexcache 386 CPU. The common denominator is "Computone". He was using two of their 16 port cards. The problem was solved after he contacted Computone and got the specific install software for their version of Xenix. It seems like their software is very taylored to each release of Xenix and required a specific match to work. Mel Shear Way Down Yonder in New Orleans
chip@vector.Dallas.TX.US (Chip Rosenthal) (08/23/89)
karl@ddsw1.MCS.COM (Karl Denninger) writes: >Digiboard comes to mind; we've begun using their cards, and are very happy >with both their performance and support... They actually listen to their >customer base. [...] Digiboard did have some initial problems with the PC/16 >drivers, but I got a diskette in the mail FIVE DAYS AFTER REPORTING >THE PROBLEM I've mentioned it before, but there's so much bitching 'n moaning here that I suppose it's worth repeating the good comments about vendors from time to time. It's possible that there are better performing boards on the market than Digiboard's. Maybe not. But I wouldn't change. The thing which has me really sold on them is their support. It is uncommonly good. First, it's free. They try to focus as much of the support work as possible through their BBS, which is probably an attempt to cut down support costs. They maintain the latest versions of drivers and documentation on the BBS, and registered users are free to download them. If you need to talk to tech support, they don't hang up because you haven't bought some annual support agreement. They don't even sell them. Second, they listen and fix their bugs. A few months back I found a few problems with their drivers. I reported them to Digiboard, and they steered me to the BBS and the latest version. This fixed all but one of the bugs. This last one required a rev to the drivers, and they had me a version to try out within a week. The weakest part of their support I've found is that the tech support people aren't too familiar with unix/xenix, so I'm not sure they would be able to answer a lot of questions on system setup. However, to their credit they were willing to accept my report of problems in the xenix context and get the design folks working on it. (It also helped that I did my homework and gave them full documentation on the problems and software which would duplicate it.) It might sound trivial that they would accept a bug report under XENIX, but too many times I've run into peecee vendors who don't think it's broke unless it breaks under DOS. -- Chip Rosenthal / chip@vector.Dallas.TX.US / Dallas Semiconductor / 214-450-5337 "I wish you'd put that starvation box down and go to bed" - Albert Collins' Mom
bill@bilver.UUCP (Bill Vermillion) (08/23/89)
In article <694@vector.Dallas.TX.US> chip@vector.Dallas.TX.US (Chip Rosenthal) writes: > ..... but too many times I've run into >peecee vendors who don't think it's broke unless it breaks under DOS. Local Nynex won a contract to supply machines for a local community college that I do some work for. Had an IBM-80 under SCO Xenix, that when told for format a disk, would turn on its drive light, hum away merrily, count down the cylinder, and finish - ALL WITH NO DISK IN THE DRIVE. Called the sales weenie - told the problem. Was asked "does it work under DOS". Answer "yes". Reply "Then it's a Xenix problem, we can't help you!" After losing my temper when they didn't seem to understand me when I told them "But I have an indetical machine next to it that works properly" - I finally called IBM, told them about their dweebie dealer, and they got the dealer straightened out and had them replace the drive. You remark is "too often ..." - I feel it is more like "almost always" unless you are dealing with someone who understands multi-user machines. -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!tarpit!bilver!bill : bill@bilver.UUCP Please use either of the above in replies. The Reply To: may be bogus!
clay@uci.UUCP (News Administrator) (08/24/89)
When I evaluated ANVIL Stallion boards back in January (2.1.3 or 2.1.7 drivers) I had input problems at 9600 and 19.2 baud also. The simple protocol I was using was a send/wait much like Xmodem. When I reduced the input packet size to 384 bytes from 1024 input worked fine at 9600 baud from multiple inputs. I would venture that if you told zmodem to use smaller packets, it would work. This is not to say that their drivers shouldn't have handled the larger packet size -- or that they should have admitted the limits up front! Note that the benchmarks are always in 'cooked' mode -- how much emacs or vi editing do YOU do in 'cooked' mode? -- Clayton Haapala ...!mmm!dicome!uci!clay Unified Communications Inc. 3001 Metro Drive - Suite 500 "Revenge is better than Christmas" Bloomington, MN 55425 -- Elvira