10 Dec, 2011

1 commit


26 Jul, 2011

1 commit

  • * 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6: (26 commits)
    amba pl011: workaround for uart registers lockup
    n_gsm: fix the wrong FCS handling
    pch_uart: add missing comment about OKI ML7223
    pch_uart: Add MSI support
    tty: fix "IRQ45: nobody cared"
    PTI feature to allow user to name and mark masterchannel request.
    0 for o PTI Makefile bug.
    tty: serial: samsung.c remove legacy PM code.
    SERIAL: SC26xx: Fix link error.
    serial: mrst_max3110: initialize waitqueue earlier
    mrst_max3110: Change max missing message priority.
    tty: s5pv210: Add delay loop on fifo reset function for UART
    tty/serial: Fix XSCALE serial ports, e.g. ce4100
    serial: bfin_5xx: fix off-by-one with resource size
    drivers/tty: use printk_ratelimited() instead of printk_ratelimit()
    tty: n_gsm: Added refcount usage to gsm_mux and gsm_dlci structs
    tty: n_gsm: Add raw-ip support
    tty: n_gsm: expose gsmtty device nodes at ldisc open time
    pch_phub: Fix register miss-setting issue
    serial: 8250, increase PASS_LIMIT
    ...

    Linus Torvalds
     

02 Jul, 2011

1 commit

  • Unthrottling the TTY during close ends up enabling interrupts
    on a device not on the active list, which will never have the
    interrupts cleared. Doctor, it hurts when I do this.

    >>> On 6/2/2011 at 01:56 AM, in message , Alan Cox wrote:
    > On Wed, 01 Jun 2011 10:34:07 +1200
    > "andrew mcgregor" wrote:
    > > The LKML message
    > > http://kerneltrap.org/mailarchive/linux-kernel/2010/2/25/4541847 from
    > > February doesn't seem to have been resolved since. We struck the
    > > issue, and the patch below (against 2.6.32) fixes it. Should I
    > > supply a patch against 3.0.0rc?
    >
    > I think that would be sensible. I don't actually see how you hit it as
    > the IRQ ought to be masked by then but it's certainly wrong for n_tty
    > to be calling into check_unthrottle at that point.
    >
    > So yes please send a patch with a suitable Signed-off-by: line to
    > linux-serial and cc GregKH as well.
    >
    > Alan

    Signed-off-by: Andrew McGregor
    Signed-off-by: Greg Kroah-Hartman

    Andrew McGregor
     

08 Jun, 2011

1 commit

  • With the previous patch, we fixed another bug where read_buf was freed
    while we still was in n_tty_read. We currently check whether read_buf
    is NULL at the start of the function. Add one more check after we wake
    up from waiting for input.

    Signed-off-by: Jiri Slaby
    Cc: Alan Cox
    Signed-off-by: Greg Kroah-Hartman

    Jiri Slaby
     

04 Jun, 2011

1 commit

  • This reverts commit b1c43f82c5aa265442f82dba31ce985ebb7aa71c.

    It was broken in so many ways, and results in random odd pty issues.

    It re-introduced the buggy schedule_work() in flush_to_ldisc() that can
    cause endless work-loops (see commit a5660b41af6a: "tty: fix endless
    work loop when the buffer fills up").

    It also used an "unsigned int" return value fo the ->receive_buf()
    function, but then made multiple functions return a negative error code,
    and didn't actually check for the error in the caller.

    And it didn't actually work at all. BenH bisected down odd tty behavior
    to it:
    "It looks like the patch is causing some major malfunctions of the X
    server for me, possibly related to PTYs. For example, cat'ing a
    large file in a gnome terminal hangs the kernel for -minutes- in a
    loop of what looks like flush_to_ldisc/workqueue code, (some ftrace
    data in the quoted bits further down).

    ...

    Some more data: It -looks- like what happens is that the
    flush_to_ldisc work queue entry constantly re-queues itself (because
    the PTY is full ?) and the workqueue thread will basically loop
    forver calling it without ever scheduling, thus starving the consumer
    process that could have emptied the PTY."

    which is pretty much exactly the problem we fixed in a5660b41af6a.

    Milton Miller pointed out the 'unsigned int' issue.

    Reported-by: Benjamin Herrenschmidt
    Reported-by: Milton Miller
    Cc: Stefan Bigler
    Cc: Toby Gray
    Cc: Felipe Balbi
    Cc: Greg Kroah-Hartman
    Cc: Alan Cox
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

23 Apr, 2011

1 commit

  • it makes it simpler to keep track of the amount of
    bytes received and simplifies how flush_to_ldisc counts
    the remaining bytes. It also fixes a bug of lost bytes
    on n_tty when flushing too many bytes via the USB
    serial gadget driver.

    Tested-by: Stefan Bigler
    Tested-by: Toby Gray
    Signed-off-by: Felipe Balbi
    Signed-off-by: Greg Kroah-Hartman

    Felipe Balbi
     

05 Apr, 2011

1 commit

  • Commit f23eb2b2b285 ('tty: stop using "delayed_work" in the tty layer')
    ended up causing hung machines on UP with no preemption, because the
    work routine to flip the buffer data to the ldisc would endlessly re-arm
    itself if the destination buffer had filled up.

    With the delayed work, that only caused a timer-driving polling of the
    tty state every timer tick, but without the delay we just ended up with
    basically a busy loop instead.

    Stop the insane polling, and instead make the code that opens up the
    receive room re-schedule the buffer flip work. That's what we should
    have been doing anyway.

    This same "poll for tty room" issue is almost certainly also the cause
    of excessive kworker activity when idle reported by Dave Jones, who also
    reported "flush_to_ldisc executing 2500 times a second" back in Nov 2010:

    http://lkml.org/lkml/2010/11/30/592

    which is that silly flushing done every timer tick. Wasting both power
    and CPU for no good reason.

    Reported-and-tested-by: Alexander Beregalov
    Reported-and-tested-by: Sitsofe Wheeler
    Cc: Greg KH
    Cc: Alan Cox
    Cc: Dave Jones
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

05 Nov, 2010

1 commit