627 lines
24 KiB
Plaintext
627 lines
24 KiB
Plaintext
From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
|
|
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 <car1002@cus.cam.ac.uk> 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 <zmbenhalCLwtwH.8D@netcom.com> 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 <grin>
|
|
|
|
--
|
|
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
|
|
<linux/ip.h> and <linux/icmp.h> 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.94Feb25034736@husc7.harvard.edu> 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 </dev/cua1
|
|
done |egrep min >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
|
|
******************************
|