From: Greg Kroah-Hartman Date: Mon, 30 Apr 2012 00:59:16 +0000 (-0700) Subject: 3.0-stable patches X-Git-Tag: v3.3.5~17 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=cce3a417b8d06066d44a4a6e93f115f0ea75f5a0;p=thirdparty%2Fkernel%2Fstable-queue.git 3.0-stable patches added patches: alsa-hda-realtek-add-quirk-for-mac-pro-5-1-machines.patch asoc-dapm-ensure-power-gets-managed-for-line-widgets.patch dmaengine-at_hdmac-remove-clear-on-read-in-atc_dostart.patch drm-i915-fix-integer-overflow-in-i915_gem_do_execbuffer.patch drm-i915-fix-integer-overflow-in-i915_gem_execbuffer2.patch drm-i915-handle-input-output-sdvo-timings-separately-in-mode_set.patch hwmon-fam15h_power-fix-bogus-values-with-current-bioses.patch hwmon-fam15h_power-fix-pci_device_id-array.patch nfs-enclose-hostname-in-brackets-when-needed-in.patch nfsv4-ensure-that-the-lock-code-sets-exception-inode.patch nfsv4-ensure-that-we-check-lock-exclusive-shared-type-against-open-modes.patch nl80211-ensure-interface-is-up-in-various-apis.patch revert-autofs-work-around-unhappy-compat-problem-on-x86-64.patch x86-apic-apic-code-touches-invalid-msr-on-p5-class-machines.patch xen-correctly-check-for-pending-events-when-restoring-irq-flags.patch xen-smp-fix-crash-when-booting-with-acpi-hotplug-cpus.patch --- diff --git a/queue-3.0/alsa-hda-realtek-add-quirk-for-mac-pro-5-1-machines.patch b/queue-3.0/alsa-hda-realtek-add-quirk-for-mac-pro-5-1-machines.patch new file mode 100644 index 00000000000..574ca73a4f0 --- /dev/null +++ b/queue-3.0/alsa-hda-realtek-add-quirk-for-mac-pro-5-1-machines.patch @@ -0,0 +1,36 @@ +From 29ebe40284c75a5888c601872059fca7e258528d Mon Sep 17 00:00:00 2001 +From: Josh Boyer +Date: Thu, 12 Apr 2012 13:55:36 -0400 +Subject: ALSA: hda/realtek - Add quirk for Mac Pro 5,1 machines + +From: Josh Boyer + +commit 29ebe40284c75a5888c601872059fca7e258528d upstream. + +A user reported that setting model=imac24 used to allow sound to work on their +Mac Pro 5,1 machine. Commit 5671087ffa "Move ALC885 macpro and imac24 models +to auto-parser" removed this model option. All Mac machines are now explicitly +handled with a quirk and the auto-parser. This adds a quirk for the device +found on the Mac Pro 5,1 machines. + +This (partially) fixes https://bugzilla.redhat.com/show_bug.cgi?id=808559 + +[sorted the new entry in the ID number order by tiwai] + +Reported-by: Gabriel Somlo +Signed-off-by: Josh Boyer +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c +index d25a6f9..8f4a484 100644 +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -5389,6 +5389,7 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = { + SND_PCI_QUIRK(0x106b, 0x3f00, "Macbook 5,1", ALC889_FIXUP_IMAC91_VREF), + SND_PCI_QUIRK(0x106b, 0x4000, "MacbookPro 5,1", ALC889_FIXUP_IMAC91_VREF), + SND_PCI_QUIRK(0x106b, 0x4100, "Macmini 3,1", ALC889_FIXUP_IMAC91_VREF), ++ SND_PCI_QUIRK(0x106b, 0x4200, "Mac Pro 5,1", ALC885_FIXUP_MACPRO_GPIO), + SND_PCI_QUIRK(0x106b, 0x4600, "MacbookPro 5,2", ALC889_FIXUP_IMAC91_VREF), + SND_PCI_QUIRK(0x106b, 0x4900, "iMac 9,1 Aluminum", ALC889_FIXUP_IMAC91_VREF), + SND_PCI_QUIRK(0x106b, 0x4a00, "Macbook 5,2", ALC889_FIXUP_IMAC91_VREF), diff --git a/queue-3.0/asoc-dapm-ensure-power-gets-managed-for-line-widgets.patch b/queue-3.0/asoc-dapm-ensure-power-gets-managed-for-line-widgets.patch new file mode 100644 index 00000000000..9f454e4c996 --- /dev/null +++ b/queue-3.0/asoc-dapm-ensure-power-gets-managed-for-line-widgets.patch @@ -0,0 +1,40 @@ +From 7e1f7c8a6e517900cd84da1b8ae020f08f286c3b Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Thu, 12 Apr 2012 17:29:36 +0100 +Subject: ASoC: dapm: Ensure power gets managed for line widgets + +From: Mark Brown + +commit 7e1f7c8a6e517900cd84da1b8ae020f08f286c3b upstream. + +Line widgets had not been included in either the power up or power down +sequences so if a widget had an event associated with it that event would +never be run. Fix this minimally by adding them to the sequences, we +should probably be doing away with the specific widget types as they all +have the same priority anyway. + +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + sound/soc/soc-dapm.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/sound/soc/soc-dapm.c ++++ b/sound/soc/soc-dapm.c +@@ -67,6 +67,7 @@ static int dapm_up_seq[] = { + [snd_soc_dapm_out_drv] = 10, + [snd_soc_dapm_hp] = 10, + [snd_soc_dapm_spk] = 10, ++ [snd_soc_dapm_line] = 10, + [snd_soc_dapm_post] = 11, + }; + +@@ -75,6 +76,7 @@ static int dapm_down_seq[] = { + [snd_soc_dapm_adc] = 1, + [snd_soc_dapm_hp] = 2, + [snd_soc_dapm_spk] = 2, ++ [snd_soc_dapm_line] = 2, + [snd_soc_dapm_out_drv] = 2, + [snd_soc_dapm_pga] = 4, + [snd_soc_dapm_mixer_named_ctl] = 5, diff --git a/queue-3.0/dmaengine-at_hdmac-remove-clear-on-read-in-atc_dostart.patch b/queue-3.0/dmaengine-at_hdmac-remove-clear-on-read-in-atc_dostart.patch new file mode 100644 index 00000000000..a5d80695c21 --- /dev/null +++ b/queue-3.0/dmaengine-at_hdmac-remove-clear-on-read-in-atc_dostart.patch @@ -0,0 +1,37 @@ +From ed8b0d67f33518a16c6b2450fe5ebebf180c2d04 Mon Sep 17 00:00:00 2001 +From: Nicolas Ferre +Date: Mon, 16 Apr 2012 14:46:30 +0200 +Subject: dmaengine: at_hdmac: remove clear-on-read in atc_dostart() + +From: Nicolas Ferre + +commit ed8b0d67f33518a16c6b2450fe5ebebf180c2d04 upstream. + +This loop on EBCISR register was designed to clear IRQ sources before enabling +a DMA channel. This register is clear-on-read so a race condition can appear if +another channel is already active and has just finished its transfer. +Removing this read on EBCISR is fixing the issue as there is no case where an IRQ +could be pending: we already make sure that this register is drained at probe() +time and during resume. + +Signed-off-by: Nicolas Ferre +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/dma/at_hdmac.c | 4 ---- + 1 file changed, 4 deletions(-) + +--- a/drivers/dma/at_hdmac.c ++++ b/drivers/dma/at_hdmac.c +@@ -237,10 +237,6 @@ static void atc_dostart(struct at_dma_ch + + vdbg_dump_regs(atchan); + +- /* clear any pending interrupt */ +- while (dma_readl(atdma, EBCISR)) +- cpu_relax(); +- + channel_writel(atchan, SADDR, 0); + channel_writel(atchan, DADDR, 0); + channel_writel(atchan, CTRLA, 0); diff --git a/queue-3.0/drm-i915-fix-integer-overflow-in-i915_gem_do_execbuffer.patch b/queue-3.0/drm-i915-fix-integer-overflow-in-i915_gem_do_execbuffer.patch new file mode 100644 index 00000000000..123b94f6a61 --- /dev/null +++ b/queue-3.0/drm-i915-fix-integer-overflow-in-i915_gem_do_execbuffer.patch @@ -0,0 +1,38 @@ +From 44afb3a04391a74309d16180d1e4f8386fdfa745 Mon Sep 17 00:00:00 2001 +From: Xi Wang +Date: Mon, 23 Apr 2012 04:06:42 -0400 +Subject: drm/i915: fix integer overflow in i915_gem_do_execbuffer() + +From: Xi Wang + +commit 44afb3a04391a74309d16180d1e4f8386fdfa745 upstream. + +On 32-bit systems, a large args->num_cliprects from userspace via ioctl +may overflow the allocation size, leading to out-of-bounds access. + +This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid +allocation for execbuffer object list"). + +Signed-off-by: Xi Wang +Reviewed-by: Chris Wilson +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c ++++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c +@@ -1046,6 +1046,11 @@ i915_gem_do_execbuffer(struct drm_device + return -EINVAL; + } + ++ if (args->num_cliprects > UINT_MAX / sizeof(*cliprects)) { ++ DRM_DEBUG("execbuf with %u cliprects\n", ++ args->num_cliprects); ++ return -EINVAL; ++ } + cliprects = kmalloc(args->num_cliprects * sizeof(*cliprects), + GFP_KERNEL); + if (cliprects == NULL) { diff --git a/queue-3.0/drm-i915-fix-integer-overflow-in-i915_gem_execbuffer2.patch b/queue-3.0/drm-i915-fix-integer-overflow-in-i915_gem_execbuffer2.patch new file mode 100644 index 00000000000..2651cb8f34e --- /dev/null +++ b/queue-3.0/drm-i915-fix-integer-overflow-in-i915_gem_execbuffer2.patch @@ -0,0 +1,36 @@ +From ed8cd3b2cd61004cab85380c52b1817aca1ca49b Mon Sep 17 00:00:00 2001 +From: Xi Wang +Date: Mon, 23 Apr 2012 04:06:41 -0400 +Subject: drm/i915: fix integer overflow in i915_gem_execbuffer2() + +From: Xi Wang + +commit ed8cd3b2cd61004cab85380c52b1817aca1ca49b upstream. + +On 32-bit systems, a large args->buffer_count from userspace via ioctl +may overflow the allocation size, leading to out-of-bounds access. + +This vulnerability was introduced in commit 8408c282 ("drm/i915: +First try a normal large kmalloc for the temporary exec buffers"). + +Signed-off-by: Xi Wang +Reviewed-by: Chris Wilson +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c ++++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c +@@ -1296,7 +1296,8 @@ i915_gem_execbuffer2(struct drm_device * + struct drm_i915_gem_exec_object2 *exec2_list = NULL; + int ret; + +- if (args->buffer_count < 1) { ++ if (args->buffer_count < 1 || ++ args->buffer_count > UINT_MAX / sizeof(*exec2_list)) { + DRM_ERROR("execbuf2 with %d buffers\n", args->buffer_count); + return -EINVAL; + } diff --git a/queue-3.0/drm-i915-handle-input-output-sdvo-timings-separately-in-mode_set.patch b/queue-3.0/drm-i915-handle-input-output-sdvo-timings-separately-in-mode_set.patch new file mode 100644 index 00000000000..1dfe74acb94 --- /dev/null +++ b/queue-3.0/drm-i915-handle-input-output-sdvo-timings-separately-in-mode_set.patch @@ -0,0 +1,178 @@ +From 6651819b4b4fc3caa6964c5d825eb4bb996f3905 Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Sun, 1 Apr 2012 19:16:18 +0200 +Subject: drm/i915: handle input/output sdvo timings separately in mode_set + +From: Daniel Vetter + +commit 6651819b4b4fc3caa6964c5d825eb4bb996f3905 upstream. + +We seem to have a decent confusion between the output timings and the +input timings of the sdvo encoder. If I understand the code correctly, +we use the original mode unchanged for the output timings, safe for +the lvds case. And we should use the adjusted mode for input timings. + +Clarify the situation by adding an explicit output_dtd to the sdvo +mode_set function and streamline the code-flow by moving the input and +output mode setting in the sdvo encode together. + +Furthermore testing showed that the sdvo input timing needs the +unadjusted dotclock, the sdvo chip will automatically compute the +required pixel multiplier to get a dotclock above 100 MHz. + +Fix this up when converting a drm mode to an sdvo dtd. + +This regression was introduced in + +commit c74696b9c890074c1e1ee3d7496fc71eb3680ced +Author: Pavel Roskin +Date: Thu Sep 2 14:46:34 2010 -0400 + + i915: revert some checks added by commit 32aad86f + +particularly the following hunk: + +# diff --git a/drivers/gpu/drm/i915/intel_sdvo.c +# b/drivers/gpu/drm/i915/intel_sdvo.c +# index 093e914..62d22ae 100644 +# --- a/drivers/gpu/drm/i915/intel_sdvo.c +# +++ b/drivers/gpu/drm/i915/intel_sdvo.c +# @@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder *encoder, +# +# /* We have tried to get input timing in mode_fixup, and filled into +# adjusted_mode */ +# - if (intel_sdvo->is_tv || intel_sdvo->is_lvds) { +# - intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode); +# + intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode); +# + if (intel_sdvo->is_tv || intel_sdvo->is_lvds) +# input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags; +# - } else +# - intel_sdvo_get_dtd_from_mode(&input_dtd, mode); +# +# /* If it's a TV, we already set the output timing in mode_fixup. +# * Otherwise, the output timing is equal to the input timing. + +Due to questions raised in review, below a more elaborate analysis of +the bug at hand: + +Sdvo seems to have two timings, one is the output timing which will be +sent over whatever is connected on the other side of the sdvo chip (panel, +hdmi screen, tv), the other is the input timing which will be generated by +the gmch pipe. It looks like sdvo is expected to scale between the two. + +To make things slightly more complicated, we have a bunch of special +cases: +- For lvds panel we always use a fixed output timing, namely + intel_sdvo->sdvo_lvds_fixed_mode, hence that special case. +- Sdvo has an interface to generate a preferred input timing for a given + output timing. This is the confusing thing that I've tried to clear up + with the follow-on patches. +- A special requirement is that the input pixel clock needs to be between + 100MHz and 200MHz (likely to keep it within the electromechanical design + range of PCIe), 270MHz on later gen4+. Lower pixel clocks are + doubled/quadrupled. + +The thing this patch tries to fix is that the pipe needs to be +explicitly instructed to double/quadruple the pixels and needs the +correspondingly higher pixel clock, whereas the sdvo adaptor seems to +do that itself and needs the unadjusted pixel clock. For the sdvo +encode side we already set the pixel mutliplier with a different +command (0x21). + +This patch tries to fix this mess by: +- Keeping the output mode timing in the unadjusted plain mode, safe + for the lvds case. +- Storing the input timing in the adjusted_mode with the adjusted + pixel clock. This way we don't need to frob around with the core + crtc mode set code. +- Fixing up the pixelclock when constructing the sdvo dtd timing + struct. This is why the first hunk of the patch is an integral part + of the series. +- Dropping the is_tv special case because input_dtd is equivalent to + adjusted_mode after these changes. Follow-up patches clear this up + further (by simply ripping out intel_sdvo->input_dtd because it's + not needed). + +v2: Extend commit message with an in-depth bug analysis. + +Reported-and-Tested-by: Bernard Blackham +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157 +Reviewed-by: Jesse Barnes +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_sdvo.c | 34 ++++++++++++++++++---------------- + 1 file changed, 18 insertions(+), 16 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_sdvo.c ++++ b/drivers/gpu/drm/i915/intel_sdvo.c +@@ -724,6 +724,7 @@ static void intel_sdvo_get_dtd_from_mode + uint16_t width, height; + uint16_t h_blank_len, h_sync_len, v_blank_len, v_sync_len; + uint16_t h_sync_offset, v_sync_offset; ++ int mode_clock; + + width = mode->crtc_hdisplay; + height = mode->crtc_vdisplay; +@@ -738,7 +739,11 @@ static void intel_sdvo_get_dtd_from_mode + h_sync_offset = mode->crtc_hsync_start - mode->crtc_hblank_start; + v_sync_offset = mode->crtc_vsync_start - mode->crtc_vblank_start; + +- dtd->part1.clock = mode->clock / 10; ++ mode_clock = mode->clock; ++ mode_clock /= intel_mode_get_pixel_multiplier(mode) ?: 1; ++ mode_clock /= 10; ++ dtd->part1.clock = mode_clock; ++ + dtd->part1.h_active = width & 0xff; + dtd->part1.h_blank = h_blank_len & 0xff; + dtd->part1.h_high = (((width >> 8) & 0xf) << 4) | +@@ -990,7 +995,7 @@ static void intel_sdvo_mode_set(struct d + struct intel_sdvo *intel_sdvo = to_intel_sdvo(encoder); + u32 sdvox; + struct intel_sdvo_in_out_map in_out; +- struct intel_sdvo_dtd input_dtd; ++ struct intel_sdvo_dtd input_dtd, output_dtd; + int pixel_multiplier = intel_mode_get_pixel_multiplier(adjusted_mode); + int rate; + +@@ -1015,20 +1020,13 @@ static void intel_sdvo_mode_set(struct d + intel_sdvo->attached_output)) + return; + +- /* We have tried to get input timing in mode_fixup, and filled into +- * adjusted_mode. +- */ +- if (intel_sdvo->is_tv || intel_sdvo->is_lvds) { +- input_dtd = intel_sdvo->input_dtd; +- } else { +- /* Set the output timing to the screen */ +- if (!intel_sdvo_set_target_output(intel_sdvo, +- intel_sdvo->attached_output)) +- return; +- +- intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode); +- (void) intel_sdvo_set_output_timing(intel_sdvo, &input_dtd); +- } ++ /* lvds has a special fixed output timing. */ ++ if (intel_sdvo->is_lvds) ++ intel_sdvo_get_dtd_from_mode(&output_dtd, ++ intel_sdvo->sdvo_lvds_fixed_mode); ++ else ++ intel_sdvo_get_dtd_from_mode(&output_dtd, mode); ++ (void) intel_sdvo_set_output_timing(intel_sdvo, &output_dtd); + + /* Set the input timing to the screen. Assume always input 0. */ + if (!intel_sdvo_set_target_input(intel_sdvo)) +@@ -1046,6 +1044,10 @@ static void intel_sdvo_mode_set(struct d + !intel_sdvo_set_tv_format(intel_sdvo)) + return; + ++ /* We have tried to get input timing in mode_fixup, and filled into ++ * adjusted_mode. ++ */ ++ intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode); + (void) intel_sdvo_set_input_timing(intel_sdvo, &input_dtd); + + switch (pixel_multiplier) { diff --git a/queue-3.0/hwmon-fam15h_power-fix-bogus-values-with-current-bioses.patch b/queue-3.0/hwmon-fam15h_power-fix-bogus-values-with-current-bioses.patch new file mode 100644 index 00000000000..589bb50b1fd --- /dev/null +++ b/queue-3.0/hwmon-fam15h_power-fix-bogus-values-with-current-bioses.patch @@ -0,0 +1,90 @@ +From 00250ec90963b7ef6678438888f3244985ecde14 Mon Sep 17 00:00:00 2001 +From: Andre Przywara +Date: Mon, 9 Apr 2012 18:16:34 -0400 +Subject: hwmon: fam15h_power: fix bogus values with current BIOSes + +From: Andre Przywara + +commit 00250ec90963b7ef6678438888f3244985ecde14 upstream. + +Newer BKDG[1] versions recommend a different initialization value for +the running average range register in the northbridge. This improves +the power reading by avoiding counter saturations resulting in bogus +values for anything below about 80% of TDP power consumption. +Updated BIOSes will have this new value set up from the beginning, +but meanwhile we correct this value ourselves. +This needs to be done on all northbridges, even on those where the +driver itself does not register at. + +This fixes the driver on all current machines to provide proper +values for idle load. + +[1] +http://support.amd.com/us/Processor_TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf +Chapter 3.8: D18F5xE0 Processor TDP Running Average (p. 452) + +Signed-off-by: Andre Przywara +Acked-by: Jean Delvare +[guenter.roeck@ericsson.com: Removed unnecessary return statement] +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hwmon/fam15h_power.c | 39 +++++++++++++++++++++++++++++++++++++++ + 1 file changed, 39 insertions(+) + +--- a/drivers/hwmon/fam15h_power.c ++++ b/drivers/hwmon/fam15h_power.c +@@ -122,6 +122,38 @@ static bool __devinit fam15h_power_is_in + return true; + } + ++/* ++ * Newer BKDG versions have an updated recommendation on how to properly ++ * initialize the running average range (was: 0xE, now: 0x9). This avoids ++ * counter saturations resulting in bogus power readings. ++ * We correct this value ourselves to cope with older BIOSes. ++ */ ++static void __devinit tweak_runavg_range(struct pci_dev *pdev) ++{ ++ u32 val; ++ const struct pci_device_id affected_device = { ++ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) }; ++ ++ /* ++ * let this quirk apply only to the current version of the ++ * northbridge, since future versions may change the behavior ++ */ ++ if (!pci_match_id(&affected_device, pdev)) ++ return; ++ ++ pci_bus_read_config_dword(pdev->bus, ++ PCI_DEVFN(PCI_SLOT(pdev->devfn), 5), ++ REG_TDP_RUNNING_AVERAGE, &val); ++ if ((val & 0xf) != 0xe) ++ return; ++ ++ val &= ~0xf; ++ val |= 0x9; ++ pci_bus_write_config_dword(pdev->bus, ++ PCI_DEVFN(PCI_SLOT(pdev->devfn), 5), ++ REG_TDP_RUNNING_AVERAGE, val); ++} ++ + static void __devinit fam15h_power_init_data(struct pci_dev *f4, + struct fam15h_power_data *data) + { +@@ -155,6 +187,13 @@ static int __devinit fam15h_power_probe( + struct device *dev; + int err; + ++ /* ++ * though we ignore every other northbridge, we still have to ++ * do the tweaking on _each_ node in MCM processors as the counters ++ * are working hand-in-hand ++ */ ++ tweak_runavg_range(pdev); ++ + if (!fam15h_power_is_internal_node0(pdev)) { + err = -ENODEV; + goto exit; diff --git a/queue-3.0/hwmon-fam15h_power-fix-pci_device_id-array.patch b/queue-3.0/hwmon-fam15h_power-fix-pci_device_id-array.patch new file mode 100644 index 00000000000..9a1cbd53dd9 --- /dev/null +++ b/queue-3.0/hwmon-fam15h_power-fix-pci_device_id-array.patch @@ -0,0 +1,47 @@ +From c3e40a9972428d6e2d8e287ed0233a57a218c30f Mon Sep 17 00:00:00 2001 +From: Guenter Roeck +Date: Wed, 25 Apr 2012 13:44:20 -0700 +Subject: hwmon: (fam15h_power) Fix pci_device_id array + +From: Guenter Roeck + +commit c3e40a9972428d6e2d8e287ed0233a57a218c30f upstream. + +pci_match_id() takes an *array* of IDs which must be properly zero- +terminated. + +Reported-by: Ben Hutchings +Signed-off-by: Guenter Roeck +Acked-by: Jean Delvare +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hwmon/fam15h_power.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/hwmon/fam15h_power.c ++++ b/drivers/hwmon/fam15h_power.c +@@ -128,17 +128,20 @@ static bool __devinit fam15h_power_is_in + * counter saturations resulting in bogus power readings. + * We correct this value ourselves to cope with older BIOSes. + */ ++static DEFINE_PCI_DEVICE_TABLE(affected_device) = { ++ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) }, ++ { 0 } ++}; ++ + static void __devinit tweak_runavg_range(struct pci_dev *pdev) + { + u32 val; +- const struct pci_device_id affected_device = { +- PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) }; + + /* + * let this quirk apply only to the current version of the + * northbridge, since future versions may change the behavior + */ +- if (!pci_match_id(&affected_device, pdev)) ++ if (!pci_match_id(affected_device, pdev)) + return; + + pci_bus_read_config_dword(pdev->bus, diff --git a/queue-3.0/nfs-enclose-hostname-in-brackets-when-needed-in.patch b/queue-3.0/nfs-enclose-hostname-in-brackets-when-needed-in.patch new file mode 100644 index 00000000000..cd0b7ca0d57 --- /dev/null +++ b/queue-3.0/nfs-enclose-hostname-in-brackets-when-needed-in.patch @@ -0,0 +1,47 @@ +From 98a2139f4f4d7b5fcc3a54c7fddbe88612abed20 Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Sat, 3 Sep 2011 01:09:43 +0200 +Subject: nfs: Enclose hostname in brackets when needed in + nfs_do_root_mount + +From: Jan Kara + +commit 98a2139f4f4d7b5fcc3a54c7fddbe88612abed20 upstream. + +When hostname contains colon (e.g. when it is an IPv6 address) it needs +to be enclosed in brackets to make parsing of NFS device string possible. +Fix nfs_do_root_mount() to enclose hostname properly when needed. NFS code +actually does not need this as it does not parse the string passed by +nfs_do_root_mount() but the device string is exposed to userspace in +/proc/mounts. + +CC: Josh Boyer +CC: Trond Myklebust +Signed-off-by: Jan Kara +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman + +--- + fs/nfs/super.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/fs/nfs/super.c ++++ b/fs/nfs/super.c +@@ -2694,11 +2694,15 @@ static struct vfsmount *nfs_do_root_moun + char *root_devname; + size_t len; + +- len = strlen(hostname) + 3; ++ len = strlen(hostname) + 5; + root_devname = kmalloc(len, GFP_KERNEL); + if (root_devname == NULL) + return ERR_PTR(-ENOMEM); +- snprintf(root_devname, len, "%s:/", hostname); ++ /* Does hostname needs to be enclosed in brackets? */ ++ if (strchr(hostname, ':')) ++ snprintf(root_devname, len, "[%s]:/", hostname); ++ else ++ snprintf(root_devname, len, "%s:/", hostname); + root_mnt = vfs_kern_mount(fs_type, flags, root_devname, data); + kfree(root_devname); + return root_mnt; diff --git a/queue-3.0/nfsv4-ensure-that-the-lock-code-sets-exception-inode.patch b/queue-3.0/nfsv4-ensure-that-the-lock-code-sets-exception-inode.patch new file mode 100644 index 00000000000..8187b5ec888 --- /dev/null +++ b/queue-3.0/nfsv4-ensure-that-the-lock-code-sets-exception-inode.patch @@ -0,0 +1,51 @@ +From 05ffe24f5290dc095f98fbaf84afe51ef404ccc5 Mon Sep 17 00:00:00 2001 +From: Trond Myklebust +Date: Wed, 18 Apr 2012 12:20:10 -0400 +Subject: NFSv4: Ensure that the LOCK code sets exception->inode + +From: Trond Myklebust + +commit 05ffe24f5290dc095f98fbaf84afe51ef404ccc5 upstream. + +All callers of nfs4_handle_exception() that need to handle +NFS4ERR_OPENMODE correctly should set exception->inode + +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman + +--- + fs/nfs/nfs4proc.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/fs/nfs/nfs4proc.c ++++ b/fs/nfs/nfs4proc.c +@@ -4424,7 +4424,9 @@ static int _nfs4_do_setlk(struct nfs4_st + static int nfs4_lock_reclaim(struct nfs4_state *state, struct file_lock *request) + { + struct nfs_server *server = NFS_SERVER(state->inode); +- struct nfs4_exception exception = { }; ++ struct nfs4_exception exception = { ++ .inode = state->inode, ++ }; + int err; + + do { +@@ -4442,7 +4444,9 @@ static int nfs4_lock_reclaim(struct nfs4 + static int nfs4_lock_expired(struct nfs4_state *state, struct file_lock *request) + { + struct nfs_server *server = NFS_SERVER(state->inode); +- struct nfs4_exception exception = { }; ++ struct nfs4_exception exception = { ++ .inode = state->inode, ++ }; + int err; + + err = nfs4_set_lock_state(state, request); +@@ -4508,6 +4512,7 @@ static int nfs4_proc_setlk(struct nfs4_s + { + struct nfs4_exception exception = { + .state = state, ++ .inode = state->inode, + }; + int err; + diff --git a/queue-3.0/nfsv4-ensure-that-we-check-lock-exclusive-shared-type-against-open-modes.patch b/queue-3.0/nfsv4-ensure-that-we-check-lock-exclusive-shared-type-against-open-modes.patch new file mode 100644 index 00000000000..a90d236bd35 --- /dev/null +++ b/queue-3.0/nfsv4-ensure-that-we-check-lock-exclusive-shared-type-against-open-modes.patch @@ -0,0 +1,42 @@ +From 55725513b5ef9d462aa3e18527658a0362aaae83 Mon Sep 17 00:00:00 2001 +From: Trond Myklebust +Date: Wed, 18 Apr 2012 12:48:35 -0400 +Subject: NFSv4: Ensure that we check lock exclusive/shared type against open modes + +From: Trond Myklebust + +commit 55725513b5ef9d462aa3e18527658a0362aaae83 upstream. + +Since we may be simulating flock() locks using NFS byte range locks, +we can't rely on the VFS having checked the file open mode for us. + +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman + +--- + fs/nfs/nfs4proc.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +--- a/fs/nfs/nfs4proc.c ++++ b/fs/nfs/nfs4proc.c +@@ -4558,6 +4558,20 @@ nfs4_proc_lock(struct file *filp, int cm + + if (state == NULL) + return -ENOLCK; ++ /* ++ * Don't rely on the VFS having checked the file open mode, ++ * since it won't do this for flock() locks. ++ */ ++ switch (request->fl_type & (F_RDLCK|F_WRLCK|F_UNLCK)) { ++ case F_RDLCK: ++ if (!(filp->f_mode & FMODE_READ)) ++ return -EBADF; ++ break; ++ case F_WRLCK: ++ if (!(filp->f_mode & FMODE_WRITE)) ++ return -EBADF; ++ } ++ + do { + status = nfs4_proc_setlk(state, cmd, request); + if ((status != -EAGAIN) || IS_SETLK(cmd)) diff --git a/queue-3.0/nl80211-ensure-interface-is-up-in-various-apis.patch b/queue-3.0/nl80211-ensure-interface-is-up-in-various-apis.patch new file mode 100644 index 00000000000..b5e66e65217 --- /dev/null +++ b/queue-3.0/nl80211-ensure-interface-is-up-in-various-apis.patch @@ -0,0 +1,150 @@ +From 2b5f8b0b44e17e625cfba1e7b88db44f4dcc0441 Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Mon, 2 Apr 2012 10:51:55 +0200 +Subject: nl80211: ensure interface is up in various APIs + +From: Johannes Berg + +commit 2b5f8b0b44e17e625cfba1e7b88db44f4dcc0441 upstream. +[backported by Ben Greear] + +The nl80211 handling code should ensure as much as +it can that the interface is in a valid state, it +can certainly ensure the interface is running. + +Not doing so can cause calls through mac80211 into +the driver that result in warnings and unspecified +behaviour in the driver. + +Reported-by: Ben Greear +Signed-off-by: Johannes Berg +Signed-off-by: John W. Linville +Signed-off-by: Ben Greear +Signed-off-by: Greg Kroah-Hartman + +--- + net/wireless/nl80211.c | 29 +++++++++++++++++------------ + 1 file changed, 17 insertions(+), 12 deletions(-) + +--- a/net/wireless/nl80211.c ++++ b/net/wireless/nl80211.c +@@ -1181,6 +1181,11 @@ static int nl80211_set_wiphy(struct sk_b + goto bad_res; + } + ++ if (!netif_running(netdev)) { ++ result = -ENETDOWN; ++ goto bad_res; ++ } ++ + nla_for_each_nested(nl_txq_params, + info->attrs[NL80211_ATTR_WIPHY_TXQ_PARAMS], + rem_txq_params) { +@@ -5432,7 +5437,7 @@ static struct genl_ops nl80211_ops[] = { + .doit = nl80211_get_key, + .policy = nl80211_policy, + .flags = GENL_ADMIN_PERM, +- .internal_flags = NL80211_FLAG_NEED_NETDEV | ++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP | + NL80211_FLAG_NEED_RTNL, + }, + { +@@ -5464,7 +5469,7 @@ static struct genl_ops nl80211_ops[] = { + .policy = nl80211_policy, + .flags = GENL_ADMIN_PERM, + .doit = nl80211_addset_beacon, +- .internal_flags = NL80211_FLAG_NEED_NETDEV | ++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP | + NL80211_FLAG_NEED_RTNL, + }, + { +@@ -5472,7 +5477,7 @@ static struct genl_ops nl80211_ops[] = { + .policy = nl80211_policy, + .flags = GENL_ADMIN_PERM, + .doit = nl80211_addset_beacon, +- .internal_flags = NL80211_FLAG_NEED_NETDEV | ++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP | + NL80211_FLAG_NEED_RTNL, + }, + { +@@ -5496,7 +5501,7 @@ static struct genl_ops nl80211_ops[] = { + .doit = nl80211_set_station, + .policy = nl80211_policy, + .flags = GENL_ADMIN_PERM, +- .internal_flags = NL80211_FLAG_NEED_NETDEV | ++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP | + NL80211_FLAG_NEED_RTNL, + }, + { +@@ -5512,7 +5517,7 @@ static struct genl_ops nl80211_ops[] = { + .doit = nl80211_del_station, + .policy = nl80211_policy, + .flags = GENL_ADMIN_PERM, +- .internal_flags = NL80211_FLAG_NEED_NETDEV | ++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP | + NL80211_FLAG_NEED_RTNL, + }, + { +@@ -5545,7 +5550,7 @@ static struct genl_ops nl80211_ops[] = { + .doit = nl80211_del_mpath, + .policy = nl80211_policy, + .flags = GENL_ADMIN_PERM, +- .internal_flags = NL80211_FLAG_NEED_NETDEV | ++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP | + NL80211_FLAG_NEED_RTNL, + }, + { +@@ -5553,7 +5558,7 @@ static struct genl_ops nl80211_ops[] = { + .doit = nl80211_set_bss, + .policy = nl80211_policy, + .flags = GENL_ADMIN_PERM, +- .internal_flags = NL80211_FLAG_NEED_NETDEV | ++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP | + NL80211_FLAG_NEED_RTNL, + }, + { +@@ -5579,7 +5584,7 @@ static struct genl_ops nl80211_ops[] = { + .doit = nl80211_get_mesh_config, + .policy = nl80211_policy, + /* can be retrieved by unprivileged users */ +- .internal_flags = NL80211_FLAG_NEED_NETDEV | ++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP | + NL80211_FLAG_NEED_RTNL, + }, + { +@@ -5711,7 +5716,7 @@ static struct genl_ops nl80211_ops[] = { + .doit = nl80211_setdel_pmksa, + .policy = nl80211_policy, + .flags = GENL_ADMIN_PERM, +- .internal_flags = NL80211_FLAG_NEED_NETDEV | ++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP | + NL80211_FLAG_NEED_RTNL, + }, + { +@@ -5719,7 +5724,7 @@ static struct genl_ops nl80211_ops[] = { + .doit = nl80211_setdel_pmksa, + .policy = nl80211_policy, + .flags = GENL_ADMIN_PERM, +- .internal_flags = NL80211_FLAG_NEED_NETDEV | ++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP | + NL80211_FLAG_NEED_RTNL, + }, + { +@@ -5727,7 +5732,7 @@ static struct genl_ops nl80211_ops[] = { + .doit = nl80211_flush_pmksa, + .policy = nl80211_policy, + .flags = GENL_ADMIN_PERM, +- .internal_flags = NL80211_FLAG_NEED_NETDEV | ++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP | + NL80211_FLAG_NEED_RTNL, + }, + { +@@ -5815,7 +5820,7 @@ static struct genl_ops nl80211_ops[] = { + .doit = nl80211_set_wds_peer, + .policy = nl80211_policy, + .flags = GENL_ADMIN_PERM, +- .internal_flags = NL80211_FLAG_NEED_NETDEV | ++ .internal_flags = NL80211_FLAG_NEED_NETDEV_UP | + NL80211_FLAG_NEED_RTNL, + }, + { diff --git a/queue-3.0/revert-autofs-work-around-unhappy-compat-problem-on-x86-64.patch b/queue-3.0/revert-autofs-work-around-unhappy-compat-problem-on-x86-64.patch new file mode 100644 index 00000000000..74d16bf4bad --- /dev/null +++ b/queue-3.0/revert-autofs-work-around-unhappy-compat-problem-on-x86-64.patch @@ -0,0 +1,123 @@ +From fcbf94b9dedd2ce08e798a99aafc94fec8668161 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Sat, 28 Apr 2012 08:29:56 -0700 +Subject: Revert "autofs: work around unhappy compat problem on x86-64" + +From: Linus Torvalds + +commit fcbf94b9dedd2ce08e798a99aafc94fec8668161 upstream. + +This reverts commit a32744d4abae24572eff7269bc17895c41bd0085. + +While that commit was technically the right thing to do, and made the +x86-64 compat mode work identically to native 32-bit mode (and thus +fixing the problem with a 32-bit systemd install on a 64-bit kernel), it +turns out that the automount binaries had workarounds for this compat +problem. + +Now, the workarounds are disgusting: doing an "uname()" to find out the +architecture of the kernel, and then comparing it for the 64-bit cases +and fixing up the size of the read() in automount for those. And they +were confused: it's not actually a generic 64-bit issue at all, it's +very much tied to just x86-64, which has different alignment for an +'u64' in 64-bit mode than in 32-bit mode. + +But the end result is that fixing the compat layer actually breaks the +case of a 32-bit automount on a x86-64 kernel. + +There are various approaches to fix this (including just doing a +"strcmp()" on current->comm and comparing it to "automount"), but I +think that I will do the one that teaches pipes about a special "packet +mode", which will allow user space to not have to care too deeply about +the padding at the end of the autofs packet. + +That change will make the compat workaround unnecessary, so let's revert +it first, and get automount working again in compat mode. The +packetized pipes will then fix autofs for systemd. + +Reported-and-requested-by: Michael Tokarev +Cc: Ian Kent +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/autofs4/autofs_i.h | 1 - + fs/autofs4/dev-ioctl.c | 1 - + fs/autofs4/inode.c | 2 -- + fs/autofs4/waitq.c | 20 ++------------------ + 4 files changed, 2 insertions(+), 22 deletions(-) + +--- a/fs/autofs4/autofs_i.h ++++ b/fs/autofs4/autofs_i.h +@@ -120,7 +120,6 @@ struct autofs_sb_info { + int sub_version; + int min_proto; + int max_proto; +- int compat_daemon; + unsigned long exp_timeout; + unsigned int type; + int reghost_enabled; +--- a/fs/autofs4/dev-ioctl.c ++++ b/fs/autofs4/dev-ioctl.c +@@ -385,7 +385,6 @@ static int autofs_dev_ioctl_setpipefd(st + sbi->pipefd = pipefd; + sbi->pipe = pipe; + sbi->catatonic = 0; +- sbi->compat_daemon = is_compat_task(); + } + out: + mutex_unlock(&sbi->wq_mutex); +--- a/fs/autofs4/inode.c ++++ b/fs/autofs4/inode.c +@@ -19,7 +19,6 @@ + #include + #include + #include +-#include + #include "autofs_i.h" + #include + +@@ -225,7 +224,6 @@ int autofs4_fill_super(struct super_bloc + set_autofs_type_indirect(&sbi->type); + sbi->min_proto = 0; + sbi->max_proto = 0; +- sbi->compat_daemon = is_compat_task(); + mutex_init(&sbi->wq_mutex); + spin_lock_init(&sbi->fs_lock); + sbi->queues = NULL; +--- a/fs/autofs4/waitq.c ++++ b/fs/autofs4/waitq.c +@@ -91,23 +91,6 @@ static int autofs4_write(struct file *fi + return (bytes > 0); + } + +-/* +- * The autofs_v5 packet was misdesigned. +- * +- * The packets are identical on x86-32 and x86-64, but have different +- * alignment. Which means that 'sizeof()' will give different results. +- * Fix it up for the case of running 32-bit user mode on a 64-bit kernel. +- */ +-static noinline size_t autofs_v5_packet_size(struct autofs_sb_info *sbi) +-{ +- size_t pktsz = sizeof(struct autofs_v5_packet); +-#if defined(CONFIG_X86_64) && defined(CONFIG_COMPAT) +- if (sbi->compat_daemon > 0) +- pktsz -= 4; +-#endif +- return pktsz; +-} +- + static void autofs4_notify_daemon(struct autofs_sb_info *sbi, + struct autofs_wait_queue *wq, + int type) +@@ -164,7 +147,8 @@ static void autofs4_notify_daemon(struct + { + struct autofs_v5_packet *packet = &pkt.v5_pkt.v5_packet; + +- pktsz = autofs_v5_packet_size(sbi); ++ pktsz = sizeof(*packet); ++ + packet->wait_queue_token = wq->wait_queue_token; + packet->len = wq->name.len; + memcpy(packet->name, wq->name.name, wq->name.len); diff --git a/queue-3.0/series b/queue-3.0/series new file mode 100644 index 00000000000..7e06d49019c --- /dev/null +++ b/queue-3.0/series @@ -0,0 +1,16 @@ +nfs-enclose-hostname-in-brackets-when-needed-in.patch +nfsv4-ensure-that-the-lock-code-sets-exception-inode.patch +nfsv4-ensure-that-we-check-lock-exclusive-shared-type-against-open-modes.patch +x86-apic-apic-code-touches-invalid-msr-on-p5-class-machines.patch +revert-autofs-work-around-unhappy-compat-problem-on-x86-64.patch +xen-correctly-check-for-pending-events-when-restoring-irq-flags.patch +xen-smp-fix-crash-when-booting-with-acpi-hotplug-cpus.patch +asoc-dapm-ensure-power-gets-managed-for-line-widgets.patch +dmaengine-at_hdmac-remove-clear-on-read-in-atc_dostart.patch +hwmon-fam15h_power-fix-bogus-values-with-current-bioses.patch +hwmon-fam15h_power-fix-pci_device_id-array.patch +drm-i915-handle-input-output-sdvo-timings-separately-in-mode_set.patch +drm-i915-fix-integer-overflow-in-i915_gem_execbuffer2.patch +drm-i915-fix-integer-overflow-in-i915_gem_do_execbuffer.patch +nl80211-ensure-interface-is-up-in-various-apis.patch +alsa-hda-realtek-add-quirk-for-mac-pro-5-1-machines.patch diff --git a/queue-3.0/x86-apic-apic-code-touches-invalid-msr-on-p5-class-machines.patch b/queue-3.0/x86-apic-apic-code-touches-invalid-msr-on-p5-class-machines.patch new file mode 100644 index 00000000000..9a8c7727df7 --- /dev/null +++ b/queue-3.0/x86-apic-apic-code-touches-invalid-msr-on-p5-class-machines.patch @@ -0,0 +1,88 @@ +From cbf2829b61c136edcba302a5e1b6b40e97d32c00 Mon Sep 17 00:00:00 2001 +From: Bryan O'Donoghue +Date: Wed, 18 Apr 2012 17:37:39 +0100 +Subject: x86, apic: APIC code touches invalid MSR on P5 class machines + +From: Bryan O'Donoghue + +commit cbf2829b61c136edcba302a5e1b6b40e97d32c00 upstream. + +Current APIC code assumes MSR_IA32_APICBASE is present for all systems. +Pentium Classic P5 and friends didn't have this MSR. MSR_IA32_APICBASE +was introduced as an architectural MSR by Intel @ P6. + +Code paths that can touch this MSR invalidly are when vendor == Intel && +cpu-family == 5 and APIC bit is set in CPUID - or when you simply pass +lapic on the kernel command line, on a P5. + +The below patch stops Linux incorrectly interfering with the +MSR_IA32_APICBASE for P5 class machines. Other code paths exist that +touch the MSR - however those paths are not currently reachable for a +conformant P5. + +Signed-off-by: Bryan O'Donoghue +Link: http://lkml.kernel.org/r/4F8EEDD3.1080404@linux.intel.com +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/apic/apic.c | 34 ++++++++++++++++++++-------------- + 1 file changed, 20 insertions(+), 14 deletions(-) + +--- a/arch/x86/kernel/apic/apic.c ++++ b/arch/x86/kernel/apic/apic.c +@@ -1558,9 +1558,11 @@ static int __init apic_verify(void) + mp_lapic_addr = APIC_DEFAULT_PHYS_BASE; + + /* The BIOS may have set up the APIC at some other address */ +- rdmsr(MSR_IA32_APICBASE, l, h); +- if (l & MSR_IA32_APICBASE_ENABLE) +- mp_lapic_addr = l & MSR_IA32_APICBASE_BASE; ++ if (boot_cpu_data.x86 >= 6) { ++ rdmsr(MSR_IA32_APICBASE, l, h); ++ if (l & MSR_IA32_APICBASE_ENABLE) ++ mp_lapic_addr = l & MSR_IA32_APICBASE_BASE; ++ } + + pr_info("Found and enabled local APIC!\n"); + return 0; +@@ -1578,13 +1580,15 @@ int __init apic_force_enable(unsigned lo + * MSR. This can only be done in software for Intel P6 or later + * and AMD K7 (Model > 1) or later. + */ +- rdmsr(MSR_IA32_APICBASE, l, h); +- if (!(l & MSR_IA32_APICBASE_ENABLE)) { +- pr_info("Local APIC disabled by BIOS -- reenabling.\n"); +- l &= ~MSR_IA32_APICBASE_BASE; +- l |= MSR_IA32_APICBASE_ENABLE | addr; +- wrmsr(MSR_IA32_APICBASE, l, h); +- enabled_via_apicbase = 1; ++ if (boot_cpu_data.x86 >= 6) { ++ rdmsr(MSR_IA32_APICBASE, l, h); ++ if (!(l & MSR_IA32_APICBASE_ENABLE)) { ++ pr_info("Local APIC disabled by BIOS -- reenabling.\n"); ++ l &= ~MSR_IA32_APICBASE_BASE; ++ l |= MSR_IA32_APICBASE_ENABLE | addr; ++ wrmsr(MSR_IA32_APICBASE, l, h); ++ enabled_via_apicbase = 1; ++ } + } + return apic_verify(); + } +@@ -2112,10 +2116,12 @@ static void lapic_resume(void) + * FIXME! This will be wrong if we ever support suspend on + * SMP! We'll need to do this as part of the CPU restore! + */ +- rdmsr(MSR_IA32_APICBASE, l, h); +- l &= ~MSR_IA32_APICBASE_BASE; +- l |= MSR_IA32_APICBASE_ENABLE | mp_lapic_addr; +- wrmsr(MSR_IA32_APICBASE, l, h); ++ if (boot_cpu_data.x86 >= 6) { ++ rdmsr(MSR_IA32_APICBASE, l, h); ++ l &= ~MSR_IA32_APICBASE_BASE; ++ l |= MSR_IA32_APICBASE_ENABLE | mp_lapic_addr; ++ wrmsr(MSR_IA32_APICBASE, l, h); ++ } + } + + maxlvt = lapic_get_maxlvt(); diff --git a/queue-3.0/xen-correctly-check-for-pending-events-when-restoring-irq-flags.patch b/queue-3.0/xen-correctly-check-for-pending-events-when-restoring-irq-flags.patch new file mode 100644 index 00000000000..f88c3803a5d --- /dev/null +++ b/queue-3.0/xen-correctly-check-for-pending-events-when-restoring-irq-flags.patch @@ -0,0 +1,44 @@ +From 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac Mon Sep 17 00:00:00 2001 +From: David Vrabel +Date: Thu, 26 Apr 2012 19:44:06 +0100 +Subject: xen: correctly check for pending events when restoring irq flags + +From: David Vrabel + +commit 7eb7ce4d2e8991aff4ecb71a81949a907ca755ac upstream. + +In xen_restore_fl_direct(), xen_force_evtchn_callback() was being +called even if no events were pending. This resulted in (depending on +workload) about a 100 times as many xen_version hypercalls as +necessary. + +Fix this by correcting the sense of the conditional jump. + +This seems to give a significant performance benefit for some +workloads. + +There is some subtle tricksy "..since the check here is trying to +check both pending and masked in a single cmpw, but I think this is +correct. It will call check_events now only when the combined +mask+pending word is 0x0001 (aka unmasked, pending)." (Ian) + +Acked-by: Ian Campbell +Signed-off-by: David Vrabel +Signed-off-by: Konrad Rzeszutek Wilk +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/xen/xen-asm.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/xen/xen-asm.S ++++ b/arch/x86/xen/xen-asm.S +@@ -96,7 +96,7 @@ ENTRY(xen_restore_fl_direct) + + /* check for unmasked and pending */ + cmpw $0x0001, PER_CPU_VAR(xen_vcpu_info) + XEN_vcpu_info_pending +- jz 1f ++ jnz 1f + 2: call check_events + 1: + ENDPATCH(xen_restore_fl_direct) diff --git a/queue-3.0/xen-smp-fix-crash-when-booting-with-acpi-hotplug-cpus.patch b/queue-3.0/xen-smp-fix-crash-when-booting-with-acpi-hotplug-cpus.patch new file mode 100644 index 00000000000..aeceefd9fe8 --- /dev/null +++ b/queue-3.0/xen-smp-fix-crash-when-booting-with-acpi-hotplug-cpus.patch @@ -0,0 +1,96 @@ +From cf405ae612b0f7e2358db7ff594c0e94846137aa Mon Sep 17 00:00:00 2001 +From: Konrad Rzeszutek Wilk +Date: Thu, 26 Apr 2012 13:50:03 -0400 +Subject: xen/smp: Fix crash when booting with ACPI hotplug CPUs. + +From: Konrad Rzeszutek Wilk + +commit cf405ae612b0f7e2358db7ff594c0e94846137aa upstream. + +When we boot on a machine that can hotplug CPUs and we +are using 'dom0_max_vcpus=X' on the Xen hypervisor line +to clip the amount of CPUs available to the initial domain, +we get this: + +(XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all +.. snip.. +DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011 +.. snip. +SMP: Allowing 64 CPUs, 32 hotplug CPUs +installing Xen timer for CPU 7 +cpu 7 spinlock event irq 361 +NMI watchdog: disabled (cpu7): hardware events not enabled +Brought up 8 CPUs +.. snip.. + [acpi processor finds the CPUs are not initialized and starts calling + arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online] +CPU 8 got hotplugged +CPU 9 got hotplugged +CPU 10 got hotplugged +.. snip.. +initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs +calling erst_init+0x0/0x2bb @ 1 + + [and the scheduler sticks newly started tasks on the new CPUs, but + said CPUs cannot be initialized b/c the hypervisor has limited the + amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag. + The spinlock tries to kick the other CPU, but the structure for that + is not initialized and we crash.] +BUG: unable to handle kernel paging request at fffffffffffffed8 +IP: [] xen_spin_lock+0x29/0x60 +PGD 180d067 PUD 180e067 PMD 0 +Oops: 0002 [#1] SMP +CPU 7 +Modules linked in: + +Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP +RIP: e030:[] [] xen_spin_lock+0x29/0x60 +RSP: e02b:ffff8801fb9b3a70 EFLAGS: 00010282 + +With this patch, we cap the amount of vCPUS that the initial domain +can run, to exactly what dom0_max_vcpus=X has specified. + +In the future, if there is a hypercall that will allow a running +domain to expand past its initial set of vCPUS, this patch should +be re-evaluated. + +Signed-off-by: Konrad Rzeszutek Wilk +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/xen/smp.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +--- a/arch/x86/xen/smp.c ++++ b/arch/x86/xen/smp.c +@@ -172,6 +172,7 @@ static void __init xen_fill_possible_map + static void __init xen_filter_cpu_maps(void) + { + int i, rc; ++ unsigned int subtract = 0; + + if (!xen_initial_domain()) + return; +@@ -186,8 +187,22 @@ static void __init xen_filter_cpu_maps(v + } else { + set_cpu_possible(i, false); + set_cpu_present(i, false); ++ subtract++; + } + } ++#ifdef CONFIG_HOTPLUG_CPU ++ /* This is akin to using 'nr_cpus' on the Linux command line. ++ * Which is OK as when we use 'dom0_max_vcpus=X' we can only ++ * have up to X, while nr_cpu_ids is greater than X. This ++ * normally is not a problem, except when CPU hotplugging ++ * is involved and then there might be more than X CPUs ++ * in the guest - which will not work as there is no ++ * hypercall to expand the max number of VCPUs an already ++ * running guest has. So cap it up to X. */ ++ if (subtract) ++ nr_cpu_ids = nr_cpu_ids - subtract; ++#endif ++ + } + + static void __init xen_smp_prepare_boot_cpu(void)