There is no such thing as a "bad frame pointer crash". That's a
diagnostic message from ddb that it can't find anything further up the
stack trace, which is correct, since the function sched_sync is on top
of the stack.
Now, what the kernel tells you is that your kernel didn't panic, so
I'm not entirely sure how you end up in ddb, since there is no panic
or fault in the traceback. What does the traceback on other cpus show?
"machine ddbcpu 0" will switch to cpu0, make a trace on each of them.
//art
On Mon, May 23, 2011 at 5:42 PM, Jeff Ross <jr...@openvistas.net> wrote:
> Hi all,
>
> I have a server that I'm trying to get on-line that continues to drop into
> ddb with a bad frame pointer crash. Right now it is only running an hourly
> rsync from the server it is to replace on an hourly basis. The server will
> run for no more than a week without this happening but sometimes it will
> crash after only a day.
>
> I filed a PR 6593 on Apr 26 on this. Right now it is running i386 -current
> from Apr 27, upgraded after I filed the PR.
>
> The message I get at the ddb prompt is virtually identical to the one
below.
>
> If anyone has any ideas on how I can further debug this, I'd like to know.
> I was hoping to use the upcoming 3 day weekend to make the final switch to
> this new server but I can't see how that will happen if I can't keep it
> running.
>
> Trace, ps and dmesg below.
>
> Thanks,
>
> Jeff Ross
>
> jross@mail:/home/jross $ sudo cu -l /dev/cua00
> Password:
> Connected
>
> ddb{2}> show panic
> the kernel did not panic
> ddb{2}> trace
> handle_workitem_freeblocks(d9d2ee78,e2ac1860,e0352f2c,d03e1c95) at
> handle_worki
> tem_freeblocks+0x2b
> process_worklist_item(0,0,e0352f5c,d03e1eff,e0352f44) at
> process_worklist_item+
> 0x171
> softdep_process_worklist(0,28,d08c4bbb,0,d03d2ec3) at
> softdep_process_worklist+
> 0x13f
> sched_sync(daea43b8) at sched_sync+0xe5
> Bad frame pointer: 0xd0ba9e88
