Linux-Hardware Digest #8, Volume #10 Mon, 12 Apr 99 20:13:36 EDT
Contents:
Re: 3com / US robotics 56K (Mark Nielsen)
Re: Compiling for x86 CPUs (Was: ... seperate "i686" tree for Redhat ...) (StatiK)
Re: With dual-processor system, is SCSI a must or is Ultra-DMA enough? (Johan
Kullstam)
Re: All the current OSes are idiotic (was Re: Is Windows for idiots?)
([EMAIL PROTECTED])
Re: Scanning temp. freezes system w/ ISA scsi card (Bill)
Linux on an Austin notebook? (Craig McCluskey)
New user: Vidio server Intel 740 (Roger Doulis)
Re: ES 1371 on Intel 440BX motherboard (Harry McGregor)
Re: 2.2.x/2.2.5 kernel no like ATAPI CDR(W) or Acer 8x CD (Brian Walker)
Re: All the current OSes are idiotic (was Re: Is Windows for idiots?) ("Rob Eamon")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Nielsen)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
Subject: Re: 3com / US robotics 56K
Date: 12 Apr 1999 15:06:57 -0400
>The problem is that I can't find any of these being sold anywhere. The
>closest model number I can find is 1787, and I can't find any technical
>details that tell if this one would probably be compatible, too. I'm curious
>if anyone else out there has had any success with this model.
>
>Also, if you know of another 56K modem that works well with linux, I wouldn't
>mind hearing about that, either.
Well, I try not to plug my company when responding to questions, but...
I sell a $50 egenric modem Internal ISA that you can jumper.
I also sell USR internal for $84.
An external one for less than $100.
If you use an external one, just attach it to one of your serial ports.
MArk
--
Mark Nielsen "Where 98 has no meaning."
www.tcu-inc.com [EMAIL PROTECTED]
The Computer Underground, Inc. 614-485-0506
computers, programming, networking, Perl, PHP, SQL, HTMl, Linux, Unix
------------------------------
From: [EMAIL PROTECTED] (StatiK)
Crossposted-To:
comp.os.linux.misc,alt.linux,alt.os.linux,comp.os.linux.development.system
Subject: Re: Compiling for x86 CPUs (Was: ... seperate "i686" tree for Redhat ...)
Reply-To: [EMAIL PROTECTED]
Date: Mon, 12 Apr 1999 22:02:32 GMT
Buy another Pro / P][ and get rid of the dx2!!
StatiK
On 12 Apr 1999 14:28:40 +0200, Urs Thuermann
<[EMAIL PROTECTED]> wrote:
>Johan Kullstam <[EMAIL PROTECTED]> writes:
>
>> -mcpu=i686 makes the compiler schedule for a i686 core. it uses only
>> the i386 instruction set.
>>
>> -march=i686 enables usage of i686 instructions like cmov (which did
>> not exist on i[345]86. it also implies cpu=i686.
>>
>> if you compile with -mcpu=i686, then yes, it would work with any of
>> intels 32bit x86 cpus. however, by using -march=i686 you will
>> introduce new op-codes which are not implemented on previous
>> processors.
>>
>> based by my own experience with compiling various things with egcs
>> on a pentiumpro, it is not very important for performance no matter
>> what the cpu or arch settings are so long as you avoid pentium.
>
>
>Could someone give some more details about this whole story, please?
>I seem to have problems with this issue since a few days.
>
>I have a Pentium II running in my server machine (which has only a
>Herkules Video card and an Atari ST attached to the serial port) and a
>i486dx2 in my diskless client running Linux and X11.
>
>Both machines run the same 2.0.36 kernel image, the diskless machine
>has its own /tftpboot dir on the server and shares the /usr with the
>server (it mounts /usr read-only, though).
>
>I run egcs-1.1.2 and gcc-2.7.2.3 which have both configured themselves
>as a i686-pc-linux-gnu native compiler. What kind of code will these
>produce if called without any -m... option? How should I invoke egcs
>and gcc-2.7.2.3 to compile with maximum performance on i686 but with
>the constraint that the code should also be executable on i486?
>
>
>
>The problem I am observing is this: With egcs configured as described
>above I compiled the glibc-2.1. When I copy /lib/lib*2.1.so and the
>other glibc-2.1 files to the diskless' /tftpboot directory, the
>diskless i486 won't boot anymore. The statically linked /sbin/init
>seems ok, but (at least) the agetty's die immediately with an SIGILL
>(illegal instruction). So I assume, glibc-2.1 is compiled in a way by
>egcs so that it only runs on i686. This may, however, also be caused
>by glibc itself. glibc-2.1 configured itself as i686-pc-linux-gnu
>also, and obviously has code for this case, which is i686-specific,
>e.g. in glibc-2.1/sysdeps/libm-i387/i686/s_fdim.S there are
>fcomi/fucomi instructions. I think I read in this thread that these
>instructions exist only on the i686, right?
>
>What target should I specify to the glibc configure script? I guess
>i486-pc-linu-gnu does't what I want, right?
>
>However, then some i686 optimized routines are not used, although
>AFAICT based on my little x86 knowledge, these seem to run on other
>CPUs as well. For example
>glibc-2.1/sysdeps/unix/sysv/linux/i386/i686/sysdep.h.
>
>Maybe some pretty solution would be to have the i686-specific code in
>the lib and have an exception handler on the i486 that emulates the
>missing instructions, i.e. similar to the kernel's i387 emulation.
>Does something like this exist and how much performance loss would
>this cause compared to regular i486 code?
>
>
>
>And what about the kernel? The 2.0.36 config help files state that
>a kernel compiled for i486, pentium, or pentium pro will run on every
>cpu except i386. But in 2.2.5 this has changed and it is stated that
>code compiled for one CPU will not neccessarily run on a previous
>CPU. Is this due to compiler options or because of different inline
>assembly routines? I've looked at the make output and even if PPro
>is selected, the compiler is called with -m486, but -D586 is changed
>to -D686, so I assume some #ifdef selects between different inline
>assembly code, that will possibly not run on all ix86 CPUs.
>
>But what sense does the -m486 make, if the code does not necessarily
>run on an i486 anyway?
>
>
>
>OK, many questions and assumption in this posting. Can someone sched
>some light on all this and answer/correct/acknowledge.
>
>
>
>urs
>
>
>P.S. I have removed the linux.redhat.misc group from the Newsgroups
> line.
------------------------------
Subject: Re: With dual-processor system, is SCSI a must or is Ultra-DMA enough?
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 12 Apr 1999 18:11:40 -0400
Michael Hucka <[EMAIL PROTECTED]> writes:
> >>>>> On 12 Apr 1999, BL <[EMAIL PROTECTED]> wrote:
>
> blev1n> one word of advice: if you want to go dual cpu, get BOTH at the
> blev1n> SAME TIME. its said that both cpu's should be from the same
> blev1n> stepping or production run. if you buy the 2nd later on, they may
> blev1n> not match well enough.
>
> This is news to me. What are the symptoms of problems when you try to use
> two processors that are not matched closely enough?
>
> [...]
>
> blev1n> if you're cost concious, then get an ncr chipset card. I got a
> blev1n> tekram dc390 that is ultra2 for under $200. not a big investment,
> blev1n> really.
>
> Unfortunately, it's not just a question of getting a SCSI card: the disks
> themselves are significantly more expensive. The systems I was comparing
> ended up closer to $400 price difference between SCSI and non-SCSI, and when
> you're looking at buying several computers, it starts to add up.
nod. a fileserver type system would benefit from scsi. a workstation
with one or perhaps two disks and not doing much by way of intensive
disk flogging wouldn't.
however, some periferals, e.g., an external DAT drive, cd writer,
scanner, are easier to configure with scsi in linux. therefore, there
is some justification for using a low end (read narrow, perhaps fast
but not ultra2) scsi card as this would let you back up many machines
with one external DAT drive.
there's no reason you cannot mix and have both ide harddrives and a
scsi card for periferals.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
comp.lang.java.advocacy,comp.os.linux.advocacy,comp.os.ms-windows.advocacy
Subject: Re: All the current OSes are idiotic (was Re: Is Windows for idiots?)
Date: Mon, 12 Apr 1999 21:23:52 GMT
The BeOS www.be.com solves a lot of problems associated with older-code OS's
like Windows. Because it was written from the ground up, it runs faster and
more reliably than Windows, and it's easier to use to boot (no pun intended).
The computer that I bought from Cydonia Computers www.cydoniacomputers.com
runs the Gobe Productive office suite on BeOS, and it's much more enjoyable
an experience than I had expected. If you give this OS a try, you're in for a
real treat: it's really amazing how much my hardware could do when I began
using BeOS :)
Jeff Pleasant
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Anthony Ord) wrote:
> On Mon, 29 Mar 1999 16:27:02 GMT, westprog
> <[EMAIL PROTECTED]> wrote:
>
> >In article <[EMAIL PROTECTED]>,
> > Scott <[EMAIL PROTECTED]> wrote:
> >> Peter Wilson wrote:
> >> >
> >> > Sorry, my point was not about single vendor - not a good idea.
> >> > My point was that this was the last major attempt by anyone (anywhere)
> >> > to lift OS design from the rut it has fallen into. My point was also
> >> > that to do the job properly requires a lot of cash - or a lot of
> >> > dedicated amateurs (not pejorative).
> >> >
> >> > Also in reply to Matthias Warkus: "New != Better". NT has proven that
> >> > point conclusively. My reply "Old != Better" either - just familiar.
> >>
> >> Well in some ways, New and Old mixed together slowly could be perfect.
> >> You'd get innovation and new technology, and with the old all the bugs
> >> would have been worked out. So as they slowly mix together, more bug
> >> fixes and improvements are made, though because of the slow mixing, most
> >> of the bugs aren't released to the general public, or if they are get
> >> eliminated very shortly after the release. Hmm sounds like linux.
> >
> >That is an excellent way to fix bugs, but it is totally unable to fix poor
> >initial design decisions. What happens on Linux when you type 'rm * .tmp'
> >instead of 'rm *.tmp'? Just the same as on any Unix system for the last 20
> >years. Why hasn't it been fixed? Because it would break old programs.
>
> No it wouldn't. At the worse it would break old
> shell-scripts. You could alter the rm command such that it
> would ask if you really wanted to do it given that ".tmp"
> does not exist, or given that you had specified it should
> delete a "hidden" file.
>
> For the ultimate in safety alias rm to rm -i. It will annoy
> the hell out of you, but people who do such things deserve
> to be annoyed.
>
> >It simply isn't possible to design a 21st Century operating system that is
> >backwards compatible with a 1980 OS.
> >
> >J.
>
> Regards
>
> Anthony
> --
> -----------------------------------------
> | And when our worlds |
> | They fall apart |
> | When the walls come tumbling in |
> | Though we may deserve it |
> | It will be worth it - Depeche Mode |
> -----------------------------------------
>
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Bill <[EMAIL PROTECTED]>
Subject: Re: Scanning temp. freezes system w/ ISA scsi card
Date: Mon, 12 Apr 1999 16:12:16 -0600
I'm not familiar with your particular SCSI card, but the DTC card that
came with my Mustek scanner doesn't use interrupts. Therefor, the CPU
is busy polling during the scan. It essentially locks up the system for
other uses. I spent $7 this weekend at a swap meet and bought an
Adaptec 1502 SCSI card that can use an interrupt. The system is now
useable while scanning...
Good Luck,
BillD.
Dave-O wrote:
>
> I have a UMAX Astra 600S scanner interfacing with my linux machine (K6-2/
>
> 300) via a PELogic v1600 ISA scsi card and SANE 1.0 as the scanner driver.
>
> I'm using the recommended aha152x kernel driver as a module and it works.
>
> problem is that everytime I scan, the machine almost totally freezes up for
>
> the duration of the scan. It returns to normal once the scan is complete.
>
> I thought scsi wasn't supposed to hog system resources to such a great
>
> extent. is there something I'm perhaps doing wrong? what are other's
>
> experiences with scanning and system load?
>
> thanks,
>
> Dave
>
> ------------------ Posted via SearchLinux ------------------
> http://www.searchlinux.com
------------------------------
From: Craig McCluskey <[EMAIL PROTECTED]>
Subject: Linux on an Austin notebook?
Date: Mon, 12 Apr 1999 17:21:50 -0500
Reply-To: [EMAIL PROTECTED]
I have an Austin Computer Company notebook computer (486DX4/100) for
which I just purchased a new 2.1 GB hard disk. I would like to install
Linux instead of Windows (obviously).
Any idea how I might go about it? (It has a 3.5" floppy, but no CD.)
Any idea if it will work or what chips I should look for inside?
Craig
P.S. With 200+ messages per day, this newsgroup is hard to keep up with!
P.P.S. The BIOS boot messages are:
PhoenixBIOS(TM) A486 Version 1.03
PhoenixMISER(TM) ACC2066 v2.0
Copyright (C) 1985-1993 Phoenix Technologies Ltd.
All Rights Reserved
Version 1.27 WD 722 NotePro+ DSTM
Reference ID FF
486 DX4 processor detected operating at 100 Mhz
TOSHIBA MK2528FC
Hard disk Block PIO enabled
------------------------------
From: Roger Doulis <[EMAIL PROTECTED]>
Subject: New user: Vidio server Intel 740
Date: Tue, 13 Apr 1999 08:47:51 +1000
Good morning all.
Ok I admit to being a very green newbee.
I've just installed redhat (V5.2) on my system at home but apparently to
support my video card (Intel 740 chip set) I need to locate the correct
video server for it. Does anyone know where it is located, that is if it
exists?
Thanks in advance
--
Roger Doulis
(A polar bear is a rectangular bear after a co-ordinate transform).
Dept Civil Engineering (Clayton Campus) Ph 9905-4964
Monash University Fax 9905-1483
Wellington Rd.
Clayton Victoria 3168
Australia
------------------------------
From: [EMAIL PROTECTED] (Harry McGregor)
Subject: Re: ES 1371 on Intel 440BX motherboard
Date: Mon, 12 Apr 1999 23:00:25 GMT
The should not be ESS chips, but ES (ensoniq Sound), ess is another
company. Ensoniq was bought out by creative about a year and a half
ago. The AudioPCI (ES1370 and 1371) is a very good card. Get the
2.2.5 kernel, compile it, and it runs great.
Harry
On 12 Apr 99 18:02:19 GMT, [EMAIL PROTECTED] wrote:
>Hi,
>
>Franck Veysset <[EMAIL PROTECTED]> wrote:
>: I have a gateway G6-450 (Pentium II), running a red-hat 5.2
>: Kernel is 2.0.36.
>
>: On the motherboard, there is an integrated sound card, soundBlaster
>: 16 compatible, based on an ES 1371 chipset.
>
>: The only option on the setup, regarding the sound card, is
>: a switch : Enable/disable... So I guess this sound parameters are PnP ?
>
>The 1371 is also used on one of the SB64PCI variations and is probably
>connected to the PCI bus, check /proc/pci. So it's "PCI-PnP".
>
>: I have only one OS on the hard drive (no way to boot under DOS or W**)
>: I have try to compile the kernel with soundcard support, but that doesn't
>: worked. I have try the usual I/O=0x220, IRQ=5, DMA=1/5...
>: also try I/O=0x240 ... (for the 100% sound blaster compatibles)
>
>The chip isn't supported in the 2.0 kernel series but recent kernels
>(2.2 series) have support for the ESS 1370/1371 chipset.
>
>regards,
> Michael
>--
>Michael Engel ([EMAIL PROTECTED])
------------------------------
From: Brian Walker <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.kernel,comp.os.linux.setup,linux.redhat.misc
Subject: Re: 2.2.x/2.2.5 kernel no like ATAPI CDR(W) or Acer 8x CD
Date: Mon, 12 Apr 1999 23:35:13 GMT
Hi. You might want to make sure that both SCSI CD-ROM support and
SCSI-Generic support are turned on and (for me at least) vendor specific
extensions is turned off. I forgot the generic support in one kernel
build and was getting similar problems. It kept complaining about
/dev/cdwrite not being a block device and in the kernel log it
complained it couldn't load some module. Hope that helps!
Brian
> Thanks for the answer.
>
> Well, turning off the Probe all LUNS fixed the multiple detection problem,
> but adding the append line did nothing for the Acrer 8X 685A CDROM - it
> doesn't show up, which is weird because the 2.0.36 kernel sees it after the
> second try and gets it. The Acer is the slave of the HP Surestor. Another
> problem is that even though the IDE-SCSI sees the HP, I cannot mount a CD.
> Mounting a CDROM in a CDRW as if it were a CDROM should be possible, no? It
> complains about too many mounted filesystems, suggests wrong FS type,
> everything. Yet all of this works fine under the 2.0.36 kernel. I don't
> what I could be doing wrong here. I'm about to give up on Kernel 2.2.x
> altogether, which is too bad b/c everything else seems faster.
>
> Could it be that RedHat does something weird? Maybe when their next 2.2.x
> version comes out the upgrade will work, but I really wanted to compile my own
> kernel for myself.
>
> --Tom
> ===============================
> Windoze NT has crashed,
> I am the Blue Screen of Death,
> No one hears your screams...
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Rob Eamon" <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.java.advocacy,comp.os.linux.advocacy,comp.os.ms-windows.advocacy
Subject: Re: All the current OSes are idiotic (was Re: Is Windows for idiots?)
Date: Mon, 12 Apr 1999 16:19:19 -0600
Leslie Mikesell wrote in message <7etn8n$2fdg$[EMAIL PROTECTED]>...
>In article <7etq2l$[EMAIL PROTECTED]>,
>Jason V. Robertson~ <[EMAIL PROTECTED]> wrote:
>>>>
>>>>This is the reason for case-sensitive operating systems, file systems
and
>>>>programming languages. Nobody really wants a system that can't recognise
>>>>"MyFileName" as the same as "MyFilename", but it saved a few cycles back
in
>>>>the valve age.
>>>
>>>you speak only for yourself here. i most certainly do want case
>>>sensitivity in my filesystems and programs. why use more than one
>>>case if they don't mean something different?
Because, as a general rule, they really don't. Only the file creator
can tell the difference. Can you tell me something about the context
of a file named 'dogs' vs. a file named 'Dogs'? Yes, I know they
are different because the ascii codes for 'd' and 'D' are different, but
without some explanation of context, the difference for the average
human is left as an exercise in interpretation and divinve intervention.
>>
>>Case preservation = good. Case sensitivity - in the filesystem - = bad.
>
>Well, we disagree.
>
>>It's easy to make arguments for the former, hard to make them against the
>>later. 99% of the time, if you type 'MyFilename' you mean (if it already
>>exists) 'MyFileName'.
>
>I prefer not to leave things to 99% guesswork. I'd rather say what I
>mean and be expected to mean what I say.
There is no guesswork involved. For case-insensitive systems,
MyFileName and MyFilename refer to the same file 100% of the time.
>
>>You prevent more errors by coding to that 99%. It's
>>pretty hard to think of legitimate cases for case sensitivity in the
filesystem
>>other than "Unix does it, so I need it."
>
>Well, yes - a 20 year history of existing practice and existing files
>that require consistent handling is a good enough reason for me.
In previous threads on this topic, it was suggested that the
shell could do a bit more work and detect these 'typos' with,
"You specified 'MyFilename' but it doesn't exist. 'MyFileName
does exist. Perform operation on MyFileName? Y/N'
Indeed, a couple folks pointed out that some shells do this
sort of interpretation.
> I
>don't quite understand the 'invent a new API and storage format yearly'
>mentality that forces you to replace everything at once.
------------------------------
** 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
******************************
