From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: Errors when copying between drives on a SiI3114 controller under kernel 2.6.18 Date: Sat, 14 Oct 2006 21:13:40 +0900 Message-ID: <4530D474.6000609@gmail.com> References: <45287FA6.5020906@gmail.com> <452A0A86.8070107@gmail.com> <452A0BA6.8030401@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from nf-out-0910.google.com ([64.233.182.190]:21441 "EHLO nf-out-0910.google.com") by vger.kernel.org with ESMTP id S932191AbWJNMNu (ORCPT ); Sat, 14 Oct 2006 08:13:50 -0400 Received: by nf-out-0910.google.com with SMTP id c2so283749nfe for ; Sat, 14 Oct 2006 05:13:48 -0700 (PDT) In-Reply-To: Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Jonathan Bell Cc: "linux-ide@vger.kernel.org" , Carlos Pardo [cc'ing Carlos again. please don't drop cc list] Jonathan Bell wrote: > On Mon, 09 Oct 2006 15:49:26 +0100, Jonathan Bell > wrote: > >> On Mon, 09 Oct 2006 09:43:18 +0100, Tejun Heo wrote: >> >>> Tejun Heo wrote: >>>> I cannot reproduce your problem here. Can you retest after running >>>> the following commands? >>>> # setpci -s 01:07.0 0c.b=04 >>>> # setpci -s 01:08.0 0c.b=04 >>> >>> I forgot something. >>> >>> * You need to make sata_sil a module. Boot, unload sata_sil if >>> loaded, run above commands, load sata_sil and test. >>> >>> * If above commands don't work, try =00 instead of =04. >>> >>> Thanks. >> >> setpci -s 01:07/8.0 0c.b=04 performed, sata_sil inserted... >> >> md5sum crapped out again, similar errors in dmesg as before. >> >> setpci -s 01:07/8.0 0c.b=00 performed, sata_sil inserted... >> >> It worked... >> cp ~/hugefile /mnt/sda1 && cp /mnt/sda1/hugefile /mnt/sdb1 >> && md5sum /mnt/sda1/hugefile /mnt/sdb1/hugefile >> >> ccf5f9052aa1fac3062c3f1920abb1fc /mnt/sda1/hugefile >> ccf5f9052aa1fac3062c3f1920abb1fc /mnt/sdb1/hugefile >> >> What does this register do, out of interest? With 00 it took ages and >> made my load average shoot up to about 6.50! > > Apologies for bumping this a mere 2 days later but I felt that progress > was being made... > > Ok, so it's the PCI cache line size register... 08 means a value of 64 > bits which corresponds to the line size of my L1/L2 cache, am I correct? Yes, you're right. > The fact that even with a value of 01 set (for fun) still corrupts the > file seems to indicate that the fault is somewhere there, but why? > Should I just give up and buy a decent mainboard? :P (currently running > A7N8X-Deluxe v2.0, latest 1008 BIOS) I'm not sure whether the cache line size is the actual problem or the slowdown caused by 0 cacheline size (r/w optimizations based on cacheline size are turned off) hides the problem. I was hoping BIOS messed up while setting cachline size and adjusting it to 4 makes things work. > I would like to know more about this since the only topics on PCI cache > line sizes I can find are ones where people are having problems. I don't know. I think this can be best diagnosed by SIMG. Carlos, does anything ring a bell? Thanks. -- tejun