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 (was: [MAILER-DAEMON@rumms.u

[Chuck Ebbert]

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


 I was wondering about that too.

 How can a major code restructure be done in tiny pieces?  I don't
think it can.


--
 Chuck
 I am not an octal number!

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

[carbonated beverage]

Hi,

On Wed, Apr 09, 2003 at 06:10:02PM -0400, Chuck Ebbert wrote:
>  How can a major code restructure be done in tiny pieces?  I don't
> think it can.

You might want to tell that to Al Viro. ;-)

-- DN
Daniel