Hi Steven,
> > >Over the weekend I ran a test that rebooted the PC permanently.
> > >After about 400 reboots I got another NULL pointer dereference.
> > >However the slub_delay_ctor_on_rt.patch has not been reverted yet.
> > >And: This looks somehow differently than the previous BUGs.
> > >
> > >
> > >[ 3.299329] BUG: unable to handle kernel NULL pointer dereference at
> 0000008c
> > >[ 3.299332] IP: [<c10df66c>] function_trace_call+0xc/0x190
> >
> > This is
> > | static void
> > | function_trace_call(unsigned long ip, unsigned long parent_ip,
> > | struct ftrace_ops *op, struct pt_regs *pt_regs)
> > | {
> > | struct trace_array *tr = op->private;
> > |…
> > |
> > | if (unlikely(!tr->function_enabled))
> > | return;
> >
> > and it looks like tr is null. BUG_ON(!tr) should prove this.
> > Steven, is it somehow possible that on module load we get "op" set
> > without its private member initialized?
> >
>
> What's the test that was run, and how did it enable function tracing?
The tracing was enabled within an init script using the following bash commands:
if ! grep -q "/sys/kernel/debug" /proc/mounts; then
mount -t debugfs nodev /sys/kernel/debug
fi
if [ -d /sys/kernel/debug/tracing ]; then
(
cd /sys/kernel/debug/tracing
echo "function" > current_tracer
echo "1" > tracing_on
echo "1" > /proc/sys/kernel/ftrace_dump_on_oops
)
fi
The test was to reboot the PC permanently (every minute).
The reboot has been initiated by another PC that remotely controls the PC under test.
Regards
Mathias
��.n��������+%������w��{.n�����{�����ǫ���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
