Re: [PATCH][RESEND] Fix a potential NULL pointer deref in the aic7xxx, ahc_print_register() function
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 == NULL checks in the routine.
--
Justin
Jesper Juhl wrote:
On 04/08/07, James Bottomley <[EMAIL PROTECTED]> wrote:
On Sat, 2007-08-04 at 20:30 +0200, Jesper Juhl wrote:
(resend of patch previously submitted on 28-Jul-2007 23:06)
Ehlo,
The Coverity checker noticed that we have a potential NULL pointer
deref in drivers/scsi/aic7xxx/aic7xxx_core.c::ahc_print_register().
This patch handles it by adding the same test against NULL that is
used elsewhere in the same function.
It's on my list of things to look at ... but not very high. I suspect
it actually isn't triggerable, but if you can tell me how, it will save
me from looking.
Here's what Coverity reported :
...
6525int
6526ahc_print_register(ahc_reg_parse_entry_t *table, u_int num_entries,
6527 const char *name, u_int address, u_int value,
6528 u_int *cur_column, u_int wrap_point)
6529{
6530int printed;
6531u_int printed_mask;
6532
Event var_compare_op: Added "cur_column" due to comparison "cur_column != 0"
Also see events: [var_deref_op]
At conditional (1): "cur_column != 0" taking false path
6533if (cur_column != NULL && *cur_column >= wrap_point) {
6534printf("\n");
6535*cur_column = 0;
6536}
6537printed = printf("%s[0x%x]", name, value);
At conditional (2): "table == 0" taking true path
6538if (table == NULL) {
6539printed += printf(" ");
Event var_deref_op: Variable "cur_column" tracked as NULL was dereferenced.
Also see events: [var_compare_op]
6540*cur_column += printed;
6541return (printed);
6542}
...
So it requires a NULL 'table' and a != NULL 'cur_column' to trigger.
Whether or not that's actually possible I'm not sure, but it seems
safer to guard against it :)
By the way; if this can actually be triggered, then
ahd_print_register() has the same problem.
-
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/
Re: [PATCH][RESEND] Fix a potential NULL pointer deref in the aic7xxx, ahc_print_register() function
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 == NULL checks in the routine.
--
Justin
Jesper Juhl wrote:
On 04/08/07, James Bottomley [EMAIL PROTECTED] wrote:
On Sat, 2007-08-04 at 20:30 +0200, Jesper Juhl wrote:
(resend of patch previously submitted on 28-Jul-2007 23:06)
Ehlo,
The Coverity checker noticed that we have a potential NULL pointer
deref in drivers/scsi/aic7xxx/aic7xxx_core.c::ahc_print_register().
This patch handles it by adding the same test against NULL that is
used elsewhere in the same function.
It's on my list of things to look at ... but not very high. I suspect
it actually isn't triggerable, but if you can tell me how, it will save
me from looking.
Here's what Coverity reported :
...
6525int
6526ahc_print_register(ahc_reg_parse_entry_t *table, u_int num_entries,
6527 const char *name, u_int address, u_int value,
6528 u_int *cur_column, u_int wrap_point)
6529{
6530int printed;
6531u_int printed_mask;
6532
Event var_compare_op: Added cur_column due to comparison cur_column != 0
Also see events: [var_deref_op]
At conditional (1): cur_column != 0 taking false path
6533if (cur_column != NULL *cur_column = wrap_point) {
6534printf(\n);
6535*cur_column = 0;
6536}
6537printed = printf(%s[0x%x], name, value);
At conditional (2): table == 0 taking true path
6538if (table == NULL) {
6539printed += printf( );
Event var_deref_op: Variable cur_column tracked as NULL was dereferenced.
Also see events: [var_compare_op]
6540*cur_column += printed;
6541return (printed);
6542}
...
So it requires a NULL 'table' and a != NULL 'cur_column' to trigger.
Whether or not that's actually possible I'm not sure, but it seems
safer to guard against it :)
By the way; if this can actually be triggered, then
ahd_print_register() has the same problem.
-
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/
Re: realiable crashing with AIC7xxxx driver and vanilla 2.4.6 kernel on KT133(A)
>** 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 what code is at 0x2c9 in your compiled version of aic7xxx.c. Just turn on the EXTRA_FLAGS=-g bit in the aic7xxx Makefile, rebuild your kernel or module, and do: gdb aic7xxx.o (gdb) l *(ahc_handle_seqint+0x2c9) -- 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/
Re: realiable crashing with AIC7xxxx driver and vanilla 2.4.6 kernel on KT133(A)
** 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 what code is at 0x2c9 in your compiled version of aic7xxx.c. Just turn on the EXTRA_FLAGS=-g bit in the aic7xxx Makefile, rebuild your kernel or module, and do: gdb aic7xxx.o (gdb) l *(ahc_handle_seqint+0x2c9) -- 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/
Re: Cleanup kbuild for aic7xxx
>> >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. Without manually >selecting it, it guarantees boot failure. I don't know if this is due to >the SGI modifications or not. The real problem I found is that during >boot failure, there was no meaningful debug message. I don't know why your kernel source is out of sync. I will have to go pull down the 2.4.5 and 2.4.6 trees and see if some portion of my patches never made it into those trees. It also looks like the comment section for this option didn't make it into my 2.4.4 and above patches. I'll correct this on this on Monday. Here's the relevent info. Do you have any comments on what would make it more useful? +Build Adapter Firmware with Kernel Build +CONFIG_AIC7XXX_BUILD_FIRMWARE + This option should only be enabled if you are modifying the + firmware source to the aic7xxx driver and wish to have the + generated firmware include files updated during a normal + kernel build. The assmebler for the firmware requires + lex and yacc or their equivalents, as well as the db v1 + library. You may have to install additional packages or + modify the assmebler make file or the files it includes + if your build environment is different than that of the + author. >Missing firmware rebuild is fatal for my system, SMP x86 with integrated >7892. Messages and config menu information is inadequate, it requires a >bit of pounding the head on the wall to figure it out. It is hard to make the kernel driver give a reasonable message for every possible error that running with incompatible components may cause. -- 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/
Re: Cleanup kbuild for aic7xxx
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. Without manually selecting it, it guarantees boot failure. I don't know if this is due to the SGI modifications or not. The real problem I found is that during boot failure, there was no meaningful debug message. I don't know why your kernel source is out of sync. I will have to go pull down the 2.4.5 and 2.4.6 trees and see if some portion of my patches never made it into those trees. It also looks like the comment section for this option didn't make it into my 2.4.4 and above patches. I'll correct this on this on Monday. Here's the relevent info. Do you have any comments on what would make it more useful? +Build Adapter Firmware with Kernel Build +CONFIG_AIC7XXX_BUILD_FIRMWARE + This option should only be enabled if you are modifying the + firmware source to the aic7xxx driver and wish to have the + generated firmware include files updated during a normal + kernel build. The assmebler for the firmware requires + lex and yacc or their equivalents, as well as the db v1 + library. You may have to install additional packages or + modify the assmebler make file or the files it includes + if your build environment is different than that of the + author. Missing firmware rebuild is fatal for my system, SMP x86 with integrated 7892. Messages and config menu information is inadequate, it requires a bit of pounding the head on the wall to figure it out. It is hard to make the kernel driver give a reasonable message for every possible error that running with incompatible components may cause. -- 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/
Re: [RFQ] aic7xxx driver panics under heavy swap.
>
>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 issue is that ahc_linux_queue bypasses the
round-robin device scheduler by calling ahc_linux_run_device_queue()
directly. The code should look like this (the LIST macro calls
where switched to TAILQ calls a bit ago to ensure round-robin, but
that change came just after 6.1.13). I haven't tested this yet...
Thanks for the bug report. If you can verify that this works under
memeory pressure, the printf can go away.
--
Justin
//depot/src/linux/drivers/scsi/aic7xxx/aic7xxx_linux.c#67 -
/usr/src/linux/drivers/scsi/aic7xxx/aic7xxx_linux.c
--- /tmp/tmp.3288.0 Tue Jun 19 11:07:32 2001
+++ /usr/src/linux/drivers/scsi/aic7xxx/aic7xxx_linux.c Tue Jun 19 11:02:54 2001
@@ -1514,7 +1514,11 @@
}
cmd->result = CAM_REQ_INPROG << 16;
TAILQ_INSERT_TAIL(>busyq, (struct ahc_cmd *)cmd, acmd_links.tqe);
- ahc_linux_run_device_queue(ahc, dev);
+ if ((dev->flags & AHC_DEV_ON_RUN_LIST) == 0) {
+ TAILQ_INSERT_TAIL(>platform_data->device_runq, dev, links);
+ dev->flags |= AHC_DEV_ON_RUN_LIST;
+ ahc_linux_run_device_queues(ahc);
+ }
ahc_unlock(ahc, );
return (0);
}
@@ -1530,6 +1534,9 @@
struct ahc_tmode_tstate *tstate;
uint16_t mask;
+ if ((dev->flags & AHC_DEV_ON_RUN_LIST) != 0)
+ panic("running device on run list");
+
while ((acmd = TAILQ_FIRST(>busyq)) != NULL
&& dev->openings > 0 && dev->qfrozen == 0) {
@@ -1538,8 +1545,6 @@
* running is because the whole controller Q is frozen.
*/
if (ahc->platform_data->qfrozen != 0) {
- if ((dev->flags & AHC_DEV_ON_RUN_LIST) != 0)
- return;
TAILQ_INSERT_TAIL(>platform_data->device_runq,
dev, links);
@@ -1550,8 +1555,6 @@
* Get an scb to use.
*/
if ((scb = ahc_get_scb(ahc)) == NULL) {
- if ((dev->flags & AHC_DEV_ON_RUN_LIST) != 0)
- panic("running device on run list");
TAILQ_INSERT_TAIL(>platform_data->device_runq,
dev, links);
dev->flags |= AHC_DEV_ON_RUN_LIST;
-
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/
Re: [RFQ] aic7xxx driver panics under heavy swap.
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 issue is that ahc_linux_queue bypasses the
round-robin device scheduler by calling ahc_linux_run_device_queue()
directly. The code should look like this (the LIST macro calls
where switched to TAILQ calls a bit ago to ensure round-robin, but
that change came just after 6.1.13). I haven't tested this yet...
Thanks for the bug report. If you can verify that this works under
memeory pressure, the printf can go away.
--
Justin
//depot/src/linux/drivers/scsi/aic7xxx/aic7xxx_linux.c#67 -
/usr/src/linux/drivers/scsi/aic7xxx/aic7xxx_linux.c
--- /tmp/tmp.3288.0 Tue Jun 19 11:07:32 2001
+++ /usr/src/linux/drivers/scsi/aic7xxx/aic7xxx_linux.c Tue Jun 19 11:02:54 2001
@@ -1514,7 +1514,11 @@
}
cmd-result = CAM_REQ_INPROG 16;
TAILQ_INSERT_TAIL(dev-busyq, (struct ahc_cmd *)cmd, acmd_links.tqe);
- ahc_linux_run_device_queue(ahc, dev);
+ if ((dev-flags AHC_DEV_ON_RUN_LIST) == 0) {
+ TAILQ_INSERT_TAIL(ahc-platform_data-device_runq, dev, links);
+ dev-flags |= AHC_DEV_ON_RUN_LIST;
+ ahc_linux_run_device_queues(ahc);
+ }
ahc_unlock(ahc, flags);
return (0);
}
@@ -1530,6 +1534,9 @@
struct ahc_tmode_tstate *tstate;
uint16_t mask;
+ if ((dev-flags AHC_DEV_ON_RUN_LIST) != 0)
+ panic(running device on run list);
+
while ((acmd = TAILQ_FIRST(dev-busyq)) != NULL
dev-openings 0 dev-qfrozen == 0) {
@@ -1538,8 +1545,6 @@
* running is because the whole controller Q is frozen.
*/
if (ahc-platform_data-qfrozen != 0) {
- if ((dev-flags AHC_DEV_ON_RUN_LIST) != 0)
- return;
TAILQ_INSERT_TAIL(ahc-platform_data-device_runq,
dev, links);
@@ -1550,8 +1555,6 @@
* Get an scb to use.
*/
if ((scb = ahc_get_scb(ahc)) == NULL) {
- if ((dev-flags AHC_DEV_ON_RUN_LIST) != 0)
- panic(running device on run list);
TAILQ_INSERT_TAIL(ahc-platform_data-device_runq,
dev, links);
dev-flags |= AHC_DEV_ON_RUN_LIST;
-
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/
Re: [PANIC] aic7xxx loaded from initrd under 2.4.5
>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 what you compiled (into) your kenrel. If the panic is completely reproduceable, the easiest way to get a useful dump is to apply the SGI kdb patches and get a real trace. -- 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/
Re: [PANIC] aic7xxx loaded from initrd under 2.4.5
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 what you compiled (into) your kenrel. If the panic is completely reproduceable, the easiest way to get a useful dump is to apply the SGI kdb patches and get a real trace. -- 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/
Re: 2.4.5 panic while starting aic7xxx
>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 = 7, target_mask = 1 >Kernel panic: SCB = 3, SCB Control = 40, MSG_OUT = 80 SCB flags = 6000 >In interrupt handler - not syncing This looks like the firmware file is not in sync with the rest of the driver. Depending on the host environment, you may be able to rebuild the firmware yourself. Just check the box in the kernel config section for the aic7xxx driver to rebuild the firmware. -- 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/
Re: 2.4.5 panic while starting aic7xxx
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 a waiting message SCSIID = 7, target_mask = 1 Kernel panic: SCB = 3, SCB Control = 40, MSG_OUT = 80 SCB flags = 6000 In interrupt handler - not syncing This looks like the firmware file is not in sync with the rest of the driver. Depending on the host environment, you may be able to rebuild the firmware yourself. Just check the box in the kernel config section for the aic7xxx driver to rebuild the firmware. -- 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/
Re: new aic7xxx oopses with AHA2940
>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-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/
Re: new aic7xxx oopses with AHA2940
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-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/
Re: New AIC7xxx driver - Berkeley DB1 to DB3
> >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 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/
Re: New AIC7xxx driver - Berkeley DB1 to DB3
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 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/
Re: [PATCH] move aic7xxx ld in drivers/scsi/Makefile
>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 here: http://people.FreeBSD.org/~gibbs/linux/ and see if this is satisfactory. -- 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/
Re: [PATCH] move aic7xxx ld in drivers/scsi/Makefile
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 here: http://people.FreeBSD.org/~gibbs/linux/ and see if this is satisfactory. -- 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/
Re: Kernel 2.4.4, Adaptec 7880 on board controller
>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_module[scsi_hostadapter]: Root fs not mounted This was fixed post v6.1.5 of the aic7xxx driver. You can obtain patches for the latest version 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.4, Adaptec 7880 on board controller
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_module[scsi_hostadapter]: Root fs not mounted This was fixed post v6.1.5 of the aic7xxx driver. You can obtain patches for the latest version 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4-ac5 aic7xxx causes hang on my machine
>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 in rev. 6.1.13 of the aic7xxx driver. -- 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/
Re: 2.4.4-ac5 aic7xxx causes hang on my machine
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 in rev. 6.1.13 of the aic7xxx driver. -- 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/
Re: Success, aic7xxx 6.1.13 fixes boot problems in 2.4.3 2.4.4pre8 2.4.4 (was: 2.4.3 2.4.4pre8: aic7xxx showstopper bug fails to detect sda)
>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 syncing up. I've sent Linus patches post 6.1.5 in the past, but I think he's been too busy with other issues to push them through. I'll ping him too. -- 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/
Re: Success, aic7xxx 6.1.13 fixes boot problems in 2.4.3 2.4.4pre8 2.4.4 (was: 2.4.3 2.4.4pre8: aic7xxx showstopper bug fails to detect sda)
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 syncing up. I've sent Linus patches post 6.1.5 in the past, but I think he's been too busy with other issues to push them through. I'll ping him too. -- 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/
Re: 2.4.3 2.4.4pre8: aic7xxx showstopper bug fails to detect sda
>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 vanilla 2.4.4, to be found at: Version 6.1.13 of my aic7xxx driver is now up. I've included patches to 2.4.4 and 2.4.4-ac2. If this version still causes problems for you, please boot with "aic7xxx=verbose" and send me any diagnostic output the driver prints. I'll try to correct your issue as quickly as I can. -- 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/
Re: 2.4.3 2.4.4pre8: aic7xxx showstopper bug fails to detect sda
>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 the FAQ at http://www.tux.org/lkml/
Re: New aic7xxx driver locking disk access
> >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" 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/
Re: 2.4.3 2.4.4pre8: aic7xxx showstopper bug fails to detect sda
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 the FAQ at http://www.tux.org/lkml/
Re: New aic7xxx driver locking disk access
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 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/
Re: 2.4.3 2.4.4pre8: aic7xxx showstopper bug fails to detect sda
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 vanilla 2.4.4, to be found at: Version 6.1.13 of my aic7xxx driver is now up. I've included patches to 2.4.4 and 2.4.4-ac2. If this version still causes problems for you, please boot with aic7xxx=verbose and send me any diagnostic output the driver prints. I'll try to correct your issue as quickly as I can. -- 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/
Re: aic7xxx: first mount always fails
> >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 loaded as a module. >Here's some diagnostic info from the failed mount. If more is needed, >please let me know. (of course, a disc _is_ present in the drive). My guess is that your CDROM drive takes longer than most to perform the initial read capacity. There is little to be done for this other than uping the timeout value in the CD driver. -- 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/
Re: aic7xxx: first mount always fails
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 loaded as a module. Here's some diagnostic info from the failed mount. If more is needed, please let me know. (of course, a disc _is_ present in the drive). My guess is that your CDROM drive takes longer than most to perform the initial read capacity. There is little to be done for this other than uping the timeout value in the CD driver. -- 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/
Re: PROBLEM: Won't compile new aic7xxx driver
>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-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/
Re: PROBLEM: Won't compile new aic7xxx driver
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-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/
Re: new aic7xxx driver problems
>> 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 hangs. It prints scsi0: blah blah scsi1: sdfdfgsg, I hear the cd >spinning up and nothing more. Did you apply a patch, or upgrade using the tar file? If the latter, you're missing some changes to the SCSI layer that make the initial bus settle delay implimentation more sane. -- 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/
Re: new aic7xxx driver problems
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 hangs. It prints scsi0: blah blah scsi1: sdfdfgsg, I hear the cd spinning up and nothing more. Did you apply a patch, or upgrade using the tar file? If the latter, you're missing some changes to the SCSI layer that make the initial bus settle delay implimentation more sane. -- 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/
Re: [PATCH] Fix scsi_unblock_requests()
>> 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 the old code is correct and your code might >introduce other problems Re-entrancy is only prevented by holding the io-request lock or in some cases a per-controller or per-controller driver lock. As the comment in scsi_unblock_requests() states, this API assumes that no locks are held. If you hold a lock in calling this routine, you may deadlock. >> unblocks. scsi_queue_next_request() verifies all other state >> to ensure queuing new transactions is safe prior to proceeding. > >Including recursion ? I suppose a poorly implemented use of this API could tail recurse. The aic7xxx driver calls this routine from a timeout handler so there is no risk of stack explosion. >The patch seems right apart from checking these details out further. Well, the patch was written to have minimal impact to an API that has never been used. A more correct solution might be to queue the affected host controller to a queue drained by a bottom-half handler. -- 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/
Re: Seems to be a lot of confusion about aic7xxx in linux 2.4.3
>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, or that something >changed between cutting the patch and the tarball. > >-jwb Actually, the issue has to do with how the firmware is generated and the dependencies between generated and source files. The tar file touched all files whereas the patch touched only a few. This is why the tar file worked and the patch did not. Newer versions of the driver completely avoid this issue by only attempting to re-build the firmware if you explicitly configure your kernel this way. -- 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/
Re: new aic7xxx driver problems
> >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 resulting messages. You should also upgrade to v6.1.11 of the driver. -- 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/
[PATCH] Fix scsi_unblock_requests()
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 these
events will ever happen.
This patch attempts to run the queues manually when the host
unblocks. scsi_queue_next_request() verifies all other state
to ensure queuing new transactions is safe prior to proceeding.
This patch is part of versions 6.1.10 and 6.1.11 of the
aic7xxx driver. Its used, along with scsi_block_requests(), to
hold off the mid-layer during the initial bus settle delay without
resorting to a busy loop.
--
Justin
diff -u -r -N linux-2.4.3.virgin/drivers/scsi/scsi_lib.c
linux-2.4.3/drivers/scsi/scsi_lib.c
--- linux-2.4.3.virgin/drivers/scsi/scsi_lib.c Fri Mar 2 19:38:39 2001
+++ linux-2.4.3/drivers/scsi/scsi_lib.c Thu Apr 5 14:28:17 2001
@@ -1108,9 +1108,13 @@
*/
void scsi_unblock_requests(struct Scsi_Host * SHpnt)
{
+ Scsi_Device *SDloop;
+
SHpnt->host_self_blocked = FALSE;
+ /* Now that we are unblocked, try to start the queues. */
+ for (SDloop = SHpnt->host_queue; SDloop; SDloop = SDloop->next)
+ scsi_queue_next_request(>request_queue, NULL);
}
-
/*
* Function:scsi_report_bus_reset()
-
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/
Re: aic7xxx and newer kernels
> >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 a >year with all prior version of linux and win2000 as well. >Also a few other folks seem to have similar problems with >newer kernels. It all depends on the access pattern. The drive will only fail if you fill its write cache. At that point, it will fall off the bus, never to return. >Do the newer drivers put a bigger demand on the drives that >might start to uncover the problems previously not seen? Depends on your settings. If you are using the default, we run a much larger number of concurrent transactions when compared to the old driver. >I did find newer firmware for the adaptec 2940u2w card >tho so perhaps I should upgrade that? If you aren't having problems with your BIOS today, there is no reason to flash the BIOS on teh 2940U2W. >I will try turning off write cache - kernel config option right? SCSI-Select option. -- 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/
Re: AIC7XXX oddities
>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 detected a CRC error a transaction and negotiated async as an indication that the initiator should perform domain validation on this bus segment again. Unfortunatly, the driver doesn't yet support domain validation, so you end up being stuck at 3.3MB/s. I would suggest looking for problems with your cabling or termination on that controller. -- 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/
Re: AIC7XXX oddities
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 detected a CRC error a transaction and negotiated async as an indication that the initiator should perform domain validation on this bus segment again. Unfortunatly, the driver doesn't yet support domain validation, so you end up being stuck at 3.3MB/s. I would suggest looking for problems with your cabling or termination on that controller. -- 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/
Re: aic7xxx and newer kernels
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 a year with all prior version of linux and win2000 as well. Also a few other folks seem to have similar problems with newer kernels. It all depends on the access pattern. The drive will only fail if you fill its write cache. At that point, it will fall off the bus, never to return. Do the newer drivers put a bigger demand on the drives that might start to uncover the problems previously not seen? Depends on your settings. If you are using the default, we run a much larger number of concurrent transactions when compared to the old driver. I did find newer firmware for the adaptec 2940u2w card tho so perhaps I should upgrade that? If you aren't having problems with your BIOS today, there is no reason to flash the BIOS on teh 2940U2W. I will try turning off write cache - kernel config option right? SCSI-Select option. -- 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/
[PATCH] Fix scsi_unblock_requests()
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 these
events will ever happen.
This patch attempts to run the queues manually when the host
unblocks. scsi_queue_next_request() verifies all other state
to ensure queuing new transactions is safe prior to proceeding.
This patch is part of versions 6.1.10 and 6.1.11 of the
aic7xxx driver. Its used, along with scsi_block_requests(), to
hold off the mid-layer during the initial bus settle delay without
resorting to a busy loop.
--
Justin
diff -u -r -N linux-2.4.3.virgin/drivers/scsi/scsi_lib.c
linux-2.4.3/drivers/scsi/scsi_lib.c
--- linux-2.4.3.virgin/drivers/scsi/scsi_lib.c Fri Mar 2 19:38:39 2001
+++ linux-2.4.3/drivers/scsi/scsi_lib.c Thu Apr 5 14:28:17 2001
@@ -1108,9 +1108,13 @@
*/
void scsi_unblock_requests(struct Scsi_Host * SHpnt)
{
+ Scsi_Device *SDloop;
+
SHpnt-host_self_blocked = FALSE;
+ /* Now that we are unblocked, try to start the queues. */
+ for (SDloop = SHpnt-host_queue; SDloop; SDloop = SDloop-next)
+ scsi_queue_next_request(SDloop-request_queue, NULL);
}
-
/*
* Function:scsi_report_bus_reset()
-
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/
Re: new aic7xxx driver problems
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 resulting messages. You should also upgrade to v6.1.11 of the driver. -- 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/
Re: Seems to be a lot of confusion about aic7xxx in linux 2.4.3
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, or that something changed between cutting the patch and the tarball. -jwb Actually, the issue has to do with how the firmware is generated and the dependencies between generated and source files. The tar file touched all files whereas the patch touched only a few. This is why the tar file worked and the patch did not. Newer versions of the driver completely avoid this issue by only attempting to re-build the firmware if you explicitly configure your kernel this way. -- 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/
Re: [PATCH] Fix scsi_unblock_requests()
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 the old code is correct and your code might introduce other problems Re-entrancy is only prevented by holding the io-request lock or in some cases a per-controller or per-controller driver lock. As the comment in scsi_unblock_requests() states, this API assumes that no locks are held. If you hold a lock in calling this routine, you may deadlock. unblocks. scsi_queue_next_request() verifies all other state to ensure queuing new transactions is safe prior to proceeding. Including recursion ? I suppose a poorly implemented use of this API could tail recurse. The aic7xxx driver calls this routine from a timeout handler so there is no risk of stack explosion. The patch seems right apart from checking these details out further. Well, the patch was written to have minimal impact to an API that has never been used. A more correct solution might be to queue the affected host controller to a queue drained by a bottom-half handler. -- 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/
Re: Version 6.1.11 of the aic7xxx driver availalbe
>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 someone to debug it. -- 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/
Re: aic7xxx 6.1.10 and 2.4.4-pre1
>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 disable write caching. You can do this via the SCSI-Select menu for the controller. -- 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/
Version 6.1.11 of the aic7xxx driver availalbe
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/linux/CHANGELOG 2.4.3-patch: http://people.FreeBSD.org/~gibbs/linux/linux-aic7xxx-6.1.11-2.4.3.patch.gz 2.2.19-patch: http://people.FreeBSD.org/~gibbs/linux/linux-aic7xxx-6.1.11-2.2.19.patch.gz -- 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/
Version 6.1.11 of the aic7xxx driver availalbe
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/linux/CHANGELOG 2.4.3-patch: http://people.FreeBSD.org/~gibbs/linux/linux-aic7xxx-6.1.11-2.4.3.patch.gz 2.2.19-patch: http://people.FreeBSD.org/~gibbs/linux/linux-aic7xxx-6.1.11-2.2.19.patch.gz -- 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/
Re: aic7xxx 6.1.10 and 2.4.4-pre1
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 disable write caching. You can do this via the SCSI-Select menu for the controller. -- 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/
Re: Version 6.1.11 of the aic7xxx driver availalbe
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 someone to debug it. -- 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/
Re: aic7xxx 6.1.10 breaks 2.4.3-ac3
>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 grabbed to figure out what it is or how it works, and then complain when they can't diagnose the result of their efforts. -- 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/
Re: aic7xxx 6.1.10 and 2.4.4-pre1
>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 not return with a value is in the panic case and that cannot happen. -- 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/
Re: aic7xxx 6.1.10 breaks 2.4.3-ac3
>> 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 patch. It will probably apply cleanly to your kernel. If it doesn't, and you don't know enough C to correct the problem, you shouldn't be playing around with kernel patches." >That is not the way to do things. It is supposed that what people can get >at your site is the aic driver. Ahh, now I have people telling me what the content of my site should be. ;-) >If the patch contains something different, from the tarball, nobody knows. I've figured this part out. >If there is a bug in kernel, please mail it to lkml. This has already happened in all cases save the functionality I've added in 6.1.10. I haven't even gotten around to announcing 6.1.10 yet, so you can hardly fault me for not posting the SCSI layer changes yet. Anyway, posting something to LK doesn't help people running already released kernels. Not everyone pushes the bleading edge by updating their kernel daily. These people should be able to get driver updates if they need them. As for people that run on the bleading edge, kernel "releases" occur far too often and in too many flavors for me to track them daily. So, I work with Linus and Alan to get driver changes into their trees and provide patches against released kernels. >And in your site make VERY clear and independent the patch to correct >that thing in main SCSI subsystem from the patch to upgrade your drivers. People using the driver will have to have the other fixes. They are not separable. Separating them will only lead to more confusion. For instance, 6.1.10 includes patches to Makefiles to correct for a link order issue. This is another *required* change for the driver to work well. Does that need to be in a separate patch file too? -- 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/
Re: aic7xxx 6.1.10 and 2.4.4-pre1
> 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': > aic7xxx_osm.h:862: warning: control reaches end of non-void function > > (for several .c files but always refers to 'ahc_pci_read_config') This is because panic() is not marked as a "no return" function. So, GCC compains that, in the panic() case, we don't return a value from this particular function. Since we will never return in that case, it is, at least in the aic7xxx driver, a harmless warning. -- 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/
Re: aic7xxx 6.1.10 breaks 2.4.3-ac3
>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 driver to other platforms. You should always use the patches to upgrade as they often touch other portions of the Linux kernel that need fixes in order to work correctly with the aic7xxx driver. >6.1.10 just stops after the init messages and stays there forever. 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. I'm working on an html page for my site that should explain all of the upgrade proceedures. -- 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/
Re: aic7xxx 6.1.10 breaks 2.4.3-ac3
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 driver to other platforms. You should always use the patches to upgrade as they often touch other portions of the Linux kernel that need fixes in order to work correctly with the aic7xxx driver. 6.1.10 just stops after the init messages and stays there forever. 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. I'm working on an html page for my site that should explain all of the upgrade proceedures. -- 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/
Re: aic7xxx 6.1.10 and 2.4.4-pre1
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': aic7xxx_osm.h:862: warning: control reaches end of non-void function (for several .c files but always refers to 'ahc_pci_read_config') This is because panic() is not marked as a "no return" function. So, GCC compains that, in the panic() case, we don't return a value from this particular function. Since we will never return in that case, it is, at least in the aic7xxx driver, a harmless warning. -- 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/
Re: aic7xxx 6.1.10 breaks 2.4.3-ac3
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 patch. It will probably apply cleanly to your kernel. If it doesn't, and you don't know enough C to correct the problem, you shouldn't be playing around with kernel patches." That is not the way to do things. It is supposed that what people can get at your site is the aic driver. Ahh, now I have people telling me what the content of my site should be. ;-) If the patch contains something different, from the tarball, nobody knows. I've figured this part out. If there is a bug in kernel, please mail it to lkml. This has already happened in all cases save the functionality I've added in 6.1.10. I haven't even gotten around to announcing 6.1.10 yet, so you can hardly fault me for not posting the SCSI layer changes yet. Anyway, posting something to LK doesn't help people running already released kernels. Not everyone pushes the bleading edge by updating their kernel daily. These people should be able to get driver updates if they need them. As for people that run on the bleading edge, kernel "releases" occur far too often and in too many flavors for me to track them daily. So, I work with Linus and Alan to get driver changes into their trees and provide patches against released kernels. And in your site make VERY clear and independent the patch to correct that thing in main SCSI subsystem from the patch to upgrade your drivers. People using the driver will have to have the other fixes. They are not separable. Separating them will only lead to more confusion. For instance, 6.1.10 includes patches to Makefiles to correct for a link order issue. This is another *required* change for the driver to work well. Does that need to be in a separate patch file too? -- 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/
Re: aic7xxx 6.1.10 and 2.4.4-pre1
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 not return with a value is in the panic case and that cannot happen. -- 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/
Re: aic7xxx 6.1.10 breaks 2.4.3-ac3
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 grabbed to figure out what it is or how it works, and then complain when they can't diagnose the result of their efforts. -- 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/
Re: AIC7xxx in Kernel 2.4.3
> >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 want to find me, type my name into a Yahoo search. I did this today and was a little surprised at the number of acurate hits. ;-) >Hence the post to this list. You should really check the archives before posting to LK. This has been discussed *a lot*. The version that was released in 2.4.3 was stale weeks prior to that final kernel cut. I'm working on getting revised versions into 2.4.4. If you want to upgrade to something newer, try the 6.1.9 release from here: http://people.FreeBSD.org/~gibbs/linux/ Just be sure to configure the bus settle delay to 5000ms as the default in that release causes a timeout. You can also configure the aic7xxx_old driver. -- 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/
Re: AIC7xxx in Kernel 2.4.3
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 want to find me, type my name into a Yahoo search. I did this today and was a little surprised at the number of acurate hits. ;-) Hence the post to this list. You should really check the archives before posting to LK. This has been discussed *a lot*. The version that was released in 2.4.3 was stale weeks prior to that final kernel cut. I'm working on getting revised versions into 2.4.4. If you want to upgrade to something newer, try the 6.1.9 release from here: http://people.FreeBSD.org/~gibbs/linux/ Just be sure to configure the bus settle delay to 5000ms as the default in that release causes a timeout. You can also configure the aic7xxx_old driver. -- 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/
Re: Minor 2.4.3 Adaptec Driver Problems
>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 6..1.8. -- 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/
Re: Minor 2.4.3 Adaptec Driver Problems
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 6..1.8. -- 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/
Re: scsi bus numbering
>"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 build system can "fix". Its a design issue that will have to be corrected by writing code. -- 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/
Re: scsi bus numbering
>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 depends on link order to function correctly. The driver is built and linked into the kernel in its current fashion to satisfy Linus' desire to make drivers as independant from the SCSI Makefile and Config file as possible. I've modified how the driver is built for the 6.1.9 driver release so it will be linked in prior to the top level drivers. -- 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/
Re: aic7xxx TCQ settings?
> >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 handle and limit the transactions accordingly. For devices with now hard limit, transactions will be dynamically varied to limit the occurrance of queue full but to otherwise try to keep the limit as high as possible. Some devices do not perform well when lots of transactions are outstanding even though they never report queue full. On these devices, you will get better performance if you lower your transaction settings. > >In /proc/scsi/aic7xxx/0 i see for my drives these numbers: > Commands Queued 14 This is a count of the number of commands ever queued to the device. The only time it will "decrease" is when the counter wraps to 0. The counter, at least in the 6.1.8 driver, is an unsigned long. > Commands Active 0 This is a count of the number of commands currently outstanding to the device. You system was idle, SCSI wise, when you pulled this information. > Command Openings 253 Current "soft limit" on tagged transactions. We've never seen a queue full from this device, so the tag count has not been reduced from its original setting. > Max Tagged Openings 253 Hard limit on the number of tagged transactions. The hard limit is set by monitoring the device's "queue full" behavior. -- 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/
Re: aic7xxx TCQ settings?
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 handle and limit the transactions accordingly. For devices with now hard limit, transactions will be dynamically varied to limit the occurrance of queue full but to otherwise try to keep the limit as high as possible. Some devices do not perform well when lots of transactions are outstanding even though they never report queue full. On these devices, you will get better performance if you lower your transaction settings. In /proc/scsi/aic7xxx/0 i see for my drives these numbers: Commands Queued 14 This is a count of the number of commands ever queued to the device. The only time it will "decrease" is when the counter wraps to 0. The counter, at least in the 6.1.8 driver, is an unsigned long. Commands Active 0 This is a count of the number of commands currently outstanding to the device. You system was idle, SCSI wise, when you pulled this information. Command Openings 253 Current "soft limit" on tagged transactions. We've never seen a queue full from this device, so the tag count has not been reduced from its original setting. Max Tagged Openings 253 Hard limit on the number of tagged transactions. The hard limit is set by monitoring the device's "queue full" behavior. -- 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/
Re: scsi bus numbering
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 depends on link order to function correctly. The driver is built and linked into the kernel in its current fashion to satisfy Linus' desire to make drivers as independant from the SCSI Makefile and Config file as possible. I've modified how the driver is built for the 6.1.9 driver release so it will be linked in prior to the top level drivers. -- 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/
Re: scsi bus numbering
"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 build system can "fix". Its a design issue that will have to be corrected by writing code. -- 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/
Re: scsi bus numbering
>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 option, the first disk on the ncr controller becomes >"/dev/sda" ... > >regards, > Peter Daum This is probably because the aic7xxx driver is not linked into the scsi "library" for statically compiled HBA drivers. It is linked directly into the kernel and I believe is after the scsi.a entry on the link line. I'll look into this on monday. -- 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/
Re: Version 6.1.6 of the aic7xxx driver availalbe
>> >> >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 worked in the past >> because it was not quite as fast at driving the bus. 2.2.19 uses the >> "old" aic7xxx driver but includes some performance improvements over 2.2.18. >> The new driver has similar improvements. Check your cables. Check >> your terminators. Etc. >> > >I dont think so. The system is very simple. On the 50 pin Fast scsi there is >the CD. And on the Ultra2 device the IBM harddrive. On the cable there is >a terminator. (This is the cable from ASUS delivered with the motherboard. >Is a balanced pair cable.) On the harddrive there is a strap for termination >and in the BIOS there is a swich for ternination. The strip is off. (I have >tryed on also) And the BIOS control led termination is ON. I have tryed all >permutations! But I have found a workaround. The wide scsi was not in use >and have the same connector so I moved the harddriv to that bus and now >everything works with 2.4.3. Or at least for a half an hour... But the drive >is a LVD and should be on the Ultra2 connector. I've seen so many bug reports lately, that I can't recall your exact configuration. You make it sound as if you have an aic7890 with a 50 pin bus and a 68 pin bus. If this is the case, it does not sound like your termination is properly setup for having devices on "either side" of the controller. The controller termination should probably be off. -- 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/
Re: Version 6.1.6 of the aic7xxx driver availalbe
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 worked in the past because it was not quite as fast at driving the bus. 2.2.19 uses the "old" aic7xxx driver but includes some performance improvements over 2.2.18. The new driver has similar improvements. Check your cables. Check your terminators. Etc. I dont think so. The system is very simple. On the 50 pin Fast scsi there is the CD. And on the Ultra2 device the IBM harddrive. On the cable there is a terminator. (This is the cable from ASUS delivered with the motherboard. Is a balanced pair cable.) On the harddrive there is a strap for termination and in the BIOS there is a swich for ternination. The strip is off. (I have tryed on also) And the BIOS control led termination is ON. I have tryed all permutations! But I have found a workaround. The wide scsi was not in use and have the same connector so I moved the harddriv to that bus and now everything works with 2.4.3. Or at least for a half an hour... But the drive is a LVD and should be on the Ultra2 connector. I've seen so many bug reports lately, that I can't recall your exact configuration. You make it sound as if you have an aic7890 with a 50 pin bus and a 68 pin bus. If this is the case, it does not sound like your termination is properly setup for having devices on "either side" of the controller. The controller termination should probably be off. -- 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/
Re: scsi bus numbering
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 option, the first disk on the ncr controller becomes "/dev/sda" ... regards, Peter Daum This is probably because the aic7xxx driver is not linked into the scsi "library" for statically compiled HBA drivers. It is linked directly into the kernel and I believe is after the scsi.a entry on the link line. I'll look into this on monday. -- 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/
Re: Version 6.1.6 of the aic7xxx driver availalbe
>"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 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 worked in the past because it was not quite as fast at driving the bus. 2.2.19 uses the "old" aic7xxx driver but includes some performance improvements over 2.2.18. The new driver has similar improvements. Check your cables. Check your terminators. Etc. -- 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/
Re: Minor 2.4.3 Adaptec Driver Problems
>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 6.1.8 of the aic7xxx driver from here. This was fixed just after 6.1.5 was released: http://people.FreeBSD.org/~gibbs/linux Use the 2.4.3-pre6 patch. -- 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/
Re: add-single-device won't work in 2.4.3
>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.FreeBSD.org/~gibbs/linux Use the 2.4.3-pre6 patch. -- 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/
Re: Version 6.1.6 of the aic7xxx driver availalbe
>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 information about the timeout which will hopefully allow me to narrow down the problem. A full dmesg of the system would be useful too as that will include the device inquiry data. -- 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/
Re: Version 6.1.6 of the aic7xxx driver availalbe
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 information about the timeout which will hopefully allow me to narrow down the problem. A full dmesg of the system would be useful too as that will include the device inquiry data. -- 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/
Re: add-single-device won't work in 2.4.3
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.FreeBSD.org/~gibbs/linux Use the 2.4.3-pre6 patch. -- 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/
Re: Minor 2.4.3 Adaptec Driver Problems
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 6.1.8 of the aic7xxx driver from here. This was fixed just after 6.1.5 was released: http://people.FreeBSD.org/~gibbs/linux Use the 2.4.3-pre6 patch. -- 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/
Re: Version 6.1.6 of the aic7xxx driver availalbe
"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 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 worked in the past because it was not quite as fast at driving the bus. 2.2.19 uses the "old" aic7xxx driver but includes some performance improvements over 2.2.18. The new driver has similar improvements. Check your cables. Check your terminators. Etc. -- 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/
Re: 2.4.3 aic7xxx wont compile
>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 complaining about the aicasm stuff, and I've provided updated patches to Linus. I'll try the psychic waves thing. Perhaps it will help. -- 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/
Re: 2.4.3 aic7xxx wont compile
> 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 patching process. The sad part is that there has been a fix for this "problem", supplied by the author of the driver, for well over a month that everyone seems to ignore. -- 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/
Re: 2.4.3 aic7xxx wont compile
>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 have to wait until 2.4.4. I'll post updated patches for 2.4.3 later today, but the ones for 2.4.3-pre6 should apply fine. -- 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/
Re: 2.4.3 aic7xxx wont compile
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 have to wait until 2.4.4. I'll post updated patches for 2.4.3 later today, but the ones for 2.4.3-pre6 should apply fine. -- 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/
Re: 2.4.3 aic7xxx wont compile
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 patching process. The sad part is that there has been a fix for this "problem", supplied by the author of the driver, for well over a month that everyone seems to ignore. -- 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/
Re: 2.4.3 aic7xxx wont compile
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 complaining about the aicasm stuff, and I've provided updated patches to Linus. I'll try the psychic waves thing. Perhaps it will help. -- 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/
Re: Linux-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
>> 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 to update to it I don't recall ever sending you diffs for the driver. My guess is that 6.1.5 got integrated into -ac from Linus' tree. Up to now, I haven't been tracking -ac kernels. I started sending diffs to Linus based on the pre series kernels. No-one has requested patch sets against -ac kernels, but if I need to support this branch, I'll start generating them and passing them your way. Chasing after all of the kernel versions can be time consuming for driver developers too. ;-) -- 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/
Re: Linux-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
>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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
>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 "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/
Re: Linux-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
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 "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/
Re: Linux-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.2-ac27 - read on /proc/bus/pci/devices never finishes after rmmod aic7xxx
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 to update to it I don't recall ever sending you diffs for the driver. My guess is that 6.1.5 got integrated into -ac from Linus' tree. Up to now, I haven't been tracking -ac kernels. I started sending diffs to Linus based on the pre series kernels. No-one has requested patch sets against -ac kernels, but if I need to support this branch, I'll start generating them and passing them your way. Chasing after all of the kernel versions can be time consuming for driver developers too. ;-) -- 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/
Re: Adaptec Array1000
>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 - 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/
Re: Adaptec Array1000
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 - 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/
