3.6.10-stable review
Subsystems (28)
Greg Kroah-Hartman
maintainercover 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(-)
Greg Kroah-Hartman
maintainerPATCH 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_dataint 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 = {
Greg Kroah-Hartman
maintainerPATCH 2/27 Dove: Fix irq_to_pmu()
In reply to Greg Kroah-Hartman3.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 ;
Greg Kroah-Hartman
maintainerPATCH 3/27 drm/radeon/dce4+: dont use radeon_crtc for vblank callback
In reply to Greg Kroah-Hartman3.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 ); }
Greg Kroah-Hartman
maintainerPATCH 4/27 drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2)
In reply to Greg Kroah-Hartman3.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);
Greg Kroah-Hartman
maintainerPATCH 5/27 drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop()
In reply to Greg Kroah-Hartman3.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_devbreak ;udelay (1 ); } + }else { + save->crtc_enabled[i] = false; } }
Greg Kroah-Hartman
maintainerPATCH 6/27 mm/vmemmap: fix wrong use of virt_to_page
In reply to Greg Kroah-Hartman3.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); } }
Greg Kroah-Hartman
maintainerPATCH 7/27 mm: vmscan: fix endless loop in kswapd balancing
In reply to Greg Kroah-Hartman3.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_datacontinue ; } -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
Greg Kroah-Hartman
maintainerPATCH 8/27 mm: soft offline: split thp at the beginning of soft_offline_page()
In reply to Greg Kroah-Hartman3.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 )
Greg Kroah-Hartman
maintainerPATCH 9/27 target: Fix handling of aborted commands
In reply to Greg Kroah-Hartman3.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 seunsigned 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 ; }
Greg Kroah-Hartman
maintainerPATCH 10/27 iwlwifi: fix the basic CCK rates calculation
In reply to Greg Kroah-Hartman3.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 ;
Greg Kroah-Hartman
maintainerPATCH 11/27 ARM: Kirkwood: Update PCI-E fixup
In reply to Greg Kroah-Hartman3.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(inreturn 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 ;
Greg Kroah-Hartman
maintainerPATCH 12/27 x86, fpu: Avoid FPU lazy restore after suspend
In reply to Greg Kroah-Hartman3.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(sttypedef 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 intper_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);
Greg Kroah-Hartman
maintainerPATCH 13/27 workqueue: exit rescuer_thread() as TASK_RUNNING
In reply to Greg Kroah-Hartman3.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
Greg Kroah-Hartman
maintainerPATCH 14/27 mac80211: fix remain-on-channel (non-)cancelling
In reply to Greg Kroah-Hartman3.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 ieee8021list_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) {
Greg Kroah-Hartman
maintainerPATCH 15/27 md/raid1{,0}: fix deadlock in bitmap_unplug.
In reply to Greg Kroah-Hartman3.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_plugstruct 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;
Greg Kroah-Hartman
maintainerPATCH 16/27 i7300_edac: Fix error flag testing
In reply to Greg Kroah-Hartman3.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 0xa0static 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);
Greg Kroah-Hartman
maintainerPATCH 17/27 Revert "sched, autogroup: Stop going ahead if autogroup is disabled"
In reply to Greg Kroah-Hartman3.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;
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
fd8ef11730f1d03d5d6555aa53126e9e34f52f12upstream.This reverts commit
800d4d30c8f20bd728e5741a3b77c4859a613f7c.Between commits
8323f26ce342("sched: Fix race intask_group()") and800d4d30c8f2("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
800d4d30c8f2not allowing autogroup to move things, and commit8323f26ce342making 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: 0000000000000000Signed-off-by Mike Galbraith <[email protected]>Acked-by Ingo Molnar <[email protected]>Cc Yong Zhang <[email protected]>Cc Peter Zijlstra <[email protected]>Signed-off-by Linus Torvalds <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- 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
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
fd8ef11730f1d03d5d6555aa53126e9e34f52f12upstream.This reverts commit
800d4d30c8f20bd728e5741a3b77c4859a613f7c.Between commits
8323f26ce342("sched: Fix race intask_group()") and800d4d30c8f2("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
800d4d30c8f2not allowing autogroup to move things, and commit8323f26ce342making 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-7502RIP: 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
Signed-off-by Mike Galbraith <[email protected]>Acked-by Ingo Molnar <[email protected]>Cc Yong Zhang <[email protected]>Cc Peter Zijlstra <[email protected]>Signed-off-by Linus Torvalds <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- 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.
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
fd8ef11730f1d03d5d6555aa53126e9e34f52f12upstream.This reverts commit
800d4d30c8f20bd728e5741a3b77c4859a613f7c.Between commits
8323f26ce342("sched: Fix race intask_group()") and800d4d30c8f2("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/1034099Sincerely,
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.
Greg Kroah-Hartman
maintainerRe: [ 17/27] Revert "sched, autogroup: Stop going ahead if autogroup is disabled"
In reply to Joseph SalisburyQuoted 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
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
Greg Kroah-Hartman
maintainerPATCH 18/27 bnx2x: remove redundant warning log
In reply to Greg Kroah-Hartman3.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)); + } } }
Greg Kroah-Hartman
maintainerPATCH 19/27 i7core_edac: fix panic when accessing sysfs files
In reply to Greg Kroah-Hartman3.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_##parstruct 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_##parastruct 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_##parstruct 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" ); \
Greg Kroah-Hartman
maintainerPATCH 20/27 s390/mm: have 16 byte aligned struct pages
In reply to Greg Kroah-Hartman3.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
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
4bffbb3455372a26816e364fb4448810f7014452upstream.Select
HAVE_ALIGNED_STRUCT_PAGEon 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.
Signed-off-by Heiko Carstens <[email protected]>Signed-off-by Martin Schwidefsky <[email protected]>Signed-off-by CAI Qian <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
Same as for 3.4: compare and swap double is not available for 3.6 on s390.
Greg Kroah-Hartman
maintainerRe: [ 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
4bffbb3455372a26816e364fb4448810f7014452upstream.Select
HAVE_ALIGNED_STRUCT_PAGEon 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
Signed-off-by Heiko Carstens <[email protected]>Signed-off-by Martin Schwidefsky <[email protected]>Signed-off-by CAI Qian <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>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
Greg Kroah-Hartman
maintainerPATCH 21/27 net: qmi_wwan: adding more ZTE devices
In reply to Greg Kroah-Hartman3.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 */
Greg Kroah-Hartman
maintainerPATCH 22/27 net: qmi_wwan: add Huawei E173
In reply to Greg Kroah-Hartman3.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)},
Greg Kroah-Hartman
maintainerPATCH 23/27 ACPI: missing break
In reply to Greg Kroah-Hartman3.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(structacpi_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));
Greg Kroah-Hartman
maintainerPATCH 24/27 i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard
In reply to Greg Kroah-Hartman3.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 */ };
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
a51d4ed01e5bb39d2cf36a12f9976ab08872c192upstream.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.
Greg Kroah-Hartman
maintainerRe: [ 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
a51d4ed01e5bb39d2cf36a12f9976ab08872c192upstream.This board is incorrectly detected as having an LVDS connector,
Quoted 7 lines
$ git describe --contains a51d4ed01e5bb39d2cf36a12f9976ab08872c192 v3.6-rc4~5^2~3^2This 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
Greg Kroah-Hartman
maintainerPATCH 25/27 drm/i915: Add no-lvds quirk for Supermicro X7SPA-H
In reply to Greg Kroah-Hartman3.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 */ };
Greg Kroah-Hartman
maintainerPATCH 26/27 x86, amd: Disable way access filter on Piledriver CPUs
In reply to Greg Kroah-Hartman3.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? */
Greg Kroah-Hartman
maintainerPATCH 27/27 8139cp: revert "set ring address before enabling receiver"
In reply to Greg Kroah-Hartman3.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_privatcpw32_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_privatcpw8 (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);
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
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.gzand 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
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.gzand 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_defconfigfailed on 3.0.56 - fixed it and sending a patch.
sh: defconfig passed on all
sparc: defconfig passed on all
tile:tilegx_defconfigpassed on all
Correction: c6x passed.
-- Shuah
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 breakMike Galbraith <[email protected]>
Revert "sched, autogroup: Stop going ahead if autogroup is disabled"
Quoted 8 lines
Mike Galbraith <[email protected]>
workqueue: exitrescuer_thread()asTASK_RUNNINGNaoya Horiguchi <[email protected]>
mm: soft offline: split thp at the beginning ofsoft_offline_page()Jianguo Wu <[email protected]>
mm/vmemmap: fix wrong use ofvirt_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