> If a tty driver has marked itself low-latency, it's still wrong to do the
> flush_to_ldisc() from interrupt context if a console event happens in
> interrupt context.
It should be ok nowdays. Calling ld->receive() paths directly from an IRQ
is verboted however.
> I thought that was the whole
James Simmons wrote:
Done. I still smell a dead lock issue tho.
Yes, but it is an existing problem that was kicked
about with no real resolution.
No one can blame you for that! :-)
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe
On Wed, 18 Jul 2007, Paul Fulghum wrote:
>
> It might be safest to drop this portion so you can get the
> obvious part of the patch accepted (consolidating
> the redundant xxx_schedule_flip functions).
But wasn't the whole _point_ that con_schedule_flip() potentially gets
called from
> While I have no problem with this, it would be a significant
> behavior change (more so than changing the initial delay to 0).
>
> IIRC, when the serial_core dead lock was being debugged
> (by Russel King with some Dell guy who reported it 1-2 years ago)
> this change was suggested and
On Wed, 2007-07-18 at 19:17 +0100, James Simmons wrote:
> I have no problem leaving at one. Here is the new patch. I did address the
> problem with tty_flip_buffer_push in this patch. It is possible for a
> driver to call tty_flip_buffer_push within a interrupt context if they
> set the
> > What should be done is
> >
> > if (tty->low_latency)
> > flush_to_ldisc(>buf.work.work);
> > else
> > schedule_delayed_work(>buf.work, 1);
> >
> > Is this acceptable to you?
>
> In that case, we might as well just always do the
> James Simmons wrote:
> > The low_latency is used by the drivers in the case where its not in a
> > interrupt context. Well we are trusting the drivers.
> > Now if it is true what you said then tty_flip_buffer_push has
> > a bug. Looking at several drivers including serial devices
> > they set
James Simmons wrote:
The low_latency is used by the drivers in the case where its not in a
interrupt context. Well we are trusting the drivers.
Now if it is true what you said then tty_flip_buffer_push has
a bug. Looking at several drivers including serial devices
they set the
What should be done is
if (tty-low_latency)
flush_to_ldisc(tty-buf.work.work);
else
schedule_delayed_work(tty-buf.work, 1);
Is this acceptable to you?
In that case, we might as well just always do the scheduled_delayed_work()
On Wed, 2007-07-18 at 19:17 +0100, James Simmons wrote:
I have no problem leaving at one. Here is the new patch. I did address the
problem with tty_flip_buffer_push in this patch. It is possible for a
driver to call tty_flip_buffer_push within a interrupt context if they
set the low_latency
While I have no problem with this, it would be a significant
behavior change (more so than changing the initial delay to 0).
IIRC, when the serial_core dead lock was being debugged
(by Russel King with some Dell guy who reported it 1-2 years ago)
this change was suggested and rejected
On Wed, 18 Jul 2007, Paul Fulghum wrote:
It might be safest to drop this portion so you can get the
obvious part of the patch accepted (consolidating
the redundant xxx_schedule_flip functions).
But wasn't the whole _point_ that con_schedule_flip() potentially gets
called from interrupt
James Simmons wrote:
Done. I still smell a dead lock issue tho.
Yes, but it is an existing problem that was kicked
about with no real resolution.
No one can blame you for that! :-)
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
If a tty driver has marked itself low-latency, it's still wrong to do the
flush_to_ldisc() from interrupt context if a console event happens in
interrupt context.
It should be ok nowdays. Calling ld-receive() paths directly from an IRQ
is verboted however.
I thought that was the whole
O> In that case, we might as well just always do the scheduled_delayed_work()
> with a zero timeout as per the earlier patch. I'd still like to know who
> *cares*, though? Why not leave it at 1?
I don't think it really matters too much on modern systems so long as we
keep the flush_to_ldisc out
On Tue, 17 Jul 2007, James Simmons wrote:
>
> Because sometimes you do want the delay. In other parts of the tty
> code we do delay.
Ahh, ok, in that it's ok by me.
> What should be done is
>
> if (tty->low_latency)
> flush_to_ldisc(>buf.work.work);
> else
>
James Simmons wrote:
James Simmons, le Tue 17 Jul 2007 19:37:57 +0100, a écrit :
- schedule_delayed_work(>buf.work, 0);
It was schedule_delayed_work(>buf.work, 1); in con_schedule_flip() ;
could that matter?
I did not detect any regressions.
The console behavior stays exactly the
James Simmons wrote:
The low_latency is used by the drivers in the case where its
not in a interrupt context. Well we are trusting the drivers.
Now if it is true what you said then tty_flip_buffer_push has
a bug. Looking at several drivers including serial devices
they set the low_latency flag.
Linus Torvalds wrote:
- schedule_delayed_work(>buf.work, 1);
+ schedule_delayed_work(>buf.work, 0);
Is there any real reason for this?
I think that patch is bogus. Either it should stay at 1, or the whole work
should be a non-scheduled one instead.
Do we really need to handle
> James Simmons wrote:
> > Because sometimes you do want the delay. In other parts of the tty code we
> > do delay. What should be done is
>
> Correct, so we must stick with the delayed work structure
> which requires calling the delayed work function.
>
> > if (tty->low_latency)
> >
James Simmons wrote:
Because sometimes you do want the delay. In other parts of the tty
code we do delay. What should be done is
Correct, so we must stick with the delayed work structure
which requires calling the delayed work function.
if (tty->low_latency)
> On Tue, 17 Jul 2007, Paul Fulghum wrote:
> >
> > The scheduling is to move the processing out of interrupt context.
> > The receive data is often extracted from the hardware
> > at interrupt time and then queued for processing.
>
> You misunderstand.
>
> If the "delay" is zero, then why are
On Tue, 17 Jul 2007, Paul Fulghum wrote:
>
> The scheduling is to move the processing out of interrupt context.
> The receive data is often extracted from the hardware
> at interrupt time and then queued for processing.
You misunderstand.
If the "delay" is zero, then why are you using
[ Alan added to participants list, since he's in charge of tty code ]
On Tue, 17 Jul 2007, James Simmons wrote:
> diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
> index de37ebc..34894e5 100644
> --- a/drivers/char/tty_io.c
> +++ b/drivers/char/tty_io.c
> @@ -559,7 +559,7 @@ void
> James Simmons, le Tue 17 Jul 2007 19:37:57 +0100, a écrit :
> > - schedule_delayed_work(>buf.work, 0);
>
> It was schedule_delayed_work(>buf.work, 1); in con_schedule_flip() ;
> could that matter?
I did not detect any regressions.
James Simmons, le Tue 17 Jul 2007 19:37:57 +0100, a écrit :
> - schedule_delayed_work(>buf.work, 0);
It was schedule_delayed_work(>buf.work, 1); in con_schedule_flip() ;
could that matter?
Samuel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
This patch has the VT subsystem use tty_schedule_flip instead of
con_schedule_flip. The patch has been tested for several weeks
on my local system and has been in the linuxconsole repository
for some time. Please apply.
Signed-Off: James Simmons <[EMAIL PROTECTED]>
diff --git
This patch has the VT subsystem use tty_schedule_flip instead of
con_schedule_flip. The patch has been tested for several weeks
on my local system and has been in the linuxconsole repository
for some time. Please apply.
Signed-Off: James Simmons [EMAIL PROTECTED]
diff --git
James Simmons, le Tue 17 Jul 2007 19:37:57 +0100, a écrit :
- schedule_delayed_work(t-buf.work, 0);
It was schedule_delayed_work(t-buf.work, 1); in con_schedule_flip() ;
could that matter?
Samuel
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
James Simmons, le Tue 17 Jul 2007 19:37:57 +0100, a écrit :
- schedule_delayed_work(t-buf.work, 0);
It was schedule_delayed_work(t-buf.work, 1); in con_schedule_flip() ;
could that matter?
I did not detect any regressions.
[ Alan added to participants list, since he's in charge of tty code ]
On Tue, 17 Jul 2007, James Simmons wrote:
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index de37ebc..34894e5 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -559,7 +559,7 @@ void
On Tue, 17 Jul 2007, Paul Fulghum wrote:
The scheduling is to move the processing out of interrupt context.
The receive data is often extracted from the hardware
at interrupt time and then queued for processing.
You misunderstand.
If the delay is zero, then why are you using
On Tue, 17 Jul 2007, Paul Fulghum wrote:
The scheduling is to move the processing out of interrupt context.
The receive data is often extracted from the hardware
at interrupt time and then queued for processing.
You misunderstand.
If the delay is zero, then why are you using delayed
James Simmons wrote:
Because sometimes you do want the delay. In other parts of the tty
code we do delay. What should be done is
Correct, so we must stick with the delayed work structure
which requires calling the delayed work function.
if (tty-low_latency)
James Simmons wrote:
Because sometimes you do want the delay. In other parts of the tty code we
do delay. What should be done is
Correct, so we must stick with the delayed work structure
which requires calling the delayed work function.
if (tty-low_latency)
James Simmons wrote:
The low_latency is used by the drivers in the case where its
not in a interrupt context. Well we are trusting the drivers.
Now if it is true what you said then tty_flip_buffer_push has
a bug. Looking at several drivers including serial devices
they set the low_latency flag.
Linus Torvalds wrote:
- schedule_delayed_work(tty-buf.work, 1);
+ schedule_delayed_work(tty-buf.work, 0);
Is there any real reason for this?
I think that patch is bogus. Either it should stay at 1, or the whole work
should be a non-scheduled one instead.
Do we really need to
James Simmons wrote:
James Simmons, le Tue 17 Jul 2007 19:37:57 +0100, a écrit :
- schedule_delayed_work(t-buf.work, 0);
It was schedule_delayed_work(t-buf.work, 1); in con_schedule_flip() ;
could that matter?
I did not detect any regressions.
The console behavior stays exactly the
On Tue, 17 Jul 2007, James Simmons wrote:
Because sometimes you do want the delay. In other parts of the tty
code we do delay.
Ahh, ok, in that it's ok by me.
What should be done is
if (tty-low_latency)
flush_to_ldisc(tty-buf.work.work);
else
O In that case, we might as well just always do the scheduled_delayed_work()
with a zero timeout as per the earlier patch. I'd still like to know who
*cares*, though? Why not leave it at 1?
I don't think it really matters too much on modern systems so long as we
keep the flush_to_ldisc out of
James Simmons wrote:
Great Here is the patch updated with the delay value set to zero.
Acked-by: Paul Fulghum <[EMAIL PROTECTED]>
You should submit this to
Andrew Morton <[EMAIL PROTECTED]>
so it can get into the mm tree.
--
Paul
-
To unsubscribe from this list: send the line
> Paul Fulghum wrote:
> > As the tty flip buffer code has evolved, that delay value of 1
> > was carried along. It may have had some historical purpose, but
> > I can't figure it out and it appears to have no use currently.
>
> I looked further back and in the 2.4 kernels this scheduling
> was
Paul Fulghum wrote:
As the tty flip buffer code has evolved, that delay value of 1
was carried along. It may have had some historical purpose, but
I can't figure it out and it appears to have no use currently.
I looked further back and in the 2.4 kernels this scheduling
was done with the timer
Paul Fulghum wrote:
As the tty flip buffer code has evolved, that delay value of 1
was carried along. It may have had some historical purpose, but
I can't figure it out and it appears to have no use currently.
I looked further back and in the 2.4 kernels this scheduling
was done with the timer
Paul Fulghum wrote:
As the tty flip buffer code has evolved, that delay value of 1
was carried along. It may have had some historical purpose, but
I can't figure it out and it appears to have no use currently.
I looked further back and in the 2.4 kernels this scheduling
was done with
James Simmons wrote:
Great Here is the patch updated with the delay value set to zero.
Acked-by: Paul Fulghum [EMAIL PROTECTED]
You should submit this to
Andrew Morton [EMAIL PROTECTED]
so it can get into the mm tree.
--
Paul
-
To unsubscribe from this list: send the line unsubscribe
On Tue, 2007-05-08 at 21:10 +0100, James Simmons wrote:
>
> This patch has the VT subsystem use tty_schedule_flip instead of
> con_schedule_flip. There are two ways we can approach this. We can
> do the below path or extend tty_schedule_flip to accept a time field.
> Comments welcomed.
This
This patch has the VT subsystem use tty_schedule_flip instead of
con_schedule_flip. There are two ways we can approach this. We can
do the below path or extend tty_schedule_flip to accept a time field.
Comments welcomed.
Signed-Off: James Simmons <[EMAIL PROTECTED]>
diff --git
This patch has the VT subsystem use tty_schedule_flip instead of
con_schedule_flip. There are two ways we can approach this. We can
do the below path or extend tty_schedule_flip to accept a time field.
Comments welcomed.
Signed-Off: James Simmons [EMAIL PROTECTED]
diff --git
On Tue, 2007-05-08 at 21:10 +0100, James Simmons wrote:
This patch has the VT subsystem use tty_schedule_flip instead of
con_schedule_flip. There are two ways we can approach this. We can
do the below path or extend tty_schedule_flip to accept a time field.
Comments welcomed.
This looks
50 matches
Mail list logo
