PATCH: IDE - sensible probing for PCI systems

PATCH: IDE - sensible probing for PCI systems

[Alan Cox]

Old ISA/VESA systems sometimes put tertiary IDE controllers at addresses
0x1e8, 0x168, 0x1e0 or 0x160. Linux thus probes these addresses on x86
systems. Unfortunately some PCI systems now use these addresses for
other purposes which leads to users seeing minute plus hangs during boot
or even crashes.

The following patch (again has been in Fedora for a while) only probes
the obscure legacy ISA ports on machinea that are pre-PCI. This seems to
keep everyone happy and if there is someone with that utterly weird
corner case the ide= command line still provides a get out of jail card.
Unsurprisingly we've not found anyone so affected.

Signed-off-by: Alan Cox <alan@redhat.com>

diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.12rc5/include/asm-i386/ide.h linux-2.6.12-rc5/include/asm-i386/ide.h
--- linux.vanilla-2.6.12rc5/include/asm-i386/ide.h	2005-05-27 15:15:42.000000000 +0100
+++ linux-2.6.12-rc5/include/asm-i386/ide.h	2005-05-27 15:43:28.000000000 +0100
@@ -41,16 +41,20 @@
 
 static __inline__ unsigned long ide_default_io_base(int index)
 {
+	if(pci_find_device(PCI_ANY_ID, PCI_ANY_ID, NULL) == NULL) {
+		switch(index) {
+			case 2: return 0x1e8;
+			case 3: return 0x168;
+			case 4: return 0x1e0;
+			case 5: return 0x160;
+			}
+	}
 	switch (index) {
 		case 0:	return 0x1f0;
 		case 1:	return 0x170;
-		case 2: return 0x1e8;
-		case 3: return 0x168;
-		case 4: return 0x1e0;
-		case 5: return 0x160;
 		default:
 			return 0;
-	}
+	}		
 }
 
 #define IDE_ARCH_OBSOLETE_INIT

Re: PATCH: IDE - sensible probing for PCI systems

[Maciej W. Rozycki]

On Tue, 21 Jun 2005, Alan Cox wrote:

> Old ISA/VESA systems sometimes put tertiary IDE controllers at addresses
> 0x1e8, 0x168, 0x1e0 or 0x160. Linux thus probes these addresses on x86
> systems. Unfortunately some PCI systems now use these addresses for
> other purposes which leads to users seeing minute plus hangs during boot
> or even crashes.

 Are these addresses visible in BARs?

> The following patch (again has been in Fedora for a while) only probes
> the obscure legacy ISA ports on machinea that are pre-PCI. This seems to
> keep everyone happy and if there is someone with that utterly weird
> corner case the ide= command line still provides a get out of jail card.
> Unsurprisingly we've not found anyone so affected.

 FYI, for MIPS for machines with a PCI bus we only probe for ISA IDE ports 
on if there's a PCI-ISA or PCI-EISA bridge somewhere there.  This might be 
a good idea for the i386 and probably any platform using PCI as well.

  Maciej

Re: PATCH: IDE - sensible probing for PCI systems

[Alan Cox]

On Maw, 2005-06-21 at 14:42, Maciej W. Rozycki wrote:
> On Tue, 21 Jun 2005, Alan Cox wrote:
> 
> > Old ISA/VESA systems sometimes put tertiary IDE controllers at addresses
> > 0x1e8, 0x168, 0x1e0 or 0x160. Linux thus probes these addresses on x86
> > systems. Unfortunately some PCI systems now use these addresses for
> > other purposes which leads to users seeing minute plus hangs during boot
> > or even crashes.
> 
>  Are these addresses visible in BARs?

Sometimes but often not. They tend to be below the PCI range used by the
systems but belonging to onboard "magic"

>  FYI, for MIPS for machines with a PCI bus we only probe for ISA IDE ports 
> on if there's a PCI-ISA or PCI-EISA bridge somewhere there.  This might be 
> a good idea for the i386 and probably any platform using PCI as well.

