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 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.