It seems with the bios option "ACPI APIC" on disabled:
(BTW the description of this bios option is: "Allows you to enable or disable
the ACPI support in the APIC, When enabled the ACPI APIC table pointer is
included in the RSDT pointer list.")
- xen 3.5 tip && 2.6.18.8-xen boots fine
- 2.6.31.6 jeremy's tree (without hypervisor) boots fine
- xen 3.5 tip && 2.6.31.6 jeremy's tree doesn't boot
completely at gives the problems reported.
With the option on enabled, it also boots xen 3.5 tip && 2.6.31.6 fine, but for
what i recall i have seen the same problem occur rarely too.
--
Sander
Friday, November 20, 2009, 11:26:26 PM, you wrote:
> Hello Konrad,
> With the bios option "ACPI APIC" on disabled, the bug comes up with
> - xen-3.5 tip && 2.6.31.6
> - xen-3.5 #20436 && 2.6.31.6
> - xen 3.5 #20365 && 2.6.31.6
> - xen 3.5 #20365 && 2.6.18.8-xen boots fine.
> Anything else i could try or give additional info about ?
> BTW the description of this bios option is:
> "Allows you to enable or disable the ACPI support in the APIC, When enabled
> the ACPI APIC table pointer is included in the RSDT pointer list."
> --
> Sander
> Friday, November 20, 2009, 3:50:20 PM, you wrote:
>> On Fri, Nov 20, 2009 at 12:25:16PM +0100, Sander Eikelenboom wrote:
>>> I occasionally have the same problem (same messages spit out by the kernel
>>> on boot.
>>> System keeps running, but everything is terribly slow it seems (these
>>> messages appear one by one with sometimes several seconds in between)
>>> In the end it can not mount the root filesystem and bails out.
>> This is most curious. Based on your Xen hypervisor logs:
>> ..snip..
>>> (XEN) IRQ: 0, IRQ affinity:0xffffffff, Vec:240 type=IO-APIC-edge
>>> status=
>>> 00000000 mapped, unbound
>>> (XEN) IRQ: 1, IRQ affinity:0x00000001, Vec: 40 type=IO-APIC-edge
>>> status=
>>> 00000006 mapped, unbound
>>> (XEN) IRQ: 2, IRQ affinity:0xffffffff, Vec:226 type=XT-PIC
>>> status=
>>> 00000000 mapped, unbound
>>> (XEN) IRQ: 3, IRQ affinity:0xffffffff, Vec:227 type=XT-PIC
>>> status=
>>> 00000002 mapped, unbound
>>> (XEN) IRQ: 4, IRQ affinity:0xffffffff, Vec:241 type=IO-APIC-edge
>>> status=
>>> 00000000 mapped, unbound
>>> (XEN) IRQ: 5, IRQ affinity:0xffffffff, Vec:229 type=XT-PIC
>>> status=
>>> 00000010 in-flight=0 domain-list=0: 5(----),
>>> (XEN) IRQ: 6, IRQ affinity:0x00000001, Vec: 48 type=IO-APIC-edge
>>> status=
>>> 00000002 mapped, unbound
>>> (XEN) IRQ: 7, IRQ affinity:0xffffffff, Vec:231 type=XT-PIC
>>> status=
>>> 00000010 in-flight=0 domain-list=0: 7(----),
>>> (XEN) IRQ: 8, IRQ affinity:0x00000001, Vec: 56 type=IO-APIC-edge
>>> status=
>>> 00000002 mapped, unbound
>> .. snip..
>> That are not mapped to the Dom0. Meaning that well, ..., they are not being
>> received by
>> Dom0, which definilty is a problem.
>> <side-track>
>> Mr Goswin,
>> Can you try getting the hypervisor output? That can be done by pressing
>> Ctrl-A three
>> times and one of the keys for the IRQ to domains mapping. I am just looking
>> to see
>> if you have the same issue.
>> </side-track>
>> There were some patches (cs/ 20437) that changed the IRQ mapping and I
>> wonder if
>> it inadvertly triggered this failure.
>> Can you revert back before cs 20437 and compile Xen.gz? Here is one way I
>> know
>> of how to do this (there is probably a better one):
>> mkdir ../test
>> cd ../test
>> hg clone ../xen-unstable.hg/ -r20436
>> cd xen-unstable.hg
>> hg tip
>> (and it should show c/s 20436 as the latest).
--
Best regards,
Sander mailto:linux@xxxxxxxxxxxxxx
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home