All of this logic was simplified back in '05 in the BSD drivers by adding
this to the top of the function:
u_int dummy_column;
if (cur_column == NULL) {
dummy_column = 0;
cur_column = &dummy_column;
}
and then stripping out the cur_column =
>** Summary **
>aic7xxx driver reliably crashes to(/in?) ahc_handle_seqint() function.
If you are using the stock driver in 2.4.6, you might try upgrading
to version 6.2.0 of the aic7xxx driver from here:
http://people.FreeBSD.org/~gibbs/linux
In the mean time, it would be interesting to know
>> >Users don't have to manually select "rebuild firmware". They can
>> >rely on the generated files already in the aic7xxx directory. This
>> >is why the option defaults to off.
>
>For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have
>had to manually select this for a 7892 co
>
>Justin,
>When free memory is low, I get a series of aic7xxx messages followed by
>panic. It appears to be a race condition in the code.
Its actually a logic error, not a race condition. You should never
enter ahc_linux_run_device_queue() while the device is still on the
run queue. The real
>A panic occurs at boot while the aic7xxx is doing its thing..the
>following has been hand copied from the screen...
Unfortunately, this trace is somewhat useless. Without symbol
references, it is impossible to say where the panic occurred
or where (symbol location is highly dependent on how an
>SCSI subsystem driver Revision: 1.00
>PCI: Found IRQ 11 for device 00:0c.0
>scsi0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13
>
>aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs
>ahc_intr: AWAITING_MSG for an SCB that does not have a waiting message
>SCSIID
>OK. Now I cut out the Oops out of my /var/log/messages, then did
Can you provide the full dmesg from a working kernel for you system?
I need to know the type of controller in use as well as some other
system attributes.
--
Justin
-
To unsubscribe from this list: send the line "unsubscribe linux
>
>Can someone verify if it's legal to change the include/link in the
>assembler for AIC7xxx ? DB 1.85 has header clash with DB 3 (db.h).
If you upgrade to the latest driver from here:
http://people.FreeBSD.org/~gibbs/linux/
you won't have to deal with the aicasm build.
--
Justin
-
To unsubscr
>Hi,
>
>while examining the makefiles of kernel-2.4.4 I noticed that the top Makefile
>contains a specific reference to the aic7xxx driver which should IMHO be
>referenced only by the drivers/scsi/Makefile.
This was changed post v6.1.5 of the aic7xxx driver. Apply the latest
patch for 2.4.4 from
>Hi,
>
>when booting on a machine having an Adaptec 7880 on board
>controller (Kernel 2.4.4), then i get the following msg:
>
>...
>...
>
>SCSI subsystem driver Revision: 1.00
>request_module[scsi_hostadapter]: Root fs not mounted
>request_module[scsi_hostadapter]: Root fs not mounted
>request_mod
>I have a dual ppro 200MHZ W6LI motherboard. I put 2.4.4-ac5 on last
>night, and the machine hung at Freeing unused Kernel memory. I
>selectively backed off what I thought were relevant patches. I got to
>aic7xxx, and ac5 without it worked. I attached /proc/scsi/aic7xxx/0.
This problem was fix
>Thanks a lot. (Might it be a good idea to ask Linus and Alan to update the
>driver they ship in 2.4.5-pre or 2.4.4-ac, respectively?)
Alan already has integrated 6.1.11 into his kernels. 6.1.13
corects an issue with cdrecord and improves read performance on
U160 cards, so I'll ping Alan about s
>Since the official aic7xxx site doesn't carry a patch against 2.4.4 yet
>(just 2.4.3) which has cosmetic issues when being patched, I made a
>patch against 2.4.4: I took the 2.4.3-aic7xxx-6.1.12 patch, applied to
>2.4.4, bumped the version to read -ma1 in EXTRAVERSION, and made a new
>patch again
>I guess we'll just have to wait for Justin to come out with the real patch...
It's out.
--
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 rea
>
>1. New aic7xxx driver locking disk access
The 6.1.5 version of the aic7xxx driver is quite stale. Can
you try 6.1.13 from:
http://people.FreeBSD.org/~gibbs/linux/
and see if this clears up your problem?
Thanks,
Justin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
>
>The first attempt at mounting a disc in my Traxdata CDR drive after
>boot always fails. From the second on, everything works flawlessly.
>Current setup is 2.2.18 kernel + 6.1.11-2.2.18 patch, but I've been
>experiencing this behaviour since I bought the adapter (around 2.2.12 or so).
>aic7xxx g
>My machine won't compile the kernel with the new aic7xxx driver, it compiles
>fine with the old driver. Says :
You need to upgrade to a leter version of the driver from here:
http://people.FreeBSD.org/~gibbs/linux/
--
Justin
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
>> Can you elaborate on what you had to modify ?
>
>I just added AHC_ULTRA to the features of 7850
>
>AHC_AIC7850_FE = AHC_SPIOCAP|AHC_AUTOPAUSE|AHC_TARGETMODE|AHC_ULTRA,
> ^^
What's the PCI id of the card you are using?
>Plain v6.
>> In its current implementation, scsi_unblock_requests() simply
>> clears host_self_blocked in the SCSI host struct. This means
>> that either a transaction must complete or a new transaction
>
>Suppose the queue is unblocked from inside the functions called to process
>the request. In that situ
>I've been seeing a lot of complaints about aic7xxx in the 2.4.3 kernel. I
>think that people are missing the crucial point: aic7xxx won't compile if
>you patch up from 2.4.2, but if you download the complete 2.4.3 tarball,
>it compiles fine.
>
>So, I conclude that the patch was created incorrect
>
>I have two Adaptec 2930CU (ultra narrow) cards. I modified the driver to
>make them work in ultra mode.
Can you elaborate on what you had to modify?
>Apr 3 23:05:10 Jay kernel: scsi1:0:4:0: Attempting to queue an ABORT message
Please run your system with aic7xxx=verbose and send me the res
In its current implementation, scsi_unblock_requests() simply
clears host_self_blocked in the SCSI host struct. This means
that either a transaction must complete or a new transaction
be issued before the mid-layer will recognize that it can
run the queues. There is no guarantee that either of t
>
>Justin:
>
>Ya think very buggy? I checked seagate web page and
>unfortunately was unable to find any firmware updates
>for the barracuda drives.
I'm pretty sure you need to be up to at leaset 0005 of
the firmware to stabilize this drive.
>Curious tho that this has worked flawlessly for well
>An invocation of hdparm -Tt /dev/sda (id 5) does this:
>
>(scsi1:A:1): 5.000MB/s transfers (5.000MHz, offset 15)
>(scsi1:A:6): 20.000MB/s transfers (20.000MHz, offset 15)
>(scsi0:A:5): 3.300MB/s transfers
The situation might be clearer if you run with aic7xxx=verbose.
My guess is that the target
>So, what about on an alpha system. I've asked a few times what I could do,
>but you didn't help nor explain what you meant.
>From talking to the maintainer of the QLogic driver, it appears
that there is a generic issue with data mapping on the Alpha.
The only way to correct this issue will be f
>Apr 7 19:56:13 snap kernel: Vendor: SEAGATE Model: ST318275LWRev:
> 0001
I seem to recall this being a very buggy firmware version. You should
check with Seagate to see if they have something new. If this is the
firmware I'm thinking of, the driver should perform correctly if you
As always, the latest version of this driver is availalbe here:
http://people.FreeBSD.org/~gibbs/linux/
This site now includes installation instructions, feature set,
etc. The page is under construction - comments welcome.
For the impatient:
CHANGELOG:
http://people.FreeBSD.org/~gibbs/lin
>Once you said 'here is my site for this certain soft updates', you can't
>excpect that people do not check it in a regular basis, did you announce
>anything or not.
I'm not expecting anything. I just find it amusing when people grab
stuff that has no instructions, don't look at what they've gra
>NORET_TYPE void panic(const char * fmt, ...)
>__attribute__ ((NORET_AND format (printf, 1, 2)));
>^
>
>Similar cases, compare include/linux/raid/md_k.h:pers_to_level() in
>2.4.3 and 2.4.3-ac3.
Then gcc is not honoring the attribute. The only way for that
function
>> To be expected as you didn't apply the patch to scsi_lib.c that makes
>> scsi_unblock_host() actually run the device queues to start the system
>> back up again.
>>
>
>There is no patch for 2.4.3-ac3. You could say, well if you want 6.1.10,
>use plain 2.4.3.
Actually, I would say, "Apply the 2
> So I started again - installed redhat 7.0.9.
> took 2.4.4-pre1 and patched it with
> linux-aic7xxx-6.1.10-2.4.3.patch
>
> Patch applied cleanly but when I compile it complains a little:
>
> In file included from aic7xxx_linux.c:131:
> aic7xxx_osm.h: In function `ahc_pci_read_config
>Hi.
>
>Subject says it all.
>
>With latest updates, i just deleted the kernel aic7xxx subtree, put instead
>the updated (from people.freebsd.org) tree, and built. All went fine
>until (and including) 6.1.9.
That's not a sufficient way to upgrade. The tar files are there for
people who are porti
>
>Hi
>
>This driver seems to be pretty broken, the way it is. It does not compile.
>The new author, Justin T. Gibbs, has been careful in avoiding to mention
>his e-mail address in his code :-(
I actually don't believe in putting email address in code. They become
stale
>The latest aic7xxx-6.1.9 doesn't boot, I can see something like:
>
>scsi1:0:0:0: Attempting to queue an ABORT message
>scsi1:0:0:0: Command found on device queue
>aic7xxx_abort returns 8194
Either disable the initial bus reset in SCSI-Select or lower
the bus settle delay from 15000ms to somet
>Volume labels dont help for all cases. Its a bug in the 6.1.5 adaptec driver
>which (to save Justin pointing it out) is fixed in 6.1.8
Actually, there is a component of this related to link order which is
fixed in the upcoming 6.1.9 driver release. The 7895, channel B
primary issue, is fixed in
>"Justin T. Gibbs" wrote:
>> It is bogus that this stuff depends on link order to function
>> correctly.
>
>No, it is simply one more rule, and one that is not immediately
>obvious. Take heart though. Like Rolaids, 2.5's updated makefile
>system will br
>The intent is that all built in HBA drivers are
>initialized _before_ the built in upper level
>drivers (e.g. sd). To get the effect you describe
>the driver init order seems to have been:
> register ncr53c8xxx
> register sd
> register aic7xxx # too late ...
It is bogus that this stuff
>
>I'm using 2.4.3 vanilla with aic7xxx (aic7880 onboard)
>I set the max # of TCQ commands per device setting to 50..what's a really
>good setting for this, just the default of 253?
Depends on the device. The aic7xxx driver will determine the
maximum number of tags that a particular device can h
>On Sun, 1 Apr 2001, Douglas Gilbert wrote:
>
>[...]
>
>> > scsihosts <
>>
>> As a boot time option try:
>> scsihosts=aic7xxx:ncr53c8xxx
>> or if you are using lilo, in /etc/lilo.conf add:
>> append="scsihosts=aic7xxx:ncr53c8xxx"
>
>that does indeed change the bus numberi
>> >> >A typical revery in my logs.
>>
>> This really looks like you bus is not up to snuff. We timeout during
>> a write to the drive. Although the chip has data to write, the target
>> has stopped asking for data. This is a classic symptom of a lost signal
>> transition on the bus. The old d
>"Justin T. Gibbs" wrote:
>
>> >I upgraded to 2.4.3 from 2.4.1 today and I get a lot of recovery on the scs
>i
>> >bus.
>> >I also upgraded to the "latest" aic7xxx driver but still the sam problems.
>> >A typical revery in my logs
>I just got 2.4.3 up a running (on Abit BP6 Dual Celeron ) and
>it reorderd my SCSI id's. Take a look. I don't like that my ZIP drive
>becomes sda because if I ever remove it then I'll @#$% my harddrive dev
>mappings again and have to change them again. Adaptec Driver 6.1.5
>:-(
Upgrade to versio
>hi!
>
>as in the subject, yesterday i upgraded to 2.4.3 (plain, no patches).
>add-single-device/del-single-device did not work anymore.
>
>tried with:
>
>controller: adaptec-19160
>device: yamaha-4260
Do you get any error messages? Does the problem persist with
the latest driver?
http://people
>I upgraded to 2.4.3 from 2.4.1 today and I get a lot of recovery on the scsi
>bus.
>I also upgraded to the "latest" aic7xxx driver but still the sam problems.
>A typical revery in my logs.
Can you resend the recovery information after booting with "aic7xxx=verbose".
This will provide more inform
>You cannot expect that all people will instantly start using the
>latest driver from your Web site, immediately. Especially considering
I guess I expect people posting on LK to read it. There have been
announcements for all the driver versions on that list, I've responded
to all of the threads
> Yes, "-I." from gcc flags.
>
> The sad part is that people have been patching right and left to get
> that monster utility to compile because the dependencies say that it
> must be used to remake the AIC sequencer binary image; which image is
> perfectly ok except of its timestampts due to
>Just tried to build 2.4.3, got:
Grumble. Grumble. Grumble.
We've been through this before. The 6.1.8 version of the
driver has a fixed Makefile, doesn't even attempt to assemble
the firmware unless you config your kernel to turn it on, and has
been out for over a month now.
I guess it will ha
>> What version of the aic7xxx driver is embedded in 2.4.2-ac27? This
>> particular issue was fixed just after 6.1.5 was released.
>
>The last patch you sent to me + small other fixups for aicdb.h. I dont have
>time to chase after peoples drivers. If you want a newer aic7xxx in -ac just
>mail me
>aic7xxx_osm.h:#define AIC7XXX_DRIVER_VERSION "6.1.5"
Pick up the latest from here:
http://people.FreeBSD.org/~gibbs/linux/
--
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.kern
>Hello,
>
>I'm using Linux-2.4.2-ac27 SMP compiled with gcc version 2.95.2 2220
>(Debian GNU/Linux).
What version of the aic7xxx driver is embedded in 2.4.2-ac27? This
particular issue was fixed just after 6.1.5 was released.
--
Justin
-
To unsubscribe from this list: send the line "unsubsc
>Hi all,
>
>Does anyone know how to configure this controller (chipset AAA-133U2
>aka AIC-78xx) with one RAID5 hardware volume ? The kernel 2.2.16 see
>all the disks (4x18Gb) but don't see the unique volume.
These boards are not currently supported in RAID mode. Your
best bet is Linux MD.
--
Ju
>Hi All,
> I notice that the new aic7xxx driver in 2.4.3-pre7 needs some version
>of the berkeley db. (the make file has -ldb1 in it). It blew
>up on my because I apparently don't have it installed.
Use the latest version of the driver from here:
http://people.FreeBSD.org/~gibbs/linux
It w
>I am trying to compile the 2.4.3-pre6 linux kernel and it is failing
>because it cannot find the "db.h" header file.
Please upgrade to the latest aic7xxx driver. Patches are available
here:
http://people.freebsd.org/~gibbs/linux/
That code will not attempt to build the firmware unless you set
As always, the latest version of this driver is availalbe here:
http://people.FreeBSD.org/~gibbs/linux/
Complete CHANGELOG is now available at the above URL.
I try to filter though LK as often as I can, but for
best response, please email issues regarding this driver to
me directly.
Changes si
>Just installed 2.4.3-pre4 same problem :(
It might help to know what controller you are using.
--
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.ht
As always, the latest version of this driver is availalbe here:
http://people.FreeBSD.org/~gibbs/linux/
Complete CHANGELOG is now available at the above URL.
I try to filter though LK as often as I can, but for
best response, please email issues regarding this driver to
me directly.
Changes si
>The bigger problem with that driver for pedants is that it contains globals
>with names like 'hard_error' which are asking for clashes . Bizarrely all
>the static functions are carefully named ahc_* and the globals are called
>things like 'restart_squencer'
Such is the evolutionary nature of mos
>(scsi1:A:0:0): data overrun detected in Data-out phase. Tag == 0x36.
>(scsi1:A:0:0): Have seen Data Phase. Length = 0. NumSGs = 0.
As I mentioned to you the last time you brought up this problem, I
don't believe that this is caused by the aic7xxx driver, but the
aic7xxx driver may be the firs
>Hi,
>
>Just a note to make gcc 2.96 (and future) happy. The aic7xxx driver is full of
>inline funcs that should return a value and do not do that:
They don't return a value because doing so is meaningless. You aren't
going to get past the panic. The compiler should know that assuming
panic is
>hmmm.. Is there a reason why this would be -needed-? It wouldn't be
>hard to implement, but I would rather not have drivers dealing with a
>list whose normal state is defined as "mostly sorted"...
That's the wrong definition. The list is "sorted by probe order".
--
Justin
-
To unsubscribe fr
>I would prefer to sort the list at probe not boot time. That makes it
>easy to reverse the order on the fly, depending on what the driver
>requests at runtime. It's SMP-friendly, because I can grab a private
>copy of the PCI device list, sort it, and scan it. You don't have to
>re-sort at ever
>Hi Justin,
> your new driver complains loudly here, because of
>ahc_match_scb is invoked with NULL scb, and it does not like that.
>
>Call trace was:
> 0xc01c9073: ahc_match_scb + 23/191
> 0xc01c945d: ahc_search_qinfifo+ 333/1719 (it is first of two calls to ahc_m
>atch...)
> 0xc01c9ede: a
> I presume the aicasm (or whatever) can do its meager DB needs
> by simpler ubiquitous things like GDBM. SleepyCat DBx is good,
> but in this case as serious overkill as e.g. using Oracle ;)
> (No, I didn't read the source of the aicasm.)
People keep saying stuff like
>What about simply removing the firmware source and assembler from the
>kernel tree? We have lots of firmware in the kernel tree for which
>there isn't even firmware avaible...
What, and not allow others to fix my bugs for me? :-)
Lots of people have embedded this driver just because it is com
>hello justin !
>
>i have just tried to install the latest 2.4.3pre3 kernel with your
>driver.
>it failed with yacc: file not found.
>while i could install yacc, i have never had to use it before. i was
>assuming that the newer bison could do the same thing (which is what
>i have installed).
>so f
>I've a Super P6SBS motherboard with a builtin dual channel Adaptec 7890
>Ultra II scsi controller. I'm attaching the console grab when booting
>2.4.3-pre2. The controller BIOS is configured to boot off the disk with
>scsi id 0 on channel B.
It looks like Doug was right to think that the function
>make[5]: Entering directory
>`/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm'
>lex -t aicasm_scan.l > aicasm_scan.c
>gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c
>aicasm_symbol.c -o aicasm
>aicasm_symbol.c:39: db/db_185.h: No such file or directory
>make[5]: *** [aicasm] E
>> Can you provide me with a dmesg from a boot with aic7xxx=verbose?
>> I just tested this on a 3940AUW and the behavior was as expected.
>> Perhaps you have a motherboard based controller that has no seeprom?
>> I don't know how to detect flipped channels in that configuration
>> but I'll see wha
>This is just to report on a the behavior of this driver. I've a dual
>channel Adaptec 7895 controller. The adapter BIOS is configured to boot
>from devices in channel B. I boot from a disk connected to channel B
>and when the kernel loads the driver the disks from channel A are seen
>first, resu
>This is just to report on a the behavior of this driver. I've a dual
>channel Adaptec 7895 controller. The adapter BIOS is configured to boot
>from devices in channel B. I boot from a disk connected to channel B
>and when the kernel loads the driver the disks from channel A are seen
>first, resu
>BTW, is there really enough common ground between the whole series of
>AIC chips to justify a single huge driver? I know they ship three
>separate NT drivers to cover this range..
The chips are very similar. I think the single driver for Linux is
actually a smaller binary than any of the indiv
>Here's the dmesg when it happened (I took this via serial console which I was
>logged in to)
>[root@kakarot:/lvm/misc] cp /dev/zero .
>(scsi1:A:2:0): data overrun detected in Data-out phase. Tag == 0x33.
Someone is sending a request that your drive believes specifies a data
transfer to the dri
>Have you any idea the breadth of cards and chips that aic7xxx supports?
>Sure, Justin's driver does great with your shiny new 7899, but can you
>verify that it also drives the 8-year-old EISA AHA-2740 I still have
>sitting around (actually retired to the parts pile, but that's beside
>the point,
>All of my boxes with that card are on 2.2.16. The rest are on 2.4.1, so I
>don't really have a need to test 2.2.18 as I would rather be on 2.4.x for
>all of my boxes.
Well, I'll try and generate patches against 2.2.16 soon. I probably
need to support 2.2.14 too. There are already so many versi
>I am still stuck on 2.2 because of this issue. I would really like to see
>this driver in 2.4.2.
Have you tested the 2.2.18 version of the new driver? The patches
should work on most 2.2.X kernels, I just haven't gotten around to
verifying that. The more testers, the merrier! :-)
--
Justin
-
>I dont plan to switch them yet a while, and never for 2.2. For 2.5 its a
>total nobrainer that we move to Justins driver or move to Justins driver post
>crudfixing that may be needed to make it clean and Linuxish
Can you be more specific about your complaints?
--
Justin
-
To unsubscribe from t
>If these 3 drives are on the adaptec aha-2940UW, I get an oops (reply for
>oops as I have to do it again and capture it) and the system locks (in
>interrupt handler, not syncing) when the copy completes. I did a timed cp
>the first time and it took 3.5 minutes and crashed as soon as I got the
>p
>Hello all,
> I included everyone (boy + dog) so everyone knows the result.
>
> After much testing here is the results. I used the following patch
>
> linux-aic7xxx-6.0.9BETA-2.4.0.diffs
>
> against the ne 2.4.0 kernel sans my patch and happy to report it
> cleaned up the TCQ problem.
Thanks for
>This is a temporary patch to keep the scsi driver from eating
>your data I am working on a real fix
>
>Leslie Donaldson
What is the firmware revision of your Seagate drives? There
were several models shipped in the recent past with firware that
would cause the drive to drop off the bus
luded
in hosts.c
--
Justin
Justin T. Gibbs
OpenSource Embedding
Adaptec Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
>> I figured as much. I will test for the #define, stash it in a #define
>> unique within my namespace, and #define it back in hosts.c should my
>> local define exist.
>
>If that driver hits a tree I maintain be aware that the first thing I will do
>is rip that out and rename the 'current' variab
>In article <[EMAIL PROTECTED]> you wrote:
>> For those
>> of you building the driver as a module, take note that the module
>> name is now "aic7xxx_mod" rather than "aic7xxx".
>
>Could you please undo that change?
>Postfixing a module name with _mod does not make sense.
>Yes, some modules use it
>
>What's wrong with current? It's perfectly fine, since it's the main data
>context entity you are working with during it's usage... Just remember
>it as
>CURRENT MAIN PROBLEM the kernel is struggling with at time.
What's wrong with the aic7xxx driver storing the "user", "goal", and
"current" tr
>> I figured as much. I will test for the #define, stash it in a #define
>> unique within my namespace, and #define it back in hosts.c should my
>> local define exist.
>
>Justin,
>
>While you're at it, can you have the new driver provide status information
>under /proc/scsi/aic7xxx? There is sim
>> BSD has curproc, but that is considerably less likely to be
>> used in "inoccent code" than "current". I mean, "current what?".
>> It could be anything, current privledges, current process, current
>> thread, the current time...
>
>I see and I assume calling a random collection of data
>
>
>> I'll update my patch tomorrow to restore the definition of current.
>> I do fear, however, that this will perpetuate the polution of the
>> namespace should "current" ever get cleaned up.
>
>It can probably get cleaned up after 2.4 by making current() the actual
>inline. For 2.2 it won't chang
>I tried it against clean 2.2.18 and patches did not work.
>Some drawbacks:
>- the patch adds config info for AIX7XXX in the top level Makefile, instead
>of in the Makefile in the scsi dir.
Yes, this will be fixed today. The aic7xx directory will build the module
or main driver file into the scs
> Date: Wed, 13 Dec 2000 20:56:08 -0700
> From: "Justin T. Gibbs" <[EMAIL PROTECTED]>
>
> None-the-less, it seems to me that spamming the kernel namespace
> with "current" in at least the way that the 2.2 kernels do (does
> this
>Thanks for posting this. Unfortunately, the kernel won't build unless you
>restore this macro to the namespace after aic7xxx_linux.h blows it away:
>
>--- linux-2.2.18/drivers/scsi/hosts.c.orig Wed Dec 13 20:27:34 2000
>+++ linux-2.2.18/drivers/scsi/hosts.c Wed Dec 13 20:26:22 2000
>@@ -137
daptec SCSI HBA device driver for the Linux Operating System
To: [EMAIL PROTECTED]
cc:
Fcc: +outbox
Subject: Adaptec AIC7XXX v6.0.6 BETA Released
---
After several months of testing and refinement, the Adaptec
sponsored aic7xxx driver is now entering Beta testing. Although
still missing doma
>Hi all,
>
>am I right that the aic7xx version in latest test is 5.2.1 ? Is there a
>reason why this is not up to date to Doug Ledfords 5.1.31 ?
My hope is that the Adaptec sponsored driver will eventually
become the driver embedded in 2.4.X kernels. This driver is
currently in Alpha (Beta to b
--- Blind-Carbon-Copy
To: [EMAIL PROTECTED]
Subject:
Date: Thu, 02 Nov 2000 11:03:37 -0700
From: "Justin T. Gibbs"
Adaptec SCSI HBA device driver for the Linux Operating System
Justin T. Gibbs
A
92 matches
Mail list logo
