From owner-freebsd-bugs Sun Nov 23 01:30:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA00914 for bugs-outgoing; Sun, 23 Nov 1997 01:30:04 -0800 (PST) (envelope-from owner-freebsd-bugs) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA00907; Sun, 23 Nov 1997 01:30:02 -0800 (PST) (envelope-from gnats) Resent-Date: Sun, 23 Nov 1997 01:30:02 -0800 (PST) Resent-Message-Id: <199711230930.BAA00907@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, hfwirth@ping.at Received: from atlantis.ping.at (a064.static.Vienna.AT.EU.net [193.154.186.64]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA00650 for ; Sun, 23 Nov 1997 01:22:08 -0800 (PST) (envelope-from hfwirth@ping.at) Received: (from hfwirth@localhost) by atlantis.ping.at (8.8.8/8.6.12) id KAA00668; Sun, 23 Nov 1997 10:22:05 +0100 (MET) Message-Id: <199711230922.KAA00668@atlantis.ping.at> Date: Sun, 23 Nov 1997 10:22:05 +0100 (MET) From: "Helmut F. Wirth" Reply-To: hfwirth@ping.at To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: i386/5128: Adaptec 2940U Timeouts with QUANTUM disk Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 5128 >Category: i386 >Synopsis: Adaptec 2940U Timeouts with QUANTUM disk >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 23 01:30:01 PST 1997 >Last-Modified: >Originator: Helmut F. Wirth >Organization: private >Release: FreeBSD 3.0-CURRENT i386 >Environment: ASUS P55T2P4, Pentium 200 MMX, Adaptec 2940 Bios Ver.1.21 64MB Memory, 1x Quantum Atlas 2GB, 1x IBM 1GB, 1xQuantum Atlas 2GB Plextor CDROM, HP 6020i Worm, Archive Viper Tape, Jaz SCSI Version FreeBSD-current, last update today via CTM from ftp.freebsd.org (Last ctm upgrade included is now src-cur.3139.gz) The newer QUANTUM ATLAS (sd2) has *upgraded* firmware, for the older QUANTUM ATLAS such an upgrade does not exist. All disks worked well up to the last change in the AHC script inside the driver. The following is the relevant part of the boot sequence: Nov 23 09:42:58 atlantis /kernel: ahc0: rev 0x00 int a irq 10 on pci0.11.0 Nov 23 09:42:58 atlantis /kernel: ahc0: aic7880 Single Channel, SCSI Id=7, 16 SCBs Nov 23 09:42:58 atlantis /kernel: ahc0: waiting for scsi devices to settle Nov 23 09:42:58 atlantis /kernel: scbus0 at ahc0 bus 0 Nov 23 09:42:58 atlantis /kernel: sd0 at scbus0 target 0 lun 0 Nov 23 09:42:58 atlantis /kernel: sd0: type 0 fixed SCSI 2 Nov 23 09:42:58 atlantis /kernel: sd0: Direct-Access 2050MB (4199760 512 byte sectors) Nov 23 09:42:58 atlantis /kernel: sd1 at scbus0 target 1 lun 0 Nov 23 09:42:58 atlantis /kernel: sd1: type 0 fixed SCSI 2 Nov 23 09:42:58 atlantis /kernel: sd1: Direct-Access 1034MB (2118144 512 byte sectors) Nov 23 09:42:58 atlantis /kernel: sd2 at scbus0 target 2 lun 0 Nov 23 09:42:58 atlantis /kernel: sd2: type 0 fixed SCSI 2 Nov 23 09:42:58 atlantis /kernel: sd2: Direct-Access 2151MB (4406960 512 byte sectors) Nov 23 09:42:58 atlantis /kernel: sd3 at scbus0 target 3 lun 0 Nov 23 09:42:58 atlantis /kernel: sd3: type 0 removable SCSI 2 Nov 23 09:42:58 atlantis /kernel: sd3: Direct-Access Nov 23 09:42:58 atlantis /kernel: sd3: ILLEGAL REQUEST asc:24,0 Invalid field in CDB Nov 23 09:42:58 atlantis /kernel: sd3 could not mode sense (4). Using ficticious geometry Nov 23 09:42:58 atlantis /kernel: Nov 23 09:42:58 atlantis /kernel: sd3: NOT READY asc:3a,0 Medium not present Nov 23 09:42:58 atlantis /kernel: sd3: could not get size Nov 23 09:42:58 atlantis /kernel: 0MB (0 512 byte sectors) Nov 23 09:42:58 atlantis /kernel: cd0 at scbus0 target 4 lun 0 Nov 23 09:42:58 atlantis /kernel: cd0: type 5 removable SCSI 2 Nov 23 09:42:58 atlantis /kernel: cd0: CD-ROM cd present [267521 x 2048 byte records] Nov 23 09:42:59 atlantis /kernel: ahc0:A:5: refuses synchronous negotiation. Using asynchronous transfers Nov 23 09:42:59 atlantis /kernel: worm0 at scbus0 target 5 lun 0 Nov 23 09:42:59 atlantis /kernel: worm0: type 5 removable SCSI 2 Nov 23 09:42:59 atlantis /kernel: worm0: Write-Once Nov 23 09:42:59 atlantis /kernel: st0 at scbus0 target 6 lun 0 Nov 23 09:42:59 atlantis /kernel: st0: type 1 removable SCSI 2 Nov 23 09:42:59 atlantis /kernel: st0: Sequential-Access density code 0x13, drive empty The disk sd1 is for WIN95 only and is never accessed under FreeBSD. The JAZ drive sd3 is always without disk, when I boot the system. Mounting it does not change the behaviour. I have currently AHC_ALLOW_MEMIO, AHC_TAGENABLE and AHC_SCBPAGING_ENABLE *disabled*, i.e. they are not in my kernel configuration. >Description: The error is not new to me: Under heavy disk load (see below) the following occurs: Nov 23 09:44:31 atlantis /kernel: sd0: SCB 0x1 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Nov 23 09:44:44 atlantis /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Nov 23 09:44:44 atlantis /kernel: sd0: Queueing an Abort SCB Nov 23 09:44:44 atlantis /kernel: sd0: Abort Message Sent Nov 23 09:44:44 atlantis /kernel: sd0: SCB 1 - Abort Completed. Nov 23 09:44:44 atlantis /kernel: sd0: no longer in timeout Nov 23 09:44:44 atlantis /kernel: sd0: SCB 0x1 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Nov 23 09:44:46 atlantis /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Nov 23 09:44:46 atlantis /kernel: sd0: Queueing an Abort SCB Nov 23 09:44:46 atlantis /kernel: sd0: Abort Message Sent Nov 23 09:44:46 atlantis /kernel: sd0: SCB 1 - Abort Completed. Nov 23 09:44:46 atlantis /kernel: sd0: no longer in timeout The behaviour is a bit improved against earlier occurences of this bug: The system is often able to recover and does not hang. However I do not know what happens to the block in the aborted SCB. Important: I some cases the system does not recover (sd0 and sd2 are my swap disks too) and hangs. I this case a *hard reset* does not suffice to bring the system up again!!! The disk seems to be in an special faulty state. Using the reset button (i.e. hard reset) boots the system, the disk reports normal while the ADAPTEC bios boots, but FreeBSD loads only the boot block, the system refuses to load and hangs. I have to power cycle the system, then all is well again. >How-To-Repeat: The error occurs with some disk load, in my case especially when building something large, like FreeBSD make world or an X11 build. >Fix: Unknown >Audit-Trail: >Unformatted: