[2335] in linux-scsi channel archive
Scsiinfo-1.7 released (Was Re: scsi.c, aic7xxx: problems in 2.0.28)
daemon@ATHENA.MIT.EDU (Michael Weller)
Sun Aug 24 15:34:37 1997
Date: Sun, 24 Aug 1997 21:30:37 +0200 (MESZ)
From: Michael Weller <eowmob@exp-math.uni-essen.de>
To: linux-admin@vger.rutgers.edu, linux-scsi@vger.rutgers.edu
Cc: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>,
Ingo Molnar <mingo@pc7537.hil.siemens.at>
Ok, following myself up:
On Wed, 13 Aug 1997, "Michael Weller" wrote:
> On Tue, 12 Aug 1997, Ulrich Windl wrote:
> > On 8 Aug 97 at 12:23, Ingo Molnar wrote:
> >
> > >
> > > Hello Ulrich,
> > >
> > > On Fri, 8 Aug 1997, Ulrich Windl wrote:
> > >
> > > > I experienced some severe problems wen trying to read the defect list
> > > > of my SCSI harddisk wirh "scsiinfo -d". The harddisk is a Conner
> > > > 1080S with a rather large defect list supplied by the manufacturer.
> > > [...]
> [...]
>
> > I have also tried Linux 2.0.30 with some patches and the 4.009
> > version of the aic7xxx: The results are even worse; I got an OOPS 2
> > and a killed interrupt handler. Maybe my harddisk is special...
>
> Please do not overestimate this, I actually worked a bit on scsiinfo and
> tried to fix it. There are many formats in which the drive can return the
> defect info. If you ask for an unsupported data format, the drive should just
> return an error, IMHO.
> [...]
Ok, following myself up, let me just note that I actually wrote myself in
the README coming with scsiinfo, that there are problems with reading
defects as you describe. So, next time read the f* manual first, then
blame Adaptec.
\begin{offtopic} This doesn't mean I support their obviously
recently developed tactics on badly documenting their products, although
*I* found them very cooperative in this respect when it came to the problems
with the aha174x driver in the long distant past.
I don't know the American market well, but talking about this with German
people actually dealing with computers and checking the market situation
myself too, I found it is simply like that: A SCSI PC has an Adaptec card.
The Buslogic drivers etc. might be nice and support the hardware great. But
noone even heard about Buslogic here in Germany. Here in Germany you just buy
an Adaptec or go with EIDE. There is nothing you can do about it. (Ok, I saw
one or two very exotic sources of other cards.)
I feel that we move against a point like those I2O (sp?) issue. Out of a
sudden we might realize that M$ controls the market and we are only able to
buy hardware which is only supported by M$ (say: Adaptec, Matrox VGA cards (I
know it changed a bit recently)). Anyway... \end{offtopic}
But now to the announcement section:
I just uploaded scsiinfo-1.7 to sunsite and tsx-11 where you'll be able to
retrieve it soon. Things worth mentioning:
a) Following this thread I made scsiinfo support all formats of defect
lists. I also realized that scsiinfo tells about 8192K of data in the
command structs albeit the kernel restricts the buffers to 4096K.
Again, I still think a sensible SCSI device should report an overrun
or other error, not lock up, or lock the SCSI bus up, and this until
the next power cycle, even not responding to hard resets (the red
button) as I found in some cases.
Of course, a long primary defect list is truncated then. I myself
can live with that, most interesting is only if the grown list
contains any more defects than a few. It can be circumvented by
using sg, but people will like to use the /dev/sd* etc devices s.t.
you need to find the right sg device and toggle between sg and the
original device to which fits best, and all this only if the kernel
supports sg which should not be required for all systems. If you
feel like it, code that.
b) I wrote an scsi low level formatter featuring everything of SCSI-2.
I were not able to try most of the options on my devices though.
It has a tcl/tk interface too, of course.
It can install a single partition and even mkfs it in one go too
which is handy to format removable medias (Lo and Behold, I own a MO
disk, yes)
c) man8 pages for all tools.
Enjoy,
Michael.
(eowmob@exp-math.uni-essen.de or eowmob@pollux.exp-math.uni-essen.de
Please do not use my vm or de0hrz1a accounts anymore. In case of real
problems reaching me try mat42b@spi.power.uni-essen.de instead.)
