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
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
<!-- retain these comments for translator revision tracking -->
<!-- original version: 11648 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 ``firmware'' 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="x86">
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="x86">
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="x86"><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="x86"><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="x86"><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 ``mapped memory'', 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="x86" id="usb-keyboard-config"><title>USB keyboards</title>
<para>
If you have no AT-style keyboard and only a USB model, you will need
to enable legacy AT keyboard emulation in your BIOS setup. Consult
your main board manual and look in the BIOS for "Legacy keyboard
emulation" or "USB keyboard support" options. It must be enabled in
order to boot the installation system. If you enabled this option and
it is working for you, you are fine and can go ahead.
</para><para>
If you cannot find this option, it might be that it is always enabled
and you can continue. It also might mean that the BIOS does not
provide any emulation support (bad luck here).
</para><para>
If you find the option and enable it, but the emulation stops working
soon after the kernel started, then you have bad luck too. You could
try the "bf2.4" flavor where the root floppy brings USB modules. If
you are installing with floppy disks, you would need the keyboard once
before the USB modules can be loaded. Specifying the "keytimer" option
at boot prompt may help in this case.
</para><para>
Sometimes, the emulation hangs but it wakes up after few minutes, so
you could wait some time and try to continue. To fix this behavior,
you could load Linux' own drivers for USB keyboards. For this, use
"modconf" (Step "Configure Device Driver Modules") and load usb-uhci
or usb-ohci modules.
</para>
</sect3>
<sect3><title>More than 64 MB RAM</title>
<para>
The Linux Kernel can not always detect what amount of RAM you have. If
this is the case please look at <xref linkend="boot-parms"/>.
</para>
</sect3>
</sect2>
</sect1>
|
