Date: Mon, 15 May 89 15:05:26 EDT From: Wm E Davidsen Jr <386users@crdos1.crd.ge.com> To: 386users@TWG.COM Subject: 80386 mailing list, vol 4 #29 80386 User's mailing list vol 4 #29 May 4, 1989 In this issue: RE: Xporting Hard Disks Vol 4 #25 80386 DX step Re: Data Sheets (Books !?!) For 486 & 860 [ 2 msgs ] ESDI controller/drive for Compaq 386 FidoNET Newsletter, Volume 6, # 18 [ 386max article ] First Impressions: Bell Technologies Unix System V/3.2 JDR 386 Motherboard Micro 1 Bankrupt [ 2 msgs ] SV/386 Consensys serial I/O board [ 2 msgs ] Re: Why unix doesn't catch on Re: uucico hangs on the AT&T 6386 The addresses for the list are now: 386users@TWG.COM - for contributions to the list or ...!uunet!TWG.COM!386users 386users-request@TWG.COM - for administrivia or ...!uunet!TWG.COM!386users-request P L E A S E N O T E If you want to get on or off the list, or change your address, please mail to the 386users-request address, or the message will be delayed by having to hand forward it (for your convenience, not mine). ---------------------------------------------------------------------- From: "LT. LARRY RIDOLF" Subject: RE: Xporting Hard Disks Vol 4 #25 Date: 1 May 89 08:07:00 EDT E L E C T R O N I C M A I L (DDN Host Address: GW2.HANSCOM.AF.MIL) Date: 1-May-1989 08:07 From: Lt Larry A. Ridolfi Username: RIDOLFIL Dept: ESD/ICPI Tel No: 186-2296 TO: _MAILER! ( _DDN[386USERS@TWG.COM] ) Subject: RE: Xporting Hard Disks Vol 4 #25 I'm on a program which transports 30 & 100 MB Winchester drives routinely. We found the following in that time: 1. Commercial packers are rejects from the airlines 2. Original shipping containers are the best 3. Shock indicators are best used for pointing fingers at common carriers 4. BACKUP, BACKUP, BACKUP !!! 5. Vehicle mass is *NOT* a factor. CJs and Duce-and-a-halfs have the same corruption rate. Hope this was helpful ------------------------------ From: exos:<@sungod.crd.ge.com:@sungod:afg@cbnewsl.ATT.COM> AT&T Bell Laboratories Subject: 80386 DX step Date: 2 May 89 15:11:18 GMT Does anyone know *exactly* what the differences are between the 80386 DX step and the B1 step ? Andy Goldberg AT&T Bell Laboratories Parsippany, New Jersey afg%vilya@research.att.com ------------------------------ From: peter@langlab1.hf.intel.com Intel Development Tools Operation, Hillsboro OR Subject: Re: Data Sheets (Books !?!) For 486 & 860 Date: 2 May 89 19:44:22 GMT In article <769@harrier.ukc.ac.uk> mch@ukc.ac.uk (Martin Howe) writes: > Also the UK branch >of Intel get their literature from the US parent (so they told me) and may >have to wait, so if anyone knows the EXACT address in the US that I could >write to, I'd be very grateful. > >Regards, >-- >Martin Howe (This posting is private, and NOT on behalf of UKC) >From my Intel Literature Guide, write or call: Intel Literature Sales Phone Number: PO Box 58130 +1 408-765-1909 Santa Clara, CA 95052-8130 USA Hope this helps! ------------------------------ From: lfm@sns4.UUCP (Larry Meadows ) FPS Computing, Beaverton,OR Subject: Re: Data Sheets (Books !?!) For 486 & 860 Date: 2 May 89 17:26:49 GMT In article <769@harrier.ukc.ac.uk> mch@ukc.ac.uk (Martin Howe) writes: >Hi there, just a short request -- can anyone tell me the order number for the >data sheets specified in the subject line ? >if anyone knows the EXACT address in the US that I could >write to, I'd be very grateful. i486 data sheet: Order #240440 i860 data sheet: Order #240296 1860 assembler/linker manual: Order #240436 i860 simulater/dbg manual: Order #240437 i860 programmers manual: Order #240329 There's also an i860 hardware design guide but I can't find the order number. Intel's main address is: Intel Corporation 3065 Bowers Avenue Santa Clara, CA 95051 UK Address is: Intel Corporation (U.K.) Ltd. Pipers Way Swindon Wiltshire, England SN3 1RJ You could also try: Intel Corporation San Tomas 4 2700 San Tomas Expressway 2nd Floor Santa Clara, CA 95051 (408)986-8086 twx: 910-338-0255 fax: 408-727-2620 Good luck! -- Larry Meadows @ FPS ...!tektronix!fpssun!lfm ...!nosun!fpssun!lfm ------------------------------ From: markmc@sequent.UUCP (Mark McCarty) Sequent Computer Systems, Inc Subject: ESDI controller/drive for Compaq 386 Date: 28 Apr 89 17:43:32 GMT I would like some recommendations for a third party 120-200MB ESDI controller and drive to be used in a Compaq 386 16Mhz machine. Any recommendations, experiences, etc. would be appreciated. Please respond to me directly and I will post a summary if there is enough interest. TIA, markmc ------------------------------ From: pozar@hoptoad.uucp (Tim Pozar) Late Night Software (San Francisco) Subject: FidoNET Newsletter, Volume 6, # 18 Date: 3 May 89 21:40:43 GMT [ This article was so excelent I exerpted it ] Bill Bolton 3:711/403 386MAX Memory Manager A BBS Application Oriented Product Peek I was after a way to get more Transient Program Area on the 386 server on the Software Tools BBS LAN that supports 3:711/403 and 3:3/113. There are maintenance tasks that run on the server and some of them are quite memory hungry. I have been using a plethora of small utilities to shadow ROMs and squeeze the maximum grunt out of the 386 but felt that there had to be more that could be done. I'd seen the ads from Qualitas for a utility called "386MAX" that promised to do some wonderful things with 386 memory management, so I decided to buy a copy and have a look at it. 386MAX allows you to fill the empty memory spaces between the ROMs above 640K with memory that can be used for a variety of purposes. It automatically moves any BIOS or EGA ROMS into fast RAM in this area and then makes the rest available for whatever use you can put it too. This area between 640K (A0000 hex) and 1M (10000 hex) is termed "high memory" by 386MAX. I found I was able to load the Lantastic REDIR program into the high memory, along with OPUSCOMM, SHARE and FASTOPEN... increasing my TPA in low memory from 450K to 486K. It looks as though other TSRs could also be loaded up there. The 386MAX documentation has some advice about what you should and shouldn't attempt to load in high memory. 386MAX uses F0000 to 100000 for showing the BIOS ROMs etc and with my EGA, Perstor and Lantastic card installed at their default locations, the high memory area was split into three chunks of 16K, 48K and 64K. It turned out that this was less than optimum for loading some of the things I wanted to get into high memory. A quick look at the Lantastic documentation showed that I could readdress the Lantastic card memory space, so I moved it from the default of D8000 to E8000 (so it sits right under the shadowed ROM area) and this gave me a 112K contiguous area of high memory that allowed me to load all the things I wanted. The batch files that load to the network had to be modified to indicate to the LANBIOS where the LAN card was addressed but that was a few moments work with an editor. 386MAX also had to be told that the Lantastic card was using the space from E8000 to F0000 by using a "RAM=E800-F000" statement on its command line. I found that some programs seem to need quite a bit of free space in high memory to load, even though they don't actually use a lot of space once loaded. FASTOPEN, for instance, only occupies about 9K when loaded with a generous amount of buffer space, but would not load at all into high memory when the largest contiguous chunk was only 64K. When I increased that to 112K I had no problem loading FASTOPEN. 386MAX can give a number of useful displays of memory utilisation. Unfortunately most of them cannot be reproduced in Fidonews. I have modified several to get a reasonable approximation of the information displayed on the screen, though in each case information had to be deleted in order to meet Fidonews presentation requirements. Figure 1 is part of the overall system memory assignment display, the nice graphic part on the top had to be chopped.... Extended memory usage... ROM mapping region = 80 KB, C000-C400, F000-10000 Program storage = 88 KB EMS memory = 0 KB Remaining ext memory = 872 KB High DOS memory = 128 KB, C400-C800, CC00-E800 Low DOS memory = 0 KB Total extended memory = 1168 KB, shadow RAM recovered = 144KB Total expanded memory = 0 KB, in use = 0 KB, available = 0 KB ==> Loading programs in LOW memory... ==> 88 KB available in HIGH memory, largest block is 75 KB. The current state is ON. FIGURE 1. The Figure 2 shows how the memory area from 0K to 1M is utilised... 386MAX -- Version 4.04 -- A Memory Manager for 386 Systems (C) Copyright 1987-8 Qualitas, Inc. All rights reserved. +---------------------------------------------+ | MEMORY MAP for RESIDENT PROGRAMS | +--------------+------+------+------+---------+ | | Hex | Hex | Hex | Decimal | | Name | Start| End | Owner| Length | +--------------+------+------+------+---------+ | DOS & drvrs | 09B2 | 149B | | 44,672 | | | | | | | | | | | | | | COMMAND.COM | 149B | 156F | 149C | 3,376 | | | 156F | 1573 | -Avl-| 48 | | COMMAND.COM | 1573 | 16EB | 149C | 6,000 | | FASTOPEN.EXE | 16EB | 16F8 | CC01 | 192 | | | 16F8 | 1717 | -Cur-| 480 | | | 1717 | 1718 | -Avl-| 0 | | 386MAX.COM | 1718 | 1777 | 1719 | 1,504 | | SERVER.EXE | 1777 | 2614 | 1778 | 59,840 | | | 2614 | 2633 | -Avl-| 480 | | | 2633 | 2664 | 2634 | 768 | | | 2664 | A000 | -Cur-| 498,096 | +-High DOS Mem-+------+------+------+---------+ | Dev=QMMXXXX0 | C400 | C4D2 | C401 | 3,344 | | Dev=386MAX$$ | | | | | | | C4D2 | C7FF | -Avl-| 12,992 | +- RAM or ROM -+ C7FF | CC00 | 0AA6 | 16,384 | | FASTOPEN.EXE | CC00 | CE39 | CC01 | 9,088 | | SHARE.EXE | CE39 | CF72 | CE3A | 4,992 | | REDIR.EXE | CF72 | D233 | CF73 | 11,264 | | OPUSCOMM.COM | D233 | D544 | D234 | 12,544 | | | D544 | E800 | -Avl-| 76,720 | +--------------+------+------+------+---------+ FIGURE 2. Figure 3 shows another handy function which indicates the relative speeds of the various memory components in your system..... 386MAX -- Version 4.04 -- A Memory Manager for 386 Systems (C) Copyright 1987-8 Qualitas, Inc. All rights reserved. +-------------------------------------------------------------+ | Timing memory accesses, please wait a moment... | +-------------------------------------------------------------+ | MEMORY ACCESS TIMES | +----------+-------------+--------+---------+-----------------+ | Starting | Range | | Average | Ratio to Fastest| | Address | Start End | Length | Time s | (1.0 = fastest) | +----------+------+------+--------+---------+-----------------+ | 00000000 | 0 | 640 | 640 | 494 | 1.0 * | | 000A0000 | 640 | 736 | 96 | 5039 | 10.2 **********>| | 000B8000 | 736 | 768 | 32 | 8413 | 17.0 **********>| | 000C0000 | 768 | 800 | 32 | 494 | 1.0 * | | 000C8000 | 800 | 816 | 16 | 5039 | 10.2 **********>| | 000CC000 | 816 | 928 | 112 | 494 | 1.0 * | | 000E8000 | 928 | 960 | 32 | 5039 | 10.2 **********>| | 000F0000 | 960 | 1896 | 936 | 494 | 1.0 * | | 001DA000 | 1896 | 2104 | 208 | | Absent | | 0020E000 | 2104 | 2192 | 88 | 494 | 1.0 * | +----------+------+------+--------+---------+-----------------+ FIGURE 3. 386MAX can do a lot of other tricks with extended memory in a 386 PC, including making it look like EMS memory. I don't have a need for most of it's other facilities for my BBS LAN applications so I haven't investigated them thoroughly, though they all seem to work well in a brief test. The "high memory" capability alone has made 386MAX a very useful tool for me and it is certainly worth a look for anyone using a 386 PC. ------------------------------ From: karl@sugar.hackercorp.com (Karl Lehenbauer) Sugar Land Unix - Houston Subject: First Impressions: Bell Technologies Unix System V/3.2 Date: 28 Apr 89 04:21:02 GMT Greetings. I have received and installed Bell Tech System V/3.2 and fooled with it a bit. Here are some comments and first impressions. First, this is marketed as an unmunged version of the AT&T/Intel 386 release. Microport and Interactive have made proprietary modifications to their releases. Some seemed to cause gratuitous incompatibilities, such as Microport's changes within their driver calling stuff, while others look interesting, such as Interactive's claimed 3X filesystem performance improvement thanks to their proprietary filesystem enhancements. (The decision to go for the enhanced filesystem is a difficult one. One the one hand, you want the higher performance, but on the other hand, reliability is critical. By definition, the Interactive code is less mature. Those of us who've lived with the disappearing inode problem are not superhappy about what we're getting from AT&T. (I haven't verified its presence yet under 3.2)) As the Bell Tech port is supposed to be generic, my comments should also apply to other generic versions of Unix. Oh yeah, being generic could be really important if the generic becomes a successful de facto standard and other version are incompatible with add-ons...these would mostly be boards and their drivers. I was upset that the price for upgrading (I was a 3.0 user) was so high, over a thousand dollars. However, they lowered the price to three hundred something. For licensees of an earlier Bell Tech release, this is compelling. Bell Tech bundles a bunch of stuff that are now officially unbundled, as I understood it from the intro docs. It seems that AT&T gone a bit crazy (in my opinion), even unbundling 'grep,' 'vi' and that lot into their own text processing bundle -- more on that later. Oh yeah, the docs promise a tested, commercial-grade operating system. Unix and the software development package came in two boxes. Finally, you get a complete set of manuals (as far as I can tell.) This is important because the system costs pretty much, like $1200 complete with development package and unlimited number of users. One thing, the manuals aren't in binder, they're in a kind of trade paperback format. This'll mean all new manuals again for 4.0. (I'm not really looking forward to 4.0, I must say. It's going to be really expensive and probably pretty bloated by the time they get all the BSD stuff in.) Anyway, installation was straightforward, and I think this was the first time I ever installed a version of Unix (Microport 1.3.7, 1.3.8, a couple 2.x versions, Bell Tech 3.0 & 3.1) and didn't have some problem somewhere in the installation procedure that required a bunch of dinking around, like hand-executing divvies, mkparts and all that rot. On the down side, it didn't show any of the output from the divvy, mkpart, mkfs and all that stuff. That may be a good thing, because that stuff may seem like frightening gibberish to The Uninitiated, so it probably should just shut up and work properly if Unix is going to get wide acceptance on PCs. I don't know yet if there's enough of a system there to cancel out of the install procedure, mount the hard disk, and do fscks, edit /etc/passwd, and such, and there might not be. That would make me feel insecure, I'll try it soon. It can be remedied by any hack, though, just mount a copy of the floppy and diddle /etc/rc* as what's in /bin as appropriate. Heck, the boot code's probably in a file somewhere, anyway. Anyway, there was this one, pretty unbelievable, anomaly in the installation procedure. You boot off the boot floppy, now known as install disk one of eight. Anyway, you enter stuff it asks for about the hard disk and it sets that up. Finally, it tells you to take the floppy out and then reboot the system. When you do this, it automatically starts into the "load floppy 2" sequence for the next several disks. On the last disk, it gronks for a good while, then says something along the line of "an error occurred while doing the install -- someone tried to use the 'grep' program and it hasn't been installed -- you've got to install the text disk first." (I bet it was a shell script named grep.) Then it says not to worry about it, something like that. I think that's pretty dumb, and I don't see how the install can be done, ever, and not cause that message to come out. Validated and commercial grade? Perhaps...but this lapse is pretty glaring. The software development stuff installs fine. Something important, this version supports multiple virtual consoles, something I gave up by going to BT SysV/386 3.0, but hey, they were the price leaders. 3.2 (and 3.0 as well) can run binaries compiled for 286 Unix, which would mostly be Microport, and I have verified that works. New to this version is the ability to run Xenix binaries as well, and I have successfully run a few Xenix 286 binaries as a test. The docs say a couple of system calls aren't supported, but use of these is apparently rare. The down side of all that is that there's a Microsoft copyright that comes up at the start right after AT&T's. I presume they get a royalty for every system sold. Although I understand the desirability of bringing the Xenix people into the fold, it's a drag for all the people who don't need it. (I'm irked at Microsoft, anyway, for doing OS/2 instead of just fixing whatever they perceived to be wrong with Unix, and for a lot of negative, untrue stuff they've said about Unix.) I assume Sys V/4.0 will have additional copyrights, those of Berkeley and Sun Microsystems -- sigh. Perhaps there will someday be a public domain, POSIX-compliant, version of Unix, without all those GNU redistribution restrictions, that we can all go to, but of course that would just be Yet Another Version of Unix...but I digress. No manuals on line, rats. There is a help facility, though. It's OK, but lacking in detail on a lot of stuff, and it doesn't know anything about a lot of commands. The 'sysadm' menu-driven administration commands are still there and they seem to work OK. Adding users and such is easy. Installing packages that cause the kernel to be rebuilt, the couple I have, worked flawlessly, so swiftly and silently that the novice user needn't even know that they just regenerated the kernel. You do get a kernel debugger, which looks like fun for driver hacks; it's separately installable from its own floppy. Anyway, that's it. I haven't done a whole lot with it since installing it. The manuals look pretty good. There're about eleven of them. It looks like it's *possible* that someone who didn't know Unix and wasn't inclined to be a guru could read them and install and manage (backup, add users, etc) a system. That's certainly what they're (AT&T et al) shooting for. Nonetheless, it is a lot tougher than the DOS install and occasional chkdsk. Of course you get a lot more, not the least of which is extended memory operation under and compilation for 386 native mode, and multiuser/multitasking. (Whether you care about multiuser or not, once you have multitasking, multiuser is easy to add.) I'll post again after I've used it for a while. I met Dmitri Rotow once...the obligatory disclaimer. -- -- uunet!sugar!karl | "Nobody hipped me to that, dude." -- Pee Wee -- Usenet BBS (713) 438-5018 ------------------------------ From: greg@dekalb.UUCP (Greg Philmon) DeKalb College, Clarkston, Ga. Subject: JDR 386 Motherboard Date: 27 Apr 89 03:15:27 GMT Has anyone had any experiances with the 386 motherboard (MCT386MB20 or 25) that JDR Microdevices is selling for $850 ($1050 for 25mhz)? I'd appreciate any info. Thanks in advance! -- --------------------------------------------------------- | Greg Philmon ...gatech!dekalb!greg CIS: 72261,1724 | --------------------------------------------------------- ------------------------------ From: galvin-peter@CS.Yale.EDU (Peter Galvin) Yale University Computer Science Dept, New Haven CT 06520-2158 Subject: Micro 1 Bankrupt Date: 1 May 89 18:55:59 GMT The saga continues...you might recall that I ordered a replacement 386 motherboard from Micro 1 in February, and since it hadn't been sent in March I cancelled my order and asked for them to credit my charge card. Being untrusting I also had the credit card company stop payment on that charge under Mail Order Laws (I hope they did that, but I'm still fighting with them about it for reasons I won't go into). Anyway My April charge card bill arrived and still no sign of the charge credit. I called Micro 1 today and asked for the scoop, and they informed be that they are now under Chapter 11 bankrupcy protection and that I'd be receiving a letter. They did say that they are under new management and expect to make good on all orders and money owed, but didn't say when...not to say that I believe them. But when I called sales they still seemed to be taking orders. So, I'd recommend NOT ORDERING from MICRO 1 until they've come out of bankrupcy. I'm surprised that they can still take orders while under court protection (if in fact they were...that's just my feeling), but I know I wouldn't order from them. Just a friendly caution. No affiliation et al. --Peter ------------------------------------------ -------------------------------- Peter Baer Galvin (203)432-1254 Senior Systems Programmer, Yale Univ. C.S. galvin-peter@cs.yale.edu 51 Prospect St, P.O.Box 2158, Yale Station ucbvax!decvax!yale!galvin-peter New Haven, Ct 06457 galvin-peter@yalecs.bitnet ------------------------------ From: dr@skivs.UUCP (David Robins) Smith-Kettlewell Eye Research Institute, San Francisco, CA Subject: Re: Micro 1 Bankrupt Date: 2 May 89 19:07:21 GMT I had a bad experience with Micro 1 last year, and I wouldn't order from them again, either. In April, '88, I ordered a 386 system, a Mylex tower. In June, I was informed the board and sheetmetal case were on backorder, but due in any moment. In checking with Mylex, I found the parts actually were in the Mylex warehouse, but Micro 1 had neglected to pick them up! After many phone calls to Micro 1, I finally got the system in September, a wait of 5 months. I checked with other stores in the area, and could have had my system in less than 3 days, just the need for burn-in time. (I couldn't cancel the order due to fiscal year restrictions.) -- David Robins, M.D. (ophthalmologist / electronics engineer) The Smith-Kettlewell Institute of Visual Science, *** net: uunet!skivs!dr 2232 Webster St, San Francisco CA 94115 *** 415/561-1705 (voice) The opinions expressed herein do not reflect the opinion of the Institute! ------------------------------ From: wayne@cbnewsh.ATT.COM (wayne.patrick.brodbeck) AT&T Bell Laboratories Subject: SV/386 Consensys serial I/O board Date: 2 May 89 14:53:22 GMT Does anyone have experience with the Consensys (power ports) 8 port I/O board. Particularly running on an AT&T 6386 with UNIX V 3.2. Wayne Brodbeck AT&T Bell Labs Holmdel NJ email : aquaman!wayne (email replies preferred) 201-949-8479 ------------------------------ From: wayne@cbnewsh.ATT.COM (wayne.patrick.brodbeck) AT&T Bell Laboratories Subject: SV/386 Consensys serial I/O board Date: 2 May 89 14:53:22 GMT Does anyone have experience with the Consensys (power ports) 8 port I/O board. Particularly running on an AT&T 6386 with UNIX V 3.2. Wayne Brodbeck AT&T Bell Labs Holmdel NJ email : aquaman!wayne (email replies preferred) 201-949-8479 ------------------------------ From: john@jwt.UUCP (John Temples) John W. Temples, III -- Orlando, FL Subject: Re: Why unix doesn't catch on Date: 30 Apr 89 02:52:38 GMT In article <274@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: >This is *Microsoft*, >people: You know--the company which markets perhaps the best optimized >C compiler in the world. And they aren't writing OS/2 in C [...] You suppose >they're just stupid? I doubt they're stupid. But just because they're successful at marketing their products doesn't mean their products are implemented the "best" way. I saw comments in the MKS Newsletter stating that they felt certain features in OS/2 were not implemented the "best" way -- because UNIX had already done it that way, and Microsoft didn't want OS/2 to be like UNIX. Yes, this is *Microsoft*, the company that finally came out with a multitasking OS...on a CPU that has been obsolete for years. Yes, this is *Microsoft*, the company that can't do DOS multitasking yet, even though UNIX has been doing DOS multitasking on the 386 for years. And as for the "best optimized C compiler" (I assume you meant "best optimizing"), yes, it has a good optimizer -- when it generates good code. I've put tens of thousands of lines of code through MSC 5.0/5.1. After initial experiences with 5.0, I wouldn't use it. 5.1 fixed many optimizer bugs, but you still have to be careful with the optimizer. Yes, Microsoft is a big, successful company. But I don't see any Microsoft products that I think are incredibly innovative or unusual. The old "ten million fans can't be wrong" argument doesn't wash with me. >And the efficiency of UNIX on the 386 is >almost certainly going to look rather sickly when compared to a mature >version of 386 OS/2. I've never used OS/2, but I've seen many comments indicating that it's quite slow -- slower than UNIX, even. I would imagine that it will improve in the future, but to the point where it will make UNIX look "sickly"? I doubt it. And it's just as likely that UNIX's performance on the 386 will continue to improve as well. >Does anyone remember the UCSD "P-Code" operating system which at one point >was being touted as superior to MS-DOS because it allowed developers to sell I really don't think comparing P-code, which is interpreted, to compiled C is valid at all. No, C will probably never be as fast as assembly. But improvements in compiler and optimization technology will continue to close the gap. -- John Temples - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!jwt!john ------------------------------ From: root@nebulus.UUCP (Dennis S. Breckenridge) Alchemy Mindworks,Toronto,Ontario Subject: Re: uucico hangs on the AT&T 6386 Date: 27 Apr 89 03:42:40 GMT In article <138@mslanpar>, pat@mslanpar (Pat R. Calhoun) writes: > In article <1055@koko.CSUStan.EDU>, robert@CSUStan.EDU (Robert Zeff) writes: > > I have an AT&T 6386 which hangs in uucico when the call is aborted. > > The uucico process cannot be killed, even from root. I also have had cu > > hang this way. AT&T has not offered any useful advice. Seems to me that > > root should be able to kill any process. We're using a Telebit Plus. > > Anyone else having this problem or have a solution? > > (Ant tips on how to handshake with the Telebit would be appreciated, also) > > If you happen to have the driver source, you will more than likely find > that the priority to sleep is less than PZERO. This means that a signal > will not kill (or wakeup) the process. This is the reason why the process > is unkillable. By exec'ing a ps(1) - 'laef', you will find the process' > priority will be <26, this means if that process is hung, you can kill > it by executing an init 0 (probably not what you want:-). > > I need more information regarding your problem. First, are you using the > standard serial port?? or are you adding a multi-port board (such as > CTC's GEMINI-10)?? I also need to know what BIOS PROM version is in ^^^^^^^^^^^^^^^^^ Is this the IPC-802 sold by AT&T I don't think so. > your system(the 386 obviously:-). Right now I'm making the assumption > that you are using ATT SYS V, and not XENIX, so you might want to > specify you OS!! > Pat writes about driver source. The rest of us do not have access to the source of the drivers but I do know that AT&T does support the "final" release of a binary for the ports card. The release is 2.1 and it fixed a whole bunch of bugs with the IPC-802. Getting a telebit to talk to ANY port (IPC or integral) on the 6386 requires some non-standard cabling. What I had to do was take pin-6 from the TB+ and move it to pin 8 on the port and then I programmed the TB+ to drop that signal on a disconnect. I tried various settings on the TB+ to get carrier to present itself on dial and drop on disconnect but I did not have much success. Making the change in hardware eliminated most of the problems I had. I have included my settups for the Telebit modem here. Try it and let me know if it works for you (after you move DSR to DCD) ERROR at&n E1 F1 M1 Q6 T V1 X1 Version BA4.00 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006 S10=007 S11=070 S12=050 S45=000 S47=004 S48=000 S49=000 S50=000 S51=005 S52=002 S53=004 S54=003 S55=000 S56=017 S57=019 S58=002 S59=000 S60=000 S61=045 S62=003 S63=001 S64=000 S65=000 S66=001 S67=000 S68=255 S90=000 S91=000 S92=000 S95=002 S100=000 S101=000 S102=000 S104=000 S110=001 S111=030 S112=001 S121=000 This has been tested on the integral serial port and the IPC-802 without hangups. What Pat failed to say was the driver was sleeping at a PZERO < 25 because the driver was hung trying to close the port without the hardware signaling to allow the close to complete. (TCSETAW hangs if DCD is not lit) This causes both cu(1) and uucico(1) to hang on a close. -- ============================================================================== "A mind is a terrible thing to MAIL: Dennis S. Breckenridge waste!" 206 Poyntz Ave North York, Ontario M2N1J6 (416) 733-1696 UUCP: uunet!attcan!nebulus!dennis ICBM: 79 28 05 W / 43 45 01 N 50 megatons should do! ============================================================================== ------------------------------ End of 80386 M/L vol 4 #29 **************************