Date: Mon, 28 Feb 2005 21:14:33 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: <freebsd-questions@freebsd.org> Subject: RE: Installation instructions for Firefox somewhere? Message-ID: <LOBBIFDAGNMAMLGJJCKNEEJEFAAA.tedm@toybox.placo.com> In-Reply-To: <956831073.20050228205253@wanadoo.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
owner-freebsd-questions@freebsd.org wrote: > Ted Mittelstaedt writes: > >> I agree Ramiro, I've setup dozens and dozens of different SCSI >> setups, and I think that his problem is hardware, such as incorrect >> termination, a bad scsi cable, bad connectors on the cable, or an >> incompatible SCSI/disk combination (which is rare, but it does >> happen) > > No. The machine ran flawlessly for eight years with the > current hardware > configuration, no errors, no data loss, even under the heaviest loads. > There's nothing wrong with the hardware. > But that was under NT I understand, using NT drivers, right? The SCSI standard is pretty big and there's been a lot of go-fast stuff added into it, and a lot of vendors have done lots of different things to their adapter cards to make them go fast. Such as adding support for tagged commands. It is entirely up to the writer of the SCSI device driver whether or not he wants to support the extra go-fast stuff. FreeBSD because of it's nature in use as a server on high-quality hardware, it's drivers tend to take advantage of every last scrap of go-fast hardware available (unless such hardware is hopeless) A great example is the ed0 driver and it's support for the 3com 3c503 card - this card can be run in either PIO mode or shared memory mode - guess which mode the ed0 driver uses? Even though the wd8013 and 3c503 are the only 2 cards out of the bazillions of ne2000 clones that support this mode. You get a gain of perhaps 5% so they go for it. I wouldn't put it past the NT driver author of your SCSI card, in an effort to avoid problems, to have written the NT driver so that ALL transactions on the SCSI bus are asynchronous. Sure this kills your throughput on the SCSI bus - but with 4GB narrow scsi disks, who is going to notice? It greatly reduces support calls because async mode is so slow that even badly terminated SCSI busses will work - thus nobody with a crapped up SCSI cable is calling Microsoft and yelling because their server crashes. Anyway, if this is it, you will not have been the first person with iffy hardware that worked fine under Windows to have it break under FreeBSD. I just had a machine do this to me Friday - a Pentium Pro 150 - but I managed to guess at a change to a BIOS setting that fixed the problem. Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LOBBIFDAGNMAMLGJJCKNEEJEFAAA.tedm>