kernel-small_fixes.patch

   1 --- linux-2.6.33/scripts/mod/modpost.c~ 2010-02-24 19:52:17.000000000 +0100
   2 +++ linux-2.6.33/scripts/mod/modpost.c  2010-03-07 14:26:47.242168558 +0100
   3 @@ -15,7 +15,8 @@
   4  #include <stdio.h>
   5  #include <ctype.h>
   6  #include "modpost.h"
   7 -#include "../../include/generated/autoconf.h"
   8 +// PLD architectures don't use CONFIG_SYMBOL_PREFIX
   9 +//#include "../../include/generated/autoconf.h"
  10  #include "../../include/linux/license.h"
  11
  12  /* Some toolchains use a `_' prefix for all user symbols. */
  13
  14 commit 87b09f1f25cd1e01d7c50bf423c7fe33027d7511
  15 Author: stephen hemminger <shemminger@vyatta.com>
  16 Date:   Fri Feb 12 06:58:00 2010 +0000
  17
  18     sky2: dont enable PME legacy mode
  19
  20     This bit is not changed by vendor driver, and should be left alone.
  21     The documentation implies this a debug bit.
  22       0 = WAKE# only asserted when VMAIN not available
  23       1 = WAKE# is depend on wake events and independent of VMAIN.
  24
  25     Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
  26     Signed-off-by: David S. Miller <davem@davemloft.net>
  27
  28 diff --git b/drivers/net/ethernet/marvell/sky2.c a/drivers/net/ethernet/marvell/sky2.c
  29 index 2494842..edf37aa 100644
  30 --- b/drivers/net/ethernet/marvell/sky2.c
  31 +++ a/drivers/net/ethernet/marvell/sky2.c
  32 @@ -733,6 +733,7 @@ static void sky2_wol_init(struct sky2_port *sky2)
  33         unsigned port = sky2->port;
  34         enum flow_control save_mode;
  35         u16 ctrl;
  36 +       u32 reg1;
  37
  38         /* Bring hardware out of reset */
  39         sky2_write16(hw, B0_CTST, CS_RST_CLR);
  40 @@ -786,6 +787,11 @@ static void sky2_wol_init(struct sky2_port *sky2)
  41         /* Disable PiG firmware */
  42         sky2_write16(hw, B0_CTST, Y2_HW_WOL_OFF);
  43
  44 +       /* Turn on legacy PCI-Express PME mode */
  45 +       reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
  46 +       reg1 |= PCI_Y2_PME_LEGACY;
  47 +       sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
  48 +
  49         /* block receiver */
  50         sky2_write8(hw, SK_REG(port, RX_GMF_CTRL_T), GMF_RST_SET);
  51  }
  52 On Sat, 2 Jul 2011, Andi Kleen wrote:
  53
  54 > > The problem is that blk_peek_request() calls scsi_prep_fn(), which
  55 > > does this:
  56 > >
  57 > >     struct scsi_device *sdev = q->queuedata;
  58 > >     int ret = BLKPREP_KILL;
  59 > >
  60 > >     if (req->cmd_type == REQ_TYPE_BLOCK_PC)
  61 > >             ret = scsi_setup_blk_pc_cmnd(sdev, req);
  62 > >     return scsi_prep_return(q, req, ret);
  63 > >
  64 > > It doesn't check to see if sdev is NULL, nor does
  65 > > scsi_setup_blk_pc_cmnd().  That accounts for this error:
  66 >
  67 > I actually added a NULL check in scsi_setup_blk_pc_cmnd early on,
  68 > but that just caused RCU CPU stalls afterwards and then eventually
  69 > a hung system.
  70
  71 The RCU problem is likely to be a separate issue.  It might even be a
  72 result of the use-after-free problem with the elevator.
  73
  74 At any rate, it's clear that the crash in the refcounting log you
  75 posted occurred because scsi_setup_blk_pc_cmnd() called
  76 scsi_prep_state_check(), which tried to dereference the NULL pointer.
  77
  78 Would you like to try this patch to see if it fixes the problem?  As I
  79 said before, I'm not certain it's the best thing to do, but it worked
  80 on my system.
  81
  82 Alan Stern
  83
  84
  85
  86
  87 Index: usb-3.0/drivers/scsi/scsi_lib.c
  88 ===================================================================
  89 --- usb-3.0.orig/drivers/scsi/scsi_lib.c
  90 +++ usb-3.0/drivers/scsi/scsi_lib.c
  91 @@ -1247,6 +1247,8 @@ int scsi_prep_fn(struct request_queue *q
  92         struct scsi_device *sdev = q->queuedata;
  93         int ret = BLKPREP_KILL;
  94
  95 +       if (!sdev)
  96 +               return ret;
  97         if (req->cmd_type == REQ_TYPE_BLOCK_PC)
  98                 ret = scsi_setup_blk_pc_cmnd(sdev, req);
  99         return scsi_prep_return(q, req, ret);
 100 Index: usb-3.0/drivers/scsi/scsi_sysfs.c
 101 ===================================================================
 102 --- usb-3.0.orig/drivers/scsi/scsi_sysfs.c
 103 +++ usb-3.0/drivers/scsi/scsi_sysfs.c
 104 @@ -322,6 +322,8 @@ static void scsi_device_dev_release_user
 105                 kfree(evt);
 106         }
 107
 108 +       /* Freeing the queue signals to block that we're done */
 109 +       scsi_free_queue(sdev->request_queue);
 110         blk_put_queue(sdev->request_queue);
 111         /* NULL queue means the device can't be used */
 112         sdev->request_queue = NULL;
 113 @@ -936,8 +938,6 @@ void __scsi_remove_device(struct scsi_de
 114         /* cause the request function to reject all I/O requests */
 115         sdev->request_queue->queuedata = NULL;
 116
 117 -       /* Freeing the queue signals to block that we're done */
 118 -       scsi_free_queue(sdev->request_queue);
 119         put_device(dev);
 120  }
 121
 122
 123
 124 --
 125 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 126 the body of a message to majordomo@vger.kernel.org
 127 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 128 Please read the FAQ at  http://www.tux.org/lkml/
 129 --- linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh~       2011-07-22 04:17:23.000000000 +0200
 130 +++ linux-3.0/scripts/kconfig/lxdialog/check-lxdialog.sh        2011-08-25 21:26:04.799150642 +0200
 131 @@ -9,6 +9,12 @@
 132                         $cc -print-file-name=lib${lib}.${ext} | grep -q /
 133                         if [ $? -eq 0 ]; then
 134                                 echo "-l${lib}"
 135 +                               for libt in tinfow tinfo ; do
 136 +                                       $cc -print-file-name=lib${libt}.${ext} | grep -q /
 137 +                                       if [ $? -eq 0 ]; then
 138 +                                               echo "-l${libt}"
 139 +                                       fi
 140 +                               done
 141                                 exit
 142                         fi
 143                 done
 144
 145
 146
 147 From:   Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
 148 To:     linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
 149 Subject: [PATCH] small fixes to 3.3 (and 3.2) CPU hotplug code. (v1)
 150 Date:   Wed,  1 Feb 2012 16:16:38 -0500
 151
 152 While I was playing with 'xm vcpu-set X N' I realized that the VCPU hotplug
 153 code in 3.2 spews tons of messages. Found out that we were missing an preempt_*
 154 call. While at it, I fixed also an annoying message ("XENBUS: Unable to ..")
 155 that shows up during bootup.
 156
 157 Anyhow, these are going for 3.3 and CC-ing stable on the:
 158  [PATCH 1/2] xen/smp: Fix CPU online/offline bug triggering a BUG:
 159
 160 --
 161 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 162 the body of a message to majordomo@vger.kernel.org
 163 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 164 Please read the FAQ at  http://www.tux.org/lkml/
 165
 166 From:   Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
 167 To:     linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
 168 Subject: [PATCH 1/2] xen/smp: Fix CPU online/offline bug triggering a BUG: scheduling while atomic.
 169 Date:   Wed,  1 Feb 2012 16:16:39 -0500
 170
 171 When a user offlines a VCPU and then onlines it, we get:
 172
 173 NMI watchdog disabled (cpu2): hardware events not enabled
 174 BUG: scheduling while atomic: swapper/2/0/0x00000002
 175 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
 176  ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs [last unloaded:
 177
 178 Pid: 0, comm: swapper/2 Tainted: G           O 3.2.0phase15.1-00003-gd6f7f5b-dirty #4
 179 Call Trace:
 180  [<ffffffff81070571>] __schedule_bug+0x61/0x70
 181  [<ffffffff8158eb78>] __schedule+0x798/0x850
 182  [<ffffffff8158ed6a>] schedule+0x3a/0x50
 183  [<ffffffff810349be>] cpu_idle+0xbe/0xe0
 184  [<ffffffff81583599>] cpu_bringup_and_idle+0xe/0x10
 185
 186 The reason for this should be obvious from this call-chain:
 187 cpu_bringup_and_idle:
 188  \- cpu_bringup
 189   |   \-[preempt_disable]
 190   |
 191   |- cpu_idle
 192        \- play_dead [assuming the user offlined the VCPU]
 193        |     \
 194        |     +- (xen_play_dead)
 195        |          \- HYPERVISOR_VCPU_off [so VCPU is dead, once user
 196        |          |                       onlines it starts from here]
 197        |          \- cpu_bringup [preempt_disable]
 198        |
 199        +- preempt_enable_no_reschedule()
 200        +- schedule()
 201        \- preempt_enable()
 202
 203 So we have two preempt_disble() and one preempt_enable(). Calling
 204 preempt_enable() after the cpu_bringup() in the xen_play_dead
 205 fixes the imbalance.
 206
 207 Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
 208 ---
 209  arch/x86/xen/smp.c |    7 +++++++
 210  1 files changed, 7 insertions(+), 0 deletions(-)
 211
 212 diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
 213 index 041d4fe..501d4e0 100644
 214 --- a/arch/x86/xen/smp.c
 215 +++ b/arch/x86/xen/smp.c
 216 @@ -409,6 +409,13 @@ static void __cpuinit xen_play_dead(void) /* used only with HOTPLUG_CPU */
 217         play_dead_common();
 218         HYPERVISOR_vcpu_op(VCPUOP_down, smp_processor_id(), NULL);
 219         cpu_bringup();
 220 +       /*
 221 +        * Balance out the preempt calls - as we are running in cpu_idle
 222 +        * loop which has been called at bootup from cpu_bringup_and_idle.
 223 +        * The cpucpu_bringup_and_idle called cpu_bringup which made a
 224 +        * preempt_disable() So this preempt_enable will balance it out.
 225 +        */
 226 +       preempt_enable();
 227  }
 228
 229  #else /* !CONFIG_HOTPLUG_CPU */
 230 --
 231 1.7.7.5
 232
 233 --
 234 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 235 the body of a message to majordomo@vger.kernel.org
 236 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 237 Please read the FAQ at  http://www.tux.org/lkml/
 238
 239 From:   Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
 240 To:     linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
 241 Subject: [PATCH 2/2] xen/bootup: During bootup suppress XENBUS: Unable to read cpu state
 242 Date:   Wed,  1 Feb 2012 16:16:40 -0500
 243
 244 When the initial domain starts, it prints (depending on the
 245 amount of CPUs) a slew of
 246 XENBUS: Unable to read cpu state
 247 XENBUS: Unable to read cpu state
 248 XENBUS: Unable to read cpu state
 249 XENBUS: Unable to read cpu state
 250
 251 which provide no useful information - as the error is a valid
 252 issue - but not on the initial domain. The reason is that the
 253 XenStore is not accessible at that time (it is after all the
 254 first guest) so the CPU hotplug watch cannot parse "availability/cpu"
 255 attribute.
 256
 257 Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
 258 ---
 259  drivers/xen/cpu_hotplug.c |    3 ++-
 260  1 files changed, 2 insertions(+), 1 deletions(-)
 261
 262 diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
 263 index 14e2d99..4dcfced 100644
 264 --- a/drivers/xen/cpu_hotplug.c
 265 +++ b/drivers/xen/cpu_hotplug.c
 266 @@ -30,7 +30,8 @@ static int vcpu_online(unsigned int cpu)
 267         sprintf(dir, "cpu/%u", cpu);
 268         err = xenbus_scanf(XBT_NIL, dir, "availability", "%s", state);
 269         if (err != 1) {
 270 -               printk(KERN_ERR "XENBUS: Unable to read cpu state\n");
 271 +               if (!xen_initial_domain())
 272 +                       printk(KERN_ERR "XENBUS: Unable to read cpu state\n");
 273                 return err;
 274         }
 275
 276 --
 277 1.7.7.5
 278
 279 --
 280 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 281 the body of a message to majordomo@vger.kernel.org
 282 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 283 Please read the FAQ at  http://www.tux.org/lkml/
 284