1046612 – qemu should quit with friendly prompt when use usb3.0 stick + uhci controller

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1046612 - qemu should quit with friendly prompt when use usb3.0 stick + uhci controller

Summary: qemu should quit with friendly prompt when use usb3.0 stick + uhci controller

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	qemu-kvm-rhev
Sub Component:
Version:	7.0
Hardware:	Unspecified
OS:	Unspecified
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Gerd Hoffmann
QA Contact:	Xujun Ma
Docs Contact:
URL:
Whiteboard:
Depends On:	1055093
Blocks:	1103193 1146460 1146483 1146486
TreeView+	depends on / blocked

Reported:	2013-12-26 10:19 UTC by Sibiao Luo
Modified:	2017-08-02 03:22 UTC (History)
CC List:	18 users (show)
Fixed In Version:	qemu-2.5.0
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Clones:	1146460 (view as bug list)
Environment:
Last Closed:	2017-08-01 23:27:12 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2017:2392	0	normal	SHIPPED_LIVE	Important: qemu-kvm-rhev security, bug fix, and enhancement update	2017-08-01 20:04:36 UTC

Description Sibiao Luo 2013-12-26 10:19:51 UTC

Description of problem:
Insert a usb3.0 stick to host from the original interface port(2.0) and then boot guest with this stich passthrough to guest using uhci controller. it boot up successfully but cann't work. The 3.0 usb stick must be passed through using ehci (or xhci). So qemu should quit with friendly prompt, like "Warning: speed mismatch...".
BTW, if insert usb3.0 stick to host from the PCI-E 2xUSB3.0 expansion card port(3.0), and then do the same test that qemu will give a speed mismatch warning and the stick cann't work in guest correctly.
qemu) c
Warning: speed mismatch trying to attach usb device "" (super speed) to bus "usb-bus.0", port "2.1" (full speed)
(qemu) 
(qemu) qemu-kvm: Warning: speed mismatch trying to attach usb device "" (super speed) to bus "usb-bus.0", port "2.1" (full speed)

Version-Release number of selected component (if applicable):
host info:
# uname -r && rpm -q qemu-kvm
3.10.0-64.el7.x86_64
qemu-kvm-1.5.3-30.el7.x86_64
guest info:
3.10.0-64.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.insert a usb3.0 stick to host from the original interface.
2.boot guest with this stich passthrough to guest using uhci controller.
e.g:# /usr/libexec/qemu-kvm -M pc....-usb -device usb-host,hostbus=1,hostaddr=5,id=usb-stick
(qemu) info usb
  Device 0.1, Port 1, Speed 12 Mb/s, Product QEMU USB Tablet
  Device 0.2, Port 2, Speed 12 Mb/s, Product QEMU USB Hub
  Device 0.3, Port 2.1, Speed 480 Mb/s, Product 
(qemu) info qtree
...
      dev: piix3-usb-uhci, id ""
        masterbus = <null>
        firstport = 0
        bandwidth = 1280
        maxframes = 128
        addr = 01.2
        romfile = <null>
        rombar = 1
        multifunction = off
        command_serr_enable = on
        class USB controller, addr 00:01.2, pci id 8086:7020 (sub 1af4:1100)
        bar 4: i/o at 0xc040 [0xc05f]
...
          dev: usb-host, id "usb-stick"
            hostbus = 1
            hostaddr = 5
            hostport = <null>
            vendorid = 0x0
            productid = 0x0
            isobufs = 4
            isobsize = 32
            bootindex = -1
            loglevel = 2
            pipeline = on
            port = <null>
            serial = <null>
            full-path = on
            addr 0.3, port 2.1, speed 480, name , attached
...

Actual results:
after step 2, the guest boot up successfully without any speed mismatch warning,  but the stick cann't work in guest.

Expected results:
it's better that qemu should quit with friendly prompt, like "Warning: speed mismatch...".

