lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory mail-archive

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:25:02 -05:00
parent 07129c3397
commit a778c607a4
1056 changed files with 796887 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

573
mail-archive/linux-devel/Volume1/digest5XX/digest551 Normal file
View File

@@ -0,0 +1,573 @@
Subject: Linux-Development Digest #551
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, 14 Mar 94 04:13:08 EST
Linux-Development Digest #551, Volume #1 Mon, 14 Mar 94 04:13:08 EST
Contents:
Re: dip for PPP when? (Michael Callahan)
Misleading ENODEV from SCSI open and messages from mount(8) (Ian Jackson)
Re: Problem with NET-2 and Winsock Gopher/HTTP clients? (NetDog)
Re: A truely non-debugging Kernel? (Frank Lofaro)
0.99p15j: bug in SLIP ? And unusual hang in NE*-Detection (System Administrator)
Re: DIP: tty: getc: I/O error (Tin Le)
cleaning rbuf for sk=00694410 tcp_ack (root@jaxnet.com)
127.x.x.x (was Re: UDP report card) (Frank Lofaro)
Real-Time Linux and a/d device drivers (David G. Boney)
Re: A truely non-debugging Kernel? (Alex Ramos)
Re: 127.x.x.x (was Re: UDP report card) (Charles Hedrick)
----------------------------------------------------------------------------
From: callahan@cluanie.maths (Michael Callahan)
Subject: Re: dip for PPP when?
Date: Sun, 13 Mar 94 22:48:53 GMT
In article <stock.763204643@dutsh7.tudelft.nl>,
Robert Stockmann <stock@dutsh7.tudelft.nl> wrote:
>After looking at dip , I noticed that there is an option for
>choosing PPP as protocol. however looking at the
>ppp.c routine it gives a message that its not implemented yet.
>
>When will this be? is someone working on it?
>
>The main advantage of dip over chat is that the script language
>is much more flexible, which is important when one wants
>to connect with PPP after a call back from a PPP server.
>
>robert stockmann <stock@dutsh7.tudelft.nl>
I have no plans on working on PPP support for dip, but would be
happy if someone else took it on.
If DIP can be made to call an external executable, then just have
it run pppd when the PPP server is on the line.
Michael
callahan@maths.ox.ac.uk
------------------------------
From: iwj10@cus.cam.ac.uk (Ian Jackson)
Subject: Misleading ENODEV from SCSI open and messages from mount(8)
Date: Sun, 13 Mar 1994 20:13:09 GMT
It seems that the kernel returns ENODEV ("No such device") if you try
to pass a filesystem type to mount(2) that it doesn't support
(fs/super.c).
However, the SCSI device drivers (drivers/scsi/sd.c) return ENODEV if
you try to access a disk that's not there. Most other devices return
ENXIO ("No such device or address") in this case.
The mount(8) program does some rather nasty return code translation.
It interprets the ENODEV as having come from a bad filesystem type,
and so prints "fs type ext2 not supported by kernel" or whatever, when
it should have said "No such device or address" or something similar.
I therefore suggest that:
(a) drivers/scsi/sd.c be modified to return ENXIO if the disk doesn't
exist.
(b) mount say what was wrong in more detail by at the very least
having a different message for each value of errno (most would be the
ones from strerror).
--
Ian Jackson, at home <ijackson@nyx.cs.du.edu> or <iwj10@cus.cam.ac.uk>
PGP2 public key available on server. Urgent email: <iwj10@phx.cam.ac.uk>
2 Lexington Close, Cambridge, CB4 3LS, England; phone: +44 223 64238
------------------------------
From: cdent@yod.honors.indiana.edu (NetDog)
Subject: Re: Problem with NET-2 and Winsock Gopher/HTTP clients?
Date: Mon, 14 Mar 1994 05:23:55 GMT
>>>>> "Steven" == Steven Kirby <kirby@scarlett.libs.uga.edu> writes:
[snipped info on problems with winsock gopher clients and linux servers]
Steven> Any advice/information will be most appreciated,
Steven> especially if it will help me figure out who to bother
Steven> first with this problem.
Your posting in comp.infosystems.gopher seems to say that you have
found a solution to the problem. What is it?
Also, does Linux 1.0 solve this problem?
I've been messing around in the gopherd.c code (adding close(sockfd)
after every writing of ".\r\n") but really have no idea if that is a
valid solution.
Could someone (Steven, Alan, whoever) clear up what's going on hear?
Thanks,
Chris
--
cdent@indiana.edu | Chris Dent IU
------------------------------
From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: A truely non-debugging Kernel?
Date: Mon, 14 Mar 94 00:37:41 GMT
In article <1994Mar13.222442.15907@ringer.cs.utsa.edu> ferovick@runner (David C Ferovick) writes:
>In article <1994Mar13.205037.24215@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
>>In article <1994Mar12.195624.9113@rpp386> jfh@rpp386.cactus.org (John F. Haugh II) writes:
>>>In article <DOUG.94Mar11165709@midget.towson.edu> doug@midget.towson.edu (Doug McNaught) writes:
>>>>In article <2loo9h$fo8@aurora.engr.latech.edu> ramos@engr.latech.edu (Alex Ramos) writes:
>>>>
>>>>>Geez! The kernel has _so much_ debugging code (sanity checks, etc) that
>>>>>I wonder how much smaller it could be. It seems most kernel developers
>>>>>have never heard of #ifdef... Just a thought :-)
>>>>
>>>> Well, I'd rather give up some memory and have something that panics
>>>>and shuts itself down rather than blindly hosing my filesystems and/or
>>>>hardware... I *like* sanity checks. A lot.
>>>
>>>That's all or nothing thinking -- ship the kernel with #ifdef DEBUG and
>>>after a few weeks when you are happy, recompile with -UDEBUG.
>>>
>>
>>Well what do you do then if the kernel suddenly goes bonkers one day,
>>and clobbers you /usr partition or something awful like that?!
>>Commerical un*xes have sanity checks, etc, why shouldn't Linux? Plus, if
>>you have a very intermittent problem, the debug stuff might make it
>>possible to find out what it is, else you'll never know. You'd have to
>>recompile with debugging after the fact and wait for it to happen again.
>>That might be an uncomfortable wait for those with mission-critical or
>>security related problems.
>>
>
>Well, if there was #ifdef's in there, it would be the USER's choice to run
>witht the debugging code or not...If a user thinks he may have a problem
>or is paranoid about not having the debugging code in the kernel, then they
>can leave it running. If you want to save memory and increase performance,
>then the user can take the risk of #undef'ing the debug code...
>
>--
>Dave Ferovick
>(ferovick@runner.jpl.utsa.edu)
There is a problem with that thought. Suppose a user compiles without
debugging and has a problem. They just say: "It crashes!", "It don't
work!", "Its broken!" and they can't give us the information we need
to fix a problem. Now if they do compile with debugging, they can tell
use what is in syslog files, what is printed, etc. No debugging means
error go unreported and unnoticed until something gets hosed, which
may be way to far after the fact (e.g. memory allocation errors, bad
I/O statuses, etc.)
We would have to make it clear that we could only help users that had
problems if they would compile with debugging enabled. I wouldn't
waste my time trying to help someone in a case where I had to try to
deduce what caused the failure, instead of having the information I
need to fix it without undue difficulty. I'd say (nicely of course),
please recompile with debugging and try again and tell us what
happens. Some subtle bugs might go unnoticed with non-debug kernels,
causing possible security holes or weird failures when they finally
"express" themselves.
Also, what does one do if there is an error that shows up in
an non-debugging kernel, but goes away in the debugging one? Then you
would HAVE TO work without the aid of debugging code. Or what if the
developers all test with debugging (wouldn't surprise me in the least)
and something the "debug" code does, e.g zero out memory,is depended
on by "normal" code. That could cause (possibly hard to find) errors
with non-debugging kernels. Developers would have to test with
debugging and normal kernels, wasting time. Or what if someone's
driver, etc works with the normal code, but changes in the debug code
cause it to break under newer debugging kernels. This would force
people to pull debugging out of their kernel or not use the driver, a
bad choice to have to make. I'd consider the driver broken: and not
use it, fix it, or not buy the hardware it uses due to poor linux
support if possible, e.g. not floppy code or somesuch, then I would be
hosed. If such a thing got mainstreamed it would be even worse.
Imagine if most of the "debug" code ended up like the malloc debugging
(okay, I admit that should be #ifdef'd, but the concept applies) code:
it is hashed out in config.in, and re-enabling it resulted in a kernel
which refused to link due to unresolved symbols (looks like stuff just
got out of sync and incompatible). This begs the question: would debug
code be supported well?
Some things should be #ifdef'd I agree, but not all. The current
situation is good I think. There real hefty debug code is left out,
but the other stuff is left in. Better for tracking problems and makes
testing, figuring out and debugging the kernel easier without having
to recompile.
------------------------------
From: root@desaster.sunflower.sub.org (System Administrator)
Subject: 0.99p15j: bug in SLIP ? And unusual hang in NE*-Detection
Date: Sat, 5 Mar 1994 03:06:20 GMT
I was using SLIP (not CSLIP :-( ) for some time, had two ncftp running when
the line dropped. I killed the ncftp-programs, and dialed again.
After reconnection, data came in, I suspect for the no-longer-there
ftp-connections - but netstat reportet they where still there!
(status: ESTABLISHED).
After a while this went away (the incoming data, not the netstat-status
for the long-ago-killed ftp-sessions), and I just worked on. Then, quite
some time after that, the following appeared in my syslog.err:
Mar 4 07:52:19 desaster linux: net timer expired - reason unknown, sk=007CCDFC
Mar 4 07:52:50 desaster linux: kfree of non-kmalloced memory: 007CCDF4, next= 00748000, order=4
Mar 4 07:53:10 desaster linux: kfree of non-kmalloced memory: 007CCDF4, next= 00748000, order=4
Mar 4 07:53:50 desaster last message repeated 2 times
Any idea what this is, and any idea how to trace down a potential bug ahere?
Another thing that I experienced this morning when I booted my machine, it
hung at the NE2000-detection (trying 0x300). It was completely hung, I had
to press the red-button. This never (!) happened before.
Cheers, Michael Will
------------------------------
From: tinle@starbase.sj.unisys.com (Tin Le)
Subject: Re: DIP: tty: getc: I/O error
Date: 12 Mar 1994 02:45:34 GMT
In article <2lgqt8$buo@nic.ott.hookup.net>, root@borg.ott.ca (Sys admin) writes:
|> * No gettys on the serial ports *
|> When I first boot my machine, I can run kermit as much as I want with no
|> problems. My first DIP script runs fine, but when I kill DIP via kill -9 pid,
|> enter kermit, enter hang command to hang up modem, I have to re-boot!
|> DIP now gives me the error in the subject, or sometimes it hangs when setting
|> the port to ttyS0. Kermit starts, then hangs untill I enter CTRL-C, which
|> brings me to the kermit prompt. When I enter 'connect' I get
|> Kermit -> Can't send character: I/O error.
|>
|> Can anyone else confirm this????
|>
|> Linux 99pl15j. Libc4.5.21.
I am running pre-1.0 and have seen similar error message. What seems to have
happened is that my DIP script set the modem to return result (ATQ0), and that
causes the serial driver problems. My system does not hang, but DIP and cu will
always give me those errors (actually cu will report receiving hangup [HUP] signal
and disconnect every time).
The fix is to power cycle my modem, which defaults to ATQ1E0V0. Then DIP, cu and
anything else that uses the port will work again. I have not had time to look at
the source yet. Perhaps someone more familiar with it can tell right away what
the problem is.
Regards,
Tin Le
--
=====
Tin Le | comp.binaries.ms-windows Moderator
TL Consulting | Send submissions to cbmsw@Saigon.COM
Current Office: 408-456-5587 | Requests to cbmsw-request@Saigon.COM
tinle@sj.unisys.com | Archive on wuarchive.wustl.edu
Or tin@saigon.com | MailServer at mailserv@Saigon.COM
------------------------------
From: root@jaxnet.com
Subject: cleaning rbuf for sk=00694410 tcp_ack
Date: Thu, 10 Mar 1994 05:35:27 GMT
Last night I got some strange messages out of the kernel. I am posting them
in case some developer out there is trying to fix bugs and that this one is
unknown. I strongly suspect what is wrong is way over my head. The system
did not crash and my slip connection is still running.
I run Linux 0.99.pl15j
CPU AMD386dx40
RAM 8meg
2 IDE hard drives
I am a heavy user of SLIP _NOT_ CSLIP
I am running DIP 3.3.4 SLIP/DIP work great I don't have to do any special
routing commands to make it work. my MTU is 1500.
The tty66 input overruns are _NOT_ from my slip connection I run my slip
connection on the 16550a chip on tty01
Here are the messages from my kernel:
<6>Console: colour EGA+ 80x50, 8 virtual consoles
<6>Serial driver version 3.99a with no serial options enabled
<6>tty00 at 0x03f8 (irq = 4) is a 16450
<6>tty01 at 0x02f8 (irq = 3) is a 16550A
<6>tty02 at 0x03e8 (irq = 4) is a 16450
<6>tty03 at 0x02e8 (irq = 3) is a 16450
<6>lp_init: lp1 exists (0), using polling driver
<6>Calibrating delay loop.. ok - 7.98 BogoMips
<6>Memory: 7404k/8448k available (456k kernel code, 384k reserved, 204k data)
<6>Floppy drive(s): fd0 is 1.44M, fd1 is 1.2M
<6>Swansea University Computer Society Net2Debugged [1.27]
<6>IP Protocols: ICMP, UDP, TCP
<6>SLIP: version 0.7.5 (4 channels)
<6>CSLIP: code copyright 1989 Regents of the University of California
<6>Linux version 0.99.15j (root@jaxnet) #1 Wed Mar 2 22:05:44 GMT 1994
<6>Partition check:
<6> hda: hda1 hda2
<6> hdb: hdb1 hdb2 hdb3
<6>VFS: Mounted root (ext2 filesystem) readonly.
<6>Adding Swap: 8184k swap-space
<6>Adding Swap: 16792k swap-space
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>tty66: input overrun
<6>cleaning rbuf for sk=00694410
<6>sk->rspace = 4096, was 4096
<6>tcp_ack: seq a5d05de6 ack 13d04455
<6>Data wakeup.
<6>cleaning rbuf for sk=00694410
<6>sk->rspace = 4096, was 4096
<6>cleaning rbuf for sk=00694410
<6>sk->rspace = 4096, was 4096
<6>tcp_ack: seq a5d05de6 ack 13d04456
<6>Data wakeup.
<6>cleaning rbuf for sk=00694410
<6>sk->rspace = 4096, was 4096
<6>tcp_ack: seq a5d05de7 ack 13d04456
--
Karl Renaut
root@jaxnet.com
------------------------------
Crossposted-To: comp.protocols.tcp-ip
From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: 127.x.x.x (was Re: UDP report card)
Date: Mon, 14 Mar 94 01:11:13 GMT
In article <Mar.13.17.50.52.1994.1393@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>ftlofaro@unlv.edu (Frank Lofaro) writes:
>
>>Linux USED TO handle 127.x.x.x right for all values of x.
>>Now all 127.x.x.x address other than 127.0.0.1 seem to try to send out
>>the default route.
>>This is bad, can we bring back the old behavior (thus not violating the RFC's
>>anymore like we are now)?
>
>I'm not convinced that it's right for 127.0.0.2 to be regarded as
>loopback. But if you want it, you can get it. It's all a matter of
>how you set up routing when you turn on loopback. I just enabled lo
>(which I normally don't have running) using
>
> ifconfig lo 127.0.0.1
> route -n add 127.0.0.0 dev lo
>
>Ping works equally well to 127.0.0.1 or 127.0.0.200.
Well the route thing works.
However, I think that all 127.x.x.x addresses should be loopback.
1: It does not break anybody's set up, unless they are violating RFC's
by using the 127 net for their own purposes (they deserve to lose, they
aren't interoperable)
2: Have 127.x.x.x always be loopback is MANDATED by rfc1122.
RFC1122:
--- rfc excerpts follow:
3. INTERNET LAYER PROTOCOLS .................................... 27
3.1 INTRODUCTION ............................................ 27
3.2 PROTOCOL WALK-THROUGH .................................. 29
3.2.1 Internet Protocol -- IP ............................ 29
3.2.1.1 Version Number ............................... 29
3.2.1.2 Checksum ..................................... 29
3.2.1.3 Addressing ................................... 29
[...]
3.2.1.3 Addressing: RFC-791 Section 3.2
[...]
(g) { 127, <any> }
Internal host loopback address. Addresses of this form
MUST NOT appear outside a host.
--- end of RFC excerpts.
Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
comment? If my interpretation is correct, 127.x.x.x should always be
looped back.
Is rfc1122 obsolete? Or does the 127.x.x.x statemnet shown above still
hold?
------------------------------
From: dboney@cs.ttu.edu (David G. Boney)
Subject: Real-Time Linux and a/d device drivers
Reply-To: dboney@cs.ttu.edu
Date: Mon, 14 Mar 94 01:13:22 GMT
--
Hi,
Are there any realtime extentions for Linux? Does any have a UN*X device driver
for a National Instruments AT-MIO-16 a/d board. Any type of unix would be OK. It would
give me a place to start.
Sincerely,
David G. Boney
American Heart Association Medical Student Research Fellow
Texas Tech School of Medicine
dboney@cs.ttu.edu Texas Tech University
Ph. 806-742-1191 Department of Computer Science
Lubbock, Tx. 79409 USA
------------------------------
From: ramos@engr.latech.edu (Alex Ramos)
Subject: Re: A truely non-debugging Kernel?
Date: 14 Mar 1994 05:56:47 GMT
Frank Lofaro (ftlofaro@unlv.edu), quoted out of context, wrote:
> Well what do you do then if the kernel suddenly goes bonkers one day,
> and clobbers you /usr partition or something awful like that?!
> Commerical un*xes have sanity checks, etc, why shouldn't Linux? Plus, if
> you have a very intermittent problem, the debug stuff might make it
> possible to find out what it is, else you'll never know. You'd have to
> recompile with debugging after the fact and wait for it to happen again.
> That might be an uncomfortable wait for those with mission-critical or
> security related problems.
I couldn't care less if my machine has security problems, since I'm the
only user. And really, a clobbered /usr partition is no big deal
either, I trash entire disks every so often.
However, all the extra debugging junk *is* a problem, because I only
have 2 megs of RAM, on a 16-mhz 16-bit processor!
Of course other people think differently.. but that's exactly one of
the good uses for #ifdef!
#ifdef KDEBUG
if ( 2+2 != 4 ) { /* :-) */
panic("integer arithmetic failure");
}
#endif
--
Alex Ramos <ramos@engr.latech.edu> * This message is copyrighted material!
Louisiana Tech University BSEE/Sr * All rights reserved. No warranty, etc
------------------------------
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Crossposted-To: comp.protocols.tcp-ip
Subject: Re: 127.x.x.x (was Re: UDP report card)
Date: 14 Mar 94 02:14:06 GMT
ftlofaro@unlv.edu (Frank Lofaro) writes:
>Well the route thing works.
>However, I think that all 127.x.x.x addresses should be loopback.
>Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
>comment? If my interpretation is correct, 127.x.x.x should always be
>looped back.
1) "the route thing" is probably the only solution you're going to get
at the moment. Where to send packets is by definition the
responsibility of the routing table. Under 0.99pl15 and later, the
kernel does not make routing entries. Your startup script is expected
to do so. That's not specific to 127. It's true for all networks. I
think the reason this worked in previous releases is the ifconfig
created routes automatically, and it doesn't do so now. After some
thought I believe I agree with Linus that enabling an interface
shouldn't create a route. That's the job of the route command. There
are different ways one might want to set up the route.
2) The RFC is clear that 127 addresses should never appear outside the
host. I don't believe it was intended to say that they have to be
implemented on the host. That is, one could simply drop all packets
to 127, and not receive any of them. I personally consider 127 to be
a class A network with exactly one host on it, 127.0.0.1. I believe
that any other 127 address should be considered "host unreachable".
But the point being made by the RFC's is: whatever you do with 127 on
your machine, no address involving it should show up outside your
machine. In the Linux context, the easiest way to do that is with
route add 127.0.0.0 dev lo
I think after release 1.0 we're going to tighten up on bogon
prevention. This includes handling all kinds of illegal addresses,
etc. I would argue that if the loopback interface is not enabled or
the route not set up, we should find a way to prevent 127 packets from
going out. Note that even under the old code, if you didn't ifconfig
the loopback, 127 would be sent out the default route. That's wrong.
One could argue that rc.local is part of the system as a whole, and
it's the responsibility of the people creating setup scripts to make
sure that the loopback interface is always turned on properly. I
guess I'd be willing to accept that, but it would make me feel
slightly better to know that 127 will never leave the machine.
By the way, the same problem occurs with incoming packets. If a
machine is misconfigured so that it sends to 127.0.0.1 on an Ethernet,
I believe we should not respond to an ARP response, and if a packet
addressed to 127.0.0.1 somehow comes from the outside, it should be
silently dropped.
------------------------------
** 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
******************************