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
