Re: [PATCH] pdc20265 problem.

Re: [PATCH] pdc20265 problem.

[Bartlomiej Zolnierkiewicz]

> Just FYI,
>
> before these "#ifdef" fixes it was treated as OFF_BOARD unless
> CONFIG_PDC202XX_FORCE is set. (now it's inverted)

This should be fixed.

>
> And my point is that it does not matter how physically this controller
> installed - onboard or offboard. Idea is that we should have control

It is not on/offboard case. It is primary/secondary boot device case.

> which controller should be treated as "primary" (ide0/1) and which as
> "secondary" (ide2/3). I don't see/know how we can do it unless we mark
> one of controllers ON_BOARD and another OFF_BOARD and play with
> CONFIG_BLK_DEV_OFFBOARD.

Yes.

> And also I don't believe that this is good idea to treat one of Promises
> so differently.

Once again - on some machines it is primary IDE (booting one), so we have
to give user possibility for 'onboarding' it. However it should depend on
CONFIG_PDC202XX_FORCE... hmm... but on others it is offboard so distro
compiled kernels might have problem here :\.

Regards
--
Bartlomiej

Re: [PATCH] pdc20265 problem.

[Marcelo Tosatti]

On Fri, 2 Aug 2002, Bartlomiej Zolnierkiewicz wrote:

>
> > Just FYI,
> >
> > before these "#ifdef" fixes it was treated as OFF_BOARD unless
> > CONFIG_PDC202XX_FORCE is set. (now it's inverted)
>
> This should be fixed.

If we change the #ifdef on ide-pci.c it will skip some controllers which
worked before _without_ CONFIG_PDC202XX_FORCE set.

Re: [PATCH] pdc20265 problem.

[Bartlomiej Zolnierkiewicz]

On Fri, 2 Aug 2002, Marcelo Tosatti wrote:
> On Fri, 2 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
> > > Just FYI,
> > >
> > > before these "#ifdef" fixes it was treated as OFF_BOARD unless
> > > CONFIG_PDC202XX_FORCE is set. (now it's inverted)
> >
> > This should be fixed.
>
> If we change the #ifdef on ide-pci.c it will skip some controllers which
> worked before _without_ CONFIG_PDC202XX_FORCE set.

I was thinking about changing it globally to do what its name suggest.

Main problem is that before introducing skipping Promises, FORCE
controlled overriding BIOS only (?) and now it is also used to control
'skipping'. (FORCE should be by default on of course)
Probably 'skipping' should be separated to another config option...

And second problem is that 20265 is used as primary onboard
sometimes and sometimes as offboard (another config option?).


Regards
--
puzzled Bartlomiej

Re: [PATCH] pdc20265 problem.

[Marcelo Tosatti]

On Sat, 3 Aug 2002, Bartlomiej Zolnierkiewicz wrote:

>
> On Fri, 2 Aug 2002, Marcelo Tosatti wrote:
> > On Fri, 2 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
> > > > Just FYI,
> > > >
> > > > before these "#ifdef" fixes it was treated as OFF_BOARD unless
> > > > CONFIG_PDC202XX_FORCE is set. (now it's inverted)
> > >
> > > This should be fixed.
> >
> > If we change the #ifdef on ide-pci.c it will skip some controllers which
> > worked before _without_ CONFIG_PDC202XX_FORCE set.
>
> I was thinking about changing it globally to do what its name suggest.
>
> Main problem is that before introducing skipping Promises, FORCE
> controlled overriding BIOS only (?) and now it is also used to control
> 'skipping'. (FORCE should be by default on of course)
> Probably 'skipping' should be separated to another config option...

Indeed. I appreciate patches ;)

>
> And second problem is that 20265 is used as primary onboard
> sometimes and sometimes as offboard (another config option?).

[PATCH] Re: [PATCH] pdc20265 problem.

[Nick Orlov]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

On Fri, Aug 02, 2002 at 09:08:15PM -0300, Marcelo Tosatti wrote:
> 
> 
> On Sat, 3 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
> 
> >
> > On Fri, 2 Aug 2002, Marcelo Tosatti wrote:
> > > On Fri, 2 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
> > > > > Just FYI,
> > > > >
> > > > > before these "#ifdef" fixes it was treated as OFF_BOARD unless
> > > > > CONFIG_PDC202XX_FORCE is set. (now it's inverted)
> > > >
> > > > This should be fixed.
> > >
> > > If we change the #ifdef on ide-pci.c it will skip some controllers which
> > > worked before _without_ CONFIG_PDC202XX_FORCE set.
> >
> > I was thinking about changing it globally to do what its name suggest.
> >
> > Main problem is that before introducing skipping Promises, FORCE
> > controlled overriding BIOS only (?) and now it is also used to control
> > 'skipping'. (FORCE should be by default on of course)
> > Probably 'skipping' should be separated to another config option...
> 
> Indeed. I appreciate patches ;)
> 

New config option added (CONFIG_PDC20265_ONBOARD).
Comments / suggestions highly appreciated :)

-- 
With best wishes,
	Nick Orlov.


[-- Attachment #2: pdc.patch --]
[-- Type: text/plain, Size: 3730 bytes --]

--- linux/Documentation/Configure.help.orig	2002-08-03 11:26:50.000000000 -0400
+++ linux/Documentation/Configure.help	2002-08-03 11:23:39.000000000 -0400
@@ -1193,6 +1193,13 @@
 
   If unsure, say N.
 
+Promise 20265 is on-board
+CONFIG_PDC20265_ONBOARD
+  Say Y here if you have motherboard with Promise 20265 primary IDE
+  controller.
+
+  Otherwise, say N.
+
 Special UDMA Feature
 CONFIG_PDC202XX_BURST
   This option causes the pdc202xx driver to enable UDMA modes on the
--- linux/drivers/ide/Config.in.orig	2002-08-03 11:27:25.000000000 -0400
+++ linux/drivers/ide/Config.in	2002-08-03 10:49:26.000000000 -0400
@@ -84,6 +84,7 @@
 	    dep_bool '    OPTi 82C621 chipset enhanced support (EXPERIMENTAL)' CONFIG_BLK_DEV_OPTI621 $CONFIG_EXPERIMENTAL
 #	    dep_mbool '   Pacific Digital A-DMA support (EXPERIMENTAL)' CONFIG_BLK_DEV_PDC_ADMA $CONFIG_BLK_DEV_ADMA $CONFIG_IDEDMA_PCI_WIP $CONFIG_EXPERIMENTAL
 	    dep_bool '    PROMISE PDC202{46|62|65|67|68|69|70} support' CONFIG_BLK_DEV_PDC202XX $CONFIG_BLK_DEV_IDEDMA_PCI
+	    dep_bool '      Promise 20265 is on-board' CONFIG_PDC20265_ONBOARD $CONFIG_BLK_DEV_PDC202XX
 	    dep_bool '      Special UDMA Feature' CONFIG_PDC202XX_BURST $CONFIG_BLK_DEV_PDC202XX
 	    dep_bool '      Special FastTrak Feature' CONFIG_PDC202XX_FORCE $CONFIG_BLK_DEV_PDC202XX
 	    dep_bool '    ServerWorks OSB4/CSB5 chipsets support' CONFIG_BLK_DEV_SVWKS $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
--- linux/drivers/ide/ide-pci.c.orig	2002-08-03 11:27:43.000000000 -0400
+++ linux/drivers/ide/ide-pci.c	2002-08-03 10:59:45.000000000 -0400
@@ -382,6 +382,12 @@
 	unsigned int		extra;
 } ide_pci_device_t;
 
+#ifdef CONFIG_PDC20265_ONBOARD
+# define PDC20265_BOARD ON_BOARD
+#else /* !CONFIG_PDC20265_ONBOARD */
+# define PDC20265_BOARD OFF_BOARD
+#endif /* CONFIG_PDC20265_ONBOARD */
+
 static ide_pci_device_t ide_pci_chipsets[] __initdata = {
 	{DEVID_PIIXa,	"PIIX",		NULL,		NULL,		INIT_PIIX,	NULL,		{{0x41,0x80,0x80}, {0x43,0x80,0x80}}, 	ON_BOARD,	0 },
 	{DEVID_PIIXb,	"PIIX",		NULL,		NULL,		INIT_PIIX,	NULL,		{{0x41,0x80,0x80}, {0x43,0x80,0x80}}, 	ON_BOARD,	0 },
@@ -405,12 +411,12 @@
 #ifndef CONFIG_PDC202XX_FORCE
         {DEVID_PDC20246,"PDC20246",	PCI_PDC202XX,	NULL,		INIT_PDC202XX,	NULL,		{{0x00,0x00,0x00}, {0x00,0x00,0x00}},	OFF_BOARD,	16 },
         {DEVID_PDC20262,"PDC20262",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x00,0x00,0x00}, {0x00,0x00,0x00}},	OFF_BOARD,	48 },
-        {DEVID_PDC20265,"PDC20265",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x00,0x00,0x00}, {0x00,0x00,0x00}},	ON_BOARD,	48 },
+        {DEVID_PDC20265,"PDC20265",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x00,0x00,0x00}, {0x00,0x00,0x00}},	PDC20265_BOARD,	48 },
         {DEVID_PDC20267,"PDC20267",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x00,0x00,0x00}, {0x00,0x00,0x00}},	OFF_BOARD,	48 },
 #else /* !CONFIG_PDC202XX_FORCE */
 	{DEVID_PDC20246,"PDC20246",	PCI_PDC202XX,	NULL,		INIT_PDC202XX,	NULL,		{{0x50,0x02,0x02}, {0x50,0x04,0x04}}, 	OFF_BOARD,	16 },
 	{DEVID_PDC20262,"PDC20262",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x50,0x02,0x02}, {0x50,0x04,0x04}},	OFF_BOARD,	48 },
