marsella@athos.rutgers.edu (Stacy Marsella) (11/06/90)
I am having some difficulty with a newly installed Voice Card in a UnixPC (3B1) and was wondering if anyone had suggestions or info on what may be causing the problem. There seems to be some form of nasty interaction between the Voice card driver and the Ethernet driver so that attempts to use Voice card applications will crash the system if the Ethernet driver is loaded. For instance, when using the voice editor (ve), clicking on record will crash the system. The crash is dramatic, i.e. the system hangs, all the LEDS go out, and there is no core file. However, if I unload the ethernet driver before running ve then there is no problem. The system is a 2meg 3b1. The kernel is version 3.51m. The Ethernet card is in the first slot and I am running version 1.4 of the WIN/3B TCP-IP software (hopefully the most recent version ...). The voice card is in the third slot and the voice board is revision 2.0 (Version 2.1 of the high and low roms - 8/87 date).The voice card system software is the most recent revision (I neglected to write it down but it is 2.?). There are no cards in the second slot. Finally, there is a line in unix.log as follows which I don't think is pertinent but here it is anyways: drv:0 part:2 blk:9841 rpts:1 <date-and-time> Before I go into "Let's try this" mode, I thought I would appeal to persons more knowledgeable in these matters. Any suggestions as to what is wrong or what I should try? (e.g. Should I attempt moving the cards into different slots? Should I reinstall software?) Thanks very much for any help Stacy Marsella marsella@aramis.rutgers.edu
thad@cup.portal.com (Thad P Floryan) (11/07/90)
marsella@athos.rutgers.edu (Stacy Marsella) in <Nov.5.15.51.57.1990.8498@athos.rutgers.edu> writes about problems with 3B1 Ethernet and Voice Power. I've literally only a few minutes on-line right now, so I'll "do" a brief answer followed by a longer one later this week. The Ethernet and Voice Power co-exist fine on my systems. HOWEVER: after several months of dorking-around (re: another expansion card), I've discovered there IS sensitivity to the ORDER in which the device drivers are loaded as well as apparent bugs with /etc/lddrv itself. The "clue" was in the UNIXPC Device Driver Writer's Guide re: two 128Kbyte sections (for a max of 0x40000) and the fact /etc/lddrv allowed me to load 0x47000 worth of device drivers (several of which crapped out by hanging the system upon an apparent interrupt until I removed xt (BLIT Terminal support) and some other stuff which I never used). Also, if/when you run diags on the Ethernet cards, be forewarned that multiple repeats of test 5 (I believe, the 16-block burst test or something like that) reveal a bug in the diags ... ALL Ethernet cards will fail this test even though they WILL operate correctly and normally in the system. The only test that seems reliable is to "ping" your system using a system that has "ping". And if you use the UA menus to unload and reload device drivers, the ORDER of loading (as shown in /etc/lddrv/drivers) WILL change, often to the detriment of your system's operation. This kinda screws the whole idea of dynamically loadable device drivers. :-( What REALLY puzzles me is the following (via "/etc/lddrv/lddrv -sv"): DEVNAME ID BLK CHAR LINE SIZE ADDR FLAGS wind 0 -1 7 -1 0x9000 0x53000 ALLOC BOUND lipc 1 -1 -1 -1 0x7000 0x360000 ALLOC BOUND cmb 2 -1 -1 -1 0x3000 0x5c000 ALLOC BOUND qt 3 -1 18 -1 0x2000 0x367000 ALLOC BOUND tp 4 -1 10 -1 0x3000 0x36b000 ALLOC BOUND starlan 5 -1 11 -1 0x14000 0x3de000 ALLOC BOUND voice 6 -1 13 -1 0xa000 0x33e000 ALLOC BOUND ether 7 -1 14 -1 0x13000 0x348000 ALLOC BOUND Perhaps "wind" is not counted in the 0x40000 total. Quien sabe? In any event, the above configuration works; almost any other order totally freezes the system (even the red "heartbeat" LED stops blinking). And, yes, this machine has an expansion chassis (which itself is the cause of a few anomalies on several systems (but not all)). Weird voodoo and juju here ... maybe we all gotta dance under the full moon and swing dead chickens over our heads! :-) Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
marsella@athos.rutgers.edu (Stacy Marsella) (11/08/90)
Just a quick note - Thad hit the nail on the head ... I followed Thad's example for the driver load order (i.e. I editted /etc/lddrv/drivers so the order was lipc, voice, and then ether) and the system now works. I can also personally appreciate the points Gil was making about the load these drivers place on the system - with the ether driver loaded, cursor motion in the voice editor window during records is considerably more "spasdic" than with the ether driver unloaded. Much Thanks - The utility I get out of my UnixPC is in large part due to the great help you guys provide the UnixPC community. Stacy Marsella marsella@aranis.rutgers.edu