Форумы Zyxmon`а
Illegal instruction на х86 сборке и х86 проце
dals2050 Сообщения: 7 Зарегистрирован: 23 окт 2019, 15:24
Сообщение dals2050 » 23 окт 2019, 16:06
Здравствуйте!
Устанавливаю х86 сборки entware и qnapware на Android_x86 (РС-версия).
shell@eeepc:/ $ uname -a Linux localhost 3.0.36-android-x86-eeepc+ #1 SMP PREEMPT Fri Jul 13 19:55:18 CST 2012 i686 GNU/Linux shell@eeepc:/Apps/opt/bin $ ./opkg print-architecture arch all 1 arch noarch 1 arch qnapx86 10 shell@eeepc:/Apps/opt/bin $ ./opkg info nano Package: nano Version: 2.4.2-1 Depends: libc, libncursesw Status: install user installed Section: utils Architecture: qnapx86 Maintainer: Jonathan Bennett MD5Sum: 64d1e846a4c4e2589656ac3f9b9740f6 Size: 35565 Filename: nano_2.4.2-1_qnapx86.ipk Source: feeds/packages/utils/nano shell@eeepc:/Apps/opt/bin $ ./nano Illegal instruction Результат идентичный — opkg работает нормально, но при попытке запуска пакетов mc, nano (другие пока не интересуют), вылетает ошибка «Illegal instruction».
Подозреваю, что дело в процессоре (может, отсутствии в нём SSE2?)
shell@eeepc:/ $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Celeron(R) M processor 900MHz stepping : 8 cpu MHz : 900.031 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts bogomips : 1800.06 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management:Как исправить ошибку Illegal instruction?
Хотел установить npm пакеты. Но система жалуется Illegal instruction. Что это значит? Скрин.
Deleted
15.03.20 13:57:14 MSK
ratvier ★
( 15.03.20 14:07:15 MSK )
Ответ на: комментарий от ratvier 15.03.20 14:07:15 MSK
Походу разрабы nodejs дибилы, не оставили выбор для пентиум процессорам. Надо же гады а! А ведь некоторые VPS’ки до сих пор работают на старых пентиумах.
Deleted
( 15.03.20 14:16:36 MSK )
можно скомпилировать npm под твой процессор
Saved searches
Use saved searches to filter your results more quickly
Cancel Create saved search
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
forked from ggerganov/llama.cpp
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Illegal instruction (core dumped) #101
nm616 opened this issue Mar 21, 2023 · 6 comments
Illegal instruction (core dumped) #101
nm616 opened this issue Mar 21, 2023 · 6 comments
Comments
nm616 commented Mar 21, 2023
Im getting ‘Illegal instruction (core dumped)’ when running ./chat on the latest linux release. Tried with 7b, 13b and 30b. All are doing the same thing. Am I missing something?
Ubuntu 22.04.2 LTS
The text was updated successfully, but these errors were encountered:
calz1 commented Mar 21, 2023 •
I get this too for the 13B model. I downloaded:
and ran:
./chat -m ggml-alpaca-13b-q4.bin
I’m using Xubuntu 22 on a 4 core VM within Hyper-V, with 64GB of RAM.
myNicole98 commented Mar 21, 2023
something something is wrong with CPUs that support AVX but doesn’t support AVX2. The quickest way to get rid of the illegal instruction error is to delete «chat», edit the Makefile and remove all -mavx and -mavx2 flags. Save and recompile with «make chat»
nkolotovkin1 commented Mar 21, 2023
something something is wrong with CPUs that support AVX but doesn’t support AVX2. The quickest way to get rid of the illegal instruction error is to delete «chat», edit the Makefile and remove all -mavx and -mavx2 flags. Save and recompile with «make chat»
thx for slow speed ;D
myNicole98 commented Mar 21, 2023
something something is wrong with CPUs that support AVX but doesn’t support AVX2. The quickest way to get rid of the illegal instruction error is to delete «chat», edit the Makefile and remove all -mavx and -mavx2 flags. Save and recompile with «make chat»
thx for slow speed ;D
I didn’t find any other solution unfortunately e.e better slow than nothing at all I guess
nkolotovkin1 commented Mar 21, 2023
что-то не так с процессорами, которые поддерживают AVX, но не поддерживают AVX2. Самый быстрый способ избавиться от ошибки недопустимой инструкции — это удалить «chat», отредактировать Makefile и удалить все флаги -mavx и -mavx2. Сохраните и перекомпилируйте с помощью «сделать чат»
спасибо за медленную скорость ;D
Я не нашел другого решения, к сожалению, лучше медленно, чем вообще ничего, я думаю
i also had to remove -mfma -mf16c to make it work
Status illegal instruction что за ошибка
The following signals are generated when a serious program error is detected by the operating system or the computer itself. In general, all of these signals are indications that your program is seriously broken in some way, and there’s usually no way to continue the computation which encountered the error.
Some programs handle program error signals in order to tidy up before terminating; for example, programs that turn off echoing of terminal input should handle program error signals in order to turn echoing back on. The handler should end by specifying the default action for the signal that happened and then reraising it; this will cause the program to terminate with that signal, as if it had not had a handler. (See Handlers That Terminate the Process.)
Termination is the sensible ultimate outcome from a program error in most programs. However, programming systems such as Lisp that can load compiled user programs might need to keep executing even if a user program incurs an error. These programs have handlers which use longjmp to return control to the command level.
The default action for all of these signals is to cause the process to terminate. If you block or ignore these signals or establish handlers for them that return normally, your program will probably break horribly when such signals happen, unless they are generated by raise or kill instead of a real error.
When one of these program error signals terminates a process, it also writes a core dump file which records the state of the process at the time of termination. The core dump file is named core and is written in whichever directory is current in the process at the time. (On GNU/Hurd systems, you can specify the file name for core dumps with the environment variable COREFILE .) The purpose of core dump files is so that you can examine them with a debugger to investigate what caused the error.
Macro: int SIGFPE ¶
The SIGFPE signal reports a fatal arithmetic error. Although the name is derived from “floating-point exception”, this signal actually covers all arithmetic errors, including division by zero and overflow. If a program stores integer data in a location which is then used in a floating-point operation, this often causes an “invalid operation” exception, because the processor cannot recognize the data as a floating-point number.
Actual floating-point exceptions are a complicated subject because there are many types of exceptions with subtly different meanings, and the SIGFPE signal doesn’t distinguish between them. The IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985 and ANSI/IEEE Std 854-1987) defines various floating-point exceptions and requires conforming computer systems to report their occurrences. However, this standard does not specify how the exceptions are reported, or what kinds of handling and control the operating system can offer to the programmer.
BSD systems provide the SIGFPE handler with an extra argument that distinguishes various causes of the exception. In order to access this argument, you must define the handler to accept two arguments, which means you must cast it to a one-argument function type in order to establish the handler. The GNU C Library does provide this extra argument, but the value is meaningful only on operating systems that provide the information (BSD systems and GNU systems).
Integer overflow (impossible in a C program unless you enable overflow trapping in a hardware-specific fashion).
Integer division by zero.
Subscript-range (something that C programs never check for).
Floating overflow trap.
Floating/decimal division by zero.
Floating underflow trap. (Trapping on floating underflow is not normally enabled.)
Decimal overflow trap. (Only a few machines have decimal arithmetic and C never uses it.)
Macro: int SIGILL ¶
The name of this signal is derived from “illegal instruction”; it usually means your program is trying to execute garbage or a privileged instruction. Since the C compiler generates only valid instructions, SIGILL typically indicates that the executable file is corrupted, or that you are trying to execute data. Some common ways of getting into the latter situation are by passing an invalid object where a pointer to a function was expected, or by writing past the end of an automatic array (or similar problems with pointers to automatic variables) and corrupting other data on the stack such as the return address of a stack frame.
SIGILL can also be generated when the stack overflows, or when the system has trouble running the handler for a signal.
Macro: int SIGSEGV ¶
This signal is generated when a program tries to read or write outside the memory that is allocated for it, or to write memory that can only be read. (Actually, the signals only occur when the program goes far enough outside to be detected by the system’s memory protection mechanism.) The name is an abbreviation for “segmentation violation”.
Common ways of getting a SIGSEGV condition include dereferencing a null or uninitialized pointer, or when you use a pointer to step through an array, but fail to check for the end of the array. It varies among systems whether dereferencing a null pointer generates SIGSEGV or SIGBUS .
Macro: int SIGBUS ¶
This signal is generated when an invalid pointer is dereferenced. Like SIGSEGV , this signal is typically the result of dereferencing an uninitialized pointer. The difference between the two is that SIGSEGV indicates an invalid access to valid memory, while SIGBUS indicates an access to an invalid address. In particular, SIGBUS signals often result from dereferencing a misaligned pointer, such as referring to a four-word integer at an address not divisible by four. (Each kind of computer has its own requirements for address alignment.)
The name of this signal is an abbreviation for “bus error”.
Macro: int SIGABRT ¶
This signal indicates an error detected by the program itself and reported by calling abort . See Aborting a Program.
Macro: int SIGIOT ¶
Generated by the PDP-11 “iot” instruction. On most machines, this is just another name for SIGABRT .
Macro: int SIGTRAP ¶
Generated by the machine’s breakpoint instruction, and possibly other trap instructions. This signal is used by debuggers. Your program will probably only see SIGTRAP if it is somehow executing bad instructions.
Macro: int SIGEMT ¶
Emulator trap; this results from certain unimplemented instructions which might be emulated in software, or the operating system’s failure to properly emulate them.
Macro: int SIGSYS ¶
Bad system call; that is to say, the instruction to trap to the operating system was executed, but the code number for the system call to perform was invalid.