From robert@kudra.com  Mon Jan 10 21:14:11 2000
Return-Path: <robert@kudra.com>
Received: from tabby.kudra.com (gw.kudra.com [199.6.32.20])
	by hub.freebsd.org (Postfix) with ESMTP id E38DF153F0
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 10 Jan 2000 21:14:01 -0800 (PST)
	(envelope-from robert@kudra.com)
Received: (from robert@localhost) by tabby.kudra.com (8.9.3/8.6.12) id AAA38043; Tue, 11 Jan 2000 00:13:53 -0500 (EST)
Message-Id: <200001110513.AAA38043@tabby.kudra.com>
Date: Tue, 11 Jan 2000 00:13:53 -0500 (EST)
From: robert@kudra.com
Reply-To: robert@kudra.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: Conner Drive Doesn't like syncronize cache (surprise)
X-Send-Pr-Version: 3.2

>Number:         16049
>Category:       kern
>Synopsis:       Connor Drive fails cache sync
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 10 21:20:01 PST 2000
>Closed-Date:    Fri Nov 16 15:33:21 PST 2001
>Last-Modified:  Fri Nov 16 15:33:43 PST 2001
>Originator:     Robert Sexton
>Release:        FreeBSD 3.4-RELEASE i386
>Organization:
Kudra.Com Web services
>Environment:
3.4 Release

>Description:

When rebooting a 3.4-RELEASE machine with a Conner drive and Adaptec
Controller, I get the following error message:

