* Re: Collecting hypervisor call stats
From: Christopher Yeoh @ 2006-06-01 5:12 UTC (permalink / raw)
To: Mike Kravetz; +Cc: Chris Yeoh, Bryan Rosenburg, linuxppc-dev
In-Reply-To: <AEFF6654-C958-42F7-93CF-64103B015CB1@watson.ibm.com>
At 2006/6/1 00:34-0400 Jimi Xenidis writes:
> IIRC, chris and bryan have done some work to track this, they may
> have some code to contribute.
> On May 31, 2006, at 4:41 PM, Mike Kravetz wrote:
>
Hi Mike,
Here's a patch we've used for collecting hcall counts and times. I
think I have a perl script lying around somewhere that helps process
the (per cpu) data a bit. I'm not sure where I put it at the moment,
but give me a ping if you're interested and I'll have another look.
Regards,
Chris
--
cyeoh@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia
diff -urpN -X linux-2.6.15.6/Documentation/dontdiff linux-2.6.15.6.ref/arch/powerpc/kernel/sysfs.c linux-2.6.15.6.hcall/arch/powerpc/kernel/sysfs.c
--- linux-2.6.15.6.ref/arch/powerpc/kernel/sysfs.c 2006-03-06 06:07:54.000000000 +1100
+++ linux-2.6.15.6.hcall/arch/powerpc/kernel/sysfs.c 2006-04-05 13:56:47.000000000 +1000
@@ -338,6 +338,213 @@ static ssize_t show_physical_id(struct s
}
static SYSDEV_ATTR(physical_id, 0444, show_physical_id, NULL);
+
+DECLARE_PER_CPU(unsigned long[NUM_HCALL_TYPES], hcall_type_count);
+DECLARE_PER_CPU(unsigned long[NUM_HCALL_TYPES], hcall_type_time);
+
+static ssize_t store_hcall_stats(struct sys_device *dev,
+ const char *buf,
+ size_t count)
+{
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev);
+ int i;
+
+ // Clear counters
+ for (i=0; i<NUM_HCALL_TYPES; i++) {
+ per_cpu(hcall_type_count, cpu->sysdev.id)[i] = 0;
+ per_cpu(hcall_type_time, cpu->sysdev.id)[i] = 0;
+ }
+ return count;
+}
+
+static ssize_t show_hcall_stats(struct sys_device *dev, char *buf)
+{
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev);
+
+ return snprintf(buf, PAGE_SIZE,
+ "H_REMOVE\t%lu\t%lu\n"
+ "H_ENTER\t%lu\t%lu\n"
+ "H_READ\t%lu\t%lu\n"
+ "H_CLEAR_MOD\t%lu\t%lu\n"
+ "H_CLEAR_REF\t%lu\t%lu\n"
+ "H_PROTECT\t%lu\t%lu\n"
+ "H_GET_TCE\t%lu\t%lu\n"
+ "H_PUT_TCE\t%lu\t%lu\n"
+ "H_SET_SPRG0\t%lu\t%lu\n"
+ "H_SET_DABR\t%lu\t%lu\n"
+ "H_PAGE_INIT\t%lu\t%lu\n"
+ "H_SET_ASR\t%lu\t%lu\n"
+ "H_ASR_ON\t%lu\t%lu\n"
+ "H_ASR_OFF\t%lu\t%lu\n"
+ "H_LOGICAL_CI_LOAD\t%lu\t%lu\n"
+ "H_LOGICAL_CI_STORE\t%lu\t%lu\n"
+ "H_LOGICAL_CACHE_LOAD\t%lu\t%lu\n"
+ "H_LOGICAL_CACHE_STORE\t%lu\t%lu\n"
+ "H_LOGICAL_ICBI\t%lu\t%lu\n"
+ "H_LOGICAL_DCBF\t%lu\t%lu\n"
+ "H_GET_TERM_CHAR\t%lu\t%lu\n"
+ "H_PUT_TERM_CHAR\t%lu\t%lu\n"
+ "H_REAL_TO_LOGICAL\t%lu\t%lu\n"
+ "H_HYPERVISOR_DATA\t%lu\t%lu\n"
+ "H_EOI\t%lu\t%lu\n"
+ "H_CPPR\t%lu\t%lu\n"
+ "H_IPI\t%lu\t%lu\n"
+ "H_IPOLL\t%lu\t%lu\n"
+ "H_XIRR\t%lu\t%lu\n"
+ "H_PERFMON\t%lu\t%lu\n"
+ "H_MIGRATE_DMA\t%lu\t%lu\n"
+ "H_REGISTER_VPA\t%lu\t%lu\n"
+ "H_CEDE\t%lu\t%lu\n"
+ "H_CONFER\t%lu\t%lu\n"
+ "H_PROD\t%lu\t%lu\n"
+ "H_GET_PPP\t%lu\t%lu\n"
+ "H_SET_PPP\t%lu\t%lu\n"
+ "H_PURR\t%lu\t%lu\n"
+ "H_PIC\t%lu\t%lu\n"
+ "H_REG_CRQ\t%lu\t%lu\n"
+ "H_FREE_CRQ\t%lu\t%lu\n"
+ "H_VIO_SIGNAL\t%lu\t%lu\n"
+ "H_SEND_CRQ\t%lu\t%lu\n"
+ "H_COPY_RDMA\t%lu\t%lu\n"
+ "H_STUFF_TCE\t%lu\t%lu\n"
+ "H_PUT_TCE_INDIRECT\t%lu\t%lu\n"
+ "H_VTERM_PARTNER_INFO\t%lu\t%lu\n"
+ "H_REGISTER_VTERM\t%lu\t%lu\n"
+ "H_FREE_VTERM\t%lu\t%lu\n"
+ "H_POLL_PENDING\t%lu\t%lu\n"
+ "H_REGISTER_LOGICAL_LAN\t%lu\t%lu\n"
+ "H_FREE_LOGICAL_LAN\t%lu\t%lu\n"
+ "H_ADD_LOGICAL_LAN_BUFFER\t%lu\t%lu\n"
+ "H_SEND_LOGICAL_LAN\t%lu\t%lu\n"
+ "H_MULTICAST_CTRL\t%lu\t%lu\n"
+ "H_CHANGE_LOGICAL_LAN_MAC\t%lu\t%lu\n",
+ per_cpu(hcall_type_count,cpu->sysdev.id)[0],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[0],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[1],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[1],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[2],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[2],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[3],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[3],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[4],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[4],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[5],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[5],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[6],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[6],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[7],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[7],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[8],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[8],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[9],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[9],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[10],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[10],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[11],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[11],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[12],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[12],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[13],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[13],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[14],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[14],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[15],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[15],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[16],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[16],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[17],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[17],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[18],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[18],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[19],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[19],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[20],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[20],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[21],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[21],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[22],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[22],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[23],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[23],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[24],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[24],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[25],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[25],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[26],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[26],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[27],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[27],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[28],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[28],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[29],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[29],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[30],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[30],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[31],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[31],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[32],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[32],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[33],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[33],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[34],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[34],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[35],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[35],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[36],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[36],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[37],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[37],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[38],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[38],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[39],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[39],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[40],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[40],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[41],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[41],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[42],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[42],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[43],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[43],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[44],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[44],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[45],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[45],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[46],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[46],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[47],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[47],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[48],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[48],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[49],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[49],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[50],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[50],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[51],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[51],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[52],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[52],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[53],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[53],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[54],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[54],
+ per_cpu(hcall_type_count,cpu->sysdev.id)[55],
+ per_cpu(hcall_type_time,cpu->sysdev.id)[55]);
+}
+
+static SYSDEV_ATTR(hcall_stats, 0666, show_hcall_stats, store_hcall_stats);
+
+static int __init hcall_stats_data_init(void)
+{
+ int cpu;
+
+ for_each_cpu(cpu) {
+ struct cpu *c = &per_cpu(cpu_devices, cpu);
+ sysdev_create_file(&c->sysdev, &attr_hcall_stats);
+ }
+ return 0;
+}
+
static int __init topology_init(void)
{
int cpu;
@@ -378,6 +585,7 @@ static int __init topology_init(void)
register_cpu_online(cpu);
}
- return 0;
+ return hcall_stats_data_init();
}
__initcall(topology_init);
+
diff -urpN -X linux-2.6.15.6/Documentation/dontdiff linux-2.6.15.6.ref/arch/powerpc/platforms/pseries/hvCall.S linux-2.6.15.6.hcall/arch/powerpc/platforms/pseries/hvCall.S
--- linux-2.6.15.6.ref/arch/powerpc/platforms/pseries/hvCall.S 2006-03-06 06:07:54.000000000 +1100
+++ linux-2.6.15.6.hcall/arch/powerpc/platforms/pseries/hvCall.S 2006-04-05 13:52:20.000000000 +1000
@@ -27,7 +27,7 @@
unsigned long *out2, R9
unsigned long *out3); R10
*/
-_GLOBAL(plpar_hcall)
+_GLOBAL(plpar_hcall_real)
HMT_MEDIUM
mfcr r0
@@ -53,10 +53,15 @@ _GLOBAL(plpar_hcall)
blr /* return r3 = status */
-/* Simple interface with no output values (other than status) */
_GLOBAL(plpar_hcall_norets)
HMT_MEDIUM
+ b plpar_hcall_norets_C
+
+/* Simple interface with no output values (other than status) */
+_GLOBAL(plpar_hcall_norets_real)
+ HMT_MEDIUM
+
mfcr r0
stw r0,8(r1)
@@ -78,7 +83,7 @@ _GLOBAL(plpar_hcall_norets)
unsigned long arg8, 112(R1)
unsigned long *out1); 120(R1)
*/
-_GLOBAL(plpar_hcall_8arg_2ret)
+_GLOBAL(plpar_hcall_8arg_2ret_real)
HMT_MEDIUM
mfcr r0
@@ -104,7 +109,7 @@ _GLOBAL(plpar_hcall_8arg_2ret)
unsigned long *out3, R10
unsigned long *out4); 112(R1)
*/
-_GLOBAL(plpar_hcall_4out)
+_GLOBAL(plpar_hcall_4out_real)
HMT_MEDIUM
mfcr r0
diff -urpN -X linux-2.6.15.6/Documentation/dontdiff linux-2.6.15.6.ref/arch/powerpc/platforms/pseries/lpar.c linux-2.6.15.6.hcall/arch/powerpc/platforms/pseries/lpar.c
--- linux-2.6.15.6.ref/arch/powerpc/platforms/pseries/lpar.c 2006-03-06 06:07:54.000000000 +1100
+++ linux-2.6.15.6.hcall/arch/powerpc/platforms/pseries/lpar.c 2006-04-05 13:54:48.000000000 +1000
@@ -532,3 +532,286 @@ void hpte_init_lpar(void)
htab_finish_init();
}
+
+DEFINE_PER_CPU(unsigned long[NUM_HCALL_TYPES], hcall_type_count);
+DEFINE_PER_CPU(unsigned long[NUM_HCALL_TYPES], hcall_type_time);
+
+/* From ibmveth.h */
+/* hcall numbers */
+#define H_VIO_SIGNAL 0x104
+#define H_REGISTER_LOGICAL_LAN 0x114
+#define H_FREE_LOGICAL_LAN 0x118
+#define H_ADD_LOGICAL_LAN_BUFFER 0x11C
+#define H_SEND_LOGICAL_LAN 0x120
+#define H_MULTICAST_CTRL 0x130
+#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
+
+inline int map_hcall_to_index(unsigned long opcode)
+{
+ switch (opcode) {
+ case H_REMOVE:
+ return 0;
+ case H_ENTER:
+ return 1;
+ case H_READ:
+ return 2;
+ case H_CLEAR_MOD:
+ return 3;
+ case H_CLEAR_REF:
+ return 4;
+ case H_PROTECT:
+ return 5;
+ case H_GET_TCE:
+ return 6;
+ case H_PUT_TCE:
+ return 7;
+ case H_SET_SPRG0:
+ return 8;
+ case H_SET_DABR:
+ return 9;
+ case H_PAGE_INIT:
+ return 10;
+ case H_SET_ASR:
+ return 11;
+ case H_ASR_ON:
+ return 12;
+ case H_ASR_OFF:
+ return 13;
+ case H_LOGICAL_CI_LOAD:
+ return 14;
+ case H_LOGICAL_CI_STORE:
+ return 15;
+ case H_LOGICAL_CACHE_LOAD:
+ return 16;
+ case H_LOGICAL_CACHE_STORE:
+ return 17;
+ case H_LOGICAL_ICBI:
+ return 18;
+ case H_LOGICAL_DCBF:
+ return 19;
+ case H_GET_TERM_CHAR:
+ return 20;
+ case H_PUT_TERM_CHAR:
+ return 21;
+ case H_REAL_TO_LOGICAL:
+ return 22;
+ case H_HYPERVISOR_DATA:
+ return 23;
+ case H_EOI:
+ return 24;
+ case H_CPPR:
+ return 25;
+ case H_IPI:
+ return 26;
+ case H_IPOLL:
+ return 27;
+ case H_XIRR:
+ return 28;
+ case H_PERFMON:
+ return 29;
+ case H_MIGRATE_DMA:
+ return 30;
+ case H_REGISTER_VPA:
+ return 31;
+ case H_CEDE:
+ return 32;
+ case H_CONFER:
+ return 33;
+ case H_PROD:
+ return 34;
+ case H_GET_PPP:
+ return 35;
+ case H_SET_PPP:
+ return 36;
+ case H_PURR:
+ return 37;
+ case H_PIC:
+ return 38;
+ case H_REG_CRQ:
+ return 39;
+ case H_FREE_CRQ:
+ return 40;
+ case H_VIO_SIGNAL:
+ return 41;
+ case H_SEND_CRQ:
+ return 42;
+ case H_COPY_RDMA:
+ return 43;
+ case H_STUFF_TCE:
+ return 44;
+ case H_PUT_TCE_INDIRECT:
+ return 45;
+ case H_VTERM_PARTNER_INFO:
+ return 46;
+ case H_REGISTER_VTERM:
+ return 47;
+ case H_FREE_VTERM:
+ return 48;
+ case H_POLL_PENDING:
+ return 49;
+ case H_REGISTER_LOGICAL_LAN:
+ return 50;
+ case H_FREE_LOGICAL_LAN:
+ return 51;
+ case H_ADD_LOGICAL_LAN_BUFFER:
+ return 52;
+ case H_SEND_LOGICAL_LAN:
+ return 53;
+ case H_MULTICAST_CTRL:
+ return 54;
+ case H_CHANGE_LOGICAL_LAN_MAC:
+ return 55;
+ default:
+ printk("Unknown hcall %ld\n", opcode);
+ return 0;
+ }
+}
+
+extern long plpar_hcall_real(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3);
+
+long plpar_hcall(unsigned long opcode, unsigned long arg1,
+ unsigned long arg2, unsigned long arg3,
+ unsigned long arg4, unsigned long *out1,
+ unsigned long *out2, unsigned long *out3)
+{
+ long retcode;
+ unsigned long t_entry;
+ int opcode_index;
+
+ opcode_index = map_hcall_to_index(opcode);
+
+ t_entry = mfspr(SPRN_PURR);
+ barrier();
+
+ retcode = plpar_hcall_real(opcode, arg1, arg2, arg3, arg4,
+ out1, out2, out3);
+
+ barrier();
+ get_cpu_var(hcall_type_count)[opcode_index]++;
+ put_cpu_var(hcall_type_count);
+ get_cpu_var(hcall_type_time)[opcode_index] += mfspr(SPRN_PURR) - t_entry;
+ put_cpu_var(hcall_type_time);
+
+ return retcode;
+};
+
+extern long plpar_hcall_norets_real(unsigned long opcode, ...);
+
+long plpar_hcall_norets_C(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6)
+{
+ long retcode;
+ unsigned long t_entry;
+ int opcode_index;
+
+ opcode_index = map_hcall_to_index(opcode);
+ t_entry = mfspr(SPRN_PURR);
+ barrier();
+
+ retcode = plpar_hcall_norets_real(opcode, arg1, arg2, arg3, arg4,
+ arg5, arg6);
+
+ barrier();
+ get_cpu_var(hcall_type_count)[opcode_index]++;
+ put_cpu_var(hcall_type_count);
+ get_cpu_var(hcall_type_time)[opcode_index] += mfspr(SPRN_PURR) - t_entry;
+ put_cpu_var(hcall_type_time);
+
+ return retcode;
+}
+
+extern long plpar_hcall_8arg_2ret_real(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long *out1);
+
+long plpar_hcall_8arg_2ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long *out1)
+{
+ long retcode;
+ unsigned long t_entry;
+ int opcode_index;
+
+ opcode_index = map_hcall_to_index(opcode);
+ t_entry = mfspr(SPRN_PURR);
+ barrier();
+
+ retcode = plpar_hcall_8arg_2ret_real(opcode, arg1, arg2, arg3, arg4,
+ arg5, arg6, arg7, arg8, out1);
+
+ barrier();
+ get_cpu_var(hcall_type_count)[opcode_index]++;
+ put_cpu_var(hcall_type_count);
+ get_cpu_var(hcall_type_time)[opcode_index] += mfspr(SPRN_PURR) - t_entry;
+ put_cpu_var(hcall_type_time);
+
+ return retcode;
+}
+
+extern long plpar_hcall_4out_real(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4);
+
+long plpar_hcall_4out(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4)
+{
+ long retcode;
+ unsigned long t_entry;
+ int opcode_index;
+
+ opcode_index = map_hcall_to_index(opcode);
+ t_entry = mfspr(SPRN_PURR);
+ barrier();
+
+ retcode = plpar_hcall_4out_real(opcode, arg1, arg2, arg3, arg4,
+ out1, out2, out3, out4);
+
+ barrier();
+ get_cpu_var(hcall_type_count)[opcode_index]++;
+ put_cpu_var(hcall_type_count);
+ get_cpu_var(hcall_type_time)[opcode_index] += mfspr(SPRN_PURR) - t_entry;
+ put_cpu_var(hcall_type_time);
+
+ return retcode;
+}
+
+
diff -urpN -X linux-2.6.15.6/Documentation/dontdiff linux-2.6.15.6.ref/include/asm-powerpc/hvcall.h linux-2.6.15.6.hcall/include/asm-powerpc/hvcall.h
--- linux-2.6.15.6.ref/include/asm-powerpc/hvcall.h 2006-03-06 06:07:54.000000000 +1100
+++ linux-2.6.15.6.hcall/include/asm-powerpc/hvcall.h 2006-04-05 13:59:22.000000000 +1000
@@ -116,6 +116,11 @@
#ifndef __ASSEMBLY__
+
+#define NUM_HCALL_TYPES 56
+/* Some are in ibmveth.h */
+
+
/* plpar_hcall() -- Generic call interface using above opcodes
*
* The actual call interface is a hypervisor call instruction with
^ permalink raw reply
* Re: Collecting hypervisor call stats
From: Jimi Xenidis @ 2006-06-01 4:34 UTC (permalink / raw)
To: Mike Kravetz, Chris Yeoh, Bryan Rosenburg; +Cc: linuxppc-dev
In-Reply-To: <20060531204144.GA7909@w-mikek2.ibm.com>
IIRC, chris and bryan have done some work to track this, they may
have some code to contribute.
On May 31, 2006, at 4:41 PM, Mike Kravetz wrote:
> We would like to add code that gathers statistics about hypervisor
> calls.
> It would keep track of things like # of calls made for each opcode
> as well
> as time spent processing the calls.
>
> The 'obvious' place to gather such statistics would be from within the
> routines making hcalls in hvCall.S. Once thing that I have noticed is
> the following comment at the beginning hvCall.S:
>
> * NOTE: this file will go away when we move to inline this work.
>
> So, it appears someone thought/thinks these routines should be
> inlined.
> I assume this is for performance reasons? If this is the case, then I
> suspect gathering of statistics (which would introduce overhead) would
> meet resistance?
>
> Comments about the feasibility of adding such statistic gathering code
> would be appreciated.
>
> Thanks,
> --
> Mike
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: AW: MPC8270 on Microsys PM827 Kernel 2.6 Oops: kernel access of bad area, sig: 11 [#1]
From: Wolfgang Denk @ 2006-06-01 1:02 UTC (permalink / raw)
To: Behre, Frederik - LT; +Cc: linuxppc-embedded
In-Reply-To: <CC692F5386B0AA47A62B7484A7CA2B6D02C4CFCC@frmx1.litef.de>
In message <CC692F5386B0AA47A62B7484A7CA2B6D02C4CFCC@frmx1.litef.de> you wrote:
> Thanks for answer me.
> I want to install Xenomai on this mpc8270. Therefor I need 2.6.14
> ,because I need the adeos patch.
You should be able to use a more recent kenrel tree as well.
Looking closer at your problem, it seems obvious where the problem
is:
...
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> NFTL driver: nftlcore.c $Revision: 1.97 $, nftlmount.c $Revision: 1.40 $
> Oops: kernel access of bad area, sig: 11 [#1]
> NIP: C0107A14 LR: C0106660 SP: C036FE30 REGS: c036fd80 TRAP: 0300 Not
> tainted
...
That's when the kernel attempts to access the flash devices on your
board.
Please use a later kernel. I just verified that the 2.6.15 kernel
(git tag DENX-v2.6.15 in our repo) works fine:
Linux version 2.6.15-gref: ref (wd@pollux.denx.de) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #1 Thu Jun 1 02:55:30 MEST 2006
Microsys PM82x PowerPC port
arch/ppc/syslib/m82xx_pci.c: The PCI bus is 37500000 Mhz.
Waiting 0.5 seconds after deasserting RST...
Built 1 zonelists
Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.1:/opt/eldk-4.0-2006-02-19/ppc_6xx ip=192.168.200.5:192.168.1.1::255.255.0.0:pm827:eth0:off panic=1 console=ttyCPM1,9600
PID hash table entries: 1024 (order: 10, 16384 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 127616k available (1592k kernel code, 412k data, 124k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:00.0
PCI: Cannot allocate resource region 1 of device 0000:00:00.0
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
Generic RTC Driver v1.07
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xf0011a80 (irq = 4) is a CPM UART
ttyCPM1 at MMIO 0xf0011a90 (irq = 5) is a CPM UART
ttyCPM2 at MMIO 0xf0011a00 (irq = 40) is a CPM UART
ttyCPM3 at MMIO 0xf0011a20 (irq = 41) is a CPM UART
ttyCPM4 at MMIO 0xf0011a40 (irq = 42) is a CPM UART
ttyCPM5 at MMIO 0xf0011a60 (irq = 43) is a CPM UART
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c $Revision: 1.41 $
Found: Intel 28F640C3B
PM82x-0: Found 4 x16 devices at 0x0 in 64-bit bank
PM82x flash bank 0: Using static image partition definition
Creating 4 MTD partitions on "PM82x-0":
0x00000000-0x00040000 : "U-Boot"
0x00040000-0x00100000 : "kernel"
0x00100000-0x00400000 : "ramdisk"
0x00400000-0x02000000 : "user"
No valid DiskOnChip devices found
eth0: FCC ENET Version 0.3, 00:40:42:81:27:0d
mii_reg: 608e78e2
eth0: Phy @ 0x1, type LXT971 (0x001378e2)
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: config: auto-negotiation on, 100HDX, 10HDX.
IP-Config: Complete:
device=eth0, addr=192.168.200.5, mask=255.255.0.0, gw=255.255.255.255,
host=pm827, domain=, nis-domain=(none),
bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.1
Looking up port of RPC 100005/1 on 192.168.1.1
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 124k init
...
Also, the current top-of-tree version (Linux-2.6.17-rc5-g1d475c9f)
works fine.
Please use current code.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to
be assimilated.
^ permalink raw reply
* Re: pmf_register_irq_client gives sleep with locks held warning
From: Benjamin Herrenschmidt @ 2006-06-01 0:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Morton, linuxppc-dev list
In-Reply-To: <1149020341.5128.7.camel@johannes>
On Tue, 2006-05-30 at 22:19 +0200, Johannes Berg wrote:
> Hi,
>
> When testing headphone detection stuff I got this:
>
> [ 634.218762] BUG: sleeping function called from invalid context at mm/slab.c:2794
> [ 634.218774] in_atomic():0, irqs_disabled():1
> [ 634.218777] Call Trace:
> [ 634.218779] [D67ADC00] [C00085F8] show_stack+0x50/0x190 (unreliable)
> [ 634.218794] [D67ADC30] [C0024030] __might_sleep+0xcc/0xe8
> [ 634.218804] [D67ADC40] [C0076C04] __kmalloc+0xf4/0xf8
> [ 634.218815] [D67ADC60] [C00B37D4] proc_create+0x9c/0xe8
> [ 634.218827] [D67ADC90] [C00B3930] proc_mkdir_mode+0x2c/0x88
> [ 634.218833] [D67ADCB0] [C005227C] register_handler_proc+0xe4/0xfc
> [ 634.218844] [D67ADD50] [C0051D70] setup_irq+0x118/0x16c
> [ 634.218850] [D67ADD70] [C0051E68] request_irq+0xa4/0xb8
> [ 634.218855] [D67ADDA0] [C0020BA0] macio_do_gpio_irq_enable+0x40/0x50
> [ 634.218860] [D67ADDB0] [C00208BC] pmf_register_irq_client+0x88/0x9c
> [..., not important]
That's a bug in the PowerMac PMF code. What about this patch ?
This fixes request_irq() potentially called from atomic context.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/platforms/powermac/pfunc_core.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/pfunc_core.c 2006-04-19 15:04:38.000000000 +1000
+++ linux-work/arch/powerpc/platforms/powermac/pfunc_core.c 2006-06-01 10:58:57.000000000 +1000
@@ -11,6 +11,7 @@
#include <linux/kernel.h>
#include <linux/spinlock.h>
#include <linux/module.h>
+#include <linux/mutex.h>
#include <asm/semaphore.h>
#include <asm/prom.h>
@@ -546,6 +547,7 @@
static LIST_HEAD(pmf_devices);
static spinlock_t pmf_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_MUTEX(pmf_irq_mutex);
static void pmf_release_device(struct kref *kref)
{
@@ -864,15 +866,17 @@
spin_lock_irqsave(&pmf_lock, flags);
func = __pmf_find_function(target, name, PMF_FLAGS_INT_GEN);
- if (func == NULL) {
- spin_unlock_irqrestore(&pmf_lock, flags);
+ if (func)
+ func = pmf_get_function(func);
+ spin_unlock_irqrestore(&pmf_lock, flags);
+ if (func == NULL)
return -ENODEV;
- }
+ mutex_lock(&pmf_irq_mutex);
if (list_empty(&func->irq_clients))
func->dev->handlers->irq_enable(func);
list_add(&client->link, &func->irq_clients);
client->func = func;
- spin_unlock_irqrestore(&pmf_lock, flags);
+ mutex_unlock(&pmf_irq_mutex);
return 0;
}
@@ -881,16 +885,16 @@
void pmf_unregister_irq_client(struct pmf_irq_client *client)
{
struct pmf_function *func = client->func;
- unsigned long flags;
BUG_ON(func == NULL);
- spin_lock_irqsave(&pmf_lock, flags);
+ mutex_lock(&pmf_irq_mutex);
client->func = NULL;
list_del(&client->link);
if (list_empty(&func->irq_clients))
func->dev->handlers->irq_disable(func);
- spin_unlock_irqrestore(&pmf_lock, flags);
+ mutex_unlock(&pmf_irq_mutex);
+ pmf_put_function(func);
}
EXPORT_SYMBOL_GPL(pmf_unregister_irq_client);
^ permalink raw reply
* RE: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Anantharaman Chetan-W16155 @ 2006-05-31 23:14 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0605311235n171f889g135e074685b578bc@mail.gmail.com>
Grant,=20
Can you please provide a link or perhaps point me to the app node that
Xilinx has to modify linuxppc-2.4 tree for V4-FX.
Thanks,=20
Chetan
-----Original Message-----
From: glikely@gmail.com [mailto:glikely@gmail.com] On Behalf Of Grant
Likely
Sent: Wednesday, May 31, 2006 2:35 PM
To: Anantharaman Chetan-W16155
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
On 5/31/06, Anantharaman Chetan-W16155
<Chetan.S.Anantharaman@motorola.com> wrote:
>
> Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4
FX
> series FPGA's, PPC405 processor?
Linux on the V4-FX is well supported. Xilinx has an app node
describing how to modify the linuxppc-2.4 tree to work on the V4-FX.
You can find out how to get the tree here:
http://www.penguinppc.org/kernel/
I've got both 2.4 & 2.6 happily running on my ML403 board here.
Cheers,
g.
--=20
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Setting I&D cache enable in the same mtspr instruction
From: Becky Bruce @ 2006-05-31 23:06 UTC (permalink / raw)
To: Assaf Hoffman; +Cc: linuxppc-embedded, Rita Shtern, Ronen Shitrit
In-Reply-To: <B9FFC3F97441D04093A504CEA31B7C41A62B2F@msilexch01.marvell.com>
I think we need to hold off on this particular patch for a few days.
I took a look at the manual section you're referencing here, and sure
enough, it says that you shouldn't set both bits in the same mtspr
instruction. The manual says this in more than one place, in fact.
However, that seemed a little bit odd to me, so I talked with a few
of the hardware designers for the 745x family. They assure me that
the manual statement is false. The normal code that sets ICE/ICFI/
DCE/DCFI all on one mtspr should be fully functional on this
processor family. I'm still working on confirming this and getting
some history on *why* the manual says that, but for now I'd say it's
a pretty good bet that the manual is in error. I will let you know
if I find out this is not the case.
You are correct, though, in that an isync is needed prior to the
write of HID0[ICE]. It's probably missing because it's not listed in
the synchronization table in chapter 2 of the manual.
For what it's worth, as soon as I can confirm this, I will make sure
the publications team here at Freescale is made aware of the error so
it can be corrected in the next printing of the manual. I will also
have the synchronization table updated as it also has incorrect
information.
Thanks,
B
^ permalink raw reply
* Re: Collecting hypervisor call stats
From: Mike Kravetz @ 2006-05-31 22:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17534.7026.169023.420733@cargo.ozlabs.ibm.com>
On Thu, Jun 01, 2006 at 08:40:50AM +1000, Paul Mackerras wrote:
> I think that gathering those statistics would be useful. I suggest
> you use a per-cpu array for them, to reduce the performance impact.
Yes, that is a must do.
We need to get a timestamp before and after the call. mftb should do
the trick. Also, I'd prefer to have the code that stuffs the values
into the array be C. So, the decision is to have the assembly code
call out to the C routine -OR- create wrappers for the assembly routines.
I much prefer C wrappers to touching the assembly.
--
Mike
^ permalink raw reply
* Re: Collecting hypervisor call stats
From: Paul Mackerras @ 2006-05-31 22:40 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev
In-Reply-To: <20060531204144.GA7909@w-mikek2.ibm.com>
Mike Kravetz writes:
> We would like to add code that gathers statistics about hypervisor calls.
> It would keep track of things like # of calls made for each opcode as well
> as time spent processing the calls.
>
> The 'obvious' place to gather such statistics would be from within the
> routines making hcalls in hvCall.S. Once thing that I have noticed is
> the following comment at the beginning hvCall.S:
>
> * NOTE: this file will go away when we move to inline this work.
I suspect that's a very old comment. :)
> So, it appears someone thought/thinks these routines should be inlined.
> I assume this is for performance reasons? If this is the case, then I
> suspect gathering of statistics (which would introduce overhead) would
> meet resistance?
>
> Comments about the feasibility of adding such statistic gathering code
> would be appreciated.
I think that gathering those statistics would be useful. I suggest
you use a per-cpu array for them, to reduce the performance impact.
Paul.
^ permalink raw reply
* Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Grant Likely @ 2006-05-31 22:33 UTC (permalink / raw)
To: Anantharaman Chetan-W16155; +Cc: linuxppc-embedded
In-Reply-To: <EDF27F298D4B03498AE0C249A941DFF803D6E8@de01exm68.ds.mot.com>
On 5/31/06, Anantharaman Chetan-W16155
<Chetan.S.Anantharaman@motorola.com> wrote:
> Was the port done on a FX100 FPGA?
No; but AFAIK, the ppc hardcore is identical for all FX parts. The
FX100 shoudn't be a problem.
> Also, what PVR number does the PPC405 indicate?
Core#0>rd pvr
pvr: 0x20011430 536941616
^ permalink raw reply
* Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Aidan Williams @ 2006-05-31 22:22 UTC (permalink / raw)
To: Anantharaman Chetan-W16155; +Cc: linuxppc-embedded
In-Reply-To: <EDF27F298D4B03498AE0C249A941DFF803D6E6@de01exm68.ds.mot.com>
Anantharaman Chetan-W16155 wrote:
> Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4
> FX series FPGA’s, PPC405 processor?
>
Yes, see
http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022583.html
Note that there are silicon bugs that prevent caches being used in some
chips.
> More specifically, the FX100 FPGA?
I don't have one of those, sorry.
- aidan
^ permalink raw reply
* Help with MPC5200 + Bestcomm + Local Plus Bus
From: roger blofeld @ 2006-05-31 21:42 UTC (permalink / raw)
To: linuxppc embedded
Hi
I have a custom board which is essentially an icecube with an FPGA on
the local bus. I have a driver which pulls data from the FPGA in
response to interrupts using memcpy_fromio(). I would like to reduce
the CPU usage.
Has anyone used bestcomm to move data from LPB to memory? Is there an
example anywhere? From the app note AN2604 it looks like writing a
bestcomm task is difficult at best. Perhaps it is possible to re-use
the ethernet rx task for this purpose?
I'm using mainline 2.6.16.18 with Sylvain's patches for
ethernet/bestcomm/ide. (BTW, will that code make it into the mainline
any time soon?)
Thanks in advance for any advice
-roger
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* RE: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Anantharaman Chetan-W16155 @ 2006-05-31 21:47 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0605311235n171f889g135e074685b578bc@mail.gmail.com>
Was the port done on a FX100 FPGA? Also, what PVR number does the PPC405
indicate?
Thanks,
Chetan
-----Original Message-----
From: glikely@gmail.com [mailto:glikely@gmail.com] On Behalf Of Grant
Likely
Sent: Wednesday, May 31, 2006 2:35 PM
To: Anantharaman Chetan-W16155
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
On 5/31/06, Anantharaman Chetan-W16155
<Chetan.S.Anantharaman@motorola.com> wrote:
>
> Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4
FX
> series FPGA's, PPC405 processor?
Linux on the V4-FX is well supported. Xilinx has an app node
describing how to modify the linuxppc-2.4 tree to work on the V4-FX.
You can find out how to get the tree here:
http://www.penguinppc.org/kernel/
I've got both 2.4 & 2.6 happily running on my ML403 board here.
Cheers,
g.
--=20
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Collecting hypervisor call stats
From: Geoff Levand @ 2006-05-31 21:25 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev
In-Reply-To: <20060531204144.GA7909@w-mikek2.ibm.com>
Mike Kravetz wrote:
> We would like to add code that gathers statistics about hypervisor calls.
> It would keep track of things like # of calls made for each opcode as well
> as time spent processing the calls.
>
> The 'obvious' place to gather such statistics would be from within the
> routines making hcalls in hvCall.S. Once thing that I have noticed is
> the following comment at the beginning hvCall.S:
>
> * NOTE: this file will go away when we move to inline this work.
>
> So, it appears someone thought/thinks these routines should be inlined.
> I assume this is for performance reasons? If this is the case, then I
> suspect gathering of statistics (which would introduce overhead) would
> meet resistance?
>
> Comments about the feasibility of adding such statistic gathering code
> would be appreciated.
FYI, there exists an add-on feature KFT (kernel function trace)
which you may be able to extend to do much of what you want. It
uses gcc's -finstrument-functions option to hook into the
entry and exit of C functions. You may able to add the hooks
by hand to the asm routines in hvCall.S and then take advantage
of the existing KFT functionality to start and stop traces, post
process the data, etc.
http://tree.celinuxforum.org/CelfPubWiki/KernelFunctionTrace
-Geoff
^ permalink raw reply
* Re: [PATCH] Provide mechanism for editing builtin command-line in zImage binary.
From: Michal Ostrowski @ 2006-05-31 21:04 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1149107718.8379.48.camel@localhost.localdomain>
On Wed, 2006-05-31 at 15:35 -0500, Matthew McClintock wrote:
> On Wed, 2006-05-31 at 16:26 -0400, Michal Ostrowski wrote:
> > I've had some experience with trying to edit existing OF trees (i.e.
> > take a G5 OF tree and alter it to reflect the fact that the OS has a
> > hypervisor between it and the HW). It's not a pleasant experience.
> >
> > Thus for OF based systems I'd be very wary of trying to edit the OF
> > tree
> > in arbitrary ways prior to Linux seeing it.
>
> Out of curiosity what was hard about it?
Well, suppose that you want to remove a particular device from an OF
tree. At what point are you certain that you've completely removed all
references to it?
I've always been concerned that there are some properties remaining in
the tree that may refer to the node I am removing (resulting in an
inconsistent tree). If you're working with one particular FW provider
then you may come up with code that does it right, but such code may not
necessarily catch all the extensions provided by another FW provider.
I've found Apple and IBM FW like to do things in different ways. In
particular IBM FW likes to add "ibm,*" properties and you'd have to know
the meaning of all such properties to ensure you've caught all
references to the device you're pruning.
Like with most things, getting a solution to solve your immediate
problem is easy; a perfect, general solution is much, much more
difficult.
(Granted, some things, such as adding a new "memory" node are pretty
easy to do.)
> Also it is worth mentioning
> some systems don't have to privilege of having a OF tree ready to go by
> the time Linux starts.
For such systems I think the right approach is to provide a
DTC-generated OF tree (provided that one ensures that we don't skip
important parts of prom_init.c).
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* Collecting hypervisor call stats
From: Mike Kravetz @ 2006-05-31 20:41 UTC (permalink / raw)
To: linuxppc-dev
We would like to add code that gathers statistics about hypervisor calls.
It would keep track of things like # of calls made for each opcode as well
as time spent processing the calls.
The 'obvious' place to gather such statistics would be from within the
routines making hcalls in hvCall.S. Once thing that I have noticed is
the following comment at the beginning hvCall.S:
* NOTE: this file will go away when we move to inline this work.
So, it appears someone thought/thinks these routines should be inlined.
I assume this is for performance reasons? If this is the case, then I
suspect gathering of statistics (which would introduce overhead) would
meet resistance?
Comments about the feasibility of adding such statistic gathering code
would be appreciated.
Thanks,
--
Mike
^ permalink raw reply
* Re: [PATCH] Provide mechanism for editing builtin command-line in zImage binary.
From: Matthew McClintock @ 2006-05-31 20:35 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: linuxppc-dev
In-Reply-To: <1149107204.6507.97.camel@brick>
On Wed, 2006-05-31 at 16:26 -0400, Michal Ostrowski wrote:
> I've had some experience with trying to edit existing OF trees (i.e.
> take a G5 OF tree and alter it to reflect the fact that the OS has a
> hypervisor between it and the HW). It's not a pleasant experience.
>
> Thus for OF based systems I'd be very wary of trying to edit the OF
> tree
> in arbitrary ways prior to Linux seeing it.
Out of curiosity what was hard about it? Also it is worth mentioning
some systems don't have to privilege of having a OF tree ready to go by
the time Linux starts.
-Matthew
^ permalink raw reply
* Re: [PATCH] Provide mechanism for editing builtin command-line in zImage binary.
From: Michal Ostrowski @ 2006-05-31 20:26 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060531200419.GA17052@mag.az.mvista.com>
On Wed, 2006-05-31 at 13:04 -0700, Mark A. Greer wrote:
> On Tue, May 30, 2006 at 05:12:37PM -0400, Michal Ostrowski wrote:
> > On Tue, 2006-05-30 at 13:41 -0700, Mark A. Greer wrote:
> > > On Mon, May 29, 2006 at 10:01:03PM -0400, mostrows@watson.ibm.com wrote:
> > I'm curious how the tacked-on dt is expected to interact with the real
> > FW dt,
>
> That's a good question. I was thinking that a tacked on dt would be a
> complete replacement for whatever dt came from the fw (but extracting
> some info like /memory props). That probably works okay for non-OF
> systems but may not work for OF systems b/c there is so much more info
> in the OF dt. Someone who knows about OF will have to speak up here.
>
I've had some experience with trying to edit existing OF trees (i.e.
take a G5 OF tree and alter it to reflect the fact that the OS has a
hypervisor between it and the HW). It's not a pleasant experience.
Thus for OF based systems I'd be very wary of trying to edit the OF tree
in arbitrary ways prior to Linux seeing it.
> > and in particular how you would expect the interrogation
> > of /chosen/bootargs in prom_init.c (using prom_getprop()) to pick up the
> > command line value I specify in the tacked-on dt.
>
> If a flattened dt is used instead of an OF dt the prom_init code isn't used.
If we always skip prom_init.c code then we may skip stuff like TCE
allocation which is only ever done on the first boot (and never on
kexec).
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* Re: [PATCH] Provide mechanism for editing builtin command-line in zImage binary.
From: Mark A. Greer @ 2006-05-31 20:04 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: linuxppc-dev
In-Reply-To: <1149023558.6507.15.camel@brick>
On Tue, May 30, 2006 at 05:12:37PM -0400, Michal Ostrowski wrote:
> On Tue, 2006-05-30 at 13:41 -0700, Mark A. Greer wrote:
> > On Mon, May 29, 2006 at 10:01:03PM -0400, mostrows@watson.ibm.com wrote:
> > > zImage will store the builtin command-line in a dedicated section, allowing
> > > it to be easily identified and edited with user-space tools.
> > >
> > > zImage will set /chosen/bootargs to the stored builtin command-line setting,
> > > if /chosen/bootargs is empty (emulating the behavior in prom_init.c).
> > >
> > > Use of this mechanism avoids the need to modify firmware or rely on a
> > > bootloader to customize kernel arguments (and overall system
> > > behavior). The command line can be edited as needed when a zImage is
> > > copied to a TFTP staging area for download by firmware.
>
>
>
>
> > Why do this? Why not get rid of storing the cmdline in the zImage altogether?
> >
>
> The CONFIG_CMDLINE that we have now is very useful if I want the
> behavior of the system to be dependent on the kernel/command line I
> specify that it used (particularly in BOOTP/TFTP scenarios). For such
> systems I configure their firmware to not provide any arguments and to
> always download via TFTP a designated kernel image.
>
> What this scenario does, is it allows me to specify system behavior by
> putting the right kernel with the right command line in the magic
> location from where it will be downloaded.
>
> The problem is, that if I have some large number of machines and I want
> to use the same kernel for all of them (and simply change the command
> line between them) then I have to effectively build a custom kernel for
> each. This patch allows me to build one kernel and then simply edit the
> command line embedded within it.
>
> The key point is that the command line changes and I don't want to have
> to require a firmware interaction every time I change it.
Okay. I hadn't thought of that scenario. You're happy with the dt that
the fw gives you except that you want to change the bootargs.
I guess we can keep CONFIG_CMDLINE around then.
> > We already have equivalent functionality by storing it in the dt's
> > /chosen/bootargs so why this unnecessary complexity?
> >
>
>
> > Add some code to edit the /chosen/bootargs at zImage runtime (just like
> > arch/ppc used to) and we're covered.
>
> That is what this patch is doing.
>
> > AFAICT, we're already adding a tool
> > to tack on flat dt's to an already existing zImage so you're not doing
> > anything we can't--or won't--do already.
> >
>
> Can you please point me at this code so that I can evaluate it in
> detail?
It doesn't exist yet and no one has jumped up to make that tool that I
have seen. I've been messing with bootwrapper code and part of that
adds cmdline editing from a running bootwrapper. We still need someone
to write this tool (assuming that's the way we're going):
http://ozlabs.org/pipermail/linuxppc-dev/2006-April/022435.html
Care to volunteer? ;)
> I'm curious how the tacked-on dt is expected to interact with the real
> FW dt,
That's a good question. I was thinking that a tacked on dt would be a
complete replacement for whatever dt came from the fw (but extracting
some info like /memory props). That probably works okay for non-OF
systems but may not work for OF systems b/c there is so much more info
in the OF dt. Someone who knows about OF will have to speak up here.
> and in particular how you would expect the interrogation
> of /chosen/bootargs in prom_init.c (using prom_getprop()) to pick up the
> command line value I specify in the tacked-on dt.
If a flattened dt is used instead of an OF dt the prom_init code isn't used.
Mark
^ permalink raw reply
* Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Grant Likely @ 2006-05-31 19:35 UTC (permalink / raw)
To: Anantharaman Chetan-W16155; +Cc: linuxppc-embedded
In-Reply-To: <EDF27F298D4B03498AE0C249A941DFF803D6E6@de01exm68.ds.mot.com>
On 5/31/06, Anantharaman Chetan-W16155
<Chetan.S.Anantharaman@motorola.com> wrote:
>
> Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4 FX
> series FPGA's, PPC405 processor?
Linux on the V4-FX is well supported. Xilinx has an app node
describing how to modify the linuxppc-2.4 tree to work on the V4-FX.
You can find out how to get the tree here:
http://www.penguinppc.org/kernel/
I've got both 2.4 & 2.6 happily running on my ML403 board here.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] use msleep() for RTAS delays
From: John Rose @ 2006-05-31 19:32 UTC (permalink / raw)
To: External List; +Cc: Paul Mackerras
The current use of udelay() for RTAS extended delay conditions can
result in CPU soft lockups. The use of msleep() won't tie up the CPU.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
---
Thanks-
John
diff -puN arch/powerpc/kernel/rtas.c~msleep_rtas arch/powerpc/kernel/rtas.c
--- 2_6_linus/arch/powerpc/kernel/rtas.c~msleep_rtas 2006-05-31 14:07:51.000000000 -0500
+++ 2_6_linus-johnrose/arch/powerpc/kernel/rtas.c 2006-05-31 14:10:09.000000000 -0500
@@ -447,10 +447,10 @@ int rtas_set_power_level(int powerdomain
while (1) {
rc = rtas_call(token, 2, 2, setlevel, powerdomain, level);
if (rc == RTAS_BUSY)
- udelay(1);
+ msleep(1);
else if (rtas_is_extended_busy(rc)) {
wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
+ msleep(wait_time);
} else
break;
}
@@ -472,10 +472,10 @@ int rtas_get_sensor(int sensor, int inde
while (1) {
rc = rtas_call(token, 2, 2, state, sensor, index);
if (rc == RTAS_BUSY)
- udelay(1);
+ msleep(1);
else if (rtas_is_extended_busy(rc)) {
wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
+ msleep(wait_time);
} else
break;
}
@@ -497,12 +497,11 @@ int rtas_set_indicator(int indicator, in
while (1) {
rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
if (rc == RTAS_BUSY)
- udelay(1);
+ msleep(1);
else if (rtas_is_extended_busy(rc)) {
wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
- }
- else
+ msleep(wait_time);
+ } else
break;
}
diff -puN arch/powerpc/kernel/rtas_flash.c~msleep_rtas arch/powerpc/kernel/rtas_flash.c
--- 2_6_linus/arch/powerpc/kernel/rtas_flash.c~msleep_rtas 2006-05-31 14:10:47.000000000 -0500
+++ 2_6_linus-johnrose/arch/powerpc/kernel/rtas_flash.c 2006-05-31 14:19:30.000000000 -0500
@@ -16,7 +16,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/proc_fs.h>
-#include <asm/delay.h>
+#include <linux/delay.h>
#include <asm/uaccess.h>
#include <asm/rtas.h>
#include <asm/abs_addr.h>
@@ -372,10 +372,10 @@ static void manage_flash(struct rtas_man
rc = rtas_call(rtas_token("ibm,manage-flash-image"), 1,
1, NULL, args_buf->op);
if (rc == RTAS_RC_BUSY)
- udelay(1);
+ msleep(1);
else if (rtas_is_extended_busy(rc)) {
wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
+ msleep(wait_time);
} else
break;
}
@@ -465,10 +465,10 @@ static void validate_flash(struct rtas_v
spin_unlock(&rtas_data_buf_lock);
if (rc == RTAS_RC_BUSY)
- udelay(1);
+ msleep(1);
else if (rtas_is_extended_busy(rc)) {
wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
+ msleep(wait_time);
} else
break;
}
_
^ permalink raw reply
* Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Anantharaman Chetan-W16155 @ 2006-05-31 19:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 180 bytes --]
Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4
FX series FPGA's, PPC405 processor?
More specifically, the FX100 FPGA?
Thanks,
Chetan
[-- Attachment #2: Type: text/html, Size: 1895 bytes --]
^ permalink raw reply
* Re: >=2.6.17-rc4-mm1 kernel compilation problem (relocation truncated to fit)
From: Nathan Pilatzke @ 2006-05-31 17:34 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linuxppc-dev
In-Reply-To: <447DC91D.8010508@zytor.com>
Applied the patch, did a 'make clean' and 'make'. The patch had no
effect for me, exact same errors.
H. Peter Anvin wrote:
> Nathan Pilatzke wrote:
>> I am getting compilation errors for 2.6.17-rc5-mm1 all the way back to
>> 2.6.17-rc4-mm1. Kernel 2.6.17-rc3-mm1 compiles better for me (I get the
>> undefined reference to __udivdi3 error that has been reported
>> previously). Here are the errors that I get for 2.6.17-rc5-mm1:
>>
>
> Could you try the following patch?
>
> -hpa
>
>
> ------------------------------------------------------------------------
>
> diff --git a/usr/klibc/arch/ppc/MCONFIG b/usr/klibc/arch/ppc/MCONFIG
> index 8b51e65..e101453 100644
> --- a/usr/klibc/arch/ppc/MCONFIG
> +++ b/usr/klibc/arch/ppc/MCONFIG
> @@ -13,9 +13,9 @@ KLIBCBITSIZE = 32
> # Extra linkflags when building the shared version of the library
> # This address needs to be reachable using normal inter-module
> # calls, and work on the memory models for this architecture
> -# 256-16 MB - normal binaries start at 256 MB, and jumps are limited
> +# 256-8 MB - normal binaries start at 256 MB, and jumps are limited
> # to +/- 16 MB
> -KLIBCSHAREDFLAGS = -Ttext 0x0f000200
> +KLIBCSHAREDFLAGS = -Ttext 0x0f800200
>
> # The kernel so far has both asm-ppc* and asm-powerpc.
> KLIBCARCHINCFLAGS = -I$(KLIBCKERNELOBJ)arch/$(KLIBCARCH)/include
^ permalink raw reply
* Re: >=2.6.17-rc4-mm1 kernel compilation problem (relocation truncated to fit)
From: H. Peter Anvin @ 2006-05-31 16:49 UTC (permalink / raw)
To: Nathan Pilatzke; +Cc: linuxppc-dev
In-Reply-To: <447DAAE4.7010503@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
Nathan Pilatzke wrote:
> I am getting compilation errors for 2.6.17-rc5-mm1 all the way back to
> 2.6.17-rc4-mm1. Kernel 2.6.17-rc3-mm1 compiles better for me (I get the
> undefined reference to __udivdi3 error that has been reported
> previously). Here are the errors that I get for 2.6.17-rc5-mm1:
>
Could you try the following patch?
-hpa
[-- Attachment #2: ppc32.so.address --]
[-- Type: text/plain, Size: 758 bytes --]
diff --git a/usr/klibc/arch/ppc/MCONFIG b/usr/klibc/arch/ppc/MCONFIG
index 8b51e65..e101453 100644
--- a/usr/klibc/arch/ppc/MCONFIG
+++ b/usr/klibc/arch/ppc/MCONFIG
@@ -13,9 +13,9 @@ KLIBCBITSIZE = 32
# Extra linkflags when building the shared version of the library
# This address needs to be reachable using normal inter-module
# calls, and work on the memory models for this architecture
-# 256-16 MB - normal binaries start at 256 MB, and jumps are limited
+# 256-8 MB - normal binaries start at 256 MB, and jumps are limited
# to +/- 16 MB
-KLIBCSHAREDFLAGS = -Ttext 0x0f000200
+KLIBCSHAREDFLAGS = -Ttext 0x0f800200
# The kernel so far has both asm-ppc* and asm-powerpc.
KLIBCARCHINCFLAGS = -I$(KLIBCKERNELOBJ)arch/$(KLIBCARCH)/include
^ permalink raw reply related
* howto allocate memory using scatter/gather
From: Muneeswaran P - TLS, Chennai @ 2006-05-31 15:40 UTC (permalink / raw)
To: kernelnewbies, linuxppc-embedded
Hi,
How do allocate the memory using scatter/gather method ?
Can I allocate memory of size of 50 KBytes using=20
scatter/gather list method and then memory map that area to=20
user space ?
=20
Please give me the way.
Regards,
Munees.
DISCLAIMER=20
The contents of this e-mail and any attachment(s) are confidential and =
intended for the=20
named recipient(s) only. It shall not attach any liability on the =
originator or HCL or its=20
affiliates. Any views or opinions presented in this email are solely =
those of the author and=20
may not necessarily reflect the opinions of HCL or its affiliates. Any =
form of reproduction,=20
dissemination, copying, disclosure, modification, distribution and / or =
publication of this=20
message without the prior written consent of the author of this e-mail =
is strictly=20
prohibited. If you have received this email in error please delete it =
and notify the sender=20
immediately. Before opening any mail and attachments please check them =
for viruses and=20
defect.
^ permalink raw reply
* >=2.6.17-rc4-mm1 kernel compilation problem (relocation truncated to fit)
From: Nathan Pilatzke @ 2006-05-31 14:40 UTC (permalink / raw)
To: linuxppc-dev
I am getting compilation errors for 2.6.17-rc5-mm1 all the way back to
2.6.17-rc4-mm1. Kernel 2.6.17-rc3-mm1 compiles better for me (I get the
undefined reference to __udivdi3 error that has been reported
previously). Here are the errors that I get for 2.6.17-rc5-mm1:
... (previous output snipped)
KLIBCCC usr/kinit/ipconfig/main.o
KLIBCCC usr/kinit/ipconfig/netdev.o
KLIBCCC usr/kinit/ipconfig/packet.o
KLIBCCC usr/kinit/ipconfig/dhcp_proto.o
KLIBCCC usr/kinit/ipconfig/bootp_proto.o
LD usr/kinit/ipconfig/lib.a
KLIBCLD usr/kinit/ipconfig/static/ipconfig
KLIBCLD usr/kinit/ipconfig/shared/ipconfig
usr/kinit/ipconfig/main.o: In function `complete_device':
main.c:(.text+0x6c): relocation truncated to fit: R_PPC_REL24 against
symbol `inet_ntoa' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0x84): relocation truncated to fit: R_PPC_REL24 against
symbol `printf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0xac): relocation truncated to fit: R_PPC_REL24 against
symbol `inet_ntoa' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0xc4): relocation truncated to fit: R_PPC_REL24 against
symbol `printf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0xe4): relocation truncated to fit: R_PPC_REL24 against
symbol `inet_ntoa' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0xfc): relocation truncated to fit: R_PPC_REL24 against
symbol `printf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0x134): relocation truncated to fit: R_PPC_REL24 against
symbol `printf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0x158): relocation truncated to fit: R_PPC_REL24 against
symbol `printf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0x17c): relocation truncated to fit: R_PPC_REL24 against
symbol `printf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0x19c): relocation truncated to fit: R_PPC_REL24 against
symbol `snprintf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0x1ac): additional relocation overflows omitted from the
output
make[3]: *** [usr/kinit/ipconfig/shared/ipconfig] Error 1
make[2]: *** [usr/kinit/ipconfig] Error 2
make[1]: *** [_usr_kinit] Error 2
make: *** [usr] Error 2
I assume that the errors I am seeing are regarding the klibc changes
that went into 2.6.17-rc4-mm1 (and apparently no one else is seeing
these errors as I would think that I would have found them reported
somewhere). I am running a gentoo system on an eMac 7450 PowerPC.
Here's my gcc info:
# gcc -v
Reading specs from /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/specs
Configured with: /var/tmp/portage/gcc-3.4.5-r1/work/gcc-3.4.5/configure
--prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/3.4.5
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include/g++-v3
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--enable-altivec --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --disable-multilib --disable-libgcj
--enable-languages=c,c++,f77 --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)
Need anything else? Can anyone offer some help or ideas?
Thanks, nathanp.
(please cc me on responses)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox