Re: ffs snapshot lockup

On Wed, Oct 04, 2006 at 01:06:37PM -0400, Vivek Khera wrote:

On Oct 4, 2006, at 12:39 PM, Kris Kennaway wrote:


The only thing I think was running at the time would be a large file
copy from a remote system to this one using rsync.

As I understand, you got the panic. Then, you shall post the panic
message.
If you have core file, then running kgdb on the core may show
required
information.
(it shall be on the console exactly before en
and backtrace (using the bt command of ddb) of the paniced thread.

YOu can also do 'show msgbuf' from DDB.


i ran kgdb on the vmcore file. since the dump was generated by
calling doadump from DDB, the backtrace was showing the call stack of
that.

from what i read in the output from kgdb, it seems that something
locked the kernel and we broke to debugger from the watchdog timeout
(I enable software watchdog).

Hmm, be careful with that - if you set the timeout too low (and note
that for some workloads O(minutes) may even be too low) then you'll
get a lot of false positives.

Kris

Attachment: pgprEiB84sFCV.pgp
Description: PGP signature

Relevant Pages

  • Re: ffs snapshot lockup
    ... then running kgdb on the core may show ... and backtrace of the paniced thread. ... YOu can also do 'show msgbuf' from DDB. ... locked the kernel and we broke to debugger from the watchdog timeout ...
    (freebsd-stable)
  • Re: FreeBSD 7.0 crashed when running super-smack upon PostgreSQL
    ... This is the backtrace output in the culprit thread: ... Is there any chance I can get remote access to a box holding the synchronized kernel, kernel debugging symbols, source code, and core dump? ... We need to track down the original thread and figure out why it's sleeping while holding that lock -- perhaps it's a user thread performing a copyin/copyout holding the lock, or perhaps an ithread or other software interrupt thread acquiring a lock of an inappropriate type while holding the lock. ...
    (freebsd-stable)
  • Re: panic with tcpdrop
    ... An other panic ocurred, but on other area, is on snp.ko module but can't get backtrace. ... page fault while in kernel mode ... Previous frame inner to this frame ...
    (freebsd-current)
  • Re: panic with tcpdrop
    ... An other panic ocurred, but on other area, is on snp.ko module but can't get backtrace. ... page fault while in kernel mode ... Previous frame inner to this frame ...
    (freebsd-current)
  • Re: how to find out what the other CPU is doing
    ... I had to do this from DDB ... ... For x86 the second CPU ... You can use the bp to trace backward through the stack ... to kgdb after getting the ebp. ...
    (freebsd-current)