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

RE: [Xen-devel] Unknown interrupt on x86_64 Xen on ES7000 x86_64



> > It looks like the page fault/interrupt is happening in map_alloc().
I
> > see that alloc_heap_pages() and map_alloc() are called before
without
> > any issues. Not sure why it is tripping up now. Any ideas?
> 
> Not really. Perhaps some part of the bitmap is not properly mapped? I
> think you'll have to add a bunch more tracing -- find out what address
> is actually faulting and work backwards to see why it's not mapped. If
> it looks like it should be valid then maybe look at the code that is
> intended to 1:1 map all RAM, in arch/x86/setup.c:__start_xen() (the
> code is wrapped in CONFIG_x86_64).

I found out that the "Unknown Interrupt" issue happens only when debug
is turned on in Xen (verbose & debug=y in Rules.mk). When debug is
turned off the systems dies in the middle of "Scrubbing Free RAM". I
have attached a serial output of the boot messages
(es7000_x86_64_nodebug_6065.txt). This could be Bugzilla #147.
Should I be still trying to find the faulting address in the debug case?

> 
> > I tried that patch. The serial output now shows "Platform timer is
> > 1.193MHz PIT" but that does not fix the problem. I am still getting
> > those fatal errors.
> 
> Enable the #if 0'ed code in arch/x86/time.c:local_time_calibration().
> That should get us more diagnostics out.

Please see the attached dell_x86_64_timer.txt file.

Aravindh

Attachment: dell_x86_64_timer.txt
Description: dell_x86_64_timer.txt

Attachment: es7000_x86_64_nodebug_6065.txt
Description: es7000_x86_64_nodebug_6065.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

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