Kernel Traffic #102 For 12 Jan 2001

There were 464 different contributors. 207 posted more than once. 108 posted last week too.

Michael Chen noticed that comiling a Celeron as a P3 or P4 chip would cause a system hang at the early stages of boot-up. He explained, "the problem is cause by the fact that Intel Celeron doesn't have a real memory barrier,but when you choose the Pentium III option, the kernel assume the processor has a real memory barrier." He posted a patch, but Erik Mouw replied:

I think there is some confusion in the name "Celeron". AFAIK there are two kinds of Celerons: the original PII based Celeron, or the newer PIII based Celeron. My laptop has a PIII (Coppermine) based Celeron, and it boots perfectly well without your patch.

If you are using a PII based Celeron, you should compile the kernel with support for the "Pentium-Pro/Celeron/Pentium-II". You certainly should not try to run a kernel with support for P4 on a "lower" CPU, read the documentation about CONFIG_M386 in Documentation/Configure.help for more information.

There was no reply to that, but Linus Torvalds also said it was a mistake to configure the processor as a chip is was not. He said, "The whole point of being able to choose the CPU to optimize for is that we can optimize things at compile-time." Several folks pointed out that some Celeron's were based on the P3, and Erik explained at one point, "The confusion is because Intel reused the name Celeron for a completely different CPU. The original Celeron was based on a PII core, the new Celeron is based on a PIII core. Both Celerons have the same features as the CPU they are based on, but with less cache memory. Selecting PIII for the new PIII based Celeron will indeed give you slightly better performance."

Elsewhere, Kai Henningsen suggested that the kernel ought to detect misconfigured CPUs at boot time. Tim Wright replied, "if you choose the wrong processor type, you may not even be able to complain. This is a user issue. All the distributions of which I am aware boot happily on any x86 machine, because they build the kernel for the lowest common denominator. Some detect the CPU type and install an appropriate kernel subsequently. So... the only way you can get into this mess is if you build a kernel yourself and choose the wrong options. There are many ways of producing a non-bootable kernel. The expectation is that if you want to go off and build your own kernel, you need to know what you're doing :-)"

Linus suggested having a boolean "Optimize for current CPU" option during configuration. Several folks liked this idea, and Riley Williams posted a patch to do it. But Alan Cox said, also in reply to Linus, "If we do that I'd rather see a make autoconfig that does the lot from proc/pci etc 8)" . Linus replied:

Good point. No point in adding a new config option, we should just have a new configurator instead. Of course, it can't handle many of the questions, so it would still have to fall back on asking.

That _would_ be a nice addition eventually. It's a bigger project than the one I envisioned, though.

If somebody (you? hint, hint) wants to do this, I'd be very happy - I can do it myself, but because it's my birthday I'm supposed to drag myself off the computer soon and be social, or Tove will be grumpy.

And you don't want Tove grumpy.

Marcelo Tosatti replied, "Ok, I'll do it because I love Tove." Rik van Riel dove betwixt Marcelo and blackest night, saying:

Marcelo, you should buy some glasses ;)

Tove != Tux

It's ok and probably safe to love Tux, the nice cuddly penguin everybody loves.

However, loving the (6-time ??) Finnish female karate champion, who happens to be married to Linus is probably quite a bit less safe ...

There are always problems with some hardware, but my personal recommendation for a card would definitely be the Intel Ethernet Pro 100 series (82557).

Unlike the tulip cards (which are pretty good too), there aren't a million different versions of it. There's a few, but it's not a big mess. It performs well, and is stable. It's pretty well documented (apart from the magic extensions), and it's common.

That said, some people have trouble even with that card. Nobody knows why, but at least the driver is actively maintained etc, so I still am not nervous about recommending it.

I bet that others will have other recommendations, but so far I have at least personally had good luck with the eepro100.

The 3c905C is a well manufactured and very feature-rich NIC which at present appears to have fewer problem reports than eepro100, 8139 or tulip.

Available in PCI, Cardbus, Mini-PCI. A dual-interface PCI version has just been released (3c982), although we've yet to hear of anyone trying it with Linux.

3com provide full specs without any NDA restrictions, plus a GPL'ed driver.

Perhaps most significantly, the 905 has full scatter/gather support. This isn't used at present, but Alexey's zerocopy-sendfile patches do utilise it. He currently has scatter-gather support for acenic, 3c905 and sunhme. I don't know what the plans are to support other 100 mbps NICs.

The in-kernel 3c59x.c isn't the world's fastest driver. On the todo list for 2.5 is MMIO support, scatter-gather maintenance, optional use of DPD polling and implementation of the onboard multicast hash filter. And implementation of the on-board VLAN support if 2.5 becomes VLAN-capable.

3c905c is a bit expensive, though. pcnet32 cards also work very well for me, and are less expensive. The 905c could be a better card (I don't really know), but pcnet32's might be more cost-effective, depending on your needs. (I've seen pcnet32-based cards selling for $15-20, and I bought a new 10-pack (of HP NightDirector 10/100's) for about $36, including shipping, on eBay.)

In any case, tulips have been more problematic for me than 8139, pcnet32, or 3c905c (whose reliability are all comparable IME). I've never tried eepro100, though. (Also, I'm speaking in terms of my experiences across all OS's which I've used the cards under, not just under Linux, although my Linux experiences are similar to the experiences I've had overall.)

Linus Torvalds dropped the '2.4.0-test' naming system, and announced 2.4.0-prelelease, saying:

Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some last-minute stuff that needed fixing (ie the dirty page lists etc), and the best I can do is make a prerelease.

There's a 2.4.0-prerelease out there, and this is basically it. I want people to test it for a while, and I want to give other architectures the chance to catch up with some of the changes, but read my lips: no more recounts. There is no "prerelease1", to become "prerelease2" and so on.

One thing other architectures will want to catch up with is the changes to handle 2GHz+ machines, which due to overflow issues caused "loops_per_sec" to become "loops_per_jiffy". And some architectures have not had much chance to synchronize with me due to other fires to put out.

Give it your worst. After you recover from being hung-over, of course.

Adam Sampson pointed out that the drm modules had unresolved symbols, and posted some linker output. Linus posted a patch, and Adam and Frank Jacobberger reported complete success; but Keith Owens cautioned:

That will break for anybody compiling a DRM card into the kernel and compiling a second DRM card as a module. drmlib.a will get a split personality, it will be compiled twice, once for kernel and once for module, which version actually gets linked will depend on the phase of the moon. Either that or it only gets compiled for kernel, which is where we came in.

DRM maintainers: can we remove this restriction on needing multiple copies of the library? It makes no sense anyway. If you build a new library with the same function names then you cannot have two DRM cards built into the kernel, the function names will collide within vmlinux. So you have to use different function names for a new library, but then the old cards can share the old library and the new cards can share the new library, i.e. there is no need for each driver to have its own copy of the library.

I strongly recommend that you remove the restriction on having multiple copies of the library. Then Adam J. Richter's patch does the job nicely, making drmlib.a a helper module.

We plan to remove the need to have multiple copies of drmlib.a and make the kernel Makefile fully compatible with the 2.4 make system -- but we haven't finished this work yet. With this new work, however, the end-user will still load a single module (e.g., tdfx.o), just like now. (Loading a single kernel module is a significant win when dealing with end users: there is no possibility of version skew or of having two modules that were compiled with different options.)

Linus -- Please use your patch or Keith Owens' patch as a bandaid to solve this problem until we can do it the right way. Whatever patch you select, please do *NOT* make drmlib into a separate helper module -- this will only lead to user confusion (especially since we'll move back to a single-module solution soon). From the user's standpoint, I'm not concerned that you can't mix modules with in-kernel versions, since most users don't do that [and we could fix the configuration file to prevent this -- that's another way to bandage this problem that I'll send you a patch for tomorrow]. I am very concerned that users will see us move from 1 DRM module to 2 and then back to 1 -- that would be very confusing for them.

Alan Cox gave his assessment of this, saying, "So with 3 video cards I have 3 wasted chunks of ram just because of a tiny tiny possibility that someone would manage to build two copies of the library with matching ksyms. That doesnt strike me as a good tade off." There was no more discussion in that subthread.

Keith Owens announced the latest version of modutils, at ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/modutils/v2.3. He added, "Assuming no problems are found in modutils and assuming that kernel 2.4.0-prerelease is followed by the official 2.4 kernel then this version of modutils will be repackaged as modutils 2.4.0." Matthias Andree pointed out that depmod gave a warning when invoked with the --version option. He figured nothing but the version information should really be output, and asked about it. Keith replied, "Historical accident. I want to clean that up but it breaks existing behaviour; somewhere, somebody is bound to rely on depmod -V updating modules.dep at the same time. modutils 2.5 will clean up a lot of backwards compatibility crud, including this one. But you will not see modutils 2.5 until Linus rolls kernel 2.5 and we start the next development cycle." This made sense to Matthias, though he suggested documenting the current behavior in the --help output and the man page. Keith felt it wasn't worth the trouble, since the whole thing would change once the kernel hit 2.5; Matthias urged, "I was just thinking to write -V "output version in addition to normal operation" in --help, nothing bigger than like 5 minutes." But there was no reply.

Ari Pollak reported, "This has not been fixed for at least a year that i can remember - in Documentation/devices.txt, it says /dev/js* should be char-major-15*, but in Documentation/joystick.txt it says it should be char-major-13. I'm assuming joystick.txt is the correct one, and devices.txt should be updated to reflect this.. before 2.4.0 would be nice." Robert Read replied, "devices.txt does need some updating. It still lists char-major-13 as the PC Speaker, but 13 appears to be the major for new input driver, and the joystick driver is now a minor off the that. Are there now two Joystick drivers, or can char-major-15 be obsoleted/deleted?" H. Peter Anvin said, "I think there are two; at least, the number will remain reserved for a long time," and gave a link to the current devices.txt. Robert and others posted patches, and the thread ended.

Elsewhere, under the Subject: [PATCH] devices.txt bugs, Geert Uytterhoeven posted a patch against devices.txt, and explained:

This patch fixes two things:

Correct the minor numbers for the frame buffer devices. We have room for 32 frame buffers since about one year, with more room for future expansion to 256. (promised to go in by HPA on Fri, 24 Mar 2000 01:47:05 -0800).
Fix a typo in the minors for the A2232 serial card

The user-mode port of 2.4.0-prerelease is available.

hostfs is more improved. Writing files really works now. Executing binaries also works. There is still some memory corruption, though.

I fixed the swapoff crash.

The input to consoles and serial lines is now much more general. You can attach them to ptys, ttys, and ports now, with a few more interfaces to come.

The project's home page is http://user-mode-linux.sourceforge.net

The project's download page is http://sourceforge.net/project/filelist.php?group_id=429

See his later announcement at Issue #102, Section #16 (4 Jan 2001: user-mode Port Of 2.4.0)

Vedran Rodic reported filesystem corruption with 2.4.0-prerelease. He put the complete kernel log of the session up on the web, and reported that he hadn't seen any new errors since that first report. Daniel Phillips asked if it was possible at all to reproduce the problem, and Vedran replied, "I can't reproduce this problem easily. You see at the log files that it happened after some hours of uptime." End of thread.

2.4.0prerelease-ac4

Fix CMOS locking for 2.4.x (Paul Gortmaker)
DecNET updates (Steve Whitehouse)
Devices.txt typo fix (Roberto Nibali)
Fix 15-23bit direct colour in logos (Geert Uytterhoeven)
Correct framebuffer device.txt (Geert Uytterhoeven)
Small mkiss fixes (Hans Grobler)
FAT cache locking for SMP ('manmower')
Fix write off end of disk bug (Jari Ruusu)
Further iee1394 build fixes (Andreas Bombe)
Better atm linking fix (Jan Rekorajski)
Skip older dm9100's from tulip driver (me)

2.4.0prerelease-ac5

