On 09/03/2013 02:27 PM, Manfred Spraul wrote: > On 09/03/2013 10:44 AM, Vineet Gupta wrote: >>> b) Could you check that it is not just a performance regression? >>> Does ./msgctl08 1000 16 hang, too? >> Nope that doesn't hang. The minimal configuration that hangs reliably is msgctl >> 50000 2 >> >> With this config there are 3 processes. >> ... >> 555 554 root S 1208 0.4 0 0.0 ./msgctl08 50000 2 >> 554 551 root S 1208 0.4 0 0.0 ./msgctl08 50000 2 >> 551 496 root S 1208 0.4 0 0.0 ./msgctl08 50000 2 >> ... >> >> [ARCLinux]$ cat /proc/551/stack >> [<80aec3c6>] do_wait+0xa02/0xc94 >> [<80aecad2>] SyS_wait4+0x52/0xa4 >> [<80ae24fc>] ret_from_system_call+0x0/0x4 >> >> [ARCLinux]$ cat /proc/555/stack >> [<80c2950e>] SyS_msgrcv+0x252/0x420 >> [<80ae24fc>] ret_from_system_call+0x0/0x4 >> >> [ARCLinux]$ cat /proc/554/stack >> [<80c28c82>] do_msgsnd+0x116/0x35c >> [<80ae24fc>] ret_from_system_call+0x0/0x4 >> >> Is this a case of lost wakeup or some such. I'm running with some more diagnostics >> and will report soon ... > What is the output of ipcs -q? Is the queue full or empty when it hangs? > I.e. do we forget to wake up a receiver or forget to wake up a sender? / # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x72d83160 163841 root 600 0 0 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
