Date: Wed, 28 Jun 2000 10:03:29 +0200 From: Thomas Zenker <thz@Lennartz-electronic.de> To: scsi@FreeBSD.ORG Cc: Nick Slager <nicks@albury.net.au> Subject: Re: Invalidating pack messages Message-ID: <20000628100329.A867@mezcal.tue.le> In-Reply-To: <20000627154536.A35696@albury.net.au>; from nicks@albury.net.au on Tue, Jun 27, 2000 at 03:45:36PM %2B1000 References: <20000620172810.A84355@albury.net.au> <200006200754.AAA28201@salsa.gv.tsc.tdk.com> <20000621143609.A3012@albury.net.au> <200006220729.AAA07327@salsa.gv.tsc.tdk.com> <20000623173844.A51332@albury.net.au> <20000627154536.A35696@albury.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 27, 2000 at 03:45:36PM +1000, Nick Slager wrote: > Thus spake Nick Slager (nicks@albury.net.au): > > > Thus spake Don Lewis (Don.Lewis@tsc.tdk.com): > > > > > If your seeing funny blinking lights on the drive, and you are not the only > > > person having problems with this particular drive model, I would be very > > > suspicious that a drive firmware bug is being tickled. The best solution > > > in this case would be to obtain a better version of the firmware from the > > > vendor, but lacking that you might try turning off tagged command queueing > > > or just reducing the number of tagged openings. I've noticed interactions > > > between tagged command queueing and write caching on Seagate drives, so you > > > might try turning off write caching and leaving the number of tagged > > > openings alone. You can do all this with camcontrol. > > > > This morning I disabled write back caching in the SCSI BIOS, and the machine > > has been copying files here and there for ~7 hours now with no problems at > > all. As you say the performance difference is pretty much negligible. > > > > I'm going to leave the machine copying and rm'ing files all weekend to make > > sure this all is OK, but at this stage it appears disabling write caching has > > fixed the problem (or at least worked around it). > > The machine ran fine for ~2.5 days without a problem. > > Just to confirm that the problem had been isolated, I turned write caching > back on this morning, expecting the box to die again. It steadfastly refuses > to die <damn, I HATE intermittent problems...> > > In any case, it would appear there is something odd going on that involves > write caching. I will turn write caching off again, do a 'make world', and > hopefully the confidence factor will start to rise :-) Hi, having at least the same symptoms like you, I could isolate the problem here to tagged queuing + heavy writes. It never happens for reading only, seeks etc. So I can read the whole disk (9G) to /dev/null without problems, but writing a big file with iozone or dd failes very quickly. I could eliminate the problem by switching of tagged queuing, with bad performance loss (write cache is turned off, bad this didn't help very much), but it survives buildworlds and writes of 6G files. best regards, -- Thomas Zenker c/o Lennartz electronic GmbH Bismarckstrasse 136, D-72072 Tuebingen, Germany Phone: +49-(0)7071-93550 Email: thz@lennartz-electronic.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000628100329.A867>