* [xen-4.1-testing test] 9805: regressions - FAIL
@ 2011-11-16 22:23 xen.org
2011-11-17 8:32 ` Jan Beulich
0 siblings, 1 reply; 12+ messages in thread
From: xen.org @ 2011-11-16 22:23 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 9805 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9805/
Regressions :-(
Tests which did not succeed and are blocking:
test-i386-i386-pv 5 xen-boot fail REGR. vs. 9756
test-amd64-amd64-xl-sedf 5 xen-boot fail REGR. vs. 9756
test-amd64-amd64-pv 5 xen-boot fail REGR. vs. 9756
test-amd64-i386-xl-multivcpu 5 xen-boot fail REGR. vs. 9756
test-amd64-i386-rhel6hvm-intel 5 xen-boot fail REGR. vs. 9756
test-amd64-i386-pv 5 xen-boot fail REGR. vs. 9756
test-amd64-amd64-xl-pcipt-intel 5 xen-boot fail REGR. vs. 9756
test-i386-i386-xl 5 xen-boot fail REGR. vs. 9756
test-amd64-i386-xl-credit2 5 xen-boot fail REGR. vs. 9756
test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 9756
test-amd64-i386-xl 5 xen-boot fail REGR. vs. 9756
test-amd64-amd64-xl 5 xen-boot fail REGR. vs. 9756
test-amd64-i386-xl-win-vcpus1 5 xen-boot fail REGR. vs. 9756
test-amd64-amd64-win 5 xen-boot fail REGR. vs. 9756
test-i386-i386-xl-win 5 xen-boot fail REGR. vs. 9756
test-amd64-amd64-pair 8 xen-boot/dst_host fail REGR. vs. 9756
test-amd64-amd64-pair 7 xen-boot/src_host fail REGR. vs. 9756
test-i386-i386-pair 7 xen-boot/src_host fail REGR. vs. 9756
test-i386-i386-pair 8 xen-boot/dst_host fail REGR. vs. 9756
test-amd64-i386-pair 8 xen-boot/dst_host fail REGR. vs. 9756
test-amd64-i386-pair 7 xen-boot/src_host fail REGR. vs. 9756
test-amd64-i386-win-vcpus1 5 xen-boot fail REGR. vs. 9756
test-amd64-amd64-xl-win 5 xen-boot fail REGR. vs. 9756
test-amd64-i386-win 5 xen-boot fail REGR. vs. 9756
test-i386-i386-win 5 xen-boot fail REGR. vs. 9756
version targeted for testing:
xen 51f58b210447
baseline version:
xen 9702967e89dd
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Gianluca Guida <gianluca.guida@citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl fail
test-amd64-i386-xl fail
test-i386-i386-xl fail
test-amd64-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 fail
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu fail
test-amd64-amd64-pair fail
test-amd64-i386-pair fail
test-i386-i386-pair fail
test-amd64-amd64-pv fail
test-amd64-i386-pv fail
test-i386-i386-pv fail
test-amd64-amd64-xl-sedf fail
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
changeset: 23186:51f58b210447
tag: tip
user: Jan Beulich <jbeulich@suse.com>
date: Wed Nov 16 16:39:02 2011 +0000
x86-64/test_x86_emulate: fix blowfish test
Incorrect register usage in the _start() wrapper caused the 64-bit
execution emulation to fail.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24149:753b21aa4087
xen-unstable date: Wed Nov 16 15:20:25 2011 +0000
changeset: 23185:efd132eee40c
user: Gianluca Guida <gianluca.guida@citrix.com>
date: Wed Nov 16 16:38:27 2011 +0000
[shadow] Disable higher level pagetables early unshadow only when the "process dying" hypercall is used.
This patch fixes a performance problem in fully virtualized guests.
Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com>
Tested-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24148:3ecc8fef4281
xen-unstable date: Wed Nov 16 15:19:33 2011 +0000
changeset: 23184:4a91cf045893
user: Ian Campbell <ian.campbell@citrix.com>
date: Wed Nov 16 16:37:49 2011 +0000
xen: avoid crash enabling turbo mode
On a system which has not had P-state information pushed down into the
hypervisor running "xenpm enable-turbo-mode" will reliably crash the
host.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 24144:cd3ef25f207a
xen-unstable date: Tue Nov 15 14:24:38 2011 +0100
Committed-by: Keir Fraser <keir@xen.org>
changeset: 23183:98ba0aceaf30
user: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date: Wed Nov 16 16:33:58 2011 +0000
x86: re-inject emulated level pirqs in PV on HVM guests if still asserted
PV on HVM guests can loose level interrupts coming from emulated
devices if they have been remapped onto event channels. The reason is
that we are missing the code to inject a pirq again in the guest when
the guest EOIs it, if it corresponds to an emulated level interrupt
and the interrupt is still asserted.
Fix this issue and also return error when the guest tries to get the
irq_status of a non-existing pirq.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24007:0526644ad2a6
xen-unstable date: Thu Oct 27 16:07:18 2011 +0100
changeset: 23182:9702967e89dd
user: Andrew Cooper <andrew.cooper3@citrix.com>
date: Sat Nov 12 16:14:02 2011 +0000
Revert c/s 23666:b96f8bdcaa15 KEXEC: disconnect all PCI devices from the PCI bus on crash
It turns out that this causes all mannor of problems on certain
motherboards (so far with no pattern I can discern)
Problems include:
* Hanging forever checking hlt instruction.
* Panics when trying to change switch root device
* Drivers hanging when trying to check for interrupts.
From: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 24137:0844b17df7a9
xen-unstable date: Fri Nov 11 18:14:35 2011 +0000
(qemu changes not included)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [xen-4.1-testing test] 9805: regressions - FAIL
2011-11-16 22:23 [xen-4.1-testing test] 9805: regressions - FAIL xen.org
@ 2011-11-17 8:32 ` Jan Beulich
2011-11-17 9:06 ` Keir Fraser
0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2011-11-17 8:32 UTC (permalink / raw)
To: Stefano Stabellini, Keir Fraser; +Cc: xen-devel, ian.jackson
>>> On 16.11.11 at 23:23, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 9805 xen-4.1-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/9805/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking:
> test-i386-i386-pv 5 xen-boot fail REGR. vs. 9756
> test-amd64-amd64-xl-sedf 5 xen-boot fail REGR. vs. 9756
> test-amd64-amd64-pv 5 xen-boot fail REGR. vs. 9756
> test-amd64-i386-xl-multivcpu 5 xen-boot fail REGR. vs. 9756
> test-amd64-i386-rhel6hvm-intel 5 xen-boot fail REGR. vs. 9756
> test-amd64-i386-pv 5 xen-boot fail REGR. vs. 9756
> test-amd64-amd64-xl-pcipt-intel 5 xen-boot fail REGR. vs. 9756
> test-i386-i386-xl 5 xen-boot fail REGR. vs. 9756
> test-amd64-i386-xl-credit2 5 xen-boot fail REGR. vs. 9756
> test-amd64-i386-rhel6hvm-amd 5 xen-boot fail REGR. vs. 9756
> test-amd64-i386-xl 5 xen-boot fail REGR. vs. 9756
> test-amd64-amd64-xl 5 xen-boot fail REGR. vs. 9756
> test-amd64-i386-xl-win-vcpus1 5 xen-boot fail REGR. vs. 9756
> test-amd64-amd64-win 5 xen-boot fail REGR. vs. 9756
> test-i386-i386-xl-win 5 xen-boot fail REGR. vs. 9756
> test-amd64-amd64-pair 8 xen-boot/dst_host fail REGR. vs. 9756
> test-amd64-amd64-pair 7 xen-boot/src_host fail REGR. vs. 9756
> test-i386-i386-pair 7 xen-boot/src_host fail REGR. vs. 9756
> test-i386-i386-pair 8 xen-boot/dst_host fail REGR. vs. 9756
> test-amd64-i386-pair 8 xen-boot/dst_host fail REGR. vs. 9756
> test-amd64-i386-pair 7 xen-boot/src_host fail REGR. vs. 9756
> test-amd64-i386-win-vcpus1 5 xen-boot fail REGR. vs. 9756
> test-amd64-amd64-xl-win 5 xen-boot fail REGR. vs. 9756
> test-amd64-i386-win 5 xen-boot fail REGR. vs. 9756
> test-i386-i386-win 5 xen-boot fail REGR. vs. 9756
This is due to a bad backport of c/s 24007:0526644ad2a6: In -unstable,
evtchn_unmask() must be called with d->event_lock held, while in 4.1
the function acquires the lock (and now gets called with the lock already
held from do_physdev_op()'s case PHYSDEVOP_eoi). The change dates
back to 23573:584c2e5e03d9, which hardly is a candidate for backporting
(but maybe the locking change needs to be pulled out of there).
Jan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [xen-4.1-testing test] 9805: regressions - FAIL
2011-11-17 8:32 ` Jan Beulich
@ 2011-11-17 9:06 ` Keir Fraser
2011-11-17 9:57 ` Stefan Bader
0 siblings, 1 reply; 12+ messages in thread
From: Keir Fraser @ 2011-11-17 9:06 UTC (permalink / raw)
To: Jan Beulich, Stefano Stabellini; +Cc: xen-devel, Ian Jackson
On 17/11/2011 08:32, "Jan Beulich" <JBeulich@suse.com> wrote:
> This is due to a bad backport of c/s 24007:0526644ad2a6: In -unstable,
> evtchn_unmask() must be called with d->event_lock held, while in 4.1
> the function acquires the lock (and now gets called with the lock already
> held from do_physdev_op()'s case PHYSDEVOP_eoi). The change dates
> back to 23573:584c2e5e03d9, which hardly is a candidate for backporting
> (but maybe the locking change needs to be pulled out of there).
Interestingly, Ubuntu's 4.1 fix has exactly the same problem.
I'll revert the patch until someone has time to actually implement and test
a working patch against our vanilla 4.1-testing tree.
-- Keir
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [xen-4.1-testing test] 9805: regressions - FAIL
2011-11-17 9:06 ` Keir Fraser
@ 2011-11-17 9:57 ` Stefan Bader
2011-11-17 10:13 ` Keir Fraser
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Bader @ 2011-11-17 9:57 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, Ian Jackson, Jan Beulich, Stefano Stabellini
On 17.11.2011 10:06, Keir Fraser wrote:
> On 17/11/2011 08:32, "Jan Beulich" <JBeulich@suse.com> wrote:
>
>> This is due to a bad backport of c/s 24007:0526644ad2a6: In -unstable,
>> evtchn_unmask() must be called with d->event_lock held, while in 4.1
>> the function acquires the lock (and now gets called with the lock already
>> held from do_physdev_op()'s case PHYSDEVOP_eoi). The change dates
>> back to 23573:584c2e5e03d9, which hardly is a candidate for backporting
>> (but maybe the locking change needs to be pulled out of there).
>
> Interestingly, Ubuntu's 4.1 fix has exactly the same problem.
>
Hm, yes we should. I am pretty sure I hit that code path often enough, Wonder
why I never saw any dead lock there...
--Stefan
> I'll revert the patch until someone has time to actually implement and test
> a working patch against our vanilla 4.1-testing tree.
>
> -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [xen-4.1-testing test] 9805: regressions - FAIL
2011-11-17 9:57 ` Stefan Bader
@ 2011-11-17 10:13 ` Keir Fraser
2011-11-17 10:28 ` Stefan Bader
0 siblings, 1 reply; 12+ messages in thread
From: Keir Fraser @ 2011-11-17 10:13 UTC (permalink / raw)
To: Stefan Bader; +Cc: xen-devel, Ian Jackson, Jan Beulich, Stefano Stabellini
On 17/11/2011 09:57, "Stefan Bader" <stefan.bader@canonical.com> wrote:
>>> This is due to a bad backport of c/s 24007:0526644ad2a6: In -unstable,
>>> evtchn_unmask() must be called with d->event_lock held, while in 4.1
>>> the function acquires the lock (and now gets called with the lock already
>>> held from do_physdev_op()'s case PHYSDEVOP_eoi). The change dates
>>> back to 23573:584c2e5e03d9, which hardly is a candidate for backporting
>>> (but maybe the locking change needs to be pulled out of there).
>>
>> Interestingly, Ubuntu's 4.1 fix has exactly the same problem.
>>
>
> Hm, yes we should. I am pretty sure I hit that code path often enough, Wonder
> why I never saw any dead lock there...
Perhaps your dom0 kernel doesn't register a pirq_eoi_map.
-- Keir
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [xen-4.1-testing test] 9805: regressions - FAIL
2011-11-17 10:13 ` Keir Fraser
@ 2011-11-17 10:28 ` Stefan Bader
2011-11-17 10:32 ` Stefano Stabellini
2011-11-17 10:37 ` Keir Fraser
0 siblings, 2 replies; 12+ messages in thread
From: Stefan Bader @ 2011-11-17 10:28 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, Ian Jackson, Jan Beulich, Stefano Stabellini
On 17.11.2011 11:13, Keir Fraser wrote:
> On 17/11/2011 09:57, "Stefan Bader" <stefan.bader@canonical.com> wrote:
>
>>>> This is due to a bad backport of c/s 24007:0526644ad2a6: In -unstable,
>>>> evtchn_unmask() must be called with d->event_lock held, while in 4.1
>>>> the function acquires the lock (and now gets called with the lock already
>>>> held from do_physdev_op()'s case PHYSDEVOP_eoi). The change dates
>>>> back to 23573:584c2e5e03d9, which hardly is a candidate for backporting
>>>> (but maybe the locking change needs to be pulled out of there).
>>>
>>> Interestingly, Ubuntu's 4.1 fix has exactly the same problem.
>>>
>>
>> Hm, yes we should. I am pretty sure I hit that code path often enough, Wonder
>> why I never saw any dead lock there...
>
> Perhaps your dom0 kernel doesn't register a pirq_eoi_map.
>
Would be the only explanation. And quite possible. Heck, I would need to know
what that is used for anyway. :/ The kernel is 3.0 based the interrupt I was
looking at just was a normal apic emulated through events one...
-Stefan
> -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [xen-4.1-testing test] 9805: regressions - FAIL
2011-11-17 10:28 ` Stefan Bader
@ 2011-11-17 10:32 ` Stefano Stabellini
2011-11-17 10:37 ` Keir Fraser
1 sibling, 0 replies; 12+ messages in thread
From: Stefano Stabellini @ 2011-11-17 10:32 UTC (permalink / raw)
To: Stefan Bader
Cc: xen-devel@lists.xensource.com, Keir (Xen.org), Stefano Stabellini,
Ian Jackson, Jan, Beulich
On Thu, 17 Nov 2011, Stefan Bader wrote:
> On 17.11.2011 11:13, Keir Fraser wrote:
> > On 17/11/2011 09:57, "Stefan Bader" <stefan.bader@canonical.com> wrote:
> >
> >>>> This is due to a bad backport of c/s 24007:0526644ad2a6: In -unstable,
> >>>> evtchn_unmask() must be called with d->event_lock held, while in 4.1
> >>>> the function acquires the lock (and now gets called with the lock already
> >>>> held from do_physdev_op()'s case PHYSDEVOP_eoi). The change dates
> >>>> back to 23573:584c2e5e03d9, which hardly is a candidate for backporting
> >>>> (but maybe the locking change needs to be pulled out of there).
> >>>
> >>> Interestingly, Ubuntu's 4.1 fix has exactly the same problem.
> >>>
> >>
> >> Hm, yes we should. I am pretty sure I hit that code path often enough, Wonder
> >> why I never saw any dead lock there...
> >
> > Perhaps your dom0 kernel doesn't register a pirq_eoi_map.
> >
> Would be the only explanation. And quite possible. Heck, I would need to know
> what that is used for anyway. :/ The kernel is 3.0 based the interrupt I was
> looking at just was a normal apic emulated through events one...
Same here, I don't have any dom0 kernels that support it.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [xen-4.1-testing test] 9805: regressions - FAIL
2011-11-17 10:28 ` Stefan Bader
2011-11-17 10:32 ` Stefano Stabellini
@ 2011-11-17 10:37 ` Keir Fraser
2011-11-17 10:43 ` Stefano Stabellini
` (2 more replies)
1 sibling, 3 replies; 12+ messages in thread
From: Keir Fraser @ 2011-11-17 10:37 UTC (permalink / raw)
To: Stefan Bader; +Cc: xen-devel, Ian Jackson, Jan Beulich, Stefano Stabellini
On 17/11/2011 10:28, "Stefan Bader" <stefan.bader@canonical.com> wrote:
>>> Hm, yes we should. I am pretty sure I hit that code path often enough,
>>> Wonder
>>> why I never saw any dead lock there...
>>
>> Perhaps your dom0 kernel doesn't register a pirq_eoi_map.
>>
> Would be the only explanation. And quite possible. Heck, I would need to know
> what that is used for anyway. :/ The kernel is 3.0 based the interrupt I was
> looking at just was a normal apic emulated through events one...
Our automated tests still use 2.6.32. It wouldn't surprise me if upstream
Linux 3 doesn't have the pirq_eoi_map stuff; it's an optimisation rather
than core absolutely-required functionality.
It's the dom0 PV kernel that matters in this case by the way, not the kernel
that you are running in HVM mode as a domU.
-- Keir
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [xen-4.1-testing test] 9805: regressions - FAIL
2011-11-17 10:37 ` Keir Fraser
@ 2011-11-17 10:43 ` Stefano Stabellini
2011-11-17 11:32 ` Sander Eikelenboom
2011-11-17 20:03 ` Pasi Kärkkäinen
2 siblings, 0 replies; 12+ messages in thread
From: Stefano Stabellini @ 2011-11-17 10:43 UTC (permalink / raw)
To: Keir Fraser
Cc: xen-devel@lists.xensource.com, Stefano Stabellini, Ian Jackson,
Stefan Bader, Jan, Beulich
On Thu, 17 Nov 2011, Keir Fraser wrote:
> On 17/11/2011 10:28, "Stefan Bader" <stefan.bader@canonical.com> wrote:
>
> >>> Hm, yes we should. I am pretty sure I hit that code path often enough,
> >>> Wonder
> >>> why I never saw any dead lock there...
> >>
> >> Perhaps your dom0 kernel doesn't register a pirq_eoi_map.
> >>
> > Would be the only explanation. And quite possible. Heck, I would need to know
> > what that is used for anyway. :/ The kernel is 3.0 based the interrupt I was
> > looking at just was a normal apic emulated through events one...
>
> Our automated tests still use 2.6.32. It wouldn't surprise me if upstream
> Linux 3 doesn't have the pirq_eoi_map stuff; it's an optimisation rather
> than core absolutely-required functionality.
>
> It's the dom0 PV kernel that matters in this case by the way, not the kernel
> that you are running in HVM mode as a domU.
In any case considering that the PHYSDEVOP_eoi case wasn't protected by
a lock before this patch, we could just add the spinlock around the new
code only, to protect accesses to the pirq_emuirq array.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [xen-4.1-testing test] 9805: regressions - FAIL
2011-11-17 10:37 ` Keir Fraser
2011-11-17 10:43 ` Stefano Stabellini
@ 2011-11-17 11:32 ` Sander Eikelenboom
2011-11-17 12:42 ` Ian Jackson
2011-11-17 20:03 ` Pasi Kärkkäinen
2 siblings, 1 reply; 12+ messages in thread
From: Sander Eikelenboom @ 2011-11-17 11:32 UTC (permalink / raw)
To: Keir Fraser
Cc: xen-devel, Konrad Rzeszutek Wilk, Stefano Stabellini, Ian Jackson,
Stefan Bader, Jan Beulich
Hello Keir,
Thursday, November 17, 2011, 11:37:01 AM, you wrote:
> On 17/11/2011 10:28, "Stefan Bader" <stefan.bader@canonical.com> wrote:
>>>> Hm, yes we should. I am pretty sure I hit that code path often enough,
>>>> Wonder
>>>> why I never saw any dead lock there...
>>>
>>> Perhaps your dom0 kernel doesn't register a pirq_eoi_map.
>>>
>> Would be the only explanation. And quite possible. Heck, I would need to know
>> what that is used for anyway. :/ The kernel is 3.0 based the interrupt I was
>> looking at just was a normal apic emulated through events one...
> Our automated tests still use 2.6.32. It wouldn't surprise me if upstream
> Linux 3 doesn't have the pirq_eoi_map stuff; it's an optimisation rather
> than core absolutely-required functionality.
Don't know how much room (time wise) the machines that do the automated testing have, but additional tests based on latest 3.x and/or konrad's linux-next branch should perhaps be considered ?
Especially since they upstream path is getting more and more feature complete and usable.
--
Sander
> It's the dom0 PV kernel that matters in this case by the way, not the kernel
> that you are running in HVM mode as a domU.
> -- Keir
--
Best regards,
Sander mailto:linux@eikelenboom.it
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [xen-4.1-testing test] 9805: regressions - FAIL
2011-11-17 11:32 ` Sander Eikelenboom
@ 2011-11-17 12:42 ` Ian Jackson
0 siblings, 0 replies; 12+ messages in thread
From: Ian Jackson @ 2011-11-17 12:42 UTC (permalink / raw)
To: Sander Eikelenboom
Cc: xen-devel@lists.xensource.com, Keir (Xen.org), Stabellini,
Konrad Rzeszutek Wilk, Stefan Bader
Sander Eikelenboom writes ("Re: [Xen-devel] [xen-4.1-testing test] 9805: regressions - FAIL"):
> Don't know how much room (time wise) the machines that do the automated testing have, but additional tests based on latest 3.x and/or konrad's linux-next branch should perhaps be considered ?
Yes. This is right at the top of my todo list, except for all the
other things that are even more urgent/important...
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [xen-4.1-testing test] 9805: regressions - FAIL
2011-11-17 10:37 ` Keir Fraser
2011-11-17 10:43 ` Stefano Stabellini
2011-11-17 11:32 ` Sander Eikelenboom
@ 2011-11-17 20:03 ` Pasi Kärkkäinen
2 siblings, 0 replies; 12+ messages in thread
From: Pasi Kärkkäinen @ 2011-11-17 20:03 UTC (permalink / raw)
To: Keir Fraser
Cc: xen-devel, Ian Jackson, Jan Beulich, Stefan Bader,
Stefano Stabellini
On Thu, Nov 17, 2011 at 10:37:01AM +0000, Keir Fraser wrote:
> On 17/11/2011 10:28, "Stefan Bader" <stefan.bader@canonical.com> wrote:
>
> >>> Hm, yes we should. I am pretty sure I hit that code path often enough,
> >>> Wonder
> >>> why I never saw any dead lock there...
> >>
> >> Perhaps your dom0 kernel doesn't register a pirq_eoi_map.
> >>
> > Would be the only explanation. And quite possible. Heck, I would need to know
> > what that is used for anyway. :/ The kernel is 3.0 based the interrupt I was
> > looking at just was a normal apic emulated through events one...
>
> Our automated tests still use 2.6.32. It wouldn't surprise me if upstream
> Linux 3 doesn't have the pirq_eoi_map stuff; it's an optimisation rather
> than core absolutely-required functionality.
>
> It's the dom0 PV kernel that matters in this case by the way, not the kernel
> that you are running in HVM mode as a domU.
>
Yep, I was testing with Linux 3.1 dom0 kernel,
and there this patch worked OK without problems.
-- Pasi
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-11-17 20:03 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-16 22:23 [xen-4.1-testing test] 9805: regressions - FAIL xen.org
2011-11-17 8:32 ` Jan Beulich
2011-11-17 9:06 ` Keir Fraser
2011-11-17 9:57 ` Stefan Bader
2011-11-17 10:13 ` Keir Fraser
2011-11-17 10:28 ` Stefan Bader
2011-11-17 10:32 ` Stefano Stabellini
2011-11-17 10:37 ` Keir Fraser
2011-11-17 10:43 ` Stefano Stabellini
2011-11-17 11:32 ` Sander Eikelenboom
2011-11-17 12:42 ` Ian Jackson
2011-11-17 20:03 ` Pasi Kärkkäinen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).