From: Greg Kroah-Hartman Date: Mon, 29 Jun 2009 18:30:49 +0000 (-0700) Subject: start .30 queue X-Git-Tag: v2.6.27.26~37 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=167ef5b24787f5cb40b64d138a0d4f7deba3833f;p=thirdparty%2Fkernel%2Fstable-queue.git start .30 queue --- diff --git a/queue-2.6.30/firmware_map-fix-hang-with-x86-32bit.patch b/queue-2.6.30/firmware_map-fix-hang-with-x86-32bit.patch new file mode 100644 index 00000000000..215c2ad18a4 --- /dev/null +++ b/queue-2.6.30/firmware_map-fix-hang-with-x86-32bit.patch @@ -0,0 +1,117 @@ +From 3b0fde0fac19c180317eb0601b3504083f4b9bf5 Mon Sep 17 00:00:00 2001 +From: Yinghai Lu +Date: Tue, 16 Jun 2009 15:31:16 -0700 +Subject: firmware_map: fix hang with x86/32bit + +From: Yinghai Lu + +commit 3b0fde0fac19c180317eb0601b3504083f4b9bf5 upstream. + +Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13484 + +Peer reported: +| The bug is introduced from kernel 2.6.27, if E820 table reserve the memory +| above 4G in 32bit OS(BIOS-e820: 00000000fff80000 - 0000000120000000 +| (reserved)), system will report Int 6 error and hang up. The bug is caused by +| the following code in drivers/firmware/memmap.c, the resource_size_t is 32bit +| variable in 32bit OS, the BUG_ON() will be invoked to result in the Int 6 +| error. I try the latest 32bit Ubuntu and Fedora distributions, all hit this +| bug. +|====== +|static int firmware_map_add_entry(resource_size_t start, resource_size_t end, +| const char *type, +| struct firmware_map_entry *entry) + +and it only happen with CONFIG_PHYS_ADDR_T_64BIT is not set. + +it turns out we need to pass u64 instead of resource_size_t for that. + +[akpm@linux-foundation.org: add comment] +Reported-and-tested-by: Peer Chen +Signed-off-by: Yinghai Lu +Cc: Ingo Molnar +Acked-by: H. Peter Anvin +Cc: Thomas Gleixner +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/firmware/memmap.c | 16 +++++++++------- + include/linux/firmware-map.h | 12 ++++-------- + 2 files changed, 13 insertions(+), 15 deletions(-) + +--- a/drivers/firmware/memmap.c ++++ b/drivers/firmware/memmap.c +@@ -31,8 +31,12 @@ + * information is necessary as for the resource tree. + */ + struct firmware_map_entry { +- resource_size_t start; /* start of the memory range */ +- resource_size_t end; /* end of the memory range (incl.) */ ++ /* ++ * start and end must be u64 rather than resource_size_t, because e820 ++ * resources can lie at addresses above 4G. ++ */ ++ u64 start; /* start of the memory range */ ++ u64 end; /* end of the memory range (incl.) */ + const char *type; /* type of the memory range */ + struct list_head list; /* entry for the linked list */ + struct kobject kobj; /* kobject for each entry */ +@@ -101,7 +105,7 @@ static LIST_HEAD(map_entries); + * Common implementation of firmware_map_add() and firmware_map_add_early() + * which expects a pre-allocated struct firmware_map_entry. + **/ +-static int firmware_map_add_entry(resource_size_t start, resource_size_t end, ++static int firmware_map_add_entry(u64 start, u64 end, + const char *type, + struct firmware_map_entry *entry) + { +@@ -132,8 +136,7 @@ static int firmware_map_add_entry(resour + * + * Returns 0 on success, or -ENOMEM if no memory could be allocated. + **/ +-int firmware_map_add(resource_size_t start, resource_size_t end, +- const char *type) ++int firmware_map_add(u64 start, u64 end, const char *type) + { + struct firmware_map_entry *entry; + +@@ -157,8 +160,7 @@ int firmware_map_add(resource_size_t sta + * + * Returns 0 on success, or -ENOMEM if no memory could be allocated. + **/ +-int __init firmware_map_add_early(resource_size_t start, resource_size_t end, +- const char *type) ++int __init firmware_map_add_early(u64 start, u64 end, const char *type) + { + struct firmware_map_entry *entry; + +--- a/include/linux/firmware-map.h ++++ b/include/linux/firmware-map.h +@@ -24,21 +24,17 @@ + */ + #ifdef CONFIG_FIRMWARE_MEMMAP + +-int firmware_map_add(resource_size_t start, resource_size_t end, +- const char *type); +-int firmware_map_add_early(resource_size_t start, resource_size_t end, +- const char *type); ++int firmware_map_add(u64 start, u64 end, const char *type); ++int firmware_map_add_early(u64 start, u64 end, const char *type); + + #else /* CONFIG_FIRMWARE_MEMMAP */ + +-static inline int firmware_map_add(resource_size_t start, resource_size_t end, +- const char *type) ++static inline int firmware_map_add(u64 start, u64 end, const char *type) + { + return 0; + } + +-static inline int firmware_map_add_early(resource_size_t start, +- resource_size_t end, const char *type) ++static inline int firmware_map_add_early(u64 start, u64 end, const char *type) + { + return 0; + } diff --git a/queue-2.6.30/fs-remove-incorrect-i_new-warnings.patch b/queue-2.6.30/fs-remove-incorrect-i_new-warnings.patch new file mode 100644 index 00000000000..543a942020e --- /dev/null +++ b/queue-2.6.30/fs-remove-incorrect-i_new-warnings.patch @@ -0,0 +1,46 @@ +From 545b9fd3d737afc0bb5203b1e79194a471605acd Mon Sep 17 00:00:00 2001 +From: Nick Piggin +Date: Tue, 2 Jun 2009 12:07:47 +0200 +Subject: fs: remove incorrect I_NEW warnings + +From: Nick Piggin + +commit 545b9fd3d737afc0bb5203b1e79194a471605acd upstream. + +Some filesystems can call in to sync an inode that is still in the +I_NEW state (eg. ext family, when mounted with -osync). This is OK +because the filesystem has sole access to the new inode, so it can +modify i_state without races (because no other thread should be +modifying it, by definition of I_NEW). Ie. a false positive, so +remove the warnings. + +The races are described here 7ef0d7377cb287e08f3ae94cebc919448e1f5dff, +which is also where the warnings were introduced. + +Reported-by: Stephen Hemminger +Signed-off-by: Nick Piggin +Signed-off-by: Al Viro +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fs-writeback.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/fs/fs-writeback.c ++++ b/fs/fs-writeback.c +@@ -289,7 +289,6 @@ __sync_single_inode(struct inode *inode, + int ret; + + BUG_ON(inode->i_state & I_SYNC); +- WARN_ON(inode->i_state & I_NEW); + + /* Set I_SYNC, reset I_DIRTY */ + dirty = inode->i_state & I_DIRTY; +@@ -314,7 +313,6 @@ __sync_single_inode(struct inode *inode, + } + + spin_lock(&inode_lock); +- WARN_ON(inode->i_state & I_NEW); + inode->i_state &= ~I_SYNC; + if (!(inode->i_state & I_FREEING)) { + if (!(inode->i_state & I_DIRTY) && diff --git a/queue-2.6.30/pci-disable-aspm-on-via-root-port-under-bridge-configurations.patch b/queue-2.6.30/pci-disable-aspm-on-via-root-port-under-bridge-configurations.patch new file mode 100644 index 00000000000..901a73aa0c5 --- /dev/null +++ b/queue-2.6.30/pci-disable-aspm-on-via-root-port-under-bridge-configurations.patch @@ -0,0 +1,34 @@ +From 8e822df700694ca6850d1e0c122fd7004b2778d8 Mon Sep 17 00:00:00 2001 +From: Shaohua Li +Date: Mon, 8 Jun 2009 09:27:25 +0800 +Subject: PCI: disable ASPM on VIA root-port-under-bridge configurations + +From: Shaohua Li + +commit 8e822df700694ca6850d1e0c122fd7004b2778d8 upstream. + +VIA has a strange chipset, it has root port under a bridge. Disable ASPM +for such strange chipset. + +Tested-by: Wolfgang Denk +Signed-off-by: Shaohua Li +Signed-off-by: Jesse Barnes +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/pcie/aspm.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/pci/pcie/aspm.c ++++ b/drivers/pci/pcie/aspm.c +@@ -638,6 +638,10 @@ void pcie_aspm_init_link_state(struct pc + if (pdev->pcie_type != PCI_EXP_TYPE_ROOT_PORT && + pdev->pcie_type != PCI_EXP_TYPE_DOWNSTREAM) + return; ++ /* VIA has a strange chipset, root port is under a bridge */ ++ if (pdev->pcie_type == PCI_EXP_TYPE_ROOT_PORT && ++ pdev->bus->self) ++ return; + down_read(&pci_bus_sem); + if (list_empty(&pdev->subordinate->devices)) + goto out; diff --git a/queue-2.6.30/series b/queue-2.6.30/series new file mode 100644 index 00000000000..b5d5a5374ef --- /dev/null +++ b/queue-2.6.30/series @@ -0,0 +1,3 @@ +firmware_map-fix-hang-with-x86-32bit.patch +fs-remove-incorrect-i_new-warnings.patch +pci-disable-aspm-on-via-root-port-under-bridge-configurations.patch