From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Mon, 28 Feb 94 23:13:09 EST Subject: Linux-Development Digest #509 Linux-Development Digest #509, Volume #1 Mon, 28 Feb 94 23:13:09 EST Contents: Re: GOD SPEAKS ON LINUX! (Doug McLaren) Re: Weird problems with sendmail 8.6.5 and 8.6.6 (Florian La Roche) linux/gcc (f)printf does not function when X11 linked (Jeffrey) Re: The GNU Public Virus rides again! (was Re: Specialix driver) (Alan Cox) Re: Patch to scheduler in developemnt : Simple Question (Christopher Shaulis) Re: Keyboard bug (Zeyd M. Ben-Halim) Re: Linux Darkstar 0.99.15 #2 Sat Jan 1 21:36:13 MET 1994 Alpha ?? (Pat Mackinlay) Re: structs ip and icmp not defined in pl15h (J Rozes) Re: Netmasks not on byte boundaries? (Mark Evans) Re: Serious 80386 bug (Tom Raggett) Re: Linux + ISDN = ????? (Alan Cox) Re: Why not put cluster diffs in nominal kernel before 1.0? (Alan Cox) Re: Specialix driver (Alan Cox) Re: TCP quirk PL15h (Rene COUGNENC) Re: dip at 14.4?? (Rene COUGNENC) Re: Linux and X WordPerfect (Rene COUGNENC) Re: Patch to scheduler in developemnt : Simple Question (Rene COUGNENC) serial driver woes (Greg McGary) ---------------------------------------------------------------------------- From: dougmc@utpapa.ph.utexas.edu (Doug McLaren) Crossposted-To: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc Subject: Re: GOD SPEAKS ON LINUX! Date: 28 Feb 1994 18:37:59 GMT In article <1994Feb25.101009.15694@infodev.cam.ac.uk>, Chris Royle wrote: | God (God@Up.There.Above) wrote: | > THIS IS THE VOICE OF THE LORD! | | [Followed by several more lines of bollocks in a spoofed news-posting with | incorrect headers.] I do like how he was able to even spoof 'NNTP-Posting-Host:' - makes me wonder if he has access to the news server itself, and did more than just 'telnet port 119' ... | In the words of Queen Victoria, "We are not amused". Now get lost you sad | wanker, and stop wasting bandwidth that a lot of people have to pay for. I was amused. Therefore, it is not a waste of bandwidth to me. If you're really concerned about bandwidth, stop crossposting to all these newsgroups! :) -- dougmc@utpapa.ph.utexas.edu "The stupider it looks, the more important it probably is." - J.R. "Bob" Dobbs, The Book of the SubGenius ------------------------------ From: rzsfl@sbusol.rz.uni-sb.de (Florian La Roche) Crossposted-To: comp.mail.sendmail Subject: Re: Weird problems with sendmail 8.6.5 and 8.6.6 Date: 28 Feb 1994 17:22:04 GMT Edvard Tuinder (Edvard.Tuinder@delirium.NL.MugNet.ORG) wrote: : Hi, : I'm experiencing a real weird problem with my sendmail. I recently : upgraded from 8.6.4 to 8.6.5. Since that time I am unable to send : local mail to any user, except when they have a .forward file. : Today I've tried 8.6.6, but the same thing happens. Look at 134.96.7.7:/pub/Linux/source/networking/mail for a working version of sendmail 8.6.6.Beta9. There is some quirks with the GNU getopt <-> BSD getopt. I have mailed the changes to the sendmail mailing list, but I don't know, if they have been included for the 8.6.6 release. As usual gcc 2.5.8, libc 4.5.21, kernel 0.99pl15h.my Florian La Roche ------------------------------ From: haym@pegasus.rutgers.edu (Jeffrey) Crossposted-To: comp.windows.x.i386unix,comp.os.linux.help,gnu.gcc.help Subject: linux/gcc (f)printf does not function when X11 linked Date: 28 Feb 94 19:15:30 GMT [posting for a friend; please reply to: dwp@tix.timeplex.com] Under Linux 0.99 ~r15/darkstar released ~11/93, Under an application compiled with gcc, (f)printf does not function when -lX11 is linked in. (f)flush does not help. (printf does function under gdb) Do I need to include or link anything special to get printf to function? thanks! david preisler please reply to: dwp@tix.timeplex.com ------------------------------ Crossposted-To: gnu.misc.discuss From: iiitac@swan.pyr (Alan Cox) Subject: Re: The GNU Public Virus rides again! (was Re: Specialix driver) Date: Mon, 28 Feb 1994 20:21:05 GMT In article <1994Feb26.013334.27351@mnemosyne.cs.du.edu> jmaynard@nyx10.cs.du.edu (Jay Maynard) writes: > >It's a real shame that I don't have the email RMS sent me a couple of years >ago, saying how they'd NEVER do this; the FSF would only consider a program to >be infected by the GPV if it textually included "significant" chunks of GPV'ed >code. On that basis, I agreed that the GPV wasn't as virulent as I'd thought. >Looks like they either changed their mind or simply pulled the wool over my >eyes. > >Looks like it's time to go home and scrub Linux off of the machine I built up >to run it... Not really the library is LGPL/BSD/PD and the kernel is Linus and co code which RMS and the FSF don't own and have little say over. Alan iiitac@pyr.swan.ac.uk ------------------------------ From: cjs@netcom.com (Christopher Shaulis) Subject: Re: Patch to scheduler in developemnt : Simple Question Date: Mon, 28 Feb 1994 20:13:10 GMT stimpson@panix.com (S. Joel Katz) writes: > You don't want users who run setuid root programs to count against >the superuser. You don't want logins, gettys and system daemons and stuff to >count either (or do you?). I have to determine during the fork system call >whether to mark the process as part of the special group or not. Is there >some simple algorithm that I haven't thought off? Uhhh.. if logins, gettys, and deamons don't count.. how is your beloved super-user gonna log in to use his time slices? Just curious, :) Christopher ___ _ ___ ____ _ _ ___ _____ ___ ___ __ __ ___ ___ __ __ / __|_ | |/ __| / __ \| \| | __|_ _|/ __|/ _ \| \/ | / __|/ _ \| \/ | | (__| |_| |\__ \/ / _` | .` | _| | | | (__| (_) | |\/| | _| (__| (_) | |\/| | \___|\___/ |___/\ \__,_|_|\_|___| |_| \___|\___/|_| |_|(_)\___|\___/|_| |_| ==================\____/======================================================= ------------------------------ From: zmbenhal@netcom.com (Zeyd M. Ben-Halim) Subject: Re: Keyboard bug Date: Mon, 28 Feb 1994 20:40:24 GMT In article zmbenhal@netcom.com (Zeyd M. Ben-Halim) writes: >In article <1994Feb24.091143.8381@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes: >>In article <2khjek$6ob@sleepy.cc.utexas.edu> jc@sleepy.cc.utexas.edu (Jonathan Clark) writes: >>> Possible keyboard driver bug : the key 'r' does not come through >>>when the keyboard is put in K_RAW mode. Instead the Scroll Lock light >>>blinks. Does anyone know why and how I can a. get around this, or b. >>>fix it. I am writing a video game for Linux and would prefer that >>>any user could run the game (without having to patch). >>> >>> Thanks, >>> JC >> >>Put the tty into RAW mode too. (the same ioctls stty raw would use). The >>scan code for r is translating into the ascii code for a flow control character. >>(I think ctrl-s) > >What is your definition of RAW mode? >You need to turn off IXON and IXOFF in addition to ICANON, ECHO, and ISIG. You also need to switch cr<->nl mapping otherwise '=' and '9' will give the same scan code. -- --- Zeyd M. Ben-Halim zmbenhal@netcom.com 10479 1/4 Santa Monica Blvd, LA, CA, 90025 (310) 470-0281 ------------------------------ From: pat@garion.it.com.au (Pat Mackinlay) Subject: Re: Linux Darkstar 0.99.15 #2 Sat Jan 1 21:36:13 MET 1994 Alpha ?? Date: 1 Mar 1994 03:47:14 +0800 job (jdbogan@kimbark.uchicago.edu) wrote: : In article <2ko84g$hri@rubb.rz.ruhr-uni-bochum.de> ruediger@tau.ep1.ruhr-uni-bochum.de (Ruediger Berlich) writes: : >With all those new processors around I would expect : >Intel to come up with a 'real' RISC-Processor one day : >exclusevely for the PC-Market. No 8086-Compatibility no nothing. : They already have. the i750, i860, and i960's are all nice risc : microprocessors. It's just that intel hasn't been pushing them in the pc : arena (their main useage seems to be in the large parrallel computing : projects). Unfortunately, Intel not only ditched the 8086 mode with the above CPUs, they also decided not to put an MMU on them. They are all targetted at embedded systems (where the real money is anyhow), and are not suitable for using as workstation CPUs. PS: And if you think moving from an x86 architecture to an i860 one would make programming easier, you're sadly mistaken - fast it may be, but it doesn't come under "nice" in my books -- pat -- empty space is wasted space. ------------------------------ From: jrozes@allegro.cs.tufts.edu (J Rozes) Subject: Re: structs ip and icmp not defined in pl15h Date: Mon, 28 Feb 1994 21:59:57 GMT I was just porting the NetBSD timed and interestingly, I found that and do not define struct ip and struct icmp, respectively. I did some grep'ing to see if they were defined elsewhere, but came up with nothing. I'm using the standard pl15, patched to pl15h, all taken from nic.funet.fi. No net3 code or anything like that; it's a vanilla kernel (+ppp). Sooo... is this a mistake, a "feature" or am I just (likely) missing something? thanks, jonathan ------------------------------ From: evansmp@mb48026.aston.ac.uk (Mark Evans) Subject: Re: Netmasks not on byte boundaries? Date: Mon, 28 Feb 1994 18:37:02 GMT Charles Hedrick (hedrick@geneva.rutgers.edu) wrote: : There's no problem with odd netmasks under Linux. If you don't : specify a netmask, it will use the standard ones, but the fancy : byte-oriented guessing code is no longer present. The only case I : know of where it will not deal with netmasks correctly is ICMP : redirects. In that case there's no netmask present, so it will assume The RFC specified behaviour is to treat ALL redirects as HOST redirects. (Until someone specs a redirect which includes the netmask) : the standard ones. This is a bug. It's supposed to redirect only the : host. (I'll try to get that fixed.) ------------------------------ From: Tom@racing.demon.co.uk (Tom Raggett) Subject: Re: Serious 80386 bug Reply-To: Tom@racing.demon.co.uk Date: Mon, 28 Feb 1994 19:40:34 +0000 In article <2kh93k$i81@harbinger.cc.monash.edu.au> billm@jacobi.maths.monash.edu.au "WE Metzenthen" writes: > I have attached the code which triggers the bug to the end of > this posting. BE AWARE THAT THIS CODE CAN RESULT IN DATA LOSS. It is > probably safest to put the code onto ram disk and run it without > any physical disks mounted. I have run it a number of times with > disks mounted and e2fsck has always been able to do the minor fix-up > when I rebooted. I ran the attached code, on my two year old AMD 386sx25 with .99pl12. It simply gave a Segmentation Fault and exited... Sorry to disappoint you, but there was no nasty crash. Andy Norman - AndyN@racing.demon.co.uk ------------------------------ From: iiitac@swan.pyr (Alan Cox) Subject: Re: Linux + ISDN = ????? Date: Mon, 28 Feb 1994 19:50:51 GMT ISDN should be doable soon. There is now a rather nice PPP ALPHA release for the protocol layer and all that's needed is the card software. I'm fortunately working on ISDN software at the moment, but for now real work time doesn't include a Linux driver port. I've added your message to the list of ISDN interested parties to plonk on the desk of the powers that be once we have a slack period (hoho!). Alan iiitac@pyr.swan.ac.uk ------------------------------ From: iiitac@swan.pyr (Alan Cox) Subject: Re: Why not put cluster diffs in nominal kernel before 1.0? Date: Mon, 28 Feb 1994 20:02:05 GMT In article <2kkoo0$6ee@renux.frmug.fr.net> cougnenc@itesec.ensta.fr (Rene COUGNENC) writes: >Ce brave Peter Mutsaers ecrit: > >> isn't it possible to put the SCSI cluster patches in the kernel before >> 1.0 is released? >> I know there was not supposed to be new stuff in the kernel before >> 1.0. But so many people have been using the cluster diffs for quite a >> while without trouble and with an enormous disk performance gain that >> it seems reasonable. > >Yes, and this is true for PPP too. > >But I think that unfortunately, we will have a 1.0 whith a good SLIP >in the kernel, and still have to patch for PPP... > I'd also like to see a 1.0 and a pl16 split together. There is a lot of code than in a month or so is going to be rock solid and well worth having (IBSC2,Quota,Acct,PPP,SCSI, New Networking ARP/linklists). Individually they are all rock solid I bet together they'll go berzerk.... Ah well on with the networking, and back to NET3 ALPHA.001 Alan iiitac@pyr.swan.ac.uk ------------------------------ From: iiitac@swan.pyr (Alan Cox) Subject: Re: Specialix driver Date: Mon, 28 Feb 1994 20:05:58 GMT In article dholland@husc7.harvard.edu (David Holland) writes: > >gt8134b@prism.gatech.EDU's message of 23 Feb 94 23:59:42 GMT said: > > > I would posit that the Linux kernel is the only available implementation > > of the Linux kernel interface. The Linux kernel is GPL'ed, therefore > > any driver written to interface with the kernel is GPL'ed. Russ's > > assertion is correct in the eyes of the FSF. > >All right. The Linux kernel is the only available implementation that >will run Linux binaries. Therefore Linux binaries have been created to >interface with the Linux kernel. The Linux kernel is GPL'd. Therefore, >everything which has ever been compiled to run under Linux is >automatically GPL'd. No the Linux interface is hardly unique and specialy at a functional level. In addition the interface to Linux is specifically not GPL'd. The whole issue is a bit of a mess. It's easy to see what RMS means to accomplish but not how its interpreted. Certainly I regard the two issues as seperate. I'm dubious about GPL forcibly applying to modules however.. > >So much for those commercial applications. Good thing BSD4.4-Lite is >coming out soon. 4.4-Lite is an irrelevance, its just more goodies and extensions for the NetBSD people Alan iiitac@pyr.swan.ac.uk ------------------------------ From: rene@renux.frmug.fr.net (Rene COUGNENC) Crossposted-To: comp.os.linux.admin Subject: Re: TCP quirk PL15h Date: 28 Feb 1994 13:35:47 GMT Reply-To: cougnenc@itesec.ensta.fr (Rene COUGNENC) Ce brave root@jaxnet.com ecrit: > I have noticed that tcp/ip connections are not terminating completely or > at least netstat is reporting the connections improperly. The following > is the output from the netstat command. The only real connection is one (...) > connected to the Internet via a SLIP connection using DIP 3.3.4 has anyone > else seen this type of ZOMBIE TCP CONNECTION? Yes, I experience that every day, just between my two Linux boxes. The problem is different for me: Sometimes, when I rlogin or telnet to the other box, and exit; the next rlogin or telet will wait 30 seconds. (minimum). Or sometimes the connections hang: renux:/home/rene $ netstat Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (State) (Uid) tcp 0 1825 renux.frmug.fr.n:login plux:1023 ESTABLISHED plux:/home/rene $ netstat Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (State) tcp 0 0 plux:1023 renux:login ESTABLISHED This is an xterm on the machine "plux", 'rlogged' on the machine 'renux'. It has been totally frozen for 2 hours, I can't type anything in it. Other connections ( deleted here) work ok. I notice that the problem occur more frequently when I connect another network whith a PPP or SLIP dialout... When a connection freeze like that, it is NEVER between the Linux box and the remote SLIP connection, but ALWAYS between my two Linux systems. Now, when I kill the processes, windows, and all, I try new "rlogin", this is what happens: plux:/home/rene $ rlogin renux ... nothing. wait, wait, wait. On renux, I get: tcp 2 0 renux.frmug.fr.n:login plux:1023 FIN_WAIT2 On plux, I get: tcp 0 0 plux:1023 renux:login SYN_SENT And I can wait like that one hour... I can no longer 'rlogin'. To be able to rlogin, I have to stop the rlogin procedure, wait for the old socket to be closed, (it can be long !), and then everything works proprely for a moment, until the next problem. (One hour or three days later, it occurs randomly). PS: I put a followup to c.o.l.d, since this is not an admin problem, but is related to the kernel... -- linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux ------------------------------ From: rene@renux.frmug.fr.net (Rene COUGNENC) Subject: Re: dip at 14.4?? Date: 28 Feb 1994 13:52:49 GMT Reply-To: cougnenc@itesec.ensta.fr (Rene COUGNENC) Ce brave Jim O'Quinn ecrit: > Is there a set of patches for dip that will run my modem at 14.4? > 9600 is wwwaaayy tttooo ssslllloooowwwww..... I'm sure that, in the documentation of your v32bis modem, it is explained that in order to get a 14400 connection, you have to set the speed of the modem / machine link to a fixed 19200, 38400 or 57600... -- linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux ------------------------------ From: rene@renux.frmug.fr.net (Rene COUGNENC) Subject: Re: Linux and X WordPerfect Date: 28 Feb 1994 13:59:46 GMT Reply-To: cougnenc@itesec.ensta.fr (Rene COUGNENC) Ce brave Eric Youngdale ecrit: > My own interests are in being able to run SVr4 binaries under linux. > Currently I can get Emacs compiled for SVr4 to come up under linux (non-X only Does the COFF or ELM format change something in the performance of the system ? I mean, is a COFF or ELM binary version of a given program, strictly equivalent in speed, memory usage, disk space, to a native Linux a.out binary ? -- linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux ------------------------------ From: rene@renux.frmug.fr.net (Rene COUGNENC) Subject: Re: Patch to scheduler in developemnt : Simple Question Date: 28 Feb 1994 14:04:47 GMT Reply-To: cougnenc@itesec.ensta.fr (Rene COUGNENC) Ce brave S. Joel Katz ecrit: > I am working on a patch to the Linux scheduler to reserve a > certain percentage of CPU time for the superuser. This would prevent mere > users from creating so many processors that a superuser couldn't access > the system quickly to fix some damage. > Now, my question: > You don't want users who run setuid root programs to count against > the superuser. You don't want logins, gettys and system daemons and stuff to > count either (or do you?). I have to determine during the fork system call Hmmm... getty and login perhaps yes: Imagine you have to quickly log as root to kill something and you don't have the cpu for that... -- linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux ------------------------------ From: gkm@tmn.com (Greg McGary) Subject: serial driver woes Date: 28 Feb 1994 22:35:12 -0500 Reply-To: gkm@tmn.com (Greg McGary) I've been wrestling with the linux 0.99.15 serial driver for a couple of days now with limited success. I would appreciate hearing from others who have delved into the serial/tty/ns16550a morass. Here are my findings, in no particular order: * I found at least three bugs in the calculation & deployment of rs_timer() timeouts, with the net result that timeouts intended to happen within a few jiffies don't happen for 60 seconds! When an interrupt is lost (and they are lost with some frequency), the driver waits all that time before things start up again. I discovered this after noting that uucp performance on my 14,400bps modem (with 16550a UART) was miserable due to 60 second dry-spells in transmission every 20-30Kb transferred. I fixed this, and got a significant improvement, but other problems still exist... * The code sets the 16550A FIFO trigger at 8 bytes. This appears to work for receive interrupts, but not for transmit--I always observe an interrupt per character on transmissions. * Receiving high speed file transfers (DCE->DCE at 14,400bps, and DCE->DTE at 38400bps) works reliably with zmodem, but is unreliable with uucp. The only observable difference is that zmodem sets VMIN to 96, while uucp sets VMIN to 6. My cursory inspection of the Taylor uucp code leads me to believe that it continually adjusts VMIN to match what its expecting according to the protocol ('g' in this case), but I observed no change in VMIN when I ran the following while a uucp transfer was in progress: while : do stty -a cua1.log I find it hard to believe statistically that I wouldn't take a snapshot of the tty modes at some time that the VMIN is set to some larger value for receiving a 64 byte packet. I'll have to run uucico under gdb, to see if the ioctl()s to reset VMIN are actually occurring. In any case though, application code shouldn't have to divine the "proper" settings of VMIN/VTIME in order to get reliable operation--the worst thing that should happen is that the CPU should have to work a bit harder with less efficient settings. * For some as yet unexplained reason, when I run the aforementioned unreliable uucp receive transfers with lots of printk() debugging turned on, the transfers become reliable and run at full speed (betw. 1200-1300 bytes/sec. on a gzip'ed file at 14,400 bps DCE->DCE). When I turn the debugging printk()s off, I get many "tty65: input overrun" errors. This makes no sense to me, firstly because printk() is relatively simple and fast, and secondly, if anything, the printk()s should prolong the interrupt handler and thereby *cause* more overrun errors. A worthwhile experiment would be to replace the printk()s with short delay loops to see if its the extra time that's significant, rather than something else peculiar about calling printk(). * The UART seems to require a "cooling off" period after servicing the interrupt, before the interrupt handler can return--I have to poll until the UART_IIR_NO_INT bit is set before returning. It usually takes at least a couple times around the service loop, after all I/O has been performed and there's nothing left to do, before the bit comes on. Sometimes, it takes a dozen loops before the bit comes on! This is neither here-nor-there, I just find it curious behavior, and, of course, it would be nice if the interrupt could be serviced faster without all the thumb-twiddling at the end, Now, some questions: * Is the Linux serial driver generally known to be buggy/unreliable at high speed, or is there something about my hardware configuration that's causing me problems that others don't have? * Are there multiple versions of the 16550a, some of which don't work--possibly like mine! :-( That's all that comes to mind at the moment. Please be in touch if you care about reliable, high-speed serial I/O under Linux and can help! -- Greg McGary (703) 729-6217 gkm@tmn.com 525K East Market Street, #110, Leesburg, Virginia, 22075 ------------------------------ ** 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 ******************************