Package: sasl2-bin
Version: 2.1.28+dfsg1-5
X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org
The openldap build on an m68k qemu-user buildd cannot install sasl2-bin in the
chroot:
[…]
Setting up pkg-config:m68k (1.8.1-1) ...
Setting up libsasl2-2:m68k (2.1.28+dfsg1-5) ...
Setting up
Hi Laurent!
On Mon, 2023-06-12 at 16:58 +0200, Laurent Vivier wrote:
> These changes to the linux package are needed to create kernel .debs
> and .udebs with all the needed modules for the QEMU m68k virt machine.
>
> These is also needed to create the debian-installer that will be u
+## sound/virtio/Kconfig
> +##
> +CONFIG_SND_VIRTIO=m
I think it should be enough to provide a partial configuration only
which overrides the CONFIG defines from the generic kernel.
Have a look at the sparc* kernel (referenced from config/sparc64/defines) for
example:
> https://sa
These changes to the linux package are needed to create kernel .debs
and .udebs with all the needed modules for the QEMU m68k virt machine.
These is also needed to create the debian-installer that will be usable
with the virt machine.
Signed-off-by: Laurent Vivier
---
debian/config/m68k
present on qemu-user [1]. Both m68k and sh4 use qemu-based
buildds which is why these architectures are affected by this problem.
Upstream has come up with a workaround for the problem which is present in
newer versions of the b2 utility [2].
Could you backport the patch to boost1.74 so that the builds
Hi,
the next m68k developer chat will be on
Friday 6th November 2020, 19:00 H CET (18:00H / 06:00 PM UTC)
at
<https://meet.m68k.info/m68k> (will be online before the meeting
starts)
Feature 1: New m68k target in Qemu - Laurent Vivier will talk
about the
existing QEMU Quadra 800 emu
- 1)) == 0' failed.
> qemu: uncaught target signal 6 (Aborted) - core dumped
> Aborted
> (sid-m68k-sbuild)root@epyc:/#
It's actually a bug in libgc and was fixed here [1].
Adrian
> [1]
> https://github.com/ivmai/bdwgc/commit/b55459ad47d9aaa75c9a4b0f99a3b867592ab8e0
--
.&#
Hi Adrian,
On Tue, Sep 22, 2020 at 5:23 PM John Paul Adrian Glaubitz
wrote:
> On 9/22/20 3:27 PM, John Paul Adrian Glaubitz wrote:
> >>> That a typical bad alignment check. It should use __alignof__, not
> >>> sizeof.
> >>
> >> Aha, I was assuming something like that already but I wasn't sure si
lp.
Hmm, now it fails with __alignof__():
(sid-m68k-sbuild)root@epyc:/# debfoster -f
debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load:
Assertion `((size_t)addr & (__alignof__(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumpe
On 9/22/20 3:27 PM, John Paul Adrian Glaubitz wrote:
>>> That a typical bad alignment check. It should use __alignof__, not
>>> sizeof.
>>
>> Aha, I was assuming something like that already but I wasn't sure since
>> libatomic-ops wasn't
>> updated for a while in Debian [1].
>
> What would be th
On Sep 22 2020, John Paul Adrian Glaubitz wrote:
> root@pacman:~# debfoster
> debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31:
> AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
That a typical bad alignment check. It should use __alignof__, not
sizeof
On 9/22/20 3:24 PM, John Paul Adrian Glaubitz wrote:
> On 9/22/20 3:22 PM, Andreas Schwab wrote:
>> On Sep 22 2020, John Paul Adrian Glaubitz wrote:
>>
>>> root@pacman:~# debfoster
>>> debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31:
>>> AO_load: Assertion `((size_t)addr & (s
On 9/22/20 3:22 PM, Andreas Schwab wrote:
> On Sep 22 2020, John Paul Adrian Glaubitz wrote:
>
>> root@pacman:~# debfoster
>> debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31:
>> AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
>
> That a typical bad al
Hi!
Could someone install the "debfoster" command please on real hardware and test
whether
it crashes like it does on qemu?
root@pacman:~# debfoster
debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load:
Assertion `((size_t)addr & (sizeof(*addr) - 1)
On Sun, 20 Sep 2020, Eero Tamminen wrote:
> Because specifying seccomp filters for containers is so trivial, there
> are going to be all kind of containers which seccomp rules allow only
> syscalls they're using _right now_.
>
If so, it means glibc-2.28 broke those filters. Regressions caused
Hi,
On 9/20/20 2:03 AM, Finn Thain wrote:
Thorsten Glaser wrote, quoting Aurelien Jarno in
https://bugs.debian.org/916276
The patch is basically replacing the getdents64 syscall by the getdents
one. This means that applying this patch would make debian differ with
regards to other distribution
Thorsten Glaser wrote, quoting Aurelien Jarno in
https://bugs.debian.org/916276
> The patch is basically replacing the getdents64 syscall by the getdents
> one. This means that applying this patch would make debian differ with
> regards to other distributions in the syscalls that are used for t
Dixi quod…
>Michael Tokarev dixit:
>> 17.09.2020 10:56, John Paul Adrian Glaubitz wrote:
>>> There is also an important glibc patch necessary to unbreak qemu-user
>>> that still hasn't been merged in glibc upstream or in Debian's glibc
>>> package [1,
On Thu, 17 Sep 2020, Thorsten Glaser wrote:
>
> >>>> Well, to be honest, you should never use the Debian QEMU package.
> >>>> It's almost always very outdated and would lack important patches
> >>>> like these. It's easier to use lo
laubitz dixit:
>>>>>
>>>>>> That’s been fixed upstream and can be configured with the
>>>>>> qemu-binfmt.sh script and the option “preserved=yes”.
>>>>>
>>>>> $ locate qemu-binfmt.sh | wc
>>>>> 0
17.09.2020 10:56, John Paul Adrian Glaubitz wrote:
> On 9/17/20 9:49 AM, Michael Tokarev wrote:
>> You should not use upstream git of qemu, since it too lacks
>> important patches like this, - please don't suggest people
>> to use outdated sources.. :)
>
> I think
On 9/17/20 9:49 AM, Michael Tokarev wrote:
> You should not use upstream git of qemu, since it too lacks
> important patches like this, - please don't suggest people
> to use outdated sources.. :)
I think I'm one of the heaviest users of QEMU inside Debian and if
I had st
17.09.2020 10:08, John Paul Adrian Glaubitz wrote:
> On 9/16/20 8:42 PM, Thorsten Glaser wrote:
>> John Paul Adrian Glaubitz dixit:
>>
>>> That’s been fixed upstream and can be configured with the
>>> qemu-binfmt.sh script and the option “preserved=yes”.
&
On 9/16/20 8:42 PM, Thorsten Glaser wrote:
> John Paul Adrian Glaubitz dixit:
>
>> That’s been fixed upstream and can be configured with the
>> qemu-binfmt.sh script and the option “preserved=yes”.
>
> $ locate qemu-binfmt.sh | wc
> 0 0 0
Well, to
time and helps with chroots and the like.
>
> BTW, it turned out not that simple as I thought, the wrapper as
> used by SUSE is still needed - or else it's impossible to distinguish
> between direct qemu-foo invocation and the same invocation using
> binfmt.
The patch tha
as I thought, the wrapper as
used by SUSE is still needed - or else it's impossible to distinguish
between direct qemu-foo invocation and the same invocation using
binfmt.
/mjt
On 9/16/20 8:16 PM, Laurent Vivier wrote:
> Yes, it's not fixed.
>
> For 10 months I'm trying to have a patch merged into the kernel to be
> able to detect if PRESERVE flag is set or not.
>
> https://patchwork.kernel.org/patch/11354255/
Is that an extension to t
On 9/16/20 7:53 PM, Michael Tokarev wrote:
> Where it's been fixed? current git version of scripts/qemu-binfmt-conf.sh
> does not have 'preserved' option, and if the P flag is set when registering
> binfmt, the kernel will _prepend_ additional argv[0] element which is n
John Paul Adrian Glaubitz dixit:
>That’s been fixed upstream and can be configured with the
>qemu-binfmt.sh script and the option “preserved=yes”.
$ locate qemu-binfmt.sh | wc
0 0 0
Also, why didn’t you fix that on the m68k and sh4 qemu buildds then? ;-)
Meow,
//mir
• if argv[1] is "-" it just outputs argv[0] and argv[1]
>>> • otherwise it also execve(2)s argv[1] with its argv[0] set to "meow"
>>
>> That’s been fixed upstream and can be configured with the qemu-binfmt.sh
>> script and the option “preserved=yes”.
>
> W
t also execve(2)s argv[1] with its argv[0] set to "meow"
>
> That’s been fixed upstream and can be configured with the qemu-binfmt.sh
> script and the option “preserved=yes”.
Where it's been fixed? current git version of scripts/qemu-binfmt-conf.sh
does not have 'p
n fixed upstream and can be configured with the qemu-binfmt.sh script
and the option “preserved=yes”.
Also, this would be an upstream bug, not a Debian bug :).
Adrian
Package: qemu-user
Version: 1:5.1+dfsg-4
Severity: important
X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org
I’m attaching a test program that does the following:
• if argv[1] is "-" it just outputs argv[0] and argv[1]
• otherwise it also execve(2)s argv[1] with its argv
t;>
>>
>> IN:
>> 0x00016a2c: fmovel #0,%fpsr
>> Disassembler disagrees with translator over instruction decoding
>> Please report this to qemu-de...@nongnu.org
>>
>> OP:
>> ld_i32 tmp0,env,$0xfff0
>> movi_i32 t
isassembler disagrees with translator over instruction decoding
> Please report this to qemu-de...@nongnu.org
>
> OP:
> ld_i32 tmp0,env,$0xfff0
> movi_i32 tmp1,$0x0
> brcond_i32 tmp0,tmp1,lt,$L0
>
> 00016a2c
> movi_i32 PC,$0x16a2c
> mov
le to reproduce the problem
with logs enabled. Apparently the instruction is not decoded correctly:
IN:
0x00016a2c: fmovel #0,%fpsr
Disassembler disagrees with translator over instruction decoding
Please report this to qemu-de...@nongnu.org
OP:
ld_i32 tmp0,env,$0x
Hi Michael!
On 5/30/20 1:49 AM, Michael Schmitz wrote:
> Can you try to run that R binary on a real 060 or 040?
Works fine on elgar:
root@elgar:~> R
R version 4.0.1 beta (2020-05-27 r78593) -- "See Things Now"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: m68k-unknown-l
e (and will clear the control
> register in the next instruction). That should not cause an address error.
>
> Can you try to run that R binary on a real 060 or 040?
It could be interesting to enable the TCG trace in QEMU.
If you have access to the QEMU monitor use the following command b
se an address error.
Can you try to run that R binary on a real 060 or 040?
Cheers,
Michael
Am 27.05.2020 um 21:14 schrieb John Paul Adrian Glaubitz:
Hi!
I just ran into the following kernel crash - which is reproducible - when trying
to build the R package r-cran-phangorn on qemu-m68k-s
On 5/27/20 11:14 AM, John Paul Adrian Glaubitz wrote:
> I just ran into the following kernel crash - which is reproducible - when
> trying
> to build the R package r-cran-phangorn on qemu-m68k-system on Linux 5.6.7.
It can reproduce by just running "R"
# R
(ke
Hi!
I just ran into the following kernel crash - which is reproducible - when trying
to build the R package r-cran-phangorn on qemu-m68k-system on Linux 5.6.7.
Adrian
[ 56.64] *** ADDRESS ERROR *** FORMAT=2
[ 56.64] Current process id is 728
[ 56.64] BAD KERNEL TRAP
..I've resend my message to mailing lists w/o attachment...
> > Screenshot is attached. (I hope mailing list will pass it)
> That's pretty neat. I would have never expected it to work without
> further changes to the driver and qemu. I'm positively surprised.
Yes, I w
I've successfully started Xorg on the Sid/QEMU.
It seems Quadra 800 framebuffer supports only limited
set of resolution and color set modes.
According to Quadra 800 page at Everymac
https://everymac.com/systems/apple/mac_quadra/specs/mac_quadra_800.html
it supports
"With 1 MB of VRAM
On 5/20/20 12:04 AM, Alexander Voropay wrote:
> I've successfully started Xorg on the Sid/QEMU.
>
> It seems Quadra 800 framebuffer supports only limited
> set of resolution and color set modes.
>
> According to Quadra 800 page at Everymac
> https://everymac.com/syst
On Mon, 18 May 2020, Laurent Vivier wrote:
> Le 18/05/2020 à 09:46, John Paul Adrian Glaubitz a écrit :
> > On 5/18/20 9:44 AM, Alexander Voropay wrote:
> >> I'm trying to run Xorg server on the git QEMU on the current Sid.
> >> It fails on fb device setting
> &
It seems it's not depend on config.
Tried 800x600 frremebuffer in QEMU
X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-11-amd64 m68k Debian
Current Operating System: Linux quadra800 5.6.0-1-m68k #1 Debian
5.6.7-1 (2020-04-29) m68k
Kernel command
Le 18/05/2020 à 09:46, John Paul Adrian Glaubitz a écrit :
> On 5/18/20 9:44 AM, Alexander Voropay wrote:
>> I'm trying to run Xorg server on the git QEMU on the current Sid.
>> It fails on fb device setting
>>
>> QEMU graphic related options:
>> -g 1200x800x
On 5/18/20 9:44 AM, Alexander Voropay wrote:
> I'm trying to run Xorg server on the git QEMU on the current Sid.
> It fails on fb device setting
>
> QEMU graphic related options:
> -g 1200x800x24 -display gtk
>
> fd console works. /dev/fb0/ device works
> (i.e.
I'm trying to run Xorg server on the git QEMU on the current Sid.
It fails on fb device setting
QEMU graphic related options:
-g 1200x800x24 -display gtk
fd console works. /dev/fb0/ device works
(i.e. "cat /dev/urandom > /dev/fb0" fills "nubus-macfb"
with rand
Control: fixed -1 1:2.10.0-1
Control: fixed -1 1:3.1+dfsg-8+deb10u2
Control: fixed -1 1:3.1+dfsg-8+deb10u3
Control: fixed -1 1:4.2-1
Hi!
> # qemu-debootstrap --arch=m68k --keyring
> /usr/share/keyrings/debian-ports-archive-keyring.gpg --no-check-gpg
> --variant=buildd --exclude=
Le 03/01/2020 à 07:41, Carlos Rodrigues a écrit :
> Hi!
> I am wanting to study a little about 68k architecture, and for that I
> want to install Debian on QEmu but I am not getting it because I am
> getting the following error:
>
> $ qemu-system-m68k.exe -boot d -hda debi
laubitz wrote:
On 1/3/20 7:41 AM, Carlos Rodrigues wrote:
I am wanting to study a little about 68k architecture, and for that I want to
install
Debian on QEmu but I am not getting it because I am getting the following error:
$ qemu-system-m68k.exe -boot d -hda debian_68k.img --cdrom
debian-1
Hi!
On 1/3/20 12:00 PM, Carlos Rodrigues wrote:
> Anyway, I can't access this url: "https://wiki.debian.org/M68k/QemuSystemM68k";
>
> I get an error saying that I don't have permission to access the URL:
>
> "You are not allowed to access this!"
Do you happen to use a VPN to hide your identity?
On 1/3/20 7:41 AM, Carlos Rodrigues wrote:
> I am wanting to study a little about 68k architecture, and for that I want to
> install
> Debian on QEmu but I am not getting it because I am getting the following
> error:
>
> $ qemu-system-m68k.exe -boot d -hda debian_68k.img --cd
Hi!
I am wanting to study a little about 68k architecture, and for that I
want to install Debian on QEmu but I am not getting it because I am
getting the following error:
$ qemu-system-m68k.exe -boot d -hda debian_68k.img --cdrom
debian-10.0-m68k-NETINST-1.iso -m 2048 -cpu m68060 -smp 1 -net
On Sun, 15 Dec 2019, Geert Uytterhoeven wrote:
> Hi Brad,
>
> On Sun, Dec 15, 2019 at 3:19 AM Brad Boyer wrote:
> > We could probably emulate a fake NuBus card in qemu that is just
> > memory in the super slot space for that card. Can a regular driver add
> > RAM,
Hi Brad,
On Sun, Dec 15, 2019 at 3:19 AM Brad Boyer wrote:
> We could probably emulate a fake NuBus card in qemu that is just memory
> in the super slot space for that card. Can a regular driver add RAM, or
> would we have to detect that in the core code somewhere?
I think a regular d
On Sun, Dec 15, 2019 at 09:36:33AM +1100, Finn Thain wrote:
> I believe that the reason for the limitation is the Mac memory map, as
> Laurent pointed out in the issue tracker,
> https://github.com/vivier/qemu-m68k/issues/42
>
> It's theoretically possible to use NuBus slot
On Sat, 14 Dec 2019, John Paul Adrian Glaubitz wrote:
> Hi!
>
> When installing Debian/m68k inside qemu-m68k-system [1], we are
> currently limited to 1 GB of physical memory which is due to a limit in
> the Linux kernel as far as I know.
>
> However, I also know that
Hi!
When installing Debian/m68k inside qemu-m68k-system [1], we are currently
limited
to 1 GB of physical memory which is due to a limit in the Linux kernel as far
as I know.
However, I also know that it is possible to run the m68k kernel on Aranym with
up to 3.5 GB of RAM. Thus, I was
Hi!
I have created a quick setup guide which explains how to get Debian/m68k up and
running inside qemu-system-m68k, see [1].
When running on a relatively recent Core i7, the emulated will be clocked at
over 1 GHz (over 1.5 GHz in my case), so it's reasonably fast.
Adrian
> [
On Fri, Sep 20, 2019 at 08:57:39AM +0200, Geert Uytterhoeven wrote:
> Hi Adrian,
>
> On Fri, Sep 20, 2019 at 8:55 AM John Paul Adrian Glaubitz
> wrote:
> > Just discovered this morning that qemu is gaining emulation support for the
> > NeXT Cube, very cool:
> >
Hi Adrian,
On Fri, Sep 20, 2019 at 8:55 AM John Paul Adrian Glaubitz
wrote:
> Just discovered this morning that qemu is gaining emulation support for the
> NeXT Cube, very cool:
>
> > https://git.qemu.org/?p=qemu.git;a=commitdiff;h=956a78118bfc7fa512b03cbe8a77b9384c6d89f4
Nice! N
Hi!
Just discovered this morning that qemu is gaining emulation support for the
NeXT Cube, very cool:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=956a78118bfc7fa512b03cbe8a77b9384c6d89f4
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau
atch by Laurent Vivier.
Activate with:
# apt purge binfmt-support
# rm /usr/bin/qemu-m68k-static
# cp -av m68k-linux-user/qemu-m68k /usr/bin/qemu-m68k-static
# ./scripts/qemu-binfmt-conf.sh --systemd m68k --qemu-path /usr/bin
--qemu-suffix -static --credential yes --persistent yes
Then ju
and the interpreter pointing to the
> *-binfmt wrapper.
Laurent helped me debugging and the problem is that Debian has its own
binfmt-support
packages which competes with systemd-binfmt with the former not setting the
preserve
flag.
It works when writing the configuration into /proc manual
On Jul 10 2019, John Paul Adrian Glaubitz wrote:
>> That should fix it:
>>
>> https://github.com/openSUSE/qemu/commit/b9d571b22b86948586a3ee622a854b5fc694cc04
>> https://github.com/openSUSE/qemu/commit/3cec667753967b778563899cbd21cc2e617d4389
>
> That doesn'
> That should fix it:
>
> https://github.com/openSUSE/qemu/commit/b9d571b22b86948586a3ee622a854b5fc694cc04
> https://github.com/openSUSE/qemu/commit/3cec667753967b778563899cbd21cc2e617d4389
That doesn't work, unfortunately. At least, I cannot get it to work in Debian.
Bo
Hi!
On 7/8/19 6:18 PM, Niko Tyni wrote:
> This can be reproduced under for instance qemu-armhf with
>
> mkdir b && cd b && ../Configure -des -Dmksymlinks
>
> resulting in lots of 'Permission denied' errors when extracting cflags.SH
> because the scr
Source: glibc
Version: 2.28-2
Severity: important
Tags: patch
User: debian-68k@lists.debian.org
Usertags: m68k
Hi!
In 298d0e3129c0b5137f4989275b13fe30d0733c4d ("Consolidate Linux getdents{64}
implementation"), upstream made changes to the getdents{64} implementation
which breaks gli
Hi!
Just a short heads-up. I have updated the version of qemu-m68k on the
four qemu buildds (vs90~vs93) to use Lauren's master-dev branch [1],
git revision is 5e79823. I have added two patches from me to add the
socket calls 19 and 20 plus update the m68k syscall table for Linux
4.4 whic
John Paul Adrian Glaubitz dixit:
>> Even Andreas (whose message I read too late) said it was a known
>> kernel bug (can it be fixed, pretty please?).
>
>Yes, a bug in the m68k kernel. Which means something that needs
No, a bug in the Linux kernel. It also appears on amd64.
That is, Linux/amd64, n
t do you mean by consistency, you are using the wrong word.
There might be an issue with miscompiled code, but this would be
rather an issue with gcc than with the emulating environment.
Yes, qemu-m68k has some bugs. But those can be ironed out and
the best way to do it is to start actually using i
John Paul Adrian Glaubitz dixit:
>On 12/06/2015 04:52 PM, Thorsten Glaser wrote:
>> John Paul Adrian Glaubitz dixit:
>>
>>> And it's not that Aranym doesn't have it's own problem. I'm still seeing
>>> the issues with kswapd consuming over 50% CPU time from time to time
^^
>>
On 12/06/2015 04:52 PM, Thorsten Glaser wrote:
> John Paul Adrian Glaubitz dixit:
>
>> And it's not that Aranym doesn't have it's own problem. I'm still seeing
>> the issues with kswapd consuming over 50% CPU time from time to time
>> slowing down the emulated machine quite notably.
>
> Someone t
John Paul Adrian Glaubitz dixit:
>And it's not that Aranym doesn't have it's own problem. I'm still seeing
>the issues with kswapd consuming over 50% CPU time from time to time
>slowing down the emulated machine quite notably.
Someone told me on SO the other day that he had this bug on
an amd64 s
Le 06/12/2015 14:09, Andreas Schwab a écrit :
> Laurent Vivier writes:
>
>> I think qemu-m68k is emulating precisely the FPU. I've checked the
>> result of testfloat on qemu-m68k, and moreover I've compared the result
>> of softloat on my Quadra 800 (68040 FP
Laurent Vivier writes:
> I think qemu-m68k is emulating precisely the FPU. I've checked the
> result of testfloat on qemu-m68k, and moreover I've compared the result
> of softloat on my Quadra 800 (68040 FPU) against the result of qemu-m68k.
That doesn't implement Mot
John Paul Adrian Glaubitz writes:
> And it's not that Aranym doesn't have it's own problem. I'm still seeing
> the issues with kswapd consuming over 50% CPU time from time to time
> slowing down the emulated machine quite notably.
This is a known kernel bug, it can be worked around by writing 1
On 12/06/2015 12:13 PM, Laurent Vivier wrote:
> I think qemu-m68k is emulating precisely the FPU. I've checked the
> result of testfloat on qemu-m68k, and moreover I've compared the result
> of softloat on my Quadra 800 (68040 FPU) against the result of qemu-m68k.
>
&
act 80...) and can have
>>> some bugs (I didn't fix the NaN format for the moment).
>>
>> In this case, e.g. Python interpreters and related things (cffi/numpy?)
>> built on qemu-m68k may be broken.
>
> It looks like Python running *on* qemu-m68k is, at the very
102 6143 cas2l %d2,%d3,%d4,%d5,%a0@,@(%d6)
e2f8: 0efc a184 81c5 cas2l %d4,%d5,%d6,%d7,%a2@,%a0@
(sid-m68k-sbuild)root@z6:/# objdump --disassemble
/lib/m68k-linux-gnu/libpthread-2.19.so | grep cas2l
(sid-m68k-sbuild)root@z6:/#
See:
https://github.com/vivier/qemu-m68k/blob/680x0-v2.3.
On 12/05/2015 08:59 PM, Thorsten Glaser wrote:
> It looks like Python running *on* qemu-m68k is, at the very least,
> broken (probably precisely because it does funny things to the FPU):
That's not questionable use, it's a bug and it will not make me stop
use qemu-m68k as it i
mat for the moment).
>
>In this case, e.g. Python interpreters and related things (cffi/numpy?)
>built on qemu-m68k may be broken.
It looks like Python running *on* qemu-m68k is, at the very least,
broken (probably precisely because it does funny things to the FPU):
19:37⎜ mira: hast du eigentli
; In any case, TARGET_NR_sendmmsg and TARGET_NR_recvmmsg are not
> defined here:
>
>>
>
https://github.com/vivier/qemu-m68k/blob/680x0-v2.3.0/linux-user/m68k/syscall_nr.h
>
> According to the kernel sources, recvmmsg is defined as 371 and sendmmsg
> as 372:
>
>>
&g
user/syscall.c
I'm not sure actually why it's called "Socketcall". Is that an
offset in the syscall numbering?
In any case, TARGET_NR_sendmmsg and TARGET_NR_recvmmsg are not
defined here:
>
https://github.com/vivier/qemu-m68k/blob/680x0-v2.3.0/linux-user/m68k/syscall_nr.h
On Sat, 21 Nov 2015, John Paul Adrian Glaubitz wrote:
> On 11/20/2015 11:11 PM, John Paul Adrian Glaubitz wrote:
> >
> > A new gcc-5 with updated dependencies is following
> > tomorrow morning. Build takes ~10 hours with qemu-m68k.
>
> Uploaded.
>
> Build to
On 11/21/2015 11:54 AM, Finn Thain wrote:
> You would still need either Aranym or physical 68k hardware to test a
> Linux binary (that is, the kernel).
Don't worry, the hardware isn't going anywhere :).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
> On Nov 20, 2015, at 4:09 PM, John Paul Adrian Glaubitz
> wrote:
>
>> On 11/20/2015 03:58 PM, John Paul Adrian Glaubitz wrote:
>> The actual package source doesn't have it either.
>
> I'm building a patched version for 'unreleased' now.
Alright! This patch actually did the trick!
Thanks a l
Laurent Vivier writes:
> But this call is strange:
>
> prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024,
> rlim_max=RLIM64_INFINITY}) = 0
>
> according to man of prlimit (if prlimit64() has the same API):
>
> int prlimit(pid_t pid, int resource, const struct rlimit *new_limit,
>
On 11/20/2015 03:58 PM, John Paul Adrian Glaubitz wrote:
> The actual package source doesn't have it either.
I'm building a patched version for 'unreleased' now.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub.
John Paul Adrian Glaubitz writes:
> root@pacman:~> ruby2.2 --help
> Segmentation fault
Do you have this patch?
Index: ruby-2.2.3/thread_pthread.c
===
--- ruby-2.2.3.orig/thread_pthread.c
+++ ruby-2.2.3/thread_pthread.c
@@ -678,15 +
Le 20/11/2015 15:42, John Paul Adrian Glaubitz a écrit :
> On 11/20/2015 03:34 PM, Andreas Schwab wrote:
>> John Paul Adrian Glaubitz writes:
>>
>>> Now, running this with strace, I made a suspicious observation which
>>> might be related to the the segmentation fault:
>>>
>>> prlimit64(0, RLIMI
On 11/20/2015 03:51 PM, Andreas Schwab wrote:
> John Paul Adrian Glaubitz writes:
>
>> root@pacman:~> ruby2.2 --help
>> Segmentation fault
>
> Do you have this patch?
Apparently not:
>
http://anonscm.debian.org/cgit/collab-maint/ruby.git/tree/thread_pthread.c#n681
The actual package source do
o=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xef79c0d8} ---
Why do you think there is any relation between these two events?
> Now, my question is: Is prlimit64 supposed to be used on 32-bit hardware
> at all or might this be the result of ruby2.2 being compiled on
> qemu-m68k on an amd64 hos
in ruby_init_stack (addr=0xe680) at thread_pthread.c:719
#2 0x871a in ?? ()
#3 0xe680 in ?? ()
#4 0xe68c in ?? ()
#5 0xe690 in ?? ()
#6 0x0000 in ?? ()
(gdb)
>> Now, my question is: Is prlimit64 supposed to be used on 32-bit hardware
>> at all or might this
he prlimit64 syscall number is defined in m68k linux includes, it is
>> defined in qemu and thus it is allowed and managed. I don't understand
>> why it doesn't work on real machine. What is the kernel version used ?
>
> root@pacman:~> uname -a
> Linux pacman 3.
ght this syscall exists on 64-bit only.
>> As the prlimit64 syscall number is defined in m68k linux includes, it is
>> defined in qemu and thus it is allowed and managed. I don't understand
>> why it doesn't work on real machine. What is the kernel version used ?
>
On 11/20/2015 03:28 PM, Laurent Vivier wrote:
>> So, from your question I assume prlimit64 is not supposed to be present
>> in an m68k binary? I'll check what ruby does during configure.
>
> As the prlimit64 syscall number is defined in m68k linux includes, it is
> defi
Le 20/11/2015 15:09, John Paul Adrian Glaubitz a écrit :
> On 11/20/2015 03:07 PM, Geert Uytterhoeven wrote:
>>> Now, my question is: Is prlimit64 supposed to be used on 32-bit hardware
>>> at all or might this be the result of ruby2.2 being compiled on
>>> qemu-m6
1 - 100 of 133 matches
Mail list logo