Resync with Linus prepatch in testing
Fix loops per jiffy oddments (Geert Uytterhoeven)
Fixed lost video patch in -ac (Geert Uytterhoeven)
One liner microcode driver fix (Tigran Aivazian)
Fix page allocator recursion (Rik van Riel)
Fix ACPI ksyms problems (Keith Owens)
Correctly resync ide-cd fixes (Byron Stanoszek)
Tidy up LAPB code (Hans Grobler)
Tidy up X.25 code (Hans Grobler)
General warning/minor bug fixes (Arjan van de Ven)
Fix i2o block driver race (Arjan van de Ven)
Acorn makefile/driver fixes (Russell King)
Make cyberfb use pci_get_drvdata (Russell King)
Kill redundant ARM timer irq code (Russell King)
Remove some ARM hacks from fbmem.c (Russell King)
Fix config bugs with fusion, indenting (Andrzej M. Krzysztofowicz)
Handle bootmem order changes in arm (Russell King)
SA1100 update (Russell King)
Remove extra codec reset from i810 audio | should fix failed VRA on some boards (Anwar Payyoorayil)
Handle ALI AGP flushes (??)
Merge some of the PPC changes (Cort Dougan)

2.4.0prerelease-ac6

Macintosh IDE updates (Geert Uytterhoeven)
Update 68k ksyms (Geert Uytterhoeven)
Fix m68k keyboard ioctls (Geert Uytterhoeven)
Fix fbdev config.in allow PM2 modular (Geert Uytterhoeven)
Update m68k ethernet drivers (Geert Uytterhoeven)
2.4 Y2K fixes for Amiga clock (Geert Uytterhoeven)
Fix sun/mac scsi drivers (Geert Uytterhoeven)
Fix fb init order (Geert Uytterhoeven)
Fix m68k miscellaneous stuff (Geert Uytterhoeven)
Update m68k lance driver (Geert Uytterhoeven)
Fix m68k asm constraints (Geert Uytterhoeven)
Fix m68k config (Geert Uytterhoeven)
Amiga serial update/serial console support (Geert Uytterhoeven)
Update m68k to use loops_per_jiffy (Geert Uytterhoeven)
Add support functions needed by gcc (Geert Uytterhoeven)
Fix amiga resource management (Geert Uytterhoeven)
Cleanup econet (Hans Grobler)
Further amateur radio cleanups (Hans Grobler)
Fix irda/SMP deadlocks (Marc Zyngier)
Further YAM fixes (Hans Grobler)
Fix rio500 locking bug (Greg Kroah-Hartmann)
Fix raid buffer leak (Neil Brown)
Additional knfsd locking (Neil Brown)
Fix isdn net leak on error (Arnaldo Carvalho de Melo)
Fix proc_get_inode export (for comx) (Hans Grobler)
Fix locking error on get_swap_page (Marcelo Tosatti)
Fix further warnings, and other stuff new gcc shows up (Arjan van de Ven)
Add isapnp module device tables to drivers [Added to ns558, serial, ide-pnp, cadet, 3c509,3c515, aironet4500,ne,sb1000, aha1542, NCR5380, ad1816, awe_wave, sb, ixj] (Bill Nottingham)
Resync with Linus prepatch

This thread started innocently enough, but Rik van Riel and Andrea Arcangeli just don't get along. Maybe it's because they're working on two competing versions of the Virtual Memory subsystem, maybe it goes back further. In this particular incarnation, Rik posted a variant of a performance patch originally written by Andrea; he added, "I know this probably isn't of any help under very low and very high loads, but it should provide a nice improvement under medium loads..." Andrea corrected him, saying, "It should provide an improvement under high VFS load (lots of files lookedup and not kept referenced all the time)." But Rik disagreed, saying, "Not really. Under very high VFS loads we'd just scan through the list twice and free the entries anyway." Andrea then threw the first stone, with, "You're obviously wrong." He went on to give a technical explanation of his point, and they quipped back and forth for a couple posts, at which point Andrea said, "Your arguments are senseless." Rik finally took the bait, with, "I could say the same of yours if I let myself sink to that level ;) </obflamebait>" . He gave his own technical explanation, at which point Andrea accused him of going off-topic. Rik said he'd just been arguing against Andrea's point; and added, "Unfortunately you seem to ignore my arguments, so lets close this thread." Andrea replied, "I've not ignored them, as said they were either obviously wrong of offtopic." To which Rik quipped, "Without giving any arguments ;)"

