Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

[Lee Revell]

Are there any known incompatibilities with oprofile and the RT preempt patch?

Lee

Oops: 0000 [#1]
PREEMPT 
Modules linked in: realtime commoncap af_packet via_rhine mii crc32 ehci_hcd usbhid uhci_hcd usbcore via_
agp agpgart evdev snd_rtctimer snd_emu10k1_synth snd_emu10k1 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_emux_synth snd_seq_virmidi s
nd_seq_midi_emul snd_seq_midi snd_rawmidi snd_seq_oss snd_seq_midi_event snd_seq snd_timer snd_seq_device snd_hwdep snd_util_mem snd snd_page_
alloc
CPU:    0
EIP:    0060:[oprofilefs_str_to_user+21/64]    Not tainted VLI
EFLAGS: 00010246   (2.6.11-rc2-RT-V0.7.37-01) 
EIP is at oprofilefs_str_to_user+0x15/0x40
eax: 00000000   ebx: 00000000   ecx: ffffffff   edx: 00000000
esi: d593b6a0   edi: 00000000   ebp: cb966f6c   esp: cb966f68
ds: 007b   es: 007b   ss: 0068   preempt: 00000001
Process cat (pid: 3290, threadinfo=cb966000 task=d083ce10)
Stack: cb966fa8 cb966f90 c01529ec 00000000 0804d038 00001000 cb966fa8 d593b6a0 
       fffffff7 0804d038 cb966fbc c0152cc1 d593b6a0 0804d038 00001000 cb966fa8 
       00000000 00000000 00000000 00000003 00001000 cb966000 c01026a4 00000003 
Call Trace:
  [show_stack+133/160] show_stack+0x85/0xa0 (32)
  [show_registers+299/400] show_registers+0x12b/0x190 (40)
  [die+219/384] die+0xdb/0x180 (52)
  [do_page_fault+824/1629] do_page_fault+0x338/0x65d (212)
  [error_code+43/48] error_code+0x2b/0x30 (64)
  [vfs_read+188/320] vfs_read+0xbc/0x140 (36)
  [sys_read+65/112] sys_read+0x41/0x70 (44)
  [syscall_call+7/11] syscall_call+0x7/0xb (-4028)
---------------------------
| preempt count: 00000002 ]
| 2-level deep critical section nesting:
----------------------------------------
.. [die+56/384] .... die+0x38/0x180
.....[do_page_fault+824/1629] ..   ( <= do_page_fault+0x338/0x65d)
.. [print_traces+19/80] .... print_traces+0x13/0x50
.....[show_stack+133/160] ..   ( <= show_stack+0x85/0xa0)

Code: 89 43 44 89 53 48 89 d8 8b 5d fc 89 ec 5d c3 8d b4 26 00 00 00 00 55 89 e5 57 e8 ab 49 ee ff 8b 55 
08 31 c0 b9 ff ff ff ff 89 d7 <f2> ae f7 d1 49 51 52 8b 45 14 8b 7d 10 50 57 8b 4d 0c 51 e8 73 
  <1>BUG: Unable to handle kernel NULL pointer dereference at virtual address 00000000
  printing eip:
c02284a5
*pde = 00000000

Re: Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

[Philippe Elie]

On Sun, 13 Feb 2005 at 01:07 +0000, Lee Revell wrote:

