Skip to contentSkip to conversation

3.6.10-stable review

PATCH In review Greg Kroah-Hartman 8 participants 41 messages Dec 7, 2012 – Dec 9, 2012

Subsystems (28)
lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 3.6.10-stable review

This is the start of the stable review cycle for the 3.6.10 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sun Dec 9 00:57:22 UTC 2012. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.6.10-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 3.6.10-rc1

Francois Romieu <[email protected]>
8139cp: revert "set ring address before enabling receiver"

Andre Przywara <[email protected]>
x86, amd: Disable way access filter on Piledriver CPUs

Chris Wilson <[email protected]>
drm/i915: Add no-lvds quirk for Supermicro X7SPA-H

Calvin Walton <[email protected]>
i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

Alan Cox <[email protected]>
ACPI: missing break

Bjørn Mork <[email protected]>
net: qmi_wwan: add Huawei E173

Bjørn Mork <[email protected]>
net: qmi_wwan: adding more ZTE devices

Heiko Carstens <[email protected]>
s390/mm: have 16 byte aligned struct pages

Prarit Bhargava <[email protected]>
i7core_edac: fix panic when accessing sysfs files

Ariel Elior <[email protected]>
bnx2x: remove redundant warning log

Mike Galbraith <[email protected]>
Revert "sched, autogroup: Stop going ahead if autogroup is disabled"

Jean Delvare <[email protected]>
i7300_edac: Fix error flag testing

NeilBrown <[email protected]>
md/raid1{,0}: fix deadlock in bitmap_unplug.

Johannes Berg <[email protected]>
mac80211: fix remain-on-channel (non-)cancelling

Mike Galbraith <[email protected]>
workqueue: exit rescuer_thread() as TASK_RUNNING

Vincent Palatin <[email protected]>
x86, fpu: Avoid FPU lazy restore after suspend

Jason Gunthorpe <[email protected]>
ARM: Kirkwood: Update PCI-E fixup

Emmanuel Grumbach <[email protected]>
iwlwifi: fix the basic CCK rates calculation

Roland Dreier <[email protected]>
target: Fix handling of aborted commands

Naoya Horiguchi <[email protected]>
mm: soft offline: split thp at the beginning of soft_offline_page()

Johannes Weiner <[email protected]>
mm: vmscan: fix endless loop in kswapd balancing

Jianguo Wu <[email protected]>
mm/vmemmap: fix wrong use of virt_to_page

Alex Deucher <[email protected]>
drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop()

Alex Deucher <[email protected]>
drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2)

Alex Deucher <[email protected]>
drm/radeon/dce4+: don't use radeon_crtc for vblank callback

Russell King - ARM Linux <[email protected]>
Dove: Fix irq_to_pmu()

Russell King - ARM Linux <[email protected]>
Dove: Attempt to fix PMU/RTC interrupts

-------------

Diffstat:

 Makefile                                         |   4 +-
 arch/arm/Kconfig                                 |   1 +
 arch/arm/mach-dove/include/mach/pm.h             |   2 +-
 arch/arm/mach-dove/irq.c                         |  14 ++-
 arch/arm/mach-kirkwood/pcie.c                    |  11 ++-
 arch/s390/Kconfig                                |   1 +
 arch/x86/include/asm/fpu-internal.h              |  15 +--
 arch/x86/kernel/cpu/amd.c                        |  14 +++
 arch/x86/kernel/smpboot.c                        |   5 +
 drivers/acpi/processor_driver.c                  |   1 +
 drivers/edac/i7300_edac.c                        |   8 +-
 drivers/edac/i7core_edac.c                       |   6 +-
 drivers/gpu/drm/i915/intel_lvds.c                |  16 ++++
 drivers/gpu/drm/radeon/evergreen.c               | 191 +++++++++++++++++++------------------
 drivers/gpu/drm/radeon/evergreen_reg.h           |   2 +
 drivers/gpu/drm/radeon/evergreend.h              |   7 ++
 drivers/gpu/drm/radeon/radeon_asic.h             |   1 +
 drivers/md/raid1.c                               |   2 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |  11 ++-
 drivers/net/ethernet/realtek/8139cp.c            |  22 ++---
 drivers/net/usb/qmi_wwan.c                       |  42 ++++++++
 drivers/net/wireless/iwlwifi/dvm/rxon.c          |  12 +--
 drivers/target/target_core_transport.c           |   6 +-
 kernel/sched/auto_group.c                        |   4 -
 kernel/sched/auto_group.h                        |   5 -
 kernel/workqueue.c                               |   4 +-
 mm/memory-failure.c                              |   8 ++
 mm/sparse.c                                      |  10 +-
 mm/vmscan.c                                      |  27 ++++--
 net/mac80211/offchannel.c                        |   2 -
 30 files changed, 288 insertions(+), 166 deletions(-)
author maintainer
#1 lore raw

PATCH 1/27 Dove: Attempt to fix PMU/RTC interrupts

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Russell King - ARM Linux <[email protected]>

commit 5d3df935426271016b895aecaa247101b4bfa35e upstream.

Fix the acknowledgement of PMU interrupts on Dove: some Dove hardware has not been sensibly designed so that interrupts can be handled in a race free manner. The PMU is one such instance.

The pending (aka 'cause') register is a bunch of RW bits, meaning that these bits can be both cleared and set by software (confirmed on the Armada-510 on the cubox.)

Hardware sets the appropriate bit when an interrupt is asserted, and software is required to clear the bits which are to be processed. If we write ~(1 << bit), then we end up asserting every other interrupt except the one we're processing. So, we need to do a read-modify-write cycle to clear the asserted bit.

However, any interrupts which occur in the middle of this cycle will also be written back as zero, which will also clear the new interrupts.

The upshot of this is: there is _no_ way to safely clear down interrupts in this register (and other similarly behaving interrupt pending registers on this device.) The patch below at least stops us creating new interrupts.

---
 arch/arm/mach-dove/irq.c |   14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)
arch/arm/mach-dove/irq.c +13 -1
@@ -45,8 +45,20 @@ static void pmu_irq_ack(struct irq_data
 	int pin = irq_to_pmu(d->irq);
 	u32 u;
 
+	/*
+	 * The PMU mask register is not RW0C: it is RW.  This means that
+	 * the bits take whatever value is written to them; if you write
+	 * a '1', you will set the interrupt.
+	 *
+	 * Unfortunately this means there is NO race free way to clear
+	 * these interrupts.
+	 *
+	 * So, let's structure the code so that the window is as small as
+	 * possible.
+	 */
 	u = ~(1 << (pin & 31));
-	writel(u, PMU_INTERRUPT_CAUSE);
+	u &= readl_relaxed(PMU_INTERRUPT_CAUSE);
+	writel_relaxed(u, PMU_INTERRUPT_CAUSE);
 }
 
 static struct irq_chip pmu_irq_chip = {
author maintainer
#2 lore raw

PATCH 2/27 Dove: Fix irq_to_pmu()

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Russell King - ARM Linux <[email protected]>

commit d356cf5a74afa32b40decca3c9dd88bc3cd63eb5 upstream.

PMU interrupts start at IRQ_DOVE_PMU_START, not IRQ_DOVE_PMU_START + 1. Fix the condition. (It may have been less likely to occur had the code been written "if (irq >= IRQ_DOVE_PMU_START" which imho is the easier to understand notation, and matches the normal way of thinking about these things.)

---
 arch/arm/mach-dove/include/mach/pm.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/mach-dove/include/mach/pm.h +1 -1
@@ -45,7 +45,7 @@ static inline int pmu_to_irq(int pin)
 
 static inline int irq_to_pmu(int irq)
 {
-	if (IRQ_DOVE_PMU_START < irq && irq < NR_IRQS)
+	if (IRQ_DOVE_PMU_START <= irq && irq < NR_IRQS)
 		return irq - IRQ_DOVE_PMU_START;
 
 	return -EINVAL;
author maintainer
#3 lore raw

PATCH 3/27 drm/radeon/dce4+: dont use radeon_crtc for vblank callback

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alex Deucher <[email protected]>

commit 4a15903db02026728d0cf2755c6fabae16b8db6a upstream.

This might be called before we've allocated the radeon_crtcs

---
 drivers/gpu/drm/radeon/evergreen.c |   20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)
drivers/gpu/drm/radeon/evergreen.c +16 -4
@@ -37,6 +37,16 @@
 #define EVERGREEN_PFP_UCODE_SIZE 1120
 #define EVERGREEN_PM4_UCODE_SIZE 1376
 
+static const u32 crtc_offsets[6] =
+{
+	EVERGREEN_CRTC0_REGISTER_OFFSET,
+	EVERGREEN_CRTC1_REGISTER_OFFSET,
+	EVERGREEN_CRTC2_REGISTER_OFFSET,
+	EVERGREEN_CRTC3_REGISTER_OFFSET,
+	EVERGREEN_CRTC4_REGISTER_OFFSET,
+	EVERGREEN_CRTC5_REGISTER_OFFSET
+};
+
 static void evergreen_gpu_init(struct radeon_device *rdev);
 void evergreen_fini(struct radeon_device *rdev);
 void evergreen_pcie_gen2_enable(struct radeon_device *rdev);
@@ -109,17 +119,19 @@ void evergreen_fix_pci_max_read_req_size
  */
 void dce4_wait_for_vblank(struct radeon_device *rdev, int crtc)
 {
-	struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc];
 	int i;
 
-	if (RREG32(EVERGREEN_CRTC_CONTROL + radeon_crtc->crtc_offset) & EVERGREEN_CRTC_MASTER_EN) {
+	if (crtc >= rdev->num_crtc)
+		return;
+
+	if (RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[crtc]) & EVERGREEN_CRTC_MASTER_EN) {
 		for (i = 0; i < rdev->usec_timeout; i++) {
-			if (!(RREG32(EVERGREEN_CRTC_STATUS + radeon_crtc->crtc_offset) & EVERGREEN_CRTC_V_BLANK))
+			if (!(RREG32(EVERGREEN_CRTC_STATUS + crtc_offsets[crtc]) & EVERGREEN_CRTC_V_BLANK))
 				break;
 			udelay(1);
 		}
 		for (i = 0; i < rdev->usec_timeout; i++) {
-			if (RREG32(EVERGREEN_CRTC_STATUS + radeon_crtc->crtc_offset) & EVERGREEN_CRTC_V_BLANK)
+			if (RREG32(EVERGREEN_CRTC_STATUS + crtc_offsets[crtc]) & EVERGREEN_CRTC_V_BLANK)
 				break;
 			udelay(1);
 		}
author maintainer
#4 lore raw

PATCH 4/27 drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2)

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alex Deucher <[email protected]>

commit 62444b7462a2b98bc78d68736c03a7c4e66ba7e2 upstream.

- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access

This should fix issues some users have seen, especially with UEFI, when changing the MC FB location that result in hangs or display corruption.

v2: fix crtc enabled check noticed by Luca Tettamanti

---
 drivers/gpu/drm/radeon/evergreen.c     |  173 +++++++++++++++------------------
 drivers/gpu/drm/radeon/evergreen_reg.h |    2 
 drivers/gpu/drm/radeon/evergreend.h    |    7 +
 drivers/gpu/drm/radeon/radeon_asic.h   |    1 
 4 files changed, 90 insertions(+), 93 deletions(-)
drivers/gpu/drm/radeon/evergreen.c +80 -93
@@ -1241,116 +1241,103 @@ void evergreen_agp_enable(struct radeon_
 
 void evergreen_mc_stop(struct radeon_device *rdev, struct evergreen_mc_save *save)
 {
+	u32 crtc_enabled, tmp, frame_count, blackout;
+	int i, j;
+
 	save->vga_render_control = RREG32(VGA_RENDER_CONTROL);
 	save->vga_hdp_control = RREG32(VGA_HDP_CONTROL);
 
-	/* Stop all video */
+	/* disable VGA render */
 	WREG32(VGA_RENDER_CONTROL, 0);
-	WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC0_REGISTER_OFFSET, 1);
-	WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC1_REGISTER_OFFSET, 1);
-	if (rdev->num_crtc >= 4) {
-		WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC2_REGISTER_OFFSET, 1);
-		WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC3_REGISTER_OFFSET, 1);
-	}
-	if (rdev->num_crtc >= 6) {
-		WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC4_REGISTER_OFFSET, 1);
-		WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC5_REGISTER_OFFSET, 1);
-	}
-	WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC0_REGISTER_OFFSET, 0);
-	WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC1_REGISTER_OFFSET, 0);
-	if (rdev->num_crtc >= 4) {
-		WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC2_REGISTER_OFFSET, 0);
-		WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC3_REGISTER_OFFSET, 0);
-	}
-	if (rdev->num_crtc >= 6) {
-		WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC4_REGISTER_OFFSET, 0);
-		WREG32(EVERGREEN_CRTC_CONTROL + EVERGREEN_CRTC5_REGISTER_OFFSET, 0);
-	}
-	WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC0_REGISTER_OFFSET, 0);
-	WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC1_REGISTER_OFFSET, 0);
-	if (rdev->num_crtc >= 4) {
-		WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC2_REGISTER_OFFSET, 0);
-		WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC3_REGISTER_OFFSET, 0);
-	}
-	if (rdev->num_crtc >= 6) {
-		WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC4_REGISTER_OFFSET, 0);
-		WREG32(EVERGREEN_CRTC_UPDATE_LOCK + EVERGREEN_CRTC5_REGISTER_OFFSET, 0);
-	}
-
-	WREG32(D1VGA_CONTROL, 0);
-	WREG32(D2VGA_CONTROL, 0);
-	if (rdev->num_crtc >= 4) {
-		WREG32(EVERGREEN_D3VGA_CONTROL, 0);
-		WREG32(EVERGREEN_D4VGA_CONTROL, 0);
-	}
-	if (rdev->num_crtc >= 6) {
-		WREG32(EVERGREEN_D5VGA_CONTROL, 0);
-		WREG32(EVERGREEN_D6VGA_CONTROL, 0);
+	/* blank the display controllers */
+	for (i = 0; i < rdev->num_crtc; i++) {
+		crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]) & EVERGREEN_CRTC_MASTER_EN;
+		if (crtc_enabled) {
+			save->crtc_enabled[i] = true;
+			if (ASIC_IS_DCE6(rdev)) {
+				tmp = RREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i]);
+				if (!(tmp & EVERGREEN_CRTC_BLANK_DATA_EN)) {
+					radeon_wait_for_vblank(rdev, i);
+					tmp |= EVERGREEN_CRTC_BLANK_DATA_EN;
+					WREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i], tmp);
+				}
+			} else {
+				tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]);
+				if (!(tmp & EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE)) {
+					radeon_wait_for_vblank(rdev, i);
+					tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;
+					WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
+				}
+			}
+			/* wait for the next frame */
+			frame_count = radeon_get_vblank_counter(rdev, i);
+			for (j = 0; j < rdev->usec_timeout; j++) {
+				if (radeon_get_vblank_counter(rdev, i) != frame_count)
+					break;
+				udelay(1);
+			}
+		}
+	}
+
+	radeon_mc_wait_for_idle(rdev);
+
+	blackout = RREG32(MC_SHARED_BLACKOUT_CNTL);
+	if ((blackout & BLACKOUT_MODE_MASK) != 1) {
+		/* Block CPU access */
+		WREG32(BIF_FB_EN, 0);
+		/* blackout the MC */
+		blackout &= ~BLACKOUT_MODE_MASK;
+		WREG32(MC_SHARED_BLACKOUT_CNTL, blackout | 1);
 	}
 }
 
 void evergreen_mc_resume(struct radeon_device *rdev, struct evergreen_mc_save *save)
 {
-	WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH + EVERGREEN_CRTC0_REGISTER_OFFSET,
-	       upper_32_bits(rdev->mc.vram_start));
-	WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH + EVERGREEN_CRTC0_REGISTER_OFFSET,
-	       upper_32_bits(rdev->mc.vram_start));
-	WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + EVERGREEN_CRTC0_REGISTER_OFFSET,
-	       (u32)rdev->mc.vram_start);
-	WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + EVERGREEN_CRTC0_REGISTER_OFFSET,
-	       (u32)rdev->mc.vram_start);
-
-	WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH + EVERGREEN_CRTC1_REGISTER_OFFSET,
-	       upper_32_bits(rdev->mc.vram_start));
-	WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH + EVERGREEN_CRTC1_REGISTER_OFFSET,
-	       upper_32_bits(rdev->mc.vram_start));
-	WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + EVERGREEN_CRTC1_REGISTER_OFFSET,
-	       (u32)rdev->mc.vram_start);
-	WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + EVERGREEN_CRTC1_REGISTER_OFFSET,
-	       (u32)rdev->mc.vram_start);
-
-	if (rdev->num_crtc >= 4) {
-		WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH + EVERGREEN_CRTC2_REGISTER_OFFSET,
-		       upper_32_bits(rdev->mc.vram_start));
-		WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH + EVERGREEN_CRTC2_REGISTER_OFFSET,
-		       upper_32_bits(rdev->mc.vram_start));
-		WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + EVERGREEN_CRTC2_REGISTER_OFFSET,
-		       (u32)rdev->mc.vram_start);
-		WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + EVERGREEN_CRTC2_REGISTER_OFFSET,
-		       (u32)rdev->mc.vram_start);
+	u32 tmp, frame_count;
+	int i, j;
 