-	{DEVID_PDC20265,"PDC20265",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x50,0x02,0x02}, {0x50,0x04,0x04}},	OFF_BOARD,	48 },
+	{DEVID_PDC20265,"PDC20265",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x50,0x02,0x02}, {0x50,0x04,0x04}},	PDC20265_BOARD,	48 },
 	{DEVID_PDC20267,"PDC20267",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x50,0x02,0x02}, {0x50,0x04,0x04}},	OFF_BOARD,	48 },
 #endif
 	{DEVID_PDC20268,"PDC20268",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x00,0x00,0x00}, {0x00,0x00,0x00}},	OFF_BOARD,	0 },

[PATCH] Re: [PATCH] pdc20265 problem.

[Nick Orlov]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

On Sat, Aug 03, 2002 at 11:37:34AM -0400, Nick Orlov wrote:
> 
> New config option added (CONFIG_PDC20265_ONBOARD).
> Comments / suggestions highly appreciated :)
> 

Slightly changed according to Bartlomiej's comments patch attached.

-- 
With best wishes,
	Nick Orlov.


[-- Attachment #2: pdc.patch --]
[-- Type: text/plain, Size: 3408 bytes --]

--- linux/Documentation/Configure.help.orig	2002-08-03 11:26:50.000000000 -0400
+++ linux/Documentation/Configure.help	2002-08-03 11:23:39.000000000 -0400
@@ -1193,6 +1193,13 @@
 
   If unsure, say N.
 
+Promise 20265 is on-board
+CONFIG_PDC20265_ONBOARD
+  Say Y here if you have motherboard with Promise 20265 primary IDE
+  controller.
+
+  Otherwise, say N.
+
 Special UDMA Feature
 CONFIG_PDC202XX_BURST
   This option causes the pdc202xx driver to enable UDMA modes on the
--- linux/drivers/ide/Config.in.orig	2002-08-03 11:27:25.000000000 -0400
+++ linux/drivers/ide/Config.in	2002-08-03 10:49:26.000000000 -0400
@@ -84,6 +84,7 @@
 	    dep_bool '    OPTi 82C621 chipset enhanced support (EXPERIMENTAL)' CONFIG_BLK_DEV_OPTI621 $CONFIG_EXPERIMENTAL
 #	    dep_mbool '   Pacific Digital A-DMA support (EXPERIMENTAL)' CONFIG_BLK_DEV_PDC_ADMA $CONFIG_BLK_DEV_ADMA $CONFIG_IDEDMA_PCI_WIP $CONFIG_EXPERIMENTAL
 	    dep_bool '    PROMISE PDC202{46|62|65|67|68|69|70} support' CONFIG_BLK_DEV_PDC202XX $CONFIG_BLK_DEV_IDEDMA_PCI
+	    dep_bool '      Promise 20265 is on-board' CONFIG_PDC20265_ONBOARD $CONFIG_BLK_DEV_PDC202XX
 	    dep_bool '      Special UDMA Feature' CONFIG_PDC202XX_BURST $CONFIG_BLK_DEV_PDC202XX
 	    dep_bool '      Special FastTrak Feature' CONFIG_PDC202XX_FORCE $CONFIG_BLK_DEV_PDC202XX
 	    dep_bool '    ServerWorks OSB4/CSB5 chipsets support' CONFIG_BLK_DEV_SVWKS $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
--- linux/drivers/ide/ide-pci.c.orig	2002-08-03 11:27:43.000000000 -0400
+++ linux/drivers/ide/ide-pci.c	2002-08-03 14:05:55.000000000 -0400
@@ -405,12 +405,20 @@
 #ifndef CONFIG_PDC202XX_FORCE
         {DEVID_PDC20246,"PDC20246",	PCI_PDC202XX,	NULL,		INIT_PDC202XX,	NULL,		{{0x00,0x00,0x00}, {0x00,0x00,0x00}},	OFF_BOARD,	16 },
         {DEVID_PDC20262,"PDC20262",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x00,0x00,0x00}, {0x00,0x00,0x00}},	OFF_BOARD,	48 },
