mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®