MS Exchange server on FreeBSD?
tedm at toybox.placo.com
Tue Mar 22 01:16:27 PST 2005
owner-freebsd-questions at 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
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
> 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
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
More information about the freebsd-questions