At around this point, Alan Cox stepped in and pulled them to opposite corners, saying, "Would the two of you ajourn this debate to alt.flame" .

Ludovic Fernandez posted a patch against 2.4.0-prerelease, to make the kernel preemptive. Rik van Riel replied, "I think this would be a nice thing to start testing once 2.5 is forked off." There was some technical discussion of the patch, and at one point elsewhere, Nigel Gamble said:

I didn't realise you were still working on this. Did you know that I am also? Our most recent version is at:

ftp://ftp.mvista.com/pub/Area51/preemptible_kernel/

although I have yet to put up a 2.4.0-prerelease patch (coming soon). We should probably pool our efforts on this for 2.5.

Ludovic explained, "I was on vacation and had a little time to kill... Going through your README, you seem much more advanced than this simple patch." He agreed that pooling their efforts sounded like the way to go. He suggested they research some possible benchmarks, and added that maybe the discussion had started to go off-topic for linux-kernel. But Daniel Phillips interceded:

No! Not off topic. And I hope you don't throw away that simple patch, it will always be useful for doing reality checks on the performance of the fancy system, and who knows, maybe it's useful in its own right.

The current fashion is to use dbench:

ftp://samba.org/pub/tridge/dbench

I think this is good for your patch because it's inherently parallel. Interesting numbers of tasks are, e.g., 1, 2, 10, 50. Of course dbench is not the last word in benchmarks but it's been pretty useful so far. You probably want something entirely cpu-bound too. How about dbench with ramfs?

In a move unanimously hailed by the trade press and industry analysts as being a sure sign of incipient braindamage, Linus Torvalds (also known as the "father of Linux" or, more commonly, as "mush-for-brains") decided that enough is enough, and that things don't get better from having the same people test it over and over again. In short, 2.4.0 is out there.

Anxiously awaited for the last too many months, 2.4.0 brings to the table many improvements, none of which come to mind to the exhausted release manager right now. "It's better", was the only printable quote. Pressed for details, Linus bared his teeth and hissed at reporters, most of which suddenly remembered that they'd rather cover "Home and Gardening" than the IT industry anyway.

Anyway, have fun. And don't bother reporting any bugs for the next few days. I won't care anyway.

In v2.4/test-kernels:

patch-2.4.0-prerelease.gz - patch from test12 to the prerelease

prerelease-to-final.gz - patch from prerelease to final.

And it will apparently take some time for the ftp servers to sync up: when I moved the test-kernels away from the main v2.4 directory I didn't think of the fact that the mirror scripts will spend quite a bit of time just synchronizing everything (the fact that _I_ did it with a simple "mv" on the master copies doesn't mean that the mirror services will be able to do it ;)

Right now the sync from the master copy has gotten to the patches in the test directory, which means that it shouldn't take more than maybe 15 minutes until everything has been synched - but I suspect that if people pound on ftp.kernel.org it will only slow stuff down further, so try to see if you can find other mirrors that got in early and don't synchronize the test-kernels...

One thing that must be on everyone's mind is the famous 'brown-paper-bag' bug that hit 2.2.0, as covered in Issue #3, Section #14 (26 Jan 1999: 2.2.0 Exploit To Crash The System) . Will a similar exploit be found for 2.4.0?

2.4.0-ac1

Resync with Linus
Fix serial compile bug (Bill Notthingham)
Clean up lapbether (Hans Grobler)
Fix endian handling in ne.c (Geert Uytterhoeven)
Fix root umount handling (Chris Mason & Al Viro)
Bring wan drivers up to scratch for 2.4 (Krzysztof Halasa)
SD module locking fix (Oliver Neukum)
Merge S/390 32/64bit ports | some rough edges to tidy up yet - guys can | you change the DMA ifdefs to match 2.2 style.. (IBM)

Miles Lane had some problems compiling, and Keith Owens posted a Makefile fix, adding that the change might prevent ACPI from working with module symbol versions; so Miles would not be able to select module symbol versions. Bill Wendling proposed another solution as well, which worked fine for Miles. Bill replied, "Great! I just wish I knew where this line was being generated so that I could send a patch in :)."

Alan announced -ac2 in Issue #102, Section #20 (5 Jan 2001: Alan Still Maintaining 2.2) .

