Date: Wed, 13 Feb 2013 18:54:28 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: "Marc G. Fournier" <scrappy@hub.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-stable@freebsd.org, Kostik Belousov <kib@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: 9-STABLE -> NFS -> NetAPP: Message-ID: <426187631.3000937.1360799668107.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <F4BD60BB-6F5F-4E67-BA6D-B4EBC5E3E5BE@hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Marc Fournier wrote: > On 2013-02-13, at 14:50 , Rick Macklem <rmacklem@uoguelph.ca> wrote: > > > He does get the odd error reported by nfs_getpages() and I don't > > think we've isolated why yet. The error is 13 (EACCES), but jhb@ > > thought it might be because of the bug he fixed where the krpc > > reported EACCES for the EINTR case. I don't think we've heard > > back from Marc w.r.t. whether he has gotten any more of these > > erros logged since applying jhb@'s patch and whether or not > > the errno has changed to EINTR? > > As mentioned previously, it doesn't happen all that often … this > latest one was after 21 days of uptime (or so) … I just upgraded the > kernel on that machine to take into consideration changes to hfs > *since* the last upgrade, so it might be another 20-30 days before it > happens again *if* that last patch didn't' fix it … > > I have several servers that do have fully operational remote consoles > though … to save time if/when it happens next, what do I all need to > run? > > ps auxlH > procstat -kk <pid> (for which process? … all part of that "group", or > just one of the apparently hung processes?) The pid that is in "T" state for the "ps auxlH". > sysctl debug.kdb.break_to_debugger=1 (shell) > <ctl><alt><esc> (from console) > Then the commands described in: http://www.freebsd.org/doc/en_US.ISO8859-1/book/developers-handbook/kerneldebug-deadlocks.html "show alllocks" and "show lockedvnods" may be the most useful, I think you can also "show sleepchain <pid>" "show lockchain <pid>" using the <pid> that is in "T" state. If you haven't built your kernel with "options WITNESS", this won't work well. > now, is there a way of forcing it to do a dump core so that I can run > the various commands from a shell *after* its rebooted? No idea. Someone familiar with what you can do to core dump and how to get your system to make will have to answer this. > Not > particularly easy to redirect console output to a file (or is it?), so > anything that scrolls off the screen is pretty much lost … I'm using a > DRAC card in most cases, no serial consoles or anything like that that > I can run within a script session … a 'ps' listing is >500 lines long, > just to give an idea ... > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?426187631.3000937.1360799668107.JavaMail.root>