From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Test-image of 0.96 available at banjo
Summary: just the binary
Date: 8 May 92 22:05:44 GMT
Organization: University of Helsinki
As 0.96 has some changes in harddisk IO handling (interrupts, timings
etc), I'd like for people that have ever had problems with the harddisk
driver under linux to try out the last test-image of the 0.96 kernel
before the official release - I'd rather not have the same types of
problems that we had with 0.95.
The image (no sources - wait till next week) is available at
banjo.concert.net: pub/Linux/Incoming/testimage.Z, and is just my
current bootimage that I'd like some feedback on.
The changes to the harddisk driver (which is the main reason I want to
make sure this version works) are just:
- interrupts enabled most of the time
- inb_p / outb_p changes
The first one is to lessen interrupt latency, the second one hopefully
helps people who had problems with the driver at high speeds. Both
changes work well for me, but then my machine seems to accept almost
anything... I hope 0.96 will work without any "a" releases.
I'd also be interested to hear if this image removes the problems with
serial lines at high speeds under X, as well as /any/ other problems. I
can still make minor bug-fixes if something turns up, but I'd want
reports by early next week or so (preferably with "testimage" in the
subject line).
The image is compiled with the us keyboard maps, and with the
floppy-device as root. It should be binary compatible with all old
versions, as well as the interim X version, so you just plug in the new
kernel and you're (hopefully) off.
Ignore this post if you don't have time to check out the image this
weekend: the image is only meant as a quick test-release to get some
fast feedback.
Linus
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Testers wanted... new 0.96 image
Date: 14 May 92 13:23:45 GMT
Organization: University of Helsinki
I've put a new testimage on banjo.concert.net:
pub/Linux/Linus/boot92.05.14.Z
and I hope people that have problems with 0.96 could try it out. I've
mainly tried to remove some races in the serial code, but I hope this
image also corrects the bootup problems experienced by some people.
If you have problems booting the original 0.96, or are seeing more
errors with the new serial lines, please try it out. As with the
earlier testimage, it's no use to me if you can't test it out in a day
or two: by that time I'll probably release 0.96a or a new testimage
depending on the success of this one.
Linus
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.96a out today/tomorrow
Date: 21 May 92 12:19:55 GMT
Organization: University of Helsinki
The subject say it all: I haven't heard any bad results (except somewhat
worse performance on the serial lines) from the testimage testers, so
I'll make 0.96a available tonight (Finnish time: EST) or tomorrow.
tsx-11, nic and banjo will be the sites I'll upload it to.
0.96a doesn't have any major new features: I just tried to correct known
bugs and get a stable version out the door. I hope 0.96 won't need any
more interim releases, but we'll see.
0.96a has gone back to non-interruptible hd-interrupts, and as long as
I'm not sure about the reason for the need of this, it's going to stay
that way. I hope this new version will run on all drives that have been
supported in the past, and the only known remaining problem is the Kalok
drives which have spurious interrupts. That's definitely a hardware
problem, and Branko Lankaster has patches that fake away these..
0.96a should also correct most of the serial line problems, and the
keyboard driver is now in C - I expect somebody will change it to allow
run-time keyboard changing. Additionally, there are various minor fixes
in various places:
- the kill fix by tytso that allows any process to wake up a stopped
process as long as it's in the same session.
- chown fix by card and me. Users can chgrp files they own to any group
they belong to etc - _POSIX_CHOWN_RESTRICTED should now be implemented
correctly. Also, chown() on a symlink now actually chown's the symlink
and not the file it points to (but GNU fileutils don't seem to want to
chown symlinks anyway - or maybe I have an older version)
- SIGSEGV fix by lankaster (?) which allows for better debugging after
protection faults. Most such errors are now trappable in gdb
(although some circumstances can still result in the process exiting
at once: out-of-memory errors etc)
I have also changed the memory manager to check for illegal memory
references (ie using the area between brk and stack), so debugging bad
pointer references should be much easier. This fix will hopefully also
trap the uncompress problem with bad files, but I haven't tried it out.
Programs can still call brk() with any value, so it doesn't mean that
you can't use up all available memory, but at least this should fix
/bad/ memory references. My limited tests with gdb seems to indicate it
all works nicely.
Core files are still not generated (I haven't got the slightest idea
what format they should have), so debugging isn't perfect yet, but it
should certainly be much easier.
Linus
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.96a available
Date: 22 May 92 21:01:59 GMT
Organization: University of Helsinki
Oh, well, no use in delaying it any more, so I sent out my latest
release to nic.funet.fi, tsx-11.mit.edu and banjo.concert.net. They
should show up in the next couple of days (they are already visible on
banjo: /pub/Linux/Linus). I hope all the bugs got fixed, but I did
something potentially stupid:
I had expected that lankaster wouldn't get his hd-speedup patches ready
for 0.96a, and I was resigned to the same hd-performance as with all
older releases. But when I saw them on the newsgroup today I thought
I'd try them out just in case, as I could always use my backup-version
if they backfired...
The point here is that the patch ended up in 0.96a after some minor
edits by me (one benign bug and some editing due to changed files). So
now hd-performance is much better on most operations. I just hope it
doesn't result in yet another release just to fix new bugs (but I doubt
it: the patches were really minor and clean - no ugly hacks needed I'm
happy to say). Branko already posted benchmarks, and I can only confirm
that it's indeed snappier, especially on writes. syncing is no longer a
pain even after heavy writing.
Other than the hd-performance, there are no new features I haven't
already mentioned in other posts. Bug-fixes, rewrites in C, better
debugging. I haven't made the cdiffs yet, so right now the new release
is only available as complete source and as a binary, but I'll try to
get patches done tonight. Possibly tomorrow. The patches will be
against the original 0.96, and shouldn't be too big.
Linus
PS. No need for more 16550 info: even if somebody doesn't implement it
for the next release, I think I can get it going. Doesn't seem too
hard. I'll also start to look into core-files. Eventually. Promise.
PPS. Ja 0.96a on taas saatavilla klaavasta /usr/tmp/linux'ssa
yliopistolla kirjoilla oleville.
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Patches...
Date: 24 May 92 10:43:10 GMT
Organization: University of Helsinki
I finally got around to doing the cdiffs against 0.96, and uploaded them
to the usual ftp-archives (nic,tsx and banjo). The patches are actually
about 35kB compressed, but they aren't as big as that sounds: it's
mainly due to the serial line changes and the fact that the keyboard
driver was changed to C. I don't know if somebody is actually going to
get the patches instead of the whole distribution, but at least it's
available if somebody does want it.
If you decide to get 0.96a by patching from 0.96, get the patch-file
(diff0.96-0.96a.Z), apply it, and remove the old keyboard.S driver: it
is no longer needed. You should also do a "make dep" to get the
dependencies up-to-date: I removed those from the cdiffs.
I am also going to upload the first set of patches against 0.96a later
today. The reason is that the faster harddisk driver had problems with
error situations, which I think I've fixed now. The patches also
correct the VC restoration with X11 after exiting (but see later). The
bugs aren't big enough to require a new version (so far I haven't had a
single bug-report on 0.96a: does it really work that well or are people
afraid to try it out?), so I'm just making the cdiffs available.
As to X: if you are using 0.1 it I'd suggest getting the new version.
It corrects the text-mode restoring bug, and with 0.96a with patch 1
applied I haven't seen any problems at all. xterm now handles resizing
correctly, and has shrunk considerably due to the multiple shared
libraries (from 570kB to 115kB).
Linus
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: linux-0.96a.patch1
Date: 24 May 92 11:46:43 GMT
Organization: University of Helsinki
Here is the patch to 0.96a that corrects the harddisk error bug, dup2()
and X11 text-mode restoration. Thanks to Rick Sladkey for finding the
dup2() bug.
This patch has also been sent to the ftp-archives.
Linus
----------
*** 0.96a/linux/fs/fcntl.c Fri Apr 24 18:36:09 1992
--- linux/fs/fcntl.c Sat May 23 23:24:24 1992
***************
*** 37,42 ****
--- 37,44 ----
int sys_dup2(unsigned int oldfd, unsigned int newfd)
{
+ if (oldfd >= NR_OPEN || !current->filp[oldfd])
+ return -EBADF;
if (newfd == oldfd)
return newfd;
sys_close(newfd);
*** 0.96a/linux/kernel/chr_drv/console.c Thu May 14 17:40:19 1992
--- linux/kernel/chr_drv/console.c Sun May 24 04:03:01 1992
***************
*** 56,64 ****
INIT_C_CC \
}
- static void blank_screen(void);
- static void unblank_screen(void);
-
/*
* These are set up by the setup-routine at boot-time:
*/
--- 56,61 ----
***************
*** 223,229 ****
{
if (video_type != VIDEO_TYPE_EGAC && video_type != VIDEO_TYPE_EGAM)
return;
! if (currcons != fg_console)
return;
cli();
outb_p(12, video_port_reg);
--- 220,226 ----
{
if (video_type != VIDEO_TYPE_EGAC && video_type != VIDEO_TYPE_EGAM)
return;
! if (currcons != fg_console || vt_cons[currcons].vt_mode == KD_GRAPHICS)
return;
cli();
outb_p(12, video_port_reg);
***************
*** 584,593 ****
printk("con_write: illegal tty\n\r");
return;
}
- if (vt_cons[currcons].vt_mode == KD_GRAPHICS) {
- flush(tty->write_q);
- return; /* no output in graphics mode */
- }
while (!tty->stopped && (c = GETCH(tty->write_q)) >= 0) {
if (c == 24 || c == 26)
state = ESnormal;
--- 581,586 ----
***************
*** 834,841 ****
state = ESnormal;
}
}
- set_cursor(currcons);
timer_active &= ~(1<< BLANK_TIMER);
if (currcons == fg_console)
if (console_blanked) {
timer_table[BLANK_TIMER].expires = 0;
--- 827,836 ----
state = ESnormal;
}
}
timer_active &= ~(1<< BLANK_TIMER);
+ if (vt_cons[currcons].vt_mode == KD_GRAPHICS)
+ return;
+ set_cursor(currcons);
if (currcons == fg_console)
if (console_blanked) {
timer_table[BLANK_TIMER].expires = 0;
***************
*** 1129,1136 ****
if (currcons<0 || currcons>=NR_CONSOLES)
currcons = 0;
- if (vt_cons[currcons].vt_mode == KD_GRAPHICS)
- return; /* no output in graphics mode */
while (c = *(b++)) {
if (c == 10) {
cr(currcons);
--- 1124,1129 ----
*** 0.96a/linux/kernel/chr_drv/vt.c Wed May 6 21:00:29 1992
--- linux/kernel/chr_drv/vt.c Sun May 24 03:50:43 1992
***************
*** 15,20 ****
--- 15,21 ----
#include < linux/sched.h>
#include < linux/tty.h>
+ #include < linux/timer.h>
#include < linux/kernel.h>
#include "vt_kern.h"
***************
*** 121,127 ****
default:
return -EINVAL;
}
! vt_cons[console].vt_mode = arg;
return 0;
case KDGETMODE:
verify_area((void *) arg, sizeof(unsigned long));
--- 122,138 ----
default:
return -EINVAL;
}
! if (vt_cons[console].vt_mode == (unsigned char) arg)
! return 0;
! vt_cons[console].vt_mode = (unsigned char) arg;
! if (console != fg_console)
! return 0;
! if (arg == KD_TEXT)
! unblank_screen();
! else {
! timer_active &= 1<< BLANK_TIMER;
! blank_screen();
! }
return 0;
case KDGETMODE:
verify_area((void *) arg, sizeof(unsigned long));
*** 0.96a/linux/kernel/blk_drv/hd.c Fri May 22 20:56:49 1992
--- linux/kernel/blk_drv/hd.c Sat May 23 17:03:41 1992
***************
*** 424,430 ****
return;
if (++CURRENT->errors >= MAX_ERRORS)
if (CURRENT->bh && CURRENT->nr_sectors > 2) {
! CURRENT->nr_sectors &= ~1;
next_buffer(0);
} else
end_request(0);
--- 424,435 ----
return;
if (++CURRENT->errors >= MAX_ERRORS)
if (CURRENT->bh && CURRENT->nr_sectors > 2) {
! CURRENT->nr_sectors--;
! CURRENT->sector++;
! if (CURRENT->nr_sectors & 1) {
! CURRENT->nr_sectors--;
! CURRENT->sector++;
! }
next_buffer(0);
} else
end_request(0);
***************
*** 530,536 ****
cli();
if (++CURRENT->errors >= MAX_ERRORS)
if (CURRENT->bh && CURRENT->nr_sectors > 2) {
! CURRENT->nr_sectors &= ~1;
next_buffer(0);
} else
end_request(0);
--- 535,546 ----
cli();
if (++CURRENT->errors >= MAX_ERRORS)
if (CURRENT->bh && CURRENT->nr_sectors > 2) {
! CURRENT->nr_sectors--;
! CURRENT->sector++;
! if (CURRENT->nr_sectors & 1) {
! CURRENT->nr_sectors--;
! CURRENT->sector++;
! }
next_buffer(0);
} else
end_request(0);
*** 0.96a/linux/kernel/blk_drv/blk.h Fri May 22 20:56:49 1992
--- linux/kernel/blk_drv/blk.h Sat May 23 17:00:10 1992
***************
*** 149,174 ****
wake_up(&bh->b_wait);
}
- extern inline void next_buffer(int uptodate)
- {
- struct buffer_head *tmp;
-
- CURRENT->bh->b_uptodate = uptodate;
- unlock_buffer(CURRENT->bh);
- if (!uptodate) {
- printk(DEVICE_NAME " I/O error\n\r");
- printk("dev %04x, block %d\n\r",CURRENT->dev,
- CURRENT->bh->b_blocknr);
- }
- tmp = CURRENT->bh;
- CURRENT->bh = CURRENT->bh->b_reqnext;
- tmp->b_reqnext = NULL;
- if (!CURRENT->bh)
- panic("next_buffer: request buffer list destroyed\r\n");
- CURRENT->buffer = CURRENT->bh->b_data;
- CURRENT->errors = 0;
- }
-
extern inline void end_request(int uptodate)
{
struct request * tmp;
--- 149,154 ----
***************
*** 188,193 ****
--- 168,195 ----
wake_up(&tmp->waiting);
tmp->dev = -1;
wake_up(&wait_for_request);
+ }
+
+ extern inline void next_buffer(int uptodate)
+ {
+ struct buffer_head *tmp;
+
+ tmp = CURRENT->bh;
+ CURRENT->bh = tmp->b_reqnext;
+ tmp->b_reqnext = NULL;
+ tmp->b_uptodate = uptodate;
+ unlock_buffer(tmp);
+ if (!uptodate) {
+ printk(DEVICE_NAME " I/O error\n\r");
+ printk("dev %04x, block %d\n\r",tmp->b_dev, tmp->b_blocknr);
+ }
+ if (!CURRENT->bh) {
+ printk("next_buffer: request buffer list destroyed\r\n");
+ end_request(0);
+ return;
+ }
+ CURRENT->buffer = CURRENT->bh->b_data;
+ CURRENT->errors = 0;
}
#ifdef DEVICE_INTR
*** 0.96a/linux/include/linux/tty.h Wed May 20 12:15:42 1992
--- linux/include/linux/tty.h Sun May 24 03:46:56 1992
***************
*** 195,200 ****
--- 195,202 ----
void copy_to_cooked(struct tty_struct * tty);
void update_screen(int new_console);
+ void blank_screen(void);
+ void unblank_screen(void);
int kill_pg(int pgrp, int sig, int priv);
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Second patch to 0.96a
Date: 4 Jun 92 22:56:21 GMT
Organization: University of Helsinki
I have just sent off the second patch to 0.96a: it should be on the
normal ftp-sites (nic, tsx-11 and banjo), although the only site which I
can make it directly readable on is banjo, so on the other sites it will
take the site-managers to make the patch available.
Patch 2 implements:
- itimers (by Darren Senn), which are now also used to implement the
alarm() system call.
- ultrastor scsi driver patches (by gentzel)
- [f]statfs() system call is implemented (so df can be made fs-
independent). Also some other minor fs-changes for the upcoming new
filesystem. Patches by Remy Card.
- preliminary core-file dumping code (linux creates a core-file, but
it's not in the correct format yet [*]).
- minor changes/bugfixes.
While patching in patch1 is a good idea for anybody, patch 2 isn't
really vital. I've made it available just so kernel hackers can keep up
with the kernel I have right now if they wish. Patch 2 is relative to
patch 1: you have to patch that in first.
[*] The current core-file is very simple, and the kernel code is there
just so that some enterprising character can expand it. A core-file
looks like this right now:
offset data
0x0000 "core-dump: regs=\n"
0x0040 struct pt_regs (see < sys/ptrace.c>)
0x0400 "floating-point regs:\n"
0x0440 struct i387 (see < linux/sched.h>)
0x0800 the first 1kB of user-space
Not very practical, but it /might/ help if the X-server dies of a
segmentation fault or similar (you can use pt_regs.eip to see where it
happened). The kernel code is very easy to change to accomodate for the
real core-file format, I just didn't know what it should be.
Linus
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: patch3....
Keywords: patch 0.96a
Date: 15 Jun 92 20:04:54 GMT
Organization: University of Helsinki
Ok, I already announced it on the kernel mailing-list, but I might as
well go all the way. I put out patch3 to 0.96a yesterday, and it's
available on banjo in pub/Linux/Linus, and I'll upload it to the other
normal ftp-sites tonight.
NOTE! Patch3 is (like patch2) more of a kernel-hacker patch: it's just
in case you want to keep up with my kernel. It has some problems with
some serial lines, and if you experience them, I'd like to know what
type of chip you are running (and what linux reports on bootup). If you
don't think patching the kernel is fun, you might as well forget this
and wait for a real release (next month?).
Patch 3 contains:
- support for attaching and detaching processes under gdb (but you need
a gdb that knows about this).
- 16550A support
- full core-dumping (again, you need a gdb that supports it)
- sockets have no problems with non-root binding etc
- /dev/zero implemented (mknod /dev/zero c 1 5)
None of the patches are very big (the whole patch is 17kB compressed,
most of it attach/detach code), but they are all pretty useful.
The 16550A support means that with the appropriate chip you now should
be able to use the serial ports at much higher speeds, but as mentioned,
it seems to break on some machines.
The detaching isn't perfect yet (I noticed only after making the diffs
that I had forgotten to do some cleanups), but it's not generally a
problem (the code just forgets to give the process back to it's rightful
father).
The patch is relative to the pl2 kernel, so you have to use the earlier
patches first. This time, I've added the lib/itimer.c code.
16550A support was written by tdavis, the correct format of the
core-dumps was written by eric (who also wrote the attach/detach code I
used as an example when implementing it), /dev/zero was written by
almesber. Nice to see good patches: I just did the socket-thing and
rewrote the attaching to suit me.
Linus
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Linux v 0.96b available
Keywords: new version 0.96b
Date: 21 Jun 92 23:12:23 GMT
Organization: University of Helsinki
I have uploaded my newest kernel sources and a US-keyboard image to both
tsx-11.mit.edu and nic.funet.fi. I'll put it on banjo too as soon as
banjo wakes up (that's when I'll do the patches too: I'll need access to
banjo to get a 0.96a.pl4 kernel to make patches against..). As usual,
it will probably be a day or two until the files have been moved from
the incoming directory to their proper places.
0.96b is not a new major release: it's pretty close to 0.96a with all my
patches (1-4). However, as there has been 4 patches already, I decided
it would be time for a full kernel release along with a bootimage, so
that people who don't feel confident with patching can use the new
features.
If you already have 0.96a patchlevel 4, 0.96b will offer you these new
features:
- the math-emulation now handles fsqrt, as gcc-2.2.2 generates that
inline. I haven't tested the kernel code at all: I tested the
algorithm in user space, but I'm lazy, so I never turned off my 387
to do real testing. I hope it works.
- better vt100 terminal emulation thanks to Mika Liljeberg.
- I removed a possible race-condition in the buffer-cache code.
- minor fixes
The vt100 emulation should now be complete enough for almost everything
(including vt100 test suites): as a result the setterm utility had to be
changed (as the old setterm codes aren't compatible with the full vt100
codes). setterm-0.96b.tar.Z contains the new setterm.
The soon-to-be-released gcc-2.2.2 will need the 0.96b kernel: (a) due to
the fsqrt emulation and (b) it uses the new stat() system call. So
upgrading is a good idea. (If you have a co-processor, (a) isn't used,
but (b) still stands)
If you have an unpatched 0.96a, the differences to 0.96b are roughly
(not counting the above-mentioned new things):
- corrected the disk-buffer-list bug with read/write-errors
- fixed read-ahead warning messages at end of disk
- better support for text-mode restoration after running MGR and X
- full core-dumping, attach/detach etc debugging features
- 16550A support
- less low 1MB memory used for kernel structures
- various minor fixes
Note that the fact that new versions (pl4 and above) use more memory in
the 1M+ area means that linux will report less free memory (it's used
for buffer-cache instead). This could concievably be a problem on 2MB
machines. The standard kernel comes with only 4 pty's though, and if
you use the standard 80x25 text modes instead of svga modes, the VC
buffers will be smaller. Please contact me if there are problems even
with this minimal setup.
0.96b does /not/ contain: the new scsi drivers, new filesystems or some
other patches I have gotten (ibm character set mode, loop-devices etc).
If you have sent me any other patch, you might want to remind me about
it.
Linus
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Serial lines patch: 0.96b.patch2
Date: 26 Jun 92 15:42:35 GMT
Organization: University of Helsinki
As promised, here is the second patch for 0.96b which hopefully clears
up the problems with some mice by implementing most of the serial line
flags like 5-8 bit characters and parity. It mainly corrects only
serial problems, but there are a couple of other patches in it too: the
fsqrt emulation patch is here, so if you already did it, you'll get a
bad patch for that file (which you can ignore). This patch also changes
all instances of signal-setting to use the "send_sig()" subroutine which
should allow gdb to debug all signals.
Apart from the serial lines, I also cleaned up the general tty-handling
routines slightly and removed at least one race-condition in the tty
code. I don't know if it's noticeable, though.
You'll need patch1 (available from all the normal sites) in order to
apply this one. As usual, I'd like to hear if this patch does help
people, or if there are new problems. This patch will also be available
on the normal ftp sites, but as it was pretty minor, I decided I might
as well include it in the post (uuencoded and compressed).
(I also corrected the all-time favourite bug: linux now reports the
right version number once more..)
Linus
[ Note to people that have sent me patches: I haven't had time to do
them. In some cases (the IBM char-set & BBS patch) other changes made
them unpatchable, in other cases I did the patch in a different way, and
yet other patches I was just too lazy to apply. As usual, re-sending
the patch relative to the newest version is a good idea, although it
still doesn't guarantee I'll use it ]
----------
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.96c out
Keywords: kernel release
Date: 4 Jul 92 23:25:40 GMT
Organization: University of Helsinki
The latest kernel version is 0.96c: the binary and sources can be found
on banjo.concert.net: pub/Linux/Linus as usual. I haven't made the
cdiffs yet, and I'll upload those tomorrow (at the same time I'll put it
on the other sites as well).
0.96c is actually what I called patch3 earlier this week, but as the new
features were pretty big and the cdiff's are probably going to be bigger
than the normal patches, I decided I might as well make it a totally new
minor release and make a bootimage and complete source available.
0.96c contains:
- bugfixes (tty, console driver, pty's, sockets)
- fifo's (names pipes - Paul Hargrove & editing by me)
- the alpha extended filesystem (Remy Card)
- st_blocks implemented (ie du, ls give reasonable if not exact values
for disk-space used)
- Makefile cleanups and warnings at compile-time removed
Note that while the extended filesystem code is there, and this kernel
successfully mounts and uses the new filesystem (with long filenames and
>64MB partitions), it's still under testing: I haven't made the mkefs
program available, and the extended filesystem features shouldn't be
used for other than testing right now.
Some of the changes are just cleanups: most of the warnings when
compiling the new kernel should be gone (not counting the scsi code
which is still the old non-cleaned-up version), and the make'ing of the
kernel is more logical now.
The bugfixes include the corrected console.c driver, the socket
corrections (without which X sometimes locks up), some pty semantics
corrections (although I'm still not certain it's correct) and some
editing in the general tty driver (including fixing the bug introduced
in 0.96b.pl2 that caused a reboot with uninitialized tty devices).
While the extended filesystem support isn't "official" yet, I can
happily report that my limited testing hasn't found any problems with
long filenames etc. It still needs a fsck program, but 1.0 looks like a
real possibility soon.
Linus
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.96c out
Keywords: kernel release
Date: 5 Jul 92 07:41:20 GMT
Organization: University of Helsinki
Earlier I wrote:
>The latest kernel version is 0.96c: the binary and sources can be found
>on banjo.concert.net: pub/Linux/Linus as usual.
I have had one report that 0.96c won't compile with an older gcc even
though 0.96b does ok. The solution is to get gcc-2.2.2: that's what I
use (the problem was the console.c file, specifically the asm statement
in scrup() - some gcc versions seem not to be able to keep enough
registers free for it).
If you are unwilling to get the new compiler, you might have to stay
with 0.96b.pl2 (or just get the new binary). Also note that if somebody
uses the extended-fs features, you'd want to recompile most programs
with 2.2.2 anyway: that way they use the correct vfs readdir() function
(reading a directory directly won't work on the ext-fs) and the new
stat() functions.
Linus
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Patch1 to 0.96c out
Keywords: 0.96c patch
Date: 11 Jul 92 20:40:11 GMT
Organization: University of Helsinki
[ I already sent this to the normal mailing-list, so you can skip this
if you already got it by mail ]
I have sent off my first patch to 0.96c: as usual it's available
directly from banjo.concert.net while nic.funet.fi and tsx-11.mit.edu
might take a day or two to put it into the right directories.
linux-0.96c.patch1 contains more changes than I originally envisioned: I
changed the IRQ routines and the serial code to be easier and cleaner
(and hopefully more efficient) and I thought that would be it. I was
wrong.
I got several patches (and one bug-report) again, and while I haven't
had time to check them all, some of them are in. Fixes:
- Remy Cards correction to the out-of-space problem with the extended
fs is here. Most people using the ext-fs might already have applied
this patch, in which case you might have problems patching.
- my ftruncate() fix is here. Again, if you already did the trivial
patch by hand, you'll get errors when patching.
- almesber's implementation of read-only filesystems is here (after
editing by yours truly). The mount() system call now accepts a flags
integer as well as a pointer to some arbitraty data in user space for
some special mount() calls. The general flags allow (a) read-only
mounting, (b) disabling of suid executables (c) disabling of device
special files and (d) total disabling of executables on a per-filesystem
basis. The filesystem specific mount() info isn't currently used by any
fs, but can be used to specify additional information that depends on a
special fs type (a password or similar would be possible..)
- the rename() system call had a bug in that it allowed moving over a
directory: I think the code to handle this was lost in the vfs editing,
and although the GNU mv utility checked it, a malicious (or just
unsuspecting) program can destroy the fs using this. Thanks for the
bug-report: it was very easy to add once I saw the problem.
- support for vesa-standard svga cards in setup.S. I'm unable to test
this, but my svga card still works after the patch, so I left it in in
the hope that it doesn't break for anybody else.
- various minor editing by me, or minor patches sent in by others.
The full cdiff is almost 50kB compressed, so this is a bigger-than-usual
patch. Hope there are no problems. People who are using the new SCSI
drivers might have problems with my changes to the SCSI irq-setup
changes, so be careful (actually using the original sources might be a
good idea, and then upgrading again). I hope to get the new SCSI
drivers into the kernel soon (definitely in time for 0.98).
I'd be interested to hear comments on serial line performance, bugs,
features, etc. As usual, I'm hoping this release won't contain any new
bugs while fixing all the old ones, but I guess that's likely to happen
right after the first winter olympics in Hell.
Linus
PS. Maybe nobody noticed, but I actually never made the patches to
0.96c available. As nobody has complained, I assume everybody just got
the complete kernel sources and used that. Unless somebody actually
asks for them, I don't think there is any point in making them any more.
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.96c second patch
Summary: it's out
Keywords: 0.96c patch
Date: 18 Jul 92 20:54:48 GMT
Organization: University of Helsinki
[ This already went out to the normal linux-activists list, so if you
got it that way, you can ignore this post. BTW, I have some reports
that some messages from over here don't make it all the way to the US,
so if you don't see this, mail me :-]
The subject pretty much says it all: I've sent out the "weekly patch"
and I'd be very interested in comments. As with patch1, there are some
very fundamental changes in the kernel, and they might have some
problems. I'd want as many as possible to test out linux-0.96c.pl2, as
that has always been the best way to test out the changes. Everything
works on my machine, but that doesn't guarantee it will work on other
setups...
The MAJOR change in 0.96c.pl2 is the totally rewritten sleep/wakeup
code. That, together with the IRQ code introduced in pl1 and slightly
edited in pl2, means that two very fundamental things in the linux
kernel have changed in the last two weeks. The code is cleaner, easier
to add devices to, and hopefully faster, but it's still a bit risky to
change this kind of very low-level behaviour.
Select() is now implemented using the vfs jump tables, and thanks to the
better sleep/wakup interface, select() performance should be noticeably
better. At least xload seems to give lower load-averages, and I hope
ka9q will work better with the new kernel. Note that things like the
tty code doesn't yet take full advantage of the new features the
rewritten sleep offers, but I wanted to get a good testing-release out
before actually tweaking all the routines to use the new interface.
The IRQ routines have changed slightly, and all known bugs are fixed.
While I'm most interested to hear comments about the IRQ and
select/sleep/wakup code, there are a few other changes in pl2:
- Swiss keyboard support.
- Screen blanking now only reacts to key-presses and kernel messages:
normal tty output doesn't make the screen unblank.
- DOS-fs version 5 is in. It wouldn't hurt to try it out. It's
somewhat alpha still, but it seems to work. mtools should be a thing of
the past once the dosfs is a bit more tested.
- core-file magic number, and a minor bug in ptrace is fixed
- a bus-mouse is supported. I'd like to hear if it still works after I
did the select() patches "blind" (I can't test it on my machine).
- iopl changing is possible (but requires root priviledges): this
allows access to all IO ports, as well as the interrupt flag. Don't use
it unless /absolutely/ necessary: a bug in your program will most likely
crash the machine if you are running with IO priviledges. It's needed
for some X VGA drivers.
As a result of all the changes, the diff is pretty big. Apply and build
it with something like:
cd /usr/src
zcat linux-0.96c.patch2.Z | patch -p0
cd linux
make dep
make clean
make Image
assuming you have the 0.96c.pl1 kernel in /usr/src/linux. I've had some
reports that my patches won't always go in cleanly: I know for a fact
that patch1 patches cleanly (I rebuilt 0.96c.pl1 by downloading it all
from banjo), so the error is in your end.
Possible problems:
- The VESA code in setup.S has some problems. I haven't even looked
into it yet, so if it won't work for you, please either (a) use the
unpatched setup.S from 0.96c, or (b) try to find the problem and tell
me. (b) is preferable, of course. I'd like to have VESA support, but
if the bug isn't found, I'll have to use the non-VESA version for 0.97.
- The IRQ code in 0.96c.pl1 could overrun the stack if linux got
un-ending interrupt requests, resulting in a re-boot. With pl2, this
shouldn't happen: linux should print out something like "Recursive
interrupt on IRQx. Shutting down" and simply disable the problematic
IRQ line. If you see this message, I'd be very interested to hear about
it (which IRQ, what devices you have, etc).
- And any new or old bugs I haven't found yet.
I have one report that 0.96c.pl1 has problems with the inode table, and
panics on bootup with a "no more inodes in mem" report. Can anybody
confirm this sighting? I haven't found the reason for it, and haven't
seen it myself. I'm hoping it's an installation problem, but if anybody
else sees the same behaviour, I'm SOL.
Linus
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.96c second patch
Keywords: 0.96c patch
Date: 18 Jul 92 22:43:04 GMT
Organization: University of Helsinki
Oops. I forgot to mention that the sleep/wakeup code changes in patch2
change the kernel data structures enough to freak out 'ps' etc programs
that go mucking around with /dev/kmem. It is not enough just to do a
"ps U" to update the nametables: you actually have to recompile the ps
package.
Linus
|