login
Search
For what it is worth I too have seen this problem this morning and it
DOES appear to be new (in contrast to a previous comment)The message: pnpacpi: exceeded the max number of mem resources: 12
is displayed each time the system is booted with the 2.6.24-rc3-git5
kernel but is NOT displayed when booting 2.6.24-rc3-git4I have made no changes in my config file between these two kernels other
than to accept any new defaults when running make oldconfig.If you had already narrowed it down to a change between git4 and git5 I
apologize for wasting your time. Have to run to work now.Chris
-
Thanks, and re-added the proper CCs. Sigh...
Well, yes, the warning is actually new as well. Previously your kernel just
silently ignored 8 more mem resources than it does now it seems.Given that people are hitting these limits, it might make sense to just do
away with the warning for 2.6.24 again while waiting for the dynamic code?Rene.
-
Ping. Should these warnings be reverted for 2.6.24?
Rene.
--
No. I don't think hiding this issue again is a good idea.
I'd rather live with people complaining about an addition dmesg line.-Len
--
We're not talking about "a" additional line. In my case [1] we're talking
about 22 (!) additional identical lines.Not fixing this before 2.6.24 seems completely inconsistent:
- either this is a real bug and the ERR level message is correct, in which
case the limits should be increased;
- or hitting the limits is harmless and the message should be changed to
DEBUG level.It is great to hear that the memory allocation will become dynamic in the
future and maybe that could just justify your standpoint, but having the
messages is damn ugly and alarming from a user point of view.Please keep in mind that depending on distro release schedules, 2.6.24 could
live for quite a bit longer than just the period needed to release 2.6.25
(if that is when the dynamic allocation will be implemented).Cheers,
FJP
On 09-01-08 10:34, Frans Pop wrote:
You lucky devil. Someone else reported 92 if I remember rightly. This really
needs to be called a 2.6.24 bug. Stick the word "regression" in the subject
line and someone will notice...The warning might provide useful information to someone looking at a dmesg
but given that people are hitting them way too hard with the only difference
versus 2.6.23 being tke kernel now complaining about it, they're not useful
enough to be printed more than once, or at more then DEBUG level or even at
all in fact since we already know the static limit isn't enough for everyone
and needs be turned dynamic -- really, what else is someone going to debug
with it?I'd consider Bjorn Helgaas the PnP maintainer and he earlier agreed that
this needed something:http://lkml.org/lkml/2007/12/5/301
Printing the warning only once per type as per attached fixes the problenm
as well.
I noticed the port number changed to 40 in 2.6.24-rc8, but it's not
enough for me still.Regards
dave
--
Same here, though the extreme noise has gone.
From /proc/ioports and dmesg it looks like I'm short by either 1, or 3 :-(Cheers,
FJP
--
Yup. It should be no worse than in 2.6.23, where we silently ignored
excess resources. We plan to fix it for real in 2.6.25.
--
Yes, that's known. In .23 even more were (silently) ignored though. Since
.24-rc8 you should at least get just 1 warning (per resource type) and if
all's well .25 should kill the static limit completely.Rene.
--
Assuming, that is, that Linus would've applied Len's trivial fix here:
Rene.
--
Revert the warning doesn't make any sense. I'd suggest changing the IO
resources number bigger till Thomas's patch in.Shaohua
--
Agree.
Change it to 90 works for me, But I think maybe 128 is better.include/linux/pnp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)diff -upr linux/include/linux/pnp.h linux.new/include/linux/pnp.h
--- linux/include/linux/pnp.h 2007-12-04 09:09:23.000000000 +0800
+++ linux.new/include/linux/pnp.h 2007-12-04 09:09:40.000000000 +0800
@@ -13,7 +13,7 @@
#include <linux/errno.h>
#include <linux/mod_devicetable.h>-#define PNP_MAX_PORT 24
+#define PNP_MAX_PORT 128
#define PNP_MAX_MEM 12
#define PNP_MAX_IRQ 2
#define PNP_MAX_DMA 2
--
I don't think we can increase PNP_MAX_PORT to 128. Only one or two
devices need that many, so just bumping the max wastes a LOT of space.
A struct resource is seven longs, so on a 32-bit system with sixteen
PNP devices, we'd be wasting (128-24)*7*4*16 = almost 47Kbytes.In hindsight, I should not have removed drivers/acpi/motherboard.c
until we had dynamic PNP resource tables. We could revert that
change [1], but the driver's been gone since 2.6.21, so I don't
think it's that urgent. It's just that we used to silently ignore
resources past the limits, and in -mm, we now print a KERN_ERR message.So I think we should either remove the message altogether (so we're
exactly like 2.6.23 in this regard), or at least tone it down to
a KERN_WARN or something.And we need to get Thomas' dynamic patch into -mm ASAP :-)
Bjorn
[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi...
--
Rene -
Thanks for the follow up - from my perspective now that I know that the
condition that caused the warning messages has been with us for some
time, and that previously the messages were suppressed it really does
not make that much difference to me if the warnings are reverted or not.So I guess that I vote for doing whatever is best for the developer.
After all they are the ones doing the heavy lifting. If the warning
message is able to provide some insight into the problem so much the
better.At this point my goal is just to learn enough to be an asset as a tester
instead of a net loss (defined as someone whose efforts cost the team
more man-hours than their contribution is worth)Chris
--
