To: scsi_ERASE@freebsd.org Cc: fabio_ERASE@cesar.unicamp.br, fty_ERASE@mcnc.org, gcrutchr_ERASE@nightflight.com, j_ERASE@uriah.heep.sax.de, jc_ERASE@irbs.com, julian_ERASE@freebsd.org, kuku_ERASE@gilberto.physik.rwth-aachen.de, lehey.pad_ERASE@sni.de, mrm_ERASE@Sceard.com, nikm_ERASE@ixa.net, tomppa_ERASE@fidata.fi, wilko_ERASE@yedi.iaf.nl, Scott Kelly , jhs@ Subject: 8 * 0xFF bytes at intermittent multiples of 0x1000 From: Julian H. Stacey Date: Tue, 11 Jun 1996 16:56:50 -0400 > From: Scott Kelly > To: jhs@ > Subject: Adaptec 1542A Users (from 12 Apr 1996) > > > I seem to be having similar problems, but with a 1542B... Do you know if there > has been a driver update since April? Don't know, cd /sys ; find . -type f -print | xargs grep 1542 I guess a scsi person might want to try: vi -c/1542 i386/conf/LINT i386/isa/aha1542.c i386/isa/isa.h \ scsi/README scsi/sd.c pci/ncr.c > I'm running 2.1... Me too (on the box in question). ------------ For reference, I'll append parts of my last mail: > Tomi Vainio > Has confirmed he sees the same Adaptec 1542A SCSI adapter bug that I do. > > > I connected sd1 to my 1542A and here are results: > > > > 1. No problems if testblock is only one that generates disk activity. > > 2. I launched couple find processes to sd0 and at same time I > > run testblock. Testblock failed only 1/10 of test runs. > > 3. I copied files with cp to sd1 when running testblock on > > sd1. Testblock failed on every time. > > > > Tomppa ........ > > > > ../testblock -v -l 10000000 /v/fish > > ../testblock: Neither -w or -r specified, so will both write then read. > > Using a block size of 61440, to a limit of 10000000. > > ../testblock writing then reading /v/fish. > > ../testblock: Started rewinding /v/fish. > > ../testblock: Finished rewinding /v/fish. > > ../testblock: In /v/fish, data mismatch at byte 49153 (0xc001), after 0 (0x0) previously checked ok. > > Byte read 255, byte expected 0 > > ../testblock: With /v/fish, only checked 0 bytes, 10,014,720 failed. > > ../testblock: Finished. ...... > > So it looks like a generic bug in FreeBSD code: > With a 1542A (& not a 1542B, which seems OK), > In simultaneous multiple task write mode to sd1 (or 2 or 3 or 4), > At random multiples of 0x1000 bytes, > The first 8 bytes of a block get forced to 0xFF. > (Of course it may well be that FreeBSD code is not `in error' but merely > doesnt allow for some wart in the 1542A, that's fixed in the 1542B, > but whatever, we need a fix). As above in this mail, I think I'm wrong there, it's not 1542A sepcific, I get it with 2 different 1542B's as well > Those who have not yet proven this on their system might like to try something > like this: > sync ; echo maybe even dump sd1 to tape # See below > cd <<>>/tmp > testblock -l 10000000 rubbish1 & > testblock -l 10000000 rubbish2 & > testblock -l 10000000 rubbish3 & > & do some other sd0 to sd1 copying in parallel. > Then run my 8f on all the data files youve run. > > Remember if you have a swap partition on sd1, & you swapped, > the swap may be damaged so you might crash. > If you'r really unlucky, while the system is creating new inodes for the > rubbish files, & is manipulating the file system, 8 bytes (out of several 0x1000) > bytes of file system structure data may get mangled. > > I have supplied CC readers with testblock.c & 8f.c, > for others interested, I'll toss them in http://............/~jhs/src/ Since Done. Julian -- Julian H. Stacey jhs@