On Mon, Oct 15, 2007 at 11:47:16AM +0200, Pawel Jakub Dawidek wrote:
This looks like VFS deadlock between process 42575 and 42585. You
debugging is really nice, but unfortunately there is no backtrace of
process 42575, so we don't know where and why it's stuck...
Can you next time take 'show lockedvnods', 'show alllocks' (as you did
this time), but also 'alltrace'?
Here's a new debug session with the above requested information:
As you can see, there were a couple of LORs before I entered the
debugger. At least one of these (the last one) appeared when trying to
list the files in one of the zfs filesystems, where rsync was hanging.
This is with RELENG_7 from Thu Oct 25 14:30:37 CEST 2007.
Regards,
Brix
--
Henrik Brix Andersen <henrik@xxxxxxxxxxxxxxx>
Re: 6.1-RELEASE / 6.2 Kernel Crash... ...Robert Watson wrote: ... Yeah, unfortunately if some combination of storage driver and hardware aren't working, it's hard to get a dump... ...debugging information from DDB and to skip the dump side of things. ... The usual first command to type is "trace" to generate a backtrace;... (freebsd-isp)
Re: 6.1-RELEASE / 6.2 Kernel Crash... ... The usual fallback here is to use a serial console to capture debugging information from DDB and to skip the dump side of things. ... The reason for using a serial console is to avoid having to hand-copy trap and debugging information, which gets very painful very quickly. ... The usual first command to type is "trace" to generate a backtrace; it's often useful also to do "show pcpu", "show allpcpu", "alltrace", and "ps", although for the problem you're seeing the last two may be less useful. ... The 0x50 trap address in your post suggests this is a NULL pointer dereference.... (freebsd-hackers)
Re: 6.1-RELEASE / 6.2 Kernel Crash... ...Robert Watson wrote: ... Yeah, unfortunately if some combination of storage driver and hardware aren't working, it's hard to get a dump... ...debugging information from DDB and to skip the dump side of things. ... The usual first command to type is "trace" to generate a backtrace;... (freebsd-hackers)
Re: 6.1-RELEASE / 6.2 Kernel Crash... ... The usual fallback here is to use a serial console to capture debugging information from DDB and to skip the dump side of things. ... The reason for using a serial console is to avoid having to hand-copy trap and debugging information, which gets very painful very quickly. ... The usual first command to type is "trace" to generate a backtrace; it's often useful also to do "show pcpu", "show allpcpu", "alltrace", and "ps", although for the problem you're seeing the last two may be less useful. ... The 0x50 trap address in your post suggests this is a NULL pointer dereference.... (freebsd-isp)
