- 20 Aug, 2013 36 commits
-
-
Matt Burtch authored
commit 6c1ee66a upstream. This fixes an issue where the bulk-in urb used for incoming data transfer is not resubmitted if the packet recieved contains an error status. This results in the driver locking until the port is closed and re-opened. Tested on a custom board with a Cinterion GSM module. Signed-off-by:
Matt Burtch <matt@grid-net.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alan Stern authored
commit 24f53137 upstream. Since commits 4005ad43 (EHCI: implement new semantics for URB_ISO_ASAP) and c75c5ab5 (ALSA: USB: adjust for changed 3.8 USB API) became widely distributed, people have been experiencing problems with audio transfers. The slightest underrun causes complete failure, requiring the audio stream to be restarted. It turns out that the current isochronous API doesn't handle underruns in the best way. The ALSA developers would much rather have transfers that are submitted too late be accepted and complete in the normal fashion, rather than being refused outright. This patch implements the requested approach. When an isochronous URB submission is so late that all its scheduled slots have already expired, a debugging message will be printed in the log and the URB will be accepted as usual. Assuming it was submitted by a completion handler (which is normally the case), it will complete shortly thereafter with all the usb_iso_packet_descriptor status fields marked -EXDEV. This fixes (for ehci-hcd) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603 It should be applied to all kernels that include commit 4005ad43. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Maksim Boyko <maksboyko@yandex.ru> CC: Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Johan Hovold authored
commit ff8a43c1 upstream. Make sure to fail properly if the device is not accepted during attach in order to avoid null-pointer derefs (of missing interface private data) at disconnect or release. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit ef6c8c1d upstream. The parallel-port code of the drivers used a stack allocated control-request buffer for asynchronous (and possibly deferred) control requests. This not only violates the no-DMA-from-stack requirement but could also lead to corrupt control requests being submitted. Signed-off-by:
-
Johan Hovold authored
commit d551ec9b upstream. Fix bug in device-type detection on big-endian machines originally introduced by commit 0eafe4de ("USB: serial: mos7840: add support for MCS7810 devices") which always matched on little-endian product ids. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Johan Hovold authored
commit e877dd2f upstream. Fix endianess bugs in firmware handling introduced by commits cb7a7c6a ("ti_usb_3410_5052: add Multi-Tech modem support") and 05a3d905 ("ti_usb_3410_5052: support alternate firmware") which made the driver use the wrong firmware for certain devices on big-endian machines. Signed-off-by:
-
Oliver Neukum authored
commit 304ab4ab upstream. These devices tend to become unresponsive after S3 Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Johannes Berg authored
commit c319d50b upstream. This is similar to the race Linus had reported, but in this case it's an older bug: nl80211_prepare_wdev_dump() uses the wiphy index in cb->args[0] as it is and thus parses the message over and over again instead of just once because 0 is the first valid wiphy index. Similar code in nl80211_testmode_dump() correctly offsets the wiphy_index by 1, do that here as well. Reported-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Takashi Iwai authored
commit 1801928e upstream. Gateway LT27 needs a fixup for the inverted digital mic. Reported-by:
"Nathanael D. Noblet" <nathanael@gnat.ca> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit db8a38e5 upstream. Correct the pins for a line-in and a headphone on LG LW25 laptop with ALC880 codec. Other pins seem fine. Reported-and-tested-by:
Joonas Saarinen <jonskunator@gmail.com> Signed-off-by:
-
Takashi Iwai authored
commit f69910dd upstream. We've added a fake mute control (setting the amp volume to zero) for CX5051 at commit [3868137e: ALSA: hda - Add a fake mute feature], but this feature was overlooked in the generic parser implementation. Now the driver lacks of mute controls on these codecs. The fix is just to check both AC_AMPCAP_MUTE and AC_AMPCAP_MIN_MUTE bits in each place checking the amp capabilities. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59001Signed-off-by:
-
Torsten Schenk authored
commit 4c2aee00 upstream. Patch makes midi output buffer DMA-able by allocating it separately. Signed-off-by:
Torsten Schenk <torsten.schenk@zoho.com> Signed-off-by:
-
Torsten Schenk authored
commit 5ece263f upstream. Patch makes pcm buffers DMA-able by allocating each one separately. Signed-off-by:
-
Maksim A. Boyko authored
commit 140d37de upstream. Add the volume control quirk for avoiding the kernel warning for the Logitech HD Webcam C525 as in the similar commit 36691e1b for the Logitech HD Webcam C310. Reported-by:
Maksim Boyko <maksim.a.boyko@gmail.com> Tested-by:
-
Stephen Warren authored
commit c90c0d7a upstream. The Tegra30 I2S driver was writing the AHUB interface parameters to the playback path register rather than the capture path register. This caused the capture parameters not to be configured at all, so if capturing using non-HW-default parameters (e.g. 16-bit stereo rather than 8-bit mono) the audio would be corrupted. With this fixed, audio capture from an analog microphone works correctly on the Cardhu board. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Brian Austin authored
commit e2c98a8b upstream. Beep Volume Min/Max was backwards. Change to SOC_SONGLE_SX_TLV for correct volume representation Signed-off-by:
Brian Austin <brian.austin@cirrus.com> Signed-off-by:
-
Lars-Peter Clausen authored
commit fe581391 upstream. list_first_entry() will always return a valid pointer, even if the list is empty. So the check whether path is NULL will always be false. So we end up calling dapm_create_or_share_mixmux_kcontrol() with a path struct that points right in the middle of the widget struct and by trying to modify the path the widgets memory will become corrupted. Fix this by using list_emtpy() to check if the widget doesn't have any paths. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Tested-by:
-
Johannes Berg authored
commit 74418ede upstream. When a P2P GO interface goes down, cfg80211 doesn't properly tear it down, leading to warnings later. Add the GO interface type to the enumeration to tear it down like AP interfaces. Otherwise, we leave it pending and mac80211's state can get very confused, leading to warnings later. Reported-by:
Ilan Peer <ilan.peer@intel.com> Tested-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 58ad436f upstream. When dumping generic netlink families, only the first dump call is locked with genl_lock(), which protects the list of families, and thus subsequent calls can access the data without locking, racing against family addition/removal. This can cause a crash. Fix it - the locking needs to be conditional because the first time around it's already locked. A similar bug was reported to me on an old kernel (3.4.47) but the exact scenario that happened there is no longer possible, on those kernels the first round wasn't locked either. Looking at the current code I found the race described above, which had also existed on the old kernel. Reported-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Stephane Grosjean authored
commit 3c322a56 upstream. Fix possibly wrong memcpy() bytes length since some CAN records received from PCAN-USB could define a DLC field in range [9..15]. In that case, the real DLC value MUST be used to move forward the record pointer but, only 8 bytes max. MUST be copied into the data field of the struct can_frame object of the skb given to the network core. Signed-off-by:
Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Johannes Berg authored
commit ddfe49b4 upstream. In case the AP has different regulatory information than we do, it can happen that we connect to an AP based on e.g. the world roaming regulatory data, and then update our database with the AP's country information disables the channel the AP is using. If this happens on an HT AP, the bandwidth tracking code will hit the WARN_ON() and disconnect. Since that's not very useful, ignore the channel-disable flag in bandwidth tracking. Reported-by:
Chris Wright <chrisw@sous-sol.org> Tested-by:
-
Chris Wright authored
commit b56e4b85 upstream. Commit "3d9646d0 mac80211: fix channel selection bug" introduced a possible infinite loop by moving the out target above the chandef_downgrade while loop. When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump back up to re-run the while loop...indefinitely. Replace goto with break and carry on. This may not be sufficient to connect to the AP, but will at least keep the cpu from livelocking. Thanks to Derek Atkins as an extra pair of debugging eyes. Signed-off-by:
-
Johannes Berg authored
commit 5cdaed1e upstream. While we're connected, the AP shouldn't change the primary channel in the HT information. We checked this, and dropped the connection if it did change it. Unfortunately, this is causing problems on some APs, e.g. on the Netgear WRT610NL: the beacons seem to always contain a bad channel and if we made a connection using a probe response (correct data) we drop the connection immediately and can basically not connect properly at all. Work around this by ignoring the HT primary channel information in beacons if we're already connected. Also print out more verbose messages in the other situations to help diagnose similar bugs quicker in the future. Acked-by:
Andy Isaacson <adi@hexapodia.org> Signed-off-by:
-
Stanislaw Gruszka authored
commit 788f7a56 upstream. Using rfkill switch can make firmware unstable, what cause various Microcode errors and kernel warnings. Reseting firmware just after rfkill off (radio on) helped with that. Resolve: https://bugzilla.redhat.com/show_bug.cgi?id=977053Reported-and-tested-by:
Justin Pearce <whitefox@guardianfox.net> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit eca396d7 upstream. If device was put into a sleep and system was restarted or module reloaded, we have to wake device up before sending other commands. Otherwise it will fail to start with Microcode error. Signed-off-by:
-
Marc Zyngier authored
commit 22cfbb6d upstream. Make sure we clear the exclusive monitor on all exception returns, which otherwise could lead to lock corruptions. Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by:
-
Marc Zyngier authored
commit 479c5ae2 upstream. When performing a Stage-2 TLB invalidation, it is necessary to make sure the write to the page tables is observable by all CPUs. For this purpose, add a dsb instruction to __kvm_tlb_flush_vmid_ipa before doing the TLB invalidation itself. Signed-off-by:
-
Marc Zyngier authored
commit 6a077e4a upstream. Not saving PAR is an unfortunate oversight. If the guest performs an AT* operation and gets scheduled out before reading the result of the translation from PAR, it could become corrupted by another guest or the host. Saving this register is made slightly more complicated as KVM also uses it on the permission fault handling path, leading to an ugly "stash and restore" sequence. Fortunately, this is already a slow path so we don't really care. Also, Linux doesn't do any AT* operation, so Linux guests are not impacted by this bug. [ Slightly tweaked to use an even register as first operand to ldrd and strd operations in interrupts_head.S - Christoffer ] Signed-off-by:
-
Jianpeng Ma authored
commit d50235b7 upstream. There's a race between elevator switching and normal io operation. Because the allocation of struct elevator_queue and struct elevator_data don't in a atomic operation.So there are have chance to use NULL ->elevator_data. For example: Thread A: Thread B blk_queu_bio elevator_switch spin_lock_irq(q->queue_block) elevator_alloc elv_merge elevator_init_fn Because call elevator_alloc, it can't hold queue_lock and the ->elevator_data is NULL.So at the same time, threadA call elv_merge and nedd some info of elevator_data.So the crash happened. Move the elevator_alloc into func elevator_init_fn, it make the operations in a atomic operation. Using the follow method can easy reproduce this bug 1:dd if=/dev/sdb of=/dev/null 2:while true;do echo noop > scheduler;echo deadline > scheduler;done The test method also use this method. Signed-off-by:
Jianpeng Ma <majianpeng@gmail.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Cc: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by:
-
Peter Zijlstra authored
commit bf0bd948 upstream. We typically update a task_group's shares within the dequeue/enqueue path. However, continuously running tasks sharing a CPU are not subject to these updates as they are only put/picked. Unfortunately, when we reverted f269ae04 (in 17bc14b7), we lost the augmenting periodic update that was supposed to account for this; resulting in a potential loss of fairness. To fix this, re-introduce the explicit update in update_cfs_rq_blocked_load() [called via entity_tick()]. Reported-by:
Max Hailperin <max@gustavus.edu> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Reviewed-by:
Paul Turner <pjt@google.com> Link: http://lkml.kernel.org/n/tip-9545m3apw5d93ubyrotrj31y@git.kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
yonghua zheng authored
commit 8c829622 upstream. Recently we met quite a lot of random kernel panic issues after enabling CONFIG_PROC_PAGE_MONITOR. After debuggind we found this has something to do with following bug in pagemap: In struct pagemapread: struct pagemapread { int pos, len; pagemap_entry_t *buffer; bool v2; }; pos is number of PM_ENTRY_BYTES in buffer, but len is the size of buffer, it is a mistake to compare pos and len in add_page_map() for checking buffer is full or not, and this can lead to buffer overflow and random kernel panic issue. Correct len to be total number of PM_ENTRY_BYTES in buffer. [akpm@linux-foundation.org: document pagemapread.pos and .len units, fix PM_ENTRY_BYTES definition] Signed-off-by:
Yonghua Zheng <younghua.zheng@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Radu Caragea authored
commit df54d6fa upstream. When the stack is set to unlimited, the bottomup direction is used for mmap-ings but the mmap_base is not used and thus effectively renders ASLR for mmapings along with PIE useless. Reviewed-by:
Rik van Riel <riel@redhat.com> Cc: Michel Lespinasse <walken@google.com> Cc: Oleg Nesterov <oleg@redhat.com> Acked-by:
-
Michal Simek authored
commit dfa9771a upstream. Fix inadvertent breakage in the clone syscall ABI for Microblaze that was introduced in commit f3268edb ("microblaze: switch to generic fork/vfork/clone"). The Microblaze syscall ABI for clone takes the parent tid address in the 4th argument; the third argument slot is used for the stack size. The incorrectly-used CLONE_BACKWARDS type assigned parent tid to the 3rd slot. This commit restores the original ABI so that existing userspace libc code will work correctly. All kernel versions from v3.8-rc1 were affected. Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Andrey Vagin authored
commit 3e6b11df upstream. struct memcg_cache_params has a union. Different parts of this union are used for root and non-root caches. A part with destroying work is used only for non-root caches. I fixed the same problem in another place v3.9-rc1-16204-gf101a946, but didn't notice this one. This patch fixes the kernel panic: [ 46.848187] BUG: unable to handle kernel paging request at 000000fffffffeb8 [ 46.849026] IP: [<ffffffff811a484c>] kmem_cache_destroy_memcg_children+0x6c/0xc0 [ 46.849092] PGD 0 [ 46.849092] Oops: 0000 [#1] SMP ... Signed-off-by:
Andrey Vagin <avagin@openvz.org> Cc: Glauber Costa <glommer@openvz.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Michal Hocko <mhocko@suse.cz> Cc: Balbir Singh <bsingharora@gmail.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Signed-off-by:
-
Stephen Boyd authored
commit b88a2595 upstream. Fix constraint check in armpmu_map_hw_event(). Reported-and-tested-by:
Vince Weaver <vincent.weaver@maine.edu> Signed-off-by:
-
Vince Weaver authored
commit c9601247 upstream. John McCalpin reports that the "drs_data" and "ncb_data" QPI uncore events are missing the "extra bit" and always return zero values unless the bit is properly set. More details from him: According to the Xeon E5-2600 Product Family Uncore Performance Monitoring Guide, Table 2-94, about 1/2 of the QPI Link Layer events (including the ones that "perf" calls "drs_data" and "ncb_data") require that the "extra bit" be set. This was confusing for a while -- a note at the bottom of page 94 says that the "extra bit" is bit 16 of the control register. Unfortunately, Table 2-86 clearly says that bit 16 is reserved and must be zero. Looking around a bit, I found that bit 21 appears to be the correct "extra bit", and further investigation shows that "perf" actually agrees with me: [root@c560-003.stampede]# cat /sys/bus/event_source/devices/uncore_qpi_0/format/event config:0-7,21 So the command # perf -e "uncore_qpi_0/event=drs_data/" Is the same as # perf -e "uncore_qpi_0/event=0x02,umask=0x08/" While it should be # perf -e "uncore_qpi_0/event=0x102,umask=0x08/" I confirmed that this last version gives results that agree with the amount of data that I expected the STREAM benchmark to move across the QPI link in the second (cross-chip) test of the original script. Reported-by:
John McCalpin <mccalpin@tacc.utexas.edu> Signed-off-by:
-
- 15 Aug, 2013 4 commits
-
-
Greg Kroah-Hartman authored
-
Markos Chandras authored
commit 78857614 upstream. The GENERIC_PCI_IOMAP does not depend on CONFIG_PCI so move it to the CONFIG_MIPS symbol so it's always selected for MIPS. This fixes the missing pci_iomap declaration for MIPS. Moreover, the pci_iounmap function was not defined in the io.h header file if the CONFIG_PCI symbol is not set, but it should since MIPS is not using CONFIG_GENERIC_IOMAP. This fixes the following problem on a allyesconfig: drivers/net/ethernet/3com/3c59x.c:1031:2: error: implicit declaration of function 'pci_iomap' [-Werror=implicit-function-declaration] drivers/net/ethernet/3com/3c59x.c:1044:3: error: implicit declaration of function 'pci_iounmap' [-Werror=implicit-function-declaration] Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Acked-by:
Steven J. Hill <Steven.Hill@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/5478/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Arnd Bergmann authored
commit 930d800b upstream. The omap2 nand device driver calls into the the elm code, which can be a loadable module, and in that case it cannot be built-in itself. I can see no reason why the omap2 driver cannot also be a module, so let's make the option "tristate" in Kconfig to fix this allmodconfig build error: ERROR: "elm_config" [drivers/mtd/nand/omap2.ko] undefined! ERROR: "elm_decode_bch_error_page" [drivers/mtd/nand/omap2.ko] undefined! Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Tony Lindgren <tony@atomide.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: Afzal Mohammed <afzal@ti.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Arnd Bergmann authored
commit b497ceb9 upstream. ARM cannot handle udelay for more than 2 miliseconds, so we should use mdelay instead for those. Signed-off-by:
GOTO Masanori <gotom@debian.or.jp> Cc: YOKOTA Hiroshi <yokota@netlab.is.tsukuba.ac.jp> Cc: "James E.J. Bottomley" <JBottomley@parallels.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