The primary/secondary ISA ports show up in PC systems because of the PCI
IDE class devices being in compatibility mode not native mode (so you
can still run old OS's). There are also a couple of older weird cases.

The PCI layer code is smart enough to figure out when a PCI and an ISA
probe find the same device and to put the entire thing together properly
so that aspect of it is ok.

For the 3rd and higher ports probing them isn't safe on a PCI box
regardless of the presence of ISA bridges so I don't think we need the
extra complexity - or am I missing something ?

Re: PATCH: IDE - sensible probing for PCI systems

[Maciej W. Rozycki]

On Tue, 21 Jun 2005, Alan Cox wrote:

> > > Old ISA/VESA systems sometimes put tertiary IDE controllers at addresses
> > > 0x1e8, 0x168, 0x1e0 or 0x160. Linux thus probes these addresses on x86
> > > systems. Unfortunately some PCI systems now use these addresses for
> > > other purposes which leads to users seeing minute plus hangs during boot
> > > or even crashes.
> > 
> >  Are these addresses visible in BARs?
> 
> Sometimes but often not. They tend to be below the PCI range used by the
> systems but belonging to onboard "magic"

 How is the range defined -- is there a way for us to find it?  I'd assume 
in the absence of a PCI-ISA or PCI-EISA bridge all I/O port addresses 
belong to PCI.  Otherwise the usual rule of "(addr & 0x300) == 0" applies.  
Perhaps with the addition of "(addr & ~0xff) != 0" for safety as junk I/O 
is often not recorded properly in BARs, sigh...

> >  FYI, for MIPS for machines with a PCI bus we only probe for ISA IDE ports 
> > on if there's a PCI-ISA or PCI-EISA bridge somewhere there.  This might be 
> > a good idea for the i386 and probably any platform using PCI as well.
> 
> The primary/secondary ISA ports show up in PC systems because of the PCI
> IDE class devices being in compatibility mode not native mode (so you
> can still run old OS's). There are also a couple of older weird cases.

 Certainly, but as long as they are seen as IDE devices on PCI, our driver 
can discover them and use without the need of probing through 
ide_default_io_base().

> The PCI layer code is smart enough to figure out when a PCI and an ISA
> probe find the same device and to put the entire thing together properly
> so that aspect of it is ok.

 Sure.

> For the 3rd and higher ports probing them isn't safe on a PCI box
> regardless of the presence of ISA bridges so I don't think we need the
> extra complexity - or am I missing something ?

 The code is OK with me, but I've been wondering whether a more general 
approach would be possible.  And poking blindly at any of these ports, 
including the "traditional" primary and secondary IDE interfaces, is 
unsafe if there is no legacy bridge in the system, because you either hit 
an innocent arbitrary device that happens to have a BAR configured for 
that range or get a master abort (I'm not sure what it results in for the 
i386 -- an NMI?) if nobody listens.

 Actually there should have always been a set of BARs for the (E)ISA in 
legacy bridges, which would have made the whole mess be avoided, sigh...

  Maciej

Re: PATCH: IDE - sensible probing for PCI systems

[Alan Cox]

>  How is the range defined -- is there a way for us to find it?  I'd assume 
> in the absence of a PCI-ISA or PCI-EISA bridge all I/O port addresses 
> belong to PCI.  Otherwise the usual rule of "(addr & 0x300) == 0" applies.  
> Perhaps with the addition of "(addr & ~0xff) != 0" for safety as junk I/O 
> is often not recorded properly in BARs, sigh...

No the low addresses belong to the chipset and motherboard. There is
also magic then for video and IDE legacy port ranges. I suspect your
mips boxen might be a lot cleaner than the PC world.

Alan

Re: PATCH: IDE - sensible probing for PCI systems

[Maciej W. Rozycki]

On Tue, 21 Jun 2005, Alan Cox wrote:

> >  How is the range defined -- is there a way for us to find it?  I'd assume 
> > in the absence of a PCI-ISA or PCI-EISA bridge all I/O port addresses 
> > belong to PCI.  Otherwise the usual rule of "(addr & 0x300) == 0" applies.  
> > Perhaps with the addition of "(addr & ~0xff) != 0" for safety as junk I/O 
> > is often not recorded properly in BARs, sigh...
> 
> No the low addresses belong to the chipset and motherboard. There is

 Well, that doesn't mean they can't be properly reported in a BAR.  

 Besides, does a modern i386 really require them?  DOS compatibility is no 
longer an issue for commodity hardware and the ISA bridge is gone.  
Apparently the only legacy device still not replaced by anything else is 
the RTC, which is rather surprising as there seems to be a lot of 
reasonable alternatives for I2C available these days and i386 boxes have 
had I2C for quite a while now.

> also magic then for video and IDE legacy port ranges. I suspect your

 Both IDE and video are distinct PCI devices these days, so there is no 
need for them to hide their decoded address ranges.  I've thought that has 
been sorted out.

> mips boxen might be a lot cleaner than the PC world.

 They are certainly cleaner, but if a lot, it depends on whether an (E)ISA 
bridge is there somewhere or not.  E.g. some PCI-ISA bridges positively 
decode some memory address ranges unconditionally which results in the 
corresponding range of RAM being unreachable from PCI.  And if there is no 
(E)ISA bridge, there may still be traces of legacy, like P2P bridges with 
an implicit special treatment of certain address ranges that traditionally 
used to be used for ISA.  Or APIC interrupt codes in messages sent over 
HT.

  Maciej

Re: PATCH: IDE - sensible probing for PCI systems

[Alan Cox]

On Iau, 2005-06-23 at 19:22, Maciej W. Rozycki wrote:
>  Besides, does a modern i386 really require them?  DOS compatibility is no 
> longer an issue for commodity hardware and the ISA bridge is gone.

Untrue on both counts

> Apparently the only legacy device still not replaced by anything else is 
> the RTC, which is rather surprising as there seems to be a lot of 
> reasonable alternatives for I2C available these days and i386 boxes have 
> had I2C for quite a while now.

DMA controller, floppy controller, keyboard, serial, mouse, parallel,
some video ports, random other objects on the lpc bus, miscellaneous
motherboard gunge.

>  Both IDE and video are distinct PCI devices these days, so there is no 
> need for them to hide their decoded address ranges.  I've thought that has 
> been sorted out.

We still support older machines that are pre PCI even. Most PC systems
also have ranges of non-PCI decoded space that appears in no PCI bar.

Alan

Re: PATCH: IDE - sensible probing for PCI systems

[Maciej W. Rozycki]

On Thu, 23 Jun 2005, Alan Cox wrote:

> >  Besides, does a modern i386 really require them?  DOS compatibility is no 
> > longer an issue for commodity hardware and the ISA bridge is gone.
> 
> Untrue on both counts

 I really mean *commodity* -- I haven't seen a single DOS installation for 
a few years now.  For specialized uses special hardware can be used.  
Add-on boards with a PCI-ISA bridge and ISA slots do also exist for this 
very reason; well, I have even seen USB-ISA "bridges".

> > Apparently the only legacy device still not replaced by anything else is 
> > the RTC, which is rather surprising as there seems to be a lot of 
> > reasonable alternatives for I2C available these days and i386 boxes have 
> > had I2C for quite a while now.
> 
> DMA controller, floppy controller, keyboard, serial, mouse, parallel,
> some video ports, random other objects on the lpc bus, miscellaneous
> motherboard gunge.

 Well, keyboard and mouse are USB these days, serial and parallel are PCI, 
floppies are not used anymore and the ISA DMA controller would only be 
needed for them.  Video?  I've thought ISA implementations are gone -- 
what is all that AGP/PCI-E noise about then?  And no more ISA slots 
either.

 Other objects?  Do you mean the pre-i486 FPU error or the A20 line 
latches?  They are not really needed either, are they?  There's some NMI 
logic, though, which hasn't been moved elsewhere, indeed.  I think it 
really belongs to the PCI configuration space somewhere -- probably I/O 
APICs or host bridges.

 Of course if a manufacturer wants to put all the legacy in their system, 
it's their choice, but there is no need anymore.

> >  Both IDE and video are distinct PCI devices these days, so there is no 
> > need for them to hide their decoded address ranges.  I've thought that has 
> > been sorted out.
> 
> We still support older machines that are pre PCI even. Most PC systems

 Certainly we do and we will do for the forseeable future.

> also have ranges of non-PCI decoded space that appears in no PCI bar.

 That is what surprises me and what my whole consideration is about.  
It's just I don't see a need for such a setup anymore and for a system 
with no ISA or EISA bridge I'd expect all that legacy to be gone leaving 
us with no need to handle implicit resources.  But has any manufacturer 
produced such an i386 system yet?

  Maciej

Re: PATCH: IDE - sensible probing for PCI systems

[Jeff Garzik]

Maciej W. Rozycki wrote:
>  Well, keyboard and mouse are USB these days, serial and parallel are PCI, 
> floppies are not used anymore and the ISA DMA controller would only be 

Oh, how I wish this were true!

The pre-production machines I get (i.e. not even on the market yet) 
still have floppy, serial, and PS/2 kbd/mouse.

	Jeff

Re: PATCH: IDE - sensible probing for PCI systems

[Maciej W. Rozycki]

On Fri, 24 Jun 2005, Jeff Garzik wrote:

> > Well, keyboard and mouse are USB these days, serial and parallel are PCI,
> > floppies are not used anymore and the ISA DMA controller would only be 
> 
> Oh, how I wish this were true!
> 
> The pre-production machines I get (i.e. not even on the market yet) still have
> floppy, serial, and PS/2 kbd/mouse.

 You must be getting them from wrong vendors. ;-)  How about switching to 
a reasonable platform that doesn't imply DOS compatibility?

  Maciej

Re: PATCH: IDE - sensible probing for PCI systems

[Bill Davidsen]

Maciej W. Rozycki wrote:
> On Fri, 24 Jun 2005, Jeff Garzik wrote:
> 
> 
>>>Well, keyboard and mouse are USB these days, serial and parallel are PCI,
>>>floppies are not used anymore and the ISA DMA controller would only be 
>>
>>Oh, how I wish this were true!
>>
>>The pre-production machines I get (i.e. not even on the market yet) still have
>>floppy, serial, and PS/2 kbd/mouse.
> 
> 
>  You must be getting them from wrong vendors. ;-)  How about switching to 
> a reasonable platform that doesn't imply DOS compatibility?

