PATCH: IDE - sensible probing for PCI systems
Alan Cox
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 <al...@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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Maciej W. Rozycki
> 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
Alan Cox
> 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 ?
Maciej W. Rozycki
> > > 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
Alan Cox
> 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
Maciej W. Rozycki
> > 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
Alan Cox
> 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
Maciej W. Rozycki
> > 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
Jeff Garzik
> 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
Alan Cox
> 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.
Maciej W. Rozycki
> > 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
Maciej W. Rozycki
> 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
Russell King
> 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
Alan Cox
> 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.
Bill Davidsen
> 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 (davi...@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me