On Mar 22, 2005, at 4:13 AM, Anthony Atkielski 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.
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.
Or it gave warnings that NT didn't. Or it showed problems that NT didn't.
NT was more sensitive to hardware issues than Windows 9x was.
OS/2 was more sensitive to hardware issues than NT was.
Linux especially liked giving errors that NT didn't to the console.
If it worked so well, why not put NT back on the machine and try running a battery of tests and diagnostics on the machine with NT to see if it was masking a problem or not?
I never lost data at all under Windows NT, either; and Windows NT never slowed down.
I don't remember ever losing data while using DOS...
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.
Really? Windows' problems are fixed by the benevolent leader Allchin in MS?
Google for "breaking windows api" gave me a link from the past... http://security.tombom.co.uk/shatter.html. Care to tell me when they'll fix this?
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?
Or they could cover the other bases...that perhaps BSD is saying something that NT didn't report.
The OS is obviously defective, since it is the only thing that changed.
Yes, obviously FreeBSD is worthless. I don't know how Yahoo stays up, or our servers here. It's amazing.
There is no reason to look anywhere else UNTIL and UNLESS the OS is ruled.
I know that I routinely scour the OS source code for problems when one of our cobbled workstations acts up under Windows. Oh, wait, I was just reminded that usually it's a network card or video card that goes bad in old systems that prevents them from working. Or a bad memory stick, or a processor that overheated. But maybe those errors were caused by a bad Windows driver? I don't know. Just know that when I replace the part, the OS must suddenly have the bugs fixed in the source code too.
Looking at
everything else _first_ just to avoid taking responsibility for a bug in
the OS is not the way it's done.
Really? Here I thought that was called "troubleshooting", especially if the hardware in question is on the support hardware list and people on lists with the same hardware aren't having that problem.
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.
Silently resetting without telling you? Then what are the errors you're getting again?
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.
Or you find someone with the same hardware setup and install the OS to see if it's reproducible. See, if it's reproducible on a likewise-configured machine, then you start looking at the drivers. Otherwise you could have a defective piece of hardware and you're the one wasting people's time.
You obviously have no idea what's wrong; why do you continue to reply?
Because you're continuing to reply to his replies?
_______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
