Chon Ming Lee [Thu, 7 Nov 2013 07:23:26 +0000 (15:23 +0800)]
drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333.
For DDR data rate reporting by Punit in PUNIT_GPU_FREQ_STS, the actual
data encoding is 00b=800, 01b=1066, 10b=1333, 11b=1333.
Some premium VLV sku will get the DDR_DATA_RATE set as 11. As a result,
the turbo frequency reporting will be incorrect without this workaround.
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 5 Nov 2013 20:42:28 +0000 (22:42 +0200)]
drm/i915: Improve vlv_gpu_freq() and vlv_freq_opcode()
We're currently miscalculating the VLV graphics clock a little bit.
This is caused by rounding the step to integer MHz, which does not
match reality. Change the formula to match the GUnit HAS to give
more accurate answers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Tue, 5 Nov 2013 20:34:12 +0000 (22:34 +0200)]
drm/i915: Sanitize prepare_pipes after valleyview_modeset_global_pipes()
valleyview_modeset_global_pipes() may add pipes that are getting fully
disabled to prepare_pipes bitmask. The rest of the code doesn't expect
this, so clear out any such pipes from the prepare_pipes bitmask.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jesse Barnes [Tue, 5 Nov 2013 00:06:59 +0000 (16:06 -0800)]
drm/i915/vlv: split CCK and DDR freq usage
It's possible that the CCK clock could run at a different rate than the
DDR clock, so use the same method to get CCK as the GMBUS code does when
calculating the new CDclk divider in the VLV display code.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jesse Barnes [Mon, 4 Nov 2013 21:48:12 +0000 (13:48 -0800)]
drm/i915/vlv: modeset_global_* for VLV v7
On VLV/BYT, we can adjust the CDclk frequency up or down based on the
max pixel clock we need to drive. Lowering it can save power, while
raising it is necessary to support high resolution.
Add a new callback in modeset_affected_pipes and a
modeset_global_resources function to perform this adjustment as
necessary.
v2: use punit interface for 320 and 266 MHz CDclk adjustments (Ville)
v3: reset GMBUS dividers too, since we changed CDclk (Ville)
v4: jump to highest voltage when going to 400MHz CDclk (Jesse)
v5: drop duplicate define (Ville)
use shifts by 1 for fixed point (Ville)
drop new callback (Daniel)
v6: fixup adjusted_mode.clock -> adjusted_mode.crtc_clock again (Ville)
document Bunit reg access better (Ville)
v7: pass modeset_pipes and pipe_config to global_pipes so we get the right
clock data (Ville)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 8 Oct 2013 10:25:43 +0000 (12:25 +0200)]
drm/i915/ns2501: Rip out the reenable hack
With the change in the modeset sequence this shouldn't be required
any more since the ->mode_set callback now gets called when the dvo
port is fully up and running.
Also limit the retry loop to 10 tries to avoid hanging the machine
while holding important modeset locks.
Cc: Thomas Richter <thor@math.tu-berlin.de> Tested-by: Thomas Richter <thor@math.tu-berlin.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 8 Oct 2013 10:25:42 +0000 (12:25 +0200)]
drm/i915/dvo: call ->mode_set callback only when the port is running
The ns2501 controller seems to need the dpll and dvo port to accept
the timing update commands. Quick testing on my x30 here seems to
indicate that other dvo controllers don't mind. So let's move the
->mode_set callback to a place where we have the port up and running
already.
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Thomas Richter <thor@math.tu-berlin.de> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 4 Nov 2013 15:28:47 +0000 (16:28 +0100)]
Merge tag 'v3.12' into drm-intel-next
I want to merge in the new Broadwell support as a late hw enabling
pull request. But since the internal branch was based upon our
drm-intel-nightly integration branch I need to resolve all the
oustanding conflicts in drm/i915 with a backmerge to make the 60+
patches apply properly.
We'll propably have some fun because Linus will come up with a
slightly different merge solution.
All rather simple adjacent lines changed or partial backports from
-next to -fixes, with the exception of the thaw code in i915_dma.c.
That one needed a bit of shuffling to restore the intent.
Oh and the massive header file reordering in intel_drv.h is a bit
trouble. But not much.
v2: Also don't forget the fixup for the silent conflict that results
in compile fail ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Linus Torvalds [Sun, 3 Nov 2013 19:36:41 +0000 (11:36 -0800)]
Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus
Pull MIPS fixes from Ralf Baechle:
"Three fixes across arch/mips with the most complex one being the GIC
interrupt fix - at nine lines still not monster. I'm confident this
are the final MIPS patches even if there should go for an rc8"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: ralink: fix return value check in rt_timer_probe()
MIPS: malta: Fix GIC interrupt offsets
MIPS: Perf: Fix 74K cache map
Mathias Krause [Sun, 3 Nov 2013 11:36:28 +0000 (12:36 +0100)]
ipc, msg: forbid negative values for "msg{max,mnb,mni}"
Negative message lengths make no sense -- so don't do negative queue
lenghts or identifier counts. Prevent them from getting negative.
Also change the underlying data types to be unsigned to avoid hairy
surprises with sign extensions in cases where those variables get
evaluated in unsigned expressions with bigger data types, e.g size_t.
In case a user still wants to have "unlimited" sizes she could just use
INT_MAX instead.
Vineet Gupta [Sat, 2 Nov 2013 12:17:49 +0000 (17:47 +0530)]
ARC: Incorrect mm reference used in vmalloc fault handler
A vmalloc fault needs to sync up PGD/PTE entry from init_mm to current
task's "active_mm". ARC vmalloc fault handler however was using mm.
A vmalloc fault for non user task context (actually pre-userland, from
init thread's open for /dev/console) caused the handler to deref NULL mm
(for mm->pgd)
The reasons it worked so far is amazing:
1. By default (!SMP), vmalloc fault handler uses a cached value of PGD.
In SMP that MMU register is repurposed hence need for mm pointer deref.
2. In pre-3.12 SMP kernel, the problem triggering vmalloc didn't exist in
pre-userland code path - it was introduced with commit 20bafb3d23d108bc
"n_tty: Move buffers into n_tty_data"
Ming Lei [Fri, 1 Nov 2013 22:41:33 +0000 (09:11 +1030)]
scripts/kallsyms: filter symbols not in kernel address space
This patch uses CONFIG_PAGE_OFFSET to filter symbols which
are not in kernel address space because these symbols are
generally for generating code purpose and can't be run at
kernel mode, so we needn't keep them in /proc/kallsyms.
For example, on ARM there are some symbols which may be
linked in relocatable code section, then perf can't parse
symbols any more from /proc/kallsyms, this patch fixes the
problem (introduced b9b32bf70f2fb710b07c94e13afbc729afe221da)
Cc: Russell King <linux@arm.linux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: stable@vger.kernel.org
Linus Torvalds [Fri, 1 Nov 2013 19:23:56 +0000 (12:23 -0700)]
Merge tag 'usb-3.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here is a set of patches that revert all of the changes done to the
pl2303 USB serial driver in the 3.12-rc timeframe, as it turns out
they break some devices that work just fine on 3.11. As it's not a
good idea to break working systems, drop them all and they will be
reworked for future kernel versions such that there is no breakage.
I've also included a MAINTAINERS update for the USB serial subsystem
and a new device id for the ftdi_sio driver as well"
* tag 'usb-3.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: serial: ftdi_sio: add id for Z3X Box device
USB: Maintainers change for usb serial drivers
Revert "USB: pl2303: restrict the divisor based baud rate encoding method to the "HX" chip type"
Revert "usb: pl2303: fix+improve the divsor based baud rate encoding method"
Revert "usb: pl2303: do not round to the next nearest standard baud rate for the divisor based baud rate encoding method"
Revert "usb: pl2303: remove 500000 baud from the list of standard baud rates"
Revert "usb: pl2303: move the two baud rate encoding methods to separate functions"
Revert "usb: pl2303: increase the allowed baud rate range for the divisor based encoding method"
Revert "usb: pl2303: also use the divisor based baud rate encoding method for baud rates < 115200 with HX chips"
Revert "usb: pl2303: add two comments concerning the supported baud rates with HX chips"
Revert "pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup()"
Revert "pl2303: improve the chip type information output on startup"
Revert "pl2303: improve the chip type detection/distinction"
Revert "USB: pl2303: distinguish between original and cloned HX chips"
Linus Torvalds [Fri, 1 Nov 2013 19:23:22 +0000 (12:23 -0700)]
Merge tag 'sound-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull more sound fixes from Takashi Iwai:
"The fixes for random bugs that have been reported lately in the game:
a few fixes in ASoC dpam and wm_hubs bugs spotted by Coverity, a
one-liner HD-audio fixup, and a fix for Oops with DPCM.
They are not so critically urgent bugs, but all small and safe"
* tag 'sound-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: fix oops in snd_pcm_info() caused by ASoC DPCM
ASoC: wm_hubs: Add missing break in hp_supply_event()
ALSA: hda - Add a fixup for ASUS N76VZ
ASoC: dapm: Return -ENOMEM in snd_soc_dapm_new_dai_widgets()
ASoC: dapm: Fix source list debugfs outputs
Linus Torvalds [Fri, 1 Nov 2013 19:22:47 +0000 (12:22 -0700)]
Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux
Pull clock subsystem fixes from Mike Turquette.
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux:
clk: fixup argument order when setting VCO parameters
clk: socfpga: Fix incorrect sdmmc clock name
clk: armada-370: fix tclk frequencies
clk: nomadik: set all timers to use 2.4 MHz TIMCLK
Greg Thelen [Fri, 1 Nov 2013 19:16:59 +0000 (12:16 -0700)]
memcg: remove incorrect underflow check
When a memcg is deleted mem_cgroup_reparent_charges() moves charged
memory to the parent memcg. As of v3.11-9444-g3ea67d0 "memcg: add per
cgroup writeback pages accounting" there's bad pointer read. The goal
was to check for counter underflow. The counter is a per cpu counter
and there are two problems with the code:
(1) per cpu access function isn't used, instead a naked pointer is used
which easily causes oops.
(2) the check doesn't sum all cpus
The fix is to remove the check. It's currently dangerous and isn't
worth fixing it to use something expensive, such as
percpu_counter_sum(), for each reparented page. __this_cpu_read() isn't
enough to fix this because there's no guarantees of the current cpus
count. The only guarantees is that the sum of all per-cpu counter is >=
nr_pages.
Paulo Zanoni [Fri, 1 Nov 2013 15:32:08 +0000 (13:32 -0200)]
drm/i915: avoid unclaimed registers when capturing the error state
Even though we only check for unclaimed registers while we're writing
registers, if we read a bad register we'll still trigger a CPU error
interrupt, and we'll print an "Unclaimed register" DRM_ERROR due to
that. To avoid this error, just avoid touching power domains that are
not enabled.
Use kzalloc so we're sure all the disabled domains will be zeroed on
the error state file. We already print the information that is enough
to discover if the power well is enabled on the error state file, so
this should not be a problem.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69747 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 1 Nov 2013 09:50:22 +0000 (10:50 +0100)]
drm/i915: scramble reset support for DP port CRC on vlv
They've moved the DC balance reset bit around. Again I don't think we
need it, but better safe than sorry and maybe HDMI port CRC will prove
useful for checking infoframes or hdmi audio.
v2: Apply the suggestions from Damien's review.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 1 Nov 2013 09:50:21 +0000 (10:50 +0100)]
drm/i915: scramble reset support for DP port CRC on g4x
We need to reset the DP scrambler on every vsync to get stable CRCs.
And since we can't use the normal pipe CRC on DP ports on g4x we
really need them to be able to test modesetting issues on (e)DP
outputs.
Note that the DC balance reset is for SDVO port CRCs so we don't
strictly need it. But better safe than sorry (and it's a nice template
in case we ever want to grab port CRCs for e.g. audio checking).
v2: Apply the suggestions from Damien's review.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 1 Nov 2013 09:50:20 +0000 (10:50 +0100)]
drm/i916: add "auto" pipe CRC source
On gmch platforms the normal pipe source CRC registers don't work for
DP and TV encoders. And on newer platforms the single pipe CRC has
been replaced by a set of CRC at different stages in the platform.
Now most of our userspace tests don't care one bit about the exact
CRC, they simply want something that reflects any changes on the
screen. Hence add a new auto target for platform agnostic tests to
use.
v2: Pass back the adjusted source so that it can be shown in debugfs.
v3: I seem to be unable to get a stable CRC for DP ports. So let's
just disable them for now when using the auto mode. Note that
testcases need to be restructured so that they can dynamically skip
connectors. They also first need to set up the desired mode
configuration, since otherwise the auto mode won't do the right thing.
v4: Don't leak the modeset mutex on error paths.
v5: Spelling fix for the i9xx auto_source function.
Greg KH [Wed, 30 Oct 2013 18:07:31 +0000 (11:07 -0700)]
USB: Maintainers change for usb serial drivers
Johan has been conned^Wgracious in accepting the maintainership of the
USB serial drivers, especially as he's been doing all of the real work
for the past few years.
At the same time, remove a bunch of old entries for USB serial drivers
that don't make sense anymore, given that the developers are no longer
around, and individual driver maintainerships for tiny things like this
is pretty pointless.
Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip. This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip. This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip. This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip. This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip. This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip. This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip. This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip. This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip. This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip. This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip. This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert all of the pl2303 changes that went into 3.12-rc1 and -rc2 as
they cause regressions on some versions of the chip. This will all be
revisited for later kernel versions when we can figure out how to handle
this in a way that does not break working devices.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Thu, 31 Oct 2013 23:58:23 +0000 (16:58 -0700)]
Merge branch 'akpm' (fixes from Andrew Morton)
Merge four more fixes from Andrew Morton.
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
lib/scatterlist.c: don't flush_kernel_dcache_page on slab page
mm: memcg: fix test for child groups
mm: memcg: lockdep annotation for memcg OOM lock
mm: memcg: use proper memcg in limit bypass
Ming Lei [Thu, 31 Oct 2013 23:34:17 +0000 (16:34 -0700)]
lib/scatterlist.c: don't flush_kernel_dcache_page on slab page
Commit b1adaf65ba03 ("[SCSI] block: add sg buffer copy helper
functions") introduces two sg buffer copy helpers, and calls
flush_kernel_dcache_page() on pages in SG list after these pages are
written to.
Unfortunately, the commit may introduce a potential bug:
- Before sending some SCSI commands, kmalloc() buffer may be passed to
block layper, so flush_kernel_dcache_page() can see a slab page
finally
- According to cachetlb.txt, flush_kernel_dcache_page() is only called
on "a user page", which surely can't be a slab page.
- ARCH's implementation of flush_kernel_dcache_page() may use page
mapping information to do optimization so page_mapping() will see the
slab page, then VM_BUG_ON() is triggered.
Aaro Koskinen reported the bug on ARM/kirkwood when DEBUG_VM is enabled,
and this patch fixes the bug by adding test of '!PageSlab(miter->page)'
before calling flush_kernel_dcache_page().
Signed-off-by: Ming Lei <ming.lei@canonical.com> Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi> Tested-by: Simon Baatz <gmbnomis@gmail.com> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Will Deacon <will.deacon@arm.com> Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Tejun Heo <tj@kernel.org> Cc: "James E.J. Bottomley" <JBottomley@parallels.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: <stable@vger.kernel.org> [3.2+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Johannes Weiner [Thu, 31 Oct 2013 23:34:15 +0000 (16:34 -0700)]
mm: memcg: fix test for child groups
When memcg code needs to know whether any given memcg has children, it
uses the cgroup child iteration primitives and returns true/false
depending on whether the iteration loop is executed at least once or
not.
Because a cgroup's list of children is RCU protected, these primitives
require the RCU read-lock to be held, which is not the case for all
memcg callers. This results in the following splat when e.g. enabling
hierarchy mode:
In the memcg case, we only care about children when we are attempting to
modify inheritable attributes interactively. Racing with deletion could
mean a spurious -EBUSY, no problem. Racing with addition is handled
just fine as well through the memcg_create_mutex: if the child group is
not on the list after the mutex is acquired, it won't be initialized
from the parent's attributes until after the unlock.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Michal Hocko <mhocko@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Johannes Weiner [Thu, 31 Oct 2013 23:34:13 +0000 (16:34 -0700)]
mm: memcg: use proper memcg in limit bypass
Commit 84235de394d9 ("fs: buffer: move allocation failure loop into the
allocator") allowed __GFP_NOFAIL allocations to bypass the limit if they
fail to reclaim enough memory for the charge. But because the main test
case was on a 3.2-based system, the patch missed the fact that on newer
kernels the charge function needs to return root_mem_cgroup when
bypassing the limit, and not NULL. This will corrupt whatever memory is
at NULL + percpu pointer offset. Fix this quickly before problems are
reported.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Michal Hocko <mhocko@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Thu, 31 Oct 2013 22:43:02 +0000 (15:43 -0700)]
vfs: decrapify dput(), fix cache behavior under normal load
We do not want to dirty the dentry->d_flags cacheline in dput() just to
set the DCACHE_REFERENCED flag when it is already set in the common case
anyway. This way the first cacheline of the dentry (which contains the
RCU lookup information etc) can stay shared among multiple CPU's.
This finishes off some of the details of all the scalability patches
merged during the merge window.
Also don't mark dentry_kill() for inlining, since it's the uncommon path
and inlining it just makes the common path slower due to extra function
entry/exit overhead.
Linus Torvalds [Thu, 31 Oct 2013 22:21:26 +0000 (15:21 -0700)]
Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull NUMA balancing memory corruption fixes from Ingo Molnar:
"So these fixes are definitely not something I'd like to sit on, but as
I said to Mel at the KS the timing is quite tight, with Linus planning
v3.12-final within a week.
These 6 commits are a minimalized set of cherry-picks needed to fix
the memory corruption bugs. All commits are fixes, except "mm: numa:
Sanitize task_numa_fault() callsites" which is a cleanup that made two
followup fixes simpler.
I've done targeted testing with just this SHA1 to try to make sure
there are no cherry-picking artifacts. The original non-cherry-picked
set of fixes were exposed to linux-next for a couple of weeks"
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
mm: Account for a THP NUMA hinting update as one PTE update
mm: Close races between THP migration and PMD numa clearing
mm: numa: Sanitize task_numa_fault() callsites
mm: Prevent parallel splits during THP migration
mm: Wait for THP migrations to complete during NUMA hinting faults
mm: numa: Do not account for a hinting fault if we raced
Linus Torvalds [Thu, 31 Oct 2013 17:38:59 +0000 (10:38 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input updates from Dmitry Torokhov:
"A bit later than I would want, but the changes are very minor - a few
new device IDs for new hardware in existing drivers, fix for battery
in Wacom devices not be considered system battery and cause emergency
hibernations, and a couple of other bug fixes"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: ALPS - add support for model found on Dell XT2
Input: wacom - add support for ISDv4 0x10E sensor
Input: wacom - add support for ISDv4 0x10F sensor
Input: wacom - export battery scope
Input: cm109 - convert high volume dev_err() to dev_err_ratelimited()
Input: move name/timer init to input_alloc_dev()
Input: i8042 - i8042_flush fix for a full 8042 buffer
Input: pxa27x_keypad - fix NULL pointer dereference
Linus Torvalds [Thu, 31 Oct 2013 17:13:28 +0000 (10:13 -0700)]
Merge tag 'pm+acpi-3.12-late' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael J Wysocki:
"Last-minute ACPI and power management fixes for 3.12
- Revert epoll and select commits related to the freezer, introduced
during the 3.11 cycle, that cause mysterious user space breakage to
occur during resume from suspend to RAM for multiple users of
32-bit x86 systems. Material for 3.11.y stable kernels.
- Revert a recent ACPI-based PCI hotplug (ACPIPHP) commit that was
part of boot problem fixes for one machine, but turns out to cause
issues with hotplug on Thunderbolt chains with multiple devices.
It also turns out to be unnecessary after another fix in the same
area that went in later. From Mika Westerberg"
* tag 'pm+acpi-3.12-late' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious notifies"
Revert "select: use freezable blocking call"
Revert "epoll: use freezable blocking call"
This is provoked when the ASoC front end is open along with its backend,
(which causes the backend to have a runtime assigned to it) and then the
SNDRV_CTL_IOCTL_PCM_INFO is requested for the (visible) backend device.
Resolve this by ensuring that ASoC internal backend devices are not
visible to userspace, just as the commentry for snd_pcm_new_internal()
says it should be.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Mark Brown <broonie@linaro.org> Cc: <stable@vger.kernel.org> [v3.4+] Signed-off-by: Takashi Iwai <tiwai@suse.de>
Paulo Zanoni [Thu, 31 Oct 2013 14:44:21 +0000 (12:44 -0200)]
drm/i915: use the correct register when turning VDD off
That explains why I was seeing 2 consecutive "Turning eDP VDD off"
messages.
Regression introduced by:
commit bf13e81b904a37d94d83dd6c3b53a147719a3ead
Author: Jani Nikula <jani.nikula@intel.com>
Date: Fri Sep 6 07:40:05 2013 +0300
drm/i915: add support for per-pipe power sequencing on vlv
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
the check for i915_disable_power_well flag was removed by overlook,
so add it back now.
Reported-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chon Ming Lee [Wed, 30 Oct 2013 02:05:19 +0000 (10:05 +0800)]
drm/i915/vlv: Fix typo in the DPIO register define.
Incorrect definition DPIO_TX3_SWING_CTL4.
From Ville's review: "Based on the specs, the typo meant that HDMI B
ended up using "incorrect" de-emphasis for the TMDS data lanes."
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add comment from Ville's review about the impact.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Wei Yongjun [Thu, 31 Oct 2013 07:51:38 +0000 (15:51 +0800)]
MIPS: ralink: fix return value check in rt_timer_probe()
In case of error, the function devm_request_and_ioremap() returns NULL
pointer not ERR_PTR(). Fix it by using devm_ioremap_resource() instead
of devm_request_and_ioremap().
Paulo Zanoni [Wed, 30 Oct 2013 21:50:27 +0000 (19:50 -0200)]
drm/i915: reduce eDP VDD message verbose
Now we only print messages when we actually enable VDD and when we
actually disable VDD.
The changes in the last commit triggered a big number of messages
while the driver was being initialized, and I thought we were toggling
things on/off too many times, but that was not really true: we were
just being too verbose.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 30 Oct 2013 21:50:26 +0000 (19:50 -0200)]
drm/i915: turn the eDP VDD on for any i2c transactions
If the eDP output is disabled, then we try to use /dev/i2c-X file to
do i2c transations, we get a WARN from intel_dp_check_edp() saying
we're trying to do AUX communication with the panel off. So this
commit reorganizes the code so we enable the VDD at
intel_dp_i2c_aux_ch() instead of just the callers inside i915.ko.
This fixes the i2c subtest from the pc8 test of intel-gpu-tools on
machines that have eDP panels.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dave Airlie [Thu, 31 Oct 2013 05:29:10 +0000 (15:29 +1000)]
Merge branch 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
Just a few small fixes for radeon (audio regression fix,
stability fix, and an endian bug noticed by coverity).
* 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon/dpm: fix incompatible casting on big endian
drm/radeon: disable bapm on KB
drm/radeon: use sw CTS/N values for audio on DCE4+
Linus Torvalds [Wed, 30 Oct 2013 21:27:10 +0000 (14:27 -0700)]
Merge branch 'akpm' (fixes from Andrew Morton)
Merge three fixes from Andrew Morton.
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
memcg: use __this_cpu_sub() to dec stats to avoid incorrect subtrahend casting
percpu: fix this_cpu_sub() subtrahend casting for unsigneds
mm/pagewalk.c: fix walk_page_range() access of wrong PTEs
Greg Thelen [Wed, 30 Oct 2013 20:56:21 +0000 (13:56 -0700)]
memcg: use __this_cpu_sub() to dec stats to avoid incorrect subtrahend casting
As of commit 3ea67d06e467 ("memcg: add per cgroup writeback pages
accounting") memcg counter errors are possible when moving charged
memory to a different memcg. Charge movement occurs when processing
writes to memory.force_empty, moving tasks to a memcg with
memcg.move_charge_at_immigrate=1, or memcg deletion.
An example showing error after memory.force_empty:
mapped_file should end with 0. 4503599627370496 == 0x10,0000,0000,0000 == 0x100,0000,0000 pages 1048576 == 0x10,0000 == 0x100 pages
This issue only affects the source memcg on 64 bit machines; the
destination memcg counters are correct. So the rmdir case is not too
important because such counters are soon disappearing with the entire
memcg. But the memcg.force_empty and memory.move_charge_at_immigrate=1
cases are larger problems as the bogus counters are visible for the
(possibly long) remaining life of the source memcg.
The problem is due to memcg use of __this_cpu_from(.., -nr_pages), which
is subtly wrong because it subtracts the unsigned int nr_pages (either
-1 or -512 for THP) from a signed long percpu counter. When
nr_pages=-1, -nr_pages=0xffffffff. On 64 bit machines stat->count[idx]
is signed 64 bit. So memcg's attempt to simply decrement a count (e.g.
from 1 to 0) boils down to:
long count = 1
unsigned int nr_pages = 1
count += -nr_pages /* -nr_pages == 0xffff,ffff */
count is now 0x1,0000,0000 instead of 0
The fix is to subtract the unsigned page count rather than adding its
negation. This only works once "percpu: fix this_cpu_sub() subtrahend
casting for unsigneds" is applied to fix this_cpu_sub().
Signed-off-by: Greg Thelen <gthelen@google.com> Acked-by: Tejun Heo <tj@kernel.org> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Greg Thelen [Wed, 30 Oct 2013 20:56:20 +0000 (13:56 -0700)]
percpu: fix this_cpu_sub() subtrahend casting for unsigneds
this_cpu_sub() is implemented as negation and addition.
This patch casts the adjustment to the counter type before negation to
sign extend the adjustment. This helps in cases where the counter type
is wider than an unsigned adjustment. An alternative to this patch is
to declare such operations unsupported, but it seemed useful to avoid
surprises.
This patch specifically helps the following example:
unsigned int delta = 1
preempt_disable()
this_cpu_write(long_counter, 0)
this_cpu_sub(long_counter, delta)
preempt_enable()
Before this change long_counter on a 64 bit machine ends with value
0xffffffff, rather than 0xffffffffffffffff. This is because
this_cpu_sub(pcp, delta) boils down to this_cpu_add(pcp, -delta),
which is basically:
long_counter = 0 + 0xffffffff
Also apply the same cast to:
__this_cpu_sub()
__this_cpu_sub_return()
this_cpu_sub_return()
All percpu_test.ko passes, especially the following cases which
previously failed:
l -= ui_one;
__this_cpu_sub(long_counter, ui_one);
CHECK(l, long_counter, -1);
Chen LinX [Wed, 30 Oct 2013 20:56:18 +0000 (13:56 -0700)]
mm/pagewalk.c: fix walk_page_range() access of wrong PTEs
When walk_page_range walk a memory map's page tables, it'll skip
VM_PFNMAP area, then variable 'next' will to assign to vma->vm_end, it
maybe larger than 'end'. In next loop, 'addr' will be larger than
'next'. Then in /proc/XXXX/pagemap file reading procedure, the 'addr'
will growing forever in pagemap_pte_range, pte_to_pagemap_entry will
access the wrong pte.
BUG: Bad page map in process procrank pte:8437526f pmd:785de067
addr:9108d000 vm_flags:00200073 anon_vma:f0d99020 mapping: (null) index:9108d
CPU: 1 PID: 4974 Comm: procrank Tainted: G B W O 3.10.1+ #1
Call Trace:
dump_stack+0x16/0x18
print_bad_pte+0x114/0x1b0
vm_normal_page+0x56/0x60
pagemap_pte_range+0x17a/0x1d0
walk_page_range+0x19e/0x2c0
pagemap_read+0x16e/0x200
vfs_read+0x84/0x150
SyS_read+0x4a/0x80
syscall_call+0x7/0xb
Signed-off-by: Liu ShuoX <shuox.liu@intel.com> Signed-off-by: Chen LinX <linx.z.chen@intel.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: <stable@vger.kernel.org> [3.10.x+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Russell King [Wed, 30 Oct 2013 14:16:16 +0000 (14:16 +0000)]
mm: list_lru: fix almost infinite loop causing effective livelock
I've seen a fair number of issues with kswapd and other processes
appearing to get stuck in v3.12-rc. Using sysrq-p many times seems to
indicate that it gets stuck somewhere in list_lru_walk_node(), called
from prune_icache_sb() and super_cache_scan().
I never seem to be able to trigger a calltrace for functions above that
point.
So I decided to add the following to super_cache_scan():
/*
* prune the dcache first as the icache is pinned by it, then
@@ -99,7 +103,7 @@ static unsigned long super_cache_scan(struct shrinker *shrink,
freed += sb->s_op->free_cached_objects(sb, fs_objects,
sc->nid);
}
-
+printk("%s:%u: %s: dentries %lu inodes %lu freed %lu\n", current->comm, current->pid, __func__, dentries, inodes, freed);
drop_super(sb);
return freed;
}
and shortly thereafter, having applied some pressure, I got this:
update-apt-xapi:1616: super_cache_scan: dentries 25632 inodes 2 total 25635
update-apt-xapi:1616: super_cache_scan: dentries 1023 inodes 0
------------[ cut here ]------------
Kernel BUG at c0101994 [verbose debug info unavailable]
Internal error: Oops - BUG: 0 [#3] SMP ARM
Modules linked in: fuse rfcomm bnep bluetooth hid_cypress
CPU: 0 PID: 1616 Comm: update-apt-xapi Tainted: G D 3.12.0-rc7+ #154
task: daea1200 ti: c3bf8000 task.ti: c3bf8000
PC is at super_cache_scan+0x1c0/0x278
LR is at trace_hardirqs_on+0x14/0x18
Process update-apt-xapi (pid: 1616, stack limit = 0xc3bf8240)
...
Backtrace:
(super_cache_scan) from [<c00cd69c>] (shrink_slab+0x254/0x4c8)
(shrink_slab) from [<c00d09a0>] (try_to_free_pages+0x3a0/0x5e0)
(try_to_free_pages) from [<c00c59cc>] (__alloc_pages_nodemask+0x5)
(__alloc_pages_nodemask) from [<c00e07c0>] (__pte_alloc+0x2c/0x13)
(__pte_alloc) from [<c00e3a70>] (handle_mm_fault+0x84c/0x914)
(handle_mm_fault) from [<c001a4cc>] (do_page_fault+0x1f0/0x3bc)
(do_page_fault) from [<c001a7b0>] (do_translation_fault+0xac/0xb8)
(do_translation_fault) from [<c000840c>] (do_DataAbort+0x38/0xa0)
(do_DataAbort) from [<c00133f8>] (__dabt_usr+0x38/0x40)
Notice that we had a very low number of inodes, which were reduced to
zero my mult_frac().
Now, prune_icache_sb() calls list_lru_walk_node() passing that number of
inodes (0) into that as the number of objects to scan:
long prune_icache_sb(struct super_block *sb, unsigned long nr_to_scan,
int nid)
{
LIST_HEAD(freeable);
long freed;
spin_lock(&nlru->lock);
restart:
list_for_each_safe(item, n, &nlru->list) {
enum lru_status ret;
/*
* decrement nr_to_walk first so that we don't livelock if we
* get stuck on large numbesr of LRU_RETRY items
*/
if (--(*nr_to_walk) == 0)
break;
So, if *nr_to_walk was zero when this function was entered, that means
we're wanting to operate on (~0UL)+1 objects - which might as well be
infinite.
Clearly this is not correct behaviour. If we think about the behaviour
of this function when *nr_to_walk is 1, then clearly it's wrong - we
decrement first and then test for zero - which results in us doing
nothing at all. A post-decrement would give the desired behaviour -
we'd try to walk one object and one object only if *nr_to_walk were one.
It also gives the correct behaviour for zero - we exit at this point.
Fixes: 5cedf721a7cd ("list_lru: fix broken LRU_RETRY behaviour") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Dave Chinner <dchinner@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org>
[ Modified to make sure we never underflow the count: this function gets
called in a loop, so the 0 -> ~0ul transition is dangerous - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Wed, 30 Oct 2013 19:29:06 +0000 (12:29 -0700)]
Merge tag 'tty-3.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull serial fixes from Greg KH:
"Here are 3 tiny fixes that are needed for 3.12-final for some serial
drivers.
One of them is a revert of a broken patch, and two others are fixes
for reported bugs. All of these have been in linux-next for a while,
I forgot I had not sent them to you yet, my fault"
(Actually, Greg, you _had_ sent two of the three, so this pulls in just
one actual new fix)
* tag 'tty-3.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty/serial: at91: fix uart/usart selection for older products
Linus Torvalds [Wed, 30 Oct 2013 19:27:12 +0000 (12:27 -0700)]
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"Mainly Intel regression fixes and quirks, along with a simple one
liner to fix rendernodes ioctl access (off by default, but testers
want to test it)"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm: allow DRM_IOCTL_VERSION on render-nodes
drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb
drm/i915: No LVDS hardware on Intel D410PT and D425KT
drm/i915/dp: workaround BIOS eDP bpp clamping issue
drm/i915: Add HSW CRT output readout support
drm/i915: Add support for pipe_bpp readout
Linus Torvalds [Wed, 30 Oct 2013 19:25:15 +0000 (12:25 -0700)]
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Paolo Bonzini:
"Fixes for the 3.12 debugfs problem - removing the duplicate directory
name, and using a better the error code"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: use a more sensible error number when debugfs directory creation fails
KVM: Fix modprobe failure for kvm_intel/kvm_amd
Dan Carpenter [Tue, 29 Oct 2013 19:11:06 +0000 (22:11 +0300)]
aacraid: missing capable() check in compat ioctl
In commit d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we
added a check on CAP_SYS_RAWIO to the ioctl. The compat ioctls need the
check as well.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Markos Chandras [Wed, 30 Oct 2013 14:27:48 +0000 (14:27 +0000)]
MIPS: malta: Fix GIC interrupt offsets
The GIC interrupt offsets are calculated based on the value of NR_CPUS.
However, this is wrong because NR_CPUS may or may not contain the real
number of the actual cpus present in the system. We fix that by using
the 'nr_cpu_ids' variable which contains the real number of cpus in
the system. Previously, an MT core (eg with 8 VPEs) will fail to boot if
NR_CPUS was > 8 with the following errors:
Mika Westerberg [Wed, 30 Oct 2013 12:40:36 +0000 (14:40 +0200)]
Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious notifies"
Commit 2dc4128 (ACPI / hotplug / PCI: Avoid doing too much for
spurious notifies) changed the enable_slot() to check return value of
pci_scan_slot() and if it is zero return early from the function. It
means that there were no new devices in this particular slot.
However, if a device appeared deeper in the hierarchy the code now
ignores it causing things like Thunderbolt chaining fail to recognize
new devices.
The problem with Alex Williamson's machine was solved with commit a47d8c8 (ACPI / hotplug / PCI: Avoid parent bus rescans on spurious
device checks) and hence we should be able to restore the original
functionality that we always rescan on bus check notification.
On a device check notification we still check what acpiphp_rescan_slot()
returns and on zero bail out early.
Fixes: 2dc41281b1d1 (ACPI / hotplug / PCI: Avoid doing too much for spurious notifies) Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This reverts commit 9745cdb36da8 (select: use freezable blocking call)
that triggers problems during resume from suspend to RAM on Paul Bolle's
32-bit x86 machines. Paul says:
Ever since I tried running (release candidates of) v3.11 on the two
working i686s I still have lying around I ran into issues on resuming
from suspend. Reverting 9745cdb36da8 (select: use freezable blocking
call) resolves those issues.
Resuming from suspend on i686 on (release candidates of) v3.11 and
later triggers issues like:
traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in libc-2.16.so[b731c000+1b0000]
and
traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0 in rtkit-daemon[8048000+d000]
Once I hit the systemd error I can only get out of the mess that the
system is at that point by power cycling it.
Since we are reverting another freezer-related change causing similar
problems to happen, this one should be reverted as well.
References: https://lkml.org/lkml/2013/10/29/583 Reported-by: Paul Bolle <pebolle@tiscali.nl> Fixes: 9745cdb36da8 (select: use freezable blocking call) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+
This reverts commit 1c441e921201 (epoll: use freezable blocking call)
which is reported to cause user space memory corruption to happen
after suspend to RAM.
Since it appears to be extremely difficult to root cause this
problem, it is best to revert the offending commit and try to address
the original issue in a better way later.
References: https://bugzilla.kernel.org/show_bug.cgi?id=61781 Reported-by: Natrio <natrio@list.ru> Reported-by: Jeff Pohlmeyer <yetanothergeek@gmail.com> Bisected-by: Leo Wolf <jclw@ymail.com> Fixes: 1c441e921201 (epoll: use freezable blocking call) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+
Paolo Bonzini [Wed, 30 Oct 2013 11:12:13 +0000 (12:12 +0100)]
KVM: use a more sensible error number when debugfs directory creation fails
I don't know if this was due to cut and paste, or somebody was really
using a D20 to pick the error code for kvm_init_debugfs as suggested by
Linus (EFAULT is 14, so the possibility cannot be entirely ruled out).
In any case, this patch fixes it.
Reported-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Daniel Vetter [Mon, 21 Oct 2013 16:04:36 +0000 (18:04 +0200)]
drm/i915: refactor ilk display interrupt handling
- Use a for_each_loop and add the corresponding #defines.
- Drop the _ILK postfix on the existing DE_PIPE_VBLANK macro for
consistency with everything else.
- Also use macros (and add the missing one for plane flips) for the
ivb display interrupt handler.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Drop the useless parens that Ville spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 21 Oct 2013 16:04:35 +0000 (18:04 +0200)]
drm/i915: use enum pipe consistently in i915_irq.c
Request by Ville in his review of the CRC stuff. This converts
everything but ilk_display_irq_handler since that needs a bit more
than a simple search&replace to look nice.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 30 Oct 2013 09:28:22 +0000 (09:28 +0000)]
drm/i915: Capture batchbuffer state upon GPU hang
The bbstate contains useful bits of debugging information such as
whether the batch is being read from GTT or PPGTT, or whether it is
allowed to execute privileged instructions.
v2: Only record BB_STATE for gen4+
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 28 Oct 2013 08:24:13 +0000 (09:24 +0100)]
drm/i915: handle faked missed interrupts as simulated hangs, too
Otherwise QA will report this as a real hang when running igt
ZZ_missed_irq.
v2: Actually test the right stuff and really shut up the DRM_ERROR
output ...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70747 Tested-by: lu hua <huax.lu@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
David Herrmann [Mon, 28 Oct 2013 09:55:49 +0000 (10:55 +0100)]
drm: allow DRM_IOCTL_VERSION on render-nodes
DRM_IOCTL_VERSION is a reliable way to get the driver-name and version
information. It's not related to the interface-version (SET_VERSION ioctl)
so we can safely enable it on render-nodes.
Note that gbm uses udev-BUSID to load the correct mesa driver. However,
the VERSION ioctl should be the more reliable way to do this (in case we
add new DRM-bus drivers which have no BUSID or similar).
Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Wed, 30 Oct 2013 02:30:12 +0000 (12:30 +1000)]
Merge tag 'drm-intel-fixes-2013-10-29' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Regression and warn fixes for i915.
* tag 'drm-intel-fixes-2013-10-29' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb
drm/i915: No LVDS hardware on Intel D410PT and D425KT
drm/i915/dp: workaround BIOS eDP bpp clamping issue
drm/i915: Add HSW CRT output readout support
drm/i915: Add support for pipe_bpp readout
Deng-Cheng Zhu [Tue, 8 Oct 2013 15:17:48 +0000 (16:17 +0100)]
MIPS: Perf: Fix 74K cache map
According to Software User's Manual, the event of last-level-cache
read/write misses is mapped to even counters. Odd counters of that
event number count miss cycles.
Imre Deak [Mon, 28 Oct 2013 15:20:35 +0000 (17:20 +0200)]
drm/i915: rename i915_init_power_well to init_power_domains_init
Similarly rename the other related functions in the power domain
interface.
Higher level driver code calling these functions knows only about power
domains, not the underlying power wells which may be different on
different platforms. Also these functions really init/cleanup/resume
power domains and only through that all related power wells, so rename
them accordingly.
Note that I left i915_{request,release}_power_well as is, since that
really changes the state only of a single power well (and is HSW
specific). It should also get a better name once we make it more
generic by controlling things through a new audio power domain.
v4:
- use intel prefix instead of i915 everywhere (Paulo)
- use a $prefix_$block_$action format (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Linus Torvalds [Tue, 29 Oct 2013 17:21:34 +0000 (10:21 -0700)]
Fix a few incorrectly checked [io_]remap_pfn_range() calls
Nico Golde reports a few straggling uses of [io_]remap_pfn_range() that
really should use the vm_iomap_memory() helper. This trivially converts
two of them to the helper, and comments about why the third one really
needs to continue to use remap_pfn_range(), and adds the missing size
check.
Linus Torvalds [Tue, 29 Oct 2013 15:36:50 +0000 (08:36 -0700)]
Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf tooling fixes from Ingo Molnar:
"This contains five tooling fixes:
- fix a remaining mmap2 assumption which resulted in perf top output
breakage
- fix mmap ring-buffer processing bug that corrupts data
- fix for a severe python scripting memory leak
- fix broken (and user-visible) -g option handling
- fix stdio output
The diffstat size is larger than what we'd like to see this late :-/"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf tools: Fixup mmap event consumption
perf top: Split -G and --call-graph
perf record: Split -g and --call-graph
perf hists: Add color overhead for stdio output buffer
perf tools: Fix up /proc/PID/maps parsing
perf script python: Fix mem leak due to missing Py_DECREFs on dict entries
Linus Torvalds [Tue, 29 Oct 2013 15:33:36 +0000 (08:33 -0700)]
Kconfig: make KOBJECT_RELEASE debugging require timer debugging
Without the timer debugging, the delayed kobject release will just
result in undebuggable oopses if it triggers any latent bugs. That
doesn't actually help debugging at all.
So make DEBUG_KOBJECT_RELEASE depend on DEBUG_OBJECTS_TIMERS to avoid
having people enable one without the other.
Daniel Vetter [Tue, 29 Oct 2013 11:04:08 +0000 (12:04 +0100)]
drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb
Originally I've thought that this is leftover hw state dirt from the
BIOS. But after way too much helpless flailing around on my part I've
noticed that the actual bug is when we change the state of an already
active pipe.
For example when we change the fdi lines from 2 to 3 without switching
off outputs in-between we'll never see the crucial on->off transition
in the ->modeset_global_resources hook the current logic relies on.
Patch version 2 got this right by instead also checking whether the
pipe is indeed active. But that in turn broke things when pipes have
been turned off through dpms since the bifurcate enabling is done in
the ->crtc_mode_set callback.
To address this issues discussed with Ville in the patch review move
the setting of the bifurcate bit into the ->crtc_enable hook. That way
we won't wreak havoc with this state when userspace puts all other
outputs into dpms off state. This also moves us forward with our
overall goal to unify the modeset and dpms on paths (which we need to
have to allow runtime pm in the dpms off state).
Unfortunately this requires us to move the bifurcate helpers around a
bit.
Also update the commit message, I've misanalyzed the bug rather badly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507 Tested-by: Jan-Michael Brummer <jan.brummer@tabos.org> Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Peter Zijlstra [Thu, 17 Oct 2013 13:32:10 +0000 (15:32 +0200)]
perf/x86: Fix NMI measurements
OK, so what I'm actually seeing on my WSM is that sched/clock.c is
'broken' for the purpose we're using it for.
What triggered it is that my WSM-EP is broken :-(
[ 0.001000] tsc: Fast TSC calibration using PIT
[ 0.002000] tsc: Detected 2533.715 MHz processor
[ 0.500180] TSC synchronization [CPU#0 -> CPU#6]:
[ 0.505197] Measured 3 cycles TSC warp between CPUs, turning off TSC clock.
[ 0.004000] tsc: Marking TSC unstable due to check_tsc_sync_source failed
For some reason it consistently detects TSC skew, even though NHM+
should have a single clock domain for 'reasonable' systems.
This marks sched_clock_stable=0, which means that we do fancy stuff to
try and get a 'sane' clock. Part of this fancy stuff relies on the tick,
clearly that's gone when NOHZ=y. So for idle cpus time gets stuck, until
it either wakes up or gets kicked by another cpu.
While this is perfectly fine for the scheduler -- it only cares about
actually running stuff, and when we're running stuff we're obviously not
idle. This does somewhat break down for perf which can trigger events
just fine on an otherwise idle cpu.
So I've got NMIs get get 'measured' as taking ~1ms, which actually
don't last nearly that long:
projects / linux-beck.git / log