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)


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