On Mar 22, 2005, at 10:19 AM, Anthony Atkielski wrote:
Bart Silverstrim writes:
Or it gave warnings that NT didn't. Or it showed problems that NT didn't.
Unless someone can tell me what these messages mean, they are useless to
me, warnings or not.
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 don't have any T&D software for NT.
Then you could purchase some or look to see if there's shareware to run the disks through their paces.
Or you can look for a boot disk from the drive or controller manufacturer. They often have test utilities available for download.
Point is you're having trouble with FBSD and kept pining about NT working better, so the best solution (especially after the number of people you've insulted here) would be to go back to that software and see if everything is indeed copasetic under that OS with diagnostic software. You've insulted your way into the killfiles of several people here on the list so they are ignoring you...seems like Ted is the only one trying other suggestions for you at this point.
The smartctl utility looks very interesting, but I don't know to what extent I can trust it.
Um...little secret...you can't trust software 100% to diagnose problems. Just like memory testers. Just because software memory tester says it's okay, doesn't mean it's okay. If it finds a problem, you probably have a problem. If it says it's fine, it means you may have a problem.
It's just one tool.
If you want something you can trust, it costs several thousand dollars for specialized diag equipment. Be my guest :-) Usually for most people it's cheaper to just narrow down the part having problems and replace it.
I don't remember ever losing data while using DOS...
I don't recall any specific instances of that, either.
Well, with that track record, who needs FreeBSD OR Windows?? :-)
Really? Windows' problems are fixed by the benevolent leader Allchin in MS?
No, but the support organizations of major vendors don't behave like ill-mannered schoolboys when they are asked to show some responsibility for their software.
I think you could also look back at some of your own posts and see that you're not entirely innocent in the matter. Several of your posts have been inflammatory. None of the people on this list are obligated to help anyone. In general they ask for some gratitude and respect and in return give advice and pointers. On top of that, none of them forced you to use FreeBSD. If it doesn't work, try a different version or a different OS. They have no "responsibility" to their software on your hardware when you weren't forced to use it in the first place.
Or they could cover the other bases...that perhaps BSD is saying something that NT didn't report.
Rest assured, they will not do that. They will cancel the FreeBSD rollout and return to NT. And I couldn't blame them.
I don't think that was the context I was stating that in. I was giving the possibility that NT was hiding the error while FreeBSD was informing you of a potential problem. If people testing for a rollout want to roll back or go to another platform, that's their business...like I've said before the FreeBSD team isn't out to rule the world, they're just working on an OS.
Yes, obviously FreeBSD is worthless.
Not worthless ... defective. On this particular machine, the SCSI problems are too serious to allow it to be used for any kind of production. I suppose a company could just swap out hardware over and over until it got lucky. Or it could run a different OS.
Well, if it's similar to the NT idea I proposed, you could comment out the portion of the driver that reports the error, and voila'! Fixed.
I've been a bit luckier on my production machine, which has brand-new hardware. Still, I'm getting mysterious SATA errors from time to time, one of which crashed the system.
Sata is *relatively* speaking, new. And I've seen other posts about questions with SATA controllers and chipsets and support. It's being fleshed out so I'm not surprised there's problems with some. Is the SATA controller on the compat list for 5.3?
As usual, nobody has a clue as to what's causing them, and once again, the Great Satan is the hardware.
If it's new or non-tested, I'm not surprised.
Even though the only common point between the two machines is that they are running FreeBSD, somehow four separate disk drives and two controllers must be magically failing simultaneously.
Only thing in common? Despite one being "near new" and the other being "eight years old"?
One cutting edge, one legacy, if only there were a middle ground where FreeBSD seemed to be comfortable running without errors...hmmm.....
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.
Tell me the exact part that is failing when I get these SCSI errors.
Check the restarter coil. It's always troublesome in my Apple systems.
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.
People with the same hardware ARE having that problem. But nobody ever resolved it for them, either. It was the usual story about how it must be a hardware problem.
So you've narrowed it down to more likely being the software.
Is it possible that there was another reason they didn't pursue fixing that particular make and model of controller's driver?
Silently resetting without telling you?
I'm talking about the quirks that the drivers take into account for different types of hardware. FreeBSD, like many other operating systems, _does_ contain special code to workaround hardware idiosyncrasies, contrary to the implication that only Windows does this and that it is somehow a Bad Thing.
Only time I remember saying that to anyone was with working about *software* idiosyncrasies. How often do FBSD/Linux bend over backwards because someone's version of Open Office stopped running after an update?
I don't actually remember anyone saying workarounds for hardware bugs being A Bad Thing. But it's probably happened.
Or you find someone with the same hardware setup and install the OS to see if it's reproducible.
Others have already encountered this error, on the same hardware, as I recall from my newsgroup and Web searches on the subject.
In any case, finding an identical machine today would be problematic.
Which would also strengthen the argument to let it go if it were very old hardware and developers can't even *get* the hardware to test with. If you feel that strongly, contact the devel team and ask *nicely* for someone to try looking at it and send them your computer...
For most people, the effort isn't worth it; they'd get a newer server with hardware specifically on the compat list. But to each their own. Can you try the liveboot CD idea with Linux? Maybe you'd be happier with that.
_______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