-		WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH + EVERGREEN_CRTC3_REGISTER_OFFSET,
+	/* update crtc base addresses */
+	for (i = 0; i < rdev->num_crtc; i++) {
+		WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH + crtc_offsets[i],
 		       upper_32_bits(rdev->mc.vram_start));
-		WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH + EVERGREEN_CRTC3_REGISTER_OFFSET,
+		WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH + crtc_offsets[i],
 		       upper_32_bits(rdev->mc.vram_start));
-		WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + EVERGREEN_CRTC3_REGISTER_OFFSET,
+		WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + crtc_offsets[i],
 		       (u32)rdev->mc.vram_start);
-		WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + EVERGREEN_CRTC3_REGISTER_OFFSET,
+		WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + crtc_offsets[i],
 		       (u32)rdev->mc.vram_start);
 	}
-	if (rdev->num_crtc >= 6) {
-		WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH + EVERGREEN_CRTC4_REGISTER_OFFSET,
-		       upper_32_bits(rdev->mc.vram_start));
-		WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH + EVERGREEN_CRTC4_REGISTER_OFFSET,
-		       upper_32_bits(rdev->mc.vram_start));
-		WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + EVERGREEN_CRTC4_REGISTER_OFFSET,
-		       (u32)rdev->mc.vram_start);
-		WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + EVERGREEN_CRTC4_REGISTER_OFFSET,
-		       (u32)rdev->mc.vram_start);
-
-		WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH + EVERGREEN_CRTC5_REGISTER_OFFSET,
-		       upper_32_bits(rdev->mc.vram_start));
-		WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH + EVERGREEN_CRTC5_REGISTER_OFFSET,
-		       upper_32_bits(rdev->mc.vram_start));
-		WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + EVERGREEN_CRTC5_REGISTER_OFFSET,
-		       (u32)rdev->mc.vram_start);
-		WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + EVERGREEN_CRTC5_REGISTER_OFFSET,
-		       (u32)rdev->mc.vram_start);
-	}
-
 	WREG32(EVERGREEN_VGA_MEMORY_BASE_ADDRESS_HIGH, upper_32_bits(rdev->mc.vram_start));
 	WREG32(EVERGREEN_VGA_MEMORY_BASE_ADDRESS, (u32)rdev->mc.vram_start);
-	/* Unlock host access */
+
+	/* unblackout the MC */
+	tmp = RREG32(MC_SHARED_BLACKOUT_CNTL);
+	tmp &= ~BLACKOUT_MODE_MASK;
+	WREG32(MC_SHARED_BLACKOUT_CNTL, tmp);
+	/* allow CPU access */
+	WREG32(BIF_FB_EN, FB_READ_EN | FB_WRITE_EN);
+
+	for (i = 0; i < rdev->num_crtc; i++) {
+		if (save->crtc_enabled) {
+			if (ASIC_IS_DCE6(rdev)) {
+				tmp = RREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i]);
+				tmp |= EVERGREEN_CRTC_BLANK_DATA_EN;
+				WREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i], tmp);
+			} else {
+				tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]);
+				tmp &= ~EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;
+				WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
+			}
+			/* wait for the next frame */
+			frame_count = radeon_get_vblank_counter(rdev, i);
+			for (j = 0; j < rdev->usec_timeout; j++) {
+				if (radeon_get_vblank_counter(rdev, i) != frame_count)
+					break;
+				udelay(1);
+			}
+		}
+	}
+	/* Unlock vga access */
 	WREG32(VGA_HDP_CONTROL, save->vga_hdp_control);
 	mdelay(1);
 	WREG32(VGA_RENDER_CONTROL, save->vga_render_control);
drivers/gpu/drm/radeon/evergreen_reg.h +2 -0
@@ -218,6 +218,8 @@
 #define EVERGREEN_CRTC_CONTROL                          0x6e70
 #       define EVERGREEN_CRTC_MASTER_EN                 (1 << 0)
 #       define EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE (1 << 24)
+#define EVERGREEN_CRTC_BLANK_CONTROL                    0x6e74
+#       define EVERGREEN_CRTC_BLANK_DATA_EN             (1 << 8)
 #define EVERGREEN_CRTC_STATUS                           0x6e8c
 #       define EVERGREEN_CRTC_V_BLANK                   (1 << 0)
 #define EVERGREEN_CRTC_STATUS_POSITION                  0x6e90
drivers/gpu/drm/radeon/evergreend.h +7 -0
@@ -87,6 +87,10 @@
 
 #define	CONFIG_MEMSIZE					0x5428
 
+#define	BIF_FB_EN						0x5490
+#define		FB_READ_EN					(1 << 0)
+#define		FB_WRITE_EN					(1 << 1)
+
 #define	CP_STRMOUT_CNTL					0x84FC
 
 #define	CP_COHER_CNTL					0x85F0
@@ -434,6 +438,9 @@
 #define		NOOFCHAN_MASK					0x00003000
 #define MC_SHARED_CHREMAP					0x2008
 
+#define MC_SHARED_BLACKOUT_CNTL           		0x20ac
+#define		BLACKOUT_MODE_MASK			0x00000007
+
 #define	MC_ARB_RAMCFG					0x2760
 #define		NOOFBANK_SHIFT					0
 #define		NOOFBANK_MASK					0x00000003
drivers/gpu/drm/radeon/radeon_asic.h +1 -0
@@ -389,6 +389,7 @@ void r700_cp_fini(struct radeon_device *
 struct evergreen_mc_save {
 	u32 vga_render_control;
 	u32 vga_hdp_control;
+	bool crtc_enabled[RADEON_MAX_CRTCS];
 };
 
 void evergreen_pcie_gart_tlb_flush(struct radeon_device *rdev);
author maintainer
#5 lore raw

PATCH 5/27 drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop()

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alex Deucher <[email protected]>

commit 804cc4a0ad3a896ca295f771a28c6eb36ced7903 upstream.

The save struct is not initialized previously so explicitly mark the crtcs as not used when they are not in use.

---
 drivers/gpu/drm/radeon/evergreen.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/gpu/drm/radeon/evergreen.c +2 -0
@@ -1276,6 +1276,8 @@ void evergreen_mc_stop(struct radeon_dev
 					break;
 				udelay(1);
 			}
+		} else {
+			save->crtc_enabled[i] = false;
 		}
 	}
 
