On 12/20/11 16:55, Robert Watson wrote:
> On Tue, 20 Dec 2011, Attilio Rao wrote:
>
>> As we are here, however, I have a question for Robert here: do you
>> think we should support the _ddb() variant of options even in the case
>> DDB is not enabled in the kernel?
>
> It's possible that _ddb() sh
On Tue, Dec 20, 2011 at 6:32 AM, John Baldwin wrote:
> On Tuesday, December 20, 2011 9:22:48 am m...@freebsd.org wrote:
>> On Tue, Dec 20, 2011 at 5:52 AM, John Baldwin wrote:
>> > On Saturday, December 17, 2011 10:41:15 pm m...@freebsd.org wrote:
>> >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander
On Tue, 20 Dec 2011, Attilio Rao wrote:
As we are here, however, I have a question for Robert here: do you think we
should support the _ddb() variant of options even in the case DDB is not
enabled in the kernel?
It's possible that _ddb() should be spelled _unlocked(), or perhaps _debug(),
bu
2011/12/20 John Baldwin :
> On Tuesday, December 20, 2011 9:20:09 am Attilio Rao wrote:
>> 2011/12/20 John Baldwin :
>> > On Saturday, December 17, 2011 10:41:15 pm m...@freebsd.org wrote:
>> >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev
>> >> wrote:
>> >> > On Sun, 18 Dec 2011 01:09:00 +0
On Tuesday, December 20, 2011 9:20:09 am Attilio Rao wrote:
> 2011/12/20 John Baldwin :
> > On Saturday, December 17, 2011 10:41:15 pm m...@freebsd.org wrote:
> >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wrote:
> >> > On Sun, 18 Dec 2011 01:09:00 +0100
> >> > "O. Hartmann" wrote:
> >> >
On Tuesday, December 20, 2011 9:22:48 am m...@freebsd.org wrote:
> On Tue, Dec 20, 2011 at 5:52 AM, John Baldwin wrote:
> > On Saturday, December 17, 2011 10:41:15 pm m...@freebsd.org wrote:
> >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wrote:
> >> > On Sun, 18 Dec 2011 01:09:00 +0100
>
On Tue, Dec 20, 2011 at 5:52 AM, John Baldwin wrote:
> On Saturday, December 17, 2011 10:41:15 pm m...@freebsd.org wrote:
>> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wrote:
>> > On Sun, 18 Dec 2011 01:09:00 +0100
>> > "O. Hartmann" wrote:
>> >
>> >> Sleeping thread (tid 100033, pid 16)
2011/12/20 John Baldwin :
> On Saturday, December 17, 2011 10:41:15 pm m...@freebsd.org wrote:
>> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wrote:
>> > On Sun, 18 Dec 2011 01:09:00 +0100
>> > "O. Hartmann" wrote:
>> >
>> >> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock
>>
on 20/12/2011 15:52 John Baldwin said the following:
> -#ifdef DDB
> - db_trace_thread(td, -1);
> +#ifdef STACK
> + stack_zero(&st);
> + stack_save_td(&st, td);
> + stack_print_ddb(&st);
> #endif
This leads to an idea
On Saturday, December 17, 2011 10:41:15 pm m...@freebsd.org wrote:
> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wrote:
> > On Sun, 18 Dec 2011 01:09:00 +0100
> > "O. Hartmann" wrote:
> >
> >> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock
> >> panic: sleeping thread
> >> cp
On 12/18/11 02:45, Alexander Kabaev wrote:
> On Sun, 18 Dec 2011 01:09:00 +0100
> "O. Hartmann" wrote:
>
>> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock
>> panic: sleeping thread
>> cpuid = 0
>>
>> PID 16 is always USB on my box.
>
> You really need to give us a backtrace when
On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev wrote:
> On Sun, 18 Dec 2011 01:09:00 +0100
> "O. Hartmann" wrote:
>
>> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock
>> panic: sleeping thread
>> cpuid = 0
>>
>> PID 16 is always USB on my box.
>
> You really need to give us a ba
On Sun, 18 Dec 2011 01:09:00 +0100
"O. Hartmann" wrote:
> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock
> panic: sleeping thread
> cpuid = 0
>
> PID 16 is always USB on my box.
You really need to give us a backtrace when you quote panics. It is
impossible to make any sense of t
Since three days for now I get a panic when I shutdown or reboot my
FreeBSD 10.0-CURREN/amd64 box:
Sleeping thread (tid 100033, pid 16) owns a non sleepable lock
panic: sleeping thread
cpuid = 0
PID 16 is always USB on my box.
Any advice or tip to get rid of it?
Oliver
signature.asc
Descript
14 matches
Mail list logo