Reproducable FreeBSD/AMD Crash

[Erez Zadok]

I'm CCing freebsd-fs here.  To the freebsd-fs people: Tom reported a freebsd
kernel panic that's triggered by an intense activity via amd (using amq -u
to unmount an entry, and then "touching" it again to re-mount it, then
repeating this process).

In message <637A278D8D0DBC438EA5E75C6E1818B9028C4810 at magenta.hq.netapp.com>, "Vincent, Thomas" writes:

> -----Original Message-----
> From: Nomura, Kevin 
> Sent: Wednesday, April 06, 2005 12:54 PM
> To: Vincent, Thomas
> Subject: Re: FW: Reproducable FreeBSD/AMD Crash
> 
> Thomas,
> 
> The amd version we saw this with: both the stock version that comes with
> freebsd 5.3, and also 6.1rc1 which I built and invoked by hand.  It does
> seem that a user space program (like am-utils) should be be the root cause
> of a kernel panic.
> There was the chance that some algorithmic change in the very latest amd
> would avoid the problem, or more precisely mask it, but that did not happen
> either.
> 
> The kernel panicked.  The console did not give much info:
> 
> gimcrack# panic: unmount: dangling vnode cpuid = 0
> boot() called on cpu#0
> Uptime: 21h58m34s
> Cannot dump. No dump device defined.
> Automatic reboot in 15 seconds - press a key on the console to abort
> 
> If a core will be useful then I can presumably set the system up to capture
> one.
> 
> Thanks,
> Kevin

I think you need to report it to the freebsd people: for now, I can put a
report in the BUGS file of am-utils that certain intense activity via amd
could trigger a panic.

I suggest you get a core dump, stack trace, whatever you can, and report it
on freebsd-hackers and/or freebsd-fs.  Clearly this is a serious bug that
they need to fix.  Of course, we'll be happy to help you and the freebsd
folks to fix it.

If it turns out that Amd is doing something wrong, then we'll fix it.  But
as I said in my earlier email to you: no kernel should ever panic b/c of
what a userland process does via syscalls (with the exception of scribbling
over random kernel memory via /dev/kmem :-)

Thanks,
Erez.