* RE: [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UPkernel
@ 2005-01-10 20:36 Tim_T_Murphy
0 siblings, 0 replies; 6+ messages in thread
From: Tim_T_Murphy @ 2005-01-10 20:36 UTC (permalink / raw)
To: alan; +Cc: rmk+lkml, linux-kernel, paulkf
Thanks for your comments and advice, I am new to
the kernel and appreciate your taking the time.
> Presumably this is a device with a fake 8250 that
> produces sudden large bursts of data ? If so then
> for now you -need- to set low_latency and should
> probably do it by the PCI vendor subid/device id.
> The problem is that the serial layer expects serial
> data arriving at serial speeds. It completely breaks
> down when it hits an emulation of a generic uart that
> suddenely receives 32Kbytes of data at ethernet speed.
Yes. Thanks, this confirms what I suspected.
> The longer term fix for this is when the flip buffers
> go away, and the same problem gets cleaned up for
> things like mainframes and some high performance DMA
> devices.
Is this, or a short-term fix, expected anytime soon?
Problem for me is that my application no longer works
with the 2.6 kernels, since it relies on the kernel's
serial support -- which worked fine with 2.4 kernels.
If there's anything I can do to expedite a fix please
let me know -- I've spent the past few days learning
and working with the code, but I obviously have a
ways to go before I sleep..
Tim
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UP kernel
@ 2004-10-31 0:26 Paul Fulghum
2004-11-01 7:14 ` [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UPkernel Stuart MacDonald
0 siblings, 1 reply; 6+ messages in thread
From: Paul Fulghum @ 2004-10-31 0:26 UTC (permalink / raw)
To: Alan Cox; +Cc: Russell King, Tim_T_Murphy, Linux Kernel Mailing List
On Sat, 2004-10-30 at 17:43, Alan Cox wrote:
> On Sad, 2004-10-30 at 00:40, Paul Fulghum wrote:
> > Would it make sense to do something like (in tty_io.c) the following?
>
> Not really because it can legally occur if you flip the low latency
> flag while a transaction is queued. It might work if you waited for
> scheduled work to complete in the flag changing.
I don't see how having flush_to_ldisc() queued
or already running (on another processor) negates
the prohibition on calling tty_flip_buffer_push()
with low_latency set in interrupt context.
The comments for tty_flip_buffer_push() state the
function should not be called in interrupt context
if low_latency is set (no exceptions are listed).
Meaning flush_to_ldisc() should only be called
in process context.
If flush_to_ldisc() is queued or already executing,
there is no protection against calling
flush_to_ldisc() again, directly in interrupt context.
TTY_DONT_FLIP is no protection, that is only set
in read_chan() of n_tty.c
If I'm missing something, please point it out.
--
Paul Fulghum
paulkf@microgate.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UPkernel
2004-10-31 0:26 [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UP kernel Paul Fulghum
@ 2004-11-01 7:14 ` Stuart MacDonald
2004-11-01 14:10 ` Paul Fulghum
0 siblings, 1 reply; 6+ messages in thread
From: Stuart MacDonald @ 2004-11-01 7:14 UTC (permalink / raw)
To: 'Paul Fulghum', 'Alan Cox'
Cc: 'Russell King',
Tim_T_Murphy, 'Linux Kernel Mailing List'
From: Paul Fulghum
> I don't see how having flush_to_ldisc() queued
> or already running (on another processor) negates
> the prohibition on calling tty_flip_buffer_push()
> with low_latency set in interrupt context.
I always thought the whole point of low_latency was to make the
receive-path very fast, which means specifically allowing the flip
routine to run from the ISR. So checking for calling from the ISR and
specifically disallowing that is basically negating the entire raison
d'etre for low_latency.
Having said that, the interrupt context "taint" that is allowed by the
low_latency flag has been a thorn in our side for some time. It would
be nice if that path was cleaned up to run properly from interrupt or
process context.
..Stu
www.connecttech.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UPkernel
2004-11-01 7:14 ` [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UPkernel Stuart MacDonald
@ 2004-11-01 14:10 ` Paul Fulghum
2004-11-01 15:12 ` Stuart MacDonald
2004-11-01 23:02 ` Alan Cox
0 siblings, 2 replies; 6+ messages in thread
From: Paul Fulghum @ 2004-11-01 14:10 UTC (permalink / raw)
To: Stuart MacDonald
Cc: 'Alan Cox', 'Russell King',
'Linux Kernel Mailing List'
Stuart MacDonald wrote:
> From: Paul Fulghum
> I always thought the whole point of low_latency was to make the
> receive-path very fast, which means specifically allowing the flip
> routine to run from the ISR. So checking for calling from the ISR and
> specifically disallowing that is basically negating the entire raison
> d'etre for low_latency.
I was thought it was to speed processing if the
caller was already in process context. Maybe the
real intentions are lost to history.
Moving forward, Alan stated that the flip
routine should not be called in interrupt context.
His last post concerning some transient state
of low_latency has confused me.
Currently, with the 8250 driver and N_TTY
line discipline, calling the flip routine from
ISR causes an SMP deadlock. There are two paths that
cause this:
1. low_latency is set
2. flip buffer becomes full
So calling the flip routine from the ISR may work
with some specific drivers, but it would be
dangerous to assume this works in all cases.
--
Paul Fulghum
paulkf@microgate.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UPkernel
2004-11-01 14:10 ` Paul Fulghum
@ 2004-11-01 15:12 ` Stuart MacDonald
2004-11-01 23:02 ` Alan Cox
1 sibling, 0 replies; 6+ messages in thread
From: Stuart MacDonald @ 2004-11-01 15:12 UTC (permalink / raw)
To: 'Paul Fulghum', tytso
Cc: 'Alan Cox', 'Russell King',
'Linux Kernel Mailing List'
From: Paul Fulghum [mailto:paulkf@microgate.com]
> Stuart MacDonald wrote:
> > I always thought the whole point of low_latency was to make the
> > receive-path very fast, which means specifically allowing the flip
> > routine to run from the ISR. So checking for calling from
> the ISR and
> > specifically disallowing that is basically negating the
> entire raison
> > d'etre for low_latency.
>
> I was thought it was to speed processing if the
> caller was already in process context. Maybe the
> real intentions are lost to history.
Best person to ask may be Ted; he was once the serial maintainer. Ted?
> Moving forward, Alan stated that the flip
> routine should not be called in interrupt context.
> His last post concerning some transient state
> of low_latency has confused me.
I didn't follow that either, but I wasn't reading too closely.
> Currently, with the 8250 driver and N_TTY
> line discipline, calling the flip routine from
> ISR causes an SMP deadlock. There are two paths that
> cause this:
> 1. low_latency is set
> 2. flip buffer becomes full
>
> So calling the flip routine from the ISR may work
> with some specific drivers, but it would be
> dangerous to assume this works in all cases.
I haven't looked at the 2.6 serial rewrite in depth yet, but the
problem always existed in the 2.4 driver. I got around the problem by
checking for interrupt context and taking the locks or not at a much
earlier stage.
..Stu
www.connecttech.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UPkernel
2004-11-01 14:10 ` Paul Fulghum
2004-11-01 15:12 ` Stuart MacDonald
@ 2004-11-01 23:02 ` Alan Cox
2004-11-02 0:18 ` Paul Fulghum
1 sibling, 1 reply; 6+ messages in thread
From: Alan Cox @ 2004-11-01 23:02 UTC (permalink / raw)
To: Paul Fulghum
Cc: Stuart MacDonald, 'Russell King',
'Linux Kernel Mailing List'
On Llu, 2004-11-01 at 14:10, Paul Fulghum wrote:
> I was thought it was to speed processing if the
> caller was already in process context. Maybe the
> real intentions are lost to history.
It was added way back by Ted to improve performance when dealing with
low latency requirements for I/O.
> Moving forward, Alan stated that the flip
> routine should not be called in interrupt context.
> His last post concerning some transient state
> of low_latency has confused me.
You were correct about that
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UPkernel
2004-11-01 23:02 ` Alan Cox
@ 2004-11-02 0:18 ` Paul Fulghum
0 siblings, 0 replies; 6+ messages in thread
From: Paul Fulghum @ 2004-11-02 0:18 UTC (permalink / raw)
To: Alan Cox
Cc: Stuart MacDonald, 'Russell King',
'Linux Kernel Mailing List'
On Mon, 2004-11-01 at 17:02, Alan Cox wrote:
> On Llu, 2004-11-01 at 14:10, Paul Fulghum wrote:
> > His last post concerning some transient state
> > of low_latency has confused me.
>
> You were correct about that
What? That I'm easily confused?
*snicker*
--
Paul Fulghum
paulkf@microgate.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-01-10 21:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-10 20:36 [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UPkernel Tim_T_Murphy
-- strict thread matches above, loose matches on Subject: below --
2004-10-31 0:26 [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UP kernel Paul Fulghum
2004-11-01 7:14 ` [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UPkernel Stuart MacDonald
2004-11-01 14:10 ` Paul Fulghum
2004-11-01 15:12 ` Stuart MacDonald
2004-11-01 23:02 ` Alan Cox
2004-11-02 0:18 ` Paul Fulghum
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).