Date: Tue, 14 Apr 1998 15:22:37 -0700 From: Mike Smith <mike@smith.net.au> To: Stephen Roome <steve@visint.co.uk> Cc: Mike Smith <mike@smith.net.au>, Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG Subject: Re: ps segfaults since I overclocked. and worries. Message-ID: <199804142222.PAA01124@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 14 Apr 1998 03:46:32 BST." <Pine.BSF.3.96.980414030756.17673E-100000@dylan>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, 10 Apr 1998, Mike Smith wrote: > > > There is some mention of this in /sys/pci/ide_pci.c, I > > > > This is a timing issue related to conformance with the various IDE > > standards. > > Do you or anyone else know where I can get a copy of the IDE standards, > I should probably have already read them before I even asked. ftp://fission.dt.wdc.com/standards You will also want the PIIX datasheeds from Intel, as well as those for other PCI IDE controllers from VIA, SiS, etc. if you want the full complement. Some of these are easy to find, some can take quite a lot of work. > > > am 100% certain that the hardware I have is performing fine at these > > > speeds, > > You have an observed aberration, yet you are "100% certain"? Who are > > you kidding? > > I see your point. Someone replied earlier with the incredibly sensible > suggestion that I should recompile my ps binary. Worked a treat! So, the > hardware was fine after all, I'd just not got the software in proper > order. Wasn't kidding anyone, I just hadn't made myself clear. This really suggests that you changed more than "just" the clock speed - recompiling ps is normally only a requirement when you've updated your kernel - it's certainly not sensitive to CPU speed! Rule #1 when experimenting: Change _only_one_thing_ at a time. > > > Does the following mean that some new PC's are not going to work properly? > > > And that FreeBSD just won't support them ? > > > > No. It means that you are expected to run the parts involved (the > > VIA571 and Intel PIIXn) at their rated speeds. If you correctly > > configure your system, this is what will happen. > > It was probably worth mentioning a long time ago that this isn't an Intel > chipset based board: > > ide_pci0: <VIA 82C586x (Apollo) Bus-master IDE controller> rev 0x06 on > pci0.7.1 Hmm, somewhat pertinent. Your mention of the motherboard model is more useful though. > Hypothetically : > > If I purchase a 6x86 that is supposed to run at 188Mhz, and hence a bus > speed of 75Mhz (and run it on this board - an FIC PA2007) does this mean > that the frequency the IDE devices are clocked at is greater than 30 or > 33Mhz ? This depends on the board implementation, and the devices in question. As a general rule, if the board claims that the higher bus speeds are supported, then the design will cater for operating the IDE interfaces at the correct speed. It would be a valid question to ask whether the IDE controller requires different programming in order to operate the IDE bus at the correct speed - you would need chipset documentation to verify this (by examining the driver source). > If so, then would a correctly configured system still work as you say? As > this isn't what the comment in the code implies to me. A correctly configured system will have a 33MHz clock available to the IDE controller so that it can generate the 8.3MHz Ultra-DMA clock, or provide extra configurability such that the IDE controller can compensate. Note that requiring the IDE driver to know the bus speed is extremely bogus, but not out of the question. > If not, then I think I realise whats going on, but don't see how one would > overclock the IDE devices (the code implies that it's possible). If the IDE controller chip expects to be only ever fed with a 30/33MHz clock (eg. Intel PIIX), and the motherboard has a fixed ratio between the CPU:memory clock and PCI clock (most Intel-based boards), then if you pull the CPU:memory clock above rated spec (eg. 66MHz) you bring the clock to the IDE controller over spec too. An example: consider an Intel-based board using a PIIX controller and the 440LX AGPset. Boards of this ilk generally run with a 66MHz master clock. The clock is internally multiplied in the CPU to obtain the core clock, and divided by 2 to obtain the PCI clock, which is also fed to the PIIX. The PIIX divides by 4 again to produce the UDMA clock. If you raise this to 75MHz, the PCI clock rises to 37.5MHz, and the UDMA clock rises to 9.375MHz. This increase is more than enough for cable noise, marginal timing, etc. to become an issue. A "more correct" board design would ensure that the PCI clock stayed at 33MHz - this is not (AFAIK) feasible with the Intel chipsets (bus rate conversion is expensive, and Intel design for speed which is why they are going straight for 100MHz). > If I've got something wrong then please could someone explain it to me. I > just wanted to know how/why it works or doesn't. I hope the above is at least marginally helpful - part of the problem here is just that despite all the marketting hype to the contrary, modern PC systems are quite complex and vary enormously at the detail level, and this detail is often difficult to ascertain without access to data that often just isn't available. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804142222.PAA01124>