[CentOS-virt] USB card reader causing qemu-kvm SEGV's

Fri Mar 17 08:06:22 UTC 2017
Sandro Bonazzola <sbonazzo at redhat.com>

Adding Paolo and Miroslav.

On Sun, Mar 12, 2017 at 11:41 PM, Philip Prindeville <
philipp_subx at redfish-solutions.com> wrote:

> Hi.
>
> I have a Supermicro 5018D-FN4T (Xeon D-1541 based SBC) that I use for
> virtualization.  I’m running Centos 7.3 on it (updated), with the
> CentOS-QEMU-EV.repo repository as the source for virtualization packages.
>
> I run an Ubuntu 16.04-2 guest VM on it, which is ordinary enough.  What’s
> perhaps less ordinary is that I’ve attached a Lexar Media, Inc. “Lexar
> Professional Workflow CR1 CFast 2.0 USB 3.0 Reader” (LRWCR1TBNA) as well as
> a WEme Superspeed Aluminum USB 3.0 Multi-in-1 Card Reader … for CF/SD/TF
> Micro SD.  Here’s the relevant lsusb output:
>
> Bus 004 Device 004: ID 0bda:0309 Realtek Semiconductor Corp.
> Bus 004 Device 025: ID 05dc:ba04 Lexar Media, Inc.
>
> and both are hanging off of an Amazon Basics 4-port USB 3.0 hub:
>
> Bus 004 Device 002: ID 2109:8110 VIA Labs, Inc. Hub
>
> The Ubuntu VM I use for doing buildroot cross builds of an embedded Linux
> environment, which I then burn the image of onto a CFast card, having
> attached the Lexar card reader to the guest VM.
>
> Problem is that the card reader is extremely dodgy, and sometimes I guess
> a flurry of messages on the virtualization host complaining about the
> device:
>
> Mar 11 15:52:46 kvm1 kernel: usb 4-2.2: Disable of device-initiated U1
> failed.
> Mar 11 15:52:46 kvm1 kernel: usb 4-2.2: Disable of device-initiated U2
> failed.
> Mar 11 15:52:46 kvm1 kernel: usb 4-2.2: Set SEL for device-initiated U1
> failed.
> Mar 11 15:52:46 kvm1 kernel: usb 4-2.2: Set SEL for device-initiated U2
> failed.
> Mar 11 15:52:47 kvm1 kernel: usb 4-2.2: reset SuperSpeed USB device number
> 25 using xhci_hcd
> Mar 11 15:52:47 kvm1 kernel: scsi host13: uas
> Mar 11 15:52:47 kvm1 kernel: scsi 13:0:0:0: Direct-Access     Lexar
> WorkflowCR1      0    PQ: 0 ANSI: 6
> Mar 11 15:52:47 kvm1 kernel: sd 13:0:0:0: [sda] 30198988 512-byte logical
> blocks: (15.4 GB/14.3 GiB)
> Mar 11 15:52:47 kvm1 kernel: sd 13:0:0:0: Attached scsi generic sg0 type 0
> Mar 11 15:52:47 kvm1 kernel: sd 13:0:0:0: [sda] Write Protect is off
> Mar 11 15:52:47 kvm1 kernel: sd 13:0:0:0: [sda] Write cache: disabled,
> read cache: enabled, doesn't support DPO or FUA
> Mar 11 15:52:47 kvm1 kernel: sda: sda1 sda2
> Mar 11 15:52:47 kvm1 kernel: sd 13:0:0:0: [sda] Attached SCSI removable
> disk
> Mar 11 15:52:48 kvm1 kernel: usb 4-2.2: usbfs: process 4354 (CPU 3/KVM)
> did not claim interface 0 before use
> Mar 11 15:52:48 kvm1 kernel: usb 4-2.2: usbfs: process 4354 (CPU 3/KVM)
> did not claim interface 0 before use
> Mar 11 15:53:21 kvm1 kernel: usb 4-2.2: usbfs: process 4355 (CPU 4/KVM)
> did not claim interface 0 before use
> Mar 11 15:53:21 kvm1 kernel: usb 4-2.2: reset SuperSpeed USB device number
> 25 using xhci_hcd
> Mar 11 15:53:21 kvm1 kernel: usb 4-2.2: reset SuperSpeed USB device number
> 25 using xhci_hcd
>
>
> but lately it just kills my VM when I’m writing to the device.  So from
> annoying to a serious potential for losing work.
>
> I run “yum update” a couple of times a week but now I’m thinking that was
> a mistake, since this has gone from being ultra-reliable to being a hazard.
>
> Is there a workaround?  Would I be better off plugging the USB 3.0
> card-reader into a USB 2.0 hub and settling for slower throughput… but not
> crashing?
>
> Below, for instance, I was doing a “dd if=xyzzy of=/dev/sda bs=1M” where
> /dev/sda is the device assigned to the USB card storage device.
>
> Thanks,
>
> -Philip
>
>
> URL for ABRT report:  https://da.gd/emJO
>
>
> _______________________________________________
> CentOS-virt mailing list
> CentOS-virt at centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
>



-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20170317/41939d27/attachment-0006.html>