Re: [Xen-devel] Re: [Xen-ia64-devel] [PATCH 0/3] IA64: add cpufreq support
On Thu, Oct 09, 2008 at 11:37:23AM +0800, Yu, Ke wrote: Oh, looks like the BIOS is broken. From the _PSS object , only the P0 state is valid, other two P states P1 and P2 are all zeros. This is not correct. Can you try another machine? Not only DSDT, but also MADE was broken, I confirmed that xenpm worked by patching those tables. That's okay. Is it assumed that the dom0 acpi layer sees real tables so that it understands all physical cpus? The assumption isn't true on xen/ia64. Xen/ia64 modifies MADT to tell dom0 how many vcpu are assigned to dom0. Please see acpi_update_lsapic() in xen/arch/ia64/xen/dom_fw_dom0.c Something needs to be done. thanks, -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-devel] Re: [Xen-ia64-devel] [PATCH 0/3] IA64: add cpufreq support
Isaku Yamahata wrote: On Thu, Oct 09, 2008 at 11:37:23AM +0800, Yu, Ke wrote: Oh, looks like the BIOS is broken. From the _PSS object , only the P0 state is valid, other two P states P1 and P2 are all zeros. This is not correct. Can you try another machine? Not only DSDT, but also MADE was broken, I confirmed that xenpm worked by patching those tables. That's okay. Is it assumed that the dom0 acpi layer sees real tables so that it understands all physical cpus? The assumption isn't true on xen/ia64. Xen/ia64 modifies MADT to tell dom0 how many vcpu are assigned to dom0. Please see acpi_update_lsapic() in xen/arch/ia64/xen/dom_fw_dom0.c Something needs to be done. thanks, Right, we already take this into consideration at the design phase. Fortunately, Only the DSDT is needed for Px state, which is unmodifed, so that is Ok for Px support. And for the acpi id to apic id maping, we dedicatedly parse the MADT before the acpi_update_lsapic, so the maping is also correct. Best Regards Ke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-devel] Re: [Xen-ia64-devel] [PATCH 0/3] IA64: add cpufreq support
On Thu, Oct 09, 2008 at 05:26:04PM +0800, Yu, Ke wrote: Isaku Yamahata wrote: On Thu, Oct 09, 2008 at 11:37:23AM +0800, Yu, Ke wrote: Oh, looks like the BIOS is broken. From the _PSS object , only the P0 state is valid, other two P states P1 and P2 are all zeros. This is not correct. Can you try another machine? Not only DSDT, but also MADE was broken, I confirmed that xenpm worked by patching those tables. That's okay. Is it assumed that the dom0 acpi layer sees real tables so that it understands all physical cpus? The assumption isn't true on xen/ia64. Xen/ia64 modifies MADT to tell dom0 how many vcpu are assigned to dom0. Please see acpi_update_lsapic() in xen/arch/ia64/xen/dom_fw_dom0.c Something needs to be done. thanks, Right, we already take this into consideration at the design phase. Fortunately, Only the DSDT is needed for Px state, which is unmodifed, so that is Ok for Px support. And for the acpi id to apic id maping, we dedicatedly parse the MADT before the acpi_update_lsapic, so the maping is also correct. Great. I confirmed it myself. I applied all your 3 patches. thanks, -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-devel] Re: [Xen-ia64-devel] [PATCH 0/3] IA64: add cpufreq support
Hi Isaku, Thanks for tesing. Please see my comments below. Isaku Yamahata wrote: Hi Yu. I tested it and have some comments. - When I run xenpm, xen panics It panics at 0xf4000406ba91 = xen-unstable.hg/xen/drivers/acpi/pmstat.c:98 (addr2line told) It looks like pxpt-u.pt[pxpt-u.cur] wasn't allocated yet resulting in NULL pointer reference. As Guanquan replied, this is a separate issue of xenpm logic, he will post another patch to fix this issue. - From the boot message, ondemand governor fails to load. I'm not sure this error is expected because of my hardware. I guess this error case haven't been tested and that it caused the above panic. From the boot message, the BIOS _PSS information is totally messed up. E.g. 1048575us latency is wrong which cause ondemand driver fail to load, also 1048575MHz freq is obviously not correct. There are several possible reasons of this: - BIOS itself is not correct - Dom0 ACPICA parsing logic is not correct. If the native linux (e.g RHEL5) works, then I tend to believe this is dut to the second reason. The dom0 kernel is bit old and bunch of ACPICA fixes in mainline kernel are not included in dom0. In my case, I also find the _PSS parsing result in my Hitachi itanium 2 box is not correct. This issue is fixed after I pulling two patch from mainline kernel (changeset 677 and 678 in http://xenbits.xensource.com/linux-2.6.18-xen.hg) Anyway, this is a separate issue. we will try to find other ia64 box to see if this issue can be reproduced and then fixed. BTW, is it possible to check in these patch first? Best Regards Ke - I added work around to avoid the above panic, but xenpm needs the following patch to get the following result. NOTE: hyperthreading is enabled. --- panic log (XEN) *** xen_handle_domain_access: exception table lookup failed, iip=0xf4000406ba90, addr=0x8, spinning... (XEN) $ PANIC in domain 0 (k6=0xf002f648): *** xen_handle_domain_access: exception table lookup failed, iip=0xf4000406ba90, addr=0x8, spinning... (XEN) d 0xf7fec100 domid 0 (XEN) vcpu 0xf002f648 vcpu 1 (XEN) (XEN) CPU 1 (XEN) psr : 121008226038 ifs : 8691 ip : [f4000406ba91] (XEN) ip is at do_get_pm_info+0x331/0x540 (XEN) unat: pfs : 0691 rsc : 0003 (XEN) rnat: bsps: pr : 0555aa99 (XEN) ldrs: ccv : fpsr: 0009804c0270033f (XEN) csd : ssd : (XEN) b0 : f4000406ba30 b6 : f40004049cf0 b7 : f40004002e30 (XEN) f6 : 1003e00037c21a350d836 f7 : 1003e000281be72cb (XEN) f8 : 0 f9 : 0 (XEN) f10 : 0 f11 : 0 (XEN) r1 : f400043e7df0 r2 : f002f6487d20 r3 : f002dce13cc1 (XEN) r8 : 0032595ac662 r9 : 0003 r10 : (XEN) r11 : 05550559 r12 : f002f6487d20 r13 : f002f648 (XEN) r14 : 0003 r15 : 0008 r16 : 0032595ac662 (XEN) r17 : r18 : f4163430 r19 : f4163898 (XEN) r20 : f4163888 r21 : f002f6487d98 r22 : 60004060 (XEN) r23 : 20043098 r24 : 001c0600 r25 : 0003 (XEN) r26 : a00100ab2ab8 r27 : r28 : (XEN) r29 : 0004 r30 : r31 : f40004190268 (XEN) (XEN) Call Trace: (XEN) [f400040eb400] show_stack+0x90/0xb0 (XEN) sp=f002f64877d0 bsp=f002f6481980 (XEN) [f400040ebec0] show_registers+0xaa0/0xac0 (XEN) sp=f002f64879a0 bsp=f002f6481940 (XEN) [f400040b1b60] panic_domain+0x120/0x170 (XEN) sp=f002f64879a0 bsp=f002f64818d0 (XEN) [f400040a2930] ia64_do_page_fault+0x710/0x720 (XEN) sp=f002f6487ae0 bsp=f002f6481838 (XEN) [f400040e28c0] ia64_leave_kernel+0x0/0x300 (XEN) sp=f002f6487b20 bsp=f002f6481838 (XEN) [f4000406ba90] do_get_pm_info+0x330/0x540 (XEN) sp=f002f6487d20 bsp=f002f64817a8 (XEN) [f40004049d00] do_sysctl+0x810/0x840 (XEN) sp=f002f6487d20 bsp=f002f6481730 (XEN) [f40004002e60] fast_hypercall+0x170/0x310 (XEN) sp=f002f6487e00 bsp=f002f6481730 --- cited from boot log (XEN) Set CPU acpi_id(3) cpuid(1) Px State info: (XEN) _PSS: (XEN) State0: 1048575MHz 1048575mW 1048575us 1048575us 0xf 0xf (XEN) State1: 1048575MHz 1048575mW 1048575us 1048575us 0xf 0xf (XEN) State2: 1048575MHz 1048575mW 1048575us 1048575us 0xf 0xf (XEN) _PSD: num_entries=5 rev=0 domain=3 coord_type=252 num_processors=1 (XEN) Current freq of CPU 1 is 1048575000 (XEN) CPU 1 initialization completed (XEN) ondemand governor failed to load due to too long transition latency latency 0x1048575000 limit 0x1000 (XEN) Set CPU acpi_id(11) cpuid(5) Px State info:
Re: [Xen-devel] Re: [Xen-ia64-devel] [PATCH 0/3] IA64: add cpufreq support
On Thu, Oct 09, 2008 at 10:34:00AM +0800, Yu, Ke wrote: Hi Isaku, Thanks for tesing. Please see my comments below. Isaku Yamahata wrote: Hi Yu. I tested it and have some comments. - When I run xenpm, xen panics It panics at 0xf4000406ba91 = xen-unstable.hg/xen/drivers/acpi/pmstat.c:98 (addr2line told) It looks like pxpt-u.pt[pxpt-u.cur] wasn't allocated yet resulting in NULL pointer reference. As Guanquan replied, this is a separate issue of xenpm logic, he will post another patch to fix this issue. Great. - From the boot message, ondemand governor fails to load. I'm not sure this error is expected because of my hardware. I guess this error case haven't been tested and that it caused the above panic. From the boot message, the BIOS _PSS information is totally messed up. E.g. 1048575us latency is wrong which cause ondemand driver fail to load, also 1048575MHz freq is obviously not correct. There are several possible reasons of this: - BIOS itself is not correct - Dom0 ACPICA parsing logic is not correct. If the native linux (e.g RHEL5) works, then I tend to believe this is dut to the second reason. The dom0 kernel is bit old and bunch of ACPICA fixes in mainline kernel are not included in dom0. In my case, I also find the _PSS parsing result in my Hitachi itanium 2 box is not correct. This issue is fixed after I pulling two patch from mainline kernel (changeset 677 and 678 in http://xenbits.xensource.com/linux-2.6.18-xen.hg) Anyway, this is a separate issue. we will try to find other ia64 box to see if this issue can be reproduced and then fixed. BTW, is it possible to check in these patch first? Yes, I'll try them. I attached DSDT.dsl which I extracted from my tiger4. It seems that wrong acpi cpuid is used. acpi cpu id which was passed should be one of 0x00,0x01,0x04,0x05,0x08,0x09,0x0C,0x0D. But unintended value is used. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-devel] Re: [Xen-ia64-devel] [PATCH 0/3] IA64: add cpufreq support
I forgot to attach the file. Now attached.
I cut off it so that it includes only \_PR becuase it's long.
If you need the full of it, please tell me.
DefinitionBlock (DSDT.aml, DSDT, 1, Intel, SR870BN4, 0x)
{
Name (PMBS, 0x0C00)
Name (PMLN, 0x08)
Name (IOB1, 0x00)
Name (IOL1, 0x00)
Name (APCB, 0xFEC0)
Name (APCL, 0x0001)
Name (PUID, 0x00)
Name (NPSS, 0x01)
Scope (\_PR)
{
Processor (CPU0, 0x00, 0x, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x063B,
0x0001ADB0,
0x,
0x,
0x,
0x0064
},
Package (0x06)
{
0x,
0x,
0x,
0x,
0x,
0x
},
Package (0x06)
{
0x,
0x,
0x,
0x,
0x,
0x
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU1, 0x08, 0x, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x063B,
0x0001ADB0,
0x,
0x,
0x,
0x0064
},
Package (0x06)
{
0x,
0x,
0x,
0x,
0x,
0x
},
Package (0x06)
{
0x,
0x,
0x,
0x,
0x,
0x
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU2, 0x04, 0x, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x063B,
0x0001ADB0,
0x,
0x,
0x,
0x0064
},
Package (0x06)
Re: [Xen-devel] Re: [Xen-ia64-devel] [PATCH 0/3] IA64: add cpufreq support
On Thu, Oct 09, 2008 at 11:54:56AM +0900, Isaku Yamahata wrote: - From the boot message, ondemand governor fails to load. I'm not sure this error is expected because of my hardware. I guess this error case haven't been tested and that it caused the above panic. From the boot message, the BIOS _PSS information is totally messed up. E.g. 1048575us latency is wrong which cause ondemand driver fail to load, also 1048575MHz freq is obviously not correct. There are several possible reasons of this: - BIOS itself is not correct - Dom0 ACPICA parsing logic is not correct. If the native linux (e.g RHEL5) works, then I tend to believe this is dut to the second reason. The dom0 kernel is bit old and bunch of ACPICA fixes in mainline kernel are not included in dom0. In my case, I also find the _PSS parsing result in my Hitachi itanium 2 box is not correct. This issue is fixed after I pulling two patch from mainline kernel (changeset 677 and 678 in http://xenbits.xensource.com/linux-2.6.18-xen.hg) Anyway, this is a separate issue. we will try to find other ia64 box to see if this issue can be reproduced and then fixed. BTW, is it possible to check in these patch first? Yes, I'll try them. I checked the ia64 linux repo. It already includes the changeset as 678:3057b932abea and 677:28419b05401c so that I tested them with those patches. thanks, -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-devel] Re: [Xen-ia64-devel] [PATCH 0/3] IA64: add cpufreq support
Oh, looks like the BIOS is broken. From the _PSS object , only the P0 state is
valid, other two P states P1 and P2 are all zeros. This is not correct.
Can you try another machine?
Best Regards
Ke
Isaku Yamahata wrote:
I forgot to attach the file. Now attached.
I cut off it so that it includes only \_PR becuase it's long.
If you need the full of it, please tell me.
DefinitionBlock (DSDT.aml, DSDT, 1, Intel, SR870BN4,
0x) {
Name (PMBS, 0x0C00)
Name (PMLN, 0x08)
Name (IOB1, 0x00)
Name (IOL1, 0x00)
Name (APCB, 0xFEC0)
Name (APCL, 0x0001)
Name (PUID, 0x00)
Name (NPSS, 0x01)
Scope (\_PR)
{
Processor (CPU0, 0x00, 0x, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x063B,
0x0001ADB0,
0x,
0x,
0x,
0x0064
},
Package (0x06)
{
0x,
0x,
0x,
0x,
0x,
0x
},
Package (0x06)
{
0x,
0x,
0x,
0x,
0x,
0x
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU1, 0x08, 0x, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x063B,
0x0001ADB0,
0x,
0x,
0x,
0x0064
},
Package (0x06)
{
0x,
0x,
0x,
0x,
0x,
0x
},
Package (0x06)
{
0x,
0x,
0x,
0x,
0x,
0x
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU2, 0x04, 0x, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x, // Address
,)
}
})
Name (_PSS, Package
Re: [Xen-devel] Re: [Xen-ia64-devel] [PATCH 0/3] IA64: add cpufreq support
Hi Yu. I tested it and have some comments. - When I run xenpm, xen panics It panics at 0xf4000406ba91 = xen-unstable.hg/xen/drivers/acpi/pmstat.c:98 (addr2line told) It looks like pxpt-u.pt[pxpt-u.cur] wasn't allocated yet resulting in NULL pointer reference. - From the boot message, ondemand governor fails to load. I'm not sure this error is expected because of my hardware. I guess this error case haven't been tested and that it caused the above panic. - I added work around to avoid the above panic, but xenpm needs the following patch to get the following result. NOTE: hyperthreading is enabled. --- panic log (XEN) *** xen_handle_domain_access: exception table lookup failed, iip=0xf4000406ba90, addr=0x8, spinning... (XEN) $ PANIC in domain 0 (k6=0xf002f648): *** xen_handle_domain_access: exception table lookup failed, iip=0xf4000406ba90, addr=0x8, spinning... (XEN) d 0xf7fec100 domid 0 (XEN) vcpu 0xf002f648 vcpu 1 (XEN) (XEN) CPU 1 (XEN) psr : 121008226038 ifs : 8691 ip : [f4000406ba91] (XEN) ip is at do_get_pm_info+0x331/0x540 (XEN) unat: pfs : 0691 rsc : 0003 (XEN) rnat: bsps: pr : 0555aa99 (XEN) ldrs: ccv : fpsr: 0009804c0270033f (XEN) csd : ssd : (XEN) b0 : f4000406ba30 b6 : f40004049cf0 b7 : f40004002e30 (XEN) f6 : 1003e00037c21a350d836 f7 : 1003e000281be72cb (XEN) f8 : 0 f9 : 0 (XEN) f10 : 0 f11 : 0 (XEN) r1 : f400043e7df0 r2 : f002f6487d20 r3 : f002dce13cc1 (XEN) r8 : 0032595ac662 r9 : 0003 r10 : (XEN) r11 : 05550559 r12 : f002f6487d20 r13 : f002f648 (XEN) r14 : 0003 r15 : 0008 r16 : 0032595ac662 (XEN) r17 : r18 : f4163430 r19 : f4163898 (XEN) r20 : f4163888 r21 : f002f6487d98 r22 : 60004060 (XEN) r23 : 20043098 r24 : 001c0600 r25 : 0003 (XEN) r26 : a00100ab2ab8 r27 : r28 : (XEN) r29 : 0004 r30 : r31 : f40004190268 (XEN) (XEN) Call Trace: (XEN) [f400040eb400] show_stack+0x90/0xb0 (XEN) sp=f002f64877d0 bsp=f002f6481980 (XEN) [f400040ebec0] show_registers+0xaa0/0xac0 (XEN) sp=f002f64879a0 bsp=f002f6481940 (XEN) [f400040b1b60] panic_domain+0x120/0x170 (XEN) sp=f002f64879a0 bsp=f002f64818d0 (XEN) [f400040a2930] ia64_do_page_fault+0x710/0x720 (XEN) sp=f002f6487ae0 bsp=f002f6481838 (XEN) [f400040e28c0] ia64_leave_kernel+0x0/0x300 (XEN) sp=f002f6487b20 bsp=f002f6481838 (XEN) [f4000406ba90] do_get_pm_info+0x330/0x540 (XEN) sp=f002f6487d20 bsp=f002f64817a8 (XEN) [f40004049d00] do_sysctl+0x810/0x840 (XEN) sp=f002f6487d20 bsp=f002f6481730 (XEN) [f40004002e60] fast_hypercall+0x170/0x310 (XEN) sp=f002f6487e00 bsp=f002f6481730 --- cited from boot log (XEN) Set CPU acpi_id(3) cpuid(1) Px State info: (XEN) _PSS: (XEN) State0: 1048575MHz 1048575mW 1048575us 1048575us 0xf 0xf (XEN) State1: 1048575MHz 1048575mW 1048575us 1048575us 0xf 0xf (XEN) State2: 1048575MHz 1048575mW 1048575us 1048575us 0xf 0xf (XEN) _PSD: num_entries=5 rev=0 domain=3 coord_type=252 num_processors=1 (XEN) Current freq of CPU 1 is 1048575000 (XEN) CPU 1 initialization completed (XEN) ondemand governor failed to load due to too long transition latency latency 0x1048575000 limit 0x1000 (XEN) Set CPU acpi_id(11) cpuid(5) Px State info: (XEN) _PSS: (XEN) State0: 1048575MHz 1048575mW 1048575us 1048575us 0xf 0xf (XEN) State1: 1048575MHz 1048575mW 1048575us 1048575us 0xf 0xf (XEN) State2: 1048575MHz 1048575mW 1048575us 1048575us 0xf 0xf (XEN) _PSD: num_entries=5 rev=0 domain=11 coord_type=252 num_processors=1 (XEN) Current freq of CPU 5 is 1048575000 (XEN) CPU 5 initialization completed (XEN) ondemand governor failed to load due to too long transition latency latency 0x1048575000 limit 0x1000 (XEN) Set CPU acpi_id(7) cpuid(3) Px State info: (XEN) _PSS: (XEN) State0: 1048575MHz 1048575mW 1048575us 1048575us 0xf 0xf (XEN) State1: 1048575MHz 1048575mW 1048575us 1048575us 0xf 0xf (XEN) State2: 1048575MHz 1048575mW 1048575us 1048575us 0xf 0xf (XEN) _PSD: num_entries=5 rev=0 domain=7 coord_type=252 num_processors=1 (XEN) Current freq of CPU 3 is 1048575000 (XEN) CPU 3 initialization completed (XEN) ondemand
RE: [Xen-devel] Re: [Xen-ia64-devel] [PATCH 0/3] IA64: add cpufreq support
Hi Isaku, I tried your updated patch, and xenpm works in my IPF box. the attached is the xenpm output. From you xenpm output, one possible reason is that the DBS (alias of Px) feature is not enabled in BIOS, thus xen can not get enough Px information to initialize cpufreq driver. You can double confirm by: - check BIOS to see if DBS is enabled. - or try the native linux (e.g. RHEL5), to see if the cpufreq works. Also, it will be helpful if you can attach the xen serial log. please add loglvl=info to elilo xen option, to make sure cpufreq information is printed. Best Regards Ke Isaku Yamahata wrote: Hi, Yu. Thnaks for updating the patches while you're off. I applied your patch with some style fixes and tried xenpm. (I attached the fixed patch. Please confirm I didn't breake them.) Then I got the followings. (NOTE: I added cpufreq=xen to xen boot option) Doesn't xenpm work on ia64? Or is there another way to test them? # xenpm Xen cpuidle is not enabled! failed to get max P-state thanks, On Sat, Sep 27, 2008 at 10:11:29AM +0800, Yu, Ke wrote: This patchset add cpufreq support for ia64 platform. The logic is borrowed from linux kernel and ported to xen. The common cpufreq infrastructure is already in xen and works in x86 side, so this patchset reuse the common infrastructure and add ia64 specific driver and cpufreq notify hypercall. Hypervisor side: 1. px-xen-ipf-driver: add cpufreq ia64 driver 2 .px-xen-ipf-hypercall: implement ia64 cpufreq notify hypercall Dom0 side: 1. px-dom0-add-ia64-hypercall.patch: add ia64 cpufreq notify hypercall Signed-off-by: Liu Jinsong [EMAIL PROTECTED] Yu Ke [EMAIL PROTECTED] BTW, this patchset depends on the xen-unstable tree (http://xenbits.xensource.com/staging/xen-unstable.hg) cset 18550, 18551, 18552, and linux xen tree (http://xenbits.xensource.com/linux-2.6.18-xen.hg) cset 681, which restructure the common cpufreq code for ia64. so ia64 tree need to sync before applying this patchset. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel xenpm.log Description: xenpm.log ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
