From: Andrew Jones <drjones@redhat.com>
To: Daniel Stodden <daniel.stodden@citrix.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Xen <xen-devel@lists.xensource.com>, Tom Kopec <tek@acm.org>
Subject: Re: Re: [PATCH] blkfront: Move blkif_interrupt into a tasklet.
Date: Mon, 27 Sep 2010 12:21:13 +0200 [thread overview]
Message-ID: <4CA07019.3050807@redhat.com> (raw)
In-Reply-To: <1285580789.4365.620.camel@ramone.somacoma.net>
On 09/27/2010 11:46 AM, Daniel Stodden wrote:
> On Mon, 2010-09-27 at 03:41 -0400, Andrew Jones wrote:
>> On 09/24/2010 08:50 PM, Jeremy Fitzhardinge wrote:
>>> On 09/24/2010 12:14 AM, Andrew Jones wrote:
>>>> On 09/23/2010 08:36 PM, Jeremy Fitzhardinge wrote:
>>>>> On 09/23/2010 09:38 AM, Paolo Bonzini wrote:
>>>>>> On 09/23/2010 06:23 PM, Jeremy Fitzhardinge wrote:
>>>>>>>> Any developments with this? I've got a report of the exact same
>>>>>>>> warnings
>>>>>>>> on RHEL6 guest. See
>>>>>>>>
>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=632802
>>>>>>>>
>>>>>>>> RHEL6 doesn't have the 'Move blkif_interrupt into a tasklet' patch, so
>>>>>>>> that can be ruled out. Unfortunately I don't have this reproducing on a
>>>>>>>> test machine, so it's difficult to debug. The report I have showed
>>>>>>>> that
>>>>>>>> in at least one case it occurred on boot up, right after initting the
>>>>>>>> block device. I'm trying to get confirmation if that's always the case.
>>>>>>>>
>>>>>>>> Thanks in advance for any pointers you might have.
>>>>>>> Yes, I see it even after reverting that change as well. However I only
>>>>>>> see it on my domain with an XFS filesystem, but I haven't dug any deeper
>>>>>>> to see if that's relevant.
>>>>>>>
>>>>>>> Do you know when this appeared? Is it recent? What changes are in the
>>>>>>> rhel6 kernel in question?
>>>>>> It's got pretty much everything in stable-2.6.32.x, up to the 16 patch
>>>>>> blkfront series you posted last July. There are some RHEL-specific
>>>>>> workarounds for PV-on-HVM, but for PV domains everything matches
>>>>>> upstream.
>>>>> Have you tried bisecting to see when this particular problem appeared?
>>>>> It looks to me like something is accidentally re-enabling interrupts -
>>>>> perhaps a stack overrun is corrupting the "flags" argument between a
>>>>> spin_lock_irqsave()/restore pair.
>>>>>
>>>> Unfortunately I don't have a test machine where I can do a bisection
>>>> (yet). I'm looking for one. I only have this one report so far, and it's
>>>> on a production machine.
>>>
>>> The report says that its repeatedly killing the machine though? In my
>>> testing, it seems to hit the warning once at boot, but is OK after that
>>> (not that I'm doing anything very stressful on the domain).
>>>
>>
>> It looks like the crash is from failing to read swap due to a bad page
>> map. It's possibly another issue, but I wanted to try and clean this
>> issue up first to see what happens.
>
> Uh oh. Sure this was a frontend crash? If you see it a again, a stack
> trace to look at would be great.
>
Hi Daniel,
You can take a look at this bug
https://bugzilla.redhat.com/show_bug.cgi?id=632802
there's stacks for the swap issue in the comments and also this attached
dmesg
https://bugzilla.redhat.com/attachment.cgi?id=447789
Thanks,
Drew
> Thanks,
> Daniel
>
>
>
>
next prev parent reply other threads:[~2010-09-27 10:21 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-23 6:54 Fix the occasional xen-blkfront deadlock, when irqbalancing Daniel Stodden
2010-08-23 6:54 ` [PATCH] blkfront: Move blkif_interrupt into a tasklet Daniel Stodden
2010-08-23 7:01 ` Daniel Stodden
2010-09-02 22:46 ` Jeremy Fitzhardinge
2010-09-02 23:08 ` Daniel Stodden
2010-09-07 1:39 ` blktap lockdep hiccup Jeremy Fitzhardinge
2010-09-07 1:46 ` Daniel Stodden
2010-09-08 2:03 ` [PATCH] blkfront: Move blkif_interrupt into a tasklet Jeremy Fitzhardinge
2010-09-08 2:21 ` Daniel Stodden
2010-09-08 6:37 ` Jeremy Fitzhardinge
2010-09-23 16:08 ` Andrew Jones
2010-09-23 16:23 ` Jeremy Fitzhardinge
2010-09-23 16:38 ` Paolo Bonzini
2010-09-23 18:36 ` Jeremy Fitzhardinge
2010-09-24 7:14 ` Andrew Jones
2010-09-24 18:50 ` Jeremy Fitzhardinge
2010-09-27 7:41 ` Andrew Jones
2010-09-27 9:46 ` Daniel Stodden
2010-09-27 10:21 ` Andrew Jones [this message]
2011-08-16 11:26 ` imammedo
2011-08-16 14:57 ` Konrad Rzeszutek Wilk
2011-08-17 2:38 ` Konrad Rzeszutek Wilk
2011-08-17 7:30 ` Paolo Bonzini
2011-08-17 9:07 ` Igor Mammedov
2011-08-24 15:36 ` Konrad Rzeszutek Wilk
2011-08-24 16:36 ` Igor Mammedov
2011-08-29 19:46 ` Konrad Rzeszutek Wilk
2011-08-31 23:47 ` [PATCH] xen: x86_32: do not enable iterrupts when returning from exception in interrupt context Igor Mammedov
2011-08-31 22:37 ` Jeremy Fitzhardinge
2011-09-01 8:19 ` Igor Mammedov
2011-09-01 11:46 ` [PATCH v2] " Igor Mammedov
2011-09-01 15:45 ` Konrad Rzeszutek Wilk
2011-09-01 16:46 ` Jeremy Fitzhardinge
2011-09-02 8:18 ` Igor Mammedov
2011-09-02 13:40 ` Konrad Rzeszutek Wilk
2011-09-02 14:01 ` [Xen-devel] " Igor Mammedov
2011-09-02 14:47 ` Konrad Rzeszutek Wilk
2011-09-06 9:16 ` Igor Mammedov
2011-09-02 9:19 ` Igor Mammedov
2011-09-02 10:00 ` Keir Fraser
2010-08-23 21:09 ` Fix the occasional xen-blkfront deadlock, when irqbalancing Jeremy Fitzhardinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CA07019.3050807@redhat.com \
--to=drjones@redhat.com \
--cc=daniel.stodden@citrix.com \
--cc=jeremy@goop.org \
--cc=pbonzini@redhat.com \
--cc=tek@acm.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).