LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Len Brown <lenb@kernel.org>
To: Dave Jones <davej@codemonkey.org.uk>,
	linux-acpi@vger.kernel.org, Adam M Belay <abelay@mit.edu>
Cc: Zhao Yakui <yakui.zhao@intel.com>,
	Li Shaohua <shaohua.li@intel.com>,
	Bjorn Helgaas <bjorn.helgaas@hp.com>,
	Thomas Renninger <trenn@suse.de>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: PNP: increase the maximum number of resources
Date: Wed, 12 Mar 2008 13:45:20 -0400	[thread overview]
Message-ID: <200803121345.21297.lenb@kernel.org> (raw)
In-Reply-To: <20080312151452.GA4523@codemonkey.org.uk>

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

  parent reply	other threads:[~2008-03-12 17:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-12 15:14 PNP: increase the maximum number of resources Dave Jones
2008-03-12 17:08 ` Olivier Galibert
2008-03-12 17:45 ` Len Brown [this message]
2008-03-13  0:16   ` Rene Herman
2008-03-13 12:04   ` PNP: dynamic pnp resources Thomas Renninger
2008-03-13 15:17     ` Bjorn Helgaas
2008-03-17 22:31     ` Rene Herman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200803121345.21297.lenb@kernel.org \
    --to=lenb@kernel.org \
    --cc=abelay@mit.edu \
    --cc=bjorn.helgaas@hp.com \
    --cc=davej@codemonkey.org.uk \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaohua.li@intel.com \
    --cc=trenn@suse.de \
    --cc=yakui.zhao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).