* Re: ACPIPNP and too large IO resources
[not found] ` <44AC26DA.1010901@drzeus.cx>
@ 2006-07-05 21:36 ` Bjorn Helgaas
2006-07-05 22:18 ` Andrew Morton
0 siblings, 1 reply; 6+ messages in thread
From: Bjorn Helgaas @ 2006-07-05 21:36 UTC (permalink / raw)
To: Pierre Ossman, Andrew Morton
Cc: Len Brown, LKML, Adam Belay, Shaohua Li, castet.matthieu,
linux-acpi, uwe.bugla
On Wednesday 05 July 2006 14:53, Pierre Ossman wrote:
> Bjorn Helgaas wrote:
> > It sounds like this might be the same problem as
> > http://bugzilla.kernel.org/show_bug.cgi?id=6292
> >
> > In short, you probably have a bridge device that consumes the
> > entire 0x0-0xffff I/O port range and produces some or all of that
> > range for downstream PNP devices. PNP doesn't know what to do
> > with these windows that are both consumed by the bridge and made
> > available to downstream devices, so it just marks them as being
> > already reserved.
>
> Ah, that explains things.
>
> > Matthieu Castet wrote a nice patch (attached) that makes PNP just
> > ignore those windows. Can you try it and see whether it fixes
> > the problem you're seeing? This patch is already in -mm, but not
> > yet in mainline. We might need to consider this patch as
> > 2.6.18 material if it resolves your problem. I suspect many
> > people will see the same problem.
>
> The patch works nicely and removes all memory and io regions for the PCI
> bridge but for the range 0xcf8-0xcff.
Andrew, I think we should try again to push
pnpacpi-reject-acpi_producer-resources.patch to the mainline.
Pierre's report (starts here: http://lkml.org/lkml/2006/7/5/20)
is another instance of http://bugzilla.kernel.org/show_bug.cgi?id=6292.
I suspect that many PNP devices are broken in 2.6.17 because of
this problem. Probably the only reason we haven't seen more
reports is that PNPACPI isn't turned on by default. (Maybe
we should do that in -mm?)
You recently proposed pushing it:
http://marc.theaimsgroup.com/?l=linux-acpi&m=115119275408021&w=2
Len initially nacked it, but I think the outcome of the discussion
is that Shaohua doesn't object to this patch. He probably would
still like to blacklist PNP0A03, but that's an additional step we
don't have to take at the same time.
Bjorn
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ACPIPNP and too large IO resources
2006-07-05 21:36 ` ACPIPNP and too large IO resources Bjorn Helgaas
@ 2006-07-05 22:18 ` Andrew Morton
2006-07-06 15:29 ` Bjorn Helgaas
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2006-07-05 22:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: drzeus-list, len.brown, linux-kernel, ambx1, shaohua.li,
castet.matthieu, linux-acpi, uwe.bugla
Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>
> On Wednesday 05 July 2006 14:53, Pierre Ossman wrote:
> > Bjorn Helgaas wrote:
> > > It sounds like this might be the same problem as
> > > http://bugzilla.kernel.org/show_bug.cgi?id=6292
> > >
> > > In short, you probably have a bridge device that consumes the
> > > entire 0x0-0xffff I/O port range and produces some or all of that
> > > range for downstream PNP devices. PNP doesn't know what to do
> > > with these windows that are both consumed by the bridge and made
> > > available to downstream devices, so it just marks them as being
> > > already reserved.
> >
> > Ah, that explains things.
> >
> > > Matthieu Castet wrote a nice patch (attached) that makes PNP just
> > > ignore those windows. Can you try it and see whether it fixes
> > > the problem you're seeing? This patch is already in -mm, but not
> > > yet in mainline. We might need to consider this patch as
> > > 2.6.18 material if it resolves your problem. I suspect many
> > > people will see the same problem.
> >
> > The patch works nicely and removes all memory and io regions for the PCI
> > bridge but for the range 0xcf8-0xcff.
>
> Andrew, I think we should try again to push
> pnpacpi-reject-acpi_producer-resources.patch to the mainline.
>
> Pierre's report (starts here: http://lkml.org/lkml/2006/7/5/20)
> is another instance of http://bugzilla.kernel.org/show_bug.cgi?id=6292.
>
> I suspect that many PNP devices are broken in 2.6.17 because of
> this problem. Probably the only reason we haven't seen more
> reports is that PNPACPI isn't turned on by default. (Maybe
> we should do that in -mm?)
>
> You recently proposed pushing it:
> http://marc.theaimsgroup.com/?l=linux-acpi&m=115119275408021&w=2
> Len initially nacked it, but I think the outcome of the discussion
> is that Shaohua doesn't object to this patch. He probably would
> still like to blacklist PNP0A03, but that's an additional step we
> don't have to take at the same time.
>
OK, well let's please push this up the priority list and work out what want
to do. If Len's now OK with merging it then I think all lights are green?
pnpacpi-reject-acpi_producer-resources.patch:
From: matthieu castet <castet.matthieu@free.fr>
A patch in -mm kernel correct the parsing of "address resources" of pnpacpi.
Before we assumed it was memory only, but it could be also IO.
But this change show an hidden bug : some resources could be producer type
that are not handled by pnp layer. So we should ignore the producer
resources.
This patch fixes bug 6292 (http://bugzilla.kernel.org/show_bug.cgi?id=6292).
Some devices like PNP0A03 have 0xd00-0xffff and 0x0-0xcf7 as IO producer
resources.
Before correcting "address resources" parsing, it was seen as memory and was
harmless, because nobody tried to reserve this memory range as it should be
IO.
With the correction it become IO resources, and make failed all others device
that want to register IO in this range and use pnp layer (like a ISA sound
card).
The solution is to ignore producer resources
Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
Signed-off-by: Uwe Bugla <uwe.bugla@gmx.de>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Adam Belay <ambx1@neo.rr.com>
Cc: "Brown, Len" <len.brown@intel.com>
akpm: previously nacked, as per comment #26. But am hanging onto it until the
thing gets fixed for real.
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/pnp/pnpacpi/rsparser.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff -puN drivers/pnp/pnpacpi/rsparser.c~pnpacpi-reject-acpi_producer-resources drivers/pnp/pnpacpi/rsparser.c
--- a/drivers/pnp/pnpacpi/rsparser.c~pnpacpi-reject-acpi_producer-resources
+++ a/drivers/pnp/pnpacpi/rsparser.c
@@ -173,6 +173,9 @@ pnpacpi_parse_allocated_address_space(st
return;
}
+ if (p->producer_consumer == ACPI_PRODUCER)
+ return;
+
if (p->resource_type == ACPI_MEMORY_RANGE)
pnpacpi_parse_allocated_memresource(res_table,
p->minimum, p->address_length);
@@ -252,9 +255,14 @@ static acpi_status pnpacpi_allocated_res
break;
case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
+ if (res->data.ext_address64.producer_consumer == ACPI_PRODUCER)
+ return AE_OK;
break;
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+ if (res->data.extended_irq.producer_consumer == ACPI_PRODUCER)
+ return AE_OK;
+
for (i = 0; i < res->data.extended_irq.interrupt_count; i++) {
pnpacpi_parse_allocated_irqresource(res_table,
res->data.extended_irq.interrupts[i],
_
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ACPIPNP and too large IO resources
2006-07-05 22:18 ` Andrew Morton
@ 2006-07-06 15:29 ` Bjorn Helgaas
2006-07-07 1:03 ` Shaohua Li
0 siblings, 1 reply; 6+ messages in thread
From: Bjorn Helgaas @ 2006-07-06 15:29 UTC (permalink / raw)
To: Andrew Morton
Cc: drzeus-list, len.brown, linux-kernel, ambx1, shaohua.li,
castet.matthieu, linux-acpi, uwe.bugla
On Wednesday 05 July 2006 16:18, Andrew Morton wrote:
> Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> > You recently proposed pushing it:
> > http://marc.theaimsgroup.com/?l=linux-acpi&m=115119275408021&w=2
> > Len initially nacked it, but I think the outcome of the discussion
> > is that Shaohua doesn't object to this patch. He probably would
> > still like to blacklist PNP0A03, but that's an additional step we
> > don't have to take at the same time.
>
> OK, well let's please push this up the priority list and work out what want
> to do. If Len's now OK with merging it then I think all lights are green?
My opinion is that we don't need to blacklist PNP0A03 unless
we discover a problem.
Len, Shaohua, can you ack this?
> pnpacpi-reject-acpi_producer-resources.patch:
>
> From: matthieu castet <castet.matthieu@free.fr>
>
> A patch in -mm kernel correct the parsing of "address resources" of pnpacpi.
> Before we assumed it was memory only, but it could be also IO.
>
> But this change show an hidden bug : some resources could be producer type
> that are not handled by pnp layer. So we should ignore the producer
> resources.
>
> This patch fixes bug 6292 (http://bugzilla.kernel.org/show_bug.cgi?id=6292).
> Some devices like PNP0A03 have 0xd00-0xffff and 0x0-0xcf7 as IO producer
> resources.
>
> Before correcting "address resources" parsing, it was seen as memory and was
> harmless, because nobody tried to reserve this memory range as it should be
> IO.
>
> With the correction it become IO resources, and make failed all others device
> that want to register IO in this range and use pnp layer (like a ISA sound
> card).
>
> The solution is to ignore producer resources
>
> Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
> Signed-off-by: Uwe Bugla <uwe.bugla@gmx.de>
> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Cc: Adam Belay <ambx1@neo.rr.com>
> Cc: "Brown, Len" <len.brown@intel.com>
>
> akpm: previously nacked, as per comment #26. But am hanging onto it until the
> thing gets fixed for real.
>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
>
> drivers/pnp/pnpacpi/rsparser.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff -puN drivers/pnp/pnpacpi/rsparser.c~pnpacpi-reject-acpi_producer-resources drivers/pnp/pnpacpi/rsparser.c
> --- a/drivers/pnp/pnpacpi/rsparser.c~pnpacpi-reject-acpi_producer-resources
> +++ a/drivers/pnp/pnpacpi/rsparser.c
> @@ -173,6 +173,9 @@ pnpacpi_parse_allocated_address_space(st
> return;
> }
>
> + if (p->producer_consumer == ACPI_PRODUCER)
> + return;
> +
> if (p->resource_type == ACPI_MEMORY_RANGE)
> pnpacpi_parse_allocated_memresource(res_table,
> p->minimum, p->address_length);
> @@ -252,9 +255,14 @@ static acpi_status pnpacpi_allocated_res
> break;
>
> case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
> + if (res->data.ext_address64.producer_consumer == ACPI_PRODUCER)
> + return AE_OK;
> break;
>
> case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> + if (res->data.extended_irq.producer_consumer == ACPI_PRODUCER)
> + return AE_OK;
> +
> for (i = 0; i < res->data.extended_irq.interrupt_count; i++) {
> pnpacpi_parse_allocated_irqresource(res_table,
> res->data.extended_irq.interrupts[i],
> _
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ACPIPNP and too large IO resources
2006-07-06 15:29 ` Bjorn Helgaas
@ 2006-07-07 1:03 ` Shaohua Li
2006-08-05 0:19 ` Pierre Ossman
0 siblings, 1 reply; 6+ messages in thread
From: Shaohua Li @ 2006-07-07 1:03 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Andrew Morton, drzeus-list, Brown, Len, linux-kernel, ambx1,
castet.matthieu, linux-acpi, uwe.bugla
On Thu, 2006-07-06 at 23:29 +0800, Bjorn Helgaas wrote:
> On Wednesday 05 July 2006 16:18, Andrew Morton wrote:
> > Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> > > You recently proposed pushing it:
> > >
> http://marc.theaimsgroup.com/?l=linux-acpi&m=115119275408021&w=2
> > > Len initially nacked it, but I think the outcome of the
> discussion
> > > is that Shaohua doesn't object to this patch. He probably would
> > > still like to blacklist PNP0A03, but that's an additional step we
> > > don't have to take at the same time.
> >
> > OK, well let's please push this up the priority list and work out
> what want
> > to do. If Len's now OK with merging it then I think all lights are
> green?
>
> My opinion is that we don't need to blacklist PNP0A03 unless
> we discover a problem.
>
> Len, Shaohua, can you ack this?
Sure. Please merge the patch Bjorn pointed out.
Thanks,
Shaohua
>
> > pnpacpi-reject-acpi_producer-resources.patch:
> >
> > From: matthieu castet <castet.matthieu@free.fr>
> >
> > A patch in -mm kernel correct the parsing of "address resources" of
> pnpacpi.
> > Before we assumed it was memory only, but it could be also IO.
> >
> > But this change show an hidden bug : some resources could be
> producer type
> > that are not handled by pnp layer. So we should ignore the
> producer
> > resources.
> >
> > This patch fixes bug 6292
> (http://bugzilla.kernel.org/show_bug.cgi?id=6292).
> > Some devices like PNP0A03 have 0xd00-0xffff and 0x0-0xcf7 as IO
> producer
> > resources.
> >
> > Before correcting "address resources" parsing, it was seen as memory
> and was
> > harmless, because nobody tried to reserve this memory range as it
> should be
> > IO.
> >
> > With the correction it become IO resources, and make failed all
> others device
> > that want to register IO in this range and use pnp layer (like a ISA
> sound
> > card).
> >
> > The solution is to ignore producer resources
> >
> > Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
> > Signed-off-by: Uwe Bugla <uwe.bugla@gmx.de>
> > Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
> > Cc: Adam Belay <ambx1@neo.rr.com>
> > Cc: "Brown, Len" <len.brown@intel.com>
> >
> > akpm: previously nacked, as per comment #26. But am hanging onto it
> until the
> > thing gets fixed for real.
> >
> > Signed-off-by: Andrew Morton <akpm@osdl.org>
> > ---
> >
> > drivers/pnp/pnpacpi/rsparser.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff -puN
> drivers/pnp/pnpacpi/rsparser.c~pnpacpi-reject-acpi_producer-resources
> drivers/pnp/pnpacpi/rsparser.c
> > ---
> a/drivers/pnp/pnpacpi/rsparser.c~pnpacpi-reject-acpi_producer-resources
> > +++ a/drivers/pnp/pnpacpi/rsparser.c
> > @@ -173,6 +173,9 @@ pnpacpi_parse_allocated_address_space(st
> > return;
> > }
> >
> > + if (p->producer_consumer == ACPI_PRODUCER)
> > + return;
> > +
> > if (p->resource_type == ACPI_MEMORY_RANGE)
> > pnpacpi_parse_allocated_memresource(res_table,
> > p->minimum, p->address_length);
> > @@ -252,9 +255,14 @@ static acpi_status pnpacpi_allocated_res
> > break;
> >
> > case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
> > + if (res->data.ext_address64.producer_consumer ==
> ACPI_PRODUCER)
> > + return AE_OK;
> > break;
> >
> > case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> > + if (res->data.extended_irq.producer_consumer ==
> ACPI_PRODUCER)
> > + return AE_OK;
> > +
> > for (i = 0; i <
> res->data.extended_irq.interrupt_count; i++) {
> >
> pnpacpi_parse_allocated_irqresource(res_table,
> > res->data.extended_irq.interrupts[i],
> > _
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ACPIPNP and too large IO resources
2006-07-07 1:03 ` Shaohua Li
@ 2006-08-05 0:19 ` Pierre Ossman
2006-08-05 1:07 ` Andrew Morton
0 siblings, 1 reply; 6+ messages in thread
From: Pierre Ossman @ 2006-08-05 0:19 UTC (permalink / raw)
To: Shaohua Li
Cc: Bjorn Helgaas, Andrew Morton, Brown, Len, linux-kernel, ambx1,
castet.matthieu, linux-acpi, uwe.bugla
Shaohua Li wrote:
> Sure. Please merge the patch Bjorn pointed out.
>
So? What's the status of this? Still not in Linus' tree.
Rgds
Pierre
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ACPIPNP and too large IO resources
2006-08-05 0:19 ` Pierre Ossman
@ 2006-08-05 1:07 ` Andrew Morton
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Morton @ 2006-08-05 1:07 UTC (permalink / raw)
To: Pierre Ossman
Cc: shaohua.li, bjorn.helgaas, len.brown, linux-kernel, ambx1,
castet.matthieu, linux-acpi, uwe.bugla
On Sat, 05 Aug 2006 02:19:46 +0200
Pierre Ossman <drzeus-list@drzeus.cx> wrote:
> Shaohua Li wrote:
> > Sure. Please merge the patch Bjorn pointed out.
> >
>
> So? What's the status of this? Still not in Linus' tree.
We have an ack from Shaohua. I'll merge it.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-08-05 1:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <44AB608F.1060903@drzeus.cx>
[not found] ` <200607051047.40734.bjorn.helgaas@hp.com>
[not found] ` <44AC26DA.1010901@drzeus.cx>
2006-07-05 21:36 ` ACPIPNP and too large IO resources Bjorn Helgaas
2006-07-05 22:18 ` Andrew Morton
2006-07-06 15:29 ` Bjorn Helgaas
2006-07-07 1:03 ` Shaohua Li
2006-08-05 0:19 ` Pierre Ossman
2006-08-05 1:07 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox