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 filename 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 sun 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 the 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 to do this. For example, to get 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: options FONT_BOLD8x16 Another useful option is options RASTERCONS_FULLSCREEN 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: Use another mouse Add options SUN_MS_BPS=4800 to your kernel configuration and recompile See &man.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. Some options: Set your terminal type to sun-cgsix. Edit your termcap so that the default 'sun' entry has :tc=sun-cgsix: instead of :tc=sun-il: Edit /etc/ttys and change console "/usr/libexec/getty suncons" sun on secure to console "/usr/libexec/getty suncons" sun-cgsix on secure NetBSD supports CardBus and PCMCIA cards with the SPARCstation Voyager's on-board interface and with the nell sbus-to-PCMCIA bridge card. All PCMCIA devices listed on the Machine-independent PCMCIA drivers page should work with NetBSD/sparc. Some have been tested, but many have not. 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. Note: multiprocessor support is currently broken in 5.0 and -current. NetBSD 4.0 is the latest release to feature working multiprocessor support for the sparc port. 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: Sun CPU and Memory Tables The Rough Guide to MBus Modules 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 Where 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, follow these 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. If the page map ram on a sparc2 fails, the PROM will not initialise the framebuffer, 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 replace 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: If using a Sun keyboard, Press [L1]+[A], (or [STOP]+[A]) If using a Tadpole SPARCbook keyboard, press [Pause]+[A] If using a serial console, send a BREAK signal (the method may very from terminal to terminal). Once at the PROM you can continue with 'go' ('ok' prompt), or 'c' (> prompt). See the troubleshooting guide at docs.sun.com. 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. Here is a shellscript provided by greywolf@starwolf.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 [L1]+[N], (or [STOP]+[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. 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. The PowerLite 85 (and 100) 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. 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. Cable Diagram (ascii 4k) Cable Diagram (jpeg 76k) Cable Diagram (postscript 18k) 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 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. You may also find this IDPROM/NVRAM Battery Replacement Page useful. 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. The interface may be autosensing to 10BaseT, even though there's no physical 10Base-T port. Check the media type in the output of "ifconfig le0". 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 its features: one SBus and one AFX slot side by side so you can only use one Crystal Semiconductor 4231 audio (audiocs) stp4020 (PCMCIA) (nell) the usual onboard serial a/b, SCSI, 10BaseT 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 &man.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 &man.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: http://sunsolve.sun.com/pub-cgi/pdownload.pl?target=102545-13&method=f - This archive contains 102545-13/lib/libc.so19 and 102545-13/5lib/libc.so29, which should be renamed to /emul/sunos/usr/lib/libc.so.1.9 and /emul/sunos/usr/5lib/libc.so.2.9 respectively. http://sunsolve.sun.com/pub-cgi/pdownload.pl?target=100257-06&method=f - This archive contains 100257-06/4.1.3c/sun4/ld.so, which should be renamed to /emul/sunos/usr/lib/ld.so Lastly, you'll need to get libdl.so.1.0 from any SunOS machine, and place this file in /emul/sunos/usr/lib. Please note that the libdl.so.1.0 from Solaris will not work for SunOS emulation. For more information see &man.compat.sunos.8;. Sun System Handbook - Sun's online system docs Memory Modules - memory module compatibility (requires a SunSolve login with a valid Sun Service Plan; alternative, free but unofficial link) SunHELP - much sun related information Sun Hardware Reference FAQ - overview of Sun hardware over the years OpenBoot Collection reference on PROM commands and variables Sun NVRAM/Hostid FAQ - if your machine PROM's battery has gone dead Sun Serial Port & Cable Pinouts - lists serial port pinouts for almost all models Frame Buffer FAQ by David Tong The SunShack Data Archive collected by Craig Dewick (includes BootROM upgrades and the Sun Field Engineer Handbook) NetBSD &release.latest; install notes - supported hardware and how to install. port-sparc mailing list - if you have any additional questions please subscribe. General NetBSD Documentation - for questions not specific to NetBSD/sparc.