Date: Sat, 27 May 2000 11:21:55 +0400 From: Grigoriy Strokin <grg@philol.msu.ru> To: Gerhard Sittig <Gerhard.Sittig@gmx.net> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: ad0 drivers revisited Message-ID: <20000527112155.A52404@isabase.philol.msu.ru> In-Reply-To: <20000523110005.L2305@speedy.gsinet>; from Gerhard.Sittig@gmx.net on Tue, May 23, 2000 at 11:00:06AM %2B0200 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
On Tue, May 23, 2000 at 11:00:06AM +0200, 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 Yes. And also, in least worst cases they do so right from the start *SOMETIMES*. That is, in most cases I turn my machine on, the sysctl -w ... line works as expected and the machine boots sucessfully. In less frequest cases, however, I see the message /sbin/jkhh32980y&*T^(*&GHihg: not found or something like that, and the start-up process stops. I turn the machine off, then on again, and then all goes well. > a beast myself lately: A VIA MVP4 board (that is, with a 82c586A > PCI IDE controller) and a Fujitsu drive. Although both of them A have 82C598MVP chip and Fujitsu drive > 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 The same happens to me > 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 boot my home machine once a day :) And anyway, the kernel always turns DMA on on boot, at the moment. -- === Grigoriy Strokin, Lomonosov University (MGU), Moscow === === contact info: http://isabase.philol.msu.ru/~grg/ === 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?20000527112155.A52404>