Source string Read only

(itstool) path: answer/para
192/1920
Context English State
How do I use my delete key in <command>sh</command> and <command>csh</command>?
For the <application>Bourne Shell</application>, add the following lines to <filename>~/.shrc</filename>. See <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> and <citerefentry><refentrytitle>editrc</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
bind ^[[3~ ed-delete-next-char # for xterm
For the <application>C Shell</application>, add the following lines to <filename>~/.cshrc</filename>. See <citerefentry><refentrytitle>csh</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
bindkey ^[[3~ delete-char # for xterm
Other Hardware
Workarounds for no sound from my <citerefentry><refentrytitle>pcm</refentrytitle><manvolnum>4</manvolnum></citerefentry> sound card?
Some sound cards set their output volume to 0 at every boot. Run the following command every time the machine boots:
<prompt>#</prompt> <userinput>mixer pcm 100 vol 100 cd 100</userinput>
Does FreeBSD support power management on my laptop?
FreeBSD supports the <acronym>ACPI</acronym> features found in modern hardware. Further information can be found in <citerefentry><refentrytitle>acpi</refentrytitle><manvolnum>4</manvolnum></citerefentry>.
Troubleshooting
Why is FreeBSD finding the wrong amount of memory on <trademark>i386</trademark> hardware?
The most likely reason is the difference between physical memory addresses and virtual addresses.
The convention for most PC hardware is to use the memory area between 3.5 GB and 4 GB for a special purpose (usually for PCI). This address space is used to access PCI hardware. As a result real, physical memory cannot be accessed by that address space.
What happens to the memory that should appear in that location is hardware dependent. Unfortunately, some hardware does nothing and the ability to use that last 500 MB of RAM is entirely lost.
Luckily, most hardware remaps the memory to a higher location so that it can still be used. However, this can cause some confusion when watching the boot messages.
On a 32-bit version of FreeBSD, the memory appears lost, since it will be remapped above 4 GB, which a 32-bit kernel is unable to access. In this case, the solution is to build a PAE enabled kernel. See the entry on memory limits for more information.
On a 64-bit version of FreeBSD, or when running a PAE-enabled kernel, FreeBSD will correctly detect and remap the memory so it is usable. During boot, however, it may seem as if FreeBSD is detecting more memory than the system really has, due to the described remapping. This is normal and the available memory will be corrected as the boot process completes.
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.)

Loading…

User avatar None

New source string

FreeBSD Doc / books_faqEnglish

New source string 9 months ago
Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: answer/para
Flags
read-only
Source string location
book.translate.xml:1734
String age
9 months ago
Source string age
9 months ago
Translation file
books/faq.pot, string 287