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
"Justin T. Gibbs" wrote: > >"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. > 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 controlled 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. > > -- > Justin -- foo! - 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: "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. 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 controlled 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. -- Justin -- foo! - 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
>"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: 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 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/ OK. This is it: Mar 31 16:39:03 pescadero kernel: UnexpecteMar 31 17:37:48 pescadero kernel: klogd 1.3-3, log source = /proc/kmsg started. Mar 31 17:37:48 pescadero kernel: Cannot find map file. Mar 31 17:37:48 pescadero kernel: No module symbols loaded. Mar 31 17:37:48 pescadero kernel: IRQ 00, APIC ID 2, APIC INT 10 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 13, APIC ID 2, APIC INT 13 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 18, APIC ID 2, APIC INT 13 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 24, APIC ID 2, APIC INT 13 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 2, IRQ 10, APIC ID 2, APIC INT 12 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 2, IRQ 14, APIC ID 2, APIC INT 13 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 2, IRQ 18, APIC ID 2, APIC INT 10 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 2, IRQ 1c, APIC ID 2, APIC INT 11 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 2c, APIC ID 2, APIC INT 11 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 30, APIC ID 2, APIC INT 10 Mar 31 17:37:48 pescadero kernel: Lint: type 3, pol 1, trig 1, bus 3, IRQ 00, APIC ID ff, APIC LINT 00 Mar 31 17:37:48 pescadero kernel: Lint: type 1, pol 1, trig 1, bus 3, IRQ 00, APIC ID ff, APIC LINT 01 Mar 31 17:37:48 pescadero kernel: Processors: 2 Mar 31 17:37:48 pescadero kernel: mapped APIC to e000 (fee0) Mar 31 17:37:48 pescadero kernel: mapped IOAPIC to d000 (fec0) Mar 31 17:37:48 pescadero kernel: Kernel command line: BOOT_IMAGE=linux.test1 ro root=801 aic7xxx=verbose pirq=0,0,0,0,18,16,17,5,19,19,19,19 ether=9,0,eth0 ether=9,0,eth1 ether=9,0,eth2 ether=9,0,eth3 Mar 31 17:37:48 pescadero kernel: PIRQ redirection, working around broken MP-BIOS. Mar 31 17:37:48 pescadero kernel: ... PIRQ0 -> IRQ 0 Mar 31 17:37:48 pescadero kernel: ... PIRQ1 -> IRQ 0 Mar 31 17:37:48 pescadero kernel: ... PIRQ2 -> IRQ 0 Mar 31 17:37:48 pescadero kernel: ... PIRQ3 -> IRQ 0 Mar 31 17:37:48 pescadero kernel: ... PIRQ4 -> IRQ 18 Mar 31 17:37:48 pescadero kernel: ... PIRQ5 -> IRQ 16 Mar 31 17:37:48 pescadero kernel: ... PIRQ6 -> IRQ 17 Mar 31 17:37:48 pescadero kernel: ... PIRQ7 -> IRQ 5 Mar 31 17:37:48 pescadero kernel: Initializing CPU#0 Mar 31 17:37:48 pescadero kernel: Detected 300.687 MHz processor. Mar 31 17:37:48 pescadero kernel: Console: colour VGA+ 132x60 Mar 31 17:37:48 pescadero kernel: Calibrating delay loop... 599.65 BogoMIPS Mar 31 17:37:48 pescadero kernel: Memory: 125936k/131060k available (1458k kernel code, 4736k reserved, 554k data, 200k init, 0k highmem) Mar 31 17:37:48 pescadero kernel: Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Mar 31 17:37:48 pescadero kernel: Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Mar 31 17:37:48 pescadero kernel: Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Mar 31 17:37:48 pescadero kernel: Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Mar 31 17:37:48 pescadero kernel: CPU: Before vendor init, caps: 0080fbff , vendor = 0 Mar 31 17:37:48 pescadero kernel: CPU: L1 I cache: 16K, L1 D cache: 16K Mar 31 17:37:48 pescadero kernel: CPU: L2 cache: 512K Mar 31 17:37:48 pescadero kernel: Intel machine check architecture supported. Mar 31 17:37:48 pescadero kernel: Intel machine check reporting enabled on CPU#0. Mar 31 17:37:48 pescadero kernel: CPU: After vendor init, caps: 0080fbff Mar 31 17:37:48 pescadero kernel: CPU: After generic, caps: 0080fbff Mar 31 17:37:48 pescadero kernel: CPU: Common caps: 0080fbff Mar 31 17:37:48 pescadero kernel: Checking 'hlt' instruction... OK. Mar 31 17:37:48 pescadero kernel: POSIX conformance testing by UNIFIX Mar 31 17:37:48 pescadero kernel: mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) Mar 31 17:37:48 pescadero kernel: mtrr: detected mtrr type: Intel Mar 31 17:37:48 pescadero kernel: CPU: Before vendor init, caps: 0080fbff , vendor = 0 Mar 31 17:37:48 pescadero kernel:
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. Mar 31 09:34:35 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:35 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:34:35 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:34:35 pescadero kernel: Recovery code sleeping Mar 31 09:34:40 pescadero kernel: Recovery code awake Mar 31 09:34:40 pescadero kernel: Timer Expired Mar 31 09:34:40 pescadero kernel: aic7xxx_abort returns 8195 Mar 31 09:34:40 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:40 pescadero kernel: Recovery SCB completes Mar 31 09:34:40 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:34:40 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:34:40 pescadero kernel: Recovery code sleeping Mar 31 09:34:40 pescadero kernel: Recovery code awake Mar 31 09:34:40 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:34:50 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:50 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:34:50 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:34:50 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:50 pescadero kernel: scsi0:0:4:0: Device is active, asserting ATN Mar 31 09:34:50 pescadero kernel: Recovery code sleeping Mar 31 09:34:55 pescadero kernel: Recovery code awake Mar 31 09:34:55 pescadero kernel: Timer Expired Mar 31 09:34:55 pescadero kernel: aic7xxx_abort returns 8195 Mar 31 09:34:55 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:55 pescadero kernel: Recovery SCB completes Mar 31 09:34:55 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:34:55 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:34:55 pescadero kernel: Recovery code sleeping Mar 31 09:34:55 pescadero kernel: Recovery code awake Mar 31 09:34:55 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:05 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:05 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:35:05 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:05 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:05 pescadero kernel: Recovery SCB completes Mar 31 09:35:05 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:35:05 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:35:05 pescadero kernel: Recovery code sleeping Mar 31 09:35:05 pescadero kernel: Recovery code awake Mar 31 09:35:05 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:15 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:15 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:35:15 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:15 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:15 pescadero kernel: Recovery SCB completes Mar 31 09:35:15 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:35:15 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:35:15 pescadero kernel: Recovery code sleeping Mar 31 09:35:15 pescadero kernel: Recovery code awake Mar 31 09:35:15 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:25 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:25 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:35:25 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:25 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:25 pescadero kernel: Recovery SCB completes Mar 31 09:35:25 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:35:25 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:35:25 pescadero kernel: Recovery code sleeping Mar 31 09:35:25 pescadero kernel: Recovery code awake Mar 31 09:35:25 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:35 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:35 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:35:35 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:35 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:35 pescadero kernel: Recovery SCB completes Mar 31 09:35:35 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:35:35 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:35:35 pescadero kernel: Recovery code sleeping Mar 31 09:35:35 pescadero kernel: Recovery code awake Mar 31 09:35:35 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:45 pescadero kernel: scsi0:0:4:0:
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. Mar 31 09:34:35 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:35 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:34:35 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:34:35 pescadero kernel: Recovery code sleeping Mar 31 09:34:40 pescadero kernel: Recovery code awake Mar 31 09:34:40 pescadero kernel: Timer Expired Mar 31 09:34:40 pescadero kernel: aic7xxx_abort returns 8195 Mar 31 09:34:40 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:40 pescadero kernel: Recovery SCB completes Mar 31 09:34:40 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:34:40 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:34:40 pescadero kernel: Recovery code sleeping Mar 31 09:34:40 pescadero kernel: Recovery code awake Mar 31 09:34:40 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:34:50 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:50 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:34:50 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:34:50 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:50 pescadero kernel: scsi0:0:4:0: Device is active, asserting ATN Mar 31 09:34:50 pescadero kernel: Recovery code sleeping Mar 31 09:34:55 pescadero kernel: Recovery code awake Mar 31 09:34:55 pescadero kernel: Timer Expired Mar 31 09:34:55 pescadero kernel: aic7xxx_abort returns 8195 Mar 31 09:34:55 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:34:55 pescadero kernel: Recovery SCB completes Mar 31 09:34:55 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:34:55 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:34:55 pescadero kernel: Recovery code sleeping Mar 31 09:34:55 pescadero kernel: Recovery code awake Mar 31 09:34:55 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:05 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:05 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:35:05 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:05 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:05 pescadero kernel: Recovery SCB completes Mar 31 09:35:05 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:35:05 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:35:05 pescadero kernel: Recovery code sleeping Mar 31 09:35:05 pescadero kernel: Recovery code awake Mar 31 09:35:05 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:15 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:15 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:35:15 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:15 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:15 pescadero kernel: Recovery SCB completes Mar 31 09:35:15 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:35:15 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:35:15 pescadero kernel: Recovery code sleeping Mar 31 09:35:15 pescadero kernel: Recovery code awake Mar 31 09:35:15 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:25 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:25 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:35:25 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:25 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:25 pescadero kernel: Recovery SCB completes Mar 31 09:35:25 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:35:25 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:35:25 pescadero kernel: Recovery code sleeping Mar 31 09:35:25 pescadero kernel: Recovery code awake Mar 31 09:35:25 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:35 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:35 pescadero kernel: scsi0:0:4:0: Cmd aborted from QINFIFO Mar 31 09:35:35 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:35 pescadero kernel: scsi0:0:4:0: Attempting to queue an ABORT message Mar 31 09:35:35 pescadero kernel: Recovery SCB completes Mar 31 09:35:35 pescadero kernel: (scsi0:A:4:0): Queuing a recovery SCB Mar 31 09:35:35 pescadero kernel: scsi0:0:4:0: Device is disconnected, re-queuing SCB Mar 31 09:35:35 pescadero kernel: Recovery code sleeping Mar 31 09:35:35 pescadero kernel: Recovery code awake Mar 31 09:35:35 pescadero kernel: aic7xxx_abort returns 8194 Mar 31 09:35:45 pescadero kernel: scsi0:0:4:0:
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
"Justin T. Gibbs" wrote: 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/ OK. This is it: Mar 31 16:39:03 pescadero kernel: UnexpecteMar 31 17:37:48 pescadero kernel: klogd 1.3-3, log source = /proc/kmsg started. Mar 31 17:37:48 pescadero kernel: Cannot find map file. Mar 31 17:37:48 pescadero kernel: No module symbols loaded. Mar 31 17:37:48 pescadero kernel: IRQ 00, APIC ID 2, APIC INT 10 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 13, APIC ID 2, APIC INT 13 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 18, APIC ID 2, APIC INT 13 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 24, APIC ID 2, APIC INT 13 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 2, IRQ 10, APIC ID 2, APIC INT 12 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 2, IRQ 14, APIC ID 2, APIC INT 13 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 2, IRQ 18, APIC ID 2, APIC INT 10 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 2, IRQ 1c, APIC ID 2, APIC INT 11 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 2c, APIC ID 2, APIC INT 11 Mar 31 17:37:48 pescadero kernel: Int: type 0, pol 3, trig 3, bus 0, IRQ 30, APIC ID 2, APIC INT 10 Mar 31 17:37:48 pescadero kernel: Lint: type 3, pol 1, trig 1, bus 3, IRQ 00, APIC ID ff, APIC LINT 00 Mar 31 17:37:48 pescadero kernel: Lint: type 1, pol 1, trig 1, bus 3, IRQ 00, APIC ID ff, APIC LINT 01 Mar 31 17:37:48 pescadero kernel: Processors: 2 Mar 31 17:37:48 pescadero kernel: mapped APIC to e000 (fee0) Mar 31 17:37:48 pescadero kernel: mapped IOAPIC to d000 (fec0) Mar 31 17:37:48 pescadero kernel: Kernel command line: BOOT_IMAGE=linux.test1 ro root=801 aic7xxx=verbose pirq=0,0,0,0,18,16,17,5,19,19,19,19 ether=9,0,eth0 ether=9,0,eth1 ether=9,0,eth2 ether=9,0,eth3 Mar 31 17:37:48 pescadero kernel: PIRQ redirection, working around broken MP-BIOS. Mar 31 17:37:48 pescadero kernel: ... PIRQ0 - IRQ 0 Mar 31 17:37:48 pescadero kernel: ... PIRQ1 - IRQ 0 Mar 31 17:37:48 pescadero kernel: ... PIRQ2 - IRQ 0 Mar 31 17:37:48 pescadero kernel: ... PIRQ3 - IRQ 0 Mar 31 17:37:48 pescadero kernel: ... PIRQ4 - IRQ 18 Mar 31 17:37:48 pescadero kernel: ... PIRQ5 - IRQ 16 Mar 31 17:37:48 pescadero kernel: ... PIRQ6 - IRQ 17 Mar 31 17:37:48 pescadero kernel: ... PIRQ7 - IRQ 5 Mar 31 17:37:48 pescadero kernel: Initializing CPU#0 Mar 31 17:37:48 pescadero kernel: Detected 300.687 MHz processor. Mar 31 17:37:48 pescadero kernel: Console: colour VGA+ 132x60 Mar 31 17:37:48 pescadero kernel: Calibrating delay loop... 599.65 BogoMIPS Mar 31 17:37:48 pescadero kernel: Memory: 125936k/131060k available (1458k kernel code, 4736k reserved, 554k data, 200k init, 0k highmem) Mar 31 17:37:48 pescadero kernel: Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Mar 31 17:37:48 pescadero kernel: Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Mar 31 17:37:48 pescadero kernel: Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Mar 31 17:37:48 pescadero kernel: Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Mar 31 17:37:48 pescadero kernel: CPU: Before vendor init, caps: 0080fbff , vendor = 0 Mar 31 17:37:48 pescadero kernel: CPU: L1 I cache: 16K, L1 D cache: 16K Mar 31 17:37:48 pescadero kernel: CPU: L2 cache: 512K Mar 31 17:37:48 pescadero kernel: Intel machine check architecture supported. Mar 31 17:37:48 pescadero kernel: Intel machine check reporting enabled on CPU#0. Mar 31 17:37:48 pescadero kernel: CPU: After vendor init, caps: 0080fbff Mar 31 17:37:48 pescadero kernel: CPU: After generic, caps: 0080fbff Mar 31 17:37:48 pescadero kernel: CPU: Common caps: 0080fbff Mar 31 17:37:48 pescadero kernel: Checking 'hlt' instruction... OK. Mar 31 17:37:48 pescadero kernel: POSIX conformance testing by UNIFIX Mar 31 17:37:48 pescadero kernel: mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) Mar 31 17:37:48 pescadero kernel: mtrr: detected mtrr type: Intel Mar 31 17:37:48 pescadero kernel: CPU: Before vendor init, caps: 0080fbff , vendor = 0 Mar 31 17:37:48 pescadero kernel: CPU: L1 I cache: 16K, L1 D
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/
