zeeff@b-tech.UUCP (Jon Zeeff) (02/20/88)
> > > [ ... description of Club '386 machine ] > > Note: this machine will not run '286 Unix (anyone know why?). > Two thoughts: is this the Everex 20MHz motherboard or the second 16MHz rev. > (I don't think they produce the first rev. any more). I'm not sure which rev it is. It's the 3000A and runs at 16 mhz. > I take it you have more faith in Bell's 386 compiler than uPorts? I haven't > tried out uPort's that much: did you have many troubles with it? Actually, getting Bell's system was just cheaper. As some point I believe that uport will offer a faster compiler and it may then be worth the extra cost. > > The fuser command doesn't seem to work. > > Ug. This is a real problem. I *need* it to prevent uucico from going wild > and continuing PC Pursuit transfers into the morning hours... I'll have to > write a program or script to directly read the lock files I guess. I did something similar - since the pid is stored in the lock file, you can just use "kill `cat $lckfile`". > > The lp driver seems unable to > > print very long strings without a newline now and then (although this > > might be caused by Merge). > > This is a stupid idea, but could the extra newlines be related to the line > width stuff in the lp driver? I don't have my manuals in front of me, but did > you set the line width to zero (or some special value) to disable newline > generation? > I was using /dev/lp directly. Is there an ioctl that will fix this? My manuals don't seem to have anything on this. > > HDB uucp insists on resetting the tty > > permissions and seems to use a bit more cpu time than it should. > > It's probably also a nightmarish security sieve, as is virtually every other > uucp I've used. I use a modified old HDB. I finally "solved" this by making additional nodes (same name, but a different directory). It works fine now. > Do they even include the drive # now? At one time (286 2.2) they didn't > include the drive number at all, and when I got a bad block, there was no > way to tell which drive faulted. I don't think the drive numbers are in the messages. There do seem to be a large number of non repeatable disk errors. Does anyone else get frequent disk errors? > I tried. I now have a WD1005 on order for delivery Monday. I also am in > the process of borrowing the WD1007 from PCs Ltd to try it out, and maybe I'd be very interested in any information on the WD1007, WD1007/WA2, and the performance of the WD1006 (ie. is it worth it). The OMTI-8620 sounds like the way to go if it would only work. ------------------------------------------------------------------ - Jon Zeeff uunet!umix!b-tech!zeeff Branch Technology zeeff%b-tech.uucp@umix.cc.umich.edu Ann Arbor, MI -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
james@bigtex.uu.net (James Van Artsdalen) (02/22/88)
In article <4280@b-tech.UUCP>, zeeff@b-tech.UUCP (Jon Zeeff) writes: > The OMTI-8620 sounds like the way to go if it would only work. A quick clarification: the OMTI 8620 definitely does not work with uPort's SysV/386, and almost certainly not with the 286 SV/AT. I was told by uPort something is being done about this, but don't know what their timetable is. I suspect problems with both uPort's driver and OMTI's card: uPort's driver appears to derive the hard disk characteristics incorrectly (it uses the CMOS drive type instead of the BIOS disk parameter table) and I'm not sure that the OMTI is entirely register-level compatible with the WD1003 and other standard AT controllers, due to its behavior under DOS. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
steve@nuchat.UUCP (Steve Nuchia) (02/25/88)
From article <4280@b-tech.UUCP>, by zeeff@b-tech.UUCP (Jon Zeeff): > I don't think the drive numbers are in the messages. There do seem to be a > large number of non repeatable disk errors. Does anyone else get frequent > disk errors? I've been getting them since day one, december 86. Running my machine at 6 MHz I was getting them on a single ST4096 so bad that I could only use half of it. At 10 MHz, single drive, they went away. Added a second drive and they came back. Sometimes the errors are really soft, some of the time the formatting of a sector gets screwed up and you get a bad spot there until you reformat the track. Needless to say, the microjerks assured me they had never heard of the problem before, I was the only person who was reporting it, it was probably real bad spots on the disk that weren't on the defect list, my controller (all three of them) was at fault. The best single piece of advice came from a very helpful and pleasant person at Western Digital who suggested that I might be overloading my power supply. Sadly, that was not the case, but it was a first class guess. I've got my ST4096 as drive 0 with root, swap, and "files" on it (in that order) and a ST251 as drive 1 with usr taking up the whole thing. My news spool is on /files and normal operations involve a lot of copying between /usr and /files. Interresting thing about it is that 99.9% of my errors land in the /files filesystem. I have to shut down at least once a week to fsck /files, often finding a lot of problems (trashed iblocks - my favorite!) but /usr and / seldom have anything serious wrong with them. I've started getting I/O errors on the swap partitiion lately, which is a real drag (panic!). The recentness of this development correlates with the installation of the ramdisk driver - I never swapped at all before that. My best guess is that this is a timing foobar triggered when switching from one drive to another and could probably be fixed quite easily - like adding one line to the driver somewhere. The problem I had before (single drive, 6MHz clock) correlated with very long seeks and is probably coincidental rather than related in any strong fasion. -- Steve Nuchia | [...] but the machine would probably be allowed no mercy. uunet!nuchat!steve | In other words then, if a machine is expected to be (713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947
zeeff@b-tech.UUCP (Jon Zeeff) (02/28/88)
Hmm, a 4096 and a ST251 are exactly the drives I'm using that causes so many disk errors with uport unix. It seems that the disk driver could at least recal the drive and try again before failing. The whole thing does make the system very unreliable. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
clewis@spectrix.UUCP (Chris R. Lewis) (03/01/88)
In article <689@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: |From article <4280@b-tech.UUCP>, by zeeff@b-tech.UUCP (Jon Zeeff): >... Talks about sporadic random and non-repeatable disk errors. Sounds a lot like you're missing terminators on your disk drives. Make absolutely certain that only one drive has the terminators installed, and it's the last in the chain. Check your drive manuals. ST506 style drives frequently go nuts in this manner if the terminators are missing or installed in both drives in a dual-drive system. -- Chris Lewis, Spectrix Microsystems Inc, UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis Phone: (416)-474-1955
mjy@sdti.UUCP (Michael J. Young) (03/02/88)
In article <474@spectrix.UUCP> clewis@spectrix.UUCP (Chris R. Lewis) writes: >Sounds a lot like you're missing terminators on your disk drives. > >Make absolutely certain that only one drive has the terminators installed, >and it's the last in the chain. Check your drive manuals. ST506 >style drives frequently go nuts in this manner if the terminators are >missing or installed in both drives in a dual-drive system. My terminators are installed correctly and I still have the problem. This is a known bug in the wn driver when used with dual drive systems, and uport is aware of it. I corresponded with Dwight Leu at length about it. Their strategy is to try porting the 386 driver back to the 286, since 386 systems don't seem to exhibit the problem. Unfortunately, at last check they were still having difficulty recreating the errors on their in-house systems. I suggest that anyone who has the dual-drive errors contact uport and offer yourselves as a beta-site for the new driver when/if it is available. I did, but I haven't heard anything back from them as yet. -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel: +1 617 443 5779
jmsully@uport.UUCP (John M. Sully) (03/11/88)
In article <211@sdti.UUCP> mjy@sdti.UUCP (0000-Michael J. Young) writes: >This >is a known bug in the wn driver when used with dual drive systems, and uport >is aware of it. I corresponded with Dwight Leu at length about it. Their >strategy is to try porting the 386 driver back to the 286, since 386 systems >don't seem to exhibit the problem. Unfortunately, at last check they were >still having difficulty recreating the errors on their in-house systems. I >suggest that anyone who has the dual-drive errors contact uport and offer >yourselves as a beta-site for the new driver when/if it is available. I >did, but I haven't heard anything back from them as yet. This is a very good suggestion. We have not as yet been able to reproduce the problems in house, but a local site has the problem and we have been testing a new version of the driver with him. It is not quite ready for beta test yet, but I will post notification on the BBS when a decent version is available (probably here on the net too). Please note that this problem is extremely hardware dependent. We have been loaned the controller and second drive which reproduce this problem at the local site and have installed them in testbed machines here but were unable to reproduce the problem.