[PATCH] pdc20265 problem.

[PATCH] pdc20265 problem.

[Nick Orlov]

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


> <marcelo@plucky.distro.conectiva> (02/07/19 1.646)
> 	Fix wrong #ifdef in ide-pci.c: Was causing problems with FastTrak

Because of this fix my Promise 20265 became ide0 instead of ide2.
Is there any reason to mark pdc20265 as ON_BOARD controller?

Anyway, attached patch fix it for me :)

-- 
With best wishes,
	Nick Orlov.


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

408c408
<         {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}},	OFF_BOARD,	48 },

Re: [PATCH] pdc20265 problem.

[Nick Orlov]

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

On Thu, Aug 01, 2002 at 09:47:28PM -0400, Nick Orlov wrote:
> 
> > <marcelo@plucky.distro.conectiva> (02/07/19 1.646)
> > 	Fix wrong #ifdef in ide-pci.c: Was causing problems with FastTrak
> 
> Because of this fix my Promise 20265 became ide0 instead of ide2.
> Is there any reason to mark pdc20265 as ON_BOARD controller?
> 
> Anyway, attached patch fix it for me :)
> 

Sorry, wrong diff format. Rediffed and attached.

-- 
With best wishes,
	Nick Orlov.


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

--- linux/drivers/ide/ide-pci.c.orig	2002-08-01 21:41:29.000000000 -0400
+++ linux/drivers/ide/ide-pci.c	2002-08-01 21:10:27.000000000 -0400
@@ -405,7 +405,7 @@
 #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}},	OFF_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 },

Re: [PATCH] pdc20265 problem.

[Alan Cox]

On Fri, 2002-08-02 at 02:47, Nick Orlov wrote:
> 
> > <marcelo@plucky.distro.conectiva> (02/07/19 1.646)
> > 	Fix wrong #ifdef in ide-pci.c: Was causing problems with FastTrak
> 
> Because of this fix my Promise 20265 became ide0 instead of ide2.
> Is there any reason to mark pdc20265 as ON_BOARD controller?

How about because it can be and it should be checked. I don't know what
is going on with the ifdef in your case to cause this but its not as
simple as it seems

Re: [PATCH] pdc20265 problem.

[Nick Orlov]

On Fri, Aug 02, 2002 at 01:27:25PM +0100, Alan Cox wrote:
> On Fri, 2002-08-02 at 02:47, Nick Orlov wrote:
> > 
> > > <marcelo@plucky.distro.conectiva> (02/07/19 1.646)
> > > 	Fix wrong #ifdef in ide-pci.c: Was causing problems with FastTrak
> > 
> > Because of this fix my Promise 20265 became ide0 instead of ide2.
> > Is there any reason to mark pdc20265 as ON_BOARD controller?
> 
> How about because it can be and it should be checked. I don't know what
> is going on with the ifdef in your case to cause this but its not as
> simple as it seems

Why pdc20265 is so special ? All other Promises marked as OFF_BOARD...

And what determines how id will be assigned to controllers if both of
them are ON_BOARD ?

-- 
With best wishes,
	Nick Orlov.

Re: [PATCH] pdc20265 problem.

[Bartlomiej Zolnierkiewicz]

On Fri, 2 Aug 2002, Nick Orlov wrote:

> On Fri, Aug 02, 2002 at 01:27:25PM +0100, Alan Cox wrote:
> > On Fri, 2002-08-02 at 02:47, Nick Orlov wrote:
> > >
> > > > <marcelo@plucky.distro.conectiva> (02/07/19 1.646)
> > > > 	Fix wrong #ifdef in ide-pci.c: Was causing problems with FastTrak
> > >
> > > Because of this fix my Promise 20265 became ide0 instead of ide2.
> > > Is there any reason to mark pdc20265 as ON_BOARD controller?
> >
> > How about because it can be and it should be checked. I don't know what
> > is going on with the ifdef in your case to cause this but its not as
> > simple as it seems
>
> Why pdc20265 is so special ? All other Promises marked as OFF_BOARD...
>
> And what determines how id will be assigned to controllers if both of
> them are ON_BOARD ?

