You are not logged in.
Pages: 1
Hi all, thanks for the distro. It has brought my old Intel Galileo back to life!
However, I'm having some problems with some apps. This could be the Quark "segfault bug" Or it could be that this CPU doesn't have all the features needed.
processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 9
model name : Quark SoC X1000
stepping : 0
cpu MHz : 399.088
cache size : 16 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 : 7
wp : yes
flags : fpu vme pse tsc msr pae cx8 apic pbe nx cpuid smep
bugs : itlb_multihit
bogomips : 798.17
clflush size : 32
cache_alignment : 32
address sizes : 32 bits physical, 32 bits virtual
Can anyone confirm to be that i486 should run on the CPU with these flags?
For example, Git and nginx Segfault
Last edited by dmarkey (2021-04-14 10:30:07)
Offline
Good question: my flags are:
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat clflush dts acpi mmx fxsr sse
sse2 ss ht tm pbe nx constant_tsc arch_perfmon p
ebs bts cpuid aperfmperf pni dtes64 monitor ds_c
pl est tm2 ssse3 xtpr pdcm movbe lahf_lm dthermAs far as I'm reading, i484 shouldn't require anything, but that can't be literally true. Listed on that page are CMOV, MMX, and all of the SSEs which allow me to run pentium4 code. If we exclude those from my flags list and those from your flags, that leaves:
de sep mtrr pge mca pat clflush dts fxsr ss ht tm constant_tsc arch_perfmod pebs bts cpuid aperfmerf pril dtes64 monitor ds_c pl est tm3 xtpr pdcm movbe lahf_lm dthermSome of those are almost certainly related to later sse stuff that I don't know about, but I can't say if any of these are needed to run i486 code. I also don't know what the smep flag is.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Hmm.. interesting. I have an alpine image which seems more stable - git works, as works, but like arch, nginx doesn't work. Alpine is completely different though, as it doesn't use libc. Will keep investigating.
Offline
Segfault sounds more like a linking issue of sorts. CPU incompatibilites would more likely result in 'Illegal Instruction'.
I'm testing the i486 architecture currently only on a i486 virtual machine with:
flags : fpu vme pse cpuid tsc_known_freq x2apic hypervisor cpuid_fault
I'm using git without segfaults.
If you can produce a stacktrace, that would be really helpful.
Offline
I just tested on the VM with nginx, I can start it and run a curl http://localhost.
I can test this evening on my lowest profile servers, maybe I can reproduce the issue on real hardware.
Offline
I tried on an AMD-K6:
model name : AMD-K6(tm) 3D processor
flags : fpu vme de pse tsc msr cx8 pge mmx syscall 3dnow k6_mtrr cpuid 3dnowprefetch vmmcall
nginx works, git works, but I found gcc bumping into:
/usr/bin/cc -o CMakeFiles/cmTC_b03e5.dir/testCCompiler.c.o -c /root/cssh/CMakeFiles/CMakeTmp/testCCompiler.c
cc: internal compiler error: Illegal instruction signal terminated program as
Fri 2021-04-16 16:47:13 CEST 663 0 0 4 present /usr/bin/as
Core was generated by `as --32 -o CMakeFiles/cmTC_b03e5.dir/testCCompiler.c.o /tmp/ccTiaULP.s'.
Program terminated with signal SIGILL, Illegal instruction.
Even calling 'ar' without any arguments results in:
Sadly Archlinux (and so Archlinux32) per default, so after building a debug version of binutils for i486
might tell more..
Offline
Apparently the endbr32 instruction only came in with tiger lake CPUs. I'm not sure therefore what it's doing in any archlinux32 builds.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
binutils has been built in the past with --enable-cet=no on i486 and with CET on i686 and pentium4. Somehow either the patch, the flag
or the code enabled/disabled by the flag is no longer working... or somehting completely else. :-)
Offline
As far as I can tell, even pentium4 builds should be built with CET opcodes disabled, but that said I've experienced no crashes in binutils on this system. Perhaps intel replaced the bad opcode with a nop this far back?
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Yes, I opted to keep endbr32 in which gets translated to multi-byte NOPs IIRC. This in order not to create chaos with address computation
(the opcode has the same length). Before some CPU (some pentium IIRC), the multi-byte NOP is missing (only the single-byte NOP is available),
so you get the SIGILL there.
Offline
Some poking around yields:
file grub.efi
grub.efi: PE32 executable (EFI application) Intel 80386 (stripped to external PDB), for MS Windows
boot/grub/grub.cfg
bzImage
core-image-minimal-initramfs-clanton.cpio.gz
grub.efi
image-full-galileo-clanton.ext3
ramdisk
Looks like a FAT32 partition (EFI compliant) with the files and a 32-bit
Grub should do it.
The ramdisk looks quite standard cpio (SVR4 with no CRC, gzipped), it has the
yocto 3.8.7 kernel modules and a busybox and a uclibc.
rootimage=image-full-galileo-clanton.ext3 could presumably be also
a second partition with an ext filesystem containg the root filesystem..
..let's see another day :-)
Offline
Looks reasonable to me, but I don't have any experience with EFI devices, both of my current x86 computers are firmly GPT based.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Pages: 1