Date: Wed, 6 Apr 2005 16:19:39 -0400 From: Erez Zadok <ezk@cs.sunysb.edu> To: "Vincent, Thomas" <Thomas.Vincent@netapp.com> Cc: am-utils@fsl.cs.sunysb.edu Subject: Re: Reproducable FreeBSD/AMD Crash Message-ID: <200504062019.j36KJdgh024816@agora.fsl.cs.sunysb.edu> In-Reply-To: Your message of "Wed, 06 Apr 2005 12:57:25 PDT." <637A278D8D0DBC438EA5E75C6E1818B9028C4810@magenta.hq.netapp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200504062019.j36KJdgh024816>