Date: Mon, 5 Feb 1996 21:32:35 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: Leo Papandreou <leo@rur.com> Cc: questions@freebsd.org Subject: Re: Quantum Atlas woes Message-ID: <199602052032.AA26782@Sysiphos> In-Reply-To: Leo Papandreou <leo@rur.com> "Quantum Atlas woes" (Feb 4, 0:59)
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 4, 0:59, Leo Papandreou wrote: } Subject: Quantum Atlas woes } } Hot on the tails of a recent Barracuda failure, I installed a Quantum } XP34300 and upgraded from 2.0.5 to 2.1-Release (nice install btw.) } } When putzing around with small file operations everything seems } cool enough but when i attempt to mget or cp several hundred files } i invariably get a stream of i/o errors. } } Feb 3 23:54:54 bart /kernel: assertion "cp" failed: file "../../pci/ncr.c", line 5560 } Feb 3 23:54:54 bart /kernel: sd1(ncr0:2:0): COMMAND FAILED (4 28) @f09b5400. Hmm, that's interesting ... The disk complains about a QUEUE FULL condition! This is the result of too many tagged commands being sent ... But I've got a Quantum Atlas (the 2GB version) myself, and it never had any problems working with 16 tags, so I don't see how that should be a problem with your drive (and you don't seem to have changed the default setting of 4 tags). (According to some docs I once read, it supports some 50 tags, IIRC.) } [repeated ad nauseum] The generic SCSI code retries the command, but there was no delay between retrys in 2.1R. This is fixed in -current, AFAIK. } And on a reboot, } } DIRECTORY /foo: LENGTH 2576 NOT A MULTIPLE OF 512 (ADJUSTED) } FREE BLK COUNTS(S) WRONG IN SUPERBLK (SALVAGED) } BLK(S) MISSING IN BIT MAPS (SALVAGED) } SUMMARY INFORMATION BAD (SALVAGED) } CLEAN FLAG NOT SET IN SUPERBLOCK (FIXED) } } } Is there a known failing in the ncr driver vis a vis the Quantum Atlas } that -STABLE corrects? No, the NCR driver didn't change in the handling of tags for about one year. } Also, it hurts me to say this and I'm begining to fear for the worst, } the drive will be quiet for several minutes and then all of a sudden } start to emit these grinding/rattling/sickening burps every 20 seconds } or so. This doesn't sound sane at all ! I've got one myself, and since it doesn't have to do thermal recals (because being of the embedded servo type), there really should be NO such noises! You could try the "handshake timeout" patch, which was necessary for some scanners and CD-R writers. It disables the SCSI phase timeout of 1.6 seconds, which was too short for those devices. It is in fact possible, that your drive has some hardware problems, and locks up for a few seconds trying to recover from them. The patch might help in that case, but this would make a hardware problem even more probable ... (BTW: The handshake timeout of 1.6 seconds had been in the NCR driver for quite a long time, and 2.1R had it as well as 2.0.5R ...) Please apply the following patch and let me know, whether it helps ... Regards, STefan Index: /sys/pci/ncr.c =================================================================== *** ncr.c 1996/01/10 21:20:57 1.56 --- ncr.c 1996/01/23 21:47:12 1.61 *************** *** 4427,4431 **** OUTB (nc_stest2, EXT ); /* Extended Sreq/Sack filtering */ OUTB (nc_stest3, TE ); /* TolerANT enable */ ! OUTB (nc_stime0, 0xfb ); /* HTH = 1.6sec STO = 0.1 sec. */ /* --- 4424,4428 ---- OUTB (nc_stest2, EXT ); /* Extended Sreq/Sack filtering */ OUTB (nc_stest3, TE ); /* TolerANT enable */ ! OUTB (nc_stime0, 0x0b ); /* HTH = disabled, STO = 0.1 sec. */ /* -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602052032.AA26782>