Linux Real Time Users

Thread Index

[Prev Page][Next Page]

Re: BKL & latency
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Regarding GDT
- From: Sri Ram Vemulpali <sri.ram.gmu06@xxxxxxxxx>
BKL & latency
- From: Tony Poppleton <tony.poppleton@xxxxxxxxx>
Re: regarding synchronization code
- From: Sri Ram Vemulpali <sri.ram.gmu06@xxxxxxxxx>
Re: regarding synchronization code
- From: Michael Blizek <michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Re: regarding synchronization code
- From: Dave Hylands <dhylands@xxxxxxxxx>
Re: Regarding interrupt task latency
- From: "Gregory Haskins" <ghaskins@xxxxxxxxxx>
Re: Regarding interrupt task latency
- From: Sri Ram Vemulpali <sri.ram.gmu06@xxxxxxxxx>
Re: regarding synchronization code
- From: "Gregory Haskins" <ghaskins@xxxxxxxxxx>
Re: Regarding interrupt task latency
- From: "Gregory Haskins" <ghaskins@xxxxxxxxxx>
regarding synchronization code
- From: Sri Ram Vemulpali <sri.ram.gmu06@xxxxxxxxx>
Re: pthread_once
- From: "Ardhan Madras" <ajhwb@xxxxxxxx>
Re: Regarding interrupt task latency
- From: Manikandan Ramachandran <crmanik@xxxxxxxxx>
Re: Regarding interrupt task latency
- From: Sri Ram Vemulpali <sri.ram.gmu06@xxxxxxxxx>
Re: Regarding interrupt task latency
- From: "Gregory Haskins" <ghaskins@xxxxxxxxxx>
Regarding interrupt task latency
- From: Sri Ram Vemulpali <sri.ram.gmu06@xxxxxxxxx>
Next Supported Kernel Version
- From: S C Rigler <riglersc@xxxxxxxxx>
Re: Help about Ubuntu Linux-rt
- From: Manikandan Ramachandran <crmanik@xxxxxxxxx>
Re: Newbie question about profiling.
- From: gowrishankar <gowrishankar.m@xxxxxxxxxxxxxxxxxx>
Re: Newbie question about profiling.
- From: Pradyumna Sampath <pradysam@xxxxxxxxx>
Newbie question about profiling.
- From: Lars Segerlund <lars.segerlund@xxxxxxxxx>
Re: Help about Ubuntu Linux-rt
- From: gowrishankar <gowrishankar.m@xxxxxxxxxxxxxxxxxx>
Re: Help about Ubuntu Linux-rt
- From: Bernardo Barros <bernardobarros2@xxxxxxxxx>
Help about Ubuntu Linux-rt
- From: rafet ilgin <rafetilginmetu@xxxxxxxxx>
Re: pthread_once
- From: Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx>
pthread_once
- From: ratheesh k <ratheesh.ksz@xxxxxxxxx>
rt patch for closed NVIDIA driver.
- From: Joakim Hernberg <jbh@xxxxxxxxxx>
Re: "yum install ...." based instruction on building a RT kernel.
- From: jordan <triplesquarednine@xxxxxxxxx>
Re: "yum install ...." based instruction on building a RT kernel.
- From: Bernardo Barros <bernardobarros2@xxxxxxxxx>
Re: "yum install ...." based instruction on building a RT kernel.
- From: jordan <triplesquarednine@xxxxxxxxx>
Re: "yum install ...." based instruction on building a RT kernel.
- From: Clark Williams <williams@xxxxxxxxxx>
Re: "yum install ...." based instruction on building a RT kernel.
- From: jordan <triplesquarednine@xxxxxxxxx>
Re: EXTERNAL: Re: "yum install ...." based instruction on building a RT kernel.
- From: jordan <triplesquarednine@xxxxxxxxx>
Re: "yum install ...." based instruction on building a RT kernel.
- From: jordan <triplesquarednine@xxxxxxxxx>
Re: "yum install ...." based instruction on building a RT kernel.
- From: jordan <triplesquarednine@xxxxxxxxx>
Re: EXTERNAL: Re: "yum install ...." based instruction on building a RT kernel.
- From: Gautam Thaker <gautam.h.thaker@xxxxxxxx>
Re: "yum install ...." based instruction on building a RT kernel.
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: "yum install ...." based instruction on building a RT kernel.
- From: Bernardo Barros <bernardobarros2@xxxxxxxxx>
Re: "yum install ...." based instruction on building a RT kernel.
- From: Daniel James <daniel@xxxxxxxxxxxx>
Re: "yum install ...." based instruction on building a RT kernel.
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: "yum install ...." based instruction on building a RT kernel.
- From: jordan <triplesquarednine@xxxxxxxxx>
"yum install ...." based instruction on building a RT kernel.
- From: Gautam Thaker <gautam.h.thaker@xxxxxxxx>
Re: preempt rt in commercial use
- From: jordan <triplesquarednine@xxxxxxxxx>
Re: preempt rt in commercial use
- From: jordan <triplesquarednine@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Re: preempt rt in commercial use
- From: Raz <raziebe@xxxxxxxxx>
Re: 2.6.33.7-rt29 PREEMPT_RT worse latency than PREEMPT_DESKTOP on AT91?
- From: Agustin Ferrin Pozuelo <agustin.ferrin@xxxxxxxxxxxx>
Re: TinxCore and PREEMPT_RT
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
Re: TinxCore and PREEMPT_RT
- From: Mike Galbraith <efault@xxxxxx>
Re: preempt rt in commercial use
- From: Daniel James <daniel@xxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Pradyumna Sampath <pradysam@xxxxxxxxx>
Re: TinxCore and PREEMPT_RT
- From: David Kastrup <dak@xxxxxxx>
Re: preempt rt in commercial use
- From: Daniel James <daniel@xxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Daniel James <daniel@xxxxxxxxxxxx>
Re: TinxCore and PREEMPT_RT
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: David Kastrup <dak@xxxxxxx>
Re: preempt rt in commercial use
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Reagan Thomas <thomasraz@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Re: preempt rt in commercial use
- From: David Kastrup <dak@xxxxxxx>
Re: 2.6.33.7-rt29 PREEMPT_RT worse latency than PREEMPT_DESKTOP on AT91?
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Re: 2.6.33.7-rt29 PREEMPT_RT worse latency than PREEMPT_DESKTOP on AT91?
- From: Agustin Ferrin Pozuelo <agustin.ferrin@xxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: David Kastrup <dak@xxxxxxx>
Re: preempt rt in commercial use
- From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Pradyumna Sampath <pradysam@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Re: preempt rt in commercial use
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Re: preempt rt in commercial use
- From: Patrice Kadionik <kadionik@xxxxxxxxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Pradyumna Sampath <pradysam@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Sergio Ruocco <ruocco@xxxxxxxxxxxxxxx>
TinxCore and PREEMPT_RT
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Klaas van Gend <klaas.van.gend@xxxxxxxxxx>
Re: preempt rt in commercial use
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
AW: preempt rt in commercial use
- From: "Lukas Redlinger" <redlinger@xxxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Patrice Kadionik <kadionik@xxxxxxxxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: jordan <triplesquarednine@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Re: preempt rt in commercial use
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Re: preempt rt in commercial use
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Re: preempt rt in commercial use
- From: "Gregory Haskins" <ghaskins@xxxxxxxxxx>
Re: Intel i3 | i5 | i7 GPU and RT kernel
- From: Mark Knecht <markknecht@xxxxxxxxx>
Re: problem in kzalloc or rt_spin_lock_fastlock?
- From: Manikandan Ramachandran <crmanik@xxxxxxxxx>
Re: Intel i3 | i5 | i7 GPU and RT kernel
- From: rosea grammostola <rosea.grammostola@xxxxxxxxx>
Re: Intel i3 | i5 | i7 GPU and RT kernel
- From: Mark Knecht <markknecht@xxxxxxxxx>
RE: problem in kzalloc or rt_spin_lock_fastlock?
- From: "Sydir, Jerry" <jerry.sydir@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Patrice Kadionik <kadionik@xxxxxxxxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Jeff Angielski <jeff@xxxxxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Pradyumna Sampath <pradysam@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Jeff Angielski <jeff@xxxxxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: "Nikita V. Youshchenko" <yoush@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Reagan Thomas <thomasraz@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Patrice Kadionik <kadionik@xxxxxxxxxxxxxxxxxx>
RE: preempt rt in commercial use
- From: "Darcy Watkins" <DWatkins@xxxxxxxxxxx>
Re: preempt rt in commercial use
- From: David Kastrup <dak@xxxxxxx>
Re: preempt rt in commercial use
- From: Daniel James <daniel@xxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Klaas van Gend <klaas.van.gend@xxxxxxxxxx>
Re: preempt rt in commercial use
- From: Pradyumna Sampath <pradysam@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: David Kastrup <dak@xxxxxxx>
Re: Priority Inheritance per se?
- From: Martin Däumler <mdae@xxxxxxxxxxxxxxxxx>
Re: Priority Inheritance per se?
- From: Sergio Ruocco <ruocco@xxxxxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Klaas van Gend <klaas.van.gend@xxxxxxxxxx>
Re: preempt rt in commercial use
- From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
Re: preempt rt in commercial use
- From: Pradyumna Sampath <pradysam@xxxxxxxxx>
Re: preempt rt in commercial use
- From: "Nikita V. Youshchenko" <yoush@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Raz <raziebe@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Rolando Martins <rolando.martins@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Raz <raziebe@xxxxxxxxx>
Re: preempt rt in commercial use
- From: Rolando Martins <rolando.martins@xxxxxxxxx>
preempt rt in commercial use
- From: Raz <raziebe@xxxxxxxxx>
Re: problem in kzalloc or rt_spin_lock_fastlock?
- From: Manikandan Ramachandran <crmanik@xxxxxxxxx>
Priority Inheritance per se?
- From: Martin Däumler <mdae@xxxxxxxxxxxxxxxxx>
problem in kzalloc or rt_spin_lock_fastlock?
- From: "Sydir, Jerry" <jerry.sydir@xxxxxxxxx>
Re: Intel i3 | i5 | i7 GPU and RT kernel
- From: Mark Knecht <markknecht@xxxxxxxxx>
Re: Intel i3 | i5 | i7 GPU and RT kernel
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Intel i3 | i5 | i7 GPU and RT kernel
- From: rosea grammostola <rosea.grammostola@xxxxxxxxx>
Re: [RFC 3/4] Disable scheduler tick when we are running SCHED_FIFO tasks
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Re: [RFC 3/4] Disable scheduler tick when we are running SCHED_FIFO tasks
- From: Jan Blunck <jblunck@xxxxxxxxxx>
Re: [RFC 3/4] Disable scheduler tick when we are running SCHED_FIFO tasks
- From: Jan Blunck <jblunck@xxxxxxxxxx>
Re: [RFC 3/4] Disable scheduler tick when we are running SCHED_FIFO tasks
- From: Jan Blunck <jblunck@xxxxxxxxxx>
Re: [RFC 3/4] Disable scheduler tick when we are running SCHED_FIFO tasks
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Re: [RFC 1/4] ftrace: Add events for tracing timer interrupts
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Re: [RFC 3/4] Disable scheduler tick when we are running SCHED_FIFO tasks
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [RFC 3/4] Disable scheduler tick when we are running SCHED_FIFO tasks
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Re: [RFC 3/4] Disable scheduler tick when we are running SCHED_FIFO tasks
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Re: [RFC 1/4] ftrace: Add events for tracing timer interrupts
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
[RFC 3/4] Disable scheduler tick when we are running SCHED_FIFO tasks
- From: Jan Blunck <jblunck@xxxxxxx>
[RFC 4/4] ftrace: Add argument to tick start/stop tracing
- From: Jan Blunck <jblunck@xxxxxxx>
[RFC 2/4] ftrace: Add events for tracing tick start and stop
- From: Jan Blunck <jblunck@xxxxxxx>
[RFC 1/4] ftrace: Add events for tracing timer interrupts
- From: Jan Blunck <jblunck@xxxxxxx>
[RFC 0/4] Disable timer tick for SCHED_FIFO tasks
- From: Jan Blunck <jblunck@xxxxxxx>
RE: 2.6.18-rt7 on HP Z800
- From: "Simpson, John (UK) (Contractor)" <john.simpson@xxxxxxxxxxxxxxxx>
patch-2.6.31.12-rt21 fails to run pthread_cond_signal()
- From: Lai Weilin-B04597 <B04597@xxxxxxxxxxxxx>
[HELP] Bug: Badness at kernel/rcutree_plugin.h
- From: Bob Liu <lliubbo@xxxxxxxxx>
raw interrupts disabled
- From: ratheesh k <ratheesh.ksz@xxxxxxxxx>
[PATCH] perf: provide kmap_atomic_direct for !CONFIG_HIGHMEM
- From: Tim Blechmann <tim@xxxxxxxxxx>
Re: why does __setup_irq use a raw spinlock? (Was: Trouble booting PREEMPT_RT kernel on ARM platform, 2.6.33)
- From: Jeremy Brown <jhbrown@xxxxxxxxxxxxxxxx>
RE: perf and oprofile causing kernel oops on 2.6.33.7-rt29 kernel
- From: "Sydir, Jerry" <jerry.sydir@xxxxxxxxx>
RE: perf and oprofile causing kernel oops on 2.6.33.7-rt29 kernel
- From: "Sydir, Jerry" <jerry.sydir@xxxxxxxxx>
Is there borken out patch for patch-2.6.33.7-rt29.gz?
- From: Bob Liu <lliubbo@xxxxxxxxx>
Re: 2.6.33.7-rt29 PREEMPT_RT worse latency than PREEMPT_DESKTOP on AT91?
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: perf and oprofile causing kernel oops on 2.6.33.7-rt29 kernel
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Re: perf and oprofile causing kernel oops on 2.6.33.7-rt29 kernel
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: why does __setup_irq use a raw spinlock? (Was: Trouble booting PREEMPT_RT kernel on ARM platform, 2.6.33)
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
2.6.33.7-rt29 PREEMPT_RT worse latency than PREEMPT_DESKTOP on AT91?
- From: Agustin Ferrin Pozuelo <agustin.ferrin@xxxxxxxxxxxx>
Re: Query regarding 2.6.335 RT and Non-RT performance
- From: gowrishankar <gowrishankar.m@xxxxxxxxxxxxxxxxxx>
why does __setup_irq use a raw spinlock? (Was: Trouble booting PREEMPT_RT kernel on ARM platform, 2.6.33)
- From: Jeremy Brown <jhbrown@xxxxxxxxxxxxxxxx>
Re: Query regarding 2.6.335 RT and Non-RT performance
- From: Sven-Thorsten Dietrich <sven@xxxxxxxxxxxxxxxxxxxxx>
Re: Query regarding 2.6.335 RT and Non-RT performance
- From: Manikandan Ramachandran <crmanik@xxxxxxxxx>
Re: 2.6.35 RT support roadmap
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Re: Query regarding 2.6.335 RT and Non-RT performance
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Re: Query regarding 2.6.335 RT and Non-RT performance
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
perf and oprofile causing kernel oops on 2.6.33.7-rt29 kernel
- From: "Sydir, Jerry" <jerry.sydir@xxxxxxxxx>
Re: Query regarding 2.6.335 RT and Non-RT performance
- From: Manikandan Ramachandran <crmanik@xxxxxxxxx>
Re: Query regarding 2.6.335 RT and Non-RT performance
- From: Mark Knecht <markknecht@xxxxxxxxx>
Re: Query regarding 2.6.335 RT and Non-RT performance
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Re: Query regarding 2.6.335 RT and Non-RT performance
- From: Manikandan Ramachandran <crmanik@xxxxxxxxx>
Re: Query regarding 2.6.335 RT and Non-RT performance
- From: David Sommerseth <davids@xxxxxxxxxx>
Re: 2.6.35 RT support roadmap
- From: Clark Williams <williams@xxxxxxxxxx>
Re: Query regarding 2.6.335 RT and Non-RT performance
- From: Mark Knecht <markknecht@xxxxxxxxx>
Re: Query regarding 2.6.335 RT and Non-RT performance
- From: Manikandan Ramachandran <crmanik@xxxxxxxxx>
Re: patch for NVIDIA on -rt
- From: Reagan Thomas <thomasraz@xxxxxxxxx>
patch for NVIDIA on -rt
- From: Joakim Hernberg <jbh@xxxxxxxxxx>
Re: Trouble booting PREEMPT_RT kernel on ARM platform, 2.6.33
- From: Jeremy Brown <jhbrown@xxxxxxxxxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: Sven-Thorsten Dietrich <sven@xxxxxxxxxxxxxxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: John Culvertson <jculvertson@xxxxxxxxx>
last patch (2.6.33.7-rt29)
- From: "Madovsky" <infos@xxxxxxxxxxxx>
Re: [DISCUSS : vxwork to linux]
- From: Raz <raziebe@xxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Re: [DISCUSS : vxwork to linux]
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
[DISCUSS : vxwork to linux]
- From: Raz <raziebe@xxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: John Culvertson <jculvertson@xxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: Sven-Thorsten Dietrich <sven@xxxxxxxxxxxxxxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: Darcy Watkins <dwatkins@xxxxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: John Culvertson <jculvertson@xxxxxxxxx>
RE: 2.6.33.6-rt28 kernel oops while stressing network
- From: "Darcy Watkins" <DWatkins@xxxxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: John Culvertson <jculvertson@xxxxxxxxx>
RE: 2.6.35 RT support roadmap
- From: "Walzer, Frank" <f-walzer@xxxxxx>
Re: 2.6.35 RT support roadmap
- From: jordan johnston <triplesquarednine@xxxxxxxxx>
RE: 2.6.18-rt7 on HP Z800
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
RE: 2.6.18-rt7 on HP Z800
- From: "Simpson, John (UK) (Contractor)" <john.simpson@xxxxxxxxxxxxxxxx>
Re: 2.6.35 RT support roadmap
- From: Mike Galbraith <efault@xxxxxx>
Re: 2.6.35 RT support roadmap
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Re: 2.6.35 RT support roadmap
- From: jordan johnston <triplesquarednine@xxxxxxxxx>
Re: 2.6.35 RT support roadmap
- From: Sven-Thorsten Dietrich <sven@xxxxxxxxxxxxxxxxxxxxx>
Re: 2.6.35 RT support roadmap
- From: Mike Galbraith <efault@xxxxxx>
Re: [ANNOUNCE] [REALTIME] 2.6.33.8-rt30-jk
- From: Patrice Kadionik <kadionik@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: Patrice Kadionik <kadionik@xxxxxxxxxxxxxxxxxx>
Re: [ANNOUNCE] [REALTIME] 2.6.33.8-rt30-jk
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [ANNOUNCE] [REALTIME] 2.6.33.8-rt30-jk
- From: Patrice Kadionik <kadionik@xxxxxxxxxxxxxxxxxx>
Re: [ANNOUNCE] [REALTIME] 2.6.33.8-rt30-jk
- From: Mark Knecht <markknecht@xxxxxxxxx>
[ANNOUNCE] [REALTIME] 2.6.33.8-rt30-jk
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: 2.6.35 RT support roadmap
- From: Xianghua Xiao <xiaoxianghua@xxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: John Culvertson <jculvertson@xxxxxxxxx>
Not getting MCP with RT_PREEMPT on MPC8313
- From: Esben Haabendal <eha@xxxxxxxxxxxxxxxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: Patrice Kadionik <kadionik@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.6-rt28 kernel oops while stressing network
- From: Patrice Kadionik <kadionik@xxxxxxxxxxxxxxxxxx>
2.6.35 RT support roadmap
- From: "Walzer, Frank" <f-walzer@xxxxxx>
2.6.33.6-rt28 kernel oops while stressing network
- From: John Culvertson <jculvertson@xxxxxxxxx>
Re: beagleboard RT problem
- From: Maksym Parkachov <lazy.gopher@xxxxxxxxx>
Re: beagleboard RT problem
- From: Maksym Parkachov <lazy.gopher@xxxxxxxxx>
BUG: [PlanetCCRMA] update: new kernel for fc13 (2.6.33.6 + rt28)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: problem nvidia driver 256.44 and linux 2.6.33.7-rt29
- From: Andres Cimmarusti <acimmarusti@xxxxxxxxx>
Re: Run RTLinux in a VM?
- From: Vivek Ayer <vivek.ayer@xxxxxxxxx>
Re: 2.6.18-rt7 on HP Z800
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
problem nvidia driver 256.44 and linux 2.6.33.7-rt29
- From: Javier Sanz <jsanza@xxxxxxxxx>
RE: 2.6.18-rt7 on HP Z800
- From: "Simpson, John (UK) (Contractor)" <john.simpson@xxxxxxxxxxxxxxxx>
Re: 2.6.18-rt7 on HP Z800
- From: Sven-Thorsten Dietrich <sven@xxxxxxxxxxxxxxxxxxxxx>
RE: 2.6.18-rt7 on HP Z800
- From: "Simpson, John (UK) (Contractor)" <john.simpson@xxxxxxxxxxxxxxxx>
Re: [RT,RFC] Hacks allowing -rt to run on POWER7 / Powerpc.
- From: Will Schmidt <will_schmidt@xxxxxxxxxxxx>
Re: advanced tips for reducing latency?
- From: David Sommerseth <dazo@xxxxxxxxxxxxxxxxxxxxx>
advanced tips for reducing latency?
- From: jordan johnston <triplesquarednine@xxxxxxxxx>
2.6.18-rt7 on HP Z800
- From: "Simpson, John (UK) (Contractor)" <john.simpson@xxxxxxxxxxxxxxxx>
Re: Run RTLinux in a VM?
- From: Vivek Ayer <vivek.ayer@xxxxxxxxx>
Re: Run RTLinux in a VM?
- From: Vivek Ayer <vivek.ayer@xxxxxxxxx>
Re: Run RTLinux in a VM?
- From: Vivek Ayer <vivek.ayer@xxxxxxxxx>
Re: Run RTLinux in a VM?
- From: Klaas van Gend <klaas.van.gend@xxxxxxxxxx>
Re: Run RTLinux in a VM?
- From: Daniel James <daniel@xxxxxxxxxxxx>
Run RTLinux in a VM?
- From: Vivek Ayer <vivek.ayer@xxxxxxxxx>
[ANNOUNCE] 2.6.33.7-rt29
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.33.6-rt26: oops
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: 2.6.33.6-rt26: oops
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: RT patch for 2.6.27.35
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.33.6-rt26: oops (network related?)
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
RT patch for 2.6.27.35
- From: Zvi Vered <veredz72@xxxxxxxxx>
Re: 2.6.33.6-rt26: oops (network related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: disable address translation (virtual/physical)
- From: Reza Roboubi <reza@xxxxxxxxxxxxxxxx>
Re: 2.6.33.6-rt26: oops (network related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
disable address translation (virtual/physical)
- From: Reza Roboubi <reza@xxxxxxxxxxxxxxxx>
[ANNOUNCE] 2.6.33.6-rt27
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
[patch] rt-tests::signaltest: update trace/display capability to match cyclictest
- From: Mike Galbraith <efault@xxxxxx>
2.6.33.6-rt26: oops
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: [patch] drivers/dca: convert dca_lock to a raw spinlock V2
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: Q6600 + low frequency periodic timer + CPU_IDLE = much jitter
- From: Carsten Emde <Carsten.Emde@xxxxxxxxx>
Re: Q6600 + low frequency periodic timer + CPU_IDLE = much jitter
- From: Mike Galbraith <efault@xxxxxx>
Q6600 + low frequency periodic timer + CPU_IDLE = much jitter
- From: Mike Galbraith <efault@xxxxxx>
Re: [patch] drivers/dca: convert dca_lock to a raw spinlock V2
- From: Mike Galbraith <efault@xxxxxx>
Re: [patch] drivers/dca: convert dca_lock to a raw spinlock V2
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: 2.6.33.6-rt26: consoles not working properly
- From: Mike Galbraith <efault@xxxxxx>
Re: 2.6.33.6-rt26: consoles not working properly
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.33.6-rt26: consoles not working properly
- From: Mike Galbraith <efault@xxxxxx>
RT patch, error at boot and random freezes
- From: Roman Beslik <rabeslik@xxxxxxxxx>
2.6.33.6-rt26: consoles not working properly
- From: Mike Galbraith <efault@xxxxxx>
Re: RT support for LTS kernel 2.6.32 ?
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
[patch] drivers/dca: convert dca_lock to a raw spinlock V2
- From: Mike Galbraith <efault@xxxxxx>
Re: RT support for LTS kernel 2.6.32 ?
- From: Ng Oon-Ee <ngoonee@xxxxxxxxx>
disabling ACPI options video and button kernel 2.6.33.6
- From: Andres Cimmarusti <acimmarusti@xxxxxxxxx>
RT support for LTS kernel 2.6.32 ?
- From: Andres Cimmarusti <acimmarusti@xxxxxxxxx>
Re: Trouble booting PREEMPT_RT kernel on ARM platform, 2.6.33
- From: Jeremy Brown <jhbrown@xxxxxxxxxxxxxxxx>
Re: Trouble booting PREEMPT_RT kernel on ARM platform, 2.6.33
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: Trouble booting PREEMPT_RT kernel on ARM platform, 2.6.33
- From: gowrishankar <gowrishankar.m@xxxxxxxxxxxxxxxxxx>
Trouble booting PREEMPT_RT kernel on ARM platform, 2.6.33
- From: Jeremy Brown <jhbrown@xxxxxxxxxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.6-rt26
- From: Barry Song <21cnbao@xxxxxxxxx>
Re: [PATCH][RT] futex: protect against pi_blocked_on corruption during requeue PI -V2
- From: Mike Galbraith <efault@xxxxxx>
Compilation Issues with patch
- From: Rahul Kumar <mailforgroup@xxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.6-rt26
- From: Philipp Überbacher <hollunder@xxxxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.6-rt26
- From: Yang Jian <flyinwindy@xxxxxxxxx>
Re: 2.6.33.5 rt23: sleeping function called from invalid context
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.33.5 rt23: sleeping function called from invalid context
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: john stultz <johnstul@xxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
tsc_sync.c
- From: Andy Pont <andy.pont@xxxxxxxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.6-rt26
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.6-rt26
- From: Ng Oon-Ee <ngoonee@xxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.6-rt26
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Linux Plumbers Conference - Real-Time Track
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.6-rt26
- From: Philipp Überbacher <hollunder@xxxxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.6-rt26
- From: "Darcy L. Watkins" <dwatkins@xxxxxxxxxxx>
Re: [PATCH][RT] futex: protect against pi_blocked_on corruption during requeue PI -V2
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.6-rt26
- From: Philipp Überbacher <hollunder@xxxxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.6-rt26
- From: Dhaval Giani <dhaval.giani@xxxxxxxxx>
Re: [PATCH][RT] futex: protect against pi_blocked_on corruption during requeue PI -V2
- From: Mike Galbraith <efault@xxxxxx>
[ANNOUNCE] 2.6.33.6-rt26
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
[PATCH][RT] futex: protect against pi_blocked_on corruption during requeue PI -V2
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [PATCH][RT] futex: protect against pi_blocked_on corruption during requeue PI
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [PATCH][RT] futex: protect against pi_blocked_on corruption during requeue PI
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [PATCH][RT] futex: protect against pi_blocked_on corruption during requeue PI
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
[PATCH][RT] futex: protect against pi_blocked_on corruption during requeue PI
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: [PATCH 4/4] futex: convert hash_bucket locks to raw_spinlock_t
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: [PATCH 4/4] futex: convert hash_bucket locks to raw_spinlock_t
- From: Mike Galbraith <efault@xxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: john stultz <johnstul@xxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: john stultz <johnstul@xxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: [PATCH 4/4] futex: convert hash_bucket locks to raw_spinlock_t
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [PATCH 4/4] futex: convert hash_bucket locks to raw_spinlock_t
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [PATCH 4/4] futex: convert hash_bucket locks to raw_spinlock_t
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: [PATCH 4/4] futex: convert hash_bucket locks to raw_spinlock_t
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [PATCH 4/4] futex: convert hash_bucket locks to raw_spinlock_t
- From: Mike Galbraith <mgalbraith@xxxxxxx>
Re: [PATCH 4/4] futex: convert hash_bucket locks to raw_spinlock_t
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: [PATCH 3/4] futex: free_pi_state outside of hb->lock sections
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: [PATCH 3/4] futex: free_pi_state outside of hb->lock sections
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [PATCH 4/4] futex: convert hash_bucket locks to raw_spinlock_t
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: [PATCH 4/4] futex: convert hash_bucket locks to raw_spinlock_t
- From: Mike Galbraith <mgalbraith@xxxxxxx>
Re: [RT,RFC] Hacks allowing -rt to run on POWER7 / Powerpc.
- From: Milton Miller <miltonm@xxxxxxx>
Re: [PATCH 4/4] futex: convert hash_bucket locks to raw_spinlock_t
- From: Mike Galbraith <efault@xxxxxx>
Re: [PATCH 2/4 V2] rtmutex: add BUG_ON if a task attempts to block on two locks
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: [PATCH 1/4] rtmutex: avoid null derefence in WARN_ON
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: [PATCH 3/4 V2] futex: free_pi_state outside of hb->lock sections
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: [PATCH 4/4 V2] futex: convert hash_bucket locks to raw_spinlock_t
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: [PATCH 3/4 V2] futex: free_pi_state outside of hb->lock sections
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: [PATCH 2/4] rtmutex: add BUG_ON if a task attempts to block on two locks
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: [PATCH 1/4] rtmutex: avoid null derefence in WARN_ON
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: [PATCH 4/4 V2] futex: convert hash_bucket locks to raw_spinlock_t
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: john stultz <johnstul@xxxxxxxxxx>
Re: [PATCH 3/4 V2] futex: free_pi_state outside of hb->lock sections
- From: Darren Hart <dvhltc@xxxxxxxxxx>
[PATCH 3/4] futex: free_pi_state outside of hb->lock sections
- From: Darren Hart <dvhltc@xxxxxxxxxx>
[PATCH 4/4] futex: convert hash_bucket locks to raw_spinlock_t
- From: Darren Hart <dvhltc@xxxxxxxxxx>
[PATCH 2/4] rtmutex: add BUG_ON if a task attempts to block on two locks
- From: Darren Hart <dvhltc@xxxxxxxxxx>
[PATCH 1/4] rtmutex: avoid null derefence in WARN_ON
- From: Darren Hart <dvhltc@xxxxxxxxxx>
[PATCH 0/4][RT] futex: fix tasks blocking on two rt_mutex locks
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: john stultz <johnstul@xxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: john stultz <johnstul@xxxxxxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Mike Galbraith <efault@xxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
[PATCH, RT, RFC] Hacks allowing -rt to run on POWER7 / Powerpc.
- From: Will Schmidt <will_schmidt@xxxxxxxxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Mike Galbraith <mgalbraith@xxxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Mike Galbraith <efault@xxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Mike Galbraith <efault@xxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Mike Galbraith <efault@xxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: 2.6.33.5 rt23: sleeping function called from invalid context
- From: john stultz <johnstul@xxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: john stultz <johnstul@xxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: john stultz <johnstul@xxxxxxxxxx>
Re: 2.6.33.5 rt23: sleeping function called from invalid context
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.5 rt23: sleeping function called from invalid context
- From: john stultz <johnstul@xxxxxxxxxx>
2.6.33.5 rt23: machine lockup (nfs/autofs related?)
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Mike Galbraith <efault@xxxxxx>
2.6.33.5 rt23: sleeping function called from invalid context
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Mike Galbraith <efault@xxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: gowrishankar <gowrishankar.m@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Mike Galbraith <efault@xxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Mike Galbraith <efault@xxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Darren Hart <dvhltc@xxxxxxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Mike Galbraith <efault@xxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
[patch] drivers/dca: convert dca_lock to a raw spinlock
- From: Mike Galbraith <efault@xxxxxx>
Re: 2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Mike Galbraith <mgalbraith@xxxxxxx>
2.6.33.[56]-rt23: howto create repeatable explosion in wakeup_next_waiter()
- From: Mike Galbraith <efault@xxxxxx>
Re: future of -rt kernels for realtime audio
- From: Pedro Ribeiro <pedrib@xxxxxxxxx>
Re: future of -rt kernels for realtime audio
- From: Philipp Überbacher <hollunder@xxxxxxxxxxx>
Re: future of -rt kernels for realtime audio
- From: Mark Knecht <markknecht@xxxxxxxxx>
Re: future of -rt kernels for realtime audio
- From: Robin Gareus <robin@xxxxxxxxxx>
future of -rt kernels for realtime audio
- From: Pedro Ribeiro <pedrib@xxxxxxxxx>
Re: fast interprocess communication ?
- From: Pradyumna Sampath <pradysam@xxxxxxxxx>
Re: fast interprocess communication ?
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
Re: [PATCH 0/2] Debian's rt-tests patches
- From: Clark Williams <williams@xxxxxxxxxx>
[PATCH 2/2] install backfire's Makefile
- From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
[PATCH 1/2] modernize backfire's Makefile
- From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
[PATCH 0/2] Debian's rt-tests patches
- From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
Re: fast interprocess communication ?
- From: Pradyumna Sampath <pradysam@xxxxxxxxx>
fast interprocess communication ?
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
Re: Broken out patches for 2.6.31.12-rt21
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Re: Can't logon (2.6.18-rt7)
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Can't logon (2.6.18-rt7)
- From: "Simpson, John (UK) (Contractor)" <john.simpson@xxxxxxxxxxxxxxxx>
Broken out patches for 2.6.31.12-rt21
- From: Andy Pont <andy.pont@xxxxxxxxxxxxxx>
Re:
- From: Denis Borisevich <dennisfen@xxxxxxxxx>
[no subject]
- From: "Simpson, John (UK) (Contractor)" <john.simpson@xxxxxxxxxxxxxxxx>
Re: lockdep "splat" on v2.6.33.5-rt23
- From: john stultz <johnstul@xxxxxxxxxx>
lockdep "splat" on v2.6.33.5-rt23
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: beagleboard RT problem
- From: Maksym Parkachov <lazy.gopher@xxxxxxxxx>
RE: beagleboard RT problem
- From: "Chatterjee, Amit" <amit.chatterjee@xxxxxx>
Re: Realtime linux kernel on multicore processor
- From: Alessio Igor Bogani <abogani@xxxxxxxxxx>
Re: Realtime linux kernel on multicore processor
- From: Neel Mehta <neelmehta89@xxxxxxxxx>
Suspend: Mem leak and "sleeping function .. invalid context"
- From: louis@xxxxxxxxxxxxxxxx
Re: Linux, RT and virtualisation
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Re: Linux, RT and virtualisation
- From: Luis Henriques <luis.henrix@xxxxxxxxx>
Re: Linux, RT and virtualisation
- From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx>
Re: Linux, RT and virtualisation
- From: Luis Henriques <luis.henrix@xxxxxxxxx>
Re: Linux, RT and virtualisation
- From: Nicholas Mc Guire <der.herr@xxxxxxx>
Re: Linux, RT and virtualisation
- From: Frank Rowand <frank.rowand@xxxxxxxxxxx>
Linux, RT and virtualisation
- From: luis.henrix@xxxxxxxxx
Re: beagleboard RT problem
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Re: beagleboard RT problem
- From: Sujit K M <sjt.kar@xxxxxxxxx>
Re: beagleboard RT problem
- From: Maksym Parkachov <lazy.gopher@xxxxxxxxx>
shared memory
- From: ratheesh k <ratheesh.ksz@xxxxxxxxx>
Next RT kernel version
- From: Xianghua Xiao <xiaoxianghua@xxxxxxxxx>
Re: beagleboard RT problem
- From: Sujit K M <sjt.kar@xxxxxxxxx>
Re: beagleboard RT problem
- From: Maksym Parkachov <lazy.gopher@xxxxxxxxx>
Re: [PATCH 2/6: v4] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: Sven-Thorsten Dietrich <sdietrich@xxxxxxxxxx>
Re: Realtime linux kernel on multicore processor
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Realtime linux kernel on multicore processor
- From: Neel Mehta <neelmehta89@xxxxxxxxx>
Re: [PATCH 2/6: v4] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [PATCH 2/6: v4] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Re: [PATCH 2/6: v4] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [PATCH 2/6: v4] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: [PATCH 2/6: v4] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Re: [PATCH 2/6: v4] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [PATCH 2/6: v4] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Re: beagleboard RT problem
- From: Maksym Parkachov <lazy.gopher@xxxxxxxxx>
2.6.33.5-rt23: BUG (lock count overflow) while booting
- From: Gowrishankar Muthukrishnan <gowrishankar.m@xxxxxxxxxxxxxxxxxx>
[PATCH 2/6: v4] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: John Kacur <jkacur@xxxxxxxxxx>
[PATCH 1/6] tracing: Update the comm field in the right variable in update_max_tr
- From: John Kacur <jkacur@xxxxxxxxxx>
[PATCH 4/6] KEYS: find_keyring_by_name() can gain access to a freed keyring
- From: John Kacur <jkacur@xxxxxxxxxx>
[PATCH 5/6] hvc_console: Fix race between hvc_close and hvc_remove
- From: John Kacur <jkacur@xxxxxxxxxx>
[PATCH 6/6] hvc_console: Fix race between hvc_close and hvc_remove
- From: John Kacur <jkacur@xxxxxxxxxx>
[PATCH 3/6] perf: Fix errors path in perf_output_begin()
- From: John Kacur <jkacur@xxxxxxxxxx>
[PATCH 0/6] Potential rt patches for tip/rt/2.6.33
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.5-rt23
- From: Will Schmidt <will_schmidt@xxxxxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.5-rt23
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.5-rt23
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: beagleboard RT problem
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Re: beagleboard RT problem
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: beagleboard RT problem
- From: Sujit K M <sjt.kar@xxxxxxxxx>
Re: beagleboard RT problem
- From: Sujit K M <sjt.kar@xxxxxxxxx>
Re: beagleboard RT problem
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: beagleboard RT problem
- From: Maksym Parkachov <lazy.gopher@xxxxxxxxx>
Re: beagleboard RT problem
- From: Sujit K M <sjt.kar@xxxxxxxxx>
beagleboard RT problem
- From: Maksym Parkachov <lazy.gopher@xxxxxxxxx>
Re: Real-time projects that could use userspace RCU
- From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Re: Real-time projects that could use userspace RCU
- From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
2.6.33.4-rt20, BUG + Ooops
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Stable gianfar driver for 2.6.33/RT_PREEMPT
- From: Esben Haabendal <eha@xxxxxxxxxxxxxxxxxxxxxx>
Config_preempt_rt patch for 2.6.34 or newer kernels
- From: Kim Christensen <kingudk@xxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.5-rt23
- From: "Darcy L. Watkins" <dwatkins@xxxxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.5-rt23
- From: Will Schmidt <will_schmidt@xxxxxxxxxxxx>
Re: real time linux - which to use?
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
Re: real time linux - which to use?
- From: Neel Mehta <neelmehta89@xxxxxxxxx>
Re: real time linux - which to use?
- From: Nicholas Mc Guire <der.herr@xxxxxxx>
Re: real time linux - which to use?
- From: Pradyumna Sampath <pradysam@xxxxxxxxx>
real time linux - which to use?
- From: Neel Mehta <neelmehta89@xxxxxxxxx>
Re: Calculating latency using high resolution timer
- From: "Sarin, Suseelan" <suseelan@xxxxxxxxx>
Re: Calculating latency using high resolution timer
- From: "Sarin, Suseelan" <suseelan@xxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.5-rt23
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: At a loss: Kernel 2.6.19-rt15 with ixp425
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Re: [ANNOUNCE] 2.6.33.5-rt23
- From: Will Schmidt <will_schmidt@xxxxxxxxxxxx>
Re: At a loss: Kernel 2.6.19-rt15 with ixp425
- From: Xianghua Xiao <xiaoxianghua@xxxxxxxxx>
Re: Calculating latency using high resolution timer
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: At a loss: Kernel 2.6.19-rt15 with ixp425
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
[ANNOUNCE] 2.6.33.5-rt23
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Calculating latency using high resolution timer
- From: "Sarin, Suseelan" <suseelan@xxxxxxxxx>
Re: At a loss: Kernel 2.6.19-rt15 with ixp425
- From: Eric W Anderson <Eric.Anderson@xxxxxxxxxxxx>
Re: At a loss: Kernel 2.6.19-rt15 with ixp425
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
At a loss: Kernel 2.6.19-rt15 with ixp425
- From: Eric W Anderson <Eric.Anderson@xxxxxxxxxxxx>
Setting priority for irq threads at runtime
- From: "Nikita V. Youshchenko" <yoush@xxxxxxxxx>
Re: Changing real time priority of interrupt handler thread
- From: Clark Williams <clark.williams@xxxxxxxxx>
Re: Changing real time priority of interrupt handler thread
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: Changing real time priority of interrupt handler thread
- From: Raphael Hertzog <raphael@xxxxxxxxx>
Re: [RT] RCU splat on 2.6.33.4-rt20
- From: Clark Williams <williams@xxxxxxxxxx>
Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: "Nikita V. Youshchenko" <yoush@xxxxxxxxx>
Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: "Nikita V. Youshchenko" <yoush@xxxxxxxxx>
Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: "Nikita V. Youshchenko" <yoush@xxxxxxxxx>
Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: Sujit K M <sjt.kar@xxxxxxxxx>
Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: Sujit K M <sjt.kar@xxxxxxxxx>
Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: "Nikita V. Youshchenko" <yoush@xxxxxxxxx>
Re: [RT] RCU splat on 2.6.33.4-rt20
- From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
[RT] RCU splat on 2.6.33.4-rt20
- From: Clark Williams <williams@xxxxxxxxxx>
2.6.33.4-rt20 inconsistent lock state
- From: John Kacur <jkacur@xxxxxxxxx>
[PATCH] Staging: pohmelfs: Fix a build error
- From: Alessio Igor Bogani <abogani@xxxxxxxxxx>
[PATCH] Comedi: usbdux: Fix a syntax error
- From: Alessio Igor Bogani <abogani@xxxxxxxxxx>
Re: Microblaze RT
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Microblaze RT
- From: Michal Simek <michal.simek@xxxxxxxxxxxxx>
Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: Xianghua Xiao <xiaoxianghua@xxxxxxxxx>
Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: Xianghua Xiao <xiaoxianghua@xxxxxxxxx>
Re: Changing real time priority of interrupt handler thread
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Re: Changing real time priority of interrupt handler thread
- From: "Darcy L. Watkins" <dwatkins@xxxxxxxxxxx>
Re: Changing real time priority of interrupt handler thread
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Re: Changing real time priority of interrupt handler thread
- From: "Darcy L. Watkins" <dwatkins@xxxxxxxxxxx>
PREEMPT_RT (2.6.33-rt17) disabled printk-to-console after console_init
- From: Xianghua Xiao <xiaoxianghua@xxxxxxxxx>
Re: PREEMPT_RT patch vs RTAI/Xenomai
- From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
backtrace from tmpfs umount on 2.6.33.4-rt19 (tip/rt/2.6.33)
- From: Clark Williams <williams@xxxxxxxxxx>
Re: PREEMPT_RT patch vs RTAI/Xenomai
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
Re: PREEMPT_RT patch vs RTAI/Xenomai
- From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
Re: [ltt-dev] lttctl locks up with RT Linux
- From: Mathieu Desnoyers <compudj@xxxxxxxxxxxxxxxxxx>
RE: [ltt-dev] lttctl locks up with RT Linux
- From: <jpaul@xxxxxxxx>
Re: PREEMPT_RT patch vs RTAI/Xenomai
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
WARNING: at fs/namespace.c:648 commit_tree+0xf1/0x10b()
- From: "Luis Claudio R. Goncalves" <lclaudio@xxxxxxxx>
Re: PREEMPT_RT patch vs RTAI/Xenomai
- From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
Re: PREEMPT_RT patch vs RTAI/Xenomai
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
rt_mutex_lock
- From: ratheesh k <ratheesh.ksz@xxxxxxxxx>
Re: preempt_disable and sleep()
- From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Re: preempt_disable and sleep()
- From: ratheesh k <ratheesh.ksz@xxxxxxxxx>
Re: preempt_disable and sleep()
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
preempt_disable and sleep()
- From: ratheesh k <ratheesh.ksz@xxxxxxxxx>
Re: [ltt-dev] lttctl locks up with RT Linux
- From: Mathieu Desnoyers <compudj@xxxxxxxxxxxxxxxxxx>
Re: PREEMPT_RT patch vs RTAI/Xenomai
- From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
Re: PREEMPT_RT patch vs RTAI/Xenomai
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
Re: PREEMPT_RT patch vs RTAI/Xenomai
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
Re: Differnce between kthread and worqueue ?
- From: Jiri Slaby <jirislaby@xxxxxxxxx>
Re: Differnce between kthread and worqueue ?
- From: Jiri Slaby <jirislaby@xxxxxxxxx>
Differnce between kthread and worqueue ?
- From: ratheesh k <ratheesh.ksz@xxxxxxxxx>
Re: softirq-rx and rt_mutex_lock
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Re: PREEMPT_RT patch vs RTAI/Xenomai
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
[PATCH 2/2] Resolve mntput_no_expire issues.
- From: john stultz <johnstul@xxxxxxxxxx>
[PATCH 1/2] Fix mnt_count typo
- From: john stultz <johnstul@xxxxxxxxxx>
Re: [ltt-dev] lttctl locks up with RT Linux
- From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
RE: PREEMPT_RT patch vs RTAI/Xenomai
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
RE: [ltt-dev] lttctl locks up with RT Linux
- From: <jpaul@xxxxxxxx>
Re: [ltt-dev] lttctl locks up with RT Linux
- From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
RE: [ltt-dev] lttctl locks up with RT Linux
- From: <jpaul@xxxxxxxx>
RE: PREEMPT_RT patch vs RTAI/Xenomai
- From: "Asier Tamayo" <asier.tamayo@xxxxxxxxxxxxxxxxxxxxxx>
Re: [ltt-dev] lttctl locks up with RT Linux
- From: Mathieu Desnoyers <compudj@xxxxxxxxxxxxxxxxxx>
Re: Real-time projects that could use userspace RCU
- From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Re: PREEMPT_RT patch vs RTAI/Xenomai
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
PREEMPT_RT patch vs RTAI/Xenomai
- From: "Asier Tamayo" <asier.tamayo@xxxxxxxxxxxxxxxxxxxxxx>
Re: Real-time projects that could use userspace RCU
- From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
Re: Real-time projects that could use userspace RCU
- From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
Re: Real-time projects that could use userspace RCU
- From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
Re: Real-time projects that could use userspace RCU
- From: John Kacur <jkacur@xxxxxxxxxx>
Real-time projects that could use userspace RCU
- From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
Re: 2.6.33.3-rt19 kernel BUG's
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.3-rt19 kernel BUG's
- From: john stultz <johnstul@xxxxxxxxxx>
Re: 2.6.33.3-rt19 kernel BUG's
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
[PATCH] cyclictest: fix accumulating overruns in periodic timer mode
- From: Michal Schmidt <mschmidt@xxxxxxxxxx>
Re: 2.6.33.3-rt19 kernel BUG's
- From: john stultz <johnstul@xxxxxxxxxx>
Re: 2.6.33.3-rt19 kernel BUG's
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: 2.6.33.3-rt19 kernel BUG's
- From: john stultz <johnstul@xxxxxxxxxx>
Re: 2.6.33.3-rt19 kernel BUG's
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
2.6.33.3-rt19 kernel BUG's
- From: Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx>
Re: Changing real time priority of interrupt handler thread
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
Re: Changing real time priority of interrupt handler thread
- From: Nivedita Singhvi <niv@xxxxxxxxxx>
Changing real time priority of interrupt handler thread
- From: Raphael Hertzog <raphael@xxxxxxxxx>
Re: [PATCH V2] lockdep: reduce stack_trace usage
- From: Yong Zhang <yong.zhang@xxxxxxxxxxxxx>
Re: [PATCH V2] lockdep: reduce stack_trace usage
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Re: [RT] 2.6.33.3-rt19: WARNING: at fs/namespace.c:648 commit_tree+0xf1/0x10b()
- From: Nick Piggin <npiggin@xxxxxxx>
Re: [PATCH V2] lockdep: reduce stack_trace usage
- From: Yong Zhang <yong.zhang@xxxxxxxxxxxxx>
Re: [RT] 2.6.33.3-rt19: WARNING: at fs/namespace.c:648 commit_tree+0xf1/0x10b()
- From: john stultz <johnstul@xxxxxxxxxx>
Re: [RT] 2.6.33.3-rt19: WARNING: at fs/namespace.c:648 commit_tree+0xf1/0x10b()
- From: "Luis Claudio R. Goncalves" <lclaudio@xxxxxxxx>
Re: [RT] 2.6.33.3-rt19: WARNING: at fs/namespace.c:648 commit_tree+0xf1/0x10b()
- From: Nick Piggin <npiggin@xxxxxxx>
[RT] 2.6.33.3-rt19: WARNING: at fs/namespace.c:648 commit_tree+0xf1/0x10b()
- From: "Luis Claudio R. Goncalves" <lclaudio@xxxxxxxx>
Re: [PATCH V2] lockdep: reduce stack_trace usage
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
[PATCH V2] lockdep: reduce stack_trace usage
- From: Yong Zhang <yong.zhang@xxxxxxxxxxxxx>
Re: [PATCH] lockdep: reduce stack_trace usage
- From: Yong Zhang <yong.zhang@xxxxxxxxxxxxx>
Re: [Fwd: Re: RFC for a new Scheduling policy/class in the Linux-kernel]
- From: Ted Baker <baker@xxxxxxxxxx>
Re: [Fwd: Re: RFC for a new Scheduling policy/class in the Linux-kernel]
- From: Ted Baker <baker@xxxxxxxxxx>
Re: [Fwd: Re: RFC for a new Scheduling policy/class in the Linux-kernel]
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Re: [PATCH] lockdep: reduce stack_trace usage
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
[ANNOUNCE] 2.6.33.3-rt19
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [PATCH] rt: Remove irrelevant CONFIGS from reminder block.
- From: John Kacur <jkacur@xxxxxxxxx>
loadavgrt
- From: Xianghua Xiao <xiaoxianghua@xxxxxxxxx>
Re: 2.6.33.3-rt16: WARNING: at fs/namespace.c:1197 umount_tree+0x127/0x175()
- From: john stultz <johnstul@xxxxxxxxxx>
[ANNOUNCE] 2.6.33.3-rt17
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.33.3-rt16: WARNING: at fs/namespace.c:1197 umount_tree+0x127/0x175()
- From: "Luis Claudio R. Goncalves" <lclaudio@xxxxxxxx>
[PATCH] rt: Remove irrelevant CONFIGS from reminder block.
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [PATCH:resend] rt: Remove CONFIG_STACK_TRACER from DEBUG_COUNT, and fix reminder block
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: 2.6.33.3-rt16: WARNING: at fs/namespace.c:1197 umount_tree+0x127/0x175()
- From: john stultz <johnstul@xxxxxxxxxx>
powerpc gianfar driver does not work well when PREEMPT/PREEMPT_RT is enabled
- From: Xianghua Xiao <xiaoxianghua@xxxxxxxxx>
Re: 2.6.33.3-rt16: WARNING: at fs/namespace.c:1197 umount_tree+0x127/0x175()
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.33.3-rt16 compile failure in fs/ecryptfs/inode.o
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [PATCH:resend] rt: Remove CONFIG_STACK_TRACER from DEBUG_COUNT, and fix reminder block
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
2.6.33.3-rt16: WARNING: at fs/namespace.c:1197 umount_tree+0x127/0x175()
- From: "Luis Claudio R. Goncalves" <lclaudio@xxxxxxxx>
2.6.33.3-rt16 compile failure in fs/ecryptfs/inode.o
- From: John Kacur <jkacur@xxxxxxxxx>
Re: [PATCH:resend] rt: Remove CONFIG_STACK_TRACER from DEBUG_COUNT, and fix reminder block
- From: Clark Williams <williams@xxxxxxxxxx>
[PATCH:resend] rt: Remove CONFIG_STACK_TRACER from DEBUG_COUNT, and fix reminder block
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [BUG] 2.6.33.2-rt13 and iptables
- From: FC <prd.gtt@xxxxxxxxxxxxx>
[ANNOUNCE] 2.6.33.3-rt16
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [BUG] 2.6.33.2-rt13 and iptables
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: [Fwd: Re: RFC for a new Scheduling policy/class in the Linux-kernel]
- From: Doug Niehaus <niehaus@xxxxxxxxxxx>
Re: [Fwd: Re: RFC for a new Scheduling policy/class in the Linux-kernel]
- From: Joerg Roedel <joro@xxxxxxxxxx>
Re: [Fwd: Re: RFC for a new Scheduling policy/class in the Linux-kernel]
- From: Ted Baker <baker@xxxxxxxxxx>
Re: [PATCH] lockdep: reduce stack_trace usage
- From: Yong Zhang <yong.zhang@xxxxxxxxxxxxx>
[BUG] 2.6.33.2-rt13 and iptables
- From: FC <prd.gtt@xxxxxxxxxxxxx>
[PATCH] lockdep: reduce stack_trace usage
- From: Yong Zhang <yong.zhang0@xxxxxxxxx>
Re: [PATCH] lockdep: Add nr_save_trace_invocations counter
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [PATCH] lockdep: Add nr_save_trace_invocations counter
- From: Yong Zhang <yong.zhang@xxxxxxxxxxxxx>
Re: [PATCH] lockdep: Add nr_save_trace_invocations counter
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [PATCH] lockdep: Add nr_save_trace_invocations counter
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Re: [PATCH] lockdep: Add nr_save_trace_invocations counter
- From: Yong Zhang <yong.zhang@xxxxxxxxxxxxx>
Re: [PATCH] lockdep: Add nr_save_trace_invocations counter
- From: Yong Zhang <yong.zhang@xxxxxxxxxxxxx>
Re: [PATCH] lockdep: Add nr_save_trace_invocations counter
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [PATCH] lockdep: Add nr_save_trace_invocations counter
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Re: [PATCH] lockdep: Add nr_save_trace_invocations counter
- From: Yong Zhang <yong.zhang@xxxxxxxxxxxxx>
[PATCH] lockdep: Add nr_save_trace_invocations counter
- From: John Kacur <jkacur@xxxxxxxxx>
Linux Plumbers Conference 2010 (Nov 3-5) Call for Tracks
- From: Nivedita Singhvi <niveditasinghvi@xxxxxxxxx>
Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: "Gregory Haskins" <GHaskins@xxxxxxxxxx>
Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: "Gregory Haskins" <ghaskins@xxxxxxxxxx>
Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
2.6.33.2-rt13: RFC: fix serial console
- From: "Nikita V. Youshchenko" <yoush@xxxxxxxxx>
Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
[PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: John Kacur <jkacur@xxxxxxxxxx>
cpu usage with high-res timer
- From: Xianghua Xiao <xiaoxianghua@xxxxxxxxx>
Re: [RFC: PATCH v2] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Re: Strange behavior of pthread_setaffinity_np
- From: Primiano Tucci <p.tucci@xxxxxxxxx>
Re: [RFC: PATCH v2] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: John Kacur <jkacur@xxxxxxxxx>
Re: Strange behavior of pthread_setaffinity_np
- From: Sujit K M <sjt.kar@xxxxxxxxx>
Re: Strange behavior of pthread_setaffinity_np
- From: Primiano Tucci <p.tucci@xxxxxxxxx>
Re: Strange behavior of pthread_setaffinity_np
- From: Sujit K M <sjt.kar@xxxxxxxxx>
Strange behavior of pthread_setaffinity_np
- From: Primiano Tucci <p.tucci@xxxxxxxxx>
Re: Re: Looking for a real time IPC to be used with select
- From: "M. Koehrer" <mathias_koehrer@xxxxxxxx>
Re: RE: Looking for a real time IPC to be used with select
- From: "M. Koehrer" <mathias_koehrer@xxxxxxxx>
Re: 2.6.33.2-rt13 make fails
- From: Norval Watson <norv2001@xxxxxxxxxxxx>
Re: 2.6.33.2-rt13 make fails
- From: Norval Watson <norv2001@xxxxxxxxxxxx>
Re: 2.6.33.2-rt13 make fails
- From: Sven-Thorsten Dietrich <thebigcorporation@xxxxxxxxx>
2.6.33.2-rt13 make fails
- From: Norval Watson <norv2001@xxxxxxxxxxxx>
Re: Looking for a real time IPC to be used with select
- From: Sujit K M <sjt.kar@xxxxxxxxx>
Re: Looking for a real time IPC to be used with select
- From: Pradyumna Sampath <pradysam@xxxxxxxxx>
Re: Looking for a real time IPC to be used with select
- From: Armin Steinhoff <armin@xxxxxxxxxxxx>
RE: Looking for a real time IPC to be used with select
- From: "Leyendecker, Robert" <Robert.Leyendecker@xxxxxxx>
Re: [RFC: PATCH v2] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: John Kacur <jkacur@xxxxxxxxxx>
Looking for a real time IPC to be used with select
- From: "M. Koehrer" <mathias_koehrer@xxxxxxxx>
[RFC: PATCH] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: Debugging a hard lockup with no symptoms
- From: Martin Shepherd <mcs@xxxxxxxxxxxxxxxxx>
Re: Debugging a hard lockup with no symptoms
- From: Martin Shepherd <mcs@xxxxxxxxxxxxxxxxx>
Re: Debugging a hard lockup with no symptoms
- From: Martin Shepherd <mcs@xxxxxxxxxxxxxxxxx>
Re: Debugging a hard lockup with no symptoms
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
[RT:PATCH] tracing/x86: Add check to GCC messing with mcount prologue
- From: John Kacur <jkacur@xxxxxxxxxx>
Debugging a hard lockup with no symptoms
- From: Martin Shepherd <mcs@xxxxxxxxxxxxxxxxx>
Re: I attached a test module to reproduce this bug. Does I miss something in my code or is there a bug?
- From: Stefan Agner <stefan@xxxxxxxx>
Re: I attached a test module to reproduce this bug. Does I miss something in my code or is there a bug?
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.32 rt patch?
- From: Sven-Thorsten Dietrich <sdietrich@xxxxxxxxxx>
I attached a test module to reproduce this bug. Does I miss something in my code or is there a bug?
- From: Stefan Agner <stefan@xxxxxxxx>
Re: 2.6.32 rt patch?
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
2.6.33.1-rt11-related bug?
- From: Udo van den Heuvel <udovdh@xxxxxxxxx>
Re: 2.6.32 rt patch?
- From: "Nikita V. Youshchenko" <yoush@xxxxxxxxx>
Sangoma wanpipe driver
- From: Michael Mueller <ss7box@xxxxxxxxx>
[PATCH] rt: This fixes the boot-up messages related to CONFIG_STACK_TRACER
- From: John Kacur <jkacur@xxxxxxxxxx>
[rt: PATCH - resend] Fix-up boot-up warnings surrounding CONFIG_STACK_TRACER
- From: John Kacur <jkacur@xxxxxxxxxx>
[ANNOUNCE] 2.6.33.2-rt13
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: Kernel 2.6.33.1-rt11 on PPC405 UIC spinlock and serial input overruns
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.32 rt patch?
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.32 rt patch?
- From: John Kacur <jkacur@xxxxxxxxx>
2.6.32 rt patch?
- From: Xianghua Xiao <xiaoxianghua@xxxxxxxxx>
Re: Kernel 2.6.33.1-rt11 on PPC405 UIC spinlock and serial input overruns
- From: "Darcy Watkins" <DWatkins@xxxxxxxxxxx>
Re: 2.6.33.1-rt11 BUG: sleeping function called from invalid context at kernel/rtmutex.c:684
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.33.1-rt11 BUG: sleeping function called from invalid context at kernel/rtmutex.c:684
- From: Udo van den Heuvel <udovdh@xxxxxxxxx>
Re: 2.6.33.1-rt11 BUG: sleeping function called from invalid context at kernel/rtmutex.c:684
- From: "Luis Claudio R. Goncalves" <lclaudio@xxxxxxxx>
Re: 2.6.33.1-rt11 BUG: sleeping function called from invalid context at kernel/rtmutex.c:684
- From: Udo van den Heuvel <udovdh@xxxxxxxxx>
Re: 2.6.33.1-rt11 BUG: sleeping function called from invalid context at kernel/rtmutex.c:684
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: Kernel 2.6.33.1-rt11 on PPC405 UIC spinlock and serial input overruns
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Re: 2.6.33.1-rt11 BUG: sleeping function called from invalid context at kernel/rtmutex.c:684
- From: Udo van den Heuvel <udovdh@xxxxxxxxx>
2.6.33.1-rt11 BUG: sleeping function called from invalid context at kernel/rtmutex.c:684
- From: Udo van den Heuvel <udovdh@xxxxxxxxx>
[PATCH 2/2] let-message-queue-timeout-use-hrtimer.patch
- From: Carsten Emde <C.Emde@xxxxxxxxx>
[PATCH 1/2] provide-schedule_hrtimeout-for-wallclock.patch
- From: Carsten Emde <C.Emde@xxxxxxxxx>
[PATCH 0/2] Convert message queue timeouts to hrtimer
- From: Carsten Emde <C.Emde@xxxxxxxxx>
Kernel 2.6.33.1-rt11 on PPC405 UIC spinlock and serial input overruns
- From: "Darcy L. Watkins" <dwatkins@xxxxxxxxxxx>
Re: [PATCH v2] rt-tests: Add option to force timeout to pmqtest
- From: Clark Williams <williams@xxxxxxxxxx>
Re: [PATCH] rt-tests: Add timeout count to pmqtest's output
- From: Carsten Emde <C.Emde@xxxxxxxxx>
[PATCH v2] rt-tests: Add option to force timeout to pmqtest
- From: Carsten Emde <Carsten.Emde@xxxxxxxxx>
[CFP workshop] Operating System Platform for Embedded Real-Time applications 2010
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Re: [PATCH] Re: mq_timedrecieve timeout accuracy
- From: Pradyumna Sampath <pradysam@xxxxxxxxx>
[PATCH] Add test of message queues to rt-tests
- From: Carsten Emde <Carsten.Emde@xxxxxxxxx>
[PATCH] Re: mq_timedrecieve timeout accuracy
- From: Carsten Emde <Carsten.Emde@xxxxxxxxx>
Re: [BUG-REPORT][PREEMPT-RT] 2.6.33.1-rt11 triggers DEBUG_LOCKS_WARN_ON(!p->hardirqs_enabled), in a 32-bit kvm session
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [BUG-REPORT][PREEMPT-RT] 2.6.33.1-rt11 triggers DEBUG_LOCKS_WARN_ON(!p->hardirqs_enabled), in a 32-bit kvm session
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
[BUG-REPORT][PREEMPT-RT] 2.6.33.1-rt11 triggers DEBUG_LOCKS_WARN_ON(!p->hardirqs_enabled), in a 32-bit kvm session
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [PATCH 2/2] rt: Remove CONFIG_STACK_TRACER from DEBUG_COUNT
- From: John Kacur <jkacur@xxxxxxxxxx>
Re: [PATCH 2/2] rt: Remove CONFIG_STACK_TRACER from DEBUG_COUNT
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>

[Index of Archives] [RT Stable] [Kernel Announce] [IETF Annouce] [Security] [Netfilter] [Linux ATA RAID] [Bugtraq]