[PATCH] aic7xxx bouncing over 4G

[PATCH] aic7xxx bouncing over 4G

[Janet Morgan]

I have an Adaptec AIC-7897 Ultra2 SCSI adapter on a system with 8G
of physical memory.  The adapter is using bounce buffers when DMA'ing
to memory >4G because of a bug in the aic7xxx driver. 

The problem is ahc_linux_get_memsize() returns an erroneous memory size 
(i.e., shifts out the high-order bits) for configurations >4G and the 
wrong dma mask is set by the caller.   The following patch fixes the problem 
by adding the needed cast.


--- linux-2.5.52/drivers/scsi/aic7xxx/aic7xxx_linux.c	Sun Dec 15 18:07:54 2002
+++ nobounce/drivers/scsi/aic7xxx/aic7xxx_linux.c	Fri Dec 20 16:08:11 2002
@@ -1156,7 +1156,7 @@
 	struct sysinfo si;
 
 	si_meminfo(&si);
-	return (si.totalram << PAGE_SHIFT);
+	return ((uint64_t)si.totalram << PAGE_SHIFT);
 }
 
 /*

Re: [PATCH] aic7xxx bouncing over 4G

[Justin T. Gibbs]

> I have an Adaptec AIC-7897 Ultra2 SCSI adapter on a system with 8G
> of physical memory.  The adapter is using bounce buffers when DMA'ing
> to memory >4G because of a bug in the aic7xxx driver. 

This has been fixed in both the aic7xxx and aic79xx drivers for some
time.  The problem is that these later revisions have not been integrated
into the mainline trees.

--
Justin

Re: [PATCH] aic7xxx bouncing over 4G

[William Lee Irwin III]

At some point in the past, Janet Morgan had her attribution removed:
>> I have an Adaptec AIC-7897 Ultra2 SCSI adapter on a system with 8G
>> of physical memory.  The adapter is using bounce buffers when DMA'ing
>> to memory >4G because of a bug in the aic7xxx driver. 

On Fri, Dec 20, 2002 at 05:23:42PM -0700, Justin T. Gibbs wrote:
> This has been fixed in both the aic7xxx and aic79xx drivers for some
> time.  The problem is that these later revisions have not been integrated
> into the mainline trees.

Could you split up the new revisions into a series of reviewable
patches with clearly-defined individual scope and descriptive changelog
entries and post them (in your mail message, not as URL's) please? I
actually use this driver at home, so I'd like to be able to understand
what's going on with it. I suspect various others are of like mind.


Thanks,
Bill

Re: [PATCH] aic7xxx bouncing over 4G

[Justin T. Gibbs]

> At some point in the past, Janet Morgan had her attribution removed:
>>> I have an Adaptec AIC-7897 Ultra2 SCSI adapter on a system with 8G
>>> of physical memory.  The adapter is using bounce buffers when DMA'ing
>>> to memory >4G because of a bug in the aic7xxx driver. 
> 
> On Fri, Dec 20, 2002 at 05:23:42PM -0700, Justin T. Gibbs wrote:
>> This has been fixed in both the aic7xxx and aic79xx drivers for some
>> time.  The problem is that these later revisions have not been integrated
>> into the mainline trees.
> 
> Could you split up the new revisions into a series of reviewable
> patches with clearly-defined individual scope and descriptive changelog
> entries and post them (in your mail message, not as URL's) please? I
> actually use this driver at home, so I'd like to be able to understand
> what's going on with it. I suspect various others are of like mind.
> 
> 
> Thanks,
> Bill

You can review all of that information by browsing the BK depot at:

http://linux-scsi.bkbits.net:8080/scsi-aic7xxx-2.5

Since the drivers in 2.4 and 2.5 are almost identical, the changelogs
there apply for 2.4.X too.

Re: [PATCH] aic7xxx bouncing over 4G

[William Lee Irwin III]

At some point in the past, my attribution was removed:
>> Could you split up the new revisions into a series of reviewable
>> patches with clearly-defined individual scope and descriptive changelog
>> entries and post them (in your mail message, not as URL's) please? I
>> actually use this driver at home, so I'd like to be able to understand
>> what's going on with it. I suspect various others are of like mind.

On Fri, Dec 20, 2002 at 05:59:10PM -0700, Justin T. Gibbs wrote:
> You can review all of that information by browsing the BK depot at:
> http://linux-scsi.bkbits.net:8080/scsi-aic7xxx-2.5
> Since the drivers in 2.4 and 2.5 are almost identical, the changelogs
> there apply for 2.4.X too.

This is not in a remotely digestible form.
(1) the entire universe's changesets are mixed together
(2) PITA, I filter for "gibbs", I see a changelog entry that says this:
   Changeset details for 1.865.1.4

   ChangeSet@1.865.1.4  2002-12-12 13:45:46-07:00  gibbs@adaptec.com
   all diffs
   o Kill host template files.
   o Move readme files into the Documentation SCSI directory
   o Enable highmem_io
   o Split out Kconfig files for aic7xxx and aic79xx
   Host template and large disk changes provided or inspired by:
           Christoph Hellwig <hch@sgi.com>

This is one cset??? These are -very- unrelated changes.

So I narrow it down to one file inside there:

   Changes for drivers/scsi/aic7xxx/aic7xxx_osm.c@1.5

   Age Author Annotate Comments
   9 days gibbs@adaptec.com 1.5
   Eliminate separate Linux host template files and move
   all host template entry ponts to one section of the Linux
   osm.c file.
   Add support for larger disks under 2.5.X.
   Enable highmem_io.

So now I have to figure out what you mean by "enable highmem io"
which is a one-line change in the middle of vast amounts of code
being shoveled from one file into another.

Moving around back and forth:

   11 days gibbs 1.865.1.2
   Complete aic7xxx 6.2.22 and aic79xx 1.3.0_ALPHA2 update.

... another nondescript logentry.

   11 days gibbs 1.858.1.2
   Update to aic7xxx 6.2.22 and aic79xx 1.3.0_ALPHA2

... and another

   8 days gibbs 1.865.1.5
   Complete the upgrade to aic7xxx 6.2.23 and aic79xx 1.3.0_ALPHA3.

... and another.

How many URL's do you expect me to chase here? Do I have to find
your *BSD cvs/whatever repo to extract meaningful log entries or are
even the cvs commit messages there useless?

So off to www.freebsd.org and right there is a very different story:

Revision 1.43, Sat Nov 30 19:30:09 2002 UTC (2 weeks, 6 days ago) by scottl
Branch: MAIN
CVS Tags: RELENG_5_0_BP, RELENG_5_0, HEAD
Changes since 1.42: +44 -7 lines

Bring in many bugfixes and changes obtained from formal testing:

        aic7xxx.c:
        aic7xxx.h:
        aic7xxx.reg:
        aic7xxx.seq:
                Bring in the protocol violation handler from the U320
                driver and replace the NO_IDENT sequencer interrupt code
                with the PROTO_VIOLATION code.  Support for this code
                required the following changes:

                SEQ_FLAGS:
                        IDENTIFY_SEEN -> NOT_IDENTIFIED
                        Added NO_CDB_SENT

                SCB_CONTROL:
                        TARGET_SCB == STATUS_RCVD for initiator mode

                scb->flags:
                        Added SCB_TARGET_SCB since we cannot rely on
                        TARGET_SCB as a target/initiator differentiator
                        due to it being overloaded in initiator mode to
                        indicate that status has been received.
        aic7xxx.seq:
                Move data fifo CLRCHN to mesgin_rdptrs which is a safer
                location for doing this operation.  This also saves a
                sequencer instruction.

        aic7xxx.c:
        aic7xxx.h:
                Change ahc/ahd_upate_neg_request() to take a "negotiation
                type" enum that allows us to negotiate:
                        o only if the goal and current parameters differ.
                        o only if the goal is non-async
                        o always - even if the negotiation will be for async.
        aic7xxx.seq:
                Reset the FIFO whenever a short CDB transfer occurs
                so that the FIFO contents do not corrupt a future CDB
                transfer retry.

                Add support for catching the various protocol violations
                handled by ahc_handle_protocol_violation.

                Reformat some comments.

        aic7xxx.c:
        aic7xxx.h:
                Just for safety, have the aic7xxx driver probe
                the stack depth.

        aic7xxx.c:
        aic7xxx.h:
                Save and restore stack contents during diagnostics.
                Some chip variants overwrite stale entries on a
                stack "pop".

                Don't use 0 to probe the stack depth.  0 is the typical
                value used to backfill the stack if entries are overwritten
                on a "pop".
        aic7xxx.h:
                Add a missing typedef.

                Collapse SCB flag entries so they are bit contiguous.

                Add AHD_ULTRA2_XFER_PERIOD for narrow fallback calculations

        aic7xxx.c:
                Don't panic (as a diagnostic to catch bugs) if we decided to
                force the renegotiation of async even if we believe we are
                already async.  This should allow us to negotiate async instead
                of the full user goal rate during startup if bus resets are
                disabled.

                Add a space to the end of the ahc/ahd_print_devinfo routines
                so that it behaves as expected by the code that uses it.

                Only force a renegotiation on a selection timeout
                if the SCB was valid.  Doing otherwise may be dangerous
                as the connection was not valid for an unknown reason.

                Add additional diagnostic output to ahc_dump_card_state(),
                and have it use the register pretty printing functions.

                Update ahc_reg_print() to handle a NULL cur_col.

                Add a newline to ahc_dump_card_state() output.

                Bring back "use_ppr".  We need to use_ppr anytime
                doppr is true or we have non-zero protocol options.
                The later case was not handled in the recent removal
                of use_ppr.

                Move a comment and remove a useless clearing of use_ppr.

                Don't disable ENBUSFREE when single stepping on
                a DT capable controller.  We cannot re-enable unexpected
                busfree detection, so we must clear BUSFREE on each
                step instead.
                Correct the lookup of the SCB ID in ahc_handle_proto_error.

                Remove a diagnostic printf.
                Remove unecessary restoration of the STACK for older
                chips.

Approved by:	re (blanket)

Wow! Now that's what I call descriptive.

The changes listed under gibbs there seem to be mostly p4 ID synchs.
Not sure what to make of those. But I did find this:


Revision 1.19, Sat Aug 31 06:46:37 2002 UTC (3 months, 2 weeks ago) by gibbs
Branch: MAIN
CVS Tags: RELENG_5_0_BP, RELENG_5_0, HEAD
Changes since 1.18: +10 -1 lines

If interrupts are disabled on the card, don't bother running
our interrupt handler.  Our handler was called due to a shared
interrupt, and the card's interrupts are explicitly disabled
to prevent entry into our interrupt handler.

The diff is actually this:

===================================================================
RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic7xxx_inline.h,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -p -r1.18 -r1.19
--- src/sys/dev/aic7xxx/aic7xxx_inline.h	2002/04/24 16:58:51	1.18
+++ src/sys/dev/aic7xxx/aic7xxx_inline.h	2002/08/31 06:46:37	1.19
@@ -37,9 +37,9 @@
  * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  * POSSIBILITY OF SUCH DAMAGES.
  *
- * $Id: //depot/aic7xxx/aic7xxx/aic7xxx_inline.h#33 $
+ * $Id: //depot/aic7xxx/aic7xxx/aic7xxx_inline.h#38 $
  *
- * $FreeBSD: /home/ncvs/src/sys/dev/aic7xxx/aic7xxx_inline.h,v 1.18 2002/04/24 16:58:51 gibbs Exp $
+ * $FreeBSD: /home/ncvs/src/sys/dev/aic7xxx/aic7xxx_inline.h,v 1.19 2002/08/31 06:46:37 gibbs Exp $
  */
 
 #ifndef _AIC7XXX_INLINE_H_
