Re: Sata controller headache

From: Paul Bliss <pbliss_at_mechno.com>
Date: Fri, 13 Oct 2006 10:12:28 -0400 (EDT)
Thanks again for the lead, Rich. I've been unable to find the comparable 
setting in my bios, though. I wonder if the burts mode specifically was 
the issue, or if just the general slowing of the IO was what did the trick 
for you.

  FYI I've heard that the nvidia sata, that is onboard with so many new 
boards, doesn't have this problem.

  I think I may just go with IDE. For the amount that I've shelled for 
controllers that haven't worked out...
pleh.

But, seriously, thanks for everyone who helped out.
-Paul

On Wed, 11 Oct 2006, Rich Wales wrote:

> Earlier, I wrote in -current:
>
>> I've been seeing the same kinds of errors [as Paul Bliss was having]
>> with a Promise SATA300 TX4 controller and a pair of Seagate 300GB
>> SATA drives.  Apparently, people have been having similar problems
>> with SATA drives on Promise controllers for quite some time now, in
>> both FreeBSD and Linux systems.  Lots of reports and requests for
>> help, but no one so far has admitted to having a clue as to what is
>> causing it.
>
> I wanted to let people know that I managed to fix (or, at least, work
> around) my problem by adjusting the BIOS settings for my (old "Slot A"
> Athlon system) motherboard.  Specifically, I disabled PCI master burst
> mode, and although this slowed down disk I/O significantly, it made
> the instabilities w/r/t the Promise card go away completely.
>
> I'm not sure whether the fundamental problem is flaky PCI bus design
> in some motherboards, or overly picky bus expectations by Promise, but
> this experience suggests to me that people who are having timeouts and
> hanging errors with Promise SATA controllers might want to try playing
> with the PCI-related BIOS settings on their motherboards and see if
> that gives them relief.  If anyone is having trouble with a Promise
> card in a recent-design motherboard with normal BIOS settings, of
> course, that would strongly point to Promise as the guilty party.
>
> Whether anything can be done to relieve this problem in the device
> driver is a question I'm not in a position to answer.
>
> Rich Wales
> Palo Alto, CA, USA
> richw_at_richw.org
> http://www.richw.org
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Fri Oct 13 2006 - 12:13:33 UTC

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