From owner-aic7xxx Sat Jan 2 12:29:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA26418 for aic7xxx-outgoing; Sat, 2 Jan 1999 12:29:21 -0800 (PST) (envelope-from owner-aic7xxx@FreeBSD.ORG) Received: from spartacus (spartacus.a2000.nl [62.108.1.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA26406 for ; Sat, 2 Jan 1999 12:29:18 -0800 (PST) (envelope-from ard@cstmel.hobby.nl) Received: from node1098a.a2000.nl ([24.132.9.138] helo=intel1.cstmel.hobby.nl) by spartacus with esmtp (Exim 2.02 #4) id 0zwXfI-0004T9-00 for aic7xxx@FreeBSD.ORG; Sat, 2 Jan 1999 21:28:52 +0100 Received: from localhost (ard@localhost) by intel1.cstmel.hobby.nl (8.8.7/8.8.7) with ESMTP id VAA22217 for ; Sat, 2 Jan 1999 21:27:51 +0100 Date: Sat, 2 Jan 1999 21:27:50 +0100 (CET) From: Ard van Breemen To: aic7xxx@FreeBSD.ORG Subject: Re: 5.1.6 failure too.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 14 Dec 1998, Ard van Breemen wrote: > > Dec 13 14:34:31 intel1 kernel: SCSI host 0 abort (pid 22185) timed out - resetting > Dec 13 14:34:31 intel1 kernel: SCSI bus is being reset for host 0 channel 0. > Dec 13 14:34:31 intel1 kernel: (scsi0:0:5:0) Reset called, scb 14, flags 0x6 > Dec 13 14:34:31 intel1 kernel: (scsi0:0:5:0) Bus Device reset, scb flags 0x6, Data-In phase > Dec 13 14:34:31 intel1 kernel: (scsi0:0:5:0) SCSISIGI 0x0, SEQADDR 0x111, SSTAT0 0x0, SSTAT1 0x0 > Dec 13 14:34:31 intel1 kernel: (scsi0:0:5:0) Invalid SCB ID 14 is active, SCB flags = 0x6. > Dec 13 14:34:31 intel1 kernel: (scsi0:-1:-1:-1) 0 commands found and queued for completion. > Dec 13 14:34:31 intel1 kernel: SCSI host 0 channel 0 reset (pid 22185) timed out - trying harder > Dec 13 14:34:31 intel1 kernel: SCSI bus is being reset for host 0 channel 0. > Dec 13 14:34:31 intel1 kernel: (scsi0:0:5:0) Reset called, scb 14, flags 0x6 > Dec 13 14:34:31 intel1 kernel: (scsi0:0:-1:-1) Reset channel called, will initiate reset. > Dec 13 14:34:32 intel1 kernel: (scsi0:0:-1:-1) Resetting currently active channel. > Dec 13 14:34:32 intel1 kernel: (scsi0:0:-1:-1) Channel reset > Dec 13 14:34:32 intel1 kernel: (scsi0:0:-1:-1) Reset device, active_scb 0 > Dec 13 14:34:32 intel1 kernel: (scsi0:0:0:-1) Cleaning up status information and delayed_scbs. > Dec 13 14:34:32 intel1 kernel: (scsi0:0:1:-1) Cleaning up status information and delayed_scbs. > Dec 13 14:34:32 intel1 kernel: (scsi0:0:2:-1) Cleaning up status information and delayed_scbs. > Dec 13 14:34:32 intel1 kernel: (scsi0:0:3:-1) Cleaning up status information and delayed_scbs. > Dec 13 14:34:32 intel1 kernel: (scsi0:0:4:-1) Cleaning up status information and delayed_scbs. > Dec 13 14:34:32 intel1 kernel: (scsi0:0:5:-1) Cleaning up status information and delayed_scbs. > Dec 13 14:34:32 intel1 kernel: (scsi0:0:5:0:tag14) matches search criteria (scsi0:0:-1:-1:tag255) > Dec 13 14:34:32 intel1 kernel: (scsi0:0:6:-1) Cleaning up status information and delayed_scbs. > Dec 13 14:34:32 intel1 kernel: (scsi0:0:-1:-1) Cleaning QINFIFO. > Dec 13 14:34:32 intel1 kernel: (scsi0:0:5:0:tag13) matches search criteria (scsi0:0:-1:-1:tag255) > Dec 13 14:34:33 intel1 kernel: (scsi0:0:-1:-1) Cleaning waiting_scbs. > Dec 13 14:34:33 intel1 kernel: (scsi0:0:-1:-1) Cleaning waiting for selection list. > Dec 13 14:34:33 intel1 kernel: (scsi0:0:-1:-1) Cleaning disconnected scbs list. > Dec 13 14:34:33 intel1 kernel: (scsi0:0:5:0) Aborting scb 13 > Dec 13 14:34:33 intel1 kernel: (scsi0:0:5:0) Aborting scb 14 > Dec 13 14:34:33 intel1 kernel: (scsi0:-1:-1:-1) 2 commands found and queued for completion. I tried doing this now on an adaptec 6260 chipset, it results in the same kind of reset loop. If I look at everyhting (including the aic7xxx sources), I can only conclude that it must be some bug somewhere in the upper scsi layers. It seems as if the upper layer times out on an abort that has already been reported back as completed. This must be somehere in the general scsi code (NOT the generic). I tried probing for my (knowing to fail) Microtek flatbed scanner on the 6260, and yes, another reset loop. These problems were all with the kernels up to 2.0.36. I still have to try the pre 2.2.0 kernel. So according to me, most scsi reset loops initiated by an error are caused by the higher level scsi code, not the adaptec aic7xxx driver code. If somebody thinks I'm mistaken, please correct, cause I don't want to spend a lot of time debugging on the wrong place ;)... Regards, Ard -- dec1: 1:44am up 8 min, 1 user, load average: 0.82, 0.50, 0.23 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message