From owner-freebsd-sparc64@FreeBSD.ORG Mon Mar 25 04:31:14 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B39C2D53 for ; Mon, 25 Mar 2013 04:31:14 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) by mx1.freebsd.org (Postfix) with ESMTP id 85B448FF for ; Mon, 25 Mar 2013 04:31:14 +0000 (UTC) Received: from magrathea.distal.com (magrathea.distal.com [IPv6:2001:470:e24c:200:ea06:88ff:feca:960e]) (authenticated bits=0) by mail.distal.com (8.14.3/8.14.3) with ESMTP id r2P4V9Sj010901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 25 Mar 2013 00:31:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: CAM timeouts on Netra X1 From: Chris Ross In-Reply-To: Date: Mon, 25 Mar 2013 00:31:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "freebsd-sparc64@freebsd.org" X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.distal.com [IPv6:2001:470:e24c:200::ae25]); Mon, 25 Mar 2013 00:31:13 -0400 (EDT) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 04:31:14 -0000 After messing with this issue for a couple of hours, I'm 99% sure that = the ATA_CAM is the crux of my problem. While fixing that issue would be = the best option, I was trying a "right now" option. I'm not sure how to = build a kernel, and release.iso (or the like) without CAM. I've been = trying numerous things with modified versions of GENERIC, but am not = sure I've gotten anything working the way I want it to. Has anyone else done this sort of custom-kernel-patched-into-a-stable = sort of thing before? - Chris On Mar 24, 2013, at 21:46 , Chris Ross wrote: > Okay. I noticed both: >=20 > atapci0: port = 0x10200-0x10207,0x10218-0x1021b,0x10210-0x10217,0x10208-0x1020b,0x10220-0x= 1022f at device 13.0 on pci0 > atapci0: using PIO transfers above 137GB as workaround for 48bit DMA = access bug, expect reduced performance >=20 > and >=20 > = http://lists.freebsd.org/pipermail/freebsd-bugs/2012-January/047385.html >=20 > Perhaps it's a CAM problem where CAM isn't using PIO on the parts of = the disk it needs to? =20 >=20 > - Chris >=20 > On Mar 24, 2013, at 21:20 , Chris Ross = wrote: >> This may not be sparc64 specific, but. I have a Netra X1 that I've = been netbooting, to eventually install FreeBSD onto its disks. Booting = a recent stable/9. with the old disks (one 80G, one 250G), I would see = the following [sort] of errors during [net]boot: >>=20 >> (ada0:ata2:0:0:0): READ_DMA48. ACB: 25 00 cf cf b5 40 25 00 00 00 01 = 00 >> (ada0:ata2:0:0:0): CAM status: Command timeout >> (ada0:ata2:0:0:0): Retrying command >> (ada0:ata2:0:0:0): READ_DMA48. ACB: 25 00 cf cf b5 40 25 00 00 00 01 = 00 >> (ada0:ata2:0:0:0): CAM status: Command timeout >> (ada0:ata2:0:0:0): Retrying command >> (ada0:ata2:0:0:0): READ_DMA48. ACB: 25 00 cf cf b5 40 25 00 00 00 01 = 00 >> (ada0:ata2:0:0:0): CAM status: Command timeout >> (ada0:ata2:0:0:0): Retrying command >> (ada0:ata2:0:0:0): READ_DMA48. ACB: 25 00 cf cf b5 40 25 00 00 00 01 = 00 >> (ada0:ata2:0:0:0): CAM status: Command timeout >> (ada0:ata2:0:0:0): Retrying command >> (ada0:ata2:0:0:0): READ_DMA48. ACB: 25 00 cf cf b5 40 25 00 00 00 01 = 00 >> (ada0:ata2:0:0:0): CAM status: Command timeout >> (ada0:ata2:0:0:0): Error 5, Retries exhausted >>=20 >> In the past, with the old disks, it was ada1, not ada0, and that was = the 250G disk that has been reporting errors when the system was running = off of it (NetBSD 5.1). So I assumed that was the problem. However, = I've replaced the disks with a pair of 320GB disks, and am now having = that same problem and messages both during boot, and when trying to = configure the disks with gpart, for both disks. >>=20 >> Is this some sort of size issue? And, is there any way around it? = NetBSD works on the machine, so I assume it's not that the hardware is = deficient in some way with larger PATA disks... >>=20 >> - Chris >>=20 >> _______________________________________________ >> freebsd-sparc64@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 >> To unsubscribe, send any mail to = "freebsd-sparc64-unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to = "freebsd-sparc64-unsubscribe@freebsd.org"