Subject: Linux-Development Digest #587 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Tue, 29 Mar 94 09:13:07 EST Linux-Development Digest #587, Volume #1 Tue, 29 Mar 94 09:13:07 EST Contents: Re: Async I/O (David F. Carlson) Re: I want real scrollback. (Stefan Dalibor) Re: IPX compliancy? (Alan Cox) Re: Specialix Driver Round 2 (From specialix) (Alan Cox) Re: IPX compliancy? (Alan Cox) Raw parallel port device? (Bill Gribble) Re: TCP/IP-Bug in 1.0 Kernel? (Alan Cox) Full blown setlocale() with support tools (Nickolay Saukh) Re: NFS timeouts (Byron A Jeff) Re: Adaptec 2742T anyone? (Vinny Andella) Kernel compile dying w/SIGSEGV (Douglas Donahue) Re: Kernel compile dying w/SIGSEGV (Peter MacLeod) fallback during boot in all cases? [was: Re: [moddev README omission]] (Georg Wiegand) How to execute SCO binaries ??? (Oliver Wurm) Re: PC as C64 file server (Andrew Bulhak) ---------------------------------------------------------------------------- From: dave@valhalla.ee.rochester.edu (David F. Carlson) Subject: Re: Async I/O Date: 28 Mar 1994 12:52:03 -0500 May I suggest rather than using MVS as a model for your async I/O support, get a recent draft of the IEEE POSIX1003.4 (nee' 1b) standard. This was recently ratified by the IEEE real-time POSIX committee and although not perfect contains much insight into the problems you discuss. The hassle is that the IEEE has decided to make money on their standards so the documents are not ftp'able. Since Linux is already 1003.1 compliant, getting the pieces to 1003.4 in place seems like the "Portable" thing to do. dave ------------------------------ From: dalibor@faui30.informatik.uni-erlangen.de (Stefan Dalibor) Subject: Re: I want real scrollback. Date: Mon, 28 Mar 1994 17:51:53 GMT In article , aeb@cwi.nl (Andries Brouwer) writes: |> ftlofaro@unlv.edu (Frank Lofaro) writes: |> :Why not put it in the kernel? It seems like a logical place for it. It seems |> :like a lot of work have to coordinate the kernel with a user process, and |> :could slow down the console driver due to context switching overhead, etc. |> :The vt100 emulation is in the kernel already, this wouldn't be much different. |> |> Answer 1: Because we want to avoid kernel bloat. |> Answer 2: Because a user process could give an arbitrary amount of scrollback, |> possibly using buffering on disk, while it would not be exactly easy |> (or clean) to make the keyboard interrupt routine access a disk file |> or swap space. |> Moreover, as soon as you have arbitrary scrollback, you'll want to search |> for a string, dump parts of the screen to a file, etc. Exactly! And all this exists, ready to run on your Linux box: Screen. Scrollback limited only by the amount of RAM/swap-space available, vi-like viewing/searching of scrollback-history, dumping of scrollback-history to files, switching between umpteen virtual vt100-windows, cut'n'paste between those windows (using keyboard commands), rebindable command keys, ability to detach and reattach sessions etc. etc. Screen performs also great when running in an xterm - IMHO it is one of the really indispensable tools, just as important as a good editor or shell. Once you have screen installed, the question of implementing things like scrollback in the kernel really becomes irrelevant. Screen-3.5.2 should be available in every GNU-archive, go try it - it makes me start to believe the rumours about GUI-oriented environments being less productive than state-of-the-art command-line interfaces. Bye, Stefan --- Stefan Dalibor dalibor@immd3.informatik.uni-erlangen.de http://faui30t.informatik.uni-erlangen.de:1200/Staff/dalibor/dalibor.html The louder you scream, the faster we go. ------------------------------ From: iiitac@uk.ac.swan.pyr (Alan Cox) Subject: Re: IPX compliancy? Date: Mon, 28 Mar 1994 11:36:19 GMT In article <1994Mar23.040824.23695@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes: >In article <1994Mar22.145503.28541@uk.ac.swan.pyr> iiitac@uk.ac.swan.pyr (Alan Cox) writes: >>There is a beta test IPX layer for Linux, but no netware support. Novell >>guards its netware details with lawyers and complex licensing agreements >>involving thousands of dollars. So forget it - Linux does Lan manager and NFS > >There is always reverse-engineering. > Dr.Dobbs journal Nov. 1993 covers most of it. It doesn't help in the slightest if you look at the list of alleged software patents that Novell hold in the USA. Reverse engineering doesn't exempt you from patents. Alan ------------------------------ From: iiitac@uk.ac.swan.pyr (Alan Cox) Subject: Re: Specialix Driver Round 2 (From specialix) Date: Mon, 28 Mar 1994 11:45:46 GMT In article <1994Mar23.182432.20120@kbbs.kiel.sub.org> hp@kbbs.kiel.sub.org (Holger Petersen) writes: >rogers@drax.isi.edu (Craig Milo Rogers) writes: > >> Revealing that part of the host-side driver, as by publishing >>its source code, would reveal details of the host-side interface which >>(at least one) vendor wishes to keep a trade secret. That's their problem. You can always reverse engineer it. > >Is ther any part in the Gnu-licence that says: > > "You have to use 'C' as _the_ language " ?? > No but you are required to give the source in its 'preferred form' so you can't scramble it up and shield it. Alan ------------------------------ From: iiitac@uk.ac.swan.pyr (Alan Cox) Subject: Re: IPX compliancy? Date: Mon, 28 Mar 1994 11:50:49 GMT In article tierney@rintintin.Colorado.EDU (Craig Tierney) writes: >Someone has already done the reverse-engineering. In Dr. Dobbs Journal a >few months back, the NCP (Netware Core Protocol) was documented. The NCP >is how the Shell(Netx) communicates with the server, on top of IPX. >There is also a book that is being released about Netware that covers >many of the undocumented aspects. If you've tried playing with this you'll find that its not accurate and it doesn't cover a lot of the 'hard' stuff like mapping a drive. I got a server hack as far as login then got too busy. Alan ------------------------------ From: bgribble@jarthur.cs.hmc.edu (Bill Gribble) Subject: Raw parallel port device? Date: 28 Mar 1994 18:26:08 GMT The only existing drivers using the parallel port (that I have seen) are PLIP and lp. I need raw parallel output with no handshaking and these devices don't seem to provide it. Should I just kludge up an output-only driver or is there enough general interest to write a decent bidirectional i/o driver? (alternatively, if someone has already done it I'd be happy to hear!) Bill Gribble ------------------------------ From: iiitac@uk.ac.swan.pyr (Alan Cox) Subject: Re: TCP/IP-Bug in 1.0 Kernel? Date: Mon, 28 Mar 1994 15:03:21 GMT In article <1994Mar26.131145.1087@pe1chl.ampr.org> pe1chl@rabo.nl writes: >Getting Alan's new binaries (ifconfig etc) broke it for me. It worked >fine before... > Every copy of this problem I've checked out so far has been old version of dip that don't know the new route syntax. So if you have a problem keep the old route binary around or upgrade to dip337uri Alan ------------------------------ From: nms@ussr.eu.net (Nickolay Saukh) Subject: Full blown setlocale() with support tools Date: Mon, 28 Mar 94 17:40:48 +0400 Reply-To: nms@ussr.eu.net I've made new setlocale() with support tools for all LC_* types (man pages are included). Previous functionality (as in libc-4.5.21) retained. The file is ftp.mrc-apu.cam.ac.uk:/pub/linux/new-locale.tar.gz Known limitations are a) 8 bit codes only; b) depend on endianess. NOTE: signed chars would not work with ctype.h for 8 bit codes. ------------------------------ Crossposted-To: comp.os.linux.admin From: byron@cc.gatech.edu (Byron A Jeff) Subject: Re: NFS timeouts Date: Tue, 29 Mar 1994 01:35:04 GMT In article <9403282352.AA26078@cs.utexas.edu>, Frank Lofaro wrote: >In article <1994Mar28.133906.8797@cc.gatech.edu> byron@cc.gatech.edu (Byron A Jeff) writes: >>In article , >>Julian Assange wrote: >>>ward@crl.com (Ward Mullins) writes: >>>>I'm trying to use a Linux Box as an NFS server to a Sparc running Solaris >>>>2.3, and I keep getting thousands of server timeouts, followed by server >>>>OK messages. >>>Linux nfs is broken, large reads kill it. Small read (around 512 bytes) are ok, >>>with solaris. >>Linux NFS is not broken. It has different buffer sizes than the Sun OS's >>(SunOS and Solaris). It's the NFS clients's responsibility to set buffer >>sizes. So if anything is broken (and nothing is) then it's Solaris ;-) >> >>Anyway the solution. When you mount set the buffer size to max 1k. Example: >> >>mount linux:/ /solaris -o rsize=1024 wsize=1024 >> >>End of problem. I've transferred upwards of 120M at a time (tar backup) >>over this kind of interface. No program necessary. Inventive though. >> > >Linux NFS _is_ broken. You don't have to use the rsize wsize kludge for >other OS's. It is a restriction that is unique to Linux (possibly plus a >small handful of other OS's). This is BAD. I think it is very good that >we have Linux and NFS for Linux for free and I am not flaming the net people, >they have done a good job so far. It is not yet finished however. This is >one of the things which should be given a very high priority. It works. What's the problem? Just because it doesn't have the same size buffers as other O.S. doesn't mean it's broken. By that reasoning then the Shareware DOS NFS client I'm testing now is broken because it only has 1K buffers (actually it is broken, long story). What I can't figure out is why NFS doesn't have a negotiation phase where the client and server can decide on the proper buffer size. Doesn't seem hard. Broken specification, not broken implementation. Anyway the only time you have problems is when you're unaware of the buffer size differences. And if rsize and wsize are such kludges then why does the originator of NFS (sun) have it in their mount code? Is there something in the NFS specification that says that the buffers must be a minimum size? What about when you're running NFS over SLIP and can't do fragment re-assembly (smaller buffer sizes solve that problem)? Is Solaris NFS broken then? Not a kludge, just added flexibility. All I know is that if I set the buffer size right then everything works. But back to the questions: why is Linux NFS limited to 1K buffers? How difficult would it be to fix? Note that I'm not bitching. I think it's fine just the way it is. Followup to c.o.l.development. BAJ --- Another random extraction from the mental bit stream of... Byron A. Jeff - PhD student operating in parallel! Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu ------------------------------ From: vandella@world.std.com (Vinny Andella) Subject: Re: Adaptec 2742T anyone? Date: Tue, 29 Mar 1994 00:55:10 GMT David Rapchun (rapchun@suicide.sdsu.edu) wrote: : Hello, I understand there are some people working on writing a driver for : the Adaptec 7770 series chip. IE, the 2742 and 2842 both use this new chip. : I was just wondering how the work is coming along since I would really like : to run Linux soon. Thanx. : Dave. : -- : ******************************************************************************* : * rapchun@mintaka.SDSU.edu Dave Rapchun * : ******************************************************************************* PLEASE SEND HELP !!!!!!!!!!!!!!!!!!!!!!!! I have a killer 486 66, with an Adaptec 2842 VL controller, I want to run Linux too. I got the CD 3 weeks ago and have been searching the internet for HELP !!!!!! Please send any information to vandella@world.std.com If a driver has not been developed yet please tell me the time frame for it. Thanks Vinny Andella ------------------------------ From: odoncaoa@panix.com (Douglas Donahue) Crossposted-To: comp.os.linux.admin,comp.os.linux.misc,alt.uu.comp.os.linux.questions Subject: Kernel compile dying w/SIGSEGV Date: 28 Mar 1994 15:54:09 -0500 Greetings, Over the course of the weekend, I attempted to recompile the kernel. The first attempt was sucessful. However, subsequent attempts failed with what would appear to have been segmentation violations. A representative error message follows. The strange part of it though, is that the compile failed at a very early point in the remake on one attempt, but breazed right through the same point in the compile on a subsequent attempt. It's obvious to me that there are not any errors in the source that are generating such problems. e.g. dividing by zero. Has anyone else had such experiences? How about one of the compiler and/or kernel experts speaking up? What would cause the compiler to fail with a segmentation violation when one doesn't actually exist? What would cause the kernel to generate such a signal and kill the compiler? A representative failure message: . . gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe \ -m386 -c -o init/main.o init/main.c gcc: Internal compiler error: program cc1 got fatal signal 11 make: ***[init/main.o] Error 1 cpp: output pipe has been closed Oh yea, 'signal 11' is defined in /usr/src/linux/signal.h as 'SIGSEGV'. Cheers, Doug Donahue ------------------------------ From: macleod@adoc.xerox.com (Peter MacLeod) Crossposted-To: comp.os.linux.admin,comp.os.linux.misc,alt.uu.comp.os.linux.questions Subject: Re: Kernel compile dying w/SIGSEGV Date: 29 Mar 1994 02:21:24 GMT Douglas Donahue (odoncaoa@panix.com) wrote: : Greetings, : Over the course of the weekend, I attempted to recompile the kernel. The first : attempt was sucessful. However, subsequent attempts failed with what would : appear to have been segmentation violations. A representative error message : follows. The strange part of it though, is that the compile failed at a very : early point in the remake on one attempt, but breazed right through the same : point in the compile on a subsequent attempt. It's obvious to me that there : are not any errors in the source that are generating such problems. e.g. : dividing by zero. Has anyone else had such experiences? How about one of the : compiler and/or kernel experts speaking up? What would cause the compiler to : fail with a segmentation violation when one doesn't actually exist? What : would cause the kernel to generate such a signal and kill the compiler? [etc] I used to get this all the time. Then I changed the timing on my motherboard, and it went away completely--I haven't had a problem since, and I've rebuilt the kernel many times. This has been discussed before, and the culprits blamed were ISA<->memory transfers, motherboard memory itself, and the phases of the moon. It would appear that simple tests, especially DOS- or Windows-based tests, don't pound the machine hard enough, so rebuilding the Linux kernel is a pretty good test. In any case, you can imagine that if gcc started paging, and one of the paging transfers had an error in it, thus changing the code, you could get a seg. violation. One problem with the kernel, at least the last time I looked, is that a lot of the hardware traps are mapped to one signal, segmentation violation. I'm not sure if that's a POSIX thing or what, but it does make figuring out what's going on a bit of a hassle. Anyway, if your motherboard has lots of settings like mine does, start changing things like ISA bus speed, DRAM wait states, ISA bus wait states, etc. If it doesn't, you might be SOL. I think the thing I did that made the most dramatic difference was slowing the ISA bus down to 8 Mhz. A lot of motherboards have a 12Mhz setting, and many ISA bus cards are unreliable at 12Mhz. Others have found that replacing SIMMs cured their problems. Also, if you have a 50Mhz DX motherboard, like I do, you might just want to replace it with a 66Mhz DX2...Oh, another thing I've remembered--when I first got my motherboard, it crashed a lot, and the problem turned out to be that I had a 50Mhz motherboard with cache RAM for a 33Mhz motherboard, so make sure that your cache SRAMs are fast enough. -- Peter ------------------------------ From: gw@gwcomp.e.open.de (Georg Wiegand) Subject: fallback during boot in all cases? [was: Re: [moddev README omission]] Date: Mon, 28 Mar 1994 21:56:37 GMT Reply-To: gw@gwcomp.e.open.de In article <1994Mar26.194716.18712@afterlife.ncsc.mil>, John Epstein wrote: >There is an important omission in moddev-0.1 README file. >The lines to add to rc.local should be >/sbin/insmod /sbin/moddev.o >modload & > >The README file omitted the "&" --- booting will not finish!!! >It did say modload runs in the background, which subtley implies >that the "&" is needed. > >That is why one should ALWAYS have a fall back method of rescuing ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >one's system. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >John BTW: What could it be to watch *all* possible errors during bootup ? To put a line like: trap 'echo -e "rc: status -- $?\ngoing single user .."; /bin/sh' 1 2 probably in every /etc/ (rc, rc.local, rc.(i)net) I'm shure there are better solutions ? george -- ******************************************************************************* # Georg Wiegand |Email: gw@gwcomp.e.open.de # # University Essen, Germany |Phone/Fax: +49 201 495192 # ******************************************************************************* ------------------------------ From: owurm@k.mup.de (Oliver Wurm) Crossposted-To: comp.os.linux.misc,comp.os.linux.admin,comp.os.linux.help Subject: How to execute SCO binaries ??? Date: 28 Mar 1994 08:17:45 GMT Hi everybody, there is only one reason for us to run our SCO UNIX server under SCO UNIX: We need some of the SCO-Programs installed there. I've read some time ago in one of the comp.os.linux.??? Newsgroups about an iBCS - Emulator, which is able to run the SCO binaries, but I can't find it on the ftp servers (most of them are SunSITE-mirrors). **PLEASE** mail me the name of a ftp server and the path to the iBCS stuff. Thanks in advance, Oliver Wurm \\\// EMail: owurm@k.mup.de (o o) ==============================ooO=(_)=Ooo====================== , , , , ,---, , |\./| ___ ___ _ _~|~ -+- |---'_ _~|~ _ _ _ | | |_| | | | | | | |_~ | |_ ' | |_| | |_ | | |_~ | ____________________Unternehmensberatung GmbH__________________ Neue Weyerstrasse 6 Tel: +49 (221) 92404 227 D-50676 Koeln Fax: +49 (221) 92404 199 (-33 from US) ------------------------------ From: acbul1@lindblat.cc.monash.edu.au (Andrew Bulhak) Crossposted-To: comp.sys.cbm Subject: Re: PC as C64 file server Date: 29 Mar 1994 05:34:56 GMT Sven Goldt (goldt@math.tu-berlin.de) wrote: : paul (paul@dino.eng.monash.edu.au) wrote: : : Ok, : : It seems quite clear that there is a need for a device that allows : : a standard ibm pc to be used as a file server for our humble ol' Commodore : : 64's. Is anyone working on such a device? What do people think about the idea? : : Is it possible ?? : Well,it IS possible.If i find the time i will write such : a client/server package.The HD could be accessed just like a : normal floppy.I think the c64 part could act like a : fastloader and the PC (server) part as a device driver or tsr program,but : i prefer to use a server under unix. I was thinking of a Linux daemon which polls a device on /dev/lp0 or somewhere and acts as a virtual 1541. That way, this would place a very light load on the machine, allowing it to be used for other tasks as well. Another Linux/1541 project, the reciprocal of this, would be a 1541 file system which uses the X1541 cable. -- Andrew Bulhak acb@yoyo.cc.monash.edu.au Slackware: The Linux of the SubGenius. ------------------------------ ** 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-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@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-Development Digest ******************************