What's reasonable about a system without serial connectivity? Damn hard 
to debug with a serial console without one. Yes you can get around it, 
but it's one more issue to address. PS/2? I have enough KVM hardware in 
place to make that non-sales point, and I bet that there are lots of 
people with some fancy mouse, or keyboard, or game thingie, that it's 
cheaper to keep the features than drop them. I don't know if the ATX 
standard requires them, but low cost features are hard to drop.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: PATCH: IDE - sensible probing for PCI systems

[Alan Cox]

On Gwe, 2005-06-24 at 12:52, Maciej W. Rozycki wrote:
>  Well, keyboard and mouse are USB these days, serial and parallel are PCI, 
> floppies are not used anymore and the ISA DMA controller would only be 
> needed for them.  Video?  I've thought ISA implementations are gone -- 
> what is all that AGP/PCI-E noise about then?  And no more ISA slots 
> either.

PC systems have serial at 0x3f8/0x2f8 (lpc bus), almost always PS/2 port
on the mainboard. Timers, interrupt controllers. 

> logic, though, which hasn't been moved elsewhere, indeed.  I think it 
> really belongs to the PCI configuration space somewhere -- probably I/O 
> APICs or host bridges.

As I understand it both Windows XP and Linux x86 still require some of
these ports. There is also a range of ports that are needed _before_ the
PCI bus can be used in order to bootstrap the system, configure ram
timings etc and in some cases adjust the caches.

