Skip site navigation (1)Skip section navigation (2)
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>