2.4.0-ac3

Add support for the newer 3c905 cards (Andrew Morton)
Drop unused field from scc.h (Hans Grobler)
Remove dead sysctl stuff from econet (Hans Grobler)
Fix documentation indexes (Paul Gortmaker)
Fix post free reference of an skb in lance (Paul Gortmaker)
Tidy appletalk code (Hans Grobler)
Fix bootup vesafb hang (David Wragg)
TCP 'reset_xmit_timer' fix (Dave Miller)
Tidy up cursor positioning on menuconfig (Kirk Reiser)
Add missing wait.h includes to some asm/semaphore (Hans Grobler)
AF_UNIX socket cleanup (Hans Grobler)
Update sd locking fixes (Oliver Neukum)
Add module locking to audio coprocessor calls (Chris Rankin)
Minor further X.25 tidy (Hans Grobler)
Fix scsi ioctl/scan crash on out of memory (Douglas Gilbert)
Soundscape patches (Chris Rankin)
M68K fixes for mem stats and stram (Geert Uytterhoeven)
Set MSG_TRUNC correctly on atm sockets (Matti Aarnio)
Add infrastructure for parport autoloading (Adam J Richter)
Make lp driver use capable not old suser() (Tim Waugh)
Fix thread/unload race on i2o block (me)
Fix drivers that use asm/delay not linux/delay (Geert Uytterhoeven)
Further warning fixes (Rich Baum)
Netfilter config/Makefile fixes (Dave Miller)
Merge updated cs4281 driver and tidy it | some cleanups by me, possibly broken it ;) (Tom Woller)
Fix bagetlance reference of freed buffer (Arnaldo Carvalho de Melo)
ISDN small fixes (Andrea Baldoni, Daniel Stodden)
ESS Maestro 3 driver (Zach Brown)

Some folks pointed out that Alan had forgotten to update the Makefile's EXTRAVERSION version number from ac2 to ac3.

Even mighty ftp.kernel.org has fallen under the /. effect after they ran the annoucenement:

http://slashdot.org/article.pl?sid=01/01/05/0049246&mode=thread

You're probably not going to have much luck getting any source off any servers tonight. Might I suggest you pop over to Slashdot and give the clueless some clues on getting their new kernels working? They need help.

Scott Laird replied, "my mirror (ftp-mirror.internap.com, or ftp15.us.kernel.org) is only seeing 1-2 Mbps worth of traffic, out of 10 Mbps available to it. I suspect that a lot of mirrors are similar." After awhile, Michael added:

I gather from the combination of what I read on Slashdot and what folks replied here that the mirrors are actually lightly loaded, but Slashdot readers don't know about them because they couldn't read the home page at http://www.kernel.org that directed them to the mirror list.

So I posted the algorithm for calculating the URL to your nearest mirror on Slashdot. Maybe that'll help some

A 2.4.0.1 should be on ftp://ftp.kernel.org/pub/linux/kernel/crypto/v2.4/. But it has been heavily re-worked. I haven't got my hands on that one and will keep quiet as to what extend that patch is produiction-ready, but I remember that the loop driver in 2.4.0 still can stall your box. Since the kerneli crypto relies on loop, this would count in favor of "don't do that yet".

BTW: You might want to join linux-crypto@nl.linux.org (majordomo) if you are interested in kerneli.

Jon was very excited to learn about the mailing list, and joined it on the spot.

The user-mode port of 2.4.0 is available.

It was updated to 2.4.0 and that's it.

The project's home page is http://user-mode-linux.sourceforge.net

The project's download page is http://sourceforge.net/project/filelist.php?group_id=429

Keith Owens announced, "http://oss.sgi.com/projects/kdb/download/ix86/ contains patches for kdb v1.7 against kernel 2.4.0. No significant changes since 2.4.0-test13 and 2.4.0-prerelease. Just fitting the patch to the new kernel."

Of course 2.4.0 runs on m68k as well :-)

Sorry, no real changes since last release, but I wanted to get something out of the door as soon as possible. Today is my last holiday, so my Linux development efforts will be much smaller next week. Someone to take over again?

