All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc: Xose Vazquez Perez <xose@wanadoo.es>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Tosatti <marcelo.tosatti@cyclades.com>,
	linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: AIC7xxx kernel problem with 2.4.2[234] kernels
Date: 22 Jan 2004 00:14:09 -0500	[thread overview]
Message-ID: <1074748451.2124.78.camel@mulgrave> (raw)
In-Reply-To: <4022195408.1074577421@aslan.btc.adaptec.com>

On Tue, 2004-01-20 at 00:43, Justin T. Gibbs wrote: 
> As for control, the type of control "I seek" does exist.  You have it.
> You can also delegate some of that control if it suits you.

Well, as you have heard from the horse's mouth: I don't. 

> I provided all of the information required for you to make a reasoned
> decision of which change sets to integrate.  I had no idea that you
> would completely disregard the wealth of information in the change sets
> and change set comments when coming up with an integration point.  Your
> actions show that you didn't review or understand the changes well enough
> to submit them into the tree.  You probably didn't even test the resulting
> driver on real hardware before you submitted the changes.

Actually, I would have done nothing but for some 2.6 migration reports
of total lockups with the then in tree aic79xx driver.  The patch that
went into the tree was tested by the people reporting the lockups. 

> > The recovery code does work.  You may want it to work differently, and
> > that may make it work better, but that's an enhancement not a bug fix.
> 
> No.  The recovery code doesn't work.  Many of the people that know this
> don't bother complaining to you about it.  They complain to the HBA driver
> authors and the tech support departments of the companies that make the HBAs.
> The HBA driver authors then do what they have to ensure that the system
> remains viable after recovery.  

You haven't outlined any incorrect cases in your emails, just could do
better cases.  If you have all these bug reports that you haven't been
passing on, could you at least distil them to the mid layer failure
scenario that we can discuss fixing? 

> I mean honestly.  Do you think I would have gone to all of the trouble
> I did in doing my own watchdog recovery if the recovery code worked
> correctly?  Or that I would stand so firm in my position if these issues
> didn't have real customer impact?

Well, in coming up with the mid layer changes from 2.4 to 2.6 I did look
at what issues the main drivers had work arounds for. I used these work
arounds and an email you sent in September 2002 as the basis for a lot
of the mid-layer changes in 2.6.  None of the other drivers does this
timer interception and the issue wasn't mentioned in your email, so I am
dubious about the seriousness of the impact.

The way fixes get into linux is either lots of people complain, or one
person sends a fix, neither has happened in this case, which again leads
me to suspect that it's not a huge problem.

The still outstanding question is, now that you have a clearer idea what
being a Maintainer entails, do you wish to be the maintainer for
aic7xxx?

James



  reply	other threads:[~2004-01-22  5:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-19 13:32 AIC7xxx kernel problem with 2.4.2[234] kernels Xose Vazquez Perez
2004-01-19 17:21 ` James Bottomley
2004-01-19 18:38   ` Justin T. Gibbs
2004-01-20  0:50     ` James Bottomley
2004-01-20  2:02       ` Justin T. Gibbs
2004-01-20  4:45         ` James Bottomley
2004-01-20  5:43           ` Justin T. Gibbs
2004-01-22  5:14             ` James Bottomley [this message]
2004-01-20 11:24           ` Chiaki
2004-01-20  7:15         ` Linus Torvalds
2004-01-20  8:30           ` Andre Hedrick
2004-01-21 20:37           ` Guennadi Liakhovetski
  -- strict thread matches above, loose matches on Subject: below --
2004-01-16 21:43 Stephen Smoogen
2004-01-16 22:39 ` Justin T. Gibbs
2004-01-16 22:59   ` Stephen Smoogen
2004-01-21 19:59     ` Stephen Smoogen
2004-02-18 19:42       ` Stephen Smoogen
2004-01-16 23:17   ` Marcelo Tosatti
2004-01-18  1:11   ` Marcelo Tosatti

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=1074748451.2124.78.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=gibbs@scsiguy.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=marcelo.tosatti@cyclades.com \
    --cc=xose@wanadoo.es \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.