Date: Mon, 20 Jun 2005 22:49:00 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: scuba@centroin.com.br Cc: freebsd-performance@FreeBSD.org Subject: Re: Slave IDE HDD not working in UDMA5 Message-ID: <20050620222051.T13863@delplex.bde.org> In-Reply-To: <Pine.BSI.4.33.0506161330290.12086-100000@hypselo.centroin.com.br> References: <Pine.BSI.4.33.0506161330290.12086-100000@hypselo.centroin.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-362250242-1119271740=:13863 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 16 Jun 2005 scuba@centroin.com.br wrote: > =09This was first posted on freebsd-question, but I could not find > the solution yet. > =09Maybe you could help me. Maybe a little. I don't use 5.4... > =09I=B4ve installed FreeBSD 5.4 on a new machine with the following > hardware: > > =09Asus P4P800 SE (BIOS v. 1008) > =092GB RAM ( 4x 512 DDR400 ) > =092 HDD Samsung SP0802N (80GB 7200rpm ata-100) 80 pins cable. > > =09The HD were formated with newfs defaults, and the following > results were the same using both as master (primary e secondary) or with = a > master / slave (same interface). > > =09With diskinfo both performance are the same, but with "dd", the > second disc (the slave or the secondary master), is always worst as if it > were working in DMA2. I remember a commit to the ata driver to fix misprogramming of DMA timing= =20 on an Intel chipset for devices and/or channels other than the first. I'm not sure if 5.4 has the bug or the fix. diskinfo only tests reading, and you only showed a dd test using writing (to a file), so the problem is apparently only that writing to the second drive is slow. > =09what should be the right results? Swap the devices to see if it is a drive problem (unlikely with the same model of drive but... I have one system that apparently has worse timing on the secondary channel. This showed up as writes causing subsequent reads to be slow -- apparently the writes caused some errors and error correction as perfect except for slowing things down). Bruce --0-362250242-1119271740=:13863--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050620222051.T13863>