On Sun, Feb 18, 2001 at 10:53:16PM +, Russell King wrote:
> Kenn Humborg writes:
> > When starting bdflush and kupdated, bdflush_init() uses a semaphore to
> > make sure that the threads have run before continuing. Shouldn't
> > start_context_thread() do something similar?
>
> I think this
On Sun, Feb 18, 2001 at 10:53:16PM +, Russell King wrote:
Kenn Humborg writes:
When starting bdflush and kupdated, bdflush_init() uses a semaphore to
make sure that the threads have run before continuing. Shouldn't
start_context_thread() do something similar?
I think this would be
On Mon, 19 Feb 2001, Philipp Rumpf wrote:
> No. If kswapd oopses it's a bug in kswapd (or related code). If keventd
> oopses most likely the broken code is actually the task queue you
> scheduled, which belongs to your driver.
If we're going to detect this case, we might as well just restart
On Mon, 19 Feb 2001, Russell King wrote:
> Philipp Rumpf writes:
> > That still won't catch keventd oopsing though - which I think might happen
> > quite easily in real life.
>
> Maybe we should panic in that case? For example, what happens if kswapd
> oopses? kreclaimd? bdflush? kupdate?
Philipp Rumpf writes:
> That still won't catch keventd oopsing though - which I think might happen
> quite easily in real life.
Maybe we should panic in that case? For example, what happens if kswapd
oopses? kreclaimd? bdflush? kupdate? All these have the same problem,
and should probably
On Mon, 19 Feb 2001, Andrew Morton wrote:
> David Woodhouse wrote:
> > [EMAIL PROTECTED] said:
> > > Why bother ? It looks like a leftover debugging message which
> > > doesn't make a lot of sense once the code is stable (what might make
> > > sense is checking keventd is still around, but
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > Why bother ? It looks like a leftover debugging message which
> > doesn't make a lot of sense once the code is stable (what might make
> > sense is checking keventd is still around, but that's not what the
> > code is doing).
keventd
[EMAIL PROTECTED] said:
> Why bother ? It looks like a leftover debugging message which
> doesn't make a lot of sense once the code is stable (what might make
> sense is checking keventd is still around, but that's not what the
> code is doing).
> Proposed patch:
> dwmw2 ?
Don't look at
On Sun, 18 Feb 2001, Kenn Humborg wrote:
> in the .config, I can get schedule_task() to fail with:
>
>schedule_task(): keventd has not started
This shouldn't be a failure case, just a (bogus) printk.
> When starting bdflush and kupdated, bdflush_init() uses a semaphore to
> make sure that
On Sun, 18 Feb 2001, Kenn Humborg wrote:
in the .config, I can get schedule_task() to fail with:
schedule_task(): keventd has not started
This shouldn't be a failure case, just a (bogus) printk.
When starting bdflush and kupdated, bdflush_init() uses a semaphore to
make sure that the
[EMAIL PROTECTED] said:
Why bother ? It looks like a leftover debugging message which
doesn't make a lot of sense once the code is stable (what might make
sense is checking keventd is still around, but that's not what the
code is doing).
Proposed patch:
dwmw2 ?
Don't look at me. I
David Woodhouse wrote:
[EMAIL PROTECTED] said:
Why bother ? It looks like a leftover debugging message which
doesn't make a lot of sense once the code is stable (what might make
sense is checking keventd is still around, but that's not what the
code is doing).
keventd *must* still
On Mon, 19 Feb 2001, Andrew Morton wrote:
David Woodhouse wrote:
[EMAIL PROTECTED] said:
Why bother ? It looks like a leftover debugging message which
doesn't make a lot of sense once the code is stable (what might make
sense is checking keventd is still around, but that's not what
Philipp Rumpf writes:
That still won't catch keventd oopsing though - which I think might happen
quite easily in real life.
Maybe we should panic in that case? For example, what happens if kswapd
oopses? kreclaimd? bdflush? kupdate? All these have the same problem,
and should probably
On Mon, 19 Feb 2001, Russell King wrote:
Philipp Rumpf writes:
That still won't catch keventd oopsing though - which I think might happen
quite easily in real life.
Maybe we should panic in that case? For example, what happens if kswapd
oopses? kreclaimd? bdflush? kupdate? All these
On Mon, 19 Feb 2001, Philipp Rumpf wrote:
No. If kswapd oopses it's a bug in kswapd (or related code). If keventd
oopses most likely the broken code is actually the task queue you
scheduled, which belongs to your driver.
If we're going to detect this case, we might as well just restart
Kenn Humborg writes:
> When starting bdflush and kupdated, bdflush_init() uses a semaphore to
> make sure that the threads have run before continuing. Shouldn't
> start_context_thread() do something similar?
I think this would be a good idea. Here is a patch to try. Please report
back if it
In init/main.c, do_basic_setup() we have:
start_context_thread();
do_initcalls();
start_context_thread() calls kernel_thread() to start the keventd
thread. Then do_initcalls() calls all the init functions and
finishes by calling flush_scheduled_tasks(). This function ends
up
In init/main.c, do_basic_setup() we have:
start_context_thread();
do_initcalls();
start_context_thread() calls kernel_thread() to start the keventd
thread. Then do_initcalls() calls all the init functions and
finishes by calling flush_scheduled_tasks(). This function ends
up
Kenn Humborg writes:
When starting bdflush and kupdated, bdflush_init() uses a semaphore to
make sure that the threads have run before continuing. Shouldn't
start_context_thread() do something similar?
I think this would be a good idea. Here is a patch to try. Please report
back if it
20 matches
Mail list logo
