Re: v2.4 megaraid2 update Re: [PATCH] Prevent NMI oopser
On Wed, Mar 02, 2005 at 11:26:06AM -0500, Bagalkote, Sreenivas wrote: > Hello Marcelo, Hi Sreenivas, Damn, now I apologize for taking so long to answer... > As per our offline conversation, I have verified the update that went into > 2.4.30-pre2. > I confirm that all changes are correct. I have only one doubt: The driver > was using > sleep_on_timeout for lack of msleep. Should it start using msleep now? I dont see the need for msleep() given that sleep_on_timeout() schedules. The problematic EH code which used udelay() was removed AFAICS. > Vasily & Andrey, thank you for your efforts. I appreciate your offline message that you're compromised to keep an eye on v2.4 megaraid2 from now on :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: v2.4 megaraid2 update Re: [PATCH] Prevent NMI oopser
Hello Marcelo, As per our offline conversation, I have verified the update that went into 2.4.30-pre2. I confirm that all changes are correct. I have only one doubt: The driver was using sleep_on_timeout for lack of msleep. Should it start using msleep now? Vasily & Andrey, thank you for your efforts. Thanks, Sreenivas LSI LOGIC Corporation >-Original Message- >From: Marcelo Tosatti [mailto:[EMAIL PROTECTED] >Sent: Wednesday, February 23, 2005 2:06 AM >To: Andrey J. Melnikoff (TEMHOTA); Vasily Averin >Cc: Matt Domsch; linux-kernel@vger.kernel.org; Mukker, Atul; >Bagalkote, Sreenivas >Subject: v2.4 megaraid2 update Re: [PATCH] Prevent NMI oopser > > >Hi, > >As the megaraid2 maintainers dont seem to care about v2.4 >mainline at all, completly >ignoring my requests to fix the NMI oopser bug for several >months, I'm applying the RHEL3 >update + inline reordering, which should do it. > >At this point I'm quite sure they wont answer this message either. :( > >Thanks Vasily and Andrey. > >On Mon, Feb 07, 2005 at 11:27:45PM +0300, Andrey J. Melnikoff >(TEMHOTA) wrote: >> Hi Matt, Marcelo! >> On Wed, Feb 02, 2005 at 02:19:14PM -0600, Matt Domsch wrote next: >> >> > On Wed, Feb 02, 2005 at 10:32:28PM +0300, Vasily Averin wrote: >> > > >As a hack, one could #define inline /*nothing*/ in >megaraid2.h to >> > > >avoid this, but it would be nice if the functions could all get >> > > >reordered such that inlining works properly, and the >need for function >> > > >declarations in megaraid2.h would disappear completely. >> > > >> > > >> > > Could you fix it by additional patch? Or you going to >prepare a new one? >> >> Any chance to include this two patches before 2.4.30 release? >> >> Vasily Averin patch: >> http://marc.theaimsgroup.com/?l=linux-kernel&m=110737085714273&w=2 >> And my (incremental) patch: >> http://marc.theaimsgroup.com/?l=linux-kernel&m=110738438005846&w=2 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
v2.4 megaraid2 update Re: [PATCH] Prevent NMI oopser
Hi, As the megaraid2 maintainers dont seem to care about v2.4 mainline at all, completly ignoring my requests to fix the NMI oopser bug for several months, I'm applying the RHEL3 update + inline reordering, which should do it. At this point I'm quite sure they wont answer this message either. :( Thanks Vasily and Andrey. On Mon, Feb 07, 2005 at 11:27:45PM +0300, Andrey J. Melnikoff (TEMHOTA) wrote: > Hi Matt, Marcelo! > On Wed, Feb 02, 2005 at 02:19:14PM -0600, Matt Domsch wrote next: > > > On Wed, Feb 02, 2005 at 10:32:28PM +0300, Vasily Averin wrote: > > > >As a hack, one could #define inline /*nothing*/ in megaraid2.h to > > > >avoid this, but it would be nice if the functions could all get > > > >reordered such that inlining works properly, and the need for function > > > >declarations in megaraid2.h would disappear completely. > > > > > > > > > Could you fix it by additional patch? Or you going to prepare a new one? > > Any chance to include this two patches before 2.4.30 release? > > Vasily Averin patch: > http://marc.theaimsgroup.com/?l=linux-kernel&m=110737085714273&w=2 > And my (incremental) patch: > http://marc.theaimsgroup.com/?l=linux-kernel&m=110738438005846&w=2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent NMI oopser
Hi Matt Domsch!
On Wed, Feb 02, 2005 at 02:19:14PM -0600, Matt Domsch wrote next:
> On Wed, Feb 02, 2005 at 10:32:28PM +0300, Vasily Averin wrote:
> > >As a hack, one could #define inline /*nothing*/ in megaraid2.h to
> > >avoid this, but it would be nice if the functions could all get
> > >reordered such that inlining works properly, and the need for function
> > >declarations in megaraid2.h would disappear completely.
> >
> >
> > Could you fix it by additional patch? Or you going to prepare a new one?
>
> Here's the hack patch (will apply after yours).
Reorder inline functions
Uninline big mega_cmd_done() function
Signed-off-by: <[EMAIL PROTECTED]>
--- drivers/scsi/megaraid2.c.orig Wed Feb 2 23:30:04 2005
+++ drivers/scsi/megaraid2.cWed Feb 2 23:57:15 2005
@@ -989,6 +989,268 @@
}
+/**
+ * issue_scb()
+ * @adapter - pointer to our soft state
+ * @scb - scsi control block
+ *
+ * Post a command to the card if the mailbox is available, otherwise return
+ * busy. We also take the scb from the pending list if the mailbox is
+ * available.
+ */
+static inline int
+issue_scb(adapter_t *adapter, scb_t *scb)
+{
+ volatile mbox64_t *mbox64 = adapter->mbox64;
+ volatile mbox_t *mbox = adapter->mbox;
+ unsigned inti = 0;
+
+ if(unlikely(mbox->busy)) {
+ do {
+ udelay(1);
+ i++;
+ } while( mbox->busy && (i < max_mbox_busy_wait) );
+
+ if(mbox->busy) return -1;
+ }
+
+ /* Copy mailbox data into host structure */
+ memcpy((char *)mbox, (char *)scb->raw_mbox, 16);
+
+ mbox->cmdid = scb->idx; /* Set cmdid */
+ mbox->busy = 1; /* Set busy */
+
+
+ /*
+* Increment the pending queue counter
+*/
+ atomic_inc(&adapter->pend_cmds);
+
+ switch (mbox->cmd) {
+ case MEGA_MBOXCMD_EXTPTHRU:
+ if( !adapter->has_64bit_addr ) break;
+ // else fall through
+ case MEGA_MBOXCMD_LREAD64:
+ case MEGA_MBOXCMD_LWRITE64:
+ case MEGA_MBOXCMD_PASSTHRU64:
+ mbox64->xfer_segment_lo = mbox->xferaddr;
+ mbox64->xfer_segment_hi = 0;
+ mbox->xferaddr = 0x;
+ break;
+ default:
+ mbox64->xfer_segment_lo = 0;
+ mbox64->xfer_segment_hi = 0;
+ }
+
+ /*
+* post the command
+*/
+ scb->state |= SCB_ISSUED;
+
+ if( likely(adapter->flag & BOARD_MEMMAP) ) {
+ mbox->poll = 0;
+ mbox->ack = 0;
+ WRINDOOR(adapter, adapter->mbox_dma | 0x1);
+ }
+ else {
+ irq_enable(adapter);
+ issue_command(adapter);
+ }
+
+ return 0;
+}
+
+
+/**
+ * mega_runpendq()
+ * @adapter - pointer to our soft state
+ *
+ * Runs through the list of pending requests.
+ */
+static inline void
+mega_runpendq(adapter_t *adapter)
+{
+ if(!list_empty(&adapter->pending_list))
+ __mega_runpendq(adapter);
+}
+
+
+static void
+__mega_runpendq(adapter_t *adapter)
+{
+ scb_t *scb;
+ struct list_head *pos, *next;
+
+ /* Issue any pending commands to the card */
+ list_for_each_safe(pos, next, &adapter->pending_list) {
+
+ scb = list_entry(pos, scb_t, list);
+
+ if( !(scb->state & SCB_ISSUED) ) {
+
+ if( issue_scb(adapter, scb) != 0 )
+ return;
+ }
+ }
+
+ return;
+}
+
+
+/**
+ * mega_allocate_scb()
+ * @adapter - pointer to our soft state
+ * @cmd - scsi command from the mid-layer
+ *
+ * Allocate a SCB structure. This is the central structure for controller
+ * commands.
+ */
+static inline scb_t *
+mega_allocate_scb(adapter_t *adapter, Scsi_Cmnd *cmd)
+{
+ struct list_head *head = &adapter->free_list;
+ scb_t *scb;
+
+ /* Unlink command from Free List */
+ if( !list_empty(head) ) {
+
+ scb = list_entry(head->next, scb_t, list);
+
+ list_del_init(head->next);
+
+ scb->state = SCB_ACTIVE;
+ scb->cmd = cmd;
+ scb->dma_type = MEGA_DMA_TYPE_NONE;
+
+ return scb;
+ }
+
+ return NULL;
+}
+
+
+/**
+ * mega_get_ldrv_num()
+ * @adapter - pointer to our soft state
+ * @cmd - scsi mid layer command
+ * @channel - channel on the controller
+ *
+ * Calculate the logical drive number based on the information in scsi command
+ * and the channel number.
+ */
+static inline int
+mega_get_ldrv_num(adapter_t *adapter, Scsi_Cmnd *cmd, int channel)
+{
+ int tgt;
+ int ldrv_num;
+
+ tgt = cmd->target;
+
+ if ( tgt > adapter->this_id )
+ tgt--; /* we do not get inquires for initiator id */
+
+ ldrv_num = (channel * 15) + tgt;
+
+
+ /*
+* If we have a logical drive with boot ena
Re: [PATCH] Prevent NMI oopser
On Wed, Feb 02, 2005 at 10:32:28PM +0300, Vasily Averin wrote: > >As a hack, one could #define inline /*nothing*/ in megaraid2.h to > >avoid this, but it would be nice if the functions could all get > >reordered such that inlining works properly, and the need for function > >declarations in megaraid2.h would disappear completely. > > > Could you fix it by additional patch? Or you going to prepare a new one? Here's the hack patch (will apply after yours). Signed-off-by: Matt Domsch <[EMAIL PROTECTED]> -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com = drivers/scsi/megaraid2.h 1.6 vs edited = --- 1.6/drivers/scsi/megaraid2.h2005-02-02 13:48:22 -06:00 +++ edited/drivers/scsi/megaraid2.h 2005-02-02 13:55:42 -06:00 @@ -5,6 +5,18 @@ #include +/* This is an ugly hack, but gets around the fact that earlier + * versions of gcc ignores the inline specification when + * the function definition comes after function use (thereby + * not inlining the code), and newer gcc fails to compile the + * code. This should be removed once the functions are properly + * ordered in megaraid2.c, and the function declarations removed + * in megaraid2.h. + */ +#undef inline +#define inline /*nothing*/ + + #define MEGARAID_VERSION \ "v2.10.8.2 (Release Date: Mon Jul 26 12:15:51 EDT 2004)\n" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent NMI oopser
Matt Domsch wrote: On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote: This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible version that I've seen), taken from latest RHEL3 kernel update. I believe it should prevent NMI in abort/reset handler. Thanks Vasily, I was just looking at this again yesterday. You'll also find that because the driver doesn't define its inline functions prior to their use, newest compilers refuse to compile this version of the driver. Earlier compilers just ignore it and don't inline anything. As a hack, one could #define inline /*nothing*/ in megaraid2.h to avoid this, but it would be nice if the functions could all get reordered such that inlining works properly, and the need for function declarations in megaraid2.h would disappear completely. Could you fix it by additional fix? Or you going to release new driver version for 2.4 kernels? Thank you, Vasily Averin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent NMI oopser
Hello Matt Matt Domsch wrote: On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote: This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible version that I've seen), taken from latest RHEL3 kernel update. I believe it should prevent NMI in abort/reset handler. Thanks Vasily, I was just looking at this again yesterday. You'll also find that because the driver doesn't define its inline functions prior to their use, newest compilers refuse to compile this version of the driver. Earlier compilers just ignore it and don't inline anything. As a hack, one could #define inline /*nothing*/ in megaraid2.h to avoid this, but it would be nice if the functions could all get reordered such that inlining works properly, and the need for function declarations in megaraid2.h would disappear completely. Could you fix it by additional patch? Or do you going to prepare a new one? Thank you, Vasily Averin, SWSoft Linux Kernel Team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent NMI oopser
Hello Matt Matt Domsch wrote: On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote: Marcelo, This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible version that I've seen), taken from latest RHEL3 kernel update. I believe it should prevent NMI in abort/reset handler. Thanks Vasily, I was just looking at this again yesterday. You'll also find that because the driver doesn't define its inline functions prior to their use, newest compilers refuse to compile this version of the driver. Earlier compilers just ignore it and don't inline anything. As a hack, one could #define inline /*nothing*/ in megaraid2.h to avoid this, but it would be nice if the functions could all get reordered such that inlining works properly, and the need for function declarations in megaraid2.h would disappear completely. Could you fix it by additional patch? Or you going to prepare a new one? Thank you, Vasily Averin, SWSoft Linux Kernel Team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent NMI oopser
Hi Vasily Averin! On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote next: > Marcelo Tosatti wrote: > >On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote: > >>You should unlock io_request_lock before msleep, like in latest versions > >>of megaraid2 drivers. > > > >Andrey, > > > >Can you please update your patch to unlock io_request_lock before sleeping > >and locking after coming back? > > > >What the driver is doing is indeed wrong. > > Marcelo, > > This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible > version that I've seen), Where ? Last version (i see announce + patch from 2.10.3) is 2.10.6. > taken from latest RHEL3 kernel update. I believe it should prevent NMI > in abort/reset handler. Thnx for patch, I try it on my server at next week. -- Best regards, TEMHOTA-RIPN aka MJA13-RIPE System Administrator. mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent NMI oopser
On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote: > Marcelo Tosatti wrote: > >On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote: > >>You should unlock io_request_lock before msleep, like in latest versions > >>of megaraid2 drivers. > > > >Andrey, > > > >Can you please update your patch to unlock io_request_lock before sleeping > >and locking after coming back? > > > >What the driver is doing is indeed wrong. > > Marcelo, > > This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible > version that I've seen), taken from latest RHEL3 kernel update. I > believe it should prevent NMI in abort/reset handler. > > Thank you, > Vasily Averin, SWSoft Linux Kernel Team Thanks Vasily, I was just looking at this again yesterday. You'll also find that because the driver doesn't define its inline functions prior to their use, newest compilers refuse to compile this version of the driver. Earlier compilers just ignore it and don't inline anything. As a hack, one could #define inline /*nothing*/ in megaraid2.h to avoid this, but it would be nice if the functions could all get reordered such that inlining works properly, and the need for function declarations in megaraid2.h would disappear completely. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent NMI oopser
Marcelo Tosatti wrote:
On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote:
You should unlock io_request_lock before msleep, like in latest versions
of megaraid2 drivers.
Andrey,
Can you please update your patch to unlock io_request_lock before sleeping
and locking after coming back?
What the driver is doing is indeed wrong.
Marcelo,
This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible
version that I've seen), taken from latest RHEL3 kernel update. I
believe it should prevent NMI in abort/reset handler.
Thank you,
Vasily Averin, SWSoft Linux Kernel Team
--- ./drivers/scsi/megaraid2.c.mr2 Wed Feb 2 08:27:13 2005
+++ ./drivers/scsi/megaraid2.c Wed Feb 2 10:28:52 2005
@@ -14,7 +14,7 @@
* - speed-ups (list handling fixes, issued_list, optimizations.)
* - lots of cleanups.
*
- * Version : v2.10.3 (Apr 08, 2004)
+ * Version : v2.10.8.2 (July 26, 2004)
*
* Authors:Atul Mukker <[EMAIL PROTECTED]>
* Sreenivas Bagalkote <[EMAIL PROTECTED]>
@@ -46,7 +46,7 @@
#include "megaraid2.h"
-#ifdef LSI_CONFIG_COMPAT
+#if defined(__x86_64__)
#include
#endif
@@ -90,10 +90,15 @@ static struct notifier_block mega_notifi
static struct mega_hbas mega_hbas[MAX_CONTROLLERS];
/*
+ * Lock to protect access to IOCTL
+ */
+static struct semaphore megaraid_ioc_mtx;
+
+/*
* The File Operations structure for the serial/ioctl interface of the driver
*/
static struct file_operations megadev_fops = {
- .ioctl = megadev_ioctl,
+ .ioctl = megadev_ioctl_entry,
.open = megadev_open,
.release= megadev_close,
.owner = THIS_MODULE,
@@ -107,7 +112,7 @@ static struct file_operations megadev_fo
static struct mcontroller mcontroller[MAX_CONTROLLERS];
/* The current driver version */
-static u32 driver_ver = 0x0210;
+static u32 driver_ver = 0x02104000;
/* major number used by the device for character interface */
static int major;
@@ -189,6 +194,11 @@ megaraid_detect(Scsi_Host_Template *host
*/
mega_reorder_hosts();
+ /*
+* Initialize the IOCTL lock
+*/
+ init_MUTEX( &megaraid_ioc_mtx );
+
#ifdef CONFIG_PROC_FS
mega_proc_dir_entry = proc_mkdir("megaraid", &proc_root);
@@ -223,7 +233,7 @@ megaraid_detect(Scsi_Host_Template *host
"MegaRAID Shutdown routine not registered!!\n");
}
-#ifdef LSI_CONFIG_COMPAT
+#if defined(__x86_64__)
/*
* Register the 32-bit ioctl conversion
*/
@@ -273,6 +283,8 @@ mega_find_card(Scsi_Host_Template *host_
unsigned long tbase;
unsigned long flag = 0;
int i, j;
+ u8 did_int_pthru_f = 0;
+ u8 did_int_data_f = 0;
while((pdev = pci_find_device(pci_vendor, pci_device, pdev))) {
@@ -328,6 +340,7 @@ mega_find_card(Scsi_Host_Template *host_
(subsysvid != HP_SUBSYS_VID) &&
(subsysvid != INTEL_SUBSYS_VID) &&
(subsysvid != FSC_SUBSYS_VID) &&
+ (subsysvid != ACER_SUBSYS_VID) &&
(subsysvid != LSI_SUBSYS_VID) ) continue;
@@ -465,6 +478,33 @@ mega_find_card(Scsi_Host_Template *host_
alloc_scb_f = 1;
+ /*
+* Allocate memory for ioctls
+*/
+ adapter->int_pthru = pci_alloc_consistent (
+ adapter->dev,
+ sizeof(mega_passthru),
+ &adapter->int_pthru_dma_hndl );
+
+ if( adapter->int_pthru == NULL ) {
+ printk(KERN_WARNING "megaraid: out of RAM.\n");
+ goto fail_attach;
+ }
+ else
+ did_int_pthru_f = 1;
+
+ adapter->int_data = pci_alloc_consistent (
+ adapter->dev,
+ INT_MEMBLK_SZ,
+ &adapter->int_data_dma_hndl );
+
+ if( adapter->int_data == NULL ) {
+ printk(KERN_WARNING "megaraid: out of RAM.\n");
+ goto fail_attach;
+ }
+ else
+ did_int_data_f = 1;
+
/* Request our IRQ */
if( adapter->flag & BOARD_MEMMAP ) {
if(request_irq(irq, megaraid_isr_memmapped, SA_SHIRQ,
@@ -676,6 +716,19 @@ mega_find_card(Scsi_Host_Template *host_
continue;
fail_attach:
+ if( did_int_data_f ) {
+ pci_free_consistent(
+ adapter->dev, INT_MEMBLK_SZ, adapter->int_data,
+
Re: [PATCH] Prevent NMI oopser
On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote: > cc: Andrey Melnikov <[EMAIL PROTECTED]> > cc: linux-kernel@vger.kernel.org > > Marcello, Andrey > > I believe this patch is wrong. > First, it prevent nothing: NMI watchdog is a signal that you wait too > long with disabled interrupts. Your controller was not answered too > long, obviously it is a hardware issue. > Second, you could not call schedule() with io_request_lock spinlock taken. > > You should unlock io_request_lock before msleep, like in latest versions > of megaraid2 drivers. > > Please fix it. Andrey, Can you please update your patch to unlock io_request_lock before sleeping and locking after coming back? What the driver is doing is indeed wrong. Thank you. Is there anybody out there at LSI? > Thank you, > Vasily Averin, SWSoft Linux Kernel Team > > # ChangeSet > # 2005/01/19 14:16:32-02:00 [EMAIL PROTECTED] > # [PATCH] Prevent NMI oopser from triggering when megaraid2 waits > # for abort/reset cmd completion > # > # > We should backport msleep() in 2.4.29-pre1. > # > # Ok, msleep() backported, but driver isn't fixed. This patch > # acceptable? > # > # Prevent NMI oopser kill kernel thread when megaraid2 driver waiting > # abort or reset command completion. > # > # Signed-off-by: Andrey Melnikov <[EMAIL PROTECTED]> > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent NMI oopser
On Tue, Jan 25, 2005 at 10:47:24AM +0300, Vasily Averin wrote: > Marcello, Andrey > > I believe this patch is wrong. > First, it prevent nothing: NMI watchdog is a signal that you wait too > long with disabled interrupts. Your controller was not answered too > long, obviously it is a hardware issue. > Second, you could not call schedule() with io_request_lock spinlock taken. > > You should unlock io_request_lock before msleep, like in latest versions > of megaraid2 drivers. > > Please fix it. OK, I've reverted it for now - waiting for megaraid2 update from LSI crew. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
