NetBSD/sun3 Frequently Asked Questions

General Questions

• No multicast or IPv6 - "le0: not multicast capable"
• Running diskless 3/80 with ESP driver - "esp: SCSI bus reset."
• SunOS 4.1 Compatibility
• Booting SCSI devices at different targets
• History of NetBSD/sun3x

Other sources of information

• SunHELP - much sun related information
• Sun Hardware Reference FAQ - overview of Sun hardware over the years
• Sun NVRAM/Hostid FAQ - if your machine PROM's battery has gone dead
• Sun CD-ROM FAQ - lists which CD-ROM drives can boot a Sun

• NetBSD 1.5.2 install notes - supported hardware and how to install.
• port-sun3 mail list - if you have any additional questions please subscribe.
• Diskless NetBSD HOW-TO.
• The Sun3 Archive has lots of information about Sun3 hardware, PROM images, etc.
• Techrat's Sun 3/160 pages contains information on Techrat's 3/160, hardware information, lots of pictures of old Sun hardware, and links to various FAQs and things.

• General NetBSD Documentation - for questions not specific to NetBSD/sun3.

General Questions

No multicast or IPv6 - "le0: not multicast capable" (top)

The LANCE revision C chips used in some sun3s (not the sun3x) have a bug which sometimes results in garbage inserted where the first bits should be, with the correct bits shifted later. So instead of the destination MAC address at the beginning, you get something random looking.

The work-around is to examine the beginning of the packet and throw away anything that's not for us (my MAC or broadcast). Unfortunately this prevents the use of multicast.

The LANCE Rev. C chip was probably only used in the 3/50, so on other sun3 machines you should be able to build a kernel without the line:

options LANCE_REVC_BUG

Running diskless 3/80 with ESP driver - "esp: SCSI bus reset." (top)

This message is a symptom of a bug in the esp driver on diskless systems. The ESP (Emulex SCSI Processor) driver in NetBSD/sun3x has a bug that causes it to enter an endless loop when it probes an empty SCSI bus. To work around this problem, use a kernel which does not have the esp device driver, or plug in at least one powered SCSI device into the bus. (Sorry, we don't have a pre-compiled esp-less kernel for you yet!)

SunOS 4.1 Compatibility (top)

NetBSD/Sun3 features extensive binary compatibility with SunOS 4.1.x programs. Static SunOS executables will run without any extra setup.

To run dynamic executables, you'll need to provide the dynamic libraries that came with your SunOS installation. SunOS programs that will not work include those that use the SunOS kvm library, certain (low-level) disk manipulation utilities, and programs making explicit use of Sun's STREAMS subsystem. Check the compat_sunos(8) manual page for more details.

Booting SCSI devices at different targets (top)

All sun3 and sun3x monitors support booting from SCSI devices. Most users will be familiar with booting from the monitor device sd(0,0,0), which they know means booting the SCSI disk at target zero. However, determining the monitor device name for booting an arbitrary SCSI device can be confusing.

A monitor boot device takes the form dev(cntrl,unit,part). dev is two letters, and cntrl, unit, and part are hexadecimal numbers.

For SCSI disks and CD-ROMs, dev is sd. For SCSI tapes, dev is st.

For all SCSI devices, cntrl is the number of the SCSI controller the device is attached to. For a machine with a single SCSI controller, cntrl is 0.

For all SCSI devices, unit identifies the SCSI target and logical unit number of the device. Exactly how the SCSI target and logical unit number are combined into the single number unit depends on your machine type and ROM revision, and whether or not the device is a disk, CD-ROM, or tape. Use the tables below to figure out how unit works on your machine.

For SCSI disks and CD-ROMs, part selects the partition to boot on that disk or CD-ROM. The first partition is 0, the second partition is 1, etc. Normally, part is 0, since the first partition on a disk is usually the bootable one. Common exceptions are booting a miniroot that has been written to the swap partition, in which case part is 1, or booting a CD-ROM that contains different bootable partitions for different architectures, in which case you have to know which partition boots your architecture.

For SCSI tapes, part selects the tape segment (also called "tape file") to boot. The first tape segment is 0, the second tape segment is 1, etc. You will need to know which tape segment is bootable for your architecture in order to give the right part.

Finally, these are the tables that demonstrate how unit works on various machines. They list sd monitor devices for disks and CD-ROMs, and st monitor devices for tapes, all at different SCSI targets. These tables assume that you want the first SCSI controller 0, and the first partition or first tape segment 0. Also, because many Sun 3 models use the same CPU board, to keep these tables simple Sun's CPU board code names are used wherever possible.

Model	CPU	Model	CPU
3/75	Carrera	3/140	Carrera
3/150	Carrera	3/160	Carrera
3/180	Carrera

CPU/rev ROM	Monitor device to boot the disk or CD-ROM at target
	0	1	2	3	4	5	6	7
3/60 rev 1.9 Carrera rev 2.7	sd(0,0,0)	sd(0,4,0)	sd(0,8,0)	sd(0,C,0)	sd(0,10,0)	sd(0,14,0)	sd(0,18,0)	N/A
3/80 rev 2.9.2	sd(0,0,0)	sd(0,8,0)	sd(0,10,0)	sd(0,18,0)	sd(0,20,0)	sd(0,28,0)	sd(0,30,0)	N/A

CPU/rev ROM	Monitor device to boot the tape at target
	0	1	2	3	4	5	6	7
3/60 rev 1.9	???	st(0,8,0)	st(0,10,0)	st(0,18,0)	st(0,0,0)	st(0,28,0)	st(0,30,0)	N/A
3/80 rev 2.9.2	???	st(0,8,0)	st(0,10,0)	st(0,18,0)	st(0,0,0)	st(0,28,0)	st(0,30,0)	N/A

The above tables also assume that you want SCSI logical unit number zero. The SCSI specification allows one SCSI target to contain different logical units (also called LUNs). Virtually no SCSI devices make use of this feature, and have only a single LUN, zero. However, if you know you have a disk at a LUN other than zero (early Sun SCSI disk setups do), you can add the LUN number to the unit value, noting that unit is a hexadecimal number.

History of NetBSD/sun3x (top)

The sun3x port of NetBSD was initiated by two independent groups of developers. The first group, headed by Gordon Ross and Jeremy Cooper, began work in March of 1996 with the (then) current sun3 port and the intent to create a new pmap system that was not based on the hp300 m68k code. Their work is the officially supported version of NetBSD/sun3x.

The second group, headed by Tsubai Masanari, also began with the sun3 distribution but instead choose to use the traditional hp300 m68k pmap. This approach allowed them to get a fully running system in a matter of weeks. They were the first to successfully integrate the SPARC Enhanced SCSI Processor driver into the kernel, proving that the Sun3x was indeed half SPARC, half Sun3.

Although the currently supported NetBSD/sun3x is based on Gordon and Jeremy's work, they are indebted to the second group for their innovation.

Between NetBSD 1.3 and 1.4 NetBSD/sun3x was merged into NetBSD/sun3. They build separate kernels, but share the same userland, and kernel build tree.

Home page

Documentation top level