[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1438849369.9747.91.camel@citrix.com>
Date: Thu, 6 Aug 2015 09:22:49 +0100
From: Ian Campbell <ian.campbell@...rix.com>
To: David Vrabel <david.vrabel@...rix.com>,
"Jason A. Donenfeld" <Jason@...c4.com>,
<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
<xen-devel@...ts.xen.org>
CC: Paul McKenney <paulmck@...ux.vnet.ibm.com>
Subject: Re: [Xen-devel] printk from softirq on xen: hard lockup
On Tue, 2015-08-04 at 18:12 +0100, David Vrabel wrote:
> On 04/08/15 17:41, Jason A. Donenfeld wrote:
> > Hi folks,
> >
> > Paul McKenney and I had an offline discussion about some rcu questions
> > that eventually lead into me investigating a strange full lock-up I'm
> > experiencing as a consequence of a printk in softirq inside of an
> > rcu_read_lock, when using Xen PV. Relevant excerpts of the
> ^^ PV guest?
>
> > (gdb) target remote localhost:9999
> > Remote debugging using localhost:9999
> > __xapic_wait_icr_idle () at ./arch/x86/include/asm/ipi.h:56
> > 56 while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ => HVM guest
>
> Which is it?
Aren't there still some code paths for PV guests which hit the native APIC
case (emulated in Xen even for PV these days, since pvops in the early days
didn't accept the hooks needed to make use of the hypercall versions of
apic read/write).
In particular I'm thinking of the IPI which is (or was) used by the sysrq
to trigger the backtrace on all CPUs.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists