In commit a7839e960675b549f06209d18283d5cee2ce9261 the number of PNP resources
was increased. In testing, we've found that the 'exceeded' warnings still get
hit with quite high frequency. See https://bugzilla.redhat.com/show_bug.cgi?id=436589
for examples.
I added the debug patch below, which yielded an interesting output.
pnpacpi: exceeded the max number of mem resources. Max:12 Found:12
off by one somewhere ?
Dave
diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
index 6aa231e..0c22e41 100644
--- a/drivers/pnp/pnpacpi/rsparser.c
+++ b/drivers/pnp/pnpacpi/rsparser.c
@@ -86,7 +86,7 @@ static void pnpacpi_parse_allocated_irqresource(struct pnp_resource_table *res,
i++;
if (i >= PNP_MAX_IRQ && !warned) {
printk(KERN_ERR "pnpacpi: exceeded the max number of IRQ "
- "resources: %d \n", PNP_MAX_IRQ);
+ "resources. Max:%d Found:%d\n", PNP_MAX_IRQ, i);
warned = 1;
return;
}
@@ -188,7 +188,7 @@ static void pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table *res,
res->dma_resource[i].end = dma;
} else if (!warned) {
printk(KERN_ERR "pnpacpi: exceeded the max number of DMA "
- "resources: %d \n", PNP_MAX_DMA);
+ "resources. Max:%d Found:%d\n", PNP_MAX_DMA, i);
warned = 1;
}
}
@@ -214,7 +214,7 @@ static void pnpacpi_parse_allocated_ioresource(struct pnp_resource_table *res,
res->port_resource[i].end = io + len - 1;
} else if (!warned) {
printk(KERN_ERR "pnpacpi: exceeded the max number of IO "
- "resources: %d \n", PNP_MAX_PORT);
+ "resources. Max:%d Found:%d\n", PNP_MAX_PORT, i);
warned = 1;
}
}
@@ -242,7 +242,7 @@ static void pnpacpi_parse_allocated_memresource(struct pnp_resource_table *res,
res->mem_resource[i].end = mem + len - 1;
} else if (!warned) {
printk(KERN_ERR "pnpacpi: exceeded the max number of mem "
- "resources: %d\n", PNP_MAX_MEM);
+ "resources. Max:%d Found:%d\n", PNP_MAX_MEM, i);
warned = 1;
}
}
--
http://www.codemonkey.org.uk
On Wed, Mar 12, 2008 at 11:14:52AM -0400, Dave Jones wrote:
> In commit a7839e960675b549f06209d18283d5cee2ce9261 the number of PNP resources
> was increased. In testing, we've found that the 'exceeded' warnings still get
> hit with quite high frequency. See https://bugzilla.redhat.com/show_bug.cgi?id=436589
> for examples.
>
> I added the debug patch below, which yielded an interesting output.
>
> pnpacpi: exceeded the max number of mem resources. Max:12 Found:12
>
> off by one somewhere ?
No, your patch is just not giving out any additional information. 'i'
is the number of currently allocated resources, not the number asked
for. That number does not exist anywhere at that point as far as I
can see, you'll have to add a counter for it.
That looks valid for every resource type btw.
OG.
On Wednesday 12 March 2008, Dave Jones wrote:
> In commit a7839e960675b549f06209d18283d5cee2ce9261 the number of PNP resources
> was increased. In testing, we've found that the 'exceeded' warnings still get
> hit with quite high frequency. See https://bugzilla.redhat.com/show_bug.cgi?id=436589
In 2.6.23 we had:
#define PNP_MAX_PORT 8
#define PNP_MAX_MEM 4
And the kernel silently ignored a BIOS exceeding these limits
In 2.6.24 we have:
#define PNP_MAX_PORT 40
#define PNP_MAX_MEM 12
And the kernel complains with KERN_ERR when a BIOS has more resources
than the kernel can describe within these limits.
We know that there are cases where these static limits will be exceeded
but refrained from making these numbers larger due to concern about data structure size
and expectation that the majory of systems will fit within these limits.
(eg. there was one box with about 96 IO resources)
I agree that having a KERN_ERR that you know is going to fire is not a good situation.
We can either delete or KERN_DEBUG the message if it causes support issues --
for we know that <= 2.6.23 did worse by being silent.
Thomas worked on a patch to make resource allocation dynamic and do away
with these limits. Unfortunately it was rather large and it wasn't in
time for the 2.6.25-rc1 window. So right now we are on a trajectory
for 2.6.25 to behave exactly like 2.6.24.
Indeed, I don't think that patch made it into the test tree,
so unless we revive that patch, it will miss 2.6.26 as well.
thanks,
-Len
On 12-03-08 18:45, Len Brown wrote:
> Thomas worked on a patch to make resource allocation dynamic and do away
> with these limits. Unfortunately it was rather large and it wasn't in
> time for the 2.6.25-rc1 window. So right now we are on a trajectory
> for 2.6.25 to behave exactly like 2.6.24.
> Indeed, I don't think that patch made it into the test tree,
> so unless we revive that patch, it will miss 2.6.26 as well.
It rather violently broke ISAPnP.
Rene.
On Wed, 2008-03-12 at 13:45 -0400, Len Brown wrote:
> On Wednesday 12 March 2008, Dave Jones wrote:
...
> Thomas worked on a patch to make resource allocation dynamic and do away
> with these limits. Unfortunately it was rather large and it wasn't in
> time for the 2.6.25-rc1 window.
I had the problem that I could not test on isa systems.
Rene Herman helped here a lot.
There are still open issues, last state was (comment from Rene):
------------------------
No. Please note we're talking about ISAPnP, not PnPBIOS. No BIOS
involved at all.
Driver (sound/isa/cs423x/cs4236.c) furthermore does not use anything but
the PnP layer itself. Start at snd_cs423x_pnpc_detect, which is the
pnp .probe() method.
I'll look into providing a more extensive answer and/or test whatever
comes in later.
-------------------------
I can also look at this, any hints until then are appreciated.
I also expect Bjorn was bound to other bugs and pushing things in a rush
is not good thing anyway.
At the end I asked for a macro problem I only had a rather ugly
solution, didn't get an answer (IIRC I also added a compile bug in my
suggestions) and things got stuck...
Do you want me to rework the patches, lay out where I see problems and
give it another try to get this into -mm?
I am bound to work the next days, but it shouldn't be that much work
after all anymore to summarize things and send something (not sure about
the ISA things).
Hmm, maybe someone still can give a comment on my last one, it's still valid.
I want to check every pnp_{port,mem,irq,dma}_{start,end..} whether they are valid.
This macro does not work:
+#define pnp_port_start(dev,bar) (pnp_port_valid((dev),(bar)) ? (dev)->res.port_resource[(bar)].start \
+ : pnp_dbg("WARN: Port start %d - [%s] invalid - %s:%d", (bar), (dev->name), __FUNCTION__, __LINE__))
The only solution I see is to use small inline functions, but that would
blow up include/linux/pnp.h significantly. The idea of the inline
functions is stated here:
http://kerneltrap.org/mailarchive/linux-kernel/2008/2/6/743614
The warning can also be omitted (the drivers should have checked for
valid already - in theory...), but it should at least stay there at the
beginning to find drivers who do not check for valid before accessing
pnp_resource_table entries.
Thomas
On Thursday 13 March 2008 06:04:08 am Thomas Renninger wrote:
> On Wed, 2008-03-12 at 13:45 -0400, Len Brown wrote:
> > On Wednesday 12 March 2008, Dave Jones wrote:
> ...
> > Thomas worked on a patch to make resource allocation dynamic and do away
> > with these limits. Unfortunately it was rather large and it wasn't in
> > time for the 2.6.25-rc1 window.
>
> I had the problem that I could not test on isa systems.
> Rene Herman helped here a lot.
> There are still open issues, last state was (comment from Rene):
> ------------------------
> No. Please note we're talking about ISAPnP, not PnPBIOS. No BIOS
> involved at all.
>
> Driver (sound/isa/cs423x/cs4236.c) furthermore does not use anything but
> the PnP layer itself. Start at snd_cs423x_pnpc_detect, which is the
> pnp .probe() method.
>
> I'll look into providing a more extensive answer and/or test whatever
> comes in later.
> -------------------------
> I can also look at this, any hints until then are appreciated.
>
> I also expect Bjorn was bound to other bugs and pushing things in a rush
> is not good thing anyway.
> At the end I asked for a macro problem I only had a rather ugly
> solution, didn't get an answer (IIRC I also added a compile bug in my
> suggestions) and things got stuck...
>
> Do you want me to rework the patches, lay out where I see problems and
> give it another try to get this into -mm?
I'm sorry that I haven't responded to this. I have some reservations,
but I wanted to try out some alternate ideas before just being a nay-
sayer because usually my grand ideas turn out to have fatal flaws.
My current grand but untested idea is that struct pnp_resource_table
is too exposed and should be better abstracted, even inside the PNP
subsystem. Since PNP is supposed to be a way to discover platform
devices, I'm looking at the platform device interfaces for ideas.
Whatever we do, I think it has to be done incrementally to make it
reviewable and bisectable.
Bjorn
On 13-03-08 13:04, Thomas Renninger wrote:
> I had the problem that I could not test on isa systems.
Perhaps we can go organize a fundraiser for SuSE so they can go out and buy
an ISAPnP soundcard. I have a few I can sell. I promise I won't overcharge
them (much).
> Rene Herman helped here a lot.
> There are still open issues, last state was (comment from Rene):
> ------------------------
> No. Please note we're talking about ISAPnP, not PnPBIOS. No BIOS
> involved at all.
>
> Driver (sound/isa/cs423x/cs4236.c) furthermore does not use anything but
> the PnP layer itself. Start at snd_cs423x_pnpc_detect, which is the
> pnp .probe() method.
>
> I'll look into providing a more extensive answer and/or test whatever
> comes in later.
> -------------------------
Did look, but decided there wasn't much more specifically to add. It's
something more fundamental about the flow of things and while the comment
above is obviously cynical I did grow a bit tired of a series of patches
that just transported the OOPS two lines down again each time, so I held out
for Bjorn as well.
Still availabe for tests.
Rene.