Date: Sat, 05 Jun 2010 13:39:26 +0300 From: Alexander Motin <mav@FreeBSD.org> To: fbsdmail@dnswatch.com, freebsd-amd64@freebsd.org Subject: Re: why does UATA/133 == UATA/100 on amd64? Message-ID: <4C0A295E.5060809@FreeBSD.org> In-Reply-To: <mailpost.1275720417.6581091.46630.mailing.freebsd.amd64@FreeBSD.cs.nctu.edu.tw> References: <4C09E783.9090007@FreeBSD.org> <mailpost.1275720417.6581091.46630.mailing.freebsd.amd64@FreeBSD.cs.nctu.edu.tw>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <Seagate ST3500630AS 3.AAK> at ata3-master >>>> SATA300 >>>> >>>> kernel: ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >>>> kernel: ad6: setting UDMA100 >>>> kernel: ad6: 476940MB <Seagate ST3500630AS 3.AAK> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C0A295E.5060809>