Anthony's drive issues.Re: ssh password delay

[Ted Mittelstaedt]

owner-freebsd-questions at freebsd.org wrote:
> 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.
>

The dmesg you sent indicated that the 2 disks were negotiating at
different sync rates.  If you did limit them to 10mbt sync negotiation
as you stated, then why does the dmesg show them at different rates?

It seems to me that either you didn't limit them, or you did limit
them and the SCSI controller or the Quantum disk overrode the limit
anyway.  In which case it would not have had any effect.  I recall
warning that this probably wouldn't work but it was the only simple
and quick test that didn't involve cracking the case that I could
think of.  You should have seen that the limit was being ignored as
soon as you rebooted.

I also don't recall you posting the result of this test either in
which case I would have reminded you it was a long shot anyway.

>> 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.
>

Of course, because you know perfectly well that doing this would
really prove it's either the hardware or FreeBSD, and you don't want
to take the risk of it being hardware, and looking like a fool.

> 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.
>

Let's assume for the sake of argument that a SCSI guru comes over to
your house with a $100K hardware SCSI analyzer, determines it's a
bug in the Adaptec microcode, then writes in a workaround in the
driver.

You would take it as proof that the FreeBSD driver was buggy - because
it didn't contain the workaround for your buggy hardware.

In short, in your universe, the only possible thing your going to
believe is that it's a bug in the FreeBSD driver.  Even if the
bug isn't in the driver but in the hardware and the driver implements
a kludge for it.

> 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.
>

Anthony, I have had EXACTLY the same kind of problem with NT4 back in
1998
when I was working for a company named Portland Software.  (since
defunct)
In my instance it was a Pentium 200 clone motherboard with, as I recall,
an Adaptec
SCSI card in it (a relabled Future Domain controller that Adaptec
bought and sold for a few years then cancelled)  In fact, it wasn't
just 1 it was 2 of these boards in identical servers.

In one server it worked fine.  In the other, with the exact same
hardware,
controller, disks, etc. NT bluescreened when I put more than 2 SCSI disks
on the bus.  NT ran fine with 2 or 1 disks.  All 6 disks were the same
model
and mfgr.  (quantum's actually)

At the time Portland Software had not just a regular service
contract/site
license with Microsoft, they had a developers contract which allowed you
to
place calls to the extra-special tech support hotlines.  I placed my
call.
Over the next month I sent a total of 5 dumps to Microsoft, trying to get
them to tell me if it was a hardware bug or software driver bug (unlike
you,
I was willing to accept that it might of been a hardware bug despite the
fact that the motherboards, disks, and controllers were all brand new)
and if possible to write a workaround or fix into the driver.

I got exactly nowhere.  Oh sure, the tech support person claimed that the
problem had been escalated to the developer.  But they would just go away
for
a few days then e-mail requesting another dump.  Then repeat the process.
Meantime a server was tied up that I needed.  (you would not believe what
the company was using previously as a server)  Eventually I just lived
with
2 disks in the server.  (Another fix would have been to buy a different
model
of controller, no doubt)  This is EXACTLY how it is done in real life.
When you run into these bugs that you can correct by changing around
hardware, you mark it down as a hardware bug, change around the hardware,
and be done with it.  Unless that is you have infinite time to play
back-and-forth games with the software people and keep a server
quarentined
while your doing it.

That is also when I discovered how Microsoft gets away with telling the
world that they will fix any problem that you call into their
$250-and-incident
tech support people.  If you present them with a problem they cannot
figure out, they will just ask for dump after dump, over and over,
until you get tired of it and go away.  Then they mark it down to the
customer not wanting to pursue the ticket and pat themselves on the back
and claim this must mean it was never their fault to begin with.

Ted