From: Greg Kroah-Hartman Date: Wed, 8 Jul 2015 07:21:54 +0000 (-0700) Subject: 3.10-stable patches X-Git-Tag: v4.0.8~11 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=bcb0916da024a66a233001fba56e7302fb7c8dfc;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: arm-kvm-force-execution-of-hcptr-access-on-vm-exit.patch crypto-talitos-avoid-memleak-in-talitos_alg_alloc.patch fs-fix-s_nosec-handling.patch kvm-x86-make-vapics_in_nmi_mode-atomic.patch mips-fix-kvm-guest-fixmap-address.patch powerpc-perf-fix-book3s-kernel-to-userspace-backtraces.patch revert-crypto-talitos-convert-to-use-be16_add_cpu.patch x86-pci-use-host-bridge-_crs-info-on-foxconn-k8m890-8237a.patch --- diff --git a/queue-3.10/arm-kvm-force-execution-of-hcptr-access-on-vm-exit.patch b/queue-3.10/arm-kvm-force-execution-of-hcptr-access-on-vm-exit.patch new file mode 100644 index 00000000000..5b1a93fec67 --- /dev/null +++ b/queue-3.10/arm-kvm-force-execution-of-hcptr-access-on-vm-exit.patch @@ -0,0 +1,113 @@ +From 85e84ba31039595995dae80b277378213602891b Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Mon, 16 Mar 2015 10:59:43 +0000 +Subject: arm: KVM: force execution of HCPTR access on VM exit + +From: Marc Zyngier + +commit 85e84ba31039595995dae80b277378213602891b upstream. + +On VM entry, we disable access to the VFP registers in order to +perform a lazy save/restore of these registers. + +On VM exit, we restore access, test if we did enable them before, +and save/restore the guest/host registers if necessary. In this +sequence, the FPEXC register is always accessed, irrespective +of the trapping configuration. + +If the guest didn't touch the VFP registers, then the HCPTR access +has now enabled such access, but we're missing a barrier to ensure +architectural execution of the new HCPTR configuration. If the HCPTR +access has been delayed/reordered, the subsequent access to FPEXC +will cause a trap, which we aren't prepared to handle at all. + +The same condition exists when trapping to enable VFP for the guest. + +The fix is to introduce a barrier after enabling VFP access. In the +vmexit case, it can be relaxed to only takes place if the guest hasn't +accessed its view of the VFP registers, making the access to FPEXC safe. + +The set_hcptr macro is modified to deal with both vmenter/vmexit and +vmtrap operations, and now takes an optional label that is branched to +when the guest hasn't touched the VFP registers. + +Reported-by: Vikram Sethi +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/kvm/interrupts.S | 10 ++++------ + arch/arm/kvm/interrupts_head.S | 20 ++++++++++++++++++-- + 2 files changed, 22 insertions(+), 8 deletions(-) + +--- a/arch/arm/kvm/interrupts.S ++++ b/arch/arm/kvm/interrupts.S +@@ -159,13 +159,9 @@ __kvm_vcpu_return: + @ Don't trap coprocessor accesses for host kernel + set_hstr vmexit + set_hdcr vmexit +- set_hcptr vmexit, (HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11)) ++ set_hcptr vmexit, (HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11)), after_vfp_restore + + #ifdef CONFIG_VFPv3 +- @ Save floating point registers we if let guest use them. +- tst r2, #(HCPTR_TCP(10) | HCPTR_TCP(11)) +- bne after_vfp_restore +- + @ Switch VFP/NEON hardware state to the host's + add r7, vcpu, #VCPU_VFP_GUEST + store_vfp_state r7 +@@ -177,6 +173,8 @@ after_vfp_restore: + @ Restore FPEXC_EN which we clobbered on entry + pop {r2} + VFPFMXR FPEXC, r2 ++#else ++after_vfp_restore: + #endif + + @ Reset Hyp-role +@@ -458,7 +456,7 @@ switch_to_guest_vfp: + push {r3-r7} + + @ NEON/VFP used. Turn on VFP access. +- set_hcptr vmexit, (HCPTR_TCP(10) | HCPTR_TCP(11)) ++ set_hcptr vmtrap, (HCPTR_TCP(10) | HCPTR_TCP(11)) + + @ Switch VFP/NEON hardware state to the guest's + add r7, r0, #VCPU_VFP_HOST +--- a/arch/arm/kvm/interrupts_head.S ++++ b/arch/arm/kvm/interrupts_head.S +@@ -570,8 +570,13 @@ vcpu .req r0 @ vcpu pointer always in r + .endm + + /* Configures the HCPTR (Hyp Coprocessor Trap Register) on entry/return +- * (hardware reset value is 0). Keep previous value in r2. */ +-.macro set_hcptr operation, mask ++ * (hardware reset value is 0). Keep previous value in r2. ++ * An ISB is emited on vmexit/vmtrap, but executed on vmexit only if ++ * VFP wasn't already enabled (always executed on vmtrap). ++ * If a label is specified with vmexit, it is branched to if VFP wasn't ++ * enabled. ++ */ ++.macro set_hcptr operation, mask, label = none + mrc p15, 4, r2, c1, c1, 2 + ldr r3, =\mask + .if \operation == vmentry +@@ -580,6 +585,17 @@ vcpu .req r0 @ vcpu pointer always in r + bic r3, r2, r3 @ Don't trap defined coproc-accesses + .endif + mcr p15, 4, r3, c1, c1, 2 ++ .if \operation != vmentry ++ .if \operation == vmexit ++ tst r2, #(HCPTR_TCP(10) | HCPTR_TCP(11)) ++ beq 1f ++ .endif ++ isb ++ .if \label != none ++ b \label ++ .endif ++1: ++ .endif + .endm + + /* Configures the HDCR (Hyp Debug Configuration Register) on entry/return diff --git a/queue-3.10/crypto-talitos-avoid-memleak-in-talitos_alg_alloc.patch b/queue-3.10/crypto-talitos-avoid-memleak-in-talitos_alg_alloc.patch new file mode 100644 index 00000000000..06ea7d14c4a --- /dev/null +++ b/queue-3.10/crypto-talitos-avoid-memleak-in-talitos_alg_alloc.patch @@ -0,0 +1,28 @@ +From 5fa7dadc898567ce14d6d6d427e7bd8ce6eb5d39 Mon Sep 17 00:00:00 2001 +From: Horia Geant? +Date: Mon, 11 May 2015 20:03:24 +0300 +Subject: crypto: talitos - avoid memleak in talitos_alg_alloc() + +From: Horia Geant? + +commit 5fa7dadc898567ce14d6d6d427e7bd8ce6eb5d39 upstream. + +Fixes: 1d11911a8c57 ("crypto: talitos - fix warning: 'alg' may be used uninitialized in this function") +Signed-off-by: Horia Geanta +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/crypto/talitos.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/crypto/talitos.c ++++ b/drivers/crypto/talitos.c +@@ -2621,6 +2621,7 @@ static struct talitos_crypto_alg *talito + break; + default: + dev_err(dev, "unknown algorithm type %d\n", t_alg->algt.type); ++ kfree(t_alg); + return ERR_PTR(-EINVAL); + } + diff --git a/queue-3.10/fs-fix-s_nosec-handling.patch b/queue-3.10/fs-fix-s_nosec-handling.patch new file mode 100644 index 00000000000..f0aea9bd564 --- /dev/null +++ b/queue-3.10/fs-fix-s_nosec-handling.patch @@ -0,0 +1,36 @@ +From 2426f3910069ed47c0cc58559a6d088af7920201 Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Thu, 21 May 2015 16:05:52 +0200 +Subject: fs: Fix S_NOSEC handling + +From: Jan Kara + +commit 2426f3910069ed47c0cc58559a6d088af7920201 upstream. + +file_remove_suid() could mistakenly set S_NOSEC inode bit when root was +modifying the file. As a result following writes to the file by ordinary +user would avoid clearing suid or sgid bits. + +Fix the bug by checking actual mode bits before setting S_NOSEC. + +Signed-off-by: Jan Kara +Signed-off-by: Al Viro +Signed-off-by: Greg Kroah-Hartman + +--- + fs/inode.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/fs/inode.c ++++ b/fs/inode.c +@@ -1628,8 +1628,8 @@ int file_remove_suid(struct file *file) + error = security_inode_killpriv(dentry); + if (!error && killsuid) + error = __remove_suid(dentry, killsuid); +- if (!error && (inode->i_sb->s_flags & MS_NOSEC)) +- inode->i_flags |= S_NOSEC; ++ if (!error) ++ inode_has_no_xattr(inode); + + return error; + } diff --git a/queue-3.10/kvm-x86-make-vapics_in_nmi_mode-atomic.patch b/queue-3.10/kvm-x86-make-vapics_in_nmi_mode-atomic.patch new file mode 100644 index 00000000000..925c0305b42 --- /dev/null +++ b/queue-3.10/kvm-x86-make-vapics_in_nmi_mode-atomic.patch @@ -0,0 +1,64 @@ +From 42720138b06301cc8a7ee8a495a6d021c4b6a9bc Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= +Date: Wed, 1 Jul 2015 15:31:49 +0200 +Subject: KVM: x86: make vapics_in_nmi_mode atomic +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= + +commit 42720138b06301cc8a7ee8a495a6d021c4b6a9bc upstream. + +Writes were a bit racy, but hard to turn into a bug at the same time. +(Particularly because modern Linux doesn't use this feature anymore.) + +Signed-off-by: Radim Krčmář +[Actually the next patch makes it much, much easier to trigger the race + so I'm including this one for stable@ as well. - Paolo] +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/kvm_host.h | 2 +- + arch/x86/kvm/i8254.c | 2 +- + arch/x86/kvm/lapic.c | 4 ++-- + 3 files changed, 4 insertions(+), 4 deletions(-) + +--- a/arch/x86/include/asm/kvm_host.h ++++ b/arch/x86/include/asm/kvm_host.h +@@ -541,7 +541,7 @@ struct kvm_arch { + struct kvm_pic *vpic; + struct kvm_ioapic *vioapic; + struct kvm_pit *vpit; +- int vapics_in_nmi_mode; ++ atomic_t vapics_in_nmi_mode; + struct mutex apic_map_lock; + struct kvm_apic_map *apic_map; + +--- a/arch/x86/kvm/i8254.c ++++ b/arch/x86/kvm/i8254.c +@@ -305,7 +305,7 @@ static void pit_do_work(struct kthread_w + * LVT0 to NMI delivery. Other PIC interrupts are just sent to + * VCPU0, and only if its LVT0 is in EXTINT mode. + */ +- if (kvm->arch.vapics_in_nmi_mode > 0) ++ if (atomic_read(&kvm->arch.vapics_in_nmi_mode) > 0) + kvm_for_each_vcpu(i, vcpu, kvm) + kvm_apic_nmi_wd_deliver(vcpu); + } +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -1123,10 +1123,10 @@ static void apic_manage_nmi_watchdog(str + if (!nmi_wd_enabled) { + apic_debug("Receive NMI setting on APIC_LVT0 " + "for cpu %d\n", apic->vcpu->vcpu_id); +- apic->vcpu->kvm->arch.vapics_in_nmi_mode++; ++ atomic_inc(&apic->vcpu->kvm->arch.vapics_in_nmi_mode); + } + } else if (nmi_wd_enabled) +- apic->vcpu->kvm->arch.vapics_in_nmi_mode--; ++ atomic_dec(&apic->vcpu->kvm->arch.vapics_in_nmi_mode); + } + + static int apic_reg_write(struct kvm_lapic *apic, u32 reg, u32 val) diff --git a/queue-3.10/mips-fix-kvm-guest-fixmap-address.patch b/queue-3.10/mips-fix-kvm-guest-fixmap-address.patch new file mode 100644 index 00000000000..d2803aa5938 --- /dev/null +++ b/queue-3.10/mips-fix-kvm-guest-fixmap-address.patch @@ -0,0 +1,41 @@ +From 8e748c8d09a9314eedb5c6367d9acfaacddcdc88 Mon Sep 17 00:00:00 2001 +From: James Hogan +Date: Mon, 27 Apr 2015 15:07:16 +0100 +Subject: MIPS: Fix KVM guest fixmap address + +From: James Hogan + +commit 8e748c8d09a9314eedb5c6367d9acfaacddcdc88 upstream. + +KVM guest kernels for trap & emulate run in user mode, with a modified +set of kernel memory segments. However the fixmap address is still in +the normal KSeg3 region at 0xfffe0000 regardless, causing problems when +cache alias handling makes use of them when handling copy on write. + +Therefore define FIXADDR_TOP as 0x7ffe0000 in the guest kernel mapped +region when CONFIG_KVM_GUEST is defined. + +Signed-off-by: James Hogan +Cc: linux-mips@linux-mips.org +Patchwork: https://patchwork.linux-mips.org/patch/9887/ +Signed-off-by: Ralf Baechle +Signed-off-by: Greg Kroah-Hartman + +--- + arch/mips/include/asm/mach-generic/spaces.h | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/mips/include/asm/mach-generic/spaces.h ++++ b/arch/mips/include/asm/mach-generic/spaces.h +@@ -90,7 +90,11 @@ + #endif + + #ifndef FIXADDR_TOP ++#ifdef CONFIG_KVM_GUEST ++#define FIXADDR_TOP ((unsigned long)(long)(int)0x7ffe0000) ++#else + #define FIXADDR_TOP ((unsigned long)(long)(int)0xfffe0000) + #endif ++#endif + + #endif /* __ASM_MACH_GENERIC_SPACES_H */ diff --git a/queue-3.10/powerpc-perf-fix-book3s-kernel-to-userspace-backtraces.patch b/queue-3.10/powerpc-perf-fix-book3s-kernel-to-userspace-backtraces.patch new file mode 100644 index 00000000000..5b2c68c72f8 --- /dev/null +++ b/queue-3.10/powerpc-perf-fix-book3s-kernel-to-userspace-backtraces.patch @@ -0,0 +1,98 @@ +From 72e349f1124a114435e599479c9b8d14bfd1ebcd Mon Sep 17 00:00:00 2001 +From: Anton Blanchard +Date: Tue, 26 May 2015 15:10:24 +1000 +Subject: powerpc/perf: Fix book3s kernel to userspace backtraces + +From: Anton Blanchard + +commit 72e349f1124a114435e599479c9b8d14bfd1ebcd upstream. + +When we take a PMU exception or a software event we call +perf_read_regs(). This overloads regs->result with a boolean that +describes if we should use the sampled instruction address register +(SIAR) or the regs. + +If the exception is in kernel, we start with the kernel regs and +backtrace through the kernel stack. At this point we switch to the +userspace regs and backtrace the user stack with perf_callchain_user(). + +Unfortunately these regs have not got the perf_read_regs() treatment, +so regs->result could be anything. If it is non zero, +perf_instruction_pointer() decides to use the SIAR, and we get issues +like this: + +0.11% qemu-system-ppc [kernel.kallsyms] [k] _raw_spin_lock_irqsave + | + ---_raw_spin_lock_irqsave + | + |--52.35%-- 0 + | | + | |--46.39%-- __hrtimer_start_range_ns + | | kvmppc_run_core + | | kvmppc_vcpu_run_hv + | | kvmppc_vcpu_run + | | kvm_arch_vcpu_ioctl_run + | | kvm_vcpu_ioctl + | | do_vfs_ioctl + | | sys_ioctl + | | system_call + | | | + | | |--67.08%-- _raw_spin_lock_irqsave <--- hi mum + | | | | + | | | --100.00%-- 0x7e714 + | | | 0x7e714 + +Notice the bogus _raw_spin_irqsave when we transition from kernel +(system_call) to userspace (0x7e714). We inserted what was in the SIAR. + +Add a check in regs_use_siar() to check that the regs in question +are from a PMU exception. With this fix the backtrace makes sense: + + 0.47% qemu-system-ppc [kernel.vmlinux] [k] _raw_spin_lock_irqsave + | + ---_raw_spin_lock_irqsave + | + |--53.83%-- 0 + | | + | |--44.73%-- hrtimer_try_to_cancel + | | kvmppc_start_thread + | | kvmppc_run_core + | | kvmppc_vcpu_run_hv + | | kvmppc_vcpu_run + | | kvm_arch_vcpu_ioctl_run + | | kvm_vcpu_ioctl + | | do_vfs_ioctl + | | sys_ioctl + | | system_call + | | __ioctl + | | 0x7e714 + | | 0x7e714 + +Signed-off-by: Anton Blanchard +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/perf/core-book3s.c | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/perf/core-book3s.c ++++ b/arch/powerpc/perf/core-book3s.c +@@ -112,7 +112,16 @@ static inline void power_pmu_bhrb_read(s + + static bool regs_use_siar(struct pt_regs *regs) + { +- return !!regs->result; ++ /* ++ * When we take a performance monitor exception the regs are setup ++ * using perf_read_regs() which overloads some fields, in particular ++ * regs->result to tell us whether to use SIAR. ++ * ++ * However if the regs are from another exception, eg. a syscall, then ++ * they have not been setup using perf_read_regs() and so regs->result ++ * is something random. ++ */ ++ return ((TRAP(regs) == 0xf00) && regs->result); + } + + /* diff --git a/queue-3.10/revert-crypto-talitos-convert-to-use-be16_add_cpu.patch b/queue-3.10/revert-crypto-talitos-convert-to-use-be16_add_cpu.patch new file mode 100644 index 00000000000..1ab366b8a79 --- /dev/null +++ b/queue-3.10/revert-crypto-talitos-convert-to-use-be16_add_cpu.patch @@ -0,0 +1,36 @@ +From 69d9cd8c592f1abce820dbce7181bbbf6812cfbd Mon Sep 17 00:00:00 2001 +From: Horia Geant? +Date: Mon, 11 May 2015 20:04:49 +0300 +Subject: Revert "crypto: talitos - convert to use be16_add_cpu()" + +From: Horia Geant? + +commit 69d9cd8c592f1abce820dbce7181bbbf6812cfbd upstream. + +This reverts commit 7291a932c6e27d9768e374e9d648086636daf61c. + +The conversion to be16_add_cpu() is incorrect in case cryptlen is +negative due to premature (i.e. before addition / subtraction) +implicit conversion of cryptlen (int -> u16) leading to sign loss. + +Cc: Wei Yongjun +Signed-off-by: Horia Geanta +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/crypto/talitos.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/crypto/talitos.c ++++ b/drivers/crypto/talitos.c +@@ -935,7 +935,8 @@ static int sg_to_link_tbl(struct scatter + sg_count--; + link_tbl_ptr--; + } +- be16_add_cpu(&link_tbl_ptr->len, cryptlen); ++ link_tbl_ptr->len = cpu_to_be16(be16_to_cpu(link_tbl_ptr->len) ++ + cryptlen); + + /* tag end of link table */ + link_tbl_ptr->j_extent = DESC_PTR_LNKTBL_RETURN; diff --git a/queue-3.10/series b/queue-3.10/series index 815f03f6a2d..80d6274bf27 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -4,3 +4,11 @@ bridge-fix-br_stp_set_bridge_priority-race-conditions.patch packet-read-num_members-once-in-packet_rcv_fanout.patch packet-avoid-out-of-bounds-read-in-round-robin-fanout.patch sctp-fix-race-between-ootb-responce-and-route-removal.patch +crypto-talitos-avoid-memleak-in-talitos_alg_alloc.patch +revert-crypto-talitos-convert-to-use-be16_add_cpu.patch +arm-kvm-force-execution-of-hcptr-access-on-vm-exit.patch +powerpc-perf-fix-book3s-kernel-to-userspace-backtraces.patch +x86-pci-use-host-bridge-_crs-info-on-foxconn-k8m890-8237a.patch +mips-fix-kvm-guest-fixmap-address.patch +kvm-x86-make-vapics_in_nmi_mode-atomic.patch +fs-fix-s_nosec-handling.patch diff --git a/queue-3.10/x86-pci-use-host-bridge-_crs-info-on-foxconn-k8m890-8237a.patch b/queue-3.10/x86-pci-use-host-bridge-_crs-info-on-foxconn-k8m890-8237a.patch new file mode 100644 index 00000000000..0586f61c915 --- /dev/null +++ b/queue-3.10/x86-pci-use-host-bridge-_crs-info-on-foxconn-k8m890-8237a.patch @@ -0,0 +1,62 @@ +From 1dace0116d0b05c967d94644fc4dfe96be2ecd3d Mon Sep 17 00:00:00 2001 +From: Bjorn Helgaas +Date: Tue, 9 Jun 2015 18:54:07 -0500 +Subject: x86/PCI: Use host bridge _CRS info on Foxconn K8M890-8237A + +From: Bjorn Helgaas + +commit 1dace0116d0b05c967d94644fc4dfe96be2ecd3d upstream. + +The Foxconn K8M890-8237A has two PCI host bridges, and we can't assign +resources correctly without the information from _CRS that tells us which +address ranges are claimed by which bridge. In the bugs mentioned below, +we incorrectly assign a sound card address (this example is from 1033299): + + bus: 00 index 2 [mem 0x80000000-0xfcffffffff] + ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f]) + pci_root PNP0A08:00: host bridge window [mem 0x80000000-0xbfefffff] (ignored) + pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff] (ignored) + pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfebfffff] (ignored) + ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff]) + pci_root PNP0A08:01: host bridge window [mem 0xbff00000-0xbfffffff] (ignored) + pci 0000:80:01.0: [1106:3288] type 0 class 0x000403 + pci 0000:80:01.0: reg 10: [mem 0xbfffc000-0xbfffffff 64bit] + pci 0000:80:01.0: address space collision: [mem 0xbfffc000-0xbfffffff 64bit] conflicts with PCI Bus #00 [mem 0x80000000-0xfcffffffff] + pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-0xfd00003fff 64bit] + BUG: unable to handle kernel paging request at ffffc90000378000 + IP: [] azx_create+0x37c/0x822 [snd_hda_intel] + +We assigned 0xfd_0000_0000, but that is not in any of the host bridge +windows, and the sound card doesn't work. + +Turn on pci=use_crs automatically for this system. + +Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/931368 +Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1033299 +Signed-off-by: Bjorn Helgaas +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/pci/acpi.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/arch/x86/pci/acpi.c ++++ b/arch/x86/pci/acpi.c +@@ -84,6 +84,17 @@ static const struct dmi_system_id pci_cr + DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"), + }, + }, ++ /* https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/931368 */ ++ /* https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1033299 */ ++ { ++ .callback = set_use_crs, ++ .ident = "Foxconn K8M890-8237A", ++ .matches = { ++ DMI_MATCH(DMI_BOARD_VENDOR, "Foxconn"), ++ DMI_MATCH(DMI_BOARD_NAME, "K8M890-8237A"), ++ DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"), ++ }, ++ }, + + /* Now for the blacklist.. */ +