atom feed17 messages in org.freebsd.freebsd-scsiRe: Invalidating pack messages
FromSent OnAttachments
Nick SlagerJun 20, 2000 12:27 am 
Don LewisJun 20, 2000 12:53 am 
Scott DonovanJun 20, 2000 1:51 am 
Nick SlagerJun 20, 2000 1:59 am 
Nick SlagerJun 20, 2000 2:02 am 
Ian WestJun 20, 2000 7:48 am 
Nick SlagerJun 20, 2000 9:35 pm 
Don LewisJun 22, 2000 12:29 am 
Steve PasseJun 22, 2000 2:27 am 
Don LewisJun 22, 2000 2:33 am 
Steve PasseJun 22, 2000 2:40 am 
Nick SlagerJun 23, 2000 12:38 am 
Wilko BulteJun 23, 2000 10:12 am 
Thomas ZenkerJun 26, 2000 2:08 am 
Nick SlagerJun 26, 2000 10:45 pm 
Thomas ZenkerJun 28, 2000 1:03 am 
Nick SlagerJun 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
List:org.freebsd.freebsd-scsi

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.

best regards,

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message