Subject: [docathon] converted Ports/alpha/faq.list
To: None <netbsd-docs@netbsd.org>
From: None <dsieger@techfak.uni-bielefeld.de>
List: netbsd-docs
Date: 04/06/2007 14:03:35
--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Port/alpha/faq.list is done
Regards,
Daniel
--
Daniel Sieger
Faculty of Technology
Bielefeld University
wwwhomes.uni-bielefeld.de/dsieger
--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="alpha-faq.diff"
Index: Makefile
===================================================================
RCS file: /cvsroot/htdocs/Ports/alpha/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- Makefile 14 Oct 2005 08:59:57 -0000 1.16
+++ Makefile 6 Apr 2007 11:58:30 -0000
@@ -1,8 +1,8 @@
# $NetBSD: Makefile,v 1.16 2005/10/14 08:59:57 rillig Exp $
# Process .list files into .html files
-XMLDOCS+= index
+XMLDOCS+= index faq
-LISTDOCS+= faq.list models.list multiafaq.list
+LISTDOCS+= models.list multiafaq.list
.include "../../share/mk/web.site.mk"
Index: layout.xml
===================================================================
RCS file: /cvsroot/htdocs/layout.xml,v
retrieving revision 1.231
diff -u -r1.231 layout.xml
--- layout.xml 4 Apr 2007 08:21:51 -0000 1.231
+++ layout.xml 6 Apr 2007 11:59:06 -0000
@@ -199,9 +203,13 @@
<tocentry page="Ports/index.xml" dir="Ports" filename=".">
<tocentry page="Ports/emulators.xml" filename="emulators.html"/>
<tocentry page="Ports/acorn26/index.xml" dir="acorn26" filename="."/>
- <tocentry page="Ports/alpha/index.xml" dir="alpha" filename="."/>
+ <tocentry page="Ports/alpha/index.xml" dir="alpha" filename=".">
+ <tocentry page="Ports/alpha/faq.xml" filename="faq.html"/>
+ </tocentry>
<tocentry page="Ports/amd64/index.xml" dir="amd64" filename="."/>
<tocentry page="Ports/amiga/index.xml" dir="amiga" filename="."/>
<tocentry page="Ports/amigappc/index.xml" dir="amigappc" filename="."/>
--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="faq.xml"
<?xml version="1.0"?>
<!DOCTYPE webpage
PUBLIC "-//NetBSD//DTD Website-based NetBSD Extension//EN"
"http://www.NetBSD.org/XML/htdocs/share/xml/website-netbsd.dtd">
<webpage id="Ports-alpha-faq">
<config param="desc" value="NetBSD/alpha Frequently Asked Questions"/>
<config param="cvstag" value="$NetBSD: Exp $"/>
<config param="rcsdate" value="$Date: $"/>
<head>
<!-- Copyright (c) 2006-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED. -->
<title>&os;/alpha Frequently Asked Questions</title>
</head>
<sect1 role="toc">
<sect2 id="cons_firm">
<title>Console and Console Firmware Issues</title>
<sect3 id="serial-consoles">
<para>What's the story on serial consoles? All versions of SRM
do a good job with serial consoles. This is actually a Very
Good Thing, because it means you can remotely administer
systems, leave them locked up in nice cool machine rooms, keep
big noisy boxes out of your work areas, etc...</para>
<para>It also means you can boot any system, even ones that have
display hardware that we don't support. And in fact,
&os;/alpha development funding has placed emphasis on
running general servers and X clients, but not on running X
servers and other desktop boxes, so sometimes the only way to
boot is to use a serial console. On a few older systems, the
graphics hardware is completely undocumented, so serial
consoles save the day there, too.</para>
<para>On almost all alpha systems, SRM switches into serial
console mode if there is no keyboard when power is turned
on. On some 3000 series machines, there is a switch in the
back that determines the console mode. I believe there is also
an SRM non-volatile variable, but you probably don't want to
set it, as it means you are then stuck in one mode and can't
just plug or unplug a keyboard to switch.</para>
<para>Most alpha systems have com ports just like the Pee Cee,
so it should be fairly obvious how to hook these back to back
with another computer acting as a terminal by running
&man.tip.1; in an <application>xterm</application> or some
PeeCee terminal emulator like
<application>HyperTerm</application>.</para>
<para>If you are unlucky enough to have the technically nice but
highly incompatible DEC MMJ ... say, on a 3000/400 ... you
will need to buy or borrow the appropriate DEC MMJ adapters
and line cord or make your own. To make one, see <ulink
url="../../Documentation/Hardware/Misc/">the &os; Hardware
Documentation - Misc</ulink> page, go to <quote>Tommy's Pinout
Collection</quote>, and search for <quote>MMJ</quote>. There
you will see documentation on the DEC MMJ pinout, and on the
DB9 that PC and workstation com ports usually use. To build
an adapter, you may want to cut the latch off an ordinary line
cord, so it will fit in the MMJ socket, and then wire the
cable as follows:</para>
<itemizedlist>
<listitem>
<para>Connect the MMJ <quote>TX+</quote> to the serial
port's <quote>RXD</quote>.</para>
</listitem>
<listitem>
<para>Connect the MMJ <quote>RX+</quote> to the serial
port's <quote>TXD</quote>.</para>
</listitem>
</itemizedlist>
<para>If you aren't sure which is <quote>TX+</quote> and which
is <quote>RX+</quote>, but you have a voltmeter or LED,
<quote>TX+</quote> is the one with the higher absolute voltage
magnitude, and the one that can light up the LED. (Try the LED
both ways; obviously it only lights up in one direction.) I'm
not sure I agree with tying <quote>TX-</quote> and
<quote>RX-</quote> together as implied by the pinout
collection diagram; if you connect no signal ground at all,
you will still get return current through the equipment
protective ground, which will work fairly well if the terminal
or terminal emulator shares a common power circuit with the
3000 and they are reasonably close together.</para>
<para>Another approach would be to connect the DEC MMJ
to a Mac or Sun box which also has a differential serial
interface.</para>
<para>Additionally, see the <ulink
url="../../Documentation/Hardware/Misc/serial.html">&os;
Serial Port Primer</ulink>.</para>
</sect3>
<sect3 id="why-firmware">
<title>Why does &os;/alpha need firmware?</title>
<para>It is possible to run on the bare hardware. But there are
some things that the PALcode does that are <emphasis>quite</emphasis>
model-specific:</para>
<itemizedlist>
<listitem>
<para>various cache issues</para>
</listitem>
<listitem>
<para>various interrupt issues (e.g. issuing EOIs,
interrupt routing, etc.)</para>
</listitem>
<listitem>
<para>machine checks generated by the core
logic</para>
</listitem>
<listitem>
<para>machine checks generated by the I/O
processors</para>
</listitem>
</itemizedlist>
<para>...and the list goes on.</para>
<para>This doesn't include the processor-model specific
stuff:</para>
<itemizedlist>
<listitem>TLB differences</listitem>
<listitem>cache differences</listitem>
<listitem>trap differences</listitem>
</itemizedlist>
<para>..and the list goes on here, too.</para>
<para>Basically, the PALcode provides a very nice abstraction to
which the Operating System can be ported - running on the bare
hardware would be a real pain.</para>
<para>Note, SRM isn't really required, per se. &os;/alpha
does run on a platform that doesn't have SRM; it's a parallel
multicomputer called the Avalon A12. It's not a DEC machine.
It doesn't have DEC console software. The console software it
does have, however, provides OSF/1 PALcode, and the A12
console software also complies with the Alpha Console
Architecture as described in the architecture manual. SRM
also complies with this (obviously). The AlphaBIOS console
software complies with ARC (originally a console specification
for MIPS systems), and not with Alpha Console
Architecture.</para>
<para>If someone were to write some free console software,
please pay careful attention to the Green and or Red Book's
description of the Console Architecture. The Console
Architecture doesn't suck.</para>
<para>Now, strictly speaking, the console software and the
PALcode are distinct entities. When &os; calls the PALcode,
it's not calling the console software, really. It's calling
the PALcode. There is a standard PALcode operations called
`swppal' which enables you do switch to a different PALcode
image on the fly (the &os;/alpha boot loader does this; SRM
comes up in the OpenVMS PALcode by default).</para>
<para>However, the PALcode is called literally all the time.
Take a &os; kernel image sometime, pump it though
<application>objdump</application>
<option>--disassemble</option>, and grep for the
<code>call_pal</code> instruction:</para>
<programlisting>
bishop:thorpej 53$ pwd
/usr/src/sys/arch/alpha/compile/GENERIC
bishop:thorpej 54$ objdump --disassemble netbsd | grep -c call_pal
4807
bishop:thorpej 55$ </programlisting>
<para>Some of those are in key places, like, for example, all
traps (syscalls, interrupts, page faults, etc.). The C
library uses it, too. It's how system calls are made (the
`callsys' PALcode operation).</para>
</sect3>
<sect3 id="nt-firmware">
<title>Can &os;/alpha run on systems with only NT (ARC)
firmware?</title>
<para>Not currently. &os;/alpha requires the SRM Console
firmware (used by OSF/1 and OpenVMS) to function. There are
two main reasons for this: the console software is what's
responsible for loading the operating system's primary
bootstrap program, and the firmware provides the PALcode for
the system, which handles low-level memory management and
interrupt handling details on a system-specific basis. (&os;
uses the Digital Unix PALcode.)</para>
<para>The NT PALcode is documented pretty well in the Green
Book, and probably even better in the Red Book. It might not
be totally unreasonable to think about a &os;/arcalpha
... however, the NT PALcode comes with some caveats:</para>
<itemizedlist>
<listitem>
<para>It's very geared to NT's kernel model</para>
</listitem>
<listitem>
<para>Memory management is essentially MIPS-like, and also
limits the virtual address space to 32-bit (except for
some virtual address extension hack used to get at the
hardware in the kernel)</para>
</listitem>
<listitem>
<para>It's ... amazingly large and complex. The number of
NT PALcode calls is simply mind boggling.</para>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="milo">
<title>Can &os;/alpha use MILO to run on systems without SRM?</title>
<para>The Alpha port of Linux can boot on systems with NT
firmware not because they can use the NT PALcode, but because
MILO, the Alpha Linux loader, includes its own PALcode. (This
of course means you need a different loader for each system
type.) The MILO PALcode is:</para>
<itemizedlist>
<listitem>
<para>Based on very old Digital Unix PALcode (from the DEC
EBSDK).</para>
</listitem>
<listitem>
<para>Missing various features needed by &os;.</para>
</listitem>
<listitem>
<para>Known to have a number of serious bugs.</para>
</listitem>
<listitem>
<para>Worked-over to be built with a totally different toolchain than
the PALcode in production SRM.</para>
</listitem>
</itemizedlist>
<para>Ross Harvey was on the verge of fixing some of the more
obnoxious bugs in it once but managed to obtain the real SRM
PALcode for the project on which he was working, so he didn't.
It is probably more productive to spend time persuading DEC to
release SRM for more platforms, or to release the unmodified
source code to a <emphasis>current</emphasis> SRM, including
the PALcode, than fix the MILO PALcode for &os;,
particularly as Linux also uses SRM for more modern
systems.</para>
</sect3>
<sect3 id="srm-console">
<title>Where do I get a copy of the SRM console for my
machine?</title>
<para>For those who own AlphaStation, AlphaServer, AlphaPC164,
Multia or AXPpci boxen, the SRM console can be obtained
through either the <quote>Alpha Systems Firmware Update
CD</quote> (part number QZ-003AA-E8) or from <ulink
url="http://ftp.digital.com/pub/DEC/Alpha/firmware/">
http://ftp.digital.com/pub/DEC/Alpha/firmware/</ulink>.
</para>
<para>Owners of older Alpha Evaluation Boards and older AlphaPC
motherboards should peruse the <quote>Alpha EBSDK and Firmware
Update Kit</quote> (part number QR-21B02-03). This can be
obtained from DEC Direct for $75 + S&H.</para>
</sect3>
<sect3 id="multiuser-boot">
<title>How do I get it to (not to) automatically boot
multi-user?</title>
<para>There are two non-volatile SRM environment variables that
affect the automatically initiated console actions.</para>
<variablelist>
<varlistentry>
<term><code>BOOT_OSFLAGS</code>
</term>
<listitem>
If set to <option>A</option> or <option>a</option>, &os; will
automatically proceed from single-user to multi-user
state. This can be overwritten with the <option>-fl</option>
option to the console <command>boot</command> command. This is for
compatibility with Digital Unix.
</listitem>
</varlistentry>
<varlistentry>
<term><code>AUTO_ACTION</code>
</term>
<listitem>This tells SRM what to do when it gets control.
Your choices here are BOOT or HALT. The HALT case gets
you the <code>>>></code> prompt.
</listitem>
</varlistentry>
<varlistentry>
<term><code>BOOTDEF_DEV</code>
</term>
<listitem>This tells SRM which device to boot from. <command>show
config</command> can show you what your choices are. To
tell it to boot from floppy, for example, you would say
<command>set bootdef_dev dva0</command>.
</listitem>
</varlistentry>
</variablelist>
<para><emphasis>Examples:</emphasis></para>
<screen>
>>> set boot_osflags a
>>> set auto_action boot
>>> set bootdef_dev dka0
>>> boot -fl a</screen>
</sect3>
<sect3 id="srm_fw">
<title>Why does my firmware not have the
<filename>srm_fw</filename> file?</title>
<para>For at least the AlphaServer1000, when booting an Alpha
Firmware cdrom when attached to a network, the update program
is unable to find the <filename>srm_fw</filename> file and
thus can not update it. This is remedied by unplugging the
network.</para>
</sect3>
<sect3 id="3000-400-firmware">
<title>Upgrading 3000/400 firmware</title>
<para>Upgrading the firmware on a 3000/400 can be a dangerous
operation, as it needs to have a sufficiently new SROM chip or
else an upgrade from an old version of the firmware to a
fairly new one will trash the system and cause it to
machine-check at power-on.</para>
<para>Be sure to read the <ulink
url="http://www.xray.mpe.mpg.de/mailing-lists/tru64-unix-managers/9507/msg00317.html">upgrade
advice</ulink> posted to the <ulink
url="http://www.xray.mpe.mpg.de/mailing-lists/tru64-unix-managers/">tru64-unix-managers</ulink>
mailing list.</para>
</sect3>
</sect2>
<sect2 id="compiling">
<title>Compiling and Programming</title>
<sect3 id="compile">
<title>Compiling a program that works on i386 gives strange
errors on alpha</title>
<para>Errors such as:</para>
<programlisting>
foo.c:91: cast from pointer to integer of different size.</programlisting>
<para>An alpha is a 64bit native machine. Unlike a pentium or
mac, which are 32 bit machines. A lot of programmers assume
things like pointers are 32 bits. So when you compile them on
alphas, they suddenly emit tons of warnings. Generally
speaking you can get away with ignoring these, and &os; is
smart enough to fix them up for you and do the right thing
with them. (it will *not* do this for kernel code!) If your
program exhibits strange behavior, you will need to sit down
and examine the code, and attempt to sort out all the 64bit
uncleanliness.</para>
</sect3>
<sect3 id="not-computable">
<title>Error message <quote>initializer element... is not
computable</quote></title>
<para>An error message</para>
<programlisting>
foo.c:192: initializer element for `foo' is not computable at load time</programlisting>
<para>is given, and the compile stops. The code in question basicly
attempts to do: <code>int foo=(int)"string";</code></para>
<para>This is almost certainly due to foo being 32 bits and the
address of "string" being 64 bits. So you're telling the
compiler to store the lower part of the address and there
isn't a mechanism in ELF to do that. The fix is sometimes to
set the <code>int</code> to <code>long</code>, or to use
<code>char *</code> instead.</para>
</sect3>
<sect3 id="cpp-link">
<title>Trouble compiling programs with makefiles that use
cpp.</title>
<para>In older releases and snapshots the toolchain installed
into <filename>/usr/local</filename>, so programs such as
<filename>/usr/libexec/cpp</filename> didn't exist and links
needed to be placed, .e.g,
<filename>/usr/libexec/cpp</filename> needed to be a symbolic
link pointing to the directory the GNU toolchain packaged
created. This was something like
<code>/usr/local/lib/gcc-lib/alpha-unknown-netbsd1.3/2.7.2.2/cpp</code></para>
<para>However, &os; 1.3.2 and the most recent binary snapshot
of the development branch (&os;-current) install the
toolchain elements into the usual places. If you see this
problem and you are not running the 1.3.3 release or a
snapshot from June 1998 or later, then just upgrade! (It's
free.)</para>
</sect3>
<sect3 id="assembler">
<title>How do I write an assembly program?</title>
<para>Below is Hello, world. Caution: like other RISC
architectures, the alpha can't necessarily load an address or
an arbitrarily large constant in a single instruction; the
examples below use a couple of build-in assembler macros that
are expanded as needed.</para>
<programlisting>
/*
* hw.S
*
* cc hw.S
* ./a.out
*/
#include <machine/asm.h>
#include <sys/syscall.h>
.text
.globl main
main:
ldgp gp,0(pv)
ldi a0, 1
lda a1, hwstring
ldi a2, hwlen
ldi v0, SYS_write
call_pal 0x83
addq zero, zero, a0
ldi v0, SYS_exit
call_pal 0x83
1: br 1b
hwstring:
.ascii "Hello, world\n"
hwlen = . - hwstring</programlisting>
</sect3>
<sect3 id="assembler2">
<title>How do I write a <emphasis>really</emphasis> standalone
assembly program?</title>
<para>Using <emphasis>standalone</emphasis> to mean a program
that doesn't require the C runtime support mechanism, here is
one that can be just run through the linker without any
startup or library code at all:</para>
<programlisting>
/*
* Completely standalone assembly Hello, world demo. Has the magic
* NetBSD .note section which tells our ELF from generic ELF.
*
* hwsa.S
*
* cc -c hw.S
* ld hw.o
* ./a.out
*/
#include <machine/asm.h>
#include <sys/syscall.h>
.set noat
.set noreorder
.section ".note.netbsd.ident", "a"
.long 2f-1f
.long 4f-3f
.long 1
1: .asciz "NetBSD"
2: .p2align 2
3: .long 199905
4: .p2align 2
.text
.globl __start
__start:
ldgp gp,0(pv)
ldi a0, 1
lda a1, hwstring
ldi a2, hwlen
ldi v0, SYS_write
call_pal 0x83
addq zero, zero, a0
ldi v0, SYS_exit
call_pal 0x83
1: br 1b
hwstring:
.ascii "Hello, world\n"
hwlen = . - hwstring</programlisting>
</sect3>
</sect2>
<sect2 id="misc">
<title>Miscellaneous</title>
<sect3 id="netscape">
<title>Can &os;/alpha run Netscape?</title>
<para>There are three 'Netscape' browsers in the <ulink
src="../../Documentation/software/packages.html">&os; packages
collection</ulink>:</para>
<itemizedlist>
<listitem><filename role="pkg">www/communicator</filename> - complete Netscape c
ommunicator install including email. (requires Digital Unix libraries)</listitem>
<listitem><filename role="pkg">www/navigator</filename> - Standalone Navigator b
rowser (requires Digital Unix libraries)</listitem>
<listitem><filename role="pkg">www/mozilla</filename> - Free version of the Nets
cape browser.</listitem>
</itemizedlist>
<para>Both the communicator and navigator packages will run
faster and provide more features than mozilla, but they
require OSF1/Digital Unix/Tru64 libraries in
<filename>/emul/osf1</filename>.</para>
</sect3>
<sect3 id="x-support">
<title>What video cards are supported by X11?</title>
<para>At this time, the following graphics cards are supported:</para>
<table id="supported_cards">
<title>Supported graphics cards</title>
<tgroup cols="7">
<thead>
<row>
<entry>Bus</entry>
<entry>Driver</entry>
<entry>Card</entry>
<entry>Product Code</entry>
<entry>Memory</entry>
<entry>Max Resolution</entry>
<entry>Depentry</entry>
</row>
</thead>
<tbody>
<row>
<entry>PCI</entry>
<entry>tga</entry>
<entry>ZLXp-E1</entry>
<entry>PBXGA-AA</entry>
<entry>2</entry>
<entry>1280x1024</entry>
<entry>8</entry>
</row>
<row>
<entry>PCI</entry>
<entry>tga</entry>
<entry>ZLXp-E2</entry>
<entry>PBXGA-BA</entry>
<entry>8</entry>
<entry>1280x1024</entry>
<entry>32</entry>
</row>
<row>
<entry>PCI</entry>
<entry>tga</entry>
<entry>ZLXp-E3</entry>
<entry>PBXGA-CA</entry>
<entry>16</entry>
<entry>1280x1024</entry>
<entry>32</entry>
</row>
<row>
<entry>PCI</entry>
<entry>tga</entry>
<entry>PowerStorm 3d30</entry>
<entry>PBXGB-AA</entry>
<entry>2</entry>
<entry>1280x1024</entry>
<entry>8</entry>
</row>
<row>
<entry>PCI</entry>
<entry>tga</entry>
<entry>PowerStorm 4d20</entry>
<entry>PBXGB-BA</entry>
<entry>16</entry>
<entry>1600x1200</entry>
<entry>32</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
Note that this applies only to the server; the X client programs
run just fine.</para>
</sect3>
<sect3 id="check">
<title>I just got a kernel trap, but my machine is still running!!</title>
<programlisting>
> fatal user trap:
>
> trap entry = 0x2 (memory management fault)
> a0 = 0xffffffffc8000004
> a1 = 0x1
> a2 = 0x1
> pc = 0x1200205b0
> ra = 0x12001a8d4
> curproc = 0xfffffe0000229c00
> pid = 22188, comm = make
</programlisting>
<para>
This means you (or someone) compiled a <code>DEBUG</code> kernel, and
some user or system program hit a bug and got a core
dump. &os;/alpha prints these on the console to help developers
debug program errors. A large number of programs that work on the
PeeCee have internal LP64 bugs that become apparent only when they are
compiled for a 64-bit architecture. (Well, sometimes: <quote>when
compiled for <emphasis>any</emphasis> other architecture</quote>, but
that's a different story.)
</para>
<para>
Ignore these errors unless you feel like debugging the problem. If it happens
in a program distributed as a part of &os;, we may need to
<ulink url="mailto:port-alpha-maintainer@NetBSD.org">hear about it.</ulink>
</para>
<para>
If your machine halts or panics on a machine check ... thats a different story. </para>
</sect3>
<sect3 id="machine-check-panic">
<title>Help! My machine just panic'd with a machine check!</title>
<para>
The PALcode has sent the machine check interrupt to the kernel, which
panic'd. There is a "logout frame" (machine check information) set up
by the PALcode which must be decoded to determine what happened. This
is both CPU (ev4, ev5, etc.) and core-logic (ALCOR, Pyxis, APECS, etc)
specific.
</para>
<para>
We only have code to decode this on a couple of the server systems in
&os; 1.4. DEC doesn't document what the codes mean, though we can
sometimes piece it together using various header files and source code
that have been made redistributable.
</para>
<para>
A '<code>660</code>' vector usually means <quote>memory ECC error</quote>.
</para>
<para>
A good percentage of the time a machine check could mean bad hardware.
The scope of this FAQ is too broad to tell you exactly what to do if
you see one of these. Your best bet would be to carefully copy it
down, or cut and paste it, and send it to <ulink
url="mailto:port-alpha@NetBSD.org">port-alpha@NetBSD.org</ulink>, and ask
the friendly people there what to do.</para>
</sect3>
<sect3 id="unaligned">
<title>Nasty message from the kernel saying something about unaligned accesses</title>
<para>
Nothing is wrong with the machine. This happens when programs
illegally cast types or make various other type-unsafe assumptions.
Unlike the x86 and vax, risc processors require data items to be
aligned. The compilers do this automatically, but some programs are so
badly written that they override the compiler's choices and force
the compiler to accept type-unsafe constructs.
</para>
<para>
The &os; kernel will fix these up on the fly,
though it may
slow your application down. To fix each unaligned access fault requires:
</para>
<orderedlist>
<listitem>Overhead of taking an unaligned access fault.</listitem>
<listitem>Overhead of fixup.</listitem>
<listitem>Additional overhead for (2) because access must be across a protection
boundary.</listitem>
</orderedlist>
<para>
Using &man.sysctl.8;, the action can be tuned to one of:
</para>
<orderedlist>
<listitem>Silently fixup the unaligned access.</listitem>
<listitem>Print out a message and fixup the unaligned access.</listitem>
<listitem>Silently send the process a SIGBUS.</listitem>
<listitem>Print out a message and send the process a SIGBUS.</listitem>
</orderedlist>
<para>
The default action is equivalent to:
</para>
<screen>
&rprompt; <userinput>sysctl -w machdep.unaligned_print=1</userinput>
&rprompt; <userinput>sysctl -w machdep.unaligned_fix=1</userinput>
&rprompt; <userinput>sysctl -w machdep.unaligned_sigbus=0</userinput>
</screen>
<para>
An unaligned access performed by the kernel will always cause a panic.
</para>
</sect3>
<sect3 id="diskless">
<title>Can &os;/alpha boot diskless?</title>
<variablelist>
<varlistentry><emphasis>In &os; 1.2 or earlier:</emphasis>
<listitem>Sort of. The kernel supports booting with NFS root and swap
partitions, found via bootparam requests. Unfortunately, there's
no network boot loader. In other words, you have to put a &os;
kernel on a Digital UNIX disk and boot the kernel from the disk (with
a command like <code>boot -fi "kernelname"</code>).</listitem></varlistentry>
</variablelist>
<variablelist>
<varlistentry><emphasis>After &os; 1.2:</emphasis>
<listitem>Yes. Starting after the &os; 1.2 release, &os;/alpha supports
diskless booting with bootp. You must have a recent version of the
SRM console firmware for this to work. For more complete documentation
see <ulink url="../../Documentation/network/netboot/index.html">Netbooting
&os;/alpha</ulink>.</listitem></varlistentry>
</variablelist>
<para>
If you try to set up a Digital UNIX 3.x (formerly DEC OSF/1) system as
an NFS server containing &os; diskless root partitions, you'll run
into a problem: Digital UNIX 3.x does not properly handle &os; device
nodes. Apparently, to ease the transition from 16-bit to 32-bit
device nodes, Digital added run-time conversion code to convert from
the old device node format to the new format. Unfortunately, this
causes the device nodes as seen by a diskless &os; to be garbage.
The only solutions to this are binary or source modifications to the
Digital UNIX kernel, so, for most users, the easiest solution is to
simply not use a Digital UNIX system as the server for &os; diskless
clients. Rumor has it that Digital Unix 4.x does not suffer from this
problem.
</para>
</sect3>
<sect3 id="installboot">
<title>How do I make a hard disk bootable?</title>
<para>
To make a hard disk bootable, you have to copy the &os;/alpha
second-stage bootstrap, <emphasis role="bold">/usr/mdec/boot</emphasis>, to
the root directory of the file system on the disk's <emphasis role="bold">a</emphasis>
partition and use the
<emphasis role="bold">&man.installboot.8;</emphasis> program to install the first-stage bootstrap.
On versions of &os; prior to 1.4, it is necessary to run
installboot(8) to insert the block numbers of /boot into the primary
bootstrap program and to insert the primary bootstrap program at the
beginning of the drive. This must be repeated if the secondary
bootstrap program (or the filesystem) is restored or updated.
</para>
<para>
In &os; 1.4 and later, there is a different primary bootstrap
program for each different root-capable filesystem; this program
automatically finds and loads /boot.
</para>
<para>
Using <emphasis role="bold">sd1</emphasis> as an example:
</para>
<variablelist>
<varlistentry><emphasis role="bold">&os; 1.3.</emphasis><emphasis>x</emphasis>
<listitem><programlisting>
# mount the file system
mount /dev/sd1a /mnt
# install the bootstrap programs
cd /usr/mdec
cp boot /mnt
sync
sync
./installboot /mnt/boot /usr/mdec/bootxx /dev/rsd1c
</programlisting></listitem></varlistentry>
<varlistentry><emphasis role="bold">&os; 1.4 and later</emphasis>
<listitem><programlisting>
# mount the file system
mount /dev/sd1a /mnt
# install the bootstrap programs
cd /usr/mdec
cp boot /mnt
./installboot /dev/rsd1c bootxx_ffs
</programlisting></listitem></varlistentry>
</variablelist>
<para>
This example (even adjusted to use the correct path names and
disk device names for your system) might not work in all situations.
You should read the &man.installboot.8; manual page for more
details about using installboot.
</para>
<para>
In addition to working for hard disks, this procedure also
works for SCSI removable-media devices (such as Zip and Jaz drives) that
contain BSD disklabels.
</para>
</sect3>
<sect3 id="bootablecd">
<title>How do I burn the cdhdtape install binary (to a CD) under MS Windows?</title>
<para>
From Colin <email>CaptnZilog@aol.com</email>:
</para>
<para>
For those of you wanting to create a &os;/Alpha bootable CD
from the <code>cdhdtape</code> image file and with access to only a Windows
based CD writer, here's one way to do it.
</para>
<para>
Get the free "Nero" demo (v4.0) from <ulink url="http://www.ahead.de">
AHEAD Software</ulink> and
simply go in <code>File/Burn Image</code>, choose the <code>cdhdtape</code>
file.
</para>
<para>
Click OK to set options when asked and use:
</para>
<programlisting>
Type of image: data mode 1
Block size: 2048
Image header (bytes): 0
Image trailer (bytes): 0
</programlisting>
<para>
and leave the "Raw Data", "Scrambled" and "Swapped" checkboxes unchecked.
</para>
<para>
That will do it.
</para>
<para>
I noticed that when booting from the CD I got a few "dka400.4.0.6.0 is
not ready" right after "NetBSD/Alpha 1.4 Primary Boot +"
but the boot process continued without problems.
(I'm running on DEC Alpha Server 400 4/166)
</para>
</sect3>
<sect3 id="alphastation">
<title>AlphaStation kernel panics</title>
<para>
If you experience kernel panics at boot after upgrading from
&os; 1.3.3 to a newer version (e.g. &os; 1.4), consider
upgrading your SRM firmware.
There were at least 2 reports that on AlphaStation 200 4/100 upgrading
the firmware to version 6.9 made the newer kernel boot correctly.
</para>
<para>
Alpha firmware updates are available from
<ulink url="http://ftp.digital.com/pub/DEC/Alpha/firmware/">
http://ftp.digital.com/pub/DEC/Alpha/firmware/</ulink>.
</para>
</sect3>
<sect3 id="compat_osf1_and_mach">
<title>Some Digital Unix programs fail with SIGSYS</title>
<para>
Assuming you &man.ktrace.1; the program and the end of the output
looks like this (where -10 could be any negative number):</para>
<programlisting>
<emphasis>pid</emphasis> <emphasis>prog</emphasis> CALL [-10]
<emphasis>pid</emphasis> <emphasis>prog</emphasis> PSIG SIGSYS SIG_DFL
<emphasis>pid</emphasis> <emphasis>prog</emphasis> NAMI <emphasis>prog</emphasis>.core
</programlisting>
<para>
Then it is trying to make a Mach system call. The file
<ulink url="http://cvsweb.NetBSD.org/bsdweb.cgi//sys/compat/osf1/README.mach-traps?rev=HEAD&content-type=text/x-cvsweb-markup">/sys/compat/osf1/README.mach-traps</ulink>
spells out the problem.
</para>
<para>
In general, apps which are linked to libpthreads.so or libpthread.so
tend to use mach system calls. Luckily, not many interesting apps are.
Acroread is the only productivity app found so far.
</para>
</sect3>
<sect3 id="coexist_tru64">
<title>Coexisting with Tru64 Unix (aka Digital Unix, aka OSF/1)</title>
<para>
It appears that Tru64 Unix uses filesystems which look like what
&os; calls <quote>old-style ffs</quote>. So, you should be able to mount a Tru64
filesystem under &os;; it will be recognized by &os;'s
compatibility code. Mounting a &os; filesystem under Tru64 Unix is
dangerous; a Tru64 fsck will destroy the fs. There is a possibility
that a fs created using &os;'s <command>newfs</command> <option>-O</option> would work interchangeably
between the two.
</para>
<para>
We have one report that a filesystem with too many files in it will
appear to be empty.
</para>
<para>
Whatever you try, we recommend that you try it first with data that's
not important to you, and we ask that you let us know if you learn
anything new, so that we can update this page.
</para>
</sect3>
<sect3 id="otherinfo">
<title>Other sources of information</title>
<itemizedlist>
<listitem>
<para><ulink url="multiafaq.html">The &os;/alpha Multia
FAQ</ulink></para>
</listitem>
<listitem>
<para><ulink url="../../Documentation/elf.html">&os; ELF FAQ</ulink>
- including why there is no ldconfig or /etc/ld.so.conf</para>
</listitem>
<listitem>
<para><ulink url="../../Documentation/wscons/">Wscons
FAQ</ulink>, for the platform-independent workstation console
driver which &os;/alpha uses</para>
</listitem>
<listitem>
<para><ulink url="../../Documentation/network/netboot/">Diskless
&os; HOW-TO</ulink></para>
</listitem>
<listitem>
<para><ulink url="../../Documentation/Hardware/Misc/serial.html">&os; Serial
Port Primer</ulink></para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
</sect1>
<parentsec url="./" text="&os;/alpha ports page"/>
</webpage>
--9jxsPFA5p3P2qPhR--