From: Digestifier To: Linux-Misc@senator-bedfellow.mit.edu Reply-To: Linux-Misc@senator-bedfellow.mit.edu Date: Wed, 12 Oct 94 22:13:27 EDT Subject: Linux-Misc Digest #925 Linux-Misc Digest #925, Volume #2 Wed, 12 Oct 94 22:13:27 EDT Contents: Information on Linux (Manish Desai) Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE (Steve Kneizys) Re: getting linux to work dail-up (Hugh Emberson) Re: getting linux to work dail-up (Carlos Irigaray) Linux's future support for ATA/IDE development thoughts... (George Shin) Re: Mystery Chip...AMD (H. Peter Anvin) Re: Mystery Chip...AMD (Jeff Kesselman) [Q] Best PCI video card for XFree86 3.1 and Linux (Jeffrey Lessem) Re: Word (Text) processors for Linux? (Steve Dunham) Re: Is linux a multithreaded operating system? (Jeff Kesselman) Re: Weakest Linux Box (H.J. Lu) Re: SW Technologies (Tim Bass (Network Systems Engineer)) Help with suck+++.tar.gz (Ian Colquhoun) ---------------------------------------------------------------------------- From: manish@.chem.uh.edu (Manish Desai) Subject: Information on Linux Date: 12 Oct 1994 03:29:32 GMT Hi, I am trying to set up a linux box as a backup server. I have gone through the most of the docs. available on net. Now I would like to know the experience of anyone who is running linux in a networked environment with all or one of the following demons/servers. 1) Named 2) bootp 3) NSF 4) gopher server and 5) Mosaic server the configuration of the system will be a 486DX/50 MHz processor with local bus arch. It will have 16Mb of RAM with 210 MB of Harddisk (IDE). Also I want to mount 1 GB hard disk from a IBM RS6000 running AIX running 3.0. The ethernet card will be eitherNE2000 or from HP . In particular I will like to know response time , reliability etc. Please let me know if the above configuration is ok or not. Please reply to manish@uh.edu. Thanks in advance, Manish Desai. ------------------------------ Crossposted-To: comp.os.linux.help,comp.os.linux.development Subject: Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE From: STEVO@acad.ursinus.edu (Steve Kneizys) Date: 7 Oct 94 22:11:57 EST Yuri Trifanov (yuri@shimari.cmf.nrl.navy.mil) wrote: : > We are using SLIP! And the problems we see are not *after* a connection : > is successfully opened, it is one of the system *refusing* connections : > (apparently). Nearly all functions handled by inetd seem affected: : > telnet logins, rlogins, ftp attempts, smail connections, attemps to do : > zone transfers from named by our provider's router, you name it. Things : > work fine *most* of the time, but the login problems are the most : > persistant and visible. In those cases, the system log *usually* shows : > 'connect from...' but the user never gets a prompt, or never gets a : > password prompt after entering username. Netd entries in the log are : > 'connection refused' mostly. : you could be having problems with the resolver and tcpd, which comes : turned on by default in at least some distributions. if it can't : resolve the inaddr of the connecting host it will refuse the : connection. I see the freeze and I only use Etherlink III 3c579 cards on the same wire as 3 VAXes, including our domain's name resolver. Telnets from the domain resolver VAX to the Linux freeze, as does FTP, finger, smtp, rlogin. Steve... ------------------------------ From: hugh@hugh.cosc.canterbury.ac.nz (Hugh Emberson) Crossposted-To: alt.os.linux,comp.os.linux.help Subject: Re: getting linux to work dail-up Date: 11 Oct 1994 04:58:44 GMT >>>>> "Carlos" == Carlos Irigaray writes: Carlos> ttyS2 stands for com3 (under DOS) and is for incoming calls Carlos> (difference between cua2 and ttyS2) This is becoming a urban legend :-) I used to believe this and it caused lots of trouble. You can and should use ttyS? for dialin and dialout. From the mgetty+sendfax docs (by Gert Doering): *Important note:* Use the `/dev/ttyS*' devices for getty and for dial-out (that is, for kermit, uucico, cu, seyon, ...) - *never* use `/dev/cua*'. Dialing out on `/dev/cua*' will result in the error message "device busy". (There are reasons why `mgetty' cannot use the "`ttyS*' vs. `cua*' kernel locking mechanism", see below), and dialing in (ugh) on `/dev/cua*' will result in dozens of strange things happening because the process won't get a controlling tty. Some guys seemingly can't resist posting misinformation to the net all the time, don't believe 'em. The `/dev/cua*' devices are *not* different from the `/dev/ttyS*' devices concerning data flow or modem control lines. The only difference is how the device reacts if you do an `open()': Opening `/dev/ttyS*' normally blocks until the "carier detect" line goes active (unless `open()' is called with the `O_NDELAY' flag; `mgetty' and all dial-out programs do that), and opening `/dev/cua*' will return an error message (`errno=EBUSY') if another process has the device already open, thus *preventing dial-out on `/dev/cua*'* if `mgetty' is active on `/dev/ttyS*'. We use `/dev/ttyS*' all the time for dial-in *and* for dial-out, and believe me, it works, and it's the *only* combination that will work properly. The kernel locking mechanism only works if you use modem auto-answer (the getty process sleeps until the modem gets a carrier), and mgetty uses manual answer (it waits for the RING message from the modem), which will save your callers a lot of grief because their calls will only be answered if your computer is ready to receive a call. Part of the motivation for writing mgetty was being tired of losing lots of money for useless calls to a hung machine. BTW I can't recommend mgetty+sendfax highly enough. Its excellent. Cheers, Hugh -- Hugh Emberson | ... from the end of the Information hugh@cosc.canterbury.ac.nz | Super-four-wheel-drive-track. ------------------------------ From: cirigara@nova.umd.edu (Carlos Irigaray) Crossposted-To: alt.os.linux,comp.os.linux.help Subject: Re: getting linux to work dail-up Date: 9 Oct 1994 01:03:00 -0400 Jacob Zielinski (jzielin@vanbc.wimsey.com) wrote: : Has anyone be able to hook their modem up so that you can dail into linux? : The people on #linux suggested agetty, and mgetty. But I didn't get to far : with those to commands. Could somebody who as done this explain how or at : least point me toward some docs. The best is to use uugetty or mgetty. You have to add to your /etc/inittab file the following line (as an example): s1:45:respawn:/sbin/uugetty ttyS2 9600 ttyS2 stands for com3 (under DOS) and is for incoming calls (difference between cua2 and ttyS2) ttyS0 for com1 ttyS1 for com2 and so on.... 9600 is a label corresponding to an entry on the /etc/gettydefs file. After, you should create a file called uugetty.ttyS2 (under /etc/defaults) with the following lines: INITLINE=cua2 WAITFOR=RING CONNECT="" ATA\r CONNECT\s\A DELAY=1 and that's it. For more information read the man pages for getty. uugetty is at the end of the manual. Note: I put ttyS2 and cua2 as an example. Your configuration might be different. Hope this helps! ____________________________________________________________ | | | Carlos Irigaray - cirigara@nova.umd.edu - carlosi@iadb.org | | | |____________________________________________________________| ------------------------------ Crossposted-To: comp.os.linux.development,comp.os.linux.help From: gshin@netcom.com (George Shin) Subject: Linux's future support for ATA/IDE development thoughts... Date: Tue, 11 Oct 1994 04:52:34 GMT Hello Linux net-folks, I've been following pretty closely on some of the discussions relating to Enhenced IDE/Fast ATA topic and would like to maybe continue on to see how it's and will effect Linux support for ATA drives. I don't intend to do all at one shot so here goes the first two attempts... But first some base-line terminology so we start out at the same ground: I would like to use the term ATA rather than IDE since to me even SCSI drives are candidate for IDE. Also, i tend to talk register mode versus BIOS support when interfacing to the drive, i.e. direct I/O port programming against BIOS ISR provider. Finally, if i may i would like to include DIOW-/DIOR- interface signals when discussing various PIO timing modes. Oh, BTW at the host-end i tend to call the drive card, host adapter card (HAC) whereas most people use the terminlogy of controller card. Most ATA HAC's are pretty much "brainless" and does nothing but data buffering in between the host and the target drive. Well, i'm not an expert in ATA drive land, however getting lot's of practice at the work so maybe share some information with fellow Linux'ers and get plenty of feedbacks hopefully. I've been funning Linux for quite some time starting with ATA drives then with all the advantage with SCSI, now am running Linux entirely from 1GB SCSI drive. However following thoughts come to me when thinking about ATA drives + Linux: 1. Since ATA-2 spec is on its way of being finallized we'll expect to see more drives with support for fast PIO timing modes especially PIO mode 3 and yes, PIO mode 4. For user to take advantage of these high speed data transfer rate one would need local-bus (VLB or PCI) ATA HAC that can strobe DIOW-/DIOR- at that frequencies. Most if not all have special on-board ATA interface chip that's capable of interfacing at that high speed as well as BIOS extension or installable device drivers. At very minimum these BIOS or device drivers will initialize various timing registers of interface chip to talk at that high data rate of ATA interface. My concern is that since Linux is doing all ATA talking at non-BIOS, register level will this have to be changed later when supporting specific high-speed ATA HAC's? I've done some measurement at work and having these cards power up and doing all register level drive access there after will NOT produce fast transfer. Looks as though these BIOS/driver routines have some special code besides your average "rep outsw" and "rep insw" instructions. So does this mean Linux now has to support specific ATA HAC's??? I guess days of generic ATA interface talking is over then... 2. ATA-2 has announced additional I/O ports for 2 more HAC's besides your current primary and secondary. This results to total of 8 ATA drives under PC. Any interest in supporting this under Linux... Hmmm, maybe i should get involved in this... I can't recall whether IRQ's are also defined or suggested... - george PS How do you REALLY know that your high-speed 1GB ATA drive is doing PIO3 or PIO4??? You REALLY don't unless... PSS BTW, check out ftp://fission.dt.wdc.com's /pub/ata and /pub/standards for ATA/SCSI papers... These really make very good bed-time readings... :-) ------------------------------ Crossposted-To: comp.sys.ibm.pc.hardware.systems,comp.os.linux.admin From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin) Subject: Re: Mystery Chip...AMD Reply-To: hpa@nwu.edu (H. Peter Anvin) Date: Sun, 9 Oct 1994 07:20:02 GMT Followup to: <3740ss$4kj@venera.isi.edu> By author: daniel@isi.edu (Daniel Zappala) In newsgroup: comp.os.linux.admin > > But doesn't Intel sell a chip that upgrades a 486DX-33 into a 486DX2-66? > How do they manage that? > It's just a 486DX2-66 with a 487 pinout that fits in a 487 socket. It switches off the DX-33, so if you keep it in the system it is only going to sit there like a heating pad. It was part of an Intel scheme to sell these "upgrade" parts without causing a messy aftermarket of used DX-33 chips, which might affect profit margins. Fortunately, both consumers and MB manufacturers rejected this as an expensive ploy and waste of MB space. However, if you buy an "Overdrive" chip from Intel, make sure to get the one with the right pinout (486 or 487). Of course, the 487 itself is just a DX chip with different pinout. Conclusion: Intel marketing sucks. /hpa -- INTERNET: hpa@nwu.edu --- Allah'u'abha --- IBM MAIL: I0050052 at IBMMAIL HAM RADIO: N9ITP or SM4TKN FIDONET: 1:115/511 or 1:115/512 STORMNET: 181:294/1 or 181:294/101 Keyboard not found, press F1 to continue ------------------------------ Crossposted-To: comp.sys.ibm.pc.hardware.systems,comp.os.linux.admin From: jeffpk@netcom.com (Jeff Kesselman) Subject: Re: Mystery Chip...AMD Date: Sun, 9 Oct 1994 06:13:34 GMT In article <1994Oct7.102248.4477@tudedv.et.tudelft.nl>, wrote: >> >> I have an AMD 486DX-40. Any news on an add-in from AMD to turn this into a >> 486DX2-80, or do I need to buy a whole new chip? >> >> Daniel > >Yes you have to buy a WHOLE new chip. > I'm DYING to know what the original poster meant by this? How would you ADD-IN to a sealed piece of silicon????? Could you explain please? JK ------------------------------ From: lessem@Colorado.EDU (Jeffrey Lessem) Crossposted-To: comp.windows.x.i386unix Subject: [Q] Best PCI video card for XFree86 3.1 and Linux Date: 9 Oct 1994 07:27:18 GMT Now that XFree86 3.1 has been out for a week, I would like to get people's opinions on what would be the best PCI video card to get for running X under Linux. Currently I am using an ATI 8514 Ultra, and the Mach8 drivers seem to work flawlessly, the performance is good, but because this card has no VGA I am forced to use another card for text screens etc., and requiring two ISA slots to run video is severly limiting my options in upgrading. I don't want to spend much more than $200, and I certainly don't want to take a performance/stability hit. The cheapest cards appear to be the ET4000/W32p based ones. I have seen some people reporting problems with performance and pallet corruption, is this a server problem, or just bad configurations? What about the S3 based cards, many of these are available relatively cheap, how stable is the X server for those? I know the Mach64 is not supported yet, but how well do Mach32 based cards work? I would be running the card at 1024x768x8, and would like the ability to go to 800x600x16 or 24. If I can do 1024x768x16+ for $200 please let me know about it. I am not interested in top of the line performance, right now if I cat termcap it scrolls too fast to read, and opaque window move works well, if opaque window move worked very well on the new card I would be happy. Thanks, if I get enough responses I'll summarize. ------------------------------ From: dunham@gdl.msu.edu (Steve Dunham) Crossposted-To: comp.unix.questions Subject: Re: Word (Text) processors for Linux? Date: 12 Oct 1994 20:59:38 GMT Richard L. Goerwitz (goer@quads.uchicago.edu) wrote: : This is lovely news, but if it's the same news as I've heard, what we have : here is not an internationalized/multilingual product, but rather one that : has been hacked to include support for a language here and there. So, for : instance, things I do easily every day with MLS (or could with Nisus) on : micros, I could not do with TeX. This includes quoting Greek, Hebrew, Eng- : lish, Arabic, etc. in the same document. I believe that some versions of : TeX do Hebrew/Arabic and English; others might do Greek and English. The : model here, though, is not that of a multilingual product. : I really hope that the info I have is wrong. Please correct me if it is. You're wrong. You can easily combine hebrew, arabic, english,, classical greek, devenagari, aramaic, ... with TeX. There is an extension to the TeX program proper which is called Tex-Xet. It is easy to apply the patch when you install TeX. It takes away no funtionality and adds on command which switches the direction of text, making the macros for hebrew/arabic a lot cleaner. It also adds a command to the DVI format but (1) many dvi printers support it, and (2) there is a program which will change the dvi into one which everything supports. The modified TeX is commpletely backwards compatible. In fact, TeX will allow you to use multiple hyphenation tables and switch between them in the middle of your document. Steve dunham@gdl.msu.edu (I like TeX, but I would like to see a front end that allows me to see my equations and Russian/Greek/Fraktur fonts on the screen while I am typing.) ------------------------------ From: jeffpk@netcom.com (Jeff Kesselman) Subject: Re: Is linux a multithreaded operating system? Date: Tue, 11 Oct 1994 05:15:16 GMT In article <37a4na$t0c@bosnia.pop.psu.edu>, David Barr wrote: >In article , >Jeff Kesselman wrote: >>So yes, UNIX is multi-threaded in the sens that there are multiple threads >>of control operating in a time-sliced fashion. The term 'threading' is >>often used in multi-tasking system however to denote a 'lesser form' of >>multi-taskign that goes on completely within a single process. > >Not quite. Most UNIXes (including Linux) are not multi-threaded at all. > >Multi-tasking is simply multiple "tasks" (call them threads, call them >processes, it doesn't matter) executing simultaneously. Traditionally, >the smallest schedule-able "task" is a process. If you want two >things to be able to execute simultaneously, you make two processes. > >Multi-threading extends this such that you can have multiple threads >per process, and each thread can be scheduled on its own. If one >thread in a process performs a read() and has to wait, other threads >can continue executing. Pardon? Thats what I said, I believe, if you read the whole post. I don't see that your read() is relevent, however. As long as your kernel is not single-tasking and blocking (as opposed to waiting, an example of such a blocking kernel is OS-9) then you shoudl be able to process eitehr in another thread OR another process. > >The difference between a "thread" and a "process" in a multi-threaded >system is that a "thread" shares the same address space as other >threads in the same process. With processes, in order to share memory, >you need to use something like the SYSV shm*() family of syscalls. > >>thsi is >>also sometimes called 'light-weight multi-tasking'. UNIX (and Linux) > >I think you're thinking of what Sun calls "light weight processes", >which is a hokey pseudo-threaded system for non-multithreading kernels. >Under LWP, system calls in one thread block all threads in the process >from executing. No, actually, I was thinking about the BSD calls on the VAX (I mentioend BSD, though I may not have netioend the VAX) and what Modula2 does inhearently (as I also mentioned.) > >There are thread libraries for Linux (pthreads) that will allow this >sort of multithreading for Linux, but don't confuse that with a >multithreading operating system. (Like Solaris) These are called >"user-level" threads, and are not nearly as useful as one with >a kernel that supports threads. (and if your kernel supports real >threads, you can compile the pthread library to do real threading) > >--Dave This blocking business is an implementation detail. I don't think its a terminology issue. This whole discussion goes to illustrate my OTHER point (deleted) that the terms thread, task and process are often used in different ways. The whole area of terminology is muddied, this is PARTICULARLY true when referrign to 'threads'. JK ------------------------------ From: hjl@nynexst.com (H.J. Lu) Subject: Re: Weakest Linux Box Date: 12 Oct 1994 18:10:52 GMT In article <37cj08$7m0@master.cs.rose-hulman.edu>, henslelf@henslelf.student.rose-hulman.edu (Linux Mac Daddy) writes: |> I was just wondering who has the weakest Linux box? What I mean by this |> is like anyone running Linux on a 386 with 3 megs of RAM... I've got a |> 386sx-16 with 5 megs of RAM and it works great (tons faster than DOS). |> If anyone has a "weaker" machine that runs Linux (and you actually use |> it) let's hear it.... |> 386sx/16 with 4 MB RAM. I am trying to upgrade and waiting for the price to drop :-(. H.J. |> ------------------------------------------------------------------------ |> Slam Foot Neck! Ride the wave. Touch Touch Touch. I'm cereal. |> Internet: henslelf@po.nextwork.rose-hulman.edu |> Bilbo: 137.112.200.75 |> o__ o__ o__ o__ o__ |> ,>/'_ ,>/'_ ,>/'_ ,>/'_ ,>/'_ |> (_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_) ------------------------------ From: bass@cais2.cais.com (Tim Bass (Network Systems Engineer)) Subject: Re: SW Technologies Date: 12 Oct 1994 21:41:40 GMT Jonathan I. Kamens (jik@cam.ov.com) wrote: : All these insults are very nice, Bob, but they don't answer Jeff's question -- : "The question I am left with here is DOES Bob feel Mr. Wu acted improperly in : bouncing this refund check, and not as a repsonsible vendor? Comments , Bob?" --------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^ ???? Well if you consider this to be NOT RESPONSIBLE then.... Selling merchandise at the lowest possible cost, Having very little profit margin, Working to insure linux runs on the platform, Trying hard to please every customer. THEN : Well, Bob? Comments? : -- : Jonathan Kamens | OpenVision Technologies, Inc. | jik@cam.ov.com ------------------------------ From: ianc@nudge.io.org (Ian Colquhoun) Subject: Help with suck+++.tar.gz Date: 12 Oct 1994 02:42:25 GMT I downloaded suck+++.tar.gz from sunsite but I can't seem to get it to compile properly on my system. It complains of improper pointer type to getbyhostaddr, finishes and does create an executable but when I try to run it it says Segmentation Fault. Has anyone got this program to compile on their system or knows of another similar program to 'suck' news easily via NNTP? Ian ianc@io.org ------------------------------ ** 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: Linux-Misc-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.misc) via: Internet: Linux-Misc@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Misc Digest ******************************