|From:||David W <dpwalters@xxxxxxxxxxxxxxx>|
|Date:||Sun, 4 Nov 2007 10:35:37 -0400|
> 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).
Description: PGP signature