- 12 May, 2010 40 commits
-
-
Hans de Goede authored
commit 7efbfd1a upstream. Without this quirk sound stops working after suspend resume. With this quirk, one still needs to manually unmute the master volume control after a suspend / / resume cycle. That is fixed in another patch in this set. Note that this patch was submitted to the alsa bug tracker a long time ago: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4319Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Daniel T Chen authored
commit 3353541f upstream. BugLink: https://launchpad.net/bugs/567494 The OR has verified that the existing model quirk, ALC880_UNIWILL, is insufficient for audible playback and capture by default. Instead, the ALC880_F1734 model quirk needs to be used. This change is necessary for both 2.6.32.11 and 2.6.33.2. Reported-by:
Arnaud Malpeyre <amalpeyre@gmail.com> Tested-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
-
Daniel T Chen authored
commit 5c1bccf6 upstream. BugLink: https://launchpad.net/bugs/568600 The OR has verified that the dell-m6 model quirk is necessary for audio to be audible by default on the Dell Studio XPS 1645. This change is necessary for 2.6.32.11 and 2.6.33.2 alike. Reported-by:
Andy Ross <andy@plausible.org> Tested-by:
-
Daniel T Chen authored
commit aac78daf upstream. BugLink: https://launchpad.net/bugs/553002 The OR has verified that the dell-m6 model quirk is necessary for audio to be audible by default on the Dell Studio XPS 1645. This change is necessary for 2.6.32.11 and 2.6.33.2 alike. Reported-by: Robert Chambers Tested-by: Robert Chambers Signed-off-by:
-
Kunal Gangakhedkar authored
commit e3d2530a upstream. Adding this PCI quirk fixes the board config detection. This also fixes jack sensing by using "hp_detect=1" via properly detected board config. Signed-off-by:
Kunal Gangakhedkar <kunal.gangakhedkar@gmail.com> Signed-off-by:
-
Daniel T Chen authored
commit 0e0280dc upstream. BugLink: https://launchpad.net/bugs/459083 The OR has verified with 2.6.32.11 and the latest alsa-driver stable daily snapshot that position_fix=1 is necessary for the external mic to work and for PulseAudio not to crash constantly. This patch is necessary also for 2.6.32.11 and 2.6.33.2. Reported-by: <imwithid@yahoo.com> Tested-by: <imwithid@yahoo.com> Signed-off-by:
-
Prarit Bhargava authored
commit ebb682f5 upstream. The per_cpu cpuid4_info shared_map can contain stale data when CPUs are added and removed. The stale data can lead to a NULL pointer derefernce panic on a remove of a CPU that has had siblings previously removed. This patch resolves the panic by verifying a cpu is actually online before adding it to the shared_cpu_map, only examining cpus that are part of the same lower level cache, and by updating other siblings lowest level cache maps when a cpu is added. Signed-off-by:
Prarit Bhargava <prarit@redhat.com> LKML-Reference: <20091209183336.17855.98708.sendpatchset@prarit.bos.redhat.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Borislav Petkov authored
commit 0e152cd7 upstream. de957628 changed setting of the x86_init.iommu.iommu_init function ptr only when GART IOMMU is found. One side effect of it is that num_k8_northbridges is not initialized anymore if not explicitly called. This resulted in uninitialized pointers in <arch/x86/kernel/cpu/intel_cacheinfo.c:amd_calc_l3_indices()>, for example, which uses the num_k8_northbridges thing through node_to_k8_nb_misc(). Fix that through an initcall that runs right after the PCI subsystem and does all the scanning. Then, remove initialization in gart_iommu_init() which is a rootfs_initcall and we're running before that. What is more, since num_k8_northbridges is being used in other places beside GART IOMMU, include it whenever we add AMD CPU support. The previous dependency chain in kconfig contained K8_NB depends on AGP_AMD64|GART_IOMMU which was clearly incorrect. The more natural way in terms of hardware dependency should be AGP_AMD64|GART_IOMMU depends on K8_NB depends on CPU_SUP_AMD && PCI. Make it so Number One! Signed-off-by:
Borislav Petkov <borislav.petkov@amd.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Joerg Roedel <joerg.roedel@amd.com> LKML-Reference: <20100312144303.GA29262@aftab> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Tested-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
H. Peter Anvin authored
commit 7a0fc404 upstream. Atom erratum AAE44/AAF40/AAG38/AAH41: "If software clears the PS (page size) bit in a present PDE (page directory entry), that will cause linear addresses mapped through this PDE to use 4-KByte pages instead of using a large page after old TLB entries are invalidated. Due to this erratum, if a code fetch uses this PDE before the TLB entry for the large page is invalidated then it may fetch from a different physical address than specified by either the old large page translation or the new 4-KByte page translation. This erratum may also cause speculative code fetches from incorrect addresses." [http://download.intel.com/design/processor/specupdt/319536.pdf] Where as commit 211b3d03 seems to workaround errata AAH41 (mixed 4K TLBs) it reduces the window of opportunity for the bug to occur and does not totally remove it. This patch disables mixed 4K/4MB page tables totally avoiding the page splitting and not tripping this processor issue. This is based on an original patch by Colin King. Originally-by:
Colin Ian King <colin.king@canonical.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> LKML-Reference: <1269271251-19775-1-git-send-email-colin.king@canonical.com> Signed-off-by:
-
H. Peter Anvin authored
commit 7ce5a2b9 upstream. When we do a thread switch, we clear the outgoing FS/GS base if the corresponding selector is nonzero. This is taken by __switch_to() as an entry invariant; it does not verify that it is true on entry. However, copy_thread() doesn't enforce this constraint, which can result in inconsistent results after fork(). Make copy_thread() match the behavior of __switch_to(). Reported-and-tested-by:
Samuel Thibault <samuel.thibault@inria.fr> Signed-off-by:
-
Borislav Petkov authored
commit 35d824b2 upstream. Correct two mishaps which prevented reporting error type (CECC vs UECC) and extended error description. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Hans de Goede authored
commit 0250ecec upstream. Hans de Goede identified a bug in p54p_check_tx_ring: there are two ring indices. 1 => tx data and 3 => tx management. But the old code had a constant "1" and this resulted in spurious dma unmapping failures. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=583623Bug-Identified-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Peter Korsgaard authored
commit e9162ab1 upstream. Use correct bit positions in DM_SHARED_CTRL register for writes. Michael Planes recently encountered a 'KY-RS9600 USB-LAN converter', which came with a driver CD containing a Linux driver. This driver turns out to be a copy of dm9601.c with symbols renamed and my copyright stripped. That aside, it did contain 1 functional change in dm_write_shared_word(), and after checking the datasheet the original value was indeed wrong (read versus write bits). On Michaels HW, this change bumps receive speed from ~30KB/s to ~900KB/s. On other devices the difference is less spectacular, but still significant (~30%). Reported-by:
Michael Planes <michael.planes@free.fr> Signed-off-by:
Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Richard Kennedy authored
commit a534dbe9 upstream. blk_rq_timed_out_timer() relied on blk_add_timer() never returning a timer value of zero, but commit 7838c15b removed the code that bumped this value when it was zero. Therefore when jiffies is near wrap we could get unlucky & not set the timeout value correctly. This patch uses a flag to indicate that the timeout value was set and so handles jiffies wrap correctly, and it keeps all the logic in one function so should be easier to maintain in the future. Signed-off-by:
Richard Kennedy <richard@rsk.demon.co.uk> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Ping Cheng authored
commit d9901660 upstream. Add Fujitsu Wacom 1FGT Tablet PC device Signed-off-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Dan Williams authored
commit 5157b4aa upstream. The raid6 recovery code should immediately drop back to the optimized synchronous path when a p+q dma resource is not available. Otherwise we run the non-optimized/multi-pass async code in sync mode. Verified with raid6test (NDISKS=255) Applies to kernels >= 2.6.32. Acked-by:
NeilBrown <neilb@suse.de> Reported-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Tejun Heo authored
commit 048c8520 upstream. perf_event_open() kfrees event after init failure which doesn't release all resources allocated by perf_event_alloc(). Use free_event() instead. Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Paul Mackerras <paulus@au1.ibm.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> LKML-Reference: <4BDBE237.1040809@kernel.org> Signed-off-by:
-
Jean Delvare authored
commit b1d4b390 upstream. Some FSC hardware monitoring chips (Syleus at least) doesn't like quick writes we typically use to probe for I2C chips. Use a regular byte read instead for the address they live at (0x73). These are the only known chips living at this address on PC systems. For clarity, this fix should not be needed for kernels 2.6.30 and later, as we started instantiating the hwmon devices explicitly based on DMI data. Still, this fix is valuable in the following two cases: * Support for recent FSC chips on older kernels. The DMI-based device instantiation is more difficult to backport than the device support itself. * Case where the DMI-based device instantiation fails, whatever the reason. We fall back to probing in that case, so it should work. This fixes kernel bug #15634: https://bugzilla.kernel.org/show_bug.cgi?id=15634Signed-off-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
-
Stephen Hemminger authored
commit 546d9e10 upstream. This patch makes the HyperV network device use the same naming scheme as other virtual drivers (Xen, KVM). In an ideal world, userspace tools would not care what the name is, but some users and applications do care. Vyatta CLI is one of the tools that does depend on what the name is. Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Cc: Hank Janssen <hjanssen@microsoft.com> Signed-off-by:
-
Cyrill Gorcunov authored
commit fa8ad025 upstream. Don't assign NULL too early Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Cc: Hank Janssen <hjanssen@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
Haiyang Zhang authored
commit 95beae90 upstream. Fix a bug affecting IPv6 Added the multicast flag for proper IPv6 function. Reported-by:
Toshikazu Sakai <toshikas@microsoft.com> Signed-off-by:
Hank Janssen <hjanssen@microsoft.com> Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
Chuck Lever authored
commit 356e76b8 upstream. NFSv4 mounts ignore the rsize and wsize mount options, and always use the default transfer size for both. This seems to be because all NFSv4 mounts are now cloned, and the cloning logic doesn't copy the rsize and wsize settings from the parent nfs_server. I tested Fedora's 2.6.32.11-99 and it seems to have this problem as well, so I'm guessing that .33, .32, and perhaps older kernels have this issue as well. Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Al Viro authored
commit d9e80b7d upstream. If dentry found stale happens to be a root of disconnected tree, we can't d_drop() it; its d_hash is actually part of s_anon and d_drop() would simply hide it from shrink_dcache_for_umount(), leading to all sorts of fun, including busy inodes on umount and oopsen after that. Bug had been there since at least 2006 (commit c636eb already has it), so it's definitely -stable fodder. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Mark Langsdorf authored
commit b810e94c upstream. With F10, model 10, all valid frequencies are in the ACPI _PST table. Signed-off-by:
Mark Langsdorf <mark.langsdorf@amd.com> LKML-Reference: <1270065406-1814-6-git-send-email-bp@amd64.org> Signed-off-by:
Thomas Renninger <trenn@suse.de> Signed-off-by:
-
Joel Becker authored
commit a36d515c upstream. When asked for a partial read of the LVB in a dlmfs file, we can accidentally calculate a negative count. Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
Joel Becker <joel.becker@oracle.com> Signed-off-by:
-
Joel Becker authored
commit a42ab8e1 upstream. Online resize writes out the new superblock and its backups directly. The metaecc data wasn't being recomputed. Let's do that directly. Signed-off-by:
Mark Fasheh <mfasheh@suse.com> Signed-off-by:
-
Dan Carpenter authored
commit 0350cb07 upstream. If "handle" is non null at the end of the function then we assume it's a valid pointer and pass it to ocfs2_commit_trans(); Signed-off-by:
-
Tao Ma authored
commit c21a534e upstream. In reflink we update the id info on the disk but forgot to update the corresponding information in the VFS inode. Update them accordingly when we want to preserve the attributes. Reported-by:
Jeff Liu <jeff.liu@oracle.com> Signed-off-by:
Tao Ma <tao.ma@oracle.com> Signed-off-by:
-
Jerome Marchand authored
commit 3835541d upstream. Correct the file_operations struct in fdinfo entry of tid_base_stuff[]. Presently /proc/*/task/*/fdinfo contains symlinks to opened files like /proc/*/fd/. Signed-off-by:
Jerome Marchand <jmarchan@redhat.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Miklos Szeredi <mszeredi@suse.cz> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Sarah Sharp authored
commit 9238f25d upstream. For periodic endpoints, we must let the xHCI hardware know the maximum payload an endpoint can transfer in one service interval. The xHCI specification refers to this as the Maximum Endpoint Service Interval Time Payload (Max ESIT Payload). This is used by the hardware for bandwidth management and scheduling of packets. For SuperSpeed endpoints, the maximum is calculated by multiplying the max packet size by the number of bursts and the number of opportunities to transfer within a service interval (the Mult field of the SuperSpeed Endpoint companion descriptor). Devices advertise this in the wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor. For high speed devices, this is taken by multiplying the max packet size by the "number of additional transaction opportunities per microframe" (the high bits of the wMaxPacketSize field in the endpoint descriptor). For FS/LS devices, this is just the max packet size. The other thing we must set in the endpoint context is the Average TRB Length. This is supposed to be the average of the total bytes in the transfer descriptor (TD), divided by the number of transfer request blocks (TRBs) it takes to describe the TD. This gives the host controller an indication of whether the driver will be enqueuing a scatter gather list with many entries comprised of small buffers, or one contiguous buffer. It also takes into account the number of extra TRBs you need for every TD. This includes No-op TRBs and Link TRBs used to link ring segments together. Some drivers may choose to chain an Event Data TRB on the end of every TD, thus increasing the average number of TRBs per TD. The Linux xHCI driver does not use Event Data TRBs. In theory, if there was an API to allow drivers to state what their bandwidth requirements are, we could set this field accurately. For now, we set it to the same number as the Max ESIT payload. The Average TRB Length should also be set for bulk and control endpoints, but I have no idea how to guess what it should be. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Sarah Sharp authored
commit 1cf62246 upstream. A SuperSpeed interrupt or isochronous endpoint can define the number of "burst transactions" it can handle in a service interval. This is indicated by the "Mult" bits in the bmAttributes of the SuperSpeed Endpoint Companion Descriptor. For example, if it has a max packet size of 1024, a max burst of 11, and a mult of 3, the host may send 33 1024-byte packets in one service interval. We must tell the xHCI host controller the number of multiple service opportunities (mults) the device can handle when the endpoint is installed. We do that by setting the Mult field of the Endpoint Context before a configure endpoint command is sent down. The Mult field is invalid for control or bulk SuperSpeed endpoints. Signed-off-by:
-
Alan Stern authored
commit fcf7d214 upstream. This patch (as1371) fixes a small bug in ohci-hcd. The HCD already knows how many ports the controller has; there's no need to go looking at the root hub's usb_device structure to find out. Especially since the root hub's maxchild value is set correctly only while the root hub is bound to the hub driver. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
commit 62f9cfa3 upstream. This patch (as1372) fixes a bug in the routine that chooses the default configuration to install when a new USB device is detected. The algorithm is supposed to look for a config whose first interface is for a non-vendor-specific class. But the way it's currently written, it will also accept a config with no interfaces at all, which is not very useful. (Believe it or not, such things do exist.) Signed-off-by:
Andrew Victor <avictor.za@gmail.com> Signed-off-by:
-
Dan Carpenter authored
commit fa7fe7af upstream. There is a typo here. We should be testing "*dentry" which was just assigned instead of "dentry". This could result in dereferencing an ERR_PTR inside either usbfs_mkdir() or usbfs_create(). Signed-off-by:
-
William Lightning authored
commit cfbaa393 upstream. Signed-off-by:
William Lightning <kassah@gmail.com> Signed-off-by:
-
Alan Stern authored
This is a backport of commit 5f677f1d. Some of the functionality had to be removed, but it should still fix the webcam problem. This patch (as1363b) changes the way USB remote wakeup is handled during system sleeps. It won't be enabled unless an interface driver specifically needs it. Also, it won't be enabled during the FREEZE or QUIESCE phases of hibernation, when the system doesn't respond to wakeup events anyway. This will fix problems people have reported with certain USB webcams that generate wakeup requests when they shouldn't, and as a result cause system suspends to fail. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/515109Signed-off-by:
-
Eric Lescouet authored
commit d01f42a2 upstream. When detaching a port from the client side (usbip --detach 0), the event thread, on the server side, is going to deadlock. The "eh" server thread is getting USBIP_EH_RESET event and calls: -> stub_device_reset() -> usb_reset_device() the USB framework is then calling back _in the same "eh" thread_ : -> stub_disconnect() -> usbip_stop_eh() -> wait_for_completion() the "eh" thread is being asleep forever, waiting for its own completion. This patch checks if "eh" is the current thread, in usbip_stop_eh(). Signed-off-by:
Eric Lescouet <eric@lescouet.org> Signed-off-by:
-
David Howells authored
commit 03449cd9 upstream. The request_key() system call and request_key_and_link() should make a link from an existing key to the destination keyring (if supplied), not just from a new key to the destination keyring. This can be tested by: ring=`keyctl newring fred @s` keyctl request2 user debug:a a keyctl request user debug:a $ring keyctl list $ring If it says: keyring is empty then it didn't work. If it shows something like: 1 key in keyring: 1070462727: --alswrv 0 0 user: debug:a then it did. request_key() system call is meant to recursively search all your keyrings for the key you desire, and, optionally, if it doesn't exist, call out to userspace to create one for you. If request_key() finds or creates a key, it should, optionally, create a link to that key from the destination keyring specified. Therefore, if, after a successful call to request_key() with a desination keyring specified, you see the destination keyring empty, the code didn't work correctly. If you see the found key in the keyring, then it did - which is what the patch is required for. Signed-off-by:
David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Signed-off-by:
-
Neil Brown authored
commit 2bc3c117 upstream. When read_buf is called to move over to the next page in the pagelist of an NFSv4 request, it sets argp->end to essentially a random number, certainly not an address within the page which argp->p now points to. So subsequent calls to READ_BUF will think there is much more than a page of spare space (the cast to u32 ensures an unsigned comparison) so we can expect to fall off the end of the second page. We never encountered thsi in testing because typically the only operations which use more than two pages are write-like operations, which have their own decoding logic. Something like a getattr after a write may cross a page boundary, but it would be very unusual for it to cross another boundary after that. Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
Jeff Mahoney authored
commit fb2162df upstream. Commit 48b32a35 ("reiserfs: use generic xattr handlers") introduced a problem that causes corruption when extended attributes are replaced with a smaller value. The issue is that the reiserfs_setattr to shrink the xattr file was moved from before the write to after the write. The root issue has always been in the reiserfs xattr code, but was papered over by the fact that in the shrink case, the file would just be expanded again while the xattr was written. The end result is that the last 8 bytes of xattr data are lost. This patch fixes it to use new_size. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=14826Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Reported-by:
Christian Kujau <lists@nerdbynature.de> Tested-by:
-