@@ -494,6 +494,15 @@ ahc_intr(struct ahc_softc *ahc)
 {
 	u_int	intstat;
 
+	if ((ahc->pause & INTEN) == 0) {
+		/*
+		 * Our interrupt is not enabled on the chip
+		 * and may be disabled for re-entrancy reasons,
+		 * so just return.  This is likely just a shared
+		 * interrupt.
+		 */
+		return;
+	}
 	/*
 	 * Instead of directly reading the interrupt status register,
 	 * infer the cause of the interrupt by checking our in-core


This is very much smaller than the individual csets you're pushing
to Linux, and has a changelog entry with actual content. Is there any
chance you could send us changes as modular and well-documented as these?


Thanks,
Bill

Re: [PATCH] aic7xxx bouncing over 4G

[Justin T. Gibbs]

> On Fri, Dec 20, 2002 at 05:59:10PM -0700, Justin T. Gibbs wrote:
>> You can review all of that information by browsing the BK depot at:
>> http://linux-scsi.bkbits.net:8080/scsi-aic7xxx-2.5
>> Since the drivers in 2.4 and 2.5 are almost identical, the changelogs
>> there apply for 2.4.X too.
> 
> This is not in a remotely digestible form.
> (1) the entire universe's changesets are mixed together

Such is BK.

> (2) PITA, I filter for "gibbs", I see a changelog entry that says this:
>    Changeset details for 1.865.1.4
> 
>    ChangeSet@1.865.1.4  2002-12-12 13:45:46-07:00  gibbs@adaptec.com
>    all diffs
>    o Kill host template files.
>    o Move readme files into the Documentation SCSI directory
>    o Enable highmem_io
>    o Split out Kconfig files for aic7xxx and aic79xx
>    Host template and large disk changes provided or inspired by:
>            Christoph Hellwig <hch@sgi.com>
> 
> This is one cset??? These are -very- unrelated changes.

You have to look at individual files in BK to get anything other
than a simple sumation of what the CSET includes.  The CSET is
simply a grouping of changes.  Since I don't develop under BK,
the CSET groupings there are by convenience.  The CSET you list
is the integration of some changes from Christoph Hellwig.  They
are, in fact, related since they all came from him in a single
CSET!

> So I narrow it down to one file inside there:
> 
>    Changes for drivers/scsi/aic7xxx/aic7xxx_osm.c@1.5
> 
>    Age Author Annotate Comments
>    9 days gibbs@adaptec.com 1.5
>    Eliminate separate Linux host template files and move
>    all host template entry ponts to one section of the Linux
>    osm.c file.
>    Add support for larger disks under 2.5.X.
>    Enable highmem_io.
> 
> So now I have to figure out what you mean by "enable highmem io"

What?  You don't know what highmem io is?  Well, either did I until
I groveled around in scsi/host.h, noticed that this new flag had
shown up and greped around to see what it did.  Welcome to the club.

> which is a one-line change in the middle of vast amounts of code
> being shoveled from one file into another.

Those were committed in separate changes into our local Perforce
repository, but I simply don't have the patience to replicate each
individual change in Perforce into a BK change.  Since all of the
Linux universe likes stuff in BK format, I do what I can to accomodate
them.

> Moving around back and forth:
> 
>    11 days gibbs 1.865.1.2
>    Complete aic7xxx 6.2.22 and aic79xx 1.3.0_ALPHA2 update.
> 
> ... another nondescript logentry.

You have to look at the individual files.  In Perforce you have
a single Changelog entry for a submission, not per-file comments.
Since BK allows per-file comments, they are split out into per-file
comments.

> How many URL's do you expect me to chase here?

Why do you expect me to format all of my BK changes exactly the
way that you want?

> Do I have to find your *BSD cvs/whatever repo to extract meaningful
> log entries or are even the cvs commit messages there useless?

Depends on what you want.  It sounds like you want the per-file
messages.  If you did a bk-pull from the above URL, all of that
information would be easily available via "bk csettool".  It's
not my fault that the web interface for BK sucks.

> So off to www.freebsd.org and right there is a very different story:

All of that information is inside the BK changelogs too.  You just
need to work harder to get it.  Don't blame me because:

1) Individual developers are allowed to commit to the central repository
   for FreeBSD, but not in Linux so this kind of information is easily
   recorded for all to see.
2) The BK web interface sucks rocks.
3) You prefer having all of the comments in the CSET entry when BK
   is designed to take per-file comments.
4) You, unlike most people, actually care, in intimate detail, what has
   transpired in the aic7xxx and aic79xx drivers, but expect that
   information to be spoon fed to you.
5) My employer will not allow us to export our Perforce repository
   to remote clients even though it contains no proprietary information.

> Wow! Now that's what I call descriptive.
> 
> The changes listed under gibbs there seem to be mostly p4 ID synchs.
> Not sure what to make of those. But I did find this:

Scott's Changelog was pulled from our Perforce repository (he's a coworker).
I just haven't had time to commit to the FreeBSD repository recently so
he's done the last few updates.   Many, if not most,  of those comments
were actually made by me.

...

> This is very much smaller than the individual csets you're pushing
> to Linux, and has a changelog entry with actual content. Is there any
> chance you could send us changes as modular and well-documented as these?

If it wasn't such a pain to get stuff into the tree, you would see
smaller changesets.  With FreeBSD, I have the authority to go in
and modify the drivers, subsystems, etc. that I maintain at any
time and in any granularity.  Linux doesn't give me that freedom so 
you get this result.  I mean really.  I've only been trying to get
Marcelo to take the aic79xx driver since May or something.  Give
me a break.

--
Justin

Re: [PATCH] aic7xxx bouncing over 4G

[David S. Miller]

On Fri, 2002-12-20 at 17:59, Justin T. Gibbs wrote:
> Those were committed in separate changes into our local Perforce
> repository, but I simply don't have the patience to replicate each
> individual change in Perforce into a BK change.  Since all of the
> Linux universe likes stuff in BK format, I do what I can to accomodate
> them.

Justin, no offense, but if you're not going to use the tool properly,
just stick with patches.

Re: [PATCH] aic7xxx bouncing over 4G

[Justin T. Gibbs]

> On Fri, 2002-12-20 at 17:59, Justin T. Gibbs wrote:
>> Those were committed in separate changes into our local Perforce
>> repository, but I simply don't have the patience to replicate each
>> individual change in Perforce into a BK change.  Since all of the
>> Linux universe likes stuff in BK format, I do what I can to accomodate
>> them.
> 
> Justin, no offense, but if you're not going to use the tool properly,
> just stick with patches.

David,

I'm glad you performed a thorough analysis of how I use BK prior
to commenting.  I think that if you look here, I put more information
into BK than most people.  Considering that it was only recently that
the Linux community decided that revision control was a good thing
and revision information was routinely "lost" on the push to Marcelo
or Linus, I don't see why everyone is being so critical:

http://linux-scsi.bkbits.net:8080/scsi-aic7xxx-2.5/cset@1.865.2.6?nav=index
.html|ChangeSet@-1d

And yes, this changeset was created *before* this thread even started.

--
Justin

Re: [PATCH] aic7xxx bouncing over 4G

[David S. Miller]

   From: "Justin T. Gibbs" <gibbs@scsiguy.com>
   Date: Sat, 21 Dec 2002 08:19:13 -0700
   
   I think that if you look here, I put more information
   into BK than most people.

When I read you say that you split the changesets into individual
precise changes in perforce, and you're not willing to translate
that into individual BK changesets, that is what makes me say
that you aren't using the tool properly.

Have a look at my changesets sometime, Justin.  Just adding a missing
include, that's a changeset.  That's the kind of thing I look for, and
when I get more changes than that in a patch I have to integrate, I
tend to cringe.

Re: [PATCH] aic7xxx bouncing over 4G

[Erik Andersen]

On Fri Dec 20, 2002 at 06:59:46PM -0700, Justin T. Gibbs wrote:
> time and in any granularity.  Linux doesn't give me that freedom so 
> you get this result.  I mean really.  I've only been trying to get
> Marcelo to take the aic79xx driver since May or something.  Give
> me a break.

Supposing I wanted to try out the latest aic7xxx driver?
These are they, right?
    http://people.freebsd.org/~gibbs/linux/SRC/aic79xx-linux-2.4-20021220.bksend.gz

I'm looking at it, and I don't know what it is, bit it sure 
isn't anything I recognize as usable.

    $ file aic79xx-linux-2.4-20021220.bksend 
    aic79xx-linux-2.4-20021220.bksend: ASCII English text

Is the latest aic7xxx driver available as, say, a unified diff,
or a tarball, or some similar usable format?

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: [PATCH] aic7xxx bouncing over 4G

[Justin T. Gibbs]

> Is the latest aic7xxx driver available as, say, a unified diff,
> or a tarball, or some similar usable format?

I'm generating tarballs right now.  The problem with unified diffs is
that everyone wants them against something different.  With the tarball,
and 2.4.X, you should be able to just drop in the driver on just about
any kernel version.

--
Justin

Re: [PATCH] aic7xxx bouncing over 4G

[Christoph Hellwig]

On Fri, Dec 20, 2002 at 06:59:46PM -0700, Justin T. Gibbs wrote:
> Those were committed in separate changes into our local Perforce
> repository, but I simply don't have the patience to replicate each
> individual change in Perforce into a BK change.  Since all of the
> Linux universe likes stuff in BK format, I do what I can to accomodate
> them.

perforce can export unified diffs for each changeste-equivalent right?
for the sgi ptools SCCS we use internally I wrote a simple script
that extracts this diff, the commit message automates a BK checking
with this.  This makes my job of keeping mainline in sync a lot easier
and preserves the fine granuality.  And it works nicely although the
internal tree has some additional noise in it (kdb and HSM support).

> If it wasn't such a pain to get stuff into the tree, you would see
> smaller changesets.

Umm, getting smaller changesets in is not such a pain :)  Linus has
stated very often that he prefers small patches that do one thing and
I 100% agree with him.  Let me suggest we heel you out to get the
current update in (and I think with your latest slave_* fixes and/or
Doug's scsi_scan.c revamp it's time to get it in now) and you send
small, self-contained patches afterwards?

Re: [PATCH] aic7xxx bouncing over 4G

[Justin T. Gibbs]

> On Fri, Dec 20, 2002 at 06:59:46PM -0700, Justin T. Gibbs wrote:
>> Those were committed in separate changes into our local Perforce
>> repository, but I simply don't have the patience to replicate each
>> individual change in Perforce into a BK change.  Since all of the
>> Linux universe likes stuff in BK format, I do what I can to accomodate
>> them.
> 
> perforce can export unified diffs for each changeste-equivalent right?
> for the sgi ptools SCCS we use internally I wrote a simple script
> that extracts this diff, the commit message automates a BK checking
> with this.  This makes my job of keeping mainline in sync a lot easier
> and preserves the fine granuality.  And it works nicely although the
> internal tree has some additional noise in it (kdb and HSM support).

I go through this exact process every time that I release a minor
revision.  I just do it as a single CSET with the comments dispersed
into the individual files that the comments apply to.  If everyone is
really so opposed to using the individual file comment feature of BK,
it will actually make my life easier.  So just let me know what you
do or don't like about the latest CSET that I've committed:

http://linux-scsi.bkbits.net:8080/scsi-aic7xxx-2.5/cset@1.865.2.6?nav=index
.html|ChangeSet@-2d

>> If it wasn't such a pain to get stuff into the tree, you would see
>> smaller changesets.
> 
> Umm, getting smaller changesets in is not such a pain :)

I think you misunderstood me.  CSETs for 2.4.X have been available since
May of this year.  I again sent them in June.  Then July, etc. etc.
This would have allowed the 2.4.X branch to track almost every minor
revision of the aic7xxx driver.  Now with so much time having passed,
*of course* the changes are large.  From my own experience though, the
smaller changes haven't helped in getting them applied.  But since these
changes are in BK, I suppose the fact that there are now several CSETs
to be applied instead of just one or two doesn't matter much.  The
revision history is there for anyone to review in whatever granularity
they want.

--
Justin

Re: [PATCH] aic7xxx bouncing over 4G

[Doug Ledford]

On Sat, Dec 21, 2002 at 08:30:12AM -0700, Justin T. Gibbs wrote:
> revision.  I just do it as a single CSET with the comments dispersed
> into the individual files that the comments apply to.

Which is perfectly acceptable IMHO.  There is no reason that a cset need 
document all the details when the file logs already do.  A cset need only 
indicate what basic work is being done and maybe a list of files in the 
cset.  Doing a bk changes -v gets the file comments as well for those 
people that want them.

I actually like the individual file comments part of the cset setup.  It's 
what my preferred use is when I'm making my own patches.  Make the cset 
have a summary of the major changes, then let each file have it's own 
detail change information.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: [PATCH] aic7xxx bouncing over 4G

[Linus Torvalds]

In article <20021221174554.GA9703@redhat.com>,
Doug Ledford  <dledford@redhat.com> wrote:
>
>I actually like the individual file comments part of the cset setup.  It's 
>what my preferred use is when I'm making my own patches.  Make the cset 
>have a summary of the major changes, then let each file have it's own 
>detail change information.

I do that too, but on the whole I tend to think that if the per-file
comments are really needed (as opposed to being just nice extra and
mostly uninteresting details), there's something wrong with the CSet. 

For example, all the regular changelog tools just use the main cset
comment, and discard the file comments.  So my own rule is that the file
comments should be something fairly small and insignificant, and a good
cset should really be sufficiently explained by the cset comment. 

If the changes are so involved that you only end up condensing the
per-file comments for the global cset comment, and the per-file comments
are really interesting, then maybe that cset should have been split up
in the first place.. 

			Linus

Re: [PATCH] aic7xxx bouncing over 4G

[Samuel Flory]

Justin T. Gibbs wrote:

>>I have an Adaptec AIC-7897 Ultra2 SCSI adapter on a system with 8G
>>of physical memory.  The adapter is using bounce buffers when DMA'ing
>>to memory >4G because of a bug in the aic7xxx driver. 
>>    
>>
>
>This has been fixed in both the aic7xxx and aic79xx drivers for some
>time.  The problem is that these later revisions have not been integrated
>into the mainline trees.
>
>  
>
  Marcelo, what is required get the aic79xx driver, and the aic7xxx 
updates into 2.4.21?  A number of linux distros are already using it. 
 It would really help people using board with the U320.  

    I've been using both drivers for some time with no issues.  Or maybe 
you'd prefer Alan put it in his tree 1st?

-- 
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>

Re: [PATCH] aic7xxx bouncing over 4G

[Marcelo Tosatti]

On Fri, 20 Dec 2002, Samuel Flory wrote:

> Justin T. Gibbs wrote:
>
> >>I have an Adaptec AIC-7897 Ultra2 SCSI adapter on a system with 8G
> >>of physical memory.  The adapter is using bounce buffers when DMA'ing
> >>to memory >4G because of a bug in the aic7xxx driver.
> >>
> >>
> >
> >This has been fixed in both the aic7xxx and aic79xx drivers for some
> >time.  The problem is that these later revisions have not been integrated
> >into the mainline trees.
> >
> >
> >
>   Marcelo, what is required get the aic79xx driver, and the aic7xxx
> updates into 2.4.21?  A number of linux distros are already using it.
>  It would really help people using board with the U320.
>
>     I've been using both drivers for some time with no issues.  Or maybe
> you'd prefer Alan put it in his tree 1st?

Ho, hum, I prefer getting it tested in -ac for a while first.

Re: [PATCH] aic7xxx bouncing over 4G

[Tomas Szepe]

> [marcelo@conectiva.com.br]
>
> > >>I have an Adaptec AIC-7897 Ultra2 SCSI adapter on a system with 8G
> > >>of physical memory.  The adapter is using bounce buffers when DMA'ing
> > >>to memory >4G because of a bug in the aic7xxx driver.
> > >>
> > >>
> > >
> > >This has been fixed in both the aic7xxx and aic79xx drivers for some
> > >time.  The problem is that these later revisions have not been integrated
> > >into the mainline trees.
> > >
> > >
> > >
> >   Marcelo, what is required get the aic79xx driver, and the aic7xxx
> > updates into 2.4.21?  A number of linux distros are already using it.
> >  It would really help people using board with the U320.
> >
> >     I've been using both drivers for some time with no issues.  Or maybe
> > you'd prefer Alan put it in his tree 1st?
> 
> Ho, hum, I prefer getting it tested in -ac for a while first.

Marcelo, you've been overlooking these updates for a bit too long now
for your "let's throw them at -ac" to sound fair.  IMHO of course.  Also
remember those are both production drivers tested thoroughly in FreeBSD,
plus you have your own testing releases -- or at least that's how I thought
'-pre' was meant, and so did Pete Zaitcev apparently
(Message-ID: <20021217142235.C8233@devserv.devel.redhat.com>). <g>

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: [PATCH] aic7xxx bouncing over 4G

[Rik van Riel]

On Sat, 28 Dec 2002, Tomas Szepe wrote:

> Marcelo, you've been overlooking these updates for a bit too long now
> for your "let's throw them at -ac" to sound fair.  IMHO of course.  Also
> remember those are both production drivers tested thoroughly in FreeBSD,

Are we talking about the old or the new aic7xxx driver ?

If it's the new driver, it's breaking on WAY too many
machines and I have no idea why it got ever merged...

I have yet to see a machine where the new aic7xxx driver
works. I'm sure they exist, but it doesn't work on any
of the machines I have access to.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>

Re: [PATCH] aic7xxx bouncing over 4G

[Tomas Szepe]

[riel@conectiva.com.br]
> 
> On Sat, 28 Dec 2002, Tomas Szepe wrote:
> 
> > Marcelo, you've been overlooking these updates for a bit too long now
> > for your "let's throw them at -ac" to sound fair.  IMHO of course.  Also
> > remember those are both production drivers tested thoroughly in FreeBSD,
> 
> Are we talking about the old or the new aic7xxx driver ?

The new one.

> If it's the new driver, it's breaking on WAY too many
> machines and I have no idea why it got ever merged...
> 
> I have yet to see a machine where the new aic7xxx driver
> works. I'm sure they exist, but it doesn't work on any
> of the machines I have access to.

Oh?  I'm surprised to hear that, because the Gibbs driver
	1) works well for all the Adaptecs I've got. :)
	2) can drive certain chips the original driver can't
		(2940U's for instance).

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: [PATCH] aic7xxx bouncing over 4G

[Tony Spinillo]

I've been using 6.2.23 on my two home machines, 29160 and 39160
cards. So far things seem okay.  When I get some down time I will
get the new driver on a few servers at work and see what shakes loose.

TS
Kernel 2.4.21pre1
Intel 845PESVL Motherboards


--- Tomas Szepe <szepe@pinerecords.com> wrote:
> [riel@conectiva.com.br]
> > 
> > On Sat, 28 Dec 2002, Tomas Szepe wrote:
> > 
> > > Marcelo, you've been overlooking these updates for a bit too long
> now
> > > for your "let's throw them at -ac" to sound fair.  IMHO of
> course.  Also
> > > remember those are both production drivers tested thoroughly in
> FreeBSD,
> > 
> > Are we talking about the old or the new aic7xxx driver ?
> 
> The new one.
> 
> > If it's the new driver, it's breaking on WAY too many
> > machines and I have no idea why it got ever merged...
> > 
> > I have yet to see a machine where the new aic7xxx driver
> > works. I'm sure they exist, but it doesn't work on any
> > of the machines I have access to.
> 
> Oh?  I'm surprised to hear that, because the Gibbs driver
> 	1) works well for all the Adaptecs I've got. :)
> 	2) can drive certain chips the original driver can't
> 		(2940U's for instance).
> 
> -- 
> Tomas Szepe <szepe@pinerecords.com>
> -
> 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
> 
> 

Re: [PATCH] aic7xxx bouncing over 4G

[James Bottomley]

riel@conectiva.com.br said:
> If it's the new driver, it's breaking on WAY too many machines and I
> have no idea why it got ever merged... 

It got merged because no-one was testing it when supplied in its current form 
outside the 2.5 tree and because no-one was fixing the older incarnation of 
this driver that was in the tree.  Including it was a caclulated risk 
mitigated significantly because we still have a maintained aic7xxx_old driver.

So far, the only bug report I have is from Andrew Morton proving that it still 
doesn't get it's bounce buffers right.

I assume all your bug reports are on their way to linux-scsi?

James

Re: [PATCH] aic7xxx bouncing over 4G

[Justin T. Gibbs]

> So far, the only bug report I have is from Andrew Morton proving that it
> still  doesn't get it's bounce buffers right.

That hasn't applied since 6.2.10 or so.  2.5.X is still using 6.2.4.

--
Justin

Re: [PATCH] aic7xxx bouncing over 4G

[James Bottomley]

gibbs@scsiguy.com said:
> That hasn't applied since 6.2.10 or so.  2.5.X is still using 6.2.4. 

The bug report is against 2.5.53 which has 6.2.24 in it, so it still needs 
fixing.  At a cursory glance at the code, it looks like you don't call 
scsi_set_pci_device early enough in the detect routine.

James

Re: [PATCH] aic7xxx bouncing over 4G

[Justin T. Gibbs]

> gibbs@scsiguy.com said:
>> That hasn't applied since 6.2.10 or so.  2.5.X is still using 6.2.4. 
> 
> The bug report is against 2.5.53 which has 6.2.24 in it, so it still
> needs  fixing.  At a cursory glance at the code, it looks like you don't
> call  scsi_set_pci_device early enough in the detect routine.

I don't see how this enters into it.  The dma mask should be set on
the PCI device in aic7xxx_osm_pci.c just after we enable the device
and set it as a bus master.  The pci device is setup in the host
structure as it is allocated and before it is registered with the
SCSI subsystem.  I can't imagine that the merge function (and thereby
the bounce limit) is selected before the host is even registered.
My guess is that the original call to setup the PCI mask is not happening
due to either a logic bug in ahc_linux_get_memsize() or the logic that
interprets its response in aic7xxx_osm_pci.c.

I'm not in front of a Linux system to debug this, so all I can do is
inspect the code right now.  Perhaps someone with an affected machine
can toss in a few printks and figure this out?

--
Justin

Re: [PATCH] aic7xxx bouncing over 4G

[Andrew Morton]

"Justin T. Gibbs" wrote:
> 
> > So far, the only bug report I have is from Andrew Morton proving that it
> > still  doesn't get it's bounce buffers right.
> 
> That hasn't applied since 6.2.10 or so.  2.5.X is still using 6.2.4.
> 

2.5.53 is using 6.2.24, and it is bounce buffering highmem I/O.  6.2.4
was OK in this regard.

$ dd if=/dev/zero of=/mnt/sde5/foo bs=1M count=4000
$ oprofpp -l -i /boot/vmlinux

...
c0133010 72       0.175854    bad_range
c0134c44 74       0.180739    __set_page_dirty_nobuffers
c0135a74 79       0.192951    poison_obj
c0136e90 86       0.210048    kmem_cache_alloc
c0196f4c 88       0.214933    ext2_get_branch
c01333a4 89       0.217375    __rmqueue
c01304a4 90       0.219818    unlock_page
c0133658 92       0.224703    buffered_rmqueue
c0130294 95       0.23203     add_to_page_cache
c0131a38 99       0.2418      generic_file_aio_write_nolock
c014ea54 110      0.268666    __find_get_block
c01972d8 136      0.332169    ext2_get_block
c0135aa4 141      0.344381    check_poison_obj
c013b174 1517     3.70515     __blk_queue_bounce       <<<<<
c01e9548 2904     7.09279     __copy_from_user
c01089f8 33209    81.1103     poll_idle

  Linux version 2.5.53 (akpm@mnm) (gcc version 2.95.3 20010315 (release)) #178 SMP Sat Dec 28 12:09:10 PST 2002
  3264MB HIGHMEM available.
  896MB LOWMEM available.
...
  highmem bounce pool size: 64 pages
...
  aic7xxx: PCI Device 0:10:0 failed memory mapped test.  Using PIO.
  ahc_pci:0:10:0: Host Adapter Bios disabled.  Using default SCSI device parameters
  scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.24
          <Adaptec 29160 Ultra160 SCSI adapter>
          aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
  
  (scsi0:A:0): 40.000MB/s transfers (20.000MHz, offset 31, 16bit)
    Vendor: QUANTUM   Model: ATLAS IV 9 SCA    Rev: 0B0B
    Type:   Direct-Access                      ANSI SCSI revision: 03
  (scsi0:A:1): 40.000MB/s transfers (20.000MHz, offset 31, 16bit)
    Vendor: QUANTUM   Model: ATLAS 10K 9SCA    Rev: UC81
    Type:   Direct-Access                      ANSI SCSI revision: 03
  (scsi0:A:2): 40.000MB/s transfers (20.000MHz, offset 15, 16bit)
    Vendor: SEAGATE   Model: ST19101W          Rev: 0014
    Type:   Direct-Access                      ANSI SCSI revision: 02
  (scsi0:A:4): 40.000MB/s transfers (20.000MHz, offset 31, 16bit)
    Vendor: QUANTUM   Model: QM39100TD-SCA     Rev: N1B0
    Type:   Direct-Access                      ANSI SCSI revision: 02
  scsi scan: host 0 channel 0 id 4 lun 0 identifier too long, length 60, max 50. Device might be improperly identified.
  (scsi0:A:5): 40.000MB/s transfers (20.000MHz, offset 63, 16bit)
    Vendor: FUJITSU   Model: MAF3364L SUN36G   Rev: 1213
    Type:   Direct-Access                      ANSI SCSI revision: 02
    Vendor: ESG-SHV   Model: SCA HSBP M4       Rev: 0.63
    Type:   Processor                          ANSI SCSI revision: 02
  scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.24
          <Adaptec aic7880 Ultra SCSI adapter>
          aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
  
  (scsi1:A:0): 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
    Vendor: QUANTUM   Model: ATLAS 10K 9SCA    Rev: UC81
    Type:   Direct-Access                      ANSI SCSI revision: 03
  (scsi1:A:1): 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
    Vendor: QUANTUM   Model: ATLAS 10K 9SCA    Rev: UCH0
    Type:   Direct-Access                      ANSI SCSI revision: 03
  (scsi1:A:2): 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
    Vendor: QUANTUM   Model: ATLAS 10K 9SCA    Rev: UC81
    Type:   Direct-Access                      ANSI SCSI revision: 03
  (scsi1:A:4): 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
    Vendor: QUANTUM   Model: ATLAS 10K 9SCA    Rev: UCP0
    Type:   Direct-Access                      ANSI SCSI revision: 03
  (scsi1:A:5): 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
    Vendor: FUJITSU   Model: MAF3364L SUN36G   Rev: 1213
    Type:   Direct-Access                      ANSI SCSI revision: 02
    Vendor: ESG-SHV   Model: SCA HSBP M4       Rev: 0.63
    Type:   Processor                          ANSI SCSI revision: 02
  SCSI device sda: drive cache: write back
  SCSI device sda: 17942584 512-byte hdwr sectors (9187 MB)
   sda: sda1
  Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
  SCSI device sdb: drive cache: write back
  SCSI device sdb: 17938986 512-byte hdwr sectors (9185 MB)
   sdb: sdb1
  Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
  SCSI device sdc: drive cache: write back
  SCSI device sdc: 17783240 512-byte hdwr sectors (9105 MB)
   sdc: sdc1
  Attached scsi disk sdc at scsi0, channel 0, id 2, lun 0
  SCSI device sdd: drive cache: write back
  SCSI device sdd: 17783249 512-byte hdwr sectors (9105 MB)
   sdd: sdd1 < sdd5 >
  Attached scsi disk sdd at scsi0, channel 0, id 4, lun 0
  SCSI device sde: drive cache: write through
  SCSI device sde: 71132959 512-byte hdwr sectors (36420 MB)
   sde: sde1 < sde5 sde6 sde7 >
  Attached scsi disk sde at scsi0, channel 0, id 5, lun 0
  SCSI device sdf: drive cache: write back
  SCSI device sdf: 17938986 512-byte hdwr sectors (9185 MB)
   sdf: sdf1
  Attached scsi disk sdf at scsi1, channel 0, id 0, lun 0
  SCSI device sdg: drive cache: write back
  SCSI device sdg: 17938986 512-byte hdwr sectors (9185 MB)
   sdg: sdg1
  Attached scsi disk sdg at scsi1, channel 0, id 1, lun 0
  SCSI device sdh: drive cache: write back
  SCSI device sdh: 17938986 512-byte hdwr sectors (9185 MB)
   sdh: sdh1
  Attached scsi disk sdh at scsi1, channel 0, id 2, lun 0
  SCSI device sdi: drive cache: write back
  SCSI device sdi: 17938986 512-byte hdwr sectors (9185 MB)
   sdi: sdi1 < sdi5 sdi6 >
  Attached scsi disk sdi at scsi1, channel 0, id 4, lun 0
  SCSI device sdj: drive cache: write through
  SCSI device sdj: 71132959 512-byte hdwr sectors (36420 MB)
   sdj: sdj1 < sdj5 sdj6 >
  Attached scsi disk sdj at scsi1, channel 0, id 5, lun 0

Re: [PATCH] aic7xxx bouncing over 4G

[Justin T. Gibbs]

> "Justin T. Gibbs" wrote:
>> 
>> > So far, the only bug report I have is from Andrew Morton proving that
>> > it still  doesn't get it's bounce buffers right.
>> 
>> That hasn't applied since 6.2.10 or so.  2.5.X is still using 6.2.4.
>> 
> 
> 2.5.53 is using 6.2.24, and it is bounce buffering highmem I/O.  6.2.4
> was OK in this regard.

Hmm.  The only previous bug report I had in this area was related to a
missing cast.  That was fixed, but I guess it wasn't enough to solve
the problem.

--
Justin

Re: [PATCH] aic7xxx bouncing over 4G

[James Bottomley]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

gibbs@scsiguy.com said:
> Hmm.  The only previous bug report I had in this area was related to a
> missing cast.  That was fixed, but I guess it wasn't enough to solve
> the problem. 

It looks like possibly a config option that doesn't exist (and a possibly 
improper reliance on the dma_mask default value---which should work almost all 
the time, but it's safer to set it).

Andrew, could you try the attached (untested) patch and see if the problem 
goes away.

James


[-- Attachment #2: tmp.diff --]
[-- Type: text/plain , Size: 994 bytes --]

===== aic7xxx_osm.c 1.7 vs edited =====
--- 1.7/drivers/scsi/aic7xxx/aic7xxx_osm.c	Fri Dec 20 18:59:50 2002
+++ edited/aic7xxx_osm.c	Sat Dec 28 16:18:40 2002
@@ -1297,14 +1297,12 @@
 	 */
 	.max_sectors		= 8192,
 #endif
-#if defined CONFIG_HIGHIO
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,18)
 /* Assume RedHat Distribution with its different HIGHIO conventions. */
 	.can_dma_32		= 1,
 	.single_sg_okay		= 1,
 #else
 	.highmem_io		= 1,
-#endif
 #endif
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)
 	.name			= "aic7xxx",
===== aic7xxx_osm_pci.c 1.3 vs edited =====
--- 1.3/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c	Thu Dec 12 14:44:00 2002
+++ edited/aic7xxx_osm_pci.c	Sat Dec 28 15:47:14 2002
@@ -166,6 +166,9 @@
 		ahc->flags |= AHC_39BIT_ADDRESSING;
 		ahc->platform_data->hw_dma_mask =
 		    (bus_addr_t)(0x7FFFFFFFFFULL & (bus_addr_t)~0);
+	} else {
+		ahc_pci_set_dma_mask(pdev, 0xffffffffULL);
+		ahc->platform_data->hw_dma_mask = 0xffffffffULL;
 	}
 #endif
 	ahc->dev_softc = pci;

Re: [PATCH] aic7xxx bouncing over 4G

[Justin T. Gibbs]

> gibbs@scsiguy.com said:
>> Hmm.  The only previous bug report I had in this area was related to a
>> missing cast.  That was fixed, but I guess it wasn't enough to solve
>> the problem. 
> 
> It looks like possibly a config option that doesn't exist

Yes.  It seems to only exist in 2.4.X.  I'll have to use a different
method for toggling the highmem_io option in the host structure.

--
Justin

Re: [PATCH] aic7xxx bouncing over 4G

[Andrew Morton]

James Bottomley wrote:
> 
> gibbs@scsiguy.com said:
> > Hmm.  The only previous bug report I had in this area was related to a
> > missing cast.  That was fixed, but I guess it wasn't enough to solve
> > the problem.
> 
> It looks like possibly a config option that doesn't exist (and a possibly
> improper reliance on the dma_mask default value---which should work almost all
> the time, but it's safer to set it).
> 
> Andrew, could you try the attached (untested) patch and see if the problem
> goes away.
> 

That fixed it, thanks.   Tested with:

	CONFIG_HIGHMEM4G
	CONFIG_HIGHMEM64G, mem=4G
	CONFIG_HIGHMEM64G, (7G)

Re: [PATCH] aic7xxx bouncing over 4G

[Justin T. Gibbs]

> On Sat, 28 Dec 2002, Tomas Szepe wrote:
> 
>> Marcelo, you've been overlooking these updates for a bit too long now
>> for your "let's throw them at -ac" to sound fair.  IMHO of course.  Also
>> remember those are both production drivers tested thoroughly in FreeBSD,
> 
> Are we talking about the old or the new aic7xxx driver ?
> 
> If it's the new driver, it's breaking on WAY too many
> machines and I have no idea why it got ever merged...
> 
> I have yet to see a machine where the new aic7xxx driver
> works. I'm sure they exist, but it doesn't work on any
> of the machines I have access to.

Thanks for all of your detailed bug reports.  Wait!  I haven't
gotten any from you.  That certainly makes it easy for me to
ignore these problems. 8-)

The main reason why the new driver "breaks" where the old one
doesn't is that the new driver does not perform an extra register
read to work-around chipsets that screw up memory mapped I/O.  There
are four solutions to this problem:

1) Insist that people buy sane hardware.

2) Perform the extra read.

3) Use programmed I/O by default and provide an option for enabling
   mememory mapped I/O.  Adaptec's Windows drivers have worked this way
   forever just because so many chipsets are broken.

4) Devise tests in the driver for catching the broken behavior and
   disabling memory mapped I/O on the fly.  The latest Linux and FreeBSD
   drivers do this and the number of systems that "suddenly work" is
   pretty amazing.

We don't live in a world where most people can tell if they are buying
sane hardware or not, so option 1 is out for the general user.  Option two
is too costly.  It is cheaper (cpu and bus cycle wise) to use PIO than to
perform the extra read on every outgoing write.  This is why the "new"
aic7xxx driver has never done this.  Option 3 makes sense if option 4 isn't
practical, but recent experience has shown that the current tests in the
aic7xxx and aic79xx drivers catch all of the known broken systems.

Unfortunately, the versions of the aic7xxx driver that are in the main
trees (both nearly a year out of date) don't have this test and, like the
"old" driver, they default to memory mapped I/O.  One of the reasons I've
been pushing so hard for this new driver to go into the tree is that 90%
of the complaints about the new driver would go away if it were updated
to a sane revision.

--
Justin

Re: [PATCH] aic7xxx bouncing over 4G

[Rik van Riel]

On Sat, 28 Dec 2002, Justin T. Gibbs wrote:

> Unfortunately, the versions of the aic7xxx driver that are in the main
> trees (both nearly a year out of date) don't have this test and, like the
> "old" driver, they default to memory mapped I/O.  One of the reasons I've
> been pushing so hard for this new driver to go into the tree is that 90%
> of the complaints about the new driver would go away if it were updated
> to a sane revision.

Ohhhh, that would certainly explain.  Where could I get a patch
to update a recent 2.4 kernel to your latest aic7xxx driver ?

I'll happily test it on the machines where I have access...

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>

Re: [PATCH] aic7xxx bouncing over 4G

[Doug Ledford]

On Sat, Dec 28, 2002 at 12:13:38PM -0700, Justin T. Gibbs wrote:
> 
> Unfortunately, the versions of the aic7xxx driver that are in the main
> trees (both nearly a year out of date) don't have this test and, like the
> "old" driver, they default to memory mapped I/O.  One of the reasons I've
> been pushing so hard for this new driver to go into the tree is that 90%
> of the complaints about the new driver would go away if it were updated
> to a sane revision.

Actually, no, you need to check 2.5.53 Justin.  Your latest stuff (6.2.24 
or thereabouts I think) has been sucked in and several of the "It breaks 
in 2.5.53" reports that have floated through linux-scsi in the last week 
are in fact about that specific version of the driver.  From the Changelog 
of 2.5.53:

<gibbs@overdrive.btc.adaptec.com>
	Update to aic7xxx 6.2.22 and aic79xx 1.3.0_ALPHA2

<gibbs@overdrive.btc.adaptec.com>
	Remove generated file.

<gibbs@overdrive.btc.adaptec.com>
	Enable highmem_io.

<gibbs@overdrive.btc.adaptec.com>
	o Kill host template files.
	o Move readme files into the Documentation SCSI directory
	o Enable highmem_io
	o Split out Kconfig files for aic7xxx and aic79xx
	
	Host template and large disk changes provided or inspired by:
		Christoph Hellwig <hch@sgi.com>

<gibbs@overdrive.btc.adaptec.com>
	Complete the upgrade to aic7xxx 6.2.23 and aic79xx 1.3.0_ALPHA3.

<gibbs@overdrive.btc.adaptec.com>
	Update to aic7xxx version 6.2.24 and aic79xx version 1.3.0_ALPHA5.

So, in short, your going to have to change your autoresponse to 2.5 
kernels now because Linus bit the bullet and grabbed your tree.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: [PATCH] aic7xxx bouncing over 4G

[Willy Tarreau]

On Sat, Dec 28, 2002 at 12:13:38PM -0700, Justin T. Gibbs wrote:
> The main reason why the new driver "breaks" where the old one
> doesn't is that the new driver does not perform an extra register
> read to work-around chipsets that screw up memory mapped I/O.

Thanks for this clear description, Justin. I now understand why I've had
problems in the past with earlier versions here, since I have other devices
(eg dl2k) which can't do MMIO on my system.

Cheers,
Willy

Re: [PATCH] aic7xxx bouncing over 4G

[David Lang]

well, I'll resend this report (previously sent to linux-kernel as it
didn't seem to be exclusingly a scsi bug)

I attempted to start running 2.5 at .50 and have not yet been able to get
it to work with my adaptec card (including .53).

with .53 I get a message
aic7xxx PCI Device 0:10:0 failed memory mapped test useing PIO
followed by the standard 'I found a card' message, but it never finishes
initializing the card and doesn't go any further through the boot.

with .50 .51 and .52 I don't get the memory map error, but I do get a
large number of error messages as it is trying to initilize things
(unfortunantly they scrolll off the screen quickly so I haven't been able
to copy them down)

David Lang

On Sat, 28 Dec 2002, Justin T. Gibbs wrote:

