Re: Build vmlinuz-2.6.29-rc5-tip

[Jeremy Fitzhardinge <jeremy@goop.org>]

Pasi Kärkkäinen wrote:
> On Tue, Feb 17, 2009 at 10:40:54AM -0800, Jeremy Fitzhardinge wrote:
>   
>> Pasi Kärkkäinen wrote:
>>     
>>> On Tue, Feb 17, 2009 at 05:31:57AM -0800, Boris Derzhavets wrote:
>>>  
>>>       
>>>> Hardware config:-
>>>> C2D E8400, 8 GB RAM, ASUS P5K Premium/WIFI (Intel P35+Intel ICH9R),
>>>> 2x250 SATA Seagate Barracuda (no RAID). Bios settings for ICH9R - AHCI.
>>>> Details here:-
>>>> http://bderzhavets.wordpress.com/2009/02/17/setup-xen-unstable-dom0-via-2629-rc5-pv_ops-enabled-kernel-on-intel-sataahci/
>>>>
>>>>    
>>>>         
>>> Thanks!
>>>
>>> So it seems you're running 64 bit dom0 OS/hypervisor.. 
>>>
>>> 64 bit seems to work better atm than 32 bit.. 
>>>  
>>>       
>> I tend to focus on 64-bit, and Ian Campbell has been looking at 32-bit.  
>> In theory there shouldn't be all that much difference between them.  
>> There have been a few issues, but they're sharing 90+% of the code.  (In 
>> practice I'm interested in any bug reports, esp comparing 32 and 64-bit 
>> behaviour).
>>
>>     
>
> I'm testing 32bit PAE dom0 on 32bit PAE hypervisor. 
>
> Today, with 2.6.29-rc5, I managed to boot my dom0 into login prompt! 
> I haven't been able to get this working earlier.. congratulations!
>
> I had to use 'noapic' dom0 kernel parameter though.. without 'noapic' I'm seeing
> the same IRQ problems with ata_piix than earlier.
>
>
> My dom0 kernel config:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/config-2.6.29-rc5-tip-dom0
>
> My grub.conf:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/grub.conf
>
> Working dom0 bootlog with 'noapic':
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-13-xen331-linux-2.6.29-rc5-noapic.txt
>
> Failing dom0 bootlog (without 'noapic'):
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-12-xen331-linux-2.6.29-rc5.txt
>   

I wonder if this is part of the problem:

ACPI: PM-Timer IO Port: 0x408
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
IOAPIC[0]: Unable to change apic_id!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
IOAPIC[0]: apic_id 255, version 32, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x05] address[0xfec84400] gsi_base[24])
IOAPIC[1]: apic_id 5, version 32, address 0xfec84400, GSI 24-47
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Enabling APIC mode:  Flat.  Using 2 I/O APICs
Using ACPI (MADT) for SMP configuration information


Not really sure what this is about.  Keir?  Jan?   Is this significant?

One of my test machines show this here:

ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 0, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x03] address[0xfec80000] gsi_base[32])
IOAPIC[1]: apic_id 3, version 0, address 0xfec80000, GSI 32-55
ACPI: IOAPIC (id[0x04] address[0xfec83000] gsi_base[64])
IOAPIC[2]: apic_id 4, version 0, address 0xfec83000, GSI 64-87

(It doesn't have ahci, unfortunately, so it doesn't tell us much about 
that.)

    J