linux/Documentation, branch v3.2.34

x86: Remove the ancient and deprecated disable_hlt() and enable_hlt() facility

2012-11-16T16:46:46Z

commit f6365201d8a21fb347260f89d6e9b3e718d63c70 upstream. The X86_32-only disable_hlt/enable_hlt mechanism was used by the 32-bit floppy driver. Its effect was to replace the use of the HLT instruction inside default_idle() with cpu_relax() - essentially it turned off the use of HLT. This workaround was commented in the code as: "disable hlt during certain critical i/o operations" "This halt magic was a workaround for ancient floppy DMA wreckage. It should be safe to remove." H. Peter Anvin additionally adds: "To the best of my knowledge, no-hlt only existed because of flaky power distributions on 386/486 systems which were sold to run DOS. Since DOS did no power management of any kind, including HLT, the power draw was fairly uniform; when exposed to the much hhigher noise levels you got when Linux used HLT caused some of these systems to fail. They were by far in the minority even back then." Alan Cox further says: "Also for the Cyrix 5510 which tended to go castors up if a HLT occurred during a DMA cycle and on a few other boxes HLT during DMA tended to go astray. Do we care ? I doubt it. The 5510 was pretty obscure, the 5520 fixed it, the 5530 is probably the oldest still in any kind of use." So, let's finally drop this. Signed-off-by: Len Brown Signed-off-by: Josh Boyer Signed-off-by: Andrew Morton Acked-by: "H. Peter Anvin" Acked-by: Alan Cox Cc: Stephen Hemminger Link: http://lkml.kernel.org/n/tip-3rhk9bzf0x9rljkv488tloib@git.kernel.org [ If anyone cares then alternative instruction patching could be used to replace HLT with a one-byte NOP instruction. Much simpler. ] Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings

lguest: fix occasional crash in example launcher.

2012-10-17T02:49:30Z

commit ca16f580a5db7e60bfafe59a50bb133bd3347491 upstream. We usually got away with ->next on the final entry being NULL, but it finally bit me. Signed-off-by: Rusty Russell [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings

i2c-i801: Add Device IDs for Intel Lynx Point-LP PCH

2012-09-19T14:05:02Z

commit 4a8f1ddde942e232387e6129ce4f4c412e43802f upstream. Add the SMBus Device IDs for the Intel Lynx Point-LP PCH. Signed-off-by: James Ralston Signed-off-by: Jean Delvare Signed-off-by: Ben Hutchings

i2c-i801: Add device IDs for Intel Lynx Point

2012-09-19T14:05:02Z

commit 062737fb6d90c632439b1f77ad6a4965cfc84a20 upstream. Add the SMBus controller device IDs for the Intel Lynx Point PCH. Signed-off-by: Seth Heasley Signed-off-by: Jean Delvare Signed-off-by: Ben Hutchings

ARM: dts: imx51-babbage: fix esdhc cd/wp properties

2012-09-19T14:04:31Z

commit a46d2619d7180bda12bad2bf15bbd0731dfc2dcf upstream. The binding doc and dts use properties "fsl,{cd,wp}-internal" while esdhc driver uses "fsl,{cd,wp}-controller". Fix binding doc and dts to get them match driver code. Reported-by: Chris Ball Signed-off-by: Shawn Guo Acked-by: Chris Ball Signed-off-by: Ben Hutchings

ALSA: hda - add dock support for Thinkpad X230 Tablet

2012-08-09T23:24:36Z

commit 108cc108a3bb42fe4705df1317ff98e1e29428a6 upstream. Also add a model/fixup string "lenovo-dock", so that other Thinkpad users will be able to test this fixup easily, to see if it enables dock I/O for them as well. BugLink: https://bugs.launchpad.net/bugs/1026953 Tested-by: John McCarron Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings

stable: update references to older 2.6 versions for 3.x

2012-08-09T23:24:35Z

commit 2584f5212d97b664be250ad5700a2d0fee31a10d upstream. Also add information on where the respective trees are. Signed-off-by: Paul Gortmaker Acked-by: Rob Landley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

stable: Allow merging of backports for serious user-visible performance issues

2012-07-04T04:44:29Z

commit eb3979f64d25120d60b9e761a4c58f70b1a02f86 upstream. Distribution kernel maintainers routinely backport fixes for users that were deemed important but not "something critical" as defined by the rules. To users of these kernels they are very serious and failing to fix them reduces the value of -stable. The problem is that the patches fixing these issues are often subtle and prone to regressions in other ways and need greater care and attention. To combat this, these "serious" backports should have a higher barrier to entry. This patch relaxes the rules to allow a distribution maintainer to merge to -stable a backported patch or small series that fixes a "serious" user-visible performance issue. They should include additional information on the user-visible bug affected and a link to the bugzilla entry if available. The same rules about the patch being already in mainline still apply. Signed-off-by: Mel Gorman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

docs: update HOWTO for 2.6.x -> 3.x versioning

2012-05-30T23:43:30Z

commit 591bfc6bf9e5e25e464fd4c87d64afd5135667c4 upstream. The HOWTO document needed updating for the new kernel versioning. The git URI for -next was updated as well. Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

tcp: change tcp_adv_win_scale and tcp_rmem[2]

2012-05-20T21:56:38Z

[ Upstream commit b49960a05e32121d29316cfdf653894b88ac9190 ] tcp_adv_win_scale default value is 2, meaning we expect a good citizen skb to have skb->len / skb->truesize ratio of 75% (3/4) In 2.6 kernels we (mis)accounted for typical MSS=1460 frame : 1536 + 64 + 256 = 1856 'estimated truesize', and 1856 * 3/4 = 1392. So these skbs were considered as not bloated. With recent truesize fixes, a typical MSS=1460 frame truesize is now the more precise : 2048 + 256 = 2304. But 2304 * 3/4 = 1728. So these skb are not good citizen anymore, because 1460 < 1728 (GRO can escape this problem because it build skbs with a too low truesize.) This also means tcp advertises a too optimistic window for a given allocated rcvspace : When receiving frames, sk_rmem_alloc can hit sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often, especially when application is slow to drain its receive queue or in case of losses (netperf is fast, scp is slow). This is a major latency source. We should adjust the len/truesize ratio to 50% instead of 75% This patch : 1) changes tcp_adv_win_scale default to 1 instead of 2 2) increase tcp_rmem[2] limit from 4MB to 6MB to take into account better truesize tracking and to allow autotuning tcp receive window to reach same value than before. Note that same amount of kernel memory is consumed compared to 2.6 kernels. Signed-off-by: Eric Dumazet Cc: Neal Cardwell Cc: Tom Herbert Cc: Yuchung Cheng Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings