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 = _column;
}
and then stripping out the cur_column ==
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
** 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
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 controller.
>
>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
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
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 and
>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
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
Adaptec 2940 Ultra2 SCSI adapter
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs
ahc_intr: AWAITING_MSG for an SCB that does not have
>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
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
>
>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
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
>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
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
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
>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
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 fixed
>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
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
>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
>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
>
>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
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 read
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
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 against
>
>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
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 gets
>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
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
>> 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
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.1.11
>> 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
>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
>
>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
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
>
>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
>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
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
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 over
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
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
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 incorrectly,
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 situation
>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
>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:
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:
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
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 for
>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
>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
>> 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
> 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
>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
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 porting the
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':
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.4.3
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
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
>
>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 far t
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 far too easily. If you ever
>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
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 bring r
>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
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
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
"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 bring relief...
Its not something the bu
>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
>> >> >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
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 driver may have
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 numbering. Unfortunately, even
with this
>"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
>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?
>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
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
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?
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 version
"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.
This really looks like you bus is not up to snuff. We ti
>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
> 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
>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
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
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
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
>> 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
>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
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
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
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 a diff
>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.
--
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.
--
Justin
1 - 100 of 178 matches
Mail list logo
