NetBSD/macppc Old Frequently Asked Questions

If you have encounter a problem listed here as being fixed, have additional information, questions, or answers, send mail to port-macppc@NetBSD.org.

• USB keyboard problems
• panic: startup: cannot allocate VM for buffers
• wdc0:0:1: lost interrupt
• pciide0:0:0: lost interrupt
• Panic: mesh: FIFO != 0
• I'm getting device timeouts on bm0
• What's the deal with the "load-base" setting?
• PowerBook (FireWire), PowerBook G4 (Titanium), and BootROM 4.1.8
• Woah, my machine just powered off!
• Where's my disk? (a.k.a. sysinst says I can not find any hard disk for use by NetBSD)

See also the following related information:

• NetBSD/macppc Frequently Asked Questions
• NetBSD/macppc System Disk Tutorial
• NetBSD/macppc Model Support Page
• NetBSD/macppc nvedit HOW-TO, for info on how to edit the contents of the NVRAMRC
• NetBSD/macppc Partitioning HOW-TO
• NetBSD/macppc X11 FAQ
• NetBSD ELF FAQ
• wscons FAQ, for NetBSD's platform-independent workstation console driver

Additional information is also available:

• port-macppc mail list - if you have any additional questions please subscribe.
• Diskless NetBSD HOW-TO.
• NetBSD Serial Port Primer
• General NetBSD Documentation - for questions not specific to NetBSD/macppc.

USB keyboard problems (top)

There are two different types of USB keyboard problems. One set of problems appeared after NetBSD 1.4.3 was released, and applies only to some iMac (Bondi Blue) and some PowerMacintosh G3 (Blue and White) machines. This problem seems to have been fixed in NetBSD 1.6.

The other problem occurred on all models with USB keyboards, but was fixed prior to the release of NetBSD 1.5.

iMac (Bondi Blue) and PowerMacintosh G3 (Blue and White) problems:

See Bob Nestor's post to the mailing list describing the problem and a workaround for the PowerMacintosh G3 (Blue and White). This workaround doesn't work for the iMac (Bondi Blue), but Rob Gridley reports that unplugging the mouse allows his system to boot and use the keyboard. Also, see the problem report, port-macppc/12894

Briefly, what he recommends is:

1. Unplug the USB keyboard and plug in an ADB keyboard and mouse

2. Boot NetBSD with the ADB keyboard

3. Enter root, swap and filesystem responses on the ADB keyboard

4. When the system gets to the shell prompt (or login if you went multi-user), unplug the ADB and plug in the USB keyboard

The USB will be usable at this point and you can use the system. You'll notice that the ADB is dead even before you unplugged it. Also you MUST boot without the USB installed or this won't work.

Alternatively, NetBSD 1.4.3 works fine on these two models and does not have this USB keyboard problem.

Repeating keypress problems prior to NetBSD 1.5:

There is a problem in some kernels that causes the first keypress from a USB keyboard to be repeated over and over again. A symptom of this would be the install system continually asking "(I)nstall, (S)hell or (H)alt ?" To avoid this problem, press the shift key before anything else.

On some newer machines, NetBSD will hang after configuring the devices but before entering single-user mode. The recommended solution is to unplug all USB devices (especially hubs) and plug the mouse into the keyboard and the keyboard directly into the back of the mac.

panic: startup: cannot allocate VM for buffers (top)

This problem should have been fixed in NetBSD 1.5.

On some machines with large quantities of RAM the kernel will run out of kernel VM when it tries to allocate the buffer cache. You can avoid this by either of:

1. Removing some RAM
2. Adding "options BUFPAGES=800" to the kernel configuration

wdc0:0:1: lost interrupt (top)

This problem is present in NetBSD 1.5.2 on newer machines that support ATA4 drives. Unfortunately, there is presently no easy workaround. Post to port-macppc@NetBSD.org for assistance.

This has been reported on the iBook (Dual USB) and the iMac (Summer 2000) which has been updated to BootROM 4.1.9.

The problem is not present in NetBSD 1.5.3 and later.

pciide0:0:0: lost interrupt (top)

This problem is fixed in NetBSD 1.5.1 and later.

The NetBSD initialization code for the CMD 646 IDE controller doesn't correctly undo some of the settings that Open Firmware sets. What happens is that Open Firmware sets the IDE controller up in 0646U2 mode and changes some of the interrupt settings. The MI pciide driver doesn't know how to deal with this situation and you get a lot of "lost interrupt" messages.

What this means is that if you use Open Firmware to load the bootloader (i.e. ofwboot.xcf) or the kernel from your hard drive, NetBSD cannot use that drive.

A workaround is to place the kernel on another bootable bus and then use that to mount the drive with your NetBSD filesystem on the drive connected to the CMD 646 IDE bus. The key phrase here is "another bootable bus". On the G3 and G4 machines which have this problem, they have more than one IDE bus (in addition to add-on SCSI busses). The hard drive is typically on the bus which we have troubles with, but the CD-ROM and Zip drive are typically on a different IDE bus which works just fine.

