Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Created attachment 494602[details]
RHEL6.1 32bit PV DomU kernel dmesg
Description of problem:
The RHEL6.1 xen PV guest will get call trace when there is high load in the guest. Try to run the kernel compiling loop and iozone test loop at the same time can reproduce the error in about 2 days. guest can work well although there is call trace in kernel message.
Version-Release number of selected component (if applicable):
kernel-2.6.32-131.0.5.el6
How reproducible:
100%
Steps to Reproduce:
1. install a 32bit RHEL6.1 as xen pv guest
2. run kernel compiling loop and iozone test with guest
3. check the guest kernel dmesg after 1~3 days
Actual results:
there is call trace in kernel dmesg:
-------------------------------------------------------------------------
hrtimer: interrupt took 2035855 ns
INFO: task iozone:13096 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
iozone D 00000000 0 13096 1771 0x00000080
eaa45030 00000282 04c4fe5d 00000000 c243fe40 b750b98c ffffffff 000c2df7
00000000 c243fe40 0000b333 d6e89cec 0000b333 c0ae2120 c0ae2120 eaa452d8
c0ae2120 c0addb54 c0ae2120 eaa452d8 ec884000 3f4fb9e5 0001c099 42b5ace7
Call Trace:
[<c0407391>] ? xen_sched_clock+0x21/0x90
[<c043e925>] ? update_curr+0x185/0x2c0
[<c0822f85>] ? schedule_timeout+0x195/0x250
[<c043f4bd>] ? enqueue_entity+0x37d/0x400
[<c0822ce9>] ? wait_for_common+0xe9/0x150
[<c044bf20>] ? default_wake_function+0x0/0x10
[<c054a3e2>] ? sync_inodes_sb+0x72/0x150
[<c054f063>] ? __sync_filesystem+0x63/0x70
[<c054f13c>] ? sync_filesystems+0xcc/0x100
[<c054f1b8>] ? sys_sync+0x18/0x40
[<c0824864>] ? syscall_call+0x7/0xb
-------------------------------------------------------------------------
Expected results:
There should no call trace
Additional info:
Hi,
A couple questions to get more info.
Was the Xen host being used to run other guests with some load? Or was dom0 running something as well? Did iozone stay in D-state? Or did it return to running, or just exit?
Thanks,
Drew
(In reply to comment #2)
> Hi,
>
> A couple questions to get more info.
>
> Was the Xen host being used to run other guests with some load? Or was dom0
> running something as well?
There are 2 RHEL6.1 PV DomUs (one is 32bit and the other is 64 bit) running on the host with the same testing (kernel compiling loop and iozone testing), only 32 bit guest get the call trace when check their status, not sure whether this only happen with 32bit.
> Did iozone stay in D-state? Or did it return to running, or just exit?
At least I saw iozone running from the output of screen. The loop was started with "while sleep 1; do iozone -a -n 10M -g 50M -i 0 -i 1 -i 5 -R;done", so I think it returned to running or just exist as the loop should be blocked if the process stay in D-state. but not sure whether it exited when there is the call trace.
Created attachment 494602 [details] RHEL6.1 32bit PV DomU kernel dmesg Description of problem: The RHEL6.1 xen PV guest will get call trace when there is high load in the guest. Try to run the kernel compiling loop and iozone test loop at the same time can reproduce the error in about 2 days. guest can work well although there is call trace in kernel message. Version-Release number of selected component (if applicable): kernel-2.6.32-131.0.5.el6 How reproducible: 100% Steps to Reproduce: 1. install a 32bit RHEL6.1 as xen pv guest 2. run kernel compiling loop and iozone test with guest 3. check the guest kernel dmesg after 1~3 days Actual results: there is call trace in kernel dmesg: ------------------------------------------------------------------------- hrtimer: interrupt took 2035855 ns INFO: task iozone:13096 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. iozone D 00000000 0 13096 1771 0x00000080 eaa45030 00000282 04c4fe5d 00000000 c243fe40 b750b98c ffffffff 000c2df7 00000000 c243fe40 0000b333 d6e89cec 0000b333 c0ae2120 c0ae2120 eaa452d8 c0ae2120 c0addb54 c0ae2120 eaa452d8 ec884000 3f4fb9e5 0001c099 42b5ace7 Call Trace: [<c0407391>] ? xen_sched_clock+0x21/0x90 [<c043e925>] ? update_curr+0x185/0x2c0 [<c0822f85>] ? schedule_timeout+0x195/0x250 [<c043f4bd>] ? enqueue_entity+0x37d/0x400 [<c0822ce9>] ? wait_for_common+0xe9/0x150 [<c044bf20>] ? default_wake_function+0x0/0x10 [<c054a3e2>] ? sync_inodes_sb+0x72/0x150 [<c054f063>] ? __sync_filesystem+0x63/0x70 [<c054f13c>] ? sync_filesystems+0xcc/0x100 [<c054f1b8>] ? sys_sync+0x18/0x40 [<c0824864>] ? syscall_call+0x7/0xb ------------------------------------------------------------------------- Expected results: There should no call trace Additional info: