🚀 go-pugleaf

david@ods.com (David Engel) writes:

>Is anyone out there using a Buslogic 946c (or any other model) SCSI
>controller with a Micropolis 4110 disk drive under Linux?  If so,
>please get in touch with me.

>I've started seeing disk drive timeouts since upgrading to the newer,
>higher-performance, Buslogic driver.  These timeouts always occur when
>accessing the tape drive (a Sony SDT-5000), occasionally occur when
>accessing the CD-ROM (a Plextor 3028) and occur every once in a while
>only accessing the disk.

>The author of the Buslogic driver for Linux, Leonard Zubkoff, has been
>very cooperative in trying to diagnose the problem but suspects that
>it is due to a faulty tagged-queuing implementation in the disk
>firmware.  The problem goes away when the tagged-queuing option in the
>Buslogic driver is disabled.  I'd rather not do that all the time

I have a hunch that once Leonard's new driver gets used on a lot more
sites (eg. shipped with a distribution) then we will uncover a whole
flock of drives with poorly tested and buggy tagged queueing 
firmware support.  So much so, that TQ will need to be disabled by
default, and an ioctl() will be used to turn it on (akin to hdparm
for IDE disks). The IDE situation was/is similar, in that there
are lots of IDE drives with buggy "block mode" firmware, and so Mark
had to turn it off by default in the Linux driver.

Leonard is more optimistic and is hoping the drive manufacturers
have done their homework, and performed rigourous testing on the
TQ firmware, in addition to the "normal" firmware. I hope he is 
right and I am wrong in this case.

>since it has a significant impact on performance.  So far, Micropolis
>technical support has not shown any interest in pursuing the problem.
>I'm hoping they'll show more interest if I can find others who are
>seeing it also.

Heh, I am not surprised. Look how long it took Conner to own up to
the buggy firmware on the 1060S drive. And that was broken under
*normal* use (i.e. no TQ or anything fancy), with probably hundreds
of linux users reporting it.

Assuming the Micropolis is broken, and it isn't a driver issue, the 
best thing for users to do is form a list of drives with broken TQ 
firmware, so that others can avoid them. Of course, contacting the 
manufacturers is still the Right Thing To Do.

Good luck,
Paul.

Paul Gortmaker (gpg109@leonard.anu.edu.au) wrote:
> >since it has a significant impact on performance.  So far, Micropolis
> >technical support has not shown any interest in pursuing the problem.
> >I'm hoping they'll show more interest if I can find others who are
> >seeing it also.
> 
> Heh, I am not surprised. Look how long it took Conner to own up to
> the buggy firmware on the 1060S drive. And that was broken under
> *normal* use (i.e. no TQ or anything fancy), with probably hundreds
> of linux users reporting it.

<chuckle> I was one of the first, if not the very first, to report
that problem to Connor.  I got the same treatment from them then that
I am getting from Micropolis now.  Fortunately, I was able to return
the Connor drive for a full refund and wound up getting the Micropolis
drive.  When others started reporting the Connor problem in various
newsgroups, I directed them to the Connor tech support manager that I
"dealt" with.  Connor eventually fixed their firmware.  I don't have
the option of returning the Micropolis drive this time so I'm taking a
more active approach. :-)

David
-- 
David Engel                        Optical Data Systems, Inc.
david@ods.com                      1101 E. Arapaho Road
(214) 234-6400                     Richardson, TX  75081

Well, we had to go to a more conventional Adaptec for the Linux boxes
[BSD was just great with the Buslogic], but since all of the Micropolis
2 Gig drives failed with bearing faults, and Micropolis reacted with a 
3-4 week repair and return policy, we've replaced them....

So, we don't have the problem any more.
/mark

David Engel (david@ods.com) wrote:
: Paul Gortmaker (gpg109@leonard.anu.edu.au) wrote:
: > >since it has a significant impact on performance.  So far, Micropolis
: > >technical support has not shown any interest in pursuing the problem.
: > >I'm hoping they'll show more interest if I can find others who are
: > >seeing it also.
: > 
: > Heh, I am not surprised. Look how long it took Conner to own up to
: > the buggy firmware on the 1060S drive. And that was broken under
: > *normal* use (i.e. no TQ or anything fancy), with probably hundreds
: > of linux users reporting it.

: <chuckle> I was one of the first, if not the very first, to report
: that problem to Connor.  I got the same treatment from them then that
: I am getting from Micropolis now.  Fortunately, I was able to return
: the Connor drive for a full refund and wound up getting the Micropolis
: drive.  When others started reporting the Connor problem in various
: newsgroups, I directed them to the Connor tech support manager that I
: "dealt" with.  Connor eventually fixed their firmware.  I don't have
: the option of returning the Micropolis drive this time so I'm taking a
: more active approach. :-)

: David
: -- 
: David Engel                        Optical Data Systems, Inc.
: david@ods.com                      1101 E. Arapaho Road
: (214) 234-6400                     Richardson, TX  75081

In article <4b5f4s$hk0@istwok.ods.com> david@ods.com (David Engel) writes:
>Paul Gortmaker (gpg109@leonard.anu.edu.au) wrote:
>> >since it has a significant impact on performance.  So far, Micropolis
>> >technical support has not shown any interest in pursuing the problem.
>> >I'm hoping they'll show more interest if I can find others who are
>> >seeing it also.
>> 
>> Heh, I am not surprised. Look how long it took Conner to own up to
>> the buggy firmware on the 1060S drive. And that was broken under
>> *normal* use (i.e. no TQ or anything fancy), with probably hundreds
>> of linux users reporting it.
>
><chuckle> I was one of the first, if not the very first, to report
>that problem to Connor.  I got the same treatment from them then that
>I am getting from Micropolis now.  Fortunately, I was able to return
>the Connor drive for a full refund and wound up getting the Micropolis
>drive.  When others started reporting the Connor problem in various
>newsgroups, I directed them to the Connor tech support manager that I
>"dealt" with.  Connor eventually fixed their firmware.  I don't have
>the option of returning the Micropolis drive this time so I'm taking a
>more active approach. :-)

