From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>,
"xen.org" <Ian.Jackson@eu.citrix.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [linux-next test] 36692: regressions - FAIL
Date: Wed, 25 Mar 2015 09:33:15 -0400 [thread overview]
Message-ID: <5512B91B.90306@oracle.com> (raw)
In-Reply-To: <1427274980.10784.12.camel@citrix.com>
On 03/25/2015 05:16 AM, Ian Campbell wrote:
> On Wed, 2015-03-25 at 04:54 +0000, xen.org wrote:
>> flight 36692 linux-next real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/36692/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test-amd64-i386-xl 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-xl-win7-amd64 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-xl-qemut-debianhvm-amd64 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-xl-qemut-win7-amd64 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-freebsd10-amd64 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-qemut-rhel6hvm-intel 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-xl-qemuu-debianhvm-amd64 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-xl-qemut-winxpsp3 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-qemuu-rhel6hvm-intel 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-xl-winxpsp3 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-qemuu-rhel6hvm-amd 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-xl-qemuu-ovmf-amd64 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-xl-qemuu-winxpsp3 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-rumpuserxen-i386 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-xl-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-rhel6hvm-intel 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-freebsd10-i386 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-qemut-rhel6hvm-amd 5 xen-boot fail REGR. vs. 36569
>> test-amd64-i386-pair 8 xen-boot/dst_host fail REGR. vs. 36569
>> test-amd64-i386-pair 7 xen-boot/src_host fail REGR. vs. 36569
> Looks like there is a regression for 32-bit dom0?
Yes, I was able to reproduce it (we typically don't test linux-next here
which is why I didn't see it).
64-bit looks OK though, I don't see problems that you reported in the
other message.
-boris
>
> The three logs I looked at stopped after:
> Mar 24 14:28:10.658757 [ 5.705317] random: nonblocking pool is initialized
>
> One of them had something more interesting though,right after the
> non-blocking pool
> http://www.chiark.greenend.org.uk/~xensrcts/logs/36692/test-amd64-i386-rhel6hvm-amd/serial-lace-bug.log:
>
> Mar 24 15:57:13.494608 [ 24.445372] INFO: rcu_sched detected stalls on CPUs/tasks:
> Mar 24 15:57:32.510635 [ 24.445389] (detected by 0, t=21002 jiffies, g=-282, c=-283, q=36)
> Mar 24 15:57:32.522591 [ 24.445397] All QSes seen, last rcu_sched kthread activity 21002 (-278938--299940), jiffies_till_next_fqs=3, root ->qsmask 0x0
> Mar 24 15:57:32.530599 [ 24.445405] migration/0 R running 0 9 2 0x00000000
> Mar 24 15:57:32.530635 [ 24.445411] db4bb000 db4bb000 db4e1cb4 c10cbac4 c188e078 00000000 00000009 00000002
> Mar 24 15:57:32.542606 [ 24.445422] 00000000 c19649c0 c19649c0 db4e1d00 c10f5bdf c18890d4 c1964c40 0000520a
> Mar 24 15:57:32.550610 [ 24.445433] fffbbe66 fffb6c5c 00000003 00000000 c19600c0 c19649c0 00000024 00000000
> Mar 24 15:57:32.562630 [ 24.445444] Call Trace:
> Mar 24 15:57:32.562665 [ 24.445451] [<c10cbac4>] sched_show_task+0xb4/0x130
> Mar 24 15:57:32.570629 [ 24.445457] [<c10f5bdf>] rcu_check_callbacks+0x63f/0x650
> Mar 24 15:57:32.570675 [ 24.445463] [<c10fa26a>] update_process_times+0x2a/0x60
> Mar 24 15:57:32.582594 [ 24.445469] [<c11084f5>] tick_periodic+0x25/0x90
> Mar 24 15:57:32.582630 [ 24.445510] [<c11086ef>] tick_handle_periodic+0x1f/0x70
> Mar 24 15:57:32.590594 [ 24.445516] [<c1055904>] xen_timer_interrupt+0x24/0x1e0
> Mar 24 15:57:32.590629 [ 24.445522] [<c1390498>] ? add_interrupt_randomness+0x38/0x1b0
> Mar 24 15:57:32.602594 [ 24.445528] [<c10ec544>] handle_irq_event_percpu+0x54/0x1d0
> Mar 24 15:57:32.602667 [ 24.445534] [<c10ebcef>] ? irq_to_desc+0xf/0x20
> Mar 24 15:57:32.610603 [ 24.445539] [<c10ee968>] ? irq_get_irq_data+0x8/0x10
> Mar 24 15:57:32.610639 [ 24.445544] [<c13532a3>] ? evtchn_from_irq+0x13/0x50
> Mar 24 15:57:32.622602 [ 24.445550] [<c10ef3f3>] handle_percpu_irq+0x33/0x50
> Mar 24 15:57:32.622640 [ 24.445555] [<c10ebd78>] generic_handle_irq+0x18/0x30
> Mar 24 15:57:32.630604 [ 24.445561] [<c13555c1>] evtchn_fifo_handle_events+0x111/0x120
> Mar 24 15:57:32.642584 [ 24.445567] [<c1352bcc>] __xen_evtchn_do_upcall+0x3c/0x80
> Mar 24 15:57:32.642620 [ 24.445572] [<c13546a2>] xen_evtchn_do_upcall+0x22/0x40
> Mar 24 15:57:32.650597 [ 24.445577] [<c1722abb>] xen_do_upcall+0x7/0x14
> Mar 24 15:57:32.650632 [ 24.445584] [<c11208bf>] ? multi_cpu_stop+0x5f/0x100
> Mar 24 15:57:32.662585 [ 24.445589] [<c1120860>] ? cpu_stopper_thread+0x150/0x150
> Mar 24 15:57:32.662622 [ 24.445595] [<c112077e>] cpu_stopper_thread+0x6e/0x150
> Mar 24 15:57:32.670617 [ 24.445600] [<c105089b>] ? xen_load_sp0+0xab/0x140
> Mar 24 15:57:32.670657 [ 24.445606] [<c105d5a3>] ? __switch_to+0x183/0x4e0
> Mar 24 15:57:32.682589 [ 24.445611] [<c10c8236>] ? finish_task_switch+0x66/0x140
> Mar 24 15:57:32.682626 [ 24.445617] [<c171e095>] ? __schedule+0x375/0x8c5
> Mar 24 15:57:32.690620 [ 24.445622] [<c171e095>] ? __schedule+0x375/0x8c5
> Mar 24 15:57:32.690658 [ 24.445628] [<c1721942>] ? _raw_spin_lock_irqsave+0x32/0xa0
> Mar 24 15:57:32.702647 [ 24.445634] [<c1721798>] ? _raw_spin_unlock_irqrestore+0x28/0x70
> Mar 24 15:57:32.702688 [ 24.445641] [<c10c43fb>] smpboot_thread_fn+0xeb/0x130
> Mar 24 15:57:32.710646 [ 24.445647] [<c10c4310>] ? sort_range+0x30/0x30
> Mar 24 15:57:32.710695 [ 24.445652] [<c10c1506>] kthread+0x96/0xb0
> Mar 24 15:57:32.722649 [ 24.445656] [<c1721e81>] ret_from_kernel_thread+0x21/0x30
> Mar 24 15:57:32.722695 [ 24.445662] [<c10c1470>] ? kthread_create_on_node+0x110/0x110
> Mar 24 15:57:32.730640 [ 24.445667] rcu_sched kthread starved for 21002 jiffies!
>
>
>
next prev parent reply other threads:[~2015-03-25 13:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-25 4:54 [linux-next test] 36692: regressions - FAIL xen.org
2015-03-25 9:16 ` Ian Campbell
2015-03-25 13:33 ` Boris Ostrovsky [this message]
2015-03-25 9:22 ` Ian Campbell
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=5512B91B.90306@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=david.vrabel@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=konrad.wilk@oracle.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.