From owner-freebsd-hackers Sun Jan 26 14:16:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27945 for hackers-outgoing; Sun, 26 Jan 1997 14:16:46 -0800 (PST) Received: from jason.garman.net (pm106-09.dialip.mich.net [192.195.231.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA27931 for ; Sun, 26 Jan 1997 14:16:32 -0800 (PST) Received: (qmail 363 invoked by uid 1000); 26 Jan 1997 22:16:25 -0000 Message-ID: Date: Sun, 26 Jan 1997 17:16:25 -0500 From: garman@jason.garman.net (Jason Garman) To: terry@lambert.org (Terry Lambert) Cc: freebsd-hackers@freebsd.org Subject: Re: CMD640b ide controller bug workarounds? References: <199701261958.MAA02186@phaeton.artisoft.com> X-Mailer: Mutt 0.58 Mime-Version: 1.0 Reply-To: garman@phs.k12.ar.us X-Phase-Of-Moon: The Moon is Waning Gibbous (91% of Full) X-Operating-System: FreeBSD/i386 2.1.5-RELEASE In-Reply-To: <199701261958.MAA02186@phaeton.artisoft.com>; from Terry Lambert on Jan 26, 1997 12:58:33 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > There are two check programs. You need to search for "+IDE +CMD640" on > AltaVista. > EIDEtest (if that's the other one you're referring to) simply asks you to do background I/O operations on, say, the second interface drives while the program does I/O on the first interface... since that causes the machine to freeze, the same would happen here. The old rztest program that Intel put out at the beginning of all this mess didn't even test for this particular flaw, because it doesn't exist in the RZ1000 chip that it checked for. Regarding automatic detection mechanisms- FreeBSD already notices that I have the flawed chip: ... *** pci0:12: CMD, device=0x0640, class=storage (ide) int a irq 14 [no driver assigned] ... wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 696MB (1427328 sectors), 1416 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (atapi): , removable, accel, dma, iordy wcd0: 344Kb/sec, 256Kb cache, audio play, 256 volume levels, ejectable tray wcd0: medium type unknown, unlocked wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (wd2): wd2: 1916MB (3924144 sectors), 3893 cyls, 16 heads, 63 S/T, 512 B/S And as for L*nux, looking through AltaVista's search results for the query you gave me, it seems that L*nux _does_ automatically and non-destructively detect and work around the CMD 640b bugs. (no hda=serialize needed after all, apparently) Detecting a VLB board using this chip would be harder (is it even possible)? Enjoy, -- Jason Garman http://www.nesc.k12.ar.us/~garman/ Student, Eleanor Roosevelt High School garman@phs.k12.ar.us