AFAIR problem is that some vendors included onboard 20265 as primary
device (playing tricks for that) and to be consistent we have to treat it as
onboard, we have right now no way to check if it is on or offboard.
EDD support will probably help here.

Regards
--
Bartlomiej

> --
> With best wishes,
> 	Nick Orlov.

Re: [PATCH] pdc20265 problem.

[Nick Orlov]

On Fri, Aug 02, 2002 at 04:00:32PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 
> On Fri, 2 Aug 2002, Nick Orlov wrote:
> 
> > On Fri, Aug 02, 2002 at 01:27:25PM +0100, Alan Cox wrote:
> > > On Fri, 2002-08-02 at 02:47, Nick Orlov wrote:
> > > >
> > > > > <marcelo@plucky.distro.conectiva> (02/07/19 1.646)
> > > > > 	Fix wrong #ifdef in ide-pci.c: Was causing problems with FastTrak
> > > >
> > > > Because of this fix my Promise 20265 became ide0 instead of ide2.
> > > > Is there any reason to mark pdc20265 as ON_BOARD controller?
> > >
> > > How about because it can be and it should be checked. I don't know what
> > > is going on with the ifdef in your case to cause this but its not as
> > > simple as it seems
> >
> > Why pdc20265 is so special ? All other Promises marked as OFF_BOARD...
> >
> > And what determines how id will be assigned to controllers if both of
> > them are ON_BOARD ?
> 
> AFAIR problem is that some vendors included onboard 20265 as primary
> device (playing tricks for that) and to be consistent we have to treat it as
> onboard, we have right now no way to check if it is on or offboard.
> EDD support will probably help here.
> 

Just FYI,

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

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

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

-- 
With best wishes,
	Nick Orlov.

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.

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

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.

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

[Petr Vandrovec]

On  5 Aug 02 at 23:48, 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.

Make me favor, and extend ide0=<port> to also allow 
ide0=pci<slotnumber>.primary or .secondary... Until then
I do not know port address in advance (my board also uses
20265 as secondary ATA host, and I was really surprised what happened
to my /dev/hde after upgrade).
                                        Petr Vandrovec
                                        vandrove@vc.cvut.cz
                                        

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.

[Adam J. Richter]

Nick Orlov writes:
>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?

	You might not see them on linux-kenrel, but there are
lots of Linux users that are not comfortable compiling a custom
kernel (or even competent to do so), but are a bit more willing
to edit files and rerun a boot configuration utility like lilo.

	Linux users in the "I'm not a sysadmin" crowd (?) probably
don't care about the scan order of the pdc20265 IDE controller,
but people in the "I'm a sysadmin, not a programmer" crowd
may have legitimiate reasons to.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: [PATCH] pdc20265 problem.

[Petr Vandrovec]

On  7 Aug 02 at 0:54, Adam J. Richter wrote:
> Nick Orlov writes:
> >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?
> 
>     Linux users in the "I'm not a sysadmin" crowd (?) probably
> don't care about the scan order of the pdc20265 IDE controller,
> but people in the "I'm a sysadmin, not a programmer" crowd
> may have legitimiate reasons to.

But such "I'm not a sysadmin" people will be very surprised that their
promise was IDE2 in 2.2.x, it was IDE2 in 2.4.18, it is IDE2 in 2.5.30,
and now - oops - it is IDE0 in 2.4.19. Broken, I'd say.

There is an CONFIG_BLK_DEV_OFFBOARD option (apparently unused...),
so use this one, if some distribution must force ide0= to promise 
if their installer cannot find master disk on /dev/hde. But changing
behavior for no reason - especially in the middle of stable series -
is IMHO unacceptable. 

Fortunately I use 2.5.30's IDE for real work ;-)
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                

Re: [PATCH] pdc20265 problem.

[Alan Cox]

On Wed, 2002-08-07 at 08:54, Adam J. Richter wrote:
> 	Linux users in the "I'm not a sysadmin" crowd (?) probably
> don't care about the scan order of the pdc20265 IDE controller,
> but people in the "I'm a sysadmin, not a programmer" crowd
> may have legitimiate reasons to.

