On Sun 04-06-17 21:26:06, Linus Torvalds wrote:
[...]
> Also adding some VM people, because I think it's ridiculous that the
> 0-order allocation failed in the first place. Full report attached,
> there's tons of memory that should have been trivial to free.
Node 0 DMA32 free:64228kB min:12788kB l
On 5/31/2017 18:50, Jani Nikula wrote:
From: Chris Wilson
An error during suspend (e100e_pm_suspend),
[ 429.994338] ACPI : EC: event blocked
[ 429.994633] e1000e: EEE TX LPI TIMER: 0011
[ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[ 430.955454] dpm_run
So there's something wrong with the memory allocation changes since
4.11, which seem to be mostly credited to Chris Wilson.
In particular, I got this earlier today:
Xorg: page allocation failure: order:0,
mode:0x14210d2(GFP_HIGHUSER|__GFP_NORETRY|__GFP_RECLAIMABLE),
nodemask=(null)
and then so
== Series Details ==
Series: drm/i915: Fix GVT-g PVINFO version compatibility check
URL : https://patchwork.freedesktop.org/series/25275/
State : warning
== Summary ==
Series 25275v1 drm/i915: Fix GVT-g PVINFO version compatibility check
https://patchwork.freedesktop.org/api/1.0/series/25275/r
Current it's strictly checked if PVINFO version matches 1.0
for GVT-g i915 guest which doesn't help for compatibility at
all and forces GVT-g host can't extend PVINFO easily with version
bump for real compatibility check.
This fixes that to check minimal required PVINFO version instead
and current
Hi,
>-Original Message-
>From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
>Behalf Of Gerd Hoffmann
>Sent: Friday, June 02, 2017 11:24 PM
>To: Alex Williamson ; Chen, Xiaoguang
>
>Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org; linux-
>ker...@vger.kernel.org;
And whilst I'm here, we need to extend I915_PARAM_HAS_GPU_RESET to
indicate having per-engine resets for the complimentary set of igt.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-g
Quoting Chris Wilson (2017-06-02 21:16:42)
> I think you want to do something like:
>
> if (intel_has_engine_reset()) {
> for_each_engine_mask() {
> if (test_and_set_bit(I915_RESET_ENGINE + engine->id))
> continue;
>
> if (i915_reset
== Series Details ==
Series: drm/i915/glk: Enable cold boot for GLK DSI
URL : https://patchwork.freedesktop.org/series/25253/
State : success
== Summary ==
Series 25253v1 drm/i915/glk: Enable cold boot for GLK DSI
https://patchwork.freedesktop.org/api/1.0/series/25253/revisions/1/mbox/
fi-bdw
As per BSEPC, if device ready bit is '0' in enable IO sequence
then its a cold boot/reset scenario eg: S3/S4 resume. In these
conditions we need to program certain registers and prepare port
from the middle of DSI enable sequence otherwise feature like S3/S4
doesn't work.
V2: Do not assume that on
10 matches
Mail list logo