Bug 459728
| Summary: | kernel BUG at arch/i386/mm/hypervisor.c:196! | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | jeffb69ma <jbartlett01> |
| Component: | kernel-xen | Assignee: | Andrew Jones <drjones> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Martin Jenner <mjenner> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.5 | CC: | clalance, drjones, jcavallaro, joe.jin, lersek, pbonzini, riel, tao, xen-maint |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-07-28 15:05:10 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: | 458302 | ||
|
Description
jeffb69ma
2008-08-21 16:56:04 UTC
Is this a 64 bit dom0 and a 32 bit domU? 32 bit dom0 and domU OK. Well, do you have your guests set up to dump core automatically when they crash? If not, please configure it in /etc/xen/xend-config.sxp; then next time it crashes, we should at least get a core. Also, if it happens again, please attach a full output from "xm dmesg" in the dom0; that will give us a little bit more information about why this is happening. Thanks, Chris Lalancette This bug is still waiting for a reproducer to be identified. Also, there's an outstanding question of whether or not the crash has been seen on later releases, at least 4.8. The upstream bug doesn't show any recent reports of it either. Just to capture some other comments here: From the xm dmesg log I see a lot of the following: (XEN) mm.c:649:d27 Error getting mfn 8846 (pfn 5555555555555555) from L1 entry 0000000008846063 for dom27 (XEN) printk: 18834 messages suppressed. There are also several other mfn errors with more sane pfns and many 'Non-privileged (27) attempt to map I/O space' errors. (In reply to comment #16) > This bug is still waiting for a reproducer to be identified. Also, there's an > outstanding question of whether or not the crash has been seen on later > releases, at least 4.8. The upstream bug doesn't show any recent reports of it > either. > > Just to capture some other comments here: > > From the xm dmesg log I see a lot of the following: > > (XEN) mm.c:649:d27 Error getting mfn 8846 (pfn 5555555555555555) from L1 entry > 0000000008846063 for dom27 > (XEN) printk: 18834 messages suppressed. Right, this is the crux of the issue. The domain gave completely bogus PFN's to the hypervisor, which the hypervisor then failed. And of course, the domain then did BUG_ON(), since it didn't expect it to happen. But what we don't know is why the domain handed down those bogus PFN's to begin with. That's something only a reproducer (or a valid crash file) could tell us. And like you said, this may have been fixed already, since there have been quite a few fixes in this area since 4.5. > > There are also several other mfn errors with more sane pfns and many > 'Non-privileged (27) attempt to map I/O space' errors. These you can ignore, for the most part. Chris Lalancette This looks very much like a dup of bug 513537. Unfortunately that one only includes xend.log and not "xm dmesg", but the bogus pfn's are exactly the symptom of the bug. *** This bug has been marked as a duplicate of bug 513537 *** Because without a reliable reproducer, I was hoping that the fix for bug 513537 fixed this as well. The alternative was CLOSED/INSUFFICIENT_DATA at the time. By looking at the patch that fixed the xm save bug, I was indeed in error. I'm reopening this. That said, as in comment 16, this was only reported on ancient versions. Does the customer have a reproducer? If not, this is going to be closed again in a few months. |