* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Here's a patch to move the pi_lock out of the "fast path". Thus, only
> threads that need to do PI will need to take it.
ok, looks good, applied it. I've renamed p->rt_lock to p->pi_lock. The
patch gave a 10% wall-clock improvement in hackbench nu
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Here's the port from the latest git to solve this.
>
> Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
thanks, applied.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
Here's a patch to move the pi_lock out of the "fast path". Thus, only
threads that need to do PI will need to take it.
Comments?
Please look for any race conditions or side effects that I might have
missed.
Thanks,
-- Steve
(Ingo and Thomas, this is what I already sent you)
Signed-off-by:
On Fri, Aug 19, 2005 at 07:20:20PM -0400, Steven Rostedt wrote:
> On Fri, 2005-08-19 at 16:12 -0700, Paul E. McKenney wrote:
> >
> > Hmmm Guess it is time for me to stop procrastinating on better
> > understanding git...
>
> Why? I still don't. Just go to http://www.kernel.org/ and download
On Fri, 2005-08-19 at 16:12 -0700, Paul E. McKenney wrote:
>
> Hmmm Guess it is time for me to stop procrastinating on better
> understanding git...
Why? I still don't. Just go to http://www.kernel.org/ and download the
latest git release (as of now it's -git11).
Of course you need to know
On Fri, Aug 19, 2005 at 07:02:42PM -0400, Steven Rostedt wrote:
> On Fri, 2005-08-19 at 15:47 -0700, Paul E. McKenney wrote:
>
> > Good catch -- but a few changes needed to be perfectly safe:
> >
> > static inline void *netpoll_poll_lock(struct net_device *dev)
> > {
> >
> >
On Fri, 2005-08-19 at 15:47 -0700, Paul E. McKenney wrote:
> Good catch -- but a few changes needed to be perfectly safe:
>
> static inline void *netpoll_poll_lock(struct net_device *dev)
> {
>
> struct netpoll_info *npi;
>
> rcu_read_lock();
>
On Fri, Aug 19, 2005 at 05:22:28PM -0400, Steven Rostedt wrote:
> On Wed, 2005-08-17 at 18:23 +0200, Ingo Molnar wrote:
>
> >
> > > And it goes on and on. This happens everytime. Without netconsole, I
> > > only get the nonzero lock count error. Also, one of my lockups on SMP
> > > had to do with
On Wed, 2005-08-17 at 18:23 +0200, Ingo Molnar wrote:
>
> > And it goes on and on. This happens everytime. Without netconsole, I
> > only get the nonzero lock count error. Also, one of my lockups on SMP
> > had to do with the kernel_thread_helper:
> >
> > Using IPI Shortcut mode
> > khelper/794[
On Wed, 2005-08-17 at 20:02 -0400, Steven Rostedt wrote:
> So I went back to the laptop's original config, and did one change. I
> disabled CONFIG_SCHED_SMT, rebooted, and the system booted up. It
> hasn't locked up after four boots. It did once get into some crazy bug
> with scheduling while at
On Wed, 2005-08-17 at 18:23 +0200, Ingo Molnar wrote:
> >
> > Using IPI Shortcut mode
> > khelper/794[CPU#0]: BUG in set_new_owner at kernel/rt.c:916
>
> this is a 'must not happen'. Somehow lock->held list got non-empty.
> Maybe some use-after-free thing? Havent seen it myself.
Well, I added
On Wed, 2005-08-17 at 21:27 +0200, Ingo Molnar wrote:
>
> Now that printk is in essence preemptible, there shouldnt be any
> warnings from netconsole - if there are any then it should be possible
> to fix them.
>
Then I guess write_msg in netconsole.c needs to remove all the
local_irq_disable
On Wed, 2005-08-17 at 13:32 -0400, Steven Rostedt wrote:
> On Wed, 2005-08-17 at 08:47 +0200, Ingo Molnar wrote:
>
> > but stop_machine() looks quite preempt-unsafe to begin with. The
> > local_irq_disable() would not be needed at all if prior the
> > for_each_online_cpu() loop we'd use set_cpus
On Wed, 2005-08-17 at 14:31 -0400, Steven Rostedt wrote:
> On my AMD SMP box, the system boots with no problems.
I shouldn't say no problems. I got this really nasty stuff on the serial
but not on the vga. Below is the patch.
I'm currently compiling my laptop to try this out. I started convert
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-17 at 10:24 -0400, Steven Rostedt wrote:
>
> > OK the output from netconsole still seems like netconsole itself is
> > causing some problems. But I think it is also showing this lockup. I'll
> > recompile my kernel as UP and see if n
On Wed, 2005-08-17 at 12:10 -0500, K.R. Foley wrote:
> This one has been biting me in the shorts since going to the 2.6.13-rc?
> RT series on my older SMP system at home. In every case the system hangs
> on shutdown and requires a hard reset. I just hadn't had the time to
> check into it. I was
On Wed, 2005-08-17 at 08:47 +0200, Ingo Molnar wrote:
> but stop_machine() looks quite preempt-unsafe to begin with. The
> local_irq_disable() would not be needed at all if prior the
> for_each_online_cpu() loop we'd use set_cpus_allowed. The current method
> of achieving 'no preemption' is sim
Ingo Molnar wrote:
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
On Wed, 2005-08-17 at 10:24 -0400, Steven Rostedt wrote:
OK the output from netconsole still seems like netconsole itself is
causing some problems. But I think it is also showing this lockup. I'll
recompile my kernel as UP and
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-17 at 10:24 -0400, Steven Rostedt wrote:
>
> > OK the output from netconsole still seems like netconsole itself is
> > causing some problems. But I think it is also showing this lockup. I'll
> > recompile my kernel as UP and see if n
el/rt.c:916
NMI watchdog detected lockup on CPU#1 (5/5)
Pid: 24, comm: khelper
EIP: 0060:[] CPU: 1
EIP is at up_mutex+0x98/0x440
EFLAGS: 0082 Not tainted (2.6.13-rc6-rt6)
EAX: c04278a4 EBX: cf68feec ECX: 0206 EDX: c0396b8c
ESI: cf68fec8 EDI: 0246 EBP: c011c191 DS: 007
tput (typed from screen).
>
> Freeing unused kernel memory: 296k freed
> NMI watchdog detected lockup on CPU#1 (50000/5)
>
> Pid: 796, comm: hotplug
> EIP: 0060:[] CPU: 1
> EIP is at _raw_spin_lock+0x72/0xa0
> EFLAGS: 0002 Not tainted (2.6.13-rc6-rt6)
> EXI: 0
ng yet.
Here's the output (typed from screen).
Freeing unused kernel memory: 296k freed
NMI watchdog detected lockup on CPU#1 (5/5)
Pid: 796, comm: hotplug
EIP: 0060:[] CPU: 1
EIP is at _raw_spin_lock+0x72/0xa0
EFLAGS: 0002 Not tainted (2.6.13-rc6-rt6)
EXI: 0
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-17 at 00:20 -0400, Steven Rostedt wrote:
> > Ingo,
> >
> > FYI, I ran this on my laptop (Pentium4 HT) and it locked up shortly
> > after it started INIT. I rebooted, and now it's up and running
> > with no problems!?! I'll reboot i
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Since the change made raw_local_save_flags the same for both
> PREEMPT_RT and !PREEMPT_RT, I moved it out of the #ifdef altogether.
> The __raw_local_save_flags already does the type checking (at least
> for intel).
ok, i've applied this one. Ind
On Wed, 2005-08-17 at 00:20 -0400, Steven Rostedt wrote:
> Ingo,
>
> FYI, I ran this on my laptop (Pentium4 HT) and it locked up shortly
> after it started INIT. I rebooted, and now it's up and running
> with no problems!?! I'll reboot it a few more times to see if it will
> lock up again.
Wit
Ingo,
FYI, I ran this on my laptop (Pentium4 HT) and it locked up shortly
after it started INIT. I rebooted, and now it's up and running
with no problems!?! I'll reboot it a few more times to see if it will
lock up again.
Unfortunately, my laptop doesn't have any serial so I don't have much to
On Tue, 2005-08-16 at 14:07 -0400, Steven Rostedt wrote:
> On Tue, 2005-08-16 at 13:50 -0400, Steven Rostedt wrote:
>
> > I changed it for now to the following, but it still desn't make sense to
> > me. With a local_save_flags, which doesn't disable or restore the
> > interrupts, why bother with
On Tue, 2005-08-16 at 13:50 -0400, Steven Rostedt wrote:
> I changed it for now to the following, but it still desn't make sense to
> me. With a local_save_flags, which doesn't disable or restore the
> interrupts, why bother with the trace at all?
Or should the following patch really be applied?
On Tue, 2005-08-16 at 19:08 +0200, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > it's the raw_local_irq_save() in ___trace() that causes trouble.
>
> ok, i've uploaded 2.6.13-rc6-rt6, which should fix this. (i've pushed
> the IRQ
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> it's the raw_local_irq_save() in ___trace() that causes trouble.
ok, i've uploaded 2.6.13-rc6-rt6, which should fix this. (i've pushed
the IRQ tracing into the raw_local_*() primitives, and kept the
__raw_local_*() primitives
30 matches
Mail list logo
