]> git.pld-linux.org Git - packages/kernel.git/blobdiff - kernel-small_fixes.patch
- 4.9.135
[packages/kernel.git] / kernel-small_fixes.patch
index 14e5b2d696b4797dff4f7f2ef7c1d68fe8c793b8..319191ce2821f2eacb3c4fdd4b50d92f33d2f795 100644 (file)
  
  /* Some toolchains use a `_' prefix for all user symbols. */
 
-commit 87b09f1f25cd1e01d7c50bf423c7fe33027d7511
-Author: stephen hemminger <shemminger@vyatta.com>
-Date:   Fri Feb 12 06:58:00 2010 +0000
-
-    sky2: dont enable PME legacy mode
-    
-    This bit is not changed by vendor driver, and should be left alone.
-    The documentation implies this a debug bit.
-      0 = WAKE# only asserted when VMAIN not available
-      1 = WAKE# is depend on wake events and independent of VMAIN.
-    
-    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
-    Signed-off-by: David S. Miller <davem@davemloft.net>
-
-diff --git b/drivers/net/ethernet/marvell/sky2.c a/drivers/net/ethernet/marvell/sky2.c
-index 2494842..edf37aa 100644
---- b/drivers/net/ethernet/marvell/sky2.c
-+++ a/drivers/net/ethernet/marvell/sky2.c
-@@ -733,6 +733,7 @@ static void sky2_wol_init(struct sky2_port *sky2)
-       unsigned port = sky2->port;
-       enum flow_control save_mode;
-       u16 ctrl;
-+      u32 reg1;
-       /* Bring hardware out of reset */
-       sky2_write16(hw, B0_CTST, CS_RST_CLR);
-@@ -786,6 +787,11 @@ static void sky2_wol_init(struct sky2_port *sky2)
-       /* Disable PiG firmware */
-       sky2_write16(hw, B0_CTST, Y2_HW_WOL_OFF);
-+      /* Turn on legacy PCI-Express PME mode */
-+      reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
-+      reg1 |= PCI_Y2_PME_LEGACY;
-+      sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
-+
-       /* block receiver */
-       sky2_write8(hw, SK_REG(port, RX_GMF_CTRL_T), GMF_RST_SET);
- }
-On Sat, 2 Jul 2011, Andi Kleen wrote:
-
-> > The problem is that blk_peek_request() calls scsi_prep_fn(), which 
-> > does this:
-> > 
-> >    struct scsi_device *sdev = q->queuedata;
-> >    int ret = BLKPREP_KILL;
-> > 
-> >    if (req->cmd_type == REQ_TYPE_BLOCK_PC)
-> >            ret = scsi_setup_blk_pc_cmnd(sdev, req);
-> >    return scsi_prep_return(q, req, ret);
-> > 
-> > It doesn't check to see if sdev is NULL, nor does 
-> > scsi_setup_blk_pc_cmnd().  That accounts for this error:
-> 
-> I actually added a NULL check in scsi_setup_blk_pc_cmnd early on,
-> but that just caused RCU CPU stalls afterwards and then eventually
-> a hung system.
-
-The RCU problem is likely to be a separate issue.  It might even be a 
-result of the use-after-free problem with the elevator.
-
-At any rate, it's clear that the crash in the refcounting log you
-posted occurred because scsi_setup_blk_pc_cmnd() called
-scsi_prep_state_check(), which tried to dereference the NULL pointer.
-
-Would you like to try this patch to see if it fixes the problem?  As I 
-said before, I'm not certain it's the best thing to do, but it worked 
-on my system.
-
-Alan Stern
-
-
-
-
-Index: usb-3.0/drivers/scsi/scsi_lib.c
-===================================================================
---- usb-3.0.orig/drivers/scsi/scsi_lib.c
-+++ usb-3.0/drivers/scsi/scsi_lib.c
-@@ -1247,6 +1247,8 @@ int scsi_prep_fn(struct request_queue *q
-       struct scsi_device *sdev = q->queuedata;
-       int ret = BLKPREP_KILL;
-+      if (!sdev)
-+              return ret;
-       if (req->cmd_type == REQ_TYPE_BLOCK_PC)
-               ret = scsi_setup_blk_pc_cmnd(sdev, req);
-       return scsi_prep_return(q, req, ret);
-Index: usb-3.0/drivers/scsi/scsi_sysfs.c
-===================================================================
---- usb-3.0.orig/drivers/scsi/scsi_sysfs.c
-+++ usb-3.0/drivers/scsi/scsi_sysfs.c
-@@ -322,6 +322,8 @@ static void scsi_device_dev_release_user
-               kfree(evt);
-       }
-+      /* Freeing the queue signals to block that we're done */
-+      scsi_free_queue(sdev->request_queue);
-       blk_put_queue(sdev->request_queue);
-       /* NULL queue means the device can't be used */
-       sdev->request_queue = NULL;
-@@ -936,8 +938,6 @@ void __scsi_remove_device(struct scsi_de
-       /* cause the request function to reject all I/O requests */
-       sdev->request_queue->queuedata = NULL;
--      /* Freeing the queue signals to block that we're done */
--      scsi_free_queue(sdev->request_queue);
-       put_device(dev);
- }
-
-
---
-To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-Please read the FAQ at  http://www.tux.org/lkml/
 --- linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh~      2011-07-22 04:17:23.000000000 +0200
 +++ linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh       2011-08-25 21:26:04.799150642 +0200
 @@ -9,6 +9,12 @@
@@ -141,144 +26,38 @@ Please read the FAQ at  http://www.tux.org/lkml/
                                exit
                        fi
                done
-
-
-
-From:  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-To:    linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
-Subject: [PATCH] small fixes to 3.3 (and 3.2) CPU hotplug code. (v1)
-Date:  Wed,  1 Feb 2012 16:16:38 -0500
-
-While I was playing with 'xm vcpu-set X N' I realized that the VCPU hotplug
-code in 3.2 spews tons of messages. Found out that we were missing an preempt_*
-call. While at it, I fixed also an annoying message ("XENBUS: Unable to ..")
-that shows up during bootup.
-
-Anyhow, these are going for 3.3 and CC-ing stable on the:
- [PATCH 1/2] xen/smp: Fix CPU online/offline bug triggering a BUG:
-
---
-To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-Please read the FAQ at  http://www.tux.org/lkml/
-
-From:  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-To:    linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
-Subject: [PATCH 1/2] xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while atomic.
-Date:  Wed,  1 Feb 2012 16:16:39 -0500
-
-When a user offlines a VCPU and then onlines it, we get:
-
-NMI watchdog disabled (cpu2): hardware events not enabled
-BUG: scheduling while atomic: swapper/2/0/0x00000002
-Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod libcrc32c crc32c radeon fbco
- ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs [last unloaded:
-
-Pid: 0, comm: swapper/2 Tainted: G           O 3.2.0phase15.1-00003-gd6f7f5b-dirty #4
-Call Trace:
- [<ffffffff81070571>] __schedule_bug+0x61/0x70
- [<ffffffff8158eb78>] __schedule+0x798/0x850
- [<ffffffff8158ed6a>] schedule+0x3a/0x50
- [<ffffffff810349be>] cpu_idle+0xbe/0xe0
- [<ffffffff81583599>] cpu_bringup_and_idle+0xe/0x10
-
-The reason for this should be obvious from this call-chain:
-cpu_bringup_and_idle:
- \- cpu_bringup
-  |   \-[preempt_disable]
-  |
-  |- cpu_idle
-       \- play_dead [assuming the user offlined the VCPU]
-       |     \
-       |     +- (xen_play_dead)
-       |          \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
-       |          |                       onlines it starts from here]
-       |          \- cpu_bringup [preempt_disable]
-       |
-       +- preempt_enable_no_reschedule()
-       +- schedule()
-       \- preempt_enable()
-
-So we have two preempt_disble() and one preempt_enable(). Calling
-preempt_enable() after the cpu_bringup() in the xen_play_dead
-fixes the imbalance.
-
-Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+From 5d12f71723762a39435d054d02bbf5fb87c5cd14 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= <arekm@maven.pl>
+Date: Mon, 6 Feb 2017 14:45:15 +0100
+Subject: [PATCH] mac80211: Print text for disassociation reason
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When disassociation happens only numeric reason is printed
+in ieee80211_rx_mgmt_disassoc(). Add text variant, too.
+
+Signed-off-by: Arkadiusz Miƛkiewicz <arekm@maven.pl>
 ---
- arch/x86/xen/smp.c |    7 +++++++
- 1 files changed, 7 insertions(+), 0 deletions(-)
+ net/mac80211/mlme.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
 
-diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
-index 041d4fe..501d4e0 100644
---- a/arch/x86/xen/smp.c
-+++ b/arch/x86/xen/smp.c
-@@ -409,6 +409,13 @@ static void __cpuinit xen_play_dead(void) /* used only with HOTPLUG_CPU */
-       play_dead_common();
-       HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
-       cpu_bringup();
-+      /*
-+       * Balance out the preempt calls - as we are running in cpu_idle
-+       * loop which has been called at bootup from cpu_bringup_and_idle.
-+       * The cpucpu_bringup_and_idle called cpu_bringup which made a
-+       * preempt_disable() So this preempt_enable will balance it out.
-+       */
-+      preempt_enable();
- }
+diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
+index 098ce9b179ee..fcf8d0aa66ec 100644
+--- a/net/mac80211/mlme.c
++++ b/net/mac80211/mlme.c
+@@ -2801,8 +2801,9 @@ static void ieee80211_rx_mgmt_disassoc(struct ieee80211_sub_if_data *sdata,
  
- #else /* !CONFIG_HOTPLUG_CPU */
--- 
-1.7.7.5
-
---
-To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-Please read the FAQ at  http://www.tux.org/lkml/
-
-From:  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-To:    linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
-Subject: [PATCH 2/2] xen/bootup: During bootup suppress XENBUS: Unable to read cpu state
-Date:  Wed,  1 Feb 2012 16:16:40 -0500
-
-When the initial domain starts, it prints (depending on the
-amount of CPUs) a slew of
-XENBUS: Unable to read cpu state
-XENBUS: Unable to read cpu state
-XENBUS: Unable to read cpu state
-XENBUS: Unable to read cpu state
-
-which provide no useful information - as the error is a valid
-issue - but not on the initial domain. The reason is that the
-XenStore is not accessible at that time (it is after all the
-first guest) so the CPU hotplug watch cannot parse "availability/cpu"
-attribute.
-
-Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
----
- drivers/xen/cpu_hotplug.c |    3 ++-
- 1 files changed, 2 insertions(+), 1 deletions(-)
-
-diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
-index 14e2d99..4dcfced 100644
---- a/drivers/xen/cpu_hotplug.c
-+++ b/drivers/xen/cpu_hotplug.c
-@@ -30,7 +30,8 @@ static int vcpu_online(unsigned int cpu)
-       sprintf(dir, "cpu/%u", cpu);
-       err = xenbus_scanf(XBT_NIL, dir, "availability", "%s", state);
-       if (err != 1) {
--              printk(KERN_ERR "XENBUS: Unable to read cpu state\n");
-+              if (!xen_initial_domain())
-+                      printk(KERN_ERR "XENBUS: Unable to read cpu state\n");
-               return err;
-       }
+       reason_code = le16_to_cpu(mgmt->u.disassoc.reason_code);
+-      sdata_info(sdata, "disassociated from %pM (Reason: %u)\n",
+-                 mgmt->sa, reason_code);
++      sdata_info(sdata, "disassociated from %pM (Reason: %u=%s)\n",
++                 mgmt->sa, reason_code,
++                 ieee80211_get_reason_code_string(reason_code));
+       ieee80211_set_disassoc(sdata, 0, 0, false, NULL);
  
 -- 
-1.7.7.5
-
---
-To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-Please read the FAQ at  http://www.tux.org/lkml/
+2.11.0
 
This page took 0.095177 seconds and 4 git commands to generate.