+#ifdef CONFIG_PDC20265_ONBOARD
         {DEVID_PDC20265,"PDC20265",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x00,0x00,0x00}, {0x00,0x00,0x00}},	ON_BOARD,	48 },
+#else /* !CONFIG_PDC20265_ONBOARD */
+        {DEVID_PDC20265,"PDC20265",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x00,0x00,0x00}, {0x00,0x00,0x00}},	OFF_BOARD,	48 },
+#endif /* CONFIG_PDC20265_ONBOARD */
         {DEVID_PDC20267,"PDC20267",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x00,0x00,0x00}, {0x00,0x00,0x00}},	OFF_BOARD,	48 },
 #else /* !CONFIG_PDC202XX_FORCE */
 	{DEVID_PDC20246,"PDC20246",	PCI_PDC202XX,	NULL,		INIT_PDC202XX,	NULL,		{{0x50,0x02,0x02}, {0x50,0x04,0x04}}, 	OFF_BOARD,	16 },
 	{DEVID_PDC20262,"PDC20262",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x50,0x02,0x02}, {0x50,0x04,0x04}},	OFF_BOARD,	48 },
+#ifdef CONFIG_PDC20265_ONBOARD
+	{DEVID_PDC20265,"PDC20265",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x50,0x02,0x02}, {0x50,0x04,0x04}},	ON_BOARD,	48 },
+#else /* !CONFIG_PDC20265_ONBOARD */
 	{DEVID_PDC20265,"PDC20265",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x50,0x02,0x02}, {0x50,0x04,0x04}},	OFF_BOARD,	48 },
