Anthony's drive issues.Re: ssh password delay

Ted Mittelstaedt tedm at toybox.placo.com
Wed Mar 23 01:41:20 PST 2005


owner-freebsd-questions at freebsd.org wrote:
> Ted Mittelstaedt writes:
>
>> OK, well then that increases the chances that it is a driver issue
>> and reduces the chances that it is a hardware issue.  Assuming your
>> termination is correct, that would increase chances it is a driver
>> issue even more.
>
> That's rather what I've thought all along.
>
>> Going to each single disk is what you really need to do now in order
>> to make a definite finger point to the driver.
>
> To each single disk?  What do you mean?
>

What I mean is temporarily pull the Quantum disk, load a scratch system
on the Seagate, run some disk testing utility or some such that beats on
the disk, and see if you get errors.

Then repeat the process with just the Quantum in the system.

What that tells you is the following:

1) If the seagate runs fine and the quantum errors, it's an
incompatibility
between the quantum and the adaptec.  Someone may be able to write around
the problem in the driver code, but most likely the driver developer will
not be able to do this.  Submit a send-pr as a bug mainly to archive the
problem
in case someone else has a similar problem in the future, and find
another Seagate
disk to replace the Quantum.

2) If the quantum runs fine and the seagate errors, it's an
incompatibility
between the seagate and the adaptec.  Someone may be able to write around
the problem in the driver code, but most likely the driver developer will
not be able to do this.  Submit a send-pr as a bug mainly to archive the
problem
in case someone else has a similar problem in the future, and find
another Quantum
disk to replace the Seagate.

3) If both run fine individually then it's an incompatibility
between the Seagate and the Quantum. Someone may be able to write around
the problem in the driver code, but most likely the driver developer will
not be able to do this.  Submit a send-pr as a bug mainly to archive the
problem
in case someone else has a similar problem in the future, and play
musical
disks with your other systems to get both disks the same manufacturer.

4) If they both error then it's a problem between the SCSI adapter and
the
FreeBSD driver.  Submit a send-pr as a bug.  This is most likely to be
looked at by the developer.

> I tried a build of the kernel again today, to exercise the
> machine.  For
> quite a while it behaved, but then the SCSI errors popped up again.
> At least it didn't crash.
>
>> I have been working on a Compaq Professional workstation from time
>> to time to setup a test workstation over the last week.  It has a
>> problem where under heavy use it will corrupt files written and read
>> from the disk.  This system was always a Windows box before, using
>> a 1GB Seagate disk drive.  (don't ask why Compaq would supply a 1GB
>> disk it is rediculous)  Here are some relevant bits of the dmesg
>> that might interest you:
>>
>> .
>> .
>> CPU: Pentium Pro (199.31-MHz 686-class CPU)
>>   Origin = "GenuineIntel"  Id = 0x619  Stepping = 9
>>
>>
> Features=0xf9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE
> ,MCA,CMOV>
>> .
>> .
>> ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0x1000-0x10ff mem
>> 0x40080000-0x40080fff irq 11 at device 18.0 on pci0
>> aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs .
>> .
>> da0 at ahc0 bus 0 target 0 lun 0
>> da0: <QUANTUM FIREBALL SE8.4S PJ09> Fixed Direct Access SCSI-2 device
>> da0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing
>> Enabled da0: 8191MB (16777215 512 byte sectors: 255H 63S/T 1044C)
>
> Looks familiar.
>
>> Now I can say one thing with certainty with this machine - Compaq has
>> definitely modded the Adaptec microcode used on the controller here.
>> Why do I know this? I know it because I tried removing the 2940 card
>> from this machine and plugging it into another non-Compaq machine,
>> and the card would not boot the disk in that system. However, a
>> non-Compaq-labeled 2940 card works fine in that system.
>
> Compaq has a terrible reputation for screwing around with standard
> hardware and firmware.  I've always felt that they could still build
> good servers even without all their home-baked junk, but they
> apparently felt differently.  I like commodity hardware and firmware.
> It's very hard today to justify custom stuff just to gain perhaps a
> few scant percent of performance under highly specific conditions.
>
>> I had assumed the problem with this system was bad ram. But, I think
>> I am going to try pulling that Quantum disk out of there and
>> using a different one.
>
> You think something on the drive itself is different?
>

I just want to see if perhaps a different manufacturer's hard disk will
work OK.  I already know they modded the microcode there's a chance
they did it wrong.  There's also a chance they didn't test with one
of the disks I put in there.

Ted



More information about the freebsd-questions mailing list