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.

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, 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.)

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.

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.

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

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

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.

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...

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)

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)

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.

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.

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

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

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)

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.

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 ;)