Bug 695206 - autotest.ltp: INFO: task msgctl10:18993 blocked for more than 120
Summary: autotest.ltp: INFO: task msgctl10:18993 blocked for more than 120
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.1
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Amos Kong
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-11 04:45 UTC by Amos Kong
Modified: 2015-05-25 00:06 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-04 02:49:17 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Amos Kong 2011-04-11 04:45:16 UTC
Description of problem:
I executed autotest.ltp test in a rhel6.1 guest, got some call trace during the testing.

more info of autotest.ltp:
https://github.com/autotest/autotest/tree/master/client/tests/ltp

Version-Release number of selected component (if applicable):
guest kernel: 2.6.32-130.el6.x86_64
host kernel: 2.6.32-128.el6.x86_64
qemu-kvm-0.12.1.2-2.156.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. Boot up a rhel6.1 guest
2. Execute autotest.ltp test in guest
guest)# cd autotest
guest)# client/bin/autotest client/tests/ltp/control
  
Actual results:
got some call trace

Expected results:
test can pass.

Additional info:

1. call trace of guest

2011-04-11 12:40:29: INFO: task msgctl10:18993 blocked for more than 120 seconds.
2011-04-11 12:40:29: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
2011-04-11 12:40:29: msgctl10      D 0000000000000001     0 18993  18706 0x00000080
2011-04-11 12:40:29:  ffff880040c45d38 0000000000000046 00007f16bf0f9000 ffffea00018a2f90
2011-04-11 12:40:29:  ffffea00016a5618 ffff880040c1e188 ffff88005b1237c8 0000000000000000
2011-04-11 12:40:29:  ffff880040c00678 ffff880040c45fd8 000000000000f598 ffff880040c00678
2011-04-11 12:40:29: Call Trace:
2011-04-11 12:40:29:  [<ffffffff814dd4a5>] rwsem_down_failed_common+0x95/0x1d0
2011-04-11 12:40:29:  [<ffffffff814dd603>] rwsem_down_write_failed+0x23/0x30
2011-04-11 12:40:29:  [<ffffffff8126e493>] call_rwsem_down_write_failed+0x13/0x20
2011-04-11 12:40:29:  [<ffffffff814dcb02>] ? down_write+0x32/0x40
2011-04-11 12:40:29:  [<ffffffff8116b839>] __khugepaged_exit+0x109/0x130
2011-04-11 12:40:29:  [<ffffffff81064578>] mmput+0xe8/0x120
2011-04-11 12:40:29:  [<ffffffff8106ba21>] exit_mm+0x111/0x150
2011-04-11 12:40:29:  [<ffffffff8106bdbf>] do_exit+0x15f/0x860
2011-04-11 12:40:29:  [<ffffffff8106b4be>] ? sys_wait4+0xae/0x100
2011-04-11 12:40:29:  [<ffffffff810d1b82>] ? audit_syscall_entry+0x272/0x2a0
2011-04-11 12:40:29:  [<ffffffff8106c518>] do_group_exit+0x58/0xd0
2011-04-11 12:40:29:  [<ffffffff8106c5a7>] sys_exit_group+0x17/0x20
2011-04-11 12:40:29:  [<ffffffff8100b172>] system_call_fastpath+0x16/0x1b

2. qemu-kvm cmdline

#qemu-kvm -chardev socket,id=qmp_monitor_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20110410-070702-0oSe,server,nowait -mon chardev=qmp_monitor_id_qmpmonitor1,mode=control -chardev socket,id=serial_id_20110410-070702-0oSe,path=/tmp/serial-20110410-070702-0oSe,server,nowait -device isa-serial,chardev=serial_id_20110410-070702-0oSe -drive file=/home/devel/autotest-devel/client/tests/kvm/images/RHEL-Server-6.1-64-virtio.qcow2,index=0,if=none,id=drive-virtio-disk1,media=disk,cache=none,format=qcow2,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,id=virtio-disk1 -device virtio-net-pci,netdev=idSfVU9r,mac=9a:8a:ec:e1:42:9b,id=ndev00idSfVU9r,bus=pci.0,addr=0x3 -netdev tap,id=idSfVU9r,vhost=on,ifname=t0-070702-0oSe,script=/home/devel/autotest-devel/client/tests/kvm/scripts/qemu-ifup-switch,downscript=no -m 2048 -smp 2,cores=1,threads=1,sockets=2 -cpu cpu64-rhel6,+sse2,+x2apic -vnc :0 -rtc base=utc,clock=host,driftfix=none -M rhel6.1.0 -boot order=cdn,once=c,menu=off -usbdevice tablet -no-kvm-pit-reinjection -enable-kvm

