Date: Tue, 29 Mar 2005 15:32:22 -0500 From: Bart Silverstrim <bsilver@chrononomicon.com> To: freebsd-questions@freebsd.org Subject: Re: Anthony's drive issues.Re: ssh password delay Message-ID: <183787faecea10b7441ee38531152aa2@chrononomicon.com> In-Reply-To: <183976925.20050329181824@wanadoo.fr> References: <1173965660.20050328020543@wanadoo.fr> <LOBBIFDAGNMAMLGJJCKNEEOOFAAA.tedm@toybox.placo.com> <1867854523.20050328120919@wanadoo.fr> <42480F8B.1060405@makeworld.com> <1407725672.20050328162134@wanadoo.fr> <6b3b25263c4e7776fd5127af2c536cd6@chrononomicon.com> <183976925.20050329181824@wanadoo.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?183787faecea10b7441ee38531152aa2>