* [ovmf baseline-only test] 75437: trouble: blocked/broken
@ 2018-10-17 10:57 Platform Team regression test user
0 siblings, 0 replies; only message in thread
From: Platform Team regression test user @ 2018-10-17 10:57 UTC (permalink / raw)
To: xen-devel, osstest-admin
This run is configured for baseline tests only.
flight 75437 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75437/
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-amd64 4 host-install(4) broken baseline untested
build-i386 4 host-install(4) broken baseline untested
build-i386-pvops 4 host-install(4) broken baseline untested
build-amd64-xsm 4 host-install(4) broken baseline untested
build-i386-xsm 4 host-install(4) broken baseline untested
build-amd64-pvops 4 host-install(4) broken baseline untested
version targeted for testing:
ovmf 25d310d9b6187ca2e770b0b959831416441ce271
baseline version:
ovmf 6d665168b0b630924a8d535316d053723998d658
Last test of basis 75433 2018-10-16 16:20:32 Z 0 days
Testing same since 75437 2018-10-17 06:20:33 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Hao Wu <hao.a.wu@intel.com>
Ruiyu Ni <ruiyu.ni@intel.com>
Wonkyu Kim <wonkyu.kim@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-amd64 host-install(4)
broken-step build-i386 host-install(4)
broken-step build-i386-pvops host-install(4)
broken-step build-amd64-xsm host-install(4)
broken-step build-i386-xsm host-install(4)
broken-step build-amd64-pvops host-install(4)
Push not applicable.
------------------------------------------------------------
commit 25d310d9b6187ca2e770b0b959831416441ce271
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date: Tue Oct 16 12:40:13 2018 +0800
MdeModulePkg/UsbMass: Reject device whose block size is 0 or > 64K
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit 8894c90d745109c4aea3998c09a8f2b1f10a6d04
Author: Hao Wu <hao.a.wu@intel.com>
Date: Thu Sep 20 13:48:02 2018 +0800
MdeModulePkg/Bus/Ufs: Ensure device not return more data than expected
This commit adds checks to make sure the UFS devices do not return more
data than the driver expected.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit b2252bab12deeb0f5981cf390dc6499d1689b4a2
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date: Mon Sep 17 16:05:26 2018 +0800
MdeModulePkg/UsbBus: Deny when the string descriptor length is odd
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit 6c46cbbd5e3e2db7f14c007482e062b90c73c70f
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date: Thu Sep 13 16:09:10 2018 +0800
MdeModulePkg/UsbMouse: Don't access key codes when length is wrong
Per USB HID spec, the buffer holding key codes should at least 3-byte
long.
Today's code assumes that the key codes buffer length is longer than
3-byte and unconditionally accesses the key codes buffer.
It's incorrect.
The patch fixes the issue by returning Device Error when the
length is less than 3-byte.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit 0dd6065520742f62678db9dd6728f22b2abd68e2
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date: Thu Sep 13 16:06:52 2018 +0800
MdeModulePkg/AbsPointer: Don't access key codes when length is wrong
Per USB HID spec, the buffer holding key codes should at least 3-byte
long.
Today's code assumes that the key codes buffer length is longer than
3-byte and unconditionally accesses the key codes buffer.
It's incorrect.
The patch fixes the issue by returning Device Error when the
length is less than 3-byte.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit 8bcbe587e794aaaa6506b647732316ce5ba40168
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date: Thu Sep 13 15:49:23 2018 +0800
MdeModulePkg/UsbKb: Don't access key codes when length is wrong
Per USB HID spec, the buffer holding key codes should be 8-byte
long.
Today's code assumes that the key codes buffer length is 8-byte
long and unconditionally accesses the key codes buffer.
It's incorrect.
The patch fixes the issue by returning Device Error when the
length is less than 8-byte.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit 4d2b5066317d3e16dc8041a3e62d3bfe1c90bb02
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date: Thu Aug 2 15:48:52 2018 +0800
SourceLevelDebugPkg/Usb3: Make sure data from HW can fit in buffer
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>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit 7fb7259fc0ef9dc25fc17f437658562f0d6f9595
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date: Thu Aug 2 09:57:17 2018 +0800
MdeModulePkg/Usb: Make sure data from HW is no more than expected
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit 70c3c2370a2aefe71cf0f6c1a1e063f7d74e1d79
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date: Thu Sep 27 16:36:05 2018 +0800
MdeModulePkg/UsbBus: Reject descriptor whose length is bad
Today's implementation doesn't check whether the length of
descriptor is valid before using it.
The patch fixes this issue.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit 4c034bf62cbc1f3c5f4b5df25de97f0f528132b2
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date: Thu Sep 27 16:34:36 2018 +0800
MdeModulePkg/UsbBus: Fix out-of-bound read access to descriptors
Today's implementation reads the Type/Length field in the USB
descriptors data without checking whether the offset to read is
beyond the data boundary.
The patch fixes this issue.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit 4f8b2f9d727d0035a2ca8d7371629418684bf80f
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date: Tue Sep 11 18:13:05 2018 +0800
MdeModulePkg/UsbMass: Fix integer overflow when BlockSize is 1
UsbBootReadWriteBlocks() and UsbBootReadWriteBlocks16() use a UINT16
local variable to hold the value of
USB_BOOT_MAX_CARRY_SIZE (=0x10000) / BlockSize.
When BlockSize is 1, the UINT16 local variable is set to 0x10000
but the high-16 bits are truncated resulting the final value be 0.
It causes the while-loop in the two functions accesses 0 block in
each loop, resulting the loop never ends.
The patch fixes the two functions to make sure no integer overflow
happens.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit e59db6a732dbbb064b1e39a288a25edc90adac5d
Author: Ruiyu Ni <ruiyu.ni@intel.com>
Date: Tue Sep 11 18:08:02 2018 +0800
MdeModulePkg/UsbMass: Merge UsbBoot(Read|Write)Blocks(16)
The change doesn't have functionality impact.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit 76d1c03cbd5e0ba683be460c2de2600bd3376e42
Author: Wonkyu Kim <wonkyu.kim@intel.com>
Date: Tue Oct 16 06:44:45 2018 +0800
CorebootPayloadPkg: don't use serial output for Release build
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Benjamin You <benjamin.you@intel.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2018-10-17 10:57 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-17 10:57 [ovmf baseline-only test] 75437: trouble: blocked/broken Platform Team regression test user
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.