author maintainer
#6 lore raw

PATCH 6/27 mm/vmemmap: fix wrong use of virt_to_page

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jianguo Wu <[email protected]>

commit ae64ffcac35de0db628ba9631edf8ff34c5cd7ac upstream.

I enable CONFIG_DEBUG_VIRTUAL and CONFIG_SPARSEMEM_VMEMMAP, when doing memory hotremove, there is a kernel BUG at arch/x86/mm/physaddr.c:20.

It is caused by free_section_usemap()->virt_to_page(), virt_to_page() is only used for kernel direct mapping address, but sparse-vmemmap uses vmemmap address, so it is going wrong here.

  ------------[ cut here ]------------
  kernel BUG at arch/x86/mm/physaddr.c:20!
  invalid opcode: 0000 [#1] SMP
  Modules linked in: acpihp_drv acpihp_slot edd cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf fuse vfat fat loop dm_mod coretemp kvm crc32c_intel ipv6 ixgbe igb iTCO_wdt i7core_edac edac_core pcspkr iTCO_vendor_support ioatdma microcode joydev sr_mod i2c_i801 dca lpc_ich mfd_core mdio tpm_tis i2c_core hid_generic tpm cdrom sg tpm_bios rtc_cmos button ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif processor thermal_sys hwmon scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic ata_piix libata megaraid_sas scsi_mod
  CPU 39
  Pid: 6454, comm: sh Not tainted 3.7.0-rc1-acpihp-final+ #45 QCI QSSC-S4R/QSSC-S4R
  RIP: 0010:[<ffffffff8103c908>]  [<ffffffff8103c908>] __phys_addr+0x88/0x90
  RSP: 0018:ffff8804440d7c08  EFLAGS: 00010006
  RAX: 0000000000000006 RBX: ffffea0012000000 RCX: 000000000000002c
  ...
---
 mm/sparse.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)
mm/sparse.c +4 -6
@@ -617,7 +617,7 @@ static void __kfree_section_memmap(struc
 {
 	return; /* XXX: Not implemented yet */
 }
-static void free_map_bootmem(struct page *page, unsigned long nr_pages)
+static void free_map_bootmem(struct page *memmap, unsigned long nr_pages)
 {
 }
 #else
@@ -658,10 +658,11 @@ static void __kfree_section_memmap(struc
 			   get_order(sizeof(struct page) * nr_pages));
 }
 
-static void free_map_bootmem(struct page *page, unsigned long nr_pages)
+static void free_map_bootmem(struct page *memmap, unsigned long nr_pages)
 {
 	unsigned long maps_section_nr, removing_section_nr, i;
 	unsigned long magic;
+	struct page *page = virt_to_page(memmap);
 
 	for (i = 0; i < nr_pages; i++, page++) {
 		magic = (unsigned long) page->lru.next;
@@ -710,13 +711,10 @@ static void free_section_usemap(struct p
 	 */
 
 	if (memmap) {
-		struct page *memmap_page;
-		memmap_page = virt_to_page(memmap);
-
 		nr_pages = PAGE_ALIGN(PAGES_PER_SECTION * sizeof(struct page))
 			>> PAGE_SHIFT;
 
-		free_map_bootmem(memmap_page, nr_pages);
+		free_map_bootmem(memmap, nr_pages);
 	}
 }
 
author maintainer
#7 lore raw

PATCH 7/27 mm: vmscan: fix endless loop in kswapd balancing

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johannes Weiner <[email protected]>

commit 60cefed485a02bd99b6299dad70666fe49245da7 upstream.

Kswapd does not in all places have the same criteria for a balanced zone. Zones are only being reclaimed when their high watermark is breached, but compaction checks loop over the zonelist again when the zone does not meet the low watermark plus two times the size of the allocation. This gets kswapd stuck in an endless loop over a small zone, like the DMA zone, where the high watermark is smaller than the compaction requirement.

Add a function, zone_balanced(), that checks the watermark, and, for higher order allocations, if compaction has enough free memory. Then use it uniformly to check for balanced zones.

This makes sure that when the compaction watermark is not met, at least reclaim happens and progress is made - or the zone is declared unreclaimable at some point and skipped entirely.

---
 mm/vmscan.c |   27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)
mm/vmscan.c +18 -9
@@ -2383,6 +2383,19 @@ static void age_active_anon(struct zone
 	} while (memcg);
 }
 
+static bool zone_balanced(struct zone *zone, int order,
+			  unsigned long balance_gap, int classzone_idx)
+{
+	if (!zone_watermark_ok_safe(zone, order, high_wmark_pages(zone) +
+				    balance_gap, classzone_idx, 0))
+		return false;
+
+	if (COMPACTION_BUILD && order && !compaction_suitable(zone, order))
+		return false;
+
+	return true;
+}
+
 /*
  * pgdat_balanced is used when checking if a node is balanced for high-order
  * allocations. Only zones that meet watermarks and are in a zone allowed
@@ -2461,8 +2474,7 @@ static bool prepare_kswapd_sleep(pg_data
 			continue;
 		}
 
-		if (!zone_watermark_ok_safe(zone, order, high_wmark_pages(zone),
-							i, 0))
+		if (!zone_balanced(zone, order, 0, i))
 			all_zones_ok = false;
 		else
 			balanced += zone->present_pages;
@@ -2571,8 +2583,7 @@ loop_again:
 				break;
 			}
 
-			if (!zone_watermark_ok_safe(zone, order,
-					high_wmark_pages(zone), 0, 0)) {
+			if (!zone_balanced(zone, order, 0, 0)) {
 				end_zone = i;
 				break;
 			} else {
@@ -2648,9 +2659,8 @@ loop_again:
 				testorder = 0;
 
 			if ((buffer_heads_over_limit && is_highmem_idx(i)) ||
-				    !zone_watermark_ok_safe(zone, testorder,
-					high_wmark_pages(zone) + balance_gap,
-					end_zone, 0)) {
+			    !zone_balanced(zone, testorder,
+					   balance_gap, end_zone)) {
 				shrink_zone(zone, &sc);
 
 				reclaim_state->reclaimed_slab = 0;
@@ -2677,8 +2687,7 @@ loop_again:
 				continue;
 			}
 
-			if (!zone_watermark_ok_safe(zone, testorder,
-					high_wmark_pages(zone), end_zone, 0)) {
+			if (!zone_balanced(zone, testorder, 0, end_zone)) {
 				all_zones_ok = 0;
 				/*
 				 * We are still under min water mark.  This
author maintainer
#8 lore raw

PATCH 8/27 mm: soft offline: split thp at the beginning of soft_offline_page()

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Naoya Horiguchi <[email protected]>

commit 783657a7dc20e5c0efbc9a09a9dd38e238a723da upstream.

When we try to soft-offline a thp tail page, put_page() is called on the tail page unthinkingly and VM_BUG_ON is triggered in put_compound_page().

This patch splits thp before going into the main body of soft-offlining.

---
 mm/memory-failure.c |    8 ++++++++
 1 file changed, 8 insertions(+)
mm/memory-failure.c +8 -0
@@ -1474,9 +1474,17 @@ int soft_offline_page(struct page *page,
 {
 	int ret;
 	unsigned long pfn = page_to_pfn(page);
+	struct page *hpage = compound_trans_head(page);
 
 	if (PageHuge(page))
 		return soft_offline_huge_page(page, flags);
+	if (PageTransHuge(hpage)) {
+		if (PageAnon(hpage) && unlikely(split_huge_page(hpage))) {
+			pr_info("soft offline: %#lx: failed to split THP\n",
+				pfn);
+			return -EBUSY;
+		}
+	}
 
 	ret = get_any_page(page, pfn, flags);
 	if (ret < 0)
author maintainer
#9 lore raw

PATCH 9/27 target: Fix handling of aborted commands

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Roland Dreier <[email protected]>

commit 3ea160b3e8f0de8161861995d9901f61192fc0b0 upstream.

- If we stop processing an already-aborted command in target_execute_cmd(), then we need to complete t_transport_stop_comp to wake up the the TMR handling thread, or else it will end up waiting forever.

- If we've a already sent an "aborted" status for a command in transport_check_aborted_status() then we should bail out of transport_send_task_abort() to avoid freeing the command twice.

---
 drivers/target/target_core_transport.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/target/target_core_transport.c +4 -2
@@ -1756,8 +1756,10 @@ void target_execute_cmd(struct se_cmd *c
 	/*
 	 * If the received CDB has aleady been aborted stop processing it here.
 	 */
-	if (transport_check_aborted_status(cmd, 1))
+	if (transport_check_aborted_status(cmd, 1)) {
+		complete(&cmd->t_transport_stop_comp);
 		return;
+	}
 
 	/*
 	 * Determine if IOCTL context caller in requesting the stopping of this
@@ -3029,7 +3031,7 @@ void transport_send_task_abort(struct se
 	unsigned long flags;
 
 	spin_lock_irqsave(&cmd->t_state_lock, flags);
-	if (cmd->se_cmd_flags & SCF_SENT_CHECK_CONDITION) {
+	if (cmd->se_cmd_flags & (SCF_SENT_CHECK_CONDITION | SCF_SENT_DELAYED_TAS)) {
 		spin_unlock_irqrestore(&cmd->t_state_lock, flags);
 		return;
 	}
author maintainer
#10 lore raw

PATCH 10/27 iwlwifi: fix the basic CCK rates calculation

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Emmanuel Grumbach <[email protected]>

commit 5edd0b946a0afeb1d0364a3654328b046fb818a2 upstream.

Fix a copy paste error in iwl_calc_basic_rates which leads to a wrong calculation of CCK basic rates.

---
 drivers/net/wireless/iwlwifi/dvm/rxon.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/net/wireless/iwlwifi/dvm/rxon.c +6 -6
@@ -1012,12 +1012,12 @@ static void iwl_calc_basic_rates(struct
 	 * As a consequence, it's not as complicated as it sounds, just add
 	 * any lower rates to the ACK rate bitmap.
 	 */
-	if (IWL_RATE_11M_INDEX < lowest_present_ofdm)
-		ofdm |= IWL_RATE_11M_MASK >> IWL_FIRST_CCK_RATE;
-	if (IWL_RATE_5M_INDEX < lowest_present_ofdm)
-		ofdm |= IWL_RATE_5M_MASK >> IWL_FIRST_CCK_RATE;
-	if (IWL_RATE_2M_INDEX < lowest_present_ofdm)
-		ofdm |= IWL_RATE_2M_MASK >> IWL_FIRST_CCK_RATE;
+	if (IWL_RATE_11M_INDEX < lowest_present_cck)
+		cck |= IWL_RATE_11M_MASK >> IWL_FIRST_CCK_RATE;
+	if (IWL_RATE_5M_INDEX < lowest_present_cck)
+		cck |= IWL_RATE_5M_MASK >> IWL_FIRST_CCK_RATE;
+	if (IWL_RATE_2M_INDEX < lowest_present_cck)
+		cck |= IWL_RATE_2M_MASK >> IWL_FIRST_CCK_RATE;
 	/* 1M already there or needed so always add */
 	cck |= IWL_RATE_1M_MASK >> IWL_FIRST_CCK_RATE;
 
author maintainer
#11 lore raw

PATCH 11/27 ARM: Kirkwood: Update PCI-E fixup

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jason Gunthorpe <[email protected]>

commit 1dc831bf53fddcc6443f74a39e72db5bcea4f15d upstream.

