* [Qemu-devel] sparc64 linux-user status
@ 2017-05-22 13:45 Alex Bennée
2017-05-25 7:43 ` Mark Cave-Ayland
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Alex Bennée @ 2017-05-22 13:45 UTC (permalink / raw)
To: Mark Cave-Ayland, Artyom Tarasenko, Richard Henderson
Cc: qemu-devel, Fam Zheng, Philippe Mathieu-Daudé
Hi,
While looking at some of the docker cross-build patches I thought I'd
checkout if I could still bootstrap some Debian linux-user images. I
made some tweaks to allow debootstrap to bootstrap from Debian's ports
to see if I could get the SPARC64 file-system up and running:
https://github.com/stsquad/qemu/commits/docker/sparc64-linux-user
However when I try to run it:
make docker-image-debian-sparc64-user V=1
It fails:
Step 4 : RUN /debootstrap/debootstrap --second-stage
---> Running in 2241c809c19f
*** longjmp causes uninitialized stack frame ***: /bin/sh terminated
Illegal instruction (core dumped)
*** longjmp causes uninitialized stack frame ***: /bin/sh terminated
Illegal instruction (core dumped)
*** longjmp causes uninitialized stack frame ***: /bin/sh terminated
Illegal instruction (core dumped)
I: Keyring file not available at /usr/share/keyrings/debian-archive-keyring.gpg; switching to https mirror https://deb.debian.org/debian
W: Failure trying to run: dpkg-deb -f /var/cache/apt/archives/dpkg_1.18.24_sparc64.deb Version
W: See //debootstrap/debootstrap.log for details
I: Installing core packages...
W: Failure trying to run: dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.43_sparc64.deb
W: See //debootstrap/debootstrap.log for details
Illegal instruction (core dumped)
The command '/bin/sh -c /debootstrap/debootstrap --second-stage' returned a non-zero code: 132
Although I can manually get the shell at least partially running:
14:43 last:125, alex@zen taken:25, git:docker/sparc64-linux-user, [/home/alex/lsrc/qemu/qemu.git]> docker run --rm -it 1084ed198b00 /bin/sh
# uname -a
[1] + Stopped (tty output) uname -a
# uname -a | cat
[2] + Stopped (tty output) uname -a | cat
# echo "hello"
hello
#
Bringing anything to the foreground hangs the window:
# fg
uname -a | cat
Linux 8cbf3e5e2234 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 sun4u GNU/Linux
/bin/sh: 4: fg: Cannot set tty process group (Inappropriate ioctl for device)
*** longjmp causes uninitialized stack frame ***: /bin/sh terminated
Which makes me think it might be a linux-user bug rather than the main
translation. Is this a tested combination? Any idea what the bug could be?
--
Alex Bennée
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] sparc64 linux-user status
2017-05-22 13:45 [Qemu-devel] sparc64 linux-user status Alex Bennée
@ 2017-05-25 7:43 ` Mark Cave-Ayland
2017-05-30 10:04 ` Alex Bennée
2017-05-25 7:56 ` Laurent Vivier
2017-05-30 10:40 ` Peter Maydell
2 siblings, 1 reply; 6+ messages in thread
From: Mark Cave-Ayland @ 2017-05-25 7:43 UTC (permalink / raw)
To: Alex Bennée, Artyom Tarasenko, Richard Henderson
Cc: Fam Zheng, qemu-devel, Philippe Mathieu-Daudé
On 22/05/17 14:45, Alex Bennée wrote:
> Hi,
>
> While looking at some of the docker cross-build patches I thought I'd
> checkout if I could still bootstrap some Debian linux-user images. I
> made some tweaks to allow debootstrap to bootstrap from Debian's ports
> to see if I could get the SPARC64 file-system up and running:
>
> https://github.com/stsquad/qemu/commits/docker/sparc64-linux-user
>
> However when I try to run it:
>
> make docker-image-debian-sparc64-user V=1
>
> It fails:
>
> Step 4 : RUN /debootstrap/debootstrap --second-stage
> ---> Running in 2241c809c19f
> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
> Illegal instruction (core dumped)
> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
> Illegal instruction (core dumped)
> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
> Illegal instruction (core dumped)
> I: Keyring file not available at /usr/share/keyrings/debian-archive-keyring.gpg; switching to https mirror https://deb.debian.org/debian
> W: Failure trying to run: dpkg-deb -f /var/cache/apt/archives/dpkg_1.18.24_sparc64.deb Version
> W: See //debootstrap/debootstrap.log for details
> I: Installing core packages...
> W: Failure trying to run: dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.43_sparc64.deb
> W: See //debootstrap/debootstrap.log for details
> Illegal instruction (core dumped)
> The command '/bin/sh -c /debootstrap/debootstrap --second-stage' returned a non-zero code: 132
>
> Although I can manually get the shell at least partially running:
>
> 14:43 last:125, alex@zen taken:25, git:docker/sparc64-linux-user, [/home/alex/lsrc/qemu/qemu.git]> docker run --rm -it 1084ed198b00 /bin/sh
> # uname -a
> [1] + Stopped (tty output) uname -a
> # uname -a | cat
> [2] + Stopped (tty output) uname -a | cat
> # echo "hello"
> hello
> #
>
> Bringing anything to the foreground hangs the window:
>
> # fg
> uname -a | cat
> Linux 8cbf3e5e2234 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 sun4u GNU/Linux
> /bin/sh: 4: fg: Cannot set tty process group (Inappropriate ioctl for device)
> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
>
> Which makes me think it might be a linux-user bug rather than the main
> translation. Is this a tested combination? Any idea what the bug could be?
Hmmm interesting. I tend to spend my time working on the system
emulation rather than linux-user section so to be honest it's not
something I test on a regular basis.
If you peek at the debian-sparc archives over the past year you'll see
there have been various SPARC64 linker bugs that have been fixed that
were causing corrupt binaries to be produced.
I see above that you're using a 4.4.0-78 kernel whereas John Paul's
latest ISO images are running 4.9.0-2 (and he's fairly good at getting
patches into ports) so without looking in detail my first thoughts are
that you could be trying to run older binaries affected by one or more
linker bugs? From memory the latest binaries are being published to sid
under debian-ports, but please do double-check against the debian-sparc
archives...
ATB,
Mark.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] sparc64 linux-user status
2017-05-22 13:45 [Qemu-devel] sparc64 linux-user status Alex Bennée
2017-05-25 7:43 ` Mark Cave-Ayland
@ 2017-05-25 7:56 ` Laurent Vivier
2017-05-30 9:49 ` Artyom Tarasenko
2017-05-30 10:40 ` Peter Maydell
2 siblings, 1 reply; 6+ messages in thread
From: Laurent Vivier @ 2017-05-25 7:56 UTC (permalink / raw)
To: Alex Bennée, Mark Cave-Ayland, Artyom Tarasenko, Richard Henderson
Cc: Fam Zheng, qemu-devel, Philippe Mathieu-Daudé
Le 22/05/2017 à 15:45, Alex Bennée a écrit :
> Hi,
>
> While looking at some of the docker cross-build patches I thought I'd
> checkout if I could still bootstrap some Debian linux-user images. I
> made some tweaks to allow debootstrap to bootstrap from Debian's ports
> to see if I could get the SPARC64 file-system up and running:
>
> https://github.com/stsquad/qemu/commits/docker/sparc64-linux-user
I was waiting that for a while, thanks!
>
> However when I try to run it:
>
> make docker-image-debian-sparc64-user V=1
>
> It fails:
>
> Step 4 : RUN /debootstrap/debootstrap --second-stage
> ---> Running in 2241c809c19f
> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
> Illegal instruction (core dumped)
> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
> Illegal instruction (core dumped)
> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
> Illegal instruction (core dumped)
> I: Keyring file not available at /usr/share/keyrings/debian-archive-keyring.gpg; switching to https mirror https://deb.debian.org/debian
> W: Failure trying to run: dpkg-deb -f /var/cache/apt/archives/dpkg_1.18.24_sparc64.deb Version
> W: See //debootstrap/debootstrap.log for details
> I: Installing core packages...
> W: Failure trying to run: dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.43_sparc64.deb
> W: See //debootstrap/debootstrap.log for details
> Illegal instruction (core dumped)
> The command '/bin/sh -c /debootstrap/debootstrap --second-stage' returned a non-zero code: 132
>
> Although I can manually get the shell at least partially running:
>
> 14:43 last:125, alex@zen taken:25, git:docker/sparc64-linux-user, [/home/alex/lsrc/qemu/qemu.git]> docker run --rm -it 1084ed198b00 /bin/sh
> # uname -a
> [1] + Stopped (tty output) uname -a
> # uname -a | cat
> [2] + Stopped (tty output) uname -a | cat
> # echo "hello"
> hello
> #
>
> Bringing anything to the foreground hangs the window:
>
> # fg
> uname -a | cat
> Linux 8cbf3e5e2234 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 sun4u GNU/Linux
> /bin/sh: 4: fg: Cannot set tty process group (Inappropriate ioctl for device)
> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
>
> Which makes me think it might be a linux-user bug rather than the main
> translation. Is this a tested combination? Any idea what the bug could be?
Do you know if the default CPU for linux-user is the good one for
debian-sparc64?
I used to run linux-user in a container, and I have this kind of problem
too. The last time I have checked I think it was because a floating
point instruction emulation failure. I don't know how works sparc64, but
on some architectures, FPU instructions are emulated by the kernel, so
it could explain why it works in softmmu mode and not in linux-user
mode: qemu doesn't emulate it because it relies on the kernel for that,
and in this case the kernel can't.
Laurent
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] sparc64 linux-user status
2017-05-25 7:56 ` Laurent Vivier
@ 2017-05-30 9:49 ` Artyom Tarasenko
0 siblings, 0 replies; 6+ messages in thread
From: Artyom Tarasenko @ 2017-05-30 9:49 UTC (permalink / raw)
To: Laurent Vivier
Cc: Alex Bennée, Mark Cave-Ayland, Richard Henderson, Fam Zheng,
qemu-devel, Philippe Mathieu-Daudé
On Thu, May 25, 2017 at 9:56 AM, Laurent Vivier <laurent@vivier.eu> wrote:
> Le 22/05/2017 à 15:45, Alex Bennée a écrit :
>> Hi,
>>
>> While looking at some of the docker cross-build patches I thought I'd
>> checkout if I could still bootstrap some Debian linux-user images. I
>> made some tweaks to allow debootstrap to bootstrap from Debian's ports
>> to see if I could get the SPARC64 file-system up and running:
>>
>> https://github.com/stsquad/qemu/commits/docker/sparc64-linux-user
>
> I was waiting that for a while, thanks!
>>
>> However when I try to run it:
>>
>> make docker-image-debian-sparc64-user V=1
>>
>> It fails:
>>
>> Step 4 : RUN /debootstrap/debootstrap --second-stage
>> ---> Running in 2241c809c19f
>> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
>> Illegal instruction (core dumped)
>> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
>> Illegal instruction (core dumped)
>> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
>> Illegal instruction (core dumped)
>> I: Keyring file not available at /usr/share/keyrings/debian-archive-keyring.gpg; switching to https mirror https://deb.debian.org/debian
>> W: Failure trying to run: dpkg-deb -f /var/cache/apt/archives/dpkg_1.18.24_sparc64.deb Version
>> W: See //debootstrap/debootstrap.log for details
>> I: Installing core packages...
>> W: Failure trying to run: dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.43_sparc64.deb
>> W: See //debootstrap/debootstrap.log for details
>> Illegal instruction (core dumped)
>> The command '/bin/sh -c /debootstrap/debootstrap --second-stage' returned a non-zero code: 132
>>
>> Although I can manually get the shell at least partially running:
>>
>> 14:43 last:125, alex@zen taken:25, git:docker/sparc64-linux-user, [/home/alex/lsrc/qemu/qemu.git]> docker run --rm -it 1084ed198b00 /bin/sh
>> # uname -a
>> [1] + Stopped (tty output) uname -a
>> # uname -a | cat
>> [2] + Stopped (tty output) uname -a | cat
>> # echo "hello"
>> hello
>> #
>>
>> Bringing anything to the foreground hangs the window:
>>
>> # fg
>> uname -a | cat
>> Linux 8cbf3e5e2234 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 sun4u GNU/Linux
>> /bin/sh: 4: fg: Cannot set tty process group (Inappropriate ioctl for device)
>> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
>>
>> Which makes me think it might be a linux-user bug rather than the main
>> translation. Is this a tested combination? Any idea what the bug could be?
>
> Do you know if the default CPU for linux-user is the good one for
> debian-sparc64?
Yes, it must be ok. Also the default CPU has a FPU, although I don't
know if it's used in linux-user mode.
> I used to run linux-user in a container, and I have this kind of problem
> too. The last time I have checked I think it was because a floating
> point instruction emulation failure. I don't know how works sparc64, but
> on some architectures, FPU instructions are emulated by the kernel, so
> it could explain why it works in softmmu mode and not in linux-user
> mode: qemu doesn't emulate it because it relies on the kernel for that,
> and in this case the kernel can't.
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] sparc64 linux-user status
2017-05-25 7:43 ` Mark Cave-Ayland
@ 2017-05-30 10:04 ` Alex Bennée
0 siblings, 0 replies; 6+ messages in thread
From: Alex Bennée @ 2017-05-30 10:04 UTC (permalink / raw)
To: Mark Cave-Ayland
Cc: Artyom Tarasenko, Richard Henderson, Fam Zheng, qemu-devel,
Philippe Mathieu-Daudé
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> writes:
> On 22/05/17 14:45, Alex Bennée wrote:
>
>> Hi,
>>
>> While looking at some of the docker cross-build patches I thought I'd
>> checkout if I could still bootstrap some Debian linux-user images. I
>> made some tweaks to allow debootstrap to bootstrap from Debian's ports
>> to see if I could get the SPARC64 file-system up and running:
>>
>> https://github.com/stsquad/qemu/commits/docker/sparc64-linux-user
>>
>> However when I try to run it:
>>
>> make docker-image-debian-sparc64-user V=1
>>
>> It fails:
>>
>> Step 4 : RUN /debootstrap/debootstrap --second-stage
>> ---> Running in 2241c809c19f
>> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
>> Illegal instruction (core dumped)
>> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
>> Illegal instruction (core dumped)
>> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
>> Illegal instruction (core dumped)
>> I: Keyring file not available at /usr/share/keyrings/debian-archive-keyring.gpg; switching to https mirror https://deb.debian.org/debian
>> W: Failure trying to run: dpkg-deb -f /var/cache/apt/archives/dpkg_1.18.24_sparc64.deb Version
>> W: See //debootstrap/debootstrap.log for details
>> I: Installing core packages...
>> W: Failure trying to run: dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.43_sparc64.deb
>> W: See //debootstrap/debootstrap.log for details
>> Illegal instruction (core dumped)
>> The command '/bin/sh -c /debootstrap/debootstrap --second-stage' returned a non-zero code: 132
>>
>> Although I can manually get the shell at least partially running:
>>
>> 14:43 last:125, alex@zen taken:25, git:docker/sparc64-linux-user, [/home/alex/lsrc/qemu/qemu.git]> docker run --rm -it 1084ed198b00 /bin/sh
>> # uname -a
>> [1] + Stopped (tty output) uname -a
>> # uname -a | cat
>> [2] + Stopped (tty output) uname -a | cat
>> # echo "hello"
>> hello
>> #
>>
>> Bringing anything to the foreground hangs the window:
>>
>> # fg
>> uname -a | cat
>> Linux 8cbf3e5e2234 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 sun4u GNU/Linux
>> /bin/sh: 4: fg: Cannot set tty process group (Inappropriate ioctl for device)
>> *** longjmp causes uninitialized stack frame ***: /bin/sh terminated
>>
>> Which makes me think it might be a linux-user bug rather than the main
>> translation. Is this a tested combination? Any idea what the bug could be?
>
> Hmmm interesting. I tend to spend my time working on the system
> emulation rather than linux-user section so to be honest it's not
> something I test on a regular basis.
>
> If you peek at the debian-sparc archives over the past year you'll see
> there have been various SPARC64 linker bugs that have been fixed that
> were causing corrupt binaries to be produced.
>
> I see above that you're using a 4.4.0-78 kernel whereas John Paul's
> latest ISO images are running 4.9.0-2 (and he's fairly good at getting
> patches into ports) so without looking in detail my first thoughts are
> that you could be trying to run older binaries affected by one or more
> linker bugs?
Hmm of course the kernel version relates to my host kernel. Could guest
code be dependant on reported kernel version? That seems a little risky
to me.
> From memory the latest binaries are being published to sid
> under debian-ports, but please do double-check against the debian-sparc
> archives...
OK I shall have a look.
>
>
> ATB,
>
> Mark.
--
Alex Bennée
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] sparc64 linux-user status
2017-05-22 13:45 [Qemu-devel] sparc64 linux-user status Alex Bennée
2017-05-25 7:43 ` Mark Cave-Ayland
2017-05-25 7:56 ` Laurent Vivier
@ 2017-05-30 10:40 ` Peter Maydell
2 siblings, 0 replies; 6+ messages in thread
From: Peter Maydell @ 2017-05-30 10:40 UTC (permalink / raw)
To: Alex Bennée
Cc: Mark Cave-Ayland, Artyom Tarasenko, Richard Henderson, Fam Zheng,
qemu-devel, Philippe Mathieu-Daudé
On 22 May 2017 at 14:45, Alex Bennée <alex.bennee@linaro.org> wrote:
> While looking at some of the docker cross-build patches I thought I'd
> checkout if I could still bootstrap some Debian linux-user images. I
> made some tweaks to allow debootstrap to bootstrap from Debian's ports
> to see if I could get the SPARC64 file-system up and running:
>
> https://github.com/stsquad/qemu/commits/docker/sparc64-linux-user
>
> However when I try to run it:
>
> make docker-image-debian-sparc64-user V=1
>
> It fails
Doesn't surprise me very much, IIRC the last time I tried the
sparc linux-user code it was a bit broken (worked for simple
stuff, not for more complicated stuff). My pull tests include
a basic "can we run ls" for sparc64, but nothing more.
(In particular SPARC is BE so if we messed up on anything that
needs struct endianness swapping it will hit it.)
thanks
-- PMM
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-05-30 10:40 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-22 13:45 [Qemu-devel] sparc64 linux-user status Alex Bennée
2017-05-25 7:43 ` Mark Cave-Ayland
2017-05-30 10:04 ` Alex Bennée
2017-05-25 7:56 ` Laurent Vivier
2017-05-30 9:49 ` Artyom Tarasenko
2017-05-30 10:40 ` Peter Maydell
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.