From: "Dave Young" <hidave.darkstar@gmail.com>
To: "Rene Herman" <rene.herman@keyaccess.nl>
Cc: "Frans Pop" <elendil@planet.nl>,
bjorn.helgaas@hp.com, "Len Brown" <lenb@kernel.org>,
akpm@osdl.org, cholvenstot@comcast.net,
linux-kernel@vger.kernel.org, shaohua.li@intel.com,
trenn@suse.de, yakui.zhao@intel.com
Subject: Re: pnpacpi : exceeded the max number of IO resources
Date: Wed, 16 Jan 2008 13:55:54 +0800 [thread overview]
Message-ID: <a8e1da0801152155x18cfd0dcvfe638323275e539d@mail.gmail.com> (raw)
In-Reply-To: <4784DE94.8020508@keyaccess.nl>
On Jan 9, 2008 10:47 PM, Rene Herman <rene.herman@keyaccess.nl> wrote:
> On 09-01-08 10:34, Frans Pop wrote:
>
> Bjorn:
>
> > Len Brown wrote:
>
> >>>> 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?
> >>> Ping. Should these warnings be reverted for 2.6.24?
> >> 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.
> >
> > We're not talking about "a" additional line. In my case [1] we're talking
> > about 22 (!) additional identical lines.
>
> 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.
>
> Bjorn, could you push your preference into 2.6.24?
>
>
> > 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
> >
> > [1] http://lkml.org/lkml/2008/1/6/279
>
>
>
> diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
> index 3c5eb37..cd9d4a8 100644
> --- a/drivers/pnp/pnpacpi/rsparser.c
> +++ b/drivers/pnp/pnpacpi/rsparser.c
> @@ -73,6 +73,7 @@ static void pnpacpi_parse_allocated_irqresource(struct pnp_resource_table *res,
> u32 gsi, int triggering,
> int polarity, int shareable)
> {
> + static int warned;
> int i = 0;
> int irq;
> int p, t;
> @@ -84,8 +85,9 @@ static void pnpacpi_parse_allocated_irqresource(struct pnp_resource_table *res,
> i < PNP_MAX_IRQ)
> i++;
> if (i >= PNP_MAX_IRQ) {
> - printk(KERN_ERR "pnpacpi: exceeded the max number of IRQ "
> - "resources: %d \n", PNP_MAX_IRQ);
> + if (!warned++)
> + printk(KERN_ERR "pnpacpi: exceeded the max number of IRQ "
> + "resources: %d \n", PNP_MAX_IRQ);
> return;
> }
> /*
> @@ -168,6 +170,7 @@ static void pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table *res,
> u32 dma, int type,
> int bus_master, int transfer)
> {
> + static int warned;
> int i = 0;
>
> while (i < PNP_MAX_DMA &&
> @@ -183,7 +186,7 @@ static void pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table *res,
> }
> res->dma_resource[i].start = dma;
> res->dma_resource[i].end = dma;
> - } else {
> + } else if (!warned++) {
> printk(KERN_ERR "pnpacpi: exceeded the max number of DMA "
> "resources: %d \n", PNP_MAX_DMA);
> }
> @@ -192,6 +195,7 @@ static void pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table *res,
> static void pnpacpi_parse_allocated_ioresource(struct pnp_resource_table *res,
> u64 io, u64 len, int io_decode)
> {
> + static int warned;
> int i = 0;
>
> while (!(res->port_resource[i].flags & IORESOURCE_UNSET) &&
> @@ -207,7 +211,7 @@ static void pnpacpi_parse_allocated_ioresource(struct pnp_resource_table *res,
> }
> res->port_resource[i].start = io;
> res->port_resource[i].end = io + len - 1;
> - } else {
> + } else if (!warned++) {
> printk(KERN_ERR "pnpacpi: exceeded the max number of IO "
> "resources: %d \n", PNP_MAX_PORT);
> }
> @@ -217,6 +221,7 @@ static void pnpacpi_parse_allocated_memresource(struct pnp_resource_table *res,
> u64 mem, u64 len,
> int write_protect)
> {
> + static int warned;
> int i = 0;
>
> while (!(res->mem_resource[i].flags & IORESOURCE_UNSET) &&
> @@ -233,7 +238,7 @@ static void pnpacpi_parse_allocated_memresource(struct pnp_resource_table *res,
>
> res->mem_resource[i].start = mem;
> res->mem_resource[i].end = mem + len - 1;
> - } else {
> + } else if (!warned++) {
> printk(KERN_ERR "pnpacpi: exceeded the max number of mem "
> "resources: %d\n", PNP_MAX_MEM);
> }
>
>
I noticed the port number changed to 40 in 2.6.24-rc8, but it's not
enough for me still.
Regards
dave
next prev parent reply other threads:[~2008-01-16 5:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-30 13:14 Chris Holvenstot
2007-11-30 22:22 ` Rene Herman
2007-12-03 17:02 ` Rene Herman
2007-12-03 22:51 ` Chris Holvenstot
2007-12-04 0:55 ` Shaohua Li
2007-12-04 1:15 ` Dave Young
2007-12-05 20:39 ` Bjorn Helgaas
2007-12-19 3:07 ` Valdis.Kletnieks
2008-01-09 3:50 ` Len Brown
2008-01-09 9:34 ` Frans Pop
2008-01-09 14:47 ` Rene Herman
2008-01-16 5:55 ` Dave Young [this message]
2008-01-16 8:00 ` Rene Herman
2008-01-16 13:04 ` Rene Herman
2008-01-19 11:03 ` Frans Pop
2008-01-19 18:38 ` Bjorn Helgaas
-- strict thread matches above, loose matches on Subject: below --
2007-11-29 9:11 Dave Young
2007-11-30 1:18 ` Dave Young
2007-11-30 2:21 ` Zhao Yakui
2007-11-30 6:40 ` Valdis.Kletnieks
2007-11-30 8:14 ` Zhao Yakui
2007-11-30 2:18 ` Rene Herman
2007-11-30 2:32 ` Shaohua Li
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=a8e1da0801152155x18cfd0dcvfe638323275e539d@mail.gmail.com \
--to=hidave.darkstar@gmail.com \
--cc=akpm@osdl.org \
--cc=bjorn.helgaas@hp.com \
--cc=cholvenstot@comcast.net \
--cc=elendil@planet.nl \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rene.herman@keyaccess.nl \
--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
all inboxes | Powered by JetHome®