Bug 868309

Summary:	KVM guest unable to reliably communicate with USB modem (MT9234ZBA-USB-CDC)
Product:	Red Hat Enterprise Linux 7	Reporter:	James B. Byrne <byrnejb>
Component:	qemu-kvm	Assignee:	Gerd Hoffmann <kraxel>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	areis, hdegoede, huding, juzhang, knoel, kraxel, mkenneth, rbalakri, rpacheco, virt-bugs, virt-maint, xfu
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-15 11:43:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description James B. Byrne 2012-10-19 13:28:06 UTC

Description of problem:
A guest vm can connect to, but not reliably communicate with, a MultiTech MT9234ZBA-USB-CDC modem that has been passed through the host to the guest using virt-manager -> add hardware => usb


Version-Release number of selected component (if applicable):
 qemu-kvm-0.12.1.2-2.295.el6_3.2.src.rpm
 virt-manager-0.9.0-14.el6.src.rpm


How reproducible:
Always


Steps to Reproduce:
1. Add USB modem to host. Verify connection from host with terminal emulator (picocom)
2. Add USB Modem to virtual guest and restart guest.
3. Verify connection from guest with terminal emulator (picocom)
4. USe wvdialconf to find modem
  

Actual results:

From guest connection to modem from picocom -b 115200 /dev/ttyACM0 causes modem TR to go high. However ATI command returns string of non-displayable characters similar to that encountered with a baud rate mismatch.

Wvdialconf can find modem but cannot communicate with it:

<pre>
Editing `/etc/wvdial.conf'.

Scanning your serial ports for a modem.

ttyS0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud
ttyS0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud
ttyS0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up.
Modem Port Scan<*1>: S1   S2   S3
WvModem<*1>: Cannot get information for serial port.
ttyACM0<*1>: ATQ0 V1 E1 -- OK
ttyACM0<*1>: ATQ0 V1 E1 Z -- OK
ttyACM0<*1>: ATQ0 V1 E1 S0=0 -- OK
ttyACM0<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK
ttyACM0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK
ttyACM0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK
ttyACM0<*1>: Modem Identifier: ATI -- Agere OCM V.92 MT9234ZBA-USB
Data/Fax Modem Version 1.02l
ttyACM0<*1>: Speed 4800: AT -- OK
ttyACM0<*1>: Speed 9600: AT -- OK
ttyACM0<*1>: Speed 19200: AT -- OK
ttyACM0<*1>: Speed 38400: AT -- OK
ttyACM0<*1>: Speed 57600: AT -- OK
ttyACM0<*1>: Speed 115200: AT -- OK
ttyACM0<*1>: Speed 230400: AT -- OK
ttyACM0<*1>: Speed 460800: AT -- Speed 460800: AT -- Speed 460800: AT
-- Max speed is 230400; that should be safe.
ttyACM0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- and failed too at
115200, giving up.

Sorry, no modem was detected!  Is it in use by another program?
Did you configure it properly with setserial?
</pre>

Expected results:
Should be able to communicate with modem via terminal emulator and issue AT commands.  Wvdialconf should be able to configure /etc/wvdial.conf/.

Additional info:

Comment 3 Ademar Reis 2012-10-22 13:01:58 UTC

Deferring to RHEL7 because this is a complex fix.

Comment 8 Gerd Hoffmann 2013-05-14 13:36:47 UTC

Any chance you can retest with upstream qemu 1.5 (-rc or final)?

Comment 9 James B. Byrne 2013-05-14 14:12:43 UTC

Where do I get the software and is it installed via yum/rpm?  If so then yes I can certainly modify at test KVM and test the modem.

Comment 10 Ronen Hod 2013-10-30 10:06:27 UTC

Hi James,

Thank you for taking the time to enter a bug report with us. We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to  guarantee the timeliness or suitability of a resolution.
 
If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain  it receives the proper attention and prioritization to assure a timely resolution. 
 
For information on how to contact the Red Hat production support team, please visit:
https://www.redhat.com/support/process/production/#howto

Comment 12 Hans de Goede 2013-10-30 13:06:55 UTC

This should really be retested with RHEL-7, there are a lot of fixes in RHEL-7 which could / should help.

Comment 13 James B. Byrne 2013-11-18 17:43:04 UTC

(In reply to Ronen Hod from comment #10)
> Hi James,
> 
> Thank you for taking the time to enter a bug report with us. We appreciate
> the feedback and look to use reports such as this to guide our efforts at
> improving our products. That being said, this bug tracking system is not a
> mechanism for requesting support, and we are not able to  guarantee the
> timeliness or suitability of a resolution.

I was not looking for support.  At the time I had access to a suitable modem and system to test any changes had I been given some precise guidance as to what software to test and where to obtain it.  That window of opportunity has now closed and I am unable to do so.

Comment 23 Gerd Hoffmann 2016-04-15 11:43:32 UTC

usb passthrough code has been put upside down (rewritten to use libusb) since this was reported.  So it's not clear at all whenever the issue is still present.

Given the original reporter can't test this any more and we don't own the
hardware in question I'm going to close this now.  Feel free to re-open if
there are new informations.