On 2013-02-13, at 14:50 , Rick Macklem <rmack...@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?) sysctl debug.kdb.break_to_debugger=1 (shell) <ctl><alt><esc> (from console) 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? 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-unsubscr...@freebsd.org"
