Date: Tue, 22 Mar 2005 15:55:38 +0100 From: Anthony Atkielski <atkielski.anthony@wanadoo.fr> To: freebsd-questions@freebsd.org Subject: Re: Anthony's drive issues.Re: ssh password delay Message-ID: <772682460.20050322155538@wanadoo.fr> In-Reply-To: <LOBBIFDAGNMAMLGJJCKNMEODFAAA.tedm@toybox.placo.com> References: <1589026462.20050322120848@wanadoo.fr> <LOBBIFDAGNMAMLGJJCKNMEODFAAA.tedm@toybox.placo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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? > Then why did you say it was done differently in your earlier post? With reference to what? I note that your description of technical support organizations and mine were independently in agreement. -- Anthony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?772682460.20050322155538>