We (the -stable team) are announcing the release of the 2.6.23.12 kernel.
It just reverts one patch that has been causing some users some
problems. For details about the problems, see:
http://bugzilla.kernel.org/show_bug.cgi?id=9514
If you are not having any problems with the 2.6.23.11 kernel, then there
is no need to upgrade.
I'll also be replying to this message with a copy of the patch between
2.6.23.11 and 2.6.23.12
The updated 2.6.23.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=summary
thanks,
greg k-h
--------
Makefile | 2 +-
drivers/pnp/pnpacpi/rsparser.c | 15 ++-------------
include/linux/pnp.h | 4 ++--
3 files changed, 5 insertions(+), 16 deletions(-)
Summary of changes from v2.6.23.11 to v2.6.23.12
================================================
Greg Kroah-Hartman (2):
Revert "PNP: increase the maximum number of resources"
Linux 2.6.23.12
diff --git a/Makefile b/Makefile
index ada10d5..96c3f02 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 23
-EXTRAVERSION = .11
+EXTRAVERSION = .12
NAME = Arr Matey! A Hairy Bilge Rat!
# *DOCUMENTATION*
diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
index 5abf5ea..0e3b8d0 100644
--- a/drivers/pnp/pnpacpi/rsparser.c
+++ b/drivers/pnp/pnpacpi/rsparser.c
@@ -82,11 +82,9 @@ static void pnpacpi_parse_allocated_irqresource(struct pnp_resource_table *res,
while (!(res->irq_resource[i].flags & IORESOURCE_UNSET) &&
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 (i >= PNP_MAX_IRQ)
return;
- }
+
res->irq_resource[i].flags = IORESOURCE_IRQ; // Also clears _UNSET flag
res->irq_resource[i].flags |= irq_flags(triggering, polarity);
irq = acpi_register_gsi(gsi, triggering, polarity);
@@ -165,9 +163,6 @@ static void pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table *res,
}
res->dma_resource[i].start = dma;
res->dma_resource[i].end = dma;
- } else {
- printk(KERN_ERR "pnpacpi: exceeded the max number of DMA "
- "resources: %d \n", PNP_MAX_DMA);
}
}
@@ -189,9 +184,6 @@ 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 {
- printk(KERN_ERR "pnpacpi: exceeded the max number of IO "
- "resources: %d \n", PNP_MAX_PORT);
}
}
@@ -215,9 +207,6 @@ 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 {
- printk(KERN_ERR "pnpacpi: exceeded the max number of mem "
- "resources: %d\n", PNP_MAX_MEM);
}
}
diff --git a/include/linux/pnp.h b/include/linux/pnp.h
index 62decab..16b46aa 100644
--- a/include/linux/pnp.h
+++ b/include/linux/pnp.h
@@ -13,8 +13,8 @@
#include <linux/errno.h>
#include <linux/mod_devicetable.h>
-#define PNP_MAX_PORT 24
-#define PNP_MAX_MEM 12
+#define PNP_MAX_PORT 8
+#define PNP_MAX_MEM 4
#define PNP_MAX_IRQ 2
#define PNP_MAX_DMA 2
#define PNP_NAME_LEN 50
The patch below was put in 2.6.23.12 as a fix for
http://bugzilla.kernel.org/show_bug.cgi?id=9514. It apparently
does make 9514 go away, but only by coincidence. There are a
couple other ideas about fixing 9514. My proposed patch is
attached in the bugzilla.
The .12 patch reduces the number of resources we reserve from
24 to 8 ioport regions and from 12 to 4 mmio regions per PNP device.
It also removes a warning about regions we ignore.
Obviously, we want to reserve ALL the regions for PNP devices,
and Thomas is working on a patch for that (which I hope will be
ready for 2.6.25). But in the meantime, the .12 patch makes it
more likely that we will have resource conflicts with PNP devices.
http://bugzilla.kernel.org/show_bug.cgi?id=9630 appears to be
such a conflict.
I think the patch below should be removed from the stable series.
Bjorn
On Tuesday 18 December 2007 03:46:36 pm Greg Kroah-Hartman wrote:
> diff --git a/Makefile b/Makefile
> index ada10d5..96c3f02 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,7 +1,7 @@
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 23
> -EXTRAVERSION = .11
> +EXTRAVERSION = .12
> NAME = Arr Matey! A Hairy Bilge Rat!
>
> # *DOCUMENTATION*
> diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
> index 5abf5ea..0e3b8d0 100644
> --- a/drivers/pnp/pnpacpi/rsparser.c
> +++ b/drivers/pnp/pnpacpi/rsparser.c
> @@ -82,11 +82,9 @@ static void pnpacpi_parse_allocated_irqresource(struct pnp_resource_table *res,
> while (!(res->irq_resource[i].flags & IORESOURCE_UNSET) &&
> 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 (i >= PNP_MAX_IRQ)
> return;
> - }
> +
> res->irq_resource[i].flags = IORESOURCE_IRQ; // Also clears _UNSET flag
> res->irq_resource[i].flags |= irq_flags(triggering, polarity);
> irq = acpi_register_gsi(gsi, triggering, polarity);
> @@ -165,9 +163,6 @@ static void pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table *res,
> }
> res->dma_resource[i].start = dma;
> res->dma_resource[i].end = dma;
> - } else {
> - printk(KERN_ERR "pnpacpi: exceeded the max number of DMA "
> - "resources: %d \n", PNP_MAX_DMA);
> }
> }
>
> @@ -189,9 +184,6 @@ 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 {
> - printk(KERN_ERR "pnpacpi: exceeded the max number of IO "
> - "resources: %d \n", PNP_MAX_PORT);
> }
> }
>
> @@ -215,9 +207,6 @@ 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 {
> - printk(KERN_ERR "pnpacpi: exceeded the max number of mem "
> - "resources: %d\n", PNP_MAX_MEM);
> }
> }
>
> diff --git a/include/linux/pnp.h b/include/linux/pnp.h
> index 62decab..16b46aa 100644
> --- a/include/linux/pnp.h
> +++ b/include/linux/pnp.h
> @@ -13,8 +13,8 @@
> #include <linux/errno.h>
> #include <linux/mod_devicetable.h>
>
> -#define PNP_MAX_PORT 24
> -#define PNP_MAX_MEM 12
> +#define PNP_MAX_PORT 8
> +#define PNP_MAX_MEM 4
> #define PNP_MAX_IRQ 2
> #define PNP_MAX_DMA 2
> #define PNP_NAME_LEN 50
On Wed, 2008-01-02 at 13:42 -0700, Bjorn Helgaas wrote:
> The patch below was put in 2.6.23.12 as a fix for
> http://bugzilla.kernel.org/show_bug.cgi?id=9514. It apparently
> does make 9514 go away, but only by coincidence. There are a
> couple other ideas about fixing 9514. My proposed patch is
> attached in the bugzilla.
>
> The .12 patch reduces the number of resources we reserve from
> 24 to 8 ioport regions and from 12 to 4 mmio regions per PNP device.
> It also removes a warning about regions we ignore.
>
> Obviously, we want to reserve ALL the regions for PNP devices,
> and Thomas is working on a patch for that (which I hope will be
> ready for 2.6.25). But in the meantime, the .12 patch makes it
> more likely that we will have resource conflicts with PNP devices.
>
> http://bugzilla.kernel.org/show_bug.cgi?id=9630 appears to be
> such a conflict.
Just let you know why we increase the resource number.
http://bugzilla.kernel.org/show_bug.cgi?id=8973
we found real I/O resource conflict here and cause system hang.
Thanks,
Shaohua
On Wed, Jan 02, 2008 at 01:42:23PM -0700, Bjorn Helgaas wrote:
> The patch below was put in 2.6.23.12 as a fix for
> http://bugzilla.kernel.org/show_bug.cgi?id=9514. It apparently
> does make 9514 go away, but only by coincidence. There are a
> couple other ideas about fixing 9514. My proposed patch is
> attached in the bugzilla.
>
> The .12 patch reduces the number of resources we reserve from
> 24 to 8 ioport regions and from 12 to 4 mmio regions per PNP device.
> It also removes a warning about regions we ignore.
That patch was merely a revert of a prior patch, it did not "do"
anything new at all :)
> Obviously, we want to reserve ALL the regions for PNP devices,
> and Thomas is working on a patch for that (which I hope will be
> ready for 2.6.25). But in the meantime, the .12 patch makes it
> more likely that we will have resource conflicts with PNP devices.
>
> http://bugzilla.kernel.org/show_bug.cgi?id=9630 appears to be
> such a conflict.
>
> I think the patch below should be removed from the stable series.
What do you mean "removed"? It was a revert of a prior patch, as this
patch was reported to cause real problems.
Do you want me to add it back, and then add another patch? If so, can
you please send the requested patches to [email protected] so I can do
it?
thanks,
greg k-h
On Wednesday 09 January 2008 08:49:52 pm Greg KH wrote:
> On Wed, Jan 02, 2008 at 01:42:23PM -0700, Bjorn Helgaas wrote:
> > The patch below was put in 2.6.23.12 as a fix for
> > http://bugzilla.kernel.org/show_bug.cgi?id=9514. It apparently
> > does make 9514 go away, but only by coincidence. There are a
> > couple other ideas about fixing 9514. My proposed patch is
> > attached in the bugzilla.
> >
> > The .12 patch reduces the number of resources we reserve from
> > 24 to 8 ioport regions and from 12 to 4 mmio regions per PNP device.
> > It also removes a warning about regions we ignore.
>
> That patch was merely a revert of a prior patch, it did not "do"
> anything new at all :)
>
> > Obviously, we want to reserve ALL the regions for PNP devices,
> > and Thomas is working on a patch for that (which I hope will be
> > ready for 2.6.25). But in the meantime, the .12 patch makes it
> > more likely that we will have resource conflicts with PNP devices.
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=9630 appears to be
> > such a conflict.
> >
> > I think the patch below should be removed from the stable series.
>
> What do you mean "removed"? It was a revert of a prior patch, as this
> patch was reported to cause real problems.
>
> Do you want me to add it back, and then add another patch? If so, can
> you please send the requested patches to [email protected] so I can do
> it?
Stepping back, the biggest part of the problem is that I replaced the
ACPI motherboard driver, which reserved all resources, with the PNP
motherboard driver, which currently can reserve only a limited number
of resources, because I didn't realize that restriction.
So we've had a variety of problems, and we've tried to address them
with hacks like increasing the PNP limits. I think we need to put
back the ACPI motherboard driver until we have dynamic PNP resources.
We will also need an it87 change to deal with
http://bugzilla.kernel.org/show_bug.cgi?id=9514.
I'll work these up and post them soon.
Bjorn