On Mar 29, 2005, at 11:18 AM, Anthony Atkielski wrote:
Bart Silverstrim writes:
I think, correct me if I'm wrong Ted (et al), that he's saying the microcode in the hardware was modified, thus has a bug proprietary to the HP implementation of that controller, and the driver/interface in NT either didn't get the error or was *ignoring* the error, whereas FreeBSD, with a driver/interface based on the generic and marketed version of the controller, was saying HELLO, SOMETHING ISN'T RIGHT HERE!, and spewed it to the error logs.
That is 100% guesswork. You have no idea why FreeBSD generated the error messages. If you do, then tell me _exactly_ what they mean.
It's deduction. If you want someone to pinpoint on the nailhead what is wrong without troubleshooting, go to a psychic.
If it's just a matter of all-wise FreeBSD detecting a "bug" that dopey
Windows NT missed, why were there never any problems with data loss or
corruption under NT, and why did NT never stall as a result of problems
with the disks ... and why didn't NT ever crash? FreeBSD not only spews
out error messages that nobody understands or can explain, but it
stalls, and sometimes it panics.
I'd speculate that there's a difference in the driver, but that would be just more guesswork, and since neither you nor anyone on the list is able/willing to get another system exactly like yours to install it on to rule out hardware failure (you know, *reproducing the bug*?), then I guess you're SOL.
That makes it a hardware problem, unless you modify that driver to ignore the error (like NT does) or get rid of the proprietary and/or possibly failing controller in the first place.
If it's an error you can ignored, it's not a hardware problem.
Really? I have a free program running on my NT machines, ntpdate I believe is the name, that just hammers the registry with requests constantly. I'd never have known it was querying it so much if it wasn't for regmon. *Contant* hits. dunno why, doesn't seem to hurt anything...thus I ignore it. NT doesn't seem to care. Only gets in the way when I'm troubleshooting registry errors.
I've already told you I had a scsi bus reset problem what showed up under Linux but not NT several years ago. But you probably ignored that.
If it's
a failing controller, well, it's been "failing" for eight years now, and
yet it still works.
I've had power supply fans that have lasted for years despite making odd noises that are indicative of impending failure. It's not unheard of.
Because they modify things so they're *almost* off the shelf, but aren't, perhaps?
A lot more than almost, I'm afraid.
You said previously with the microcode version that it WAS NOT off-the-shelf. It was an HP-branded firmware. When asked about the HCL, you insisted on the controller, not to my recollection the entire machine as you have it configured on the HCL. Which is it? If it lists the controller generically in the HCL, go get an off-the-shelf controller and put it in so the firmware code ISN'T proprietarily altered then start bitching the list.
Among other things they do to introduce "glitches"?
What they introduce is mainly incompatibilities. You have to do everything their way, or not at all.
What did you think I meant by glitches? Do you prefer gotchas?
If you want to keep insisting on how superior it is, then reinstall it and ignore the warnings. Why is this not an option to consider?
Because I'd rather run FreeBSD, if I could just get it to work.
That's nice. Some hardware is being a pain. People here either ignore you at this point or tell you to replace that controller and/or disks and see what it takes from there. You refuse and insist people sit down and trace the error for an eight-year-old set of hardware that has proprietary extensions. While they're at it, why don't they get FreeBSD to run on my TiVO. Just need to alter a few drivers here and there...
_______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
