- Feb 11, 2013
-
-
Greg Kroah-Hartman authored
-
Alan Stern authored
commit b09a61cc upstream. This patch (as1653) fixes a bug in ehci-hcd. Unlike iTD entries, an siTD entry in the periodic schedule may not complete until the frame after the one it belongs to. Consequently, when scanning the periodic schedule it is necessary to start with the frame _preceding_ the one where the previous scan ended. Not doing this properly can result in memory leaks and failures to complete isochronous URBs. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by:
Andy Leiserson <andy@leiserson.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Moore authored
commit 58b2939b upstream. When the xHCI driver is not available, actively switch the ports to EHCI mode since some BIOSes leave them in xHCI mode where they would otherwise appear dead. This was discovered on a Dell Optiplex 7010, but it's possible other systems could be affected. This should be backported to kernels as old as 3.0, that contain the commit 69e848c2 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by:
David Moore <david.moore@gmail.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Alan Stern authored
commit 48c3375c upstream. This patch (as1640) fixes a memory leak in xhci-hcd. The urb_priv data structure isn't always deallocated in the handle_tx_event() routine for non-control transfers. The patch adds a kfree() call so that all paths end up freeing the memory properly. This patch should be backported to kernels as old as 2.6.36, that contain the commit 8e51adcc "USB: xHCI: Introduce urb_priv structure" Signed-off-by:
Martin Mokrejs <mmokrejs@fold.natur.cuni.cz> Signed-off-by:
-
Sarah Sharp authored
commit f18f8ed2 upstream. To calculate the TD size for a particular TRB in an isoc TD, we need know the endpoint's max packet size. Isochronous endpoints also encode the number of additional service opportunities in their wMaxPacketSize field. The TD size calculation did not mask off those bits before using the field. This resulted in incorrect TD size information for isochronous TRBs when an URB frame buffer crossed a 64KB boundary. For example: - an isoc endpoint has 2 additional service opportunites and a max packet size of 1020 bytes - a frame transfer buffer contains 3060 bytes - one frame buffer crosses a 64KB boundary, and must be split into one 1276 byte TRB, and one 1784 byte TRB. The TD size is is the number of packets that remain to be transferred for a TD after processing all the max packet sized packets in the current TRB and all previous TRBs. For this TD, the number of packets to be transferred is (3060 / 1020), or 3. The first TRB contains 1276 bytes, which means it contains one full packet, and a 256 byte remainder. After processing all the max packet-sized packets in the first TRB, the host will have 2 packets left to transfer. The old code would calculate the TD size for the first TRB as: total packet count = DIV_ROUND_UP (TD length / endpoint wMaxPacketSize) total packet count - (first TRB length / endpoint wMaxPacketSize) The math should have been: total packet count = DIV_ROUND_UP (3060 / 1020) = 3 3 - (1276 / 1020) = 2 Since the old code didn't mask off the additional service interval bits from the wMaxPacketSize field, the math ended up as total packet count = DIV_ROUND_UP (3060 / 5116) = 1 1 - (1276 / 5116) = 1 Fix this by masking off the number of additional service opportunities in the wMaxPacketSize field. This patch should be backported to stable kernels as old as 3.0, that contain the commit 4da6e6f2 "xhci 1.0: Update TD size field format." It may not apply well to kernels older than 3.2 because of commit 29cc8897 "USB: use usb_endpoint_maxp() instead of le16_to_cpu()". Signed-off-by:
-
Sarah Sharp authored
commit 760973d2 upstream. An isochronous TD is comprised of one isochronous TRB chained to zero or more normal TRBs. Only the isoc TRB has the TBC and TLBPC fields. The normal TRBs must set those fields to zeroes. The code was setting the TBC and TLBPC fields for both isoc and normal TRBs. Fix this. This should be backported to stable kernels as old as 3.0, that contain the commit b61d378f " xhci 1.0: Set transfer burst last packet count field." Signed-off-by:
-
Nickolai Zeldovich authored
commit ba7b5c22 upstream. Fix incorrect bit test that originally showed up in 4ee823b8 "USB/xHCI: Support device-initiated USB 3.0 resume." Use '&' instead of '&&'. This should be backported to kernels as old as 3.4. Signed-off-by:
Nickolai Zeldovich <nickolai@csail.mit.edu> Signed-off-by:
-
fangxiaozhi authored
commit 200e0d99 upstream. 1. Optimize the match rules with new macro for Huawei USB storage devices, to avoid to load USB storage driver for the modem interface with Huawei devices. 2. Add to support new switch command for new Huawei USB dongles. Signed-off-by:
fangxiaozhi <huananhu@huawei.com> Signed-off-by:
-
fangxiaozhi authored
commit 07c7be3d upstream. 1. Define a new macro for USB storage match rules: matching with Vendor ID and interface descriptors. Signed-off-by:
-
Lan Tianyu authored
commit 54a3ac0c upstream. Usb3.0 device defines function remote wakeup which is only for interface recipient rather than device recipient. This is different with usb2.0 device's remote wakeup feature which is defined for device recipient. According usb3.0 spec 9.4.5, the function remote wakeup can be modified by the SetFeature() requests using the FUNCTION_SUSPEND feature selector. This patch is to use correct way to disable usb3.0 device's function remote wakeup after suspend error and resuming. This should be backported to kernels as old as 3.4, that contain the commit 623bef9e "USB/xhci: Enable remote wakeup for USB3 devices." Signed-off-by:
Lan Tianyu <tianyu.lan@intel.com> Signed-off-by:
-
Alan Stern authored
commit 3e619d04 upstream. This patch (as1654) fixes a very old bug in ehci-hcd, connected with scheduling of periodic split transfers. The calculations for full/low-speed bus usage are all carried out after the correction for bit-stuffing has been applied, but the values in the max_tt_usecs array assume it hasn't been. The array should allow for allocation of up to 90% of the bus capacity, which is 900 us, not 780 us. The symptom caused by this bug is that any isochronous transfer to a full-speed device with a maxpacket size larger than about 980 bytes is always rejected with a -ENOSPC error. Signed-off-by:
-
Alan Stern authored
commit ee74290b upstream. This patch (as1652) fixes a long-standing bug in ehci-hcd. The driver relies on status polls to know when to stop port-resume signalling. It uses the root-hub status timer to schedule these status polls. But when the driver for the root hub is resumed, the timer is rescheduled to go off immediately -- before the port is ready. When this happens the timer does not get re-enabled, which prevents the port resume from finishing until some other event occurs. The symptom is that when a new device is plugged in, it doesn't get recognized or enumerated until lsusb is run or something else happens. The solution is to re-enable the root-hub status timer after every status poll while a port resume is in progress. This bug hasn't surfaced before now because we never used to try to suspend the root hub in the middle of a port resume (except by coincidence). Signed-off-by:
Norbert Preining <preining@logic.at> Tested-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
-
Alan Stern authored
commit 6e0c3339 upstream. This patch (as1648) fixes a regression affecting nVidia EHCI controllers. Evidently they don't like to have more than one async QH unlinked at a time. I can't imagine how they manage to mess it up, but at least one of them does. The patch changes the async unlink logic in two ways: Each time an IAA cycle is started, only the first QH on the async unlink list is handled (rather than all of them). Async QHs do not all get unlinked as soon as they have been empty for long enough. Instead, only the last one (i.e., the one that has been on the schedule the longest) is unlinked, and then only if no other unlinks are in progress at the time. This means that when multiple QHs are empty, they won't be unlinked as quickly as before. That's okay; it won't affect correct operation of the driver or add an excessive load. Multiple unlinks tend to be relatively rare in any case. Signed-off-by:
Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> Signed-off-by:
-
Alan Stern authored
commit 55bcdce8 upstream. This patch (as1647) attempts to work around a problem that seems to affect some nVidia EHCI controllers. They sometimes take a very long time to turn off their async or periodic schedules. I don't know if this is a result of other problems, but in any case it seems wise not to depend on schedule enables or disables taking effect in any specific length of time. The patch removes the existing 20-ms timeout for enabling and disabling the schedules. The driver will now continue to poll the schedule state at 1-ms intervals until the controller finally decides to obey the most recent command issued by the driver. Just in case this hides a problem, a debugging message will be logged if the controller takes longer than 20 polls. I don't know if this will actually fix anything, but it can't hurt. Signed-off-by:
-
Daniele Palmas authored
commit 78796ae1 upstream. Add VID and PID for Telit Gobi QDL device Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
-
Bjørn Mork authored
commit d4fa6815 upstream. New device with 3 serial interfaces: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend) Sub=ff Prot=ff If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend) Sub=ff Prot=ff If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend) Sub=ff Prot=ff If#= 3 Alt= 0 #EPs= 2 Cls=08(stor) Sub=06 Prot=50 Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Daniele Palmas authored
commit 03eb466f upstream. Add PID and special handling for Telit LE920 Signed-off-by:
-
Sven Killig authored
commit c249f911 upstream. Add PID/VID entries for ELV WS 300 PC II weather station Signed-off-by:
Sven Killig <sven@killig.de> Signed-off-by:
-
Petr Kubánek authored
commit 0ba3b2cc upstream. Add support for Zolix Omni 1509 monochromator custom USB-RS232 converter. Signed-off-by:
Petr Kubánek <petr@kubanek.net> Signed-off-by:
-
Haojian Zhuang authored
commit e7e034e1 upstream. The RTC control register should be enabled in the process of initializing. Without this patch, I failed to enable RTC in Hisilicon Hi3620 SoC. The register mapping section in RTC is always read as zero. So I doubt that ST guys may already enable this register in bootloader. So they won't meet this issue. Signed-off-by:
Haojian Zhuang <haojian.zhuang@linaro.org> Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jan Luebbe authored
commit 72fca4a4 upstream. Previously the alarm event was not propagated into the RTC subsystem. By adding a call to rtc_update_irq, this fixes a timeout problem with the hwclock utility. Signed-off-by:
Jan Luebbe <jlu@pengutronix.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Tony Lu authored
commit be7517d6 upstream. When setting a huge PTE, besides calling pte_mkhuge(), we also need to call arch_make_huge_pte(), which we indeed do in make_huge_pte(), but we forget to do in hugetlb_change_protection() and remove_migration_pte(). Signed-off-by:
Zhigang Lu <zlu@tilera.com> Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Reviewed-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
Hillf Danton <dhillf@gmail.com> Signed-off-by:
-
Vyacheslav Dubeyko authored
commit a9bae189 upstream. There exists a situation when GC can work in background alone without any other filesystem activity during significant time. The nilfs_clean_segments() method calls nilfs_segctor_construct() that updates superblocks in the case of NILFS_SC_SUPER_ROOT and THE_NILFS_DISCONTINUED flags are set. But when GC is working alone the nilfs_clean_segments() is called with unset THE_NILFS_DISCONTINUED flag. As a result, the update of superblocks doesn't occurred all this time and in the case of SPOR superblocks keep very old values of last super root placement. SYMPTOMS: Trying to mount a NILFS2 volume after SPOR in such environment ends with very long mounting time (it can achieve about several hours in some cases). REPRODUCING PATH: 1. It needs to use external USB HDD, disable automount and doesn't make any additional filesystem activity on the NILFS2 volume. 2. Generate temporary file with size about 100 - 500 GB (for example, dd if=/dev/zero of=<file_name> bs=1073741824 count=200). The size of file defines duration of GC working. 3. Then it needs to delete file. 4. Start GC manually by means of command "nilfs-clean -p 0". When you start GC by means of such way then, at the end, superblocks is updated by once. So, for simulation of SPOR, it needs to wait sometime (15 - 40 minutes) and simply switch off USB HDD manually. 5. Switch on USB HDD again and try to mount NILFS2 volume. As a result, NILFS2 volume will mount during very long time. REPRODUCIBILITY: 100% FIX: This patch adds checking that superblocks need to update and set THE_NILFS_DISCONTINUED flag before nilfs_clean_segments() call. Reported-by:
Sergey Alexandrov <splavgm@gmail.com> Signed-off-by:
Vyacheslav Dubeyko <slava@dubeyko.com> Tested-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Tested-by:
-
Sergei Shtylyov authored
commit 7a9c8388 upstream. Commit cdeadd71 (mtd: nand: davinci: add OF support for davinci nand controller) has never been really build tested with the driver as a module. When the driver is built-in, the missing semicolon after structure initializer is "compensated" by MODULE_DEVICE_TABLE() macro being empty and so the initializer using the trailing semicolon on the next line; when the driver is built as a module, compilation error ensues, and as the 'davinci_all_defconfig' has the NAND driver modular, this error prevents DaVinci family kernel from building... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Shawn Bohrer authored
commit aa7f6730 upstream. When the system has multiple domains do_sched_rt_period_timer() can run on any CPU and may iterate over all rt_rq in cpu_online_mask. This means when balance_runtime() is run for a given rt_rq that rt_rq may be in a different rd than the current processor. Thus if we use smp_processor_id() to get rd in do_balance_runtime() we may borrow runtime from a rt_rq that is not part of our rd. This changes do_balance_runtime to get the rd from the passed in rt_rq ensuring that we borrow runtime only from the correct rd for the given rt_rq. This fixes a BUG at kernel/sched/rt.c:687! in __disable_runtime when we try reclaim runtime lent to other rt_rq but runtime has been lent to a rt_rq in another rd. Signed-off-by:
Shawn Bohrer <sbohrer@rgmadvisors.com> Acked-by:
Steven Rostedt <rostedt@goodmis.org> Acked-by:
Mike Galbraith <bitbucket@online.de> Cc: peterz@infradead.org Link: http://lkml.kernel.org/r/1358186131-29494-1-git-send-email-sbohrer@rgmadvisors.com Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Jan Beulich authored
commit 40a1ef95 upstream. For some reason they didn't get replaced so far by their paravirt equivalents, resulting in code to be run with interrupts disabled that doesn't expect so (causing, in the observed case, a BUG_ON() to trigger) when syscall auditing is enabled. David (Cc-ed) came up with an identical fix, so likely this can be taken to count as an ack from him. Reported-by:
Peter Moody <pmoody@google.com> Signed-off-by:
Jan Beulich <jbeulich@suse.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Link: http://lkml.kernel.org/r/5108E01902000078000BA9C5@nat28.tlf.novell.com Signed-off-by:
-
liu chuansheng authored
commit f2d68cf4 upstream. When kzalloc() failed in radeon_user_framebuffer_create(), need to call object_unreference() to match the object_reference(). Signed-off-by:
liu chuansheng <chuansheng.liu@intel.com> Signed-off-by:
xueminsu <xuemin.su@intel.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit fd5d93a0 upstream. If the requested number of DWs on the ring is larger than the size of the ring itself, return an error. In testing with large VM updates, we've seen crashes when we try and allocate more space on the ring than the total size of the ring without checking. This prevents the crash but for large VM updates or bo moves of very large buffers, we will need to break the transaction down into multiple batches. I have patches to use IBs for the next kernel. Signed-off-by:
-
Mikko Tiihonen authored
commit f689e3ac upstream. Make sure at least one RB is enabled in r6xx_remap_render_backend() to avoid an division by zero in some corner cases. See: https://bugzilla.redhat.com/show_bug.cgi?id=892233 Signed-off-by:
-
Alex Deucher authored
commit f7eb9730 upstream. Need to adjust the backend map depending on which RB is enabled. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=892233 Reported-by:
Mikko Tiihonen <mikko.tiihonen@iki.fi> Signed-off-by:
-
Christopher Staite authored
commit bb588820 upstream. Force the crtc mem requests on/off immediately rather than waiting for the double buffered updates to kick in. Seems we miss the update in certain conditions. Also handle the DCE6 case. Signed-off-by:
Christopher Staite <chris@yourdreamnet.co.uk> Signed-off-by:
-
Alex Deucher authored
commit 9200ee49 upstream. vbios says external TMDS while the board is actually internal TMDS. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=60037 Signed-off-by:
-
Alex Deucher authored
commit 674a16f2 upstream. Newer versions of mesa emit this. Signed-off-by:
-
Alex Deucher authored
commit ed39fadd upstream. Some chips seem to need a little delay after blacking out the MC before the requests actually stop. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=56139 https://bugs.freedesktop.org/show_bug.cgi?id=57567 Signed-off-by:
-
YOSHIFUJI Hideaki authored
commit 7810cc1e upstream. digsig_verify_rsa() does not free kmalloc'ed buffer returned by mpi_get_buffer(). Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
Dmitry Kasatkin <dmitry.kasatkin@intel.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Aneesh Kumar K.V authored
commit eda8eebd upstream. The ASM version of hash computation function was truncating the upper bit. Make the ASM version similar to hpt_hash function. Remove masking vsid bits. Without this patch, we observed hang during bootup due to not satisfying page fault request correctly. The fault handler used wrong hash values to update the HPTE. Hence we kept looping with page fault. hash_page(ea=000001003e260008, access=203, trap=300 ip=3fff91787134 dsisr 42000000 The computed value of hash 000000000f22f390 update: avpnv=4003e46054003e00, hash=000000000722f390, f=80000006, psize: 2 ... BenH: The over-masking has been there for ever but only hurts with the new 64T support introduced in 3.7 Reported-by:
Mike Qiu <qiudayu@linux.vnet.ibm.com> Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Tested-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
- Feb 03, 2013
-
-
Greg Kroah-Hartman authored
-
Pablo Neira Ayuso authored
commit 4610476d upstream. net/netfilter/xt_CT.c: In function ‘xt_ct_tg_check_v1’: net/netfilter/xt_CT.c:250:6: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized] net/netfilter/xt_CT.c: In function ‘xt_ct_tg_check_v0’: net/netfilter/xt_CT.c:112:6: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized] Reported-by:
Borislav Petkov <bp@alien8.de> Acked-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
CAI Qian authored
This is for stable-3.7.y only and this problem has already been solved in mainline through some slab/slub re-work which isn't suitable to backport here. See create_kmalloc_cache() in mm/slab_common.c there. commit cce89f4f ('Move kmem_cache refcounting to common code') moves some refcount manipulation code to common code. Unfortunately, it also removed refcount assignment for kmalloc_caches. So, kmalloc_caches's refcount is initially 0. This makes erroneous situation. Paul Hargrove report that when he create a 8-byte kmem_cache and destory it, he encounter below message. 'Objects remaining in kmalloc-8 on kmem_cache_close()' 8-byte kmem_cache merge with 8-byte kmalloc cache and refcount is increased by one. So, resulting refcount is 1. When destroy it, it hit refcount = 0, then kmem_cache_close() is executed and error message is printed. This patch assign initial refcount 1 to kmalloc_caches, so fix this erroneous situation. Reported-by:
Paul Hargrove <phhargrove@lbl.gov> Cc: Christoph Lameter <cl@linux.com> Signed-off-by:
Joonsoo Kim <js1304@gmail.com> Signed-off-by:
CAI Qian <caiqian@redhat.com> Signed-off-by:
-
Jani Nikula authored
commit b5144075 upstream. We stopped reading FORCEWAKE for posting reads in commit 8dee3eea Author: Ben Widawsky <ben@bwidawsk.net> Date: Sat Sep 1 22:59:50 2012 -0700 drm/i915: Never read FORCEWAKE and started using something from the same cacheline instead. On the bug reporter's machine this broke entering rc6 states after a suspend/resume cycle. It turns out reading ECOBUS as posting read worked fine, while GTFIFODBG did not, preventing RC6 states after suspend/resume per the bug report referenced below. It's not entirely clear why, but clearly GTFIFODBG was nowhere near the same cacheline or address range as FORCEWAKE. Trying out various registers for posting reads showed that all tested registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true work. Conversely, most (but not quite all) registers for which NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced bug. Based on the above, add posting reads on ECOBUS where GTFIFODBG was previously relied on. In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same address range as FORCEWAKE_VLV. v2: Add more details to the commit message. No functional changes. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411 Reported-and-tested-by:
Alexander Bersenev <bay@hackerdom.ru> CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org [danvet: add cc: stable and make the commit message a bit clearer that this is a regression fix and what exactly broke.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