- The code relies on rc_pci_fixup being called, which only happens when CONFIG_PCI_QUIRKS is enabled, so add that to Kconfig. Omitting this causes a booting failure with a non-obvious cause.
- Update rc_pci_fixup to set the class properly, copying the more modern style from other places
- Correct the rc_pci_fixup comment

---
 arch/arm/Kconfig              |    1 +
 arch/arm/mach-kirkwood/pcie.c |   11 ++++++++---
 2 files changed, 9 insertions(+), 3 deletions(-)
arch/arm/Kconfig +1 -0
@@ -585,6 +585,7 @@ config ARCH_KIRKWOOD
 	bool "Marvell Kirkwood"
 	select CPU_FEROCEON
 	select PCI
+	select PCI_QUIRKS
 	select ARCH_REQUIRE_GPIOLIB
 	select GENERIC_CLOCKEVENTS
 	select NEED_MACH_IO_H
arch/arm/mach-kirkwood/pcie.c +8 -3
@@ -225,14 +225,19 @@ static int __init kirkwood_pcie_setup(in
 	return 1;
 }
 
+/*
+ * The root complex has a hardwired class of PCI_CLASS_MEMORY_OTHER, when it
+ * is operating as a root complex this needs to be switched to
+ * PCI_CLASS_BRIDGE_HOST or Linux will errantly try to process the BAR's on
+ * the device. Decoding setup is handled by the orion code.
+ */
 static void __devinit rc_pci_fixup(struct pci_dev *dev)
 {
-	/*
-	 * Prevent enumeration of root complex.
-	 */
 	if (dev->bus->parent == NULL && dev->devfn == 0) {
 		int i;
 
+		dev->class &= 0xff;
+		dev->class |= PCI_CLASS_BRIDGE_HOST << 8;
 		for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
 			dev->resource[i].start = 0;
 			dev->resource[i].end   = 0;
author maintainer
#12 lore raw

PATCH 12/27 x86, fpu: Avoid FPU lazy restore after suspend

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vincent Palatin <[email protected]>

commit 644c154186386bb1fa6446bc5e037b9ed098db46 upstream.

When a cpu enters S3 state, the FPU state is lost.
After resuming for S3, if we try to lazy restore the FPU for a process running on the same CPU, this will result in a corrupted FPU context.

Ensure that "fpu_owner_task" is properly invalided when (re-)initializing a CPU, so nobody will try to lazy restore a state which doesn't exist in the hardware.

Tested with a 64-bit kernel on a 4-core Ivybridge CPU with eagerfpu=off, by doing thousands of suspend/resume cycles with 4 processes doing FPU operations running. Without the patch, a process is killed after a few hundreds cycles by a SIGFPE.

---
 arch/x86/include/asm/fpu-internal.h |   15 +++++++++------
 arch/x86/kernel/smpboot.c           |    5 +++++
 2 files changed, 14 insertions(+), 6 deletions(-)
arch/x86/include/asm/fpu-internal.h +9 -6
@@ -334,14 +334,17 @@ static inline void __thread_fpu_begin(st
 typedef struct { int preload; } fpu_switch_t;
 
 /*
- * FIXME! We could do a totally lazy restore, but we need to
- * add a per-cpu "this was the task that last touched the FPU
- * on this CPU" variable, and the task needs to have a "I last
- * touched the FPU on this CPU" and check them.
+ * Must be run with preemption disabled: this clears the fpu_owner_task,
+ * on this CPU.
  *
- * We don't do that yet, so "fpu_lazy_restore()" always returns
- * false, but some day..
+ * This will disable any lazy FPU state restore of the current FPU state,
+ * but if the current thread owns the FPU, it will still be saved by.
  */
+static inline void __cpu_disable_lazy_restore(unsigned int cpu)
+{
+	per_cpu(fpu_owner_task, cpu) = NULL;
+}
+
 static inline int fpu_lazy_restore(struct task_struct *new, unsigned int cpu)
 {
 	return new == this_cpu_read_stable(fpu_owner_task) &&
arch/x86/kernel/smpboot.c +5 -0
@@ -68,6 +68,8 @@
 #include <asm/mwait.h>
 #include <asm/apic.h>
 #include <asm/io_apic.h>
+#include <asm/i387.h>
+#include <asm/fpu-internal.h>
 #include <asm/setup.h>
 #include <asm/uv/uv.h>
 #include <linux/mc146818rtc.h>
@@ -817,6 +819,9 @@ int __cpuinit native_cpu_up(unsigned int
 
 	per_cpu(cpu_state, cpu) = CPU_UP_PREPARE;
 
+	/* the FPU context is blank, nobody can own it */
+	__cpu_disable_lazy_restore(cpu);
+
 	err = do_boot_cpu(apicid, cpu, tidle);
 	if (err) {
 		pr_debug("do_boot_cpu failed %d\n", err);
author maintainer
#13 lore raw

PATCH 13/27 workqueue: exit rescuer_thread() as TASK_RUNNING

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mike Galbraith <[email protected]>

commit 412d32e6c98527078779e5b515823b2810e40324 upstream.

A rescue thread exiting TASK_INTERRUPTIBLE can lead to a task scheduling off, never to be seen again. In the case where this occurred, an exiting thread hit reiserfs homebrew conditional resched while holding a mutex, bringing the box to its knees.

PID: 18105 TASK: ffff8807fd412180 CPU: 5 COMMAND: "kdmflush"
#0 [ffff8808157e7670] schedule at ffffffff8143f489
#1 [ffff8808157e77b8] reiserfs_get_block at ffffffffa038ab2d [reiserfs] #2 [ffff8808157e79a8] __block_write_begin at ffffffff8117fb14 #3 [ffff8808157e7a98] reiserfs_write_begin at ffffffffa0388695 [reiserfs] #4 [ffff8808157e7ad8] generic_perform_write at ffffffff810ee9e2 #5 [ffff8808157e7b58] generic_file_buffered_write at ffffffff810eeb41 #6 [ffff8808157e7ba8] __generic_file_aio_write at ffffffff810f1a3a #7 [ffff8808157e7c58] generic_file_aio_write at ffffffff810f1c88 #8 [ffff8808157e7cc8] do_sync_write at ffffffff8114f850
#9 [ffff8808157e7dd8] do_acct_process at ffffffff810a268f

    [exception RIP: kernel_thread_helper]
    RIP: ffffffff8144a5c0  RSP: ffff8808157e7f58  RFLAGS: 00000202
    RAX: 0000000000000000  RBX: 0000000000000000  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: ffffffff8107af60  RDI: ffff8803ee491d18
    RBP: 0000000000000000   R8: 0000000000000000   R9: 0000000000000000
    R10: 0000000000000000  R11: 0000000000000000  R12: 0000000000000000
    R13: 0000000000000000  R14: 0000000000000000  R15: 0000000000000000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
---
 kernel/workqueue.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
kernel/workqueue.c +3 -1
@@ -2266,8 +2266,10 @@ static int rescuer_thread(void *__wq)
 repeat:
 	set_current_state(TASK_INTERRUPTIBLE);
 
-	if (kthread_should_stop())
+	if (kthread_should_stop()) {
+		__set_current_state(TASK_RUNNING);
 		return 0;
+	}
 
 	/*
 	 * See whether any cpu is asking for help.  Unbounded
author maintainer
#14 lore raw

PATCH 14/27 mac80211: fix remain-on-channel (non-)cancelling

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johannes Berg <[email protected]>

commit 6bdd253f635f7b2ef027d116933a6c9ec148b87f upstream.

Felix Liao reported that when an interface is set DOWN while another interface is executing a ROC, the warning in ieee80211_start_next_roc() (about the first item on the list having started already) triggers.

This is because ieee80211_roc_purge() calls it even if it never actually changed the list of ROC items. To fix this, simply remove the function call. If it is needed then it will be done by the ieee80211_sw_roc_work() function when the ROC item that is being removed while active is cleaned up.

---
 net/mac80211/offchannel.c |    2 --
 1 file changed, 2 deletions(-)
net/mac80211/offchannel.c +0 -2
@@ -453,8 +453,6 @@ void ieee80211_roc_purge(struct ieee8021
 		list_move_tail(&roc->list, &tmp_list);
 		roc->abort = true;
 	}
-
-	ieee80211_start_next_roc(local);
 	mutex_unlock(&local->mtx);
 
 	list_for_each_entry_safe(roc, tmp, &tmp_list, list) {
author maintainer
#15 lore raw

PATCH 15/27 md/raid1{,0}: fix deadlock in bitmap_unplug.

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: NeilBrown <[email protected]>

commit 874807a83139abc094f939e93623c5623573d543 upstream.

If the raid1 or raid10 unplug function gets called from a make_request function (which is very possible) when there are bios on the current->bio_list list, then it will not be able to successfully call bitmap_unplug() and it could need to submit more bios and wait for them to complete. But they won't complete while current->bio_list is non-empty.

So detect that case and handle the unplugging off to another thread just like we already do when called from within the scheduler.

RAID1 version of bug was introduced in 3.6, so that part of fix is suitable for 3.6.y. RAID10 part won't apply.

---
 drivers/md/raid1.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/raid1.c +1 -1
@@ -958,7 +958,7 @@ static void raid1_unplug(struct blk_plug
 	struct r1conf *conf = mddev->private;
 	struct bio *bio;
 
-	if (from_schedule) {
+	if (from_schedule || current->bio_list) {
 		spin_lock_irq(&conf->device_lock);
 		bio_list_merge(&conf->pending_bio_list, &plug->pending);
 		conf->pending_count += plug->pending_cnt;
author maintainer
#16 lore raw

PATCH 16/27 i7300_edac: Fix error flag testing

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jean Delvare <[email protected]>

commit 7e06b7a3333f5c7a0cec12aff20d39c5c87c0795 upstream.

* Right-shift the values in GET_FBD_FAT_IDX and GET_FBD_NF_IDX, so that the callers get the result they expect.
* Fix definition of FERR_FAT_FBD_ERR_MASK.
* Call GET_FBD_NF_IDX, not GET_FBD_FAT_IDX, when operating on register FERR_NF_FBD. We were lucky they have the same definition.

This fixes kernel bug #44131:
https://bugzilla.kernel.org/show_bug.cgi?id=44131

---
 drivers/edac/i7300_edac.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/edac/i7300_edac.c +4 -4
@@ -197,8 +197,8 @@ static const char *ferr_fat_fbd_name[] =
 	[0]  = "Memory Write error on non-redundant retry or "
 	       "FBD configuration Write error on retry",
 };
-#define GET_FBD_FAT_IDX(fbderr)	(fbderr & (3 << 28))
-#define FERR_FAT_FBD_ERR_MASK ((1 << 0) | (1 << 1) | (1 << 2) | (1 << 3))
+#define GET_FBD_FAT_IDX(fbderr)	(((fbderr) >> 28) & 3)
+#define FERR_FAT_FBD_ERR_MASK ((1 << 0) | (1 << 1) | (1 << 2) | (1 << 22))
 
 #define FERR_NF_FBD	0xa0
 static const char *ferr_nf_fbd_name[] = {
@@ -225,7 +225,7 @@ static const char *ferr_nf_fbd_name[] =
 	[1]  = "Aliased Uncorrectable Non-Mirrored Demand Data ECC",
 	[0]  = "Uncorrectable Data ECC on Replay",
 };
-#define GET_FBD_NF_IDX(fbderr)	(fbderr & (3 << 28))
+#define GET_FBD_NF_IDX(fbderr)	(((fbderr) >> 28) & 3)
 #define FERR_NF_FBD_ERR_MASK ((1 << 24) | (1 << 23) | (1 << 22) | (1 << 21) |\
 			      (1 << 18) | (1 << 17) | (1 << 16) | (1 << 15) |\
 			      (1 << 14) | (1 << 13) | (1 << 11) | (1 << 10) |\
@@ -464,7 +464,7 @@ static void i7300_process_fbd_error(stru
 		errnum = find_first_bit(&errors,
 					ARRAY_SIZE(ferr_nf_fbd_name));
 		specific = GET_ERR_FROM_TABLE(ferr_nf_fbd_name, errnum);
-		branch = (GET_FBD_FAT_IDX(error_reg) == 2) ? 1 : 0;
+		branch = (GET_FBD_NF_IDX(error_reg) == 2) ? 1 : 0;
 
 		pci_read_config_dword(pvt->pci_dev_16_1_fsb_addr_map,
 			REDMEMA, &syndrome);
author maintainer
#17 lore raw

PATCH 17/27 Revert "sched, autogroup: Stop going ahead if autogroup is disabled"

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mike Galbraith <[email protected]>

commit fd8ef11730f1d03d5d6555aa53126e9e34f52f12 upstream.

This reverts commit 800d4d30c8f20bd728e5741a3b77c4859a613f7c.

Between commits 8323f26ce342 ("sched: Fix race in task_group()") and 800d4d30c8f2 ("sched, autogroup: Stop going ahead if autogroup is disabled"), autogroup is a wreck.

With both applied, all you have to do to crash a box is disable autogroup during boot up, then reboot.. boom, NULL pointer dereference due to commit 800d4d30c8f2 not allowing autogroup to move things, and commit 8323f26ce342 making that the only way to switch runqueues:

  BUG: unable to handle kernel NULL pointer dereference at           (null)
  IP: [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
  Pid: 7047, comm: systemd-user-se Not tainted 3.6.8-smp #7 MEDIONPC MS-7502/MS-7502
  RIP: effective_load.isra.43+0x50/0x90
  Process systemd-user-se (pid: 7047, threadinfo ffff880221dde000, task ffff88022618b3a0)
  Call Trace:
    select_task_rq_fair+0x255/0x780
    try_to_wake_up+0x156/0x2c0
    wake_up_state+0xb/0x10
    signal_wake_up+0x28/0x40
    complete_signal+0x1d6/0x250
    __send_signal+0x170/0x310
    send_signal+0x40/0x80
    do_send_sig_info+0x47/0x90
    group_send_sig_info+0x4a/0x70
    kill_pid_info+0x3a/0x60
    sys_kill+0x97/0x1a0
    ? vfs_read+0x120/0x160
    ? sys_read+0x45/0x90
    system_call_fastpath+0x16/0x1b
  Code: 49 0f af 41 50 31 d2 49 f7 f0 48 83 f8 01 48 0f 46 c6 48 2b 07 48 8b bf 40 01 00 00 48 85 ff 74 3a 45 31 c0 48 8b 8f 50 01 00 00 <48> 8b 11 4c 8b 89 80 00 00 00 49 89 d2 48 01 d0 45 8b 59 58 4c
  RIP  [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
   RSP <ffff880221ddfbd8>
  CR2: 0000000000000000
---
 kernel/sched/auto_group.c |    4 ----
 kernel/sched/auto_group.h |    5 -----
 2 files changed, 9 deletions(-)
kernel/sched/auto_group.c +0 -4
@@ -143,15 +143,11 @@ autogroup_move_group(struct task_struct
 
 	p->signal->autogroup = autogroup_kref_get(ag);
 
-	if (!ACCESS_ONCE(sysctl_sched_autogroup_enabled))
-		goto out;
-
 	t = p;
 	do {
 		sched_move_task(t);
 	} while_each_thread(p, t);
 
-out:
 	unlock_task_sighand(p, &flags);
 	autogroup_kref_put(prev);
 }
kernel/sched/auto_group.h +0 -5
@@ -4,11 +4,6 @@
 #include <linux/rwsem.h>
 
 struct autogroup {
-	/*
-	 * reference doesn't mean how many thread attach to this
-	 * autogroup now. It just stands for the number of task
-	 * could use this autogroup.
-	 */
 	struct kref		kref;
 	struct task_group	*tg;
 	struct rw_semaphore	lock;
#18 lore raw

Re: [ 17/27] Revert "sched, autogroup: Stop going ahead if autogroup is disabled"

Quoted 91 lines · Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mike Galbraith <[email protected]>

commit fd8ef11730f1d03d5d6555aa53126e9e34f52f12 upstream.

This reverts commit 800d4d30c8f20bd728e5741a3b77c4859a613f7c.

Between commits 8323f26ce342 ("sched: Fix race in task_group()") and 800d4d30c8f2 ("sched, autogroup: Stop going ahead if autogroup is disabled"), autogroup is a wreck.

With both applied, all you have to do to crash a box is disable autogroup during boot up, then reboot.. boom, NULL pointer dereference due to commit 800d4d30c8f2 not allowing autogroup to move things, and commit 8323f26ce342 making that the only way to switch runqueues:

   BUG: unable to handle kernel NULL pointer dereference at           (null)
   IP: [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
   Pid: 7047, comm: systemd-user-se Not tainted 3.6.8-smp #7 MEDIONPC MS-7502/MS-7502
   RIP: effective_load.isra.43+0x50/0x90
   Process systemd-user-se (pid: 7047, threadinfo ffff880221dde000, task ffff88022618b3a0)
   Call Trace:
     select_task_rq_fair+0x255/0x780
     try_to_wake_up+0x156/0x2c0
     wake_up_state+0xb/0x10
     signal_wake_up+0x28/0x40
     complete_signal+0x1d6/0x250
     __send_signal+0x170/0x310
     send_signal+0x40/0x80
     do_send_sig_info+0x47/0x90
     group_send_sig_info+0x4a/0x70
     kill_pid_info+0x3a/0x60
     sys_kill+0x97/0x1a0
     ? vfs_read+0x120/0x160
     ? sys_read+0x45/0x90
     system_call_fastpath+0x16/0x1b
   Code: 49 0f af 41 50 31 d2 49 f7 f0 48 83 f8 01 48 0f 46 c6 48 2b 07 48 8b bf 40 01 00 00 48 85 ff 74 3a 45 31 c0 48 8b 8f 50 01 00 00 <48> 8b 11 4c 8b 89 80 00 00 00 49 89 d2 48 01 d0 45 8b 59 58 4c
   RIP  [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
    RSP <ffff880221ddfbd8>
   CR2: 0000000000000000
---
  kernel/sched/auto_group.c |    4 ----
  kernel/sched/auto_group.h |    5 -----
  2 files changed, 9 deletions(-)
kernel/sched/auto_group.c +0 -4
@@ -143,15 +143,11 @@ autogroup_move_group(struct task_struct
 
  	p->signal->autogroup = autogroup_kref_get(ag);
 
-	if (!ACCESS_ONCE(sysctl_sched_autogroup_enabled))
-		goto out;
-
  	t = p;
  	do {
  		sched_move_task(t);
  	} while_each_thread(p, t);
 
-out:
  	unlock_task_sighand(p, &flags);
  	autogroup_kref_put(prev);
  }
kernel/sched/auto_group.h +0 -6
@@ -4,11 +4,6 @@
  #include <linux/rwsem.h>
 
  struct autogroup {
-	/*
-	 * reference doesn't mean how many thread attach to this
-	 * autogroup now. It just stands for the number of task
-	 * could use this autogroup.
-	 */
  	struct kref		kref;
  	struct task_group	*tg;
  	struct rw_semaphore	lock;
 
 
--
Quoted 4 lines

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi Ben,

Will you also be including this patch in v3.5 stable? It has been tested and confirmed to resolve http://bugs.launchpad.net/bugs/1034099

Sincerely,

Joe Salisbury

#19 lore raw

Re: [ 17/27] Revert "sched, autogroup: Stop going ahead if autogroup is disabled"

Quoted 98 lines · Joseph Salisbury
Quoted 95 lines · Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mike Galbraith <[email protected]>

commit fd8ef11730f1d03d5d6555aa53126e9e34f52f12 upstream.

This reverts commit 800d4d30c8f20bd728e5741a3b77c4859a613f7c.

Between commits 8323f26ce342 ("sched: Fix race in task_group()") and 800d4d30c8f2 ("sched, autogroup: Stop going ahead if autogroup is disabled"), autogroup is a wreck.

With both applied, all you have to do to crash a box is disable autogroup during boot up, then reboot.. boom, NULL pointer dereference due to commit 800d4d30c8f2 not allowing autogroup to move things, and commit 8323f26ce342 making that the only way to switch runqueues:

   BUG: unable to handle kernel NULL pointer dereference at           

(null)
IP: [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
Pid: 7047, comm: systemd-user-se Not tainted 3.6.8-smp #7 MEDIONPC
MS-7502/MS-7502

   RIP: effective_load.isra.43+0x50/0x90
   Process systemd-user-se (pid: 7047, threadinfo ffff880221dde000, 
task ffff88022618b3a0)
   Call Trace:
     select_task_rq_fair+0x255/0x780
     try_to_wake_up+0x156/0x2c0
     wake_up_state+0xb/0x10
     signal_wake_up+0x28/0x40
     complete_signal+0x1d6/0x250
     __send_signal+0x170/0x310
     send_signal+0x40/0x80
     do_send_sig_info+0x47/0x90
     group_send_sig_info+0x4a/0x70
     kill_pid_info+0x3a/0x60
     sys_kill+0x97/0x1a0
     ? vfs_read+0x120/0x160
     ? sys_read+0x45/0x90
     system_call_fastpath+0x16/0x1b
   Code: 49 0f af 41 50 31 d2 49 f7 f0 48 83 f8 01 48 0f 46 c6 48 2b 
07 48 8b bf 40 01 00 00 48 85 ff 74 3a 45 31 c0 48 8b 8f 50 01 00 00 <48> 8b 11 4c 8b 89 80 00 00 00 49 89 d2 48 01 d0 45 8b 59 58 4c
   RIP  [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
    RSP <ffff880221ddfbd8>

CR2: 0000000000000000

---
  kernel/sched/auto_group.c |    4 ----
  kernel/sched/auto_group.h |    5 -----
  2 files changed, 9 deletions(-)
kernel/sched/auto_group.c +0 -2
@@ -143,15 +143,11 @@ autogroup_move_group(struct task_struct
        p->signal->autogroup = autogroup_kref_get(ag);
  -    if (!ACCESS_ONCE(sysctl_sched_autogroup_enabled))
-        goto out;
-
      t = p;
      do {
          sched_move_task(t);
      } while_each_thread(p, t);
  -out:
      unlock_task_sighand(p, &flags);
      autogroup_kref_put(prev);
  }
kernel/sched/auto_group.h +0 -5
@@ -4,11 +4,6 @@
  #include <linux/rwsem.h>
    struct autogroup {
-    /*
-     * reference doesn't mean how many thread attach to this
-     * autogroup now. It just stands for the number of task
-     * could use this autogroup.
-     */
      struct kref        kref;
      struct task_group    *tg;
      struct rw_semaphore    lock;
 
Signature · 5 lines
-- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Ben,

Quoted 6 lines

Will you also be including this patch in v3.5 stable? It has been tested and confirmed to resolve http://bugs.launchpad.net/bugs/1034099

Sincerely,

Joe Salisbury

Make that v3.2 stable. Sorry.

#20 lore raw

Re: [ 17/27] Revert "sched, autogroup: Stop going ahead if autogroup is disabled"

Quoted 16 lines · Joseph Salisbury
Quoted 15 lines · Joseph Salisbury
Quoted 14 lines · Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mike Galbraith <[email protected]>

commit fd8ef11730f1d03d5d6555aa53126e9e34f52f12 upstream.

This reverts commit 800d4d30c8f20bd728e5741a3b77c4859a613f7c.

Between commits 8323f26ce342 ("sched: Fix race in task_group()") and 800d4d30c8f2 ("sched, autogroup: Stop going ahead if autogroup is disabled"), autogroup is a wreck.

[...]

Quoted 11 lines
Quoted 9 lines

Hi Ben,

Will you also be including this patch in v3.5 stable? It has been tested and confirmed
to resolve http://bugs.launchpad.net/bugs/1034099

Sincerely,

Joe Salisbury

Make that v3.2 stable. Sorry.

Yes, if there's no objection to it.

Ben.

Signature · 2 lines
Ben Hutchings
It is impossible to make anything foolproof because fools are so ingenious.
author maintainer
#21 lore raw

Re: [ 17/27] Revert "sched, autogroup: Stop going ahead if autogroup is disabled"

In reply to Joseph Salisbury
Quoted 1 line · Joseph Salisbury

Will you also be including this patch in v3.5 stable?

There is no v3.5-stable kernel tree anymore, it has been end-of-life for a while.

There is a 3.5-stable tree that Canonical is doing, but no one on the
Cc: you sent this to is in control of that one.

Sorry,

greg k-h

#22 lore raw

Re: [ 17/27] Revert "sched, autogroup: Stop going ahead if autogroup is disabled"

Quoted 10 lines · Greg Kroah-Hartman
Quoted 1 line · Joseph Salisbury

Will you also be including this patch in v3.5 stable?

There is no v3.5-stable kernel tree anymore, it has been end-of-life for a while.

There is a 3.5-stable tree that Canonical is doing, but no one on the
Cc: you sent this to is in control of that one.

Sorry,

greg k-h

Sorry about the typo, I meant to request v3.2-stable.

Thanks,

Joe

author maintainer
#23 lore raw

PATCH 18/27 bnx2x: remove redundant warning log

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ariel Elior <[email protected]>

commit 4a25417c20fac00b3afd58ce27408f964d19e708 upstream.

fix bug where a register which was only meant to be read in 578xx/57712 devices causes a bogus error message to be logged when read from other devices.

---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c +7 -4
@@ -9545,10 +9545,13 @@ static int __devinit bnx2x_prev_unload_c
  */
 static void __devinit bnx2x_prev_interrupted_dmae(struct bnx2x *bp)
 {
-	u32 val = REG_RD(bp, PGLUE_B_REG_PGLUE_B_INT_STS);
-	if (val & PGLUE_B_PGLUE_B_INT_STS_REG_WAS_ERROR_ATTN) {
-		BNX2X_ERR("was error bit was found to be set in pglueb upon startup. Clearing");
-		REG_WR(bp, PGLUE_B_REG_WAS_ERROR_PF_7_0_CLR, 1 << BP_FUNC(bp));
+	if (!CHIP_IS_E1x(bp)) {
+		u32 val = REG_RD(bp, PGLUE_B_REG_PGLUE_B_INT_STS);
+		if (val & PGLUE_B_PGLUE_B_INT_STS_REG_WAS_ERROR_ATTN) {
+			BNX2X_ERR("was error bit was found to be set in pglueb upon startup. Clearing");
+			REG_WR(bp, PGLUE_B_REG_WAS_ERROR_PF_7_0_CLR,
+			       1 << BP_FUNC(bp));
+		}
 	}
 }
 
author maintainer
#24 lore raw

PATCH 19/27 i7core_edac: fix panic when accessing sysfs files

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Prarit Bhargava <[email protected]>

commit 42709efb3a47524c6252e1bdc85e205f7bc356fb upstream.

The i7core_edac addrmatch_dev and chancounts_dev have sysfs files associated with them. The sysfs files, however, are coded so that the parent device is is the mci device. This is incorrect and the mci struct should be obtained through the addrmatch_dev and chancounts_dev device's private data field which is populated in i7core_create_sysfs_devices().

---
 drivers/edac/i7core_edac.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/edac/i7core_edac.c +3 -3
@@ -816,7 +816,7 @@ static ssize_t i7core_inject_store_##par
 	struct device_attribute *mattr,				\
 	const char *data, size_t count)				\
 {								\
-	struct mem_ctl_info *mci = to_mci(dev);			\
+	struct mem_ctl_info *mci = dev_get_drvdata(dev);	\
 	struct i7core_pvt *pvt;					\
 	long value;						\
 	int rc;							\
@@ -845,7 +845,7 @@ static ssize_t i7core_inject_show_##para
 	struct device_attribute *mattr,				\
 	char *data)						\
 {								\
-	struct mem_ctl_info *mci = to_mci(dev);			\
+	struct mem_ctl_info *mci = dev_get_drvdata(dev);	\
 	struct i7core_pvt *pvt;					\
 								\
 	pvt = mci->pvt_info;					\
@@ -1052,7 +1052,7 @@ static ssize_t i7core_show_counter_##par
 	struct device_attribute *mattr,				\
 	char *data)						\
 {								\
-	struct mem_ctl_info *mci = to_mci(dev);			\
+	struct mem_ctl_info *mci = dev_get_drvdata(dev);	\
 	struct i7core_pvt *pvt = mci->pvt_info;			\
 								\
 	edac_dbg(1, "\n");					\
author maintainer
#25 lore raw

PATCH 20/27 s390/mm: have 16 byte aligned struct pages

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Heiko Carstens <[email protected]>

commit 4bffbb3455372a26816e364fb4448810f7014452 upstream.

Select HAVE_ALIGNED_STRUCT_PAGE on s390, so that the slub allocator can make use of compare and swap double for lockless updates. This increases the size of struct page to 64 bytes (instead of 56 bytes), however the performance gain justifies the increased size:

- now excactly four struct pages fit into a single cache line; the case that accessing a struct page causes two cache line loads does not exist anymore.
- calculating the offset of a struct page within the memmap array is only a simple shift instead of a more expensive multiplication.

A "hackbench 200 process 200" run on a 32 cpu system did show an 8% runtime improvement.

---
 arch/s390/Kconfig |    1 +
 1 file changed, 1 insertion(+)
arch/s390/Kconfig +1 -0
@@ -89,6 +89,7 @@ config S390
 	select HAVE_MEMBLOCK
 	select HAVE_MEMBLOCK_NODE_MAP
 	select HAVE_CMPXCHG_LOCAL
+	select HAVE_ALIGNED_STRUCT_PAGE if SLUB
 	select ARCH_DISCARD_MEMBLOCK
 	select BUILDTIME_EXTABLE_SORT
 	select ARCH_INLINE_SPIN_TRYLOCK
#26 lore raw

Re: [ 20/27] s390/mm: have 16 byte aligned struct pages

Quoted 19 lines · Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Heiko Carstens <[email protected]>

commit 4bffbb3455372a26816e364fb4448810f7014452 upstream.

Select HAVE_ALIGNED_STRUCT_PAGE on s390, so that the slub allocator can make use of compare and swap double for lockless updates. This increases the size of struct page to 64 bytes (instead of 56 bytes), however the performance gain justifies the increased size:

- now excactly four struct pages fit into a single cache line; the case that accessing a struct page causes two cache line loads does not exist anymore.
- calculating the offset of a struct page within the memmap array is only a simple shift instead of a more expensive multiplication.

Quoted 7 lines

A "hackbench 200 process 200" run on a 32 cpu system did show an 8% runtime improvement.

Same as for 3.4: compare and swap double is not available for 3.6 on s390.

author maintainer
#27 lore raw

Re: [ 20/27] s390/mm: have 16 byte aligned struct pages

Quoted 23 lines · Heiko Carstens
Quoted 22 lines · Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Heiko Carstens <[email protected]>

commit 4bffbb3455372a26816e364fb4448810f7014452 upstream.

Select HAVE_ALIGNED_STRUCT_PAGE on s390, so that the slub allocator can make use of compare and swap double for lockless updates. This increases the size of struct page to 64 bytes (instead of 56 bytes), however the performance gain justifies the increased size:

- now excactly four struct pages fit into a single cache line; the case that accessing a struct page causes two cache line loads does not exist anymore.
- calculating the offset of a struct page within the memmap array is only a simple shift instead of a more expensive multiplication.

A "hackbench 200 process 200" run on a 32 cpu system did show an 8% runtime improvement.

Quoted 6 lines
Quoted 4 lines

Same as for 3.4: compare and swap double is not available for 3.6 on s390.

Thanks for letting me know, and the review, much appreciated, I'll drop these from 3.4 and 3.6 now.

CAI, your track record here isn't very good, I'm going to now require you to get an ACK from the maintainer of all patches you are suggesting for the stable kernels, before I will take them. Please do that in the future, as this has wasted a lot of developer time, myself especially.

thanks,

greg k-h

author maintainer
#28 lore raw

PATCH 21/27 net: qmi_wwan: adding more ZTE devices

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bjørn Mork <[email protected]>

commit c6846ee148e07e4cfae4de486532efb02d238938 upstream.

Analyzed a few Windows driver description files, supporting this long list of devices:

%ztewwan.DeviceDesc0002%    = ztewwan.ndi, USB\VID_19D2&PID_0002&MI_01
%ztewwan.DeviceDesc0012%    = ztewwan.ndi, USB\VID_19D2&PID_0012&MI_01
%ztewwan.DeviceDesc0017%    = ztewwan.ndi, USB\VID_19D2&PID_0017&MI_03
%ztewwan.DeviceDesc0021%    = ztewwan.ndi, USB\VID_19D2&PID_0021&MI_04
%ztewwan.DeviceDesc0025%    = ztewwan.ndi, USB\VID_19D2&PID_0025&MI_01
%ztewwan.DeviceDesc0031%    = ztewwan.ndi, USB\VID_19D2&PID_0031&MI_04
%ztewwan.DeviceDesc0042%    = ztewwan.ndi, USB\VID_19D2&PID_0042&MI_04
%ztewwan.DeviceDesc0049%    = ztewwan.ndi, USB\VID_19D2&PID_0049&MI_05
%ztewwan.DeviceDesc0052%    = ztewwan.ndi, USB\VID_19D2&PID_0052&MI_04
%ztewwan.DeviceDesc0055%    = ztewwan.ndi, USB\VID_19D2&PID_0055&MI_01
%ztewwan.DeviceDesc0058%    = ztewwan.ndi, USB\VID_19D2&PID_0058&MI_04
%ztewwan.DeviceDesc0063%    = ztewwan.ndi, USB\VID_19D2&PID_0063&MI_04
%ztewwan.DeviceDesc2002%    = ztewwan.ndi, USB\VID_19D2&PID_2002&MI_04
%ztewwan.DeviceDesc0104%    = ztewwan.ndi, USB\VID_19D2&PID_0104&MI_04
%ztewwan.DeviceDesc0113%    = ztewwan.ndi, USB\VID_19D2&PID_0113&MI_05
%ztewwan.DeviceDesc0118%    = ztewwan.ndi, USB\VID_19D2&PID_0118&MI_05
%ztewwan.DeviceDesc0121%    = ztewwan.ndi, USB\VID_19D2&PID_0121&MI_05
%ztewwan.DeviceDesc0123%    = ztewwan.ndi, USB\VID_19D2&PID_0123&MI_04
%ztewwan.DeviceDesc0124%    = ztewwan.ndi, USB\VID_19D2&PID_0124&MI_05
%ztewwan.DeviceDesc0125%    = ztewwan.ndi, USB\VID_19D2&PID_0125&MI_06
%ztewwan.DeviceDesc0126%    = ztewwan.ndi, USB\VID_19D2&PID_0126&MI_05
%ztewwan.DeviceDesc1008%    = ztewwan.ndi, USB\VID_19D2&PID_1008&MI_04
%ztewwan.DeviceDesc1010%    = ztewwan.ndi, USB\VID_19D2&PID_1010&MI_04
%ztewwan.DeviceDesc1012%    = ztewwan.ndi, USB\VID_19D2&PID_1012&MI_04
%ztewwan.DeviceDesc1402%    = ztewwan.ndi, USB\VID_19D2&PID_1402&MI_02
%ztewwan.DeviceDesc0157%    = ztewwan.ndi, USB\VID_19D2&PID_0157&MI_05
%ztewwan.DeviceDesc0158%    = ztewwan.ndi, USB\VID_19D2&PID_0158&MI_03
%ztewwan.DeviceDesc1401%    = ztewwan.ndi, USB\VID_19D2&PID_1401&MI_02
%ztewwan.DeviceDesc0130%    = ztewwan.ndi, USB\VID_19D2&PID_0130&MI_01
%ztewwan.DeviceDesc0133%    = ztewwan.ndi, USB\VID_19D2&PID_0133&MI_03
%ztewwan.DeviceDesc0176%    = ztewwan.ndi, USB\VID_19D2&PID_0176&MI_03
%ztewwan.DeviceDesc0178%    = ztewwan.ndi, USB\VID_19D2&PID_0178&MI_03
%ztewwan.DeviceDesc0168%    = ztewwan.ndi, USB\VID_19D2&PID_0168&MI_04

;EuFi890
%ztewwan.DeviceDesc0191% = ztewwan.ndi, USB\VID_19D2&PID_0191&MI_04
;AL621
%ztewwan.DeviceDesc0167% = ztewwan.ndi, USB\VID_19D2&PID_0167&MI_04
;MF821

%ztewwan.DeviceDesc0199%    = ztewwan.ndi, USB\VID_19D2&PID_0199&MI_01
%ztewwan.DeviceDesc0200%    = ztewwan.ndi, USB\VID_19D2&PID_0200&MI_01
%ztewwan.DeviceDesc0257%    = ztewwan.ndi, USB\VID_19D2&PID_0257&MI_03

;MF821V
%ztewwan.DeviceDesc1018% = ztewwan.ndi, USB\VID_19D2&PID_1018&MI_03
;MF91
%ztewwan.DeviceDesc1426% = ztewwan.ndi, USB\VID_19D2&PID_1426&MI_02
;0141

%ztewwan.DeviceDesc1247%    = ztewwan.ndi, USB\VID_19D2&PID_1247&MI_04
%ztewwan.DeviceDesc1425%    = ztewwan.ndi, USB\VID_19D2&PID_1425&MI_02
%ztewwan.DeviceDesc1424%    = ztewwan.ndi, USB\VID_19D2&PID_1424&MI_02
%ztewwan.DeviceDesc1252%    = ztewwan.ndi, USB\VID_19D2&PID_1252&MI_04
%ztewwan.DeviceDesc1254%    = ztewwan.ndi, USB\VID_19D2&PID_1254&MI_04
%ztewwan.DeviceDesc1255A%   = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_03
%ztewwan.DeviceDesc1255B%   = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_04
%ztewwan.DeviceDesc1256%    = ztewwan.ndi, USB\VID_19D2&PID_1256&MI_04
%ztewwan.DeviceDesc1245%    = ztewwanCombB.ndi, USB\VID_19D2&PID_1245&MI_04
%ztewwan.DeviceDesc1021%    = ztewwan.ndi, USB\VID_19D2&PID_1021&MI_02

Adding the ones we were missing.

---
 drivers/net/usb/qmi_wwan.c |   41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)
drivers/net/usb/qmi_wwan.c +41 -0
@@ -398,16 +398,57 @@ static const struct usb_device_id produc
 	},
 
 	/* 3. Combined interface devices matching on interface number */
+	{QMI_FIXED_INTF(0x19d2, 0x0002, 1)},
+	{QMI_FIXED_INTF(0x19d2, 0x0012, 1)},
+	{QMI_FIXED_INTF(0x19d2, 0x0017, 3)},
+	{QMI_FIXED_INTF(0x19d2, 0x0021, 4)},
+	{QMI_FIXED_INTF(0x19d2, 0x0025, 1)},
+	{QMI_FIXED_INTF(0x19d2, 0x0031, 4)},
+	{QMI_FIXED_INTF(0x19d2, 0x0042, 4)},
+	{QMI_FIXED_INTF(0x19d2, 0x0049, 5)},
+	{QMI_FIXED_INTF(0x19d2, 0x0052, 4)},
 	{QMI_FIXED_INTF(0x19d2, 0x0055, 1)},	/* ZTE (Vodafone) K3520-Z */
+	{QMI_FIXED_INTF(0x19d2, 0x0058, 4)},
 	{QMI_FIXED_INTF(0x19d2, 0x0063, 4)},	/* ZTE (Vodafone) K3565-Z */
 	{QMI_FIXED_INTF(0x19d2, 0x0104, 4)},	/* ZTE (Vodafone) K4505-Z */
+	{QMI_FIXED_INTF(0x19d2, 0x0113, 5)},
+	{QMI_FIXED_INTF(0x19d2, 0x0118, 5)},
+	{QMI_FIXED_INTF(0x19d2, 0x0121, 5)},
+	{QMI_FIXED_INTF(0x19d2, 0x0123, 4)},
+	{QMI_FIXED_INTF(0x19d2, 0x0124, 5)},
+	{QMI_FIXED_INTF(0x19d2, 0x0125, 6)},
+	{QMI_FIXED_INTF(0x19d2, 0x0126, 5)},
+	{QMI_FIXED_INTF(0x19d2, 0x0130, 1)},
+	{QMI_FIXED_INTF(0x19d2, 0x0133, 3)},
+	{QMI_FIXED_INTF(0x19d2, 0x0141, 5)},
 	{QMI_FIXED_INTF(0x19d2, 0x0157, 5)},	/* ZTE MF683 */
+	{QMI_FIXED_INTF(0x19d2, 0x0158, 3)},
 	{QMI_FIXED_INTF(0x19d2, 0x0167, 4)},	/* ZTE MF820D */
+	{QMI_FIXED_INTF(0x19d2, 0x0168, 4)},
+	{QMI_FIXED_INTF(0x19d2, 0x0176, 3)},
+	{QMI_FIXED_INTF(0x19d2, 0x0178, 3)},
+	{QMI_FIXED_INTF(0x19d2, 0x0191, 4)},	/* ZTE EuFi890 */
+	{QMI_FIXED_INTF(0x19d2, 0x0199, 1)},	/* ZTE MF820S */
+	{QMI_FIXED_INTF(0x19d2, 0x0200, 1)},
+	{QMI_FIXED_INTF(0x19d2, 0x0257, 3)},	/* ZTE MF821 */
 	{QMI_FIXED_INTF(0x19d2, 0x0326, 4)},	/* ZTE MF821D */
 	{QMI_FIXED_INTF(0x19d2, 0x1008, 4)},	/* ZTE (Vodafone) K3570-Z */
 	{QMI_FIXED_INTF(0x19d2, 0x1010, 4)},	/* ZTE (Vodafone) K3571-Z */
+	{QMI_FIXED_INTF(0x19d2, 0x1012, 4)},
 	{QMI_FIXED_INTF(0x19d2, 0x1018, 3)},	/* ZTE (Vodafone) K5006-Z */
+	{QMI_FIXED_INTF(0x19d2, 0x1021, 2)},
+	{QMI_FIXED_INTF(0x19d2, 0x1245, 4)},
+	{QMI_FIXED_INTF(0x19d2, 0x1247, 4)},
+	{QMI_FIXED_INTF(0x19d2, 0x1252, 4)},
+	{QMI_FIXED_INTF(0x19d2, 0x1254, 4)},
+	{QMI_FIXED_INTF(0x19d2, 0x1255, 3)},
+	{QMI_FIXED_INTF(0x19d2, 0x1255, 4)},
+	{QMI_FIXED_INTF(0x19d2, 0x1256, 4)},
+	{QMI_FIXED_INTF(0x19d2, 0x1401, 2)},
 	{QMI_FIXED_INTF(0x19d2, 0x1402, 2)},	/* ZTE MF60 */
+	{QMI_FIXED_INTF(0x19d2, 0x1424, 2)},
+	{QMI_FIXED_INTF(0x19d2, 0x1425, 2)},
+	{QMI_FIXED_INTF(0x19d2, 0x1426, 2)},	/* ZTE MF91 */
 	{QMI_FIXED_INTF(0x19d2, 0x2002, 4)},	/* ZTE (Vodafone) K3765-Z */
 	{QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)},    /* Sierra Wireless MC7700 */
 	{QMI_FIXED_INTF(0x114f, 0x68a2, 8)},    /* Sierra Wireless MC7750 */
author maintainer
#29 lore raw

PATCH 22/27 net: qmi_wwan: add Huawei E173

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bjørn Mork <[email protected]>

commit ba695af067f9cadfec84457ac06b44e3fa849b15 upstream.

The Huawei E173 is a QMI/wwan device which normally appear as 12d1:1436 in Linux. The descriptors displayed in that mode will be picked up by cdc_ether. But the modem has another mode with a different device ID and a slightly different set of descriptors. This is the mode used by Windows like this:

3Modem: USB\VID_12D1&PID_140C&MI_00\6&3A1D2012&0&0000
Networkcard: USB\VID_12D1&PID_140C&MI_01\6&3A1D2012&0&0001 Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&3A1D2012&0&0002 PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&3A1D2012&0&0003

---
 drivers/net/usb/qmi_wwan.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/usb/qmi_wwan.c +1 -0
@@ -398,6 +398,7 @@ static const struct usb_device_id produc
 	},
 
 	/* 3. Combined interface devices matching on interface number */
+	{QMI_FIXED_INTF(0x12d1, 0x140c, 1)},	/* Huawei E173 */
 	{QMI_FIXED_INTF(0x19d2, 0x0002, 1)},
 	{QMI_FIXED_INTF(0x19d2, 0x0012, 1)},
 	{QMI_FIXED_INTF(0x19d2, 0x0017, 3)},
author maintainer
#30 lore raw

PATCH 23/27 ACPI: missing break

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alan Cox <[email protected]>

commit 879dca019dc43a1622edca3e7dde644b14b5acc5 upstream.

We handle NOTIFY_THROTTLING so don't then fall through to unsupported event.

---
 drivers/acpi/processor_driver.c |    1 +
 1 file changed, 1 insertion(+)
drivers/acpi/processor_driver.c +1 -0
@@ -409,6 +409,7 @@ static void acpi_processor_notify(struct
 		acpi_bus_generate_proc_event(device, event, 0);
 		acpi_bus_generate_netlink_event(device->pnp.device_class,
 						  dev_name(&device->dev), event, 0);
+		break;
 	default:
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 				  "Unsupported event [0x%x]\n", event));
author maintainer
#31 lore raw

PATCH 24/27 i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Calvin Walton <[email protected]>

commit a51d4ed01e5bb39d2cf36a12f9976ab08872c192 upstream.

This board is incorrectly detected as having an LVDS connector, resulting in the VGA output (the only available output on the board) showing the console only in the top-left 1024x768 pixels, and an extra LVDS connector appearing in X.

It's a desktop Mini-ITX board using an Atom D525 CPU with an NM10 chipset.

I've had this board for about a year, but this is the first time I noticed the issue because I've been running it headless for most of its life.

---
 drivers/gpu/drm/i915/intel_lvds.c |    8 ++++++++
 1 file changed, 8 insertions(+)
drivers/gpu/drm/i915/intel_lvds.c +8 -0
@@ -788,6 +788,14 @@ static const struct dmi_system_id intel_
 			DMI_MATCH(DMI_BOARD_NAME, "D525TUD"),
 		},
 	},
+	{
+		.callback = intel_no_lvds_dmi_callback,
+		.ident = "Gigabyte GA-D525TUD",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "Gigabyte Technology Co., Ltd."),
+			DMI_MATCH(DMI_BOARD_NAME, "D525TUD"),
+		},
+	},
 
 	{ }	/* terminating entry */
 };
#32 lore raw

Re: [ 24/27] i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

Sorry, dropped the CCs when I replied... I don't normally use the Gmail web interface :)

Quoted 9 lines · Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Calvin Walton <[email protected]>

commit a51d4ed01e5bb39d2cf36a12f9976ab08872c192 upstream.

This board is incorrectly detected as having an LVDS connector,

$ git describe --contains a51d4ed01e5bb39d2cf36a12f9976ab08872c192
v3.6-rc4~5^2~3^2

This patch was already included in Linus's 3.6 upstream release, so it doesn't need to be (re-)applied to the 3.6.x stable tree. I'm surprised it applied at all, it must need some fuzz to add the duplicate entry...?

Anyways, it should only be applied to the 3.0 and 3.4 trees.

Calvin.

author maintainer
#33 lore raw

Re: [ 24/27] i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard

Quoted 15 lines · Calvin Walton

Sorry, dropped the CCs when I replied... I don't normally use the Gmail web interface :)

Quoted 9 lines · Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Calvin Walton <[email protected]>

commit a51d4ed01e5bb39d2cf36a12f9976ab08872c192 upstream.

This board is incorrectly detected as having an LVDS connector,

Quoted 7 lines
$ git describe --contains a51d4ed01e5bb39d2cf36a12f9976ab08872c192
v3.6-rc4~5^2~3^2

This patch was already included in Linus's 3.6 upstream release, so it doesn't need to be (re-)applied to the 3.6.x stable tree. I'm surprised it applied at all, it must need some fuzz to add the duplicate entry...?

Ah, yes, it did, thanks for catching that, I've now dropped this from the 3.6-stable tree.

greg k-h

author maintainer
#34 lore raw

PATCH 25/27 drm/i915: Add no-lvds quirk for Supermicro X7SPA-H

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Chris Wilson <[email protected]>

commit c31407a3672aaebb4acddf90944a114fa5c8af7b upstream.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55375

---
 drivers/gpu/drm/i915/intel_lvds.c |    8 ++++++++
 1 file changed, 8 insertions(+)
drivers/gpu/drm/i915/intel_lvds.c +8 -0
@@ -796,6 +796,14 @@ static const struct dmi_system_id intel_
 			DMI_MATCH(DMI_BOARD_NAME, "D525TUD"),
 		},
 	},
+	{
+		.callback = intel_no_lvds_dmi_callback,
+		.ident = "Supermicro X7SPA-H",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Supermicro"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "X7SPA-H"),
+		},
+	},
 
 	{ }	/* terminating entry */
 };
