linux/drivers/tty, branch v2.6.39-rc2

tty: fix endless work loop when the buffer fills up

2011-04-04T21:26:54Z

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

apbuart: Depend upon sparc.

2011-03-31T04:12:24Z

It absolutely needs to be able to get at pdev_archdata members which are sparc specific. Signed-off-by: David S. Miller Reported-by: Stephen Rothwell

sparc32,leon: Fixed APBUART frequency detection

2011-03-30T11:28:54Z

The UARTs may be located on different APB buses, thus have different UART clock frequency. The system frequency is not the same (but often) as the UART frequency, rather the APB bus frequency that the APBUART is located at has the same frequency, so this looks at the "freq" property instead. Signed-off-by: Daniel Hellstrom Signed-off-by: David S. Miller

sparc32, leon: APBUART driver must use archdata to get IRQ number

2011-03-30T11:28:54Z

See Commit id 1636f8ac2b08410df4766449f7c86b912443cd99 (sparc/of: Move of_device fields into struct pdev_archdata), this patch is similar to 19e4875fb21a69fbf620e84769a74d189c69c58d (of/sparc: fix build regression from of_device changes) Signed-off-by: Daniel Hellstrom Acked-by: Sam Ravnborg Signed-off-by: David S. Miller

drivers: Final irq namespace conversion

2011-03-29T12:48:19Z

Scripted with coccinelle. Signed-off-by: Thomas Gleixner

Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb

2011-03-26T04:04:56Z

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb: kdb: add usage string of 'per_cpu' command kgdb,x86_64: fix compile warning found with sparse kdb: code cleanup to use macro instead of value kgdboc,kgdbts: strlen() doesn't count the terminator

kgdboc,kgdbts: strlen() doesn't count the terminator

2011-03-25T21:37:30Z

This is an off by one because strlen() doesn't count the null terminator. We strcpy() these strings into an array of size MAX_CONFIG_LEN. Signed-off-by: Dan Carpenter Signed-off-by: Jason Wessel

lib, arch: add filter argument to show_mem and fix private implementations

2011-03-25T00:49:37Z

Commit ddd588b5dd55 ("oom: suppress nodes that are not allowed from meminfo on oom kill") moved lib/show_mem.o out of lib/lib.a, which resulted in build warnings on all architectures that implement their own versions of show_mem(): lib/lib.a(show_mem.o): In function `show_mem': show_mem.c:(.text+0x1f4): multiple definition of `show_mem' arch/sparc/mm/built-in.o:(.text+0xd70): first defined here The fix is to remove __show_mem() and add its argument to show_mem() in all implementations to prevent this breakage. Architectures that implement their own show_mem() actually don't do anything with the argument yet, but they could be made to filter nodes that aren't allowed in the current context in the future just like the generic implementation. Reported-by: Stephen Rothwell Reported-by: James Bottomley Suggested-by: Andrew Morton Signed-off-by: David Rientjes Signed-off-by: Linus Torvalds

drivers/tty/bfin_jtag_comm.c: avoid calling put_tty_driver on NULL

2011-03-24T02:46:39Z

put_tty_driver calls tty_driver_kref_put on its argument, and then tty_driver_kref_put calls kref_put on the address of a field of this argument. kref_put checks for NULL, but in this case the field is likely to have some offset and so the result of taking its address will not be NULL. Labels are added to be able to skip over the call to put_tty_driver when the argument will be NULL. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression *x; @@ *if (x == NULL) { ... * put_tty_driver(x); ... return ...; } // Signed-off-by: Julia Lawall Cc: Torben Hohn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

tty: stop using "delayed_work" in the tty layer

2011-03-22T23:17:32Z

Using delayed-work for tty flip buffers ends up causing us to wait for the next tick to complete some actions. That's usually not all that noticeable, but for certain latency-critical workloads it ends up being totally unacceptable. As an extreme case of this, passing a token back-and-forth over a pty will take two ticks per iteration, so even just a thousand iterations will take 8 seconds assuming a common 250Hz configuration. Avoiding the whole delayed work issue brings that ping-pong test-case down to 0.009s on my machine. In more practical terms, this latency has been a performance problem for things like dive computer simulators (simulating the serial interface using the ptys) and for other environments (Alan mentions a CP/M emulator). Reported-by: Jef Driesen Acked-by: Greg KH Acked-by: Alan Cox Signed-off-by: Linus Torvalds