From owner-freebsd-sparc64@FreeBSD.ORG Thu Nov 25 03:13:24 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD82616A4CE for ; Thu, 25 Nov 2004 03:13:24 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27B1043D41 for ; Thu, 25 Nov 2004 03:13:24 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iAP3GIKq066441; Wed, 24 Nov 2004 20:16:19 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41A54DF0.10102@freebsd.org> Date: Wed, 24 Nov 2004 20:13:52 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Konieczny References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-sparc64@freebsd.org Subject: Re: 5.3 on ultra2: scsi disk not detected X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2004 03:13:24 -0000 mk@capri.pl wrote: > [...] > > Linux infinitely keeps repeating last warning. FreeBSD at least reports > few parity errors, skips the disk and goes on. > > For now I'm out of spare SCA disks, so tests stop here, but I will try > some more disks when I find them, because it's intriguing. > > FreeBSD/Ultra2 users: what disks work for you ? Are the disks exactly > what Sun describes as "compatible", or maybe something else works also ? > Not for me :( I thought SCSI is SCSI, especially considering the same > generation disks. > > Best regards, > u2# camcontrol devlist -v scbus0 on esp0 bus 0: at scbus0 target 0 lun 0 (da0,pass0) at scbus0 target 1 lun 0 (da1,pass1) at scbus0 target 6 lun 0 (cd0,pass2) < > at scbus0 target -1 lun -1 () scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) I boot FreeBSD off of da0 and NetBSD off of da1. Both can see all three devices. So it's not a problem that is related to the number of disks. My guess here, since I'm not a Solaris expert and don't know how to extract the information out of it that would be helpful, is that either your misbehaving disk is 'special' and solaris knows to do special things with it, or it's stuck in narrow mode or has a faulty pin and solaris is smart enough to deal with that. Neither FreeBSD nor Linux know how to do domain validation, so a faulty pin on the upper half of the bus would show up as a mystery parity error. A faulty pin on the lower half of the bus could interfer with selections on the other low-numbered devices, though I have no idea how solaris could compensate for this. I can hack the driver to allow you to force everything into async-narrow mode. That might help identify the problem, but it won't help much if it's a case of the drive needing special instructions that we don't understand. A SCSI bus capture would be ideal. The only other idea is that the disk is auto-terminating the bus and interfering with the termination that already exists. Again, I have no idea how solaris could compensate for this unless it's forcing everything to async, or it knows how to 'fix' the misbehaving device. Scott