[opensuse-factory] Minimal processor features for Tumbleweed on i586?
Hi, I tried to run Tumbleweed on i586 today and when starting Gnome on X11 or got a number of errors caused by invalid opcodes. [ 630.370899] traps: evolution-sourc[2962] trap invalid opcode ip:ae285db9 sp:bfd6fa00 error:0 in libjavascriptcoregtk- 4.0.so.18.14.8[ad937000+ca8000] [ 631.149280] traps: goa-daemon[3006] trap invalid opcode ip:b454cdb9 sp:bfa6d8f0 error:0 in libjavascriptcoregtk- 4.0.so.18.14.8[b3bfe000+ca8000] [ 632.868196] traps: goa-daemon[3039] trap invalid opcode ip:b453fdb9 sp:bf814b60 error:0 in libjavascriptcoregtk- 4.0.so.18.14.8[b3bf1000+ca8000] [ 637.998523] traps: pool-gnome-shel[3052] trap invalid opcode ip:a01f80dd sp:b163fb90 error:0 in librsvg- 2.so.2.46.0[a0027000+1e8000] [ 638.011551] traps: pool-gnome-shel[2994] trap invalid opcode ip:a01dacef sp:a232bbb0 error:0 in librsvg- 2.so.2.46.0[a0027000+1e8000] [ 653.946106] traps: pool-gnome-shel[3060] trap invalid opcode ip:a19f60dd sp:b16ebb90 error:0 in librsvg- 2.so.2.46.0[a1825000+1e8000] [ 653.967114] traps: pool-gnome-shel[3072] trap invalid opcode ip:a19d8cef sp:a17f9bb0 error:0 in librsvg-2.so.2.46.0[a1825000+1e8000] [ 658.790216] traps: gnome-session-f[3075] trap invalid opcode ip:b4a620dd sp:bfb96f50 error:0 in librsvg- 2.so.2.46.0[b4891000+1e8000] The processor is an Athlon XP. Compared to a Pentium 4, it lacks a bit on SSE instructions, but I hoped it would still meet the requirements [1]. See the cpuinfo below. linux:~ # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(tm) XP 1700+ stepping : 2 cpu MHz : 1466.409 cache size : 256 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall bugs : fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass bogomips : 2932.81 clflush size : 32 cache_alignment : 32 address sizes : 34 bits physical, 32 bits virtual power management: ts It this a bug in the build or is the processor not compatible? Best regards Thomas [1] https://en.opensuse.org/Hardware_requirements -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Thursday 2020-01-30 11:40, Thomas Zimmermann wrote:
I tried to run Tumbleweed on i586 today and when starting Gnome on X11 or got a number of errors caused by invalid opcodes.
[ 630.370899] traps: evolution-sourc[2962] trap invalid opcode ip:ae285db9 sp:bfd6fa00 error:0 in libjavascriptcoregtk- 4.0.so.18.14.8[ad937000+ca8000]
It's the usual crap that programs make use of sse2 without checking cpuid AT DAMN RUNTIME. webkit2gtk3 build log: [ 64s] -- Performing Test C_COMPILER_SUPPORTS_-msse2 [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-msse2 - Success [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-mfpmath=sse [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-mfpmath=sse - Success [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-msse2 [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-msse2 - Success [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-mfpmath=sse [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-mfpmath=sse - Success -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 1/30/20 11:50 AM, Jan Engelhardt wrote:
On Thursday 2020-01-30 11:40, Thomas Zimmermann wrote:
I tried to run Tumbleweed on i586 today and when starting Gnome on X11 or got a number of errors caused by invalid opcodes.
[ 630.370899] traps: evolution-sourc[2962] trap invalid opcode ip:ae285db9 sp:bfd6fa00 error:0 in libjavascriptcoregtk- 4.0.so.18.14.8[ad937000+ca8000]
It's the usual crap that programs make use of sse2 without checking cpuid AT DAMN RUNTIME.
Yeah, and overwriting CFLAGS/CXXFLAGS from the environment. Adrian
Hi Am 30.01.20 um 11:50 schrieb Jan Engelhardt:
On Thursday 2020-01-30 11:40, Thomas Zimmermann wrote:
I tried to run Tumbleweed on i586 today and when starting Gnome on X11 or got a number of errors caused by invalid opcodes.
[ 630.370899] traps: evolution-sourc[2962] trap invalid opcode ip:ae285db9 sp:bfd6fa00 error:0 in libjavascriptcoregtk- 4.0.so.18.14.8[ad937000+ca8000]
It's the usual crap that programs make use of sse2 without checking cpuid AT DAMN RUNTIME.
webkit2gtk3 build log: [ 64s] -- Performing Test C_COMPILER_SUPPORTS_-msse2 [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-msse2 - Success [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-mfpmath=sse [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-mfpmath=sse - Success [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-msse2 [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-msse2 - Success [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-mfpmath=sse [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-mfpmath=sse - Success
Glad to see that the processor is not yet entirely unsupported. Shall I open a bug report for this problem? Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Thu, 2020-01-30 at 12:11 +0100, Thomas Zimmermann wrote:
Hi
Am 30.01.20 um 11:50 schrieb Jan Engelhardt:
On Thursday 2020-01-30 11:40, Thomas Zimmermann wrote:
I tried to run Tumbleweed on i586 today and when starting Gnome on X11 or got a number of errors caused by invalid opcodes.
[ 630.370899] traps: evolution-sourc[2962] trap invalid opcode ip:ae285db9 sp:bfd6fa00 error:0 in libjavascriptcoregtk- 4.0.so.18.14.8[ad937000+ca8000]
It's the usual crap that programs make use of sse2 without checking cpuid AT DAMN RUNTIME.
webkit2gtk3 build log: [ 64s] -- Performing Test C_COMPILER_SUPPORTS_-msse2 [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-msse2 - Success [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-mfpmath=sse [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-mfpmath=sse - Success [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-msse2 [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-msse2 - Success [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-mfpmath=sse [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-mfpmath=sse - Success
Glad to see that the processor is not yet entirely unsupported. Shall I open a bug report for this problem?
That will be tough: webkit2gtk claims in the CMake files: include(DetectSSE2) if (NOT SSE2_SUPPORT_FOUND) message(FATAL_ERROR "SSE2 support is required to compile WebKit") endif () Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2020-01-30 12:39, Dominique Leuenberger / DimStar wrote:
That will be tough: webkit2gtk claims in the CMake files:
include(DetectSSE2) if (NOT SSE2_SUPPORT_FOUND) message(FATAL_ERROR "SSE2 support is required to compile WebKit") endif ()
Somehow that sounds surprising, given it builds on non-SSE platforms like arm and ppc (and does not force the use of e.g. altivec, either). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Am 30.01.20 um 12:39 schrieb Dominique Leuenberger / DimStar:
On Thu, 2020-01-30 at 12:11 +0100, Thomas Zimmermann wrote:
Hi
Am 30.01.20 um 11:50 schrieb Jan Engelhardt:
On Thursday 2020-01-30 11:40, Thomas Zimmermann wrote:
I tried to run Tumbleweed on i586 today and when starting Gnome on X11 or got a number of errors caused by invalid opcodes.
[ 630.370899] traps: evolution-sourc[2962] trap invalid opcode ip:ae285db9 sp:bfd6fa00 error:0 in libjavascriptcoregtk- 4.0.so.18.14.8[ad937000+ca8000]
It's the usual crap that programs make use of sse2 without checking cpuid AT DAMN RUNTIME.
webkit2gtk3 build log: [ 64s] -- Performing Test C_COMPILER_SUPPORTS_-msse2 [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-msse2 - Success [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-mfpmath=sse [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-mfpmath=sse - Success [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-msse2 [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-msse2 - Success [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-mfpmath=sse [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-mfpmath=sse - Success
Glad to see that the processor is not yet entirely unsupported. Shall I open a bug report for this problem?
That will be tough: webkit2gtk claims in the CMake files:
include(DetectSSE2) if (NOT SSE2_SUPPORT_FOUND) message(FATAL_ERROR "SSE2 support is required to compile WebKit") endif ()
Wonderful! It forces its requirements on every piece of the software stack that depends on it. However, I wonder what they do on arm. I don't strictly depend on Gnome. I use the machine for kernel development and Gnome/X11 is just one of my smoke tests. Twm works nicely BTW! :) Best regards Thomas
Cheers, Dominique
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 30.01.2020 14:54, Thomas Zimmermann пишет:
Hi
Am 30.01.20 um 12:39 schrieb Dominique Leuenberger / DimStar:
On Thu, 2020-01-30 at 12:11 +0100, Thomas Zimmermann wrote:
Hi
Am 30.01.20 um 11:50 schrieb Jan Engelhardt:
On Thursday 2020-01-30 11:40, Thomas Zimmermann wrote:
I tried to run Tumbleweed on i586 today and when starting Gnome on X11 or got a number of errors caused by invalid opcodes.
[ 630.370899] traps: evolution-sourc[2962] trap invalid opcode ip:ae285db9 sp:bfd6fa00 error:0 in libjavascriptcoregtk- 4.0.so.18.14.8[ad937000+ca8000]
It's the usual crap that programs make use of sse2 without checking cpuid AT DAMN RUNTIME.
webkit2gtk3 build log: [ 64s] -- Performing Test C_COMPILER_SUPPORTS_-msse2 [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-msse2 - Success [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-mfpmath=sse [ 65s] -- Performing Test C_COMPILER_SUPPORTS_-mfpmath=sse - Success [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-msse2 [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-msse2 - Success [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-mfpmath=sse [ 65s] -- Performing Test CXX_COMPILER_SUPPORTS_-mfpmath=sse - Success
Glad to see that the processor is not yet entirely unsupported. Shall I open a bug report for this problem?
That will be tough: webkit2gtk claims in the CMake files:
include(DetectSSE2) if (NOT SSE2_SUPPORT_FOUND) message(FATAL_ERROR "SSE2 support is required to compile WebKit") endif ()
Wonderful! It forces its requirements on every piece of the software stack that depends on it. However, I wonder what they do on arm.
Probably, it is excessive requirement. Is there any assembler inline code in the project?
I don't strictly depend on Gnome. I use the machine for kernel development and Gnome/X11 is just one of my smoke tests. Twm works nicely BTW! :)
Best regards Thomas
Cheers, Dominique
-----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEFnRguwljCXV9IjzOAv0PX1iySn8FAl4y1mgACgkQAv0PX1iy Sn9Ingf/d5XAEgQkwd/7kjVnqfIMC0IhNJuRQEwyUbzgKHnaSv9spyehVJ8YAM7a uNQ55C3/J/Wj4FgIeOu2XiQ1z3pSWNA/KOHTthKbjFc25qOCW8OM1x5bInd4bwd9 kIfRrLb9P5fTli+jWRdz9wRh1GjlSiPiY5ip20h1im4FoCE1TSGxNDv9nLr70IE4 IK9H3NrUXFcM09SWlSvTxGLdT24dlsyWNKEzsmvab0dkQE6b6vzPJCpJLCOWk55a J99iab652dz6Cs+ttWCEEpyPGGxhTA+noex57CAt8ylv8gEbXSYSfiuU3NtQasGr 3tG6vzggcofzc7H+9Qbeh3reJgHUIg== =C9+y -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 30 Jan 2020 12:54:28 +0100 Thomas Zimmermann wrote:
That will be tough: webkit2gtk claims in the CMake files:
include(DetectSSE2) if (NOT SSE2_SUPPORT_FOUND) message(FATAL_ERROR "SSE2 support is required to compile WebKit") endif ()
Wonderful! It forces its requirements on every piece of the software stack that depends on it. However, I wonder what they do on arm.
This requirement looks like introduced by a CPU manufacturer who wants to obsolete former CPU generations. From software point of view I can't believe that the benefit of SSE2 is so miraculous that something that is not doable without SSE2 is suddenly easily possible. BTW: I am also using Tumbleweed on an Athlon-XP. I upgraded from openSUSE 13.2 to Tumbleweed in Sept. 2018 using the procedure described in this message: https://lists.opensuse.org/opensuse-factory/2018-09/msg00128.html and keep it up to date ever since. In the first months konsole was not working, it crashed with an illegal opcode, but in the meantime this was resolved. There exist x86_64 CPUs with significantly less performance than the Athlon-XP, so I hope 32-bit support (without SSE2 requirement) will still be around for some time. Kind regards, Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thomas Zimmermann composed on 2020-01-30 06:11 (UTC-0500):
Glad to see that the processor is not yet entirely unsupported. Shall I open a bug report for this problem?
I think if you do that you'll get a wontfix because SSE2 is a required CPU configuration. I quit trying to use Socket A CPUs for TW over a year ago. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2020-01-30 18:13, Felix Miata wrote:
Thomas Zimmermann composed on 2020-01-30 06:11 (UTC-0500):
Glad to see that the processor is not yet entirely unsupported. Shall I open a bug report for this problem?
btw, https://bugzilla.opensuse.org/show_bug.cgi?id=1162283 is now open
I think if you do that you'll get a wontfix because SSE2 is a required CPU configuration.
Says where? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt composed on 2020-01-30 18:48 (UTC+0100):
Felix Miata wrote:
Thomas Zimmermann composed on 2020-01-30 06:11 (UTC-0500):
Glad to see that the processor is not yet entirely unsupported. Shall I open a bug report for this problem?
btw, https://bugzilla.opensuse.org/show_bug.cgi?id=1162283 is now open
I think if you do that you'll get a wontfix because SSE2 is a required CPU configuration.
Says where?
Only place I can find is this: https://bugzilla.opensuse.org/show_bug.cgi?id=1032165 WONTFIX Tumbleweed Installation ISO i585 Kernel Panic on Non-SSE2 CPUs due to failed FIPS self which stemmed from this thread: https://lists.opensuse.org/opensuse-factory/2018-09/msg00148.html I thought I remembered a different bug with something more, but am having no luck finding. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Jan 30, 2020 at 7:50 AM Jan Engelhardt <jengelh@inai.de> wrote:
It's the usual crap that programs make use of sse2 without checking cpuid AT DAMN RUNTIME.
And it clearly shows nobody uses TW in old hardware and that there should be a way to make the compiler gobally ignore or reinterpret certain flags -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 30 Jan 2020, Cristian Rodríguez wrote:
On Thu, Jan 30, 2020 at 7:50 AM Jan Engelhardt <jengelh@inai.de> wrote:
It's the usual crap that programs make use of sse2 without checking cpuid AT DAMN RUNTIME.
And it clearly shows nobody uses TW in old hardware and that there should be a way to make the compiler gobally ignore or reinterpret certain flags
And a way to ignore those global "ignore" setting? ... You get what you feed it. Don't feed it crap. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Thu, Jan 30, 2020 at 8:30 AM Richard Biener <rguenther@suse.de> wrote:
You get what you feed it. Don't feed it crap.
Agreed, that's kinda difficult with thousands and thousands of packages though. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2020-01-30 12:13, Cristian Rodríguez wrote:
On Thu, Jan 30, 2020 at 7:50 AM Jan Engelhardt <jengelh@inai.de> wrote:
It's the usual crap that programs make use of sse2 without checking cpuid AT DAMN RUNTIME.
And it clearly shows nobody uses TW in old hardware
That is bullcrap. I do use TW on two items of i586-class hardware. Not very often, but still. It's just that... webkit is not used by anything I care about (xfce4). According to .spec files: atril balsa bijiben bookworm capnet-assist devhelp eclipse emacs empathy eolie epiphany evolution-data-server evolution geary gitg glade gnome-books gnome-boxes gnome-builder gnome-documents gnome-online-accounts gnucash gthumb libgepub meteo midori nemo-extensions notes-up pix python-wxPython quilter remmina shotwell sushi vimb vocal webkit2gtk3 wxGTK3-3_2 xiphos xreader yelp zenity So mostly a GNOME thing. zenity is sometimes pulled in. For example: clamtk live-fat-stick marco metacity muffin mutter opengl-games-utils openrct2 patterns-gnome patterns-mate python-dialite shellementary wqy-zenhei-fonts xfce4-panel[subpkg] So yeah, as a xfce4 user, you don't really get to deal with webkit2gtk. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Am 30.01.20 um 12:36 schrieb Jan Engelhardt:
On Thursday 2020-01-30 12:13, Cristian Rodríguez wrote:
On Thu, Jan 30, 2020 at 7:50 AM Jan Engelhardt <jengelh@inai.de> wrote:
It's the usual crap that programs make use of sse2 without checking cpuid AT DAMN RUNTIME.
And it clearly shows nobody uses TW in old hardware
That is bullcrap. I do use TW on two items of i586-class hardware. Not very often, but still. It's just that... webkit is not used by anything I care about (xfce4). According to .spec files:
Well, I just tried xfce4 and found that it uses librsvg. Hence it triggers the same bug. Do you see this on your system as well? Best regards Thomas
atril balsa bijiben bookworm capnet-assist devhelp eclipse emacs empathy eolie epiphany evolution-data-server evolution geary gitg glade gnome-books gnome-boxes gnome-builder gnome-documents gnome-online-accounts gnucash gthumb libgepub meteo midori nemo-extensions notes-up pix python-wxPython quilter remmina shotwell sushi vimb vocal webkit2gtk3 wxGTK3-3_2 xiphos xreader yelp zenity
So mostly a GNOME thing. zenity is sometimes pulled in. For example:
clamtk live-fat-stick marco metacity muffin mutter opengl-games-utils openrct2 patterns-gnome patterns-mate python-dialite shellementary wqy-zenhei-fonts xfce4-panel[subpkg]
So yeah, as a xfce4 user, you don't really get to deal with webkit2gtk.
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Thu, 2020-01-30 at 14:50 +0100, Thomas Zimmermann wrote:
That is bullcrap. I do use TW on two items of i586-class hardware. Not very often, but still. It's just that... webkit is not used by anything I care about (xfce4). According to .spec files:
Well, I just tried xfce4 and found that it uses librsvg. Hence it triggers the same bug. Do you see this on your system as well?
rsvg -> rust... nuff said
Hi Am 30.01.20 um 15:13 schrieb Dominique Leuenberger / DimStar:
On Thu, 2020-01-30 at 14:50 +0100, Thomas Zimmermann wrote:
That is bullcrap. I do use TW on two items of i586-class hardware. Not very often, but still. It's just that... webkit is not used by anything I care about (xfce4). According to .spec files:
Well, I just tried xfce4 and found that it uses librsvg. Hence it triggers the same bug. Do you see this on your system as well?
rsvg -> rust... nuff said
Admittedly, I lol'ed. But then it doesn't really help me with my problem. And according to zypper se --requires librsvg almost every graphical environment depends on librsvg. So in practice it imposes a minimal requirement for all things graphics. Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Am 30.01.20 um 15:52 schrieb Thomas Zimmermann:
Hi
Am 30.01.20 um 15:13 schrieb Dominique Leuenberger / DimStar:
On Thu, 2020-01-30 at 14:50 +0100, Thomas Zimmermann wrote:
That is bullcrap. I do use TW on two items of i586-class hardware. Not very often, but still. It's just that... webkit is not used by anything I care about (xfce4). According to .spec files:
Well, I just tried xfce4 and found that it uses librsvg. Hence it triggers the same bug. Do you see this on your system as well?
rsvg -> rust... nuff said
Admittedly, I lol'ed.
But then it doesn't really help me with my problem. And according to
zypper se --requires librsvg
almost every graphical environment depends on librsvg. So in practice it imposes a minimal requirement for all things graphics.
Or wait a sec, it doesn't seem to list anything KDE. There's hope...
Best regards Thomas
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Am 30.01.20 um 15:58 schrieb Thomas Zimmermann:
Am 30.01.20 um 15:52 schrieb Thomas Zimmermann:
Hi
Am 30.01.20 um 15:13 schrieb Dominique Leuenberger / DimStar:
On Thu, 2020-01-30 at 14:50 +0100, Thomas Zimmermann wrote:
That is bullcrap. I do use TW on two items of i586-class hardware. Not very often, but still. It's just that... webkit is not used by anything I care about (xfce4). According to .spec files:
Well, I just tried xfce4 and found that it uses librsvg. Hence it triggers the same bug. Do you see this on your system as well?
rsvg -> rust... nuff said
Admittedly, I lol'ed.
But then it doesn't really help me with my problem. And according to
zypper se --requires librsvg
almost every graphical environment depends on librsvg. So in practice it imposes a minimal requirement for all things graphics.
Or wait a sec, it doesn't seem to list anything KDE. There's hope...
It's a mixed bag. KDE still starts up, but: [ 134.757646] traps: opensuse-welcom[1807] trap invalid opcode ip:af0a7d89 sp:bf9ca0dc error:0 in libQt5WebEngineCore.so.5.14.0[af047000+61b8000] [ 172.001956] traps: gst-plugin-scan[2058] trap invalid opcode ip:b5c7a412 sp:bfdabca4 error:0 in libgstopengl.so[b5c54000+2a000] [ 172.205344] traps: gst-plugin-scan[2057] trap invalid opcode ip:b5bd2412 sp:bfc6f8a4 error:0 in libgstopengl.so[b5bac000+2a000] [ 172.315414] traps: gst-plugin-scan[2064] trap invalid opcode ip:b73e2412 sp:bf964bd4 error:0 in libgstopengl.so[b73bc000+2a000] [ 172.442156] traps: gst-plugin-scan[2068] trap invalid opcode ip:b7441412 sp:bfb27f34 error:0 in libgstopengl.so[b741b000+2a000] So it's better for what I what, but not good in general.
Best regards Thomas
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Thu, 2020-01-30 at 15:52 +0100, Thomas Zimmermann wrote:
Hi
Am 30.01.20 um 15:13 schrieb Dominique Leuenberger / DimStar:
On Thu, 2020-01-30 at 14:50 +0100, Thomas Zimmermann wrote:
That is bullcrap. I do use TW on two items of i586-class hardware. Not very often, but still. It's just that... webkit is not used by anything I care about (xfce4). According to .spec files:
Well, I just tried xfce4 and found that it uses librsvg. Hence it triggers the same bug. Do you see this on your system as well?
rsvg -> rust... nuff said
Admittedly, I lol'ed.
But then it doesn't really help me with my problem. And according to
zypper se --requires librsvg
almost every graphical environment depends on librsvg. So in practice it imposes a minimal requirement for all things graphics.
Just came across an interesting blog post[0] it contains: """ The 32-bit x86 Rust compiler also targets the "i686" CPU architecture. Sortof. Rust doesn't actually work on these processors, despite claims, because it actually targets the Pentium 4 processor, by using SSE2 instructions that were first introduced on that chip. If you try to run it on a real i686 (a Pentium Pro, Pentium II, or Pentium III), it will try to execute SSE2 instructions which that chip knows nothing about, and crash. """ If there is sufficient demand and our rust maintainer(s) are willing to bite the bullet, we could offer rust as i586 and i686 package. But please, not to many of those i686 packages - or we have to sit together with the OBS team to get the product builder 'smarter' about this; I have to manually list all i686 binaries for now - and so far this was only glibc, where we have .i586 AND .i686 and Firefox (which are .i686 already) Cheers, Dominique [0] https://fraserblog.codewise.org/rust-on-i586/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 30.01.2020 18:46, Dominique Leuenberger / DimStar пишет:
On Thu, 2020-01-30 at 15:52 +0100, Thomas Zimmermann wrote:
Hi
Am 30.01.20 um 15:13 schrieb Dominique Leuenberger / DimStar:
On Thu, 2020-01-30 at 14:50 +0100, Thomas Zimmermann wrote:
That is bullcrap. I do use TW on two items of i586-class hardware. Not very often, but still. It's just that... webkit is not used by anything I care about (xfce4). According to .spec files:
Well, I just tried xfce4 and found that it uses librsvg. Hence it triggers the same bug. Do you see this on your system as well?
rsvg -> rust... nuff said
Admittedly, I lol'ed.
But then it doesn't really help me with my problem. And according to
zypper se --requires librsvg
almost every graphical environment depends on librsvg. So in practice it imposes a minimal requirement for all things graphics.
Just came across an interesting blog post[0] it contains:
""" The 32-bit x86 Rust compiler also targets the "i686" CPU architecture. Sortof. Rust doesn't actually work on these processors, despite claims, because it actually targets the Pentium 4 processor, by using SSE2 instructions that were first introduced on that chip. If you try to run it on a real i686 (a Pentium Pro, Pentium II, or Pentium III), it will try to execute SSE2 instructions which that chip knows nothing about, and crash. """
This post is five years old. I hope the things changed since then. Anyway, I think that if rust generates SSE for i586 target, this should be reported upstream. It is a bug. Or there should be an option to disable. Go compiler may be tuned not to use SSE for i386 go target.
If there is sufficient demand and our rust maintainer(s) are willing to bite the bullet, we could offer rust as i586 and i686 package. But please, not to many of those i686 packages - or we have to sit together with the OBS team to get the product builder 'smarter' about this; I have to manually list all i686 binaries for now - and so far this was only glibc, where we have .i586 AND .i686 and Firefox (which are .i686 already)
Cheers, Dominique
-----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEFnRguwljCXV9IjzOAv0PX1iySn8FAl4y/3kACgkQAv0PX1iy Sn9c+wf+Kgf/soi10jaLb9wvHLb+5k8CZFRTi9hxludBXZiA9Jzz3oVHxAIzJ2Ge LmPzJVoBDDcpzsXBe6FI48ZUJi5iRCoRlg9NHl/7wdxIVGipL8HcNfomdzPVIckY mea+lm8fXoOsZV+gLEaZU+7tTS5qcAtvtggGqyWF/F5pc9mR85YuMd8y2dfyQ5H8 qjERCRxZs6gmgUuXzA2kyx9cX4RmW+eAap276ioWFxMO+SykKl+nCpJ5O2JF+Hrl Ye8pmfQtjLy0xyi0/wWBV21hgeA1CGGqWXkqNf4rPpIUpDOQAWfCebuKr7n3S2B+ 0nuvqfrDLZSBPkL+t0UZOFFFOf3+/w== =BpMp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2020-01-30 at 19:08 +0300, Matwey V. Kornilov wrote:
Just came across an interesting blog post[0] it contains:
""" The 32-bit x86 Rust compiler also targets the "i686" CPU architecture. Sortof. Rust doesn't actually work on these processors, despite claims, because it actually targets the Pentium 4 processor, by using SSE2 instructions that were first introduced on that chip. If you try to run it on a real i686 (a Pentium Pro, Pentium II, or Pentium III), it will try to execute SSE2 instructions which that chip knows nothing about, and crash. """
This post is five years old. I hope the things changed since then. Anyway, I think that if rust generates SSE for i586 target, this should be reported upstream. It is a bug. Or there should be an option to disable. Go compiler may be tuned not to use SSE for i386 go target.
yes, sure, the post is old, so things might have improved (or not: the systems he claimed as old 5 years ago are now - about five years older) But one thing we often fall into the trap is that, just like webkit2gtk3, things tend to check at build time what the processor is capable of and build the binaries accordingly. Do I need to say that OBS has quite new workers and not a single, real, i586 CPU? :) That's what Jan meant with his shout-out that such things should be checked at runtime, not at build time (one of the first replies in this thread) Cheers, Dominique
On Thursday 2020-01-30 17:14, Dominique Leuenberger / DimStar wrote:
Do I need to say that OBS has quite new workers and not a single, real, i586 CPU? :)
OBS also has no native riscv64 workers as far as I can tell and yet it produces RPMs of that kind. ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2020-01-30 at 17:19 +0100, Jan Engelhardt wrote:
On Thursday 2020-01-30 17:14, Dominique Leuenberger / DimStar wrote:
Do I need to say that OBS has quite new workers and not a single, real, i586 CPU? :)
OBS also has no native riscv64 workers as far as I can tell and yet it produces RPMs of that kind. ;-)
Yes, in both cases we use qemu to build the packages. And our config for i586 builds reports: [ 40s] 2nd stage started in virtual machine [ 40s] machine type: i686 And as we already know: i686 is only half the truth - as there is i686 with different feature sets; some with SSE2, some without. Surely, there is a way to tell qemu to not put sse2 features into the VM. but that seems not to be done so far. Keep in mind that disabling SSE2 on i586 has also an impact on 64bit users that install things like wine, steam and so on - basically every 64bit user that has -32bit packages installed. Cheers, Dominique
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 30.01.2020 19:39, Dominique Leuenberger / DimStar пишет:
On Thu, 2020-01-30 at 17:19 +0100, Jan Engelhardt wrote:
On Thursday 2020-01-30 17:14, Dominique Leuenberger / DimStar wrote:
Do I need to say that OBS has quite new workers and not a single, real, i586 CPU? :)
OBS also has no native riscv64 workers as far as I can tell and yet it produces RPMs of that kind. ;-)
Yes, in both cases we use qemu to build the packages. And our config for i586 builds reports:
[ 40s] 2nd stage started in virtual machine [ 40s] machine type: i686
And as we already know: i686 is only half the truth - as there is i686 with different feature sets; some with SSE2, some without. Surely, there is a way to tell qemu to not put sse2 features into the VM. but that seems not to be done so far.
Keep in mind that disabling SSE2 on i586 has also an impact on 64bit users that install things like wine, steam and so on - basically every 64bit user that has -32bit packages installed.
It depends on our understanding of what i586 is. In the ancient times of openSUSE 11.2 I have fully positive experience of running it on i586 CPU without SSE. Nothing ever crashed with SIGILL.
Cheers, Dominique
-----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEFnRguwljCXV9IjzOAv0PX1iySn8FAl4zGbQACgkQAv0PX1iy Sn/fEAf/RlsDE5gBxMW2NieS2KpkM8JFUKhOcymPU5jQ04TQRbVYG4QYMI5Pf6Xx PUuewde58dgS0TAa7Yhfww9B/PtkkJdfZ89+dEdpzsJB2WdOalO7TSKrMQ//im8o bPozdW/0UC5QTa2ezOq6ntPtz29JsM9obPhcgCfyWDL3FA2Q8hIDMqqBD2dyP3Lz uub3Svgno1XcKn5SHLBnOwKxkzv7Gbv8cplhRcey/QZTJfE5RCxeX6gD9rwBtWL/ j76V+8nakl14NNKKzc0QoIPL5gfNYumQkCYioAjeDnArY7ePl54z3ZsGpywWqSt3 wxqqdBliK3IEuNX8gbJhNMl28Wwy2A== =M8eG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-01-30, 14:13 GMT, Dominique Leuenberger / DimStar wrote:
Well, I just tried xfce4 and found that it uses librsvg. Hence it triggers the same bug. Do you see this on your system as well?
rsvg -> rust... nuff said
Is it? Could you elaborate, please? Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Do not long for the night, when people vanish in their place. Be careful, do not turn to evil; for you have preferred this to affliction. -- Job 36:20f (NASB) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 30.01.20 um 16:31 schrieb Matěj Cepl:
On 2020-01-30, 14:13 GMT, Dominique Leuenberger / DimStar wrote:
Well, I just tried xfce4 and found that it uses librsvg. Hence it triggers the same bug. Do you see this on your system as well?
rsvg -> rust... nuff said
Is it? Could you elaborate, please?
Or stay on topic. Your choice.
Matěj
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Thu, 2020-01-30 at 16:31 +0100, Matěj Cepl wrote:
rsvg -> rust... nuff said
Is it? Could you elaborate, please?
Get into the fun of building rust; it's painful 'at best' (actually, ever now and then an update does not give more gray hair..) ok, in all fairness: it is getting better with the latest updates to it. as for rsvg: this used to be a nice library written in C (or was it C++?), early in the build stack. Then it was put behind rust, which builds forever - and that was not the best change for distro builders (but we live with it) Cheers, Dominique
On 2020-01-30 15:13, Dominique Leuenberger / DimStar wrote:
On Thu, 2020-01-30 at 14:50 +0100, Thomas Zimmermann wrote:
Well, I just tried xfce4 and found that it uses librsvg. Hence it triggers the same bug. Do you see this on your system as well?
rsvg -> rust... nuff said
Rust is available for i686 (i586), and LLVM will do the right thing. Where do you see the problem? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Jan 30 2020, aplanas wrote:
On 2020-01-30 15:13, Dominique Leuenberger / DimStar wrote:
On Thu, 2020-01-30 at 14:50 +0100, Thomas Zimmermann wrote:
Well, I just tried xfce4 and found that it uses librsvg. Hence it triggers the same bug. Do you see this on your system as well?
rsvg -> rust... nuff said
Rust is available for i686 (i586), and LLVM will do the right thing.
Depends on rust using the right llvm target (which I haven't checked). Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 30.01.20 um 12:13 schrieb Cristian Rodríguez:
On Thu, Jan 30, 2020 at 7:50 AM Jan Engelhardt <jengelh@inai.de> wrote:
It's the usual crap that programs make use of sse2 without checking cpuid AT DAMN RUNTIME.
And it clearly shows nobody uses TW in old hardware and that there
No it doesn't. It shows that people (me, at least) use TW on old hardware.
should be a way to make the compiler gobally ignore or reinterpret certain flags
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Am Donnerstag, 30. Januar 2020, 12:56:02 CET schrieb Thomas Zimmermann:
Am 30.01.20 um 12:13 schrieb Cristian Rodríguez:
On Thu, Jan 30, 2020 at 7:50 AM Jan Engelhardt <jengelh@inai.de> wrote:
It's the usual crap that programs make use of sse2 without checking cpuid AT DAMN RUNTIME.
And it clearly shows nobody uses TW in old hardware and that there
No it doesn't. It shows that people (me, at least) use TW on old hardware.
And it's getting more with the number of alternatives declining... From the "big" distributions, besides TW only Debian is left (AFAIK), hence the scale of "manual work vs. convenience setup" is covered at both ends ;-) Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 In the past, I remember that i586 binaries must not use SSE extensions. I am not sure about i686 thought. If nothing changed since that ancient times, then it should be considered as a packaging bug. 30.01.2020 13:40, Thomas Zimmermann пишет:
Hi,
I tried to run Tumbleweed on i586 today and when starting Gnome on X11 or got a number of errors caused by invalid opcodes.
[ 630.370899] traps: evolution-sourc[2962] trap invalid opcode ip:ae285db9 sp:bfd6fa00 error:0 in libjavascriptcoregtk- 4.0.so.18.14.8[ad937000+ca8000] [ 631.149280] traps: goa-daemon[3006] trap invalid opcode ip:b454cdb9 sp:bfa6d8f0 error:0 in libjavascriptcoregtk- 4.0.so.18.14.8[b3bfe000+ca8000] [ 632.868196] traps: goa-daemon[3039] trap invalid opcode ip:b453fdb9 sp:bf814b60 error:0 in libjavascriptcoregtk- 4.0.so.18.14.8[b3bf1000+ca8000] [ 637.998523] traps: pool-gnome-shel[3052] trap invalid opcode ip:a01f80dd sp:b163fb90 error:0 in librsvg- 2.so.2.46.0[a0027000+1e8000] [ 638.011551] traps: pool-gnome-shel[2994] trap invalid opcode ip:a01dacef sp:a232bbb0 error:0 in librsvg- 2.so.2.46.0[a0027000+1e8000] [ 653.946106] traps: pool-gnome-shel[3060] trap invalid opcode ip:a19f60dd sp:b16ebb90 error:0 in librsvg- 2.so.2.46.0[a1825000+1e8000] [ 653.967114] traps: pool-gnome-shel[3072] trap invalid opcode ip:a19d8cef sp:a17f9bb0 error:0 in librsvg-2.so.2.46.0[a1825000+1e8000] [ 658.790216] traps: gnome-session-f[3075] trap invalid opcode ip:b4a620dd sp:bfb96f50 error:0 in librsvg- 2.so.2.46.0[b4891000+1e8000]
The processor is an Athlon XP. Compared to a Pentium 4, it lacks a bit on SSE instructions, but I hoped it would still meet the requirements [1]. See the cpuinfo below.
linux:~ # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(tm) XP 1700+ stepping : 2 cpu MHz : 1466.409 cache size : 256 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall bugs : fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass bogomips : 2932.81 clflush size : 32 cache_alignment : 32 address sizes : 34 bits physical, 32 bits virtual power management: ts
It this a bug in the build or is the processor not compatible?
Best regards Thomas
-----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEFnRguwljCXV9IjzOAv0PX1iySn8FAl4yv3QACgkQAv0PX1iy Sn+PMAf+Jc7za3aYtcIEctiaaez3xBRd6o9WklBOp0IO+FHcz4GaqPTPNfAQ6hEQ QTbkzBqcIPcHgDiqf1WbvDSNssMf1oG/j5de1CPSaWq3OGgwiSSQuvF5UbG+pEb/ +0uWBcXZtcnVMoFwfH4nglrdwjDpyP6ur+GkFmzpRFTWt+TUwWzalNM/I9/eLYCT LixxwaB5OPFeyfGwloCCO1994Sl0K810oNG42+xwsdUjThLE9HbvfbKd5n4JcpWa XH5Iu8F79bKl9p8xRaCuY24VgM5KkTOBGZCw99fzkyC0fm6p1jIJyrV6Mnx80/Jp dkshbtQqCns/amp7o9C+0SNMX6ofag== =FIC7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2020-01-30 12:35, Matwey V. Kornilov wrote:
In the past, I remember that i586 binaries must not use SSE extensions. I am not sure about i686 thought. If nothing changed since that ancient times, then it should be considered as a packaging bug.
Instruction-wise, i686 is mostly about CMOV (and maybe FXSAVE). SSE is not mandatory. SSE2 isn't either - as exemplified by the Athlon XP and the Pentium3. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
30.01.2020 14:40, Jan Engelhardt пишет:
On Thursday 2020-01-30 12:35, Matwey V. Kornilov wrote:
In the past, I remember that i586 binaries must not use SSE extensions. I am not sure about i686 thought. If nothing changed since that ancient times, then it should be considered as a packaging bug.
Instruction-wise, i686 is mostly about CMOV (and maybe FXSAVE). SSE is not mandatory. SSE2 isn't either - as exemplified by the Athlon XP and the Pentium3.
I had even more exotic CPUs: https://github.com/SUSE/machinery/issues/2243 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (13)
-
Andreas Schwab -
aplanas -
Cristian Rodríguez -
dieter -
Dominique Leuenberger / DimStar -
Felix Miata -
Hans-Peter Jansen -
Jan Engelhardt -
John Paul Adrian Glaubitz -
Matwey V. Kornilov -
Matěj Cepl -
Richard Biener -
Thomas Zimmermann