LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Brad Campbell <brad@wasp.net.au>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: libata Promise driver regression 2.6.5->2.6.6
Date: Wed, 19 May 2004 17:17:53 +0400 [thread overview]
Message-ID: <40AB5E81.4050301@wasp.net.au> (raw)
In-Reply-To: <40AA4585.4060301@pobox.com>
Against my better judgment I'm going to send this again as I have been having problems with a
particularly faulty mail server randomly blackholing outgoing mail and I have not seen this in the
archives after about 20 hours. Apologies if this arrives twice. I have temporarily subscribed to the
list.
Jeff Garzik wrote:
> Interesting.
>
> Well since it's not global behavior, but isolated to one port or card, I
> still worry about non-libata things:
> 1) is a SATA cable bad, or not plugged in well? I'm finding that it's
> easier to screw up SATA cabling than PATA. It's more-convenient design
> is also less rugged.
Nup, all seated fine and working perfectly well (and I mean raid-5 across all 10 disks and spraying
data at maximum PCI speed for 8 hours at a time well) with 2.6.5, and they are Supermicro cables
SATA cables with a pair of 5 bay Supermicro Hotswap bays so the quality is pretty good.
> 2) is a PCI slot bad, or not busmastering like it should? have you
> tried moving the card to another PCI slot?
I hadn't, but I just gutted the system and did a heap of card shuffles.. it ain't that.
> 3) is it always the 9th port, regardless of the ordering of the PCI
> cards in PCI slots?
Nup, but it's always appears to be on the 3rd card. Pull one of the cards and it's sweet.
> I apologize if you answered some of these in a previous message.
I hadn't, but I have now :p)
Under all these circumstances, 2.6.5 would boot fine. These tests were done with 2.6.5 and the patch
you supplied me.
I can even pull all the drives from boards 1&2 (drives 0-7) and it will lock hard on drive 8.
If I pull the 3rd card then it all behaves perfectly no matter what I do to it. I have relocated the
3rd card in other slots to change the detection order and it always *seems* to die on the 3rd
initialised card, no matter what slot.
Strange, No?
Brad
(I have knocked the other guys from the CC: as it does not appear to be ACPI related)
next prev parent reply other threads:[~2004-05-19 13:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <A6974D8E5F98D511BB910002A50A6647615FB7A9@hdsmsx403.hd.intel.com>
2004-05-17 19:01 ` Len Brown
2004-05-17 19:13 ` Brad Campbell
2004-05-17 19:35 ` Jeff Garzik
[not found] ` <40AA3844.9010403@wasp.net.au>
[not found] ` <40AA4585.4060301@pobox.com>
2004-05-19 13:17 ` Brad Campbell [this message]
2004-05-28 10:22 ` libata Promise driver regression 2.6.5->2.6.6 (now 2.6.7-rc1-bk4) Brad Campbell
2004-05-16 17:18 libata Promise driver regression 2.6.5->2.6.6 Brad Campbell
2004-05-16 17:49 ` Sergey Vlasov
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=40AB5E81.4050301@wasp.net.au \
--to=brad@wasp.net.au \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--subject='Re: libata Promise driver regression 2.6.5->2.6.6' \
/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
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).