mav at elserv
Jun 8, 2012, 2:11 PM
Post #8 of 9
08.06.2012 15:47, Jan Beulich пишет:
Re: Pv_ops Dom0 crash on IBM eServer x3400
[In reply to]
>>>> On 08.06.12 at 12:19, Alex Moskalenko<mav [at] elserv> wrote:
>> 08.06.2012 11:43, Jan Beulich пишет:
>>>>>> On 07.06.12 at 11:29, Alex Moskalenko<mav [at] elserv> wrote:
>>>> I ran into a trouble when trying to run Xen 4.1.x with pv_ops kernel on
>>>> IBM eServer x3400. Without noacpi command line option dom0 kernel
>>>> crashes on ACPI initialization. Kermels 2.6.32 (with konrad xen
>>>> patches), 3.1, 3.3, Xen 4.1.2 behave the same way. Without hypervisor
>>>> all kernels run without any problems.
>>> This is an issue that was reported and discussed previously.
>>> Fundamentally, it is a firmware problem from my pov: ACPI has
>>> _nothing_ to do with the MMIO space used for the IO-APICs of
>>> the system once they are under control of the OS. It shouldn't
>>> even be reading from them (which iirc was the case in earlier
>>> reports), but in your case it looks like it's even writing them. I
>>> had been considering to allow Dom0 read access to those pages,
>>> but obviously this wouldn't help in your case.
>>> Could you extract and supply the ACPI tables of that system, so
>>> we can make an attempt at checking whether there is some reason
>>> for the firmware writing to the IO-APIC that we didn't think of so
>> Please see attached archive. Tables are grabbed with acpidump -b under
>> Xen 4.1.2 and patched kernel 2.6.32.
> _SB.PCI0._CRS has
> Store (0x2E, IDX)
> And (0xFFFEFFFF, WND, WND)
> OperationRegion (Z00D, SystemMemory, 0xFEC80000, 0x0100)
> Field (Z00D, DWordAcc, Lock, Preserve)
> IDX, 32,
> Offset (0x10),
> WND, 32
> so what the BIOS tries to do is unmask pin 15 of the second
> IO-APIC. To me this makes no sense at all (and is definitely
> impossible to be sync-ed properly with any OSes accesses to
> the IO-APIC registers), but could you nevertheless boot a
> native kernel with "apic=debug" and post the full set of boot
> messages (the dumps of the IO-APICs being what I'm really
> after). Alternatively, "apic_verbosity=debug" passed to Xen
> or sending the 'z' debug key would produce similar information.
Thank you for our answer, Jan!
I attached full dmesg output of kernel 3.3.8.
Also I removed the 'Store' and 'And' statements from DSDT and compiled
it. When altered DSDT is loaded with grub, kernel 3.3.8 boots
successfully (good!). But with hypervisor boot process hangs at loading
aacraid module (last message is about setting up IRQ). Aacraid module
loads without any problem on bare hardware. Kernel 2.6.32 boots
successfully and loads all modules. I think this issue is not related to
patched DSDT, but I'm not sure.
WBR, Alex Moskalenko