[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #35501] Work with memory object before it is initiated hangs the ke

From: Maksym Planeta
Subject: [bug #35501] Work with memory object before it is initiated hangs the kernel.
Date: Fri, 10 Feb 2012 18:53:20 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0 Iceweasel/8.0


                 Summary: Work with memory object before it is initiated hangs
the kernel.
                 Project: The GNU Hurd
            Submitted by: mplaneta
            Submitted on: Fri 10 Feb 2012 08:53:19 PM EET
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Reproducibility: None
              Size (loc): None
         Planned Release: None
                  Effort: 0.00
Wiki-like text discussion box: 



I was testing tmpfs for parallel writing. For this I was using following

mkdir -p /tmp/log/$1
for i in {1..9}
  fsx -N3000 $1/bar$i -S$i -l$((1024*1024*8)) -d -P /tmp/log &

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

This bug doesn't appear when fsx programs are started consecutively and number
of threads should be about 8.

(1) <a
to install fsx.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]