Comment 1 RHEL Program Management 2011-04-11 06:00:13 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 4 Gleb Natapov 2011-06-15 14:27:52 UTC
(In reply to comment #0)
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. Boot up a rhel6.1 guest
> 2. Execute autotest.ltp test in guest
> guest)# cd autotest
> guest)# client/bin/autotest client/tests/ltp/control
> 
> Actual results:
> got some call trace
The trace is harmless.

> 
> Expected results:
> test can pass.
How the trace stops it from passing?


> 2. qemu-kvm cmdline
> 

> -m 2048 -smp 2,cores=1,threads=1,sockets=2 -cpu cpu64-rhel6,+sse2,+x2apic -vnc
How much memory/cpus host has?

Comment 5 Amos Kong 2011-07-20 03:05:33 UTC
(In reply to comment #4)
> (In reply to comment #0)
> > 
> > How reproducible:
> > always
> > 
> > Steps to Reproduce:
> > 1. Boot up a rhel6.1 guest
> > 2. Execute autotest.ltp test in guest
> > guest)# cd autotest
> > guest)# client/bin/autotest client/tests/ltp/control
> > 
> > Actual results:
> > got some call trace
> The trace is harmless.

So we can close this bug as NOTABUG.

> > Expected results:
> > test can pass.
> How the trace stops it from passing?

ltp test always timeout.

> > 2. qemu-kvm cmdline
> > 
> 
> > -m 2048 -smp 2,cores=1,threads=1,sockets=2 -cpu cpu64-rhel6,+sse2,+x2apic -vnc
> How much memory/cpus host has?

host memory: 4G
host cpus: 4

Comment 6 Gleb Natapov 2011-07-20 08:56:13 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #0)
> > > 
> > > How reproducible:
> > > always
> > > 
> > > Steps to Reproduce:
> > > 1. Boot up a rhel6.1 guest
> > > 2. Execute autotest.ltp test in guest
> > > guest)# cd autotest
> > > guest)# client/bin/autotest client/tests/ltp/control
> > > 
> > > Actual results:
> > > got some call trace
> > The trace is harmless.
> 
> So we can close this bug as NOTABUG.
If ltp test always timeouts then probably we can't.

> 
> > > Expected results:
> > > test can pass.
> > How the trace stops it from passing?
> 
> ltp test always timeout.
HHave you tried to reproduce manually (without aoutotest)?

> 
> > > 2. qemu-kvm cmdline
> > > 
> > 
> > > -m 2048 -smp 2,cores=1,threads=1,sockets=2 -cpu cpu64-rhel6,+sse2,+x2apic -vnc
> > How much memory/cpus host has?
> 
> host memory: 4G
> host cpus: 4

Is this the only guest on the host during the test?

Comment 7 Amos Kong 2011-08-02 08:18:23 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > > > How reproducible:
> > > > always
> > > > 
> > > > Steps to Reproduce:
> > > > 1. Boot up a rhel6.1 guest
> > > > 2. Execute autotest.ltp test in guest
> > > > guest)# cd autotest
> > > > guest)# client/bin/autotest client/tests/ltp/control
> > > > 
> > > > Actual results:
> > > > got some call trace
> > > The trace is harmless.
> > 
> > So we can close this bug as NOTABUG.
> If ltp test always timeouts then probably we can't.
> 
> > 
> > > > Expected results:
> > > > test can pass.
> > > How the trace stops it from passing?
> > 
> > ltp test always timeout.
> Have you tried to reproduce manually (without aoutotest)?

No trace outputs in manual test.
I also tested in the physical machine, system is very slow, but no call trace.

> > > > 2. qemu-kvm cmdline
> > > > 
> > > 
> > > > -m 2048 -smp 2,cores=1,threads=1,sockets=2 -cpu cpu64-rhel6,+sse2,+x2apic -vnc
> > > How much memory/cpus host has?
> > 
> > host memory: 4G
> > host cpus: 4
> 
> Is this the only guest on the host during the test?

Yes.

Comment 9 Amos Kong 2012-05-04 02:49:17 UTC
Tested with latest qemu/kernel, the _harmless_ calltrace also exists because of heavy load. 
qemu-kvm-0.12.1.2-2.285.el6.x86_64
host/guest kernel: 2.6.32-262.el6.x86_64

---
client/tests/ltp is a client test in autotest upstream, there is not time limitation.

In internal autotest, they added a new test autotest.ltp, and set the test timeout to 1000000 (11 days). and this test is not executed in routine testing.
---


Note You need to log in before you can comment on or make changes to this bug.