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);
}
/*
> 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
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
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 <[email protected]>
> 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.
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
[email protected] 2002-12-12 13:45:46-07:00 [email protected]
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 <[email protected]>
This is one cset??? These are -very- unrelated changes.
So I narrow it down to one file inside there:
Changes for drivers/scsi/aic7xxx/[email protected]
Age Author Annotate Comments
9 days [email protected] 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 http://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
> 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
>
> [email protected] 2002-12-12 13:45:46-07:00 [email protected]
> 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 <[email protected]>
>
> 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/[email protected]
>
> Age Author Annotate Comments
> 9 days [email protected] 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 http://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
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.
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--
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?
> 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
> 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/[email protected]?nav=index
.html|ChangeSet@-1d
And yes, this changeset was created *before* this thread even started.
--
Justin
> 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/[email protected]?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
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 <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
From: "Justin T. Gibbs" <[email protected]>
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.
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.
> [[email protected]]
>
> > >>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: <[email protected]>). <g>
--
Tomas Szepe <[email protected]>
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..
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:"[email protected]">[email protected]</a>
[[email protected]]
>
> 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 <[email protected]>
[email protected] 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
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:"[email protected]">[email protected]</a>
> 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
> 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
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:
<[email protected]>
Update to aic7xxx 6.2.22 and aic79xx 1.3.0_ALPHA2
<[email protected]>
Remove generated file.
<[email protected]>
Enable highmem_io.
<[email protected]>
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 <[email protected]>
<[email protected]>
Complete the upgrade to aic7xxx 6.2.23 and aic79xx 1.3.0_ALPHA3.
<[email protected]>
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 <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
> [[email protected]]
>
> 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...
http://people.freebsd.org/~gibbs/linux/SRC/aic79xx-linux-2.4-20021220.tar.gz
(Both the 7xxx and 79xx drivers are included.)
--
Tomas Szepe <[email protected]>
"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
[email protected] 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
> "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
> [email protected] 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
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
[email protected] 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
> [email protected] 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
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 <[email protected]>
> To: Rik van Riel <[email protected]>, Tomas Szepe <[email protected]>
> Cc: Marcelo Tosatti <[email protected]>,
> Samuel Flory <[email protected]>, Janet Morgan <[email protected]>,
> [email protected], [email protected],
> Alan Cox <[email protected]>
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
James Bottomley wrote:
>
> [email protected] 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)
On 2002.12.28 Justin T. Gibbs wrote:
> > [email protected] 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, could you write some Configure.help for new options, please ?
TIA
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.21-pre2-jam1 (gcc 3.2.1 (Mandrake Linux 9.1 3.2.1-2mdk))
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
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
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 <[email protected]>
>> 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
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
[email protected]
> 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