1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
|
<!-- retain these comments for translator revision tracking -->
<!-- original version: 28997 untranslated -->
<sect1 id="pre-install-bios-setup">
<title>Pre-Installation Hardware and Operating System Setup</title>
<para>
This section will walk you through pre-installation hardware setup, if
any, that you will need to do prior to installing Debian. Generally,
this involves checking and possibly changing firmware settings for
your system. The <quote>firmware</quote> is the core software used by the
hardware; it is most critically invoked during the bootstrap process
(after power-up). Known hardware issues affecting the reliability of
&debian; on your system are also highlighted.
</para>
&bios-setup-i386.xml;
&bios-setup-m68k.xml;
&bios-setup-powerpc.xml;
&bios-setup-sparc.xml;
&bios-setup-s390.xml;
<sect2><title>Hardware Issues to Watch Out For</title>
<para arch="not-s390">
Many people have tried operating their 90 MHz CPU at 100 MHz, etc. It
sometimes works, but is sensitive to temperature and other factors and
can actually damage your system. One of the authors of this document
over-clocked his own system for a year, and then the system started
aborting the <command>gcc</command> program with an unexpected signal
while it was compiling the operating system kernel. Turning the CPU
speed back down to its rated value solved the problem.
</para><para arch="not-s390">
The <command>gcc</command> compiler is often the first thing to die
from bad memory modules (or other hardware problems that change data
unpredictably) because it builds huge data structures that it
traverses repeatedly. An error in these data structures will cause it
to execute an illegal instruction or access a non-existent
address. The symptom of this will be <command>gcc</command> dying from
an unexpected signal.
</para><para arch="m68k">
Atari TT RAM boards are notorious for RAM problems under Linux; if you
encounter any strange problems, try running at least the kernel in
ST-RAM. Amiga users may need to exclude RAM using a booter memfile.
<phrase condition="FIXME"><emphasis>
FIXME: more description of this needed.
</emphasis></phrase>
</para><para arch="i386">
The very best motherboards support parity RAM and will actually tell
you if your system has a single-bit error in RAM. Unfortunately, they
don't have a way to fix the error, thus they generally crash
immediately after they tell you about the bad RAM. Still, it's better
to be told you have bad memory than to have it silently insert errors
in your data. Thus, the best systems have motherboards that support
parity and true-parity memory modules; see
<xref linkend="Parity-RAM"/>.
</para><para arch="i386">
If you do have true-parity RAM and your motherboard can handle it, be
sure to enable any BIOS settings that cause the motherboard to
interrupt on memory parity errors.
</para>
<sect3 arch="i386"><title>The Turbo Switch</title>
<para>
Many systems have a <emphasis>turbo</emphasis> switch that controls
the speed of the CPU. Select the high-speed setting. If your BIOS
allows you to disable software control of the turbo switch (or
software control of CPU speed), do so and lock the system in
high-speed mode. We have one report that on a particular system, while
Linux is auto-probing (looking for hardware devices) it can
accidentally touch the software control for the turbo switch.
</para>
</sect3>
<sect3 arch="i386"><title>Cyrix CPUs and Floppy Disk Errors</title>
<para>
Many users of Cyrix CPUs have had to disable the cache in their
systems during installation, because the floppy disk has errors if
they do not. If you have to do this, be sure to re-enable your cache
when you are finished with installation, as the system runs
<emphasis>much</emphasis> slower with the cache disabled.
</para><para>
We don't think this is necessarily the fault of the Cyrix CPU. It may
be something that Linux can work around. We'll continue to look into
the problem. For the technically curious, we suspect a problem with
the cache being invalid after a switch from 16-bit to 32-bit code.
</para>
</sect3>
<sect3 arch="i386"><title>Peripheral Hardware Settings</title>
<para>
You may have to change some settings or jumpers on your computer's
peripheral cards. Some cards have setup menus, while others rely on
jumpers. This document cannot hope to provide complete information on
every hardware device; what it hopes to provide is useful tips.
</para><para>
If any cards provide <quote>mapped memory</quote>, the memory should be
mapped somewhere between 0xA0000 and 0xFFFFF (from 640K to just below 1
megabyte) or at an address at least 1 megabyte greater than the total
amount of RAM in your system.
</para>
</sect3>
<sect3 arch="i386" id="usb-keyboard-config">
<title>USB BIOS support and keyboards</title>
<para>
If you have no AT-style keyboard and only a USB model, you may need
to enable legacy AT keyboard emulation in your BIOS setup. Only do this if
the installation system fails to use your keyboard in USB mode. Conversely,
for some systems (especially laptops) you may need to disable legacy USB
support if your keyboard does not respond.
Consult your main board manual and look in the BIOS for <quote>Legacy
keyboard emulation</quote> or <quote>USB keyboard support</quote> options.
</para>
</sect3>
<sect3><title>More than 64 MB RAM</title>
<para>
The Linux Kernel cannot always detect what amount of RAM you have. If
this is the case please look at <xref linkend="boot-parms"/>.
</para>
</sect3>
</sect2>
</sect1>
|
