Date: Thu, 05 Feb 2004 21:28:47 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk> To: Kirk Strauser <kirk@strauser.com> Cc: freebsd-current@freebsd.org Subject: Re: -CURRENT barfing on UDMA on Via 8233 Message-ID: <4022A77F.7070207@DeepCore.dk> In-Reply-To: <87vfmlb84s.fsf@strauser.com> References: <20040126035539.GP1456@sentex.net> <20040127162251.GA90882@afflictions.org> <87oesdcqcd.fsf@strauser.com> <40229B2C.1030005@DeepCore.dk> <87vfmlb84s.fsf@strauser.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. <RANT MODE> 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. </RANT MODE> -- -Søren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4022A77F.7070207>