On Sun, Mar 17, 2013 at 03:34:46PM +0100, Oleg Nesterov wrote:
> > > (Just in case, this was recently changed. After
> > > coredump-ensure-that-sigkill-always-kills-the-dumping-thread.patch in -mm
> > > tree the dumper doesn't run in SIGNAL_GROUP_EXIT, but probably this
> > > doesn't matter)
> >
On Mon, Mar 18, 2013 at 06:03:02PM +0100, Oleg Nesterov wrote:
> > Assume that's not happening, why would ptrace give me -ESRCH, yet
> > /proc//status would show me ptrace attached to the thread.
>
> And why do you think this should be explained by SIGKILL?
It's an assumption, if I knew before yo
Hi,
I was writing an application to ptrace a process which is dumping core
from inside the pipe application for core_pattern.
So for example you make core pattern equal to something like
"|/bin/corepipe_app" then the kernel runs that app prior to actually
killing the process that failed.
Before
On Sat, Mar 16, 2013 at 06:58:45PM +0100, Oleg Nesterov wrote:
> On 03/15, Daniel Walker wrote:
> >
> > I was writing an application to ptrace a process which is dumping core
> > from inside the pipe application for core_pattern.
>
> This was never possible. And never w
On Mon, Feb 04, 2008 at 03:35:13PM -0800, Max Krasnyanskiy wrote:
> This is just an FYI. As part of the "Isolated CPU extensions" thread Daniel
> suggest for me
> to check out latest RT kernels. So I did or at least tried to and immediately
> spotted a couple
> of issues.
>
> The machine I'm runn
On Mon, Feb 04, 2008 at 10:02:12PM -0700, Gregory Haskins wrote:
> >>> On Mon, Feb 4, 2008 at 9:51 PM, in message
> <[EMAIL PROTECTED]>, Daniel Walker
> <[EMAIL PROTECTED]> wrote:
> > I get the following when I tried it,
> >
> > BUG: sleeping fu
Hi,
I get this crash on linux-next as of today ..
[4.678947] general protection fault: [#1] SMP
2 [4.678953] CPU: 0 PID: 1 C
Hi,
Are you aware that http://www.latencytop.org/ is not functioning ? I was
trying to get the update source code, but seem there is no place to do
that.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
If the opstate_init() isn't called the driver won't start properly.
I just added it in what appears to be an appropriate place.
Signed-off-by: Daniel Walker
---
drivers/edac/octeon_edac-lmc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/edac/octeon_edac-lmc.c b/dr
This adds an ad-hoc error injection method. Octeon II doesn't have
hardware support for injection, so this simulates it.
Signed-off-by: Daniel Walker
---
drivers/edac/octeon_edac-lmc.c | 177 +++--
1 file changed, 171 insertions(+), 6 deletions(-)
diff
On Mon, Mar 25, 2013 at 10:48:07AM +0100, Denys Vlasenko wrote:
> On 03/19/2013 09:19 PM, Oleg Nesterov wrote:
> >> The above is regarding the situation which I'm running my corepipe_app ,
> >> i.e. my system doesn't have a disk to save a core file for parsing.
> >
> > Can't you process the data i
On Sun, Feb 17, 2008 at 01:50:50PM +0300, Alexey Dobriyan wrote:
> > profile-likely-unlikely-macros
> > page-owner-tracking-leak-detector
> > cciss-procfs-updates-to-display-info-about-many-volumes
>
> Guys, create_proc_entry() is slightly racy in case of modular code and
> proc_create() was inven
On Mon, Feb 18, 2008 at 08:45:35PM +0100, [EMAIL PROTECTED] wrote:
> @@ -1391,7 +1391,7 @@
>
> /* Initialize device descriptor */
> init_MUTEX( &ccp->mutex);
> - init_MUTEX( &ccp->readmutex);
> + mutex_init(&ccp->readmutex);
> auerbuf_init (&ccp->bufctl);
> c
On Tue, Feb 05, 2008 at 11:25:18AM -0700, Gregory Haskins wrote:
> @@ -6241,7 +6242,7 @@ static void rq_attach_root(struct rq *rq, struct
> root_domain *rd)
> cpu_clear(rq->cpu, old_rd->online);
>
> if (atomic_dec_and_test(&old_rd->refcount))
> -
Source: Daniel Walker <[EMAIL PROTECTED]> MontaVista Software, Inc
Description:
This patch adds the priority list data structure from Inaky
Perez-Gonzalez
to the Preempt Real-Time mutex.
the patch order is (starting with a 2.6.11 kernel tree),
patch-2.6.12-rc2
realtime-preempt-
On Thu, 2005-04-07 at 23:28, Ingo Molnar wrote:
> this one looks really clean.
>
> it makes me wonder, what is the current status of fusyn's? Such a light
> datastructure would be much more mergeable upstream than the former
> 100-queues approach.
Inaky was telling me that 100 queues
I submitted a fix for this a while ago, I think ..
interruptible_sleep_on()'s are broken ..
Daniel
On Fri, 2005-04-08 at 13:15, Lee Revell wrote:
> Kernel is 2.6.12-rc1-RT-V0.7.43-05.
>
> BUG: scheduling with irqs disabled: umount/0x/20612
> caller is schedule_timeout+0x63/0xc0
> [] d
On Fri, 2005-04-08 at 14:25, Perez-Gonzalez, Inaky wrote:
> I concur with Daniel. If we can decide how to deal with that (toss
> one out, keep one, merge them, whatever), we could reuse all the user
> space glue that is the hardest part to get right.
I have a preference to the Real-Time PI
On Sun, 2005-04-10 at 03:53, Ingo Molnar wrote:
> ok, i've added this patch to the -45-00 release. It's looking good on my
> testsystems so far, but it will need some more testing i guess.
Yes, I ran the PI test, and just let the system run .. So it could use
more extensive testing..
Daniel
On Fri, 2005-04-08 at 14:51, Lee Revell wrote:
> On Fri, 2005-04-08 at 13:38 -0700, Daniel Walker wrote:
> > I submitted a fix for this a while ago, I think ..
> > interruptible_sleep_on()'s are broken ..
>
> I saw the fix in -stable, but it does not seem to be in 2.6.
On Fri, 2005-04-08 at 21:44, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > I submitted a fix for this a while ago, I think ..
> > interruptible_sleep_on()'s are broken ..
>
> sleep_on() is a fundamentally broken interface, it only w
I'm not sure if this has changed at all in recent RT patches, but I've
noticed several issues popping up that are related to the timer
interrupt sending signals , one in particular is the fact that
send_sig() calls into __cache_alloc() which has it's interrupt disable
protections removed i
On Mon, 2005-04-11 at 11:03, john cooper wrote:
> Daniel Walker wrote:
> > I'm not sure if this has changed at all in recent RT patches, but I've
> > noticed several issues popping up that are related to the timer
> > interrupt sending signals...
>
> I&#
I just wanted to discuss the problem a little more. From all the
conversations that I've had it seem that everyone is worried about
having PI in Fusyn, and PI in the RT mutex.
It seems like these two locks are going to interact on a very limited
basis. Fusyn will be the user space mutex, and the
On Tue, 2005-04-12 at 13:33, Joe Korty wrote:
> On Tue, Apr 12, 2005 at 11:15:02AM -0700, Daniel Walker wrote:
>
> > It seems like these two locks are going to interact on a very limited
> > basis. Fusyn will be the user space mutex, and the RT mutex is only in
> > the k
On Tue, 2005-04-12 at 13:29, Esben Nielsen wrote:
> You basicly need 3 priorities:
> 1) Actual: task->prio
> 2) Base prio with no RT locks taken: task->static_prio
> 3) Base prio with no Fusyn locks taken: task->??
>
> So no, you will not need the same API, at all :-) Fusyn manipulates
> task->st
On Tue, 2005-04-12 at 15:26, Perez-Gonzalez, Inaky wrote:
> You should not need any of this if your user space mutexes are a
> wrapper over the kernel space ones. The kernel handles everything
> the same and there is no need to take care of any special cases or
> variations [other than the ones im
d the error must be in Fusyn based code.
>
> Esben
>
> On Tue, 12 Apr 2005, Perez-Gonzalez, Inaky wrote:
>
> > >From: Esben Nielsen [mailto:[EMAIL PROTECTED]
> > >On 12 Apr 2005, Daniel Walker wrote:
> > >
> > >>
> > >>
> > &g
On Sun, 2005-04-10 at 04:09, Ingo Molnar wrote:
> Unless i'm missing something, this could be implemented by detaching
> lock->owner_prio from lock->owner - via e.g. negative values. Thus some
> minimal code would check whether we need the owner's priority in the PI
> logic, or the semaphore's "own
On Wed, 2005-04-13 at 08:46, Steven Rostedt wrote:
> How hard would it be to use the RT mutex PI for the priority inheritance
> for fusyn? I only work with the RT mutex now and haven't looked at the
> fusyn. Maybe Ingo can make a separate PI system with its own API that
> both the fusyn and RT mu
I get Slab corruption while repeatedly loading and unloading small (3k)
executables that just loop calling gettimeofday().. The
"last user" is alway __mmdrop() . This only happens under RT ..
I think this is related to a problem observed by Steven Rostedt .
Another trigger is to run bonnie++
The PREEMPT_RT description doesn't seem correct. According to your
"hard" definition, PREEMPT_RT can provably hit a hard deadline for
interrupt response.
Daniel
On Mon, 2005-07-11 at 07:55 -0700, Paul E. McKenney wrote:
>
> a.Quality of service: "soft realtime", with timeframe of a few
On Mon, 2005-07-11 at 09:43 -0700, Paul E. McKenney wrote:
> Hello, Daniel,
>
> In principle, one could inspect the Linux kernel with the PREEMPT_RT patch
> applied, and calculate the worst-case time during which interrupts are
> disabled, though I have not heard of anyone actually doing this. Is
On Mon, 2005-07-11 at 10:19 -0700, Paul E. McKenney wrote:
> OK, interesting point, though this would apply only to interrupt latency,
> not to scheduling latency or to latency for any other system services,
> right?
Only for interrupt latency, that I know of.
> Do you believe that the 50-us de
This may help ..
Index: linux-2.6.12/arch/x86_64/kernel/mce.c
===
--- linux-2.6.12.orig/arch/x86_64/kernel/mce.c 2005-06-17 19:48:29.0
+
+++ linux-2.6.12/arch/x86_64/kernel/mce.c 2005-07-11 18:44:42.0
+00
On Tue, 2005-07-12 at 16:02 +0200, Ingo Molnar wrote:
> * Karsten Wiese <[EMAIL PROTECTED]> wrote:
>
> > Hi Ingo
> >
> > I've refined io_apic.c a little more:
>
> great. I've applied these changes and have released the -28 patch. (note
> that the last chunk of your patch was malformed, have app
On Tue, 2005-07-12 at 16:28 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > I observed a situation on a dual xeon where IOAPIC_POSTFLUSH , if on,
> > would actually cause spurious interrupts. It was odd cause it's
> > suppose to
On Tue, 2005-07-12 at 16:46 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > I haven't tested it recently . This was on an older version of RT
> > though . I could try it if it's interesting ? Or do you think it's
> &g
Is there something so odd about the XFS locking, that it can't use the
rt_lock ?
--- linux.orig/fs/xfs/linux-2.6/mrlock.h
+++ linux/fs/xfs/linux-2.6/mrlock.h
@@ -37,12 +37,12 @@
enum { MR_NONE, MR_ACCESS, MR_UPDATE };
typedef struct {
- struct rw_semaphore mr_lock;
- int
On Wed, 2005-07-13 at 10:25 +1000, Nathan Scott wrote:
> On Tue, Jul 12, 2005 at 04:01:32PM -0700, Daniel Walker wrote:
> >
> > Is there something so odd about the XFS locking, that it can't use the
> > rt_lock ?
>
> Not that I know of - XFS does use the downgr
On Wed, 2005-07-13 at 08:47 +0200, Ingo Molnar wrote:
>
> downgrade_write() wasnt the main problem - the main problem was that for
> PREEMPT_RT i implemented 'strict' semaphores, which are not identical to
> vanilla kernel semaphores. The thing that seemed to impact XFS the most
> is the 'acqui
On Thu, 2005-07-14 at 13:50 +1000, Dave Chinner wrote:
> Now that I've read the thread, I see it's not mrlocks that is the
> issue with unlocking in a different context - it's semaphores.
>
> All the pagebuf synchronisation is done with a semaphore because
> it's held across the I/O and it's _most
On Thu, 2005-07-14 at 07:23 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > The whole point of using a semaphore in the pagebuf is because there
> > > is no tracking of who "owns" the lock so we can actually release it
>
On Fri, 2005-07-15 at 12:23 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > PI is always good, cause it allows the tracking of what is high
> > priority , and what is not .
>
> that's just plain wrong. PI might be good if one cares
On Tue, 2005-07-12 at 07:56 -0700, Daniel Walker wrote:
> On Tue, 2005-07-12 at 16:46 +0200, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > I haven't tested it recently . This was on an older version of RT
> > > though . I
On Wed, 2005-07-20 at 08:16 +1000, Con Kolivas wrote:
> Interestingly the average latencies are slightly higher (in the miniscule
> <2us
> range), but the maximum latencies are excellently bound to 25us.
>
> The results are quite reproducible.
I would guess that the average latencies are tunab
On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote:
>
> - networking is another frequent source of latencies - it might make
>sense to add a workload doing lots of socket IO. (localhost might be
>enough, but not for everything)
The Gnutella test?
Daniel
-
To unsubscribe from this
On Wed, 2005-07-20 at 11:04 +1000, Con Kolivas wrote:
> On Wed, 20 Jul 2005 10:23 am, Daniel Walker wrote:
> > On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote:
> > > - networking is another frequent source of latencies - it might make
> > >sense to add a workl
On Tue, 2005-08-09 at 11:23 -0400, Steven Rostedt wrote:
>
> I just downloaded 2.6.13-rc6-git and I don't see the merge of the soft
> lockup code. Is this a Fedora thing? If so, could someone point me to
> a link to download this Fedora kernel. I'm currently using Debian.
I seem to recall seein
It looks like this might be an SMP race , it seem that both processors
are in e100_down(). There is a while loop in e100_clean_cbs() that
appears to have an unsafe looping condition .
It looks like cbs_avail might jump over params.cbs.count , then you
would have to wait for a rollover . Is this
This may fix the warning , but I doubt it does anything for any hangs..
--- linux-2.6.12.orig/drivers/usb/core/hcd.c2005-08-09 22:41:18.0
+
+++ linux-2.6.12/drivers/usb/core/hcd.c 2005-08-10 00:23:16.0 +
@@ -540,8 +540,7 @@ void usb_hcd_poll_rh_status(struct usb_h
On Wed, 2005-08-10 at 13:52 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > This may fix the warning , but I doubt it does anything for any hangs..
> >
> > --- linux-2.6.12.orig/drivers/usb/core/hcd.c2005-08-09
> > 22:41:18.
On Wed, 2005-08-10 at 13:52 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > This may fix the warning , but I doubt it does anything for any hangs..
> >
> > --- linux-2.6.12.orig/drivers/usb/core/hcd.c2005-08-09
> > 22:41:18.
On Thu, 2005-08-04 at 15:52 +0200, Ingo Molnar wrote:
> would be nice to clean up the impact of the latency-histogram code some
> more though: e.g. the #ifdef jungle check_critical_timing() is
> disgusting. Could be cleaned up by always recording the latency_type
> being currently traced into a
Comments below ...
On Thu, 2005-08-11 at 09:43 +, yangyi wrote:
> +#ifndef CONFIG_CRITICAL_LATENCY_HIST
> if (!report_latency(delta))
> goto out;
> +#endif
Why ? This combined with the hunk below is just preempt_threshold ..
Just use preempt_threshold instead of all the
On Thu, 21 Apr 2005, Ingo Molnar wrote:
>
> i have released the -V0.7.46-00 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
>http://redhat.com/~mingo/realtime-preempt/
>
> this is a merge to 2.6.12-rc3, plus the 'ping localhost' fix from
> [EMAIL PROTECTED]
>
On Thu, 2005-04-21 at 00:35, Ingo Molnar wrote:
> this is a merge to 2.6.12-rc3, plus the 'ping localhost' fix from
> [EMAIL PROTECTED]
We had some discussion about this one, there just need to be a softirqd
wakeup , the netif_rx_ni() call isn't really needed .
How about removing the softirqd
What command line did you use ?
./test --samples 1 --hertz 128 --tasks 0
Daniel
On Fri, 22 Apr 2005, Ingo Molnar wrote:
>
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > Is this the PriorityInversionTest (pi_test.tgz) or was there another one?
>
Oops, I missed that you tested a non-plist kernel .. Maybe there are some
lingering problems in current stuff..
Daniel
On Fri, 22 Apr 2005, Inaky Perez-Gonzalez wrote:
> With 2.6.12-rc3-V0.7.46-02 I get:
>
> ...
> 2 maximum cycle time: 0.003ms
> 3 maximum cycle time: 1.706ms
> 4 maximum cyc
Is this the PriorityInversionTest (pi_test.tgz) or was there another one?
Daniel
On Fri, 22 Apr 2005, Ingo Molnar wrote:
>
> > this includes fixes from Daniel Walker, which could fix the plist
> > related slowdown bugs:
>
> there are still some problems remain
t
On Fri, 22 Apr 2005, Inaky Perez-Gonzalez wrote:
> >>>>> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> >> this includes fixes from Daniel Walker, which could fix the plist
> >> related slowdown bugs:
>
> > there are still some probl
You might want to CC Andrew Morton , and Rusty Russell.
What is the status of the glibc side of this?
Daniel
On Tue, 2005-07-05 at 16:11 -0700, Todd Kneisel wrote:
> This is a resend of my patch to add robust futex support to the existing
> sys_futex system call. The patch applies to 2.6.12. A
I noticed some typo's or mis-thoughts .. Here are my corrections. I
tried to CC all the authors.
Daniel
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
Index: linux-2.6.12/Documentation/ManagementStyle
===
--- linux-
On Fri, 2005-07-08 at 15:43 +0200, Ingo Molnar wrote:
> * Vitaly Wool <[EMAIL PROTECTED]> wrote:
>
> > Hi Ingo,
> >
> > I've come across the following problem during the debugging of IDE
> > driver for Philips PNX0105 ARM9 platform in RT mode
> > (CONFIG_PREEMPT_RT). When I mount/unmount a devi
On Sat, 2005-07-09 at 09:19 +0200, Ingo Molnar wrote:
> (if your goal was to check how heavily external interrupts can influence
> a PREEMPT_RT box, you should chrt the network IRQ thread to SCHED_OTHER
> and renice it and softirq-net-rx and softirq-net-tx to nice +19.)
>
This is interesting.
Don't you break sched_find_first_bit() , seems it's dependent on a
140-bit bitmap .
Daniel
On Wed, 2005-07-27 at 10:13 -0400, Steven Rostedt wrote:
> The following patch makes the MAX_RT_PRIO and MAX_USER_RT_PRIO
> configurable from the make *config. This is more of a proposal since
> I'm not
>From 2.6.13-rc4 this hunk
+#else
+# define rt_hash_lock_addr(slot) NULL
+# define rt_hash_lock_init()
+#endif
Doesn't work with the following,
+ spin_unlock(rt_hash_lock_addr(i));
Cause your spin locking a NULL .. I would give a patch, but I'm not sure
what should be done in t
On Sun, 2005-07-31 at 11:46 -0700, David S. Miller wrote:
> From: Daniel Walker <[EMAIL PROTECTED]>
> Date: Sun, 31 Jul 2005 09:27:55 -0700
>
> > >From 2.6.13-rc4 this hunk
> >
> > +#else
> > +# define rt_hash_lock_addr(slot) NULL
> > +# define
On Sun, 2005-07-31 at 12:11 -0700, David S. Miller wrote:
> From: Daniel Walker <[EMAIL PROTECTED]>
> Date: Sun, 31 Jul 2005 12:06:47 -0700
>
> > The ifdef that switched between the two rt_hash_lock_addr() switched on
> > for CONFIG_SMP or CONFIG_DEBUG_SPINLOCK
On Mon, 2005-08-01 at 08:17 -0700, Andrew Burgess wrote:
> Stock 2.6.12.3 #2 Sun Jul 31 16:55:16 PDT 2005 i686 i686 i386 GNU/Linux
>
> Seems to be triggered by mplayer but not right away (30 minutes sometimes),
> sometimes
> no mplayer is necessary.
>
> This is a busy machine. There is continuou
On Mon, 2005-08-01 at 14:22 -0400, Steven Rostedt wrote:
> Ingo,
>
> What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> getting a bunch of them from the IDE interrupt. It's not locking up,
> but it does things that probably do take some time. Is this really
> necessary? Here's
In the interest of CC'ing everyone here's another patch .
This checks for wake_up_process() calls inside was preempt off sections.
So if it was a spinlock , and you call wake_up_process() it will trigger
a warning.. These are problematic cause in RT the wake_up_process() (if
it's an RT task) will
On Mon, 2005-08-01 at 22:52 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Ingo,
> >
> > What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> > getting a bunch of them from the IDE interrupt. It's not locking up,
> > but it does things that proba
On Mon, 2005-08-01 at 23:55 -0400, Steven Rostedt wrote:
> On Mon, 2005-08-01 at 14:20 -0700, Daniel Walker wrote:
> > It means that IRQ 14 is running for a long time as an RT task
>
> Oh yeah, I forgot to comment on this. Yes IRQ 14 is rather slow. It's
> the IDE driv
Couldn't you just do some math off current->timestamp to see how long
the task has been running? This per arch stuff seems a bit invasive..
Daniel
On Tue, 2005-08-02 at 15:45 -0400, Steven Rostedt wrote:
> On Tue, 2005-08-02 at 12:19 +0200, Ingo Molnar wrote:
> > * Steven Rostedt <[EMAIL PROTECT
On Tue, 2005-08-02 at 20:00 -0400, Steven Rostedt wrote:
> On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
> > Couldn't you just do some math off current->timestamp to see how long
> > the task has been running? This per arch stuff seems a bit invasive..
>
> T
On Tue, 2005-08-02 at 22:42 -0400, Steven Rostedt wrote:
> On Tue, 2005-08-02 at 19:25 -0700, Daniel Walker wrote:
> > On Tue, 2005-08-02 at 20:00 -0400, Steven Rostedt wrote:
> > > On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
> > > > Couldn'
On Wed, 2005-08-03 at 06:30 -0400, Steven Rostedt wrote:
> On Tue, 2005-08-02 at 19:58 -0700, Daniel Walker wrote:
> > The stack trace should show where the problem is . If it's in the kernel
> > we will see kernel functions before do_IRQ() , if it's just a whacked
> &g
On Thu, 2005-08-04 at 16:42 +0200, Ingo Molnar wrote:
> I've applied your patch, and have released the -52-13 PREEMPT_RT
> patchset. [ But please be more careful with the coding style next time,
> see below the number of fixups i had to do relative to your patch
> (whitespaces, line length, cod
On Mon, 2005-08-22 at 15:44 -0400, Steven Rostedt wrote:
> On Mon, 2005-08-22 at 20:33 +0200, Ingo Molnar wrote:
>
> > any ideas how to get rid of pi_lock altogether?
>
> I've toyed with the idea of adding another raw_spin_lock to the mutex. A
> lock specific pi_lock. Instead of grabbing a glob
On Mon, 2005-08-22 at 20:26 -0400, Steven Rostedt wrote:
>
> How would you add to a lock with just holding a lock for a task? When
> you are grabbing a lock, you must first grab a raw lock associated to
> the lock being grabbed. Although, I'm starting to look into this idea,
> and I'm going to
On Wed, 2005-08-24 at 21:13 -0400, Steven Rostedt wrote:
> Well, after turning off hrtimers, I keep getting one bug. A possible
> soft lockup with the ext3 code. But this didn't seem to be caused by the
> changes I made. So just to be sure, I ran my test on the vanilla
> 2.6.13-rc6-rt11 and it gave
;(Thomas Gleixner)
>
> - fix larger-than-5-sec sleeps (Thomas Gleixner)
>
> - ALL_TASKS_PI compilation fixes (Daniel Walker)
>
> - HRT compilation warning fix (Daniel Walker)
>
> - PPC fixes (Thomas Gleixner)
>
> - merge to 2.6.13-rc7
>
> -
On Thu, 2005-08-25 at 16:09 -0400, Steven Rostedt wrote:
> A word of caution (aka. disclaimer). This is still new. I still expect
> there are some cases in the code that was missed and can cause a dead
> lock or other bad side effect. Hopefully, we can iron these all out.
> Also, I noticed that
On Thu, 2005-08-25 at 19:45 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > Does anyone have x86_64 working in PREEMPT_RT ?
>
> builds fine, but doesnt seem to boot at the moment. Havent investigated
> yet.
I tested an em64t , and it h
Wakeup race checking shouldn't trigger when interrupts are off. Here's a
fix.
Daniel
Index: linux-2.6.12/kernel/rt.c
===
--- linux-2.6.12.orig/kernel/rt.c 2005-08-25 21:33:43.0 +
+++ linux-2.6.12/kernel/rt.c200
On Thu, 2005-08-25 at 23:54 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > @@ -257,6 +257,7 @@ void check_preempt_wakeup(struct task_st
> > * hangs and race conditions.
> > */
> > if (!preempt_count() &am
Nevermind , the original patch looks fine.
Daniel
On Thu, 2005-08-25 at 23:54 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > @@ -257,6 +257,7 @@ void check_preempt_wakeup(struct task_st
> > * hangs and race conditions.
> >
Devastating latency on a 3Ghz xeon .. Maybe the raw_spinlock in the
timer base is creating a unbounded latency?
Daniel
( softirq-timer/1-13 |#1): new 66088 us maximum-latency critical section.
=> started at timestamp 1857957769: <__down_mutex+0x5f/0x295>
=> ended at timestamp 1858023857: <_
On Fri, 2005-08-26 at 02:22 +0200, Thomas Gleixner wrote:
> On Thu, 2005-08-25 at 16:29 -0700, Daniel Walker wrote:
> > Devastating latency on a 3Ghz xeon .. Maybe the raw_spinlock in the
> > timer base is creating a unbounded latency?
>
> The lock is only held for really sh
On Fri, 2005-08-26 at 08:43 +0200, Thomas Gleixner wrote:
> On Thu, 2005-08-25 at 18:15 -0700, Daniel Walker wrote:
> > On Fri, 2005-08-26 at 02:22 +0200, Thomas Gleixner wrote:
> > > On Thu, 2005-08-25 at 16:29 -0700, Daniel Walker wrote:
> > > > Devastating laten
On Fri, 2005-08-26 at 08:31 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2005-08-25 at 19:45 +0200, Ingo Molnar wrote:
> > > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> > >
> > > > Does anyone have x
On Mon, 2005-08-29 at 10:48 +0200, Ingo Molnar wrote:
>
> - x86_64 boot fix (Daniel Walker)
Ingo, Did this work for you?
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordo
On Mon, 2005-08-29 at 17:18 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2005-08-29 at 10:48 +0200, Ingo Molnar wrote:
> >
> > >
> > > - x86_64 boot fix (Daniel Walker)
> >
> > Ingo, Did this work f
Have you tried turning on
"Non-preemptible critical section latency timing" or "Latency tracing"
I don't know if it's related to the PI changes, but I'm getting a crash
with those on em64t .
With both above options I get
<0>init[1]: segfault at 8010ef44 rip 8010ef44 rsp
7f
Ingo,
This patch adds a vermagic hook so PREEMPT_RT modules can be
distinguished from PREEMPT_DESKTOP modules.
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
Index: linux-2.6.10/include/linux/verm
There is already a suite HRT of tests they include a nanosleep jitter
test with 8 or 9 other tests..
find them inside the hrt-support patch at http://high-res-timer.sf.net
Daniel
On Wed, 2005-08-31 at 11:01 -0400, Steven Rostedt wrote:
> Thomas,
>
> I just was wondering how the HR Timers were
Sorry, that's http://high-res-timers.sf.net/
Daniel
On Wed, 2005-08-31 at 11:01 -0400, Steven Rostedt wrote:
> Thomas,
>
> I just was wondering how the HR Timers were in the latest -rtX patch and
> wrote my own little jitter test using nanosleep. Here's the results:
>
> On vanilla 2.6.13-rc7-
No problem .. There are some other tests in there though .. I've been
using them for stress testing .. Apparently you don't need HRT on to use
them either.
Daniel
On Wed, 2005-08-31 at 11:19 -0400, Steven Rostedt wrote:
> On Wed, 2005-08-31 at 08:13 -0700, Daniel Walker wrote:
>
On Thu, 2005-09-01 at 01:50 +0200, Roman Zippel wrote:
> What "more versions" are you talking about? When you convert a user time
> to kernel time you can automatically validate it and later you can use
> standard kernel APIs, so you don't have to add even more API bloat.
What's kernel time? Ar
1 - 100 of 808 matches
Mail list logo
