On 2024-08-23 07:58, Dave Vasilevsky wrote:
> On 2024-08-23 03:16, John Paul Adrian Glaubitz wrote:
>> It should be disabled on m68k and sh by default as well.
>
> Sure, I can change that. What's the reasoning, so I can explain in my commit
> message?
Oh I don't think m68k even has ARCH_SUPPORTS
On 2024-08-23 03:16, John Paul Adrian Glaubitz wrote:
> It should be disabled on m68k and sh by default as well.
Sure, I can change that. What's the reasoning, so I can explain in my commit
message?
-Dave
y
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 007bab9f2a0e..aa4666bb9e9c 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2087,6 +2087,9 @@ config ARCH_SUPPORTS_KEXEC_JUMP
> config ARCH_SUPPORTS_CRASH_DUMP
> def_bool X86_64 || (X86_32 &&
f --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
index 6c34e63c88ff..4d111f871951 100644
--- a/kernel/Kconfig.kexec
+++ b/kernel/Kconfig.kexec
@@ -97,7 +97,7 @@ config KEXEC_JUMP
config CRASH_DUMP
bool "kernel crash dumps"
- default y
+ default ARCH_DEFAULT_CR
> default "0x0200" if PPC_BOOK3S && CRASH_DUMP && !NONSTATIC_KERNEL
> default "0x"
I think the architecture does support crash dumps, but I think the kernel has to
be booted from kexec in this case. Booting a kernel with CRASH_
Hi Baoquan,
On Wed, 2024-01-24 at 13:12 +0800, Baoquan He wrote:
> By splitting CRASH_RESERVE and VMCORE_INFO out from CRASH_CORE, cleaning
> up the dependency of FA_DMUMP on CRASH_DUMP, and moving crash codes from
> kexec_core.c to crash_core.c, now we can rearrange CRASH_DUMP to
&g
On Thu, Feb 29, 2024 at 7:07 PM Casey C wrote:
>
> Hello,
>
> All versions of LibreOffice that I've tested after 7.3.5 appear to have
> a bug which causes the application to crash when attempting to open a
> previously saved document.
>
> When running via gdb,
Hello,
All versions of LibreOffice that I've tested after 7.3.5 appear to have
a bug which causes the application to crash when attempting to open a
previously saved document.
When running via gdb, the application ends with the following output:
"Thread 1 "soffice.bin&q
Source: mariadb
Version: 1:10.11.1-1
Tags: upstream, confirmed, help, ftbfs
User: debian-powerpc@lists.debian.org
Usertags: ppc64
X-Debbugs-CC: debian-powerpc@lists.debian.org
Builds on ppc64 pass but the testsuite that validates that binary
works failed with:
Control: tags -1 + fixed-upstream
This should now be fixed in VLC master branch. I can try to backport but it
won't be so straightforward.
--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma
brièveté.
ynamic_mt_modes" actually did the trick, the
> host is no longer
> > crashing. However, I have observed on two occasions now that the build
> VM is just suddenly
> > off as if someone has shut it down using the "force-off" option in the
> virt-manager user
have observed on two occasions now that the build VM is
> just suddenly
> off as if someone has shut it down using the "force-off" option in the
> virt-manager user
> interface.
Just as a heads-up. Ever since I set
echo 0 > /sys/module/kvm_hv/parameters/d
Hi Michael!
On 1/9/22 23:17, John Paul Adrian Glaubitz wrote:
> On 1/7/22 12:20, John Paul Adrian Glaubitz wrote:
>>> Can you separately test with (on the host):
>>>
>>> # echo 0 > /sys/module/kvm_hv/parameters/dynamic_mt_modes
>>
>> I'm trying to turn off "dynamic_mt_modes" first and see if that
Hi Michael!
On 1/7/22 12:20, John Paul Adrian Glaubitz wrote:
>> Can you separately test with (on the host):
>>
>> # echo 0 > /sys/module/kvm_hv/parameters/dynamic_mt_modes
>
> I'm trying to turn off "dynamic_mt_modes" first and see if that makes any
> difference.
>
> I will report back.
So f
Hi Michael!
On 1/6/22 11:58, Michael Ellerman wrote:
>> We're currently running 5.15.x on the host system and the guests and the
>> testsuite
>> for gcc-9 still reproducibly kills the KVM host.
>
> Have you been able to try the different -smp options I suggested?
>
> Can you separately test wit
kvm_hv/parameters/dynamic_mt_modes
cheers
> On 11/1/21 07:53, Michael Ellerman wrote:
>> Sure, will give that a try.
>>
>> I was able to crash my machine over the weekend, building openjdk, but I
>> haven't been able to reproduce it for ~24 hours now (I didn't chan
ill give that a try.
>
> I was able to crash my machine over the weekend, building openjdk, but I
> haven't been able to reproduce it for ~24 hours now (I didn't change
> anything).
>
>
> Can you try running your guests with no SMT threads?
>
> I think one of
On Fri, Oct 29, 2021 at 02:33:12PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Nicholas!
>
> On 10/29/21 02:41, Nicholas Piggin wrote:
> > Soft lockup should mean it's taking timer interrupts still, just not
> > scheduling. Do you have the hard lockup detector enabled as well? Is
> > there anyth
ort of monitoring for capturing the
> output
> of the serial console non-interactively? This way I would be able to capture
> the
> crash besides what I have seen above.
I am pretty sure you can run something like
script ipmitool
to capture output indefinitely, and the same inside screen on a remote
machine.
Thanks
Michal
Hi Michael!
On 11/1/21 08:37, John Paul Adrian Glaubitz wrote:
> I made another experiment and upgraded the host to 5.15-rc7 which contains
> your
> fixes and made the guests build gcc-10. Interestingly, this time, the gcc-10
> build crashed the guest but didn't manage to crash
Hi Michael!
On 11/1/21 07:53, Michael Ellerman wrote:
> Sure, will give that a try.
>
> I was able to crash my machine over the weekend, building openjdk, but I
> haven't been able to reproduce it for ~24 hours now (I didn't change
> anything).
I made another experiment
d --arch=powerpc --no-arch-all gcc-10_10.3.0-12.dsc
> $ sbuild -d sid --arch=ppc64 --no-arch-all gcc-10_10.3.0-12.dsc
Sure, will give that a try.
I was able to crash my machine over the weekend, building openjdk, but I
haven't been able to reproduce it for ~24 hours now (I didn't cha
Hi Michael!
On 10/28/21 08:39, Michael Ellerman wrote:
> That completed fine on my BE VM here.
>
> I ran these in two tmux windows:
> $ sbuild -d sid --arch=powerpc --no-arch-all gcc-11_11.2.0-10.dsc
> $ sbuild -d sid --arch=ppc64 --no-arch-all gcc-11_11.2.0-10.dsc
Could you try gcc-10 inste
el: [14110.585534] LR [7fff92bc5e90]
0x7fff92bc5e90
> Could you try a sysrq+w to get a trace of blocked tasks?
Not sure how to send a magic sysrequest over the IPMI serial console. Any idea?
> Are you able to shut down the guests and exit qemu normally?
Not after the crash. I have to hard-r
Excerpts from John Paul Adrian Glaubitz's message of October 29, 2021 12:05 am:
> Hi Michael!
>
> On 10/28/21 13:20, John Paul Adrian Glaubitz wrote:
>> It seems I also can no longer reproduce the issue, even when building the
>> most problematic
>> packages and I think we should consider it fixe
> report
> to oss-security that the machine seems to be stable again, the issue showed
> up :(.
Do you know whether IPMI features any sort of monitoring for capturing the
output
of the serial console non-interactively? This way I would be able to capture the
crash besides what
Hi Michael!
On 10/28/21 13:20, John Paul Adrian Glaubitz wrote:
> It seems I also can no longer reproduce the issue, even when building the
> most problematic
> packages and I think we should consider it fixed for now. I will keep
> monitoring the server,
> of course, and will let you know in ca
Hello!
On 10/28/21 15:52, John Paul Adrian Glaubitz wrote:
> I am not sure what triggered my previous crash but I don't think it's related
> to this
> particular bug. I will keep monitoring the server in any case and open a new
> bug report
> in case I'm running
> server and let
> the build daemons do their work over night.
I have done thorough testing and I'm no longer seeing the problem with the
patched kernel.
I am not sure what triggered my previous crash but I don't think it's related
to this
particular bug. I will keep monitor
Hi Michael!
On 10/28/21 08:39, Michael Ellerman wrote:
>>> No, I will try that now.
>
> That completed fine on my BE VM here.
>
> I ran these in two tmux windows:
> $ sbuild -d sid --arch=powerpc --no-arch-all gcc-11_11.2.0-10.dsc
> $ sbuild -d sid --arch=ppc64 --no-arch-all gcc-11_11.2.0-10
which
>>>> was building glibc, that passes for me with a patched host.
>>>
>>> Did you manage to crash the unpatched host?
>>
>> Yes, the parallel builds of glibc you described crashed the unpatched
>> host 100% reliably for me.
>
> OK, that i
John Paul Adrian Glaubitz writes:
> Hi Michael!
>
> On 10/27/21 07:30, Michael Ellerman wrote:
>> I did test the repro case you gave me before (in the bugzilla), which
>> was building glibc, that passes for me with a patched host.
>
> Did you manage to crash the unpatch
that passes for me with a patched host.
>>
>> Did you manage to crash the unpatched host?
>
> Yes, the parallel builds of glibc you described crashed the unpatched
> host 100% reliably for me.
OK, that is very good news!
> I also have a standalone reproducer I'll send y
Hi Michael!
On 10/27/21 07:30, Michael Ellerman wrote:
> I did test the repro case you gave me before (in the bugzilla), which
> was building glibc, that passes for me with a patched host.
Did you manage to crash the unpatched host? If the unpatched host crashes
for you but the patched d
John Paul Adrian Glaubitz writes:
> Hi Michael!
Hi Adrian,
Thanks for testing ...
>> The Linux kernel for powerpc since v5.2 has a bug which allows a
>> malicious KVM guest to crash the host, when the host is running on
>> Power8.
>>
>> Only machines using
Excerpts from John Paul Adrian Glaubitz's message of October 26, 2021 6:48 pm:
> Hi Michael!
>
>> The Linux kernel for powerpc since v5.2 has a bug which allows a
>> malicious KVM guest to crash the host, when the host is running on
>> Power8.
>>
>> On
Hi Michael!
> The Linux kernel for powerpc since v5.2 has a bug which allows a
> malicious KVM guest to crash the host, when the host is running on
> Power8.
>
> Only machines using Linux as the hypervisor, aka. KVM, powernv or bare
> metal, are affected by the bug. Machines r
On 9/29/21 00:36, Cameron MacPherson wrote:
> i can confirm that the ppc64 snapshot packages work without illegal
> instructions
Comparing the build logs, it seems that this an issue with the newer version
of autoconf that was used to build version 3.4.2-2. Looking at the log for
3.4.2-2, a lot of
i can confirm that the ppc64 snapshot packages work without illegal
instructions
On Tue, Sep 28, 2021 at 12:54 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> Hi!
>
> On 9/28/21 21:34, John Paul Adrian Glaubitz wrote:
> > OK. I'm regenerating the chroots on the build servers
On 9/28/21 22:27, John Paul Adrian Glaubitz wrote:
> Yes. And this is not acceptable because they are manipulating the baseline.
And just for confirmation. After closely inspecting the build log, it becomes
obvious that "-mcpu=power8" is actually passed to GCC during build.
Adrian
--
.''`. Jo
On Tue, Sep 28, 2021 at 10:27:59PM +0200, John Paul Adrian Glaubitz wrote:
> Yes. And this is not acceptable because they are manipulating the baseline.
>
> Thanks for catching this. This is our bug!
I would be surprised if powerpc is the only architecture bitten by this.
What is i386 being compi
On Tue, Sep 28, 2021 at 04:26:04PM -0400, Lennart Sorensen wrote:
> On Tue, Sep 28, 2021 at 09:34:23PM +0200, John Paul Adrian Glaubitz wrote:
> > OK. I'm regenerating the chroots on the build servers now and then
> > trigger another rebuild of the package. If that still doesn't help,
> > we know t
On 9/28/21 22:26, Lennart Sorensen wrote:
> Would this be a problem:
>
> powerpc*)
> cputype=`((grep cpu /proc/cpuinfo | head -n 1 | cut -d: -f2 | cut -d,
> -f1 | $SED 's/ //g') ; /usr/bin/machine ; /bin/machine; grep CPU
> /var/run/dmesg.boot | head -n 1 | cut -d" " -f2) 2> /dev/null`
>
On Tue, Sep 28, 2021 at 09:34:23PM +0200, John Paul Adrian Glaubitz wrote:
> OK. I'm regenerating the chroots on the build servers now and then
> trigger another rebuild of the package. If that still doesn't help,
> we know there is some runtime detection which enables these instructions
> during b
Hi!
On 9/28/21 21:34, John Paul Adrian Glaubitz wrote:
> OK. I'm regenerating the chroots on the build servers now and then
> trigger another rebuild of the package. If that still doesn't help,
> we know there is some runtime detection which enables these instructions
> during build and I have to
On 9/28/21 17:49, Riccardo Mottola wrote:
> Thanks. I got from there libffi8_3.4.2-2+b1_powerpc.deb
>
> I replaced the one I compiled myself and I immediately get illegal
> instruction in a libffi-using app.
OK. I'm regenerating the chroots on the build servers now and then
trigger another rebuil
Hello!
On 9/28/21 17:46, Riccardo Mottola wrote:
> I did this on my PowerBook G4 .
> I had some issues with build-dep - it doesn't like my deb-src in the
> sources file:
>
> apt-get build-dep libffi
> Reading package lists... Done
> E: You must put some 'deb-src' URIs in your sources.list
>
> I
i installed the b1 version of libffi8 and the illegal instruction messages
are back
[ 16.195961] fail2ban-server[384]: illegal instruction (4) at
3fffa5270970 nip 3fffa5270970 lr 3fffa526ff90 code 1 in
libffi.so.8.1.0[3fffa5268000+c000]
[ 16.196045] fail2ban-server[384]: code: b1090008 f949000
Hi Adrian
John Paul Adrian Glaubitz wrote:
>>
>
> It’s been moved:
>
> > http://incoming.ports.debian.org/buildd/packages/sid/main/
>
Thanks. I got from there libffi8_3.4.2-2+b1_powerpc.deb
I replaced the one I compiled myself and I immediately get illegal
instruction in a libffi-using app.
I
Hello,
John Paul Adrian Glaubitz wrote:
>
> It's not being built with -mnative as far I could tell from the logs.
>
> But you can verify whether this is the case or not by building the
> Debian package on your local machine:
>
> $ apt-get install devscripts
> $ dget -u
> https://deb.debian.org/de
> On Sep 28, 2021, at 3:14 PM, Riccardo Mottola
> wrote:
>
> Hello Adrian
>
> John Paul Adrian Glaubitz wrote:
>> $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_powerpc.deb
>> $ dpkg -i libffi8_3.4.2-2+b1_powerpc.deb
>>
>> For ppc64:
>>
>> $ wget http://incoming.ports.debian.or
Hello Adrian
John Paul Adrian Glaubitz wrote:
> $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_powerpc.deb
> $ dpkg -i libffi8_3.4.2-2+b1_powerpc.deb
>
> For ppc64:
>
> $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_ppc64.deb
> $ dpkg -i libffi8_3.4.2-2+b1_ppc64.deb
I can
On 9/28/21 12:58, John Paul Adrian Glaubitz wrote:> On 9/28/21 12:55, Cameron
MacPherson wrote:
>> after building and installing it locally using your commands (i had to add
>> --no-sign to dpkg-buildpackage) it works. no illegal instructions
>
> Well, that's becoming intesting now. I'm going to
On 9/28/21 12:55, Cameron MacPherson wrote:
> after building and installing it locally using your commands (i had to add
> --no-sign to dpkg-buildpackage) it works. no illegal instructions
Well, that's becoming intesting now. I'm going to have the packages rebuilt
on the buildds now.
Adrian
--
after building and installing it locally using your commands (i had to add
--no-sign to dpkg-buildpackage) it works. no illegal instructions
On Tue, Sep 28, 2021 at 3:08 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> Hi Cameron!
>
> On 9/28/21 11:38, Cameron MacPherson wrot
Hi Cameron!
On 9/28/21 11:38, Cameron MacPherson wrote:
> i recompiled everything with gcc-10 and there is no change vs gcc version 11
As a last test, can you try rebuilding the Debian package locally and test that?
$ apt-get install devscripts
$ dget -u https://deb.debian.org/debian/pool/main/l
i recompiled everything with gcc-10 and there is no change vs gcc version 11
On Tue, Sep 28, 2021 at 2:24 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> On 9/28/21 11:22, Cameron MacPherson wrote:
> > after running the commands you listed i repeated my process with the new
On 9/28/21 11:22, Cameron MacPherson wrote:
> after running the commands you listed i repeated my process with the new
> libffi.so.8 from v3.4.2 vs HEAD and there is no change. both of them work.
> i am using gcc 11.2.0-7
Ah, the compiler is a good point.
Try building with gcc-10 instead by setti
after running the commands you listed i repeated my process with the new
libffi.so.8 from v3.4.2 vs HEAD and there is no change. both of them work.
i am using gcc 11.2.0-7
On Tue, Sep 28, 2021 at 2:07 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> Hi Cameron!
>
> On 9/28/21
Hi Cameron!
On 9/28/21 10:59, Cameron MacPherson wrote:
> i ran apt install --reinstall libffi8, restarted the system and the
> following messages reappeared
>
> [ 16.874069] fail2ban-server[384]: illegal instruction (4) at
> 3fff7ef95970 nip 3fff7ef95970 lr 3fff7ef94f90 code 1 in
> libffi.so.8
version?
>
> You need to make sure 100% that this version fixes it while the
> libffi.so.8.1.0 from the Debian package causes the crash.
>
> Also, can you check whether passing "--disable-exec-static-tramp"
> makes a difference?
>
> We need to find out why the Debia
essages
Did you verify that it is actually using the proper version?
You need to make sure 100% that this version fixes it while the
libffi.so.8.1.0 from the Debian package causes the crash.
Also, can you check whether passing "--disable-exec-static-tramp"
makes a difference?
We n
hi,
after ./autogen.sh && ./configure && make i then copied the new
libffi.so.8.1.0 from ~/libffi/powerpc64-unknown-linux-gnu/.libs to
/usr/lib/powerpc64-linux-gnu and that solved it. no more illegal
instruction messages
On Tue, Sep 28, 2021 at 12:44 AM John Paul Adrian Glaubitz <
glaub...@physik
sggested. Configured
> and built without any additional parameter.
>
> export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
>
> And things works. Python does not crash and GNUstep works, as I am typing
> this right mail from my iMac.
Please try building with "--disable
Hello!
On 9/28/21 06:18, Cameron MacPherson wrote:
> i too am having problems with libffi8 on a powermac g5
>
> # dmesg
> ...
> [ 16.257543] fail2ban-server[384]: illegal instruction (4) at
> 3fffb4283970 nip 3fffb4283970 lr 3fffb4282f90 code 1 in
> libffi.so.8.1.0[3fffb427b000+c000]
> ...
> #
Hello!
On 9/27/21 23:43, Riccardo Mottola wrote:
> yes please check that - I will access this computer only next weekend,
> so for now no test, I only have my laptop with me, but 32bit might not
> be affected.
It's not being built with -mnative as far I could tell from the logs.
But you can veri
ood thing is that the new kernel boots and X11 comes up.
>
> The bad news is lots of applications crash and they all have one thing
> in common, libffi.
>
>
> So e.g. a build of ArcticFox fails:
> multix@PPC970FX:~/code/Arctic-Fox$ ./mach build
> /usr/bin/which: this version of
I confirm that. I had problem with Arctic fox an Fadedorb because of lack of
that lib.
On my G4 machines I have installed missing lib from Fienix repos.
Terv,
Kristoffer
--
Wiadomość wysłana za pomocą serwisu Tutanota, oferującego bezpieczną i wolną
od reklam usługę e-mail:
https://tutanot
Hi,
just for info - the issue happens also on PowerPC G4 32bit.
strange nobody else shares this?
Riccardo
Hi,
John Paul Adrian Glaubitz wrote:
No I cannot, 3.4.2 (cleaned, reconfigured, installed) seems to work fine out of
the box.
So either the release is not well tagged, or there is an issue with the Debian
package.
You could try rebuilding the libffi Debian package locally and see if that
ma
On 9/26/21 22:38, Riccardo Mottola wrote:
> No I cannot, 3.4.2 (cleaned, reconfigured, installed) seems to work fine out
> of the box.
>
> So either the release is not well tagged, or there is an issue with the
> Debian package.
You could try rebuilding the libffi Debian package locally and see
Hi Adrian,
On 2021-09-26 18:34:47 +0100 John Paul Adrian Glaubitz
wrote:
On 9/26/21 19:31, Riccardo Mottola wrote:
Would you like me to build the latest "release" of libffi ?
Yes, please test the 3.4.2 release by checking out the "v3.4.2" tag:
$ git checkout v3.4.2
If you can reproduce
On 9/26/21 19:31, Riccardo Mottola wrote:
> Would you like me to build the latest "release" of libffi ?
Yes, please test the 3.4.2 release by checking out the "v3.4.2" tag:
$ git checkout v3.4.2
If you can reproduce the issue then, please start bisecting with:
$ git bisect start
$ git bisect g
any additional parameter.
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
And things works. Python does not crash and GNUstep works, as I am
typing this right mail from my iMac.
Now this means that thebug is not present in current upstream. Either
it is already solved, or there
On 9/26/21 15:39, Riccardo Mottola wrote:
> That's a bit a similar issue with building libffi locally. In /usr/local
> I am unsure it would be picked up. I can of course still do it and perhaps
> have GNUstep pick it up and do some tests there.
>
> In the meanwhile, I'm setting up to configure and
crash and they all have one
thing in
common, libffi.
So e.g. a build of ArcticFox fails:
multix@PPC970FX:~/code/Arctic-Fox$ ./mach build
/usr/bin/which: this version of `which' is deprecated; use `command
-v' in
scripts instead.
Illegal instruction
Did you verify that downg
On 9/26/21 14:56, John Paul Adrian Glaubitz wrote:
> On 9/26/21 14:54, John Paul Adrian Glaubitz wrote:
>> Did you verify that downgrading the libffi package fixes the problem?
>>
>> If yes, you may file an upstream bug here [1]. The powerpc-related changes I
>> can
>> see at first glance are thes
On 9/26/21 14:54, John Paul Adrian Glaubitz wrote:
> Did you verify that downgrading the libffi package fixes the problem?
>
> If yes, you may file an upstream bug here [1]. The powerpc-related changes I
> can
> see at first glance are these [2].
My guess would be this change:
> https://github.
Hello!
On 9/26/21 14:36, Riccardo Mottola wrote:
> I upgraded my iMac G5 to latest debian, including kernel 5.14 !
> The good thing is that the new kernel boots and X11 comes up.
>
> The bad news is lots of applications crash and they all have one thing in
> common, libffi.
&g
Hi,
I upgraded my iMac G5 to latest debian, including kernel 5.14 !
The good thing is that the new kernel boots and X11 comes up.
The bad news is lots of applications crash and they all have one thing
in common, libffi.
So e.g. a build of ArcticFox fails:
multix@PPC970FX:~/code/Arctic-Fox
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Mar 14, 2021 at 7:34 PM Jeffrey Walton wrote:
> You probably need to go to frame 1 ('f 1' under gdb) and disassemble
> ('disass .' or 'disass' followed by a bunch of pages). That will show
> the offending instruc
On Sun, Mar 14, 2021 at 2:57 PM Riccardo Mottola
wrote:
>
> On 3/8/21 9:49 AM, John Paul Adrian Glaubitz wrote:
> > We certainly shouldn't disable the whole JIT over a single instruction but
> > rather
> > check whether this instruction can be guarded on older POWER systems.
> >
> > But we need t
Hi,
On 3/8/21 9:49 AM, John Paul Adrian Glaubitz wrote:
We certainly shouldn't disable the whole JIT over a single instruction but
rather
check whether this instruction can be guarded on older POWER systems.
But we need to find out first which instruction triggers the SIGILL.
Indeed, it cras
On Mon, Mar 8, 2021 at 8:50 AM John Paul Adrian Glaubitz
wrote:
>
> On 3/8/21 9:38 AM, Jeffrey Walton wrote:
> >> a cursory scan shows no evidence of the use of VSX there.
> >
> > If needed... I believe it is possible to disable PCRE2's JIT at configure
> > time.
>
> We certainly shouldn't disabl
On 3/8/21 9:38 AM, Jeffrey Walton wrote:
>> a cursory scan shows no evidence of the use of VSX there.
>
> If needed... I believe it is possible to disable PCRE2's JIT at configure
> time.
We certainly shouldn't disable the whole JIT over a single instruction but
rather
check whether this instru
On Sun, Mar 7, 2021 at 2:10 PM Luke Kenneth Casson Leighton
wrote:
>
> On Sunday, March 7, 2021, Riccardo Mottola
> wrote:.
>>
>> the issue is most probably in libpcre2 or Qt5Core
>>
>> #0 0x7fffe9c5fa30 in ?? ()
>> #1 0x702c406c in ?? () from
>> /usr/lib/powerpc64-linux-gnu/libpc
On Sunday, March 7, 2021, Riccardo Mottola
wrote:.
>
>
> the issue is most probably in libpcre2 or Qt5Core
>
> #0 0x7fffe9c5fa30 in ?? ()
> #1 0x702c406c in ?? () from /usr/lib/powerpc64-linux-gnu/l
> ibpcre2-16.so.0
https://vcs.pcre.org/pcre2/code/trunk/src/sljit/sljitNativePPC_c
Hello!
On 3/7/21 7:25 PM, Riccardo Mottola wrote:
>> Most likely someone added VSX support to either of them without guarding the
>> code with #ifdefs.
>
> the issue is most probably in libpcre2 or Qt5Core
>
> #0 0x7fffe9c5fa30 in ?? ()
> #1 0x702c406c in ?? () from
> /usr/lib/po
Hi Adrian!
On 2021-03-06 15:22:02 +0100 John Paul Adrian Glaubitz
wrote:
Please install the dbgsym/dbg package for VLC and ffmpeg and provide
a
backtrace.
Most likely someone added VSX support to either of them without
guarding the
code with #ifdefs.
the issue is most probably in li
Hello!
> On Mar 6, 2021, at 2:33 PM, Riccardo Mottola
> wrote:
>
>
> I just tried VLC on a G5... it starts but as soon as I try to open a file, it
> dies "inside" the file selector! Not just a file, trying to click on my home
> directory, I get illegal instruction.ù
>
> If I give it a MP4 o
Hi,
I just tried VLC on a G5... it starts but as soon as I try to open a
file, it dies "inside" the file selector! Not just a file, trying to
click on my home directory, I get illegal instruction.ù
If I give it a MP4 on the command line, it will come up and then die
with illegal instruction.
On 1/30/20 11:05 PM, Riccardo Mottola wrote:
> I'm trying to check out ArcticFox sources on the PPC64 devkit gear to test a
> compilation of it. It has these cpu's:
>
> processor : 0
> cpu : e6500, altivec supported
> clock : 1799.82MHz
> revision : 2.0 (pvr
Hi!
I'm trying to check out ArcticFox sources on the PPC64 devkit gear to
test a compilation of it. It has these cpu's:
processor : 0
cpu : e6500, altivec supported
clock : 1799.82MHz
revision : 2.0 (pvr 8040 0120)
since GIT is currently not available d
On Mon, 24 Sep 2018 at 21:18:47 +0100, Simon McVittie wrote:
> Most of the test cases provided with mozjs60 crash:
>
> grep '^TEST-' s390x.log | cut -d' ' -f1 | sort | uniq -c
>1714 TEST-KNOWN-FAIL
>6923 TEST-PASS
> 28635 TEST-UNEXPECTED-FAIL
This
Mottola
Inviato: domenica 12 novembre 2017 00:27
A: Gabriel Paubert
Cc: debian-powerpc@lists.debian.org
Oggetto: Re: Bug#830180: PowerPC without altivec causes crash
Hi,
On 12/11/2017 00:03, Gabriel Paubert wrote:
> I hope that you don't parse /proc/cpuinfo to know the capabilities of
&g
t machine more than
> daily use.
Firefox is completely unusable on my G4 (1.67GHz G4 Powerbook), and
usable on my quad G5 (64 bit version).
In both cases, there is also the problem that it will crash easily (almost
any right mouse button click) if you put the display in 16 bit depth. But
opengl
Hi,
On 12/11/2017 00:03, Gabriel Paubert wrote:
I hope that you don't parse /proc/cpuinfo to know the capabilities of
your CPU. There is a better way to do this, namely use getauxval(3).
jpeg-turbo was doing exactly that and getauxval() was refused, read the
bug discussion.
Speaking of
On Sat, Nov 11, 2017 at 10:07:50AM +0100, Riccardo Mottola wrote:
> Hi,
>
>
> On 09/11/2017 17:41, John Paul Adrian Glaubitz wrote:
> > On 11/09/2017 05:30 PM, Ondřej Surý wrote:
> > > this has been already fixed by upstream:
> > >
> > > https://github.com/libjpeg-turbo/libjpeg-turbo/commit/02fa
Hi,
On 09/11/2017 17:41, John Paul Adrian Glaubitz wrote:
On 11/09/2017 05:30 PM, Ondřej Surý wrote:
this has been already fixed by upstream:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/02fa8f244e549edd3f3acf174b97157590d1b71e
Ah, nice. I didn't see that. Thanks for reporting th
Hi!
On 11/09/2017 05:30 PM, Ondřej Surý wrote:
this has been already fixed by upstream:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/02fa8f244e549edd3f3acf174b97157590d1b71e
Ah, nice. I didn't see that. Thanks for reporting the issue and
getting it fixed. Much appreciated!
(I gave
1 - 100 of 277 matches
Mail list logo
