Re: [PATCH] aic7* claims all checked EISA io ranges (was: [MAILER-DAEMON@rumms.u

Re: [PATCH] aic7* claims all checked EISA io ranges (was: [MAILER-DAEMON@rumms.u

[Chuck Ebbert]

Justin T. Gibbs wrote:


>As far as the 2.4.X series is concerned, pushing has not helped.  I've
>seen spelling fixes and incorrorct changes get accepted from non
>maintainers "instantly", while the maintainers changes are not accepted.


And your code goes for long periods of time without merging good fixes,
like this one (from 2.4.20):


--- aic7-20030310/drivers/scsi/aic7xxx/aic7770.c.orig	Mon Mar 10 20:46:36 2003
+++ aic7-20030310/drivers/scsi/aic7xxx/aic7770.c	Tue Apr  8 20:45:20 2003
@ -314,7 +314,7 @
 	if (bootverbose)
 		printf("%s: Reading SEEPROM...", ahc_name(ahc));
 	have_seeprom = ahc_read_seeprom(&sd, (uint16_t *)sc,
-					/*start_addr*/0, sizeof(sc)/2);
+					/*start_addr*/0, sizeof(*sc)/2);
 
 	if (have_seeprom) {
 


--
 Chuck
 Can't we all just get along?

Re: [PATCH] aic7* claims all checked EISA io ranges (was: [MAILER-DAEMON@rumms.u

[Justin T. Gibbs]

> And your code goes for long periods of time without merging good fixes,
> like this one (from 2.4.20):

If I were aware of this bug, it would have been merged.  Unfortunately,
the Linux model where maintainers are not consulted before changes are
accepted leads to good changes getting missed and bad changes get accepted.

--
Justin

Re: [PATCH] aic7* claims all checked EISA io ranges (was: [MAILER-DAEMON@rumms.u

[Alan Cox]

On Mer, 2003-04-09 at 02:21, Chuck Ebbert wrote:
> And your code goes for long periods of time without merging good fixes,
> like this one (from 2.4.20):

Which is one reason Justin's patches don't get merged. They are giant
changes which back out other clear corrections.

Re: [PATCH] aic7* claims all checked EISA io ranges (was: [MAILER-DAEMON@rumms.u

[Justin T. Gibbs]

> On Mer, 2003-04-09 at 02:21, Chuck Ebbert wrote:
>> And your code goes for long periods of time without merging good fixes,
>> like this one (from 2.4.20):
> 
> Which is one reason Justin's patches don't get merged. They are giant
> changes which back out other clear corrections.

This tells me two things:

1) You don't trust maintainers.  If a maintainer can't make large changes,
   who can?

2) When a maintainer makes a mistake (fails to integrate a good change,
   or introduces a bug), the maintainers changes are simply dropped rather
   then notify (either politely or not I don't much care) the maintainer
   of his/her mistake.

Neither of the above applied to integration of the aic79xx driver into
the 2.4.X tree, but it still took something like 8 months.

There must be a better way.

--
Justin

Re: [PATCH] aic7* claims all checked EISA io ranges

[Stephan von Krawczynski]

On Wed, 09 Apr 2003 11:34:01 -0600
"Justin T. Gibbs" <gibbs@scsiguy.com> wrote:

> > On Mer, 2003-04-09 at 02:21, Chuck Ebbert wrote:
> >> And your code goes for long periods of time without merging good fixes,
> >> like this one (from 2.4.20):
> > 
> > Which is one reason Justin's patches don't get merged. They are giant
> > changes which back out other clear corrections.
> 
> This tells me two things:
> 
> 1) You don't trust maintainers.  If a maintainer can't make large changes,
>    who can?
> 
> 2) When a maintainer makes a mistake (fails to integrate a good change,
>    or introduces a bug), the maintainers changes are simply dropped rather
>    then notify (either politely or not I don't much care) the maintainer
>    of his/her mistake.
> 
> Neither of the above applied to integration of the aic79xx driver into
> the 2.4.X tree, but it still took something like 8 months.
> 
> There must be a better way.

As I am probably one of the victims of these differing opinions, can anyone
tell me where to get a really-known-to-work aic-driver for 2.4? I am
experiencing zapping-black events while reading from a SDLT drive (writing to
it does fine).

Short hardware story:
02:03.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)
02:03.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01)

Host: scsi0 Channel: 00 Id: 08 Lun: 00
  Vendor: IBM      Model: IC35L073UWDY10-0 Rev: S21E
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 02 Lun: 00
  Vendor: QUANTUM  Model: SDLT320          Rev: 3838
  Type:   Sequential-Access                ANSI SCSI revision: 02

Any hints welcome

Regards,
Stephan

Re: [PATCH] aic7* claims all checked EISA io ranges

[Justin T. Gibbs]

> As I am probably one of the victims of these differing opinions, can anyone
> tell me where to get a really-known-to-work aic-driver for 2.4? I am
> experiencing zapping-black events while reading from a SDLT drive (writing to
> it does fine).

The best way to get to a resolution on aic7xxx issues is to use the
drivers from here:

http://people.FreeBSD.org/~gibbs/linux/SRC/

And provide as much information about the problem as you can.  In this
case, I'm at a loss for what a "zapping-black event" is.

--
Justin

Re: [PATCH] aic7* claims all checked EISA io ranges

[Stephan von Krawczynski]

On Thu, 10 Apr 2003 10:44:50 -0600
"Justin T. Gibbs" <gibbs@scsiguy.com> wrote:

> > As I am probably one of the victims of these differing opinions, can anyone
> > tell me where to get a really-known-to-work aic-driver for 2.4? I am
> > experiencing zapping-black events while reading from a SDLT drive (writing
> > to it does fine).
> 
> The best way to get to a resolution on aic7xxx issues is to use the
> drivers from here:
> 
> http://people.FreeBSD.org/~gibbs/linux/SRC/
> 
> And provide as much information about the problem as you can.  In this
> case, I'm at a loss for what a "zapping-black event" is.

Thank you for pointing to the URL.

OK, the error description was a bit flaky :-), I simply meant the box freezes
and the  screen turns black - no oops, no nothing.
This occurs while reading back about 70 GB of data from an SDLT. _Writing_ this
data (which is done just before verify-reading it) seems no problem.

-- 
Regards,
Stephan

Re: [PATCH] aic7* claims all checked EISA io ranges

[Stephan von Krawczynski]

On Thu, 10 Apr 2003 10:44:50 -0600
"Justin T. Gibbs" <gibbs@scsiguy.com> wrote:

> > As I am probably one of the victims of these differing opinions, can anyone
> > tell me where to get a really-known-to-work aic-driver for 2.4? I am
> > experiencing zapping-black events while reading from a SDLT drive (writing
> > to it does fine).
> 
> The best way to get to a resolution on aic7xxx issues is to use the
> drivers from here:
> 
> http://people.FreeBSD.org/~gibbs/linux/SRC/

Ok, I tried this one on top of 2.4.21-pre6 (can't compile -pre7) and had to
find out, that it freezes on X startup. I have never experienced something like
that before.
Anything I can do/test? There is no oops, just freeze (screen does not turn
black, kdm freezes in the middle of the startup, displays window borders but no
images).

-- 
Regards,
Stephan

Re: [PATCH] aic7* claims all checked EISA io ranges

[James Bottomley]

On Tue, 2003-04-08 at 18:12, Justin T. Gibbs wrote:
> > I take it 2.5 is up to date, right?  Because otherwise we should have
> > seen an update notice go across linux-scsi@vger.kernel.org.
> 
> In the past, I have sent mail directly to Linus which has worked for 2.5.
> Unfortunately, it looks like he has not applied the last bundle I posted
> to him on 2003/03/25.  This is the same bk output as posted on my website.

Well, the aic7xxx is part of SCSI, and SCSI has an active BK tree for
accumulating patches and pushing them to Linus.  If you want to
circumvent this, then patches will get lost sometimes.

The way to avoid this is to send patches to linux-scsi@vger.kernel.org.

> > This problem looks to be present in 2.5, so should I apply the patch?
> 
> It would be better to just upgrade the driver with bits I submitted to
> Linus.  I have another update coming to correctly fix the del_timer_sync()
> issue since the last, unsanctioned, change in this area has a large potential
> to cause a deadlock.

I'll see if I can pull them.

James

Re: [PATCH] aic7* claims all checked EISA io ranges

[Justin T. Gibbs]

> I take it 2.5 is up to date, right?  Because otherwise we should have
> seen an update notice go across linux-scsi@vger.kernel.org.

In the past, I have sent mail directly to Linus which has worked for 2.5.
Unfortunately, it looks like he has not applied the last bundle I posted
to him on 2003/03/25.  This is the same bk output as posted on my website.

> This problem looks to be present in 2.5, so should I apply the patch?

It would be better to just upgrade the driver with bits I submitted to
Linus.  I have another update coming to correctly fix the del_timer_sync()
issue since the last, unsanctioned, change in this area has a large potential
to cause a deadlock.

--
Justin

Re: [PATCH] aic7* claims all checked EISA io ranges

[James Bottomley]

> As far as the 2.4.X series is concerned, pushing has not helped.  I've
> seen spelling fixes and incorrorct changes get accepted from non
> maintainers "instantly", while the maintainers changes are not
accepted.
> Considering how long it took for the last set of driver changes to
make
> it from -ac into kernel.org, I just assumed that this strategy was
> also failing.  Is that really the only way to get updates into
Marcelo's
> tree?

I take it 2.5 is up to date, right?  Because otherwise we should have
seen an update notice go across linux-scsi@vger.kernel.org.

This problem looks to be present in 2.5, so should I apply the patch?

James