[2012] in linux-scsi channel archive
Re: Intel TX chipset not yet supported by linux?
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Sun Jun 15 16:25:08 1997
Date: Sun, 15 Jun 1997 20:45:29 +0200 (MET DST)
From: Gerard Roudier <groudier@club-internet.fr>
To: Robert Johannes <rjohanne@piper.hamline.edu>
cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <33A424CD.67F1@piper.hamline.edu>
On Sun, 15 Jun 1997, Robert Johannes wrote:
> Hello,
> those of you who gave me advice and have been following my shopping
> spree on building a system from components might be interested in
> knowing the final tentative results. I've ended up buying a supermicro
> atx motherboard with the TX chipset, 64 megs of 12ns sdram which was
> only selling at about $20 more than EDO 60ns(hopefully linux won't make
> a fuss about that); the processor is the regular pentium 200/mmx, and I
> already had an ibm and adaptec 2940u scsi devices; I know alot of you
> advised on buslogic, but during a mail order spree, I got caught up in a
> tight situation with one company that I had ordered the buslogic BT-948,
> and ended up buying the adaptec 2940u for about 35 dollars less than the
> BT-948 (which is unusual because the 2940's usually sell for much more
> than the BT-948s) I don't think the aicxxx support is too terrible, and
> I'm willing to live with that until the support for it becomes standard.
I live with a Promise SCSI Ultra (875 rev. 3) and I am quite happy of it.
You could purchase similar stuff for at least $35 less in my opinion. ;-)
> The ultra-scsi IBM drive, I don't quite know what to think of it. It is
> an ultrastar 2ES, and I'm looking for information about its performance.
You probably can get some from the IBM web site. You can expect following
sustaint data rates with recent scsi hard disks, depending on the
rotationnal speed:
- 5400 -> 5-7 MB/sec
- 7200 -> 8-10 MB/sec
I typically get the following results with an Atlas II Ultra Wide using
bonnie benchmark:
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
4Kfs 300 6253 97.3 9694 34.7 4199 34.0 5917 94.5 9381 32.2 87.8 4.0
1Kfs 300 5185 94.4 8770 52.0 3345 38.0 5433 93.0 8792 41.0 51.1 2.7
> If anyone has information, please let me know. The specs of this drive
> say that it is supposed to transfer at a minimum sustained rate of 5.1
> megs/s, and up to 8 megs/s in certain positions of the drive. I've
> repeatedly tried copying a 47meg wave file, and each time the drive has
> taken 34 seconds to finish copying it. This translates to about 1.4 or
> 1.5 megs/s, and ofcourse since I'm copying the file to another partition
> of the same drive, there's twice as much activity on the scsi-bus, but
> even then if the minimum sustained rate is at least 5.1, twice as much
> activity on the bus should reduce this rate to about 2.5 megs/s; but I'm
> only getting half that. Ofcourse I don't know if copying a 47 meg file
> is a good way to time the read/write speed of a drive; I would welcome
> suggestions on how to do that.
When you copy a file from 1 partition to another one on the same disk,
you cannot get maximum throughput due to head positionning.
Given the assumed performances of your disk, you must configure your
SCSI subsystem for using at least 10 MB/sec FAST SCSI 2 data transfer.
I currently use an Atlas II Ultra Wide at 40 MB/sec data transfer
without any problem.
> The final problem, that I didn't anticipate when I was shopping for
> components is the support of the TX chipset. After I put together the
> system, (which by the way turned out to be much easier than I
> anticipated; I always thought the hardware installation was easier than
> the software installation; it was a snap to put that together, but the
> software installation is going to be a bitch.) I tried installing linux
> (redhat 4.1) and it hung over "keyboard timed out" "keyboard timout
There is no reason this problem be due to the chipset in my opinion.
> error", and I had to reset the system to start the procedure again. It
> also said something like, "unable to read the partition table" and
Not due to the chipset in my opinion. This is perhaps caused by disk IO
errors.
> "unrecognized pci device"; I'm imagining that this refers to the TX
Means that the PCI driver does not know the device_id of a PCI device.
That's harmless in my opinion but very probably refers to the chipset
as you mentioned.
> chipset which I imagine isn't yet supported by linux? I would
> appreciate somehelp if anybody would have knowledge of how to bypass
> this.
New chipset and CPUs are supposed to be compatibles with previous ones.
So, they normally are supported at least in some 'generic' mode.
Gerard.
