From owner-freebsd-amd64@FreeBSD.ORG Sat Jun 5 10:39:49 2010 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 472BF1065672 for ; Sat, 5 Jun 2010 10:39:49 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id C3F778FC15 for ; Sat, 5 Jun 2010 10:39:48 +0000 (UTC) Received: by fxm20 with SMTP id 20so1288105fxm.13 for ; Sat, 05 Jun 2010 03:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=siCK+SmPPv56/vKOHVkTPBEbzqKbDtuOq5BtsJ9Q7Z8=; b=uRhzpVEL01+Jp/TDS1rbteKhdtz66VD7xTXMLbzG/jq3fFdOVNu0VTU0La2jugf+0n /wQX6/uyCAE9sf62ejxrdx6wQOcPy7nJT/QR72bZIOIb6z32AoWLKcZSCUbiH1LHhI1G e41zJFEQ7xpIwkG2UdzYdnuUxRKC+4PjbfH8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ekPkd6XMSb1IqedU7g0ZGHBQX8Ylv6U9Ozkm80OfMWz9H9nAisUHzPHTyyOHfEsf5+ O7wdn+gajEzoTvXCG2BlUoSVJ8FxwNJhbthBUABsI3vw7htwcrRLQdn14n3QMQx7HMTQ 2EoTbHbeicVXTTN5FgXCAp+4UDOsvgF/eWfCU= Received: by 10.223.92.154 with SMTP id r26mr12857320fam.33.1275734387648; Sat, 05 Jun 2010 03:39:47 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm9768718fad.22.2010.06.05.03.39.46 (version=SSLv3 cipher=RC4-MD5); Sat, 05 Jun 2010 03:39:47 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C0A295E.5060809@FreeBSD.org> Date: Sat, 05 Jun 2010 13:39:26 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: fbsdmail@dnswatch.com, freebsd-amd64@freebsd.org References: <4C09E783.9090007@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: why does UATA/133 == UATA/100 on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2010 10:39:49 -0000 fbsdmail@dnswatch.com wrote: > On Fri, June 4, 2010 10:58 pm, Alexander Motin wrote: >> Peter Jeremy wrote: >>> On 2010-Jun-04 16:36:08 -0700, fbsdmail@dnswatch.com wrote: >>> >>>> After _finally_ making the correct decisions to install amd64 on an >>>> AMD64 system. I was able to make/build/install world && kernel, I see >>>> a difference in drive recognition. >>> Can you please do a verbose boot and post the resultant dmesg somewhere >>> (preferably with your USB DVD drive connected). >>> >>>> kernel: ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >>>> kernel: ad6: 476940MB at ata3-master >>>> SATA300 >>>> >>>> kernel: ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >>>> kernel: ad6: setting UDMA100 >>>> kernel: ad6: 476940MB at ata3-master >>>> UDMA100 >>>> SATA 3Gb/s >>>> >>> The 'UDMA' numbers are meaningless for SATA controllers/drives. >>> >> The 'UDMA' numbers are meaningless for _native_ SATA controllers/drives. >> >> They may be not meaningless for legacy SATA devices, using SATA->PATA >> bridge inside. Some bridges do not support UDMA133 on PATA part, so ata(4) >> prefers not to use it. But in this case it is indeed meaningless. > > If it's not already apparent. The board has an AMD 880G chipset, that > provides RAID support on 6 ports @ 6GBs. Now, from a purely logistical > standpoint. The numbers _can't_ be meaningless. It's clear that the kernel > is making a "judgment call" here: kernel: ad6: setting UDMA100 It is impossible to detect SATA->PATA bridge presence, so kernel has to always follow worst scenario. But as I have said, for this particular device this value affects nothing. > The "judgment call" on both GENERIC/i386, and GENERIC/amd64 was never > made. The capability of both the port && the drive were accepted. Both > cases were booted using "verbose" (5). Please understand, I'm not > attempting to be argumentative here. I just observe this to be true. > In other words; it must have _some_ meaning - no? I have feeling that you have updated your sources while building custom kernel. I can't explain difference you have shown by other reasons. -- Alexander Motin