No supported rate found!error from mpg123 (top)
If you've gotten this error you'll have to pass arguments to mpg123 for your number of channels and rate of stream. Older systems (such as the sun4c machines and the SPARC Classic) only support an 8 bit 8 kHz mono sampling rate. For these systems, you would specify:
mpg123 -m -r 8000
The -m option is for mixing both channels for mono output, and the -r specifies the rate that the audio card supports.
Typically this is because the default terminal type for console is
and most serial terminals are
vt100 (or similar), and they
use different escape codes. The temporary fix is to change your terminal type:
# setenv TERM vt100
The permanent solution is to edit
/etc/ttys and change
console line to read:
console "/usr/libexec/getty suncons" vt100 on secure
Then you need to
kill -HUP 1 or reboot.
You have to recompile a kernel for this. For example, for a white on black console, add the following to your kernel config file:
options RASTERCONSOLE_FGCOL=WSCOL_WHITE options RASTERCONSOLE_BGCOL=WSCOL_BLACK
For a smaller font, add the following:
Another useful option is
ms0: input error (0xc47)) (top)
Apparently the original mouse that came with the Voyager (the Compact1 370-1865-01 mouse, but not the 370-1865-03) runs at a faster serial speed than every other Sun mouse (4800 bps instead of 1200 bps). You have two options:
options SUN_MS_BPS=4800to your kernel configuration and recompile
See ms(4) for more information.
When exiting vi, and sometimes when scrolling back, the display scrolls back for a few seconds displaying a lot of garbage. There is usually garbage in the non-text portion of the screen as well. This is purported to be caused by a firmware bug on Sbus cgsix boards, and has to date been noticed on all machines in which a cgsix board is installed.
sun' entry has
console "/usr/libexec/getty suncons" sun on secure
>console "/usr/libexec/getty suncons" sun-cgsix on secure
The memory management hardware on sun4c machines (SPARCstation
1, 1+, 2, IPC, IPX, SLC, ELC and clones) is not handled
particularly well by Linux. Until Linux reworks their MMU code
NetBSD will be significantly faster on this hardware. There was a
longstanding bug prior to NetBSD 1.6.2 on SPARCstation/server 1,
SPARCstation/server 1+, and Sun IPC models. We recommend updating these
models to the latest version of NetBSD to for improved stability and
sw flush: cache enabled.
ld: /usr/lib/c++rt0.o: illegal reloc type mixwhen compiling (top)
For versions older than 1.4.3, the default NetBSD/sparc /usr/lib/c++rt0.o is compiled -fpic. This means it can only handle offsets up to a certain size, and can fail to work in large programs. Compiling -fPIC allows larger offsets and should permit large programs to function.
If you're using a NetBSD release before 1.4.3, replacing /usr/lib/c++rt0.o with a -fPIC version, located at ftp://ftp.NetBSD.org/pub/NetBSD/arch/sparc/c++rt0/, will solve this problem.
To create install floppies for NetBSD/sparc, you first need to have the
release source. You also need to have the release files installed; you'll
find them under the
NetBSD-release section. Note that the release source extracts to
src directory, so be sure to extract the archive under
Next, create the INSTALL kernel:
# cd /sys/arch/sparc/INSTALL; make
After the kernel has build, you can create the installation floppies:
# cd /usr/src/distrib/sparc/sysinst.ramdisk; make # cd /usr/src/distrib/sparc/sysinst.bootfs; make
See the NetBSD Bootable CD ROM HOWTO.
NetBSD 1.6 and later support cardbus and PCMCIA cards with the SPARCstation Voyager's on-board interface and with the nell sbus-to-PCMCIA bridge card. Support was dramatically improved in NetBSD 2.0, fixing many longstanding bugs. All PCMCIA devices listed on the Machine-independent PCMCIA drivers page should work in NetBSD 2.0. Some have been tested. The GENERIC kernel has the nell interface disabled by default. You'll need to build a kernel with the nell and various pcmcia interfaces uncommented.
In NetBSD 1.6.x, there is a byte endian issue which currently prevents 16 bit devices from working. See the post by Martin Husemann on nell support. This problem is fixed in NetBSD 2.0 and later.
In NetBSD 1.6.x, There is a conflict between the audioamd device in sun4c and some sun4m models and the (nell) device. This problem is fixed in NetBSD 2.0 and later.
If your 1.6.x system has the audioamd device on-board and you want to use it and the nell interface, you need to build a new kernel with the following option:
This problem is fixed in NetBSD 2.0 and later.
If you wish to use the Lucent WaveLAN card on 1.6.x, you will need to add the following hack to your kernel configuration:
options WI_AT_BIGENDIAN_BUS_HACK wi* at pcmcia? function ? # Lucent WaveLan IEEE (802.11)
Note: This capability was added in NetBSD 2.0. NetBSD 1.6.x and earlier will only use one CPU if more than one is present.
The only NetBSD/sparc models capable of SMP are the Sun 4/600, SPARCstation/server 10, SPARCstation/server 20, and clones of these models. Most SuperSPARC-I, SuperSPARC-II, and hyperSPARC MBus CPU modules can be used in an SMP system. Briefly, two modules with the same speed and (non-zero) cache size will have no problems. Modules with different cache sizes and speeds have been reported to work, but you run into trouble when using older (i.e. slower) modules and modules without caches. Check the following references:
You will need to use the GENERIC.MP kernel, or a kernel with the following options enabled:
options MULTIPROCESSOR # include multiprocessor support cpu* at mainbus0 # declare additional CPUs
To boot from a different CPU, run the following commands at the PROM prompt:
<#0> ok N switch-cpu
N is the cpu number you want to switch to. 0 is
the primary CPU on the first mbus module. 1 is the second CPU on the
first module. 2 is the first CPU on the second module. 3 is the second
CPU on the second module. Switching to a non-existent CPU may cause
your system to hang.
You must have already booted NetBSD once to load the CPU code into the
PROM. See Paul Kranenburg's post.
Well, there are two ways, build your own cable, or purchase an adapter. The adapters can be found for around US$30 and the framebuffer will typically "just work" at its default resolution.
To build your own cable, can follow the instructions provided by Izumi Tsutsui.
Don't forget to take a look at the Frame Buffer FAQ for information on your framebuffer, what resolutions it supports, and how to set the default resolution in the prom.
"*** U0209 ***" "
PMAP 000d5000, Exp = 00000000, Obs = 04000000" from the PROM mean (top)
If the page map ram on a sparc2 fails the PROM will not initialise the frambuffer, but will output a message similar to
*** U0209 *** PMAP = 000d5000, Exp = 00000000, Obs = 04000000
to the serial console. (the U0209 can also be U0208). The only options are to replace the chip, which requires exceptionally delicate soldering work, or the entire motherboard.
Yes. All Ross hyperSPARC modules should work. See also What CPU modules are capable of running multiprocessor.
Ben Cottrell reports that: “For anyone else who's curious about this, the slots in a Ross sparc 20 clone go like: 0 4 1 5 2 6 3 7, going top to bottom, looking down on the case in its conventional orientation. ”
Older sun4 machines might have an old style SCSI connector with three rows of pins. The pins are listed on this page.
There are three ways to abort to the prom:
Once at the prom you can continue with '
go' ('ok' prompt), or
c' (> prompt).
See the troubleshooing guide at
Additionally, if your ethernet address is
FF:FF:FF:FF:FF:FF, then your
NVRAM is dead and you may have trouble booting. See
Ethernet address or hostid are all ones.
Most UNIX workstations, including Sun's OpenBoot PROM, have a PROM that requires the CD-ROM to support a 512 byte block size. Most OEM Sun CD-ROM drives are set to 512 byte block size by default. Most newer 3rd party drives automatically support both 512 and 2048 byte block sizes. Older 3rd party drives may have a jumper to change the value from 2048 bytes to 512 bytes. Check with your hardware vendor -- those drives that do not support 512 byte sectors will be unusable for booting, but will be useable once the kernel is loaded for normal operations.
See the Sun CD-ROM FAQ.
sw flush: cache enabled(top)
Prior to NetBSD 1.6.2, there was a longstanding MMU bug in the sun4c architecture. NetBSD 1.6 and 1.6.1 attempted to work around this bug by using a slower caching mechanism on the SPARCstation/server 1, SPARCstation/server 1+, and Sun IPC. All known problems are fixed in 1.6.2 and later. Read Paul Kranenburg's post for more information.
open netbsd: no such file or directory(top)
D'oh. The NetBSD 1.6 installer does not install a kernel if you select the default install. This is, of course, corrected in NetBSD 1.6.1 and later.
The easy fix is to run the installer again and select
sets or install additional sets and chose the
kern-GENERIC.tgz package to install.
Here is a shellscript provided by email@example.com which speeds up PROM access to the framebuffer on sun4c hosts running OBP version 2 and greater (such as the IPX).
#! /bin/sh - eeprom 'nvramrc=probe-all install-console ramforth : cache-page dup pgmap@ cacheable swap pgmap! ; up@ cache-page here origin do i cache-page pagesize +loop banner' eeprom 'use-nvramrc?=true' exit 0
Yes and no. The prom only knows how to load a bootloader from the beginning of a cylinder. This means that your bootable partitions need to start on cylinder boundaries. The cylinder size in your disklabel does not have to bear any relation to the actual physical cylinder size of the disk. You can't just set your cylinder size to 1 (i.e. the number of cylinders = the number of sectors), since the number of cylinders is stored as a 16 bit number (i.e. your disk could only be about 32 MB).
The partitions apparently do not need to end on cylinder boundaries, and there are no bad side-effects of doing so.
You need physical access to the machine to erase the password. Power off,
power on, hold
[N]) until the PROM prompt. This will
reset your PROM to the factory defaults.
Alternatively (this is not for the faint of heart), power on, abort, wait for the password prompt, carefully remove the PROM chip, hit return, carefully replace the PROM, enter a new password.
cache chip bug; trap page uncachedkernel message mean? (top)
If you get this kernel message, nothing has gone wrong. Machines with
"buserr-type" 1 have a bug in the cache chip that affects traps. The
cache chip bug; trap page uncached message is the kernel
activating a workaround for this bug.
Without this workaround, the cache simply delivers wrong data. Often this turns into an illegal instruction, so that you get a trap during a trap, which causes a reset. This condition can only be caught by the ROM, and by then it is too late to do anything about it. This message, if you happen to get it, just means you'll avoid that problem.
Unfortunately, the NetBSD 1.4.2 floppies, have a problem with the bootloader on some machines (in particular, sun4c machines with non-contiguous memory banks, such as the IPX). If you encounter this error, then you will need to download the repaired floppy images or install a 16 MB SIMM in the first bank of your machine (4 MB isn't large enough to hold the broken bootloader and the kernel).
This problem is only present on 1.4.2 boot floppies. It has been fixed in -current and will not be present in future releases of NetBSD/sparc.
The PowerLite 85 seems to have an OpenBoot PROM bug in the floppy driver. Cliff Wright has determined the nvramrc patch to fix this:
: trk0_delay 50 ms 4 ; ['] trk0_delay false ['] 4 false ffd34e90 (patch) 4 true ['] 2 false ffd34f28 (patch)
See his post for more information.
When booting a 1.4 or 1.4.1 kernel from a serial console, the following messages may appear:
Warning: unparseable stdin-path property Warning: unparseable stdout-path property cninit: invalid inSource 0xffffffff
This is a know problem when booting with a serial console on a
with a PROM revision prior to 2.4. The full details can be found under
PR/7409. The problem has been solved in NetBSD 1.4.2. If you need a
patched 1.4.1 GENERIC kernel, try
this one. A patch which alters
src/arch/sparc/dev/zs.c to force
/dev/ttya as the only serial console can be found as
Note that this patch does not prevent a standard keyboard and monitor from
being the console; it forces
/dev/ttya to be the console should a
serial console be selected.
A continuous stream of zeros is equivalent to a "BREAK" command which will enter the prom. This might happen, since the serial lines are floating when you unplug your cable. If you build a special switchbox that uses a pullup resistor, then you can avoid this problem.
Put a 4.7 KOhm resistor between pins 3 and 25.
Yes and no. Yes, you can use it, but it doesn't support the same hardware handshaking lines so you won't get hardware handshaking.
See the NetBSD Serial Port Primer for more information.
Some sparc machines, such as the SPARCstation 20 and SPARC Classic, have 2 serial ports but use a single DB-25 connector. Serial port A is wired using the standard pin out so that it may be used with a "normal" (whatever that means with serial ports) serial cable. To use serial port B, an adapter cable is required. Dan McMahill has traced the pin out on a Sun P/N 530-1677-01 cable.
The short answer: No.
The long answer is that you can possibly run it at non-standard speeds (such as 76800 bps and 51200 bps). der Mouse has patched things in the attempt to run the serial chip in an even faster mode, but it is very unreliable (i.e. very error-prone).
Note that some of the sparc64 machines can run their serial ports faster, but they use a different serial chipset.
Yes, that's correct. In general, each machine only has one ethernet hardware address (a.k.a. MAC) for all ethernet interfaces attached to it, since the MAC address is stored in the NVRAM on the motherboard instead of on the ethernet interface.
This means that if you have a sparc box with more than one ethernet interface, no two interfaces can be on the same subnet. In most practical situations, this should not be a problem. For example:
smaug% ifconfig -a le0: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 address: 08:00:20:20:e2:54 media: Ethernet autoselect be0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500 address: 08:00:20:20:e2:54 media: Ethernet autoselect (10baseT half-duplex)
If a machine boots up with with an all-ones ethernet address (i.e. ff:ff:ff:ff:ff:ff) or hostid, it is most likely because the NVRAM has reached the end of its life cycle. This is especially common on sun4c class machines because the NVRAM used in those systems have relatively short life spans many of which are currently ending now.
See the Sun NVRAM/Hostid FAQ for information on how to replace and reinitialize the chip and possible workarounds if you cannot find a new NVRAM chip.
If you don't know your system's original hostid and ethernet address, it may be possible to reconstruct them using the information on the nvram chip's barcode. See this post and this post for more information.
plugged in at boot The interface may be autosensing to 10BaseT, even though there's no physical 10Base-T port.
Check the media type in the output of "
it should read
10Base5 to use the external transceiver, if
not issue a "
ifconfig le0 media 10base5" command.
Read the JavaStation Status page to determine what JavaStation you have, and which hardware is supported.
The Linux on the Sun JavaStation NC HOWTO contains gobs of good info. Section 2 covers the various models and what sorts of guts they've got. Section 3 describes the netboot environment (also see the NetBSD Diskless HOW-TO on how to set up netbooting for these puppies). And Section 10 lists the jumper settings for JavaStations.
The Fox is probably best described as a brick sized SS4. Among it's features:
This was used in the early versions of the Java car, which later moved to a faster machine.
Kinda. If Solaris 5 or later created a filesystem with access control lists (ACL), NetBSD's fsck(8) will render the superblock unusable to Solaris (i.e. Solaris can't mount the filesystem again).
You should either mount your Solaris filesystem read-only or have created it without ACLs. See this post by Christos Zoulas on this topic.
Note: Remember, despite Sun's marketing and the misleading output of uname on Solaris, SunOS and Solaris are not the same OS! SunOS 4.x (Solaris 1.x) is BSD, Solaris 2.x is SysV. SunOS uname says `SunOS 4.x', Solaris uname says `SunOS 5.x'.
To setup Solaris emulation, you'll need to compile a kernel with COMPAT_SVR4, and copy the appropriate files from a Solaris system. For more information, please consult compat_svr4(8).
To setup SunOS emulation, you'll need to compile a kernel with COMPAT_SUNOS, and some of SunOS's libraries. They can be found at Sun's support site. You'll need the following libraries:
ftp://sunsolve.sun.com/pub/patches/102545-13.tar.Z- This archive contains
102545-13/5lib/libc.so29, which should be renamed to
ftp://sunsolve.sun.com/pub/patches/100257-06.tar.Z- This archive contains
100257-06/4.1.3c/sun4/ld.so, which should be renamed to
libdl.so.1.0from any SunOS machine, and place this file in
/emul/sunos/usr/lib. Please note that the
libdl.so.1.0from Solaris will not work for SunOS emulation.
For more information see compat_sunos(8).
There are three 'Netscape' browsers in the NetBSD packages collection:
Both the communicator and navigator packages will run faster and provide more features than mozilla, but they require either Solaris libraries in /emul/svr4 (see compat_svr4(8)) or SunOS-4.1 libraries in /emul/sunos (see compat_sunos(8)). All of the SunOS-4.1 libraries except libdl.so are available from Sun's ftp site. If anyone is interested in putting together a libdl it would be greatly appreciated :) The Solaris-2.5.1 versions of communicator and navigator are the defaults as current netscape versions are available for Solaris. It appears that netscape-4.61 was the last SunOS-4.1 version available. If you wish to use the SunOS-4.1 version of netscape, set the NS_USE_SUNOS variable in /etc/mk.conf.
Solaris Netscape (at least, version 4.51 attempts to use a pipe rather than a Unix domain socket to connect to the X server. Put DISPLAY=unix:0.0 into netscape's environment before starting it and it will work ok. The easiest way to do this, as well as the other variables you need to set up for it, is to have a shell script that does this before executing netscape:
#!/bin/sh export XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB export MOZILLA_HOME=/usr/local/netscape.svr4 export XNLSPATH=$MOZILLA_HOME/nls exec $MOZILLA_HOME/netscape $*