Bug#908396: your mail
I download it and install it (dpkg) and it doesn't work: ~$ firefox ExceptionHandler::GenerateDump cloned child 2617 ExceptionHandler::SendContinueSignalToChild sent continue signal to child ExceptionHandler::WaitForContinueSignal waiting for continue signal... Failed to open curl lib from binary, use libcurl.so instead -- Gerard ___ *** * Created with "mutt 1.8.3" * under Debian Linux STRETCH 9.3 * Registered Linux User #388243 * https://Linuxcounter.net ***
Bug#908396: your mail
On Tue, Sep 11, 2018 at 02:10:14PM +0900, Mike Hommey wrote: > On Tue, Sep 11, 2018 at 09:08:35AM +0900, Mike Hommey wrote: > > On Mon, Sep 10, 2018 at 08:40:08PM +0200, Moritz Mühlenhoff wrote: > > > On Mon, Sep 10, 2018 at 02:54:54AM +0200, b...@debian.16bits.net wrote: > > > > /proc/cpuinfo shows it supports sse, but not sse2. And movsd is a sse2 > > > > instruction [1] > > > > > > This is an intentional upstream change which also affects the binaries > > > provided by Mozilla: > > > https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported > > > > > > It might be possible to disable the use of SSE2 for the i386 architecture > > > (as every CPU covered by amd64 supports SSE2), but I have no idea how > > > intrusive that would be (and might cause some problems in the long term > > > if the non-SSE2 code paths are not covered by upstream CI/tests). It's > > > also one additional patch to be carried forward until i386 is retired > > > as an architecture. > > > > The problem from bug #877445 is actually trivial to fix, but the ones > > from bug 908449/908396 would seem unrelated. I tried running firefox-esr > > from stretch-security in qemu without sse2 (without kvm), and it... just > > worked. I couldn't even reproduce #877445. The problem is that > > apparently, even when doing emulation, qemu doesn't actually disable > > instruction sets, it just hides them from cpuid. > > So, looking at a local build for i386, it appears that most of the SSE2 > code in libxul comes from ... rust. Because the rust compiler happily > emits SSE2 on i386, which it shouldn't be doing. Now that bug #908561 is fixed to address the rust problem, I created a build for stretch with a fix for bug #877445 and built against the fixed rust compiler. Could anyone with a non-SSE2 CPU check if it works (as per the above, qemu doesn't cut it)? https://people.debian.org/~glandium/firefox-esr_60.2.0esr-1~deb9u2.1_i386.deb sha256: b7cdb4b4ff57d302e4b5d2fbc3ff7a7bce2f35431e3fc40e0915dc2d65deefac Thanks Mike
Bug#908396: your mail
On Tue, Sep 11, 2018 at 09:08:35AM +0900, Mike Hommey wrote: > On Mon, Sep 10, 2018 at 08:40:08PM +0200, Moritz Mühlenhoff wrote: > > On Mon, Sep 10, 2018 at 02:54:54AM +0200, b...@debian.16bits.net wrote: > > > /proc/cpuinfo shows it supports sse, but not sse2. And movsd is a sse2 > > > instruction [1] > > > > This is an intentional upstream change which also affects the binaries > > provided by Mozilla: > > https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported > > > > It might be possible to disable the use of SSE2 for the i386 architecture > > (as every CPU covered by amd64 supports SSE2), but I have no idea how > > intrusive that would be (and might cause some problems in the long term > > if the non-SSE2 code paths are not covered by upstream CI/tests). It's > > also one additional patch to be carried forward until i386 is retired > > as an architecture. > > The problem from bug #877445 is actually trivial to fix, but the ones > from bug 908449/908396 would seem unrelated. I tried running firefox-esr > from stretch-security in qemu without sse2 (without kvm), and it... just > worked. I couldn't even reproduce #877445. The problem is that > apparently, even when doing emulation, qemu doesn't actually disable > instruction sets, it just hides them from cpuid. So, looking at a local build for i386, it appears that most of the SSE2 code in libxul comes from ... rust. Because the rust compiler happily emits SSE2 on i386, which it shouldn't be doing. Mike
Bug#908396: your mail
On Mon, Sep 10, 2018 at 08:40:08PM +0200, Moritz Mühlenhoff wrote: > On Mon, Sep 10, 2018 at 02:54:54AM +0200, b...@debian.16bits.net wrote: > > /proc/cpuinfo shows it supports sse, but not sse2. And movsd is a sse2 > > instruction [1] > > This is an intentional upstream change which also affects the binaries > provided by Mozilla: > https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported > > It might be possible to disable the use of SSE2 for the i386 architecture > (as every CPU covered by amd64 supports SSE2), but I have no idea how > intrusive that would be (and might cause some problems in the long term > if the non-SSE2 code paths are not covered by upstream CI/tests). It's > also one additional patch to be carried forward until i386 is retired > as an architecture. The problem from bug #877445 is actually trivial to fix, but the ones from bug 908449/908396 would seem unrelated. I tried running firefox-esr from stretch-security in qemu without sse2 (without kvm), and it... just worked. I couldn't even reproduce #877445. The problem is that apparently, even when doing emulation, qemu doesn't actually disable instruction sets, it just hides them from cpuid. Mike
Bug#908396: your mail
On Mon, Sep 10, 2018 at 02:54:54AM +0200, b...@debian.16bits.net wrote: > /proc/cpuinfo shows it supports sse, but not sse2. And movsd is a sse2 > instruction [1] This is an intentional upstream change which also affects the binaries provided by Mozilla: https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported It might be possible to disable the use of SSE2 for the i386 architecture (as every CPU covered by amd64 supports SSE2), but I have no idea how intrusive that would be (and might cause some problems in the long term if the non-SSE2 code paths are not covered by upstream CI/tests). It's also one additional patch to be carried forward until i386 is retired as an architecture. Cheers, Moritz
