From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 12:30:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19AF216A4CE for ; Thu, 5 Feb 2004 12:30:06 -0800 (PST) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id A29D143D39 for ; Thu, 5 Feb 2004 12:29:41 -0800 (PST) (envelope-from sos@DeepCore.dk) Received: from DeepCore.dk (sos.deepcore.dk [194.192.25.130]) by spider.deepcore.dk (8.12.10/8.12.10) with ESMTP id i15KPECm059615; Thu, 5 Feb 2004 21:25:14 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <4022A77F.7070207@DeepCore.dk> Date: Thu, 05 Feb 2004 21:28:47 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20040126 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kirk Strauser References: <20040126035539.GP1456@sentex.net> <20040127162251.GA90882@afflictions.org> <87oesdcqcd.fsf@strauser.com> <40229B2C.1030005@DeepCore.dk> <87vfmlb84s.fsf@strauser.com> In-Reply-To: <87vfmlb84s.fsf@strauser.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.3 X-Mailman-Approved-At: Fri, 06 Feb 2004 05:12:59 -0800 cc: freebsd-current@freebsd.org Subject: Re: -CURRENT barfing on UDMA on Via 8233 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 20:30:06 -0000 Kirk Strauser wrote: > I no longer have the ability to do so. After running in PIO4 from September > through last week, I switched from an Asus P3V4X motherboard with a Pentium > 3/933 CPU to an Asus A7V with a Thunderbird 1.4GHz CPU, at which point the > problems disappeared completely. Note that the motherboard and CPU were, > literally, the only components replaced. I kept the same RAM, cables, power > supply, drive, case screws - everything but the mb and CPU. > > However, as of the day I made the switch (January 27) I was still unable to > operate the P3V4X in any UDMA mode with ACPI disabled. I had attempted to > run a GENERIC kernel and slow add options to match the config I had been > using until I could find which options triggered the problem. My first try > was to comment INVARIANTS* and WITNESS*, and that was enough to cause the > crashes (even with acpi disabled). I never succeeded in building a > non-freezing kernel with any combination of options that didn't include > those debugging options (which I presume stabilized the system by making it > run more slowly, and therefore less likely to overload the ATA code). Excuse my bluntness but it sounds an awfull lot like bad behaving HW to me, there has been alot of changes that make certain HW fail, ACPI is one thin APIC is another. Let me rephrase, if ATA had such severe problems noone would be able to use it. However I'm sure there are corner cases that has problems, there always will be, and I'll fix them if possible. You would not belive the amount of crappy HW out there (and no it doesn't need to be cheap to be crappy :) ), and coping with it all is very *very* tricky. Sometimes the best way to get such issues fixed is to dive in yourself and try to figure out whats wrong or gain as much info from the borked system as possible by instrumenting the code. When the problem is known, I can almost always develop a fix quickly. But if I just get "it doesn't work" and dont have semilar HW to reproduce the problem here in the lab, well I simply dont have the time to vaste on second guessing what is going wrong. -- -Søren