[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] dom0 / hypervisor hang on dom0 boot


  • To: xen-devel@xxxxxxxxxxxxx
  • From: Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>
  • Date: Thu, 16 May 2013 13:07:05 +0200
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  • Delivery-date: Thu, 16 May 2013 11:13:45 +0000
  • Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:From:To:Cc:Subject:Date:Message-ID: User-Agent:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding:Content-Type; b=i3ymySpgRJWC8ZHl4RsonP3o2gQYL4ZSzgYmfNaMu49xW5v4aX4DqGjT 22yzjsgdLoUN/t8J/7VvsoZykF7KSr/5lUlqKoQn0H2dMZWws9jO+KO2o PVKqEUe5r2hGFzEj49X5079+OI1Dzew6jy7bInhXuaqaUhDwEFwnTGK9L D77Fmgg6/aap8NCDpCI9t0VFcBNJ2Cq4o/aDlryMfoU1alkDQMgG5BvVe 6qX12Xjj4XP8iazo/I4KC3UdNsqZk;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

Am Mittwoch 15 Mai 2013, 10:42:17 schrieb Jan Beulich:
> >>> On 15.05.13 at 11:12, Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx> wrote:
> > Am Mittwoch 15 Mai 2013, 09:35:46 schrieb Jan Beulich:
> >> >>> On 15.05.13 at 08:53, Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx> wrote:
> >> > I tried iommu=debug and I can't see any faulting messages but Iam not
> >> > familiar with this code.
> >> > I attached the logging, maybe anyone can have a look on this.
> 
> Perhaps only (if at all) by instrumenting the hypervisor. The
> question of course is how easily/quickly you can narrow down the
> code region that it might be dying in. And whether it's a hypervisor
> action at all that causes the hang (as opposed to something the
> DRM code in Dom0 does).

I added some debug code to the linux kernel and could track down the
point of the hang. I used openSuSE kernel 3.7.10-1.4 but I looked at newer
kernels and found that the code is similar.

i915_gem_init_global_gtt(...)
 ...
 intel_gtt_clear_range(start / PAGE_SIZE, (end-start) / PAGE_SIZE);
 ...

void intel_gtt_clear_range(unsigned int first_entry, unsigned int num_entries)
{
        unsigned int i;

    ---> A printk(...) here is seen on serial line!

        for (i = first_entry; i < (first_entry + num_entries); i++) {
                
intel_private.driver->write_entry(intel_private.base.scratch_page_dma,
                                                  i, 0);
        }

    ---> A printk(...) here is never seen!

        readl(intel_private.gtt+i-1);
}

The function behind the pointer intel_private.driver->write_entry is
i965_write_entry(). And the interesting instruction seems to be:
  writel(addr | pte_flags, intel_private.gtt + entry);

I added another printk() on start of the function i965_write_entry().
And surprisingly  after printing a lot of messages the kernel came up!!!
But now I had other problems like losing the audio device (maybe timeouts).
So maybe the hang is a timing problem?

What I wanted to check is, what the hypervisor is doing while the system hangs.
Has anybody an idea maybe a timer and after 30s printing a dump of the stack of
all cpus?
Thanks.

Dietmar.


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.