Skip to contentSkip to conversation

aic7* claims all checked EISA io ranges (was: [[email protected]

PATCH Chuck Ebbert 4 participants 8 messages Apr 9, 2003 – Apr 11, 2003

lore
Share & tools
lore
#0 lore raw
Quoted 3 lines · Justin T. Gibbs

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?

#1 lore raw
Quoted 2 lines

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

#2 lore raw
In reply to Chuck Ebbert
Quoted 2 lines · Chuck Ebbert

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.

#3 lore raw
Quoted 6 lines · Chuck Ebbert
Quoted 2 lines

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

#4 lore raw

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

Quoted 17 lines · On Wed, 09 Apr 2003 11:34:01 -0600 "Justin T. Gibbs" <[email protected]> wrote:
Quoted 6 lines · Chuck Ebbert
Quoted 2 lines

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.

Quoted 4 lines

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

#5 lore raw

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

Quoted 4 lines

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

#6 lore raw

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

Quoted 5 lines · On Thu, 10 Apr 2003 10:44:50 -0600 "Justin T. Gibbs" <[email protected]> wrote:
Quoted 4 lines

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).

Quoted 7 lines

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.

Signature · 2 lines
Regards,
Stephan
#7 lore raw

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

In reply to Justin T. Gibbs
Quoted 9 lines · On Thu, 10 Apr 2003 10:44:50 -0600 "Justin T. Gibbs" <[email protected]> wrote:
Quoted 4 lines

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).

Signature · 2 lines
Regards,
Stephan