{ To: tomppa_ERASE@fidata.fi cc: julian_ERASE@freebsd.org Subject: Re: Adaptec 1542A Users From: Julian H. Stacey Hi tomppa_ERASE_@fidata.fi CC Julian Elischer julian_ERASE@freebsd.org From Julian H. Stacey jhs@ Reference: > From: Tomi Vainio > Reply-to: tomppa_ERASE@fidata.fi > Subject: Re: Adaptec 1542A Users > Date: Thu, 11 Apr 1996 15:11:55 +0300 (EET DST) > Message-id: <199604111211.PAA25640_ERASE@zeta.fidata.fi> > > Julian H. Stacey writes: > > I have found a bug, involving sd1 & sd2 & sd3 (but not sd0), asserting > > 8 * 0xFF at the beginning of random blocks aligned at 0x1000 intervals. > > I want to clarify if it's a generic FreeBSD bug or unique to my card. > > > > Here is my original mail that I sent. Why, did it bounce when sending to me before ? > Tomppa > > *** > >From tomppa Wed Feb 14 02:12:58 1996 > To: julian_ERASE@tfs.com > Subject: Adaptec 1542A > Date: Wed, 14 Feb 96 02:12:58 EET > > > Hi! > > I have very strange problem with my system. I ask this directly from > you because I don't want to get "check your termination" -help from > public list Yes it's a good reponse for some simple recipients, but I admit I was afraid I was receiving such noise too :-) > and you have written aha1542 driver. Umm sorry ... No ! Julian Elischer wrote scsi code So I copied this to . I Julian H. Stacey think Ive found a bug in 1542A driver. > Problem is with machine 2. SCSI card is Adaptec 1542A rev D and drive is > ST41200 (IMPRIMIS 94601-15) 1G hard drive. I bought this drive 1991. > Since then I have used it without any problems on these systems. > Adaptec 1542B BIOS 3.10 and 3.20 - DOS - ISC UNIX SVR3 > AMI BT742/AHA1542 compatible - DOS - ISC UNIX - FreeBSD 2.0, 2.05, 2.1 > WD7000FASST - FreeBSD 2.0, 2.05 > > Now I'm using it in machine 2. 50% of data I write on that drive on > machine 2 gets corrupted. Please tell me in what way the data is corrupted. Do you get a block of 8 0xFF bytes aligned at the beginning of random (not all) 0x1000 boundary aligned blocks ? Please run the enclosed 8f.c on some corrupt files, maybe with script find /usr.flaky.drive -exec 8f {} /dev/null \; I am very interested to know if you see the same bad data I do ! > I try use drive as my zip archive. I copy > couple files and run unzip test on them. If I copy files machine 2's > boot drive everything works. This faulty drive also works on machine 1. > Do you have any hints how to debug this problem? > > These things I have already tried: > 1. terminators and cables checked and changed > 2. active terminators used both ends of cable > 3. made faulty drive as only device on SCSI bus and installed new 2.1.0R > system on it > 4. adaptec jumper settings defaulted > 5. used faulty drive on another machine and it works > > > Tomppa > > > Machine 1: > *** > FreeBSD 2.1-STABLE #0: Tue Jan 30 19:07:18 EET 1996 > tomppa_ERASE@tick:/u/local/sup/sys/compile/TICK > CPU: i486DX (486-class CPU) > real memory = 33554432 (32768K bytes) > avail memory = 31309824 (30576K bytes) > eisa0: > Probing for devices on the EISA bus > bt0: adapter> at 0x33 > 0-0x333 irq 11 on eisa0 slot 4 > bt0: Bt747S/ 0-(32bit) bus > bt0: reading board settings, busmastering, int=11 > bt0: version 0.51, async only, parity, 32 mbxs, 32 ccbs > bt0: Not using Strict Round robin scheme > bt0 waiting for scsi devices to settle > (bt0:0:0): "SEAGATE ST12400N 8650" type 0 fixed SCSI 2 > sd0(bt0:0:0): Direct-Access 2048MB (4194685 512 byte sectors) > sd0(bt0:0:0): with 2621 cyls, 19 heads, and an average 84 > sectors/track > (bt0:2:0): "WANGTEK 5525ES SCSI 70Z" type 1 removable SCSI 2 > st0(bt0:2:0): Sequential-Access density code 0x0, drive empty > (bt0:6:0): "TOSHIBA CD-ROM XM-4101TA 2483" type 5 removable SCSI 2 > cd0(bt0:6:0): CD-ROM > cd0(bt0:6:0): NOT READY asc:3a,0 Medium not present > can't get the size > eisa0:6 unknown device > Probing for devices on the ISA bus: > sc0 at 0x60-0x6f irq 1 on motherboard > sc0: VGA color <4 virtual consoles, flags=0x0> > ed0 at 0x280-0x29f irq 15 maddr 0xd8000 msize 16384 on isa > ed0: address 00:00:c0:a8:f9:06, type WD8013EBT (16 bit) > sio1 at 0x2f8-0x2ff irq 3 on isa > sio1: type 16450 > sio0 at 0x3f8-0x3ff irq 4 on isa > sio0: type 16450 > lpt0 at 0x378-0x37f irq 7 on isa > lpt0: Interrupt-driven port > lp0: TCP/IP capable interface > fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > fdc0: NEC 72065B > fd0: 1.44MB 3.5in > fd1: 1.2MB 5.25in > bt1: disabled, not probed. > pas0 at 0x388 irq 10 drq 7 on isa > pas0: > opl0 at 0x388 on isa > opl0: > sb0 at 0x220 irq 7 drq 1 on isa > sb0: > npx0 on motherboard > npx0: INT 16 interface > changing root device to sd0a > *** > > Machine 2: > *** > FreeBSD 2.1-STABLE #0: Tue Jan 30 23:55:25 EET 1996 > tomppa_ERASE@tick:/u/local/sup/sys/compile/WORM > CPU: i486 SX (486-class CPU) > Origin = "GenuineIntel" Id = 0x423 Stepping=3 > Features=0x2 > real memory = 33554432 (32768K bytes) > avail memory = 30732288 (30012K bytes) > Probing for devices on the ISA bus: > sc0 at 0x60-0x6f irq 1 on motherboard > sc0: VGA color <4 virtual consoles, flags=0x0> > mse0 at 0x23c irq 5 on isa > pca0 on motherboard > pca0: PC speaker audio driver > sio0 at 0x3f8-0x3ff irq 4 on isa > sio0: type 16450 > sio1 at 0x2f8-0x2ff flags 0x785 on isa > sio1: type 16550A (multiport) > sio2 at 0x3e8-0x3ef flags 0x785 on isa > sio2: type 16550A (multiport) > sio3 at 0x2e8-0x2ef flags 0x785 on isa > sio3: type 16550A (multiport) > sio4 at 0x280-0x287 flags 0x785 on isa > sio4: type 16450 (multiport) > sio5 at 0x288-0x28f flags 0x785 on isa > sio5: type 16450 (multiport) > sio6 at 0x290-0x297 flags 0x785 on isa > sio6: type 16450 (multiport) > sio7 at 0x298-0x29f irq 3 flags 0x785 on isa > sio7: type 16450 (multiport master) > fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > fdc0: NEC 765 > fd0: 1.44MB 3.5in > 200 nSEC ok, using 250 nSEC > aha0 at 0x330-0x333 irq 11 drq 5 on isa > aha0 waiting for scsi devices to settle > (aha0:0:0): "SEAGATE ST5660N 0518" type 0 fixed SCSI 2 > sd0(aha0:0:0): Direct-Access 520MB (1065664 512 byte sectors) > sd0(aha0:0:0): with 3002 cyls, 4 heads, and an average 88 > sectors/track > (aha0:1:0): "IMPRIMIS 94601-15 4614" type 0 fixed SCSI 1 > sd1(aha0:1:0): Direct-Access 992MB (2031705 512 byte sectors) > sd1(aha0:1:0): with 1931 cyls, 15 heads, and an average 70 > sectors/track > wds0: disabled, not probed. > 1 3C5x9 board(s) on ISA found at 0x300 > ep0 at 0x300-0x30f irq 10 on isa > ep0: aui/bnc/utp[*BNC*] address 00:20:af:5c:0a:7d irq 10 > npx0 on motherboard > npx0: 387 emulator > changing root device to sd0a > *** > --- > Tomi Vainio, Fimeko-Data OY Phone +358-0-4582421 > Internet tomppa_ERASE@fidata.fi Telefax +358-0-4582425 > X.400 /C=fi/ADMD=fumail/PRMD=inet/O=fidata/S=Vainio/G=Tomi/ > > > ----------- begin 644 8f.tgz DELETED end ----------- By seperate cover: A copy of what I recently sent to the other 1542A people Julian -- Julian H. Stacey jhs@ }{ Reply-to: tomppa_ERASE@fidata.fi Date: Fri, 12 Apr 1996 02:15:28 +0300 (EET DST) From: Tomi Vainio To: "Julian H. Stacey" > > > Here is my original mail that I sent. > Why, did it bounce when sending to me before ? > It didn't bounce. I didn't mail this to you before. I mailed it directly to Julian Elischer. I found this problems last year with 2.0.5R but then I had enough disk space. This machine is my home router and sd1 is an old 1G seagate that I'd like to use for zip archive. After that I installed 2.1.0R and at last 2.1.0-stable. Problems was still the same. No one else seemed suffer about this same problem. At last I got enough time to test and courage to report problem to Julian. > Umm sorry ... No ! > Julian Elischer wrote scsi code > So I copied this to . > I Julian H. Stacey I hope we have found same bug and we can fix it :) > > Please tell me in what way the data is corrupted. > Do you get a block of 8 0xFF bytes aligned at the beginning of random > (not all) 0x1000 boundary aligned blocks ? > > Please run the enclosed 8f.c on some corrupt files, > maybe with > script > find /usr.flaky.drive -exec 8f {} /dev/null \; > I am very interested to know if you see the same bad data I do ! > I don't know how data is corrupted. I try use this drive as zip archive that contains 1G of zip files sized 1-2M/each. Zip contains -t -option that checks integrity of zip file. I just copied couple large zip files to this drive and run unzip -t -test to them. Last Sunday sd0 of this machine got head crash. Same time I disconnected sd1 from SCSI bus. Later today I will connect it back and run your test programs. Tomppa }{ From tomppa_ERASE@zeta.fidata.fi Fri Apr 12 16:40:13 1996 From: Tomi Vainio To: "Julian H. Stacey" Subject: Re: Adaptec 1542A Users Reply-To: tomppa_ERASE@fidata.fi Julian H. Stacey writes: > > Please tell me in what way the data is corrupted. > Do you get a block of 8 0xFF bytes aligned at the beginning of random > (not all) 0x1000 boundary aligned blocks ? > > Please run the enclosed 8f.c on some corrupt files, > maybe with > script > find /usr.flaky.drive -exec 8f {} /dev/null \; > I am very interested to know if you see the same bad data I do ! > fish is file that testblock made and zip files are copied with cp Tomppa worm:/v(13)# find . -exec 8f/8f {} /dev/null \; ../fish: byte (dec) 147457 (hex) 24001, line 577 character 247 ../fish: byte (dec) 2203649 (hex) 21a001, line 8608 character 25 ../fish: byte (dec) 2383873 (hex) 246001, line 9312 character 28 ../herit201.zip: byte (dec) 147457 (hex) 24001, line 570 character 21 ../herit209.zip: byte (dec) 212993 (hex) 34001, line 833 character 53 ../herit209.zip: byte (dec) 1245185 (hex) 130001, line 5132 character 122 ../herit208.zip: byte (dec) 53249 (hex) d001, line 233 character 482 ../herit208.zip: byte (dec) 147457 (hex) 24001, line 619 character 355 ../herit207.zip: byte (dec) 49153 (hex) c001, line 178 character 39 ../herit204.zip: byte (dec) 999425 (hex) f4001, line 3874 character 275 ../herit204.zip: byte (dec) 1458177 (hex) 164001, line 5863 character 11 ../herit203.zip: byte (dec) 147457 (hex) 24001, line 406 character 56 ../herit203.zip: byte (dec) 868353 (hex) d4001, line 3138 character 72 ../herit202.zip: byte (dec) 49153 (hex) c001, line 194 character 239 ../herit210.zip: byte (dec) 49153 (hex) c001, line 192 character 497 ../herit210.zip: byte (dec) 147457 (hex) 24001, line 611 character 491 ../8f/8f.c: byte (dec) 173 (hex) ad, line 10 character 32 }{ Reply-to: tomppa_ERASE@fidata.fi Date: Fri, 12 Apr 1996 23:37:12 +0300 (EET DST) From: Tomi Vainio To: "Julian H. Stacey" Subject: Re. Adaptec 1542A Users Julian H. Stacey writes: > > Since my posting, > I have written & read a 190 meg image on sd3 using a system with a 1542B, > then I took it to the 1542A system, as sd1 ... it blew within a few K. > > The test on a 1542A system is simple: > make > ./testblock -v -l 10000000 /usr2/tmp/rubbish > (where /usr2/tmp must be on /dev/sd1 or 2 or 3, but not /dev/sd0 or /dev/wd* > & wait to see if you get something like: > data mismatch at byte 40961 (0xa001), after 0 (0x0) previously checked ok. 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. }{