Date: Tue, 23 May 2000 11:00:06 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-stable@FreeBSD.ORG Subject: Re: ad0 drivers revisited Message-ID: <20000523110005.L2305@speedy.gsinet> In-Reply-To: <Pine.BSF.4.21.0005221942240.249-100000@discover.siteplus.net>; from jim@siteplus.net on Mon, May 22, 2000 at 07:48:24PM -0400 References: <3929BB7F.60ECEFE4@airmail.net> <Pine.BSF.4.21.0005221942240.249-100000@discover.siteplus.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 22, 2000 at 19:48 -0400, Jim Weeks wrote:
>
> On Mon, 22 May 2000, Alan Edmonds wrote:
> >
> > What worked for me was to put
> > hw.atamodes=pio,,pio,
> > in /etc/sysctl.conf
>
> I tried this also. Did you by any chance use this along with
> /sbin/sysctl -w hw.atamodes=pio,pio,pio,pio in /etc/rc?
IIRC are there some combinations of boards (i.e. controllers) and
disks out there unable to cope with each other. And in the worse
cases they do so right from the start. I struggled against such
a beast myself lately: A VIA MVP4 board (that is, with a 82c586A
PCI IDE controller) and a Fujitsu drive. Although both of them
are new and cables aren't cheap (and of course I swapped them to
make sure and I have a few of these machines and they all behave
similarly) DMA mode simply won't work.
The problem is: I could even disable UDMA modes in BIOS -- and
all I get was that they get initialized to PIO mode when the BIOS
is done. But: As soon as the BSD kernel is loaded and sees the
hardware and activates its own drivers, negotiation takes place
again (am I right in this or do I miss a point?). The chip is
known to handle UDMA, the disk says "I can do that" and the
lowest common denominator - and thus the conclusion the driver
comes to - is "let's use it this way". Boom! And problems arise
even before the user (or admin) is able to degrade downwards to a
known to work mode (see the logs with read timeouts right after
mounting root someone else - Jim? - posted in this thread).
What I have seen in the previos discussions - and what I missed
this time - was a simple approach like this: boot up with
conservative assumptions and have UDMA mode get activated later
via sysctl. This way *any* machine will work fine from boot to
shutdown, and the confident in their hardware or the ones wanting
to fiddle for performance could switch to higher modes for their
daily operation. There might be a minimal loss of performance
for those with hardware (combinations) capable of UDMA -- but
only from installation to the point when they throw the switch.
And I wouldn't mind the few seconds lost in the boot sequence
between kernel loading and rc execution (if it's seconds at all).
To make it even less important: How often does one boot? Once a
year? Twice a year?
I feel this little approach to be what helps most of the
problematic cases where hardware claims high capabilities and
fails to operate with these when actually enabled. And the UDMA
switch could be prepared in /etc/sysctl.conf just as well as the
routing switch is.
> I even saw a post saying that someone put it into
> /root/.profile and /root/.login, although I am not sure how
> that was implemented or why.
Setting IDE modes down to lower values (or upping them) shouldn't
be necessary this often, once should suffice absolutely. The
real problem is (as sketched above) that you might have errors
even before you can turn off UDMA mode. I found OpenBSD show the
first errors and falling back to PIO when formatting upon
installation and it couldn't even boot after installation's end.
And no matter how often I'm able to get a shell -- as long as
during installation the sysctl(8) command is missing I could be
willing to do something as much as I could, I'm simply _unable_
to make it work. Remembering this situation and hearing about
yours I feel "being trapped" is the right phrase to name this.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000523110005.L2305>