fedora 12 install woes
in [UK Linux]
|
From: Baron on 16 Jan 2010 13:32 Nix Inscribed thus: > On 14 Jan 2010, Baron said: > >> Darren Salt Inscribed thus: >> >>> I demand that Baron may or may not have written... >>> >>> [snip] >>>> Remember that video cards have onboard power supply circuits as >>>> well as CD drives and HDD. >>> >>> I know that old sound cards have IDE interfaces, but that's just >>> silly... > > :))) > >> I'll ignore that remark ! > > You missed the joke, right? > >> If you look at the video PCI, AGP, PCIe etc you will find at least >> one >> probably more power supply circuits. How do you think they get the >> 1.5v or there abouts for the Vcpu. >> >> Same applies to the other items I mentioned. >> >> Indeed I'm surprised by your ignorance ! > > Yes, you missed the joke. So it seems... -- Best Regards: Baron.
From: Baron on 16 Jan 2010 13:38 Nix Inscribed thus: > On 9 Jan 2010, crn(a)nospam.netunix.com told this: >> First download memtest86, burn it to CDROM and boot it. >> This will give the motherboard and memory a good workout > > Actually just about all it proves is that the RAM isn't utterly > broken. It can't spot more subtle problems such as crosstalk flipping > bits when particular patterns are sent down the bus and that sort of > thing. (At least, not reliably.) > > My latest desktop box is a Core i7 with a fully-populated Asus P6T > motherboard, i.e. 12Gb RAM. When I got it, that RAM was clocked at > 1333MHz. memtest worked, but a GCC bootstrap-and-test threw multiple > spontaneous coredumps, a huge pile of test failures, a bunch of > machine check exceptions and a system lockup at me. Slowing the RAM to > 1066MHz fixed the problem completely: our suspicion is that the > motherboard simply doesn't deliver enough power to run all its RAM > chips at its top rated speed. I've seen similar problems ! But they seem to be more related to timing jitter rather than power issues. > Note that memtest *did not spot this*. That doesn't surprise me. All you would see are errors. > (A lot of people swear by kernel compilations for finding problems > like this, but I swear by rolling GCC bootstrap-and-test runs. They're > harder to set up than a rolling kernel compile, but not only do they > test the RAM and caches hard by doing a lot of pointer chasing --- any > use of GCC will do that --- but they compile some truly enormous > things, using many Gb of RAM if bootstrapped with --enable-intermodule > (if it works, that's a rather wobbly option), and then they write them > to disk, read them back again and *make sure that they work the same > as the originals*. The problem with a kernel compile as system testbed > is that the compiler could be generating absolute rubbish or stuff > that's different every time you run it, and you'd never know. (Maybe > this is a little unlikely, but I'm paranoid.) You know what they say... -- Best Regards: Baron.
From: Mike Tomlinson on 17 Jan 2010 10:34 In article <87aaweuc6y.fsf(a)spindle.srvr.nix>, Nix <nix-razor- pit(a)esperi.org.uk> writes > Slowing the RAM to 1066MHz >fixed the problem completely: our suspicion is that the motherboard >simply doesn't deliver enough power to run all its RAM chips at its top >rated speed. Didn't read the manual, did you? -- (\__/) (='.'=) Bunny says Windows 7 is Vi$ta reloaded. (")_(") http://imgs.xkcd.com/comics/windows_7.png
From: Nix on 17 Jan 2010 18:45 On 16 Jan 2010, Baron spake thusly: > Nix Inscribed thus: > >> On 10 Jan 2010, Baron verbalised: >>> 75% of software problems are hardware related, ignoring virus and >>> PBKC. >> >> Speaking as someone who writes software for a living, boyoboy you >> couldn't be more wrong. I'd give the figure as well under 1%. Bugs >> in software are ubiquitous. >> >> (Even considering "you didn't read the hardware spec before you did >> $FOO and now it's failed" as a "hardware bug" and thus considering >> cache-coherency problems in multithreaded apps to be "hardware >> problems", the figure is likely still well under 5%). > > Ok ! So you are the only person that programs for all potential > hardware faults... I don't think so ! No... but hardware has a lot of *potential* faults, but relatively few *actual* ones that aren't catastrophic. Bad RAM (or bad cells on flash) is probably the most common, and that surely isn't common: I've never seen it except on new machiens. Software has myriad actual faults: the flow of bugs never stops. Compare to, say, the erratum list for a modern Intel CPU: a lot of faults, many of which sound horrible... but all of which are so obscure that either the OS can work around them or it never runs into them at all.
From: Nix on 17 Jan 2010 18:47
On 17 Jan 2010, Mike Tomlinson spake thusly: > In article <87aaweuc6y.fsf(a)spindle.srvr.nix>, Nix <nix-razor- > pit(a)esperi.org.uk> writes > >> Slowing the RAM to 1066MHz >>fixed the problem completely: our suspicion is that the motherboard >>simply doesn't deliver enough power to run all its RAM chips at its top >>rated speed. > > Didn't read the manual, did you? Yes, as a matter of fact. No mention of this. None at all. (The mobo vendor has, after pressure, admitted a design fault and inserted a caveat to that effect in later motherboard releases.) |