> Date: Sat, 28 Dec 2002 12:13:38 -0700
> From: Justin T. Gibbs <gibbs@scsiguy.com>
> To: Rik van Riel <riel@conectiva.com.br>, Tomas Szepe <szepe@pinerecords.com>
> Cc: Marcelo Tosatti <marcelo@conectiva.com.br>,
>      Samuel Flory <sflory@rackable.com>, Janet Morgan <janetmor@us.ibm.com>,
>      linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
>      Alan Cox <alan@lxorguk.ukuu.org.uk>
> Subject: Re: [PATCH] aic7xxx bouncing over 4G
>
> > On Sat, 28 Dec 2002, Tomas Szepe wrote:
> >
> >> Marcelo, you've been overlooking these updates for a bit too long now
> >> for your "let's throw them at -ac" to sound fair.  IMHO of course.  Also
> >> remember those are both production drivers tested thoroughly in FreeBSD,
> >
> > Are we talking about the old or the new aic7xxx driver ?
> >
> > If it's the new driver, it's breaking on WAY too many
> > machines and I have no idea why it got ever merged...
> >
> > I have yet to see a machine where the new aic7xxx driver
> > works. I'm sure they exist, but it doesn't work on any
> > of the machines I have access to.
>
> Thanks for all of your detailed bug reports.  Wait!  I haven't
> gotten any from you.  That certainly makes it easy for me to
> ignore these problems. 8-)
>
> The main reason why the new driver "breaks" where the old one
> doesn't is that the new driver does not perform an extra register
> read to work-around chipsets that screw up memory mapped I/O.  There
> are four solutions to this problem:
>
> 1) Insist that people buy sane hardware.
>
> 2) Perform the extra read.
>
> 3) Use programmed I/O by default and provide an option for enabling
>    mememory mapped I/O.  Adaptec's Windows drivers have worked this way
>    forever just because so many chipsets are broken.
>
> 4) Devise tests in the driver for catching the broken behavior and
>    disabling memory mapped I/O on the fly.  The latest Linux and FreeBSD
>    drivers do this and the number of systems that "suddenly work" is
>    pretty amazing.
>
> We don't live in a world where most people can tell if they are buying
> sane hardware or not, so option 1 is out for the general user.  Option two
> is too costly.  It is cheaper (cpu and bus cycle wise) to use PIO than to
> perform the extra read on every outgoing write.  This is why the "new"
> aic7xxx driver has never done this.  Option 3 makes sense if option 4 isn't
> practical, but recent experience has shown that the current tests in the
> aic7xxx and aic79xx drivers catch all of the known broken systems.
>
> Unfortunately, the versions of the aic7xxx driver that are in the main
> trees (both nearly a year out of date) don't have this test and, like the
> "old" driver, they default to memory mapped I/O.  One of the reasons I've
> been pushing so hard for this new driver to go into the tree is that 90%
> of the complaints about the new driver would go away if it were updated
> to a sane revision.
>
> --
> Justin
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [PATCH] aic7xxx bouncing over 4G

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

On Sat, 2002-12-28 at 20:13, Justin T. Gibbs wrote:

> 
> The main reason why the new driver "breaks" where the old one
> doesn't is that the new driver does not perform an extra register
> read to work-around chipsets that screw up memory mapped I/O.  There
> are four solutions to this problem:

just to be sure...you're not talking about PCI posting right?
can you explain in a bit more detail the exact behavior that is the
problem ? (I'm sure a lot of other drivers will suffer the same so I
consider it of general interest)

Greetings,
   Arjan van de Ven

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] aic7xxx bouncing over 4G

[Justin T. Gibbs]

>> The main reason why the new driver "breaks" where the old one
>> doesn't is that the new driver does not perform an extra register
>> read to work-around chipsets that screw up memory mapped I/O.  There
>> are four solutions to this problem:
> 
> just to be sure...you're not talking about PCI posting right?
> can you explain in a bit more detail the exact behavior that is the
> problem ? (I'm sure a lot of other drivers will suffer the same so I
> consider it of general interest)

PCI posting is an expected (and desired) characteristic of PCI, so, no
I'm not complaining about that.  According to the PCI spec, prefetch
is only allowed for devices that explicitly indicate that they support
it (via a bit in their BAR registers).  Further, write combining and
byte merging are only allowed for prefetchable regions.  The Adaptec
parts do not set the prefetch bit and do not support either of these
options (most registers are 8bits anyway, so there was nothing to
gain by complicating the part with this support).  Some BIOSes ignore
this rule and attempt to prefetch and/or write combine transactions
to these chips.  Other BIOSes actually have an option so that the user
can say "ignore the rules".  The new tests are designed to weed out
this broken behavior and to fallback to PIO where prefetch and write
combining cannot come into play.

--
Justin

aic79xx bug? my stupidity?

[Roberto Peon]

I'm not sure to whom I should be addressing this, but it seems that
Justin Gibbs is one of those people.


I've been trying to get the aic79xx driver working in 2.4.19 without success.
I'll clarify:

I've extracted the source tarfile into the kernel dist directory, config'd the
module to build, built it, installed it, etc.

I've gotten far enough that I can get the kernel to boot with it, and it seems
to see the controller, however, I cannot get it to find the root partition.

I have had success using redhat and the driver diskette.
The hardware is an aic7902, integrated onto a Supermicro X5DA8.


>From what I could find on the archives, it seemed like a patch might be
needed to get a vanilla kernel up&running with the aic79xx driver. Is this
right? If so, where might that patch be?

I have more questions and possibly a bug, but would like to find the proper
people to speak with before burdening the list with tons of data.

-Roberto J Peon
robertopeon@sportvision.com

Re: aic79xx bug? my stupidity?

[Justin T. Gibbs]

> I'm not sure to whom I should be addressing this, but it seems that
> Justin Gibbs is one of those people.

I wrote the aic79xx driver.

> I've been trying to get the aic79xx driver working in 2.4.19 without
> success. I'll clarify:

Which version?

> I've gotten far enough that I can get the kernel to boot with it, and it
> seems to see the controller, however, I cannot get it to find the root
> partition.

Does it see the disk where the root partition resides?  If you boot
off of IDE or some other device, can you perform I/O to this disk?

> From what I could find on the archives, it seemed like a patch might be
> needed to get a vanilla kernel up&running with the aic79xx driver. Is this
> right? If so, where might that patch be?

I don't know of any changes outside of adding the driver and adjusting the
Makefiles that are required.

> I have more questions and possibly a bug, but would like to find the
> proper people to speak with before burdening the list with tons of data.

You can just send the info to me.  If it's not my bug I'll redirect you
to the list.

--
Justin

Re: [PATCH] aic7xxx bouncing over 4G

[Samuel Flory]

Rik van Riel wrote:

>On Sat, 28 Dec 2002, Tomas Szepe wrote:
>
>  
>
>>Marcelo, you've been overlooking these updates for a bit too long now
>>for your "let's throw them at -ac" to sound fair.  IMHO of course.  Also
>>remember those are both production drivers tested thoroughly in FreeBSD,
>>    
>>
>
>Are we talking about the old or the new aic7xxx driver ?
>
>If it's the new driver, it's breaking on WAY too many
>machines and I have no idea why it got ever merged...
>  
>

  Well it might have had sometime to do with the way the old driver 
tended to lockup under heavy load.

>I have yet to see a machine where the new aic7xxx driver
>works. I'm sure they exist, but it doesn't work on any
>of the machines I have access to.
>
>  
>

  Funny the reverse is true for me .  It works for every system I have 
access to.

-- 
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>

Re: [PATCH] aic7xxx bouncing over 4G

[Christoph Hellwig]

On Sat, Dec 28, 2002 at 03:32:44AM -0200, Marcelo Tosatti wrote:
> >     I've been using both drivers for some time with no issues.  Or maybe
> > you'd prefer Alan put it in his tree 1st?
> 
> Ho, hum, I prefer getting it tested in -ac for a while first.

Doesn't make much sense for aic79xx which is a new driver (= not changing
existing code at all) and already shipped by the commercial distros for ages..

Re: [PATCH] aic7xxx bouncing over 4G

[Alan Cox]

On Sat, 2002-12-28 at 05:32, Marcelo Tosatti wrote:
> >     I've been using both drivers for some time with no issues.  Or maybe
> > you'd prefer Alan put it in his tree 1st?
> 
> Ho, hum, I prefer getting it tested in -ac for a while first.

Well 79xx driver is a new driver for new hardware so less of a concern