Re: [Bug #15124] PCI host bridge windows ignored (works withpci=use_crs)

From: Jesse Barnes
Date: Thu Jan 28 2010 - 14:03:44 EST

On Thu, 28 Jan 2010 10:20:04 -0800
Yinghai Lu <yinghai@xxxxxxxxxx> wrote:

> On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
> > On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
> >> On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
> >>> On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
> >
> >>>> 2. how about when apci is disabled?
> >>>
> >>> When ACPI is disabled, I think we just have to accept that we
> >>> lose some functionality. I don't see the need for alternate ways
> >>> to accomplish everything that ACPI does. It's becoming less and
> >>> less useful to disable ACPI; I think it's only interesting as a
> >>> debugging tool, and even then it's a sledgehammer.
> >>
> >> some systems when acpi is enabled could have interrupt storm.
> >> and have to disable acpi.
> >
> > We should fix that problem rather than just covering it up by
> > disabling ACPI. Can you provide any details?
> that is not covering problem. acpi just cause too many problems.
> systems using acpi hotplug support, and use acpi aml code to monitor
> the hotplug status instead of HW and after one or two days will have
> interrupt storm with sci/acpi interrupt aka 9.

But disabling it gets us into trouble too. When platforms are designed
for Linux, they may be designed to have ACPI disabled (though this is
probably rare for general purpose PCs and servers). However when
they're designed for Windows, they're generally designed to use ACPI,
so if we disable it we run the risk of hitting all sorts of bugs since
we're running in an untested configuration.

So fixing the issues with ACPI enabled seems like a better idea; after
all, presumably Windows works on this platform with ACPI enabled, why
shouldn't we?

But I'm speaking in general here; we'd have to dig into the details of
the particular problem you mention to figure out the best course of
action (but I'm still pretty sure it's not "disable ACPI").

Jesse Barnes, Intel Open Source Technology Center
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at