Date: Wed, 19 Nov 2008 13:16:33 +0100 From: Jan Sebosik <sebosik@demax.sk> To: Jeremy Chadwick <koitsu@FreeBSD.org> Cc: freebsd-hardware@freebsd.org Subject: Re: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] Message-ID: <492403A1.60209@demax.sk> In-Reply-To: <20081119115311.GA85626@icarus.home.lan> References: <4923E5A2.2060402@demax.sk> <20081119101530.GA82861@icarus.home.lan> <4923E839.7090001@demax.sk> <20081119102552.GA83022@icarus.home.lan> <4923F0A6.9080304@demax.sk> <20081119112102.GA84963@icarus.home.lan> <4923F7D5.8030409@demax.sk> <4923F928.8010604@demax.sk> <4923FA30.5000303@modulus.org> <4923FB4D.7090505@demax.sk> <20081119115311.GA85626@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeremy Chadwick napsal(a): > On Wed, Nov 19, 2008 at 12:41:01PM +0100, Jan Sebosik wrote: >> Andrew Snow napsal(a): >>> Hi >>> >>> I have a P45 chipset but haven't noticed those problems. I use AHCI >>> mode because it enabled hotswap SATA. >>> >>> But do you also get error messages on the console about timecount going >>> backwards for some processes? I can't make it go away, even if I force >>> HPET as a counter >>> >>> - Andrew >> Hi >> >> obviously no, I don`t get any messages about time going backwards. >> >> I`ve also tryied AHCI mode, but after some mailing with Intel technical >> support they claimed to downgrade to native SATA mode (non-AHCI >> operation). > > Andrew: > > "Time going backwards" is known to happen on certain systems which use > features like Intel SpeedStep. I can reproduce the problem on all sorts > of server hardware. It's documented in my Wiki under "Kernel": > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > Power-save modes such as C1E might also cause it, but I've enabled this > on systems without any repercussions. Just EIST appears to behave > oddly, on RELENG_7. (I've tried EIST on CURRENT, and it seems to behave > better. I remember reading about major improvements jhb@ completed > there which might explain CURRENT working) > > Jan: > > (Quoting you from your misplaced mail to -stable) > >> I thought also about bios bug... it`s pretty new piece of HW with modern >> chipset (Q45). I believe that the next release of BIOS comes soon. > > The chipset has nothing to do with it. I can show you two identical > systems, chipset-wise, and show you BIOS bugs. The system manufacturer > is who maintains the BIOS, not the chipset manufacturer. Thanks for explanation. >> But what about those atapicd problems? Is it related to SATA interface >> of DVD/CD drive? Maybe also the LG drive has buggy FW :). > > Now I'm confused. Didn't we just determine that your acd0 problems > disappear if you disable HPET in the BIOS (which makes no sense, but it > works, and is probably a BIOS bug)? If so, then what's that got to do > with SATA interfaces or LG optical drives? Please help me understand. No, atapicd problems are still there regardless of HPET setting. But with HPET enabled, when I kldload atapicd and then try to mount it with command "mount -t cd9660 /dev/acd0 /mnt/cd0", I get neverending "READ_BIG FAILURE" timeouts. -- Jan Sebosik, Slovakia sebosik@demax.sk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?492403A1.60209>