From: Ben Collins Date: Mon, 11 Jun 2012 18:44:44 +0000 (-0400) Subject: [SCSI] aacraid: Relax the tight timeout loop on fib commands X-Git-Tag: v3.6-rc1~103^2~47 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=30002f1c02ada69342443e7ed5ee9118feb89510;p=profile%2Fivi%2Fkernel-x86-ivi.git [SCSI] aacraid: Relax the tight timeout loop on fib commands The loop that waited for syncronous fib commands was causing a CPU stall when a timeout actually occured. 1) Switch to using a more accurate timeout mechanism. 2) Do not pace the loop with udelay(). Use cpu_relax() to allow for scheduling to occur. Signed-off-by: Ben Collins Acked-by: Achim Leubner Signed-off-by: James Bottomley --- diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c index 4b32ca4..906a501 100644 --- a/drivers/scsi/aacraid/commsup.c +++ b/drivers/scsi/aacraid/commsup.c @@ -564,10 +564,10 @@ int aac_fib_send(u16 command, struct fib *fibptr, unsigned long size, * functioning because an interrupt routing or other * hardware failure has occurred. */ - unsigned long count = 36000000L; /* 3 minutes */ + unsigned long timeout = jiffies + (180 * HZ); /* 3 minutes */ while (down_trylock(&fibptr->event_wait)) { int blink; - if (--count == 0) { + if (time_is_before_eq_jiffies(timeout)) { struct aac_queue * q = &dev->queues->queue[AdapNormCmdQueue]; spin_lock_irqsave(q->lock, qflags); q->numpending--; @@ -588,7 +588,10 @@ int aac_fib_send(u16 command, struct fib *fibptr, unsigned long size, } return -EFAULT; } - udelay(5); + /* We used to udelay() here but that absorbed + * a CPU when a timeout occured. Not very + * useful. */ + cpu_relax(); } } else if (down_interruptible(&fibptr->event_wait)) { /* Do nothing ... satisfy