The non sysadmin people care that is has not change, and generally
prefer that its the same ordering as windows seems to use. Once you go
to modular IDE it gets trickier. Certainly if you load modules the usual
bets are off (as with scsi)

It is possible to take a serial like approach and we could say

	if(pci && southbridge_has_ide_device())
		reserve_ide0();

That would ensure the southbridge IDE stayed in one place. Another
alternative is to enumerate all the IDE devices by class (we can do that
nice and easy, with a little tweak for the fasttrak stuff) then hand
them off according to the enumeration position. That would preserve the
old semantics nicely for pci IDE. (Plug in ISA IDE is pretty rare and
since we can't probe those its kind of hard to do anything much about
it).

Andre is currently dealing with some of this in the main IDE code

Re: [PATCH] pdc20265 problem.

[Thunder from the hill]

Hi,

On Wed, 7 Aug 2002, Adam J. Richter wrote:
> 	You might not see them on linux-kenrel, but there are
> lots of Linux users that are not comfortable compiling a custom
> kernel (or even competent to do so), but are a bit more willing
> to edit files and rerun a boot configuration utility like lilo.
> 
> 	Linux users in the "I'm not a sysadmin" crowd (?) probably
> don't care about the scan order of the pdc20265 IDE controller,
> but people in the "I'm a sysadmin, not a programmer" crowd
> may have legitimiate reasons to.

Oh, that's really no problem. You can reduce the programm to choosing a 
simple list entry and clicking a button. Anything can be made easy via the 
proper frontend. (And BTW, one should always be both - (sys|net)admin and 
"programmer".)

			Thunder
-- 
.-../../-./..-/-..- .-./..-/.-.././.../.-.-.-

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.

[Adam J. Richter]

On Wed, 2002-08-07 at 10:47, Alan Cox wrote:
>On Wed, 2002-08-07 at 08:54, Adam J. Richter wrote:
>>       Linux users in the "I'm not a sysadmin" crowd (?) probably
>> don't care about the scan order of the pdc20265 IDE controller,
>> but people in the "I'm a sysadmin, not a programmer" crowd
>> may have legitimiate reasons to.
>
>The non sysadmin people care that is has not change, and generally
>prefer that its the same ordering as windows seems to use. Once you go
>to modular IDE it gets trickier. Certainly if you load modules the usual
>bets are off (as with scsi)
[...]

And Petr Vandrovec wrote:
| But such "I'm not a sysadmin" people will be very surprised that their
| promise was IDE2 in 2.2.x, it was IDE2 in 2.4.18, it is IDE2 in 2.5.30,
| and now - oops - it is IDE0 in 2.4.19. Broken, I'd say.

	I was not expresing an opinion on what the default
ordering should be.

	There seemed to be agreement that no single ordering would
make all users happy and that there should be some way of changing
the ordering.  The post that I replied to discussed and module
arguments versus a compile time flag.  All that I was saying was
that providing arguments would probably be more useful for the
population that might care about this issue, as they might not be
comfortable having to rebuild custom kernels (or supporting another
kernel in their site, I should add now).

I might as well address the response from "Thunder from the hill" as well;
: Oh, that's really no problem. You can reduce the programm to choosing a 
: simple list entry and clicking a button. Anything can be made easy via the 
: proper frontend. (And BTW, one should always be both - (sys|net)admin and 
: "programmer".)

	That would require the distribution provider to double
the number of precompiled kernels or module trees that they ship
and support.  That would be a lot more work than implementing a
module option and a boot option and use a lot more space, for no
substatial advantages that I'm aware of.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: [PATCH] pdc20265 problem.

[Thunder from the hill]

Hi,

On Wed, 7 Aug 2002, Adam J. Richter wrote:
> That would require the distribution provider to double the number of
> precompiled kernels or module trees that they ship and support.  That
> would be a lot more work than implementing a module option and a boot
> option and use a lot more space, for no substatial advantages that I'm
> aware of.

Not exactly. Somebody who releases Linux distributions should be able to 
release it with a kernel that can have a boot parameter or such about it 
which is configured via mouse click...

That still doesn't make it any harder to achieve.

			Thunder
-- 
.-../../-./..-/-..- .-./..-/.-.././.../.-.-.-

Re: [PATCH] pdc20265 problem.

[Thunder from the hill]

Hi,

On 7 Aug 2002, Alan Cox wrote:
> You know where to send the patches

If you want me to, yes.

			Thunder
-- 
.-../../-./..-/-..- .-./..-/.-.././.../.-.-.-

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.

[Alan Cox]

On Wed, 2002-08-07 at 20:33, Thunder from the hill wrote:
>
> Not exactly. Somebody who releases Linux distributions should be able to 
> release it with a kernel that can have a boot parameter or such about it 
> which is configured via mouse click...
> 
> That still doesn't make it any harder to achieve.

You know where to send the patches

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.

[Bill Davidsen]

On Wed, 7 Aug 2002, Petr Vandrovec wrote:

> On  7 Aug 02 at 0:54, Adam J. Richter wrote:

> >     Linux users in the "I'm not a sysadmin" crowd (?) probably
> > don't care about the scan order of the pdc20265 IDE controller,
> > but people in the "I'm a sysadmin, not a programmer" crowd
> > may have legitimiate reasons to.
> 
> But such "I'm not a sysadmin" people will be very surprised that their
> promise was IDE2 in 2.2.x, it was IDE2 in 2.4.18, it is IDE2 in 2.5.30,
> and now - oops - it is IDE0 in 2.4.19. Broken, I'd say.

And on that one I really do agree. A change like that in 2.5 wouldn't
bother me beyond usual ten minutes of consigning whoever did it to the
darkest level of hell ;-) I would think that distributions would ship with
a kernel which follows Plauger's "law of least astonishment," so it may
not matter unless you roll your own. Kind of violates the idea of "stable"
IMHO, but I have other design decisions which bother me far more.
 
> There is an CONFIG_BLK_DEV_OFFBOARD option (apparently unused...),
> so use this one, if some distribution must force ide0= to promise 
> if their installer cannot find master disk on /dev/hde. But changing
> behavior for no reason - especially in the middle of stable series -
> is IMHO unacceptable. 

I disagree with "no reason," there was a reason, but I do think it was a
bad idea. There just aren't that many people with an onboard controller to
justify a change. My opinion, of course.
 
> Fortunately I use 2.5.30's IDE for real work ;-)

