Try scanning the archives at http://mail-index.netbsd.org for MCHK.
There are quite a few messages. I don't know if this would solve
the issue you are seeing, but the symptoms sound somewhat similar:

http://mail-index.netbsd.org/port-powerpc/2005/06/28/0000.html

I forget if this fix made it into only current or 3.0 as well; or
if it still hasn't been corrected.

On Jun 7, 2006, at 7:37 PM, Guy Erb wrote:

> Hi
>
> I am developing a driver for a CardBus network device to be used for
> diagnostic purposes. The driver and associated user-land application
> work correctly on a NetBSD 3.0 i386 installation but am having issue
> on powerpc (15" PowerBook G4 667MHz with DVI, 1 GB RAM)
>
> During attach(), the driver allocates a large 2MB buffer via
> bus_dmamem_alloc(). The user-land application will get a
> mmap() of this buffer and can then setup tx/rx packets and descriptor
> rings for testing.
>
> On macppc, the attach() routine is successful but there is generally a
> panic (but not always) soon after as booting continues.
>
> If the machine doesn't panic during boot (perhaps one in ten boots),
> then it will panic later at seeminlgy random points while the
> user-land application is busy banging away at this memory buffer.
>
> The allocation of this large buffer follows the pattern I see in other
> platform independant drivers, i.e.,
>
>    bus_dmamem_alloc()
>    bus_dmamem_map()
>    bus_dmamap_create()
>    bus_dmamap_load()
>
> I believe I have narrowed it down to the succcessful
> bus_dmamem_alloc() of the 2MB buffer as being sufficient to
> destabilize the system.
>
>        if ((error = bus_dmamem_alloc(sc->sc_dmat, sc->sc_dlen,  
> PAGE_SIZE,
>                             0, &sc->sc_dseg, 1, &sc->sc_dnseg, 0)) ! 
> = 0) {
>                printf("%s: unable to allocate control data, error =  
> %d",
>                       sc->sc_dev->dv_xname, error);
>                goto fail0;
>        }
>
> Whether the panic happens at boot or runtime, the back trace will
> generally look something like the following.
>
> panic: trap
> Stopped at netbsd:cpu_Debugger+0x10:  lwz      r0, r1, 0x14
> db> t
> 0x0065dcd0:     at  panic+0x19c
> 0x0065dd60:     at  trap+0xe8
> 0x0065dde0:     kernel MCHK trap by splraise+0xc: srr1=0x149030
>                r1=0x65dea0 cr=0x20009032 xer=0 ctr=0x3c02f4
> 0x0065dea0:     at ADBDevTable+0xffa1d4b4
> 0x0065deb0:     at callout_schedule+0x68
> 0x0065dee0:     at pffasttimeo+0x9c
> 0x0065df00:     at softclock+0x248
> 0x0065df40:     at hardclock+0x314
> 0x0065df70:     at decr_intr+0xfc
> 0x0065dfa0:     at trapstart+0xbd8
> 0xd6457e00:     at Idle+0x24
> 0xd6457e10:     at mi_switch+0x194
> 0xd6457e40:     at ltsleep+0x3fc
> 0xd6457e80:     at sys_nanosleep+0x148
> 0xd6457ed0:     at syscall_plain+0xe0
> 0xd6457f40:     user SC trap #240 by 0xefd7ddc: srr1=0xf032
>                r1=0xffffcfc0 cr=0x24000028 xer=0x20000000  
> ctr=0xefdbd5bc
>
>
> Thanks for your consideration.
>
>
> regards
> Guy
>
>
>
> !DSPAM:44876b0543071380014938!
>
>
>