From: Greg Kroah-Hartman Date: Tue, 21 Dec 2010 00:17:17 +0000 (-0800) Subject: .36 patches X-Git-Tag: v2.6.36.3~8 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=bfb97fbe6c516d720e4585c8b8e53070e23cc2ce;p=thirdparty%2Fkernel%2Fstable-queue.git .36 patches --- diff --git a/queue-2.6.36/alsa-hda-enable-jack-sense-for-thinkpad-edge-11.patch b/queue-2.6.36/alsa-hda-enable-jack-sense-for-thinkpad-edge-11.patch new file mode 100644 index 00000000000..91c4924266b --- /dev/null +++ b/queue-2.6.36/alsa-hda-enable-jack-sense-for-thinkpad-edge-11.patch @@ -0,0 +1,29 @@ +From 6027277e77df2d2893d906c42f5c9f9abcb731e0 Mon Sep 17 00:00:00 2001 +From: Manoj Iyer +Date: Tue, 23 Nov 2010 07:43:44 +0100 +Subject: ALSA: hda - Enable jack sense for Thinkpad Edge 11 + +From: Manoj Iyer + +commit 6027277e77df2d2893d906c42f5c9f9abcb731e0 upstream. + +Add a quirk entry for Thinkpad Edge 11 as well as other TP Edge models. + +Signed-off-by: Manoj Iyer +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_conexant.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_conexant.c ++++ b/sound/pci/hda/patch_conexant.c +@@ -3099,6 +3099,7 @@ static struct snd_pci_quirk cxt5066_cfg_ + SND_PCI_QUIRK(0x17aa, 0x21b2, "Thinkpad X100e", CXT5066_IDEAPAD), + SND_PCI_QUIRK(0x17aa, 0x21b3, "Thinkpad Edge 13 (197)", CXT5066_IDEAPAD), + SND_PCI_QUIRK(0x17aa, 0x21b4, "Thinkpad Edge", CXT5066_IDEAPAD), ++ SND_PCI_QUIRK(0x17aa, 0x21c8, "Thinkpad Edge 11", CXT5066_IDEAPAD), + SND_PCI_QUIRK(0x17aa, 0x215e, "Lenovo Thinkpad", CXT5066_THINKPAD), + SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo G series", CXT5066_IDEAPAD), + SND_PCI_QUIRK(0x17aa, 0x390a, "Lenovo S10-3t", CXT5066_IDEAPAD), diff --git a/queue-2.6.36/arch-tile-handle-clone_settls-in-copy_thread-not-user-space.patch b/queue-2.6.36/arch-tile-handle-clone_settls-in-copy_thread-not-user-space.patch new file mode 100644 index 00000000000..ae9d724acee --- /dev/null +++ b/queue-2.6.36/arch-tile-handle-clone_settls-in-copy_thread-not-user-space.patch @@ -0,0 +1,45 @@ +From bc4cf2bb271b2d557fc510426755da786fc985be Mon Sep 17 00:00:00 2001 +From: Chris Metcalf +Date: Tue, 14 Dec 2010 15:57:49 -0500 +Subject: arch/tile: handle CLONE_SETTLS in copy_thread(), not user space + +From: Chris Metcalf + +commit bc4cf2bb271b2d557fc510426755da786fc985be upstream. + +Previously we were just setting up the "tp" register in the +new task as started by clone() in libc. However, this is not +quite right, since in principle a signal might be delivered to +the new task before it had its TLS set up. (Of course, this race +window still exists for resetting the libc getpid() cached value +in the new task, in principle. But in any case, we are now doing +this exactly the way all other architectures do it.) + +This change is important for 2.6.37 since the tile glibc we will +be submitting upstream will not set TLS in user space any more, +so it will only work on a kernel that has this fix. It should +also be taken for 2.6.36.x in the stable tree if possible. + +Signed-off-by: Chris Metcalf +Signed-off-by: Greg Kroah-Hartman + +--- + arch/tile/kernel/process.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/arch/tile/kernel/process.c ++++ b/arch/tile/kernel/process.c +@@ -212,6 +212,13 @@ int copy_thread(unsigned long clone_flag + childregs->sp = sp; /* override with new user stack pointer */ + + /* ++ * If CLONE_SETTLS is set, set "tp" in the new task to "r4", ++ * which is passed in as arg #5 to sys_clone(). ++ */ ++ if (clone_flags & CLONE_SETTLS) ++ childregs->tp = regs->regs[4]; ++ ++ /* + * Copy the callee-saved registers from the passed pt_regs struct + * into the context-switch callee-saved registers area. + * We have to restore the callee-saved registers since we may diff --git a/queue-2.6.36/input-synaptics-fix-handling-of-2-button-clickpads.patch b/queue-2.6.36/input-synaptics-fix-handling-of-2-button-clickpads.patch new file mode 100644 index 00000000000..dcc05c4bab2 --- /dev/null +++ b/queue-2.6.36/input-synaptics-fix-handling-of-2-button-clickpads.patch @@ -0,0 +1,41 @@ +From 3bfa321e662edf90fb8123a02c987c2965fa50bb Mon Sep 17 00:00:00 2001 +From: Yan Li +Date: Tue, 30 Nov 2010 23:51:03 -0800 +Subject: Input: synaptics - fix handling of 2-button ClickPads + +From: Yan Li + +commit 3bfa321e662edf90fb8123a02c987c2965fa50bb upstream. + +Lenovo S10-3t's ClickPad is a 2-button ClickPad that reports BTN_LEFT +and BTN_RIGHT as normal touchpad, unlike the 1-button ClickPad used in +HP mini 210 that reports solely BTN_MIDDLE. + +In 0xc0-cap response, the 1-button ClickPad has the 20-bit set while +2-button ClickPad has the 8-bit set. + +This patch makes the kernel only handle 1-button ClickPad specially, +and treat 2-button ClickPad in the same fashion as regular touchpads. + +This fixes kernel bug #18122 and MeeGo bug #4807. + +Signed-off-by: Yan Li +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/mouse/synaptics.h | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/input/mouse/synaptics.h ++++ b/drivers/input/mouse/synaptics.h +@@ -51,7 +51,8 @@ + #define SYN_EXT_CAP_REQUESTS(c) (((c) & 0x700000) >> 20) + #define SYN_CAP_MULTI_BUTTON_NO(ec) (((ec) & 0x00f000) >> 12) + #define SYN_CAP_PRODUCT_ID(ec) (((ec) & 0xff0000) >> 16) +-#define SYN_CAP_CLICKPAD(ex0c) ((ex0c) & 0x100100) ++#define SYN_CAP_CLICKPAD(ex0c) ((ex0c) & 0x100000) /* 1-button ClickPad */ ++#define SYN_CAP_CLICKPAD2BTN(ex0c) ((ex0c) & 0x000100) /* 2-button ClickPad */ + #define SYN_CAP_MAX_DIMENSIONS(ex0c) ((ex0c) & 0x020000) + + /* synaptics modes query bits */ diff --git a/queue-2.6.36/install_special_mapping-skips-security_file_mmap-check.patch b/queue-2.6.36/install_special_mapping-skips-security_file_mmap-check.patch new file mode 100644 index 00000000000..aab6012c20e --- /dev/null +++ b/queue-2.6.36/install_special_mapping-skips-security_file_mmap-check.patch @@ -0,0 +1,107 @@ +From 462e635e5b73ba9a4c03913b77138cd57ce4b050 Mon Sep 17 00:00:00 2001 +From: Tavis Ormandy +Date: Thu, 9 Dec 2010 15:29:42 +0100 +Subject: install_special_mapping skips security_file_mmap check. + +From: Tavis Ormandy + +commit 462e635e5b73ba9a4c03913b77138cd57ce4b050 upstream. + +The install_special_mapping routine (used, for example, to setup the +vdso) skips the security check before insert_vm_struct, allowing a local +attacker to bypass the mmap_min_addr security restriction by limiting +the available pages for special mappings. + +bprm_mm_init() also skips the check, and although I don't think this can +be used to bypass any restrictions, I don't see any reason not to have +the security check. + + $ uname -m + x86_64 + $ cat /proc/sys/vm/mmap_min_addr + 65536 + $ cat install_special_mapping.s + section .bss + resb BSS_SIZE + section .text + global _start + _start: + mov eax, __NR_pause + int 0x80 + $ nasm -D__NR_pause=29 -DBSS_SIZE=0xfffed000 -f elf -o install_special_mapping.o install_special_mapping.s + $ ld -m elf_i386 -Ttext=0x10000 -Tbss=0x11000 -o install_special_mapping install_special_mapping.o + $ ./install_special_mapping & + [1] 14303 + $ cat /proc/14303/maps + 0000f000-00010000 r-xp 00000000 00:00 0 [vdso] + 00010000-00011000 r-xp 00001000 00:19 2453665 /home/taviso/install_special_mapping + 00011000-ffffe000 rwxp 00000000 00:00 0 [stack] + +It's worth noting that Red Hat are shipping with mmap_min_addr set to +4096. + +Signed-off-by: Tavis Ormandy +Acked-by: Kees Cook +Acked-by: Robert Swiecki +[ Changed to not drop the error code - akpm ] +Reviewed-by: James Morris +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/exec.c | 5 +++++ + mm/mmap.c | 16 ++++++++++++---- + 2 files changed, 17 insertions(+), 4 deletions(-) + +--- a/fs/exec.c ++++ b/fs/exec.c +@@ -268,6 +268,11 @@ static int __bprm_mm_init(struct linux_b + vma->vm_flags = VM_STACK_FLAGS | VM_STACK_INCOMPLETE_SETUP; + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); + INIT_LIST_HEAD(&vma->anon_vma_chain); ++ ++ err = security_file_mmap(NULL, 0, 0, 0, vma->vm_start, 1); ++ if (err) ++ goto err; ++ + err = insert_vm_struct(mm, vma); + if (err) + goto err; +--- a/mm/mmap.c ++++ b/mm/mmap.c +@@ -2460,6 +2460,7 @@ int install_special_mapping(struct mm_st + unsigned long addr, unsigned long len, + unsigned long vm_flags, struct page **pages) + { ++ int ret; + struct vm_area_struct *vma; + + vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL); +@@ -2477,16 +2478,23 @@ int install_special_mapping(struct mm_st + vma->vm_ops = &special_mapping_vmops; + vma->vm_private_data = pages; + +- if (unlikely(insert_vm_struct(mm, vma))) { +- kmem_cache_free(vm_area_cachep, vma); +- return -ENOMEM; +- } ++ ret = security_file_mmap(NULL, 0, 0, 0, vma->vm_start, 1); ++ if (ret) ++ goto out; ++ ++ ret = insert_vm_struct(mm, vma); ++ if (ret) ++ goto out; + + mm->total_vm += len >> PAGE_SHIFT; + + perf_event_mmap(vma); + + return 0; ++ ++out: ++ kmem_cache_free(vm_area_cachep, vma); ++ return ret; + } + + static DEFINE_MUTEX(mm_all_locks_mutex); diff --git a/queue-2.6.36/md-fix-bug-with-re-adding-of-partially-recovered-device.patch b/queue-2.6.36/md-fix-bug-with-re-adding-of-partially-recovered-device.patch new file mode 100644 index 00000000000..8924e4cc1e2 --- /dev/null +++ b/queue-2.6.36/md-fix-bug-with-re-adding-of-partially-recovered-device.patch @@ -0,0 +1,62 @@ +From 1a855a0606653d2d82506281e2c686bacb4b2f45 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Thu, 9 Dec 2010 16:36:28 +1100 +Subject: md: fix bug with re-adding of partially recovered device. + +From: NeilBrown + +commit 1a855a0606653d2d82506281e2c686bacb4b2f45 upstream. + +With v0.90 metadata, a hot-spare does not become a full member of the +array until recovery is complete. So if we re-add such a device to +the array, we know that all of it is as up-to-date as the event count +would suggest, and so it a bitmap-based recovery is possible. + +However with v1.x metadata, the hot-spare immediately becomes a full +member of the array, but it record how much of the device has been +recovered. If the array is stopped and re-assembled recovery starts +from this point. + +When such a device is hot-added to an array we currently lose the 'how +much is recovered' information and incorrectly included it as a full +in-sync member (after bitmap-based fixup). +This is wrong and unsafe and could corrupt data. + +So be more careful about setting saved_raid_disk - which is what +guides the re-adding of devices back into an array. +The new code matches the code in slot_store which does a similar +thing, which is encouraging. + +This is suitable for any -stable kernel. + +Reported-by: "Dailey, Nate" +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/md.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/drivers/md/md.c ++++ b/drivers/md/md.c +@@ -5150,7 +5150,7 @@ static int add_new_disk(mddev_t * mddev, + PTR_ERR(rdev)); + return PTR_ERR(rdev); + } +- /* set save_raid_disk if appropriate */ ++ /* set saved_raid_disk if appropriate */ + if (!mddev->persistent) { + if (info->state & (1<raid_disk < mddev->raid_disks) +@@ -5160,7 +5160,10 @@ static int add_new_disk(mddev_t * mddev, + } else + super_types[mddev->major_version]. + validate_super(mddev, rdev); +- rdev->saved_raid_disk = rdev->raid_disk; ++ if (test_bit(In_sync, &rdev->flags)) ++ rdev->saved_raid_disk = rdev->raid_disk; ++ else ++ rdev->saved_raid_disk = -1; + + clear_bit(In_sync, &rdev->flags); /* just to be sure */ + if (info->state & (1< +Date: Thu, 9 Dec 2010 17:02:14 +1100 +Subject: md: protect against NULL reference when waiting to start a raid10. + +From: NeilBrown + +commit 589a594be1fb8815b3f18e517be696c48664f728 upstream. + +When we fail to start a raid10 for some reason, we call +md_unregister_thread to kill the thread that was created. + +Unfortunately md_thread() will then make one call into the handler +(raid10d) even though md_wakeup_thread has not been called. This is +not safe and as md_unregister_thread is called after mddev->private +has been set to NULL, it will definitely cause a NULL dereference. + +So fix this at both ends: + - md_thread should only call the handler if THREAD_WAKEUP has been + set. + - raid10 should call md_unregister_thread before setting things + to NULL just like all the other raid modules do. + +This is applicable to 2.6.35 and later. + +Reported-by: "Citizen" +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/md.c | 5 ++--- + drivers/md/raid10.c | 2 +- + 2 files changed, 3 insertions(+), 4 deletions(-) + +--- a/drivers/md/md.c ++++ b/drivers/md/md.c +@@ -6040,9 +6040,8 @@ static int md_thread(void * arg) + || kthread_should_stop(), + thread->timeout); + +- clear_bit(THREAD_WAKEUP, &thread->flags); +- +- thread->run(thread->mddev); ++ if (test_and_clear_bit(THREAD_WAKEUP, &thread->flags)) ++ thread->run(thread->mddev); + } + + return 0; +--- a/drivers/md/raid10.c ++++ b/drivers/md/raid10.c +@@ -2396,13 +2396,13 @@ static int run(mddev_t *mddev) + return 0; + + out_free_conf: ++ md_unregister_thread(mddev->thread); + if (conf->r10bio_pool) + mempool_destroy(conf->r10bio_pool); + safe_put_page(conf->tmppage); + kfree(conf->mirrors); + kfree(conf); + mddev->private = NULL; +- md_unregister_thread(mddev->thread); + out: + return -EIO; + } diff --git a/queue-2.6.36/orinoco-clear-countermeasure-setting-on-commit.patch b/queue-2.6.36/orinoco-clear-countermeasure-setting-on-commit.patch new file mode 100644 index 00000000000..e40d0b9d6ea --- /dev/null +++ b/queue-2.6.36/orinoco-clear-countermeasure-setting-on-commit.patch @@ -0,0 +1,42 @@ +From ba34fcee476d11e7c9df95932787a22a96ff6e68 Mon Sep 17 00:00:00 2001 +From: David Kilroy +Date: Sun, 5 Dec 2010 15:45:58 +0000 +Subject: orinoco: clear countermeasure setting on commit + +From: David Kilroy + +commit ba34fcee476d11e7c9df95932787a22a96ff6e68 upstream. + +... and interface up. + +In these situations, you are usually trying to connect to a new AP, so +keeping TKIP countermeasures active is confusing. This is already how +the driver behaves (inadvertently). However, querying SIOCGIWAUTH may +tell userspace that countermeasures are active when they aren't. + +Clear the setting so that the reporting matches what the driver has +done.. + +Signed-off by: David Kilroy +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/orinoco/main.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/net/wireless/orinoco/main.c ++++ b/drivers/net/wireless/orinoco/main.c +@@ -1813,6 +1813,12 @@ static int __orinoco_commit(struct orino + struct net_device *dev = priv->ndev; + int err = 0; + ++ /* If we've called commit, we are reconfiguring or bringing the ++ * interface up. Maintaining countermeasures across this would ++ * be confusing, so note that we've disabled them. The port will ++ * be enabled later in orinoco_commit or __orinoco_up. */ ++ priv->tkip_cm_active = 0; ++ + err = orinoco_hw_program_rids(priv); + + /* FIXME: what about netif_tx_lock */ diff --git a/queue-2.6.36/orinoco-fix-tkip-countermeasure-behaviour.patch b/queue-2.6.36/orinoco-fix-tkip-countermeasure-behaviour.patch new file mode 100644 index 00000000000..8660bb78d61 --- /dev/null +++ b/queue-2.6.36/orinoco-fix-tkip-countermeasure-behaviour.patch @@ -0,0 +1,61 @@ +From 0a54917c3fc295cb61f3fb52373c173fd3b69f48 Mon Sep 17 00:00:00 2001 +From: David Kilroy +Date: Sun, 5 Dec 2010 15:43:55 +0000 +Subject: orinoco: fix TKIP countermeasure behaviour + +From: David Kilroy + +commit 0a54917c3fc295cb61f3fb52373c173fd3b69f48 upstream. + +Enable the port when disabling countermeasures, and disable it on +enabling countermeasures. + +This bug causes the response of the system to certain attacks to be +ineffective. + +It also prevents wpa_supplicant from getting scan results, as +wpa_supplicant disables countermeasures on startup - preventing the +hardware from scanning. + +wpa_supplicant works with ap_mode=2 despite this bug because the commit +handler re-enables the port. + +The log tends to look like: + +State: DISCONNECTED -> SCANNING +Starting AP scan for wildcard SSID +Scan requested (ret=0) - scan timeout 5 seconds +EAPOL: disable timer tick +EAPOL: Supplicant port status: Unauthorized +Scan timeout - try to get results +Failed to get scan results +Failed to get scan results - try scanning again +Setting scan request: 1 sec 0 usec +Starting AP scan for wildcard SSID +Scan requested (ret=-1) - scan timeout 5 seconds +Failed to initiate AP scan. + +Reported by: Giacomo Comes +Signed-off by: David Kilroy +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/orinoco/wext.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/wireless/orinoco/wext.c ++++ b/drivers/net/wireless/orinoco/wext.c +@@ -904,10 +904,10 @@ static int orinoco_ioctl_set_auth(struct + */ + if (param->value) { + priv->tkip_cm_active = 1; +- ret = hermes_enable_port(hw, 0); ++ ret = hermes_disable_port(hw, 0); + } else { + priv->tkip_cm_active = 0; +- ret = hermes_disable_port(hw, 0); ++ ret = hermes_enable_port(hw, 0); + } + break; + diff --git a/queue-2.6.36/rt2x00-fix-max-tx-power-settings.patch b/queue-2.6.36/rt2x00-fix-max-tx-power-settings.patch new file mode 100644 index 00000000000..21ec37391bd --- /dev/null +++ b/queue-2.6.36/rt2x00-fix-max-tx-power-settings.patch @@ -0,0 +1,310 @@ +From 8d1331b37d5b656a7a8e561f8e9d7661dd00c910 Mon Sep 17 00:00:00 2001 +From: Ivo van Doorn +Date: Mon, 23 Aug 2010 19:56:07 +0200 +Subject: rt2x00: Fix max TX power settings + +From: Ivo van Doorn + +commit 8d1331b37d5b656a7a8e561f8e9d7661dd00c910 upstream. + +During initialization each driver reads the default TX power +for each individual channel. However mac80211 only accepts the +maximum value (which is also handled as default value). + +As a result, the TX power of the device was being limited to +the default value, which is often quite low compared to the +real maximum acceptable value. + +This patch allows each driver to set the maximum value on a +per-channel basis which is forwarded to mac80211. The default +value will be preserved for now, in case we want to update +mac80211 to differentiate between the maximum and default txpower. + +This fixes bug complaining about limited TX power values like: +https://bugzilla.kernel.org/show_bug.cgi?id=16358 + +Signed-off-by: Ivo van Doorn +Acked-by: Helmut Schaa +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/rt2x00/rt2400pci.c | 6 ++- + drivers/net/wireless/rt2x00/rt2500pci.c | 12 ++++-- + drivers/net/wireless/rt2x00/rt2500usb.c | 12 ++++-- + drivers/net/wireless/rt2x00/rt2800.h | 7 +++ + drivers/net/wireless/rt2x00/rt2800lib.c | 59 ++++++++++++++++++-------------- + drivers/net/wireless/rt2x00/rt2x00.h | 5 +- + drivers/net/wireless/rt2x00/rt2x00dev.c | 2 - + drivers/net/wireless/rt2x00/rt61pci.c | 12 ++++-- + drivers/net/wireless/rt2x00/rt73usb.c | 12 ++++-- + 9 files changed, 82 insertions(+), 45 deletions(-) + +--- a/drivers/net/wireless/rt2x00/rt2400pci.c ++++ b/drivers/net/wireless/rt2x00/rt2400pci.c +@@ -1488,8 +1488,10 @@ static int rt2400pci_probe_hw_mode(struc + spec->channels_info = info; + + tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_START); +- for (i = 0; i < 14; i++) +- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ for (i = 0; i < 14; i++) { ++ info[i].max_power = TXPOWER_FROM_DEV(MAX_TXPOWER); ++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ } + + return 0; + } +--- a/drivers/net/wireless/rt2x00/rt2500pci.c ++++ b/drivers/net/wireless/rt2x00/rt2500pci.c +@@ -1802,12 +1802,16 @@ static int rt2500pci_probe_hw_mode(struc + spec->channels_info = info; + + tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_START); +- for (i = 0; i < 14; i++) +- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ for (i = 0; i < 14; i++) { ++ info[i].max_power = MAX_TXPOWER; ++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ } + + if (spec->num_channels > 14) { +- for (i = 14; i < spec->num_channels; i++) +- info[i].tx_power1 = DEFAULT_TXPOWER; ++ for (i = 14; i < spec->num_channels; i++) { ++ info[i].max_power = MAX_TXPOWER; ++ info[i].default_power1 = DEFAULT_TXPOWER; ++ } + } + + return 0; +--- a/drivers/net/wireless/rt2x00/rt2500usb.c ++++ b/drivers/net/wireless/rt2x00/rt2500usb.c +@@ -1705,12 +1705,16 @@ static int rt2500usb_probe_hw_mode(struc + spec->channels_info = info; + + tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_START); +- for (i = 0; i < 14; i++) +- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ for (i = 0; i < 14; i++) { ++ info[i].max_power = MAX_TXPOWER; ++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ } + + if (spec->num_channels > 14) { +- for (i = 14; i < spec->num_channels; i++) +- info[i].tx_power1 = DEFAULT_TXPOWER; ++ for (i = 14; i < spec->num_channels; i++) { ++ info[i].max_power = MAX_TXPOWER; ++ info[i].default_power1 = DEFAULT_TXPOWER; ++ } + } + + return 0; +--- a/drivers/net/wireless/rt2x00/rt2800.h ++++ b/drivers/net/wireless/rt2x00/rt2800.h +@@ -1841,6 +1841,13 @@ struct mac_iveiv_entry { + #define EEPROM_RSSI_A2_LNA_A2 FIELD16(0xff00) + + /* ++ * EEPROM Maximum TX power values ++ */ ++#define EEPROM_MAX_TX_POWER 0x0027 ++#define EEPROM_MAX_TX_POWER_24GHZ FIELD16(0x00ff) ++#define EEPROM_MAX_TX_POWER_5GHZ FIELD16(0xff00) ++ ++/* + * EEPROM TXpower delta: 20MHZ AND 40 MHZ use different power. + * This is delta in 40MHZ. + * VALUE: Tx Power dalta value (MAX=4) +--- a/drivers/net/wireless/rt2x00/rt2800lib.c ++++ b/drivers/net/wireless/rt2x00/rt2800lib.c +@@ -1120,27 +1120,27 @@ static void rt2800_config_channel_rf2xxx + * double meaning, and we should set a 7DBm boost flag. + */ + rt2x00_set_field32(&rf->rf3, RF3_TXPOWER_A_7DBM_BOOST, +- (info->tx_power1 >= 0)); ++ (info->default_power1 >= 0)); + +- if (info->tx_power1 < 0) +- info->tx_power1 += 7; ++ if (info->default_power1 < 0) ++ info->default_power1 += 7; + + rt2x00_set_field32(&rf->rf3, RF3_TXPOWER_A, +- TXPOWER_A_TO_DEV(info->tx_power1)); ++ TXPOWER_A_TO_DEV(info->default_power1)); + + rt2x00_set_field32(&rf->rf4, RF4_TXPOWER_A_7DBM_BOOST, +- (info->tx_power2 >= 0)); ++ (info->default_power2 >= 0)); + +- if (info->tx_power2 < 0) +- info->tx_power2 += 7; ++ if (info->default_power2 < 0) ++ info->default_power2 += 7; + + rt2x00_set_field32(&rf->rf4, RF4_TXPOWER_A, +- TXPOWER_A_TO_DEV(info->tx_power2)); ++ TXPOWER_A_TO_DEV(info->default_power2)); + } else { + rt2x00_set_field32(&rf->rf3, RF3_TXPOWER_G, +- TXPOWER_G_TO_DEV(info->tx_power1)); ++ TXPOWER_G_TO_DEV(info->default_power1)); + rt2x00_set_field32(&rf->rf4, RF4_TXPOWER_G, +- TXPOWER_G_TO_DEV(info->tx_power2)); ++ TXPOWER_G_TO_DEV(info->default_power2)); + } + + rt2x00_set_field32(&rf->rf4, RF4_HT40, conf_is_ht40(conf)); +@@ -1180,13 +1180,11 @@ static void rt2800_config_channel_rf3xxx + rt2800_rfcsr_write(rt2x00dev, 6, rfcsr); + + rt2800_rfcsr_read(rt2x00dev, 12, &rfcsr); +- rt2x00_set_field8(&rfcsr, RFCSR12_TX_POWER, +- TXPOWER_G_TO_DEV(info->tx_power1)); ++ rt2x00_set_field8(&rfcsr, RFCSR12_TX_POWER, info->default_power1); + rt2800_rfcsr_write(rt2x00dev, 12, rfcsr); + + rt2800_rfcsr_read(rt2x00dev, 13, &rfcsr); +- rt2x00_set_field8(&rfcsr, RFCSR13_TX_POWER, +- TXPOWER_G_TO_DEV(info->tx_power2)); ++ rt2x00_set_field8(&rfcsr, RFCSR13_TX_POWER, info->default_power2); + rt2800_rfcsr_write(rt2x00dev, 13, rfcsr); + + rt2800_rfcsr_read(rt2x00dev, 23, &rfcsr); +@@ -2516,6 +2514,13 @@ int rt2800_validate_eeprom(struct rt2x00 + default_lna_gain); + rt2x00_eeprom_write(rt2x00dev, EEPROM_RSSI_A2, word); + ++ rt2x00_eeprom_read(rt2x00dev, EEPROM_MAX_TX_POWER, &word); ++ if (rt2x00_get_field16(word, EEPROM_MAX_TX_POWER_24GHZ) == 0xff) ++ rt2x00_set_field16(&word, EEPROM_MAX_TX_POWER_24GHZ, MAX_G_TXPOWER); ++ if (rt2x00_get_field16(word, EEPROM_MAX_TX_POWER_5GHZ) == 0xff) ++ rt2x00_set_field16(&word, EEPROM_MAX_TX_POWER_5GHZ, MAX_A_TXPOWER); ++ rt2x00_eeprom_write(rt2x00dev, EEPROM_MAX_TX_POWER, word); ++ + return 0; + } + EXPORT_SYMBOL_GPL(rt2800_validate_eeprom); +@@ -2755,9 +2760,10 @@ int rt2800_probe_hw_mode(struct rt2x00_d + { + struct hw_mode_spec *spec = &rt2x00dev->spec; + struct channel_info *info; +- char *tx_power1; +- char *tx_power2; ++ char *default_power1; ++ char *default_power2; + unsigned int i; ++ unsigned short max_power; + u16 eeprom; + + /* +@@ -2871,21 +2877,26 @@ int rt2800_probe_hw_mode(struct rt2x00_d + + spec->channels_info = info; + +- tx_power1 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG1); +- tx_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG2); ++ rt2x00_eeprom_read(rt2x00dev, EEPROM_MAX_TX_POWER, &eeprom); ++ max_power = rt2x00_get_field16(eeprom, EEPROM_MAX_TX_POWER_24GHZ); ++ default_power1 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG1); ++ default_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG2); + + for (i = 0; i < 14; i++) { +- info[i].tx_power1 = TXPOWER_G_FROM_DEV(tx_power1[i]); +- info[i].tx_power2 = TXPOWER_G_FROM_DEV(tx_power2[i]); ++ info[i].max_power = max_power; ++ info[i].default_power1 = TXPOWER_G_FROM_DEV(default_power1[i]); ++ info[i].default_power2 = TXPOWER_G_FROM_DEV(default_power2[i]); + } + + if (spec->num_channels > 14) { +- tx_power1 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A1); +- tx_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A2); ++ max_power = rt2x00_get_field16(eeprom, EEPROM_MAX_TX_POWER_5GHZ); ++ default_power1 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A1); ++ default_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A2); + + for (i = 14; i < spec->num_channels; i++) { +- info[i].tx_power1 = TXPOWER_A_FROM_DEV(tx_power1[i]); +- info[i].tx_power2 = TXPOWER_A_FROM_DEV(tx_power2[i]); ++ info[i].max_power = max_power; ++ info[i].default_power1 = TXPOWER_A_FROM_DEV(default_power1[i]); ++ info[i].default_power2 = TXPOWER_A_FROM_DEV(default_power2[i]); + } + } + +--- a/drivers/net/wireless/rt2x00/rt2x00.h ++++ b/drivers/net/wireless/rt2x00/rt2x00.h +@@ -212,8 +212,9 @@ struct channel_info { + unsigned int flags; + #define GEOGRAPHY_ALLOWED 0x00000001 + +- short tx_power1; +- short tx_power2; ++ short max_power; ++ short default_power1; ++ short default_power2; + }; + + /* +--- a/drivers/net/wireless/rt2x00/rt2x00dev.c ++++ b/drivers/net/wireless/rt2x00/rt2x00dev.c +@@ -710,7 +710,7 @@ static int rt2x00lib_probe_hw_modes(stru + for (i = 0; i < spec->num_channels; i++) { + rt2x00lib_channel(&channels[i], + spec->channels[i].channel, +- spec->channels_info[i].tx_power1, i); ++ spec->channels_info[i].max_power, i); + } + + /* +--- a/drivers/net/wireless/rt2x00/rt61pci.c ++++ b/drivers/net/wireless/rt2x00/rt61pci.c +@@ -2661,13 +2661,17 @@ static int rt61pci_probe_hw_mode(struct + spec->channels_info = info; + + tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_G_START); +- for (i = 0; i < 14; i++) +- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ for (i = 0; i < 14; i++) { ++ info[i].max_power = MAX_TXPOWER; ++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ } + + if (spec->num_channels > 14) { + tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A_START); +- for (i = 14; i < spec->num_channels; i++) +- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ for (i = 14; i < spec->num_channels; i++) { ++ info[i].max_power = MAX_TXPOWER; ++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ } + } + + return 0; +--- a/drivers/net/wireless/rt2x00/rt73usb.c ++++ b/drivers/net/wireless/rt2x00/rt73usb.c +@@ -2091,13 +2091,17 @@ static int rt73usb_probe_hw_mode(struct + spec->channels_info = info; + + tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_G_START); +- for (i = 0; i < 14; i++) +- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ for (i = 0; i < 14; i++) { ++ info[i].max_power = MAX_TXPOWER; ++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ } + + if (spec->num_channels > 14) { + tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A_START); +- for (i = 14; i < spec->num_channels; i++) +- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ for (i = 14; i < spec->num_channels; i++) { ++ info[i].max_power = MAX_TXPOWER; ++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]); ++ } + } + + return 0; diff --git a/queue-2.6.36/series b/queue-2.6.36/series index 746eca4d0bb..666ba08a006 100644 --- a/queue-2.6.36/series +++ b/queue-2.6.36/series @@ -86,3 +86,19 @@ acpi-ec-add-another-dmi-match-entry-for-msi-hardware.patch mips-jz4740-qi_lb60-fix-gpio-for-the-6th-row-of-the-keyboard-matrix.patch pm-runtime-fix-pm_runtime_suspended.patch inotify-stop-kernel-memory-leak-on-file-creation-failure.patch +orinoco-fix-tkip-countermeasure-behaviour.patch +orinoco-clear-countermeasure-setting-on-commit.patch +x86-amd-fix-panic-on-amd-cpu-family-0x15.patch +md-fix-bug-with-re-adding-of-partially-recovered-device.patch +md-protect-against-null-reference-when-waiting-to-start-a-raid10.patch +tracing-fix-panic-when-lseek-called-on-trace-opened-for-writing.patch +arch-tile-handle-clone_settls-in-copy_thread-not-user-space.patch +x86-gcc-4.6-use-gcc-m-options-when-building-vdso.patch +x86-enable-the-intr-remap-fault-handling-after-local-apic-setup.patch +x86-vt-d-handle-previous-faults-after-enabling-fault-handling.patch +x86-vt-d-fix-the-vt-d-fault-handling-irq-migration-in-the-x2apic-mode.patch +x86-vt-d-quirk-for-masking-vtd-spec-errors-to-platform-error-handling-logic.patch +rt2x00-fix-max-tx-power-settings.patch +alsa-hda-enable-jack-sense-for-thinkpad-edge-11.patch +input-synaptics-fix-handling-of-2-button-clickpads.patch +install_special_mapping-skips-security_file_mmap-check.patch diff --git a/queue-2.6.36/tracing-fix-panic-when-lseek-called-on-trace-opened-for-writing.patch b/queue-2.6.36/tracing-fix-panic-when-lseek-called-on-trace-opened-for-writing.patch new file mode 100644 index 00000000000..5e3566faff0 --- /dev/null +++ b/queue-2.6.36/tracing-fix-panic-when-lseek-called-on-trace-opened-for-writing.patch @@ -0,0 +1,48 @@ +From 364829b1263b44aa60383824e4c1289d83d78ca7 Mon Sep 17 00:00:00 2001 +From: Slava Pestov +Date: Wed, 24 Nov 2010 15:13:16 -0800 +Subject: tracing: Fix panic when lseek() called on "trace" opened for writing + +From: Slava Pestov + +commit 364829b1263b44aa60383824e4c1289d83d78ca7 upstream. + +The file_ops struct for the "trace" special file defined llseek as seq_lseek(). +However, if the file was opened for writing only, seq_open() was not called, +and the seek would dereference a null pointer, file->private_data. + +This patch introduces a new wrapper for seq_lseek() which checks if the file +descriptor is opened for reading first. If not, it does nothing. + +Signed-off-by: Slava Pestov +LKML-Reference: <1290640396-24179-1-git-send-email-slavapestov@google.com> +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/trace.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -2320,11 +2320,19 @@ tracing_write_stub(struct file *filp, co + return count; + } + ++static loff_t tracing_seek(struct file *file, loff_t offset, int origin) ++{ ++ if (file->f_mode & FMODE_READ) ++ return seq_lseek(file, offset, origin); ++ else ++ return 0; ++} ++ + static const struct file_operations tracing_fops = { + .open = tracing_open, + .read = seq_read, + .write = tracing_write_stub, +- .llseek = seq_lseek, ++ .llseek = tracing_seek, + .release = tracing_release, + }; + diff --git a/queue-2.6.36/x86-amd-fix-panic-on-amd-cpu-family-0x15.patch b/queue-2.6.36/x86-amd-fix-panic-on-amd-cpu-family-0x15.patch new file mode 100644 index 00000000000..b1147cdf1d4 --- /dev/null +++ b/queue-2.6.36/x86-amd-fix-panic-on-amd-cpu-family-0x15.patch @@ -0,0 +1,56 @@ +From andreas.herrmann3@amd.com Mon Dec 20 15:36:51 2010 +From: Andreas Herrmann +Date: Thu, 16 Dec 2010 21:29:37 +0100 +Subject: x86, amd: Fix panic on AMD CPU family 0x15 +To: "stable@kernel.org" +Message-ID: <20101216202937.GF29531@alberich.amd.com> +Content-Disposition: inline + +From: Andreas Herrmann + +[The mainline kernel doesn't have this problem. Commit "(23588c3) x86, +amd: Add support for CPUID topology extension of AMD CPUs" removed the +family check. But 2.6.32.y needs to be fixed.] + +This CPU family check is not required -- existence of the NodeId MSR +is indicated by a CPUID feature flag which is already checked in +amd_fixup_dcm() -- and it needlessly prevents amd_fixup_dcm() to be +called for newer AMD CPUs. + +In worst case this can lead to a panic in the scheduler code for AMD +family 0x15 multi-node AMD CPUs. I just have a picture of VGA console +output so I can't copy-and-paste it herein, but the call stack of such +a panic looked like: + + do_divide_error + ... + find_busiest_group + run_rebalance_domains + ... + apic_timer_interrupt + ... + cpu_idle + +The mainline kernel doesn't have this problem. Commit "(23588c3) x86, +amd: Add support for CPUID topology extension of AMD CPUs" removed the +family check. But 2.6.32.y needs to be fixed. + +Signed-off-by: Andreas Herrmann +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/amd.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/arch/x86/kernel/cpu/amd.c ++++ b/arch/x86/kernel/cpu/amd.c +@@ -305,8 +305,7 @@ static void __cpuinit amd_detect_cmp(str + /* use socket ID also for last level cache */ + per_cpu(cpu_llc_id, cpu) = c->phys_proc_id; + /* fixup topology information on multi-node processors */ +- if ((c->x86 == 0x10) && (c->x86_model == 9)) +- amd_fixup_dcm(c); ++ amd_fixup_dcm(c); + #endif + } + diff --git a/queue-2.6.36/x86-enable-the-intr-remap-fault-handling-after-local-apic-setup.patch b/queue-2.6.36/x86-enable-the-intr-remap-fault-handling-after-local-apic-setup.patch new file mode 100644 index 00000000000..9016345f3e1 --- /dev/null +++ b/queue-2.6.36/x86-enable-the-intr-remap-fault-handling-after-local-apic-setup.patch @@ -0,0 +1,67 @@ +From 7f7fbf45c6b748074546f7f16b9488ca71de99c1 Mon Sep 17 00:00:00 2001 +From: Kenji Kaneshige +Date: Tue, 30 Nov 2010 22:22:28 -0800 +Subject: x86: Enable the intr-remap fault handling after local APIC setup + +From: Kenji Kaneshige + +commit 7f7fbf45c6b748074546f7f16b9488ca71de99c1 upstream. + +Interrupt-remapping gets enabled very early in the boot, as it determines the +apic mode that the processor can use. And the current code enables the vt-d +fault handling before the setup_local_APIC(). And hence the APIC LDR registers +and data structure in the memory may not be initialized. So the vt-d fault +handling in logical xapic/x2apic modes were broken. + +Fix this by enabling the vt-d fault handling in the end_local_APIC_setup() + +A cleaner fix of enabling fault handling while enabling intr-remapping +will be addressed for v2.6.38. [ Enabling intr-remapping determines the +usage of x2apic mode and the apic mode determines the fault-handling +configuration. ] + +Signed-off-by: Kenji Kaneshige +LKML-Reference: <20101201062244.541996375@intel.com> +Signed-off-by: Suresh Siddha +Acked-by: Chris Wright +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/apic/apic.c | 8 ++++++++ + arch/x86/kernel/apic/probe_64.c | 7 ------- + 2 files changed, 8 insertions(+), 7 deletions(-) + +--- a/arch/x86/kernel/apic/apic.c ++++ b/arch/x86/kernel/apic/apic.c +@@ -1340,6 +1340,14 @@ void __cpuinit end_local_APIC_setup(void + + setup_apic_nmi_watchdog(NULL); + apic_pm_activate(); ++ ++ /* ++ * Now that local APIC setup is completed for BP, configure the fault ++ * handling for interrupt remapping. ++ */ ++ if (!smp_processor_id() && intr_remapping_enabled) ++ enable_drhd_fault_handling(); ++ + } + + #ifdef CONFIG_X86_X2APIC +--- a/arch/x86/kernel/apic/probe_64.c ++++ b/arch/x86/kernel/apic/probe_64.c +@@ -76,13 +76,6 @@ void __init default_setup_apic_routing(v + /* need to update phys_pkg_id */ + apic->phys_pkg_id = apicid_phys_pkg_id; + } +- +- /* +- * Now that apic routing model is selected, configure the +- * fault handling for intr remapping. +- */ +- if (intr_remapping_enabled) +- enable_drhd_fault_handling(); + } + + /* Same for both flat and physical. */ diff --git a/queue-2.6.36/x86-gcc-4.6-use-gcc-m-options-when-building-vdso.patch b/queue-2.6.36/x86-gcc-4.6-use-gcc-m-options-when-building-vdso.patch new file mode 100644 index 00000000000..8996dec1e28 --- /dev/null +++ b/queue-2.6.36/x86-gcc-4.6-use-gcc-m-options-when-building-vdso.patch @@ -0,0 +1,45 @@ +From de2a8cf98ecdde25231d6c5e7901e2cffaf32af9 Mon Sep 17 00:00:00 2001 +From: H. Peter Anvin +Date: Mon, 13 Dec 2010 16:01:38 -0800 +Subject: x86, gcc-4.6: Use gcc -m options when building vdso + +From: H. Peter Anvin + +commit de2a8cf98ecdde25231d6c5e7901e2cffaf32af9 upstream. + +The vdso Makefile passes linker-style -m options not to the linker but +to gcc. This happens to work with earlier gcc, but fails with gcc +4.6. Pass gcc-style -m options, instead. + +Note: all currently supported versions of gcc supports -m32, so there +is no reason to conditionalize it any more. + +Reported-by: H. J. Lu +Signed-off-by: H. Peter Anvin +LKML-Reference: +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/vdso/Makefile | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/vdso/Makefile ++++ b/arch/x86/vdso/Makefile +@@ -25,7 +25,7 @@ targets += vdso.so vdso.so.dbg vdso.lds + + export CPPFLAGS_vdso.lds += -P -C + +-VDSO_LDFLAGS_vdso.lds = -m elf_x86_64 -Wl,-soname=linux-vdso.so.1 \ ++VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \ + -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 + + $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so +@@ -69,7 +69,7 @@ vdso32.so-$(VDSO32-y) += sysenter + vdso32-images = $(vdso32.so-y:%=vdso32-%.so) + + CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds) +-VDSO_LDFLAGS_vdso32.lds = -m elf_i386 -Wl,-soname=linux-gate.so.1 ++VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-soname=linux-gate.so.1 + + # This makes sure the $(obj) subdirectory exists even though vdso32/ + # is not a kbuild sub-make subdirectory. diff --git a/queue-2.6.36/x86-vt-d-fix-the-vt-d-fault-handling-irq-migration-in-the-x2apic-mode.patch b/queue-2.6.36/x86-vt-d-fix-the-vt-d-fault-handling-irq-migration-in-the-x2apic-mode.patch new file mode 100644 index 00000000000..15a0b9de213 --- /dev/null +++ b/queue-2.6.36/x86-vt-d-fix-the-vt-d-fault-handling-irq-migration-in-the-x2apic-mode.patch @@ -0,0 +1,35 @@ +From 086e8ced65d9bcc4a8e8f1cd39b09640f2883f90 Mon Sep 17 00:00:00 2001 +From: Kenji Kaneshige +Date: Wed, 1 Dec 2010 09:40:32 -0800 +Subject: x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode + +From: Kenji Kaneshige + +commit 086e8ced65d9bcc4a8e8f1cd39b09640f2883f90 upstream. + +In x2apic mode, we need to set the upper address register of the fault +handling interrupt register of the vt-d hardware. Without this +irq migration of the vt-d fault handling interrupt is broken. + +Signed-off-by: Kenji Kaneshige +LKML-Reference: <1291225233.2648.39.camel@sbsiddha-MOBL3> +Signed-off-by: Suresh Siddha +Acked-by: Chris Wright +Tested-by: Takao Indoh +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/apic/io_apic.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/x86/kernel/apic/io_apic.c ++++ b/arch/x86/kernel/apic/io_apic.c +@@ -3626,6 +3626,7 @@ static int dmar_msi_set_affinity(unsigne + msg.data |= MSI_DATA_VECTOR(cfg->vector); + msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK; + msg.address_lo |= MSI_ADDR_DEST_ID(dest); ++ msg.address_hi = MSI_ADDR_BASE_HI | MSI_ADDR_EXT_DEST_ID(dest); + + dmar_msi_write(irq, &msg); + diff --git a/queue-2.6.36/x86-vt-d-handle-previous-faults-after-enabling-fault-handling.patch b/queue-2.6.36/x86-vt-d-handle-previous-faults-after-enabling-fault-handling.patch new file mode 100644 index 00000000000..e0eb76ec870 --- /dev/null +++ b/queue-2.6.36/x86-vt-d-handle-previous-faults-after-enabling-fault-handling.patch @@ -0,0 +1,46 @@ +From 7f99d946e71e71d484b7543b49e990508e70d0c0 Mon Sep 17 00:00:00 2001 +From: Suresh Siddha +Date: Tue, 30 Nov 2010 22:22:29 -0800 +Subject: x86, vt-d: Handle previous faults after enabling fault handling + +From: Suresh Siddha + +commit 7f99d946e71e71d484b7543b49e990508e70d0c0 upstream. + +Fault handling is getting enabled after enabling the interrupt-remapping (as +the success of interrupt-remapping can affect the apic mode and hence the +fault handling mode). + +Hence there can potentially be some faults between the window of enabling +interrupt-remapping in the vt-d and the fault-handling of the vt-d units. + +Handle any previous faults after enabling the vt-d fault handling. + +For v2.6.38 cleanup, need to check if we can remove the dmar_fault() in the +enable_intr_remapping() and see if we can enable fault handling along with +enabling intr-remapping. + +Signed-off-by: Suresh Siddha +LKML-Reference: <20101201062244.630417138@intel.com> +Acked-by: Chris Wright +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/dmar.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/pci/dmar.c ++++ b/drivers/pci/dmar.c +@@ -1414,6 +1414,11 @@ int __init enable_drhd_fault_handling(vo + (unsigned long long)drhd->reg_base_addr, ret); + return -1; + } ++ ++ /* ++ * Clear any previous faults. ++ */ ++ dmar_fault(iommu->irq, iommu); + } + + return 0; diff --git a/queue-2.6.36/x86-vt-d-quirk-for-masking-vtd-spec-errors-to-platform-error-handling-logic.patch b/queue-2.6.36/x86-vt-d-quirk-for-masking-vtd-spec-errors-to-platform-error-handling-logic.patch new file mode 100644 index 00000000000..af550c804cc --- /dev/null +++ b/queue-2.6.36/x86-vt-d-quirk-for-masking-vtd-spec-errors-to-platform-error-handling-logic.patch @@ -0,0 +1,72 @@ +From 254e42006c893f45bca48f313536fcba12206418 Mon Sep 17 00:00:00 2001 +From: Suresh Siddha +Date: Mon, 6 Dec 2010 12:26:30 -0800 +Subject: x86, vt-d: Quirk for masking vtd spec errors to platform error handling logic + +From: Suresh Siddha + +commit 254e42006c893f45bca48f313536fcba12206418 upstream. + +On platforms with Intel 7500 chipset, there were some reports of system +hang/NMI's during kexec/kdump in the presence of interrupt-remapping enabled. + +During kdump, there is a window where the devices might be still using old +kernel's interrupt information, while the kdump kernel is coming up. This can +cause vt-d faults as the interrupt configuration from the old kernel map to +null IRTE entries in the new kernel etc. (with out interrupt-remapping enabled, +we still have the same issue but in this case we will see benign spurious +interrupt hit the new kernel). + +Based on platform config settings, these platforms seem to generate NMI/SMI +when a vt-d fault happens and there were reports that the resulting SMI causes +the system to hang. + +Fix it by masking vt-d spec defined errors to platform error reporting logic. +VT-d spec related errors are already handled by the VT-d OS code, so need to +report the same error through other channels. + +Signed-off-by: Suresh Siddha +LKML-Reference: <1291667190.2675.8.camel@sbsiddha-MOBL3.sc.intel.com> +Reported-by: Max Asbock +Reported-and-tested-by: Takao Indoh +Acked-by: Chris Wright +Acked-by: Kenji Kaneshige +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/quirks.c | 23 +++++++++++++++++++++++ + 1 file changed, 23 insertions(+) + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -2714,6 +2714,29 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RI + DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832); + #endif /*CONFIG_MMC_RICOH_MMC*/ + ++#if defined(CONFIG_DMAR) || defined(CONFIG_INTR_REMAP) ++#define VTUNCERRMSK_REG 0x1ac ++#define VTD_MSK_SPEC_ERRORS (1 << 31) ++/* ++ * This is a quirk for masking vt-d spec defined errors to platform error ++ * handling logic. With out this, platforms using Intel 7500, 5500 chipsets ++ * (and the derivative chipsets like X58 etc) seem to generate NMI/SMI (based ++ * on the RAS config settings of the platform) when a vt-d fault happens. ++ * The resulting SMI caused the system to hang. ++ * ++ * VT-d spec related errors are already handled by the VT-d OS code, so no ++ * need to report the same error through other channels. ++ */ ++static void vtd_mask_spec_errors(struct pci_dev *dev) ++{ ++ u32 word; ++ ++ pci_read_config_dword(dev, VTUNCERRMSK_REG, &word); ++ pci_write_config_dword(dev, VTUNCERRMSK_REG, word | VTD_MSK_SPEC_ERRORS); ++} ++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x342e, vtd_mask_spec_errors); ++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x3c28, vtd_mask_spec_errors); ++#endif + + static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f, + struct pci_fixup *end)