On Mon, Mar 18, 2019 at 07:07:25AM +, Fernando Casas Schössow wrote:
> Wanted to share one more update regarding this issue.
> Since running the new package with the patch from Natanael, the issue never
> happen again.
> It's been three weeks with all guests running on virtio-scsi and no issue
Hi all,
Wanted to share one more update regarding this issue.
Since running the new package with the patch from Natanael, the issue never
happen again.
It's been three weeks with all guests running on virtio-scsi and no issues at
all so I guess we can consider this solved.
Thanks again to every
After two weeks of running the new QEMU package everything is fine.
Moreover I migrated the rest of the guests (both Windows and Linux) to
virtio-scsi and no issues so far.
I will monitor for another week but this issue seems pretty much fixed!
Kudos to each and everyone of you that helped findin
On Mon, 25 Feb 2019 at 13:06, Peter Maydell wrote:
>
> On Mon, 25 Feb 2019 at 12:22, Natanael Copa wrote:
> >
> > On Mon, 25 Feb 2019 10:34:23 +
> > Peter Maydell wrote:
> > > The short term fix is to fix your toolchain/compilation
> > > environment options so that it isn't trying to overrid
Just wanted to share a small update on the situation after updating QEMU to the
new Alpine package patched with Natanael's patch.
So far so good, moreover I switched a few other guests from SATA to VirtIO SCSI
and after two days no issues.
Unless I find any problem I will report back with an upda
On 23/02/19 12:49, Natanael Copa wrote:
> I suspect this happens due to the Alpine toolchain will enable
> _FORTIFY_SOURCE=2 by default and the way this is implemented via
> fortify-headers:
> http://git.2f30.org/fortify-headers/file/include/string.h.html#l39
The call to __orig_memcpy is the culp
Ok, the new package is deployed.
I stopped and started the test guest so it will use the new QEMU binary.
Will monitor and report back.
On lun, feb 25, 2019 at 2:32 PM, Fernando Casas Schössow
wrote:
Thanks Natanael. Is the new package ready?
I will update as soon as the package is available,
Thanks Natanael. Is the new package ready?
I will update as soon as the package is available, try to repro and report back.
Thanks everyone for looking into this!
On lun, feb 25, 2019 at 2:25 PM, Natanael Copa wrote:
On Mon, 25 Feb 2019 13:06:16 + Peter Maydell
mailto:peter.mayd...@linaro.
On Mon, 25 Feb 2019 13:06:16 +
Peter Maydell wrote:
> On Mon, 25 Feb 2019 at 12:22, Natanael Copa wrote:
> >
> > On Mon, 25 Feb 2019 10:34:23 +
> > Peter Maydell wrote:
> > > The short term fix is to fix your toolchain/compilation
> > > environment options so that it isn't trying to o
On Mon, 25 Feb 2019 at 12:22, Natanael Copa wrote:
>
> On Mon, 25 Feb 2019 10:34:23 +
> Peter Maydell wrote:
> > The short term fix is to fix your toolchain/compilation
> > environment options so that it isn't trying to override
> > the definition of memcpy().
>
> The easiest workaround is to
On Mon, 25 Feb 2019 10:34:23 +
Peter Maydell wrote:
> On Mon, 25 Feb 2019 at 10:24, Natanael Copa wrote:
> >
> > On Sat, 23 Feb 2019 16:18:15 +
> > Peter Maydell wrote:
> >
> > > On Sat, 23 Feb 2019 at 16:05, Natanael Copa
> > > wrote:
> > > > I was thinking of something in the li
I’m running the test guest on another host for the last three days and so far
so good.
Yet because of the nature of this bug/issue it can take a few hours or a few
days more to fail. The failure is unpredictable.
Does it make sense to continue running the guest on this different host to try
to
On Sat, 23 Feb 2019 16:18:15 +
Peter Maydell wrote:
> On Sat, 23 Feb 2019 at 16:05, Natanael Copa wrote:
> > I was thinking of something in the lines of:
> >
> > typedef volatile uint16_t __attribute__((__may_alias__)) volatile_uint16_t;
> > static inline int lduw_he_p(const void *ptr)
> > {
On Mon, Feb 25, 2019 at 10:30 AM Stefan Hajnoczi wrote:
> On Sat, Feb 23, 2019 at 3:55 PM Natanael Copa wrote:
> > On Fri, 22 Feb 2019 14:04:20 +
> > Stefan Hajnoczi wrote:
> > > On Fri, Feb 22, 2019 at 12:57 PM Fernando Casas Schössow
> > > wrote:
> > I tried to find this section. How do y
On Sat, Feb 23, 2019 at 3:55 PM Natanael Copa wrote:
> On Fri, 22 Feb 2019 14:04:20 +
> Stefan Hajnoczi wrote:
> > On Fri, Feb 22, 2019 at 12:57 PM Fernando Casas Schössow
> > wrote:
> I tried to find this section. How do you get the assembly listing of
> relevant secion? I tried to do "disa
On Mon, 25 Feb 2019 at 10:24, Natanael Copa wrote:
>
> On Sat, 23 Feb 2019 16:18:15 +
> Peter Maydell wrote:
>
> > On Sat, 23 Feb 2019 at 16:05, Natanael Copa wrote:
> > > I was thinking of something in the lines of:
> > >
> > > typedef volatile uint16_t __attribute__((__may_alias__))
> > >
On Fri, 22 Feb 2019 at 14:07, Stefan Hajnoczi wrote:
> Richard: Commit 7db2145a6826b14efceb8dd64bfe6ad8647072eb ("bswap: Add
> host endian unaligned access functions") introduced the unaligned
> memory access functions in question here. Please see below for
> details on the bug - basically QEMU c
Hi Natanael,
The package information is the following:
https://pkgs.alpinelinux.org/package/v3.9/main/x86_64/qemu-system-x86_64
The binary is for x86_64 architecture and dynamically linked:
fernando@vmsvr01:~$ file /usr/bin/qemu-system-x86_64
/usr/bin/qemu-system-x86_64: ELF 64-bit LSB shared o
On Sat, 23 Feb 2019 at 16:05, Natanael Copa wrote:
> I was thinking of something in the lines of:
>
> typedef volatile uint16_t __attribute__((__may_alias__)) volatile_uint16_t;
> static inline int lduw_he_p(const void *ptr)
> {
> volatile_uint16_t r = *(volatile_uint16_t*)ptr;
> return
On Fri, 22 Feb 2019 14:04:20 +
Stefan Hajnoczi wrote:
> On Fri, Feb 22, 2019 at 12:57 PM Fernando Casas Schössow
> wrote:
>
> I have CCed Natanael Copa, qemu package maintainer in Alpine Linux.
>
> Fernando: Can you confirm that the bug occurs with an unmodified
> Alpine Linux qemu binary?
On Fri, 22 Feb 2019 14:04:20 +
Stefan Hajnoczi wrote:
> On Fri, Feb 22, 2019 at 12:57 PM Fernando Casas Schössow
> wrote:
>
> I have CCed Natanael Copa, qemu package maintainer in Alpine Linux.
Hi!
...
> Richard: Commit 7db2145a6826b14efceb8dd64bfe6ad8647072eb ("bswap: Add
> host endian
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 22/02/19 17:37, Dr. David Alan Gilbert wrote:
> > Why does vring_avail_idx use virtio_ld*u*w_phys_cached?
> > (similar for vring_avail_ring).
> > There's no generically safe way to do unaligned atomic loads - don't we know
> > in virtio that these a
On 22/02/19 17:37, Dr. David Alan Gilbert wrote:
> Why does vring_avail_idx use virtio_ld*u*w_phys_cached?
> (similar for vring_avail_ring).
> There's no generically safe way to do unaligned atomic loads - don't we know
> in virtio that these are naturally aligned?
u is for unsigned. :) We know t
* Stefan Hajnoczi (stefa...@gmail.com) wrote:
> On Fri, Feb 22, 2019 at 12:57 PM Fernando Casas Schössow
> wrote:
>
> I have CCed Natanael Copa, qemu package maintainer in Alpine Linux.
>
> Fernando: Can you confirm that the bug occurs with an unmodified
> Alpine Linux qemu binary?
>
> Richard:
You can find the the information here:
https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
For your convenience, I can setup an Alpine VM and give you SSH access with the
build environment and the aports tree already setup.
Then summary steps in case you want to try on your own containe
Hi all,
Indeed I can confirm this issue occurs with the stock, unmodified QEMU binary
provided with Alpine since at least Alpine 3.6 up to 3.9.
Is there any compiler flag I can tweak, add or remove to rebuild qemu and try
to repro to confirm a possible workaround?
Thanks.
Fernando
Sent from
On 22/02/19 15:43, Fernando Casas Schössow wrote:
> Hi all,
>
> Indeed I can confirm this issue occurs with the stock, unmodified
> QEMU binary provided with Alpine since at least Alpine 3.6 up to
> 3.9.
>
> Is there any compiler flag I can tweak, add or remove to rebuild qemu
> and try to repro
On 22/02/19 15:04, Stefan Hajnoczi wrote:
> On Fri, Feb 22, 2019 at 12:57 PM Fernando Casas Schössow
> wrote:
>
> I have CCed Natanael Copa, qemu package maintainer in Alpine Linux.
>
> Fernando: Can you confirm that the bug occurs with an unmodified
> Alpine Linux qemu binary?
I can confirm th
On Fri, Feb 22, 2019 at 12:57 PM Fernando Casas Schössow
wrote:
I have CCed Natanael Copa, qemu package maintainer in Alpine Linux.
Fernando: Can you confirm that the bug occurs with an unmodified
Alpine Linux qemu binary?
Richard: Commit 7db2145a6826b14efceb8dd64bfe6ad8647072eb ("bswap: Add
ho
Hi Stefan,
I can confirm that the symbols are included in the binary using gdb.
I will send you and Paolo an email with the link and credentials (if needed) so
you can download everything.
Thanks!
On jue, feb 21, 2019 at 12:11 PM, Stefan Hajnoczi wrote:
On Wed, Feb 20, 2019 at 06:56:04PM +000
On Wed, Feb 20, 2019 at 06:56:04PM +, Fernando Casas Schössow wrote:
> Regarding the dumps I have three of them including guest memory, 2 for
> virtio-scsi, 1 for virtio-blk, in case a comparison may help to confirm which
> is the proble.) I can upload them to a server you indicate me or I ca
Hi Paolo,
This is Fernando, the one that reported the issue.
Regarding the dumps I have three of them including guest memory, 2 for
virtio-scsi, 1 for virtio-blk, in case a comparison may help to confirm which
is the proble.) I can upload them to a server you indicate me or I can also put
them
On 20/02/19 17:58, Stefan Hajnoczi wrote:
> On Mon, Feb 18, 2019 at 07:21:25AM +, Fernando Casas Schössow wrote:
>> It took a few days but last night the problem was reproduced.
>> This is the information from the log:
>>
>> vdev 0x55f261d940f0 ("virtio-blk")
>> vq 0x55f261d9ee40 (idx 0)
>> inu
On Mon, Feb 18, 2019 at 07:21:25AM +, Fernando Casas Schössow wrote:
> It took a few days but last night the problem was reproduced.
> This is the information from the log:
>
> vdev 0x55f261d940f0 ("virtio-blk")
> vq 0x55f261d9ee40 (idx 0)
> inuse 128 vring.num 128
> old_shadow_avail_idx 58874
Problem reproduced with virtio-scsi as well on the same guest, this time it
took less than a day.
Information from the log file:
vdev 0x55823f119f90 ("virtio-scsi")
vq 0x55823f122e80 (idx 2)
inuse 128 vring.num 128
old_shadow_avail_idx 58367 last_avail_idx 58113 avail_idx 58367
avail 0x3de8a800 a
It took a few days but last night the problem was reproduced.
This is the information from the log:
vdev 0x55f261d940f0 ("virtio-blk")
vq 0x55f261d9ee40 (idx 0)
inuse 128 vring.num 128
old_shadow_avail_idx 58874 last_avail_idx 58625 avail_idx 58874
avail 0x3d87a800 avail_idx (cache bypassed) 58625
Thanks for looking into this Stefan.
I rebuilt Qemu with the new patch and got a couple of guests running with the
new build. Two of them using virtio-scsi and another one using virtio-blk. Now
I'm waiting for any of them to crash.
I also set libvirt to include the guest memory in the qemu dumps
On Wed, Feb 06, 2019 at 04:47:19PM +, Fernando Casas Schössow wrote:
> I could also repro the same with virtio-scsi on the same guest a couple of
> hours later:
>
> 2019-02-06 07:10:37.672+: starting up libvirt version: 4.10.0, qemu
> version: 3.1.0, kernel: 4.19.18-0-vanilla, hostname:
I could also repro the same with virtio-scsi on the same guest a couple of
hours later:
2019-02-06 07:10:37.672+: starting up libvirt version: 4.10.0, qemu
version: 3.1.0, kernel: 4.19.18-0-vanilla, hostname: vmsvr01.homenet.local
LC_ALL=C
PATH=/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/
I can now confirm that the same happens with virtio-blk and virtio-scsi.
Please find below the qemu log enhanced with the new information added by the
patch provided by Stefan:
vdev 0x55d22b8e10f0 ("virtio-blk")
vq 0x55d22b8ebe40 (idx 0)
inuse 128 vring.num 128
2019-02-06T00:40:41.742552Z qemu-sy
I can test again with qemu 3.1 but with previous versions yes, it was happening
the same with both virtio-blk and virtio-scsi.
For 3.1 I can confirm it happens for virtio-scsi (already tested it) and I can
test with virtio-blk again if that will add value to the investigation.
Also I'm attaching
Are you sure this happens with both virtio-blk and virtio-scsi?
The following patch adds more debug output. You can build as follows:
$ git clone https://git.qemu.org/git/qemu.git
$ cd qemu
$ patch apply -p1
...paste the patch here...
^D
# For info on build dependencies see https://
Hi Stefan,
Thanks for looking into this. Please find the requested details below.
If you need any further details (like the host storage details) just let me
know.
Host details:
CPU: Intel(R) Xeon(R) CPU E3-1230 V2
Memory: 32GB (ECC)
OS: Alpine 3.9
Kernel version: 4.19.18-0-vanilla
Qemu version:
On Thu, Jan 31, 2019 at 11:32:32AM +, Fernando Casas Schössow wrote:
> Sorry for resurrecting this thread after so long but I just upgraded the host
> to Qemu 3.1 and libvirt 4.10 and I'm still facing this problem.
> At the moment I cannot use virtio disks (virtio-blk nor virtio-scsi) with my
44 matches
Mail list logo