author maintainer
#35 lore raw

PATCH 26/27 x86, amd: Disable way access filter on Piledriver CPUs

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andre Przywara <[email protected]>

commit 2bbf0a1427c377350f001fbc6260995334739ad7 upstream.

The Way Access Filter in recent AMD CPUs may hurt the performance of some workloads, caused by aliasing issues in the L1 cache. This patch disables it on the affected CPUs.

The issue is similar to that one of last year:
http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/00041.html
This new patch does not replace the old one, we just need another quirk for newer CPUs.

The performance penalty without the patch depends on the circumstances, but is a bit less than the last year's 3%.

The workloads affected would be those that access code from the same physical page under different virtual addresses, so different processes using the same libraries with ASLR or multiple instances of PIE-binaries. The code needs to be accessed simultaneously from both cores of the same compute unit.

More details can be found here:
http://developer.amd.com/Assets/SharedL1InstructionCacheonAMD15hCPU.pdf

CPUs affected are anything with the core known as Piledriver. That includes the new parts of the AMD A-Series (aka Trinity) and the just released new CPUs of the FX-Series (aka Vishera).
The model numbering is a bit odd here: FX CPUs have model 2, A-Series has model 10h, with possible extensions to 1Fh. Hence the range of model ids.

---
 arch/x86/kernel/cpu/amd.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)
