Source string Read only

(itstool) path: listitem/para
361/3610
Context English State
Why do my programs occasionally die with <errorname>Signal 11</errorname> errors?
Signal 11 errors are caused when a process has attempted to access memory which the operating system has not granted it access to. If something like this is happening at seemingly random intervals, start investigating the cause.
These problems can usually be attributed to either:
If the problem is occurring only in a specific custom application, it is probably a bug in the code.
If it is a problem with part of the base FreeBSD system, it may also be buggy code, but more often than not these problems are found and fixed long before us general <acronym>FAQ</acronym> readers get to use these bits of code (that is what -CURRENT is for).
It is probably not a FreeBSD bug if the problem occurs compiling a program, but the activity that the compiler is carrying out changes each time.
For example, if <command>make buildworld</command> fails while trying to compile <filename>ls.c</filename> into <filename>ls.o</filename> and, when run again, it fails in the same place, this is a broken build. Try updating source and try again. If the compile fails elsewhere, it is almost certainly due to hardware.
In the first case, use a debugger such as <citerefentry><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry> to find the point in the program which is attempting to access a bogus address and fix it.
In the second case, verify which piece of hardware is at fault.
Common causes of this include:
The hard disks might be overheating: Check that the fans are still working, as the disk and other hardware might be overheating.
The processor running is overheating: This might be because the processor has been overclocked, or the fan on the processor might have died. In either case, ensure that the hardware is running at what it is specified to run at, at least while trying to solve this problem. If it is not, clock it back to the default settings.)
Regarding overclocking, it is far cheaper to have a slow system than a fried system that needs replacing! Also the community is not sympathetic to problems on overclocked systems.
Dodgy memory: if multiple memory SIMMS/DIMMS are installed, pull them all out and try running the machine with each SIMM or DIMM individually to narrow the problem down to either the problematic DIMM/SIMM or perhaps even a combination.
Over-optimistic motherboard settings: the BIOS settings, and some motherboard jumpers, provide options to set various timings. The defaults are often sufficient, but sometimes setting the wait states on RAM too low, or setting the <quote>RAM Speed: Turbo</quote> option will cause strange behavior. A possible idea is to set to BIOS defaults, after noting the current settings first.
Unclean or insufficient power to the motherboard. Remove any unused I/O boards, hard disks, or CD-ROMs, or disconnect the power cable from them, to see if the power supply can manage a smaller load. Or try another power supply, preferably one with a little more power. For instance, if the current power supply is rated at 250 Watts, try one rated at 300 Watts.
Read the section on <link linkend="signal11">Signal 11</link> for a further explanation and a discussion on how memory testing software or hardware can still pass faulty memory. There is an extensive <acronym>FAQ</acronym> on this at <link xlink:href="http://www.bitwizard.nl/sig11/">the SIG11 problem <acronym>FAQ</acronym></link>.
Finally, if none of this has helped, it is possibly a bug in FreeBSD. Follow <link linkend="access-pr">these instructions</link> to send a problem report.
My system crashes with either <errorname>Fatal trap 12: page fault in kernel mode</errorname>, or <errorname>panic:</errorname>, and spits out a bunch of information. What should I do?
The FreeBSD developers are interested in these errors, but need more information than just the error message. Copy the full crash message. Then consult the <acronym>FAQ</acronym> section on <link linkend="kernel-panic-troubleshooting">kernel panics</link>, build a debugging kernel, and get a backtrace. This might sound difficult, but does not require any programming skills. Just follow the instructions.
What is the meaning of the error <errorname>maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)</errorname>?
The FreeBSD kernel will only allow a certain number of processes to exist at one time. The number is based on the <varname>kern.maxusers</varname> <citerefentry><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> variable. <varname>kern.maxusers</varname> also affects various other in-kernel limits, such as network buffers. If the machine is heavily loaded, increase <varname>kern.maxusers</varname>. This will increase these other system limits in addition to the maximum number of processes.
To adjust the <varname>kern.maxusers</varname> value, see the <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html#kern-maxfiles">File/Process Limits</link> section of the Handbook. While that section refers to open files, the same limits apply to processes.
If the machine is lightly loaded but running a very large number of processes, adjust the <varname>kern.maxproc</varname> tunable by defining it in <filename>/boot/loader.conf</filename>. The tunable will not get adjusted until the system is rebooted. For more information about tuning tunables, see <citerefentry><refentrytitle>loader.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If these processes are being run by a single user, adjust <varname>kern.maxprocperuid</varname> to be one less than the new <varname>kern.maxproc</varname> value. It must be at least one less because one system program, <citerefentry><refentrytitle>init</refentrytitle><manvolnum>8</manvolnum></citerefentry>, must always be running.
Why do full screen applications on remote machines misbehave?
The remote machine may be setting the terminal type to something other than <literal>xterm</literal> which is required by the FreeBSD console. Alternatively the kernel may have the wrong values for the width and height of the terminal.
Check the value of the <envar>TERM</envar> environment variable is <literal>xterm</literal>. If the remote machine does not support that try <literal>vt100</literal>.
Run <command>stty -a</command> to check what the kernel thinks the terminal dimensions are. If they are incorrect, they can be changed by running <command>stty rows <replaceable>RR</replaceable> cols <replaceable>CC</replaceable></command>.
Alternatively, if the client machine has <package>x11/xterm</package> installed, then running <command>resize</command> will query the terminal for the correct dimensions and set them.
Why does it take so long to connect to my computer via <command>ssh</command> or <command>telnet</command>?
The symptom: there is a long delay between the time the TCP connection is established and the time when the client software asks for a password (or, in <citerefentry><refentrytitle>telnet</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s case, when a login prompt appears).

Loading…

User avatar None

New source string

FreeBSD Doc / books_faqEnglish

New source string 6 months ago
Browse all component changes

Things to check

Long untranslated

The string has not been translated for a long time

Reset

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: listitem/para
Flags
read-only
Source string location
book.translate.xml:1861
String age
6 months ago
Source string age
6 months ago
Translation file
books/faq.pot, string 306