I don't know. That seemed to have changed the option from merely mystifying to down right confusing. By that wording, does that feature override it into being a plain IDE controller, or an IDE RAID controller? The new name seems to imply the former, while the mentions of ataraid suggest the latter.
Despite the grammatical errors, pdc202xx.c's comments perhaps describe it better.
* Linux kernel will misunderstand FastTrak ATA-RAID series as Ultra
* IDE Controller, UNLESS you enable "CONFIG_PDC202XX_FORCE"
* That's you can use FastTrak ATA-RAID controllers as IDE controllers.
If this is true, may I suggest something more along the lines of:
Ignore FastTrak BIOS and configure controller for RAID
CONFIG_PDC202XX_FORCE
Forces the driver to use the ATA-RAID capabilities, overriding the
BIOS configuration of the controller. Do not enable if you are
using Promise's binary module. This option is compatible with the
ataraid driver.
If the Linux driver has the same limitation in regards to using CD-ROM drives on the controller while it's in RAID mode as the Windows drivers do, it may be useful to mention the fact that the option is incompatible with CD-ROM drives attached to the controller.
Of course, maybe it means the complete opposite, and I'm reading everything wrong, in which case, there are some comments you may want to fix, too.
-----Original Message-----
From: Samuel Flory
Sent: July 10, 2003 4:11 PM
Subject: Re: IDE/Promise 20276 FastTrack RAID Doesn't work in 2.4.21,
patchattached to fix
Bartlomiej Zolnierkiewicz wrote:
>Hi,
>
>Do you have "Special FastTrak Feature" enabled?
Can we change the option to something that makes sense. I get the
feeling no one understands what it does at 1st glance. This is the 2nd
time I've seen a patch like this.
Chad Kitching wrote:
>I don't know. That seemed to have changed the option from merely mystifying to down right confusing. By that wording, does that feature override it into being a plain IDE controller, or an IDE RAID controller? The new name seems to imply the former, while the mentions of ataraid suggest the latter.
>
>Despite the grammatical errors, pdc202xx.c's comments perhaps describe it better.
>* Linux kernel will misunderstand FastTrak ATA-RAID series as Ultra
>* IDE Controller, UNLESS you enable "CONFIG_PDC202XX_FORCE"
>* That's you can use FastTrak ATA-RAID controllers as IDE controllers.
>
>
I stopped reading the comments as they made my brain hurt more than
reading the ide driver code;-)
>If this is true, may I suggest something more along the lines of:
>
>Ignore FastTrak BIOS and configure controller for RAID
>CONFIG_PDC202XX_FORCE
> Forces the driver to use the ATA-RAID capabilities, overriding the
> BIOS configuration of the controller. Do not enable if you are
> using Promise's binary module. This option is compatible with the
> ataraid driver.
>
This is completely wrong in my experience. In many configs linux's
ide driver will ignore the controller entirely without
CONFIG_PDC202XX_FORCE. In these cases you can't use the disk as either
ide disks, or ataraid disks. (Keep in mind you can access the raw disk
even if ataraid is loaded.) This seems to be true of the enbedded
promise controllers found on intel and tyan boards. A few newer intel
boards will allow you to toggle between ataraid, and ide modes in the
bios. In this case you don't need CONFIG_PDC202XX_FORCE to see the drives.
>
>If the Linux driver has the same limitation in regards to using CD-ROM drives on the controller while it's in RAID mode as the Windows drivers do, it may be useful to mention the fact that the option is incompatible with CD-ROM drives attached to the controller.
>
>Of course, maybe it means the complete opposite, and I'm reading everything wrong, in which case, there are some comments you may want to fix, too.
>
>-----Original Message-----
>From: Samuel Flory
>Sent: July 10, 2003 4:11 PM
>Subject: Re: IDE/Promise 20276 FastTrack RAID Doesn't work in 2.4.21,
>patchattached to fix
>
>
>Bartlomiej Zolnierkiewicz wrote:
>
>
>
>>Hi,
>>
>>Do you have "Special FastTrak Feature" enabled?
>>
>>
>
>Can we change the option to something that makes sense. I get the
>feeling no one understands what it does at 1st glance. This is the 2nd
>time I've seen a patch like this.
>
>
--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory <[email protected]>
Even with special fasttrack feature enabled, my disk devices on the
PDC20276 is not found. There is code in pci-setup.c which blocks other
PDC controllers, why not the 20276? Is that code for some other
purpose, or orthagonal to the force option?
Thanks
-steve
Samuel Flory wrote:
> Chad Kitching wrote:
>
>> I don't know. That seemed to have changed the option from merely
>> mystifying to down right confusing. By that wording, does that
>> feature override it into being a plain IDE controller, or an IDE RAID
>> controller? The new name seems to imply the former, while the
>> mentions of ataraid suggest the latter.
>>
>> Despite the grammatical errors, pdc202xx.c's comments perhaps
>> describe it better.
>> * Linux kernel will misunderstand FastTrak ATA-RAID series as Ultra
>> * IDE Controller, UNLESS you enable "CONFIG_PDC202XX_FORCE"
>> * That's you can use FastTrak ATA-RAID controllers as IDE controllers.
>>
>>
>
> I stopped reading the comments as they made my brain hurt more than
> reading the ide driver code;-)
>
>> If this is true, may I suggest something more along the lines of:
>>
>> Ignore FastTrak BIOS and configure controller for RAID
>> CONFIG_PDC202XX_FORCE
>> Forces the driver to use the ATA-RAID capabilities, overriding the
>> BIOS configuration of the controller. Do not enable if you are
>> using Promise's binary module. This option is compatible with the
>> ataraid driver.
>>
>
> This is completely wrong in my experience. In many configs linux's
> ide driver will ignore the controller entirely without
> CONFIG_PDC202XX_FORCE. In these cases you can't use the disk as
> either ide disks, or ataraid disks. (Keep in mind you can access the
> raw disk even if ataraid is loaded.) This seems to be true of the
> enbedded promise controllers found on intel and tyan boards. A few
> newer intel boards will allow you to toggle between ataraid, and ide
> modes in the bios. In this case you don't need CONFIG_PDC202XX_FORCE
> to see the drives.
>
>>
>> If the Linux driver has the same limitation in regards to using
>> CD-ROM drives on the controller while it's in RAID mode as the
>> Windows drivers do, it may be useful to mention the fact that the
>> option is incompatible with CD-ROM drives attached to the controller.
>>
>> Of course, maybe it means the complete opposite, and I'm reading
>> everything wrong, in which case, there are some comments you may want
>> to fix, too.
>>
>> -----Original Message-----
>> From: Samuel Flory
>> Sent: July 10, 2003 4:11 PM
>> Subject: Re: IDE/Promise 20276 FastTrack RAID Doesn't work in 2.4.21,
>> patchattached to fix
>>
>>
>> Bartlomiej Zolnierkiewicz wrote:
>>
>>
>>
>>> Hi,
>>>
>>> Do you have "Special FastTrak Feature" enabled?
>>>
>>
>>
>> Can we change the option to something that makes sense. I get the
>> feeling no one understands what it does at 1st glance. This is the
>> 2nd time I've seen a patch like this.
>>
>
>
On Thu, 10 Jul 2003, Chad Kitching wrote:
> I don't know. That seemed to have changed the option from merely
> mystifying to down right confusing. By that wording, does that feature
> override it into being a plain IDE controller, or an IDE RAID controller?
> The new name seems to imply the former, while the mentions
> of ataraid suggest the latter.
Hmmm... you are right. Comment is still misleading in respect to RAID.
ataraid driver is a _software_ RAID, just like Promise's binary driver.
FastTracks have software RAID. There are few true hardware FastTrak
RAID controllers with I2O interface but we probe for them properly in
pdc202xx_new.c driver and don't use IDE driver for them.
> Despite the grammatical errors, pdc202xx.c's comments perhaps describe it
> better.
> * Linux kernel will misunderstand FastTrak ATA-RAID series as Ultra
> * IDE Controller, UNLESS you enable "CONFIG_PDC202XX_FORCE"
> * That's you can use FastTrak ATA-RAID controllers as IDE controllers.
It is quite opposite.
> If this is true, may I suggest something more along the lines of:
>
> Ignore FastTrak BIOS and configure controller for RAID
> CONFIG_PDC202XX_FORCE
> Forces the driver to use the ATA-RAID capabilities, overriding the
> BIOS configuration of the controller. Do not enable if you are
> using Promise's binary module. This option is compatible with the
> ataraid driver.
What about this:
Ignore FastTrak BIOS
CONFIG_PDC202XX_FORCE
Forces the driver to use FastTrak controller even if it was disabled
by BIOS for Promise software RAID driver.
Say Y if you do not use Promise's software RAID or
if you want to use ataraid driver.
Say N if you want to use Promise's binary module.
> If the Linux driver has the same limitation in regards to using CD-ROM
> drives on the controller while it's in RAID mode as the Windows drivers
> do, it may be useful to mention the fact that the option is incompatible
> with CD-ROM drives attached to the controller.
It has. According to Andre it is doable but big pain,
also Promise gives docs under NDA which makes it even harder.
Please search lkml archive if you want know technical details.
> Of course, maybe it means the complete opposite, and I'm reading everything
> wrong, in which case, there are some comments you may want to fix, too.
Comments in Promise driver need fixing.
Thanks,
--
Bartlomiej
> -----Original Message-----
> From: Samuel Flory
> Sent: July 10, 2003 4:11 PM
> Subject: Re: IDE/Promise 20276 FastTrack RAID Doesn't work in 2.4.21,
> patchattached to fix
>
>
> Bartlomiej Zolnierkiewicz wrote:
>
> >Hi,
> >
> >Do you have "Special FastTrak Feature" enabled?
>
> Can we change the option to something that makes sense. I get the
> feeling no one understands what it does at 1st glance. This is the 2nd
> time I've seen a patch like this.
Steven Dake wrote:
> Even with special fasttrack feature enabled, my disk devices on the
> PDC20276 is not found. There is code in pci-setup.c which blocks
> other PDC controllers, why not the 20276? Is that code for some other
> purpose, or orthagonal to the force option?
The comments would seem to indicate that this is only needed if you
have a second controller. Which leads me to wonder what if I have 3 or
4 pdc controllers.
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;
--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory <[email protected]>
Bartlomiej Zolnierkiewicz wrote:
>On Thu, 10 Jul 2003, Chad Kitching wrote:
>
>
>
>>I don't know. That seemed to have changed the option from merely
>>mystifying to down right confusing. By that wording, does that feature
>>override it into being a plain IDE controller, or an IDE RAID controller?
>>The new name seems to imply the former, while the mentions
>>of ataraid suggest the latter.
>>
>>
>
>Hmmm... you are right. Comment is still misleading in respect to RAID.
>
>ataraid driver is a _software_ RAID, just like Promise's binary driver.
>
>FastTracks have software RAID. There are few true hardware FastTrak
>RAID controllers with I2O interface but we probe for them properly in
>pdc202xx_new.c driver and don't use IDE driver for them.
>
>
>
>>Despite the grammatical errors, pdc202xx.c's comments perhaps describe it
>>better.
>>* Linux kernel will misunderstand FastTrak ATA-RAID series as Ultra
>>* IDE Controller, UNLESS you enable "CONFIG_PDC202XX_FORCE"
>>* That's you can use FastTrak ATA-RAID controllers as IDE controllers.
>>
>>
>
>It is quite opposite.
>
>
>
>>If this is true, may I suggest something more along the lines of:
>>
>>Ignore FastTrak BIOS and configure controller for RAID
>>CONFIG_PDC202XX_FORCE
>> Forces the driver to use the ATA-RAID capabilities, overriding the
>> BIOS configuration of the controller. Do not enable if you are
>> using Promise's binary module. This option is compatible with the
>> ataraid driver.
>>
>>
>
>What about this:
>
Much better, but
>
>Ignore FastTrak BIOS
>CONFIG_PDC202XX_FORCE
> Forces the driver to use FastTrak controller even if it was disabled
> by BIOS for Promise software RAID driver.
>
This one might confuse people thinking we mean the ataraid driver, and
not the binary only driver.
Maybe:
Forces the driver to use FastTrak controller even if it was disabled
by BIOS for Promise's binary only software RAID driver.
>
> Say Y if you do not use Promise's software RAID or
> if you want to use ataraid driver.
>
>
> Say N if you want to use Promise's binary module.
>
>
>
>>If the Linux driver has the same limitation in regards to using CD-ROM
>>drives on the controller while it's in RAID mode as the Windows drivers
>>do, it may be useful to mention the fact that the option is incompatible
>>with CD-ROM drives attached to the controller.
>>
>>
>
>It has. According to Andre it is doable but big pain,
>also Promise gives docs under NDA which makes it even harder.
>
>Please search lkml archive if you want know technical details.
>
>
>
>>Of course, maybe it means the complete opposite, and I'm reading everything
>>wrong, in which case, there are some comments you may want to fix, too.
>>
>>
>
>Comments in Promise driver need fixing.
>
>
>
--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory <[email protected]>
It shouldn't matter.
Look at the code in setup-pci.c:
ide_pci_enablebit_t *e = &(d->enablebits[port]);
If CONFIG_PDC202XX_FORCE=y d->enablebits will be { 0x00, 0x00, 0x00 }
for both ports, now look at drivers/ide/setup-pci.c:
/*
* 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;
if (e->reg && (pci_read_config_byte(dev, e->reg, &tmp) ||
(tmp & e->mask) != e->val))
continue; /* port not enabled */
controller_ok:
So if e = { 0x00, 0x00, 0x00 } test above (for enabled port) should fail,
no need for your patch.
Can you put printks inside this code to see what are values
of e->reg, e->mask and e->val?
On Thu, 10 Jul 2003, Samuel Flory wrote:
> Steven Dake wrote:
>
> > Even with special fasttrack feature enabled, my disk devices on the
> > PDC20276 is not found. There is code in pci-setup.c which blocks
> > other PDC controllers, why not the 20276? Is that code for some other
> > purpose, or orthagonal to the force option?
>
> The comments would seem to indicate that this is only needed if you
> have a second controller. Which leads me to wonder what if I have 3 or
> 4 pdc controllers.
>
> 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 workaround was added before "Special FastTrack Feature"
option. Andre?
--
Bartlomiej
Samuel Flory wrote:
> Steven Dake wrote:
>
>> Even with special fasttrack feature enabled, my disk devices on the
>> PDC20276 is not found. There is code in pci-setup.c which blocks
>> other PDC controllers, why not the 20276? Is that code for some
>> other purpose, or orthagonal to the force option?
>
>
> The comments would seem to indicate that this is only needed if you
> have a second controller. Which leads me to wonder what if I have 3
> or 4 pdc controllers.
Hmm thats not how I read the code. My system has a standard IDE device
as part of the chipset, and then also has a fasttrack controller. The
fasttrack controller comes in 2nd, (hence making it the 2nd controller
and making it marked disabled). I think your right about the 3rd/4th
controller though, what happens to those !
-steve
>
> 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;
>
>
>
>
>
>
On Thu, 10 Jul 2003, Steven Dake wrote:
> Samuel Flory wrote:
>
> > Steven Dake wrote:
> >
> >> Even with special fasttrack feature enabled, my disk devices on the
> >> PDC20276 is not found. There is code in pci-setup.c which blocks
> >> other PDC controllers, why not the 20276? Is that code for some
> >> other purpose, or orthagonal to the force option?
> >
> >
> > The comments would seem to indicate that this is only needed if you
> > have a second controller. Which leads me to wonder what if I have 3
> > or 4 pdc controllers.
>
> Hmm thats not how I read the code. My system has a standard IDE device
Hmmm... read the code again :-).
> as part of the chipset, and then also has a fasttrack controller. The
> fasttrack controller comes in 2nd, (hence making it the 2nd controller
> and making it marked disabled). I think your right about the 3rd/4th
> controller though, what happens to those !
> -steve
>
> >
> > 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.
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?
--
Bartlomiej
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 <[email protected]>
Bartlomiej Zolnierkiewicz wrote:
>It shouldn't matter.
>
>Look at the code in setup-pci.c:
>
> ide_pci_enablebit_t *e = &(d->enablebits[port]);
>
>If CONFIG_PDC202XX_FORCE=y d->enablebits will be { 0x00, 0x00, 0x00 }
>for both ports, now look at drivers/ide/setup-pci.c:
>
> /*
> * 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;
>
> if (e->reg && (pci_read_config_byte(dev, e->reg, &tmp) ||
> (tmp & e->mask) != e->val))
> continue; /* port not enabled */
>
>controller_ok:
>
>So if e = { 0x00, 0x00, 0x00 } test above (for enabled port) should fail,
>no need for your patch.
>
>Can you put printks inside this code to see what are values
>of e->reg, e->mask and e->val?
>
>
Your right, I tried printks of those values, and they are all zero. Now
with fasttrack special feature enabled, my kernel boots without the PDC
patch I sent earlier. After I reconfigured the kernel in my previous
tests, the kernel build system must not have build the source files a new.
Thanks for all the help.
And atleast we got the help in the kernel config straightened out:)
-steve
>On Thu, 10 Jul 2003, Samuel Flory wrote:
>
>
>
>
>>Steven Dake wrote:
>>
>>
>>
>>>Even with special fasttrack feature enabled, my disk devices on the
>>>PDC20276 is not found. There is code in pci-setup.c which blocks
>>>other PDC controllers, why not the 20276? Is that code for some other
>>>purpose, or orthagonal to the force option?
>>>
>>>
>> The comments would seem to indicate that this is only needed if you
>>have a second controller. Which leads me to wonder what if I have 3 or
>>4 pdc controllers.
>>
>> 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 workaround was added before "Special FastTrack Feature"
>option. Andre?
>--
>Bartlomiej
>
>
>
>
>
>
On Thu, 10 Jul 2003, Samuel Flory wrote:
> 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
Steven, can you put printks for secondpdc and port into
ide_pci_setup_ports() and get some output for your patch
(without "Special FastTrak Feature")?
--
Bartlomiej
> begs the question why they didn't just test for an odd numbered channel.
Various people wrote:
> >>Ignore FastTrak BIOS and configure controller for RAID
> >>CONFIG_PDC202XX_FORCE
> >> Forces the driver to use the ATA-RAID capabilities, overriding the
> >> BIOS configuration of the controller. Do not enable if you are
> >> using Promise's binary module. This option is compatible with the
> >> ataraid driver.
> >What about this:
> Much better, but
> >Ignore FastTrak BIOS
> >CONFIG_PDC202XX_FORCE
> > Forces the driver to use FastTrak controller even if it was disabled
> > by BIOS for Promise software RAID driver.
> This one might confuse people thinking we mean the ataraid driver, and
> not the binary only driver.
My personal experience of the FastTrak device is that you must always "force"
it if you just want JBOD. [Note: I have never used a promise device as the
1st controller, because the Southbridge ide controller always comes in
first]. Now, I have never tried using ataraid or the promise bin-only driver,
so I guess there are occasions when not forcing is a good thing. I assume
from other comments that no-force is the right option for the Promise
binary-only driver?
I am much of the opinion that "CONFIG_PDC202XX_FORCE" should be a run-time
option so that it can be set up correctly for the user's machine even when
the kernel is a vendor one with pre-selected config choices. If this doesn't
happen, in some cases (e.g. installing a new kernel) the user's disks just
disappear and there isn't much you can do about it :-( See my comments at
the end of the mail for more on this.
> Maybe:
> Forces the driver to use FastTrak controller even if it was disabled
> by BIOS for Promise's binary only software RAID driver.
>
> > Say Y if you do not use Promise's software RAID or
> > if you want to use ataraid driver.
> >
> > Say N if you want to use Promise's binary module.
I don't like this one, as at least on first reading I completely misunderstood
it -- it seemed as if you only had RAID choices, no non-RAID ones. I see now
that Y gives you a (veiled) non-RAID choice. Is the following better?
Don't reserve the FastTrak controller for the Promise proprietary RAID driver.
Say Y if you:
- want to use attached disks quite independently;
- want to use attached disks in a Linux Software RAID (mdX) array;
- want to use attached disks with the Linux 'ataraid' driver. You must
also enable the option CONFIG_BLK_DEV_ATARAID_PDC.
Say N if you want to use Promise's proprietary, binary only, Software
RAID driver.
I think a better configuration setup than this would be a multiple- choice
arrangement that subsumes CONFIG_PDC202XX_FORCE, CONFIG_BLK_DEV_ATARAID_PDC
and CONFIG_PDC202XX_NEW option into one question, like this:
Configuration of the FastTrak IDE controller
CONFIG_PDC202XX_MODE
Please select the appropriate driver for this controller:
[ ] Promise proprietary, binary only, Software RAID driver
[ ] Linux GPL version of Promise Software RAID driver
[ ] Standard IDE driver, for disks that can be used quite independently
However, this still has the problem of what happens if you have multiple
controllers and wish to use them in 2 or more different configurations (e.g.
2 disks on 1st controller ataraid, 2 disks on another controller as JBOD).
Therefore, IMO the best setup would be to provide options that enable
possibilities (e.g enable you to use ataraid by compiling the code) but that
the actual use of the disks is defined in a module or command-line switch
(e.g. "pdc_ide2=ataraid,pdc_ide3=jbod"). In this case, we will keep the
CONFIG_BLK_DEV_ATARAID_PDC and CONFIG_PDC202XX_NEW options but they do not
imply a purpose: they just ensure that code is compiled. The option
CONFIG_PDC202XX_FORCE becomes a run-time only thing, and so disappears from
the config.
Should I think about coding this?
Regards,
Ruth
--
Engineer, Author and Webweaver
On Sat, 12 Jul 2003, Ruth Ivimey-Cook wrote:
> Various people wrote:
> > >>Ignore FastTrak BIOS and configure controller for RAID
> > >>CONFIG_PDC202XX_FORCE
> > >> Forces the driver to use the ATA-RAID capabilities, overriding the
> > >> BIOS configuration of the controller. Do not enable if you are
> > >> using Promise's binary module. This option is compatible with the
> > >> ataraid driver.
> > >What about this:
> > Much better, but
> > >Ignore FastTrak BIOS
> > >CONFIG_PDC202XX_FORCE
> > > Forces the driver to use FastTrak controller even if it was disabled
> > > by BIOS for Promise software RAID driver.
> > This one might confuse people thinking we mean the ataraid driver, and
> > not the binary only driver.
>
> My personal experience of the FastTrak device is that you must always "force"
> it if you just want JBOD. [Note: I have never used a promise device as the
> 1st controller, because the Southbridge ide controller always comes in
> first]. Now, I have never tried using ataraid or the promise bin-only driver,
> so I guess there are occasions when not forcing is a good thing. I assume
> from other comments that no-force is the right option for the Promise
> binary-only driver?
Yes.
> I am much of the opinion that "CONFIG_PDC202XX_FORCE" should be a run-time
> option so that it can be set up correctly for the user's machine even when
> the kernel is a vendor one with pre-selected config choices. If this doesn't
> happen, in some cases (e.g. installing a new kernel) the user's disks just
> disappear and there isn't much you can do about it :-( See my comments at
> the end of the mail for more on this.
Agreed.
> > Maybe:
> > Forces the driver to use FastTrak controller even if it was disabled
> > by BIOS for Promise's binary only software RAID driver.
> >
> > > Say Y if you do not use Promise's software RAID or
> > > if you want to use ataraid driver.
> > >
> > > Say N if you want to use Promise's binary module.
>
> I don't like this one, as at least on first reading I completely misunderstood
> it -- it seemed as if you only had RAID choices, no non-RAID ones. I see now
> that Y gives you a (veiled) non-RAID choice. Is the following better?
There is "or" not "and", but I see your point.
> Don't reserve the FastTrak controller for the Promise proprietary RAID driver.
> Say Y if you:
> - want to use attached disks quite independently;
> - want to use attached disks in a Linux Software RAID (mdX) array;
> - want to use attached disks with the Linux 'ataraid' driver. You must
> also enable the option CONFIG_BLK_DEV_ATARAID_PDC.
Better: no "Say Y" description et all :-).
> Say N if you want to use Promise's proprietary, binary only, Software
> RAID driver.
Above with "saying N will cause ide driver to skip Promise controllers"
should be sufficent.
> I think a better configuration setup than this would be a multiple- choice
> arrangement that subsumes CONFIG_PDC202XX_FORCE, CONFIG_BLK_DEV_ATARAID_PDC
> and CONFIG_PDC202XX_NEW option into one question, like this:
>
> Configuration of the FastTrak IDE controller
> CONFIG_PDC202XX_MODE
> Please select the appropriate driver for this controller:
> [ ] Promise proprietary, binary only, Software RAID driver
> [ ] Linux GPL version of Promise Software RAID driver
> [ ] Standard IDE driver, for disks that can be used quite independently
>
No way! This will make it even uglier.
Command line parameter is a superior solution.
> However, this still has the problem of what happens if you have multiple
> controllers and wish to use them in 2 or more different configurations (e.g.
> 2 disks on 1st controller ataraid, 2 disks on another controller as JBOD).
>
> Therefore, IMO the best setup would be to provide options that enable
> possibilities (e.g enable you to use ataraid by compiling the code) but that
> the actual use of the disks is defined in a module or command-line switch
> (e.g. "pdc_ide2=ataraid,pdc_ide3=jbod"). In this case, we will keep the
> CONFIG_BLK_DEV_ATARAID_PDC and CONFIG_PDC202XX_NEW options but they do not
> imply a purpose: they just ensure that code is compiled. The option
> CONFIG_PDC202XX_FORCE becomes a run-time only thing, and so disappears from
> the config.
I think you just need "pdc_ide=0,force" and "pdc_ide=0,noforce".
No need to complicate things.
Remember that ataraid is only software RAID driver and pdc202xx_new
is a chipset driver.
jbod/raid should be managed by ataraid driver not ide or pdc202xx_new.
And seriously, I don't care unless somebody ports ataraid to 2.5.
[ Hint, hint! ;-) ]
> Should I think about coding this?
No, think about porting ataraid and pdcraid to 2.5 first.
Regards,
--
Bartlomiej
> Regards,
>
> Ruth
>
> --
> Engineer, Author and Webweaver
On Saturday 12 Jul 2003 5:14 pm, Bartlomiej Zolnierkiewicz wrote:
> I think you just need "pdc_ide=0,force" and "pdc_ide=0,noforce".
> No need to complicate things.
> Remember that ataraid is only software RAID driver and pdc202xx_new
> is a chipset driver.
I am not forgetting, but I don't like this idea of 'force' -- it instantly
raises the question 'force what' and then you're in the quagmire again.
Better to tell the kernel what you want and let the kernel worry about how to
make it happen.
So the "pdc_ide2=jbod" would be scanned and interpreted as a request to
activate ('force') the drive into IDE mode and not enable any ataraid (jbod
==> just disks),
while "pdc_ide3=promise" would let the drive state be, and make the kernel do
a "modprobe promise-ft" (or whatever it's called) to load the rest of the
driver, as is done for 'scsi-hostadapter'. [Would you ever have to force a
promise chip into promise-raid mode?].
Do you see what I mean?
If you prefer, the string could be "pdc=ide2:ide, ide3:ataraid".
> jbod/raid should be managed by ataraid driver not ide or pdc202xx_new.
I was using jbod as just that, not as meaning raid-0 or similar. Perhaps I
should have been clearer. So you've a choice of (just IDE), (RAID via
ataraid) and (RAID via Promise)
> And seriously, I don't care unless somebody ports ataraid to 2.5.
> [ Hint, hint! ;-) ]
Hint understood and I'll look, but I'm no kernel guru.
> > Should I think about coding this?
>
> No, think about porting ataraid and pdcraid to 2.5 first.
pdcraid == ataraid module for PDC?? Haven't looked at the src yet.
Regards,
Ruth
--
Engineer, Author and Webweaver
Ruth Ivimey-Cook wrote:
>On Saturday 12 Jul 2003 5:14 pm, Bartlomiej Zolnierkiewicz wrote:
>
>
>>I think you just need "pdc_ide=0,force" and "pdc_ide=0,noforce".
>>No need to complicate things.
>>Remember that ataraid is only software RAID driver and pdc202xx_new
>>is a chipset driver.
>>
Doesn't the following already work "ide2=0 ide3=0 ...." for the
promise binary driver?
>
>I am not forgetting, but I don't like this idea of 'force' -- it instantly
>raises the question 'force what' and then you're in the quagmire again.
>
>Better to tell the kernel what you want and let the kernel worry about how to
>make it happen.
>
>So the "pdc_ide2=jbod" would be scanned and interpreted as a request to
>activate ('force') the drive into IDE mode and not enable any ataraid (jbod
>==> just disks),
>
>while "pdc_ide3=promise" would let the drive state be, and make the kernel do
>a "modprobe promise-ft" (or whatever it's called) to load the rest of the
>driver, as is done for 'scsi-hostadapter'. [Would you ever have to force a
>promise chip into promise-raid mode?].
>
This is getting really complex. Weren't we trying to make things
simple? The simple solution is to have the single option, and let user
space (initrd) determine if you want to load the pdcraid driver.
>
>Do you see what I mean?
>
>If you prefer, the string could be "pdc=ide2:ide, ide3:ataraid".
>
>
>
>>jbod/raid should be managed by ataraid driver not ide or pdc202xx_new.
>>
>>
>
>I was using jbod as just that, not as meaning raid-0 or similar. Perhaps I
>should have been clearer. So you've a choice of (just IDE), (RAID via
>ataraid) and (RAID via Promise)
>
>
>
No you really have only 2 options.
1)Let linux see the ide controller.
2)Don't then linux see the ide controller.
#1 Will only see ataraid partitions if there exists a promise raid
configuration, and the pdcraid driver is loaded.
>
>
>
>>>Should I think about coding this?
>>>
>>>
>>No, think about porting ataraid and pdcraid to 2.5 first.
>>
>>
>
>pdcraid == ataraid module for PDC?? Haven't looked at the src yet.
>
>
Yes unless you insert the pdcraid module. Linux will only see the raw
drives. Once you insert pdcraid you can see the raid devices, and raw
disks. Which can cause major issues at times.
--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory <[email protected]>
> Yes unless you insert the pdcraid module. Linux will only see the raw
> drives. Once you insert pdcraid you can see the raid devices, and raw
> disks. Which can cause major issues at times.
You need to be able to see both for some situations - eg maintainability