> Are there any known incompatibilities with oprofile and the RT preempt patch?
> 
> Lee
> 
> Oops: 0000 [#1]
> PREEMPT 

> alloc
> CPU:    0
> EIP:    0060:[oprofilefs_str_to_user+21/64]    Not tainted VLI
> EFLAGS: 00010246   (2.6.11-rc2-RT-V0.7.37-01) 
> EIP is at oprofilefs_str_to_user+0x15/0x40
> eax: 00000000   ebx: 00000000   ecx: ffffffff   edx: 00000000
> esi: d593b6a0   edi: 00000000   ebp: cb966f6c   esp: cb966f68
> ds: 007b   es: 007b   ss: 0068   preempt: 00000001
> Process cat (pid: 3290, threadinfo=cb966000 task=d083ce10)
> Stack: cb966fa8 cb966f90 c01529ec 00000000 0804d038 00001000 cb966fa8 d593b6a0 
>        fffffff7 0804d038 cb966fbc c0152cc1 d593b6a0 0804d038 00001000 cb966fa8 
>        00000000 00000000 00000000 00000003 00001000 cb966000 c01026a4 00000003 

oprofile_files.c:
 oprofilefs_str_to_user(oprofile_ops.cpu_type, buf, count, offset);

oprofilefs.c:
ssize_t oprofilefs_str_to_user(char const * str, char __user * buf,
	size_t count, loff_t * offset)
{
	return simple_read_from_buffer(buf, count, offset, str, strlen(str));
}

oprofile_ops.cpu_type == NULL, this has been fixed 3 weeks ago,
can you retry with -rc4 ?

Philippe Elie

Re: Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> Are there any known incompatibilities with oprofile and the RT preempt
> patch?

not that i know of. Does the same thing work fine with !PREEMPT_RT? (or
the patch unapplied?)

	Ingo

Re: Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

[Peter Zijlstra]

On Sun, 2005-02-13 at 01:07 -0500, Lee Revell wrote:
> Are there any known incompatibilities with oprofile and the RT preempt patch?

non so far for me, I use that combo quite a lot at work. However I do
use the -mm series which might contain oprofile updates not found in
plain -rc.

Kind regards,

PeterZ

PS. Ingo: Any plans to move the RT tree to -mm again (would save me time
patching; does keep me practised though)?

Re: Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

[Ingo Molnar]

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> PS. Ingo: Any plans to move the RT tree to -mm again (would save me
> time patching; does keep me practised though)?

not at the moment - but you might want to make your port available to
others?

	Ingo

Re: Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

[Peter Zijlstra]

On Sun, 2005-02-13 at 14:16 +0100, Ingo Molnar wrote:
> * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> 
> > PS. Ingo: Any plans to move the RT tree to -mm again (would save me
> > time patching; does keep me practised though)?
> 
> not at the moment - but you might want to make your port available to
> others?

Sure, I'll post the diff next time I do one.

-- 
Peter Zijlstra <a.p.zijlstra@chello.nl>

Re: Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

[Ingo Molnar]

* Philippe Elie <phil.el@wanadoo.fr> wrote:

> oprofile_ops.cpu_type == NULL, this has been fixed 3 weeks ago, can
> you retry with -rc4 ?

i've uploaded an -rc4 port of the -RT tree half an hour ago (-39-00).

	Ingo

Re: Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

[Lee Revell]

On Sun, 2005-02-13 at 14:30 +0100, Ingo Molnar wrote:
> * Philippe Elie <phil.el@wanadoo.fr> wrote:
> 
> > oprofile_ops.cpu_type == NULL, this has been fixed 3 weeks ago, can
> > you retry with -rc4 ?
> 
> i've uploaded an -rc4 port of the -RT tree half an hour ago (-39-00).
> 

OK, I will test that.  FWIW I was running with PREEMPT_DESKTOP.

Maybe my CPU being a Cyrix III (VIA EPIA board) has something to do with
it.  I noticed that this CPU model is not mentioned on the oprofile web
site.

Lee

Re: Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

[Dave Jones]

On Sun, Feb 13, 2005 at 07:55:35PM -0500, Lee Revell wrote:
 > On Sun, 2005-02-13 at 14:30 +0100, Ingo Molnar wrote:
 > > * Philippe Elie <phil.el@wanadoo.fr> wrote:
 > > 
 > > > oprofile_ops.cpu_type == NULL, this has been fixed 3 weeks ago, can
 > > > you retry with -rc4 ?
 > > 
 > > i've uploaded an -rc4 port of the -RT tree half an hour ago (-39-00).
 > > 
 > 
 > OK, I will test that.  FWIW I was running with PREEMPT_DESKTOP.
 > 
 > Maybe my CPU being a Cyrix III (VIA EPIA board) has something to do with
 > it.  I noticed that this CPU model is not mentioned on the oprofile web
 > site.

The C3 doesn't have any performance counters that oprofile can use.

		Dave

Re: Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

[Lee Revell]

On Sun, 2005-02-13 at 14:30 +0100, Ingo Molnar wrote:
> * Philippe Elie <phil.el@wanadoo.fr> wrote:
> 
> > oprofile_ops.cpu_type == NULL, this has been fixed 3 weeks ago, can
> > you retry with -rc4 ?
> 
> i've uploaded an -rc4 port of the -RT tree half an hour ago (-39-00).
> 

Thanks, -rc4 did fix the bug.

I noticed profiling the kernel with PREEMPT_DESKTOP that mcount and
__mcount add quite a bit of overhead.  Something like .5% CPU each.
Sorry, I didn't save the oprofile output.

So, disable CONFIG_MCOUNT if you want minimal overhead from the RT
patches.  IIRC it was previously stated that the latency tracing
overhead could be mostly avoided by disabling it at runtime.

Lee 

Re: Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> I noticed profiling the kernel with PREEMPT_DESKTOP that mcount and
> __mcount add quite a bit of overhead.  Something like .5% CPU each.
> Sorry, I didn't save the oprofile output.
> 
> So, disable CONFIG_MCOUNT if you want minimal overhead from the RT
> patches.  IIRC it was previously stated that the latency tracing
> overhead could be mostly avoided by disabling it at runtime.

yes - most of the overhead can be disabled, but not all. 1% CPU time
might sound alot but when compared against 10% (or more) tracing
overehad it's small. The least overhead comes from disabling tracing in
the .config.

	Ingo