arch/x86/kernel/cpu/amd.c +14 -0
@@ -631,6 +631,20 @@ static void __cpuinit init_amd(struct cp
 		}
 	}
 
+	/*
+	 * The way access filter has a performance penalty on some workloads.
+	 * Disable it on the affected CPUs.
+	 */
+	if ((c->x86 == 0x15) &&
+	    (c->x86_model >= 0x02) && (c->x86_model < 0x20)) {
+		u64 val;
+
+		if (!rdmsrl_safe(0xc0011021, &val) && !(val & 0x1E)) {
+			val |= 0x1E;
+			wrmsrl_safe(0xc0011021, val);
+		}
+	}
+
 	cpu_detect_cache_sizes(c);
 
 	/* Multi core CPU? */
author maintainer
#36 lore raw

PATCH 27/27 8139cp: revert "set ring address before enabling receiver"

In reply to Greg Kroah-Hartman

3.6-stable review patch. If anyone has any objections, please let me know.

------------------

From: Francois Romieu <[email protected]>

commit b26623dab7eeb1e9f5898c7a49458789dd492f20 upstream.

This patch reverts b01af4579ec41f48e9b9c774e70bd6474ad210db.

The original patch was tested with emulated hardware. Real hardware chokes.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=47041

---
 drivers/net/ethernet/realtek/8139cp.c |   22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)
drivers/net/ethernet/realtek/8139cp.c +11 -11
@@ -979,17 +979,6 @@ static void cp_init_hw (struct cp_privat
 	cpw32_f (MAC0 + 0, le32_to_cpu (*(__le32 *) (dev->dev_addr + 0)));
 	cpw32_f (MAC0 + 4, le32_to_cpu (*(__le32 *) (dev->dev_addr + 4)));
 
-	cpw32_f(HiTxRingAddr, 0);
-	cpw32_f(HiTxRingAddr + 4, 0);
-
-	ring_dma = cp->ring_dma;
-	cpw32_f(RxRingAddr, ring_dma & 0xffffffff);
-	cpw32_f(RxRingAddr + 4, (ring_dma >> 16) >> 16);
-
-	ring_dma += sizeof(struct cp_desc) * CP_RX_RING_SIZE;
-	cpw32_f(TxRingAddr, ring_dma & 0xffffffff);
-	cpw32_f(TxRingAddr + 4, (ring_dma >> 16) >> 16);
-
 	cp_start_hw(cp);
 	cpw8(TxThresh, 0x06); /* XXX convert magic num to a constant */
 
@@ -1003,6 +992,17 @@ static void cp_init_hw (struct cp_privat
 
 	cpw8(Config5, cpr8(Config5) & PMEStatus);
 
+	cpw32_f(HiTxRingAddr, 0);
+	cpw32_f(HiTxRingAddr + 4, 0);
+
+	ring_dma = cp->ring_dma;
+	cpw32_f(RxRingAddr, ring_dma & 0xffffffff);
+	cpw32_f(RxRingAddr + 4, (ring_dma >> 16) >> 16);
+
+	ring_dma += sizeof(struct cp_desc) * CP_RX_RING_SIZE;
+	cpw32_f(TxRingAddr, ring_dma & 0xffffffff);
+	cpw32_f(TxRingAddr + 4, (ring_dma >> 16) >> 16);
+
 	cpw16(MultiIntr, 0);
 
 	cpw8_f(Cfg9346, Cfg9346_Lock);
#37 lore raw
In reply to Greg Kroah-Hartman
Quoted 1 line · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.6.10 release.

Patched against 3.6.9/builds/works fine on 3 Gentoo ~x86 machines, two generic i5/i7 boxes (one ATI with Evergreen chip) and an old T60 Thinkpad. No borkage detected so far.

-h

#38 lore raw
In reply to Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.6.10 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Quoted 8 lines

Responses should be made by Sun Dec 9 00:57:22 UTC 2012. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.6.10-rc1.gz

and the diffstat can be found below.

thanks,

Patch applied cleanly and compiled and booted on the following systems:

HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics

Cross-compile tests
alpha: defconfig passed
arm: defconfig passed
c6x: not applicable
mips: defconfig passed
mipsel: defconfig passed
powerpc: wii_defconfig failed on 3.0.56 - fixed it and sending a patch.
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

-- Shuah

#39 lore raw
Quoted 21 lines · Shuah Khan
Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.6.10 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Quoted 8 lines

Responses should be made by Sun Dec 9 00:57:22 UTC 2012. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.6.10-rc1.gz

and the diffstat can be found below.

thanks,

Patch applied cleanly and compiled and booted on the following systems:

HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics

Quoted 10 lines

Cross-compile tests
alpha: defconfig passed
arm: defconfig passed
c6x: not applicable
mips: defconfig passed
mipsel: defconfig passed
powerpc: wii_defconfig failed on 3.0.56 - fixed it and sending a patch.
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

Correction: c6x passed.

-- Shuah

#40 lore raw
In reply to Greg Kroah-Hartman

Hi Greg,

2012/12/7 Greg Kroah-Hartman <[email protected]>:

Quoted 4 lines

This is the start of the stable review cycle for the 3.6.10 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine.

- Build Machine: debian wheezy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
memory: 8GB

- Test machine: debian wheezy x86_64(KVM guest on the Build Machine)
vCPU: x2
memory: 2GB

I reviewed the following patches and it looks good to me.

Quoted 6 lines

Alan Cox <[email protected]>
ACPI: missing break

Mike Galbraith <[email protected]>
Revert "sched, autogroup: Stop going ahead if autogroup is disabled"

Quoted 8 lines

Mike Galbraith <[email protected]>
workqueue: exit rescuer_thread() as TASK_RUNNING

Naoya Horiguchi <[email protected]>
mm: soft offline: split thp at the beginning of soft_offline_page()

Jianguo Wu <[email protected]>
mm/vmemmap: fix wrong use of virt_to_page

Thanks,
Satoru

Quoted 42 lines

-------------

Diffstat:

 Makefile                                         |   4 +-
 arch/arm/Kconfig                                 |   1 +
 arch/arm/mach-dove/include/mach/pm.h             |   2 +-
 arch/arm/mach-dove/irq.c                         |  14 ++-
 arch/arm/mach-kirkwood/pcie.c                    |  11 ++-
 arch/s390/Kconfig                                |   1 +
 arch/x86/include/asm/fpu-internal.h              |  15 +--
 arch/x86/kernel/cpu/amd.c                        |  14 +++
 arch/x86/kernel/smpboot.c                        |   5 +
 drivers/acpi/processor_driver.c                  |   1 +
 drivers/edac/i7300_edac.c                        |   8 +-
 drivers/edac/i7core_edac.c                       |   6 +-
 drivers/gpu/drm/i915/intel_lvds.c                |  16 ++++
 drivers/gpu/drm/radeon/evergreen.c               | 191 +++++++++++++++++++------------------
 drivers/gpu/drm/radeon/evergreen_reg.h           |   2 +
 drivers/gpu/drm/radeon/evergreend.h              |   7 ++
 drivers/gpu/drm/radeon/radeon_asic.h             |   1 +
 drivers/md/raid1.c                               |   2 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |  11 ++-
 drivers/net/ethernet/realtek/8139cp.c            |  22 ++---
 drivers/net/usb/qmi_wwan.c                       |  42 ++++++++
 drivers/net/wireless/iwlwifi/dvm/rxon.c          |  12 +--
 drivers/target/target_core_transport.c           |   6 +-
 kernel/sched/auto_group.c                        |   4 -
 kernel/sched/auto_group.h                        |   5 -
 kernel/workqueue.c                               |   4 +-
 mm/memory-failure.c                              |   8 ++
 mm/sparse.c                                      |  10 +-
 mm/vmscan.c                                      |  27 ++++--
 net/mac80211/offchannel.c                        |   2 -
 30 files changed, 288 insertions(+), 166 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html