hammer does cache_lock

[Matthew Dillon]

:> I prepared the subdirectory for the mail service using the master-slave pfs.
:...
:> Ok, the problem is now, that (for the second  time) some files are
:> blocked, I get following messages in my logs:
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:> [diagnostic] cache_lock: blocked on 0xd7b9d3c8 "group"
:> [diagnostic] cache_lock: blocked on 0xd7b9d3c8 "group"
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:>
:> The email-account containing this file isn't usable anymore when this
:> file is locked. When I try to access e.g. the group file (from dspam) my
:> console freezes.

    Hi Damian.  This looks like a bug in HAMMER.  The namecache must
    be deadlocking.

:Addition:
:The reboot solved the problem for now but it kernel-panicked with
:following message:
:
:Waiting (max 60 seconds) for system thread syncer to stop...stopped
:syncing disks... 932 932 932 932 932 932 932 932 932 932 932 932 932 932
:932 932 932 932
:giving up on 1 buffers
:Debugger("busy buffer problem")
:Stopped at Debugger+0x34: movb $0,in_Debugger.3949
:db>
:So I did send reset to the debugger.
:
:Damian

    This is probably due to the same bug.

    If it is possible I would like you to generate a kernel core the
    next time the cache_lock problem occurs.  You can avoid the buffer
    sync issue with:

	sysctl kern.sync_on_panic=0

    You need to set up a dump device to get a kernel core dump.  Typically
    a line in /etc/rc.conf like this does the job:

	dumpdev="/dev/ad6s1b"

	(assuming you have a swap partition on /dev/ad6s1b that is large
	enough to hold all of main memory).

	This will set the dump device on boot.  To set it manually without
	rebooting you would run 'dumpon /dev/ad6s1b' or something similar.

    If you can get a kernel crash dump and email me privately where I can
    download it, I can examine it and hopefully find the bug.

    The way you get a kernel core is you wait for the problem to occur,
    then you drop into the debugg and manually panic the machine.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>