| 2018-12-10 17:36:02 |
Wes Tarro |
bug |
|
|
added bug |
| 2018-12-10 17:36:02 |
Wes Tarro |
attachment added |
|
Add an extra define to enable timerfd_create support. https://bugs.launchpad.net/bugs/1807743/+attachment/5220929/+files/fix-timerfd-support-on-ppc.patch |
|
| 2018-12-11 04:21:34 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2018-12-11 04:21:42 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2018-12-11 09:11:12 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Trusty |
|
| 2018-12-11 09:11:12 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Trusty) |
|
| 2018-12-11 09:11:12 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Precise |
|
| 2018-12-11 09:11:12 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Precise) |
|
| 2018-12-11 09:11:12 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Xenial |
|
| 2018-12-11 09:11:12 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Xenial) |
|
| 2018-12-11 09:11:12 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Cosmic |
|
| 2018-12-11 09:11:12 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Cosmic) |
|
| 2018-12-11 09:11:12 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-12-11 09:11:12 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Bionic) |
|
| 2018-12-11 09:11:19 |
Christian Ehrhardt |
qemu (Ubuntu Precise): status |
New |
Invalid |
|
| 2018-12-11 09:11:21 |
Christian Ehrhardt |
qemu (Ubuntu Trusty): status |
New |
Invalid |
|
| 2018-12-11 09:11:23 |
Christian Ehrhardt |
qemu (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2018-12-11 09:11:27 |
Christian Ehrhardt |
qemu (Ubuntu Bionic): status |
New |
Fix Released |
|
| 2018-12-11 09:11:29 |
Christian Ehrhardt |
qemu (Ubuntu Cosmic): status |
New |
Fix Released |
|
| 2018-12-11 09:11:30 |
Christian Ehrhardt |
qemu (Ubuntu): status |
New |
Fix Released |
|
| 2018-12-11 09:16:03 |
Christian Ehrhardt |
description |
QEMU erroneously fails to detect support for the timerfd_create syscall when running user-mode emulation of PowerPC targets. QEMU supports the timerfd_create syscall, but because the PowerPC target syscall header has it named "timerfd" instead of "timerfd_create", support is erroneously not enabled. This notably affects anything that uses Boost.Asio with deadline timers because it uses timerfds under the hood. I have attached a patch to fix the problem. For now I have a custom-built qemu-user-static.deb file with this fix implemented, but I would appreciate it if you could officially backport this patch to 16.04 LTS (Xenial) so our developers can use the official package repositories. |
[Impact]
* A bad named define made timerfd_create be in the code but not available
* two smaller fixes to be backported from upstream that change the define
names; This will enable the timerfd_create in qemu-user
[Test Case]
* TODO @WES
[Regression Potential]
* The headers are only used internally so no outside regression should
happen.
* Even then only the names changed but the number stayed, that means even
if it would be an external ABI (it isn't) the number would be the same
* Internally the old define was only used when defining it, but not used
(see grep in comment #1)
* The one regression I could think of is software running in qemu-user
today and working by having a path like "does this have timerfd create
-> no, ok then do A", with the change this might become "-> yes, so do
B" and if that B is broken there would be a regression, but I'd
consider it unlikely since all versions after Xenials 2.5 had the new
variant and I have seen no complaints about it.
[Other Info]
* n/a
---
QEMU erroneously fails to detect support for the timerfd_create syscall when running user-mode emulation of PowerPC targets. QEMU supports the timerfd_create syscall, but because the PowerPC target syscall header has it named "timerfd" instead of "timerfd_create", support is erroneously not enabled. This notably affects anything that uses Boost.Asio with deadline timers because it uses timerfds under the hood. I have attached a patch to fix the problem. For now I have a custom-built qemu-user-static.deb file with this fix implemented, but I would appreciate it if you could officially backport this patch to 16.04 LTS (Xenial) so our developers can use the official package repositories. |
|
| 2018-12-11 19:10:30 |
Wes Tarro |
attachment added |
|
C source code to exercise timerfd support https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1807743/+attachment/5221438/+files/timerfd_support_test.c |
|
| 2018-12-12 11:56:16 |
Christian Ehrhardt |
description |
[Impact]
* A bad named define made timerfd_create be in the code but not available
* two smaller fixes to be backported from upstream that change the define
names; This will enable the timerfd_create in qemu-user
[Test Case]
* TODO @WES
[Regression Potential]
* The headers are only used internally so no outside regression should
happen.
* Even then only the names changed but the number stayed, that means even
if it would be an external ABI (it isn't) the number would be the same
* Internally the old define was only used when defining it, but not used
(see grep in comment #1)
* The one regression I could think of is software running in qemu-user
today and working by having a path like "does this have timerfd create
-> no, ok then do A", with the change this might become "-> yes, so do
B" and if that B is broken there would be a regression, but I'd
consider it unlikely since all versions after Xenials 2.5 had the new
variant and I have seen no complaints about it.
[Other Info]
* n/a
---
QEMU erroneously fails to detect support for the timerfd_create syscall when running user-mode emulation of PowerPC targets. QEMU supports the timerfd_create syscall, but because the PowerPC target syscall header has it named "timerfd" instead of "timerfd_create", support is erroneously not enabled. This notably affects anything that uses Boost.Asio with deadline timers because it uses timerfds under the hood. I have attached a patch to fix the problem. For now I have a custom-built qemu-user-static.deb file with this fix implemented, but I would appreciate it if you could officially backport this patch to 16.04 LTS (Xenial) so our developers can use the official package repositories. |
[Impact]
* A bad named define made timerfd_create be in the code but not available
* two smaller fixes to be backported from upstream that change the define
names; This will enable the timerfd_create in qemu-user
[Test Case]
* Compile the attached source code using your host C compiler.
=> https://launchpadlibrarian.net/401131808/timerfd_support_test.c
* Run the resulting binary.
> It should run for 3 seconds and print timer information. (sanity test)
* Compile the attached source code using a PowerPC cross compiler with
static linking enabled (to make the remaining steps simpler).
* Run the resulting binary using the unpatched qemu-user or qemu-user-static
executable for your selected PowerPC architecture.
> It should exit immediately complaining about an unsupported syscall.
* Run the same binary using the patched qemu-user or qemu-user-static
executable for your selected PowerPC architecture.
> It should behave as the host version did.
> If you chose a big-endian PowerPC architecture, the "timer expirations"
output may be "72057594037927936" instead of "1" because the bytes read
were in host byte order instead of target byte order.
[Regression Potential]
* The headers are only used internally so no outside regression should
happen.
* Even then only the names changed but the number stayed, that means even
if it would be an external ABI (it isn't) the number would be the same
* Internally the old define was only used when defining it, but not used
(see grep in comment #1)
* The one regression I could think of is software running in qemu-user
today and working by having a path like "does this have timerfd create
-> no, ok then do A", with the change this might become "-> yes, so do
B" and if that B is broken there would be a regression, but I'd
consider it unlikely since all versions after Xenials 2.5 had the new
variant and I have seen no complaints about it.
[Other Info]
* n/a
---
QEMU erroneously fails to detect support for the timerfd_create syscall when running user-mode emulation of PowerPC targets. QEMU supports the timerfd_create syscall, but because the PowerPC target syscall header has it named "timerfd" instead of "timerfd_create", support is erroneously not enabled. This notably affects anything that uses Boost.Asio with deadline timers because it uses timerfds under the hood. I have attached a patch to fix the problem. For now I have a custom-built qemu-user-static.deb file with this fix implemented, but I would appreciate it if you could officially backport this patch to 16.04 LTS (Xenial) so our developers can use the official package repositories. |
|
| 2018-12-12 12:06:25 |
Christian Ehrhardt |
description |
[Impact]
* A bad named define made timerfd_create be in the code but not available
* two smaller fixes to be backported from upstream that change the define
names; This will enable the timerfd_create in qemu-user
[Test Case]
* Compile the attached source code using your host C compiler.
=> https://launchpadlibrarian.net/401131808/timerfd_support_test.c
* Run the resulting binary.
> It should run for 3 seconds and print timer information. (sanity test)
* Compile the attached source code using a PowerPC cross compiler with
static linking enabled (to make the remaining steps simpler).
* Run the resulting binary using the unpatched qemu-user or qemu-user-static
executable for your selected PowerPC architecture.
> It should exit immediately complaining about an unsupported syscall.
* Run the same binary using the patched qemu-user or qemu-user-static
executable for your selected PowerPC architecture.
> It should behave as the host version did.
> If you chose a big-endian PowerPC architecture, the "timer expirations"
output may be "72057594037927936" instead of "1" because the bytes read
were in host byte order instead of target byte order.
[Regression Potential]
* The headers are only used internally so no outside regression should
happen.
* Even then only the names changed but the number stayed, that means even
if it would be an external ABI (it isn't) the number would be the same
* Internally the old define was only used when defining it, but not used
(see grep in comment #1)
* The one regression I could think of is software running in qemu-user
today and working by having a path like "does this have timerfd create
-> no, ok then do A", with the change this might become "-> yes, so do
B" and if that B is broken there would be a regression, but I'd
consider it unlikely since all versions after Xenials 2.5 had the new
variant and I have seen no complaints about it.
[Other Info]
* n/a
---
QEMU erroneously fails to detect support for the timerfd_create syscall when running user-mode emulation of PowerPC targets. QEMU supports the timerfd_create syscall, but because the PowerPC target syscall header has it named "timerfd" instead of "timerfd_create", support is erroneously not enabled. This notably affects anything that uses Boost.Asio with deadline timers because it uses timerfds under the hood. I have attached a patch to fix the problem. For now I have a custom-built qemu-user-static.deb file with this fix implemented, but I would appreciate it if you could officially backport this patch to 16.04 LTS (Xenial) so our developers can use the official package repositories. |
[Impact]
* A bad named define made timerfd_create be in the code but not available
* two smaller fixes to be backported from upstream that change the define
names; This will enable the timerfd_create in qemu-user
[Test Case]
* Compile the attached source code using your host C compiler.
=> https://launchpadlibrarian.net/401131808/timerfd_support_test.c
$ apt install build-essential
$ gcc -Wall timertest.c -o timertest
* Run the resulting binary.
It should run for 3 seconds and print timer information. (sanity
test)
$ ./timertest
* Compile the attached source code using a PowerPC cross compiler with
static linking enabled (to make the remaining steps simpler).
$ apt install gcc-powerpc64-linux-gnu
$ powerpc64-linux-gnu-gcc -static -Wall timertest.c -o timertest
* Run the resulting binary using the unpatched qemu-user or qemu-user-
static executable for your selected PowerPC architecture. It should
exit immediately complaining about an unsupported syscall.
$ apt install qemu-user
$ qemu-ppc64 ./timertest
qemu: Unsupported syscall: 306
timerfd_create(CLOCK_REALTIME): Function not implemented
* Run the same binary using the patched qemu-user or qemu-user-static
executable for your selected PowerPC architecture.
It should behave as the host version did.
Note: If you chose a big-endian PowerPC architecture, the "timer expirations" output may be "72057594037927936" instead of "1" because the bytes read were in host byte order instead of target byte order.
[Regression Potential]
* The headers are only used internally so no outside regression should
happen.
* Even then only the names changed but the number stayed, that means even
if it would be an external ABI (it isn't) the number would be the same
* Internally the old define was only used when defining it, but not used
(see grep in comment #1)
* The one regression I could think of is software running in qemu-user
today and working by having a path like "does this have timerfd create
-> no, ok then do A", with the change this might become "-> yes, so do
B" and if that B is broken there would be a regression, but I'd
consider it unlikely since all versions after Xenials 2.5 had the new
variant and I have seen no complaints about it.
[Other Info]
* n/a
---
QEMU erroneously fails to detect support for the timerfd_create syscall when running user-mode emulation of PowerPC targets. QEMU supports the timerfd_create syscall, but because the PowerPC target syscall header has it named "timerfd" instead of "timerfd_create", support is erroneously not enabled. This notably affects anything that uses Boost.Asio with deadline timers because it uses timerfds under the hood. I have attached a patch to fix the problem. For now I have a custom-built qemu-user-static.deb file with this fix implemented, but I would appreciate it if you could officially backport this patch to 16.04 LTS (Xenial) so our developers can use the official package repositories. |
|
| 2018-12-12 14:28:18 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/360798 |
|
| 2018-12-13 19:58:06 |
Andreas Hasenack |
qemu (Ubuntu Xenial): status |
Confirmed |
In Progress |
|
| 2018-12-13 19:58:16 |
Andreas Hasenack |
qemu (Ubuntu Xenial): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2018-12-18 19:11:02 |
Brian Murray |
qemu (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2018-12-18 19:11:05 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-12-18 19:11:08 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2018-12-18 19:11:13 |
Brian Murray |
tags |
patch |
patch verification-needed verification-needed-xenial |
|
| 2019-01-07 14:39:26 |
Christian Ehrhardt |
tags |
patch verification-needed verification-needed-xenial |
patch verification-done verification-done-xenial |
|
| 2019-01-08 17:23:09 |
Launchpad Janitor |
qemu (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2019-01-08 17:23:20 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
