public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Brian King <brking@us.ibm.com>
Cc: James.Bottomley@steeleye.com, gibbs@scsiguy.com,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH] allow drivers to hook into watchdog timeout
Date: Tue, 20 Jan 2004 18:06:56 +0000	[thread overview]
Message-ID: <20040120180656.B18616@infradead.org> (raw)
In-Reply-To: <400D5E9F.8030802@us.ibm.com>; from brking@us.ibm.com on Tue, Jan 20, 2004 at 11:00:15AM -0600

On Tue, Jan 20, 2004 at 11:00:15AM -0600, Brian King wrote:
> If we get rid of scsi_add_timer, could we have a scsi_mod_timer? In the 
> ipr driver I submitted, I would like to be able to simply double the 
> timeout value, I don't necessarily want to change the timeout policy. 
> The adapter firmware is already timing each command, so I would like to 
> use that as the primary timing mechanism if possible.
> 
> For normal SCSI devices under this adapter I could change the philosophy 
> and not let the adapter time the commands, but for disk array devices, 
> the timeout value for reads/writes is too short.

messing with the timer after it's setup sounds like the wrong way to do
that to me.  Overriding the timeout in the host template or the device
sounds like the better idea.  Given that there seem to be other adapters
that need longer timeouts, I wonder whether we should look for a generic
solution to this

> 
> 
> -- 
> Brian King
> eServer Storage I/O
> IBM Linux Technology Center
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
---end quoted text---

-- 
Christoph Hellwig <hch@lst.de>		-	Freelance Hacker
Contact me for driver hacking and kernel development consulting

  reply	other threads:[~2004-01-20 18:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-20 13:20 [PATCH] allow drivers to hook into watchdog timeout Christoph Hellwig
2004-01-20 15:53 ` Mike Anderson
2004-01-20 16:00   ` Christoph Hellwig
2004-01-20 16:47     ` Mike Anderson
2004-01-22 13:59       ` Christoph Hellwig
2004-01-22 14:27         ` Justin T. Gibbs
2004-01-20 17:00 ` Brian King
2004-01-20 18:06   ` Christoph Hellwig [this message]
2004-02-10 16:34 ` Justin T. Gibbs
2004-02-10 16:42   ` James Bottomley
2004-02-10 17:47     ` Justin T. Gibbs
2004-02-10 18:41       ` James Bottomley
2004-02-10 19:44         ` Justin T. Gibbs
2004-02-10 20:05           ` James Bottomley
2004-02-10 20:26             ` Justin T. Gibbs
2004-02-10 22:47               ` Clay Haapala
2004-02-11 20:05               ` James Bottomley
2004-02-12  0:15                 ` Justin T. Gibbs
2004-02-12 14:42                   ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040120180656.B18616@infradead.org \
    --to=hch@infradead.org \
    --cc=James.Bottomley@steeleye.com \
    --cc=brking@us.ibm.com \
    --cc=gibbs@scsiguy.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox