Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
We currently ship qemupciserial.inf on the virtio-win .iso, however there's also a qemupciserial.cat file which we _don't_ ship. It's unclear if that omission was intentional or just an oversight of the previous build system. I asked Vadim in private mail:
On 05/02/2015 04:10 AM, Vadim Rozenfeld wrote:>>>> > >> The qemupciserial thing seems strange... we _do_ ship the .inf but not the
>>>> > >> .cat file? What's the reason for that?
>>> > >
>>> > > It's a very special case. The short story is like this - MS provides in-box
>>> > > serial.sys driver, which can be used for an OEM provided serial (UART) devices.
>>> > > So, it's basically what qemupciserial.inf does - binding the standard MS-provided
>>> > > in-box driver to custom PCI based device, which is fully compatible with th
>>> > > on-board serial devices.
>>> > >
>> >
>> > Gotchya. What's the .cat file for then? Just curious
> Oops, we must be referencing two different qemupciserial.inf files. I
> am, by mistake, was looking into the old one, which is "Class=Ports",
> and for this one no cat file was needed, while you are asking about the
> new one "Class=MultiFunction". So please ignore everything I told you
> before regarding to qemupciserial.inf and qemupciserial.cat files.
> For this approach we still use in in-box serial.sys file, but in this
> case we use it in conjunction with with another one in-box multifunction
> driver. For the case .cat file is absolutely necessary and should be
> distributed together with qemupciserial.inf file.
So we should distribute the .cat file as well
Hi,
After installing the virtio-win rpm package, qemupciserial.cat file are in iso.
version: virtio-win-1.9.1-0.el7.noarch.rpm
change status to verified.
Thanks
Yu Wang
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/RHBA-2017:2341
We currently ship qemupciserial.inf on the virtio-win .iso, however there's also a qemupciserial.cat file which we _don't_ ship. It's unclear if that omission was intentional or just an oversight of the previous build system. I asked Vadim in private mail: On 05/02/2015 04:10 AM, Vadim Rozenfeld wrote:>>>> > >> The qemupciserial thing seems strange... we _do_ ship the .inf but not the >>>> > >> .cat file? What's the reason for that? >>> > > >>> > > It's a very special case. The short story is like this - MS provides in-box >>> > > serial.sys driver, which can be used for an OEM provided serial (UART) devices. >>> > > So, it's basically what qemupciserial.inf does - binding the standard MS-provided >>> > > in-box driver to custom PCI based device, which is fully compatible with th >>> > > on-board serial devices. >>> > > >> > >> > Gotchya. What's the .cat file for then? Just curious > Oops, we must be referencing two different qemupciserial.inf files. I > am, by mistake, was looking into the old one, which is "Class=Ports", > and for this one no cat file was needed, while you are asking about the > new one "Class=MultiFunction". So please ignore everything I told you > before regarding to qemupciserial.inf and qemupciserial.cat files. > For this approach we still use in in-box serial.sys file, but in this > case we use it in conjunction with with another one in-box multifunction > driver. For the case .cat file is absolutely necessary and should be > distributed together with qemupciserial.inf file. So we should distribute the .cat file as well