Fri 10 Feb 2012 06:53:19 PM UTC, original submission:
I was testing tmpfs for parallel writing. For this I was using following script:
#!/bin/bash
mkdir -p /tmp/log/$1
for i in {1..9}
do
fsx -N3000 $1/bar$i -S$i -l$((102410248)) -d -P /tmp/log &
done
wait
This script starts 9 fsx(1) programs. Each creates 8Mb file with own seed and tries to do 3000 operations. After some time (about half of minute) kernel hangs and following message is printed:
/hurd/mach-defpager: panic (default pager):copy/hurd/mach-defpager: panic (default pager):copy/hurd/mach-defpager: pancic (default pager):copypanic: thread_invoke:thread 30c9faa0 has unexpected state 14
The same behavior is present on ramfs+ext2fs and on pure ext2fs.
So, 1) OS completely hangs 2) the same behavior is present both in ramfs and tmpfs. That's why I think that bug is in kernel and not in defpager or tmpfs.
When I tried to investigate bug in tmpfs I found out that there was created a memory object with seqnos_memory_object_create and than seqnos_memory_object_data_write was called on this object. But function seqnos_memory_object_data_write doesn't have body since defpager uses new calling conventions.
Function m_o_data_write is called because by default new object uses old calling conventions when created. This could be changed when m_o_init is called. At the end of this function server should notify kernel that memory object is ready to use. If it is done with memory_object_ready than new calling convention should be used in future. If it is done with memory_object_set_attributes than old conventions stay.
There was no m_o_init call that's why m_o_data_write was called instead of m_o_data_return.
This bug doesn't appear when fsx programs are started consecutively and number of threads should be about 8.
(1) <a href="http://www.bddebian.com:8888/~hurd-web/user/Maksym_Planeta/#fsx_install">See</a> to install fsx.
|