|Nick Slager||Jun 20, 2000 12:27 am|
|Don Lewis||Jun 20, 2000 12:53 am|
|Scott Donovan||Jun 20, 2000 1:51 am|
|Nick Slager||Jun 20, 2000 1:59 am|
|Nick Slager||Jun 20, 2000 2:02 am|
|Ian West||Jun 20, 2000 7:48 am|
|Nick Slager||Jun 20, 2000 9:35 pm|
|Don Lewis||Jun 22, 2000 12:29 am|
|Steve Passe||Jun 22, 2000 2:27 am|
|Don Lewis||Jun 22, 2000 2:33 am|
|Steve Passe||Jun 22, 2000 2:40 am|
|Nick Slager||Jun 23, 2000 12:38 am|
|Wilko Bulte||Jun 23, 2000 10:12 am|
|Thomas Zenker||Jun 26, 2000 2:08 am|
|Nick Slager||Jun 26, 2000 10:45 pm|
|Thomas Zenker||Jun 28, 2000 1:03 am|
|Nick Slager||Jun 28, 2000 5:43 am|
|Subject:||Re: Invalidating pack messages|
|From:||Thomas Zenker (th...@Lennartz-electronic.de)|
|Date:||Jun 28, 2000 1:03:07 am|
On Tue, Jun 27, 2000 at 03:45:36PM +1000, Nick Slager wrote:
Thus spake Nick Slager (nic...@albury.net.au):
Thus spake Don Lewis (Don....@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.
-- Thomas Zenker c/o Lennartz electronic GmbH Bismarckstrasse 136, D-72072 Tuebingen, Germany Phone: +49-(0)7071-93550 Email: th...@lennartz-electronic.de
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message