Re: [Xen-devel] [linux-linus test] 17376: regressions - FAIL

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 22/03/13 20:17, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 22, 2013 at 07:23:48PM +0000, xen.org wrote:
>> flight 17376 linux-linus real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/17376/
>>
>> Regressions :-(
> So.. looking at it:
>
>
> [  260.914218] CE: Reprogramming failure. Giving up
> [  260.914218] CE: Reprogramming failure. Giving up
> [  260.914218] PM: noirq restore of devices complete after 0.025 msecs
> [  260.914218] PM: early restore of devices complete after 0.009 msecs
> [  261.033132] PM: restore of devices complete after 98.510 msecs
> [  261.033187] CE: Reprogramming failure. Giving up
> [  261.056750] Setting capacity to 8388608
> [  261.069104] Setting capacity to 2048000
>
> INIT: Switching to runlevel: 0
>
> INIT: Sending processes the TERM signal
>
> [  523.220878]
> vcpu 0
>   0: masked=0 pending=0 event_sel 00000000
>
> pending:
>
> ...
> and
> http://www.chiark.greenend.org.uk/~xensrcts/logs/17376/test-amd64-i386-xl/bush-cricket-output-%23usr%23lib%23xen%23bin%23xenctx_15_0
> tells us that it is stuck at
>   <c10023a7>]  <--
>   [<c1051002>]
>   [<c18e5fd0>]
>   [<c7013000>]
>   [<c1050ff0>]
>   [<c1883f04>]
>   [<c1061c44>]
>   [<c18e5fd0>]
>   [<c7013000>]
>   [<c189a158>]
>   [<c1883f10>]
>   [<c1061506>]
>   [<c19353c0>]
>   [<c1883f18>]
>   [<c167a258>]
>   [<c1883f38>]
>   [<c18edbc9>]
>   [<ffffffff>]
>   [<ffffffff>]
>   [<c18ed6e3>]
>   [<c19353c0>]
>   [<c1883f44>]
>   [<c18ed369>]
>   [<c189a158>]
>   [<c1883ffc>]
>   [<c18f0e88>]
>   [<c1883fe8>]
>   [<c7013000>]
>
> Any chance of making xenctx use the System.map of the guest?

>From the log:

cs:eip: 0061:c10023a7 
flags: 00001246 i z p
ss:esp: 0069:c1883ee0
eax: 00000000   ebx: deadbeef   ecx: deadbeef   edx: 00000000
esi: c7013000   edi: c1050ff0   ebp: c1883ef0
 ds:     007b    es:     007b    fs:     00d8    gs:     0000
Code (instr addr c10023a7)
cc cc cc cc cc cc cc cc cc cc cc cc cc cc b8 1d 00 00 00 cd 82 <c3> cc cc cc cc 
cc cc cc cc cc cc 


Stack:
 c1051002 c18e5fd0 c7013000 c1050ff0 c1883f04 c1061c44 c18e5fd0 c7013000
 c189a158 c1883f10 c1061506 c19353c0 c1883f18 c167a258 c1883f38 c18edbc9
 00000163 ffffffff ffffffff c18ed6e3 c19353c0 01c8f000 c1883f44 c18ed369
 c189a158 c1883ffc c18f0e88 c1883fe8 00000000 00000000 00000000 00000000

Call Trace:
  [<c10023a7>]  <--


With my work on the xen-crashdump-analyser, I have come across a few
instances like this.

Call trace is in a SCHEDOP_yield hypercall

~Andrew


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