Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
At 01:57 AM 4/5/2005 -0600, Zwane Mwaikambo wrote: On Tue, 5 Apr 2005, Esben Nielsen wrote: > > I'm sure a lot of the yield() users could be converted to > > schedule_timeout(), some of the users i saw were for low memory conditions > > where we want other tasks to make progress and complete so that we a bit > > more free memory. > > > > Easy, but damn ugly. Completions are the right answer. The memory system > needs a queue system where tasks can sleep (with a timeout) until the > right amount of memory is available instead of half busy-looping. I agree entirely, that would definitely be a better way to go eventually. I wouldn't bet on it. There used to be a queue - minus the timeout. Throughput improved markedly with it's removal. That said, yield()s in the kernel can be quite evil. I once instrumented semaphores, and under hefty load, frequently found tasks waiting for a semaphore held by someone in the expired array. When you've got a busy cpu, that wait can be _extremely_ painful. The yield()s in mm/*.c are long gone (thank god), but after a quick grep/peek, I can imagine the one in free_more_memory() causing some throughput grief in a cpu intense environment, and the one in __wait_on_freeing_inode() would punt you into the dungeon while you're holding the inode lock... that looks like it could be pretty unpleasant. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Tue, 5 Apr 2005, Ingo Molnar wrote:
>
> * Esben Nielsen <[EMAIL PROTECTED]> wrote:
>
> > > Now the question is, who will fix it? Preferably the maintainers, but I
> > > don't know how much of a priority this is to them. I don't have the time
> > > now to look at this and understand enough about the code to be able to
> > > make a proper fix, and I'm sure you have other things to do too.
> >
> > How about adding a
> > if(rt_task(current)) {
> > WARN_ON(1);
> > mutex_setprio(current, MAX_PRIO-1)
> > }
> > ?
> >
> > to find all calls to yields from rt-tasks. That will force the user
> > (aka the real-time developer) to either stop calling the subsystems
> > still using yield from his RT-tasks, or fix those subsystems.
>
> i've added this to the -43-08 patch, so that we can see the scope of the
> problem. But any yield() use could become a problem due to priority
> inheritance. (which might eventually be expanded to userspace locking
> too)
>
Any calls to non-deterministic subsystems breaks the real-time properties.
yield() is certainly not the only problem. Code waiting for RCU-completion
or whatever is bad too. Calling code like that from RT-tasks or calling
them while having locks shared with RT-tasks is just bad. Anyone knowing
about RT development _has_ to know that. Putting warnings and traces into
the kernel is a nice feature.
Static code analyzes would also help quite a bit. What about having a new
attribute "nonrt" for functions and locks? yield() and syncronize_kernel() are
certain candidates. Any function having nonrt operations are marked
nonrt. Any lock becomes held while doing a nonrt operation is marked
nonrt. Taking a nonrt lock is a nonrt operation. (Might end up marking the
whole kernel nonrt)
Esben
> Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Tue, 5 Apr 2005, Esben Nielsen wrote: > > I'm sure a lot of the yield() users could be converted to > > schedule_timeout(), some of the users i saw were for low memory conditions > > where we want other tasks to make progress and complete so that we a bit > > more free memory. > > > > Easy, but damn ugly. Completions are the right answer. The memory system > needs a queue system where tasks can sleep (with a timeout) until the > right amount of memory is available instead of half busy-looping. I agree entirely, that would definitely be a better way to go eventually. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Tue, 5 Apr 2005, Esben Nielsen wrote: I'm sure a lot of the yield() users could be converted to schedule_timeout(), some of the users i saw were for low memory conditions where we want other tasks to make progress and complete so that we a bit more free memory. Easy, but damn ugly. Completions are the right answer. The memory system needs a queue system where tasks can sleep (with a timeout) until the right amount of memory is available instead of half busy-looping. I agree entirely, that would definitely be a better way to go eventually. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Tue, 5 Apr 2005, Ingo Molnar wrote:
* Esben Nielsen [EMAIL PROTECTED] wrote:
Now the question is, who will fix it? Preferably the maintainers, but I
don't know how much of a priority this is to them. I don't have the time
now to look at this and understand enough about the code to be able to
make a proper fix, and I'm sure you have other things to do too.
How about adding a
if(rt_task(current)) {
WARN_ON(1);
mutex_setprio(current, MAX_PRIO-1)
}
?
to find all calls to yields from rt-tasks. That will force the user
(aka the real-time developer) to either stop calling the subsystems
still using yield from his RT-tasks, or fix those subsystems.
i've added this to the -43-08 patch, so that we can see the scope of the
problem. But any yield() use could become a problem due to priority
inheritance. (which might eventually be expanded to userspace locking
too)
Any calls to non-deterministic subsystems breaks the real-time properties.
yield() is certainly not the only problem. Code waiting for RCU-completion
or whatever is bad too. Calling code like that from RT-tasks or calling
them while having locks shared with RT-tasks is just bad. Anyone knowing
about RT development _has_ to know that. Putting warnings and traces into
the kernel is a nice feature.
Static code analyzes would also help quite a bit. What about having a new
attribute nonrt for functions and locks? yield() and syncronize_kernel() are
certain candidates. Any function having nonrt operations are marked
nonrt. Any lock becomes held while doing a nonrt operation is marked
nonrt. Taking a nonrt lock is a nonrt operation. (Might end up marking the
whole kernel nonrt)
Esben
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
At 01:57 AM 4/5/2005 -0600, Zwane Mwaikambo wrote: On Tue, 5 Apr 2005, Esben Nielsen wrote: I'm sure a lot of the yield() users could be converted to schedule_timeout(), some of the users i saw were for low memory conditions where we want other tasks to make progress and complete so that we a bit more free memory. Easy, but damn ugly. Completions are the right answer. The memory system needs a queue system where tasks can sleep (with a timeout) until the right amount of memory is available instead of half busy-looping. I agree entirely, that would definitely be a better way to go eventually. I wouldn't bet on it. There used to be a queue - minus the timeout. Throughput improved markedly with it's removal. That said, yield()s in the kernel can be quite evil. I once instrumented semaphores, and under hefty load, frequently found tasks waiting for a semaphore held by someone in the expired array. When you've got a busy cpu, that wait can be _extremely_ painful. The yield()s in mm/*.c are long gone (thank god), but after a quick grep/peek, I can imagine the one in free_more_memory() causing some throughput grief in a cpu intense environment, and the one in __wait_on_freeing_inode() would punt you into the dungeon while you're holding the inode lock... that looks like it could be pretty unpleasant. -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Esben Nielsen <[EMAIL PROTECTED]> wrote:
> > Now the question is, who will fix it? Preferably the maintainers, but I
> > don't know how much of a priority this is to them. I don't have the time
> > now to look at this and understand enough about the code to be able to
> > make a proper fix, and I'm sure you have other things to do too.
>
> How about adding a
> if(rt_task(current)) {
> WARN_ON(1);
> mutex_setprio(current, MAX_PRIO-1)
> }
> ?
>
> to find all calls to yields from rt-tasks. That will force the user
> (aka the real-time developer) to either stop calling the subsystems
> still using yield from his RT-tasks, or fix those subsystems.
i've added this to the -43-08 patch, so that we can see the scope of the
problem. But any yield() use could become a problem due to priority
inheritance. (which might eventually be expanded to userspace locking
too)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Mon, 4 Apr 2005, Zwane Mwaikambo wrote: > On Mon, 4 Apr 2005, Steven Rostedt wrote: > > > On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote: > > > > > > Currently my fix is in yield to lower the priority of the task calling > > > > yield and raise it after the schedule. This is NOT a proper fix. It's > > > > just a hack so I can get by it and test other parts. > > > > > > yeah, yield() is a quite RT-incompatible concept, which could livelock > > > an upstream kernel just as much - if the task in question is SCHED_FIFO. > > > Almost all yield() uses should be eliminated from the upstream kernel, > > > step by step. > > > > Now the question is, who will fix it? Preferably the maintainers, but I > > don't know how much of a priority this is to them. I don't have the time > > now to look at this and understand enough about the code to be able to > > make a proper fix, and I'm sure you have other things to do too. > > I'm sure a lot of the yield() users could be converted to > schedule_timeout(), some of the users i saw were for low memory conditions > where we want other tasks to make progress and complete so that we a bit > more free memory. > Easy, but damn ugly. Completions are the right answer. The memory system needs a queue system where tasks can sleep (with a timeout) until the right amount of memory is available instead of half busy-looping. Esben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Mon, 4 Apr 2005, Steven Rostedt wrote:
> On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
>
> > > Currently my fix is in yield to lower the priority of the task calling
> > > yield and raise it after the schedule. This is NOT a proper fix. It's
> > > just a hack so I can get by it and test other parts.
> >
> > yeah, yield() is a quite RT-incompatible concept, which could livelock
> > an upstream kernel just as much - if the task in question is SCHED_FIFO.
> > Almost all yield() uses should be eliminated from the upstream kernel,
> > step by step.
>
> Now the question is, who will fix it? Preferably the maintainers, but I
> don't know how much of a priority this is to them. I don't have the time
> now to look at this and understand enough about the code to be able to
> make a proper fix, and I'm sure you have other things to do too.
How about adding a
if(rt_task(current)) {
WARN_ON(1);
mutex_setprio(current, MAX_PRIO-1)
}
?
to find all calls to yields from rt-tasks. That will force the user (aka
the real-time developer) to either stop calling the subsystems still using
yield from his RT-tasks, or fix those subsystems.
Esben
>
> -- Steve
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Mon, 2005-04-04 at 16:51 -0600, Zwane Mwaikambo wrote: > I'm sure a lot of the yield() users could be converted to > schedule_timeout(), some of the users i saw were for low memory conditions > where we want other tasks to make progress and complete so that we a bit > more free memory. > I've stated earlier that I was locked up in fs/inode.c with the __wait_on_freeing_inode. Can this be switched to a schedule_timeout? Of course schedule_timeout is not too good with RT as well. Although you can prevent a live_deadlock, but we bring up the problem of priority inversion again. The process needing to run can still be starved by another higher priority process that is lower in priority as the one doing the waiting. The schedule_timeout should stop the livelock. But what is the effect of switching to it? -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Mon, 4 Apr 2005, Steven Rostedt wrote: > On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote: > > > > Currently my fix is in yield to lower the priority of the task calling > > > yield and raise it after the schedule. This is NOT a proper fix. It's > > > just a hack so I can get by it and test other parts. > > > > yeah, yield() is a quite RT-incompatible concept, which could livelock > > an upstream kernel just as much - if the task in question is SCHED_FIFO. > > Almost all yield() uses should be eliminated from the upstream kernel, > > step by step. > > Now the question is, who will fix it? Preferably the maintainers, but I > don't know how much of a priority this is to them. I don't have the time > now to look at this and understand enough about the code to be able to > make a proper fix, and I'm sure you have other things to do too. I'm sure a lot of the yield() users could be converted to schedule_timeout(), some of the users i saw were for low memory conditions where we want other tasks to make progress and complete so that we a bit more free memory. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote: > > Currently my fix is in yield to lower the priority of the task calling > > yield and raise it after the schedule. This is NOT a proper fix. It's > > just a hack so I can get by it and test other parts. > > yeah, yield() is a quite RT-incompatible concept, which could livelock > an upstream kernel just as much - if the task in question is SCHED_FIFO. > Almost all yield() uses should be eliminated from the upstream kernel, > step by step. Now the question is, who will fix it? Preferably the maintainers, but I don't know how much of a priority this is to them. I don't have the time now to look at this and understand enough about the code to be able to make a proper fix, and I'm sure you have other things to do too. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > > actually, what priorities do the yielding tasks have? sched_yield() does > > not guarantee that the CPU will be given up, of if a highest-prio > > SCHED_FIFO task is in a yield() loop it will livelock the system. > > What scares me is the code in fs/inode.c with that > __wait_on_freeing_inode. Look at the code in find_inode and > find_inode_fast. Here you will see that they really are busy loops > with a yield in them, if the inode they are waiting on is I_FREEING or > I_CLEAR and the process doing this hasn't set I_LOCK. I haven't > looked much at this, but my kernel has livelocked on it. ok, makes sense. > Currently my fix is in yield to lower the priority of the task calling > yield and raise it after the schedule. This is NOT a proper fix. It's > just a hack so I can get by it and test other parts. yeah, yield() is a quite RT-incompatible concept, which could livelock an upstream kernel just as much - if the task in question is SCHED_FIFO. Almost all yield() uses should be eliminated from the upstream kernel, step by step. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Mon, 2005-04-04 at 22:00 +0200, Ingo Molnar wrote: > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > So it is probably stuck in some spinning "yield" loop, which was the > > reason I was writing this test to begin with! It's most likely also > > waiting for kjournald to do some work, and is starving it in a > > schedule or yield loop never actually going to sleep letting kjournald > > do the real work. > > actually, what priorities do the yielding tasks have? sched_yield() does > not guarantee that the CPU will be given up, of if a highest-prio > SCHED_FIFO task is in a yield() loop it will livelock the system. > What scares me is the code in fs/inode.c with that __wait_on_freeing_inode. Look at the code in find_inode and find_inode_fast. Here you will see that they really are busy loops with a yield in them, if the inode they are waiting on is I_FREEING or I_CLEAR and the process doing this hasn't set I_LOCK. I haven't looked much at this, but my kernel has livelocked on it. My custom kernel plays with dynamic priorities. That is tasks jump around in their priorities based on different situations not part of the normal linux kernel. So my kernel can find these cases easier since a path where a process gets bumped up to a high priority happens more often and causes preemption more often than the normal RT kernel. But this situation can probably occur in the RT kernel and maybe even the mainline kernel, since it only needs to have a RT FIFO task get blocked here, and a lower priority task needing to run to change the state. Currently my fix is in yield to lower the priority of the task calling yield and raise it after the schedule. This is NOT a proper fix. It's just a hack so I can get by it and test other parts. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > So it is probably stuck in some spinning "yield" loop, which was the > reason I was writing this test to begin with! It's most likely also > waiting for kjournald to do some work, and is starving it in a > schedule or yield loop never actually going to sleep letting kjournald > do the real work. actually, what priorities do the yielding tasks have? sched_yield() does not guarantee that the CPU will be given up, of if a highest-prio SCHED_FIFO task is in a yield() loop it will livelock the system. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Steven Rostedt [EMAIL PROTECTED] wrote: So it is probably stuck in some spinning yield loop, which was the reason I was writing this test to begin with! It's most likely also waiting for kjournald to do some work, and is starving it in a schedule or yield loop never actually going to sleep letting kjournald do the real work. actually, what priorities do the yielding tasks have? sched_yield() does not guarantee that the CPU will be given up, of if a highest-prio SCHED_FIFO task is in a yield() loop it will livelock the system. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Mon, 2005-04-04 at 22:00 +0200, Ingo Molnar wrote: * Steven Rostedt [EMAIL PROTECTED] wrote: So it is probably stuck in some spinning yield loop, which was the reason I was writing this test to begin with! It's most likely also waiting for kjournald to do some work, and is starving it in a schedule or yield loop never actually going to sleep letting kjournald do the real work. actually, what priorities do the yielding tasks have? sched_yield() does not guarantee that the CPU will be given up, of if a highest-prio SCHED_FIFO task is in a yield() loop it will livelock the system. What scares me is the code in fs/inode.c with that __wait_on_freeing_inode. Look at the code in find_inode and find_inode_fast. Here you will see that they really are busy loops with a yield in them, if the inode they are waiting on is I_FREEING or I_CLEAR and the process doing this hasn't set I_LOCK. I haven't looked much at this, but my kernel has livelocked on it. My custom kernel plays with dynamic priorities. That is tasks jump around in their priorities based on different situations not part of the normal linux kernel. So my kernel can find these cases easier since a path where a process gets bumped up to a high priority happens more often and causes preemption more often than the normal RT kernel. But this situation can probably occur in the RT kernel and maybe even the mainline kernel, since it only needs to have a RT FIFO task get blocked here, and a lower priority task needing to run to change the state. Currently my fix is in yield to lower the priority of the task calling yield and raise it after the schedule. This is NOT a proper fix. It's just a hack so I can get by it and test other parts. -- Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Steven Rostedt [EMAIL PROTECTED] wrote: actually, what priorities do the yielding tasks have? sched_yield() does not guarantee that the CPU will be given up, of if a highest-prio SCHED_FIFO task is in a yield() loop it will livelock the system. What scares me is the code in fs/inode.c with that __wait_on_freeing_inode. Look at the code in find_inode and find_inode_fast. Here you will see that they really are busy loops with a yield in them, if the inode they are waiting on is I_FREEING or I_CLEAR and the process doing this hasn't set I_LOCK. I haven't looked much at this, but my kernel has livelocked on it. ok, makes sense. Currently my fix is in yield to lower the priority of the task calling yield and raise it after the schedule. This is NOT a proper fix. It's just a hack so I can get by it and test other parts. yeah, yield() is a quite RT-incompatible concept, which could livelock an upstream kernel just as much - if the task in question is SCHED_FIFO. Almost all yield() uses should be eliminated from the upstream kernel, step by step. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote: Currently my fix is in yield to lower the priority of the task calling yield and raise it after the schedule. This is NOT a proper fix. It's just a hack so I can get by it and test other parts. yeah, yield() is a quite RT-incompatible concept, which could livelock an upstream kernel just as much - if the task in question is SCHED_FIFO. Almost all yield() uses should be eliminated from the upstream kernel, step by step. Now the question is, who will fix it? Preferably the maintainers, but I don't know how much of a priority this is to them. I don't have the time now to look at this and understand enough about the code to be able to make a proper fix, and I'm sure you have other things to do too. -- Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Mon, 4 Apr 2005, Steven Rostedt wrote: On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote: Currently my fix is in yield to lower the priority of the task calling yield and raise it after the schedule. This is NOT a proper fix. It's just a hack so I can get by it and test other parts. yeah, yield() is a quite RT-incompatible concept, which could livelock an upstream kernel just as much - if the task in question is SCHED_FIFO. Almost all yield() uses should be eliminated from the upstream kernel, step by step. Now the question is, who will fix it? Preferably the maintainers, but I don't know how much of a priority this is to them. I don't have the time now to look at this and understand enough about the code to be able to make a proper fix, and I'm sure you have other things to do too. I'm sure a lot of the yield() users could be converted to schedule_timeout(), some of the users i saw were for low memory conditions where we want other tasks to make progress and complete so that we a bit more free memory. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Mon, 2005-04-04 at 16:51 -0600, Zwane Mwaikambo wrote: I'm sure a lot of the yield() users could be converted to schedule_timeout(), some of the users i saw were for low memory conditions where we want other tasks to make progress and complete so that we a bit more free memory. I've stated earlier that I was locked up in fs/inode.c with the __wait_on_freeing_inode. Can this be switched to a schedule_timeout? Of course schedule_timeout is not too good with RT as well. Although you can prevent a live_deadlock, but we bring up the problem of priority inversion again. The process needing to run can still be starved by another higher priority process that is lower in priority as the one doing the waiting. The schedule_timeout should stop the livelock. But what is the effect of switching to it? -- Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Mon, 4 Apr 2005, Steven Rostedt wrote:
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
Currently my fix is in yield to lower the priority of the task calling
yield and raise it after the schedule. This is NOT a proper fix. It's
just a hack so I can get by it and test other parts.
yeah, yield() is a quite RT-incompatible concept, which could livelock
an upstream kernel just as much - if the task in question is SCHED_FIFO.
Almost all yield() uses should be eliminated from the upstream kernel,
step by step.
Now the question is, who will fix it? Preferably the maintainers, but I
don't know how much of a priority this is to them. I don't have the time
now to look at this and understand enough about the code to be able to
make a proper fix, and I'm sure you have other things to do too.
How about adding a
if(rt_task(current)) {
WARN_ON(1);
mutex_setprio(current, MAX_PRIO-1)
}
?
to find all calls to yields from rt-tasks. That will force the user (aka
the real-time developer) to either stop calling the subsystems still using
yield from his RT-tasks, or fix those subsystems.
Esben
-- Steve
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Mon, 4 Apr 2005, Zwane Mwaikambo wrote: On Mon, 4 Apr 2005, Steven Rostedt wrote: On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote: Currently my fix is in yield to lower the priority of the task calling yield and raise it after the schedule. This is NOT a proper fix. It's just a hack so I can get by it and test other parts. yeah, yield() is a quite RT-incompatible concept, which could livelock an upstream kernel just as much - if the task in question is SCHED_FIFO. Almost all yield() uses should be eliminated from the upstream kernel, step by step. Now the question is, who will fix it? Preferably the maintainers, but I don't know how much of a priority this is to them. I don't have the time now to look at this and understand enough about the code to be able to make a proper fix, and I'm sure you have other things to do too. I'm sure a lot of the yield() users could be converted to schedule_timeout(), some of the users i saw were for low memory conditions where we want other tasks to make progress and complete so that we a bit more free memory. Easy, but damn ugly. Completions are the right answer. The memory system needs a queue system where tasks can sleep (with a timeout) until the right amount of memory is available instead of half busy-looping. Esben - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Esben Nielsen [EMAIL PROTECTED] wrote:
Now the question is, who will fix it? Preferably the maintainers, but I
don't know how much of a priority this is to them. I don't have the time
now to look at this and understand enough about the code to be able to
make a proper fix, and I'm sure you have other things to do too.
How about adding a
if(rt_task(current)) {
WARN_ON(1);
mutex_setprio(current, MAX_PRIO-1)
}
?
to find all calls to yields from rt-tasks. That will force the user
(aka the real-time developer) to either stop calling the subsystems
still using yield from his RT-tasks, or fix those subsystems.
i've added this to the -43-08 patch, so that we can see the scope of the
problem. But any yield() use could become a problem due to priority
inheritance. (which might eventually be expanded to userspace locking
too)
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote: > > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a > > Grub option), and the system just locked up hard. I just was curious > > if this was from a different change. But at least in the latest it > > shows output, and not just a hard lockup. > > > > Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. > > ok, so it's not the recent NFS changes. Here's an interesting trace I got today. It looks either the emu10k1 or USB irq handler left IRQ 10 disabled. This isn't a tracer bug because you can clearly see this leads to an xrun. Since I've been hacking the emu10k1 driver quite a bit, I suspect this is the problem. This trace also shows that my trigger callback for the emu10k1 multichannel device needs optimizing; it takes 300 usecs to stop all 16 voices, not acceptable for an ALSA irq handler which uses SA_INTERRUPT. I think I can improve this significantly by reordering the register settings and eliminating some function call overhead. Lee latency_trace.bz2 Description: application/bzip
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Saturday 02 April 2005 15:34, Ingo Molnar wrote:
>* Lee Revell <[EMAIL PROTECTED]> wrote:
>> It wasn't clear from your last mail whether you were using NFS.
>> If so I would be suspicious given the NFS changes in the new RT
>> patches. I'll try to reproduce the problem on a local fs.
>
>also, try to undo the fs/nfs/*.c and include/linux/*nfs*.h changes,
>those are latency breakers, so not strictly necessary.
>
> Ingo
Hi Ingo;
I just got done rebooting to 43-06, had problems with my heyu
startup scripts again, but I finally found a missing & in one
of them, and I can have it recycle itself from the cli like it
used to again.
So far, with *all* the 'logit' switches turned on and in full
preempt mode, there's nothing unusual in the log.
Here goes tvtime from a cli:
Audio only, blue screen video, this in the log:
---
Apr 2 17:12:48 coyote kernel: cx88[0]: video y / packed - dma channel status
dump
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: initial risc: 0x06b46000
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: cdt base: 0x00180440
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: cdt size: 0x000c
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq base : 0x00180400
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq size : 0x0010
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: risc pc : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq wr ptr : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq rd ptr : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: cdt current : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: pci target : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: line / byte : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: risc0: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: risc1: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: risc2: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: risc3: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 0: 0x80008000 [ sync resync
count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 1: 0x1c000500 [ write sol eol
count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 2: 0x06922000 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 3: 0x1c000500 [ write sol eol
count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 4: 0x06922a00 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 5: 0x1c000500 [ write sol eol
count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 6: 0x2dc68400 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 7: 0x18000200 [ write sol
count=512 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 8: 0x2dc68e00 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 9: 0x14000300 [ write eol
count=768 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq a: 0x2dc69000 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq b: 0x1c000500 [ write sol eol
count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq c: 0x2dc69800 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq d: 0x0031c040 [ INVALID 21 20 cnt0
resync 14 count=64 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq e: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq f: 0x0011 [ INVALID count=17 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: fifo: 0x00180c00 -> 0x183400
Apr 2 17:12:48 coyote kernel: cx88[0]: ctrl: 0x00180400 -> 0x180460
Apr 2 17:12:48 coyote kernel: cx88[0]: ptr1_reg: 0x00182118
Apr 2 17:12:48 coyote kernel: cx88[0]: ptr2_reg: 0x00180488
Apr 2 17:12:48 coyote kernel: cx88[0]: cnt1_reg: 0x0082
Apr 2 17:12:48 coyote kernel: cx88[0]: cnt2_reg: 0x
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d4da5940/0] timeout - dma=0x
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d4da5d40/1] timeout - dma=0x
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d417d960/2] timeout - dma=0x
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d4da5540/3] timeout - dma=0x06b46000
Apr 2 17:12:49 coyote kernel: cx88[0]: video y / packed - dma channel status
dump
[...]
followed by many repeats of the above as I let it run about
5-6 seconds. On exit, this:
Apr 2 17:12:57 coyote kernel: rtc latency histogram of {tvtime/5717, 232
samples}:
Apr 2 17:12:57 coyote kernel: 20 4
Apr 2 17:12:57 coyote kernel: 21 81
Apr 2 17:12:57 coyote kernel: 22 64
Apr 2 17:12:57 coyote kernel: 23 32
Apr 2 17:12:57 coyote kernel: 24 13
Apr 2 17:12:57 coyote kernel: 25 2
Apr 2 17:12:57 coyote kernel: 26 8
Apr 2 17:12:57 coyote kernel: 27 2
Apr 2 17:12:57 coyote kernel: 28 3
Apr 2 17:12:57 coyote kernel: 29 1
Apr 2 17:12:57 coyote kernel: 30 1
Apr 2 17:12:57 coyote kernel: 32 2
Apr 2 17:12:57 coyote kernel: 33 2
Apr 2 17:12:57 coyote kernel: 34 1
Apr 2 17:12:57 coyote kernel: 35 1
Apr 2 17:12:57 coyote kernel: 37 1
Apr 2 17:12:57 coyote kernel: 14
dma timeouts. I don't get these, and I do get good
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Sat, 2005-04-02 at 15:44 -0500, Steven Rostedt wrote: > On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote: > > > > > > FYI > > > > > > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a > > > Grub option), and the system just locked up hard. I just was curious > > > if this was from a different change. But at least in the latest it > > > shows output, and not just a hard lockup. > > > > > > Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. > > > > ok, so it's not the recent NFS changes. > > > > I may need to take this back. I forgot to open the serial, so it wasn't > accepting input. So it would just appear dead. And the console was > fighting against the RT tasks, so it too would seem to be dead. I've > reran the test on the latest, but this time I didn't have the NFS > mounted, and it's still running. > I tried the 2.6.12-rc1-RT-V0.7.43-06 kernel again, and I still have the serial, to do sysrq. The console is using X which locks (even all the ctrl-alt-X functions) and the ssh session that I run the test stops after the processes try to grab the locks. It doesn't reply to ping. But the sysrq from the serial shows constantly: stest3_rt: 2269 [cf304690, 89] (not blocked) stest3_rt: 2270 [cf304050, 88] (not blocked) stest3_rt: 2271 [cef86cb0, 87] (not blocked) stest3_rt: 2272 [cef86670, 86] (not blocked) Rtest3_rt: 2273 [cf28a050, 85] (not blocked) So it seems that it's in a deadlock somewhere. Since the 43-06 gets much further, this seems to be another problem. I'm not going to look at this problem anymore, since it doesn't show up in the lastest. I'll run a few more tests to see if I can narrow things down on 43-06. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote: > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote: > > > > > Here's the bug I get: > > > > > > > FYI > > > > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a > > Grub option), and the system just locked up hard. I just was curious > > if this was from a different change. But at least in the latest it > > shows output, and not just a hard lockup. > > > > Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. > > ok, so it's not the recent NFS changes. > I may need to take this back. I forgot to open the serial, so it wasn't accepting input. So it would just appear dead. And the console was fighting against the RT tasks, so it too would seem to be dead. I've reran the test on the latest, but this time I didn't have the NFS mounted, and it's still running. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Lee Revell <[EMAIL PROTECTED]> wrote: > It wasn't clear from your last mail whether you were using NFS. If so > I would be suspicious given the NFS changes in the new RT patches. > I'll try to reproduce the problem on a local fs. also, try to undo the fs/nfs/*.c and include/linux/*nfs*.h changes, those are latency breakers, so not strictly necessary. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote: > > > Here's the bug I get: > > > > FYI > > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a > Grub option), and the system just locked up hard. I just was curious > if this was from a different change. But at least in the latest it > shows output, and not just a hard lockup. > > Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. ok, so it's not the recent NFS changes. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Sat, 2005-04-02 at 15:06 -0500, Steven Rostedt wrote: > On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote: > > > Here's the bug I get: > > > > FYI > > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a > Grub option), and the system just locked up hard. I just was curious if > this was from a different change. But at least in the latest it shows > output, and not just a hard lockup. I had the same results yesterday, while punishing the swap by building the kernel with make -j64 over NFS. It thrashed wildly for 20 minutes or so then eventually all disk activity stopped. Of course that stupid cow continued bouncing up and down... It wasn't clear from your last mail whether you were using NFS. If so I would be suspicious given the NFS changes in the new RT patches. I'll try to reproduce the problem on a local fs. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote: > What the test program does, is spawn 5 processes, each with a different > priority. Starting with 10 and going to 14. All are SCHED_FIFO. Each of > these processes just do a scan of all directories starting with the root > directory '/' and going down. I usually run this with a directory NFS > mounted too, but I don't think this was a problem. My knowledge of the kernel is still pretty limited, but it looks to me like something corrupted the timer list. Have you tried kdb? Last time I checked it worked great with PREEMPT_RT. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote: > Here's the bug I get: > FYI For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a Grub option), and the system just locked up hard. I just was curious if this was from a different change. But at least in the latest it shows output, and not just a hard lockup. Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
Hi Ingo,
I've discovered a problem with basically all "yields" in the kernel. But
that's not why I'm writing you this. To see if your kernel has the same
problems as mine, I wrote a modified test that caused me the problems,
and ran it on your kernel. But too my surprise, this test caused other
problems. This modified test causes my kernel the same types of problems
too.
Attached is the test I ran. The list.h is just my version of the kernels
list functions for userspace. It's used in the test program.
What the test program does, is spawn 5 processes, each with a different
priority. Starting with 10 and going to 14. All are SCHED_FIFO. Each of
these processes just do a scan of all directories starting with the root
directory '/' and going down. I usually run this with a directory NFS
mounted too, but I don't think this was a problem.
Here's the bug I get:
Slab corruption: start=cfc45938, len=276
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [](mempool_free+0x9d/0xb0)
050: 68 9a 3e c0 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Prev obj: start=cfc45818, len=276
Redzone: 0x170fc2a5/0x170fc2a5.
Last user: [](mempool_create+0xe8/0x120)
000: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
010: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
Next obj: start=cfc45a58, len=276
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [<>](0x0)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
BUG at kernel/timer.c:419!
[ cut here ]
kernel BUG at kernel/timer.c:419!
invalid operand: [#1]
PREEMPT
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010282 (2.6.12-rc1-RT-V0.7.43-06)
EIP is at cascade+0x6d/0x80
eax: 001e ebx: c03e9a90 ecx: edx: c0118720
esi: c03e9a68 edi: c03e9a90 ebp: c1273f44 esp: c1273f2c
ds: 007b es: 007b ss: 0068 preempt: 0001
Process ksoftirqd/0 (pid: 2, threadinfo=c1272000 task=cffed260)
Stack: c0387e66 c0389ef9 01a3 c03e9878 c1273f60 c1273f78 c0121bae
c03e9080 c03e98f0 002f c1272000 c1273f60 c1273f60 c0112643
0005 c1272000 c1273fa0 c011d45a c04f3e28 c1272000 cffeff00
Call Trace:
[] show_stack+0x8f/0xb0 (28)
[] show_registers+0x16a/0x1d0 (56)
[] die+0xf6/0x190 (64)
[] do_invalid_op+0xc1/0xd0 (204)
[] error_code+0x2b/0x30 (84)
[] run_timer_softirq+0x2ae/0x420 (52)
[] ___do_softirq+0x9a/0x100 (40)
[] _do_softirq+0x29/0x30 (8)
[] ksoftirqd+0xb1/0x130 (20)
[] kthread+0xaa/0xb0 (48)
[] kernel_thread_helper+0x5/0x10 (1054392340)
---
| preempt count: 0002 ]
| 2-level deep critical section nesting:
.. [] die+0x43/0x190
.[] .. ( <= do_invalid_op+0xc1/0xd0)
.. [] print_traces+0x1d/0x60
.[] .. ( <= show_stack+0x8f/0xb0)
Code: 76 04 8b 45 10 83 c4 0c 5b 5e 5f 5d c3 c7 04 24 66 7e 38 c0 b8 a3 01 00
00 89 44 24 08 b8 f9 9e 38 c0 89 44 24 04 e8 d3 6e ff ff <0f> 0b a3 01 f9 9e 38
c0 eb b3 89 f6 8d bc 27 00 00 00 00 55 89
BUG: ksoftirqd/0/2, lock held at task exit time!
[c03e9080] {>lock}
.. held by: ksoftirqd/0:2 [cffed260, 106]
... acquired at: run_timer_softirq+0x243/0x420
-- Steve
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define __USE_GNU
#include
#ifdef SDR_TOOLS
#include
#include
#include
#include
#include "dump_trace.h"
int logfd = -1;
#else
#define logdev_print(x...) do {} while(0)
#define logdev_switch_set(x) (0)
#endif
#include
static int reader (int i);
typedef int (*callfunc_t)(int);
#define NR_PROCS 5
pid_t pids[NR_PROCS];
callfunc_t dofunc[NR_PROCS] = {
reader,
reader,
reader,
reader,
reader
};
int priorities[NR_PROCS] = {
10,
11,
12,
13,
14,
};
key_t key;
int semid = -1;
int shmid = -1;
int safe = 0;
int tod = 0;
int *flags;
void cleanup(void)
{
int i;
for (i=0; i < NR_PROCS; i++) {
if (pids[i])
kill(pids[i],SIGKILL);
}
if (semid >= 0)
semctl(semid, 0, IPC_RMID);
if (shmid >= 0)
shmctl(shmid, IPC_RMID, NULL);
#ifdef SDR_TOOLS
if (logfd >= 0)
close_logdev(logfd);
#endif
}
void catchall(int sig)
{
cleanup();
psignal(sig,"Caught: ");
exit(-1);
}
static int compare_timeval(const struct timeval *a, const struct timeval *b)
{
return (a->tv_sec > b->tv_sec) ? 1 :
(a->tv_sec < b->tv_sec) ? -1:
(a->tv_usec > b->tv_usec) ? 1:
(a->tv_usec < b->tv_usec) ? -1:
0;
}
static void add_timeval(const struct timeval *a, const struct timeval *b, struct timeval *c)
{
c->tv_usec = a->tv_usec + b->tv_usec;
c->tv_sec = a->tv_sec + b->tv_sec;
while (c->tv_usec > 100) {
c->tv_usec -= 100;
c->tv_sec++;
}
}
static void sub_timeval(const struct timeval *a, const struct timeval *b, struct timeval *c)
{
c->tv_usec = a->tv_usec - b->tv_usec;
c->tv_sec = a->tv_sec - b->tv_sec;
while (c->tv_usec < 0) {
c->tv_usec +=
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
Hi Ingo,
I've discovered a problem with basically all yields in the kernel. But
that's not why I'm writing you this. To see if your kernel has the same
problems as mine, I wrote a modified test that caused me the problems,
and ran it on your kernel. But too my surprise, this test caused other
problems. This modified test causes my kernel the same types of problems
too.
Attached is the test I ran. The list.h is just my version of the kernels
list functions for userspace. It's used in the test program.
What the test program does, is spawn 5 processes, each with a different
priority. Starting with 10 and going to 14. All are SCHED_FIFO. Each of
these processes just do a scan of all directories starting with the root
directory '/' and going down. I usually run this with a directory NFS
mounted too, but I don't think this was a problem.
Here's the bug I get:
Slab corruption: start=cfc45938, len=276
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [c0142b1d](mempool_free+0x9d/0xb0)
050: 68 9a 3e c0 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Prev obj: start=cfc45818, len=276
Redzone: 0x170fc2a5/0x170fc2a5.
Last user: [c01426a8](mempool_create+0xe8/0x120)
000: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
010: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
Next obj: start=cfc45a58, len=276
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [](0x0)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
BUG at kernel/timer.c:419!
[ cut here ]
kernel BUG at kernel/timer.c:419!
invalid operand: [#1]
PREEMPT
Modules linked in:
CPU:0
EIP:0060:[c012142d]Not tainted VLI
EFLAGS: 00010282 (2.6.12-rc1-RT-V0.7.43-06)
EIP is at cascade+0x6d/0x80
eax: 001e ebx: c03e9a90 ecx: edx: c0118720
esi: c03e9a68 edi: c03e9a90 ebp: c1273f44 esp: c1273f2c
ds: 007b es: 007b ss: 0068 preempt: 0001
Process ksoftirqd/0 (pid: 2, threadinfo=c1272000 task=cffed260)
Stack: c0387e66 c0389ef9 01a3 c03e9878 c1273f60 c1273f78 c0121bae
c03e9080 c03e98f0 002f c1272000 c1273f60 c1273f60 c0112643
0005 c1272000 c1273fa0 c011d45a c04f3e28 c1272000 cffeff00
Call Trace:
[c0103bef] show_stack+0x8f/0xb0 (28)
[c0103daa] show_registers+0x16a/0x1d0 (56)
[c0103fc6] die+0xf6/0x190 (64)
[c01044e1] do_invalid_op+0xc1/0xd0 (204)
[c010381b] error_code+0x2b/0x30 (84)
[c0121bae] run_timer_softirq+0x2ae/0x420 (52)
[c011d45a] ___do_softirq+0x9a/0x100 (40)
[c011d579] _do_softirq+0x29/0x30 (8)
[c011da41] ksoftirqd+0xb1/0x130 (20)
[c012de1a] kthread+0xaa/0xb0 (48)
[c0100e35] kernel_thread_helper+0x5/0x10 (1054392340)
---
| preempt count: 0002 ]
| 2-level deep critical section nesting:
.. [c0103f13] die+0x43/0x190
.[c01044e1] .. ( = do_invalid_op+0xc1/0xd0)
.. [c0137b8d] print_traces+0x1d/0x60
.[c0103bef] .. ( = show_stack+0x8f/0xb0)
Code: 76 04 8b 45 10 83 c4 0c 5b 5e 5f 5d c3 c7 04 24 66 7e 38 c0 b8 a3 01 00
00 89 44 24 08 b8 f9 9e 38 c0 89 44 24 04 e8 d3 6e ff ff 0f 0b a3 01 f9 9e 38
c0 eb b3 89 f6 8d bc 27 00 00 00 00 55 89
BUG: ksoftirqd/0/2, lock held at task exit time!
[c03e9080] {base-lock}
.. held by: ksoftirqd/0:2 [cffed260, 106]
... acquired at: run_timer_softirq+0x243/0x420
-- Steve
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
#include time.h
#include sys/sem.h
#include sys/shm.h
#include sys/time.h
#include sys/wait.h
#include sys/types.h
#include sys/stat.h
#include dirent.h
#include fcntl.h
#include signal.h
#include ctype.h
#include sched.h
#define __USE_GNU
#include sys/ipc.h
#ifdef SDR_TOOLS
#include dump_log.h
#include linux/logdev.h
#include dump_log.h
#include tracer_xml.h
#include dump_trace.h
int logfd = -1;
#else
#define logdev_print(x...) do {} while(0)
#define logdev_switch_set(x) (0)
#endif
#include list.h
static int reader (int i);
typedef int (*callfunc_t)(int);
#define NR_PROCS 5
pid_t pids[NR_PROCS];
callfunc_t dofunc[NR_PROCS] = {
reader,
reader,
reader,
reader,
reader
};
int priorities[NR_PROCS] = {
10,
11,
12,
13,
14,
};
key_t key;
int semid = -1;
int shmid = -1;
int safe = 0;
int tod = 0;
int *flags;
void cleanup(void)
{
int i;
for (i=0; i NR_PROCS; i++) {
if (pids[i])
kill(pids[i],SIGKILL);
}
if (semid = 0)
semctl(semid, 0, IPC_RMID);
if (shmid = 0)
shmctl(shmid, IPC_RMID, NULL);
#ifdef SDR_TOOLS
if (logfd = 0)
close_logdev(logfd);
#endif
}
void catchall(int sig)
{
cleanup();
psignal(sig,Caught: );
exit(-1);
}
static int compare_timeval(const struct timeval *a, const struct timeval *b)
{
return (a-tv_sec b-tv_sec) ? 1 :
(a-tv_sec b-tv_sec) ? -1:
(a-tv_usec b-tv_usec) ? 1:
(a-tv_usec b-tv_usec) ? -1:
0;
}
static void add_timeval(const struct timeval *a, const struct timeval *b, struct timeval *c)
{
c-tv_usec = a-tv_usec + b-tv_usec;
c-tv_sec = a-tv_sec +
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote: Here's the bug I get: FYI For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a Grub option), and the system just locked up hard. I just was curious if this was from a different change. But at least in the latest it shows output, and not just a hard lockup. Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. -- Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote: What the test program does, is spawn 5 processes, each with a different priority. Starting with 10 and going to 14. All are SCHED_FIFO. Each of these processes just do a scan of all directories starting with the root directory '/' and going down. I usually run this with a directory NFS mounted too, but I don't think this was a problem. My knowledge of the kernel is still pretty limited, but it looks to me like something corrupted the timer list. Have you tried kdb? Last time I checked it worked great with PREEMPT_RT. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Sat, 2005-04-02 at 15:06 -0500, Steven Rostedt wrote: On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote: Here's the bug I get: FYI For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a Grub option), and the system just locked up hard. I just was curious if this was from a different change. But at least in the latest it shows output, and not just a hard lockup. I had the same results yesterday, while punishing the swap by building the kernel with make -j64 over NFS. It thrashed wildly for 20 minutes or so then eventually all disk activity stopped. Of course that stupid cow continued bouncing up and down... It wasn't clear from your last mail whether you were using NFS. If so I would be suspicious given the NFS changes in the new RT patches. I'll try to reproduce the problem on a local fs. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Steven Rostedt [EMAIL PROTECTED] wrote: On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote: Here's the bug I get: FYI For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a Grub option), and the system just locked up hard. I just was curious if this was from a different change. But at least in the latest it shows output, and not just a hard lockup. Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. ok, so it's not the recent NFS changes. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Lee Revell [EMAIL PROTECTED] wrote: It wasn't clear from your last mail whether you were using NFS. If so I would be suspicious given the NFS changes in the new RT patches. I'll try to reproduce the problem on a local fs. also, try to undo the fs/nfs/*.c and include/linux/*nfs*.h changes, those are latency breakers, so not strictly necessary. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote: * Steven Rostedt [EMAIL PROTECTED] wrote: On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote: Here's the bug I get: FYI For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a Grub option), and the system just locked up hard. I just was curious if this was from a different change. But at least in the latest it shows output, and not just a hard lockup. Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. ok, so it's not the recent NFS changes. I may need to take this back. I forgot to open the serial, so it wasn't accepting input. So it would just appear dead. And the console was fighting against the RT tasks, so it too would seem to be dead. I've reran the test on the latest, but this time I didn't have the NFS mounted, and it's still running. -- Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Sat, 2005-04-02 at 15:44 -0500, Steven Rostedt wrote: On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote: FYI For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a Grub option), and the system just locked up hard. I just was curious if this was from a different change. But at least in the latest it shows output, and not just a hard lockup. Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. ok, so it's not the recent NFS changes. I may need to take this back. I forgot to open the serial, so it wasn't accepting input. So it would just appear dead. And the console was fighting against the RT tasks, so it too would seem to be dead. I've reran the test on the latest, but this time I didn't have the NFS mounted, and it's still running. I tried the 2.6.12-rc1-RT-V0.7.43-06 kernel again, and I still have the serial, to do sysrq. The console is using X which locks (even all the ctrl-alt-X functions) and the ssh session that I run the test stops after the processes try to grab the locks. It doesn't reply to ping. But the sysrq from the serial shows constantly: stest3_rt: 2269 [cf304690, 89] (not blocked) stest3_rt: 2270 [cf304050, 88] (not blocked) stest3_rt: 2271 [cef86cb0, 87] (not blocked) stest3_rt: 2272 [cef86670, 86] (not blocked) Rtest3_rt: 2273 [cf28a050, 85] (not blocked) So it seems that it's in a deadlock somewhere. Since the 43-06 gets much further, this seems to be another problem. I'm not going to look at this problem anymore, since it doesn't show up in the lastest. I'll run a few more tests to see if I can narrow things down on 43-06. -- Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Saturday 02 April 2005 15:34, Ingo Molnar wrote:
* Lee Revell [EMAIL PROTECTED] wrote:
It wasn't clear from your last mail whether you were using NFS.
If so I would be suspicious given the NFS changes in the new RT
patches. I'll try to reproduce the problem on a local fs.
also, try to undo the fs/nfs/*.c and include/linux/*nfs*.h changes,
those are latency breakers, so not strictly necessary.
Ingo
Hi Ingo;
I just got done rebooting to 43-06, had problems with my heyu
startup scripts again, but I finally found a missing in one
of them, and I can have it recycle itself from the cli like it
used to again.
So far, with *all* the 'logit' switches turned on and in full
preempt mode, there's nothing unusual in the log.
Here goes tvtime from a cli:
Audio only, blue screen video, this in the log:
---
Apr 2 17:12:48 coyote kernel: cx88[0]: video y / packed - dma channel status
dump
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: initial risc: 0x06b46000
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: cdt base: 0x00180440
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: cdt size: 0x000c
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq base : 0x00180400
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq size : 0x0010
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: risc pc : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq wr ptr : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: iq rd ptr : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: cdt current : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: pci target : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: cmds: line / byte : 0x
Apr 2 17:12:48 coyote kernel: cx88[0]: risc0: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: risc1: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: risc2: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: risc3: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 0: 0x80008000 [ sync resync
count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 1: 0x1c000500 [ write sol eol
count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 2: 0x06922000 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 3: 0x1c000500 [ write sol eol
count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 4: 0x06922a00 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 5: 0x1c000500 [ write sol eol
count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 6: 0x2dc68400 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 7: 0x18000200 [ write sol
count=512 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 8: 0x2dc68e00 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq 9: 0x14000300 [ write eol
count=768 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq a: 0x2dc69000 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq b: 0x1c000500 [ write sol eol
count=1280 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq c: 0x2dc69800 [ arg #1 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq d: 0x0031c040 [ INVALID 21 20 cnt0
resync 14 count=64 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq e: 0x [ INVALID count=0 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: iq f: 0x0011 [ INVALID count=17 ]
Apr 2 17:12:48 coyote kernel: cx88[0]: fifo: 0x00180c00 - 0x183400
Apr 2 17:12:48 coyote kernel: cx88[0]: ctrl: 0x00180400 - 0x180460
Apr 2 17:12:48 coyote kernel: cx88[0]: ptr1_reg: 0x00182118
Apr 2 17:12:48 coyote kernel: cx88[0]: ptr2_reg: 0x00180488
Apr 2 17:12:48 coyote kernel: cx88[0]: cnt1_reg: 0x0082
Apr 2 17:12:48 coyote kernel: cx88[0]: cnt2_reg: 0x
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d4da5940/0] timeout - dma=0x
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d4da5d40/1] timeout - dma=0x
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d417d960/2] timeout - dma=0x
Apr 2 17:12:48 coyote kernel: cx88[0]/0: [d4da5540/3] timeout - dma=0x06b46000
Apr 2 17:12:49 coyote kernel: cx88[0]: video y / packed - dma channel status
dump
[...]
followed by many repeats of the above as I let it run about
5-6 seconds. On exit, this:
Apr 2 17:12:57 coyote kernel: rtc latency histogram of {tvtime/5717, 232
samples}:
Apr 2 17:12:57 coyote kernel: 20 4
Apr 2 17:12:57 coyote kernel: 21 81
Apr 2 17:12:57 coyote kernel: 22 64
Apr 2 17:12:57 coyote kernel: 23 32
Apr 2 17:12:57 coyote kernel: 24 13
Apr 2 17:12:57 coyote kernel: 25 2
Apr 2 17:12:57 coyote kernel: 26 8
Apr 2 17:12:57 coyote kernel: 27 2
Apr 2 17:12:57 coyote kernel: 28 3
Apr 2 17:12:57 coyote kernel: 29 1
Apr 2 17:12:57 coyote kernel: 30 1
Apr 2 17:12:57 coyote kernel: 32 2
Apr 2 17:12:57 coyote kernel: 33 2
Apr 2 17:12:57 coyote kernel: 34 1
Apr 2 17:12:57 coyote kernel: 35 1
Apr 2 17:12:57 coyote kernel: 37 1
Apr 2 17:12:57 coyote kernel: 14
dma timeouts. I don't get these, and I do get good video under
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote: For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a Grub option), and the system just locked up hard. I just was curious if this was from a different change. But at least in the latest it shows output, and not just a hard lockup. Oh, the bug report was running kernel 2.6.12-rc1-RT-V0.7.43-06. ok, so it's not the recent NFS changes. Here's an interesting trace I got today. It looks either the emu10k1 or USB irq handler left IRQ 10 disabled. This isn't a tracer bug because you can clearly see this leads to an xrun. Since I've been hacking the emu10k1 driver quite a bit, I suspect this is the problem. This trace also shows that my trigger callback for the emu10k1 multichannel device needs optimizing; it takes 300 usecs to stop all 16 voices, not acceptable for an ALSA irq handler which uses SA_INTERRUPT. I think I can improve this significantly by reordering the register settings and eliminating some function call overhead. Lee latency_trace.bz2 Description: application/bzip
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Gene Heskett <[EMAIL PROTECTED]> wrote:
> Apr 1 18:05:20 coyote ieee1394.agent[6016]: ... no drivers for IEEE1394
> product 0x/0x/0x
> Apr 1 18:05:24 coyote kernel:
> Apr 1 18:05:24 coyote kernel: ==
> Apr 1 18:05:24 coyote kernel: [ BUG: lock recursion deadlock detected! |
> Apr 1 18:05:24 coyote kernel: --
> Apr 1 18:05:24 coyote kernel: already locked: [e4d17228] {(struct semaphore
> *)(>complete_sem)}
> Apr 1 18:05:24 coyote kernel: .. held by: kino: 6082 [e13ecbb0,
> 118]
> Apr 1 18:05:24 coyote kernel: ... acquired at: raw1394_read+0x104/0x110
> [raw1394]
hm - does the patch below help? (or -43-06 which has the same patch)
Ingo
--- linux/drivers/ieee1394/raw1394-private.h.orig
+++ linux/drivers/ieee1394/raw1394-private.h
@@ -29,7 +29,7 @@ struct file_info {
struct list_head req_pending;
struct list_head req_complete;
-struct semaphore complete_sem;
+struct compat_semaphore complete_sem;
spinlock_t reqlists_lock;
wait_queue_head_t poll_wait_complete;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Friday 01 April 2005 20:45, Lee Revell wrote: >On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote: >> No one has commented about the loss of video in the >> tvtime/pcHDTV-3000 card situation, am I on my own, basicly >> reverting to the >> pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff? > >You didn't really give much of a clue as to where to start looking. > >If you report a bug of the "hardware foo stopped working with kernel >bar" type, and that's all the information you provide, the bug > report is useless to anyone who does not have the exact same > hardware. > >Lee I did, in a previous incarnation of this thread 2-3 days ago, post the lsmod output and a section of the log showing (I believe) rampant dma failures. It also didn't generate any comments. FWIW, I have reinstalled the tarballs version of the drivers, but that was of no use, so its definitely something in the RT patch itself I believe. 2.6.12-rc1 works great. By default. As far as my being able to fix that, I'm afraid I'll have to plead NDI. The last time I dealt with dma, was on an rca 1802 cpu, which had its own builtin dma controller that took care of everything but the pointer reload for the next 6 byte fetch, and which I used for 6 bytes per field of video to feed a homebrewed character generator I made out of ttl chips, to generate the academy leader on a commercial. The year was 1978. A bit far back up the log for even me, altho I may still have a copy of the machine code I wrote that ran it at KRCR-TV in Redding CA for a decade that I know of, maybe longer. That is neither here nor there now of course, just shining a light back up the calendar about 27 years for illustration. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote: > No one has commented about the loss of video in the tvtime/pcHDTV-3000 > card situation, am I on my own, basicly reverting to the > pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff? You didn't really give much of a clue as to where to start looking. If you report a bug of the "hardware foo stopped working with kernel bar" type, and that's all the information you provide, the bug report is useless to anyone who does not have the exact same hardware. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Friday 01 April 2005 14:22, K.R. Foley wrote:
>Gene Heskett wrote:
>> On Friday 01 April 2005 13:27, K.R. Foley wrote:
>>>Gene Heskett wrote:
>>>
>>>
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts
output: ---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file lib/rwsem-spinlock.c
Hunk #5 FAILED at 133.
Hunk #6 FAILED at 160.
Hunk #7 FAILED at 179.
Hunk #8 FAILED at 194.
Hunk #9 FAILED at 204.
Hunk #10 FAILED at 231.
Hunk #11 FAILED at 250.
Hunk #12 FAILED at 265.
Hunk #13 FAILED at 274.
Hunk #14 FAILED at 293.
Hunk #15 FAILED at 314.
11 out of 15 hunks FAILED -- saving rejects to file
lib/rwsem-spinlock.c.rej
---
I doubt it would run, so I haven't built it. Should I?
>>>
>>>Adding the attached patch on top of the above should resolve the
>>>failures, at least in the patching. Still working on building it.
>>
>> I assume you mean apply before the 43-04 patch?
>
>No actually I meant to apply it after the 43-04 patch. However, Ingo
> has a new patch that should cover this also.
>
>> I'll give it a go later today, right now I've got dirt to move in
>> the yard.
3 hrs later, rained out, or in as the case may be. 43-05 is building
now, with lots of traceing turned on to see what sorts of grins I
might get out of it.
No one has commented about the loss of video in the tvtime/pcHDTV-3000
card situation, am I on my own, basicly reverting to the
pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff?
--
2 friggin hours later, I'm finally rebooted. I start heyu in my
rc.local file by launching a series of scripts to set that all up,
and my cm-11a interface decided, for the first time in a couple
of years, to not talk to the 'heyu setclock' command. Boot hung,
but not of course until I'd used up half the boots per fsck on
100GB of disks. Grwwff.
Anyway, now lets see what works.
tvtime doesn't, even if I re-install the drivers from the pcHDTV-2.0
archive. No video, just a blue screen, sound so-so.
kino works
xsane works
spcagui works
But, I did get some odd stuff in the logs while doing this as I had
a lot of traceing stuff turned on over and above the defaults:
Warning, this IS lengthy
---
Apr 1 18:05:13 coyote gconfd (root-5947): starting (version 2.6.0), pid 5947
user 'root'
Apr 1 18:05:13 coyote gconfd (root-5947): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only config source at
position 0
Apr 1 18:05:13 coyote gconfd (root-5947): Resolved address
"xml:readwrite:/root/.gconf" to a writable config source at position 1
Apr 1 18:05:13 coyote gconfd (root-5947): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only config source at
position 2
Apr 1 18:05:19 coyote ieee1394.agent[6002]: ... no drivers for IEEE1394
product 0x/0x/0x
Apr 1 18:05:20 coyote kernel: ieee1394: raw1394: /dev/raw1394 device
initialized
Apr 1 18:05:20 coyote ieee1394.agent[6016]: ... no drivers for IEEE1394
product 0x/0x/0x
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: ==
Apr 1 18:05:24 coyote kernel: [ BUG: lock recursion deadlock detected! |
Apr 1 18:05:24 coyote kernel: --
Apr 1 18:05:24 coyote kernel: already locked: [e4d17228] {(struct semaphore
*)(>complete_sem)}
Apr 1 18:05:24 coyote kernel: .. held by: kino: 6082 [e13ecbb0,
118]
Apr 1 18:05:24 coyote kernel: ... acquired at: raw1394_read+0x104/0x110
[raw1394]
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: --
Apr 1 18:05:24 coyote kernel: | showing all locks held by: | (kino/6082
[e13ecbb0, 118]):
Apr 1 18:05:24 coyote kernel: --
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: #001: [e4d17228] {(struct semaphore
*)(>complete_sem)}
Apr 1 18:05:24 coyote kernel: ... acquired at: raw1394_read+0x104/0x110
[raw1394]
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: -{current task's backtrace}->
Apr 1 18:05:24 coyote kernel: [] dump_stack+0x23/0x30 (20)
Apr 1 18:05:24 coyote kernel: [] check_deadlock+0x2fe/0x320 (44)
Apr 1 18:05:24 coyote kernel: [] task_blocks_on_lock+0x37/0xf0 (36)
Apr 1 18:05:24 coyote kernel: [] __down_interruptible+0x257/0x4f0
(88)
Apr 1 18:05:24 coyote kernel: [] rt_down_interruptible+0xba/0x1f0
(48)
Apr 1 18:05:24 coyote kernel: [] raw1394_read+0x104/0x110 [raw1394]
(32)
Apr 1 18:05:24 coyote kernel: [] vfs_read+0xcd/0x140 (36)
Apr 1 18:05:24 coyote kernel: [] sys_read+0x50/0x80 (44)
Apr 1 18:05:24 coyote kernel: [] sysenter_past_esp+0x61/0x89 (-4028)
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: showing all tasks:
Apr 1 18:05:24 coyote kernel: Sinit:1
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
> >> >> needs unknown symbol __compat_down_failed_interruptible >> >> Nope. Same error output as last report. > > does -43-04 work for you? > RT-V0.7.43-05 is now working for me. No quirks so far, on the UP laptop. Building now for the SMP/HT desktop. Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
Gene Heskett wrote: On Friday 01 April 2005 13:27, K.R. Foley wrote: Gene Heskett wrote: It was up to 43-04 by the time I got there. This one didn't go in cleanly Ingo. From my build-src scripts output: --- Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04 [...] patching file lib/rwsem-spinlock.c Hunk #5 FAILED at 133. Hunk #6 FAILED at 160. Hunk #7 FAILED at 179. Hunk #8 FAILED at 194. Hunk #9 FAILED at 204. Hunk #10 FAILED at 231. Hunk #11 FAILED at 250. Hunk #12 FAILED at 265. Hunk #13 FAILED at 274. Hunk #14 FAILED at 293. Hunk #15 FAILED at 314. 11 out of 15 hunks FAILED -- saving rejects to file lib/rwsem-spinlock.c.rej --- I doubt it would run, so I haven't built it. Should I? Adding the attached patch on top of the above should resolve the failures, at least in the patching. Still working on building it. I assume you mean apply before the 43-04 patch? No actually I meant to apply it after the 43-04 patch. However, Ingo has a new patch that should cover this also. I'll give it a go later today, right now I've got dirt to move in the yard. -- kr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Friday 01 April 2005 13:29, Ingo Molnar wrote: >* K.R. Foley <[EMAIL PROTECTED]> wrote: >> >This one didn't go in cleanly Ingo. From my build-src scripts >> > output: --- >> >Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04 >> >> Adding the attached patch on top of the above should resolve the >> failures, at least in the patching. Still working on building it. > >i fixed these things up in -43-05 ... i hope :-| > > Ingo Ok, I'll try that later today too. Got dirt to move in the yard, decent weather for a change & the old farts gotta get his exersize :-) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Friday 01 April 2005 13:27, K.R. Foley wrote: >Gene Heskett wrote: > > >> It was up to 43-04 by the time I got there. >> >> This one didn't go in cleanly Ingo. From my build-src scripts >> output: --- >> Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04 >> [...] >> patching file lib/rwsem-spinlock.c >> Hunk #5 FAILED at 133. >> Hunk #6 FAILED at 160. >> Hunk #7 FAILED at 179. >> Hunk #8 FAILED at 194. >> Hunk #9 FAILED at 204. >> Hunk #10 FAILED at 231. >> Hunk #11 FAILED at 250. >> Hunk #12 FAILED at 265. >> Hunk #13 FAILED at 274. >> Hunk #14 FAILED at 293. >> Hunk #15 FAILED at 314. >> 11 out of 15 hunks FAILED -- saving rejects to file >> lib/rwsem-spinlock.c.rej >> --- >> I doubt it would run, so I haven't built it. Should I? > >Adding the attached patch on top of the above should resolve the >failures, at least in the patching. Still working on building it. I assume you mean apply before the 43-04 patch? I'll give it a go later today, right now I've got dirt to move in the yard. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
Gene Heskett wrote:
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts output:
---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file lib/rwsem-spinlock.c
Hunk #5 FAILED at 133.
Hunk #6 FAILED at 160.
Hunk #7 FAILED at 179.
Hunk #8 FAILED at 194.
Hunk #9 FAILED at 204.
Hunk #10 FAILED at 231.
Hunk #11 FAILED at 250.
Hunk #12 FAILED at 265.
Hunk #13 FAILED at 274.
Hunk #14 FAILED at 293.
Hunk #15 FAILED at 314.
11 out of 15 hunks FAILED -- saving rejects to file
lib/rwsem-spinlock.c.rej
---
I doubt it would run, so I haven't built it. Should I?
Adding the attached patch on top of the above should resolve the
failures, at least in the patching. Still working on building it.
--
kr
--- linux-2.6.12/lib/rwsem-spinlock.c.orig 2005-04-01 12:00:21.0 -0600
+++ linux-2.6.12/lib/rwsem-spinlock.c 2005-04-01 12:19:06.0 -0600
@@ -18,7 +18,7 @@ struct rwsem_waiter {
};
#if RWSEM_DEBUG
-void rwsemtrace(struct rw_semaphore *sem, const char *str)
+void rwsemtrace(struct compat_rw_semaphore *sem, const char *str)
{
if (sem->debug)
printk("[%d] %s({%d,%d})\n",
@@ -30,7 +30,7 @@ void rwsemtrace(struct rw_semaphore *sem
/*
* initialise the semaphore
*/
-void fastcall init_rwsem(struct rw_semaphore *sem)
+void fastcall compat_init_rwsem(struct compat_rw_semaphore *sem)
{
sem->activity = 0;
spin_lock_init(>wait_lock);
@@ -49,8 +49,8 @@ void fastcall init_rwsem(struct rw_semap
* - woken process blocks are discarded from the list after having task zeroed
* - writers are only woken if wakewrite is non-zero
*/
-static inline struct rw_semaphore *
-__rwsem_do_wake(struct rw_semaphore *sem, int wakewrite)
+static inline struct compat_rw_semaphore *
+__rwsem_do_wake(struct compat_rw_semaphore *sem, int wakewrite)
{
struct rwsem_waiter *waiter;
struct task_struct *tsk;
@@ -111,8 +111,8 @@ __rwsem_do_wake(struct rw_semaphore *sem
/*
* wake a single writer
*/
-static inline struct rw_semaphore *
-__rwsem_wake_one_writer(struct rw_semaphore *sem)
+static inline struct compat_rw_semaphore *
+__rwsem_wake_one_writer(struct compat_rw_semaphore *sem)
{
struct rwsem_waiter *waiter;
struct task_struct *tsk;
@@ -133,7 +133,8 @@ __rwsem_wake_one_writer(struct rw_semaph
/*
* get a read lock on the semaphore
*/
-void fastcall __sched __down_read(struct rw_semaphore *sem)
+void fastcall __sched __down_read(struct compat_rw_semaphore *sem)
+
{
struct rwsem_waiter waiter;
struct task_struct *tsk;
@@ -179,7 +180,8 @@ void fastcall __sched __down_read(struct
/*
* trylock for reading -- returns 1 if successful, 0 if contention
*/
-int fastcall __down_read_trylock(struct rw_semaphore *sem)
+int fastcall __down_read_trylock(struct compat_rw_semaphore *sem)
+
{
unsigned long flags;
int ret = 0;
@@ -204,7 +206,8 @@ int fastcall __down_read_trylock(struct
* get a write lock on the semaphore
* - we increment the waiting count anyway to indicate an exclusive lock
*/
-void fastcall __sched __down_write(struct rw_semaphore *sem)
+void fastcall __sched __down_write(struct compat_rw_semaphore *sem)
+
{
struct rwsem_waiter waiter;
struct task_struct *tsk;
@@ -250,7 +253,8 @@ void fastcall __sched __down_write(struc
/*
* trylock for writing -- returns 1 if successful, 0 if contention
*/
-int fastcall __down_write_trylock(struct rw_semaphore *sem)
+int fastcall __down_write_trylock(struct compat_rw_semaphore *sem)
+
{
unsigned long flags;
int ret = 0;
@@ -274,7 +278,8 @@ int fastcall __down_write_trylock(struct
/*
* release a read lock on the semaphore
*/
-void fastcall __up_read(struct rw_semaphore *sem)
+void fastcall __up_read(struct compat_rw_semaphore *sem)
+
{
unsigned long flags;
@@ -293,7 +298,7 @@ void fastcall __up_read(struct rw_semaph
/*
* release a write lock on the semaphore
*/
-void fastcall __up_write(struct rw_semaphore *sem)
+void fastcall __up_write(struct compat_rw_semaphore *sem)
{
unsigned long flags;
@@ -314,7 +319,7 @@ void fastcall __up_write(struct rw_semap
* downgrade a write lock into a read lock
* - just wake up any readers at the front of the queue
*/
-void fastcall __downgrade_write(struct rw_semaphore *sem)
+void fastcall __downgrade_write(struct compat_rw_semaphore *sem)
{
unsigned long flags;
@@ -331,7 +336,7 @@ void fastcall __downgrade_write(struct r
rwsemtrace(sem, "Leaving __downgrade_write");
}
-EXPORT_SYMBOL(init_rwsem);
+EXPORT_SYMBOL(compat_init_rwsem);
EXPORT_SYMBOL(__down_read);
EXPORT_SYMBOL(__down_read_trylock);
EXPORT_SYMBOL(__down_write);
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* K.R. Foley <[EMAIL PROTECTED]> wrote: > >This one didn't go in cleanly Ingo. From my build-src scripts output: > >--- > >Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04 > Adding the attached patch on top of the above should resolve the > failures, at least in the patching. Still working on building it. i fixed these things up in -43-05 ... i hope :-| Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Friday 01 April 2005 05:47, Ingo Molnar wrote: >i have released the -V0.7.43-00 Real-Time Preemption patch, which > can be downloaded from the usual place: > > http://redhat.com/~mingo/realtime-preempt/ > >this release too is a step towards more robustness. I found a bug > that caused an infinite recursion and subsequent spontaneous > reboot. The bug was once again related to lock->debug locks, so i > decided to get rid of them altogether: from now on every lock in > the -RT domain is debugged. > >To be able to use code that relies on incompatible properties of > stock Linux semaphores (and rwsems), i've added a new compile-time > semaphore-type mechanism that enables the easy switching from RT > semaphores to stock semaphores. I've done this conversion for all > subsystems that needed it - e.g. XFS, firewire, USB and SCSI. XFS > seems to be working much better with this approach - BYMMV. > >but an unavoidable side-effect is that the whole codebase got turned >upside down once again, so be careful and expect a few rough edges. > In particular keep an eye on new compile-time warnings related to > semaphores - code that gives a warning might build but it will > almost certainly not work. > >to create a -V0.7.43-00 tree from scratch, the patching order is: > > http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2 I use the .gz, more reliable unpacks > http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc1.bz >2 Again I use the .gz > http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-r >c1-V0.7.43-00 > > Ingo It was up to 43-04 by the time I got there. This one didn't go in cleanly Ingo. From my build-src scripts output: --- Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04 [...] patching file lib/rwsem-spinlock.c Hunk #5 FAILED at 133. Hunk #6 FAILED at 160. Hunk #7 FAILED at 179. Hunk #8 FAILED at 194. Hunk #9 FAILED at 204. Hunk #10 FAILED at 231. Hunk #11 FAILED at 250. Hunk #12 FAILED at 265. Hunk #13 FAILED at 274. Hunk #14 FAILED at 293. Hunk #15 FAILED at 314. 11 out of 15 hunks FAILED -- saving rejects to file lib/rwsem-spinlock.c.rej --- I doubt it would run, so I haven't built it. Should I? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote: > >> needs unknown symbol __compat_down_failed_interruptible > > Nope. Same error output as last report. does -43-04 work for you? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
> * Rui Nuno Capela wrote: > >> > thx - i've uploaded -43-01 which should fix this. >> > >> >> Now it's dying-on-the-beach: > >> needs unknown symbol __compat_down_failed_interruptible > > ok - does -43-02 work any better? > Nope. Same error output as last report. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote: > > thx - i've uploaded -43-01 which should fix this. > > > > Now it's dying-on-the-beach: > needs unknown symbol __compat_down_failed_interruptible ok - does -43-02 work any better? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
> > thx - i've uploaded -43-01 which should fix this. > Now it's dying-on-the-beach: . . . if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 2.6.12-rc1-RT-V0.7.43-01.0; fi WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/usb/storage/usb-storage.ko needs unknown symbol __compat_down_failed_interruptible WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/usb/storage/usb-storage.ko needs unknown symbol __compat_up_wakeup WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/parport/parport.ko needs unknown symbol __compat_down_failed_interruptible WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/parport/parport.ko needs unknown symbol __compat_up_wakeup WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/net/ppp_async.ko needs unknown symbol __compat_up_wakeup WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/net/ppp_async.ko needs unknown symbol __compat_down_failed WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol __compat_down_failed_trylock WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol __compat_down_failed_interruptible WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol __compat_up_wakeup WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol __compat_down_failed make: *** [_modinst_post] Error 1 Bye. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote: > > i have released the -V0.7.43-00 Real-Time Preemption patch, which can be > > downloaded from the usual place: > > > > RT-V0.7.43-00 is failing to build here: > kernel/rt.c:1435: error: `up_read' undeclared here (not in a function) > kernel/rt.c:1435: error: initializer element is not constant > kernel/rt.c:1435: error: (near initialization for `__ksymtab_up_read.value') > kernel/rt.c:1435: error: __ksymtab_up_read causes a section type conflict > make[1]: *** [kernel/rt.o] Error 1 thx - i've uploaded -43-01 which should fix this. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
> > i have released the -V0.7.43-00 Real-Time Preemption patch, which can be > downloaded from the usual place: > RT-V0.7.43-00 is failing to build here: . . . CC kernel/rcupdate.o CC kernel/intermodule.o kernel/intermodule.c:179: warning: `inter_module_register' is deprecated (declar ed at kernel/intermodule.c:38) kernel/intermodule.c:180: warning: `inter_module_unregister' is deprecated (decl ared at kernel/intermodule.c:79) kernel/intermodule.c:182: warning: `inter_module_put' is deprecated (declared at kernel/intermodule.c:160) CC kernel/extable.o CC kernel/params.o CC kernel/posix-timers.o CC kernel/kthread.o CC kernel/wait.o CC kernel/kfifo.o CC kernel/sys_ni.o CC kernel/posix-cpu-timers.o CC kernel/rt.o kernel/rt.c:1435: error: `up_read' undeclared here (not in a function) kernel/rt.c:1435: error: initializer element is not constant kernel/rt.c:1435: error: (near initialization for `__ksymtab_up_read.value') kernel/rt.c:1435: error: __ksymtab_up_read causes a section type conflict make[1]: *** [kernel/rt.o] Error 1 make: *** [kernel] Error 2 Bye. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
i have released the -V0.7.43-00 Real-Time Preemption patch, which can be downloaded from the usual place: RT-V0.7.43-00 is failing to build here: . . . CC kernel/rcupdate.o CC kernel/intermodule.o kernel/intermodule.c:179: warning: `inter_module_register' is deprecated (declar ed at kernel/intermodule.c:38) kernel/intermodule.c:180: warning: `inter_module_unregister' is deprecated (decl ared at kernel/intermodule.c:79) kernel/intermodule.c:182: warning: `inter_module_put' is deprecated (declared at kernel/intermodule.c:160) CC kernel/extable.o CC kernel/params.o CC kernel/posix-timers.o CC kernel/kthread.o CC kernel/wait.o CC kernel/kfifo.o CC kernel/sys_ni.o CC kernel/posix-cpu-timers.o CC kernel/rt.o kernel/rt.c:1435: error: `up_read' undeclared here (not in a function) kernel/rt.c:1435: error: initializer element is not constant kernel/rt.c:1435: error: (near initialization for `__ksymtab_up_read.value') kernel/rt.c:1435: error: __ksymtab_up_read causes a section type conflict make[1]: *** [kernel/rt.o] Error 1 make: *** [kernel] Error 2 Bye. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Rui Nuno Capela [EMAIL PROTECTED] wrote: i have released the -V0.7.43-00 Real-Time Preemption patch, which can be downloaded from the usual place: RT-V0.7.43-00 is failing to build here: kernel/rt.c:1435: error: `up_read' undeclared here (not in a function) kernel/rt.c:1435: error: initializer element is not constant kernel/rt.c:1435: error: (near initialization for `__ksymtab_up_read.value') kernel/rt.c:1435: error: __ksymtab_up_read causes a section type conflict make[1]: *** [kernel/rt.o] Error 1 thx - i've uploaded -43-01 which should fix this. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
thx - i've uploaded -43-01 which should fix this. Now it's dying-on-the-beach: . . . if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 2.6.12-rc1-RT-V0.7.43-01.0; fi WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/usb/storage/usb-storage.ko needs unknown symbol __compat_down_failed_interruptible WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/usb/storage/usb-storage.ko needs unknown symbol __compat_up_wakeup WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/parport/parport.ko needs unknown symbol __compat_down_failed_interruptible WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/parport/parport.ko needs unknown symbol __compat_up_wakeup WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/net/ppp_async.ko needs unknown symbol __compat_up_wakeup WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/net/ppp_async.ko needs unknown symbol __compat_down_failed WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol __compat_down_failed_trylock WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol __compat_down_failed_interruptible WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol __compat_up_wakeup WARNING: /lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/ieee1394/ieee1394.ko needs unknown symbol __compat_down_failed make: *** [_modinst_post] Error 1 Bye. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Rui Nuno Capela [EMAIL PROTECTED] wrote: thx - i've uploaded -43-01 which should fix this. Now it's dying-on-the-beach: needs unknown symbol __compat_down_failed_interruptible ok - does -43-02 work any better? Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Rui Nuno Capela wrote: thx - i've uploaded -43-01 which should fix this. Now it's dying-on-the-beach: needs unknown symbol __compat_down_failed_interruptible ok - does -43-02 work any better? Nope. Same error output as last report. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Rui Nuno Capela [EMAIL PROTECTED] wrote: needs unknown symbol __compat_down_failed_interruptible Nope. Same error output as last report. does -43-04 work for you? Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Friday 01 April 2005 05:47, Ingo Molnar wrote: i have released the -V0.7.43-00 Real-Time Preemption patch, which can be downloaded from the usual place: http://redhat.com/~mingo/realtime-preempt/ this release too is a step towards more robustness. I found a bug that caused an infinite recursion and subsequent spontaneous reboot. The bug was once again related to lock-debug locks, so i decided to get rid of them altogether: from now on every lock in the -RT domain is debugged. To be able to use code that relies on incompatible properties of stock Linux semaphores (and rwsems), i've added a new compile-time semaphore-type mechanism that enables the easy switching from RT semaphores to stock semaphores. I've done this conversion for all subsystems that needed it - e.g. XFS, firewire, USB and SCSI. XFS seems to be working much better with this approach - BYMMV. but an unavoidable side-effect is that the whole codebase got turned upside down once again, so be careful and expect a few rough edges. In particular keep an eye on new compile-time warnings related to semaphores - code that gives a warning might build but it will almost certainly not work. to create a -V0.7.43-00 tree from scratch, the patching order is: http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2 I use the .gz, more reliable unpacks http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc1.bz 2 Again I use the .gz http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-r c1-V0.7.43-00 Ingo It was up to 43-04 by the time I got there. This one didn't go in cleanly Ingo. From my build-src scripts output: --- Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04 [...] patching file lib/rwsem-spinlock.c Hunk #5 FAILED at 133. Hunk #6 FAILED at 160. Hunk #7 FAILED at 179. Hunk #8 FAILED at 194. Hunk #9 FAILED at 204. Hunk #10 FAILED at 231. Hunk #11 FAILED at 250. Hunk #12 FAILED at 265. Hunk #13 FAILED at 274. Hunk #14 FAILED at 293. Hunk #15 FAILED at 314. 11 out of 15 hunks FAILED -- saving rejects to file lib/rwsem-spinlock.c.rej --- I doubt it would run, so I haven't built it. Should I? -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* K.R. Foley [EMAIL PROTECTED] wrote: This one didn't go in cleanly Ingo. From my build-src scripts output: --- Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04 Adding the attached patch on top of the above should resolve the failures, at least in the patching. Still working on building it. i fixed these things up in -43-05 ... i hope :-| Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
Gene Heskett wrote:
snip
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts output:
---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file lib/rwsem-spinlock.c
Hunk #5 FAILED at 133.
Hunk #6 FAILED at 160.
Hunk #7 FAILED at 179.
Hunk #8 FAILED at 194.
Hunk #9 FAILED at 204.
Hunk #10 FAILED at 231.
Hunk #11 FAILED at 250.
Hunk #12 FAILED at 265.
Hunk #13 FAILED at 274.
Hunk #14 FAILED at 293.
Hunk #15 FAILED at 314.
11 out of 15 hunks FAILED -- saving rejects to file
lib/rwsem-spinlock.c.rej
---
I doubt it would run, so I haven't built it. Should I?
Adding the attached patch on top of the above should resolve the
failures, at least in the patching. Still working on building it.
--
kr
--- linux-2.6.12/lib/rwsem-spinlock.c.orig 2005-04-01 12:00:21.0 -0600
+++ linux-2.6.12/lib/rwsem-spinlock.c 2005-04-01 12:19:06.0 -0600
@@ -18,7 +18,7 @@ struct rwsem_waiter {
};
#if RWSEM_DEBUG
-void rwsemtrace(struct rw_semaphore *sem, const char *str)
+void rwsemtrace(struct compat_rw_semaphore *sem, const char *str)
{
if (sem-debug)
printk([%d] %s({%d,%d})\n,
@@ -30,7 +30,7 @@ void rwsemtrace(struct rw_semaphore *sem
/*
* initialise the semaphore
*/
-void fastcall init_rwsem(struct rw_semaphore *sem)
+void fastcall compat_init_rwsem(struct compat_rw_semaphore *sem)
{
sem-activity = 0;
spin_lock_init(sem-wait_lock);
@@ -49,8 +49,8 @@ void fastcall init_rwsem(struct rw_semap
* - woken process blocks are discarded from the list after having task zeroed
* - writers are only woken if wakewrite is non-zero
*/
-static inline struct rw_semaphore *
-__rwsem_do_wake(struct rw_semaphore *sem, int wakewrite)
+static inline struct compat_rw_semaphore *
+__rwsem_do_wake(struct compat_rw_semaphore *sem, int wakewrite)
{
struct rwsem_waiter *waiter;
struct task_struct *tsk;
@@ -111,8 +111,8 @@ __rwsem_do_wake(struct rw_semaphore *sem
/*
* wake a single writer
*/
-static inline struct rw_semaphore *
-__rwsem_wake_one_writer(struct rw_semaphore *sem)
+static inline struct compat_rw_semaphore *
+__rwsem_wake_one_writer(struct compat_rw_semaphore *sem)
{
struct rwsem_waiter *waiter;
struct task_struct *tsk;
@@ -133,7 +133,8 @@ __rwsem_wake_one_writer(struct rw_semaph
/*
* get a read lock on the semaphore
*/
-void fastcall __sched __down_read(struct rw_semaphore *sem)
+void fastcall __sched __down_read(struct compat_rw_semaphore *sem)
+
{
struct rwsem_waiter waiter;
struct task_struct *tsk;
@@ -179,7 +180,8 @@ void fastcall __sched __down_read(struct
/*
* trylock for reading -- returns 1 if successful, 0 if contention
*/
-int fastcall __down_read_trylock(struct rw_semaphore *sem)
+int fastcall __down_read_trylock(struct compat_rw_semaphore *sem)
+
{
unsigned long flags;
int ret = 0;
@@ -204,7 +206,8 @@ int fastcall __down_read_trylock(struct
* get a write lock on the semaphore
* - we increment the waiting count anyway to indicate an exclusive lock
*/
-void fastcall __sched __down_write(struct rw_semaphore *sem)
+void fastcall __sched __down_write(struct compat_rw_semaphore *sem)
+
{
struct rwsem_waiter waiter;
struct task_struct *tsk;
@@ -250,7 +253,8 @@ void fastcall __sched __down_write(struc
/*
* trylock for writing -- returns 1 if successful, 0 if contention
*/
-int fastcall __down_write_trylock(struct rw_semaphore *sem)
+int fastcall __down_write_trylock(struct compat_rw_semaphore *sem)
+
{
unsigned long flags;
int ret = 0;
@@ -274,7 +278,8 @@ int fastcall __down_write_trylock(struct
/*
* release a read lock on the semaphore
*/
-void fastcall __up_read(struct rw_semaphore *sem)
+void fastcall __up_read(struct compat_rw_semaphore *sem)
+
{
unsigned long flags;
@@ -293,7 +298,7 @@ void fastcall __up_read(struct rw_semaph
/*
* release a write lock on the semaphore
*/
-void fastcall __up_write(struct rw_semaphore *sem)
+void fastcall __up_write(struct compat_rw_semaphore *sem)
{
unsigned long flags;
@@ -314,7 +319,7 @@ void fastcall __up_write(struct rw_semap
* downgrade a write lock into a read lock
* - just wake up any readers at the front of the queue
*/
-void fastcall __downgrade_write(struct rw_semaphore *sem)
+void fastcall __downgrade_write(struct compat_rw_semaphore *sem)
{
unsigned long flags;
@@ -331,7 +336,7 @@ void fastcall __downgrade_write(struct r
rwsemtrace(sem, Leaving __downgrade_write);
}
-EXPORT_SYMBOL(init_rwsem);
+EXPORT_SYMBOL(compat_init_rwsem);
EXPORT_SYMBOL(__down_read);
EXPORT_SYMBOL(__down_read_trylock);
EXPORT_SYMBOL(__down_write);
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Friday 01 April 2005 13:27, K.R. Foley wrote: Gene Heskett wrote: snip It was up to 43-04 by the time I got there. This one didn't go in cleanly Ingo. From my build-src scripts output: --- Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04 [...] patching file lib/rwsem-spinlock.c Hunk #5 FAILED at 133. Hunk #6 FAILED at 160. Hunk #7 FAILED at 179. Hunk #8 FAILED at 194. Hunk #9 FAILED at 204. Hunk #10 FAILED at 231. Hunk #11 FAILED at 250. Hunk #12 FAILED at 265. Hunk #13 FAILED at 274. Hunk #14 FAILED at 293. Hunk #15 FAILED at 314. 11 out of 15 hunks FAILED -- saving rejects to file lib/rwsem-spinlock.c.rej --- I doubt it would run, so I haven't built it. Should I? Adding the attached patch on top of the above should resolve the failures, at least in the patching. Still working on building it. I assume you mean apply before the 43-04 patch? I'll give it a go later today, right now I've got dirt to move in the yard. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Friday 01 April 2005 13:29, Ingo Molnar wrote: * K.R. Foley [EMAIL PROTECTED] wrote: This one didn't go in cleanly Ingo. From my build-src scripts output: --- Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04 Adding the attached patch on top of the above should resolve the failures, at least in the patching. Still working on building it. i fixed these things up in -43-05 ... i hope :-| Ingo Ok, I'll try that later today too. Got dirt to move in the yard, decent weather for a change the old farts gotta get his exersize :-) -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
Gene Heskett wrote: On Friday 01 April 2005 13:27, K.R. Foley wrote: Gene Heskett wrote: snip It was up to 43-04 by the time I got there. This one didn't go in cleanly Ingo. From my build-src scripts output: --- Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04 [...] patching file lib/rwsem-spinlock.c Hunk #5 FAILED at 133. Hunk #6 FAILED at 160. Hunk #7 FAILED at 179. Hunk #8 FAILED at 194. Hunk #9 FAILED at 204. Hunk #10 FAILED at 231. Hunk #11 FAILED at 250. Hunk #12 FAILED at 265. Hunk #13 FAILED at 274. Hunk #14 FAILED at 293. Hunk #15 FAILED at 314. 11 out of 15 hunks FAILED -- saving rejects to file lib/rwsem-spinlock.c.rej --- I doubt it would run, so I haven't built it. Should I? Adding the attached patch on top of the above should resolve the failures, at least in the patching. Still working on building it. I assume you mean apply before the 43-04 patch? No actually I meant to apply it after the 43-04 patch. However, Ingo has a new patch that should cover this also. I'll give it a go later today, right now I've got dirt to move in the yard. -- kr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
needs unknown symbol __compat_down_failed_interruptible Nope. Same error output as last report. does -43-04 work for you? RT-V0.7.43-05 is now working for me. No quirks so far, on the UP laptop. Building now for the SMP/HT desktop. Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Friday 01 April 2005 14:22, K.R. Foley wrote:
Gene Heskett wrote:
On Friday 01 April 2005 13:27, K.R. Foley wrote:
Gene Heskett wrote:
snip
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts
output: ---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file lib/rwsem-spinlock.c
Hunk #5 FAILED at 133.
Hunk #6 FAILED at 160.
Hunk #7 FAILED at 179.
Hunk #8 FAILED at 194.
Hunk #9 FAILED at 204.
Hunk #10 FAILED at 231.
Hunk #11 FAILED at 250.
Hunk #12 FAILED at 265.
Hunk #13 FAILED at 274.
Hunk #14 FAILED at 293.
Hunk #15 FAILED at 314.
11 out of 15 hunks FAILED -- saving rejects to file
lib/rwsem-spinlock.c.rej
---
I doubt it would run, so I haven't built it. Should I?
Adding the attached patch on top of the above should resolve the
failures, at least in the patching. Still working on building it.
I assume you mean apply before the 43-04 patch?
No actually I meant to apply it after the 43-04 patch. However, Ingo
has a new patch that should cover this also.
I'll give it a go later today, right now I've got dirt to move in
the yard.
3 hrs later, rained out, or in as the case may be. 43-05 is building
now, with lots of traceing turned on to see what sorts of grins I
might get out of it.
No one has commented about the loss of video in the tvtime/pcHDTV-3000
card situation, am I on my own, basicly reverting to the
pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff?
--
2 friggin hours later, I'm finally rebooted. I start heyu in my
rc.local file by launching a series of scripts to set that all up,
and my cm-11a interface decided, for the first time in a couple
of years, to not talk to the 'heyu setclock' command. Boot hung,
but not of course until I'd used up half the boots per fsck on
100GB of disks. Grwwff.
Anyway, now lets see what works.
tvtime doesn't, even if I re-install the drivers from the pcHDTV-2.0
archive. No video, just a blue screen, sound so-so.
kino works
xsane works
spcagui works
But, I did get some odd stuff in the logs while doing this as I had
a lot of traceing stuff turned on over and above the defaults:
Warning, this IS lengthy
---
Apr 1 18:05:13 coyote gconfd (root-5947): starting (version 2.6.0), pid 5947
user 'root'
Apr 1 18:05:13 coyote gconfd (root-5947): Resolved address
xml:readonly:/etc/gconf/gconf.xml.mandatory to a read-only config source at
position 0
Apr 1 18:05:13 coyote gconfd (root-5947): Resolved address
xml:readwrite:/root/.gconf to a writable config source at position 1
Apr 1 18:05:13 coyote gconfd (root-5947): Resolved address
xml:readonly:/etc/gconf/gconf.xml.defaults to a read-only config source at
position 2
Apr 1 18:05:19 coyote ieee1394.agent[6002]: ... no drivers for IEEE1394
product 0x/0x/0x
Apr 1 18:05:20 coyote kernel: ieee1394: raw1394: /dev/raw1394 device
initialized
Apr 1 18:05:20 coyote ieee1394.agent[6016]: ... no drivers for IEEE1394
product 0x/0x/0x
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: ==
Apr 1 18:05:24 coyote kernel: [ BUG: lock recursion deadlock detected! |
Apr 1 18:05:24 coyote kernel: --
Apr 1 18:05:24 coyote kernel: already locked: [e4d17228] {(struct semaphore
*)(fi-complete_sem)}
Apr 1 18:05:24 coyote kernel: .. held by: kino: 6082 [e13ecbb0,
118]
Apr 1 18:05:24 coyote kernel: ... acquired at: raw1394_read+0x104/0x110
[raw1394]
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: --
Apr 1 18:05:24 coyote kernel: | showing all locks held by: | (kino/6082
[e13ecbb0, 118]):
Apr 1 18:05:24 coyote kernel: --
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: #001: [e4d17228] {(struct semaphore
*)(fi-complete_sem)}
Apr 1 18:05:24 coyote kernel: ... acquired at: raw1394_read+0x104/0x110
[raw1394]
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: -{current task's backtrace}-
Apr 1 18:05:24 coyote kernel: [c0103353] dump_stack+0x23/0x30 (20)
Apr 1 18:05:24 coyote kernel: [c013093e] check_deadlock+0x2fe/0x320 (44)
Apr 1 18:05:24 coyote kernel: [c01313b7] task_blocks_on_lock+0x37/0xf0 (36)
Apr 1 18:05:24 coyote kernel: [c0374987] __down_interruptible+0x257/0x4f0
(88)
Apr 1 18:05:24 coyote kernel: [c0132cba] rt_down_interruptible+0xba/0x1f0
(48)
Apr 1 18:05:24 coyote kernel: [f8c9d8f4] raw1394_read+0x104/0x110 [raw1394]
(32)
Apr 1 18:05:24 coyote kernel: [c015d45d] vfs_read+0xcd/0x140 (36)
Apr 1 18:05:24 coyote kernel: [c015d750] sys_read+0x50/0x80 (44)
Apr 1 18:05:24 coyote kernel: [c0102cf8] sysenter_past_esp+0x61/0x89 (-4028)
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: showing all tasks:
Apr 1 18:05:24 coyote kernel: Sinit:1 [c190d670, 116] (not
blocked)
Apr 1 18:05:24
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote: No one has commented about the loss of video in the tvtime/pcHDTV-3000 card situation, am I on my own, basicly reverting to the pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff? You didn't really give much of a clue as to where to start looking. If you report a bug of the hardware foo stopped working with kernel bar type, and that's all the information you provide, the bug report is useless to anyone who does not have the exact same hardware. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
On Friday 01 April 2005 20:45, Lee Revell wrote: On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote: No one has commented about the loss of video in the tvtime/pcHDTV-3000 card situation, am I on my own, basicly reverting to the pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff? You didn't really give much of a clue as to where to start looking. If you report a bug of the hardware foo stopped working with kernel bar type, and that's all the information you provide, the bug report is useless to anyone who does not have the exact same hardware. Lee I did, in a previous incarnation of this thread 2-3 days ago, post the lsmod output and a section of the log showing (I believe) rampant dma failures. It also didn't generate any comments. FWIW, I have reinstalled the tarballs version of the drivers, but that was of no use, so its definitely something in the RT patch itself I believe. 2.6.12-rc1 works great. By default. As far as my being able to fix that, I'm afraid I'll have to plead NDI. The last time I dealt with dma, was on an rca 1802 cpu, which had its own builtin dma controller that took care of everything but the pointer reload for the next 6 byte fetch, and which I used for 6 bytes per field of video to feed a homebrewed character generator I made out of ttl chips, to generate the academy leader on a commercial. The year was 1978. A bit far back up the log for even me, altho I may still have a copy of the machine code I wrote that ran it at KRCR-TV in Redding CA for a decade that I know of, maybe longer. That is neither here nor there now of course, just shining a light back up the calendar about 27 years for illustration. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.43-00
* Gene Heskett [EMAIL PROTECTED] wrote:
Apr 1 18:05:20 coyote ieee1394.agent[6016]: ... no drivers for IEEE1394
product 0x/0x/0x
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: ==
Apr 1 18:05:24 coyote kernel: [ BUG: lock recursion deadlock detected! |
Apr 1 18:05:24 coyote kernel: --
Apr 1 18:05:24 coyote kernel: already locked: [e4d17228] {(struct semaphore
*)(fi-complete_sem)}
Apr 1 18:05:24 coyote kernel: .. held by: kino: 6082 [e13ecbb0,
118]
Apr 1 18:05:24 coyote kernel: ... acquired at: raw1394_read+0x104/0x110
[raw1394]
hm - does the patch below help? (or -43-06 which has the same patch)
Ingo
--- linux/drivers/ieee1394/raw1394-private.h.orig
+++ linux/drivers/ieee1394/raw1394-private.h
@@ -29,7 +29,7 @@ struct file_info {
struct list_head req_pending;
struct list_head req_complete;
-struct semaphore complete_sem;
+struct compat_semaphore complete_sem;
spinlock_t reqlists_lock;
wait_queue_head_t poll_wait_complete;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
