Re: [issue833] cache_lock: blocked on 0xe29c3b08 ""

[David W <dpwalters@xxxxxxxxxxxxxxx>]

> I guess a simple shell script should be sufficient so that Matt can
> reproduce the bug.  Unless of course you want to get your hands dirty
> yourself.  In this case I guess gdb needs to be extended to be able to
> deal with multiple threads :)
> 
> cheers
>   simon

Attached is a script that probably works 100% of the time. You may want
to backup your vkernel filesystem before running the script as it may
become trashed due to the inability to sync the filesystem after becoming
locked up. Also, there is some preparation work to do before running this
script inside of a vkernel. Here are some example commands (assuming your
vkernel filesystem is a lot like the one in the vkernel man page) to prepare
the vkernel and then trigger the bug inside of the vkernel.

1. dd if=/dev/zero of=/mnt.img bs=1m count=5
2. vnconfig -c -s labels vn0 /mnt.img
3. disklabel -r -w vn0s0 auto
4. disklabel -e vn0s0                      #edit the label to create a vn0s0a partition
5. newfs /dev/vn0s0a
6. echo "/dev/vn0s0a  /mnt  ufs  rw,userquota  1  1" >> /etc/fstab
7. mount /mnt
8. ./bug.sh /mnt

After having run the script myself, it would seem you can ctrl-z out of the
script and just have a zombied process. I'm not sure, but when /home
is the filesystem and you're trying to login remotely as a user this is
very bad (as sshd gets zombied repeatedly and this is what I was experiencing).
Also, you cannot unmount the filesystem after locking it up. You also may or
may not see the "cache_lock: blocked" message(s).

Attachment: bug.sh
Description: application/shellscript

Attachment: pgp00005.pgp
Description: PGP signature