Kernel Traffic #19 For 20�May�1999

By Zack Brown

Table Of Contents

Introduction

Unfortunately, LinuxHQ (http://www.linuxhq.com) seems down at the moment, so the story titles don't lead into the archives. I'll fix this as soon as the site is back up and I get a chance.

(Update: and there's the reason (http://www.kernelnotes.org/linuxhq-announcement.txt) . LinuxHQ is gone, and its new (temporary) home is http://kernelnotes.org/. So KT story titles are pointing there for the time being. (and thanks go out to Dohn A. Arms and Pauli Ojanpera for pointing this out to me) -- Ed: [23 May 1999 00:00:00 -0800]

Note: Alan Cox had at least 31 posts this week, but they were from several different email addresses, which screws up my scripts. A number of other folks also routinely get devalued that way. If anyone wants to donate a script that solves this problem, please contact me (mailto:zbrown@tumblerings.org) .

Mailing List Stats For This Week

We looked at 1495 posts in 6049K.

There were 549 different contributors. 231 posted more than once. 178 posted last week too.

The top posters of the week were:

1. Attempted Scheduler Improvements

9�May�1999�-�11�May�1999 (37 posts) Archive Link: "[patch] new scheduler"

Topics: Scheduler

People: Rik van Riel,�Ingo Molnar

Rik van Riel did a lot of work on the scheduler. He posted a patch against 2.2.8-5, and said:

attached is a patch that changes the Linux scheduler to do the following things better/right:

Ingo Molnar was a little confused by the patch. It seemed to him that the priority recalculation mechanism had been removed, which had allowed interactive processes to automatically get a priority boost. There was a bit of discussion, in which the two of them had a hard time connecting; Ingo felt Rik wasn't improving the scheduler, and Rik felt Ingo wasn't understanding his improvements. Some folks posted short programs to test for limitations in schedulers, and it came out that time accounting in the kernel had some serious weaknesses. At this point, Rik said, "I guess I'll completely give up on my scheduler changes until there's some instrumentation available to measure things. Besides, there are more then enough other things that need to be done (now that the scheduling seems to be good enough in 2.2.8, with only a superfluous reschedule_idle() in schedule_tail())."

An hour later, he also added (under the Subject: WARNING: scheduler patch (http://kernelnotes.org/lnxlists/linux-kernel/lk_9905_02/msg00344.html) ):

my scheduler patch seems to contain a weird bug that makes your machine hang somewhere halfway booting, so DON'T FRIGGIN USE IT :)

I know what it is (in reschedule_idle the goodness of the idle task is near-infinite), but the 'original' scheduler of 2.2.8 performs so good that I don't really care anymore.

When people really bug me for a larger difference between nice levels or if removal of the process recalculation ritual is wanted, I'll start working on the scheduler again. In the meantime, try out 2.2.8-preX and tell Mingo how much you like it...

2. ISDN And The Kernel

10�May�1999�-�13�May�1999 (12 posts) Archive Link: "ISDN and the Latest Kernels ..."

Topics: Networking, Version Control

People: Dominik Kubla,�Bernhard Rosenkraenzer

A frustrated Brian Schau wanted to know when the latest ISDN stuff would get into the kernel. He also pointed to the ISDN Upgrade for kernel 2.2.x Mini HOWTO (http://www.brisse.dk/site/linux/isdn.htm) .

Marc Hansen had given a pointer to the ISDN4Linux ftp site (ftp://ftp.suse.com/pub/isdn4linux/) , but Dominik Kubla said;

That's not right: If you look closely, you will see that the ISDN code from the CVS archive (or the snapshots at ftp.suse.com) simply overwrites the kernel code. So you will loose all the work that has been done to get the ISDN stuff running on non-Intel platforms, especially the onboard ISDN of certain SparcStations.

I have pointed that out weeks ago on de.alt.comm.isdn4linux, which is gated to the ISDN4Linux mailing list with absolutely no reaction at all.

It seems to me that ISDN4Linux and the Kernel have drifted apart and will stay so. I am not sure what to do about this. My guess is that somebody in close contact both with the ISDN developers and Linus needs to take a week off and get the act together.

Mark Constable put out a call for folks to get ISDN working at least passably, for systems that really couldn't do without it. He said he'd gotten ISDN on his system almost fully functional, and with a little work it could be a good intermediary solution. Bernhard Rosenkraenzer (from Mandrake) replied that they had gotten ISDN working (albeit imperfectly), and gave a pointer to the source RPM directory (ftp://sunsite.uio.no/pub/linux/mariner/SRPMS) .

3. Changing Default Ramdisk Size

10�May�1999�-�12�May�1999 (7 posts) Archive Link: "RAM disk question"

Constantine Gavrilov asked if it were possible to change the default ramdisk size (with ramdisk compiled as a module), without changing the source code. He pointed out that setting the ramdisk_size boot parameter (with 'modprobe rd rd_size=8192') didn't seem to work. In the course of discussion, it came out that setting the module parameter was indeed possible, but only in kernels 2.2.7 and above. So the final solution was to upgrade the kernel.

4. Increasing Maximum Physical Memory On x86 Machines

10�May�1999�-�11�May�1999 (5 posts) Archive Link: "[RFT] [PATCH] kanoj-mm1-2.2.5 ia32 big memory patch"

Topics: Big Memory Support

People: Stephen C. Tweedie,�Kanoj Sarcar

Kanoj Sarcar posted a rough patch to increase the maximum physical memory allowed on ia32 machines up from 2Gb to 3.8Gb. He gave the URL (http://www.linux.sgi.com/intel/bigmem/) of the patch and the explanation behind it, and said he was looking for testers. Stephen C. Tweedie found a bug, and Kanoj posted a new patch. A few days later he posted another (http://reality.sgi.com/kanoj_engr/kanoj-mm1.3-2.2.9) , against 2.2.9.

5. ftime() Resolution Bug In glibc

10�May�1999�-�12�May�1999 (10 posts) Archive Link: "ftime() not giving miliseconds?"

People: Andreas Jaeger,�Pavel Machek,�Andries Brouwer

Pavel Machek noticed that ftime() failed to report milliseconds. Andries Brouwer pointed out that ftime() was obsolete, and that the observed behavior was a bug in glibc. He updated the manpage to point out the bug. Andreas Jaeger replied (only 2 days after Pavel's original post) that a fix had been found and would go into glibc 2.1.1.

6. Legacy a.out Support Fading

10�May�1999�-�13�May�1999 (18 posts) Archive Link: "2.2.8pre6, can't run ZMAGIC binaries"

Topics: Executable File Format

People: Alan Cox,�Andrea Arcangeli,�Peter Osterlund

Peter Osterlund was getting segmentation faults on the old ZMAGIC a.out binaries. It turned out the kernel did indeed break them in that release (but did not break the newer, "normal" a.out binaries). Andrea Arcangeli posted a patch to fix it. There was a bit of discussion about how to really solve the problem, but it looks like ZMAGIC binaries may be nearing the chopping block, in favor of satisfying other concerns.

An interesting tidbit: Alan Cox pointed out that the old libc4 is not Y2K safe. If you're still using an a.out system, 1999 might be a good time to switch to ELF.

7. 2.3 Development Series Begins!

12�May�1999�-�14�May�1999 (17 posts) Archive Link: "2.3.0 kernel - announce??"

People: Chris Evans

A happy Chris Evans stumbled on linux-2.3.0.tar.bz2 in the archive. In the course of discussion it came out that the only difference between it and 2.2.8 was the version number.

8. Wait-queue And Semaphore Initialization Revamp

11�May�1999�-�12�May�1999 (3 posts) Archive Link: "pre-2.3.1-1 fails compile (smbfs)"

People: Ingo Molnar,�Linus Torvalds

Pete Clements reported a compile error, and Linus Torvalds replied that a lot of the wait-queue and semaphore initializations had to be changed, and he was open to patches. Ingo Molnar obliged him, posting an untested patch. End Of Thread.

9. Bug Tracking And Revision Control For Linux

11�May�1999�-�13�May�1999 (12 posts) Archive Link: "JitterBug for 2.3"

Topics: Bug Tracking, Version Control

People: Linus Torvalds,�Larry McVoy,�Alan Cox,�Tristan,�Jakub Jelinek,�Dax Kelson

Jakub Jelinek wanted to know if JitterBug would be used, now that 2.3 was out. Linus Torvalds replied:

JitterBug turned out to be way too much pain for me, and the biggest reasons I tried (Alan and David) both started working in a way that made the original reason for us wanting to have JitterBug go away.

Something like JitterBug might eventually rear its igly head, but not in the immediate future..

Tristan Greaves was against Jitterbug, but recommended Bugzilla. Alan Cox didn't like Bugzilla because it wouldn't work without cookies or through multiple-ip load balancing proxies. But he liked the Debian bug tracker.

On a related note, Dax Kelson had been under the impression that 2.3 would be developed under the (free for noncommercial use) Bitkeeper (http://www.bitkeeper.com/) revision control system, and Linus replied:

I probably _am_ going to switch to bitkeeper, but I wanted to open 2.3.x even before Larry had given me the real demo etc.

BitKeeper doesn't imply any quality assurance either, but it _should_ make it easier to keep in sync.

Larry McVoy (the principal architect of Bitkeeper) said, "That's the plan and I think we'll get there pretty soon. I suspect we will have growing pains but BitMover is prepared to focus almost 100% of its engineers (we're up to 4) on making this stuff work for the Linux kernel team."

10. Slashdot Scoops 2.3.0

12�May�1999�-�17�May�1999 (30 posts) Archive Link: "Slashdot shitheads"

People: Linus Torvalds

As usual, there was some resentment of premature announcements on Slashdot (http://www.slashdot.org/) . Just as happened with 2.2.0, 2.3.0 was announced on slashdot as soon as it appeared. One objection that came out was that the announcement failed to warn people to avoid the 2.3.x series unless they're helping develop it, due to the inherent instability of any X.oddnum.Y kernels.

The interesting part is that for 2.2.0 there was actually some attempt at writing a press release. But since there was no way of knowing when to submit it to Linus Torvalds (or even who's version should be submitted) it was left in the dust when the release finally came.

Personally, I think it's great that major releases of the kernel have gone unannounced. What other product in the world gets away with that? Linux not only gets away with it, it puts major releases in their proper perspective: just another stage of development. Rather than bewail the situation, we should bask in it!

11. Alan Migrates -ac Patches To 2.3 For Official Inclusion

12�May�1999�-�14�May�1999 (4 posts) Archive Link: "The -ac patches and 2.3.0"

Topics: Kernel Release Announcement

People: Alan Cox,�Linus Torvalds

Alan Cox announced his intention to start feeding the various parts of his 2.2.x-ac patches to Linus Torvalds for inclusion in 2.3.x; the goal being to eventually get all those features into the development series and from there to the next stable tree.

12. Most Stable Kernel In The Stable Series

14�May�1999�-�17�May�1999 (9 posts) Archive Link: "most stable 2.2.x kernel?"

Topics: Preferred Kernel Version

People: Simon Kirby,�Rik van Riel

After upgrading from 2.0.35, Brian Feeny had crashes with 2.2.8 and 2.2.7ac4, so he wanted to know which were the kernels he should choose from. In addition, he wanted to include the >1024 file descriptors patch (hence the -ac4). Simon Kirby recommended 2.2.9 and included a patch for the file descriptors and other stuff.

Rik van Riel said 2.2.7 and 2.2.9 looked best to him, depending on the hardware.

13. Lockup When Testing Sound On 2.3.1 Fixed In 2.3.2

14�May�1999�-�15�May�1999 (2 posts) Archive Link: "2.3.1 hard lockup after sound being initalized"

Topics: Sound

People: Bob Tracy

David Morgan tested out 2.3.1 and found that he had no sound. Running 'GQmpeg' to test for sound locked the system reproducibly. Bob Tracy confirmed this, and noticed that upgrading to 2.3.2 fixed it.

14. Mailing List Delays And Header Changes

14�May�1999�-�17�May�1999 (7 posts) Archive Link: "vger weirdness"

Topics: Mailing List Administration, Microsoft, Spam

People: Matti Aarnio,�George Bonser,�Alexander Viro

George Bonser noticed that all of a sudden, linux-kernel mail had started having a X-UIDL: header, causing his system to trash it as spam (apparently a lot of spam has that header). Matti Aarnio replied, "My opinnion about considering "X-UIDL:" as a sign of spam is that the idea is misguided. All in all, an evolutionary view at the spammers can show that for every *simple* countermeasure we use against some simple signature characteristics, the spammers will adapt fairly quickly." for anti-spam documentation, he recommended RFC 2505 (ftp://ftp.funet.fi/rfc/rfc2505.txt) .

George said that aside from the current situation, he'd never gotten X-UIDL in a non-spam message. Someone pointed out that Pegasus, a common free email program for Microsoft, also used those headers.

Meanwhile, Alexander Viro noticed that vger was having major delays. Matti Aarnio said the server was overloaded once again, in addition to other problems. He added that since he'll be at Linux Expo until May 24, he hoped nothing would go seriously wrong before then.

15. Keyboard Behavior Improvements

16�May�1999 (6 posts) Archive Link: "PATCH: sticky shift keys: bug fix and more intuitive behaviour"

People: Werner Almesberger,�Andries Brouwer,�Linus Torvalds

Werner Almesberger posted a patch to add a configuration option for improving keyboard behavior. He said:

This patch adds a compile-time option CONFIG_SMART_SLOCK to improve the behaviour of "sticky" shift/ctrl/alt/etc. keys in virtual terminals. The current behaviour for the sticky keys is that they change the next key, and only that one. If CONFIG_SMART_SLOCK is enabled, they still change the next key, but they also continue changing while held down, i.e. like shift and friends do in normal (non-"sticky") operation.

Example: when pressing A, pressing (and releasing) Shift, pressing B, then holding down Shift, pressing C, pressing D, and then releasing Shift, we get:

Without sticky keys: a b C D
With sticky keys, without CONFIG_SMART_SLOCK: a B C d
With sticky keys, with CONFIG_SMART_SLOCK: a B C D

This is likely to be more intuitive than the current sticky behaviour on machines which are sometimes operated single-handedly, e.g. PDAs. I've introduced this extension at the beginning of March in the Linux-7k project and used it quite extensively on my Psion. I've tested the 2.3.2 version briefly on my PC without noticing any problems.

The patch also adds conflict resolution if a keypress doesn't yield a valid code. (The second change in do_slock.) This is a bug fix which you may want to add to 2.2 too. E.g. the keyboard currently locks up if you use the US layout, make Shift, Ctrl, and Alt "sticky", and then press each of them. Reason: there is no valid map for Shift+Ctrl+Alt, so all further keys are ignored.

Furthermore, the patch prevents sticky keys from being used to compose the boot sequence. (I've added this after noticing that I had a tendency of trying to "correct" typos in the Ctrl and Alt region by pressing Del ... ;-)

I've made this change a compile-time option because current users of sticky keys may need the traditional behaviour for some reason (e.g. special hardware). It would be good if current users of the sticky keys could comment on the change, so that it may perhaps become the standard behaviour in the future.

This extension was inspired by the way shift keys work on HP100/200LX palmtops.

Linus Torvalds was happy, but said it shouldn't even be an option. The kernel should just use the better behavior. Werner obliged with another patch.

Andries Brouwer, who wrote most of the code in keyboard.c (though there is currently no official maintainer), agreed that there shouldn't be a compile option, and also had some implementation suggestions. Werner posted a third patch, and Andries was satisfied.

16. 2.3.1 Boot Failures May Be Linked To egcs

16�May�1999�-�17�May�1999 (4 posts) Archive Link: "Problem with 2.3.1 and later."

Topics: Compiler

People: Horst von Brand

Someone couldn't boot any kernels >=2.3.1 because it wouldn't detect their hard disk. Horst von Brand had the same problem, and they discovered they both were using egcs-19990502. There was no resolution on the thread, but Horst said he'd look into it.

17. Linus Takes A Break After 2.3.3

17�May�1999 (1 post) Archive Link: "Linux-2.3.3 and a short hiatus.."

People: Linus Torvalds

Before jumping on a plane for a couple days in Finland, Linus Torvalds released 2.3.3 (though he forgot to increment the version number in the patch), which (he hoped) fixed all the waitqueue changes.

18. Alan's Approach To The Unstable Tree

17�May�1999 (1 post) Archive Link: "Linux 2.3.3ac1"

Topics: Kernel Release Announcement

People: Alan Cox

Alan Cox announced 2.3.3ac1, but said he didn't plan to do ac patches regularly for the development series. This one was just to test a few things like big files and DECnet. Under the Subject: 2.3.3ac1 - whoops (../unavailable.html) , he later said the patch was flawed, and that an ac2 would be out shortly.

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.