18 Jan, 2012
40 commits
-
commit 9af0c7a6fa860698d080481f24a342ba74b68982 upstream.
On x86_32 casting the unsigned int result of get_random_int() to
long may result in a negative value. On x86_32 the range of
mmap_rnd() therefore was -255 to 255. The 32bit mode on x86_64
used 0 to 255 as intended.The bug was introduced by 675a081 ("x86: unify mmap_{32|64}.c")
in January 2008.Signed-off-by: Ludwig Nussel
Cc: Linus Torvalds
Cc: harvey.harrison@gmail.com
Cc: "H. Peter Anvin"
Cc: Harvey Harrison
Signed-off-by: Andrew Morton
Link: http://lkml.kernel.org/r/201111152246.pAFMklOB028527@wpaz5.hot.corp.google.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit ab936cbcd02072a34b60d268f94440fd5cf1970b upstream.
Commit ef6a3c6311 ("mm: add replace_page_cache_page() function") added a
function replace_page_cache_page(). This function replaces a page in the
radix-tree with a new page. WHen doing this, memory cgroup needs to fix
up the accounting information. memcg need to check PCG_USED bit etc.In some(many?) cases, 'newpage' is on LRU before calling
replace_page_cache(). So, memcg's LRU accounting information should be
fixed, too.This patch adds mem_cgroup_replace_page_cache() and removes the old hooks.
In that function, old pages will be unaccounted without touching
res_counter and new page will be accounted to the memcg (of old page).
WHen overwriting pc->mem_cgroup of newpage, take zone->lru_lock and avoid
races with LRU handling.Background:
replace_page_cache_page() is called by FUSE code in its splice() handling.
Here, 'newpage' is replacing oldpage but this newpage is not a newly allocated
page and may be on LRU. LRU mis-accounting will be critical for memory cgroup
because rmdir() checks the whole LRU is empty and there is no account leak.
If a page is on the other LRU than it should be, rmdir() will fail.This bug was added in March 2011, but no bug report yet. I guess there
are not many people who use memcg and FUSE at the same time with upstream
kernels.The result of this bug is that admin cannot destroy a memcg because of
account leak. So, no panic, no deadlock. And, even if an active cgroup
exist, umount can succseed. So no problem at shutdown.Signed-off-by: KAMEZAWA Hiroyuki
Acked-by: Johannes Weiner
Acked-by: Michal Hocko
Cc: Miklos Szeredi
Cc: Hugh Dickins
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 1140afa862842ac3e56678693050760edc4ecde9 upstream.
Since:
commit 816c04fe7ef01dd9649f5ccfe796474db8708be5
Author: Christian Lamparter
Date: Sat Apr 30 15:24:30 2011 +0200mac80211: consolidate MIC failure report handling
is possible to that we dereference rx->key == NULL when driver set
RX_FLAG_MMIC_STRIPPED and not RX_FLAG_IV_STRIPPED and we are in
promiscuous mode. This happen with rt73usb and rt61pci at least.Before the commit we always check rx->key against NULL, so I assume
fix should be done in mac80211 (also mic_fail path has similar check).References:
https://bugzilla.redhat.com/show_bug.cgi?id=769766
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-January/004395.htmlReported-by: Stuart D Gathman
Reported-by: Kai Wohlfahrt
Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit d90db4b12bc1b9b8a787ef28550fdb767ee25a49 upstream.
When downloading firmware into the device, the driver fails to check the
return when allocating an skb. When the allocation fails, a BUG can be
generated, as seen in https://bugzilla.redhat.com/show_bug.cgi?id=771656.Signed-off-by: Larry Finger
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit eb31aae8cb5eb54e234ed2d857ddac868195d911 upstream.
Some Dell BIOSes have MCFG tables that don't report the entire
MMCONFIG area claimed by the chipset. If we move PCI devices into
that claimed-but-unreported area, they don't work.This quirk reads the AMD MMCONFIG MSRs and adds PNP0C01 resources as
needed to cover the entire area.Example problem scenario:
BIOS-e820: 00000000cfec5400 - 00000000d4000000 (reserved)
Fam 10h mmconf [d0000000, dfffffff]
PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xd0000000-0xd3ffffff] (base 0xd0000000)
pnp 00:0c: [mem 0xd0000000-0xd3ffffff]
pci 0000:00:12.0: reg 10: [mem 0xffb00000-0xffb00fff]
pci 0000:00:12.0: no compatible bridge window for [mem 0xffb00000-0xffb00fff]
pci 0000:00:12.0: BAR 0: assigned [mem 0xd4000000-0xd40000ff]Reported-by: Lisa Salimbas
Reported-by:
Tested-by: dann frazier
References: https://bugzilla.kernel.org/show_bug.cgi?id=31602
References: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/647043
References: https://bugzilla.redhat.com/show_bug.cgi?id=770308
Signed-off-by: Bjorn Helgaas
Signed-off-by: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman -
commit 73736e0387ba0e6d2b703407b4d26168d31516a7 upstream.
Zhihua Che reported a possible memleak in slub allocator on
CONFIG_PREEMPT=y builds.It is possible current thread migrates right before disabling irqs in
__slab_alloc(). We must check again c->freelist, and perform a normal
allocation instead of scratching c->freelist.Many thanks to Zhihua Che for spotting this bug, introduced in 2.6.39
V2: Its also possible an IRQ freed one (or several) object(s) and
populated c->freelist, so its not a CONFIG_PREEMPT only problem.Reported-by: Zhihua Che
Signed-off-by: Eric Dumazet
Acked-by: Christoph Lameter
Signed-off-by: Pekka Enberg
Signed-off-by: Greg Kroah-Hartman -
commit 7b7e5916aa2f46e57f8bd8cb89c34620ebfda5da upstream.
Don't free a valid measurement entry on TPM PCR extend failure.
Signed-off-by: Roberto Sassu
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman -
commit 45fae7493970d7c45626ccd96d4a74f5f1eea5a9 upstream.
Info about new measurements are cached in the iint for performance. When
the inode is flushed from cache, the associated iint is flushed as well.
Subsequent access to the inode will cause the inode to be re-measured and
will attempt to add a duplicate entry to the measurement list.This patch frees the duplicate measurement memory, fixing a memory leak.
Signed-off-by: Roberto Sassu
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman -
commit 307729c8bc5b5a41361af8af95906eee7552acb1 upstream.
We normally try to avoid reading from write-mostly devices, but when
we do we really have to check for bad blocks and be sure not to
try reading them.With the current code, best_good_sectors might not get set and that
causes zero-length read requests to be send down which is very
confusing.This bug was introduced in commit d2eb35acfdccbe2 and so the patch
is suitable for 3.1.x and 3.2.xReported-and-tested-by: Michał Mirosław
Reported-and-tested-by: Art -kwaak- van Breemen
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 9e7860cee18241633eddb36a4c34c7b61d8cecbc upstream.
Haogang Chen found out that:
There is a potential integer overflow in process_msg() that could result
in cross-domain attack.body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent
call to xb_read() would write to a zero-length buffer.The other end of this connection is always the xenstore backend daemon
so there is no guest (malicious or otherwise) which can do this. The
xenstore daemon is a trusted component in the system.However this seem like a reasonable robustness improvement so we should
have it.And Ian when read the API docs found that:
The payload length (len field of the header) is limited to 4096
(XENSTORE_PAYLOAD_MAX) in both directions. If a client exceeds the
limit, its xenstored connection will be immediately killed by
xenstored, which is usually catastrophic from the client's point of
view. Clients (particularly domains, which cannot just reconnect)
should avoid this.so this patch checks against that instead.
This also avoids a potential integer overflow pointed out by Haogang Chen.
Signed-off-by: Ian Campbell
Cc: Haogang Chen
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman -
commit aff132d95ffe14eca96cab90597cdd010b457af7 upstream.
The amount of memory required for tracking chain buffers is rather
large, and when the host credit count is big, memory allocation
failure occurs inside __get_free_pages.The fix is to limit the number of chains to 100,000. In addition,
the number of host credits is limited to 30,000 IOs. However this
limitation can be overridden this using the command line option
max_queue_depth. The algorithm for calculating the
reply_post_queue_depth is changed so that it is equal to
(reply_free_queue_depth + 16), previously it was (reply_free_queue_depth * 2).Signed-off-by: Nagalakshmi Nandigama
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman -
commit 30c43282f3d347f47f9e05199d2b14f56f3f2837 upstream.
Added code to release the spinlock that is used to protect the
raid device list before calling a function that can block. The
blocking was causing a reschedule, and subsequently it is tried
to acquire the same lock, resulting in a panic (NMI Watchdog
detecting a CPU lockup).Signed-off-by: Nagalakshmi Nandigama
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman -
commit 5cf9a4e69c1ff0ccdd1d2b7404f95c0531355274 upstream.
We only need amd_bus.o for AMD systems with PCI. arch/x86/pci/Makefile
already depends on CONFIG_PCI=y, so this patch just adds the dependency
on CONFIG_AMD_NB.Cc: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 24d25dbfa63c376323096660bfa9ad45a08870ce upstream.
This factors out the AMD native MMCONFIG discovery so we can use it
outside amd_bus.c.amd_bus.c reads AMD MSRs so it can remove the MMCONFIG area from the
PCI resources. We may also need the MMCONFIG information to work
around BIOS defects in the ACPI MCFG table.Cc: Borislav Petkov
Cc: Yinghai Lu
Signed-off-by: Bjorn Helgaas
Signed-off-by: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman -
commit ae5cd86455381282ece162966183d3f208c6fad7 upstream.
This assures that a _CRS reserved host bridge window or window region is
not used if it is not addressable by the CPU. The new code either trims
the window to exclude the non-addressable portion or totally ignores the
window if the entire window is non-addressable.The current code has been shown to be problematic with 32-bit non-PAE
kernels on systems where _CRS reserves resources above 4GB.Signed-off-by: Gary Hade
Reviewed-by: Bjorn Helgaas
Cc: Thomas Renninger
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman -
commit a776c491ca5e38c26d9f66923ff574d041e747f4 upstream.
I traced a nasty kexec on panic boot failure to the fact that we had
screaming msi interrupts and we were not disabling the msi messages at
kernel startup. The booting kernel had not enabled those interupts so
was not prepared to handle them.I can see no reason why we would ever want to leave the msi interrupts
enabled at boot if something else has enabled those interrupts. The pci
spec specifies that msi interrupts should be off by default. Drivers
are expected to enable the msi interrupts if they want to use them. Our
interrupt handling code reprograms the interrupt handlers at boot and
will not be be able to do anything useful with an unexpected interrupt.This patch applies cleanly all of the way back to 2.6.32 where I noticed
the problem.Signed-off-by: Eric W. Biederman
Signed-off-by: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman -
commit 1830ea91c20b06608f7cdb2455ce05ba834b3214 upstream.
Spec shows this as 1010b = 0xa
Signed-off-by: Alex Williamson
Signed-off-by: Jesse Barnes
Signed-off-by: Greg Kroah-Hartman -
commit e57e0d8e818512047fe379157c3f77f1b9fabffb upstream.
When we fail to erase a PEB, we free the corresponding erase entry object,
but then re-schedule this object if the error code was something like -EAGAIN.
Obviously, it is a bug to use the object after we have freed it.Reported-by: Emese Revfy
Signed-off-by: Artem Bityutskiy
Signed-off-by: Greg Kroah-Hartman -
commit e801e128b2200c40a0ec236cf2330b2586b6e05a upstream.
Under some cases, when scrubbing the PEB if we did not get the lock on
the PEB it fails to scrub. Add that PEB again to the scrub listArtem: minor amendments.
Signed-off-by: Bhavesh Parekh
Signed-off-by: Artem Bityutskiy
Signed-off-by: Greg Kroah-Hartman -
commit e46e927b9b7e8d95526e69322855243882b7e1a3 upstream.
This allows the latest N-Trig devices to function properly.
BugLink: https://bugs.launchpad.net/bugs/724831
Signed-off-by: Chase Douglas
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 8a0d551a59ac92d8ff048d6cb29d3a02073e81e8 upstream.
Setting the security context of a NFSv4 mount via the context= mount
option is currently broken. The NFSv4 codepath allocates a parsed
options struct, and then parses the mount options to fill it. It
eventually calls nfs4_remote_mount which calls security_init_mnt_opts.
That clobbers the lsm_opts struct that was populated earlier. This bug
also looks like it causes a small memory leak on each v4 mount where
context= is used.Fix this by moving the initialization of the lsm_opts into
nfs_alloc_parsed_mount_data. Also, add a destructor for
nfs_parsed_mount_data to make it easier to free all of the allocations
hanging off of it, and to ensure that the security_free_mnt_opts is
called whenever security_init_mnt_opts is.I believe this regression was introduced quite some time ago, probably
by commit c02d7adf.Signed-off-by: Jeff Layton
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit bf118a342f10dafe44b14451a1392c3254629a1f upstream.
The NFSv4 bitmap size is unbounded: a server can return an arbitrary
sized bitmap in an FATTR4_WORD0_ACL request. Replace using the
nfs4_fattr_bitmap_maxsz as a guess to the maximum bitmask returned by a server
with the inclusion of the bitmap (xdr length plus bitmasks) and the acl data
xdr length to the (cached) acl page data.This is a general solution to commit e5012d1f "NFSv4.1: update
nfs4_fattr_bitmap_maxsz" and fixes hitting a BUG_ON in xdr_shrink_bufhead
when getting ACLs.Fix a bug in decode_getacl that returned -EINVAL on ACLs > page when getxattr
was called with a NULL buffer, preventing ACL > PAGE_SIZE from being retrieved.Signed-off-by: Andy Adamson
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 2edb6bc3852c681c0d948245bd55108dc6407604 upstream.
From c6d615d2b97fe305cbf123a8751ced859dca1d5e Mon Sep 17 00:00:00 2001
From: NeilBrown
Date: Wed, 16 Nov 2011 09:39:05 +1100
Subject: NFS - fix recent breakage to NFS error handling.commit 02c24a82187d5a628c68edfe71ae60dc135cd178 made a small and
presumably unintended change to write error handling in NFS.Previously an error from filemap_write_and_wait_range would only be of
interest if nfs_file_fsync did not return an error. After this commit,
an error from filemap_write_and_wait_range would mean that (the rest of)
nfs_file_fsync would not even be called.This means that:
1/ you are more likely to see EIO than e.g. EDQUOT or ENOSPC.
2/ NFS_CONTEXT_ERROR_WRITE remains set for longer so more writes are
synchronous.This patch restores previous behaviour.
Cc: Josef Bacik
Cc: Jan Kara
Cc: Al Viro
Signed-off-by: NeilBrown
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 61f2e5106582d02f30b6807e3f9c07463c572ccb upstream.
Signed-off-by: Andy Adamson
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 43717c7daebf10b43f12e68512484b3095bb1ba5 upstream.
Lukas Razik reports that on his SPARC system,
booting with an NFS root file system stopped working after commit
56463e50 "NFS: Use super.c for NFSROOT mount option parsing."We found that the network switch to which Lukas' client was attached
was delaying access to the LAN after the client's NIC driver reported
that its link was up. The delay was longer than the timeouts used in
the NFS client during mounting.NFSROOT worked for Lukas before commit 56463e50 because in those
kernels, the client's first operation was an rpcbind request to
determine which port the NFS server was listening on. When that
request failed after a long timeout, the client simply selected the
default NFS port (2049). By that time the switch was allowing access
to the LAN, and the mount succeeded.Neither of these client behaviors is desirable, so reverting 56463e50
is really not a choice. Instead, introduce a mechanism that retries
the NFSROOT mount request several times. This is the same tactic that
normal user space NFS mounts employ to overcome server and network
delays.Signed-off-by: Lukas Razik
[ cel: match kernel coding style, add proper patch description ]
[ cel: add exponential back-off ]
Signed-off-by: Chuck Lever
Tested-by: Lukas Razik
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 3df96909b75835d487a9178761622b0cbd7310d4 upstream.
It would previously write basically random bits to PCI configuration space...
Not very surprising that the GPU tended to stop responding completely. The
resulting MCE even froze the whole machine sometimes.Now resetting the GPU after a lockup has at least a fighting chance of
succeeding.Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 28eebb703e28bc455ba704adb1026f76649b768c upstream.
We often end up missing fences on older asics with
writeback enabled which leads to delays in the userspace
accel code, so just disable it by default on those asics.Reported-by: Helge Deller
Reported-by: Dave Airlie
Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 92db7f6c860b8190571a9dc1fcbc16d003422fe8 upstream.
This change was verified to fix both issues with no video I've
investigated. I've also checked checksum calculation with fglrx on:
RV620, HD54xx, HD5450, HD6310, HD6320.Signed-off-by: Rafał Miłecki
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit d4afc7754a60b885b63ef23fd194984e2d53a4e6 upstream.
This patch avoid a page fault in the ideapad-laptop extras when
turning the backlight power on or off.Signed-off-by: Rene Bolldorf
Signed-off-by: Matthew Garrett
Signed-off-by: Jonathan Nieder
Tested-by: Artem X
Signed-off-by: Greg Kroah-Hartman -
(cherry picked from commit 3d27e23b17010c668db311140b17bbbb70c78fb9)
Only allow KVM device assignment to attach to devices which:
- Are not bridges
- Have BAR resources (assume others are special devices)
- The user has permissions to useAssigning a bridge is a configuration error, it's not supported, and
typically doesn't result in the behavior the user is expecting anyway.
Devices without BAR resources are typically chipset components that
also don't have host drivers. We don't want users to hold such devices
captive or cause system problems by fencing them off into an iommu
domain. We determine "permission to use" by testing whether the user
has access to the PCI sysfs resource files. By default a normal user
will not have access to these files, so it provides a good indication
that an administration agent has granted the user access to the device.[Yang Bai: add missing #include]
[avi: fix comment style]Signed-off-by: Alex Williamson
Signed-off-by: Yang Bai
Signed-off-by: Marcelo Tosatti
Signed-off-by: Greg Kroah-Hartman -
(cherry picked from commit 423873736b78f549fbfa2f715f2e4de7e6c5e1e9)
This option has no users and it exposes a security hole that we
can allow devices to be assigned without iommu protection. Make
KVM_DEV_ASSIGN_ENABLE_IOMMU a mandatory option.Signed-off-by: Alex Williamson
Signed-off-by: Marcelo Tosatti
Signed-off-by: Greg Kroah-Hartman -
(cherry picked from commit 0924ab2cfa98b1ece26c033d696651fd62896c69)
User space may create the PIT and forgets about setting up the irqchips.
In that case, firing PIT IRQs will crash the host:BUG: unable to handle kernel NULL pointer dereference at 0000000000000128
IP: [] kvm_set_irq+0x30/0x170 [kvm]
...
Call Trace:
[] pit_do_work+0x51/0xd0 [kvm]
[] process_one_work+0x111/0x4d0
[] worker_thread+0x152/0x340
[] kthread+0x7e/0x90
[] kernel_thread_helper+0x4/0x10Prevent this by checking the irqchip mode before starting a timer. We
can't deny creating the PIT if the irqchips aren't set up yet as
current user land expects this order to work.Signed-off-by: Jan Kiszka
Signed-off-by: Marcelo Tosatti
Signed-off-by: Greg Kroah-Hartman -
(cherry picked from commit 95ef1e52922cf75b1ea2eae54ef886f2cc47eecb)
Prevent tracing of preempt_disable() in get_cpu_var() in
kvm_clock_read(). When CONFIG_DEBUG_PREEMPT is enabled,
preempt_disable/enable() are traced and this causes the function_graph
tracer to go into an infinite recursion. By open coding the
preempt_disable() around the get_cpu_var(), we can use the notrace
version which prevents preempt_disable/enable() from being traced and
prevents the recursion.Based on a similar patch for Xen from Jeremy Fitzhardinge.
Tested-by: Gleb Natapov
Acked-by: Steven Rostedt
Signed-off-by: Avi Kivity
Signed-off-by: Greg Kroah-Hartman -
commit f2cbba7602383cd9cdd21f0a5d0b8bd1aad47b33 upstream.
When multiple headphone or other detectable output pins are present,
the power-map has to be updated after resume appropriately, but the
current driver doesn't check all pins but only the first pin (since
it's enough to check it for the mute-behavior). This resulted in the
silent output from the secondary outputs after PM resume.This patch fixes the problem by checking all pins at (re-)init time.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740347
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 4808d12d1dddb046ec86425e5f6766f02e950292 upstream.
Currently the driver checks only the out_mix_path[] for the primary
output route for judging whether to create the loopback-mixing control
or not. But, there are cases where aamix-routing is available only on
headphone or speaker paths but not on the primary output path. So, the
driver ignores such cases inappropriately.This patch fixes the check of the loopback-mixing control by testing
all mix-routing paths.Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 3a90274de3548ebb2aabfbf488cea8e275a73dc6 upstream.
When an invalid NID is given, get_wcaps() returns zero as the error,
but get_wcaps_type() takes it as the normal value and returns a bogus
AC_WID_AUD_OUT value. This confuses the parser.With this patch, get_wcaps_type() returns -1 when value 0 is given,
i.e. an invalid NID is passed to get_wcaps().Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740118
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit de4da59e480cdf1075b33dbaf8078fc87bc52241 upstream.
These laptops can work well with the auto-parser and their BIOS setups,
and in addition, the auto-parser fixes the problem with S3/S4 where
the unsol event handling is killed after resume due to fallback to the
single-cmd mode.Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=740115
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit e7848163aa2a649d9065f230fadff80dc3519775 upstream.
Cards with identical PCI ids but no AC97 config in EEPROM do not have
the ac97 field initialized. We must check for this case to avoid kernel oops.Signed-off-by: Pavel Hofman
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 78e2a928e377d5124932d4399c6c581908b027a0 upstream.
There was a bug in the automute logic causing speakers not to
mute when headphones were plugged in.Tested-by: Hsin-Yi Chen
Signed-off-by: David Henningsson
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
