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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.