Bug 499553
| Summary: | Cannot generate proper stacktrace on xen-ia64 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Daniel Kwon <dkwon> |
| Component: | kernel-xen | Assignee: | Andrew Jones <drjones> |
| Status: | CLOSED ERRATA | QA Contact: | Boris Ranto <branto> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.4 | CC: | branto, clalance, drjones, jlv, ltroan, pbonzini, tao, xen-maint |
| Target Milestone: | rc | ||
| Target Release: | 5.6 | ||
| Hardware: | ia64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-01-13 20:48:06 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 514489, 557597 | ||
| Attachments: | |||
|
Description
Daniel Kwon
2009-05-07 07:01:18 UTC
For RHEL-5 Xen bugs, please make sure the "Product" field is set to "Red Hat Enterprise Linux 5", otherwise there is a chance we will not see it. Also, please do not attach tar files for patches, even if there are more than one. It makes it difficult to look at and review. I've fixed both of these issues on this bug. Chris Lalancette Created attachment 342778 [details]
Pathc 1/3, the kernel side of the stack unwinding
Created attachment 342779 [details]
Patch 2/3, hypervisor patch to dump execution state
Created attachment 342780 [details]
Patch 3/3, hypervisor patch to add unwind_info
I've uploaded a test kernel that should have a fix for this problem here: http://people.redhat.com/clalance/virttest/ Can the reporters who are having problems please download and try out this test kernel? Thanks, Chris Lalancette Event posted on 08-26-2009 10:26am JST by moshiro Dear Chris, Could you please provide source package to Fujitsu as well? Fujitsu would like to review the code as well. Best Regards, Moritoshi This event sent from IssueTracker by moshiro issue 283498 (In reply to comment #6) > Event posted on 08-26-2009 10:26am JST by moshiro > > Dear Chris, > > Could you please provide source package to Fujitsu as well? Fujitsu would > like to review the code as well. I've uploaded the .src.rpm to the same location. The code should be the same as what was posted in this BZ. Chris Lalancette Yeah, this one just fell off of my radar. The patches in this BZ are the latest, and should work fine. Drew, do you mind posting them? Thanks, Chris Lalancette (In reply to comment #14) > Yeah, this one just fell off of my radar. The patches in this BZ are the > latest, and should work fine. Drew, do you mind posting them? > No problem. I'll get the posted soon. Drew Looks like this is a go for 5.6. Setting BLOCKER=? until commented by devel. Otherwise will miss 5.6. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. Correction, setting exception awaiting ACK by QA I can go ahead and post this patchset, since it doesn't look risky and might make some improvement. However my testing didn't show a huge improvement. When dumping registers before this patch with the Xen serial console I still got backtraces and registers, but only when there was something to show (best done during a boot). After this patch I get the backtrace every time (due to the 2nd patch in the series), but otherwise what seems to be the same behavior as before (perhaps it now supports more, but I didn't try to test it further). Therefore, my question to Fujitsu is whether or not they truly find this necessary and useful. If not, I would drop it to avoid the code change. I went ahead and posted the patch set. It matches upstream and looks ok. I guess there's some improvement, even if small, so should be worth the posting/reviewing time. Drew in kernel-2.6.18-215.el5 You can download this test kernel from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed. Moving back to POST, the xen half of this patchset was missed in 215. in kernel-2.6.18-219.el5 You can download this test kernel from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed. When I tried to verify I've found out that FIXME: implement ia64 dump_execution_state() line is still there although call trace is generated. I see that it is same in the patch but is this right? Isn't it already implemented, now? We still don't get a register dump, since all we added was the calltrace. So I think the fixme is still technically correct, but it probably could have be changed to a code comment instead of a print message. OK, thanks for the answer. If anything is still missing there than I guess it is ok to print the message. Moving to verified. In 2.6.18-225, Call Trace is present: [root@hp-sapphire-01 ~]# uname -a Linux hp-sapphire-01.rhts.eng.bos.redhat.com 2.6.18-225.el5xen #1 SMP Mon Sep 27 10:57:15 EDT 2010 ia64 ia64 ia64 GNU/Linux [root@hp-sapphire-01 ~]# (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to DOM0). (XEN) 'd' pressed -> dumping registers (XEN) (XEN) *** Dumping CPU0 host state: *** (XEN) FIXME: implement ia64 dump_execution_state() (XEN) (XEN) Call Trace: (XEN) [<f0000000040c0530>] show_stack+0x80/0xa0 (XEN) sp=f000000004127970 bsp=f000000004121580 (XEN) [<f00000000402cab0>] __dump_execstate+0x30/0x100 (XEN) sp=f000000004127b40 bsp=f000000004121568 (XEN) [<f00000000402cbe0>] dump_registers+0x60/0x180 (XEN) sp=f000000004127b40 bsp=f000000004121540 (XEN) [<f00000000402ced0>] handle_keypress+0x1d0/0x210 (XEN) sp=f000000004127b40 bsp=f000000004121508 (XEN) [<f00000000405ad10>] serial_rx+0x1a0/0x1c0 (XEN) sp=f000000004127b40 bsp=f0000000041214d8 (XEN) [<f00000000405d330>] serial_rx_interrupt+0x1a0/0x2b0 (XEN) sp=f000000004127b40 bsp=f0000000041214a0 (XEN) [<f00000000405bf20>] ns16550_interrupt+0xa0/0xf0 (XEN) sp=f000000004127b50 bsp=f000000004121460 (XEN) [<f000000004078a40>] __do_IRQ+0x360/0x480 (XEN) sp=f000000004127b50 bsp=f000000004121400 (XEN) [<f0000000040b9b50>] ia64_handle_irq+0xf0/0x180 (XEN) sp=f000000004127b50 bsp=f0000000041213b0 (XEN) [<f0000000040b9320>] ia64_leave_kernel+0x0/0x300 (XEN) sp=f000000004127b50 bsp=f0000000041213b0 (XEN) [<f000000004062590>] startup_cpu_idle_loop+0x300/0x320 (XEN) sp=f000000004127d50 bsp=f000000004121330 (XEN) [<f000000004095c80>] start_kernel+0x1590/0x1840 (XEN) sp=f000000004127df0 bsp=f000000004121270 (XEN) [<f000000004019d20>] _start+0x340/0x360 (XEN) sp=f000000004127e00 bsp=f0000000041211d0 (XEN) *** Dumping CPU0 guest state: *** (XEN) No guest context (CPU is idle). An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0017.html |