lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
eec934fe6cdf00ff46c70c324c1949d18222ecc3
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest101
gohigh 32616db5a4 add directory ftp-archives
2024-02-19 00:24:15 -05:00

558 lines
21 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
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: Thu, 1 Sep 94 13:13:09 EDT
Subject: Linux-Development Digest #101
Linux-Development Digest #101, Volume #2 Thu, 1 Sep 94 13:13:09 EDT
Contents:
Re: AAAAAH - Where Linux.1.1.49 (Robert G. Smith)
RE: ext2fs floppy/82077 corruption with 1.1.49 (ddelsig@uoft02.utoledo.edu)
Kernel change summary 1.1.48 -> 1.1.49 (Russell Nelson)
IDE write bug (John Wilson)
Any interest for DCF77 clock code? (David Kastrup)
<patch> updating system clock w/o APM (nozomi@glaucomys.seino.tsukuba.ac.jp)
Re: DOSEMU successes (Andreas Zisowsky)
Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library) (David Barr)
Re: SOCK_PACKET: Why not reading outgoing packets ? (Robert Sanders)
Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library) (Robert Sanders)
Re: Future of linux -- the sequel (Lawrence Foard)
----------------------------------------------------------------------------
From: rob@bip.anatomy.upenn.edu (Robert G. Smith)
Subject: Re: AAAAAH - Where Linux.1.1.49
Date: 1 Sep 1994 13:25:02 GMT
Robert Mudge (mudge@sunny.dab.ge.com) wrote:
: I was referenced to linux 1.1.49,
: can't find it on sunsite...
: can anyone tell me where it is?
The patches and a few of the complete sources are on:
sunsite.unc.edu:pub/Linux/kernel/v1.1
linuxftp.caltech.edu:pub/Linux/Linus/v1.1
ftp.funet.fi:pub/OS/Linux/PEOPLE/Linus/v1.1
and many other sites.
Try to download during the late night hours for the site
to avoid clogging busy networks.
Install the patches (must of course be done in sequence) with:
cd /usr/src
zcat patch??.gz | patch -p0
If you want the complete distribution (updated usually a few
days after the patches are released) try:
linuxftp.caltech.edu:pub/Linux/patched-kernels
For more info on all of this, read the HOWTO documents
at:
sunsite.unc.edu:pub/Linux/docs/HOWTO
Also please read the c.o.linux.admin and c.o.linux.help
newsgroups for more info on this subject.
Hope this helps,
Rob Smith
------------------------------
From: ddelsig@uoft02.utoledo.edu
Subject: RE: ext2fs floppy/82077 corruption with 1.1.49
Date: Thu, 1 Sep 1994 04:14:02 GMT
>This is guaranteed to demonstrate the problem on 82077 based systems.
>I have verified it on two systems with 82077 chips on cards from
>different manufacturers. I know it did so on 47 and 48, as well as 1.1.49,
>but can't vouch for how far it goes back. I sent this to the KERNEL
>channel, but I think the mail-server ate it. :-(
>
>1) mke2fs a floppy
>2) mount it and copy a big (~500k) file to it (or several files)
>3) unmount it but _don't_ eject it
>4) run "e2fsck -vrf /dev/fd0" --- it will come up clean (reading the cache)
>5) eject it and immediately stick it back in (set disk change flag)
>6) Repeat step 4 -- you will get most of the blocks in the above file(s)
> being marked as "not in use".
>
>Paul.
Paul,
What are the terms of your guarantee? :)
I've got a Compaq Concerto with an 82077 on it, running kernel 1.1.49. I
followed your instructions on how to screw up my floppies, and was not able to
generate any errors. On my first try I used a 670 K file, on the second I used
~1.1 M of smaller files. Neither tries complained or gave me any trouble.
What version of mke2fs did you use? I've got version 0.5 (latest?) Hopefully
some others will try this out on their floppies and see if indeed there is a
problem with the 82077.
Dave
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
```````````````````````````````````````````````````````````````````````````````
_/_/_/_/ _/_/ _/_/ _/_/_/_/ David M. Del Signore
_/ _/ _/_/ _/_/ _/ _/ University of Toledo
_/ _/ _/ _/ _/ _/ _/ _/ Toledo, Ohio
_/ _/ _/ _/_/ _/ _/ _/
_/ _/ _/ _/ _/ _/ _/ ddelsig@uoft02.utoledo.edu
_/_/_/_/ _/_/ _/_/ _/_/_/_/ suprdave@esserv01.eng.utoledo.edu
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
```````````````````````````````````````````````````````````````````````````````
------------------------------
From: nelson@crynwr.com (Russell Nelson)
Crossposted-To: comp.os.linux.announce
Subject: Kernel change summary 1.1.48 -> 1.1.49
Date: 01 Sep 1994 03:14:49 GMT
Switching to release 2.6 of SoundBlaster Pro CD-ROM driver. No real
changes, just cleaning up a few code sillynesses.
Support changed to one or two floppy controllers (not up to four).
Immediately after reading the ID bytes off the IDE driver, reset the
driver IFF it's a Quantum.
Added a little more delay to turning off the ID information.
Fixed spellling erors in ni5210 and ni6510 dirver messages.
SCSI disk driver deleted the wrong disk device.
Added a few calls to MAP_NR macro in filesystem buffer code (no change
in actual code).
Set the block size of a file when an inode is created.
MSDOS filesystem wasn't able to deal with files with embedded blanks
(supposedly illegal but DOS will let some intrinsics create them).
A few more compatibility fixes.
Create a macro for printing our return address.
A whole bunch of embedded/trailing whitespace removed from skbuff.c
Caught an off-by-one flag in TCP checksum code.
--
-russ <nelson@crynwr.com> http://www.crynwr.com/crynwr/nelson.html
Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St. | +1 315 268 1925 (9201 FAX) | What is thee doing about it?
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.
------------------------------
From: wilsonj@alum01.its.rpi.edu (John Wilson)
Crossposted-To: alt.comp.hardware.homebuilt,comp.periphs
Subject: IDE write bug
Date: 1 Sep 1994 07:06:25 GMT
Does anyone know the specifics of the alleged bug in some IDE drives
where if you get an interrupt while writing data to the sector buffer,
the drive writes the wrong data to disk? I found a reference to this
behavior somewhere in the Linux docs (and in /usr/src/linux/drivers/block/
hd.c), but the code is hard for me to follow so I'm not clear on which
calls to cli() and sti() are relevant to the bug and which aren't.
My angle is, I have a homemade IDE interface running my own BIOS which
writes the wrong data to the right sector (I think) on my Conner drive
once in a blue moon (causing havoc as you can imagine), I've always
assumed it was my rat's nest wiring but if all I have to do enclose my
REP STOSWs in cli/sti instructions and everything will be fine, I'd
like to know about it! The interface is supposed to be a prototype for
several "for real" projects so it's important to me to fix it, it's not
like I still use my old PC that much...
So, does anyone know anything about this? Does it matter if you have
an interrupt (or other delay) between DRQ coming on and actually
writing the buffer or is it only bad once you've written the first
word of data? Is there any way to tell for sure whether a drive has
the bug (it would be nice to not disable ints if it's not necessary)?
Is this all just the pigment of my imagination after all and it's my
own damn fault I keep losing files?
Thanks, John Wilson
------------------------------
From: dak@rama.informatik.rwth-aachen.de (David Kastrup)
Subject: Any interest for DCF77 clock code?
Date: 31 Aug 1994 17:56:12 GMT
Trying to get a head count...
How many people would be interested in a small program which gets the current
time from the radio clock DCF77 (receivable about 900km around Frankfurt,
Deutschland, official time base for Germany) and sets the system time?
Comes with man page, and has
options making it secure to use, say, daily in your crontab, while updating
the CMOS clock as well.
It sets UTC directly, so is timezone independent. You need a small radio
clock device tied up to a serial port.
This program will be freely available to whoever wants it.
However, making it a package requires that there are specifications
included concerning the hardware.
Would you please answer me, and tell me if
a) A logic description of the hardware would be ok for you.
b) A circuit diagram would be ok for you (circuits about 20DM)
c) You would rather buy a finished product for 50DM.
Since the latter would cause development costs for me, I will only delve
into it if sufficient response is there. Note that everything softwarish
item will be freely available, including circuit diagram.
In case there is enough interest in ready to use hardware, I will include
an offer in the documentation. In case there is not, I will leave out
the offer, but include a circuit diagram.
I will not go into the bother of producing devices myself if I do not
get a head count of at least 10 which would definitely purchase their
device from me (including a 3.5" disk with the software, if wanted.
But it will be ftp-able as well).
Apart from the "offer-hardware-or-not"-question, the thing is running,
including man-page, and so you should be able to pick it up somewhere
around next week. See c.o.l.a.
David Kastrup dak@pool.informatik.rwth-aachen.de
Tel: +49-241-72419 Fax: +49-241-79502
Goethestr. 20, D-52064 Aachen
--
David Kastrup dak@pool.informatik.rwth-aachen.de
Tel: +49-241-72419 Fax: +49-241-79502
Goethestr. 20, D-52064 Aachen
------------------------------
From: nozomi@glaucomys.seino.tsukuba.ac.jp
Subject: <patch> updating system clock w/o APM
Date: 1 Sep 94 07:53:29 GMT
I use Linux 1.1.48 on T3400, which can supend and resume,
but does not have APM bios.
I made the following small patch to update system clock.
The interval of update is determined by the BogoMips.
It might be useful these machines with suspend/resume
but without APM.
There was minute/second mismach in warp_clock, kernel/time.c.
Of course, you may redistribute this pach under the GPL.
Nozomi
_________________________________
--- kernel/sys.c.original Sun Aug 28 12:21:37 1994
+++ kernel/sys.c Sun Aug 28 12:35:56 1994
@@ -35,6 +35,11 @@
return -EINVAL;
}
+extern unsigned long refresh_system_time_each;
+extern unsigned long system_time_refresh;
+extern void warp_clock(void);
+extern void ask_RTC_time(void);
+
asmlinkage int sys_idle(void)
{
int i;
@@ -51,6 +56,11 @@
for (;;) {
if (hlt_works_ok && !need_resched)
__asm__("hlt");
+ if(0 == --system_time_refresh) {
+ ask_RTC_time();
+ warp_clock();
+ system_time_refresh = refresh_system_time_each;
+ }
schedule();
}
}
--- kernel/time.c.original Sun Aug 28 12:27:05 1994
+++ kernel/time.c Sun Aug 28 12:35:12 1994
@@ -60,23 +60,9 @@
)*60 + sec; /* finally seconds */
}
-void time_init(void)
+void ask_RTC_time(void)
{
unsigned int year, mon, day, hour, min, sec;
- int i;
-
- /* checking for Update-In-Progress could be done more elegantly
- * (using the "update finished"-interrupt for example), but that
- * would require excessive testing. promise I'll do that when I find
- * the time. - Torsten
- */
- /* read RTC exactly on falling edge of update flag */
- for (i = 0 ; i < 1000000 ; i++) /* may take up to 1 second... */
- if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)
- break;
- for (i = 0 ; i < 1000000 ; i++) /* must try at least 2.228 ms*/
- if (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP))
- break;
do { /* Isn't this overkill ? UIP above should guarantee consistency */
sec = CMOS_READ(RTC_SECONDS);
min = CMOS_READ(RTC_MINUTES);
@@ -98,6 +84,25 @@
year += 100;
xtime.tv_sec = mktime(year, mon, day, hour, min, sec);
}
+
+void time_init(void)
+{
+ int i;
+
+ /* checking for Update-In-Progress could be done more elegantly
+ * (using the "update finished"-interrupt for example), but that
+ * would require excessive testing. promise I'll do that when I find
+ * the time. - Torsten
+ */
+ /* read RTC exactly on falling edge of update flag */
+ for (i = 0 ; i < 1000000 ; i++) /* may take up to 1 second... */
+ if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)
+ break;
+ for (i = 0 ; i < 1000000 ; i++) /* must try at least 2.228 ms*/
+ if (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP))
+ break;
+ ask_RTC_time();
+}
/*
* The timezone where the local system is located. Used as a default by some
* programs who obtain this value by using gettimeofday.
@@ -250,7 +255,7 @@
inline static void warp_clock(void)
{
cli();
- xtime.tv_sec += sys_tz.tz_minuteswest * 60;
+ xtime.tv_sec += sys_tz.tz_minuteswest;
sti();
}
--- init/main.c.original Sun Aug 28 12:18:38 1994
+++ init/main.c Sun Aug 28 12:37:58 1994
@@ -247,6 +247,9 @@
unsigned long loops_per_sec = 1;
+unsigned long refresh_system_time_each;
+unsigned long system_time_refresh;
+
static void calibrate_delay(void)
{
int ticks;
@@ -266,6 +269,8 @@
printk("ok - %lu.%02lu BogoMips\n",
loops_per_sec/500000,
(loops_per_sec/5000) % 100);
+ system_time_refresh
+ = refresh_system_time_each = loops_per_sec/10000;
return;
}
}
--
$B#N#O#Z(B $B0KF#!!4u!J$N$>$_!K!!C^GHBg3X!!@8J*2J3X7O(B
$B#O!!#O(B nozomi@glaucomys.seino.tsukuba.ac.jp
$B#Z#O#N(B
------------------------------
From: zisi@cs.tu-berlin.de (Andreas Zisowsky)
Subject: Re: DOSEMU successes
Date: 31 Aug 1994 18:21:39 GMT
mkrisch@avalanche.mpce.mq.edu.au (Mark Krischer) writes:
>thinking of going back to my good old reliable WordPerfect for DOS. I've got the nice
>version 6.0, and am wondering how well that runs under DOSEMU. and how well DOSEMU runs
Even in graphic mode I have no problems with it using MS-Dos 5. Only when
using Novell Dos 7 under Dosemu, WP says "access denied" to some files
(also some other programs do).
Ciao.
Andreas
--
Andreas Zisowsky ----- Internet: zisi@cs.tu-berlin.de
zisi@marie.physik.tu-berlin.de
------------------------------
From: barr@pop.psu.edu (David Barr)
Subject: Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library)
Date: 1 Sep 1994 10:38:46 -0400
In article <RSANDERS.94Aug31133242@hrothgar.mindspring.com>,
Robert Sanders <rsanders@mindspring.com> wrote:
>Linux does that; shared libraries have major and minor revision
>numbers.
Sure, but the loader mechansim is significantly different than
Solaris', so it's not really the same.
--Dave
------------------------------
From: rsanders@mindspring.com (Robert Sanders)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
Subject: Re: SOCK_PACKET: Why not reading outgoing packets ?
Date: 30 Aug 1994 17:46:26 GMT
On 30 Aug 1994 16:25:00 +0100, morten@gurke.allcon.com (Morten Jammer) said:
> Why can the socket typ SOCK_PACKET only read outgoing packets
> when the interface is in promiscious mode ?
In later kernels SOCK_PACKET does return outgoing packets. I can't
give you the exact patchlevel, but I think it's in the late 1.1.30
series. Check the kernel changelogs generously posted by Russ Nelson
(also available from nic.funet.fi:/pub/OS/Linux/PEOPLE/Linus/v1.1).
-- Robert
------------------------------
From: rsanders@mindspring.com (Robert Sanders)
Subject: Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library)
Date: 31 Aug 1994 17:32:40 GMT
On 31 Aug 1994 12:26:17 -0400, barr@pop.psu.edu (David Barr) said:
> Being a long-time SunOS 4.x user/admin and dreading the move to
> Solaris along with everbody else, this is one thing that Solaris
> does better.
I wouldn't be so sure. In fact, I'd think twice before ever saying
that.
> Filenames libraries in Solaris are compiled in to the binary. If you
> make a compatible change/bugfix to a shared C library, you simply
> replace the shared library in-place. If you make an incompatible
> change, then you bump the revision number and BOTH the current programs
> work as well as the old ones. (assuming you keep the old shared
> libraries around) Everbody's happy.
Linux does that; shared libraries have major and minor revision
numbers. Minor revision numbers are for compatible changes. So,
binaries compiled for libc 4.5.x will happily work with 4.6.x.
Binaries compiled for libc 4.6.x will work with 4.5.x, but will give a
warning. binaries compiled for libc 5.y.x won't even look at libc
4.y.x.
-- Robert
------------------------------
From: entropy@world.std.com (Lawrence Foard)
Subject: Re: Future of linux -- the sequel
Date: Thu, 1 Sep 1994 17:03:32 GMT
In article <1994Sep1.143432.27144@reks.uia.ac.be>,
Peter.Leyssens <leyssens@uia.ac.be> wrote:
>
>Hi,
>
>I think Linux used to be quite fine as it is, but now things are changing.
>Linux is a free Unix-clone and there is no reason to choose it over another
>U**x-version except that it's free. If you want a more stable system or
>a better programming, you can choose something different.
Free is only one reason, better is a bigger reason for many things. I'm
porting a custom greenhouse database system to Linux. The main reason for
the change is that Linux works better than SCO, cost is only part of the
reason. If SCO was as good as Linux and Linux as bad as SCO it would be
worth while paying $1000 for it.
>Linux was THE choice when the only other choices were BSD/386 or OpenDesktop.
>Now, there's Solaris, NextStep as well, and Windows NT.
And how are they better than Linux? How much hardware support does Solaris
or Nextstep have? What if I want to modify the kernel?
>It's time to make choice. There's a lot ahead (Multi-Processing, Micro-kernels)
>and Linux is NOT following. This should be quite clear. Everybody's constantly
>asking : "Has Linux already been ported to system XXX or CPU YYY ?" And
>the usual answer is : nope, but they're working on it, wait a year or so.
>Porting takes way too long. Linux is stuck on one system, and that's the
>Intel PC-series with ISA/VL-BUS.
Why should I pay 5 times more for a non PC system which gives me the same
performance as a 486 100? When there are enough non PC users to port
Linux to other platforms it will get ported. Why do you expect
PC users to spend $10K for a workstation so they can spend time porting
Linux to it? Its up to the people who own those systems to put in the
effort, don't expect someone to do it for you. (If you have all that
extra money to throw around why not pay somone to port it?)
>And with multi-CPU-pc's knocking at your door (I mean, this is reality :
>dual Pentiums are becoming more and more common, there are Inmos T800 and
>i-860 plug-in-boards, and the Acorn Risc-PC has the standard multi-CPU
>system, that allows 2 completely different (1 ARM, 1 486) to work together),
>it's time to jump on that boat.
When someone who owns them wants Linux to work on them they will port it.
If you want it ported maybe you should donate one to someone who has the
time to do porting?
>The only way (as I see it) to get great multi-processing power is to find
>a micro-kernel (or write one :), and see that the rest is portable enough.
What does micro-kernel have to do with anything? Most multi CPU OS's are
monolithic kernels.
>Linux isn't portable. And we all would like to plug in a Dec/Alpha board
>into our PC and see performance triple, wouldn't we ?
Linux hasn't been ported, that doesn't mean it can't be, or that its even
that hard. Only a small fraction of kernel code these days is machine
dependant.
>I heard Linux/Mach is being worked on... Well, Mach isn't quite multi-
>processing either (or is it ?). I'd like to have some information on that
>please, I'll be compiling the Mach-kernel myself one of these days.
You mean one of these years :) The GNU-hurd (or heard?) project has been
going on for years before Linux was even thought of. Linux is running, the
micro-kernel hurd is still in vapor land.
--
====== Call the skeptic hotline 1=900=666=5555 talk to your own personal .
\ / skeptic 24 hours/day. Just say no to victimless crimes. . .
\ / High quality Linux application development available. . . .
\/ Violence is a lousy substitute for sex and drugs. . . . .
------------------------------
** 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
******************************
Reference in New Issue View Git Blame Copy Permalink