(da0:ahc0:0:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 
(da0:ahc0:0:0:0): ILLEGAL REQUEST asc:20,0
(da0:ahc0:0:0:0): Invalid command operation code

Here are the boot messages pertaining to the disk adapter and drive:
ahc0: <Adaptec 2940 SCSI adapter> rev 0x03 int a irq 11 on pci0.18.0
ahc0: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs

da0: <CONNER CFP1080S 4443> Fixed Direct Access SCSI-2 device 
da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
da0: 1030MB (2110812 512 byte sectors: 255H 63S/T 131C)

>How-To-Repeat:

halt/reboot the machine.

>Fix:

*** scsi_da.c   Tue Jan 11 00:10:20 2000
--- scsi_da.c.new       Tue Jan 11 00:00:50 2000
***************
*** 160,165 ****
--- 160,173 ----
        },
        {
                /*
+                * The Conner Doesn't like it either.
+                * Reported by Robert Sexton <robert@kudra.com>
+                */
+               {T_DIRECT, SIP_MEDIA_FIXED, "CONNER", "CFP1080*",
"*"},
+               /*quirks*/ DA_Q_NO_SYNC_CACHE
+       },
+       {
+               /*
                 * Doesn't work correctly with 6 byte reads/writes.
                 * Returns illegal request, and points to byte 9 of
the
                 * 6-byte CDB.


>Release-Note:
>Audit-Trail:

From: Peter Wemm <peter@netplex.com.au>
To: robert@kudra.com
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/16049: Conner Drive Doesn't like syncronize cache (surprise) 
Date: Tue, 11 Jan 2000 13:49:22 +0800

 robert@kudra.com wrote:
 
 > When rebooting a 3.4-RELEASE machine with a Conner drive and Adaptec
 > Controller, I get the following error message:
 > 
 > (da0:ahc0:0:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 
 > (da0:ahc0:0:0:0): ILLEGAL REQUEST asc:20,0
 > (da0:ahc0:0:0:0): Invalid command operation code
 
 Yes, but does it lock up the drive?  Or just a cosmetic problem..  We add
 quirks for the drives that crash or lock up if I recall correctly.  (I have
 one of these drives too <CONNER CFP2105S  2.14GB 2D4D>, it complains too
 but doesn't fail).
 
 Cheers,
 -Peter
 --
 Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
 "All of this is for nothing if we don't go to the stars" - JMS/B5
 
 

From: "Kenneth D. Merry" <ken@kdm.org>
To: robert@tabby.kudra.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, gibbs@FreeBSD.ORG
Subject: Re: kern/16049: Conner Drive Doesn't like syncronize cache (surprise)
Date: Thu, 20 Jan 2000 21:51:08 -0700

 --dDRMvlgZJXvWKvBx
 Content-Type: text/plain; charset=us-ascii
 
 On Tue, Jan 11, 2000 at 00:13:53 -0500, robert@tabby.kudra.com wrote:
 > >Release:        FreeBSD 3.4-RELEASE i386
 > >Organization:
 > Kudra.Com Web services
 > >Environment:
 > 3.4 Release
 > 
 > >Description:
 > 
 > When rebooting a 3.4-RELEASE machine with a Conner drive and Adaptec
 > Controller, I get the following error message:
 > 
 > (da0:ahc0:0:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 
 > (da0:ahc0:0:0:0): ILLEGAL REQUEST asc:20,0
 > (da0:ahc0:0:0:0): Invalid command operation code
 > 
 > Here are the boot messages pertaining to the disk adapter and drive:
 > ahc0: <Adaptec 2940 SCSI adapter> rev 0x03 int a irq 11 on pci0.18.0
 > ahc0: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs
 > 
 > da0: <CONNER CFP1080S 4443> Fixed Direct Access SCSI-2 device 
 > da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
 > da0: 1030MB (2110812 512 byte sectors: 255H 63S/T 131C)
 > 
 > >How-To-Repeat:
 > 
 > halt/reboot the machine.
 
 Instead of quirking it, can you try the attached patch?  Justin and I have
 a theory on why these messages might be popping up, but we're not quite
 sure.
 
 I've tested this under -current, but the patch is against -stable, which
 should apply okay to your 3.4-RELEASE sources.  (Obviously, you'll need to
 remove or comment out your quirk to test this.)
 
 Anyway, let us know how it works.  Make sure to CC your mail to
 FreeBSD-gnats-submit@FreeBSD.ORG, so it gets in the log for this PR as
 well.
 
 Thanks,
 
 Ken
 -- 
 Kenneth Merry
 ken@kdm.org
 
 --dDRMvlgZJXvWKvBx
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="scsi_da.c.cache_sync.stable.20000120"
 
 ==== //depot/FreeBSD-ken-stable/src/sys/cam/scsi/scsi_da.c#1 - /a/ken/perforce/FreeBSD-ken-stable/src/sys/cam/scsi/scsi_da.c ====
 *** /tmp/tmp.4027.0	Thu Jan 20 21:47:33 2000
 --- /a/ken/perforce/FreeBSD-ken-stable/src/sys/cam/scsi/scsi_da.c	Thu Jan 20 21:46:25 2000
 ***************
 *** 263,268 ****
 --- 263,269 ----
   
   static SLIST_HEAD(,da_softc) softc_list;
   static struct extend_array *daperiphs;
 + static union ccb *da_shutdown_ccb;
   
   static int
   daopen(dev_t dev, int flags, int fmt, struct proc *p)
 ***************
 *** 808,814 ****
   		printf("da: Failed to alloc extend array!\n");
   		return;
   	}
 ! 	
   	/*
   	 * Install a global async callback.  This callback will
   	 * receive async callbacks like "new device found".
 --- 809,826 ----
   		printf("da: Failed to alloc extend array!\n");
   		return;
   	}
 ! 
 ! 	da_shutdown_ccb = malloc(sizeof(union ccb), M_DEVBUF, M_NOWAIT);
 ! 	if (da_shutdown_ccb == NULL) {
 ! 		/*
 ! 		 * XXX KDM should we worry about a memory leak from
 ! 		 * daperiphs here?
 ! 		 */
 ! 		printf("da: Failed to alloc shutdown CCB!\n");
 ! 		return;
 ! 	} else
 ! 		bzero(da_shutdown_ccb, sizeof(union ccb));
 ! 
   	/*
   	 * Install a global async callback.  This callback will
   	 * receive async callbacks like "new device found".
 ***************
 *** 1578,1586 ****
   
   	for (periph = TAILQ_FIRST(&dadriver.units); periph != NULL;
   	     periph = TAILQ_NEXT(periph, unit_links)) {
 ! 		union ccb ccb;
   		softc = (struct da_softc *)periph->softc;
   
   		/*
   		 * We only sync the cache if the drive is still open, and
   		 * if the drive is capable of it..
 --- 1590,1600 ----
   
   	for (periph = TAILQ_FIRST(&dadriver.units); periph != NULL;
   	     periph = TAILQ_NEXT(periph, unit_links)) {
 ! 		union ccb *ccb;
   		softc = (struct da_softc *)periph->softc;
   
 + 		ccb = da_shutdown_ccb;
 + 
   		/*
   		 * We only sync the cache if the drive is still open, and
   		 * if the drive is capable of it..
 ***************
 *** 1589,1598 ****
   		 || (softc->quirks & DA_Q_NO_SYNC_CACHE))
   			continue;
   
 ! 		xpt_setup_ccb(&ccb.ccb_h, periph->path, /*priority*/1);
   
 ! 		ccb.ccb_h.ccb_state = DA_CCB_DUMP;
 ! 		scsi_synchronize_cache(&ccb.csio,
   				       /*retries*/1,
   				       /*cbfcnp*/dadone,
   				       MSG_SIMPLE_Q_TAG,
 --- 1603,1612 ----
   		 || (softc->quirks & DA_Q_NO_SYNC_CACHE))
   			continue;
   
 ! 		xpt_setup_ccb(&ccb->ccb_h, periph->path, /*priority*/1);
   
 ! 		ccb->ccb_h.ccb_state = DA_CCB_DUMP;
 ! 		scsi_synchronize_cache(&ccb->csio,
   				       /*retries*/1,
   				       /*cbfcnp*/dadone,
   				       MSG_SIMPLE_Q_TAG,
 ***************
 *** 1601,1630 ****
   				       SSD_FULL_SIZE,
   				       5 * 60 * 1000);
   
 ! 		xpt_polled_action(&ccb);
   
 ! 		if ((ccb.ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) {
 ! 			if (((ccb.ccb_h.status & CAM_STATUS_MASK) ==
   			     CAM_SCSI_STATUS_ERROR)
 ! 			 && (ccb.csio.scsi_status == SCSI_STATUS_CHECK_COND)){
   				int error_code, sense_key, asc, ascq;
   
 ! 				scsi_extract_sense(&ccb.csio.sense_data,
   						   &error_code, &sense_key,
   						   &asc, &ascq);
   
   				if (sense_key != SSD_KEY_ILLEGAL_REQUEST)
 ! 					scsi_sense_print(&ccb.csio);
   			} else {
   				xpt_print_path(periph->path);
   				printf("Synchronize cache failed, status "
   				       "== 0x%x, scsi status == 0x%x\n",
 ! 				       ccb.ccb_h.status, ccb.csio.scsi_status);
   			}
   		}
   
 ! 		if ((ccb.ccb_h.status & CAM_DEV_QFRZN) != 0)
 ! 			cam_release_devq(ccb.ccb_h.path,
   					 /*relsim_flags*/0,
   					 /*reduction*/0,
   					 /*timeout*/0,
 --- 1615,1645 ----
   				       SSD_FULL_SIZE,
   				       5 * 60 * 1000);
   
 ! 		xpt_polled_action(ccb);
   
 ! 		if ((ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) {
 ! 			if (((ccb->ccb_h.status & CAM_STATUS_MASK) ==
   			     CAM_SCSI_STATUS_ERROR)
 ! 			 && (ccb->csio.scsi_status == SCSI_STATUS_CHECK_COND)){
   				int error_code, sense_key, asc, ascq;
   
 ! 				scsi_extract_sense(&ccb->csio.sense_data,
   						   &error_code, &sense_key,
   						   &asc, &ascq);
   
   				if (sense_key != SSD_KEY_ILLEGAL_REQUEST)
 ! 					scsi_sense_print(&ccb->csio);
   			} else {
   				xpt_print_path(periph->path);
   				printf("Synchronize cache failed, status "
   				       "== 0x%x, scsi status == 0x%x\n",
 ! 				       ccb->ccb_h.status,
 ! 				       ccb->csio.scsi_status);
   			}
   		}
   
 ! 		if ((ccb->ccb_h.status & CAM_DEV_QFRZN) != 0)
 ! 			cam_release_devq(ccb->ccb_h.path,
   					 /*relsim_flags*/0,
   					 /*reduction*/0,
   					 /*timeout*/0,
 
 --dDRMvlgZJXvWKvBx--
 

From: Andy Farkas <andyf@speednet.com.au>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/16049: Conner Drive Doesn't like syncronize cache (surprise)
Date: Fri, 21 Jan 2000 20:50:46 +1100 (EST)

 On Thu, 20 Jan 2000, Kenneth D. Merry wrote:
 
 >  > When rebooting a 3.4-RELEASE machine with a Conner drive and Adaptec
 >  > Controller, I get the following error message:
 >  > 
 >  > (da0:ahc0:0:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 
 >  > (da0:ahc0:0:0:0): ILLEGAL REQUEST asc:20,0
 >  > (da0:ahc0:0:0:0): Invalid command operation code
 >  > 
 >  > Here are the boot messages pertaining to the disk adapter and drive:
 >  > ahc0: <Adaptec 2940 SCSI adapter> rev 0x03 int a irq 11 on pci0.18.0
 >  > ahc0: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs
 >  > 
 >  > da0: <CONNER CFP1080S 4443> Fixed Direct Access SCSI-2 device 
 >  > da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
 >  > da0: 1030MB (2110812 512 byte sectors: 255H 63S/T 131C)
 >  > 
 >  > >How-To-Repeat:
 >  > 
 >  > halt/reboot the machine.
 >  
 >  Instead of quirking it, can you try the attached patch?  Justin and I have
 >  a theory on why these messages might be popping up, but we're not quite
 >  sure.
 >  
 
 I see the same error message on my system after I 'shutdown', then 'halt'.
 I have two disks on the scsi bus, but it only complains about da0.  (I see
 the _exact_ same error message as above).
 
 I applied your patch, but still see the same message. (exactly the same)
 
 What I noticed though, because my da0 (100MB) is totaly dedicated to swap,
 if I boot single-user without executing 'swapon', it would not show the
 message during reboot.  I can read/write _just_ da1, then reboot, and no
 message.  If I do a 'swapon' in single-user mode, I see the error message
 after 'halt'ing.
 
 In other words, if the controller does not access da0, I will not see a
 message.
 
 Some details:
 
 uname: FreeBSD 3.4-STABLE #0: Fri Jan 21 05:41:30 EST 2000
 
 relevent dmesg stuff:
 
 CPU: i486 DX4 (486-class CPU)
 real memory  = 33554432 (32768K bytes)
 
 ahc0: <Adaptec 284X SCSI host adapter> at 0x1c00-0x1cff irq 11 on eisa0 slot 1
 ahc0: aic7770 <= Rev C, Single Channel A, SCSI Id=7, 4/255 SCBs
 
 Probing for devices on the ISA bus:
 wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa
 wdc0: unit 0 (wd0): <DSAA-3270>, multi-block-32
 wd0: 258MB (528640 sectors), 944 cyls, 14 heads, 40 S/T, 512 B/S
 wdc0: unit 1 (wd1): <H3256-A3>, multi-block-16
 wd1: 245MB (502272 sectors), 872 cyls, 16 heads, 36 S/T, 512 B/S
 
 Waiting 15 seconds for SCSI devices to settle
 da0 at ahc0 bus 0 target 0 lun 0
 da0: <QUANTUM LP105S 910109405 3.1> Fixed Direct Access SCSI-2 device 
 da0: 4.032MB/s transfers (4.032MHz, offset 8)
 da0: 100MB (205561 512 byte sectors: 64H 32S/T 100C)
 da1 at ahc0 bus 0 target 6 lun 0
 da1: <QUANTUM XP34301 1051> Fixed Direct Access SCSI-2 device 
 da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
 da1: 4106MB (8410200 512 byte sectors: 64H 32S/T 4106C)
 changing root device to wd0s1a
 
 
 >  
 >  Ken
 >  -- 
 >  Kenneth Merry
 >  ken@kdm.org
 >  
 
 --
  
  :{ andyf@speednet.com.au
   
         Andy Farkas
     System Administrator
    Speednet Communications
  http://www.speednet.com.au/
   
 
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Mon Aug 27 13:29:45 PDT 2001 
State-Changed-Why:  

Was this issue ever resolved? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=16049 
State-Changed-From-To: feedback->closed 
State-Changed-By: jedgar 
State-Changed-When: Fri Nov 16 15:33:21 PST 2001 
State-Changed-Why:  
Feedback timeout (3 months). 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=16049 
>Unformatted:
