1. 03 7月, 2011 1 次提交
  2. 05 6月, 2011 1 次提交
  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. 03 6月, 2011 1 次提交
  5. 02 6月, 2011 13 次提交
  6. 01 6月, 2011 22 次提交
  7. 31 5月, 2011 1 次提交
    • P
      dmaengine: shdma: Fix up fallout from runtime PM changes. · 5c2de444
      Paul Mundt 提交于
      The runtime PM changes introduce sh_dmae_rst() wrapping via the
      runtime_resume helper, depending on dev_get_drvdata() to fetch the
      platform data needed for the DMAOR initialization default at a time
      where drvdata hasn't yet been established by the probe path, resulting
      in general probe misery:
      
              Unable to handle kernel NULL pointer dereference at virtual address 000000c4
              pc = 8025adee
              *pde = 00000000
              Oops: 0000 [#1]
              Modules linked in:
      
              Pid : 1, Comm:           swapper
              CPU : 0                  Not tainted  (3.0.0-rc1-00012-g9436b4ab-dirty #1456)
      
              PC is at sh_dmae_rst+0x28/0x86
              PR is at sh_dmae_rst+0x22/0x86
              PC  : 8025adee SP  : 9e803d10 SR  : 400080f1 TEA : 000000c4
              R0  : 000000c4 R1  : 0000fff8 R2  : 00000000 R3  : 00000040
              R4  : 000000f0 R5  : 00000000 R6  : 00000000 R7  : 804f184c
              R8  : 00000000 R9  : 804dd0e8 R10 : 80283204 R11 : ffffffda
              R12 : 000000a0 R13 : 804dd18c R14 : 9e803d10
              MACH: 00000000 MACL: 00008f20 GBR : 00000000 PR  : 8025ade8
      
              Call trace:
              [<8025ae70>] sh_dmae_runtime_resume+0x24/0x34
              [<80283238>] pm_generic_runtime_resume+0x34/0x3c
              [<80283370>] rpm_callback+0x4a/0x7e
              [<80283efc>] rpm_resume+0x240/0x384
              [<80283f54>] rpm_resume+0x298/0x384
              [<8028428c>] __pm_runtime_resume+0x44/0x7c
              [<8038a358>] __ioremap_caller+0x0/0xec
              [<80284296>] __pm_runtime_resume+0x4e/0x7c
              [<8038a358>] __ioremap_caller+0x0/0xec
              [<80666254>] sh_dmae_probe+0x180/0x6a0
              [<802803ae>] platform_drv_probe+0x26/0x2e
      
      Fix up the ordering accordingly.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      5c2de444