Additional info:
# /usr/libexec/qemu-kvm -M pc -S -cpu SandyBridge,hv_spinlocks=0x1fff,hv_relaxed,hv_vapic -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -no-kvm-pit-reinjection -usb -device usb-tablet,id=input0 -name sluo -uuid 990ea161-6b67-47b2-b803-19fb01d30d30 -rtc base=localtime,clock=host,driftfix=slew -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0,bus=pci.0,addr=0x3 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port2 -drive file=/home/en_windows_server_2012_r2_x64.raw,if=none,id=drive-virtio-disk,format=raw,cache=none,aio=native,werror=stop,rerror=stop -device virtio-blk-pci,vectors=0,bus=pci.0,addr=0x4,scsi=off,drive=drive-virtio-disk,id=virtio-disk,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=00:01:02:03:04:05,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=ballooning,bus=pci.0,addr=0x6 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -k en-us -boot menu=on -qmp tcp:0:4444,server,nowait -vnc :1 -spice disable-ticketing,port=5931 -vga qxl -monitor stdio -device usb-host,hostbus=1,hostaddr=5,id=usb-stick

Comment 1 Gerd Hoffmann 2014-01-15 16:11:31 UTC

I guess this implies usb_host_full_speed_compat() needs some refinements ...
Hans, any ideas?

Comment 2 Hans de Goede 2014-01-15 16:18:16 UTC

Sibiao, can you please attach lsusb -v output for the usb-stick in question both when plugged into a usb-2 port, as well as when plugged into a usb-3 port?

Comment 3 Sibiao Luo 2014-01-16 02:29:32 UTC