+#endif /* CONFIG_PDC20265_ONBOARD */
 	{DEVID_PDC20267,"PDC20267",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x50,0x02,0x02}, {0x50,0x04,0x04}},	OFF_BOARD,	48 },
 #endif
 	{DEVID_PDC20268,"PDC20268",	PCI_PDC202XX,	ATA66_PDC202XX,	INIT_PDC202XX,	NULL,		{{0x00,0x00,0x00}, {0x00,0x00,0x00}},	OFF_BOARD,	0 },

Re: [PATCH] pdc20265 problem.

[Nick Orlov]

On Sat, Aug 03, 2002 at 02:55:21AM +0200, Bartlomiej Zolnierkiewicz wrote:
> 
> On Fri, 2 Aug 2002, Marcelo Tosatti wrote:
> > On Fri, 2 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
> > > > Just FYI,
> > > >
> > > > before these "#ifdef" fixes it was treated as OFF_BOARD unless
> > > > CONFIG_PDC202XX_FORCE is set. (now it's inverted)
> > >
> > > This should be fixed.
> >
> > If we change the #ifdef on ide-pci.c it will skip some controllers which
> > worked before _without_ CONFIG_PDC202XX_FORCE set.
> 
> I was thinking about changing it globally to do what its name suggest.
> 
> Main problem is that before introducing skipping Promises, FORCE
> controlled overriding BIOS only (?) and now it is also used to control
> 'skipping'. (FORCE should be by default on of course)
> Probably 'skipping' should be separated to another config option...
> 
> And second problem is that 20265 is used as primary onboard
> sometimes and sometimes as offboard (another config option?).
> 

I think that question is _how often_ pdc20265 is used as primary
controller? Actually I know a lot of mobos with pdc20265 as additional
controller (and I don't see the one that uses it as primary). 

Don't forget about "ide=reverse" parameter that allows you to treat
pdc20265 as primary if by default kernel treat pdc20265 as secondary.

So I don't see _any_ reason to force pdc20265 to be primary (onboard)
unless CONFIG_PDC202XX_FORCE is set.

-- 
With best wishes,
	Nick Orlov.

Re: [PATCH] pdc20265 problem.

[Alan Cox]

On Sat, 2002-08-03 at 02:22, Nick Orlov wrote:
> I think that question is _how often_ pdc20265 is used as primary
> controller? Actually I know a lot of mobos with pdc20265 as additional
> controller (and I don't see the one that uses it as primary). 
> 
> Don't forget about "ide=reverse" parameter that allows you to treat
> pdc20265 as primary if by default kernel treat pdc20265 as secondary.
> 
> So I don't see _any_ reason to force pdc20265 to be primary (onboard)
> unless CONFIG_PDC202XX_FORCE is set.

This is the wrong question.

The right question for a stable kernel is "Why isnt it behaving
precisely the same way as it did before the merge". What got confused in
the _FORCE stuff. Why did _FORCE checks even get into the raid probe not
another config option...

Re: [PATCH] pdc20265 problem.

[Bill Davidsen]

On Sat, 3 Aug 2002, Bartlomiej Zolnierkiewicz wrote:

> And second problem is that 20265 is used as primary onboard
> sometimes and sometimes as offboard (another config option?).

Can that not be configured at boot time with ide0=xxx or similar? I'm
clearly missing why it would matter on or off board as long as the
controller(s) were checked in the right order.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [PATCH] pdc20265 problem.

[Nick Orlov]

On Mon, Aug 05, 2002 at 11:48:47PM -0400, Bill Davidsen wrote:
> On Sat, 3 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
> 
> > And second problem is that 20265 is used as primary onboard
> > sometimes and sometimes as offboard (another config option?).
> 
> Can that not be configured at boot time with ide0=xxx or similar? I'm
> clearly missing why it would matter on or off board as long as the
> controller(s) were checked in the right order.
> 

I'm not expert in this field, but my current understanding is:

1. ide0/1 reserved for onboard controllers.
2. on most hardware, pdc20xxx is really additional controller.
3. if we put pdc20265 in "onboard" list on some hardware (mine for example)
pdc20265 is assigned to ide0/1 (even if it's really ide2/3)
4. ide0=<what> ??? (do we have this option?)

Correct me, if I'm wrong.

-- 
With best wishes,
	Nick Orlov.

Re: [PATCH] pdc20265 problem.

[Bill Davidsen]

On Tue, 6 Aug 2002, Nick Orlov wrote:

> 1. ide0/1 reserved for onboard controllers.

Not sure about that, I've run 2.4.x (ie. x<10} on machines so old that
they had no onboard anything, and were using "VESA bus" ide controllers. I
think they were ide0/1.

> 2. on most hardware, pdc20xxx is really additional controller.

That's the problem, most not all. No matter what we assume it will be
wrong part of the time.

> 3. if we put pdc20265 in "onboard" list on some hardware (mine for example)
> pdc20265 is assigned to ide0/1 (even if it's really ide2/3)

Does this matter as long as we can force it to be where we want? 

> 4. ide0=<what> ??? (do we have this option?)

I made that up, I believe we do/did if my memory isn't totally kidding me.
 
> Correct me, if I'm wrong.

This is lkml, count on it. Sometimes they correct you if you're right ;-)

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [PATCH] pdc20265 problem.

[Nick Orlov]

On Tue, Aug 06, 2002 at 11:09:14PM -0400, Bill Davidsen wrote:
> 
> > 2. on most hardware, pdc20xxx is really additional controller.
> 
> That's the problem, most not all. No matter what we assume it will be
> wrong part of the time.

Agreed.

> 
> > 3. if we put pdc20265 in "onboard" list on some hardware (mine for example)
> > pdc20265 is assigned to ide0/1 (even if it's really ide2/3)
> 
> Does this matter as long as we can force it to be where we want? 

But wouldn't it be a cleaner solution if we will have _compile_ time
option that by default is turned on in order to handle rare cases,
and _can_ be turned off in order to handle _most_ cases without any
boot-time options?


-- 
With best wishes,
	Nick Orlov.

Re: [PATCH] pdc20265 problem.

[Andre Hedrick]

Marcelo,

Well here is the long a waited "I Told You So, but You Would Not Listen".

It worked just fine until you all decided to let an OEM get in the game
and dictate the changes.  Back out the cruft and return sanity to an
insane world.  Just because and OEM makes hardware does not mean they can
make it run proper.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Tue, 6 Aug 2002, Nick Orlov wrote:

> On Tue, Aug 06, 2002 at 11:09:14PM -0400, Bill Davidsen wrote:
> > 
> > > 2. on most hardware, pdc20xxx is really additional controller.
> > 
> > That's the problem, most not all. No matter what we assume it will be
> > wrong part of the time.
> 
> Agreed.
> 
> > 
> > > 3. if we put pdc20265 in "onboard" list on some hardware (mine for example)
> > > pdc20265 is assigned to ide0/1 (even if it's really ide2/3)
> > 
> > Does this matter as long as we can force it to be where we want? 
> 
> But wouldn't it be a cleaner solution if we will have _compile_ time
> option that by default is turned on in order to handle rare cases,
> and _can_ be turned off in order to handle _most_ cases without any
> boot-time options?
> 
> 
> -- 
> With best wishes,
> 	Nick Orlov.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [PATCH] pdc20265 problem.

[Tomas Szepe]

> It worked just fine until you all decided to let an OEM get in the game
> and dictate the changes.  Back out the cruft and return sanity to an
> insane world.  Just because and OEM makes hardware does not mean they can
> make it run proper.

Btw, Andre, I have this system with an extra PDC20268 controller that
I can't get to work in UDMA >2, *but only* until I actually I force it
to using "ide2=ata66 ide3=ata66". You wouldn't happen to have an idea
as to what could be the cause here, would you?

This applies for all the recent 2.4 kernels that I've tested, both
vanilla and -ac.

A comment in ide.c reads:

 * Added idex=ata66 for the quirky chipsets that are
 * ATA-66 compliant, but have yet to determine a method
 * of verification of the 80c cable presence.
 * Specifically Promise's PDC20262 chipset.

i.e. it talks of a chipset different from what I have here.
All right. Supposing CONFIG_BLK_DEV_IDEPCI=y and "idex=ata66"
hasn't been specified as a boot option, the value of
hwif->udma_four remains unset during setup and is to
be determined later:

	if (hwif->udma_four) {
		printk("%s: ATA-66/100 forced bit set (WARNING)!!\n", d->name);
	} else {
		hwif->udma_four = (d->ata66_check) ? d->ata66_check(hwif) : 0;
	}

If I parse this right, then if a function has been defined that can find
out about the chipset's ability to support DMA4+, it's called to do its
job, otherwise we assume UDMA4+ can't be had. This narrows my problem down
to: 1) either this cunning function doesn't exist for PDC20268, or 2) for
some weird reason it exists but is not nearly as cunning, because it doesn't
know it should be returning a nice "one" for my controller.

Trouble is, I have failed to find where the value of ata66_check in struct
ide_pci_device_s is assigned for the controller so I couldn't go on tracking
the problem. The code is sooooo beautifully messy. <g>

T.

ide_setup: ide2=ata66
ide_setup: ide3=ata66
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX3: IDE controller on PCI bus 00 dev 21
PCI: Enabling device 00:04.1 (0000 -> 0001)
PIIX3: chipset revision 0
PIIX3: not 100% native mode: will probe irqs later
PIIX3: neither IDE port enabled (BIOS)
PDC20268: IDE controller on PCI bus 00 dev 30
PDC20268: chipset revision 2
PDC20268: not 100% native mode: will probe irqs later
PDC20268: ATA-66/100 forced bit set (WARNING)!!
    ide2: BM-DMA at 0xf8b0-0xf8b7, BIOS settings: hde:pio, hdf:pio
PDC20268: ATA-66/100 forced bit set (WARNING)!!
    ide3: BM-DMA at 0xf8b8-0xf8bf, BIOS settings: hdg:pio, hdh:pio
hde: WDC WD205BA, ATA DISK drive
hdg: IBM-DJNA-351520, ATA DISK drive
ide2 at 0xf898-0xf89f,0xf8aa on irq 9
ide3 at 0xf8a0-0xf8a7,0xf8ae on irq 9
hde: host protected area => 1
hde: 40088160 sectors (20525 MB) w/2048KiB Cache, CHS=39770/16/63, UDMA(66)
hdg: host protected area => 1
hdg: 30033360 sectors (15377 MB) w/430KiB Cache, CHS=29795/16/63, UDMA(33)

00:06.0 Unknown mass storage controller: Promise Technology, Inc. 20268 (rev 02) (prog-if 85)
        Subsystem: Promise Technology, Inc. Ultra100TX2
        Flags: bus master, 66Mhz, slow devsel, latency 64, IRQ 9
        I/O ports at f898 [size=8]
        I/O ports at f8a8 [size=4]
        I/O ports at f8a0 [size=8]
        I/O ports at f8ac [size=4]
        I/O ports at f8b0 [size=16]
        Memory at fedfc000 (32-bit, non-prefetchable) [size=16K]
        Expansion ROM at <unassigned> [disabled] [size=16K]
        Capabilities: [60] Power Management version 1

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=m

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=m

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=m
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_IDEDISK_STROKE is not set
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
# CONFIG_BLK_DEV_IDEDISK_IBM is not set
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
# CONFIG_BLK_DEV_IDEDISK_WD is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_TIVO is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_TASKFILE_IO=y

# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_BLK_DEV_IDEDMA_TIMEOUT is not set
# CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_AEC62XX_TUNING is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_AMD74XX_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_CMD680 is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_ADMA100 is not set
CONFIG_BLK_DEV_PDC202XX=y
CONFIG_PDC202XX_BURST=y
# CONFIG_PDC202XX_FORCE is not set
# CONFIG_BLK_DEV_RZ1000 is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y
# CONFIG_BLK_DEV_ATARAID is not set
# CONFIG_BLK_DEV_ATARAID_PDC is not set
# CONFIG_BLK_DEV_ATARAID_HPT is not set

Re: [PATCH] pdc20265 problem.

[Bill Davidsen]

On Tue, 6 Aug 2002, Nick Orlov wrote:

> On Tue, Aug 06, 2002 at 11:09:14PM -0400, Bill Davidsen wrote:

> > > 3. if we put pdc20265 in "onboard" list on some hardware (mine for example)
> > > pdc20265 is assigned to ide0/1 (even if it's really ide2/3)
> > 
> > Does this matter as long as we can force it to be where we want? 
> 
> But wouldn't it be a cleaner solution if we will have _compile_ time
> option that by default is turned on in order to handle rare cases,
> and _can_ be turned off in order to handle _most_ cases without any
> boot-time options?

Nick, I think that's a matter of taste. I am perfectly happy to default to
using the ideN based on the io address, or any other determanent method,
as long as it's reasonable to have the user specify the order if s/he has
a reason to do so. Of course some BIOS will mess up io addresses at some
time, crappy {hard,firm}ware is a problem in any case.

I would just as soon use a boot option as to try and make it a compile
option, and I think that many people just use a compiled kernel and never
change, which argues for a reasonable default (most pdc20265) ARE
currently offboard, and an easy way to change it.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [PATCH] pdc20265 problem.

[Andre Hedrick]

On Wed, 7 Aug 2002, Bill Davidsen wrote:

> I would just as soon use a boot option as to try and make it a compile
> option, and I think that many people just use a compiled kernel and never
> change, which argues for a reasonable default (most pdc20265) ARE
> currently offboard, and an easy way to change it.

There are ZERO pdc20265's offboard, only pdc20267's were in both options.
This is the direct asic packaging.  Thus all pdc20265 have the right to be
listed as onboard.  If you have a pdc20265 on an add-on card please send
me a digital photo so I can question promise as to why.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: [PATCH] pdc20265 problem.

[Nick Orlov]

On Thu, Aug 08, 2002 at 03:50:19AM -0700, Andre Hedrick wrote:
> On Wed, 7 Aug 2002, Bill Davidsen wrote:
> 
> > I would just as soon use a boot option as to try and make it a compile
> > option, and I think that many people just use a compiled kernel and never
> > change, which argues for a reasonable default (most pdc20265) ARE
> > currently offboard, and an easy way to change it.
> 
> There are ZERO pdc20265's offboard, only pdc20267's were in both options.
> This is the direct asic packaging.  Thus all pdc20265 have the right to be
> listed as onboard.

Could you comment next couple lines of code (2.4.19-vanilla):

==========================================
#else /* !CONFIG_PDC202XX_FORCE */
[ ... skipped ... ]
        {DEVID_PDC20265,"PDC20265" .... OFF_BOARD ..... },
                                        ^^^^^^^^^
[ ... skipped ... ]
#endif
==========================================

Another bug? Just typo?
Why author put PDC20265 in off-board list ?

> Cheers,
> 
> Andre Hedrick
> LAD Storage Consulting Group
> 

-- 
With best wishes,
        Nick Orlov.

Re: [PATCH] pdc20265 problem.

[Andre Hedrick]

Because I can not get a FSCKING PATCH past any of the Lead Penquins.

/src/linux-2.5.4-pristine/drivers/ide/ide-pci.c
#ifdef CONFIG_PDC202XX_FORCE
        {DEVID_PDC20265,"PDC20265",     PCI_PDC202XX,   ATA66_PDC202XX,
INIT_PDC202XX,  NULL,           {{0x00,0x00,0x00}, {0x00,0x00,0x00}},
ON_BOARD,
48 },
#else /* !CONFIG_PDC202XX_FORCE */
        {DEVID_PDC20265,"PDC20265",     PCI_PDC202XX,   ATA66_PDC202XX,
INIT_PDC202XX,  NULL,           {{0x50,0x02,0x02}, {0x50,0x04,0x04}},
OFF_BOARD,
48 },
#endif

But since there is the option to compile off-board as bootable, it is a
noop.  I have not been able to directly add code or update any kernel
first hand since the change in 2.5.3 and my exit of Linux Development at
2.5.5.  So I really don't give a damn.

But what I do know is people bug me for patches and updates and ask me to
fix 2.5.XX on a regular bases.  Nobody takes my patches but man when crap
hits the fan they come running for me to put it right again.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Thu, 8 Aug 2002, Nick Orlov wrote:

> On Thu, Aug 08, 2002 at 03:50:19AM -0700, Andre Hedrick wrote:
> > On Wed, 7 Aug 2002, Bill Davidsen wrote:
> > 
> > > I would just as soon use a boot option as to try and make it a compile
> > > option, and I think that many people just use a compiled kernel and never
> > > change, which argues for a reasonable default (most pdc20265) ARE
> > > currently offboard, and an easy way to change it.
> > 
> > There are ZERO pdc20265's offboard, only pdc20267's were in both options.
> > This is the direct asic packaging.  Thus all pdc20265 have the right to be
> > listed as onboard.
> 
> Could you comment next couple lines of code (2.4.19-vanilla):
> 
> ==========================================
> #else /* !CONFIG_PDC202XX_FORCE */
> [ ... skipped ... ]
>         {DEVID_PDC20265,"PDC20265" .... OFF_BOARD ..... },
>                                         ^^^^^^^^^
> [ ... skipped ... ]
> #endif
> ==========================================
> 
> Another bug? Just typo?
> Why author put PDC20265 in off-board list ?
> 
> > Cheers,
> > 
> > Andre Hedrick
> > LAD Storage Consulting Group
> > 
> 
> -- 
> With best wishes,
>         Nick Orlov.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [PATCH] pdc20265 problem.

[Marcin Dalecki]

Uz.ytkownik Andre Hedrick napisa?:
> Because I can not get a FSCKING PATCH past any of the Lead Penquins.
> 
> /src/linux-2.5.4-pristine/drivers/ide/ide-pci.c
> #ifdef CONFIG_PDC202XX_FORCE
>         {DEVID_PDC20265,"PDC20265",     PCI_PDC202XX,   ATA66_PDC202XX,
> INIT_PDC202XX,  NULL,           {{0x00,0x00,0x00}, {0x00,0x00,0x00}},
> ON_BOARD,
> 48 },
> #else /* !CONFIG_PDC202XX_FORCE */
>         {DEVID_PDC20265,"PDC20265",     PCI_PDC202XX,   ATA66_PDC202XX,
> INIT_PDC202XX,  NULL,           {{0x50,0x02,0x02}, {0x50,0x04,0x04}},
> OFF_BOARD,
> 48 },
> #endif
> 
> But since there is the option to compile off-board as bootable, it is a
> noop.  I have not been able to directly add code or update any kernel
> first hand since the change in 2.5.3 and my exit of Linux Development at
> 2.5.5.  So I really don't give a damn.
> 
> But what I do know is people bug me for patches and updates and ask me to
> fix 2.5.XX on a regular bases.  Nobody takes my patches but man when crap
> hits the fan they come running for me to put it right again.

Bullshit. First you have to send patches out at all before they can be
accepted or rejected. As far as I'm concerned I never saw anything from
him.

Re: [PATCH] pdc20265 problem.

[Andre Hedrick]

Hey PinHead #2,

> > /src/linux-2.5.4-pristine/drivers/ide/ide-pci.c

This was before you WRECKED the functionality.
I am having to much of a laugh watching you destroy the driver and the Fin
having the suffer the pain of the reports of your global failure.

The only patch I will send you is rm -rf ./linux-2.5.X/driver/ide/

It is the only proper thing to do at this time.

Regards,

Andre Hedrick
LAD Storage Consulting Group

On Fri, 9 Aug 2002, Marcin Dalecki wrote:

> Uz.ytkownik Andre Hedrick napisa?:
> > Because I can not get a FSCKING PATCH past any of the Lead Penquins.
> > 
> > /src/linux-2.5.4-pristine/drivers/ide/ide-pci.c
> > #ifdef CONFIG_PDC202XX_FORCE
> >         {DEVID_PDC20265,"PDC20265",     PCI_PDC202XX,   ATA66_PDC202XX,
> > INIT_PDC202XX,  NULL,           {{0x00,0x00,0x00}, {0x00,0x00,0x00}},
> > ON_BOARD,
> > 48 },
> > #else /* !CONFIG_PDC202XX_FORCE */
> >         {DEVID_PDC20265,"PDC20265",     PCI_PDC202XX,   ATA66_PDC202XX,
> > INIT_PDC202XX,  NULL,           {{0x50,0x02,0x02}, {0x50,0x04,0x04}},
> > OFF_BOARD,
> > 48 },
> > #endif
> > 
> > But since there is the option to compile off-board as bootable, it is a
> > noop.  I have not been able to directly add code or update any kernel
> > first hand since the change in 2.5.3 and my exit of Linux Development at
> > 2.5.5.  So I really don't give a damn.
> > 
> > But what I do know is people bug me for patches and updates and ask me to
> > fix 2.5.XX on a regular bases.  Nobody takes my patches but man when crap
> > hits the fan they come running for me to put it right again.
> 
> Bullshit. First you have to send patches out at all before they can be
> accepted or rejected. As far as I'm concerned I never saw anything from
> him.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [PATCH] pdc20265 problem.

[Bill Davidsen]

On Thu, 8 Aug 2002, Andre Hedrick wrote:

> On Wed, 7 Aug 2002, Bill Davidsen wrote:
> 
> > I would just as soon use a boot option as to try and make it a compile
> > option, and I think that many people just use a compiled kernel and never
> > change, which argues for a reasonable default (most pdc20265) ARE
> > currently offboard, and an easy way to change it.
> 
> There are ZERO pdc20265's offboard, only pdc20267's were in both options.
> This is the direct asic packaging.  Thus all pdc20265 have the right to be
> listed as onboard.  If you have a pdc20265 on an add-on card please send
> me a digital photo so I can question promise as to why.

I probably should have said non-primary, but the issue is the the pdc now
may be identified before the built-in IDE, such as VIA. If Linux doesn't
identify hda as the same drive as the BIOS, interesting boot problems
occur. And if 2.4.18 did one thing and 2.4.19 did another it gets even
more likely to confuse the user.

I think the real issue is if we should change the order of detection in a
stable kernel series, and I'll just sit and watch the sparks, there seem
to be strong feelings both ways.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.