I think you may have more luck if you power-cycle the box. When I've seen this under NetBSD/alpha, I suspected it was caused by the IDE controller acting as a noise generator, and was able to cure it by disabling the ide controller.

> your mileage may vary.

This happens if you attempt to put an 'unverified' card onto pci bus 0 (and thus expose it to the pyxis DMA bug present in non-GL miatas). See my Miata brain-dump below for an explanation, bearing in mind that a DPW {433,500,600}{a,au} == "Miata" or "MiataGL"

A MiataGL can be distingiushed from a Miata by the presense of a Cypress SIO (aka "PCI Peripheral Controller") chip in place of the Intel SIO chip at Bus 00 Slot 07 (from SRM '>>>show config'). A non-GL Miata has some nasty PCI bugs, including problems doing DMA reads across page boundaries. All Miatas are equipped with a 21x52 pci-pci bridge which breaks up DMA's at page boundaries. The 3 32-bit PCI slots sit behind the ppb. The 2 64-bit slots sit directly on the primary PCI bus. To avoid problems with cards which are not safe for Digital UNIX (eg, they're not certain they don't do DMA reads across page boundaries), DEC put a hack into the SRM console which prevents you from placing unverified cards directly on the primary PCI bus.

If you know a card & its driver are "safe", or if you're on a MiataGL, you can get around this by setting the undocumented SRM console variable 'pci_device_override' to the PCI device id followed by the pci vendor id. Eg, for a card with the VendorID 0x10e8 & Device ID 0x8043, one may use: >>> set pci_device_override 804310e8

In later versions of the firmware, I hear that you can just set it to -1.

On a Miata-GL that I just uncrated this afternoon (with version V6.8-44 of the firmware), pci_device_override no longer needs to be set.