On 05/25/11 09:05, Jeff Ross wrote:
On 05/24/11 01:52, Artur Grabowski wrote:
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_s
> > 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.
> >
>
On 05/24/11 01:52, Artur Grabowski wrote:
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
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
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 happenin
Is this worthy of a sendbug report?
Jeff
ddb{0}> show panic
the kernel did not panic
ddb{0}> trace
handle_workitem_freeblocks(da4d70a8,e3a50ecc,daeba000,daea53b8) at
handle_worki
tem_freeblocks+0x2b
process_worklist_item(0,0,e034ff5c,dae7f0ac,0) at
process_worklist_item+0x171
softdep_process_
6 matches
Mail list logo
