On 12/4/11 5:11 PM, Andriy Gapon wrote:
on 02/12/2011 17:30 m...@freebsd.org said the following:
On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon wrote:
on 02/12/2011 06:36 John Baldwin said the following:
Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when kdb was
active).
2011/12/7 Andriy Gapon :
> on 07/12/2011 00:11 Attilio Rao said the following:
>> I'd just change this check on panicstr:
>> @@ -606,9 +603,13 @@ kdb_trap(int type, int code, struct trapframe *tf)
>> intr = intr_disable();
>>
>> #ifdef SMP
>> - other_cpus = all_cpus;
>> - CPU_CLR(PCP
on 07/12/2011 00:11 Attilio Rao said the following:
> I'd just change this check on panicstr:
> @@ -606,9 +603,13 @@ kdb_trap(int type, int code, struct trapframe *tf)
> intr = intr_disable();
>
> #ifdef SMP
> - other_cpus = all_cpus;
> - CPU_CLR(PCPU_GET(cpuid), &other_cpus);
> -
2011/12/6 Andriy Gapon :
> on 06/12/2011 20:34 Attilio Rao said the following:
> [snip]
>> - I'm not entirely sure, why we want to disable interrupts at this
>> moment (before to stop other CPUs)?:
>
> Because I believe that stop_cpus_hard() should run in a context with
> interrupts
> and preempti
on 06/12/2011 20:34 Attilio Rao said the following:
[snip]
> - I'm not entirely sure, why we want to disable interrupts at this
> moment (before to stop other CPUs)?:
Because I believe that stop_cpus_hard() should run in a context with interrupts
and preemption disabled. Also, I believe that the
2011/11/13 Kostik Belousov :
> I was tricked into finishing the work by Andrey Gapon, who developed
> the patch to reliably stop other processors on panic. The patch
> greatly improves the chances of getting dump on panic on SMP host.
> Several people already saw the patchset, and I remember that
2011/12/4 Andriy Gapon :
> on 02/12/2011 19:18 Attilio Rao said the following:
>> BTW, I'm waiting for the details to settle (including the patch we
>> have been discussing internally about binding to CPU0 during ACPI
>> shutdown)
>
> I do not see strong interdependency between that patch and the p
2011/12/4 Andriy Gapon :
> on 21/11/2011 18:58 Attilio Rao said the following:
>> I would be very in favor about having a 'thread trampoline for KDB',
>> thus that it can use locks.
>
> I keep hearing the suggestion to add this trampoline, but I admit that I do
> not
> understand its technical mea
2011/12/2 Andriy Gapon :
> on 02/12/2011 20:40 John Baldwin said the following:
>> On 12/2/11 12:18 PM, Attilio Rao wrote:
>>> 2011/12/2 John Baldwin:
On 12/2/11 5:05 AM, Andriy Gapon wrote:
>
> on 02/12/2011 06:36 John Baldwin said the following:
>>
>> Ah, ok (I had thought SC
on 02/12/2011 19:18 Attilio Rao said the following:
> BTW, I'm waiting for the details to settle (including the patch we
> have been discussing internally about binding to CPU0 during ACPI
> shutdown)
I do not see strong interdependency between that patch and the panic patch.
BTW, I think that yo
on 21/11/2011 18:58 Attilio Rao said the following:
> I would be very in favor about having a 'thread trampoline for KDB',
> thus that it can use locks.
I keep hearing the suggestion to add this trampoline, but I admit that I do not
understand its technical meaning in this context. And also how i
on 02/12/2011 17:30 m...@freebsd.org said the following:
> On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon wrote:
>> on 02/12/2011 06:36 John Baldwin said the following:
>>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when
>>> kdb was
>>> active). But I think these two chang
on 02/12/2011 20:40 John Baldwin said the following:
> On 12/2/11 12:18 PM, Attilio Rao wrote:
>> 2011/12/2 John Baldwin:
>>> On 12/2/11 5:05 AM, Andriy Gapon wrote:
on 02/12/2011 06:36 John Baldwin said the following:
>
> Ah, ok (I had thought SCHEDULER_STOPPED was going to alway
2011/12/2 John Baldwin :
> On 12/2/11 12:18 PM, Attilio Rao wrote:
>>
>> 2011/12/2 John Baldwin:
>>>
>>> On 12/2/11 5:05 AM, Andriy Gapon wrote:
on 02/12/2011 06:36 John Baldwin said the following:
>
>
> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true
On 12/2/11 12:18 PM, Attilio Rao wrote:
2011/12/2 John Baldwin:
On 12/2/11 5:05 AM, Andriy Gapon wrote:
on 02/12/2011 06:36 John Baldwin said the following:
Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when
kdb was
active). But I think these two changes should cover c
2011/12/2 John Baldwin :
> On 12/2/11 5:05 AM, Andriy Gapon wrote:
>>
>> on 02/12/2011 06:36 John Baldwin said the following:
>>>
>>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when
>>> kdb was
>>> active). But I think these two changes should cover critical_exit() ok.
>>>
On 12/2/11 5:05 AM, Andriy Gapon wrote:
on 02/12/2011 06:36 John Baldwin said the following:
Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when kdb was
active). But I think these two changes should cover critical_exit() ok.
I attempted to start a discussion about this a
On Fri, Dec 2, 2011 at 2:05 AM, Andriy Gapon wrote:
> on 02/12/2011 06:36 John Baldwin said the following:
>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when kdb
>> was
>> active). But I think these two changes should cover critical_exit() ok.
>>
>
> I attempted to start
on 02/12/2011 06:36 John Baldwin said the following:
> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when kdb
> was
> active). But I think these two changes should cover critical_exit() ok.
>
I attempted to start a discussion about this a few times already :-)
Should we tr
On 12/1/11 4:42 PM, Andriy Gapon wrote:
on 01/12/2011 22:53 John Baldwin said the following:
On Thursday, December 01, 2011 3:42:24 pm Andriy Gapon wrote:
Returning to critical_exit, what do you think about the following patch?
I guess that it could be committed independently of / before the
SC
on 01/12/2011 22:53 John Baldwin said the following:
> On Thursday, December 01, 2011 3:42:24 pm Andriy Gapon wrote:
>> Returning to critical_exit, what do you think about the following patch?
>> I guess that it could be committed independently of / before the
>> SCHEDULER_STOPPED thing.
>>
>> comm
On Thursday, December 01, 2011 3:42:24 pm Andriy Gapon wrote:
> on 01/12/2011 20:49 John Baldwin said the following:
> > On Thursday, December 01, 2011 11:59:10 am Andriy Gapon wrote:
> >>
> >> [cc list trimmed]
> >>
> >> on 21/11/2011 18:32 John Baldwin said the following:
> >>> On Friday, Novembe
on 01/12/2011 20:49 John Baldwin said the following:
> On Thursday, December 01, 2011 11:59:10 am Andriy Gapon wrote:
>>
>> [cc list trimmed]
>>
>> on 21/11/2011 18:32 John Baldwin said the following:
>>> On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote:
on 17/11/2011 23:38 John Bald
On Thursday, December 01, 2011 11:59:10 am Andriy Gapon wrote:
>
> [cc list trimmed]
>
> on 21/11/2011 18:32 John Baldwin said the following:
> > On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote:
> >> on 17/11/2011 23:38 John Baldwin said the following:
> >>> On Thursday, November 17, 2
[cc list trimmed]
on 21/11/2011 18:32 John Baldwin said the following:
> On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote:
>> on 17/11/2011 23:38 John Baldwin said the following:
>>> On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote:
Hmmm, you could also make critical_ex
2011/11/21 John Baldwin :
> On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote:
>> on 17/11/2011 23:38 John Baldwin said the following:
>> > On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote:
>> >> Hmmm, you could also make critical_exit() not perform deferred preemptions
>> >> i
On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote:
> on 17/11/2011 23:38 John Baldwin said the following:
> > On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote:
> >> Hmmm, you could also make critical_exit() not perform deferred preemptions
> >> if SCHEDULER_STOPPED? That would
on 17/11/2011 23:38 John Baldwin said the following:
> On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote:
>> Hmmm, you could also make critical_exit() not perform deferred preemptions
>> if SCHEDULER_STOPPED? That would fix the recursion and still let the
>> preemption "work" when resum
Alexander Motin wrote:
> On 11/17/11 13:14, Kostik Belousov wrote:
> > On Thu, Nov 17, 2011 at 11:29:02AM +0200, Alexander Motin wrote:
> >> On 11/17/11 11:06, Kostik Belousov wrote:
> >>> On Thu, Nov 17, 2011 at 10:40:58AM +0200, Alexander Motin wrote:
> On 11/17/11 10:15, Kostik Belousov w
On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote:
> On Thursday, November 17, 2011 2:42:51 pm Andriy Gapon wrote:
> > on 17/11/2011 21:09 John Baldwin said the following:
> > > On Thursday, November 17, 2011 11:58:03 am Andriy Gapon wrote:
> > >> on 17/11/2011 18:37 John Baldwin said th
On Thursday, November 17, 2011 2:42:51 pm Andriy Gapon wrote:
> on 17/11/2011 21:09 John Baldwin said the following:
> > On Thursday, November 17, 2011 11:58:03 am Andriy Gapon wrote:
> >> on 17/11/2011 18:37 John Baldwin said the following:
> >>> On Thursday, November 17, 2011 4:47:42 am Andriy Ga
* run on another processor.
>> + */
>> + thread_lock(curthread);
>> + sched_bind(curthread, 0);
>> + thread_unlock(curthread);
>> + KASSERT(PCPU_GET(cpuid) == 0, ("boot: not running on c
thread_unlock(curthread);
> + KASSERT(PCPU_GET(cpuid) == 0, ("boot: not running on cpu 0"));
> + }
> #endif
> /* We're in the process of rebooting. */
> rebooting = 1;
Yes, you have contributed thi
2011/11/17 :
> On Thu, Nov 17, 2011 at 12:54 PM, Attilio Rao wrote:
>> 2011/11/17 Andriy Gapon :
>>> BTW, it is my opinion that we really should not let the debugger code call
>>> mi_switch for any reason.
>>
>> Yes, I agree with this, this is why the sched_bind() in boot() is
>> broken (immagine
On Thu, Nov 17, 2011 at 12:54 PM, Attilio Rao wrote:
> 2011/11/17 Andriy Gapon :
>> BTW, it is my opinion that we really should not let the debugger code call
>> mi_switch for any reason.
>
> Yes, I agree with this, this is why the sched_bind() in boot() is
> broken (immagine calling things like d
2011/11/17 Andriy Gapon :
> on 17/11/2011 21:09 John Baldwin said the following:
>> On Thursday, November 17, 2011 11:58:03 am Andriy Gapon wrote:
>>> on 17/11/2011 18:37 John Baldwin said the following:
On Thursday, November 17, 2011 4:47:42 am Andriy Gapon wrote:
> on 17/11/2011 10:34 An
on 17/11/2011 21:09 John Baldwin said the following:
> On Thursday, November 17, 2011 11:58:03 am Andriy Gapon wrote:
>> on 17/11/2011 18:37 John Baldwin said the following:
>>> On Thursday, November 17, 2011 4:47:42 am Andriy Gapon wrote:
on 17/11/2011 10:34 Andriy Gapon said the following:
>
On Thursday, November 17, 2011 11:58:03 am Andriy Gapon wrote:
> on 17/11/2011 18:37 John Baldwin said the following:
> > On Thursday, November 17, 2011 4:47:42 am Andriy Gapon wrote:
> >> on 17/11/2011 10:34 Andriy Gapon said the following:
> >>> on 17/11/2011 10:15 Kostik Belousov said the follow
On Thu, Nov 17, 2011 at 02:40:45PM +0200, Alexander Motin wrote:
> On 11/17/11 13:14, Kostik Belousov wrote:
> > On Thu, Nov 17, 2011 at 11:29:02AM +0200, Alexander Motin wrote:
> >> On 11/17/11 11:06, Kostik Belousov wrote:
> >>> On Thu, Nov 17, 2011 at 10:40:58AM +0200, Alexander Motin wrote:
> >
On Nov 13, 2011, at 3:32 AM, Kostik Belousov wrote:
> I was tricked into finishing the work by Andrey Gapon, who developed
> the patch to reliably stop other processors on panic. The patch
> greatly improves the chances of getting dump on panic on SMP host.
> Several people already saw the patch
on 17/11/2011 18:37 John Baldwin said the following:
> On Thursday, November 17, 2011 4:47:42 am Andriy Gapon wrote:
>> on 17/11/2011 10:34 Andriy Gapon said the following:
>>> on 17/11/2011 10:15 Kostik Belousov said the following:
I have the following change for eons on my test boxes. Withou
On Thursday, November 17, 2011 4:47:42 am Andriy Gapon wrote:
> on 17/11/2011 10:34 Andriy Gapon said the following:
> > on 17/11/2011 10:15 Kostik Belousov said the following:
> >> I have the following change for eons on my test boxes. Without it,
> >> I simply cannot get _any_ dump.
> >>
> >> dif
On 11/17/11 13:14, Kostik Belousov wrote:
> On Thu, Nov 17, 2011 at 11:29:02AM +0200, Alexander Motin wrote:
>> On 11/17/11 11:06, Kostik Belousov wrote:
>>> On Thu, Nov 17, 2011 at 10:40:58AM +0200, Alexander Motin wrote:
On 11/17/11 10:15, Kostik Belousov wrote:
> On Thu, Nov 17, 2011 at
On Thu, Nov 17, 2011 at 11:29:02AM +0200, Alexander Motin wrote:
> On 11/17/11 11:06, Kostik Belousov wrote:
> > On Thu, Nov 17, 2011 at 10:40:58AM +0200, Alexander Motin wrote:
> >> On 11/17/11 10:15, Kostik Belousov wrote:
> >>> On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote:
> >
on 17/11/2011 10:34 Andriy Gapon said the following:
> on 17/11/2011 10:15 Kostik Belousov said the following:
>> I have the following change for eons on my test boxes. Without it,
>> I simply cannot get _any_ dump.
>>
>> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c
>> index 10b89c7..a38e42f
On 11/17/11 11:06, Kostik Belousov wrote:
> On Thu, Nov 17, 2011 at 10:40:58AM +0200, Alexander Motin wrote:
>> On 11/17/11 10:15, Kostik Belousov wrote:
>>> On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote:
On 17.11.2011 00:21, Andriy Gapon wrote:
> on 16/11/2011 21:27 Fabi
On Thu, Nov 17, 2011 at 10:40:58AM +0200, Alexander Motin wrote:
> On 11/17/11 10:15, Kostik Belousov wrote:
> > On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote:
> >> On 17.11.2011 00:21, Andriy Gapon wrote:
> >>> on 16/11/2011 21:27 Fabian Keil said the following:
> Kostik Bel
On 11/17/11 10:15, Kostik Belousov wrote:
> On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote:
>> On 17.11.2011 00:21, Andriy Gapon wrote:
>>> on 16/11/2011 21:27 Fabian Keil said the following:
Kostik Belousov wrote:
> I was tricked into finishing the work by Andrey Ga
on 17/11/2011 10:15 Kostik Belousov said the following:
> On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote:
>> On 17.11.2011 00:21, Andriy Gapon wrote:
>>> Going further up the stack one can come up with the following proposals:
>>> - check SCHEDULER_STOPPED() swi_sched() and return
On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote:
> On 17.11.2011 00:21, Andriy Gapon wrote:
> >on 16/11/2011 21:27 Fabian Keil said the following:
> >>Kostik Belousov wrote:
> >>
> >>>I was tricked into finishing the work by Andrey Gapon, who developed
> >>>the patch to reliably st
On 17.11.2011 00:21, Andriy Gapon wrote:
on 16/11/2011 21:27 Fabian Keil said the following:
Kostik Belousov wrote:
I was tricked into finishing the work by Andrey Gapon, who developed
the patch to reliably stop other processors on panic. The patch
greatly improves the chances of getting dum
on 16/11/2011 21:27 Fabian Keil said the following:
> Kostik Belousov wrote:
>
>> I was tricked into finishing the work by Andrey Gapon, who developed
>> the patch to reliably stop other processors on panic. The patch
>> greatly improves the chances of getting dump on panic on SMP host.
>
> I t
Kostik Belousov wrote:
> I was tricked into finishing the work by Andrey Gapon, who developed
> the patch to reliably stop other processors on panic. The patch
> greatly improves the chances of getting dump on panic on SMP host.
I tested the patch trying to get a dump (from the debugger) for
ke
on 14/11/2011 15:08 Kostik Belousov said the following:
> On Mon, Nov 14, 2011 at 12:06:48PM +0200, Andriy Gapon wrote:
>> On a more serious note:
>> - some code in my latest version of the patch was contributed by or was based
>> on the code or ideas contributed by jhb and mdf (so that attribution
On Mon, Nov 14, 2011 at 12:06:48PM +0200, Andriy Gapon wrote:
> on 13/11/2011 10:32 Kostik Belousov said the following:
> > I was tricked into finishing the work by Andrey Gapon, who developed the
> > patch to reliably stop other processors on panic. The patch greatly
> > improves the chances of g
on 13/11/2011 10:32 Kostik Belousov said the following:
> I was tricked into finishing the work by Andrey Gapon, who developed the
> patch to reliably stop other processors on panic. The patch greatly
> improves the chances of getting dump on panic on SMP host. Several people
> already saw the pat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kostik,
thanks a lot!
I am not really sorry for taking part in tricking you into doing this :)
I guess I now own that cognac back :)
on 13/11/2011 10:32 Kostik Belousov said the following:
> I was tricked into finishing the work by Andrey Gapon, who
I was tricked into finishing the work by Andrey Gapon, who developed
the patch to reliably stop other processors on panic. The patch
greatly improves the chances of getting dump on panic on SMP host.
Several people already saw the patchset, and I remember that Andrey
posted it to some lists.
The
The patches can be found at the same locations:
head - http://people.freebsd.org/~avg/stop_scheduler_on_panic.diff
stable/8 - http://people.freebsd.org/~avg/stop_scheduler_on_panic.8.x.diff
Additionally, if you use a USB keyboard, then the following patch is required
for
proper operation in post
59 matches
Mail list logo