If you are 100% certain the tag queuing is AFU in the Micropolis
drives, you could write up in technical detail your evidence that
it sucks, and e-mail it to their principle voting member of X3T10,
who is Chris Nieves (Chris_Nieves@microp.com).  I'm sure he'll
ignore e-mail looking for routine tech support, but if TQ is broken
he should know about it.


-- 
Gary M. Watson                              
Electronic Engineer                         Internet: trimm@netcom.com
Sigma-Trimm Technologies, A Division of Robroy Industries
350 Pilot Road   
Las Vegas, NV 89119                         Phone: (800) 423-2024 x2115 
** Enclosures for SCSI, RAID, Fibre Channel, and SSA **

David Engel (david@ods.com) wrote:

// Is anyone out there using a Buslogic 946c (or any other model) SCSI
// controller with a Micropolis 4110 disk drive under Linux?  If so,
// please get in touch with me.

I just bought a BusLogic 956C and works fine with my Micropolis 4110...
although my drive is starting to have problems spinning up if I power
down.... but that's another story ...icky... 


// I've started seeing disk drive timeouts since upgrading to the newer,
// higher-performance, Buslogic driver.  These timeouts always occur when
// accessing the tape drive (a Sony SDT-5000), occasionally occur when
// accessing the CD-ROM (a Plextor 3028) and occur every once in a while
// only accessing the disk.

// The author of the Buslogic driver for Linux, Leonard Zubkoff, has been
// very cooperative in trying to diagnose the problem but suspects that
// it is due to a faulty tagged-queuing implementation in the disk
// firmware.  The problem goes away when the tagged-queuing option in the
// Buslogic driver is disabled.  I'd rather not do that all the time
// since it has a significant impact on performance.  So far, Micropolis
// technical support has not shown any interest in pursuing the problem.
// I'm hoping they'll show more interest if I can find others who are
// seeing it also.

// David
// -- 
// David Engel                        Optical Data Systems, Inc.
// david@ods.com                      1101 E. Arapaho Road
// (214) 234-6400                     Richardson, TX  75081

--


                                            http://www.interport.net/~alster/
                                    alster@mindvox.phantom.com\\interport.net

Mark Fraser (mfraser@vanbc.wimsey.com) wrote:

:>Well, we had to go to a more conventional Adaptec for the Linux boxes
:>[BSD was just great with the Buslogic], but since all of the Micropolis
:>2 Gig drives failed with bearing faults, and Micropolis reacted with a 
:>3-4 week repair and return policy, we've replaced them....

:>So, we don't have the problem any more.
:>/mark

We've had the problem quite bad - we have a half dozen or so Micropolis
LT 2.1G RAIDIONS stacks.  Drives have been going down  periodically
for the past month.

The line from Micropolis was that the wrong bearing grease was used
in the spindles resulting in thermal breakdown of the grease and your
drive grinding itself out of existence, with your client data data of 
course.  No drive failure would be complete without that.

I wished Micropolis had been proactive about this issue.  This tiptoeing
around the tulips treatment is bullshit.  For net admins, our assess
are hanging out in the wind because these jokers wouldn't even give us
the true story.  Even when they did tell the truth, they refused to send
out more than one replacement drive; their service rep refused to
believe more than one drive had failed simultaneously.  We had to get
someone higher up and let him hear over the phone the nice screeching 
wail his company's product was putting up before we had an incredulous 
response, "IS that one of OUR drives??!"

Micropolis really FUBAR'd on this one.


SC Lam - slam@alpha.wright.edu

:>David Engel (david@ods.com) wrote:
:>: Paul Gortmaker (gpg109@leonard.anu.edu.au) wrote:
:>: > > [Conner dissing deleted]

>>> On 18 Dec 1995 17:08:01 GMT, david@ods.com (David Engel) said:

David> Is anyone out there using a Buslogic 946c (or any other model)
David> SCSI controller with a Micropolis 4110 disk drive under Linux?
David> If so, please get in touch with me.

David> I've started seeing disk drive timeouts since upgrading to the
David> newer, higher-performance, Buslogic driver.  These timeouts
David> always occur when accessing the tape drive (a Sony SDT-5000),
David> occasionally occur when accessing the CD-ROM (a Plextor 3028) and
David> occur every once in a while only accessing the disk.

I've started seeing them too, as soon as I got (temporarily) a second
DAT drive. I have been thinking that this was due to the several
outstanding SCSI transactions when doing two backups concurrently (one
from an EIDE disk to the 1st DAT, the second from a SCSI disk to the 2nd
DAT). My SCSI drives are:

	QUANTUM Pro 1.2GB
	HP 35450A DAT
	HP 35470A DAT

David> The author of the Buslogic driver for Linux, Leonard Zubkoff, has
David> been very cooperative in trying to diagnose the problem but
David> suspects that it is due to a faulty tagged-queuing implementation
David> in the disk firmware.  The problem goes away when the
David> tagged-queuing option in the Buslogic driver is disabled.

I'd suspect that since there are few OSes that have drivers that do
tagged queueing, quite a few drives have less shaken out tagged queueing
support.