Re: Promise SATA 300 TX4

From: FreeBSD Mailing Lists <lists_at_curacao.billsf.net>
Date: Mon, 13 Aug 2007 09:15:38 +0200
On Mon, Aug 13, 2007 at 02:03:28PM +0900, Nathan Butcher wrote:
> >I tried to roll back to right before the above mentioned change
> >Karsten (well, I assume it was him  :-)  ) noted on IRC that it might
> >be the cause of the problems since I have a similar controller, though
> >not exactly the same one, but it didn't fix the timeouts for me.
> 
> >For this server I have 3 disks in a graid3 (so no ZFS but the errors
> >are similar to what I have seen / heard about wrt. ZFS + ata use) and
> >I get timeouts several times a day which causes FreeBSD to loose
> >contact with one or more disks where I have to reboot before things
> >recover (usually FreeBSD panic's enough so the system reboots by
> >itself).
> 
> I'm certain that the issue with this card isn't limited to ZFS. It's
> been seen before in the 6.x series too.
> 
> I really would like to find out which code changes ruined the card's
> correct operation... if that could help the ata maintainer in some way.
> Unfortunately my csup-fu isn't that strong, otherwise I would send my
> source tree back to June 15th and analyse daily buildworlds from that
> date until I could pin-point the exact date and file changes that caused
> the problem all of us are seeing.
> 
> Could someone teach me how to do csup rollbacks to a specific date in
> the source tree? If it's not obvious already, I'd really like to squash
> this bug.

Nathan,

This problem has gone away for me, for the most part. At one point, out
of desparation, I changed a few lines in the kernel to prevent crashes.
I don't have this problem with zfs, but that is on a production server 
using a SCSI RAID system. (v6.2-stable about a year old) 

According to csup(1) just add 'date=[cc]yy.mm.dd.hh.mm.ss' to your cmdline
arguments. Presumably it also works in 'supfile'. Note that you must supply
the full year past 2000. I'd either reserve another space or back-up your
current source tree. I've only needed to backtrack once before and that was
using cvsup(1). Corrupted or improperly tagged material just stays.
Actually this is a feature, but offtopic. 

The machine I'm referring too uses an on-board nVidia N570 SATA-300 system, 
though the Promise cards are 100% compatible. (and preferred because the 
connectors are hard to reach and as a result are easy to break)

Bill

 
Received on Mon Aug 13 2007 - 05:15:40 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:16 UTC