fedora 12 install woes
in [UK Linux]
|
From: Baron on 14 Jan 2010 17:52 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 ! 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 ! -- Best Regards: Baron.
From: Nix on 15 Jan 2010 19:18 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%).
From: Nix on 15 Jan 2010 19:19 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.
From: Nix on 15 Jan 2010 19:26 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. Note that memtest *did not spot this*. (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.)
From: Baron on 16 Jan 2010 13:31
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 ! -- Best Regards: Baron. |