On Jan 9, 2008 10:47 PM, Rene Herman <[EMAIL PROTECTED]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/