|
-
Well, because I go away an awful lot (hence you only see me on here occasionally) the off-line backup only happens once every 6 months. The drive is powered down and removed from the array and placed into storage when it's not used. Since my server platform is not a file server and more a network/communications server, the actual contents of its hard drives doesn't change much. RAID-1 is more than adequate in this situation because although it's slow at writing (well, slower than operating one SATA drive - it's not slow in any sense!) because it has to do the write operation twice, it's extremely fast at reading because the Linux software RAID solution can (and does) use both hard drives simultaneously for read operations.
At least with RAID-1 I have more security than operating a single hard drive but I appreciate that there is a need for more redundancy. I just can't justify running 3 RAID-1 mirror drives 24x7 since the electricity drain is so much higher and the likelihood of failure is just about the same for the reason bwkaz stated above
James
-----------------------------
UseLinux.net
-----------------------------
perl -e 'use Math::Complex;$|=1;for$r(0..24){for$c (0..79){$C=cplx(($c/20.0)-3.0,-($r/12.0)+1.0);$Z= cplx(0,0);for($i=0;($i<80)&&(abs($Z)<2.0);$i++){$Z =$Z*$Z+$C;}print$i>=80?"*":" ";}print"\n";}'
-
I can't believe it. I tried running fluxbox, and I still haven't heard a peep put of the Motherboard's "audio post", just so long as I keep running Folding at Home. The idea that FAH could be the solution to my problem just tickles me to no end.
-
 Originally Posted by blackbelt_jones
I can't believe it. I tried running fluxbox, and I still haven't heard a peep put of the Motherboard's "audio post", just so long as I keep running Folding at Home. The idea that FAH could be the solution to my problem just tickles me to no end.
Wow, I'm running an Ubuntu Hardy live CD. I had the same problem with the audio post, and I fixed it the same way, by downloading and running the Folding at Home client. It works 100 per cent of the time. It's amazing enough that this should work so well, but that I should happen to think of it... seems a little miraculous, in a small everyday way.
Oh, and the old machine that I'd been using seems to have given up the ghost the minute I didn't need it anymore. Happy New Year!
-
Originally Posted by blackbelt_jones
It happens more when X is not running that when it is running.
X using a bit more CPU than a non-X system, probably?
It happens less when I'm using KDE than when I'm using a lighter GUI, e.g. fluxbox or icewm. Whenever it happens, doing almost anything with the keyboard or the mouse will instantly stop the annoyance, if only for for a moment.
Yeah, any of that will cause the machine to come out of its idle mode (either HLT, or an ACPI power saving state).
Now, if your kernel is using an ACPI power saving state (C3 I think it's called?), the issue may be with your motherboard's ACPI firmware. The kernel idles the CPU by calling some ACPI method or other, which transfers control to the firmware (BIOS), which runs whatever it thinks it needs to run. If the control transfer point is into whichever ACPI bit runs the voice, then that would explain why you hear the voice during idle times (though not during bootup).
That would not explain why it goes away when you need to use the CPU, though (if that was what was happening, then I'd expect the CPU to never come back). Another explanation (still a bug in the ACPI firmware) might be that the idle method works (more or less) as advertised, and the kernel is calling into the right place, but that method also starts up the voice for some reason (likely a bug).
If you know how to read ACPI tables, you may be able to grab Intel's ACPI disassembler and dump out your motherboard's ACPI DSDT (the binary version is available in sysfs somewhere; under /sys/firmware/acpi/ probably). Then see if you can figure out the bug. If you can, fix it, recompile the DSDT (using Intel's ACPI compiler), recompile your kernel, and tell it to use that file instead of the motherboard's built in (buggy) DSDT. It's one of the options under the ACPI menu somewhere ("path to alternate DSDT file" or something like that).
Alternately (and this is likely easier), you can attempt to upgrade your kernel. Or your motherboard's BIOS, if there's a newer version of that available. Or, you can attempt to make the kernel use the HLT instruction instead of ACPI to idle the CPU (try appending "idle=halt" to the kernel command line). 
-
Originally Posted by bwkaz
X using a bit more CPU than a non-X system, probably?
Yeah, any of that will cause the machine to come out of its idle mode (either HLT, or an ACPI power saving state).
Now, if your kernel is using an ACPI power saving state (C3 I think it's called?), the issue may be with your motherboard's ACPI firmware. The kernel idles the CPU by calling some ACPI method or other, which transfers control to the firmware (BIOS), which runs whatever it thinks it needs to run. If the control transfer point is into whichever ACPI bit runs the voice, then that would explain why you hear the voice during idle times (though not during bootup).
That would not explain why it goes away when you need to use the CPU, though (if that was what was happening, then I'd expect the CPU to never come back). Another explanation (still a bug in the ACPI firmware) might be that the idle method works (more or less) as advertised, and the kernel is calling into the right place, but that method also starts up the voice for some reason (likely a bug).
If you know how to read ACPI tables, you may be able to grab Intel's ACPI disassembler and dump out your motherboard's ACPI DSDT (the binary version is available in sysfs somewhere; under /sys/firmware/acpi/ probably). Then see if you can figure out the bug. If you can, fix it, recompile the DSDT (using Intel's ACPI compiler), recompile your kernel, and tell it to use that file instead of the motherboard's built in (buggy) DSDT. It's one of the options under the ACPI menu somewhere ("path to alternate DSDT file" or something like that).
Alternately (and this is likely easier), you can attempt to upgrade your kernel. Or your motherboard's BIOS, if there's a newer version of that available. Or, you can attempt to make the kernel use the HLT instruction instead of ACPI to idle the CPU (try appending "idle=halt" to the kernel command line).
You understand that I solved the problem by running the folding client, right? But much thanks. I'm very interested in understanding what was causing this, and might be willing to invest some time in "proper" cure.
However, in case you haven't been able to sense it, understand that I'm immensely pleased with myself for my improvised fix. I didn't stumble on this. I actually figured it out that FAH, which I always intended to run once I got everything working, could be the answer to keeping the system just above the idle mark. After observing it a bit, I'm quite certain that it's no coincidence, and so far, it works 100 percent.
Last edited by blackbelt_jones; 01-05-2009 at 12:25 AM.
-
Originally Posted by blackbelt_jones
However, in case you haven't been able to sense it, understand that I'm immensely pleased with myself for my improvised fix.
On the plus side, if the client ever crashes or you reboot and forget to turn it on (if you didn't setup as a daemon) then you'll have a repetitive audio reminder until you do! 
"Whenever you find yourself on the side of the majority, it's time to pause and reflect."
-Mark Twain
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
|
Reply With Quote
