> 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 linux-kernel
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
> 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 rejecte
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_late
> > 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 sche
> 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 th
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(&tty->buf.work.work);
> el
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 th
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:
> > 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)
flush_to_
> 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 y
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
[ 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 tty_s
> 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.
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 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 "unsubscrib
> 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 do
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
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 look
23 matches
Mail list logo
