Re: is buslogic 958 really better than 2940uw
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: carlos@fisica.ufpr.br
To: debian-user@lists.debian.org
Subject: Re: is buslogic 958 really better than 2940uw
In-Reply-To: <[🔎] 333243A6.52CF@numbat.cs.rmit.edu.au>
References: <[🔎] 333243A6.52CF@numbat.cs.rmit.edu.au>
FCC: ~/Courier/.record
Lawrence Chim (ychim@numbat.cs.rmit.edu.au) wrote on 21 March 1997 19:15:
>There are so many discussion about 958 vs 2940uw.
>I found that the main arugment 958 better than 2940uw
>is that buslogic supports linux and allows source
>distribution of the driver.
It's not exactly buslogic that supports linux. See
/usr/src/linux/drivers/scsi/README.BusLogic
Here's also a description that Leonard gave (he's now the SCSI
kernel maintainer):
Leonard N. Zubkoff (lnz@dandelion.com) wrote on 6 February 1997 14:49:
>Let me give you an example of the difference that true manufacturer
>support makes... A few months back I received a couple of reports of
>problems with the Seagate Hawk drives. Occasionally someone would
>see a timeout and reset under heavy load, and I was convinced that
>it wasn't a simple problem of cabling or termination, unlike a lot
>of such reports. I mentioned this to the folks at BusLogic, and they
>checked their DVT records to see if that particular drive had been
>tested. It had been tested through the usual test suites (including
>NT and Netware stress tests), and they'd seen no problems
>themselves, but they offered to loan me a drive if I wanted to try
>and make it misbehave. I borrowed the drive and it wasn't long
>before I was able to reproduce a problem under heavy load.
>
>I didn't have to stop by BusLogic to reproduce it for them that week
>since it could take 15 minutes or more for the problem to occur, so
>I borrowed an Ancot SCSI Bus Analyzer from them for the next weekend
>to capture a trace of the problem. I sent them the trace via email
>and they immediately acknowledged that it was a firmware bug, and
>asked me to reproduce it in their test environment so that the
>problem could be readily located (they debug firmware problems on
>the BT-948/958 using an ICE that provides source level debugging --
>it's really quite pleasant). I brought my test system in later that
>week and their firmware engineer worked on debugging the problem.
>Unlike most of the other problems I'd reported, this one was more
>elusive, so I eventually cloned my test system's disk onto one of
>their testbeds and gave the engineer instructions on how to
>reproduce the problem. A day or two later they had a fixed version
>of firmware for me, and I again borrowed the disk drive to run a
>couple of days of heavy tests myself. When the problem did not
>recur, I sent the new firmware to the two people who had reported
Reply to: