From: Robert Hancock <hancockrwd@gmail.com>
To: Andrius Narbutas <andrius.narbutas@gmail.com>
Cc: linux-ide@vger.kernel.org
Subject: Re: Crash with Z77 chipset
Date: Tue, 18 Dec 2012 21:36:51 -0600 [thread overview]
Message-ID: <50D13653.3000708@gmail.com> (raw)
In-Reply-To: <50D02E83.3090403@gmail.com>
On 12/18/2012 02:51 AM, Andrius Narbutas wrote:
> On 2012.12.18 05:41, Robert Hancock wrote:
>> My first thought would be that a power problem is a possibility. These
>> kinds of setups with multiple HDs in a RAID setup are known to cause
>> these issues in some cases if the PSU isn't adequate.
>
> I do not think PSU is a problem, because:
> 1) All hard disks combined draw less energy than loaded CPU, even at
> heavy load (from HDD datasheet: "Read/Write: 6.80 Watts; Idle 6.10
> Watts" - difference is 0.7W per HDD, so < 3W combined, CPU draws ~40W
> when loaded, compared to idle). Loading CPU/RAM to max does not crash
> system at all
The CPU has a voltage regulator in front of it which can compensate for
dips in the input voltage. The disks don't. The wattage figures don't
necessarily account for short-duration power draw peaks. And depending
on how the drives are hooked up, especially if they are all on one
cable, they can potentially see a problematic voltage drop.
> 2) I'm planning power supplies at 2x needed power (you know, all those
> "Chinese Watt" system is unreliable). Anyway, should be more than enough
> for whole system (and CPU is almost at idle when creating filesystem, so
> load on PSU is very low - should be < 70W - that's almost nothing on
> 560W PSU, even counting "Chinese Watt" coefficient)
> 3) If PSU is fault - why it fails at exact the same place? Most of
> hardware failures have some "random" factor - you get segfaults at
> random places from faulty RAM, crashes from dying PSU when doing random
> tasks... But now it fails at exactly the same place (when using the same
> kernel)
> 4) Let's say PSU is faulty. Then how comes, that with 3.6.10 kernel i
> still have control over system (when it crashes) - so only disk
> subsystem fails? Because it has only one 12V rail - you cannot
> disconnect disks from system, without killing motherboard power too. But
> after crash i still can do `ssh root@deadhost 'echo b >
> /proc/sysrq-trigger'` - so system is alive and working well (just disks
> are dead)
>
> I could imagine that motherboard itself is faulty (well, interesting
> anyway - why it fails only on heavy I/O load), so i will try to get
> Windows Server installed to check if that will work.
prev parent reply other threads:[~2012-12-19 3:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-17 17:07 Crash with Z77 chipset Andrius Narbutas
2012-12-18 3:41 ` Robert Hancock
2012-12-18 8:51 ` Andrius Narbutas
2012-12-19 3:36 ` Robert Hancock [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50D13653.3000708@gmail.com \
--to=hancockrwd@gmail.com \
--cc=andrius.narbutas@gmail.com \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).