From owner-freebsd-stable Thu May 25 7:17:34 2000 Delivered-To: freebsd-stable@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id A073C37C25A for ; Thu, 25 May 2000 07:17:26 -0700 (PDT) (envelope-from Gerhard.Sittig@gmx.net) Received: (qmail 6320 invoked by uid 0); 23 May 2000 13:17:22 -0000 Received: from p3e9e7a98.dip.t-dialin.net (HELO speedy.gsinet) (62.158.122.152) by mail05.rzmi.gmx.net with SMTP; 23 May 2000 13:17:22 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id LAA17571 for freebsd-stable@FreeBSD.ORG; Tue, 23 May 2000 11:00:06 +0200 Date: Tue, 23 May 2000 11:00:06 +0200 From: Gerhard Sittig To: freebsd-stable@FreeBSD.ORG Subject: Re: ad0 drivers revisited Message-ID: <20000523110005.L2305@speedy.gsinet> Mail-Followup-To: freebsd-stable@FreeBSD.ORG References: <3929BB7F.60ECEFE4@airmail.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from jim@siteplus.net on Mon, May 22, 2000 at 07:48:24PM -0400 Organization: System Defenestrators Inc. Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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