--- /dev/null
+From 3b0fde0fac19c180317eb0601b3504083f4b9bf5 Mon Sep 17 00:00:00 2001
+From: Yinghai Lu <yinghai@kernel.org>
+Date: Tue, 16 Jun 2009 15:31:16 -0700
+Subject: firmware_map: fix hang with x86/32bit
+
+From: Yinghai Lu <yinghai@kernel.org>
+
+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 <pchen@nvidia.com>
+Signed-off-by: Yinghai Lu <yinghai@kernel.org>
+Cc: Ingo Molnar <mingo@elte.hu>
+Acked-by: H. Peter Anvin <hpa@zytor.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
+ }
--- /dev/null
+From 545b9fd3d737afc0bb5203b1e79194a471605acd Mon Sep 17 00:00:00 2001
+From: Nick Piggin <npiggin@suse.de>
+Date: Tue, 2 Jun 2009 12:07:47 +0200
+Subject: fs: remove incorrect I_NEW warnings
+
+From: Nick Piggin <npiggin@suse.de>
+
+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 <shemminger@vyatta.com>
+Signed-off-by: Nick Piggin <npiggin@suse.de>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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) &&
--- /dev/null
+From 8e822df700694ca6850d1e0c122fd7004b2778d8 Mon Sep 17 00:00:00 2001
+From: Shaohua Li <shaohua.li@intel.com>
+Date: Mon, 8 Jun 2009 09:27:25 +0800
+Subject: PCI: disable ASPM on VIA root-port-under-bridge configurations
+
+From: Shaohua Li <shaohua.li@intel.com>
+
+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 <wd@denx.de>
+Signed-off-by: Shaohua Li <shaohua.li@intel.com>
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ 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;
projects / thirdparty / kernel / stable-queue.git / commitdiff
