All of 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)


  reply	other threads:[~2004-05-19 13:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <A6974D8E5F98D511BB910002A50A6647615FB7A9@hdsmsx403.hd.intel.com>
     [not found] ` <A6974D8E5F98D511BB910002A50A6647615FB7A9-N2PTB0HCzHJviC08c4yzC1DQ4js95KgL@public.gmane.org>
2004-05-17 19:01   ` libata Promise driver regression 2.6.5->2.6.6 Len Brown
2004-05-17 19:01     ` Len Brown
2004-05-17 19:13     ` Brad Campbell
2004-05-17 19:35       ` Jeff Garzik
     [not found]         ` <40A91410.5040408-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2004-05-18 16:22           ` Brad Campbell
     [not found]             ` <40AA3844.9010403-UPaTOFvTz1K6c6uEtOJ/EA@public.gmane.org>
2004-05-18 16:51               ` Brad Campbell
2004-05-18 17:19               ` Jeff Garzik
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 \
    /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.