From: Tejun Heo <htejun@gmail.com>
To: Gabor FUNK <FUNK.Gabor@hunetkft.hu>
Cc: IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: JMicron - hard resetting link
Date: Tue, 12 Feb 2008 23:52:09 +0900 [thread overview]
Message-ID: <47B1B299.3010208@gmail.com> (raw)
In-Reply-To: <003801c86d84$fdae0510$4d0fa8c0@M2007>
Gabor FUNK wrote:
>> It shouldn't kill the RAID. Hmmm... The log is truncated. Can you
>> please post full kernel log spanning from boot to array death?
>
> RAID "dies" because controller dies, then it loses 4 disks out of 8...
> Actually, the server last time was up and running for 2 months.
> Then when it failed the 1st time, I did some tests and it went on for
> 3 days, including building the raid and heavy test file copy.
> The full log from the 1st relevant error message till the death of
> the array is here:
> http://www.huweb.hu/maques/tmp/jmicron/syslog
What I said was that timeouts occurring due to transmission errors
should be recoverable. It seems like IRQ delivery didn't work probably
due to screaming IRQ. I need to see the messages before the first
relevant error message. It's always a good idea to post full kernel log
from boot till failure. Things which don't seem relevant are often
relevant.
>> Move half of the drives to the new PSU and see whether the problem goes
>> away.
>
> This is a new server, with a Chieftec GPS650AB, 650W PSU in it.
> Though AFAIK a harddisk consumes around 10W, and I will try to use
> more than one PSU-s.
I've recently tracked down IO problems a server product line from a
major (really, one of the top three) vendor to malfunctioning PSU, so
don't trust the labeling too much.
> The main problem is that I can't immediately see if it helps or not.
> Even if it will work without this problem for a week, I can't be sure it
> still will in 2 months...
> Because of this - and because I believe that this problem related to the HW
> (motherboard, chipset) - I'd rather just throw away the MB and use an
> other one with two extra 4 port SATA cards.
Till now, none of this kind of problem has been tracked down to MB or
the controller while 90% of hardware problems turned out to be power
related.
Thanks.
--
tejun
next prev parent reply other threads:[~2008-02-12 14:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-12 9:48 JMicron - hard resetting link Gabor FUNK
2008-02-12 13:05 ` Tejun Heo
2008-02-12 14:38 ` Gabor FUNK
2008-02-12 14:52 ` Tejun Heo [this message]
2008-02-12 17:27 ` Gabor FUNK
2008-02-12 23:50 ` Tejun Heo
2008-02-14 23:02 ` Gabor FUNK
2008-02-14 23:32 ` Tejun Heo
2008-02-21 21:45 ` Gabor FUNK
2008-02-22 2:03 ` Tejun Heo
2008-02-24 9:04 ` Gabor FUNK
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=47B1B299.3010208@gmail.com \
--to=htejun@gmail.com \
--cc=FUNK.Gabor@hunetkft.hu \
--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).