<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openembedded-core.git/meta/lib/oeqa/runtime/parselogs.py, branch 2016-10</title>
<subtitle>Mirror of openembedded-core</subtitle>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/'/>
<entry>
<title>parselogs.py: Add disabling eDP error to x86_common whitelist</title>
<updated>2016-10-04T23:17:12+00:00</updated>
<author>
<name>California Sullivan</name>
<email>california.l.sullivan@intel.com</email>
</author>
<published>2016-09-30T23:40:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=4c3fb7f63aad4a5d1b9720c76091cd0646859c2a'/>
<id>4c3fb7f63aad4a5d1b9720c76091cd0646859c2a</id>
<content type='text'>
The NUC6 firmware tells the kernel to try and initialize an embedded
DisplayPort it does not have, causing this warning. Its harmless, so
just whitelist it.

Fixes [YOCTO #9434].

Signed-off-by: California Sullivan &lt;california.l.sullivan@intel.com&gt;
Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The NUC6 firmware tells the kernel to try and initialize an embedded
DisplayPort it does not have, causing this warning. Its harmless, so
just whitelist it.

Fixes [YOCTO #9434].

Signed-off-by: California Sullivan &lt;california.l.sullivan@intel.com&gt;
Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parselogs: Update uvesafb errors in qemu whitelist</title>
<updated>2016-09-28T23:32:58+00:00</updated>
<author>
<name>Jianxun Zhang</name>
<email>jianxun.zhang@linux.intel.com</email>
</author>
<published>2016-09-27T21:32:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=2e15b478343c6703c37b9a45e61c9de200d98027'/>
<id>2e15b478343c6703c37b9a45e61c9de200d98027</id>
<content type='text'>
This change only whitelists the timeout message in infinite
wait case in uvesafb driver.

With the latest timeout patch introducing infinite wait in
uvesafb driver, we whitelist the timeout message since it works
as a warning for issues related to timeout not to be fixed in
build servers.

We remove other errors for bug-discovering purposes in some cases
where these lines are still worthy to be caught (not whitelisted):

The removed errors show up again in the infinite wait case. It
indicates a different root cause or the timeout patch doesn't work
correctly.

Timeout happens when developers explicitly set a non-negative timeout
of a limited period to wait for task completion in uvesafb driver.

Timeout or/and errors occur when kernel doesn't have the latest
timeout patch in driver.

Note: The latest timeout patch is tracked by:
a2966330bcd29e99c0403235edb29433b0c53d56

[YOCTO #8245]

Signed-off-by: Jianxun Zhang &lt;jianxun.zhang@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This change only whitelists the timeout message in infinite
wait case in uvesafb driver.

With the latest timeout patch introducing infinite wait in
uvesafb driver, we whitelist the timeout message since it works
as a warning for issues related to timeout not to be fixed in
build servers.

We remove other errors for bug-discovering purposes in some cases
where these lines are still worthy to be caught (not whitelisted):

The removed errors show up again in the infinite wait case. It
indicates a different root cause or the timeout patch doesn't work
correctly.

Timeout happens when developers explicitly set a non-negative timeout
of a limited period to wait for task completion in uvesafb driver.

Timeout or/and errors occur when kernel doesn't have the latest
timeout patch in driver.

Note: The latest timeout patch is tracked by:
a2966330bcd29e99c0403235edb29433b0c53d56

[YOCTO #8245]

Signed-off-by: Jianxun Zhang &lt;jianxun.zhang@linux.intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parselogs.py: Add amd_nb error to x86_common whitelist</title>
<updated>2016-09-28T09:15:54+00:00</updated>
<author>
<name>California Sullivan</name>
<email>california.l.sullivan@intel.com</email>
</author>
<published>2016-09-23T18:15:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=9c432dae1045a087f8eb2de7c9bd3a9cbd46c459'/>
<id>9c432dae1045a087f8eb2de7c9bd3a9cbd46c459</id>
<content type='text'>
This has always silently failed on hardware without AMD Northbridge,
and a recent kernel patch made it not silent. It would be ideal to only
whitelist the error for genericx86 MACHINEs and disable the CONFIG
option that enables it in intel-* MACHINEs, but in order to disable
this configuration option we would have to enable EXPERT and
DEBUG_KERNEL, which we don't want. Instead just whitelist it on all
x86 MACHINEs.

Fixes [YOCTO #10261].

Signed-off-by: California Sullivan &lt;california.l.sullivan@intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This has always silently failed on hardware without AMD Northbridge,
and a recent kernel patch made it not silent. It would be ideal to only
whitelist the error for genericx86 MACHINEs and disable the CONFIG
option that enables it in intel-* MACHINEs, but in order to disable
this configuration option we would have to enable EXPERT and
DEBUG_KERNEL, which we don't want. Instead just whitelist it on all
x86 MACHINEs.

Fixes [YOCTO #10261].

Signed-off-by: California Sullivan &lt;california.l.sullivan@intel.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>oeqa/runtime/parselogs.py: Add ignore of tsc calibration fail in x86</title>
<updated>2016-09-20T14:10:37+00:00</updated>
<author>
<name>Aníbal Limón</name>
<email>anibal.limon@linux.intel.com</email>
</author>
<published>2016-09-19T16:50:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=2271f59a0f506f89f9fea6777701c4b40790ddd9'/>
<id>2271f59a0f506f89f9fea6777701c4b40790ddd9</id>
<content type='text'>
We are experimenting failures to calibrate CPU's using TSC in x86
VM's due to usage of nested KVM [1], this is a known issue [2][3]
in virtualization environments, for detail explnation see [4].

Also we already have an ignore for 'TSC Fast calibration fail'.

[1] http://errors.yoctoproject.org/Errors/Details/83684/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=814231
[3] https://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg01547.html
[4] https://www.kernel.org/doc/Documentation/virtual/kvm/timekeeping.txt

Signed-off-by: Aníbal Limón &lt;anibal.limon@linux.intel.com&gt;
Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We are experimenting failures to calibrate CPU's using TSC in x86
VM's due to usage of nested KVM [1], this is a known issue [2][3]
in virtualization environments, for detail explnation see [4].

Also we already have an ignore for 'TSC Fast calibration fail'.

[1] http://errors.yoctoproject.org/Errors/Details/83684/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=814231
[3] https://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg01547.html
[4] https://www.kernel.org/doc/Documentation/virtual/kvm/timekeeping.txt

Signed-off-by: Aníbal Limón &lt;anibal.limon@linux.intel.com&gt;
Signed-off-by: Ross Burton &lt;ross.burton@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>oeqa/parselogs: Don't use cwd for file transfers</title>
<updated>2016-09-09T12:21:18+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2016-09-09T12:19:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=ac8f1e58ca3a0945795087cad9443be3e3e6ead8'/>
<id>ac8f1e58ca3a0945795087cad9443be3e3e6ead8</id>
<content type='text'>
If you run:

MACHINE=A bitbake &lt;image&gt; -c testimage
MACHINE=B bitbake &lt;image&gt; -c testimage

and A has errors in parselogs, machine B can pick these up and cause
immense confusion. This is because the test transfers the log files
to cwd which is usually TOPDIR. This is clearly bad and this patch
uses a subdir of WORKDIR to ensure machines don't contaminate each
other.

Also ensure any previous logs are cleaned up from any existing
transfer directory.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If you run:

MACHINE=A bitbake &lt;image&gt; -c testimage
MACHINE=B bitbake &lt;image&gt; -c testimage

and A has errors in parselogs, machine B can pick these up and cause
immense confusion. This is because the test transfers the log files
to cwd which is usually TOPDIR. This is clearly bad and this patch
uses a subdir of WORKDIR to ensure machines don't contaminate each
other.

Also ensure any previous logs are cleaned up from any existing
transfer directory.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parselogs: Whitelist qemux86 error message with qemu 2.7.0</title>
<updated>2016-09-09T10:52:10+00:00</updated>
<author>
<name>Robert Yang</name>
<email>liezhi.yang@windriver.com</email>
</author>
<published>2016-09-08T16:11:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=4d542cdc86c34f0f4a3dde8b0aab059bca76a9fb'/>
<id>4d542cdc86c34f0f4a3dde8b0aab059bca76a9fb</id>
<content type='text'>
qemu 2.7.0 introduces kernel errors:

[    2.310768] pci 0000:00:00.0: [11ab:4620] type 00 class 0x060000
[    2.311338] pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
[    2.311604] pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
[    2.311835] pci 0000:00:00.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
[    2.312063] pci 0000:00:00.0: [Firmware Bug]: reg 0x20: invalid BAR (can't size)
[    2.312323] pci 0000:00:00.0: [Firmware Bug]: reg 0x24: invalid BAR (can't size)
[    2.314320] pci 0000:00:0a.0: [8086:7110] type 00 class 0x060100
[    2.315363] pci 0000:00:0a.1: [8086:7111] type 00 class 0x010180

Whitelist this for now since this is preferable to the random failures
we're seeing from qemuppc with 2.6.0.

Signed-off-by: Robert Yang &lt;liezhi.yang@windriver.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
qemu 2.7.0 introduces kernel errors:

[    2.310768] pci 0000:00:00.0: [11ab:4620] type 00 class 0x060000
[    2.311338] pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
[    2.311604] pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
[    2.311835] pci 0000:00:00.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
[    2.312063] pci 0000:00:00.0: [Firmware Bug]: reg 0x20: invalid BAR (can't size)
[    2.312323] pci 0000:00:00.0: [Firmware Bug]: reg 0x24: invalid BAR (can't size)
[    2.314320] pci 0000:00:0a.0: [8086:7110] type 00 class 0x060100
[    2.315363] pci 0000:00:0a.1: [8086:7111] type 00 class 0x010180

Whitelist this for now since this is preferable to the random failures
we're seeing from qemuppc with 2.6.0.

Signed-off-by: Robert Yang &lt;liezhi.yang@windriver.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parselogs: Whitelist qemuppc error message with qemu 2.7.0</title>
<updated>2016-09-09T10:52:10+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2016-09-08T10:39:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=2472ed5393ab01ad79c011ea19c73224ed5125de'/>
<id>2472ed5393ab01ad79c011ea19c73224ed5125de</id>
<content type='text'>
qemu 2.7.0 introduces kernel errors:

[0.474981] pci 0000:00:0f.0: reg 0x10: [io  0x0400-0x041f]
[0.483796] pci 0000:00:0f.0: reg 0x20: can't handle BAR above 4GB (bus address 0xffffffff82800000)
[0.484204] pci 0000:00:0f.0: reg 0x20: [mem size 0x00800000 64bit pref]
[0.488077] pci 0000:00:0f.0: reg 0x30: [mem 0x83000000-0x8303ffff pref]
[0.488903] pci 0000:00:10.0: [1af4:1005] type 00 class 0x00ff00
[0.490485] pci 0000:00:10.0: reg 0x10: [io  0x0480-0x049f]
[0.496512] pci 0000:00:10.0: reg 0x20: can't handle BAR above 4GB (bus address 0xffffffff83800000)
[0.496783] pci 0000:00:10.0: reg 0x20: [mem size 0x00800000 64bit pref]
[0.500345] pci 0000:00:11.0: [1af4:1001] type 00 class 0x010000
[0.501790] pci 0000:00:11.0: reg 0x10: [io  0x0500-0x053f]
[0.507362] pci 0000:00:11.0: reg 0x20: can't handle BAR above 4GB (bus address 0xffffffff84000000)
[0.507677] pci 0000:00:11.0: reg 0x20: [mem size 0x00800000 64bit pref]
[0.513905] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
[0.516493] PCI 0000:00 Cannot reserve Legacy IO [io  0x0000-0x0fff]
[0.517512] pci 0000:00:0f.0: BAR 4: assigned [mem 0x80800000-0x80ffffff 64bit pref]
[0.518877] pci 0000:00:10.0: BAR 4: assigned [mem 0x82800000-0x82ffffff 64bit pref]
[0.519890] pci 0000:00:11.0: BAR 4: assigned [mem 0x83800000-0x83ffffff 64bit pref]

Whitelist this for now since this is preferable to the random failures
we're seeing from qemuppc with 2.6.0.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
qemu 2.7.0 introduces kernel errors:

[0.474981] pci 0000:00:0f.0: reg 0x10: [io  0x0400-0x041f]
[0.483796] pci 0000:00:0f.0: reg 0x20: can't handle BAR above 4GB (bus address 0xffffffff82800000)
[0.484204] pci 0000:00:0f.0: reg 0x20: [mem size 0x00800000 64bit pref]
[0.488077] pci 0000:00:0f.0: reg 0x30: [mem 0x83000000-0x8303ffff pref]
[0.488903] pci 0000:00:10.0: [1af4:1005] type 00 class 0x00ff00
[0.490485] pci 0000:00:10.0: reg 0x10: [io  0x0480-0x049f]
[0.496512] pci 0000:00:10.0: reg 0x20: can't handle BAR above 4GB (bus address 0xffffffff83800000)
[0.496783] pci 0000:00:10.0: reg 0x20: [mem size 0x00800000 64bit pref]
[0.500345] pci 0000:00:11.0: [1af4:1001] type 00 class 0x010000
[0.501790] pci 0000:00:11.0: reg 0x10: [io  0x0500-0x053f]
[0.507362] pci 0000:00:11.0: reg 0x20: can't handle BAR above 4GB (bus address 0xffffffff84000000)
[0.507677] pci 0000:00:11.0: reg 0x20: [mem size 0x00800000 64bit pref]
[0.513905] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
[0.516493] PCI 0000:00 Cannot reserve Legacy IO [io  0x0000-0x0fff]
[0.517512] pci 0000:00:0f.0: BAR 4: assigned [mem 0x80800000-0x80ffffff 64bit pref]
[0.518877] pci 0000:00:10.0: BAR 4: assigned [mem 0x82800000-0x82ffffff 64bit pref]
[0.519890] pci 0000:00:11.0: BAR 4: assigned [mem 0x83800000-0x83ffffff 64bit pref]

Whitelist this for now since this is preferable to the random failures
we're seeing from qemuppc with 2.6.0.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>oeqa/parselogs: Add qemuarm64 warning from 4.8 kernel to whitelist</title>
<updated>2016-09-05T10:55:50+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2016-09-01T16:50:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=ae865fee26d2a32ae07236fc7aa1cf1b234a2156'/>
<id>ae865fee26d2a32ae07236fc7aa1cf1b234a2156</id>
<content type='text'>
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>oeqa/parselogs/qemuarm: Whitelist amba and jitter for 4.8+ kernels</title>
<updated>2016-09-05T10:55:50+00:00</updated>
<author>
<name>Bruce Ashfield</name>
<email>bruce.ashfield@windriver.com</email>
</author>
<published>2016-08-31T14:54:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=f5315b8c7998611da9984fd6bce2b48d6304ff6c'/>
<id>f5315b8c7998611da9984fd6bce2b48d6304ff6c</id>
<content type='text'>
With the update to the 4.8 kernel the versatile platform (and hence
qemuarm) has switched to a device tree boot.

We are using an ummodified mainline kernel versatilepb device tree,
which includes definitions of multiple amba devices. These devices
are not present in the qemu system emulation, hence throw warnings
during boot.

These warnings are not unique to oe-core, and rather than carry kernel
patches to the device tree (for now), we whitelist the known warnings
so qa testing will pass. We also can't turn amba off completely, since
it is providing valid devices (like the serial port) and AMBA is
force selected by other kconfig values.

We also have a jitterentropy warning that shows up on some hosts.
This warning is harmless, and like amba we can't turn it off in a
fragment since it is force selected by crypto (and we'd rather not
turn all crypto off). So we add it to the whitelist while investigations
continue into what is needed in the host to support this fully.

Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@windriver.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With the update to the 4.8 kernel the versatile platform (and hence
qemuarm) has switched to a device tree boot.

We are using an ummodified mainline kernel versatilepb device tree,
which includes definitions of multiple amba devices. These devices
are not present in the qemu system emulation, hence throw warnings
during boot.

These warnings are not unique to oe-core, and rather than carry kernel
patches to the device tree (for now), we whitelist the known warnings
so qa testing will pass. We also can't turn amba off completely, since
it is providing valid devices (like the serial port) and AMBA is
force selected by other kconfig values.

We also have a jitterentropy warning that shows up on some hosts.
This warning is harmless, and like amba we can't turn it off in a
fragment since it is force selected by crypto (and we'd rather not
turn all crypto off). So we add it to the whitelist while investigations
continue into what is needed in the host to support this fully.

Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@windriver.com&gt;
Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parselogs: Ignore uvesafb timeouts</title>
<updated>2016-08-25T21:57:29+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2016-08-19T10:03:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.multitech.net/cgit/openembedded-core.git/commit/?id=8097f2da79b7862733494d2321e3dfdb0880804d'/>
<id>8097f2da79b7862733494d2321e3dfdb0880804d</id>
<content type='text'>
We're periodically seeing uvesafb timeouts on the autobuilder. Whitelist these
errors as there is little it seems we can do about them and we therefore
choose to ignore them rather than fail the builds.

[YOCTO #8245]

There is a better solution proposed in the bug with a -1 timeout however
this avoids failed builds until such times as that is implemented.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We're periodically seeing uvesafb timeouts on the autobuilder. Whitelist these
errors as there is little it seems we can do about them and we therefore
choose to ignore them rather than fail the builds.

[YOCTO #8245]

There is a better solution proposed in the bug with a -1 timeout however
this avoids failed builds until such times as that is implemented.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