The patch is quite short. Looks like the stressy period just before a new major release is good for our patch acceptance rate. It's like a duel: who can handle the most stress, and who gives up... Linus might have lost this time :-)

If you can live without `exotic' architectures (Atari, Mac, Sun3, ... :-), the patch is... tiny.

Good luck! Enjoy!

http://home.tvd.be/cr26864/Download/linux-m68k-2.4.0.diff.bz2

Samuli Kaski reported that LVM wouldn't compile with the CONFIG_LVM_PROC_FS config option, and Alan Cox replied, "Fixed in -ac for ages. Linus didnt think it important enough for 2.4.0 - which compared to 'it crashes when I..' is reasonable enough I think." End Of Thread.

2.4.0-ac2

Clean up strip driver (Hans Grobler)
Fix fore atm makefile (Jan Rekorajski)
Fix m68k lance mismerge (Geert Uytterhoeven)
Fix tty documentation typos (Hans Grobler)
Fix ohci1394 build (Arjan van de Ven)
Remove dead lapbether inits (Hans Grobler)
Workaround the acpi recursive variable name Makefile problem (Bill Wendling)
Further minor S/390 merge (Ulrich Weigand)
Fix DRM build problem on ATI Rage 120/no AGP (Gareth Hughes)
Fix mac address setting in 8139too (Ben Greear)
AGP oops fix/ALi cleanup (Bill Crawford)
Further DECnet cleanups (Hans Grobler)
S/390 last fixes (Ulrich Weigand)
Fix missing arlan symbol (Hans Grobler)
Do basic IPX/SPX cleanups (Hans Grobler)

Octave Klaba asked if Alan intended to release new 2.2 kernels, or if he planned on working only on 2.4 from then on. Alan replied, "2.2.19 is still cooking nicely. Im aiming for a month or two."

Josh Fryman asked if Linux had been successfully ported to the Intel IXP1200 programmable network processor. He'd heard rumors that it had, but had been unable to dig up anything definite. Russell King replied, "Yes there is. Look at: http://www.netwinder.org/~urnaik/ixp1200_howto.html for more information on getting Linux running." End Of Thread (tm).

Matthew Schumacher reported that the 2.4.0 kernel wouldn't compile when CONFIG_IP_NF_FTP was selected during the configuration phase. David S. Miller pointed out that CONNTRACK and full NAT both had to be enabled as well. He asked Rusty Russell, "Rusty, why doesn't the Config stuff just enforece this if it is necessary when enabling FTP support etc.?" Rusty replied, "Deja Vu: we've been through this before. But someone else fuck^H^H^H^Hfixed the makefiles recently." He posted a fix, which seemed fine to David, and the thread ended.

I've put up a patch against linux-2.4.0 for uClinux 2.4. The supported platforms are listed below, in the announcement which was sent to the uClinux-dev list.

We would like to merge into the mainline Linux tree in 2.5, so we've taken an approach which touches as little as possible of the generic kernel :-)

This relase includes support for Motorola ColdFire MCF5307 and MC68328. The MCF5307 support targets Lineo NetTEL and the 68328 support targets XCoPilot.

Status:

MCF5307 support is the most complete. It includes networking and drivers for the NetTEL. There are a few memory leaks and there is a bug in wait4().

MC68328 support has been carried forward from test11, and still has a little breakage (the interrupt vector table stuff got broken along the way). We'll fix that in the next couple of days.

Use gcc-2.95.2 configured --target=m68k-elf to build these targets.

Many thanks to David McCullough he did the heavy lifing moving this to release from my early work on test5, Michael Leslie who did the merge from Randy Buchanan's 68328 work. And of course Linus and the entire community that produced the Linux 2.4 release.

Joe Pranevich said, "This document has already been picked up by some Linux news sites, but it really belongs here. This is my list of new features since Linux 2.2, gathered by reading this list, playing with patches, and getting input from people. Parts of it are non-technical, but there is some good info here. I hope that someone out there finds this list useful." He included his list, which you can find on Linux Today. Jean-Christian de Rivaz had a question about the "Networking And Protocols" section, in which Joe had said, "It should also be mentioned at this point that Linux is still the only operating system completely compatible with the letter of the IPv4 specification." Jean-Christian replied, "I am very interesting about the proof of this. I work on a project witch need to be certified. Any informations about the compliance of Linux to some specification is very welcome." Andi Kleen replied:

It's very dubious at least. AFAIK no RFC1122/RFC1812 evulation has been done recently (since 2.0 or so). Also part of these RFCs have been superseeded by later RFCs that have not reached Internet standard status yet, so it would not be very useful anyways (today's internet looks very different from 1989's when 1122 was written)

The mechanism the comment refers to (asynchronous error notification for UDP, which is not in traditional BSD) is not used by 99.9% of all apps BTW ;)

Jim Olsen had been a victim of the do_try_to_free_pages problem reported in the recent past. He had some idea from following linux-kernel that the problem had been fixed or at least modified, and asked, "exactly which kernel should I use in order to rid my server of this VM issue? I'm uncomfortable (and always have been) with running pre* kernels on production machines, so i'd like to stick with 2.2.18, but I would like to know if it truly does fix the problem(s) with the VM. If I need to, though, I will (hesitantly) put a 2.2.19pre* kernel on the box." Alan Cox, Rik van Riel, and Ville Herva pointed out that 2.2.19pre2 had the actual fix. As Ville put it, "It's fixed 2.2.19pre2 (which includes the Andrea Arcangeli's vm-global-7 patch that (among other things) fixes this.) You can also apply the vm-global-patch to 2.2.18 if you like."


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	23 Dec 2000 - 1 Jan 2001	(22 posts)	CPU Configuration And Autoconfiguration
2.	28 Dec 2000 - 4 Jan 2001	(62 posts)	Tove
3.	28 Dec 2000 - 1 Jan 2001	(13 posts)	Network Card Recommendations
4.	31 Dec 2000 - 4 Jan 2001	(24 posts)	2.4.0-prerelease: Approaching 2.4.0
5.	31 Dec 2000 - 3 Jan 2001	(6 posts)	The Future Of modutils
6.	1 Jan 2001 - 2 Jan 2001	(10 posts)	devices.txt Cleanup
7.	1 Jan 2001	(1 post)	user-mode Port Of 2.4.0-prerelease
8.	2 Jan 2001	(5 posts)	Possible Filesystem Corruption In 2.4.0-prerelease
9.	2 Jan 2001 - 4 Jan 2001	(3 posts)	ac Patches Against 2.4.0-prerelease
10.	3 Jan 2001 - 5 Jan 2001	(17 posts)	Rik And Andrea: As The Saga Turns
11.	3 Jan 2001 - 4 Jan 2001	(25 posts)	Preemption Patch For 2.4.0-prerelease
12.	4 Jan 2001 - 6 Jan 2001	(15 posts)	2.4.0 Is Released
13.	4 Jan 2001 - 6 Jan 2001	(9 posts)	ac Patches Against 2.4.0
14.	4 Jan 2001	(3 posts)	Problems Trying To Download 2.4.0
15.	4 Jan 2001 - 6 Jan 2001	(3 posts)	Crypto In 2.4
16.	4 Jan 2001	(1 post)	user-mode Port Of 2.4.0
17.	4 Jan 2001	(1 post)	Kernel Debugger For 2.4.0
18.	5 Jan 2001	(1 post)	Linux/m68k 2.4.0
19.	5 Jan 2001	(2 posts)	Minor LVM Problems In 2.4.0
20.	5 Jan 2001 - 6 Jan 2001	(8 posts)	Alan Still Maintaining 2.2
21.	5 Jan 2001	(2 posts)	Linux On The Intel IXP1200
22.	5 Jan 2001 - 6 Jan 2001	(5 posts)	Configuration Cleanup In 2.4.0
23.	5 Jan 2001 - 6 Jan 2001	(2 posts)	uClinux 2.4.0.0pre0 Released
24.	6 Jan 2001	(3 posts)	"Wonderful World of Linux 2.4"
25.	7 Jan 2001	(7 posts)	"VM: do_try_to_free_pages" Lockups: The Saga Ends Peacefully

Kernel Traffic #102 For 12 Jan 2001

By Zack Brown