On 07/10/2007, Michael Lorenz <macallan@netbsd.org> wrote:
> Hmm, that's file system code. Does it always come form there?

Well, I now have a second stack trace.  Note that in the meantime, I
did the following:  I updated from cvs, and recompiled (while under
4.0rc1).  The resulting kernel booted and ran as well as the previous
one, but when it crashed I didn't get a debugging console - in fact,
no indication of any sort other than unresponsiveness.  I rebooted
with the 3.1 kernel, rebuilt tools and kernel, and this one is back to
"normal".  (The compile under 4.0rc1 crashed once or twice, I think,
with "internal compiler error" or something - again I would think this
points to data corruption from the drive)

Anyways, the crash with the 4.0rc2 kernel:
panic: pool_get: ncachepl: page empty
0xd565fb40: at panic+0x14
... at cache_enter+0x2b4
at ufs_lookup+0x768
at VOP_LOOKUP+0x34
at lookup+0x320
at namei+0x138
at compat_30_sys___lstat13+0x54
ay syscall_plain+0x1fc
at user SC trap #280 by 0xeff99940 srr1=0xf032 r1=0xfffdad0
cr=0x20028048 xer=0 ctr=0

> Since you're running everything in PIO4/DMA2 anyway - could you
> please check if anything changes when the disks are hooked up to wdc
> at obio? If that works without errors we know it's the cmdide, if
> they persist I'd suspect the hardware.

I can try that, do I do that by disabling the
wdc*    at mediabay? flags 0
line?

> > Yes, I'll definitively try swapping cables.  However, 3.1 did seem
> > more stable, so I'll wait for the next crash (shouldn't take too long
> > ;-) and see if the backtrace is similar.
>
> Well, if 3.1 didn't crash at all that would be an indication.

Well, it did occasionally, just not quite as reliably :-)

Joe.