steve@cdp.UUCP (07/28/88)
Can anyone sumarize the issues surrounding running two ESDI
drives on Microport V/386 2.2 ? Microport technical support
told me that "some" Western Digital (WD1007) controllers
support 2 drives, and some won't. This is not to say that some
revisions of the board work and others don't. Rather, they
meant was that any individual card may or may not work ! This
concerns me, and makes me wonder if it is wise to try to run 2
ESDI drives at all.
Another interesting note. In a fit of frustration, I tried to
link the 386/ix hd.o driver into the uPort kernel. The link
failed, with undefined (global) symbols 'dpt1' and 'dpt2'. I
find it outrageous that Microport decided to break the SVR3
driver interface. After all, isn't the success of UNIX based
on the standard interfaces it provides ?
As another experiment, I tried to link Microport's Everex tape
driver (ev.o), into a 386/ix kernel. But this also failed --
and you can guess who's software introduced undefined symbols !
ev.o references 'dmainitted' and 'initdma'. Incredible.
Steve Fram
Community Data Processing (CdP)
{ihnp4, hplabs, uunet, ...}!cdp!stevedyer@spdcc.COM (Steve Dyer) (07/29/88)
In article <138500039@cdp> steve@cdp.UUCP writes: >Another interesting note. In a fit of frustration, I tried to >link the 386/ix hd.o driver into the uPort kernel. The link >failed, with undefined (global) symbols 'dpt1' and 'dpt2'. I >find it outrageous that Microport decided to break the SVR3 >driver interface. After all, isn't the success of UNIX based >on the standard interfaces it provides ? > >As another experiment, I tried to link Microport's Everex tape >driver (ev.o), into a 386/ix kernel. But this also failed -- >and you can guess who's software introduced undefined symbols ! >ev.o references 'dmainitted' and 'initdma'. Incredible. > Ha hah haahahahahahhaha.... "Standard interfaces" are at the system call and library level, not at the device driver binary level. That, for better or worse, is far far far from being standardized. It's a nice direction to aim for the future, now that we are moving towards standard kernels (it *would* be nice to buy a tape/disk/worm/serial driver from a 3rd party and not have to worry about this, but that's just not how business is done yet.) You may dislike Microport, but this is standard practice: device drivers are tightly integrated with a particular revision of a kernel; it's no reason to single them out for bitching. -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer
james@bigtex.uucp (James Van Artsdalen) (07/31/88)
IN article <138500039@cdp>, steve@cdp.UUCP wrote: > Can anyone sumarize the issues surrounding running two ESDI > drives on Microport V/386 2.2 ? Microport technical support > told me that "some" Western Digital (WD1007) controllers > support 2 drives, and some won't. I run two CDC Wren III-182 drives with a WD1007/WA2. I haven't had any trouble, and the infamous two-drive bug in uPort hasn't shown (this is 386 unix, so it may not exist). I'll point out that the system "uport" is running with a WD1007/Wren III/Compaq combination last I heard. I'll point out that I'm running a fairly unusual combination too. One of the Wren-IIIs is the normal CDC 150meg drive, but the other is the Compaq-damaged variety that only has 130meg. The uPort driver seems capable of living with this (the 150meg drive is 9 heads, 34 sec/trk, but the 130meg drive is 16 heads, 17 sec/trk). -- James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
jmsully@uport.UUCP (John M. Sully) (08/02/88)
In article <138500039@cdp> steve@cdp.UUCP writes: |Can anyone sumarize the issues surrounding running two ESDI |drives on Microport V/386 2.2 ? The problem you are wondering about is the infamous "2-drive" problem. To summarize: it appears that some samples of a given controller will cause problems when switching between drives with the current version of the hard disk driver. This problem has been, to the best of our knowledge, resolved in the driver being incorporated into the next release of both the 286 and 386 product. |Another interesting note. In a fit of frustration, I tried to |link the 386/ix hd.o driver into the uPort kernel. The link |failed, with undefined (global) symbols 'dpt1' and 'dpt2'. I |find it outrageous that Microport decided to break the SVR3 |driver interface. After all, isn't the success of UNIX based |on the standard interfaces it provides ? My guess is that these are global symbols in the Interactive driver which are referenced by some other driver in Interactive's distribution. The core (not the device drivers) of both our kernels is based on the same code from AT&T. Microport did *not* decide to break the kernel interface and neither did Interactive. |As another experiment, I tried to link Microport's Everex tape |driver (ev.o), into a 386/ix kernel. But this also failed -- |and you can guess who's software introduced undefined symbols ! |ev.o references 'dmainitted' and 'initdma'. Incredible. As in the above case, these symbols are located in our floppy driver and are used to indicate whether or not the DMA controller has been initialized. John M. Sully
steve@cdp.UUCP (08/05/88)
John, > |Another interesting note. In a fit of frustration, I tried to > |link the 386/ix hd.o driver into the uPort kernel. The link > |failed, with undefined (global) symbols 'dpt1' and 'dpt2'. I > |find it outrageous that Microport decided to break the SVR3 > |driver interface. After all, isn't the success of UNIX based > |on the standard interfaces it provides ? > > My guess is that these are global symbols in the Interactive driver which > are referenced by some other driver in Interactive's distribution. The > core (not the device drivers) of both our kernels is based on the same > code from AT&T. Microport did *not* decide to break the kernel interface > and neither did Interactive. > The error message from ld indicated that the undefined symbols 'dpt1' and 'dpt2' were referenced from uPort's kernel (os.o). Thanks for spending the time to address these concerns. Steve Fram