From owner-freebsd-hackers Mon Apr 8 14:32:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA00462 for hackers-outgoing; Mon, 8 Apr 1996 14:32:37 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA00446 for ; Mon, 8 Apr 1996 14:32:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.12/8.6.6) with SMTP id PAA27236 for ; Mon, 8 Apr 1996 15:32:00 -0600 Message-Id: <199604082132.PAA27236@rover.village.org> To: hackers@freebsd.org Subject: Odd IDE problem???? Date: Mon, 08 Apr 1996 15:31:59 -0600 From: Warner Losh Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a friend who has a Packard Bell machine. This has a IDE controller built into the motherboard. When I try to boot FreeBSD 2.1R GENERIC on this, I get the following error messages: wd0: interrupt timeout: wd0: status 58 error 0 wd0: interrupt timeout: wd0: status 50 error 1 Sometimes after the fsck, sometimes during, sometimes before. these were the same errors that happened about once a fortnight under 1.1.5.1R. He's upgrading in the hopes that the situation will get better, but it hasn't. We were able to load a 2.1R image onto the disk that is telling us this on a 386 box. So we tried to slow down the kernel by putting delays in after each out. This didn't help much. We tried running bad144 on the drive, only to get an error at different points each time (sometimes at 1000ish, others at 3000ish, 6000ish, 4000ish, etc). We tried a different disk drive, same problem. We tried disabling the built in IDE controller, same problem (both disks, that work fine with a 386DX40). We swapped out the CPU and the problem still persisted, either with the builtin IDE controller, or with the one on a multi-function card that we tried earlier. Oh, and the system was billed as green, but it isn't a laptop. The drives in question are a Conner CFS420A (master) and a Conner CP30204 (Slave). All combinations of master/slave result in the same behavior. Both these disks were able to survive an install on the above 386 (with a builtin IDE controller, so we can't move it to the 486). Smells like a hardware failure to me. I thought I'd double check here to make sure before I suggested new hardware. Has anybody seen this before? Warner