From: David Hildenbrand <david@redhat.com>
To: Ivan Warren <ivan@vmfacility.fr>,
Cornelia Huck <cohuck@redhat.com>,
Bug 1847232 <1847232@bugs.launchpad.net>
Cc: qemu-devel@nongnu.org
Subject: Re: [Bug 1847232] [NEW] qemu TCG in s390x mode issue with calculating HASH
Date: Mon, 14 Oct 2019 12:22:11 +0200 [thread overview]
Message-ID: <4115ee76-8f74-cce2-348b-44752cd402ed@redhat.com> (raw)
In-Reply-To: <8ada8acb-d2ce-a09d-6c9a-b758360edcb2@redhat.com>
On 14.10.19 11:53, David Hildenbrand wrote:
> On 08.10.19 16:11, Ivan Warren wrote:
>>
>> On 10/8/2019 3:35 PM, David Hildenbrand wrote:
>>> On 08.10.19 14:11, Cornelia Huck wrote:
>>>> On Tue, 08 Oct 2019 11:19:25 -0000
>>>> Ivan Warren via <qemu-devel@nongnu.org> wrote:
>>>>
>>>>> Public bug reported:
>>>>>
>>>>> When using go on s390x on Debian x64 (buster) (host) and debian s390x
>>>>> (sid) (guest) I run into the following problem :
>>>>>
>>>>> The following occurs while trying to build a custom project :
>>>>>
>>>>> go: github.com/FactomProject/basen@v0.0.0-20150613233007-fe3947df716e:
>>>>> Get
>>>>> https://proxy.golang.org/github.com/%21factom%21project/basen/@v/v0.0.0-20150613233007-fe3947df716e.mod:
>>>>> local error: tls: bad record MAC
>>>>>
>>>>> Doing a git bisect I find that this problem only occurs on and after
>>>>> commit 08ef92d556c584c7faf594ff3af46df456276e1b
>>>>>
>>>>> Before that commit, all works fine. Past this commit, build always
>>>>> fails.
>>>> What version are you using? Current master?
>>>>
>>>> Can you please share your command line?
>>>>
>>>>> Without any proof, It looks like a hash calculation bug related to using
>>>>> z/Arch vector facilities...
>>>> Not an unreasonable guess, cc:ing David in case he has seen that before.
>>>>
>>> Can you reproduce with "-cpu qemu,vx=off" added to the QEMU command
>>> line? Could be some fallout from vector instruction support. Currently
>>> ill, will have a look when I'm feeling better.
>>
>> Reposted with a reply all... (sorry for the duplicates)
>>
>> So it does !
>>
>>
>> My qemu command line is now (forget the odd funny networking things..)
>>
>> qemu-system-s390x \
>> -drive
>> file=DEB002.IMG.NEW,discard=unmap,cache=writeback,id=drive-0,if=none \
>> -device virtio-scsi-ccw,id=virtio-scsi-0 \
>> -device scsi-hd,id=scsi-hd-0,drive=drive-0 \
>> -m 8G \
>> -net nic,macaddr=52:54:00:00:00:02 \
>> -net tap,ifname=taparm,script=no \
>> -nographic -accel tcg,thread=multi \
>> -monitor unix:ms,server,nowait \
>> -cpu qemu,vx=off \ ##### THAT WAS ADDED as instructed - without it
>> everything goes kaput !
>> -smp 12
>>
>> And using the latest bleeding edge qemu from github, my build works (the
>> problem goes away).
>>
>> So the z/Arch vector instructions may have a glitch is a venue to
>> consider.. Probably one that couldn't be screened through conventional
>> methods.
>>
>> I'm not that versed into z/Arch vector instruction, but if there
>> anything I can help with, I will !
>
> I'll have to reproduce, can you outline the steps needed to trigger
> this? (never had to build a go project before #luckyme ( ;) )). It looks
> like https://github.com/FactomProject/basen is getting pulled in from
> some other project?
>
I just tried with Fedora 31 Nightly using "go get"
[root@f31 ~]# go get -v -d github.com/FactomProject/factom
github.com/FactomProject/factom (download)
github.com/FactomProject/btcutil (download)
github.com/FactomProject/ed25519 (download)
github.com/FactomProject/go-bip32 (download)
github.com/FactomProject/btcutilecc (download)
package golang.org/x/crypto/ripemd160: unrecognized import path "golang.org/x/crypto/ripemd160" (https fetch: Get https://golang.org/x/crypto/ripemd160?go-get=1: local error: tls: bad record MAC)
github.com/FactomProject/go-bip39 (download)
package golang.org/x/crypto/pbkdf2: unrecognized import path "golang.org/x/crypto/pbkdf2" (https fetch: Get https://golang.org/x/crypto/pbkdf2?go-get=1: local error: tls: bad record MAC)
github.com/FactomProject/go-bip44 (download)
github.com/FactomProject/netki-go-partner-client (download)
github.com/FactomProject/go-simplejson (download)
With vx=off:
[root@f31 ~]# go get -v -d github.com/FactomProject/factom
github.com/FactomProject/factom (download)
github.com/FactomProject/btcutil (download)
github.com/FactomProject/ed25519 (download)
github.com/FactomProject/go-bip32 (download)
github.com/FactomProject/basen (download)
github.com/FactomProject/btcutilecc (download)
get "golang.org/x/crypto/ripemd160": found meta tag get.metaImport{Prefix:"golang.org/x/crypto", VCS:"git", RepoRoot:"https://go.googlesource.com/crypto"} at //golang.org/x/crypto/ripemd160?go-get=1
get "golang.org/x/crypto/ripemd160": verifying non-authoritative meta tag
golang.org/x/crypto (download)
github.com/FactomProject/go-bip39 (download)
github.com/FactomProject/go-bip44 (download)
github.com/FactomProject/netki-go-partner-client (download)
github.com/FactomProject/go-simplejson (download)
That should be sufficient to identify the instruction. Might take some time, though. E.g.,
the HASH calculation in the kernel works just fine.
--
Thanks,
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <1847232@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: Re: [Bug 1847232] [NEW] qemu TCG in s390x mode issue with calculating HASH
Date: Mon, 14 Oct 2019 10:22:11 -0000 [thread overview]
Message-ID: <4115ee76-8f74-cce2-348b-44752cd402ed@redhat.com> (raw)
Message-ID: <20191014102211.S15TIf-xA3XnVaAllmCyP20WXyapTlVKccrDOKWmn-g@z> (raw)
In-Reply-To: 8ada8acb-d2ce-a09d-6c9a-b758360edcb2@redhat.com
On 14.10.19 11:53, David Hildenbrand wrote:
> On 08.10.19 16:11, Ivan Warren wrote:
>>
>> On 10/8/2019 3:35 PM, David Hildenbrand wrote:
>>> On 08.10.19 14:11, Cornelia Huck wrote:
>>>> On Tue, 08 Oct 2019 11:19:25 -0000
>>>> Ivan Warren via <qemu-devel@nongnu.org> wrote:
>>>>
>>>>> Public bug reported:
>>>>>
>>>>> When using go on s390x on Debian x64 (buster) (host) and debian s390x
>>>>> (sid) (guest) I run into the following problem :
>>>>>
>>>>> The following occurs while trying to build a custom project :
>>>>>
>>>>> go: github.com/FactomProject/basen@v0.0.0-20150613233007-fe3947df716e:
>>>>> Get
>>>>> https://proxy.golang.org/github.com/%21factom%21project/basen/@v/v0.0.0-20150613233007-fe3947df716e.mod:
>>>>> local error: tls: bad record MAC
>>>>>
>>>>> Doing a git bisect I find that this problem only occurs on and after
>>>>> commit 08ef92d556c584c7faf594ff3af46df456276e1b
>>>>>
>>>>> Before that commit, all works fine. Past this commit, build always
>>>>> fails.
>>>> What version are you using? Current master?
>>>>
>>>> Can you please share your command line?
>>>>
>>>>> Without any proof, It looks like a hash calculation bug related to using
>>>>> z/Arch vector facilities...
>>>> Not an unreasonable guess, cc:ing David in case he has seen that before.
>>>>
>>> Can you reproduce with "-cpu qemu,vx=off" added to the QEMU command
>>> line? Could be some fallout from vector instruction support. Currently
>>> ill, will have a look when I'm feeling better.
>>
>> Reposted with a reply all... (sorry for the duplicates)
>>
>> So it does !
>>
>>
>> My qemu command line is now (forget the odd funny networking things..)
>>
>> qemu-system-s390x \
>> -drive
>> file=DEB002.IMG.NEW,discard=unmap,cache=writeback,id=drive-0,if=none \
>> -device virtio-scsi-ccw,id=virtio-scsi-0 \
>> -device scsi-hd,id=scsi-hd-0,drive=drive-0 \
>> -m 8G \
>> -net nic,macaddr=52:54:00:00:00:02 \
>> -net tap,ifname=taparm,script=no \
>> -nographic -accel tcg,thread=multi \
>> -monitor unix:ms,server,nowait \
>> -cpu qemu,vx=off \ ##### THAT WAS ADDED as instructed - without it
>> everything goes kaput !
>> -smp 12
>>
>> And using the latest bleeding edge qemu from github, my build works (the
>> problem goes away).
>>
>> So the z/Arch vector instructions may have a glitch is a venue to
>> consider.. Probably one that couldn't be screened through conventional
>> methods.
>>
>> I'm not that versed into z/Arch vector instruction, but if there
>> anything I can help with, I will !
>
> I'll have to reproduce, can you outline the steps needed to trigger
> this? (never had to build a go project before #luckyme ( ;) )). It looks
> like https://github.com/FactomProject/basen is getting pulled in from
> some other project?
>
I just tried with Fedora 31 Nightly using "go get"
[root@f31 ~]# go get -v -d github.com/FactomProject/factom
github.com/FactomProject/factom (download)
github.com/FactomProject/btcutil (download)
github.com/FactomProject/ed25519 (download)
github.com/FactomProject/go-bip32 (download)
github.com/FactomProject/btcutilecc (download)
package golang.org/x/crypto/ripemd160: unrecognized import path "golang.org/x/crypto/ripemd160" (https fetch: Get https://golang.org/x/crypto/ripemd160?go-get=1: local error: tls: bad record MAC)
github.com/FactomProject/go-bip39 (download)
package golang.org/x/crypto/pbkdf2: unrecognized import path "golang.org/x/crypto/pbkdf2" (https fetch: Get https://golang.org/x/crypto/pbkdf2?go-get=1: local error: tls: bad record MAC)
github.com/FactomProject/go-bip44 (download)
github.com/FactomProject/netki-go-partner-client (download)
github.com/FactomProject/go-simplejson (download)
With vx=off:
[root@f31 ~]# go get -v -d github.com/FactomProject/factom
github.com/FactomProject/factom (download)
github.com/FactomProject/btcutil (download)
github.com/FactomProject/ed25519 (download)
github.com/FactomProject/go-bip32 (download)
github.com/FactomProject/basen (download)
github.com/FactomProject/btcutilecc (download)
get "golang.org/x/crypto/ripemd160": found meta tag get.metaImport{Prefix:"golang.org/x/crypto", VCS:"git", RepoRoot:"https://go.googlesource.com/crypto"} at //golang.org/x/crypto/ripemd160?go-get=1
get "golang.org/x/crypto/ripemd160": verifying non-authoritative meta tag
golang.org/x/crypto (download)
github.com/FactomProject/go-bip39 (download)
github.com/FactomProject/go-bip44 (download)
github.com/FactomProject/netki-go-partner-client (download)
github.com/FactomProject/go-simplejson (download)
That should be sufficient to identify the instruction. Might take some time, though. E.g.,
the HASH calculation in the kernel works just fine.
--
Thanks,
David / dhildenb
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1847232
Title:
qemu TCG in s390x mode issue with calculating HASH
Status in QEMU:
New
Bug description:
When using go on s390x on Debian x64 (buster) (host) and debian s390x
(sid) (guest) I run into the following problem :
The following occurs while trying to build a custom project :
go: github.com/FactomProject/basen@v0.0.0-20150613233007-fe3947df716e:
Get
https://proxy.golang.org/github.com/%21factom%21project/basen/@v/v0.0.0-20150613233007-fe3947df716e.mod:
local error: tls: bad record MAC
Doing a git bisect I find that this problem only occurs on and after
commit 08ef92d556c584c7faf594ff3af46df456276e1b
Before that commit, all works fine. Past this commit, build always
fails.
Without any proof, It looks like a hash calculation bug related to
using z/Arch vector facilities...
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1847232/+subscriptions
next prev parent reply other threads:[~2019-10-14 10:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 11:19 [Bug 1847232] [NEW] qemu TCG in s390x mode issue with calculating HASH Ivan Warren via
2019-10-08 12:11 ` Cornelia Huck
2019-10-08 13:35 ` David Hildenbrand
2019-10-08 13:35 ` David Hildenbrand
2019-10-08 14:11 ` Ivan Warren
2019-10-08 14:11 ` Ivan Warren via
2019-10-14 9:53 ` David Hildenbrand
2019-10-14 9:53 ` David Hildenbrand
2019-10-14 10:22 ` David Hildenbrand [this message]
2019-10-14 10:22 ` David Hildenbrand
2019-10-17 11:28 ` David Hildenbrand
2019-10-17 11:28 ` David Hildenbrand
2019-10-08 13:41 ` [Bug 1847232] " Thomas Huth
2019-10-14 10:48 ` Ivan Warren via
2019-10-14 11:02 ` Ivan Warren via
2019-10-18 16:17 ` David Hildenbrand
2019-10-23 9:05 ` David Hildenbrand
2019-10-23 9:37 ` Ivan Warren via
2019-10-23 10:05 ` David Hildenbrand
2019-10-23 10:34 ` Ivan Warren via
2020-01-23 5:57 ` Thomas Huth
2020-03-13 11:42 ` John Boero
2020-03-13 11:45 ` John Boero
2020-03-13 13:09 ` carlosedp
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=4115ee76-8f74-cce2-348b-44752cd402ed@redhat.com \
--to=david@redhat.com \
--cc=1847232@bugs.launchpad.net \
--cc=cohuck@redhat.com \
--cc=ivan@vmfacility.fr \
--cc=qemu-devel@nongnu.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).