Sorry for delay,
On 06/07, Mark Hounschell wrote:
>
> >From an earlier thread member:
>
> >> Mark writes:
> >> Again I don't understand why flush_scheduled_work() running on behalf
> >> of a process affinitized to processor-1 requires cooperation from
> >> events/2 (affinitized to processor-2)
>
Sorry for delay,
On 06/07, Mark Hounschell wrote:
From an earlier thread member:
Mark writes:
Again I don't understand why flush_scheduled_work() running on behalf
of a process affinitized to processor-1 requires cooperation from
events/2 (affinitized to processor-2)
when there is
Matt Mackall wrote:
> On Thu, Jun 07, 2007 at 06:18:52AM -0400, Mark Hounschell wrote:
>> Matt Mackall wrote:
>>> On Wed, Jun 06, 2007 at 10:28:28AM -0700, Andrew Morton wrote:
On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell <[EMAIL PROTECTED]>
wrote:
>> As far as a 100% CPU
Matt Mackall wrote:
On Thu, Jun 07, 2007 at 06:18:52AM -0400, Mark Hounschell wrote:
Matt Mackall wrote:
On Wed, Jun 06, 2007 at 10:28:28AM -0700, Andrew Morton wrote:
On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell [EMAIL PROTECTED]
wrote:
As far as a 100% CPU bound task being a valid
On Thu, Jun 07, 2007 at 06:18:52AM -0400, Mark Hounschell wrote:
> Matt Mackall wrote:
> > On Wed, Jun 06, 2007 at 10:28:28AM -0700, Andrew Morton wrote:
> >> On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell <[EMAIL PROTECTED]>
> >> wrote:
> >>
> As far as a 100% CPU bound task being a
Matt Mackall wrote:
> On Wed, Jun 06, 2007 at 10:28:28AM -0700, Andrew Morton wrote:
>> On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell <[EMAIL PROTECTED]> wrote:
>>
As far as a 100% CPU bound task being a valid thing to do, it has been
done for many years on SMP machines. Any kernel
Matt Mackall wrote:
On Wed, Jun 06, 2007 at 10:28:28AM -0700, Andrew Morton wrote:
On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell [EMAIL PROTECTED] wrote:
As far as a 100% CPU bound task being a valid thing to do, it has been
done for many years on SMP machines. Any kernel limitation on
On Thu, Jun 07, 2007 at 06:18:52AM -0400, Mark Hounschell wrote:
Matt Mackall wrote:
On Wed, Jun 06, 2007 at 10:28:28AM -0700, Andrew Morton wrote:
On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell [EMAIL PROTECTED]
wrote:
As far as a 100% CPU bound task being a valid thing to do, it
On Wed, Jun 06, 2007 at 10:28:28AM -0700, Andrew Morton wrote:
> On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell <[EMAIL PROTECTED]> wrote:
>
> > >
> > > As far as a 100% CPU bound task being a valid thing to do, it has been
> > > done for many years on SMP machines. Any kernel limitation on
On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell <[EMAIL PROTECTED]> wrote:
> >
> > As far as a 100% CPU bound task being a valid thing to do, it has been
> > done for many years on SMP machines. Any kernel limitation on this
> > surely must be considered a bug?
> >
>
> Could someone
Mark Hounschell wrote:
> Oleg Nesterov wrote:
>> On 06/02, Mark Hounschell wrote:
>>> Jun 2 16:36:11 harley kernel: ERR!! events/1 flush hang: c201dbc0
>>> c201dbc0 10012 10012
>>> Jun 2 16:36:11 harley kernel: CURR: 7974 7974 vrsx 93 26
>>> Jun 2 16:36:11 harley kernel:
Mark Hounschell wrote:
Oleg Nesterov wrote:
On 06/02, Mark Hounschell wrote:
Jun 2 16:36:11 harley kernel: ERR!! events/1 flush hang: c201dbc0
c201dbc0 10012 10012
Jun 2 16:36:11 harley kernel: CURR: 7974 7974 vrsx 93 26
Jun 2 16:36:11 harley kernel: wq_barrier_func+0x0/0x8
Jun 2
On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell [EMAIL PROTECTED] wrote:
As far as a 100% CPU bound task being a valid thing to do, it has been
done for many years on SMP machines. Any kernel limitation on this
surely must be considered a bug?
Could someone authoritatively
On Wed, Jun 06, 2007 at 10:28:28AM -0700, Andrew Morton wrote:
On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell [EMAIL PROTECTED] wrote:
As far as a 100% CPU bound task being a valid thing to do, it has been
done for many years on SMP machines. Any kernel limitation on this
Oleg Nesterov wrote:
> On 06/02, Mark Hounschell wrote:
>> Jun 2 16:36:11 harley kernel: ERR!! events/1 flush hang: c201dbc0
>> c201dbc0 10012 10012
>> Jun 2 16:36:11 harley kernel: CURR: 7974 7974 vrsx 93 26
>> Jun 2 16:36:11 harley kernel: wq_barrier_func+0x0/0x8
>> Jun 2 16:36:11 harley
Oleg Nesterov wrote:
On 06/02, Mark Hounschell wrote:
Jun 2 16:36:11 harley kernel: ERR!! events/1 flush hang: c201dbc0
c201dbc0 10012 10012
Jun 2 16:36:11 harley kernel: CURR: 7974 7974 vrsx 93 26
Jun 2 16:36:11 harley kernel: wq_barrier_func+0x0/0x8
Jun 2 16:36:11 harley kernel:
On 06/02, Mark Hounschell wrote:
>
> Jun 2 16:36:11 harley kernel: ERR!! events/1 flush hang: c201dbc0
> c201dbc0 10012 10012
> Jun 2 16:36:11 harley kernel: CURR: 7974 7974 vrsx 93 26
> Jun 2 16:36:11 harley kernel: wq_barrier_func+0x0/0x8
> Jun 2 16:36:11 harley kernel:
On 06/02, Mark Hounschell wrote:
Jun 2 16:36:11 harley kernel: ERR!! events/1 flush hang: c201dbc0
c201dbc0 10012 10012
Jun 2 16:36:11 harley kernel: CURR: 7974 7974 vrsx 93 26
Jun 2 16:36:11 harley kernel: wq_barrier_func+0x0/0x8
Jun 2 16:36:11 harley kernel:
Oleg Nesterov wrote:
> On 06/01, Mark Hounschell wrote:
>> Oleg Nesterov wrote:
>>> On 06/01, Mark Hounschell wrote:
Ok the prctl never returned. I just replaced the ioctl with it and added
a printf before and after. I only get the one before. The thread is hung
at this point just
On 06/01, Mark Hounschell wrote:
>
> Oleg Nesterov wrote:
> > On 06/01, Mark Hounschell wrote:
> >>
> >> Ok the prctl never returned. I just replaced the ioctl with it and added
> >> a printf before and after. I only get the one before. The thread is hung
> >> at this point just as if I'd done the
On 06/01, Mark Hounschell wrote:
Oleg Nesterov wrote:
On 06/01, Mark Hounschell wrote:
Ok the prctl never returned. I just replaced the ioctl with it and added
a printf before and after. I only get the one before. The thread is hung
at this point just as if I'd done the ioctl?
Oleg Nesterov wrote:
On 06/01, Mark Hounschell wrote:
Oleg Nesterov wrote:
On 06/01, Mark Hounschell wrote:
Ok the prctl never returned. I just replaced the ioctl with it and added
a printf before and after. I only get the one before. The thread is hung
at this point just as if I'd done the
Oleg Nesterov wrote:
> On 06/01, Mark Hounschell wrote:
>> Oleg Nesterov wrote:
>>> Could you apply the trivial patch below, and change the i/o thread to do
>>>
>>> prctl(1234);// hangs ???
>>> printf(something);
>>>
On 06/01, Mark Hounschell wrote:
>
> Oleg Nesterov wrote:
> >
> > Could you apply the trivial patch below, and change the i/o thread to do
> >
> > prctl(1234);// hangs ???
> > printf(something);
> > ioctl(Q->DevSpec1, FDSETPRM, );
Oleg Nesterov wrote:
> On 06/01, Mark Hounschell wrote:
>> Oleg Nesterov wrote:
>>> Yes, but see above. flush_scheduled_work() needs a cooperation from events/2
>>> which is bound to CPU 2.
>>>
>> Again I don't understand why flush_scheduled_work() running on behalf of a
>> process
>> affinitized
On 06/01, Mark Hounschell wrote:
>
> Oleg Nesterov wrote:
> > Yes, but see above. flush_scheduled_work() needs a cooperation from events/2
> > which is bound to CPU 2.
> >
>
> Again I don't understand why flush_scheduled_work() running on behalf of a
> process
> affinitized to processor-1
Oleg Nesterov wrote:
> I hope Ingo will correct me if I am wrong,
>
> On 05/31, Mark Hounschell wrote:
>> Oleg Nesterov wrote:
>>> So, the main question is: is it possible that one of RT processes/threads
>>> pins itself
>>> to some CPU and eats 100% cpu power?
>>>
>> The main process is pinned
I hope Ingo will correct me if I am wrong,
On 05/31, Mark Hounschell wrote:
>
> Oleg Nesterov wrote:
> >
> > So, the main question is: is it possible that one of RT processes/threads
> > pins itself
> > to some CPU and eats 100% cpu power?
> >
>
> The main process is pinned to a processor(2)
Mark Hounschell wrote:
> Oleg Nesterov wrote:
>> On 05/31, Mark Hounschell wrote:
>>> Oleg Nesterov wrote:
On 05/31, Mark Hounschell wrote:
> Basically the main RT-process (which is a CPU bound process on
> processor-2) signals a
> thread to do some I/O. That RT-thread (running
Mark Hounschell wrote:
Oleg Nesterov wrote:
On 05/31, Mark Hounschell wrote:
Oleg Nesterov wrote:
On 05/31, Mark Hounschell wrote:
Basically the main RT-process (which is a CPU bound process on
processor-2) signals a
thread to do some I/O. That RT-thread (running on the other processor)
I hope Ingo will correct me if I am wrong,
On 05/31, Mark Hounschell wrote:
Oleg Nesterov wrote:
So, the main question is: is it possible that one of RT processes/threads
pins itself
to some CPU and eats 100% cpu power?
The main process is pinned to a processor(2) with all
Oleg Nesterov wrote:
I hope Ingo will correct me if I am wrong,
On 05/31, Mark Hounschell wrote:
Oleg Nesterov wrote:
So, the main question is: is it possible that one of RT processes/threads
pins itself
to some CPU and eats 100% cpu power?
The main process is pinned to a processor(2)
On 06/01, Mark Hounschell wrote:
Oleg Nesterov wrote:
Yes, but see above. flush_scheduled_work() needs a cooperation from events/2
which is bound to CPU 2.
Again I don't understand why flush_scheduled_work() running on behalf of a
process
affinitized to processor-1 requires
Oleg Nesterov wrote:
On 06/01, Mark Hounschell wrote:
Oleg Nesterov wrote:
Yes, but see above. flush_scheduled_work() needs a cooperation from events/2
which is bound to CPU 2.
Again I don't understand why flush_scheduled_work() running on behalf of a
process
affinitized to processor-1
On 06/01, Mark Hounschell wrote:
Oleg Nesterov wrote:
Could you apply the trivial patch below, and change the i/o thread to do
prctl(1234);// hangs ???
printf(something);
ioctl(Q-DevSpec1, FDSETPRM, medprm); // this
Oleg Nesterov wrote:
On 06/01, Mark Hounschell wrote:
Oleg Nesterov wrote:
Could you apply the trivial patch below, and change the i/o thread to do
prctl(1234);// hangs ???
printf(something);
ioctl(Q-DevSpec1, FDSETPRM,
Oleg Nesterov wrote:
> On 05/31, Mark Hounschell wrote:
>> Oleg Nesterov wrote:
>>> On 05/31, Mark Hounschell wrote:
Basically the main RT-process (which is a CPU bound process on
processor-2) signals a
thread to do some I/O. That RT-thread (running on the other processor)
On 05/31, Mark Hounschell wrote:
>
> Oleg Nesterov wrote:
> > On 05/31, Mark Hounschell wrote:
> >>
> >> Basically the main RT-process (which is a CPU bound process on
> >> processor-2) signals a
> >> thread to do some I/O. That RT-thread (running on the other processor)
> >> does a simple
> >
Oleg Nesterov wrote:
> On 05/31, Mark Hounschell wrote:
>> Andrew Morton wrote:
>>> On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell <[EMAIL PROTECTED]>
>>> wrote:
>>>
Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I
have. I have tracked
it down to a
Oleg Nesterov wrote:
> On 05/31, Mark Hounschell wrote:
>> Andrew Morton wrote:
>>> On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell <[EMAIL PROTECTED]>
>>> wrote:
>>>
Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I
have. I have tracked
it down to a
On 05/31, Mark Hounschell wrote:
>
> Andrew Morton wrote:
> > On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I
> >> have. I have tracked
> >> it down to a single line of code. When
Andrew Morton wrote:
> On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell <[EMAIL PROTECTED]> wrote:
>
>> Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I
>> have. I have tracked
>> it down to a single line of code. When the following patch is applied to the
>> version
Andrew Morton wrote:
On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell [EMAIL PROTECTED] wrote:
Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I
have. I have tracked
it down to a single line of code. When the following patch is applied to the
version in 2.6.18
my
On 05/31, Mark Hounschell wrote:
Andrew Morton wrote:
On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell [EMAIL PROTECTED]
wrote:
Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I
have. I have tracked
it down to a single line of code. When the following
Oleg Nesterov wrote:
On 05/31, Mark Hounschell wrote:
Andrew Morton wrote:
On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell [EMAIL PROTECTED]
wrote:
Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I
have. I have tracked
it down to a single line of code. When the
Oleg Nesterov wrote:
On 05/31, Mark Hounschell wrote:
Andrew Morton wrote:
On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell [EMAIL PROTECTED]
wrote:
Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I
have. I have tracked
it down to a single line of code. When the
On 05/31, Mark Hounschell wrote:
Oleg Nesterov wrote:
On 05/31, Mark Hounschell wrote:
Basically the main RT-process (which is a CPU bound process on
processor-2) signals a
thread to do some I/O. That RT-thread (running on the other processor)
does a simple
If the main
Oleg Nesterov wrote:
On 05/31, Mark Hounschell wrote:
Oleg Nesterov wrote:
On 05/31, Mark Hounschell wrote:
Basically the main RT-process (which is a CPU bound process on
processor-2) signals a
thread to do some I/O. That RT-thread (running on the other processor)
does a simple
If the
On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell <[EMAIL PROTECTED]> wrote:
> Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I have.
> I have tracked
> it down to a single line of code. When the following patch is applied to the
> version in 2.6.18
> my application
On Tue, 29 May 2007 13:31:05 -0400 Mark Hounschell [EMAIL PROTECTED] wrote:
Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I have.
I have tracked
it down to a single line of code. When the following patch is applied to the
version in 2.6.18
my application works.
Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I have. I
have tracked
it down to a single line of code. When the following patch is applied to the
version in 2.6.18
my application works.
--- linux-2.6.18/drivers/block/floppy.c 2006-09-19 23:42:06.0 -0400
+++
Changes in floppy.c from 2.6.17 and 2.6.18 have broken an application I have. I
have tracked
it down to a single line of code. When the following patch is applied to the
version in 2.6.18
my application works.
--- linux-2.6.18/drivers/block/floppy.c 2006-09-19 23:42:06.0 -0400
+++
52 matches
Mail list logo