I use 2.5 kernels to test my backups :-( The last one I ran drooled
spillage in every attached drive, including my BSD drive which is on an
offboard controller. I would tell you the version, but it gone. Somewhere
in the 2.5.24..27 range.

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

Re: [PATCH] pdc20265 problem.

[Bill Davidsen]

On 7 Aug 2002, Alan Cox wrote:

> That would ensure the southbridge IDE stayed in one place. Another
> alternative is to enumerate all the IDE devices by class (we can do that
> nice and easy, with a little tweak for the fasttrak stuff) then hand
> them off according to the enumeration position. That would preserve the
> old semantics nicely for pci IDE. (Plug in ISA IDE is pretty rare and
> since we can't probe those its kind of hard to do anything much about
> it).

ISA my foot, real men went to the VESA bus as soon as it came out, to get
32 bit i/o. I have a 486 router, with 2.4.9 or so, maybe I should refresh
my memory as to what hardware lives there. Last install moderately recent,
it had the new bind and I had to convert all the files.

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

Re: [PATCH] pdc20265 problem.

[Alan Cox]

On Wed, 2002-08-07 at 21:02, Thunder from the hill wrote:
> Hi,
> 
> On 7 Aug 2002, Alan Cox wrote:
> > You know where to send the patches
> 
> If you want me to, yes.

I'm all for the promise raid switch being runtime

Re: [PATCH] pdc20265 problem.

[Zwane Mwaikambo]

On Wed, 7 Aug 2002, Bill Davidsen wrote:

> On 7 Aug 2002, Alan Cox wrote:
> 
> > That would ensure the southbridge IDE stayed in one place. Another
> > alternative is to enumerate all the IDE devices by class (we can do that
> > nice and easy, with a little tweak for the fasttrak stuff) then hand
> > them off according to the enumeration position. That would preserve the
> > old semantics nicely for pci IDE. (Plug in ISA IDE is pretty rare and
> > since we can't probe those its kind of hard to do anything much about
> > it).

Well there is also the ISAPNP IDE plug in variant, or would these qualify 
as 'pci' in terms of enumeration? The devices i'm thinking about are the 
ones on ISAPNP sound cards.

	Zwane

-- 
function.linuxpower.ca

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.

[Petr Vandrovec]

On  8 Aug 02 at 3:50, 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.

They are on the mainboard, but mainboard has also (in my case VIA) IDE
chipset on the shelf, and BIOS shows everywhere (autodetection, IDE config)
that VIA is the primary chipset, and PDC ('UDMA100' interface in the BIOS)
is an additional, optional, interface. So forcing PDC20265 as primary is 
a bug - it is not consistent with BIOS, it is not consistent with Windows, 
and it is not consistent with other Linux versions.

Up to now nobody showed me mainboard which has PDC20265, but which does
not have other IDE chipset integrated in the southbridge, or at least
mainbord with BIOS which names disks connected to the PDC primary/secondary
master/slave. It is 3rd/4th channel on all mainboards I ever saw.
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz
                                                    

Re: [PATCH] pdc20265 problem.

[Andre Hedrick]

Please go check your BIOS and search or support/boot INT19 services.
That is how the mainboard selects ordering from the bios.

Go read e01125r0 and the e01133r0's related sections.

There are mainboard out there designed specifically to boot off the third
party host.  I have one with the pdc20265 on it.  So if you mainboard is
produced by some lame OEM who is trying to grant first access to the addon
host chip by playing silly devfn/bus ordering games you get what you
bought.  Yeah there are cheesy crap-mainboard oem's that play this game.

Regards,

Andre Hedrick
LAD Storage Consulting Group

On Thu, 8 Aug 2002, Petr Vandrovec wrote:

> On  8 Aug 02 at 3:50, 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.
> 
> They are on the mainboard, but mainboard has also (in my case VIA) IDE
> chipset on the shelf, and BIOS shows everywhere (autodetection, IDE config)
> that VIA is the primary chipset, and PDC ('UDMA100' interface in the BIOS)
> is an additional, optional, interface. So forcing PDC20265 as primary is 
> a bug - it is not consistent with BIOS, it is not consistent with Windows, 
> and it is not consistent with other Linux versions.
> 
> Up to now nobody showed me mainboard which has PDC20265, but which does
> not have other IDE chipset integrated in the southbridge, or at least
> mainbord with BIOS which names disks connected to the PDC primary/secondary
> master/slave. It is 3rd/4th channel on all mainboards I ever saw.
>                                                     Petr Vandrovec
>                                                     vandrove@vc.cvut.cz
>                                                     
> 

Re: [PATCH] pdc20265 problem.

[Petr Vandrovec]

On  8 Aug 02 at 6:02, Andre Hedrick wrote:
> 
> There are mainboard out there designed specifically to boot off the third
> party host.  I have one with the pdc20265 on it.  So if you mainboard is

Vendor + motherboard name, please.

> produced by some lame OEM who is trying to grant first access to the addon
> host chip by playing silly devfn/bus ordering games you get what you
> bought.  Yeah there are cheesy crap-mainboard oem's that play this game.

Uhh? Changing boot order in the BIOS must NOT change what ide0 is.

What are you smoking? It would completely screw my system that if I
decide to boot from secondary channel, it magically becomes ide0. If
Linux would behave this way, I could never tell which disk will get which
name until I boot. What if I boot from floppy? Then IDE interfaces will 
become numbered from ide1, because of there was no IDE boot device?
Should we also swap hda with hdb if I boot my system from primary slave?

And I did not found anything about ide0 in documents you provided.

And BTW, my board is A7V from Asus. Manual refers to VIA interface
as 'primary/secondary channels', and to PDC as 'UDMA100 interface'(s).
And PDC is always run in the native mode, IRQ14/15 is not wired to the
PDC chip at all.

I always thought that if there is IDE interface at the 0x1F0 in the
system, it will become ide0, and if there is interface at the 0x170,
it will become ide1 (and simillary for ISA-based tertiary/quaterniary). 
After this step unused ide* interfaces are populated with native PCI IDE 
interfaces, starting at ide0, and going up...
                                            Petr Vandrovec
                                            vandrove@vc.cvut.cz
                                            

Re: [PATCH] pdc20265 problem.

[Andre Hedrick]

Petr,

Here is a short list!

http://www.tyan.com/products/html/thunderlet.html
http://www.tyan.com/products/html/tiger200t.html
http://www.tyan.com/products/html/trinityi845e.html
http://www.tyan.com/products/html/trinitygcsl.html
http://www.epox.com/html/english/products/motherboard/ep-d3va.htm
http://www.epox.com/html/english/products/motherboard/ep-8k3a.htm
http://www.supermicro.com/PRODUCT/MotherBoards/VIA/370DDE.htm
http://www.supermicro.com/PRODUCT/MotherBoards/VIA/P3TDDE.htm


It is absolutely lame that people in 2.5 are clueless to what is going to
need to be supported.  Also it is lame in 2.4 that cruft from OEMs who do
not get Linux, but their changes are accepted.  There were very careful
decisions made over the past 4-5 years about device ordering and
protecting the power of ide0/ide1.  Within a few days it is shot to hell
because nobody ever thinks to look at what was there before them.  They
all know better, are wiser, empower w/ megalmania (sp) and gawd knows what
else.  Please next time, do your homework before you attempt to call me
on these issues.  Do the two word "Native" and "Compatablity" in ATA-ATAPI
have meaning?  This will help you go a long way.

Regards,


Andre Hedrick
LAD Storage Consulting Group


On Thu, 8 Aug 2002, Petr Vandrovec wrote:

> On  8 Aug 02 at 6:02, Andre Hedrick wrote:
> > 
> > There are mainboard out there designed specifically to boot off the third
> > party host.  I have one with the pdc20265 on it.  So if you mainboard is
> 
> Vendor + motherboard name, please.
> 
> > produced by some lame OEM who is trying to grant first access to the addon
> > host chip by playing silly devfn/bus ordering games you get what you
> > bought.  Yeah there are cheesy crap-mainboard oem's that play this game.
> 
> Uhh? Changing boot order in the BIOS must NOT change what ide0 is.
> 
> What are you smoking? It would completely screw my system that if I
> decide to boot from secondary channel, it magically becomes ide0. If
> Linux would behave this way, I could never tell which disk will get which
> name until I boot. What if I boot from floppy? Then IDE interfaces will 
> become numbered from ide1, because of there was no IDE boot device?
> Should we also swap hda with hdb if I boot my system from primary slave?
> 
> And I did not found anything about ide0 in documents you provided.
> 
> And BTW, my board is A7V from Asus. Manual refers to VIA interface
> as 'primary/secondary channels', and to PDC as 'UDMA100 interface'(s).
> And PDC is always run in the native mode, IRQ14/15 is not wired to the
> PDC chip at all.
> 
> I always thought that if there is IDE interface at the 0x1F0 in the
> system, it will become ide0, and if there is interface at the 0x170,
> it will become ide1 (and simillary for ISA-based tertiary/quaterniary). 
> After this step unused ide* interfaces are populated with native PCI IDE 
> interfaces, starting at ide0, and going up...
>                                             Petr Vandrovec
>                                             vandrove@vc.cvut.cz
>                                             
> 

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.

[Petr Vandrovec]

On  8 Aug 02 at 10:30, Andre Hedrick wrote:
> 
> http://www.tyan.com/products/html/thunderlet.html

Page 40 of manual: choose Onboard IDE or FastTrak ATA-100/RAID.
OnboardIDE means Serverworks, FastTrak means PDC20265.
BIOS settings for primary/secondary disk relate to the Serverworks
channels.

> http://www.tyan.com/products/html/tiger200t.html

Page 11: Primary/secondary IDE: VIA, RAID primary/secondary: PDC.
Page 33: Primary/secondary IDE settings relate to the VIA.

> http://www.tyan.com/products/html/trinityi845e.html

Page 5: Integrated PCI IDE (it talks about i845 internal) +
integrated IDE RAID (20267, so no relevance here). Page 28:
primary/secondary disables i845, not PDC.

> http://www.tyan.com/products/html/trinitygcsl.html

Serverworks, with IDE. Serverworks IDE is primary.
RAID is 20267, so no relevance. Manual not available yet.

> http://www.epox.com/html/english/products/motherboard/ep-d3va.htm

VIA onboard, HPT370 RAID. Connectors of RAID marked IDE3/IDE4.

> http://www.epox.com/html/english/products/motherboard/ep-8k3a.htm

8k3a has no RAID. 8k3a+ has PDC20267. Primary IDE is from VIA,
RAID is additional...

> http://www.supermicro.com/PRODUCT/MotherBoards/VIA/370DDE.htm

Manual unavailable from the web (404 Page not found after clicking
on manual). Picture shows IDE #1/IDE #2 (VIA) and IDE RAID #1/#2.
Besides that it has PDC20267, so it has no relevance to this discussion.

> http://www.supermicro.com/PRODUCT/MotherBoards/VIA/P3TDDE.htm

Manual page #10: IDE1/IDE2 for VIA, IDE RAID #1/#2 for PDC.
Page 14: 2 IDE bus master interfaces support UDMA/100 (listed first),
2 IDE RAID connectors (listed later). Page 49: IDE primary/secondary
settings relate to the VIA.
 
> all know better, are wiser, empower w/ megalmania (sp) and gawd knows what
> else.  Please next time, do your homework before you attempt to call me
> on these issues.  Do the two word "Native" and "Compatablity" in ATA-ATAPI
> have meaning?  This will help you go a long way.

I did my homework. I still believe that there is NO MAINBOARD with
PDC20265, and without southbridge IDE - be it VIA, SiS, Intel or Nvidia.
All motherboards you listed have PDC (or HPT) as an additional controller,
and manual always refers to southbridge as IDE#1/IDE#2, while PDC
is referred as IDE RAID#1/#2, or even as IDE#3/IDE#4.

If you tried to prove that PDC20265 should never be ide0/ide1, then
we are on the same boat.
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                
P.S.: Both Tyan and Epox should make their ftp servers much, much faster...
                                                

Re: [PATCH] pdc20265 problem.

[Andre Hedrick]

Clearly the difference between what is silkscreened and the usage intent
is beyond the obvious :-/  Since I have had or still have first hand
experience in the observed behaior under Linux and MicroSoft, you are
going by what is read.  Book knowledges gets you books not reality.
try a few w/ all of them bootable and see what happens.  So until Linux
gets a clue about EDDS 2.0 and or 3.0 it has not a chance of getting the
correct hd0/hd1 from the INT13/19 services.  Obviously experience and
first hand knowledge of reality is worthless in Linux.  I am out of this
thread.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Thu, 8 Aug 2002, Petr Vandrovec wrote:

> On  8 Aug 02 at 10:30, Andre Hedrick wrote:
> > 
> > http://www.tyan.com/products/html/thunderlet.html
> 
> Page 40 of manual: choose Onboard IDE or FastTrak ATA-100/RAID.
> OnboardIDE means Serverworks, FastTrak means PDC20265.
> BIOS settings for primary/secondary disk relate to the Serverworks
> channels.
> 
> > http://www.tyan.com/products/html/tiger200t.html
> 
> Page 11: Primary/secondary IDE: VIA, RAID primary/secondary: PDC.
> Page 33: Primary/secondary IDE settings relate to the VIA.
> 
> > http://www.tyan.com/products/html/trinityi845e.html
> 
> Page 5: Integrated PCI IDE (it talks about i845 internal) +
> integrated IDE RAID (20267, so no relevance here). Page 28:
> primary/secondary disables i845, not PDC.
> 
> > http://www.tyan.com/products/html/trinitygcsl.html
> 
> Serverworks, with IDE. Serverworks IDE is primary.
> RAID is 20267, so no relevance. Manual not available yet.
> 
> > http://www.epox.com/html/english/products/motherboard/ep-d3va.htm
> 
> VIA onboard, HPT370 RAID. Connectors of RAID marked IDE3/IDE4.
> 
> > http://www.epox.com/html/english/products/motherboard/ep-8k3a.htm
> 
> 8k3a has no RAID. 8k3a+ has PDC20267. Primary IDE is from VIA,
> RAID is additional...
> 
> > http://www.supermicro.com/PRODUCT/MotherBoards/VIA/370DDE.htm
> 
> Manual unavailable from the web (404 Page not found after clicking
> on manual). Picture shows IDE #1/IDE #2 (VIA) and IDE RAID #1/#2.
> Besides that it has PDC20267, so it has no relevance to this discussion.
> 
> > http://www.supermicro.com/PRODUCT/MotherBoards/VIA/P3TDDE.htm
> 
> Manual page #10: IDE1/IDE2 for VIA, IDE RAID #1/#2 for PDC.
> Page 14: 2 IDE bus master interfaces support UDMA/100 (listed first),
> 2 IDE RAID connectors (listed later). Page 49: IDE primary/secondary
> settings relate to the VIA.
>  
> > all know better, are wiser, empower w/ megalmania (sp) and gawd knows what
> > else.  Please next time, do your homework before you attempt to call me
> > on these issues.  Do the two word "Native" and "Compatablity" in ATA-ATAPI
> > have meaning?  This will help you go a long way.
> 
> I did my homework. I still believe that there is NO MAINBOARD with
> PDC20265, and without southbridge IDE - be it VIA, SiS, Intel or Nvidia.
> All motherboards you listed have PDC (or HPT) as an additional controller,
> and manual always refers to southbridge as IDE#1/IDE#2, while PDC
> is referred as IDE RAID#1/#2, or even as IDE#3/IDE#4.
> 
> If you tried to prove that PDC20265 should never be ide0/ide1, then
> we are on the same boat.
>                                                 Petr Vandrovec
>                                                 vandrove@vc.cvut.cz
>                                                 
> P.S.: Both Tyan and Epox should make their ftp servers much, much faster...
>                                                 
> 

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.

[Marcin Dalecki]

Uz.ytkownik Andre Hedrick napisa?:
> Clearly the difference between what is silkscreened and the usage intent
> is beyond the obvious :-/  Since I have had or still have first hand
> experience in the observed behaior under Linux and MicroSoft, you are
> going by what is read.  Book knowledges gets you books not reality.
> try a few w/ all of them bootable and see what happens.  So until Linux
> gets a clue about EDDS 2.0 and or 3.0 it has not a chance of getting the
> correct hd0/hd1 from the INT13/19 services.  Obviously experience and
> first hand knowledge of reality is worthless in Linux.  I am out of this
> thread.

BTW. EDDS is up to level 3.3

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.

Re: [PATCH] pdc20265 problem.

[Andre Hedrick]

On Fri, 9 Aug 2002, Marcin Dalecki wrote:

> Uz.ytkownik Andre Hedrick napisa?:
> > Clearly the difference between what is silkscreened and the usage intent
> > is beyond the obvious :-/  Since I have had or still have first hand
> > experience in the observed behaior under Linux and MicroSoft, you are
> > going by what is read.  Book knowledges gets you books not reality.
> > try a few w/ all of them bootable and see what happens.  So until Linux
> > gets a clue about EDDS 2.0 and or 3.0 it has not a chance of getting the
> > correct hd0/hd1 from the INT13/19 services.  Obviously experience and
> > first hand knowledge of reality is worthless in Linux.  I am out of this
> > thread.
> 
> BTW. EDDS is up to level 3.3

That is nice to know since it has never been submitted to the Committee
and the last time I checked with the author it was 3.0.  Then again you
are so vast with knowledge, maybe you submitted 3.3 ... LOL.

You are so full of BULLSHIT it is no longer funny.

e02112r1 is the current revision for project proposal for EDDS 3.0.

Gee, where is Martin's name and or Company to be found for the adoption
into ATA-7.

No where.

Andre Hedrick
LAD Storage Consulting Group

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/
>