<br>计算机爱好者<br>云计算<br>云存储<br>网络技术<br>非洲酋长<br>可爱的胖子<br>十年攻城狮

    818 R810 win10 usb3.0摄像头重定向失败

    [busuanzi]
    字数统计: 853字   |   阅读时长≈ 4分

    linux系统下

    KYLIN336

    cheese 2.0 工作正常
    cheese 3.0 无法正常打开

    自己写的cam 2.0 工作正常
    自己写的cam 3.0 工作正常

    windows10

    系统windows1909（专业版）(未安装guesttool)

    amcap 2.0 工作正常
    amcap 3.0 段时间卡死

    驱动版本
    UsbXhciCompantion.dll 10.0.18362.207
    USBXHCI.SYS 10.0.18362.1
    usbccgp.sys 10.0.18362.1
    ksthunk.sys 10.0.18362.1
    SecureUSBVideo.dll 10.0.18362.1
    usbvideo.sys 10.0.18362.1
    WdmCompantionFilter.sys 10.0.18362.1

    windows1709

    amcap 2.0 工作正常
    amcap 3.0 段时间卡死
    驱动版本
    USBXHCI.SYS 10.0.16299.15
    USBHUB3.SYS 10.0.16299.15
    usbccgp.sys 10.0.16299.15
    ksthunk.sys 10.0.16299.15
    usbvideo.sys 10.0.16299.15

    对比后排除驱动问题

    问题怀疑可能和那个HUB有关

    确认为不是

    确认为和qemu的xhci驱动代码有关

    合入qemu主代码仓库（https://gitlab.com/qemu-project/qemu ）4个xhci相关补丁后解决

    R810 使用3.0摄像头做重定向 问题修改

    • 问题 XHCI驱动问题，导致长时间播放会卡住
    • 任务 #58012 R810 使用3.0摄像头做重定向，插在3.0的口上，window10 打开amcap软件之后，过一会 软件就卡死，插2.0的口没有问题
    • 修改 合入开源社区4个关于XHCI问题的补丁
    • 自测 长时间运行3.0摄像头，不会卡住
    • 相关 usbredir有同一个问题的改动
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    commit a587c832a3f1d6d47dce93bda52c80cfa163e7cf
    Author: Yuri Benditovich <yuri.benditovich@janustech.com>
    Date:   Mon Jan 28 20:05:07 2019 +0000

        usb: XHCI shall not halt isochronous endpoints
        
        According to the XHCI spec (4.10.2) the controller
        never halts isochronous endpoints. This commit prevent
        stop of isochronous streaming when sporadic errors
        status received from backends.
        
        Signed-off-by: Yuri Benditovich <yuri.benditovich@janustech.com>
        Message-id: 20190128200444.5128-2-yuri.benditovich@janustech.com
        Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

    commit b4329d1a2a42d3c49ac4b76ec86b6c9db19ea1e9
    Author: Yuri Benditovich <yuri.benditovich@janustech.com>
    Date:   Mon Jan 28 20:05:09 2019 +0000

        usb: implement XHCI underrun/overrun events
        
        Implement underrun/overrun events of isochronous endpoints
        according to XHCI spec (4.10.3.1)
        Guest software restarts data streaming when receives these events.
        The XHCI reports these events using interrupter assigned
        to the slot (as these events do not have TRB), so current
        commit adds the field of assigned interrupter to the
        XHCISlot structure. Guest software assigns interrupter to the
        slot on 'Address Device' and 'Evaluate Context' commands.
        
        Signed-off-by: Yuri Benditovich <yuri.benditovich@janustech.com>
        Message-id: 20190128200444.5128-3-yuri.benditovich@janustech.com
        Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

    commit 7cb513aa34fe5639c71223f06b2b6c7934815317
    Author: Liam Merwick <liam.merwick@oracle.com>
    Date:   Wed Feb 6 13:36:50 2019 +0000

        xhci: check device is not NULL before calling usb_ep_get()
        
        Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
        Message-id: 1549460216-25808-4-git-send-email-liam.merwick@oracle.com
        Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

    commit 0a076730adf469918d5d1cfdf9d740c6928208a4
    Author: Longpeng <longpeng2@huawei.com>
    Date:   Tue Apr 30 14:21:41 2019 +0800

        usb/xhci: avoid trigger assertion if guest write wrong epid
        
        we found the following core in our environment:
        0  0x00007fc6b06c2237 in raise ()
        1  0x00007fc6b06c3928 in abort ()
        2  0x00007fc6b06bb056 in __assert_fail_base ()
        3  0x00007fc6b06bb102 in __assert_fail ()
        4  0x0000000000702e36 in xhci_kick_ep (...)
        5  0x000000000047897a in memory_region_write_accessor (...)
        6  0x000000000047767f in access_with_adjusted_size (...)
        7  0x000000000047944d in memory_region_dispatch_write (...)
        (mr=mr@entry=0x7fc6a0138df0, addr=addr@entry=156, data=1648892416,
        size=size@entry=4, attrs=attrs@entry=...)
        8  0x000000000042df17 in address_space_write_continue (...)
        10 0x000000000043084d in address_space_rw (...)
        11 0x000000000047451b in kvm_cpu_exec (cpu=cpu@entry=0x1ab11b0)
        12 0x000000000045dcf5 in qemu_kvm_cpu_thread_fn (arg=0x1ab11b0)
        13 0x0000000000870631 in qemu_thread_start (args=args@entry=0x1acfb50)
        14 0x00000000008959a7 in thread_entry_for_hotfix (pthread_cb=<optimized out>)
        15 0x00007fc6b0a60dd5 in start_thread ()
        16 0x00007fc6b078a59d in clone ()
        
        (gdb) f 5
        5  0x000000000047897a in memory_region_write_accessor (...)
        529         mr->ops->write(mr->opaque, addr, tmp, size);
        (gdb) p /x tmp
        $9 = 0x62481a00 <-- last byte 0x00 is @epid
        
        xhci_doorbell_write() already check the upper bound of @slotid an @epid,
        it also need to check the lower bound.
        
        Cc: Gonglei <arei.gonglei@huawei.com>
        Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
        Signed-off-by: Longpeng <longpeng2@huawei.com>
        Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
        Message-id: 1556605301-44112-1-git-send-email-longpeng2@huawei.com
        
        [ kraxel: fixed typo in subject line ]
        
        Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>