 | |
Seagate ST32430N upgrade
SCSI peripheral devices Discussion of SCSI-based peripheral devices. (comp.periphs.scsi)
 |
| | Thread Tools | Search this Thread | Display Modes |
#11
 
| |||
| |||
|
Re: Seagate ST32430N upgrade -
04-11-2007
, 05:20 PM
|
Most wide drives have a jumper on then to force narrow, so buy a wide to narrow adapter to plug into the cable. |
on the controller negotiation to select wide/narrow.
Quote:
|
I've only done this once on my old 486 box, but it had to be retired finally, can't get 100 mbit network cards for eisa bus.  |
will auto-negotiate 10 or 100 and auto-bridge the speeds.
Quote:
|
I'm trying to restore a Gateway 2000 that is part of a GC/MS instrument, to functionality. The hard drive is a SCSI v2 2.1 GB Seagate ST32430N which does not appear to be spinning ... |
or was this a data-only drive?
--
-- mejeep deMeep ferret!
#12
| |||
| |||
|
|
msg <msg (AT) _cybertheque (DOT) org_> writes: The 3Com 3c597 is 100BaseT EISA; my problem is finding a development kit for it (or any other fast EISA NIC) since drivers for AT&T SVR4 are not to be found. Can anyone add to this list or point to drivers and DDKs? |
Quote:
|
FWIW: any era in which AT&T released a Unix OS was done when any device driver writers were expected to be source licenseees of the OS. |
There was the SVID (System V Interface Definition)
for later versions of System V Release 3, and then SVR4.
I am rather sure think were Device Driver interface books
for Unix before SVR4 because AT&T sold Unix
for their WeCo 32000 based VME card
and that certainly required device drivers for all the other interface cards.
And there was "the Lyons book".
Quote:
|
Sun actually did the most work in making the DDI/DDK API for device drivers for Solaris 2.x systems. But that work stayed in Solaris, it wasn't put back into AT&T's codebase past the initial work Sun did with them in building SVr4. |
I was part of AT&T's SVR4.0 development and yes, Sun Microsystems and AT&T
traded a LOT of Unix technology, but AT&T's network team did a lot of
device driver work and were a major part of the interface and documentation.
During a later assignment when I wrote a serial device driver
for SVR4.0 and Solaris, I worked adhering to the Device Driver Interface and
the Driver-Kernel Interface (DDI/DKI). That documented all I needed for the job.
--
-- mejeep deMeep ferret!
#13
| |||
| |||
|
|
Most wide drives have a jumper on then to force narrow, so buy a wide to narrow adapter to plug into the cable. |
then it is only needed if the HBA doesn't allow negotiating narrow-only for that drive.
It has no meaning when connected to a narrow HBA.
Quote:
|
I've only done this once on my old 486 box, but it had to be retired finally, can't get 100 mbit network cards for eisa bus. Robert On Wed, 07 Mar 2007 10:53:23 -0800, d.086 wrote: Hi, I'm trying to restore a Gateway 2000 that is part of a GC/MS instrument, to functionality. The hard drive is a SCSI v2 2.1 GB Seagate ST32430N which does not appear to be spinning because I can neither verify nor format it in the disk controller BIOS. Since it is part of an instrument, it is probably better to restore the Gateway 2000 to functionality, because there are a variety of interface connectors. The Seagate ST32430N is still respected and is available on the market, mostly refurbished. However, it might be better to find a more modern, larger drive that maintains the SCSI v2 interface. Can anyone recommend a good candidate to replace this drive? Thanks. Danny |
#14
| |||
| |||
|
|
In article <461d1757$0$36719$892e0abb (AT) auth (DOT) newsreader.octanews.com>, Doug McIntyre <merlyn (AT) geeks (DOT) org> wrote: msg <msg (AT) _cybertheque (DOT) org_> writes: The 3Com 3c597 is 100BaseT EISA; my problem is finding a development kit for it (or any other fast EISA NIC) since drivers for AT&T SVR4 are not to be found. Can anyone add to this list or point to drivers and DDKs? I wish I could, but my consulting to AT&T information systems ended around 1989. FWIW: any era in which AT&T released a Unix OS was done when any device driver writers were expected to be source licenseees of the OS. It helped immensely to have the source code but was not truly required. There was the SVID (System V Interface Definition) for later versions of System V Release 3, and then SVR4. I am rather sure think were Device Driver interface books for Unix before SVR4 because AT&T sold Unix for their WeCo 32000 based VME card and that certainly required device drivers for all the other interface cards. And there was "the Lyons book". |
Interface (DLPI). It was an evolution of the Logical Link Interface
(LLI) which was used in SVR3.
There were also NIC driver frameworks to make it easier for ethernet
vendors to write their own drivers without having to know the details
of the DDI/DKI/DLPI. Sun's was GLD which was introduced for Solaris x86
(and far too many years later, appeared on sparc too). I forget the
name of the SVR4 one (which was quite different). It was driven by
Novell and Intel, but never gained any serious tracktion and AFAIK
is now dead.
Quote:
|
Sun actually did the most work in making the DDI/DDK API for device drivers for Solaris 2.x systems. But that work stayed in Solaris, it wasn't put back into AT&T's codebase past the initial work Sun did with them in building SVr4. I'm unsure how to scan/read what you said. I was part of AT&T's SVR4.0 development and yes, Sun Microsystems and AT&T traded a LOT of Unix technology, but AT&T's network team did a lot of device driver work and were a major part of the interface and documentation. |
their stack from Lucent, same as they did with SVR3. Sun bought
their stack from Mentant(sp?), but used Sun's own STREAMS
implementation, because Sun's requirement to run in a multi-processor
pre-emptive kernel was not available in any other UNIX STREAMS
implementation at that time.
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
#15
| |||
| |||
|
|
Solaris and AT&T SVR4 used different TCP/IP stacks. AT&T bought their stack from Lucent, same as they did with SVR3. Sun bought their stack from Mentant(sp?), but used Sun's own STREAMS implementation, because Sun's requirement to run in a multi-processor pre-emptive kernel was not available in any other UNIX STREAMS implementation at that time. |
v1.x, v2.x; MP-RAS moved to the Legent/Lachman stack. I am still
running the Wollongong TCP/IP which means many tweaks for link
layer code. What releases used a Lucent (Bell Labs?) product?
Regards,
Michael
#16
| |||
| |||
|
|
Andrew Gabriel wrote: Solaris and AT&T SVR4 used different TCP/IP stacks. AT&T bought their stack from Lucent, same as they did with SVR3. Sun bought their stack from Mentant(sp?), but used Sun's own STREAMS implementation, because Sun's requirement to run in a multi-processor pre-emptive kernel was not available in any other UNIX STREAMS implementation at that time. AFAIK, SVR3 used the Wollongong stack (WIN3B, etc.) as does AT&T SVR4 v1.x, v2.x; MP-RAS moved to the Legent/Lachman stack. I am still running the Wollongong TCP/IP which means many tweaks for link layer code. What releases used a Lucent (Bell Labs?) product? |
http://groups.google.com/group/comp.... d3ead0f57735
Quote:
|
Note that AT&T's version of WIN/TCP is still 3.0. Wollongong sells 3.1 themselves as the current release, and they include drivers for a number of common ethernet cards (AT&T strips those out). On my 6386s, I'm running Wollongong's own 3.1 version on WD cards because I have to use interrupt 2 (=9), and WIN/TCP 3.0 doesn't handle that interrupt properly... |
Regards,
Michael
#17
| |||
| |||
|
|
Andrew Gabriel wrote: Solaris and AT&T SVR4 used different TCP/IP stacks. AT&T bought their stack from Lucent, same as they did with SVR3. Sun bought their stack from Mentant(sp?), but used Sun's own STREAMS implementation, because Sun's requirement to run in a multi-processor pre-emptive kernel was not available in any other UNIX STREAMS implementation at that time. AFAIK, SVR3 used the Wollongong stack (WIN3B, etc.) as does AT&T SVR4 v1.x, v2.x; MP-RAS moved to the Legent/Lachman stack. I am still running the Wollongong TCP/IP which means many tweaks for link layer code. What releases used a Lucent (Bell Labs?) product? |
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
#18
| |||
| |||
|
|
In article <1329i5tdt0d5b2e (AT) corp (DOT) supernews.com>, msg <msg (AT) _cybertheque (DOT) org_> writes: Andrew Gabriel wrote: Solaris and AT&T SVR4 used different TCP/IP stacks. AT&T bought their stack from Lucent, same as they did with SVR3. Sun bought their stack from Mentant(sp?), but used Sun's own STREAMS implementation, because Sun's requirement to run in a multi-processor pre-emptive kernel was not available in any other UNIX STREAMS implementation at that time. AFAIK, SVR3 used the Wollongong stack (WIN3B, etc.) as does AT&T SVR4 v1.x, v2.x; MP-RAS moved to the Legent/Lachman stack. I am still running the Wollongong TCP/IP which means many tweaks for link layer code. What releases used a Lucent (Bell Labs?) product? Sorry, I meant Lachman, not Lucent. |
scott
#19
| |||
| |||
|
|
In article <1329i5tdt0d5b2e (AT) corp (DOT) supernews.com>, msg <msg (AT) _cybertheque (DOT) org_> writes: Andrew Gabriel wrote: Solaris and AT&T SVR4 used different TCP/IP stacks. AT&T bought their stack from Lucent, same as they did with SVR3. Sun bought their stack from Mentant(sp?), but used Sun's own STREAMS implementation, because Sun's requirement to run in a multi-processor pre-emptive kernel was not available in any other UNIX STREAMS implementation at that time. AFAIK, SVR3 used the Wollongong stack (WIN3B, etc.) as does AT&T SVR4 v1.x, v2.x; MP-RAS moved to the Legent/Lachman stack. I am still running the Wollongong TCP/IP which means many tweaks for link layer code. What releases used a Lucent (Bell Labs?) product? Sorry, I meant Lachman, not Lucent. |
Solaris 2.0, I think, still used the original SVR4.2 stack (which I think
was Lachman, not Wollongong).
Solaris 2.1 and later used Mentat as does HP/UX.
But Solaris just did a one-time source buy and evolved from there
(not a whole lot is left from the original code I suspect, specifically
after the large and ongoing rewrites in S10 and Nevada)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
#20
| |||
| |||
|
|
andrew (AT) cucumber (DOT) demon.co.uk (Andrew Gabriel) writes: In article <1329i5tdt0d5b2e (AT) corp (DOT) supernews.com>, msg <msg (AT) _cybertheque (DOT) org_> writes: Andrew Gabriel wrote: Solaris and AT&T SVR4 used different TCP/IP stacks. AT&T bought their stack from Lucent, same as they did with SVR3. Sun bought their stack from Mentant(sp?), but used Sun's own STREAMS implementation, because Sun's requirement to run in a multi-processor pre-emptive kernel was not available in any other UNIX STREAMS implementation at that time. AFAIK, SVR3 used the Wollongong stack (WIN3B, etc.) as does AT&T SVR4 v1.x, v2.x; MP-RAS moved to the Legent/Lachman stack. I am still running the Wollongong TCP/IP which means many tweaks for link layer code. What releases used a Lucent (Bell Labs?) product? Sorry, I meant Lachman, not Lucent. Solaris 2.0, I think, still used the original SVR4.2 stack (which I think was Lachman, not Wollongong). Solaris 2.1 and later used Mentat as does HP/UX. But Solaris just did a one-time source buy and evolved from there (not a whole lot is left from the original code I suspect, specifically after the large and ongoing rewrites in S10 and Nevada) |
for working on the Solaris TCP/IP stack as it bore too little
resemblance to the original. In particular its interaction
with the STREAMS framework was very significantly different, as
Sun evolved the STREAMS framework to work well with very many
processors/threads (reduction in calls for exclusivity at module
perimeters) as systems advanced in size.
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.