Date: Tue, 27 Aug 1996 22:35:11 +0200 (MET DST) From: Stefan Esser <se@zpr.uni-koeln.de> To: James Risner <risner@heathers.stdio.com> Cc: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: SCSI ncr.c assertion fail due to S_QUEUE_FULL error. Message-ID: <199608272035.WAA04283@x14.mi.uni-koeln.de> In-Reply-To: <199608271359.JAA02300@heathers.stdio.com> References: <199608271359.JAA02300@heathers.stdio.com>
next in thread | previous in thread | raw e-mail | index | archive | help
James Risner writes: > > I have a 3.5 GIG drive: > ncrcontrol -u 1 > T:L Vendor Device Rev Speed Max Wide Tags > 1:0 DEC RZ74 (C) DEC 427H 10.0 10.0 8 4 > > on heavy disk seeking I get: > sd1(ncr1:1:0): COMMAND FAILED (4 28) @f09fb000. > assertion "cp" failed: file "../../pci/ncr.c", line 5563 > > I looked up the COMMAND.FAILED code and found that 4 28 means: > COND_MET or HS_COMPLETE and QUEUE_FULL Yes, true. Sorry, I'm too busy and didn't immediatlely remmeber those codes, but that kind of problem has also been noticed by an user of the SEQUEL 5200 (?) drive, which is a DEC 5.25" designed drive with 2GB or 3GB capacity. I'll have to scan my mail archive for details ... > I looked up the code about QUEUE_FULL which it does not run and it sets > tags to 0 to fix. Hmmm, that code was there as a precaution in case a device supported only a very small number of tags. But I never had access to a device that actually triggered this code, and it really never has been tested for that reason. > I set tags to 1 with > ncrcontrol -u 1 -t 1 -w -stags=1 (You don't need the -w in this case. If there is only one NCR card in the system, then you may also ommit the -u 1 option.) Just use 0 as the number of tags. This may slightly reduce the overhead (I'm not sure whether there is a test for more than ONE or more than ZERO tags. ONE tag obviously doesn't make much sense :) > The problem went away. > Now it is: > ncrcontrol -u 1 > T:L Vendor Device Rev Speed Max Wide Tags > 1:0 DEC RZ74 (C) DEC 427H 10.0 10.0 8 1 > > Who's problem was present? Since tags work with just about every current drive (the HP 3724 and 3725 being the (un)famous exception), I guess it is the drive's fault. I'm using my Quantum Atlas with tags for more than a year now, and though I rebuild the world (FreeBSD-current) nearly each night as kind of a regression test, it never failed. It does work with 4 tags (the default) as reliable as with 16. > SCSI system for not probing the drive and setting the tags lower somehow? No, the drive announces support of tags in its INQUIRY response. Most drives seem to support at least a few tens of tags, I never hit the limit in my tests :) > ncr.c for not properly reseting after a QUEUE_FULL from a disk? Well, as I said, this code should not actually be necessary, and it has not been tested. The new generic SCSI code that is currently developed by Justin Gibbs will move most of the complexity of tag support into the controller independent layer, and I'm sure his code will be better tested and will do the right thing :) For now just disable tags. I'd be interested to know, whether it works reliably with tags if driven by some other host adapter, but I guess you don't have the equipment to test this. It would be especially interesting to see whether it fails if too many commands are active simultanously, or whether it does not like to many different tag numbers to be used over time. (The NCR driver tries to always use the same tag numbers over and over, except if a command fails, when it will choose a new driver in certain situations.) BTW: A firmware upgrade might solve your problem, too. If you still got warranty on the drive, you may even be able to get it for free. I'm not sure at all, whether this drive is still supported in some way, and by whom (since DEC sold its Storage Division to Quantum some two years ago), but getting the latest firmware that was released might help. (It did for some other drives, that had problems with tags!) Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608272035.WAA04283>