diff --git a/kernel/kernel/files/configs/kernel-x86_64-config b/kernel/kernel/files/configs/kernel-x86_64-config index b3d3edeb..b6092c88 100644 --- a/kernel/kernel/files/configs/kernel-x86_64-config +++ b/kernel/kernel/files/configs/kernel-x86_64-config @@ -1,6 +1,6 @@ # # Automatically generated file; DO NOT EDIT. -# Linux/x86_64 4.4.0 Kernel Configuration +# Linux/x86_64 4.4.2 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y @@ -5807,7 +5807,6 @@ CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS=m CONFIG_EXT3_FS_POSIX_ACL=y -CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y diff --git a/kernel/kernel/files/patches/linux/patch-4.4.2.xz b/kernel/kernel/files/patches/linux/patch-4.4.2.xz new file mode 100644 index 00000000..b2133065 Binary files /dev/null and b/kernel/kernel/files/patches/linux/patch-4.4.2.xz differ diff --git a/kernel/kernel/files/patches/mageia/ata-libata-disable-forced-PORTS_IMPL-for-AHCI-1.3.patch b/kernel/kernel/files/patches/mageia/ata-libata-disable-forced-PORTS_IMPL-for-AHCI-1.3.patch deleted file mode 100644 index 266ac607..00000000 --- a/kernel/kernel/files/patches/mageia/ata-libata-disable-forced-PORTS_IMPL-for-AHCI-1.3.patch +++ /dev/null @@ -1,42 +0,0 @@ -From: Tejun Heo -Subject: [PATCH v2] libata: disable forced PORTS_IMPL for >= AHCI 1.3 -Date: Fri, 15 Jan 2016 15:13:05 -0500 - -Some early controllers incorrectly reported zero ports in PORTS_IMPL -register and the ahci driver fabricates PORTS_IMPL from the number of -ports in those cases. This hasn't mattered but with the new nvme -controllers there are cases where zero PORTS_IMPL is valid and should -be honored. - -Disable the workaround for >= AHCI 1.3. - -Signed-off-by: Tejun Heo -Reported-by: Andy Lutomirski -Link: http://lkml.kernel.org/g/CALCETrU7yMvXEDhjAUShoHEhDwifJGapdw--BKxsP0jmjKGmRw@mail.gmail.com ---- -Hello, Andy. - -Can you please see whether this one works? - -Thanks. - - drivers/ata/libahci.c | 5 +++-- - 1 file changed, 3 insertions(+), 2 deletions(-) - -diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c -index d61740e..a91432a 100644 ---- a/drivers/ata/libahci.c -+++ b/drivers/ata/libahci.c -@@ -496,8 +496,9 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv) - } - } - -- /* fabricate port_map from cap.nr_ports */ -- if (!port_map) { -+ /* fabricate port_map from cap.nr_ports for < AHCI 1.3 */ -+ if (!port_map && (!(vers >> 16) || -+ ((vers >> 16) == 1 && (vers & 0xFFFF) < 0x300))) { - port_map = (1 << ahci_nr_ports(cap)) - 1; - dev_warn(dev, "forcing PORTS_IMPL to 0x%x\n", port_map); - - diff --git a/kernel/kernel/files/patches/mageia/fs-xfs-Revert-xfs-clear-PF_NOFREEZE-for-xfsaild-kthread.patch b/kernel/kernel/files/patches/mageia/fs-xfs-Revert-xfs-clear-PF_NOFREEZE-for-xfsaild-kthread.patch new file mode 100644 index 00000000..5c483f7f --- /dev/null +++ b/kernel/kernel/files/patches/mageia/fs-xfs-Revert-xfs-clear-PF_NOFREEZE-for-xfsaild-kthread.patch @@ -0,0 +1,39 @@ +From 3e85286e75224fa3f08bdad20e78c8327742634e Mon Sep 17 00:00:00 2001 +From: Dave Chinner +Date: Tue, 19 Jan 2016 08:21:46 +1100 +Subject: [PATCH] Revert "xfs: clear PF_NOFREEZE for xfsaild kthread" + +This reverts commit 24ba16bb3d499c49974669cd8429c3e4138ab102 as it +prevents machines from suspending. This regression occurs when the +xfsaild is idle on entry to suspend, and so there s no activity to +wake it from it's idle sleep and hence see that it is supposed to +freeze. Hence the freezer times out waiting for it and suspend is +cancelled. + +There is no obvious fix for this short of freezing the filesystem +properly, so revert this change for now. + +cc: # 4.4 +Signed-off-by: Dave Chinner +Acked-by: Jiri Kosina +Reviewed-by: Brian Foster +Signed-off-by: Dave Chinner +--- + fs/xfs/xfs_trans_ail.c | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/fs/xfs/xfs_trans_ail.c b/fs/xfs/xfs_trans_ail.c +index aa67339..4f18fd9 100644 +--- a/fs/xfs/xfs_trans_ail.c ++++ b/fs/xfs/xfs_trans_ail.c +@@ -497,7 +497,6 @@ xfsaild( + long tout = 0; /* milliseconds */ + + current->flags |= PF_MEMALLOC; +- set_freezable(); + + while (!kthread_should_stop()) { + if (tout && tout <= 20) +-- +2.7.1 + diff --git a/kernel/kernel/files/patches/mageia/gpu-drm-Fix-drm_vblank_pre_post_modeset-regression-from-Linux-4.4.patch b/kernel/kernel/files/patches/mageia/gpu-drm-Fix-drm_vblank_pre_post_modeset-regression-from-Linux-4.4.patch new file mode 100644 index 00000000..df761c07 --- /dev/null +++ b/kernel/kernel/files/patches/mageia/gpu-drm-Fix-drm_vblank_pre_post_modeset-regression-from-Linux-4.4.patch @@ -0,0 +1,82 @@ +From: Mario Kleiner +Subject: [PATCH 3/6] drm: Fix drm_vblank_pre/post_modeset regression from Linux 4.4 +Date: Fri, 12 Feb 2016 20:30:29 +0100 + +Changes to drm_update_vblank_count() in Linux 4.4 broke the +behaviour of the pre/post modeset functions as the new update +code doesn't deal with hw vblank counter resets inbetween calls +to drm_vblank_pre_modeset an drm_vblank_post_modeset, as it +should. + +This causes mistreatment of such hw counter resets as counter +wraparound, and thereby large forward jumps of the software +vblank counter which in turn cause vblank event dispatching +and vblank waits to fail/hang --> userspace clients hang. + +This symptom was reported on radeon-kms to cause a infinite +hang of KDE Plasma 5 shell's login procedure, preventing users +from logging in. + +Fix this by detecting when drm_update_vblank_count() is called +inside a pre->post modeset interval. If so, clamp valid vblank +increments to the safe values 0 and 1, pretty much restoring +the update behavior of the old update code of Linux 4.3 and +earlier. Also reset the last recorded hw vblank count at call +to drm_vblank_post_modeset() to be safe against hw that after +modesetting, dpms on etc. only fires its first vblank irq after +drm_vblank_post_modeset() was already called. + +Reported-by: Vlastimil Babka +Signed-off-by: Mario Kleiner +Reviewed-by: Daniel Vetter +Tested-by: Vlastimil Babka + +Cc: # 4.4+ +Cc: michel@daenzer.net +Cc: vbabka@suse.cz +Cc: ville.syrjala@linux.intel.com +Cc: daniel.vetter@ffwll.ch +Cc: dri-devel@lists.freedesktop.org +Cc: alexander.deucher@amd.com +Cc: christian.koenig@amd.com +--- + drivers/gpu/drm/drm_irq.c | 16 ++++++++++++++++ + 1 file changed, 16 insertions(+) + +diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c +index 92ad62f..055b0fa 100644 +--- a/drivers/gpu/drm/drm_irq.c ++++ b/drivers/gpu/drm/drm_irq.c +@@ -222,6 +222,21 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, + } + + /* ++ * Within a drm_vblank_pre_modeset - drm_vblank_post_modeset ++ * interval? If so then vblank irqs keep running and it will likely ++ * happen that the hardware vblank counter is not trustworthy as it ++ * might reset at some point in that interval and vblank timestamps ++ * are not trustworthy either in that interval. Iow. this can result ++ * in a bogus diff >> 1 which must be avoided as it would cause ++ * random large forward jumps of the software vblank counter. ++ */ ++ if (diff > 1 && (vblank->inmodeset & 0x2)) { ++ DRM_DEBUG_VBL("clamping vblank bump to 1 on crtc %u: diffr=%u" ++ " due to pre-modeset.\n", pipe, diff); ++ diff = 1; ++ } ++ ++ /* + * FIMXE: Need to replace this hack with proper seqlocks. + * + * Restrict the bump of the software vblank counter to a safe maximum +@@ -1575,6 +1590,7 @@ void drm_vblank_post_modeset(struct drm_device *dev, unsigned int pipe) + if (vblank->inmodeset) { + spin_lock_irqsave(&dev->vbl_lock, irqflags); + dev->vblank_disable_allowed = true; ++ drm_reset_vblank_timestamp(dev, pipe); + spin_unlock_irqrestore(&dev->vbl_lock, irqflags); + + if (vblank->inmodeset & 0x2) +-- +1.9.1 + diff --git a/kernel/kernel/files/patches/mageia/gpu-drm-Fix-treatment-of-drm_vblank_offdelay-in-drm_vblank_on-v2.patch b/kernel/kernel/files/patches/mageia/gpu-drm-Fix-treatment-of-drm_vblank_offdelay-in-drm_vblank_on-v2.patch new file mode 100644 index 00000000..246229bd --- /dev/null +++ b/kernel/kernel/files/patches/mageia/gpu-drm-Fix-treatment-of-drm_vblank_offdelay-in-drm_vblank_on-v2.patch @@ -0,0 +1,64 @@ +From: Mario Kleiner +Subject: [PATCH 4/6] drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2) +Date: Fri, 12 Feb 2016 20:30:30 +0100 + +drm_vblank_offdelay can have three different types of values: + +< 0 is to be always treated the same as dev->vblank_disable_immediate += 0 is to be treated as "never disable vblanks" +> 0 is to be treated as disable immediate if kms driver wants it + that way via dev->vblank_disable_immediate. Otherwise it is + a disable timeout in msecs. + +This got broken in Linux 3.18+ for the implementation of +drm_vblank_on. If the user specified a value of zero which should +always reenable vblank irqs in this function, a kms driver could +override the users choice by setting vblank_disable_immediate +to true. This patch fixes the regression and keeps the user in +control. + +v2: Only reenable vblank if there are clients left or the user + requested to "never disable vblanks" via offdelay 0. Enabling + vblanks even in the "delayed disable" case (offdelay > 0) was + specifically added by Ville in commit cd19e52aee922 + ("drm: Kick start vblank interrupts at drm_vblank_on()"), + but after discussion it turns out that this was done by accident. + + Citing Ville: "I think it just ended up as a mess due to changing + some of the semantics of offdelay<0 vs. offdelay==0 vs. + disable_immediate during the review of the series. So yeah, given + how drm_vblank_put() works now, I'd just make this check for + offdelay==0." + +Signed-off-by: Mario Kleiner +Reviewed-by: Daniel Vetter + +Cc: # 3.18+ +Cc: michel@daenzer.net +Cc: vbabka@suse.cz +Cc: ville.syrjala@linux.intel.com +Cc: daniel.vetter@ffwll.ch +Cc: dri-devel@lists.freedesktop.org +Cc: alexander.deucher@amd.com +Cc: christian.koenig@amd.com +--- + drivers/gpu/drm/drm_irq.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c +index 055b0fa..8090989 100644 +--- a/drivers/gpu/drm/drm_irq.c ++++ b/drivers/gpu/drm/drm_irq.c +@@ -1494,8 +1494,7 @@ void drm_vblank_on(struct drm_device *dev, unsigned int pipe) + * re-enable interrupts if there are users left, or the + * user wishes vblank interrupts to be enabled all the time. + */ +- if (atomic_read(&vblank->refcount) != 0 || +- (!dev->vblank_disable_immediate && drm_vblank_offdelay == 0)) ++ if (atomic_read(&vblank->refcount) != 0 || drm_vblank_offdelay == 0) + WARN_ON(drm_vblank_enable(dev, pipe)); + spin_unlock_irqrestore(&dev->vbl_lock, irqflags); + } +-- +1.9.1 + diff --git a/kernel/kernel/files/patches/mageia/gpu-drm-No-Op-redundant-calls-to-drm_vblank_off-v2.patch b/kernel/kernel/files/patches/mageia/gpu-drm-No-Op-redundant-calls-to-drm_vblank_off-v2.patch new file mode 100644 index 00000000..480c88ba --- /dev/null +++ b/kernel/kernel/files/patches/mageia/gpu-drm-No-Op-redundant-calls-to-drm_vblank_off-v2.patch @@ -0,0 +1,76 @@ +From: Mario Kleiner +Subject: [PATCH 1/6] drm: No-Op redundant calls to drm_vblank_off() (v2) +Date: Fri, 12 Feb 2016 20:30:27 +0100 + +Otherwise if a kms driver calls into drm_vblank_off() more than once +before calling drm_vblank_on() again, the redundant calls to +vblank_disable_and_save() will call drm_update_vblank_count() +while hw vblank counters and vblank timestamping are in a undefined +state during modesets, dpms off etc. + +At least with the legacy drm helpers it is not unusual to +get multiple calls to drm_vblank_off and drm_vblank_on, e.g., +half a dozen calls to drm_vblank_off and two calls to drm_vblank_on +were observed on radeon-kms during dpms-off -> dpms-on transition. + +We don't no-op calls from atomic modesetting drivers, as they +should do a proper job of tracking hw state. + +Fixes large jumps of the software maintained vblank counter due to +the hardware vblank counter resetting to zero during dpms off or +modeset, e.g., if radeon-kms is modified to use drm_vblank_off/on +instead of drm_vblank_pre/post_modeset(). + +This fixes a regression caused by the changes made to +drm_update_vblank_count() in Linux 4.4. + +v2: Don't no-op on atomic modesetting drivers, per suggestion + of Daniel Vetter. + +Signed-off-by: Mario Kleiner +Reviewed-by: Daniel Vetter + +Cc: # 4.4+ +Cc: michel@daenzer.net +Cc: vbabka@suse.cz +Cc: ville.syrjala@linux.intel.com +Cc: daniel.vetter@ffwll.ch +Cc: dri-devel@lists.freedesktop.org +Cc: alexander.deucher@amd.com +Cc: christian.koenig@amd.com +--- + drivers/gpu/drm/drm_irq.c | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c +index 607f493..1a18033 100644 +--- a/drivers/gpu/drm/drm_irq.c ++++ b/drivers/gpu/drm/drm_irq.c +@@ -1313,7 +1313,13 @@ void drm_vblank_off(struct drm_device *dev, unsigned int pipe) + spin_lock_irqsave(&dev->event_lock, irqflags); + + spin_lock(&dev->vbl_lock); +- vblank_disable_and_save(dev, pipe); ++ DRM_DEBUG_VBL("crtc %d, vblank enabled %d, inmodeset %d\n", ++ pipe, vblank->enabled, vblank->inmodeset); ++ ++ /* Avoid redundant vblank disables without previous drm_vblank_on(). */ ++ if (drm_core_check_feature(dev, DRIVER_ATOMIC) || !vblank->inmodeset) ++ vblank_disable_and_save(dev, pipe); ++ + wake_up(&vblank->queue); + + /* +@@ -1415,6 +1421,9 @@ void drm_vblank_on(struct drm_device *dev, unsigned int pipe) + return; + + spin_lock_irqsave(&dev->vbl_lock, irqflags); ++ DRM_DEBUG_VBL("crtc %d, vblank enabled %d, inmodeset %d\n", ++ pipe, vblank->enabled, vblank->inmodeset); ++ + /* Drop our private "prevent drm_vblank_get" refcount */ + if (vblank->inmodeset) { + atomic_dec(&vblank->refcount); +-- +1.9.1 + diff --git a/kernel/kernel/files/patches/mageia/gpu-drm-Prevent-vblank-counter-bumps-1-with-active-vblank-clients-v2.patch b/kernel/kernel/files/patches/mageia/gpu-drm-Prevent-vblank-counter-bumps-1-with-active-vblank-clients-v2.patch new file mode 100644 index 00000000..c65efe96 --- /dev/null +++ b/kernel/kernel/files/patches/mageia/gpu-drm-Prevent-vblank-counter-bumps-1-with-active-vblank-clients-v2.patch @@ -0,0 +1,120 @@ +From: Mario Kleiner +Subject: [PATCH 2/6] drm: Prevent vblank counter bumps > 1 with active vblank clients. (v2) +Date: Fri, 12 Feb 2016 20:30:28 +0100 + +This fixes a regression introduced by the new drm_update_vblank_count() +implementation in Linux 4.4: + +Restrict the bump of the software vblank counter in drm_update_vblank_count() +to a safe maximum value of +1 whenever there is the possibility that +concurrent readers of vblank timestamps could be active at the moment, +as the current implementation of the timestamp caching and updating is +not safe against concurrent readers for calls to store_vblank() with a +bump of anything but +1. A bump != 1 would very likely return corrupted +timestamps to userspace, because the same slot in the cache could +be concurrently written by store_vblank() and read by one of those +readers in a non-atomic fashion and without the read-retry logic +detecting this collision. + +Concurrent readers can exist while drm_update_vblank_count() is called +from the drm_vblank_off() or drm_vblank_on() functions or other non-vblank- +irq callers. However, all those calls are happening with the vbl_lock +locked thereby preventing a drm_vblank_get(), so the vblank refcount +can't increase while drm_update_vblank_count() is executing. Therefore +a zero vblank refcount during execution of that function signals that +is safe for arbitrary counter bumps if called from outside vblank irq, +whereas a non-zero count is not safe. + +Whenever the function is called from vblank irq, we have to assume concurrent +readers could show up any time during its execution, even if the refcount +is currently zero, as vblank irqs are usually only enabled due to the +presence of readers, and because when it is called from vblank irq it +can't hold the vbl_lock to protect it from sudden bumps in vblank refcount. +Therefore also restrict bumps to +1 when the function is called from vblank +irq. + +Such bumps of more than +1 can happen at other times than reenabling +vblank irqs, e.g., when regular vblank interrupts get delayed by more +than 1 frame due to long held locks, long irq off periods, realtime +preemption on RT kernels, or system management interrupts. + +A better solution would be to rewrite the timestamp caching to use +full seqlocks to allow concurrent writes and reads for arbitrary +vblank counter increments. + +v2: Add code comment that this is essentially a hack and should + be replaced by a full seqlock implementation for caching of + timestamps. + +Signed-off-by: Mario Kleiner +Reviewed-by: Daniel Vetter + +Cc: # 4.4+ +Cc: michel@daenzer.net +Cc: vbabka@suse.cz +Cc: ville.syrjala@linux.intel.com +Cc: daniel.vetter@ffwll.ch +Cc: dri-devel@lists.freedesktop.org +Cc: alexander.deucher@amd.com +Cc: christian.koenig@amd.com +--- + drivers/gpu/drm/drm_irq.c | 43 +++++++++++++++++++++++++++++++++++++++++++ + 1 file changed, 43 insertions(+) + +diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c +index 1a18033..92ad62f 100644 +--- a/drivers/gpu/drm/drm_irq.c ++++ b/drivers/gpu/drm/drm_irq.c +@@ -221,6 +221,49 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, + diff = (flags & DRM_CALLED_FROM_VBLIRQ) != 0; + } + ++ /* ++ * FIMXE: Need to replace this hack with proper seqlocks. ++ * ++ * Restrict the bump of the software vblank counter to a safe maximum ++ * value of +1 whenever there is the possibility that concurrent readers ++ * of vblank timestamps could be active at the moment, as the current ++ * implementation of the timestamp caching and updating is not safe ++ * against concurrent readers for calls to store_vblank() with a bump ++ * of anything but +1. A bump != 1 would very likely return corrupted ++ * timestamps to userspace, because the same slot in the cache could ++ * be concurrently written by store_vblank() and read by one of those ++ * readers without the read-retry logic detecting the collision. ++ * ++ * Concurrent readers can exist when we are called from the ++ * drm_vblank_off() or drm_vblank_on() functions and other non-vblank- ++ * irq callers. However, all those calls to us are happening with the ++ * vbl_lock locked to prevent drm_vblank_get(), so the vblank refcount ++ * can't increase while we are executing. Therefore a zero refcount at ++ * this point is safe for arbitrary counter bumps if we are called ++ * outside vblank irq, a non-zero count is not 100% safe. Unfortunately ++ * we must also accept a refcount of 1, as whenever we are called from ++ * drm_vblank_get() -> drm_vblank_enable() the refcount will be 1 and ++ * we must let that one pass through in order to not lose vblank counts ++ * during vblank irq off - which would completely defeat the whole ++ * point of this routine. ++ * ++ * Whenever we are called from vblank irq, we have to assume concurrent ++ * readers exist or can show up any time during our execution, even if ++ * the refcount is currently zero, as vblank irqs are usually only ++ * enabled due to the presence of readers, and because when we are called ++ * from vblank irq we can't hold the vbl_lock to protect us from sudden ++ * bumps in vblank refcount. Therefore also restrict bumps to +1 when ++ * called from vblank irq. ++ */ ++ if ((diff > 1) && (atomic_read(&vblank->refcount) > 1 || ++ (flags & DRM_CALLED_FROM_VBLIRQ))) { ++ DRM_DEBUG_VBL("clamping vblank bump to 1 on crtc %u: diffr=%u " ++ "refcount %u, vblirq %u\n", pipe, diff, ++ atomic_read(&vblank->refcount), ++ (flags & DRM_CALLED_FROM_VBLIRQ) != 0); ++ diff = 1; ++ } ++ + DRM_DEBUG_VBL("updating vblank count on crtc %u:" + " current=%u, diff=%u, hw=%u hw_last=%u\n", + pipe, vblank->count, diff, cur_vblank, vblank->last); +-- +1.9.1 + diff --git a/kernel/kernel/files/patches/mageia/gpu-drm_nouveau_display-Enable-vblank-irqs-after-display-engine-is-on-again.patch b/kernel/kernel/files/patches/mageia/gpu-drm_nouveau_display-Enable-vblank-irqs-after-display-engine-is-on-again.patch new file mode 100644 index 00000000..1db4ce1c --- /dev/null +++ b/kernel/kernel/files/patches/mageia/gpu-drm_nouveau_display-Enable-vblank-irqs-after-display-engine-is-on-again.patch @@ -0,0 +1,57 @@ +From: Mario Kleiner +Subject: [PATCH 6/6] drm/nouveau/display: Enable vblank irqs after display engine is on again. +Date: Fri, 12 Feb 2016 20:30:32 +0100 + +In the display resume path, move the calls to drm_vblank_on() +after the point when the display engine is running again. + +Since changes were made to drm_update_vblank_count() in Linux 4.4+ +to emulate hw vblank counters via vblank timestamping, the function +drm_vblank_on() now needs working high precision vblank timestamping +and therefore working scanout position queries at time of call. +These don't work before the display engine gets restarted, causing +miscalculation of vblank counter increments and thereby large forward +jumps in vblank count at display resume. These jumps can cause client +hangs on resume, or desktop hangs in the case of composited desktops. + +Fix this Linux 4.4 regression by reordering calls accordingly. + +Signed-off-by: Mario Kleiner +Cc: # 4.4+ +Cc: Ben Skeggs +Cc: ville.syrjala@linux.intel.com +Cc: daniel.vetter@ffwll.ch +Cc: dri-devel@lists.freedesktop.org +--- + drivers/gpu/drm/nouveau/nouveau_display.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c +index 18676b8..1f8e51b 100644 +--- a/drivers/gpu/drm/nouveau/nouveau_display.c ++++ b/drivers/gpu/drm/nouveau/nouveau_display.c +@@ -634,10 +634,6 @@ nouveau_display_resume(struct drm_device *dev, bool runtime) + nv_crtc->lut.depth = 0; + } + +- /* Make sure that drm and hw vblank irqs get resumed if needed. */ +- for (head = 0; head < dev->mode_config.num_crtc; head++) +- drm_vblank_on(dev, head); +- + /* This should ensure we don't hit a locking problem when someone + * wakes us up via a connector. We should never go into suspend + * while the display is on anyways. +@@ -647,6 +643,10 @@ nouveau_display_resume(struct drm_device *dev, bool runtime) + + drm_helper_resume_force_mode(dev); + ++ /* Make sure that drm and hw vblank irqs get resumed if needed. */ ++ for (head = 0; head < dev->mode_config.num_crtc; head++) ++ drm_vblank_on(dev, head); ++ + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { + struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc); + +-- +1.9.1 + diff --git a/kernel/kernel/files/patches/mageia/net-netfilter-IFWLOG-remove-unused-label.patch b/kernel/kernel/files/patches/mageia/net-netfilter-IFWLOG-remove-unused-label.patch new file mode 100644 index 00000000..b2c71eab --- /dev/null +++ b/kernel/kernel/files/patches/mageia/net-netfilter-IFWLOG-remove-unused-label.patch @@ -0,0 +1,10 @@ +--- linux-4.4/net/ipv4/netfilter/ipt_IFWLOG.c~ 2016-01-24 13:19:13.233713998 +0100 ++++ linux-4.4/net/ipv4/netfilter/ipt_IFWLOG.c 2016-01-24 20:49:10.145823623 +0100 +@@ -74,7 +74,6 @@ + return; + } + +-nlmsg_failure: + kfree_skb(skb); + PRINTR(KERN_WARNING "IFWLOG: Error sending netlink packet\n"); + } diff --git a/kernel/kernel/files/patches/mageia/series b/kernel/kernel/files/patches/mageia/series index edc9f22b..331e7847 100644 --- a/kernel/kernel/files/patches/mageia/series +++ b/kernel/kernel/files/patches/mageia/series @@ -122,9 +122,6 @@ block-Make-CFQ-default-to-IOPS-mode-on-SSDs.patch # ahci ids ahci-add-new-Intel-device-IDs.patch -# ahci fix -ata-libata-disable-forced-PORTS_IMPL-for-AHCI-1.3.patch - ### ### File-system ### @@ -141,6 +138,9 @@ fs-ovl-root-copy-attr.patch fs-ovl-setattr-check-permissions-before-copy-up.patch fs-ovl-check-dentry-positiveness-in-ovl_cleanup_whiteou.patch +# xfs trace fix (mga#17489) +fs-xfs-Revert-xfs-clear-PF_NOFREEZE-for-xfsaild-kthread.patch + ### ### FireWire ### @@ -200,6 +200,13 @@ gpu-drm-0109-drm-vc4-Add-an-interface-for-capturing-the-GPU-state.patch gpu-drm-radeon-Update-radeon_get_vblank_counter_kms.patch gpu-drm-radeon-Drop-unnecessary-unsigned-int-0-check.patch +# vblank fixes +gpu-drm-No-Op-redundant-calls-to-drm_vblank_off-v2.patch +gpu-drm-Prevent-vblank-counter-bumps-1-with-active-vblank-clients-v2.patch +gpu-drm-Fix-drm_vblank_pre_post_modeset-regression-from-Linux-4.4.patch +gpu-drm-Fix-treatment-of-drm_vblank_offdelay-in-drm_vblank_on-v2.patch +gpu-drm_nouveau_display-Enable-vblank-irqs-after-display-engine-is-on-again.patch + ### ### Hardware Monitoring ### @@ -244,6 +251,7 @@ net-netfilter-IFWLOG-2.6.35-buildfix.patch net-netfilter-IFWLOG-2.6.37-buildfix.patch net-ipv4-netfilter-ipt_IFWLOG-3.6-buildfix.patch net-netfilter-IFWLOG-3.7-buildfix.patch +net-netfilter-IFWLOG-remove-unused-label.patch # netfilter psd support net-netfilter-psd.patch diff --git a/kernel/kernel/pspec.xml b/kernel/kernel/pspec.xml index f3ae3f4f..1d4be546 100644 --- a/kernel/kernel/pspec.xml +++ b/kernel/kernel/pspec.xml @@ -28,8 +28,8 @@ - patches/linux/patch-4.4.1.xz - + patches/linux/patch-4.4.2.xz + patches/mageia/x86-pci-toshiba-equium-a60-assign-busses.patch @@ -65,6 +65,7 @@ patches/mageia/fs-ovl-root-copy-attr.patch patches/mageia/fs-ovl-setattr-check-permissions-before-copy-up.patch patches/mageia/fs-ovl-check-dentry-positiveness-in-ovl_cleanup_whiteou.patch + patches/mageia/fs-xfs-Revert-xfs-clear-PF_NOFREEZE-for-xfsaild-kthread.patch patches/mageia/firewire-ieee1394-module-aliases.patch patches/mageia/char-agp-intel-new-Q57-id.patch patches/mageia/gpu-drm-mach64.patch @@ -102,6 +103,11 @@ patches/mageia/gpu-drm-0109-drm-vc4-Add-an-interface-for-capturing-the-GPU-state.patch patches/mageia/gpu-drm-radeon-Update-radeon_get_vblank_counter_kms.patch patches/mageia/gpu-drm-radeon-Drop-unnecessary-unsigned-int-0-check.patch + patches/mageia/gpu-drm-No-Op-redundant-calls-to-drm_vblank_off-v2.patch + patches/mageia/gpu-drm-Prevent-vblank-counter-bumps-1-with-active-vblank-clients-v2.patch + patches/mageia/gpu-drm-Fix-drm_vblank_pre_post_modeset-regression-from-Linux-4.4.patch + patches/mageia/gpu-drm-Fix-treatment-of-drm_vblank_offdelay-in-drm_vblank_on-v2.patch + patches/mageia/gpu-drm_nouveau_display-Enable-vblank-irqs-after-display-engine-is-on-again.patch patches/mageia/input-i8042-quirks-for-Fujitsu-Lifebook-A544-and-Lif.patch patches/mageia/net-sis190-fix-list-usage.patch patches/mageia/net-netfilter-IFWLOG.patch @@ -110,6 +116,7 @@ patches/mageia/net-netfilter-IFWLOG-2.6.37-buildfix.patch patches/mageia/net-ipv4-netfilter-ipt_IFWLOG-3.6-buildfix.patch patches/mageia/net-netfilter-IFWLOG-3.7-buildfix.patch + patches/mageia/net-netfilter-IFWLOG-remove-unused-label.patch patches/mageia/net-netfilter-psd.patch patches/mageia/net-netfilter-psd-mdv.patch patches/mageia/net-netfilter-psd-2.6.35-buildfix.patch @@ -149,7 +156,6 @@ patches/mageia/3rd-viahss-3.0-buildfix.patch patches/mageia/3rd-rtl8723bs.patch patches/mageia/ahci-add-new-Intel-device-IDs.patch - patches/mageia/ata-libata-disable-forced-PORTS_IMPL-for-AHCI-1.3.patch patches/mageia/arm-0001-dt-bindings-Add-root-properties-for-Raspberry-Pi-2.patch patches/mageia/arm-0002-ARM-bcm2835-Add-a-compat-string-for-bcm2836-machine-.patch patches/mageia/arm-0003-ARM-bcm2835-Add-Kconfig-support-for-bcm2836.patch @@ -162,6 +168,7 @@ patches/mageia/arm-0024-ARM-bcm2835-Add-the-auxiliary-clocks-to-the-device-t.patch patches/mageia/arm-0031-ARM-bcm2835-enable-all-bcm2835-relevant-in-defconfig.patch patches/mageia/arm-0032-ARM-bcm2835-enable-auxiliary-spi-driver-in-defconfig.patch + mageia/net-netfilter-IFWLOG-remove-unused-label.patch @@ -216,6 +223,17 @@ + + 2016-02-18 + 4.4.2 + Version bump to 4.4.2 https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.2 + security + + systemRestart + + Ertuğrul Erata + ertugrulerata@gmail.com + 2016-02-02 4.4.1