lkml.org 
[lkml]   [2009]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [GIT PULL] block bits for 2.6.29-rc5
Jens wrote:

> > > Perhaps we should shrink it to something a little more
> tolerable and
> > > put it in the noop loop instead. 30 seconds is insane...
> >
> > Some of these controllers do take a long time to recover from the
> > reset because the firmware has to re-initialize. The firmware guys
> > claim that's only a few seconds but that's not true.
> >
> > Granted, the 5i is old as dirt. Don't know how many are still out
> > there running newer kernels.
>
> So a small improvement would be to do that delay only for 5i.
> Or how about just being a little more relaxed, ala the below?
> It's still 30 seconds in total, but that's now worst case.
> Will the 5i crap itself if we attempt to talk to it too soon?
>
> diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
> index d2cb67b..b5a0611 100644
> --- a/drivers/block/cciss.c
> +++ b/drivers/block/cciss.c
> @@ -3611,11 +3611,15 @@ static int __devinit
> cciss_init_one(struct pci_dev *pdev,
> schedule_timeout_uninterruptible(30*HZ);
>
> /* Now try to get the controller to respond to
> a no-op */
> - for (i=0; i<12; i++) {
> + for (i=0; i<30; i++) {
> if (cciss_noop(pdev) == 0)
> break;
> - else
> - printk("cciss: no-op
> failed%s\n", (i < 11 ? "; re-trying" : ""));
> +
> + schedule_timeout_uninterruptible(HZ);
> + }
> + if (i == 30) {
> + printk(KERN_ERR "cciss: controller
> seems dead\n");
> + return -EBUSY;
> }
> }

The controller won't crap the bed, it will just ignore any requests until it becomes ready. I don't see any problem with this change.

Reviewed-by: Mike Miller <mike.miller@hp.com>

-- mikem

\
 
 \ /
  Last update: 2009-02-20 19:55    [W:2.023 / U:1.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site