* Beauchemin, Mark <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> Any thoughts on the patch?
looks good to me - but it has a number of style issues, please run it
through scripts/checkpatch.pl to see those.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
Ingo,
Any thoughts on the patch?
Thanks,
Mark
-Original Message-
From: Beauchemin, Mark
Sent: Tuesday, August 07, 2007 3:42 PM
To: 'Ingo Molnar'
Cc: Thomas Gleixner; linux-kernel@vger.kernel.org; David Miller
Subject: RE: [PATCH -rt] Preemption problem in
> could you please change this to use 'current' (instead of the CPU
> number) as the xmit_lock_owner unconditionally? That results in much
> fewer #ifdefs and far cleaner code.
>
> Ingo
Ingo,
Here's the new patch. Please check me on the non-rt portion.
I think the check is s
* Beauchemin, Mark <[EMAIL PROTECTED]> wrote:
> sorry.. I sent the wrong patch file. There was a warning in the
> other one.
> - int xmit_lock_owner;
> +#ifdef CONFIG_PREEMPT_RT
> + void * xmit_lock_owner;
> +#else
> + int
sorry.. I sent the wrong patch file. There was a warning in the other one.
diff -ur linux-2.6.23-rc1-rt0/include/linux/netdevice.h
linux-2.6.23-rc1-rt0_new/include/linux/netdevice.h
--- linux-2.6.23-rc1-rt0/include/linux/netdevice.h 2007-07-24
15:17:07.0 -0400
+++ linux-2.6.23-r
OTECTED]
Sent: Tuesday, July 24, 2007 3:15 PM
To: Beauchemin, Mark
Cc: Thomas Gleixner; linux-kernel@vger.kernel.org; David Miller
Subject: Re: [PATCH -rt] Preemption problem in kernel RT Patch
* Beauchemin, Mark <[EMAIL PROTECTED]> wrote:
> I'm not sure why the check for recursion ha
ark
-Original Message-
From: Ingo Molnar [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 24, 2007 3:15 PM
To: Beauchemin, Mark
Cc: Thomas Gleixner; linux-kernel@vger.kernel.org; David Miller
Subject: Re: [PATCH -rt] Preemption problem in kernel RT Patch
* Beauchemin, Mark <[EMAIL
* Beauchemin, Mark <[EMAIL PROTECTED]> wrote:
> I'm not sure why the check for recursion has been removed. In the
> backtrace below, I think it would be caught by this check and not
> recursively call the spinlock code.
ah ... i think i did it like that because i didnt realize that there
wou
Thomas,
I think I've gotten to the heart of the problem. Here's an excerpt
from the latest -rt patch: net/core/dev.c in the function dev_queue_xmit
@@ -1588,11 +1588,17 @@ gso:
Either shot noqueue qdisc, it is even simpler 8)
*/
if (dev->flags & IFF_UP) {
-
Mark,
On Sat, 2007-06-23 at 10:08 -0400, Beauchemin, Mark wrote:
> Thanks for straightening me out. I was reading the function
> try_to_take_rt_mutex wrong... The problem makes more sense now. The tunnel
> code encapsulates the current packet in a new packet and calls ip_output
> to ge
Thomas,
> please fix your mail client to do proper line wraps at column 78.
Outlook sucks. I'll install thunderbird this weekend. sorry.
> Nice, but nevertheless wrong theory.
>
> This check is part of the RT-Patch and it _is_ entirely correct:
> Something tries to do a spin_lock()
Mark,
please fix your mail client to do proper line wraps at column 78.
On Thu, 2007-06-21 at 15:39 -0400, Beauchemin, Mark wrote:
> Hi,
> I've found a preemption problem in kernel/rtmutex.c:649. The BUG_ON
> listed in the patch below makes sure a preemption event hasn't
> occurred since t
12 matches
Mail list logo
