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 <jinsong.liu@intel.com>
Yu Ke <ke.yu@intel.com>
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
Isaku Yamahata
2008-Oct-02 08:18 UTC
Re: [Xen-ia64-devel] [PATCH 0/3] IA64: add cpufreq support
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 <jinsong.liu@intel.com> > Yu Ke <ke.yu@intel.com> > > 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 >-- yamahata _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Yu, Ke
2008-Oct-03 06:16 UTC
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 <jinsong.liu@intel.com> >> Yu Ke <ke.yu@intel.com> >> >> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Isaku Yamahata
2008-Oct-07 10:28 UTC
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 0xf40000000406ba91 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=0xf40000000406ba90, addr=0x8, spinning...
(XEN) $$$$$ PANIC in domain 0 (k6=0xf0000002f6480000): ***
xen_handle_domain_access: exception table lookup failed, iip=0xf40000000406ba90,
addr=0x8, spinning...
(XEN) d 0xf000000007fec100 domid 0
(XEN) vcpu 0xf0000002f6480000 vcpu 1
(XEN)
(XEN) CPU 1
(XEN) psr : 0000121008226038 ifs : 8000000000000691 ip :
[<f40000000406ba91>]
(XEN) ip is at do_get_pm_info+0x331/0x540
(XEN) unat: 0000000000000000 pfs : 0000000000000691 rsc : 0000000000000003
(XEN) rnat: 0000000000000000 bsps: 0000000000000000 pr : 000000000555aa99
(XEN) ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f
(XEN) csd : 0000000000000000 ssd : 0000000000000000
(XEN) b0 : f40000000406ba30 b6 : f400000004049cf0 b7 : f400000004002e30
(XEN) f6 : 1003e00037c21a350d836 f7 : 1003e0000000281be72cb
(XEN) f8 : 000000000000000000000 f9 : 000000000000000000000
(XEN) f10 : 000000000000000000000 f11 : 000000000000000000000
(XEN) r1 : f4000000043e7df0 r2 : f0000002f6487d20 r3 : f0000002dce13cc1
(XEN) r8 : 00000032595ac662 r9 : 0000000000000003 r10 : 0000000000000000
(XEN) r11 : 0000000005550559 r12 : f0000002f6487d20 r13 : f0000002f6480000
(XEN) r14 : 0000000000000003 r15 : 0000000000000008 r16 : 00000032595ac662
(XEN) r17 : 0000000000000000 r18 : f000000004163430 r19 : f000000004163898
(XEN) r20 : f000000004163888 r21 : f0000002f6487d98 r22 : 6000000000004060
(XEN) r23 : 2000000000043098 r24 : 00000000001c0600 r25 : 0000000000000003
(XEN) r26 : a000000100ab2ab8 r27 : 0000000000000000 r28 : 0000000000000000
(XEN) r29 : 0000000000000004 r30 : 0000000000000000 r31 : f400000004190268
(XEN)
(XEN) Call Trace:
(XEN) [<f4000000040eb400>] show_stack+0x90/0xb0
(XEN) sp=f0000002f64877d0 bsp=f0000002f6481980
(XEN) [<f4000000040ebec0>] show_registers+0xaa0/0xac0
(XEN) sp=f0000002f64879a0 bsp=f0000002f6481940
(XEN) [<f4000000040b1b60>] panic_domain+0x120/0x170
(XEN) sp=f0000002f64879a0 bsp=f0000002f64818d0
(XEN) [<f4000000040a2930>] ia64_do_page_fault+0x710/0x720
(XEN) sp=f0000002f6487ae0 bsp=f0000002f6481838
(XEN) [<f4000000040e28c0>] ia64_leave_kernel+0x0/0x300
(XEN) sp=f0000002f6487b20 bsp=f0000002f6481838
(XEN) [<f40000000406ba90>] do_get_pm_info+0x330/0x540
(XEN) sp=f0000002f6487d20 bsp=f0000002f64817a8
(XEN) [<f400000004049d00>] do_sysctl+0x810/0x840
(XEN) sp=f0000002f6487d20 bsp=f0000002f6481730
(XEN) [<f400000004002e60>] fast_hypercall+0x170/0x310
(XEN) sp=f0000002f6487e00 bsp=f0000002f6481730
---
cited from boot log
(XEN) Set CPU acpi_id(3) cpuid(1) Px State info:
(XEN) _PSS:
(XEN) State0: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff 0xfffff
(XEN) State1: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff 0xfffff
(XEN) State2: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff 0xfffff
(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 0x10000000
(XEN) Set CPU acpi_id(11) cpuid(5) Px State info:
(XEN) _PSS:
(XEN) State0: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff 0xfffff
(XEN) State1: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff 0xfffff
(XEN) State2: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff 0xfffff
(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 0x10000000
(XEN) Set CPU acpi_id(7) cpuid(3) Px State info:
(XEN) _PSS:
(XEN) State0: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff 0xfffff
(XEN) State1: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff 0xfffff
(XEN) State2: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff 0xfffff
(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 governor failed to load due to too long transition latency
latency 0x1048575000 limit 0x10000000
(XEN) Set CPU acpi_id(15) cpuid(7) Px State info:
(XEN) _PSS:
(XEN) State0: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff 0xfffff
(XEN) State1: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff 0xfffff
(XEN) State2: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff 0xfffff
(XEN) _PSD: num_entries=5 rev=0 domain=15 coord_type=252 num_processors=1
(XEN) Current freq of CPU 7 is 1048575000
(XEN) CPU 7 initialization completed
(XEN) ondemand governor failed to load due to too long transition latency
latency 0x1048575000 limit 0x10000000
---
patch to xenpm
diff -r ccb87aa7c243 tools/misc/xenpm.c
--- a/tools/misc/xenpm.c Fri Oct 03 13:12:42 2008 +0900
+++ b/tools/misc/xenpm.c Tue Oct 07 18:54:42 2008 +0900
@@ -85,7 +85,7 @@
else
fprintf(stderr, "failed to get max C-state\n");
- break;
+ continue;
}
cxstat->triggers = malloc(max_cx_num * sizeof(uint64_t));
@@ -108,7 +108,7 @@
fprintf(stderr, "failed to get C-states statistics
information\n");
free(cxstat->triggers);
free(cxstat->residencies);
- break;
+ continue;
}
printf("cpu id : %d\n", i);
@@ -144,7 +144,7 @@
else
fprintf(stderr, "failed to get max P-state\n");
- break;
+ continue;
}
pxstat->trans_pt = malloc(max_px_num * max_px_num *
sizeof(uint64_t));
@@ -161,12 +161,12 @@
break;
}
- ret = xc_pm_get_pxstat(xc_fd, 0, pxstat);
+ ret = xc_pm_get_pxstat(xc_fd, i, pxstat);
if( ret ) {
fprintf(stderr, "failed to get P-states statistics
information\n");
free(pxstat->trans_pt);
free(pxstat->pt);
- break;
+ continue;
}
printf("cpu id : %d\n", i);
---
result of xenpm
# ./xenpm
Xen cpuidle is not enabled!
Xen cpuidle is not enabled!
Xen cpuidle is not enabled!
Xen cpuidle is not enabled!
Xen cpuidle is not enabled!
Xen cpuidle is not enabled!
Xen cpuidle is not enabled!
Xen cpuidle is not enabled!
failed to get max P-state
cpu id : 1
total P-states : 3
usable P-states : 3
current frequency : 1048575 MHz
*P0 : freq [1048575 MHz]
transition [00000000000000000000]
residency [00000000000000004361 ms]
P1 : freq [1048575 MHz]
transition [00000000000000000000]
residency [00000000000000000000 ms]
P2 : freq [1048575 MHz]
transition [00000000000000000000]
residency [00000000000000000000 ms]
failed to get max P-state
cpu id : 3
total P-states : 3
usable P-states : 3
current frequency : 1048575 MHz
*P0 : freq [1048575 MHz]
transition [00000000000000000000]
residency [00000000000000004781 ms]
P1 : freq [1048575 MHz]
transition [00000000000000000000]
residency [00000000000000000000 ms]
P2 : freq [1048575 MHz]
transition [00000000000000000000]
residency [00000000000000000000 ms]
failed to get max P-state
cpu id : 5
total P-states : 3
usable P-states : 3
current frequency : 1048575 MHz
*P0 : freq [1048575 MHz]
transition [00000000000000000000]
residency [00000000000000004507 ms]
P1 : freq [1048575 MHz]
transition [00000000000000000000]
residency [00000000000000000000 ms]
P2 : freq [1048575 MHz]
transition [00000000000000000000]
residency [00000000000000000000 ms]
failed to get max P-state
cpu id : 7
total P-states : 3
usable P-states : 3
current frequency : 1048575 MHz
*P0 : freq [1048575 MHz]
transition [00000000000000000000]
residency [00000000000000005799 ms]
P1 : freq [1048575 MHz]
transition [00000000000000000000]
residency [00000000000000000000 ms]
P2 : freq [1048575 MHz]
transition [00000000000000000000]
residency [00000000000000000000 ms]
On Fri, Oct 03, 2008 at 02:16:54PM +0800, Yu, Ke wrote:> 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 <jinsong.liu@intel.com>
> >> Yu Ke <ke.yu@intel.com>
> >>
> >> 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
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
--
yamahata
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Lu, Guanqun
2008-Oct-08 14:08 UTC
RE: [Xen-devel] Re: [Xen-ia64-devel] [PATCH 0/3] IA64: add cpufreq support
>-----Original Message----- >From: Isaku Yamahata [mailto:yamahata@valinux.co.jp] >Sent: Tuesday, October 07, 2008 6:29 PM >To: Yu, Ke >Cc: xen-devel@lists.xensource.com; >xen-ia64-devel@lists.xensource.com; Lu, Guanqun >Subject: 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 0xf40000000406ba91 > 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. > >[...]>- ret = xc_pm_get_pxstat(xc_fd, 0, pxstat); >+ ret = xc_pm_get_pxstat(xc_fd, i, pxstat);A simple copy leaves bugs behind... Many thanks!> if( ret ) { > fprintf(stderr, "failed to get P-states >statistics information\n"); > free(pxstat->trans_pt); > free(pxstat->pt); >- break; >+ continue;The other changes from ''break'' to ''continue'' seem reasonable for your hyperthreading configuration. But people may get unhappy when he sees lots of the same message.> } > > printf("cpu id : %d\n", i); > > >--- >result of xenpm > ># ./xenpm >Xen cpuidle is not enabled! >Xen cpuidle is not enabled! >Xen cpuidle is not enabled! >Xen cpuidle is not enabled! >Xen cpuidle is not enabled! >Xen cpuidle is not enabled! >Xen cpuidle is not enabled! >Xen cpuidle is not enabled! >failed to get max P-state >cpu id : 1 >total P-states : 3 >usable P-states : 3 >current frequency : 1048575 MHz >*P0 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000004361 ms] >P1 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] >P2 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] > >failed to get max P-state >cpu id : 3 >total P-states : 3 >usable P-states : 3 >current frequency : 1048575 MHz >*P0 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000004781 ms] >P1 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] >P2 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] > >failed to get max P-state >cpu id : 5 >total P-states : 3 >usable P-states : 3 >current frequency : 1048575 MHz >*P0 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000004507 ms] >P1 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] >P2 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] > >failed to get max P-state >cpu id : 7 >total P-states : 3 >usable P-states : 3 >current frequency : 1048575 MHz >*P0 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000005799 ms] >P1 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] >P2 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] > >[...]> >-- >yamahata >-- Guanqun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu, Ke
2008-Oct-09 02:34 UTC
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 0xf40000000406ba91 > 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=0xf40000000406ba90, addr=0x8, spinning... (XEN) $$$$$ PANIC in > domain 0 (k6=0xf0000002f6480000): *** xen_handle_domain_access: > exception table lookup failed, iip=0xf40000000406ba90, addr=0x8, > spinning... (XEN) d 0xf000000007fec100 domid 0 (XEN) vcpu > 0xf0000002f6480000 vcpu 1 (XEN) (XEN) CPU 1 > (XEN) psr : 0000121008226038 ifs : 8000000000000691 ip : > [<f40000000406ba91>] (XEN) ip is at do_get_pm_info+0x331/0x540 > (XEN) unat: 0000000000000000 pfs : 0000000000000691 rsc : > 0000000000000003 (XEN) rnat: 0000000000000000 bsps: 0000000000000000 > pr : 000000000555aa99 (XEN) ldrs: 0000000000000000 ccv : > 0000000000000000 fpsr: 0009804c0270033f (XEN) csd : 0000000000000000 > ssd : 0000000000000000 (XEN) b0 : f40000000406ba30 b6 : > f400000004049cf0 b7 : f400000004002e30 (XEN) f6 : > 1003e00037c21a350d836 f7 : 1003e0000000281be72cb (XEN) f8 : > 000000000000000000000 f9 : 000000000000000000000 (XEN) f10 : > 000000000000000000000 f11 : 000000000000000000000 (XEN) r1 : > f4000000043e7df0 r2 : f0000002f6487d20 r3 : f0000002dce13cc1 (XEN) > r8 : 00000032595ac662 r9 : 0000000000000003 r10 : 0000000000000000 > (XEN) r11 : 0000000005550559 r12 : f0000002f6487d20 r13 : > f0000002f6480000 (XEN) r14 : 0000000000000003 r15 : 0000000000000008 > r16 : 00000032595ac662 (XEN) r17 : 0000000000000000 r18 : > f000000004163430 r19 : f000000004163898 (XEN) r20 : f000000004163888 > r21 : f0000002f6487d98 r22 : 6000000000004060 (XEN) r23 : > 2000000000043098 r24 : 00000000001c0600 r25 : 0000000000000003 (XEN) > r26 : a000000100ab2ab8 r27 : 0000000000000000 r28 : 0000000000000000 > (XEN) r29 : 0000000000000004 r30 : 0000000000000000 r31 : > f400000004190268 (XEN) (XEN) Call Trace: (XEN) [<f4000000040eb400>] > show_stack+0x90/0xb0 (XEN) > sp=f0000002f64877d0 bsp=f0000002f6481980 (XEN) [<f4000000040ebec0>] > show_registers+0xaa0/0xac0 (XEN) > sp=f0000002f64879a0 bsp=f0000002f6481940 (XEN) [<f4000000040b1b60>] > panic_domain+0x120/0x170 (XEN) > sp=f0000002f64879a0 bsp=f0000002f64818d0 (XEN) [<f4000000040a2930>] > ia64_do_page_fault+0x710/0x720 (XEN) > sp=f0000002f6487ae0 bsp=f0000002f6481838 (XEN) [<f4000000040e28c0>] > ia64_leave_kernel+0x0/0x300 (XEN) > sp=f0000002f6487b20 bsp=f0000002f6481838 (XEN) [<f40000000406ba90>] > do_get_pm_info+0x330/0x540 (XEN) > sp=f0000002f6487d20 bsp=f0000002f64817a8 (XEN) [<f400000004049d00>] > do_sysctl+0x810/0x840 (XEN) > sp=f0000002f6487d20 bsp=f0000002f6481730 (XEN) [<f400000004002e60>] > fast_hypercall+0x170/0x310 (XEN) > sp=f0000002f6487e00 bsp=f0000002f6481730 > > > --- > cited from boot log > > (XEN) Set CPU acpi_id(3) cpuid(1) Px State info: > (XEN) _PSS: > (XEN) State0: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff > 0xfffff (XEN) State1: 1048575MHz 1048575mW 1048575us 1048575us > 0xfffff 0xfffff (XEN) State2: 1048575MHz 1048575mW 1048575us > 1048575us 0xfffff 0xfffff (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 0x10000000 (XEN) Set CPU > acpi_id(11) cpuid(5) Px State info: (XEN) _PSS: > (XEN) State0: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff > 0xfffff (XEN) State1: 1048575MHz 1048575mW 1048575us 1048575us > 0xfffff 0xfffff (XEN) State2: 1048575MHz 1048575mW 1048575us > 1048575us 0xfffff 0xfffff (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 0x10000000 (XEN) Set CPU > acpi_id(7) cpuid(3) Px State info: (XEN) _PSS: > (XEN) State0: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff > 0xfffff (XEN) State1: 1048575MHz 1048575mW 1048575us 1048575us > 0xfffff 0xfffff (XEN) State2: 1048575MHz 1048575mW 1048575us > 1048575us 0xfffff 0xfffff (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 governor failed to load due to too long transition > latency latency 0x1048575000 limit 0x10000000 (XEN) Set CPU > acpi_id(15) cpuid(7) Px State info: (XEN) _PSS: > (XEN) State0: 1048575MHz 1048575mW 1048575us 1048575us 0xfffff > 0xfffff (XEN) State1: 1048575MHz 1048575mW 1048575us 1048575us > 0xfffff 0xfffff (XEN) State2: 1048575MHz 1048575mW 1048575us > 1048575us 0xfffff 0xfffff (XEN) _PSD: num_entries=5 rev=0 domain=15 > coord_type=252 num_processors=1 (XEN) Current freq of CPU 7 is > 1048575000 (XEN) CPU 7 initialization completed > (XEN) ondemand governor failed to load due to too long transition > latency latency 0x1048575000 limit 0x10000000 > > > --- > patch to xenpm > > diff -r ccb87aa7c243 tools/misc/xenpm.c > --- a/tools/misc/xenpm.c Fri Oct 03 13:12:42 2008 +0900 > +++ b/tools/misc/xenpm.c Tue Oct 07 18:54:42 2008 +0900 > @@ -85,7 +85,7 @@ > else > fprintf(stderr, "failed to get max C-state\n"); > > - break; > + continue; > } > > cxstat->triggers = malloc(max_cx_num * sizeof(uint64_t)); > @@ -108,7 +108,7 @@ > fprintf(stderr, "failed to get C-states statistics > information\n"); free(cxstat->triggers); > free(cxstat->residencies); > - break; > + continue; > } > > printf("cpu id : %d\n", i); > @@ -144,7 +144,7 @@ > else > fprintf(stderr, "failed to get max P-state\n"); > > - break; > + continue; > } > > pxstat->trans_pt = malloc(max_px_num * max_px_num * > sizeof(uint64_t)); @@ -161,12 +161,12 @@ > break; > } > > - ret = xc_pm_get_pxstat(xc_fd, 0, pxstat); > + ret = xc_pm_get_pxstat(xc_fd, i, pxstat); > if( ret ) { > fprintf(stderr, "failed to get P-states statistics > information\n"); free(pxstat->trans_pt); > free(pxstat->pt); > - break; > + continue; > } > > printf("cpu id : %d\n", i); > > > --- > result of xenpm > > # ./xenpm > Xen cpuidle is not enabled! > Xen cpuidle is not enabled! > Xen cpuidle is not enabled! > Xen cpuidle is not enabled! > Xen cpuidle is not enabled! > Xen cpuidle is not enabled! > Xen cpuidle is not enabled! > Xen cpuidle is not enabled! > failed to get max P-state > cpu id : 1 > total P-states : 3 > usable P-states : 3 > current frequency : 1048575 MHz > *P0 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000004361 ms] > P1 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] > P2 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] > > failed to get max P-state > cpu id : 3 > total P-states : 3 > usable P-states : 3 > current frequency : 1048575 MHz > *P0 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000004781 ms] > P1 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] > P2 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] > > failed to get max P-state > cpu id : 5 > total P-states : 3 > usable P-states : 3 > current frequency : 1048575 MHz > *P0 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000004507 ms] > P1 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] > P2 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] > > failed to get max P-state > cpu id : 7 > total P-states : 3 > usable P-states : 3 > current frequency : 1048575 MHz > *P0 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000005799 ms] > P1 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] > P2 : freq [1048575 MHz] > transition [00000000000000000000] > residency [00000000000000000000 ms] > > > > > On Fri, Oct 03, 2008 at 02:16:54PM +0800, Yu, Ke wrote: >> 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 <jinsong.liu@intel.com> >>>> Yu Ke <ke.yu@intel.com> >>>> >>>> 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 >> > > >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Isaku Yamahata
2008-Oct-09 02:54 UTC
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 0xf40000000406ba91 > > 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-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Isaku Yamahata
2008-Oct-09 02:58 UTC
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", 0x00000000)
{
Name (PMBS, 0x0C00)
Name (PMLN, 0x08)
Name (IOB1, 0x00)
Name (IOL1, 0x00)
Name (APCB, 0xFEC00000)
Name (APCL, 0x00010000)
Name (PUID, 0x00)
Name (NPSS, 0x01)
Scope (\_PR)
{
Processor (CPU0, 0x00, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x0000063B,
0x0001ADB0,
0x00000000,
0x00000000,
0x00000000,
0x00000064
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU1, 0x08, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x0000063B,
0x0001ADB0,
0x00000000,
0x00000000,
0x00000000,
0x00000064
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU2, 0x04, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x0000063B,
0x0001ADB0,
0x00000000,
0x00000000,
0x00000000,
0x00000064
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU3, 0x0C, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x0000063B,
0x0001ADB0,
0x00000000,
0x00000000,
0x00000000,
0x00000064
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU4, 0x01, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x0000063B,
0x0001ADB0,
0x00000000,
0x00000000,
0x00000000,
0x00000064
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU5, 0x09, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x0000063B,
0x0001ADB0,
0x00000000,
0x00000000,
0x00000000,
0x00000064
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU6, 0x05, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x0000063B,
0x0001ADB0,
0x00000000,
0x00000000,
0x00000000,
0x00000064
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU7, 0x0D, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x0000063B,
0x0001ADB0,
0x00000000,
0x00000000,
0x00000000,
0x00000064
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
},
Package (0x06)
{
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU8, 0x02, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPU9, 0x0A, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPUA, 0x06, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPUB, 0x0E, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPUC, 0x03, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPUD, 0x0B, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPUE, 0x07, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
Processor (CPUF, 0x0F, 0x00000000, 0x00)
{
Name (_PCT, Package (0x02)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
},
ResourceTemplate ()
{
Register (FFixedHW,
0x00, // Bit Width
0x00, // Bit Offset
0x0000000000000000, // Address
,)
}
})
Name (_PSS, Package (0x03)
{
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
},
Package (0x06)
{
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF,
0x000FFFFF
}
})
Method (_PPC, 0, NotSerialized)
{
Return (0x00)
}
}
}
...
On Thu, Oct 09, 2008 at 11:54:56AM +0900, Isaku Yamahata
wrote:> 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 0xf40000000406ba91 > > >
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-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Isaku Yamahata
2008-Oct-09 03:04 UTC
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-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu, Ke
2008-Oct-09 03:37 UTC
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", > 0x00000000) { > Name (PMBS, 0x0C00) > Name (PMLN, 0x08) > Name (IOB1, 0x00) > Name (IOL1, 0x00) > Name (APCB, 0xFEC00000) > Name (APCL, 0x00010000) > Name (PUID, 0x00) > Name (NPSS, 0x01) > Scope (\_PR) > { > Processor (CPU0, 0x00, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x0000063B, > 0x0001ADB0, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000064 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPU1, 0x08, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x0000063B, > 0x0001ADB0, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000064 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPU2, 0x04, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x0000063B, > 0x0001ADB0, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000064 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPU3, 0x0C, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x0000063B, > 0x0001ADB0, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000064 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPU4, 0x01, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x0000063B, > 0x0001ADB0, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000064 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPU5, 0x09, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x0000063B, > 0x0001ADB0, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000064 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPU6, 0x05, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x0000063B, > 0x0001ADB0, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000064 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPU7, 0x0D, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x0000063B, > 0x0001ADB0, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000064 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > }, > > Package (0x06) > { > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000, > 0x00000000 > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPU8, 0x02, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPU9, 0x0A, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPUA, 0x06, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPUB, 0x0E, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPUC, 0x03, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPUD, 0x0B, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPUE, 0x07, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > > Processor (CPUF, 0x0F, 0x00000000, 0x00) > { > Name (_PCT, Package (0x02) > { > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > }, > > ResourceTemplate () > { > Register (FFixedHW, > 0x00, // Bit Width > 0x00, // Bit Offset > 0x0000000000000000, // Address > ,) > } > }) > Name (_PSS, Package (0x03) > { > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > }, > > Package (0x06) > { > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF, > 0x000FFFFF > } > }) > Method (_PPC, 0, NotSerialized) > { > Return (0x00) > } > } > } > > ... > > On Thu, Oct 09, 2008 at 11:54:56AM +0900, Isaku Yamahata wrote: >> 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 0xf40000000406ba91 >>>> 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._______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Isaku Yamahata
2008-Oct-09 08:49 UTC
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-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu, Ke
2008-Oct-09 09:26 UTC
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
Isaku Yamahata
2008-Oct-10 02:25 UTC
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