Date: Tue, 22 Mar 2005 01:16:26 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: <freebsd-questions@freebsd.org> Subject: RE: MS Exchange server on FreeBSD? Message-ID: <LOBBIFDAGNMAMLGJJCKNKEOBFAAA.tedm@toybox.placo.com> In-Reply-To: <686409441.20050321194550@wanadoo.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
owner-freebsd-questions@freebsd.org wrote: > Ted Mittelstaedt writes: > >> The problem is you just don't want it to be a hardware problem >> because you don't accept the possibility that the NT driver wrote >> around a hardware problem and the FreeBSD driver doesen't. > > No, I don't want to run on a wild goose chase just because it hurts > someone's pride to think that FreeBSD might have a bug. > > The only thing that changed on this machine was a move from Windows NT > to FreeBSD. Therefore the source of the problem is FreeBSD. > You have no proof of that unless you were to run the tests that I already posted. Your just making a hypothesis that the problem is FreeBSD, you have no interest in testing the hypothesis to see if it is correct. The tests that I told you to make would show whether it was FreeBSD or whether it was hardware. If you go to the single Seagate disk and run that for a while, then remove the Seagate and go to a single Quantum and run that a while, and in both cases if the error messages still happen, then that is extremely compelling proof that it's FreeBSD. if by contrast the error messages go away with just the Seagate disk in there and reappear with just the Quantum disk, then that is compelling proof that the problem is the Quantum disk. Or, if the error messages go away with just the Quantum disk in there and reappear with just the Seagate disk, then that is compelling proof that it is the Seagate disk. Or if the error messages go away with just the Quantum, and if they go away with just the Seagate, then that is compelling proof that it is an incompatability with the 2 disks on the same SCSI bus. >> Despite the fact that making up for hardware problems with >> writearounds in the software drivers is a common thing in the >> industry. > > That would explain the "quirks" coding in FreeBSD, then, wouldn't it? > Or is this only bad when other operating systems do it? > All device drivers for all operating system have 'quirks' programming in them. Most of the time the quirks for different hardware are documented in the data sheets for the hardware from that manufacturer. Adaptec unfortunately does not readily release programming data. >> So you won't do the testing to prove that it is or isn't a hardware >> bug, and thus you can continue pretending to yourself that it must be >> software, and thus not your responsibility. > > Nobody here knows enough about FreeBSD to even tell me what > its messages > mean; I don't see any particular reason to knock myself out indulging > their baseless conjectures. I already went through step by step the last error messages you posted and explained to you what they meant. What you don't seem to understand is that the error messages are mostly generics and you would get most of the same error messages with many different types of problems. Most of the errors you posted show up only after the fault develops on the SCSI bus and are output as the driver resets the bus and attempts to gain back control over the targets on the bus, as a result they only tell you what you already know. (ie: that there is a problem) And the few messages output that come out when the error happens simply do not point to any single thing on the bus other than the targets suddenly lost synchronization with the initiator (the scsi card) They do not say why the targets lost synchronization. And in the case of a hardware problem, such as a bug in a disk drive microcode, or bad termination, or some such, those error messages may not show those problems, because you cannot write a software program that can detect all hardware error conditions in hardware that it must run on. It is like writing a memory testing program. Suppose the memory error is in a bit that is being used to hold the program code for the memory test program itself. As soon as you execute the memory test program it crashes before it can even test the memory and tell you there's a problem. Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LOBBIFDAGNMAMLGJJCKNKEOBFAAA.tedm>