From owner-freebsd-questions@FreeBSD.ORG Tue Mar 22 16:00:29 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B37BA16A4D0 for ; Tue, 22 Mar 2005 16:00:29 +0000 (GMT) Received: from trans-warp.net (hyperion.trans-warp.net [216.37.208.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45D8E43D5A for ; Tue, 22 Mar 2005 16:00:16 +0000 (GMT) (envelope-from bsilver@chrononomicon.com) Received: from [127.0.0.1] (unverified [65.193.73.208]) by trans-warp.net (SurgeMail 2.2g3) with ESMTP id 744795 for ; Tue, 22 Mar 2005 11:00:19 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <7310064775.20050322163748@wanadoo.fr> References: <423E116D.50805@usmstudent.com> <423EEE60.2050205@dial.pipex.com> <18510151385.20050321193911@wanadoo.fr> <1975192207.20050322041925@wanadoo.fr> <1688160068.20050322102514@wanadoo.fr> <334ed8bd3d1e5ee9582b706d65919fb4@chrononomicon.com> <7310064775.20050322163748@wanadoo.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6ec0c1f6a3e49f41d839a641d6bd5046@chrononomicon.com> Content-Transfer-Encoding: 7bit From: Bart Silverstrim Date: Tue, 22 Mar 2005 11:00:11 -0500 To: freebsd-questions@freebsd.org X-Mailer: Apple Mail (2.619.2) X-Server: High Performance Mail Server - http://surgemail.com X-Authenticated-User: bsilver@chrononomicon.com X-DNS-Paranoid: DNS ptr lookup of (65.193.73.208) failed Subject: Re: Anthony's drive issues.Re: ssh password delay X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2005 16:00:30 -0000 On Mar 22, 2005, at 10:37 AM, Anthony Atkielski wrote: > Bart Silverstrim writes: > >> Depends on the problem. Windows 98 needed more reboots than NT did on >> the same hardware. By your comparison they should be the same in >> reliability and performance, no? > > No, by my comparison they should experience the same hardware errors > (or > absence thereof). Not if one of them suppresses errors (or crashes) instead. >> Actually I think he suggested that NT was hiding the problem. > > Fine. What exactly _is_ the problem? FreeBSD is certainly spewing no > end of output to the console about it, but nobody seems to know what it > means. *I*'m not a developer. I'm just a FreeBSD user who keeps trying to get you to see that insulting people on the list is *definitely* not going to help your cause, and that maybe there are other things to consider, despite the off-list emails I've gotten saying you're a hopeless cause who at this point is just trolling and baiting people. The best advice I gave was trying a liveboot CD or some other distro, or alternatively commenting out the code that spews the error so you can ignore the error again so it was like things were with NT, or contact the devel team and ask about the offending code there. >> Is anyone on this list running a twenty year old version of UNIX on >> their system? Most are running something of at least the 4.x line of >> FreeBSD, I thought... > > Unless 4.x was a total rewrite from scratch with a design completely > different from that of UNIX, it's more than twenty years old. Holy crap no wonder your SATA controller doesn't work. >> You tried it, you didn't like it, reinstall NT and see if diagnostic >> software turns anything up and if not then see if the hardware >> continues to run hunky-dory for the next year or so without failing. >> No harm, no foul. > > I didn't say I didn't like it, I said that it has trouble dealing with > my SCSI disks. *sigh* Is there any way for you to disable the onboard SCSI and use a newer controller, maybe two same-brand same-model drives and see if that fixes your problem? >> Usually the first one I've heard is to check the compatibility list, >> because that's hardware that it's been tested on. Your hardware is on >> the list? > > Yes. Now, you've said the chipset...is it the actual hardware you have (HP you said?), where the system's been tested with any changes that company may have made to the firmware? Does anyone know of a way for Anthony to have a trace run of the driver to see where this error is being spit out and why?