From: Samuel Flory <sflory@rackable.com>
To: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Steven Dake <sdake@mvista.com>,
Chad Kitching <CKitching@powerlandcomputers.com>,
linux-kernel@vger.kernel.org, andre@linux-ide.org
Subject: Re: IDE/Promise 20276 FastTrack RAID Doesn't work in 2.4.21, patchattached to fix
Date: Thu, 10 Jul 2003 16:54:46 -0700 [thread overview]
Message-ID: <3F0DFCC6.3000609@rackable.com> (raw)
In-Reply-To: <Pine.SOL.4.30.0307110132220.7938-100000@mion.elka.pw.edu.pl>
Bartlomiej Zolnierkiewicz wrote:
>
>>
>>
>>
>>> for (port = 0; port <= 1; ++port) {
>>> ide_pci_enablebit_t *e = &(d->enablebits[port]);
>>>
>>> /*
>>> * If this is a Promise FakeRaid controller,
>>> * the 2nd controller will be marked as
>>> * disabled while it is actually there and enabled
>>> * by the bios for raid purposes.
>>> * Skip the normal "is it enabled" test for those.
>>> */
>>> if (((d->vendor == PCI_VENDOR_ID_PROMISE) &&
>>> ((d->device == PCI_DEVICE_ID_PROMISE_20262) ||
>>> (d->device == PCI_DEVICE_ID_PROMISE_20265))) &&
>>> (secondpdc++==1) && (port==1))
>>> goto controller_ok;
>>>
>>>
>
>I think this test in reality does something different then comment states.
>
This seems to be a theme with the pdc comments in general.
>
>For first port of PDC20262/65 this test increases secondpdc variable
>(so it is 1 after test). For second port this test is true
>(its PDC20262/65 && secondpdc == 1 && port == 1) so we don't test whether
>2nd port (not controller!) of 1st controller is enabled.
>
>Or I am reading it wrong?
>
>
>
Don't look at me. I come to a different conclusion every time I read
it. Rereading it a couple of times would seem support your theroy.
Which makes me wonder why Steven's patch works at all. Unless for some
reason the second port needs to be enabled for things to work. Which
begs the question why they didn't just test for an odd numbered channel.
--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory <sflory@rackable.com>
next prev parent reply other threads:[~2003-07-10 23:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-10 22:05 IDE/Promise 20276 FastTrack RAID Doesn't work in 2.4.21, patchattached to fix Chad Kitching
2003-07-10 22:18 ` Samuel Flory
2003-07-10 22:29 ` Steven Dake
2003-07-10 22:51 ` Samuel Flory
2003-07-10 23:13 ` Bartlomiej Zolnierkiewicz
2003-07-10 23:57 ` Steven Dake
2003-07-10 23:24 ` Steven Dake
2003-07-10 23:43 ` Bartlomiej Zolnierkiewicz
2003-07-10 23:54 ` Samuel Flory [this message]
2003-07-11 0:18 ` Bartlomiej Zolnierkiewicz
2003-07-10 22:55 ` Bartlomiej Zolnierkiewicz
2003-07-10 23:04 ` Samuel Flory
2003-07-12 15:11 ` Ruth Ivimey-Cook
2003-07-12 16:14 ` Bartlomiej Zolnierkiewicz
2003-07-12 17:01 ` Ruth Ivimey-Cook
2003-07-14 17:31 ` Samuel Flory
2003-07-14 18:49 ` Alan Cox
2003-07-12 18:36 Bartlomiej Zolnierkiewicz
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=3F0DFCC6.3000609@rackable.com \
--to=sflory@rackable.com \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=CKitching@powerlandcomputers.com \
--cc=andre@linux-ide.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sdake@mvista.com \
/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).