Hey,
On Mon, Mar 22, 2010 at 03:28:55PM -0700, Bjorn Helgaas wrote:
> On Monday 22 March 2010 02:51:21 pm Dominik Brodowski wrote:
> > On Mon, Mar 22, 2010 at 01:36:03PM -0700, Bjorn Helgaas wrote:
> > > > You can still use subtractive-decoded resources, but then you have to add
> > > > them to /etc/pcmcia/config.opts and run pcmcia-startup-bridges (or echo the
> > > > resource to a sysfs file).
> > >
> > > It's too bad we still have such manual configuration.
> >
> > Agreed.
> >
> > > Is there still
> > > information there that we can't figure out automatically?
> >
> > That's unknown to me -- are there any ISA-capable systems being sold? If so,
> > then I suspect the answer may be "yes".
> >
> > > > Now, "usecrs" is only used on 2008-or-newer systems where we _hope_ that all
> > > > resource "consumers" are accounted for. So the problem might be mitigated.
> > > > However, I wouldn't dare to use ioports 0x0-0xff anyways for they usually
> > > > are used for onboard legacy devices...
> > >
> > > Right. But PCMCIA is at no greater risk than regular PCI, right?
> > > It looks like both will allocate only above PCIBIOS_MIN_IO (0x1000).
> >
> > No, PCMCIA will happily allocate below this limit.
>
> I saw "#define PCIBIOS_MIN_CARDBUS_IO PCIBIOS_MIN_IO" in yenta_socket.c
> and assumed it would take care of this, but I didn't look any deeper.
>
> I'm still confused about why PCMCIA is "special" in this regard and
> why pci=use_crs breaks it. Can you make up an example that illustrates
> the problem?
Consider the following case:
(1) The root PCI bus has _CRS I/O 0000-0cf7; 0d00-ffff "produced";
the (transparent) PCI-PCI bridge offers, as bus resources, to
downstream users 0x4000-0x4fff plus everything else because of
subtractive decoding;
there is a yenta-style PCI-CardBus/PCMCIA bridge below this
PCI-PCI bridge.
(2) There are some I/O ports which react rather unfriendly to being read or
written. Let's assume they're at 0x100-0x10f; and let's also assume that
the BIOS writers forgot to mention them at all in the ACPI _CRS
settings; no other part of the kernel knows about it.
0000-0cf7 : PCI Bus 0000:00
...
00f0-00ff : fpu
0170-0177 : 0000:00:1f.2
(3) A PCMCIA card is inserted. It needs an I/O port resource of size 8. The
PCMCIA subsystem looks in its own resource database which I/O ports it
may use; there, it finds not only 0x4000-0x4fff but (with a small
exception) 0x0000-0xffff; as 0x0000-0x00ff are already assigned, it
happily assigns the first free area -- 0x100-0x108 -- to the PCMCIA
card.
0000-0cf7 : PCI Bus 0000:00
...
00f0-00ff : fpu
0100-0108 : pcmcia0.0
0170-0177 : 0000:00:1f.2
(4) The PCMCIA card and the PCMCIA driver are set up to work with an IO
resource at 0x100-0x108. As soon as they attempt to use this resource,
bad things happen (lockups, etc.) because of the reasons spelled out at
(2).
=> It is only an issue if the ACPI resource descriptions are incomplete. It
is worse for PCMCIA because it happily assigns resources below 0x1000, where
such system/platform devices usually listen to. And usecrs worsens the
situation also in another regard: on my own laptop (a pre-2008 model),
pci=use_crs makes the PCI-PCI bridge to be marked as "transparent", while
pci=nocrs means the PCI-PCI bridge is assumed to be "non-transparent".
Best,
Dominik
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
