Linux-Hardware Digest #750, Volume #10 Tue, 13 Jul 99 09:14:12 EDT
Contents:
UMAX Scanner (Renzo Lauper)
Re: SCSI controller/device advice (Helge Hafting)
Re: FWD: Intel could nip dual-Celeron move in bud (Helge Hafting)
Help with Sound Card ("Brian")
NCR 53C710 Fast SCSI-2 Controller ("Mike Coakley")
Re: NTFS Striped Partitions (Helge Hafting)
Re: Bogus hard disk sizes from manufacturers (David Fox)
Re: Linux/KDE; KDat backup on dat tape proggy (Marc SCHAEFER)
Re: Help with Sound Card ("ph")
Re: Celeron, what's the catch? (kls)
----------------------------------------------------------------------------
From: Renzo Lauper <[EMAIL PROTECTED]>
Subject: UMAX Scanner
Date: Tue, 13 Jul 1999 12:16:07 +0200
Hi there
I've got a UMAX Astra 1220S Scanner connected through a SCSI Card (generic NCR
5380/53c400). I compiled the kernel (2.0.36) with SCSI-Support (built in the
kernel) SCSI-disk-Support (for an external ZIP-Drive) as a modul, SCSI
generic support and the SCSI low level driver for generic NCR 5380/53c400.
When I built support for the SCSI-Card Support in the kernel, the system
stopped when it came to recognize the SCSI-Card, so I built it as a module and
loaded the module with insmod, and the system stopped again.
Can anybody help me?
Thanks in advance
Renzo Lauper
------------------------------
From: Helge Hafting <[EMAIL PROTECTED]>
Subject: Re: SCSI controller/device advice
Date: Tue, 13 Jul 1999 12:58:41 +0200
[EMAIL PROTECTED] wrote:
>
> In <7m4tid$ik3$[EMAIL PROTECTED]>, Chris <[EMAIL PROTECTED]> writes:
> |
> |
> |Phil Brutsche wrote:
> |
> || On Tue, 30 Mar 1999, Dave wrote:
> |
> ||
> |
> || > Thanks for the advice! I've also heard a _lot_ of people recommending
> |
> |the
> |
> || > IBM drives.
> |
> |
> |
> |I'll recommend them, too. I'm planning on purchasing the 9.1GB 9LP...
> |
> |
> |
> || > I'm still trying to decide between the Quantum Atlas III drive and the
> |
> |IBM
> |
> || > Ultrastar 9ES though. The Ultrastar looks excellent, and about the same
> |
> || > price as the Quantum drives. However it only has a 512KB buffer, as
> |
> || > opposed to the Quantum's 1MB. The IBM drives with 1MB (such as the 9LP)
> |
> || > appear to be about $200 more.
> |
> || >
> |
> || > Is the extra 512KB buffer worth it to go Quantum for the price? Or is
> |
> |the
> |
> || > performance increase negligible?
> |
> |
> |
> |Actually, if you head over to http://www.storagereview.com they did a
> |
> |comparison review of two almost identical IDE drives (make/manuf. escapes
> |
> |me) from the same manufacturer, where the only thing different was an
> |
> |increased cache.
> |
> |
> |
> |The performance did not change ONE BIT.
> |
> |
> |
> |I'm going to have to poke around to see if the 9ES would be sufficient...
> |
> |The storagereview site also allows you to do lots of side by side
> |
> |comparisons of drives they've reviewed. It's a fun thing to do.
> |
> |
> |
> |ttfn.
> |
> |
> |
> |chris.
> |
> |------------------ Posted via SearchLinux ------------------
> | http://www.searchlinux.com
>
> How effective the drive's on board cache will be is determined by
> YOUR data access characteristics, most tests do not use
> YOUR data access characteristics; so, draw your own conclusions...
>
> Large cache helps when most data access is sequential, so that the
> read ahead of full/multiple tracks will actually bring in what you
> need next. Also, a larger cache allows things that will will be
> re-read frequently to stay in the cache. This is especially useful
> in a multi-tasking environment where competing tasks might cause
> the smaller cache to thrash.
For SCSI, the large cache *also* help very random-access. Just
make sure you use tagged queuing. The drive will then be able to
read the next sector(s) (from any place on disk) into its cache
while the previous one is transferred across the scsi bus.
Helge Hafting
------------------------------
From: Helge Hafting <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: FWD: Intel could nip dual-Celeron move in bud
Date: Tue, 13 Jul 1999 13:07:24 +0200
Anon wrote:
>
> Why on earth would Intel care!? Selling two celerons is better than
> selling one. A person who has to go celeron for SMP more than likely
> could not afford PII/III SMP in the first place so it is not like Intel
> would be forcing them to the more expensive CPU. They would just be
> losing the sale of 1 cpu.
It is not that simple. They are afraid their buyers might find out that
while celeron isn't as good as xeon, it isn't too far behind. So
the celeron has better price/performance than xeon, and it makes sense
using, say, 5 celeron servers instead of 3 xeon servers. Cheaper
*and* better performance if it is ok to split the load over more
machines.
That's certainly fine for file servers.
Helge Hafting
------------------------------
Reply-To: "Brian" <[EMAIL PROTECTED]>
From: "Brian" <[EMAIL PROTECTED]>
Subject: Help with Sound Card
Date: Tue, 13 Jul 1999 11:32:49 GMT
I am using redhat 5.2 with the kernel 2.0.36
I am having trouble with my sound card.
It is a ESS with full Adlib, Sound Blaster and Sound Blaster Pro
compatibility as well as plug and pray.
This information came from my windows setup:
ES1869 Plug and Play AudioDrive
IRQ: 05
I/O: 0220h-022FH
I/O: 0388h-038Bh
I/O: 0330h-0331h
DMA:01
DMA:03
When I try to set it up I get this error:
/lib/modules/preferred/misc/sb.o:init_module:Device or resource busy
sound:Device or resource busy
Can anyone help?
I am new to linux so please excuse my lack of knowledge.
Thank you in advance.
------------------------------
From: "Mike Coakley" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.system
Subject: NCR 53C710 Fast SCSI-2 Controller
Date: Tue, 13 Jul 1999 07:48:34 -0400
I am having trouble installing a RedHat 6.0 installation onto a Compaq
Proliant 4000 with the NCR53C710 controller. The installation simply cannot
find the controller and cannot continue without it. (I know I shouldn't be
saying this...) I can install MS WinNT without any problems and the
controller is recognized and the system boots off of this controller/HD.
Does anyone out there have any ideas?
Mike
------------------------------
From: Helge Hafting <[EMAIL PROTECTED]>
Subject: Re: NTFS Striped Partitions
Date: Tue, 13 Jul 1999 13:55:46 +0200
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> Linux is my last idea to solve our problem. So please answer if you
> have any idea
>
> I read all the How Tows in Linux carefully and found no hint on my
> prob
>
> We used to have a NT Server 4.0 Service Pack 3 with two hard disks
> using striped partitions (non parity) running in our company (for the
> last time I swear). After a crash NT had to be installed again. No
> problem so far. Unfortunately the striped partitions were not
> recognized by the Hard Disk Manager anymore (grrrhh :-( (They were
> not harmed in any way during the crash !)
> To make the shitty HD Manager recognize the striped partitions again
> the Rescue Diskette has to be used which has of course defect sectors
> :-(
>
> M$ claims there is no way to rescue our data.
>
> I know that Linux can use striped partitions.
> THE QUESTION:
> Is there any way to make Linux read the NT striped partitions?
>
> With hope in my heart :-)
> Sascha
This is hard to say. Linux can read ordinary ntfs, and can use striped
partitions.
do you know the stripe size, and the order of stripes (i.e. which disk
has stripes 0,2,4,... which one has 1,3,5,...?)
Linux may save you if the striped filesystem is *only* standard ntfs
striped across the disks. The procedure below will not work otherwise,
such as if they include some extra blocks with raid info or if
disk addresses in the stripes use something other than offsets from the
beginning of the combined volume. (Such as including disk number in
the address...)
You may want to try this:
1. Prepare a linux boot floppy with RAID support.
If you don't know how - just download a debian install floppy
and press alt+f2 after selecting color mode and keyboard.
Also make sure this boot kernel support ntfs. If it doesn't,
compile a new kernel.
2. Use fdisk and find out which partitions contains the stripes.
They are probably the ones that have exactly the same size.
3. Use the mdadd command and try combining the two partitions into
a /dev/md0. Then use "mount /dev/md0 /mnt -t ntfs"
Check that this works by doing a "ls /mnt" and see if you see
the nt files as usual.
4. If (3) didn't work, retry with the two partitions in reverse order
for the mdadd command. If that don't help, try a different stripe
size.
This may or may not work. I believe it is harmless though, it shouldn't
cause further damage. If you want to be really safe though, check if the
drives have read-only jumpers! If it works, copy the files to some other
drive
or to another machine using the network.
If it doesn't work and you don't have a backup, consider how
much the data is worth. There are companies specialising in
restoring data from wrecked/burned machines, they can probably
recover all your files but it'll cost a lot.
Helge Hafting
------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Crossposted-To: comp.sys.ibm.pc.hardware.storage
Subject: Re: Bogus hard disk sizes from manufacturers
Date: 13 Jul 1999 05:03:55 -0700
[EMAIL PROTECTED] writes:
> David Fox wrote:
>
> > [EMAIL PROTECTED] (Craig Ruff) writes:
> >
> > > It is called "The Marketing Unit of Disk Capacity", aka Marketing
> > > {Mega,Giga}bytes. This unit of measurement is actually very useful,
> > > as it can mean whatever the manufacturer means.
> >
> > It does *not* mean whatever the manufacturer [wants it to] mean. It
> > is an honest attempt by the manufacturers to be both clear and
> > competitive. Remember, kilo didn't always mean 1024, for the most
> > part it still means 1000.
>
> Except in this case, IBM's "kilo" is not 1000 nor 1024, it's 1006.38
> and 16.8 GB = 8.4 GB * 1.9996
>
> Their website does not show the actual number of sectors, so you don't know
> really unless you actually buy one. The specs are at (with no real numbers)
> http://www.storage.ibm.com/hardsoft/diskdrdl/desk/1614data.htm
>
> So yeah, in the world of marketing, units mean whatever the manufacturer
> wants it to mean.
I still don't see why folks are getting exercised about IBM
understating its disk size by 0.6%.
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
From: Marc SCHAEFER <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup,comp.arch.storage
Subject: Re: Linux/KDE; KDat backup on dat tape proggy
Date: 13 Jul 1999 08:05:41 GMT
In comp.arch.storage Gene Heskett <[EMAIL PROTECTED]> wrote:
: 'strace'? I'm not familiar with that one yet. Sounds usefull though. I
: really miss having a utility such as the amiga snoopdos.
Having used the AmigaOS myself, yes, strace is quite similar, except
that strace shows every system call with the parameters, not only
file I/O operations.
Example:
golid> schaefer:/users/schaefer> strace date
execve("/bin/date", ["date"], [/* 47 vars */]) = 0
[ ... ]
write(1, "Tue Jul 13 10:04:12 MEST 1999\n", 30Tue Jul 13 10:04:12 MEST 1999
) = 30
[ ... ]
You can also restrict the search, for example if you say:
<golid> schaefer:/users/schaefer> strace -e write date
write(1, "Tue Jul 13 10:05:09 MEST 1999\n", 30Tue Jul 13 10:05:09 MEST 1999
) = 30
See the man page (man strace) for details.
------------------------------
From: "ph" <[EMAIL PROTECTED]>
Subject: Re: Help with Sound Card
Date: 13 Jul 1999 12:10:33 GMT
I have a ESS688 and i use the OSS-linux precompiled modules for kernel
2.0.36. Now it works, except for midi files. I found it on my suse 6.0, no
idea about where it come from...
------------------------------
From: [EMAIL PROTECTED] (kls)
Crossposted-To: comp.sys.ibm.pc.hardware.chips,comp.sys.intel
Subject: Re: Celeron, what's the catch?
Date: Tue, 13 Jul 1999 12:19:19 GMT
Coming back from a hiatus from the computer, i c the lil' fud gremlins have
been busy:)
In article <7m8p8t$1a8$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>>Can't say I've ever heard of damaged hard drives from overclocking
>
>This happens. This happened already to me, and this can
>happen to anyone trying to risk their drives, for example, 83MHz. File
>system damage is already a common known fact for overclocking hard
>drives. You can reduce damage by turning off UDMA and going down to PIO
>2, but that will take performance off your hard drive.
Reducing the ide mode reduces the speed from overclocked back to normal.
>>I wasn't basing a ratio off newsgroup responses but refering to polls &
tests
>>on websites(not MY ratio's either). Anybody remember that one site where
>>the guy was a vendor & was testing the celerons he was selling? He had made
>>a chart of speed grades crossed with voltage settings & % of success/fail.
>>
>
>Careful with this people.
Careful with what? Am I supposed to be some oc'ing thug ready to pounce
on people with oc'ing info?:)
>>Poopooing again Chris?:) Abit havn't been/aren't the only ones coming out
with
>
<response: snip, snip, blah, abit bad, blah, very bad, snip, boo, snip>
Again, there's more motherboard manf. than just abit. Fixation?:)
>>>No. For most of them, just no. Look at those ARSTechnica benchmarks
>>>again. Note that these are recent ZDNet benchmarks, which often run
>>>multiple processes simultaneously, and these benchmarks are well known
>>>to have evolved to this manner from earlier, single processing ZDNet
>>>benches, primarily suspected aimed to give an advantage for PII caches.
>>>What advantage does SMP have there? ZDNet benches are supposed to
>>>represent the average Windows enviroment with its most commonly used
>>>applications.
>>
>>1st single threaded bus. winstone 99: no speed gain, no suprise.
>>2nd, multi threaded winstone 99: 29.5%
>>3rd, single threaded high end: no gain.
>>4th, list of individual apps performance: 3 multithreaded, 4 single. guess.
>> vc mp: 39.8%
>> sound forge: minute
>> premiere: minute
>> photoshop mp: 35.5%
>> microstation se mp: 22%
>> frontpage 98: minute
>> avs/express: minute
>>5th, cpumark: not benching 2nd cpu.
>>6th, fpumark: not benching 2nd cpu.
>>7th, disk, slight gain.
>>8th, graphics, no gain.
>>9th, photoshop 30mb file, multi threaded: 30%
>>10th, || 100mb file, ||: 3%
>>11th, || 30mb lighting effect: none
>>12th, || 100mb ||: 2%
>>13th, linux compile: 71%
>>14th, quake 2 8x6: none
>>15th, || 10x7: none
>>
>>Four out of seven is pretty thin ratio to try to pull off a comment like
"No.
>>For most of them, just no." don't ya think?:) Doesn't matter, as these are
NOT
>
>And out of all 15, only six has benefit, five at 20-30% and only one has
>71%. 9 has no practical difference at all. The five 20-30% does not
>justify the cost and complexity of SMP either, since you might as well
>buy a single faster processor.
Your tally is a joke Chris:
14/15quake in two resolutions, ha!, 5/6 cpu/fpumark synthetic tests, 9 benches
the hd, cpu has minimal impact, 10 benches video, functions long since moved
onto video cards, 9-12 breakdown of photoshops average score, 1&3 averaged
score of single threaed apps from 4. Sheesh, who'd you think you where going
to fool?
>So tell me how dual Celeron 333s and 366s can be consistently faster
>than a single K6-III 450 again with an estimated integer performance
>better than a Cel 500?
duals, oc'ing, multithreaded, multiprocess, multitasking.
>>run in multiple processes like you claim but are benchmark results of the
>>individual apps performance. Guess what happens when you multitask? you
>>guessed it, those single threaded apps running in their own process gets
>>shuffled off to one on each processor. btw, I saw a discussion about how
k63
>
>Perhaps you're a bit dim. Doesn't give shit when these processes or
>threads are going to be synchronization, user or I/O bound. In this
>case, the processor is only made to wait on a process or thread that is
>essentially blocked or placed in a wait state.
>
>There is a monumental book about multiprocessing. It's "In Search of
>Clusters" by Pfister, who did a lot of MP research for RS/6000s in IBM.
>Why don't you read it.
Sticks & stones... ps. could you rephrase the second sentence? Still not
sure what you say there:)
>>256k cache is better at multitasking because of it's size. vs a single
celeron
>
>>that should be true, but we're talking about a dual celeron here & that not
>>only means two processing cores but 2x128k cache, the same as a k63.
>>
>
>Two seperate caches on different processors are not the same as a single
>unified cache on one processor, which in addition has an L3 to boot.
Addendum: the same *amount* as a k63.
>>btw, cpureview got around to putting up a dual celeron linux compile time:
>>http://cpureview.com/art_smp_f.html. 77.4%(183% utilization) vs k63's
23.5%:)
>>The test is compiling the linux kernal but the performance is indicative of
>>everything that's compiled or assembled using a makefile. & his system only
>>had 64MB of memory!(I seem to recall an argument that one would have to
spend
>>extra $ on a larger amount of memory than a k63 would need in order to
attain
>>such performance(acutally, I also seem to recall it was argued such
performance
>
>>wasn't realistic or obtainable:) moot point regardless with such low memory
>>prices. btw did everyone notice 128MB pc100 dimms just jumped +$10
>>recently!?).
>>
>>>>>Plus there is no 100% guarantee that a dual Celeron will work reliably
>>>>>everytime and without problems, so again, that's a crap shot.
>>>>
>>>>Yeah, but by user reports, they're good odds.
>>>
>>>You cannot deny a K6-III 450 working on its rated
>>>speed and delivering its vaunted performance is practically a guaranteed
>>
>>Don't think anyone ever has. That is, no one's argued 'a k63 is not as
>>fast as a k63!':)
>>
>>>and much better odds than dual Celerons,
>>
>>Well, there's overclocking odds & odds that there's multithreaded &/or
>>multiprocess enhancements for the type of apps you want to use or will be
>>helped out in general from the os being smp aware. That a k63 is as fast as
a
>
>Don't expect to see such applications except for expensive, workstation
>class types that work on NT,
We've gone over what apps & none of them were 'expensive workstation class
types'. Those are a bonus:)<snicker>:)
>and nobody would take the chance of working
>such applications on unproven unsupported platforms like dual Celerons.
I beg to differ about nobody chance taking & unproven. So would motherboard
manf., slot 1 converter manf., hardware vendors, system vendors, & end users.
>Other than this, the best utilization for SMP right now is being a LAN
>party game server using LInux and Linux compiles.
>
>There is plenty of heavy kinds of Windows applications out there, and
>most of them are basically single process.
<new windows slogan>:P
'where do you want to <multi-task> today?':)
>>k63 one would regard as a baseline. Odds come into play with betting you'll
>>get astoundingly better performance(dual oc'd), much better
performance(dual),
>>roughly the same(oc'd), or 23.5% less than(can't oc, doesn't take advantage
of
>>duals) with inbetween gradients of performance where duals come into play
>>depending on how well dual support is implemented.
>
>Overclocking and using the processors beyond their specification is
>unacceptable on a workplace enviroment.
For the business user & the timid, they can opt not to overclock & choose just
the much better performance instead of the astoundingly better performance
category:)
>Keep the hobbies to yourself; they have no place on business.
Keep the flaim bait to yourself; they have no place on newsgroups:)
>Anything thats recommended for a business enviroment makes a much more
>valid ground for recommendation that your opinion about taking chances
>on warranty and doing things out of spec. A business enviroment
>recommendation will cover far more users out there, than one for a
>fringe geek group.
Keep the flaim bait to yourself; they have no place on newsgroups:)
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.hardware) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Hardware Digest
******************************
