On Tuesday 03 November 2009 02:02:08 Weldon S Godfrey 3 wrote: > If memory serves me right, sometime around Tomorrow, Ivan Voras told me: > > > Weldon S Godfrey 3 wrote: > > > >> I don't know how to troubleshoot this further on the server since I am not > >> getting any problems indicated in logging, panics, cores, etc. > > > > If you have console access to the system, the generic advice would be to > > compile a kernel with the kernel debugger - options KDB and DDB (see > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html), > > enter the debugger, force a kernel dump file to be created (by entering "call > > doadump") and then proceed with post-mortem examination of the kernel at your > > leisure (e.g. from a remote ssh console, etc). > > > > See > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html > > for instructions on what information to collect. > > > > If you can provoke your problem with using WITNESS that would probably be > > great, but it will slow down your production machine noticeably. When WITNESS > > is enabled you might also get more information - such as LOR warnings, which > > you should also collect. > > > > Keep the dump file, someone might ask you for more information. > > > > Thanks, I will work on trying to get a system with those enabled. > > Another thought that came to mind that this sounds like some sort of > network buffer exhaustion. Is there anything to look for there? Are you perhaps using em(4)? There was an mbuf leak in the driver, which was fixed recently. You can check mbuf usage with netstat -m. -- Pieter de GoejeReceived on Tue Nov 03 2009 - 07:49:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:57 UTC