Bug 16049

Summary: Connor Drive fails cache sync
Product: Base System Reporter: robert <robert>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 3.4-RELEASE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff
none
scsi_da.c.cache_sync.stable.20000120 none

Description robert 2000-01-11 05:20:01 UTC
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.
Comment 1 peter 2000-01-11 05:49:22 UTC
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
Comment 2 ken 2000-01-21 04:51:08 UTC
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
Comment 3 Andy Farkas 2000-01-21 09:50:46 UTC
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/
Comment 4 iedowse freebsd_committer freebsd_triage 2001-08-27 21:29:45 UTC
State Changed
From-To: open->feedback


Was this issue ever resolved?
Comment 5 Chris D.Faulhaber freebsd_committer freebsd_triage 2001-11-16 23:33:21 UTC
State Changed
From-To: feedback->closed

Feedback timeout (3 months).