(In reply to Hans de Goede from comment #2)
> Sibiao, can you please attach lsusb -v output for the usb-stick in question
> both when plugged into a usb-2 port, as well as when plugged into a usb-3
> port?
My USB3.0 stick plugged into a usb-3 port info:
# lsusb | grep CompUSA
Bus 004 Device 002: ID 1516:6221 CompUSA 
# lsusb -v
...

Bus 004 Device 002: ID 1516:6221 CompUSA 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x1516 CompUSA
  idProduct          0x6221 
  bcdDevice            1.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 ���
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           44
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               3
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               3
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        2047 micro seconds
Device Status:     0x0000
  (Bus Powered)

---------------------------------------------------------------------------

My USB3.0 stick plugged into a usb-2 port info:
# lsusb | grep CompUSA
Bus 001 Device 005: ID 1516:6221 CompUSA 
# lsusb -v
...

Bus 001 Device 005: ID 1516:6221 CompUSA 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1516 CompUSA
  idProduct          0x6221 
  bcdDevice            1.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 ���
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        2047 micro seconds
Device Status:     0x0000
  (Bus Powered)

Comment 4 Hans de Goede 2014-01-16 11:04:53 UTC

I just tested 2 similar sticks with usbredir + a Linux guest and it works fine.

Sibiao, what os are you using as guest? If windows can you please retest with a Linux guest?

And if a Linux guest also does not work, can you please re-test with Spice's usbredir instead of using usb-host ?

Comment 5 Sibiao Luo 2014-01-17 05:20:11 UTC

(In reply to Hans de Goede from comment #4)
> I just tested 2 similar sticks with usbredir + a Linux guest and it works
> fine.
Right, passthrough the usb via usbredir did not hit this issue(I just test the rhel7 guest), all of them can work well without any qemu warning message. I will send a email to you for discus the speed problem.
> Sibiao, what os are you using as guest? If windows can you please retest
> with a Linux guest?
The rhel guest and windows guest has little different when the USB3.0 stick inserted from the original interface port(2.0): the usb stick work well in rhel guest but cann't work in windows guest.

I test the passthrough from usb-host with rhel7.0 guest: 
1.Passthrough from usb-host: USB3.0 stick + original interface port(2.0) + uhci controller --------> the usb stick work well in guest without any warning message, 480 Mb/s
-usb -device usb-host,hostbus=1,hostaddr=7,id=usb-stick
Warning: option deprecated, use lost_tick_policy property of kvm-pit instead.
QEMU 1.5.3 monitor - type 'help' for more information
(qemu) 
(qemu) c
(qemu) 
(qemu) info usb
  Device 0.1, Port 1, Speed 480 Mb/s, Product 

2.Passthrough from usb-host: USB3.0 stick + PCI-E 2xUSB3.0 expansion card port(3.0) + uhci controller --------> fail to work in guest and qemu gave warning message.
-usb -device usb-host,hostbus=4,hostaddr=3,id=usb-stick
Warning: option deprecated, use lost_tick_policy property of kvm-pit instead.
QEMU 1.5.3 monitor - type 'help' for more information
(qemu) c
Warning: speed mismatch trying to attach usb device "" (super speed) to bus "usb-bus.0", port "1" (full speed)
(qemu) info usbqemu-kvm: Warning: speed mismatch trying to attach usb device "" (super speed) to bus "usb-bus.0", port "1" (full speed)

  Device 0.0, Port 1, Speed 5000 Mb/s, Product 
(qemu) qemu-kvm: Warning: speed mismatch trying to attach usb device "" (super speed) to bus "usb-bus.0", port "1" (full speed)

(qemu) info usb
  Device 0.0, Port 1, Speed 5000 Mb/s, Product 

> And if a Linux guest also does not work, can you please re-test with Spice's
> usbredir instead of using usb-host ?

Comment 6 Gerd Hoffmann 2014-01-17 13:34:21 UTC

usb_host_full_speed_compat() is only called for usb 2.0 devices, not for usb 3.0 devices.  The actual speed the device is running on counts, i.e. for usb3 sticks plugged into a usb2 port (therefore running at usb2 highspeed) the compat check is done, for usb3 sticks plugged into usb3 port the check is not done.

So, that explains why comment #5 test #2 errors out.

Comment #5 test #1 showing different results on windows vs. linux guests indicates that windows is more strict in parameter checking and refuses to accept the usb2/3 device on a usb1 port.

/me thinks it is time to simply drop usb_host_full_speed_compat().  ehci emulation is stable and supported through the full stack these days, and you should better use ehci anyway for performance reasons.  Hans, what do you think?

Comment 7 Hans de Goede 2014-01-18 16:32:07 UTC

Hi,

(In reply to Gerd Hoffmann from comment #6)
> usb_host_full_speed_compat() is only called for usb 2.0 devices, not for usb
> 3.0 devices.  The actual speed the device is running on counts, i.e. for
> usb3 sticks plugged into a usb2 port (therefore running at usb2 highspeed)
> the compat check is done, for usb3 sticks plugged into usb3 port the check
> is not done.
> 
> So, that explains why comment #5 test #2 errors out.
> 
> Comment #5 test #1 showing different results on windows vs. linux guests
> indicates that windows is more strict in parameter checking and refuses to
> accept the usb2/3 device on a usb1 port.
> 
> /me thinks it is time to simply drop usb_host_full_speed_compat().  ehci
> emulation is stable and supported through the full stack these days, and you
> should better use ehci anyway for performance reasons.  Hans, what do you
> think?

I tend to agree. It was only ever introduced to avoid regressions for people using usb (host or net) redir with usb-2 devices while not using the new ehci emulation, because otherwise their use-case would regress. I guess some people may still be using such a config, but it is time for them to move on now. So I'm fine with dropping the check.

Comment 8 Hans de Goede 2014-01-18 19:15:05 UTC

(In reply to Hans de Goede from comment #7)
> > /me thinks it is time to simply drop usb_host_full_speed_compat().  ehci
> > emulation is stable and supported through the full stack these days, and you
> > should better use ehci anyway for performance reasons.  Hans, what do you
> > think?
> 
> I tend to agree. It was only ever introduced to avoid regressions for people
> using usb (host or net) redir with usb-2 devices while not using the new
> ehci emulation, because otherwise their use-case would regress. I guess some
> people may still be using such a config, but it is time for them to move on
> now. So I'm fine with dropping the check.

Hmm, if we do this we should make similar changes to usbredir.c which does similar checks. Note I've just filed a related RFE for qemu, based on a mail from Sibiao. usbredir does something similar to usb_host_full_speed_compat() not only for redirecting usb-2 speed devices to uhci, but also for usb-3 speed devices to ehci. Although the former is something which is probably better dealt with by telling users to just configure there vms with ehci support, I believe the latter will still make sense for a while, ie when running older guest os-es which don't support xhci. See bug 1055093.

Comment 10 Gerd Hoffmann 2014-07-03 08:51:38 UTC

see: upstream commit b88a3e01f5718d5da538bfe072cc8452107badca
[ reworks port speed compatibility checks ]

Comment 11 Gerd Hoffmann 2014-07-04 11:39:46 UTC

Please retest with this test build:
http://people.redhat.com/ghoffman/bz1103193/

Comment 17 Gerd Hoffmann 2016-04-19 11:44:41 UTC

Doesn't reproduce locally, please reset with latest qemu 2.5 builds.

Comment 18 juzhang 2016-04-19 13:02:49 UTC

Hi Jing,

Could you reply comment17?

Best Regards,
Junyi

Comment 25 Xujun Ma 2016-09-12 08:00:22 UTC

Reproduced the issue on old version:

Version-Release number of selected component (if applicable):
qemu-kvm-1.5.3-30.el7.x86_64
host:kernel-3.10.0-64.el7.x86_64
guest:kernel-3.10.0-64.el7.x86_64

Steps to Reproduce:
1.plug usb usb3.0 stick to usb2.0 port then boot up guest with commands:
/usr/libexec/qemu-kvm \
 -name guest \
 -m 4096 \
 -smp 1 \
 -monitor stdio \
 -vnc 0:58 \
 -qmp tcp:0:9998,server,nowait \
 -device virtio-scsi-pci,bus=pci.0,id=x \
 -device scsi-hd,drive=b,id=cc \
 -device ich9-usb-uhci6,id=uhci \
 -device usb-host,hostbus=3,hostaddr=3,id=ksks,bus=uhci.0 \
 -drive file=RHEL-Server-7.3-64-virtio.qcow2,if=none,id=b,format=qcow2,cache=none \
 -device virtio-net-pci,netdev=net0,id=nic0,mac=52:54:00:c4:e7:86 \
 -netdev tap,id=net0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,vhost=on \
2.check if usb stick can work in guest 
#lsusb


3.plug usb usb3.0 stick to usb3.0 port then boot up guest with commands:
/usr/libexec/qemu-kvm \
 -name guest \
 -m 4096 \
 -smp 1 \
 -monitor stdio \
 -vnc 0:58 \
 -qmp tcp:0:9998,server,nowait \
 -device virtio-scsi-pci,bus=pci.0,id=x \
 -device scsi-hd,drive=b,id=cc \
 -device ich9-usb-uhci6,id=uhci \
 -device usb-host,hostbus=3,hostaddr=3,id=ksks,bus=uhci.0 \
 -drive file=RHEL-Server-7.3-64-virtio.qcow2,if=none,id=b,format=qcow2,cache=none \
 -device virtio-net-pci,netdev=net0,id=nic0,mac=52:54:00:c4:e7:86 \
 -netdev tap,id=net0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,vhost=on \

4.check if usb stick can work in guest 
#lsusb

Actual results:
No any warning information and usb3.0 stick can work in guest when plugging to usb2.0 port.

Have speed mismatch warning and usb3.0 stick can't work in guest when plugging to usb3.0 port.



Verified the issue on the latest build:
Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.6.0-24.el7.x86_64
host：kernel-3.10.0-492.el7.x86_64
guest:kernel-3.10.0-492.el7.x86_64


Steps to Verify:
The same steps as above

Actual results:
No any warning information and usb stick can work in guest when plugging to usb2.0 port or usb 3.0 port.


Hi Gerd
I can't reproduce that usb 3.0 stick cant't work when plug it to usb2.0 port.
I would like to know if we can ignore it and change status to verified or tell me how to do it.

Comment 26 Gerd Hoffmann 2016-09-12 10:14:19 UTC

Please retest once bug 1055093 is fixed.

Comment 30 Xujun Ma 2016-09-23 06:01:38 UTC

I think it's necessary to explain the test result about comment 25.I don't know why,sometimes,the usb3.0 stick was identified as usb2.0 deivce when plugging to usb3.0 port.I retest when confirming it was identified as usb3.0 deivce when plugging to usb3.0 port.The test actual results is :Have speed mismatch warning and usb3.0 stick can't found in the guest.So the bug hasn't been fixed yet.So please ignore the verified results in comment 25.

Comment 34 errata-xmlrpc 2017-08-01 23:27:12 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 35 errata-xmlrpc 2017-08-02 01:04:50 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 36 errata-xmlrpc 2017-08-02 01:56:50 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 37 errata-xmlrpc 2017-08-02 02:37:35 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 38 errata-xmlrpc 2017-08-02 03:02:18 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 39 errata-xmlrpc 2017-08-02 03:22:27 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Note You need to log in before you can comment on or make changes to this bug.