> > also have ranges of non-PCI decoded space that appears in no PCI bar.
> 
>  That is what surprises me and what my whole consideration is about.  
> It's just I don't see a need for such a setup anymore and for a system 
> with no ISA or EISA bridge I'd expect all that legacy to be gone leaving 
> us with no need to handle implicit resources.  But has any manufacturer 
> produced such an i386 system yet?

Whats the _economic_ incentive to do so ? There basically isnt one.

Re: PATCH: IDE - sensible probing for PCI systems

[Maciej W. Rozycki]

On Sat, 25 Jun 2005, Alan Cox wrote:

> PC systems have serial at 0x3f8/0x2f8 (lpc bus), almost always PS/2 port

 Strange -- boxes have started to appear that have no connectors or at 
least PCB headers for them.  What's the point in removing connectors and 
leaving the (otherwise useful) hardware inaccessible?

> on the mainboard. Timers, interrupt controllers. 

 Indeed, but APICs make them redundant.  I recall ACPI has defined 
additional "board" timers as well, hasn't it?

> As I understand it both Windows XP and Linux x86 still require some of
> these ports. There is also a range of ports that are needed _before_ the

 Adjusting software to get rid of these requirements should be pretty 
straightforward -- there are really very few these days.  In Linux that is 
-- I can't comment the others, but Intel has recommended against using the 
PITs or the PICs as implemented by the PC/AT standard for some ten years 
now and "the others" follow these guidelines more closely it would seem.  
In particular for a "legacy-free" box I can't see any problem with leaving 
the firmware upon bootstrap with the APIC mode already set up.  Perhaps 
even in the protected mode.

