fails to handle a usb serial port with a specific vendorid

Bug #1180924 reported by Rostislav Devyatov
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
QEMU
Fix Released
Undecided
Unassigned

Bug Description

If I run qemu-system-i386 with arguments
-usb -usbdevice serial:vendorid=1221:pty
(this is what the documentation says about how I shoud add a usb device which has a serial port interface and which has a specific vendor id, I used the documentation located here:
http://qemu.weilnetz.de/qemu-doc.html
), it says
char device redirected to /dev/pts/<something> (label usbserial0)
qemu-system-i386: -usbdevice serial:vendorid=1221:pty: Property '.vendorid' not found
Aborted
and exits. Moreover, if I try to add such a device to a running machine by typing usb_add serial:vendorid=1221:pty in the machine's control terminal (to reach it, I press ctrl-alt-2), qemu also writes
char device redirected to /dev/pts/<something> (label usbserial0)
Aborted
to the terminal where I run it from and exits. To the quest OS this looks like a power failure which causes all the programs inside the virtual machine to lose their unsaved data.
I have tested this with qemu-1.5.0-rc2, actually, the issue occured in a similar way since 1.0.1, but did not occur in 0.11.1.
The issue is reproducible always, even if I don't specify any hard disk in the command line, i. e.
$ qemu-system-i386 -usb -usbdevice serial:vendorid=1221:pty
, so I believe it is guest OS -independent.

Revision history for this message
Gerd Hoffmann (kraxel-redhat) wrote : Re: [Qemu-devel] [Bug 1180924] [NEW] fails to handle a usb serial port with a specific vendorid

  Hi,

>> (this is what the documentation says about how I shoud add a usb device which has a serial port interface and which has a specific vendor id, I used the documentation located here:
>> http://qemu.weilnetz.de/qemu-doc.html
>> ), it says
>> char device redirected to /dev/pts/<something> (label usbserial0)
>> qemu-system-i386: -usbdevice serial:vendorid=1221:pty: Property '.vendorid' not found
>> Aborted
> [...]
>
> Regression; this definitely worked when I wrote docs/qdev-device-use.txt.

> Not a release blocker, since it regressed a long time ago (v0.12).

Guess the docs should be updated, unless someone can come up with a
reasonable use case for the vendorid + deviceid properties.

cheers,
  Gerd

Revision history for this message
Rostislav Devyatov (deviatov) wrote :

I think the ability to specify a different vendorid + deviceid can be useful. Suppose there is a USB device such that the specifications are open and officially published, but the driver is proprietary. (As far as I know, this is similar to the situation with ATI video cards, but they are not USB devices.) And I suspect that the driver is buggy (i. e. it does not send the data according to the specifications). I want to figure out where exactly it works incorrectly to submit a bug report to the developer of the driver. Or suppose I have a physical device, but it works a bit incorrectly. I want to figure out where exactly the problem is, in the driver or in the device. Since I am not sure that the device is OK, I don't want to write my own driver and interact with the device, maybe I will damage it even more. In both cases, I can emulate the device according to the specifications, install the driver in a guest system, and then see whether the driver sends correct data or where and when exactly the data are incorrect.

Anyway, I think it is more or less ok if qemu crashes right after it starts due to bad command line parameters (nevertherless, the functionality lost this way could be useful as I explained). But I think IT IS NOT OK WHEN A WORKING VM WITH PROGRAMS INSIDE CRASHES after user enters a bad command in the machine's control terminal, unless the user explicitly requests termination (e. g. enters the q command).

Revision history for this message
felix (felix.von.s) wrote :

Regressed in commit f29783f72ea77dfbd7ea0c993d62d253d4c4e023.

I've just run into this in a similar circumstance: trying to reverse-engineer a driver for a phone to which I can only connect via Bluetooth. No problem, I can just have it pretend to be a USB device. Except that I can't, because the driver won't recognise it.

Revision history for this message
Thomas Huth (th-huth) wrote :

The crash has now been fixed here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=aa612b364ecbe1dc
Please also note that the "-usbdevice serial" syntax is considered as deprecated nowadays - use "-device usb-serial" instead.

Changed in qemu:
status: New → Fix Committed
Thomas Huth (th-huth)
Changed in qemu:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.