Date: Wed, 17 Mar 2010 22:21:38 -0300 (BRT) From: "Nenhum_de_Nos" <matheus@eternamente.info> To: freebsd-stable@freebsd.org Subject: Re: ahci errors on 8-stable Message-ID: <8e44fe1b34b8107348d2ec5d86f4d7bf.squirrel@lamneth> In-Reply-To: <4BA08DCD.1060009@omnilan.de> References: <80587c73d8c5ee56d8890d04179024b8.squirrel@cygnus.homeunix.com> <20100308222653.GA87837@icarus.home.lan> <20100308204458.9e0d51a8.matheus@eternamente.info> <4B9E6C82.8050403@omnilan.de> <cb96e5149e2c0b9a321325280d488b3e.squirrel@lamneth> <4BA08DCD.1060009@omnilan.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, March 17, 2010 05:07, Harald Schmalzbauer wrote: > Nenhum_de_Nos schrieb am 16.03.2010 02:01 (localtime): >> On Mon, March 15, 2010 14:21, Harald Schmalzbauer wrote: >>> Nenhum_de_Nos schrieb am 09.03.2010 00:44 (localtime): >>>> On Mon, 8 Mar 2010 14:26:53 -0800 >>>> Jeremy Chadwick <freebsd@jdc.parodius.com> wrote: >>>> >>>>> On Mon, Mar 08, 2010 at 06:38:02PM -0300, Nenhum_de_Nos wrote: >>>>>> I've seen these errors in a production machine in deep disk load >>>>>> (scp >>>>>> and >>>>>> bsdtar in heavy use): >>>>> Please provide the output from the following commands: >>>> As I had huge disk activity when those messages appeared, I did reboot >>>> after and now no more are there. I think the vmstat command should be >>>> issued when the problem was happening right ? (if so I can run the >>>> backup tar's and see what happens). >>> What disks do you use? >>> I have similar timeouts and mav has the hd firmware in mind to be the >>> culprit >>> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2010-02/msg00737.html >>> >>> In my case it's the samsung EcoGreen SpinPouint F2 1.5TB, Firmware >>> 1AG01113 and 1AG01118. The disk on ahcich2 (where the timeouts appear) >>> has the newer firmware. >> >> 2 Seagate 1TB disks: >> >> Mar 8 13:49:45 optimus kernel: ada1 at ahcich1 bus 0 scbus1 target 0 >> lun 0 >> Mar 8 13:49:45 optimus kernel: ada1: <ST31000528AS CC38> ATA-8 SATA 2.x >> device >> Mar 8 13:49:45 optimus kernel: ada1: 300.000MB/s transfers (SATA 2.x, >> UDMA6, PIO size 8192bytes) >> Mar 8 13:49:45 optimus kernel: ada1: Command Queueing enabled >> Mar 8 13:49:45 optimus kernel: ada1: 953869MB (1953525168 512 byte >> sectors: 16H 63S/T 16383C) >> Mar 8 13:49:45 optimus kernel: ada2 at ahcich3 bus 0 scbus3 target 0 >> lun 0 >> Mar 8 13:49:45 optimus kernel: ada2: <ST31000528AS CC38> ATA-8 SATA 2.x >> device >> Mar 8 13:49:45 optimus kernel: ada2: 300.000MB/s transfers (SATA 2.x, >> UDMA6, PIO size 8192bytes) >> Mar 8 13:49:45 optimus kernel: ada2: Command Queueing enabled >> Mar 8 13:49:45 optimus kernel: ada2: 953869MB (1953525168 512 byte >> sectors: 16H 63S/T 16383C) >> >> those are known to be bad ? > > In my experience, these are reliable drives. And completely different to > mine. So I think it's not liklely to be a firmware bug. > I hope the problem can be pointed out. If there's anything I can help, > please let me know. > > Thanks, > > -Harry thanks. but it was caused by a disk intensive script that was running to much (a cron line that said * on minute and */4 on hour). so disks were never idle. when I corrected it no more of those showed up. if needed more tests can be done :) thanks all, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8e44fe1b34b8107348d2ec5d86f4d7bf.squirrel>