> PCI bus can be used in order to bootstrap the system, configure ram
> timings etc and in some cases adjust the caches.

 Well, that should normally be done using PCI configuration(!) space (it's 
been invented for that purpose after all) of host bridges.  Some tasks may 
require poking at I2C mapped somewhere, but the space for that device may 
be properly handled with BARs.  Or it can be system-specific and disabled 
after initial setup -- I've seen systems with a minimal I2C controller 
wired directly to the CPU bus and a full-blown one available in a south 
bridge with the former being able to be disabled once unneeded.

> >  That is what surprises me and what my whole consideration is about.  
> > It's just I don't see a need for such a setup anymore and for a system 
> > with no ISA or EISA bridge I'd expect all that legacy to be gone leaving 
> > us with no need to handle implicit resources.  But has any manufacturer 
> > produced such an i386 system yet?
> 
> Whats the _economic_ incentive to do so ? There basically isnt one.

 One chip less?  Well, perhaps the cost of R&D for such a system would 
exceed the total cost of keeping that chip included in all boards 
manufactured during the term corporate planning is able to cover....

  Maciej

Re: PATCH: IDE - sensible probing for PCI systems

[Russell King]

On Mon, Jun 27, 2005 at 03:55:39PM +0100, Maciej W. Rozycki wrote:
> On Sat, 25 Jun 2005, Alan Cox wrote:
> 
> > PC systems have serial at 0x3f8/0x2f8 (lpc bus), almost always PS/2 port
> 
>  Strange -- boxes have started to appear that have no connectors or at 
> least PCB headers for them.  What's the point in removing connectors and 
> leaving the (otherwise useful) hardware inaccessible?

It's far easier for a mobo manufacturer to remove the connectors and
PCB tracking for the connections.  For all we know, PCI southbridges
with serial ports integrated into them may still be cheaper in quantity
than ones without - so if mobo manufacturers want to get rid of the
serial ports their easiest way is to omit the connectors and associated
PCB tracks.

> > >  That is what surprises me and what my whole consideration is about.  
> > > It's just I don't see a need for such a setup anymore and for a system 
> > > with no ISA or EISA bridge I'd expect all that legacy to be gone leaving 
> > > us with no need to handle implicit resources.  But has any manufacturer 
> > > produced such an i386 system yet?
> > 
> > Whats the _economic_ incentive to do so ? There basically isnt one.
> 
>  One chip less?  Well, perhaps the cost of R&D for such a system would 
> exceed the total cost of keeping that chip included in all boards 
> manufactured during the term corporate planning is able to cover....

The southbridge typically contains the other things like the RTC, etc.
What you're suggesting isn't just a case of "removing a chip" - it's
more a case of designing a replacement without a lot of the legacy
stuff in.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: PATCH: IDE - sensible probing for PCI systems

[Alan Cox]

On Llu, 2005-06-27 at 15:55, Maciej W. Rozycki wrote:
>  Strange -- boxes have started to appear that have no connectors or at 
> least PCB headers for them.  What's the point in removing connectors and 
> leaving the (otherwise useful) hardware inaccessible?

It saves external components, buffers etc and makes it easier to pass
FCC and CE emissions testing, while removing it from the chip means two
chips and that costs money

> > Whats the _economic_ incentive to do so ? There basically isnt one.
> 
>  One chip less?  Well, perhaps the cost of R&D for such a system would 
> exceed the total cost of keeping that chip included in all boards 
> manufactured during the term corporate planning is able to cover....

A PC with all the LPC bus goodies is generally a three chip solution
anyway. The ISA bus vanished, some bits got integrated and an LPC bus
was added. By now the LPC bus and its contents have all vanished into
the onboard logic too.