What you may want to do is move your hard drive to the bus the CD-ROM is attached to (paying attention to the master/slave jumpers), and all your problems will go away, although your drive is using a slower IDE bus protocol.

Panic: mesh: FIFO != 0 (top)

This bug is not present in NetBSD 1.5 and later.

This is usually caused by bad SCSI cabling or devices. Check your internal and external termination. Check the length and quality of your cables. Disconnect all devices that are not critical.

More often than not, this is caused by having a Zip drive on your MESH SCSI bus, as these devices do not behave like good SCSI citizens.

One person suggested that the MESH driver is more reliable if you don't reboot from MacOS into NetBSD. (That is, if you're running MacOS, shut down rather than rebooting, and then power it back on and boot to NetBSD.)

M L Riechers posted a very thorough message on this topic.

Good luck.

I'm getting device timeouts on bm0 (top)

This problem has been fixed in NetBSD 1.5 and later.

Inserting a 10Mb Hub (forcing bm0 to 10Mb/s instead of 100Mb/s) seems to prevent this problem.

What's the deal with the "load-base" setting? (top)

The Open Firmware environment variable load-base is the address at which Open Firmware loads the bootloader from your boot-device. The behavior is different for the various versions of Open Firmware and boot-devices. The symptom of an incorrectly set load-base is CLAIM failed.

Open Firmware 3

Do not change the load-base. Open Firmware 3 machines have re-writable firmware, and users have found that changing the load-base has overwritten their flash BootROM, rendering their machines dead (requiring an expensive trip back to Apple). Do not change the load-base on an Open Firmware 3 machine. Apple has fixed Open Firmware 3 such that you needn't change load-base to boot.

Open Firmware 1.0.5, 1.1.22, 2.0.x, and 2.4

The default value of load-base on these systems is 4000, which isn't very good for our purposes. System Disk sets load-base to 600000, which suits us just fine for NetBSD 1.5.3 and later. mkLinux uses a different value, which may prevent you from booting NetBSD/macppc. If you're using NetBSD 1.5.3 or later, reading further may simply confuse you -- stop here and just use 600000.

The load-base is handled differently by ofwboot.xcf and ofwboot. ofwboot.xcf is the XCOFF bootloader used on MS-DOS floppies, ISO CD-Rs, and with netbooting. ofwboot is the "partition zero" bootloader on the install floppies, install CD-R images, and hard drives prepared with sysinst or installboot.

ofwboot has been set to use 600000. Therefore, you should use a load-base of 600000.

The NetBSD 1.5.3 and later versions of ofwboot.xcf have been set to use 640000. Due to a perculiarity of Apple's Open FIrmware, load-base must be an address different from the address ofwboot.xcf is set to use. Therefore, you should use a load-base of 600000. This value is also the correct one for booting MacOS X.

The ofwboot.xcf from NetBSD versions prior to 1.5.3 had been set to use 600000. Therefore, if you're trying to boot using this bootloader, you should use a load-base of 640000 or get a newer version of ofwboot.xcf

Once you are entirely positive that your machine has Open Firmware 1.0.5, 1.1.22, 2.0.x, or 2.4 (see Which version of Open Firmware does my machine have?), run the following commands to set your load-base properly

0 > setenv load-base 600000
0 > reset-all

You should double-check that this value has been set using the printenv command.

PowerBook (FireWire), PowerBook G4 (Titanium), and BootROM 4.1.8 (top)

The two models listed above will fail to boot NetBSD 1.5.x and earlier if they have have BootROM version 4.1.8 or later.

This problem is fixed in NetBSD 1.6 and later.

Woah, my machine just powered off! (top)

Well, that's probably because you're using a recent laptop (iBook, PowerBook (FireWire), and some later models) and NetBSD 1.5 or later.

The page up key sequence (FN-uparrow) will panic a NetBSD 1.5.1 or 1.5 kernel. This is fixed in NetBSD 1.5.2 and later.

The "brightness" keys (F1 and F2) will power off your machine and zap your clock. You will need to build a new kernel without the abtn option. Remove the following line from your kernel configuration:

#abtn*  at adb?

Where's my disk? (a.k.a. sysinst says I can not find any hard disk for use by NetBSD) (top)

Well, that's a good question!

The root cause is that NetBSD didn't find your hard drive (or, more insidiously, didn't find your drive controller). There a variety of reasons why this happens.

If you have a recent machine which support ATA4, and/or you've installed a recent FirmWare update (late 2001), and you're trying to use NetBSD 1.5.2, you may run into the wdc0:0:1: lost interrupt problem.

The NetBSD 1.5.1 install kernel image does not support the IDE controller in the PowerMacintosh G3 (Blue and White). The real kernel does support it.

Home page

Documentation top level