To: tomppa_ERASE@fidata.fi,julian_ERASE@freebsd.org, John Capo <jc_ERASE@irbs.com>, Gary Crutcher <gcrutchr_ERASE@nightflight.com>, Greg Lehey <lehey.pad_ERASE@sni.de>, "Christoph P. Kukulies" <kuku_ERASE@gilberto.physik.rwth-aachen.de>, mrm_ERASE@Sceard.COM (M.R.Murphy), "Frank E. Terhaar-Yonkers" <fty_ERASE@mcnc.org>, fabio_ERASE@cesar.unicamp.br (Fabio M. Mengue - SUSS - CCUEC #200403# ), Nikos Mouat <nikm_ERASE@ixa.net>
Subject: Re. Adaptec 1542A Users
From: Julian H. Stacey <jhs@

1542A People,

I've done more tests here,
It seems if the system is quiet, my testblock program doesnt seem 
to always detect the bug, I think it seems more likely to occur if
the system is busy,
I have also managed to get the same bug (8*0xFF on random 0x1000 boundaries)
once on my 60m scsi tape.

Perhaps those of you have run my test on an otherwise quiescent system ,
& have detected no problem might try something like:
	tty1:		testblock -v /usr1/bla
	tty2:		testblock -v /usr/tmp/bla
	tty3:		testblock -v /usr2/tmp/bla
	tty4:		find / -type f -exec ls -l {} \; > /dev/null
-l 10000000 will limit bla to 10 Meg if you want, 
but more data gives more chance of catching the problem.

Of course if you dont use -l ,	bla will grow to fill all free space
on that disk partition (watch out !).

I also wrote 190M on a 1542B & read it OK on a 1542A (but it may have been
an otherwise quiescent 1542A), but it migh suggest this is a write problem
rather than read ... I'll do more tests.

BTW Plse. note I am not the Julian Elischer <julian_ERASE@freebsd.org>
that wrote much scsi code (somebody got me confused with him),
I am just some other Julian :-)
However if Julian E. missed my initial report, I'd be very happy to mail 
him a copy :-)

Julian
--
Julian H. Stacey  jhs@