- 08 Mar, 2017 40 commits
-
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1663687 Enable multi-q support. We will allocate the outgoing channel using the following policy: 1. We will make every effort to pick a channel that is in the same NUMA node that is initiating the I/O 2. The mapping between the guest CPU and the outgoing channel is persistent. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Reviewed-by:
Long Li <longli@microsoft.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (back ported from linux-next commit d86adf48) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Conflicts: drivers/scsi/storvsc_drv.c Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1663687 Remove the artificially imposed restriction on max segment size. Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1663687 Enable tracking of queue depth. Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1662666 In blk_mq_map_swqueue, there is a memory optimization that frees the tags of a queue that has gone unmapped. Later, if that hctx is remapped after another topology change, the tags need to be reallocated. If this allocation fails, a simple WARN_ON triggers, but the block layer ends up with an active hctx without any corresponding set of tags. Then, any income IO to that hctx can trigger an Oops. I can reproduce it consistently by running IO, flipping CPUs on and off and eventually injecting a memory allocation failure in that path. In the fix below, if the system experiences a failed allocation of any hctx's tags, we remap all the ctxs of that queue to the hctx_0, which should always keep it's tags. There is a minor performance hit, since our mapping just got worse after the error path, but this is the simplest solution to handle this error path. The performance hit will disappear after another successful remap. I considered dropping the memory optimization all together, but it seemed a bad trade-off to handle this very specific error case. This should apply cleanly on top of Jens' for-next branch. The Oops is the one below: SP (3fff935ce4d0) is in userspace 1:mon> e cpu 0x1: Vector: 300 (Data Access) at [c000000fe99eb110] pc: c0000000005e868c: __sbitmap_queue_get+0x2c/0x180 lr: c000000000575328: __bt_get+0x48/0xd0 sp: c000000fe99eb390 msr: 900000010280b033 dar: 28 dsisr: 40000000 current = 0xc000000fe9966800 paca = 0xc000000007e80300 softe: 0 irq_happened: 0x01 pid = 11035, comm = aio-stress Linux version 4.8.0-rc6+ (root@bean) (gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.2) ) #3 SMP Mon Oct 10 20:16:53 CDT 2016 1:mon> s [c000000fe99eb3d0] c000000000575328 __bt_get+0x48/0xd0 [c000000fe99eb400] c000000000575838 bt_get.isra.1+0x78/0x2d0 [c000000fe99eb480] c000000000575cb4 blk_mq_get_tag+0x44/0x100 [c000000fe99eb4b0] c00000000056f6f4 __blk_mq_alloc_request+0x44/0x220 [c000000fe99eb500] c000000000570050 blk_mq_map_request+0x100/0x1f0 [c000000fe99eb580] c000000000574650 blk_mq_make_request+0xf0/0x540 [c000000fe99eb640] c000000000561c44 generic_make_request+0x144/0x230 [c000000fe99eb690] c000000000561e00 submit_bio+0xd0/0x200 [c000000fe99eb740] c0000000003ef740 ext4_io_submit+0x90/0xb0 [c000000fe99eb770] c0000000003e95d8 ext4_writepages+0x588/0xdd0 [c000000fe99eb910] c00000000025a9f0 do_writepages+0x60/0xc0 [c000000fe99eb940] c000000000246c88 __filemap_fdatawrite_range+0xf8/0x180 [c000000fe99eb9e0] c000000000246f90 filemap_write_and_wait_range+0x70/0xf0 [c000000fe99eba20] c0000000003dd844 ext4_sync_file+0x214/0x540 [c000000fe99eba80] c000000000364718 vfs_fsync_range+0x78/0x130 [c000000fe99ebad0] c0000000003dd46c ext4_file_write_iter+0x35c/0x430 [c000000fe99ebb90] c00000000038c280 aio_run_iocb+0x3b0/0x450 [c000000fe99ebce0] c00000000038dc28 do_io_submit+0x368/0x730 [c000000fe99ebe30] c000000000009404 system_call+0x38/0xec Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Cc: Brian King <brking@linux.vnet.ibm.com> Cc: Douglas Miller <dougmill@linux.vnet.ibm.com> Cc: linux-block@vger.kernel.org Cc: linux-scsi@vger.kernel.org Reviewed-by:
Douglas Miller <dougmill@linux.vnet.ibm.com> Signed-off-by:
Jens Axboe <axboe@fb.com> (cherry picked from commit d1b1cea1) Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1662666 While stressing memory and IO at the same time we changed SMT settings, we were able to consistently trigger deadlocks in the mm system, which froze the entire machine. I think that under memory stress conditions, the large allocations performed by blk_mq_init_rq_map may trigger a reclaim, which stalls waiting on the block layer remmaping completion, thus deadlocking the system. The trace below was collected after the machine stalled, waiting for the hotplug event completion. The simplest fix for this is to make allocations in this path non-reclaimable, with GFP_NOIO. With this patch, We couldn't hit the issue anymore. This should apply on top of Jens's for-next branch cleanly. Changes since v1: - Use GFP_NOIO instead of GFP_NOWAIT. Call Trace: [c000000f0160aaf0] [c000000f0160ab50] 0xc000000f0160ab50 (unreliable) [c000000f0160acc0] [c000000000016624] __switch_to+0x2e4/0x430 [c000000f0160ad20] [c000000000b1a880] __schedule+0x310/0x9b0 [c000000f0160ae00] [c000000000b1af68] schedule+0x48/0xc0 [c000000f0160ae30] [c000000000b1b4b0] schedule_preempt_disabled+0x20/0x30 [c000000f0160ae50] [c000000000b1d4fc] __mutex_lock_slowpath+0xec/0x1f0 [c000000f0160aed0] [c000000000b1d678] mutex_lock+0x78/0xa0 [c000000f0160af00] [d000000019413cac] xfs_reclaim_inodes_ag+0x33c/0x380 [xfs] [c000000f0160b0b0] [d000000019415164] xfs_reclaim_inodes_nr+0x54/0x70 [xfs] [c000000f0160b0f0] [d0000000194297f8] xfs_fs_free_cached_objects+0x38/0x60 [xfs] [c000000f0160b120] [c0000000003172c8] super_cache_scan+0x1f8/0x210 [c000000f0160b190] [c00000000026301c] shrink_slab.part.13+0x21c/0x4c0 [c000000f0160b2d0] [c000000000268088] shrink_zone+0x2d8/0x3c0 [c000000f0160b380] [c00000000026834c] do_try_to_free_pages+0x1dc/0x520 [c000000f0160b450] [c00000000026876c] try_to_free_pages+0xdc/0x250 [c000000f0160b4e0] [c000000000251978] __alloc_pages_nodemask+0x868/0x10d0 [c000000f0160b6f0] [c000000000567030] blk_mq_init_rq_map+0x160/0x380 [c000000f0160b7a0] [c00000000056758c] blk_mq_map_swqueue+0x33c/0x360 [c000000f0160b820] [c000000000567904] blk_mq_queue_reinit+0x64/0xb0 [c000000f0160b850] [c00000000056a16c] blk_mq_queue_reinit_notify+0x19c/0x250 [c000000f0160b8a0] [c0000000000f5d38] notifier_call_chain+0x98/0x100 [c000000f0160b8f0] [c0000000000c5fb0] __cpu_notify+0x70/0xe0 [c000000f0160b930] [c0000000000c63c4] notify_prepare+0x44/0xb0 [c000000f0160b9b0] [c0000000000c52f4] cpuhp_invoke_callback+0x84/0x250 [c000000f0160ba10] [c0000000000c570c] cpuhp_up_callbacks+0x5c/0x120 [c000000f0160ba60] [c0000000000c7cb8] _cpu_up+0xf8/0x1d0 [c000000f0160bac0] [c0000000000c7eb0] do_cpu_up+0x120/0x150 [c000000f0160bb40] [c0000000006fe024] cpu_subsys_online+0x64/0xe0 [c000000f0160bb90] [c0000000006f5124] device_online+0xb4/0x120 [c000000f0160bbd0] [c0000000006f5244] online_store+0xb4/0xc0 [c000000f0160bc20] [c0000000006f0a68] dev_attr_store+0x68/0xa0 [c000000f0160bc60] [c0000000003ccc30] sysfs_kf_write+0x80/0xb0 [c000000f0160bca0] [c0000000003cbabc] kernfs_fop_write+0x17c/0x250 [c000000f0160bcf0] [c00000000030fe6c] __vfs_write+0x6c/0x1e0 [c000000f0160bd90] [c000000000311490] vfs_write+0xd0/0x270 [c000000f0160bde0] [c0000000003131fc] SyS_write+0x6c/0x110 [c000000f0160be30] [c000000000009204] system_call+0x38/0xec Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1624164 This is optional firmware. It had been added to xenial's linux-firmware but was removed due to regressions with some hardware. Since it's not required we can remove the MODULE_FIRMWARE statement to prevent missing firmware warnings when generating the initrd. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1662763 Properly stop the extra workqueue items and ensure that we resume cleanly. This is better than using igb_ptp_init and igb_ptp_stop since these functions destroy the PHC device, which will cause other problems if we do so. Since igb_ptp_reset now re-schedules the work-queue item we don't need an equivalent igb_ptp_resume in the resume workflow. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit 8646f7b4) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1662763 Make igb_ptp_stop take advantage of this new function to reduce code duplication. Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1661430 Commit a389fcfd ("Drivers: hv: vmbus: Fix signaling logic in hv_need_to_signal_on_read()") added the proper mb(), but removed the test "prev_write_sz < pending_sz" when making the signal decision. As a result, the guest can signal the host unnecessarily, and then the host can throttle the guest because the host thinks the guest is buggy or malicious; finally the user running stress test can perceive intermittent freeze of the guest. This patch brings back the test, and properly handles the in-place consumption APIs used by NetVSC (see get_next_pkt_raw(), put_pkt_raw() and commit_rd_index()). Fixes: a389fcfd ("Drivers: hv: vmbus: Fix signaling logic in hv_need_to_signal_on_read()") Signed-off-by:
Dexuan Cui <decui@microsoft.com> Reported-by:
Rolf Neugebauer <rolf.neugebauer@docker.com> Tested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from linux-next commit 433e19cf) Signed-off-by:
Marcelo Cerri <marcelo.cerri@canonical.com> Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1661430 Signal the host when we determine the host is to be signaled - on th read path. The currrent code determines the need to signal in the ringbuffer code and actually issues the signal elsewhere. This can result in the host viewing this interrupt as spurious since the host may also poll the channel. Make the necessary adjustments. Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1661430 Signal the host when we determine the host is to be signaled. The currrent code determines the need to signal in the ringbuffer code and actually issues the signal elsewhere. This can result in the host viewing this interrupt as spurious since the host may also poll the channel. Make the necessary adjustments. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1593293Signed-off-by:
-
John Johansen authored
The patch Fix no_new_privs blocking change_onexec when using stacked namespaces changed when the no_new_privs checks is processed so the test could be correctly applied in a stacked profile situation. However it changed the behavior of the error returned in complain mode, which will have both @error and @new set. Fix this by introducing a new var to indicate the no_new_privs condition instead of relying on error. While doing this allow the new label under no new privs to be audited, by having its reference put in the error path, instead of in the no_new_privs condition check. BugLink: http://bugs.launchpad.net/bugs/1661030 BugLink: http://bugs.launchpad.net/bugs/1648903Signed-off-by:
John Johansen <john.johansen@canonical.com> Acked-by:
Colin King <colin.king@canonical.com> Acked-by:
-
John Johansen authored
When an open file with cached permissions is checked for the flock permission. The cache check fails and falls through to no error instead of auditing, and returning an error. For the fall through to do a permission check, so it will audit the failed flock permission check. BugLink: http://bugs.launchpad.net/bugs/1658219Signed-off-by:
-
John Johansen authored
null profiles that don't have the same control flags as the parent behave in unexpected ways and can cause failures. BugLink: http://bugs.launchpad.net/bugs/1656121Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1660849Signed-off-by:
-
John Johansen authored
Push the no_new_privs logic into the per profile transition fns, so that the no_new_privs check can be done at the ns level instead of the aggregate stack level. BugLink: http://bugs.launchpad.net/bugs/1648143Signed-off-by:
-
John Johansen authored
There is a lock inversion that can result in a dead lock when profile replacements are racing with dir creation for a namespace in apparmorfs. BugLink: http://bugs.launchpad.net/bugs/1645037Signed-off-by:
-
John Johansen authored
apparmor is leaking pinfs refcoutn when inode setup fails. BugLink: http://bugs.launchpad.net/bugs/1660846Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1660845Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1660842Signed-off-by:
-
John Johansen authored
Bind mounts can oops when devname lookup fails because the devname is uninitialized and used in auditing the denial. BugLink: http://bugs.launchpad.net/bugs/1660840Signed-off-by:
-
John Johansen authored
When an fd is disallowed from being inherited during exec, instead of closed it is duped to a special apparmor/.null file. This prevents the fd from being reused by another file in case the application expects the original file on a give fd (eg stdin/stdout etc). This results in a denial message like [32375.561535] audit: type=1400 audit(1478825963.441:358): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-t_<var-lib-lxd>" profile="/sbin/dhclient" name="/dev/pts/1" pid=16795 comm="dhclient" requested_mask="wr" denied_mask="wr" fsuid=165536 ouid=165536 Further access to the fd is resultin in the rather useless denial message of [32375.566820] audit: type=1400 audit(1478825963.445:359): apparmor="DENIED" operation="file_perm" namespace="root//lxd-t_<var-lib-lxd>" profile="/sbin/dhclient" name="/apparmor/.null" pid=16795 comm="dhclient" requested_mask="w" denied_mask="w" fsuid=165536 ouid=0 since we have the original denial, the noisy and useless .null based denials can be skipped. BugLink: http://bugs.launchpad.net/bugs/1660836Signed-off-by:
-
John Johansen authored
When a new label is created, it is created with a proxy in a circular ref count that is broken by replacement. However if the label is not used it will never be replaced and the circular ref count will never be broken resulting in a leak. BugLink: http://bugs.launchpad.net/bugs/1660834Signed-off-by:
-
John Johansen authored
@new does not have a reference taken locally and should not have its reference put locally either. BugLink: http://bugs.launchpad.net/bugs/1660833Signed-off-by:
-
John Johansen authored
The reading of rawdata is subject to a replacement race when the rawdata is read in chunks smaller than the data size. For each read the profile proxy is rechecked for the newest profile; Which means if a profile is replaced between reads later chunks will contain data from the new version of the profile while the earlier reads will contain data from the previous version. This can result in data that is inconsistent and corrupt. Instead of rechecking for the current profile at each read. Get the current profile at the time of the open and use the rawdata of the profile for the lifetime that the file handle is open. BugLink: http://bugs.launchpad.net/bugs/1638996Signed-off-by:
-
John Johansen authored
When using nested namespaces policy within the nested namespace is trying to cross validate with policy outside of the namespace that is not visible to it. This results the access being denied and with no way to add a rule to policy that would allow it. The check should only be done again policy that is visible. BugLink: http://bugs.launchpad.net/bugs/1660832Signed-off-by:
-
Miklos Szeredi authored
BugLink: http://bugs.launchpad.net/bugs/1659417 The hash salting changes meant that we can no longer reuse the hash in the overlay dentry to look up the underlying dentry. Instead of lookup_hash(), use lookup_one_len_unlocked() and swith to mounter's creds (like we do for all other operations later in the series). Now the lookup_hash() export introduced in 4.6 by 3c9fe8cd ("vfs: add lookup_hash() helper") is unused and can possibly be removed; its usefulness negated by the hash salting and the idea that mounter's creds should be used on operations on underlying filesystems. Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Fixes: 8387ff25 ("vfs: make the string hashes salt the hash") (backported from commit c1b2cc1a) Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1659417 This reverts commit 30c0ff60 since the clone_cred() interface is no longer used. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1659417 There is no longer any need to raise additional capabilities in the mounter's credentials, so we can do away with the extra complexity of cloning the credentials and associated error handling. Replace that with the same interface which was later adopted upstream, ovl_override_creds(). Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1660634Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1663657Signed-off-by:
-
Toshi Kani authored
BugLink: http://bugs.launchpad.net/bugs/1663657 commit a96dfddb upstream. Reading a sysfs "memoryN/valid_zones" file leads to the following oops when the first page of a range is not backed by struct page. show_valid_zones() assumes that 'start_pfn' is always valid for page_zone(). BUG: unable to handle kernel paging request at ffffea017a000000 IP: show_valid_zones+0x6f/0x160 This issue may happen on x86-64 systems with 64GiB or more memory since their memory block size is bumped up to 2GiB. [1] An example of such systems is desribed below. 0x3240000000 is only aligned by 1GiB and this memory block starts from 0x3200000000, which is not backed by struct page. BIOS-e820: [mem 0x0000003240000000-0x000000603fffffff] usable Since test_pages_in_a_zone() already checks holes, fix this issue by extending this function to return 'valid_start' and 'valid_end' for a given range. show_valid_zones() then proceeds with the valid range. [1] 'Commit bdee237c ("x86: mm: Use 2GB memory block size on large-memory x86-64 systems")' Link: http://lkml.kernel.org/r/20170127222149.30893-3-toshi.kani@hpe.comSigned-off-by:
Toshi Kani <toshi.kani@hpe.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Zhang Zhen <zhenzhang.zhang@huawei.com> Cc: Reza Arbab <arbab@linux.vnet.ibm.com> Cc: David Rientjes <rientjes@google.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: <stable@vger.kernel.org> [4.4+] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1663657 commit aaaec6fc upstream. The recent commit which prevents double activation of interrupts unearthed interesting code in x86. The code (ab)uses irq_domain_activate_irq() to reconfigure an already activated interrupt. That trips over the prevention code now. Fix it by deactivating the interrupt before activating the new configuration. Fixes: 08d85f3e "irqdomain: Avoid activating interrupts more than once" Reported-and-tested-by:
Mike Galbraith <efault@gmx.de> Reported-and-tested-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311901580.3457@nanosSigned-off-by:
-
Bjørn Mork authored
BugLink: http://bugs.launchpad.net/bugs/1663657 commit 5d03a2fd upstream. Yet another laptop vendor rebranded Novatel E371. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Vincent Pelletier authored
BugLink: http://bugs.launchpad.net/bugs/1663657 commit 83e526f2 upstream. OS descriptor head, when flagged as provided, is accessed without checking if it fits in provided buffer. Verify length before access. Also, there are other places where buffer length it checked after accessing offsets which are potentially past the end. Check buffer length before as well to fail cleanly. Signed-off-by:
Vincent Pelletier <plr.vincent@gmail.com> Acked-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Lukáš Lalinský authored
BugLink: http://bugs.launchpad.net/bugs/1663657 commit d9b2997e upstream. Add a quirk for WORLDE easykey.25 MIDI keyboard (idVendor=0218, idProduct=0401). The device reports that it has config string descriptor at index 3, but when the system selects the configuration and tries to get the description, it returns a -EPROTO error, the communication restarts and this keeps repeating over and over again. Not requesting the string descriptor makes the device work correctly. Relevant info from Wireshark: [...] CONFIGURATION DESCRIPTOR bLength: 9 bDescriptorType: 0x02 (CONFIGURATION) wTotalLength: 101 bNumInterfaces: 2 bConfigurationValue: 1 iConfiguration: 3 Configuration bmAttributes: 0xc0 SELF-POWERED NO REMOTE-WAKEUP 1... .... = Must be 1: Must be 1 for USB 1.1 and higher .1.. .... = Self-Powered: This device is SELF-POWERED ..0. .... = Remote Wakeup: This device does NOT support remote wakeup bMaxPower: 50 (100mA) [...] 45 0.369104 host 2.38.0 USB 64 GET DESCRIPTOR Request STRING [...] URB setup bmRequestType: 0x80 1... .... = Direction: Device-to-host .00. .... = Type: Standard (0x00) ...0 0000 = Recipient: Device (0x00) bRequest: GET DESCRIPTOR (6) Descriptor Index: 0x03 bDescriptorType: 0x03 Language Id: English (United States) (0x0409) wLength: 255 46 0.369255 2.38.0 host USB 64 GET DESCRIPTOR Response STRING[Malformed Packet] [...] Frame 46: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0 USB URB [Source: 2.38.0] [Destination: host] URB id: 0xffff88021f62d480 URB type: URB_COMPLETE ('C') URB transfer type: URB_CONTROL (0x02) Endpoint: 0x80, Direction: IN Device: 38 URB bus id: 2 Device setup request: not relevant ('-') Data: present (0) URB sec: 1484896277 URB usec: 455031 URB status: Protocol error (-EPROTO) (-71) URB length [bytes]: 0 Data length [bytes]: 0 [Request in: 45] [Time from request: 0.000151000 seconds] Unused Setup Header Interval: 0 Start frame: 0 Copy of Transfer Flags: 0x00000200 Number of ISO descriptors: 0 [Malformed Packet: USB] [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)] [Malformed Packet (Exception occurred)] [Severity level: Error] [Group: Malformed] Signed-off-by:
Lukáš Lalinský <lukas@oxygene.sk> Signed-off-by:
-
Marcel J.E. Mol authored
BugLink: http://bugs.launchpad.net/bugs/1663657 commit d07830db upstream. Seems that ATEN serial-to-usb devices using pl2303 exist with different device ids. This patch adds a missing device ID so it is recognised by the driver. Signed-off-by:
Marcel J.E. Mol <marcel@mesa.nl> Signed-off-by:
-
Aleksander Morgado authored
BugLink: http://bugs.launchpad.net/bugs/1663657 commit 24d615a6 upstream. The Dell DW5570 is a re-branded Sierra Wireless MC8805 which will by default boot with vid 0x413c and pid 0x81a3. When triggered QDL download mode, the device switches to pid 0x81a6 and provides the standard TTY used for firmware upgrade. Signed-off-by:
Aleksander Morgado <aleksander@aleksander.es> Signed-off-by:
-
Radim Krčmář authored
BugLink: http://bugs.launchpad.net/bugs/1663657 commit 00c87e9a upstream. Saving unsupported state prevents migration when the new host does not support a XSAVE feature of the original host, even if the feature is not exposed to the guest. We've masked host features with guest-visible features before, with 4344ee98 ("KVM: x86: only copy XSAVE state for the supported features") and dropped it when implementing XSAVES. Do it again. Fixes: df1daba7 ("KVM: x86: support XSAVES usage in the host") Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
