From: Platform Team regression test user <citrix-osstest@xenproject.org>
To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org
Subject: [ovmf baseline-only test] 75205: trouble: blocked/broken
Date: Wed, 12 Sep 2018 15:39:37 +0100 [thread overview]
Message-ID: <osstest-75205-mainreport@xen.org> (raw)
This run is configured for baseline tests only.
flight 75205 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75205/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm <job status> broken
build-i386 <job status> broken
build-amd64-pvops <job status> broken
build-i386-xsm <job status> broken
build-amd64 <job status> broken
build-i386-pvops <job status> broken
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
build-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
build-i386-libvirt 1 build-check(1) blocked n/a
build-i386 4 host-install(4) broken baseline untested
build-i386-pvops 4 host-install(4) broken baseline untested
build-i386-xsm 4 host-install(4) broken baseline untested
build-amd64-xsm 4 host-install(4) broken baseline untested
build-amd64-pvops 4 host-install(4) broken baseline untested
build-amd64 4 host-install(4) broken baseline untested
version targeted for testing:
ovmf 5c9ac43f47865bb9b13608fd7ae1d39ab73ef397
baseline version:
ovmf 1ad635b283812283e8db457ba4809d5d38433f17
Last test of basis 75200 2018-09-11 15:50:18 Z 0 days
Testing same since 75205 2018-09-12 08:20:22 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Ruiyu Ni <ruiyu.ni@intel.com>
jobs:
build-amd64-xsm broken
build-i386-xsm broken
build-amd64 broken
build-i386 broken
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvops broken
build-i386-pvops broken
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images
Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
broken-job build-amd64-xsm broken
broken-job build-i386 broken
broken-job build-amd64-pvops broken
broken-job build-i386-xsm broken
broken-job build-amd64 broken
broken-job build-i386-pvops broken
broken-step build-i386 host-install(4)
broken-step build-i386-pvops host-install(4)
broken-step build-i386-xsm host-install(4)
broken-step build-amd64-xsm host-install(4)
broken-step build-amd64-pvops host-install(4)
broken-step build-amd64 host-install(4)
Push not applicable.
------------------------------------------------------------
commit 5c9ac43f47865bb9b13608fd7ae1d39ab73ef397
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date: Wed Apr 11 11:37:08 2018 +0800
MdeModulePkg/ConPlatform: Support short-form USB device path
Today's implementation does an exact device path match to check
whether the device path of a console is in ConIn/ConOut/ErrOut.
But that doesn't work for the USB keyboard.
Because when a platform have multiple USB port, ConIn needs to
carry all device paths corresponding to each port.
Even worse, today's BDS core logic removes the device path from
ConIn/ConOut/ErrOut when the connection to that device path fails.
So if user switches the USB keyboard from one port to another across
boot, the USB keyboard doesn't work in the second boot.
ConPlatform driver solved this problem by adding the
IsHotPlugDevice() function. So that for USB keyboard, ConPlatform
doesn't care whether its device path is in ConIn or not.
But the rule is too loose, and now causes platform BDS cannot control
whether to enable USB keyboard as an active console.
The patch changes ConPlatform to support USB short-form device path
when checking whether the device path of a console is in
ConIn/ConOut/ErrOut.
The logic to always accept USB/PCCARD device as active console is
removed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
reply other threads:[~2018-09-12 14:39 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=osstest-75205-mainreport@xen.org \
--to=citrix-osstest@xenproject.org \
--cc=osstest-admin@xenproject.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).