Date: Thu, 25 May 2000 12:38:33 -0700 From: Kent Stewart <kstewart@3-cities.com> To: Gerhard Sittig <Gerhard.Sittig@gmx.net> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: ad0 drivers revisited Message-ID: <392D8139.7299E044@3-cities.com> References: <3929BB7F.60ECEFE4@airmail.net> <Pine.BSF.4.21.0005221942240.249-100000@discover.siteplus.net> <20000523110005.L2305@speedy.gsinet>
next in thread | previous in thread | raw e-mail | index | archive | help
Gerhard Sittig wrote: > > 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. The important point is that you can't turn it off when your system is in trouble. They never set "flags 0xa0ffa0ff" as the default on the 2.x-3.x because it didn't work on some systems. The new ATA driver defaults to UDMA66 and doesn't give you the opportunity to turn it off when you boot and you have one of those combinations that really need it to only use PIO. I have been really slow upgrading one of my machines because of the ATA driver problems with UDMA66 HD's. I'm not going to tear a machine apart and rebuild it just to find out it suddenly won't work. The curent system is really slow but one that doesn't work is much worse. I'm not sure the delay in booting will be more than a few seconds. I got 8MB/s off a PIO 4 drive and 14MB/s off of a UDMA66 drive in 33 mode. Once you start doing any random I/O they were both equally slow. Because of the equally slow part, you might not be able to measure the difference in boot time. Unless, you are suddenly successful :). Kent > > > 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 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?392D8139.7299E044>