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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
