Anthony's drive issues.Re: ssh password delay

[Anthony Atkielski]

Ted Mittelstaedt writes:

> I have told him to go into his Vectra BIOS and limit the sync negotiation
> on both disk drives to the same speed - 10Mbt.  He refuses to try doing
> this.

You're incorrect.  I have _already_ done it, at your suggestion; it had
no effect, as I expected.

> I've also told him to remove the Quantum and try running a FreeBSD system
> off the Seagate, to see if it errors with just the single Seagate drive
> on it.  He refuses to do that either.

I'm not going to take the machine apart just to eliminate every other
possible cause in the universe before blaming it on FreeBSD.

Only one thing has changed in this machine: I replaced Windows NT with
FreeBSD.  Windows NT had no problem with the SCSI drives; FreeBSD has a
problem with them.  Therefore FreeBSD is defective.

> The basic problem is that Anthony has an error that is non-damaging to
> his data - every once in a while the machine spews a bunch of SCSI
> errors, resets the bus and everything on it, things slow down for a
> moment, then life continues. He has by his admission, not lost data -
> yet.

I never lost data at all under Windows NT, either; and Windows NT never
slowed down.

> So the summary of it is that IMHO he LIKES things the way they are -
> it's been happening enough so that he's not afraid of losing data
> anymore, yet it gives him an error he can wave around every time he
> wants to knock FreeBSD's drivers. He isn't really interested in
> finding the root of the problem or isolating it to either a
> controller, a disk, or a software driver issue. Instead he thinks that
> the SCSI driver author can just wave a wand, and look at a non-debug
> output of the error messages, and magically know exactly what
> workaround to stick in the driver to make the error messages go away.

All I know, is that nobody who has replied to my questions is competent
or energetic enough to actually find the bug in FreeBSD.  You can argue
all you want about that, but it's precisely this sort of attitude that
prevents operating systems like FreeBSD from being adopted on a large
scale in many organizations.  If they delete NT to try FreeBSD, and
FreeBSD generates a raft of errors that NT never did, and all anyone
involved with the product can say is "it's your hardware!" do you think
that they're going to keep using FreeBSD?  The OS is obviously
defective, since it is the only thing that changed.  There is no reason
to look anywhere else UNTIL and UNLESS the OS is ruled.  Looking at
everything else _first_ just to avoid taking responsibility for a bug in
the OS is not the way it's done.

> For all we know the SCSI device driver under Windows NT ran into the
> exact same error - and simply did the bus reset silently, without
> informing the user. That would be completely in character with how
> Microsoft approaches things (ie: if it doesen't kill the system the
> user doesen't need to know about it)

That's how FreeBSD does it, too, based on the snippets of code I've
looked at.

> As I have told him before the only way to find the error is to install
> a SCSI analyzer onto the SCSI bus, and only Adaptec and the disk drive
> manufacturers have such a tool - and if one did, they would almost
> certainly find out it is some kind of low-level timing od SCSI command
> set implementation issue that would need a correction in either the
> Adaptec controller microcode, or one of the disk drive's microcode -
> and you could identify which disk it was a lot simpler and quicker by
> just doing the troubleshooting suggestions that have already been
> given to him. Besides which, a half hour of time on such a tool would
> probably cost more than the price of a brand new server.

No, the only way to find the error is to find someone who knows the
FreeBSD code and is competent and willing to discuss the problem,
instead of people who spend their time blowing smoke in order to avoid
admitting that they haven't a ghost of a clue as to what the problem is.

You obviously have no idea what's wrong; why do you continue to reply?

-- 
Anthony