Hello, I wrote:
>>If there are no objections, I will commit the following patch.
>>--
>>This patch fixes some corner cases where KGDB will silently hang or
>>kill the system, if a user accidentally tries to source step into a
>>spin_unlock() call or source step in on a macro containing
>>smp_pro
Sergei Shtylyov wrote:
>>If there are no objections, I will commit the following patch.
Sorry for the belated objections. :-<
>>Signed-off-by: Jason Wessel <[EMAIL PROTECTED]>
>>Index: linux-2.6.21.1/kernel/kgdb.c
>>===
>>--- lin
Hello.
Jason Wessel wrote:
> If there are no objections, I will commit the following patch.
> --
> This patch fixes some corner cases where KGDB will silently hang or
> kill the system, if a user accidentally tries to source step into a
> spin_unlock() call or source step in on a macro containi
Hello.
Jason Wessel wrote:
>>> If not can you provide me with a test case to see the problem?
>>Well, for example, with 2.6.18-rt7 kernel, stepping into
>> smp_processor_id() was blowing away U-Boot (!) on my PPC board (even
>> in PREEMPT_DESKTOP mode)... On x86, stepping past preempt_disa
Jason Wessel wrote:
>> But what about powerpc.patch which includes only the copying of
>> thread info to the critical exception stack in arch/ppc/ and I've
>> already incorporated the same code into arch/powerpc/ port -- should I
>> contrarywise separate it?
> Out of all the patches, I w
Hello.
Jason Wessel wrote:
> I'll try to get Sergei's latest patches in and finish up the 2.6.22-rc1
> tree in the next day or so.
It turned out that I *still* have patches to submit -- will do this today.
> Jason.
WBR, Sergei
-
Sergei Shtylyov wrote:
> Hello.
>
>
> But what about powerpc.patch which includes only the copying of thread
> info to the critical exception stack in arch/ppc/ and I've already
> incorporated the same code into arch/powerpc/ port -- should I contrarywise
> separate it?
>
>
Out of all
Sergei Shtylyov wrote:
> Hello.
>
> Jason Wessel wrote:
>
>> I'll try to get Sergei's latest patches in and finish up the
>> 2.6.22-rc1 tree in the next day or so.
>
>It turned out that I *still* have patches to submit -- will do this
> today.
>
I am patching stuff into both trees at this po
Hello.
Tom Rini wrote:
>>>This patch is committed in the linux2_6_21_uprev branch across:
>>>core-lite.patch core.patch i386-lite.patch x86_64-lite.patch
>>BTW, what's the reason we *still* have both
>>{core|i386|ia64|powerpc|x86_64}-lite.patch and
>>core{core|i386|ia64|powerpc|x86_64}.pat
Bob Picco wrote:
> Well I thought that core related patches weren't destined for mainline.
> At least I think that was the objective in 2006. For ia64, a coworker
> attempted to use Jason's git repository. The details aren't
> known to me, but he wasn't successful. The ia64.patch in core would
> ca
Sergei Shtylyov wrote: [Sat May 19 2007, 02:54:00PM EDT]
> Jason Wessel wrote:
>
> > This patch is committed in the linux2_6_21_uprev branch across:
> > core-lite.patch core.patch i386-lite.patch x86_64-lite.patch
>
> BTW, what's the reason we *still* have both
> {core|i386|ia64|powerpc|x86
On Sat, May 19, 2007 at 10:54:00PM +0400, Sergei Shtylyov wrote:
> Jason Wessel wrote:
>
> > This patch is committed in the linux2_6_21_uprev branch across:
> > core-lite.patch core.patch i386-lite.patch x86_64-lite.patch
>
> BTW, what's the reason we *still* have both
> {core|i386|ia64|powe
Jason Wessel wrote:
> This patch is committed in the linux2_6_21_uprev branch across:
> core-lite.patch core.patch i386-lite.patch x86_64-lite.patch
BTW, what's the reason we *still* have both
{core|i386|ia64|powerpc|x86_64}-lite.patch and
core{core|i386|ia64|powerpc|x86_64}.patch? Why not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason Wessel wrote:
> Pete/Piet Delaney wrote:
>> Sounds great to me; avoiding spin locks() is a hassle.
>>
>> Ever noticed a problem with kgdb surviving a weekend of non-use?
>>
>> I hit a breakpoint on Saturday and hoped to continue looking at it
>>
Jason Wessel wrote:
> This patch fixes some corner cases where KGDB will silently hang or
> kill the system, if a user accidentally tries to source step into a
> spin_unlock() call or source step in on a macro containing
> smp_processor_id(). The use of raw_smp_processor_id is desired in
> kernel/
Sergei Shtylyov wrote:
> Hello.
>
> Jason Wessel wrote:
>> If not can you provide me with a test case to see the problem?
>
>Well, for example, with 2.6.18-rt7 kernel, stepping into
> smp_processor_id() was blowing away U-Boot (!) on my PPC board (even
> in PREEMPT_DESKTOP mode)... On x86, st
Hello.
Jason Wessel wrote:
>>> This patch fixes some corner cases where KGDB will silently hang or
>>> kill the system, if a user accidentally tries to source step into a
>>> spin_unlock() call or source step in on a macro containing
>>> smp_processor_id(). The use of raw_smp_processor_id is des
Sergei Shtylyov wrote:
> Jason Wessel wrote:
>
>> This patch fixes some corner cases where KGDB will silently hang or
>> kill the system, if a user accidentally tries to source step into a
>> spin_unlock() call or source step in on a macro containing
>> smp_processor_id(). The use of raw_smp_proce
Jason,
That's a good patch. Instead of relying on kernel's mechanism to panic, this
way we do something more reliable to report the panic to a user.
-Amit
On Tuesday 15 May 2007 08:39, Jason Wessel wrote:
> If there are no objections, I will commit the following patch.
>
> --
>
> This patch fi
Jason Wessel wrote:
> This patch fixes some corner cases where KGDB will silently hang or
> kill the system, if a user accidentally tries to source step into a
> spin_unlock() call or source step in on a macro containing
> smp_processor_id(). The use of raw_smp_processor_id is desired in
> kernel
Pete/Piet Delaney wrote:
> Sounds great to me; avoiding spin locks() is a hassle.
>
> Ever noticed a problem with kgdb surviving a weekend of non-use?
>
> I hit a breakpoint on Saturday and hoped to continue looking at it
> today but the kgdb-stub, as usual, got out of phase and I had
> to re-do th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason Wessel wrote:
> If there are no objections, I will commit the following patch.
Sounds great to me; avoiding spin locks() is a hassle.
Ever noticed a problem with kgdb surviving a weekend of non-use?
I hit a breakpoint on Saturday and hoped to
22 matches
Mail list logo
