1. 16 6月, 2011 1 次提交
  2. 08 6月, 2011 1 次提交
    • L
      tty_buffer: get rid of 'seen_tail' logic in flush_to_ldisc · 81de916f
      Linus Torvalds 提交于
      The flush_to_ldisc() work entry has special logic to notice when it has
      seen the original tail of the data queue, and it avoids continuing the
      flush if it sees that _original_ tail rather than the current tail.
      
      This logic can trigger in case somebody is constantly adding new data to
      the tty while the flushing is active - and the intent is to avoid
      excessive CPU usage while flushing the tty, especially as we used to do
      this from a softirq context which made it non-preemptible.
      
      However, since we no longer re-arm the work-queue from within itself
      (because that causes other trouble: see commit a5660b41 "tty: fix
      endless work loop when the buffer fills up"), this just leads to
      possible hung tty's (most easily seen in SMP and with a test-program
      that floods a pty with data - nobody seems to have reported this for any
      real-life situation yet).
      
      And since the workqueue isn't done from timers and softirq's any more,
      it's doubtful whether the CPU useage issue is really relevant any more.
      So just remove the logic entirely, and see if anybody ever notices.
      
      Alternatively, we might want to re-introduce the "re-arm the work" for
      just this case, but then we'd have to re-introduce the delayed work
      model or some explicit timer, which really doesn't seem worth it for
      this.
      Reported-and-tested-by: NGuillaume Chazarain <guichaz@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      81de916f
  3. 04 6月, 2011 1 次提交
    • L
      Revert "tty: make receive_buf() return the amout of bytes received" · 55db4c64
      Linus Torvalds 提交于
      This reverts commit b1c43f82.
      
      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 a5660b41: "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 a5660b41.
      
      Milton Miller pointed out the 'unsigned int' issue.
      Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Reported-by: NMilton Miller <miltonm@bga.com>
      Cc: Stefan Bigler <stefan.bigler@keymile.com>
      Cc: Toby Gray <toby.gray@realvnc.com>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      55db4c64
  4. 27 5月, 2011 1 次提交
  5. 25 5月, 2011 3 次提交
  6. 23 5月, 2011 3 次提交
  7. 20 5月, 2011 3 次提交
  8. 19 5月, 2011 2 次提交
  9. 14 5月, 2011 1 次提交
    • J
      n_tracerouter and n_tracesink ldisc additions. · ee4f6b4b
      J Freyensee 提交于
      The n_tracerouter and n_tracesink line discpline drivers use the
      Linux tty line discpline framework to route trace data coming
      from a tty port (say UART for example) to the trace sink line
      discipline driver and to another tty port(say USB).  Those
      these two line discipline drivers can be used together,
      independently from pti.c, they are part of the original
      implementation solution of the MIPI P1149.7, compact JTAG, PTI
      solution for Intel mobile platforms starting with the
      Medfield platform.
      Signed-off-by: NJ Freyensee <james_p_freyensee@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ee4f6b4b
  10. 13 5月, 2011 1 次提交
  11. 12 5月, 2011 1 次提交
    • S
      8250_pci: Add support for the Digi/IBM PCIe 2-port Adapter · aa273ae5
      Scott Kilau 提交于
      Add support to the 8250 PCI serial driver for the Digi/IBM PCIe 2-port Async EIA-232 Adapter.
      
      Oxford Semiconductor produces a 2/4/8 port UART (OXPCIe952/OXPCIe954/OXPCIe958) chip
      called the Tornado, that can be used to create a very simple serial board product.
      The kernel sources currently have just 2 vendors using this chip, which is Oxford and Mainpipe.
      This new Digi/IBM serial product now uses it as well.
      
      Rather than create a long running comment of vendors using the chip, the one changed comment
      in the patch below now just lists "For Oxford Semiconductor Tornado based devices" to be a
      more generic comment for all vendors that end up using the Oxford Tornado chip.
      
      Cc: Michael Reed <mreed10@us.ibm.com>
      Signed-off-by: NScott Kilau <scottk@digi.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      aa273ae5
  12. 11 5月, 2011 1 次提交
  13. 10 5月, 2011 1 次提交
  14. 06 5月, 2011 1 次提交
  15. 04 5月, 2011 1 次提交
  16. 30 4月, 2011 2 次提交
  17. 26 4月, 2011 8 次提交
  18. 23 4月, 2011 1 次提交
  19. 20 4月, 2011 7 次提交
反馈
建议
客服 返回
顶部