NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/sun/misc/3784

Text File | 1992-08-19 | 3.4 KB | 70 lines

Newsgroups: comp.sys.sun.misc
Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!sdd.hp.com!usc!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!lynx!zia.aoc.nrao.edu!rmilner
From: [e-mail] (Ruth Milner)
Subject: Re: 4.1.2 miniroot and EXB 8200SX problem?
Message-ID: <[e-mail]>
Reply-To: [e-mail] (Ruth Milner)
Organization: National Radio Astronomy Observatory, Socorro NM
References: <[e-mail]> <[e-mail]>
Date: Wed, 19 Aug 92 18:43:34 GMT
Lines: 58

In article <[e-mail]> [e-mail] (Matthew Jacob) writes:
>>st0:    Generic Drive, Vendor=<EXABYTE>
>>    Unknown type- assuming 0.25 inch cartridge
>>    Fixed record length (1024 byte blocks) I/O
>
>Unfortunately, the inquiry data of:
>
>    'EXABYTE 8200SX'
>
>neither matches "EXABYTE EXB-8500" nor "EXABYTE EXB-8200", which is
>what the fallback table in 4.1.2 has for exabytes.
>
>If you can't make a new kernel, you're hosed. If you can, edit
>the table in /sys/scsi/targets/st_conf.c as appropriate.
>I'd also complain to your exabyte rep.
>
>I'd also file a bug at Sun (Hah! fixed in NT! :-;)

There should be no reason why the administrator of the system couldn't make
a new kernel. st_conf.c is part of the binary distribution, and the C compiler
is bundled. When you do change it, be aware that any Sun which builds with
that module won't recognize an 8500 if you install one, since it will match
the entry for the 8200. You might be able to get around it by juggling the
order of table entries and tape device types (in stdef.h) so the 8500 would
match first (assuming the table is searched sequentially), but I wouldn't
count on it.

When you do make the change, be sure to edit the preceding field as well,
which is the number of characters in the string you're matching against. If
you leave it too long, it will probably pad your string with blanks, or nulls,
and it still won't match.

Note that Sun *had* to change the string they match against in order to
determine whether the drive is an 8200 or an 8500, and therefore support
the 8500's special features (e.g. dual-density). What else could they have
matched against? I don't think there's any easy way the tape table could do
matching of "8500" or "8200" anywhere in the I.D. string. Doing so would
probably involve a substantial rewrite in the driver code.

The *real* culprit is the reseller who changed the PROM so that it no longer
produces the usual string. Do complain to them about this change (what does
"SX" really mean, anyway?). Do they *really* understand how Suns configure
devices, and are they really "up" on SunOS? If so, at the very least they
should include instructions on how to change st_conf.c and rebuild your kernel
(which should not be necessary for a device as commonly-supported as Exabyte).

It could simply be that up to this point it has always worked, and they
haven't tested it on SunOS 4.1.2 yet. They could have it return "EXABYTE
EXB-8200SX" if they really need to get their fancy-shmancy model number in
there, and then it would still work. It should be pretty easy for them to
change it so that it does, and send you a new PROM (or a firmware load tape
if their 8200 supports it).

I'd be willing to bet this breaks other systems' autoconfiguration as well,
not just Suns'.
--
Ruth Milner                          NRAO/VLA                  Socorro NM
Computing Division Head      [e-mail]