Running opcontrol --reset on an em64t P4 yields the following (clearly
there must be a reason why it's disabled but i'll address that
seperately);
Unable to handle kernel NULL pointer dereference at virtual address
00000000
printing eip:
c0562cf4
*pde = 00000000
Oops: 0000 [#1]
PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 1
EIP: 0060:[<c0562cf4>] Not tainted VLI
EFLAGS: 00010246 (2.6.11-rc2)
EIP is at oprofilefs_str_to_user+0x24/0x50
eax: 00000000 ebx: 00000000 ecx: ffffffff edx: ffffffff
esi: 00001000 edi: 00000000 ebp: ec477f78 esp: ec477f60
ds: 007b es: 007b ss: 0068
Process cat (pid: 2810, threadinfo=ec476000 task=f739ead0)
Stack: 00000000 c016806a 0804d858 c072aa00 ec9eff58 00001000 ec477f9c c015e1e7
ec477fa8 00000000 00000000 0804d858 ec9eff58 fffffff7 0804d858 ec477fbc
c015e50d ec477fa8 00000000 00000000 00000000 00000003 00001000 ec476000
Call Trace:
[<c0103fea>] show_stack+0x7a/0x90
[<c0104176>] show_registers+0x156/0x1d0
[<c01043a0>] die+0x100/0x190
[<c01170be>] do_page_fault+0x45e/0x644
[<c0103c77>] error_code+0x2b/0x30
[<c015e1e7>] vfs_read+0xc7/0x160
[<c015e50d>] sys_read+0x3d/0x70
[<c0103105>] sysenter_past_esp+0x52/0x75
Code: 90 90 90 90 90 90 90 55 89 e5 83 ec 18 89 5d f4 31 db 89 55 f0 ba ff
ff ff ff 89 75 f8 89 ce 89 d1 89 7d fc 89 c7 89 04 24 89 d8 <f2> ae f7 d1
49 89 4c 24 04 8b 45 f0 89 f2 8b 4d 08 e8 66 e4 c1
->cpu_type is NULL since p4_init skipped this specific processor.
Signed-off-by: Zwane Mwaikambo <[email protected]>
===== drivers/oprofile/oprofile_files.c 1.7 vs edited =====
--- 1.7/drivers/oprofile/oprofile_files.c 2005-01-04 19:48:23 -07:00
+++ edited/drivers/oprofile/oprofile_files.c 2005-01-28 11:36:25 -07:00
@@ -63,7 +63,9 @@ static struct file_operations pointer_si
static ssize_t cpu_type_read(struct file * file, char __user * buf, size_t count, loff_t * offset)
{
- return oprofilefs_str_to_user(oprofile_ops.cpu_type, buf, count, offset);
+ if (oprofile_ops.cpu_type)
+ return oprofilefs_str_to_user(oprofile_ops.cpu_type, buf, count, offset);
+ return -EIO;
}
On Fri, Jan 28, 2005 at 12:06:19PM -0700, Zwane Mwaikambo wrote:
> ===== drivers/oprofile/oprofile_files.c 1.7 vs edited =====
> --- 1.7/drivers/oprofile/oprofile_files.c 2005-01-04 19:48:23 -07:00
> +++ edited/drivers/oprofile/oprofile_files.c 2005-01-28 11:36:25 -07:00
> @@ -63,7 +63,9 @@ static struct file_operations pointer_si
>
> static ssize_t cpu_type_read(struct file * file, char __user * buf, size_t count, loff_t * offset)
> {
> - return oprofilefs_str_to_user(oprofile_ops.cpu_type, buf, count, offset);
> + if (oprofile_ops.cpu_type)
> + return oprofilefs_str_to_user(oprofile_ops.cpu_type, buf, count, offset);
> + return -EIO;
This is wrong: you need to investigate why .cpu_type isn't set: in
particular, it should have fallen back to timer mode.
oprofile_arch_init() should have returned -ENODEV, and that should have
set timer mode.
Unfortunately bkcvs seems out of date so I can't even look at this
myself.
john
On Sat, 29 Jan 2005, John Levon wrote:
> On Fri, Jan 28, 2005 at 12:06:19PM -0700, Zwane Mwaikambo wrote:
>
> > ===== drivers/oprofile/oprofile_files.c 1.7 vs edited =====
> > --- 1.7/drivers/oprofile/oprofile_files.c 2005-01-04 19:48:23 -07:00
> > +++ edited/drivers/oprofile/oprofile_files.c 2005-01-28 11:36:25 -07:00
> > @@ -63,7 +63,9 @@ static struct file_operations pointer_si
> >
> > static ssize_t cpu_type_read(struct file * file, char __user * buf, size_t count, loff_t * offset)
> > {
> > - return oprofilefs_str_to_user(oprofile_ops.cpu_type, buf, count, offset);
> > + if (oprofile_ops.cpu_type)
> > + return oprofilefs_str_to_user(oprofile_ops.cpu_type, buf, count, offset);
> > + return -EIO;
>
> This is wrong: you need to investigate why .cpu_type isn't set: in
> particular, it should have fallen back to timer mode.
> oprofile_arch_init() should have returned -ENODEV, and that should have
> set timer mode.
>
> Unfortunately bkcvs seems out of date so I can't even look at this
> myself.
Yes you are right, i checked bk and there was a lot of shuffling about due
to the timer override. But it looks like we're depending on the timer
variable being set. We could always just run timer_init if cpu_type is not
set.
Signed-off-by: Zwane Mwaikambo <[email protected]>
===== drivers/oprofile/oprof.c 1.11 vs edited =====
--- 1.11/drivers/oprofile/oprof.c 2005-01-04 19:48:23 -07:00
+++ edited/drivers/oprofile/oprof.c 2005-01-29 09:38:24 -07:00
@@ -157,7 +157,7 @@ static int __init oprofile_init(void)
oprofile_arch_init(&oprofile_ops);
- if (timer) {
+ if (timer || !oprofile_ops.cpu_type) {
printk(KERN_INFO "oprofile: using timer interrupt.\n");
oprofile_timer_init(&oprofile_ops);
}
On Sat, Jan 29, 2005 at 09:47:42AM -0700, Zwane Mwaikambo wrote:
> > Unfortunately bkcvs seems out of date so I can't even look at this
> > myself.
>
> Yes you are right, i checked bk and there was a lot of shuffling about due
> to the timer override. But it looks like we're depending on the timer
> variable being set. We could always just run timer_init if cpu_type is not
> set.
>
> Signed-off-by: Zwane Mwaikambo <[email protected]>
>
> ===== drivers/oprofile/oprof.c 1.11 vs edited =====
> --- 1.11/drivers/oprofile/oprof.c 2005-01-04 19:48:23 -07:00
> +++ edited/drivers/oprofile/oprof.c 2005-01-29 09:38:24 -07:00
> @@ -157,7 +157,7 @@ static int __init oprofile_init(void)
>
> oprofile_arch_init(&oprofile_ops);
>
> - if (timer) {
> + if (timer || !oprofile_ops.cpu_type) {
Looks like you're still on the broken bkcvs, which is missing this
patch:
http://linus.bkbits.net:8080/linux-2.5/[email protected]?nav=index.html|ChangeSet@-2w
which AFAICS is the correct solution to the problem.
regards,
john
On Sat, 29 Jan 2005, John Levon wrote:
> Looks like you're still on the broken bkcvs, which is missing this
> patch:
>
> http://linus.bkbits.net:8080/linux-2.5/[email protected]?nav=index.html|ChangeSet@-2w
>
> which AFAICS is the correct solution to the problem.
Hmm i was actually using BK and not BKCVS and had pulled after the 25th.
Anyway thanks, that should do it then.