--- linux-2.6.33/scripts/mod/modpost.c~ 2010-02-24 19:52:17.000000000 +0100 +++ linux-2.6.33/scripts/mod/modpost.c 2010-03-07 14:26:47.242168558 +0100 @@ -15,7 +15,8 @@ #include #include #include "modpost.h" -#include "../../include/generated/autoconf.h" +// PLD architectures don't use CONFIG_SYMBOL_PREFIX +//#include "../../include/generated/autoconf.h" #include "../../include/linux/license.h" /* Some toolchains use a `_' prefix for all user symbols. */ commit 87b09f1f25cd1e01d7c50bf423c7fe33027d7511 Author: stephen hemminger 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 Signed-off-by: David S. Miller 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 @@ $cc -print-file-name=lib${lib}.${ext} | grep -q / if [ $? -eq 0 ]; then echo "-l${lib}" + for libt in tinfow tinfo ; do + $cc -print-file-name=lib${libt}.${ext} | grep -q / + if [ $? -eq 0 ]; then + echo "-l${libt}" + fi + done exit fi done From: Konrad Rzeszutek Wilk 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 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: [] __schedule_bug+0x61/0x70 [] __schedule+0x798/0x850 [] schedule+0x3a/0x50 [] cpu_idle+0xbe/0xe0 [] 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 --- arch/x86/xen/smp.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 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(); } #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 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 --- 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; } -- 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/