Kernel Traffic #253 by Zack Brown
[email protected] Sun, 07 Mar 2004 22:33:35 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #253 For 7 Mar
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 16 Jan - 4 Feb (30 Linux 2.4.25-pre6 Released
posts)
2. 26 Jan - 6 Feb (50 udev 015 Released
posts)
3. 27 Jan - 4 Feb (36 Linux 2.6.2-rc2-mm1
posts)
4. 29 Jan - 4 Feb (46 Software Suspend 2.0 Released
posts)
5. 30 Jan - 6 Feb (26 Linux 2.6.2-rc2-mm2 Released
posts)
6. 31 Jan - 5 Feb (19 CPU Hotplugging Code Update
posts)
7. 31 Jan - 6 Feb (13 Working Around Buggy BIOSes That Incorrectly
posts) Report CPU Speeds
8. 1 Feb - 4 Feb (26 Uptime Rollover; Status Of 2.0
posts)
9. 2 Feb - 4 Feb (19 Linux 2.6.2-rc4-mm1 Released; Status Of
posts) Possible ReiserFS Upgrade To Version 4
10. 3 Feb - 6 Feb (14 Linux 2.6.2 "Feisty Dunnary" Released
posts)
11. 3 Feb - 5 Feb (14 Providing Open Firmware Paths In SysFS
posts)
12. 4 Feb - 6 Feb (2 Some Kernel Release History
posts)
13. 4 Feb - 5 Feb (2 forcedeth Network Driver Version 0.23 Submitted
posts)
14. 4 Feb (1 uClinux Update
post)
15. 5 Feb - 7 Feb (44 Linux 2.6.2-mm1 "Geriatric Wombat" Released
posts)
16. 5 Feb - 6 Feb (1 Linux 2.4.25-rc1 Released
post)
17. 5 Feb - 6 Feb (5 FUSE (Filesystem In User Space) Update
posts)
18. 5 Feb (2 Status Of INI9100U Driver In 2.6.2
posts)
19. 5 Feb (3 New rcu_barrier() Interface Possibly Useful For
posts) ReiserFS
20. 5 Feb - 6 Feb (7 HFS+ Driver Update For 2.6.1; 2.6 Inclusion
posts) Policies
21. 6 Feb (1 Linux Test Project Release For February
post)
22. 6 Feb - 9 Feb (21 Linux 2.6.3-rc1; Status Of SysFS Support
posts)
23. 8 Feb (1 Linux 2.0.40 "Moss-Covered Tortoise" Released
post)
Mailing List Stats For This Week
We looked at 2034 posts in 9669K.
There were 568 different contributors. 292 posted more than once. 141 posted
last week too.
The top posters of the week were:
* 76 posts in 288K by Greg KH
* 66 posts in 318K by Andrew Morton
* 50 posts in 179K by Kronos
* 33 posts in 244K by "Prakash K. Cheemplavam"
* 31 posts in 115K by Adrian Bunk
* Full Stats
1. Linux 2.4.25-pre6 Released
16 Jan - 4 Feb (30 posts) Archive Link: "Linux 2.4.25-pre6"
People: Marcelo Tosatti, Jean Tourrilhes, Adrian Bunk
Marcelo Tosatti announced 2.4.25-pre6, saying:
This release came out so quickly because -pre5 contains a deadly mistake in
one of the fs patches.
It contains SPARC/x86-64 updates, networking and crypto updates, amongst
others.
Adrian Bunk reported a linker error when trying to compile Jean Tourrilhes' VIA
IrDA driver as a module under this kernel. He posted a patch to fix the
problem, and Jean replied, "Thanks you Adrian. Yes, I must confess that I never
test non-modular build (because it doesn't work). Marcelo, would you mind
including Adrian's patch in your next kernel" [...] "I tested his patch
successfully with modular and static compile." Adrian asked why the linking
problem had occurred in the first place; and whether it might be better to
disallow static builds of that driver altogether. Jean replied:
I never looked in details at those issues. Some people claim it works, but
personally I always had touble with driver init (double initialisation). I
don't want to disable it if some embedded people depend on it (stable
kernel => stable feature list).
My "solution" was to totally rework the driver init (and stack init) in
2.5.X and put ample warning on my web page "use static at your own risk".
2. udev 015 Released
26 Jan - 6 Feb (50 posts) Archive Link: "[ANNOUNCE] udev 015 release"
Topics: Disks: SCSI, FS: devfs, FS: sysfs, Hot-Plugging, Microsoft, USB,
Version Control
People: Greg KH, Martin Schlemmer, Chris Friesen
Greg KH announced udev 015, saying:
It can be found at: kernel.org/pub/linux/utils/kernel/hotplug/
udev-015.tar.gz
rpms built against Red Hat FC1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.i386.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.i386.rpm)
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.src.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.src.rpm)
udev allows users to have a dynamic /dev and provides the ability to have
persistent device names. It uses sysfs and /sbin/hotplug and runs entirely
in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run.
Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ (http://www.kernel.org/
pub/linux/utils/kernel/hotplug/udev-FAQ)
For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs)
Major changes from the 014 version:
+ we finally look up the chain of sysfs device entries trying to match
all devices in the chain for each rule.
What this means to users: Consider the following sysfs device:
$ tree /sys/class/input/mouse1/
/sys/class/input/mouse1/
|-- dev
|-- device -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
`-- driver -> ../../../bus/usb/drivers/hid
Now this is a USB trackball. udev will follow that "device" symlink and get
to the following directory:
$ tree /sys/devices/pci0000:00/0000 :00:1d.0/usb2/2-1/2-1:1.0
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
|-- bAlternateSetting
|-- bInterfaceClass
|-- bInterfaceNumber
|-- bInterfaceProtocol
|-- bInterfaceSubClass
|-- bNumEndpoints
|-- detach_state
|-- iInterface
`-- power
`-- state
This is the directory of the USB interface that is bound to a mouse driver.
But in itself, that directory is pretty boring, no vendor id, no product
id, no manufacturer string... What a user really wants is the directory
above this:
$ tree /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1
|-- 2-1:1.0
| |-- bAlternateSetting
| ...
|-- bConfigurationValue
|-- bDeviceClass
|-- bDeviceProtocol
|-- bDeviceSubClass
|-- bMaxPower
|-- bNumConfigurations
|-- bNumInterfaces
|-- bcdDevice
|-- bmAttributes
|-- detach_state
|-- idProduct
|-- idVendor
|-- manufacturer
|-- power
| `-- state
|-- product
`-- speed
Now this directory contains good stuff:
$ cat /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/product
Microsoft Trackball Optical?
So, in short, you can now write a udev rule for this device as:
SYSFS_product="Microsoft Trackball*", NAME="my_trackball", SYMLINK="input/
mouse1"
and it will actually work :)
This is really helpful for all USB devices, and SCSI devices on USB or
Firewire buses. If anyone has any questions about this, please let me know,
or bring it up on the linux-hotplug-devel mailing list.
Another big thing in this release is 'udevinfo'. It's a way to get all
information out of the udev database about what devices are present, what
they are called, and other good stuff. It also will walk the sysfs chain of
any device and print out all information on the device which helps out a
lot in creating rules for udev.
Thanks to Kay Sievers who wrote udevinfo. Great job.
Also in this release is the start of a udev daemon. It's really in 3
pieces:
+ udevsend - sends the hotplug message to the udev daemon
+ udevd - the udev daemon, gets the hotplug messages, sorts them in
proper order, and passes them off to the udev program to act apon them.
+ udev - still the same.
This lets us keep udevsend and udevd small, and hopefully bug free. These
programs still need a lot of work and polish before we feel they are stable
enough to use for everyone (they are not built right now in the .rpm). Help
is appreciated here.
Thanks a lot to Kay Sievers and Xiaofeng Ling for the work on udevsend and
udevd. Again, I really appreciate it.
Thanks also to everyone who has send me patches for this release, a full
list of everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
Chris Friesen asked about the rationale of splitting the udev daemon up into
the three pieces udevsend, udevd, and udev. Greg replied, "It should be faster
this way. We can send off udev to run for different devices at the same time
(blocking for any pending device changes for any currently running udev
instances.)"
Elsewhere, Greg added that the code was under "major flux" at the moment, and
that bugs and other breakage should be expected for a time.
Elsewhere, Martin Schlemmer posted a patch to allow run-time toggling of
debugging code, since the current udev tree was very "noisy", and Martin wanted
to have a way of turning on and off the debugging output without having to
recompile. He posted a fix to his own patch, and Greg replied:
I'm going to hold off on this patch for now for a number of reasons:
+ doesn't apply anymore
+ is buggy as your follow on message stated
+ I don't think it's really needed.
Martin said he'd try again with udev 016, and see if he couldn't answer some of
Greg's objections.
3. Linux 2.6.2-rc2-mm1
27 Jan - 4 Feb (36 posts) Archive Link: "2.6.2-rc2-mm1"
Topics: FS: ReiserFS, Framebuffer, Networking, Power Management: ACPI, Sound:
ALSA
People: Andrew Morton, Christoph Hellwig, Antony Suter, Mike Fedyk, Randy
Dunlap, David S. Miller, Nikita Danilov, Jeff Garzik
Andrew Morton announced 2.6.2-rc2-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc2/
2.6.2-rc2-mm1/
+ From now on, -mm kernels will contain the latest contents of:
Linus's tree: linus.patch
The ACPI tree: acpi.patch
Vojtech's tree: input.patch
Jeff's tree: netdev.patch
The ALSA tree: alsa.patch
If anyone has any more external trees which need similar treatment,
please let me know.
+ Various fixes. Nothing stands out.
Christoph Hellwig asked, regarding Jeff Garzik's netdev patches, "Any plan when
we'll get the damn netdev lifetime rule fixes merged? They're real life
problems and have been around for a long time.." David S. Miller asked
Christoph to be mroe specific, bu there was no discussion following.
Several folks suggested also including the fbdev updates, and Nikita Danilov
also suggested accepting some ReiserFS 4 (http://www.namesys.com/snapshots/
LATEST/all.diff.gz) updates into Andrew's tree. Stian Jordet also suggested
some ISDN updates (ftp://ftp.isdn4linux.de/pub/isdn4linux/kernel/v2.6) . Antony
Suter also suggested including "The WLI patchset. It has a small number of good
improvements for NUMA machines and notebooks. A couple of the patches have
already made it into the kernel." But Mike Fedyk felt, "Isn't that a bit much?
The wli tree makes changes across the entire tree, so it isn't very localized
to any specific subsystem. Though specific cleanups would be good to merge into
-mm from -wli..."
Elsewhere, Randy Dunlap asked Andrew, "About kernel-janitors patches: Do you
want to continue reviewing/merging the KJ patches one by one or just grab the
complete patchset?" Andrew replied, "Please just send them to me in the usual
manner when you think they're ready. The reject rate has been fairly high, so
we need to go through them carefully."
4. Software Suspend 2.0 Released
29 Jan - 4 Feb (46 posts) Archive Link: "Software Suspend 2.0"
Topics: Big Memory Support, FS: NFS, SMP, Software Suspend, USB
People: Nigel Cunningham, Sebastian Kugler, Pavel Machek, Marc Lehmann
Nigel Cunningham said:
Software Suspend 2.0 for Linux 2.4 and 2.6 kernels is now available from
http://swsusp.sf.net. The 2.0 release is a major advance over previous
versions and includes the following features:
+ Support for HighMem (Up to 4G), SMP (SMP is currently only supported
under 2.4; 2.6 support should not be far away.) and preemptive kernels.
+ Support for any number of swap partitions and/or files.
+ Full asynchronous I/O and readahead for synchronous I/O for maximum
throughput.
+ Image compression (LZF and GZIP - the former is very fast and highly
recommended).
+ Support for saving a full image of your memory, resulting in a fast,
responsive system after resuming.
+ Support for plugins: data transformers (compression, encryption) and
new storage backends (NFS support is planned).
+ Nice user interface (Bootsplash (http://www.bootsplash.org) compatible;
+ The ability to specify a maximum image size;
+ The ability to cancel a suspend by pressing Escape (for security, this
can be disabled).
+ Speed and reliability. Software Suspend 2.0 has been extensively tested
in a variety of configurations over many months. It is not guaranteed
to be perfect, but bugs found will be hunted and fixed quickly.
The Software Suspend website includes extensive documentation, including
known issues (primarily DRI and USB support) and FAQS. A well-used mailing
list is also available.
Known issues with Suspend 2.0 are as follows:
+ DRI support is lacking power management support under 2.4 & 2.6.
+ AGP support under 2.6 is partially implemented.
+ USB support under 2.4 and 2.6 is lacking.
+ SMP support is currently 2.4 only.
+ Other drivers have varying degrees of power management support.
+ There is currently no support for discontig memory.
+ Suspend currently requires the PSE extension (check /proc/cpuinfo).
+ Highmem >4GB is currently not supported.
+ SMP currently suffers from lost interrupts during resuming
+ 2.6 does not currently flush caches properly before powering down.
Some of these issues have work-arounds available: check the FAQs for
details.
Note that two patches are required to use suspend: one for the particular
kernel version you are using (make sure you get the most recent for your
kernel version), and a second (applied afterwards) contains the core files.
Special thanks go to Gabor Kuti, Pavel Machek and Florent Chabaud for their
work, which I have built on; to Michael Frank for many months of extensive
testing of the code, to Marc Lehmann for supplying the LZF compressor, to
Bernard Blackham for maintaining the swsusp.sf.net website and especially
to LinuxFund.org for their sponsorship of the project, which has allowed me
to work full-time on Software Suspend over the last four months.
Finally, heres a little ditty, to be sung to the tune of the 'The Pirates
Who Don't Do Anything' (http://www.bassbios.com/bodclan/pirates.mp3)
I'm just a user who wanted to suspend, I didn't want to be a kernel hacker
at all! I'm just a user who wanted to suspend, and now I'm happy because I
can suspend.
Well I've never been to LinuxConf
and I've never written a device driver
And I've never talked to Linus
and I'm not an expert at BK
And I don't normally get paid to do this
and I don't own any hardware manuals
And I've never been to Boston in the fall...
Sebastian Kugler replied:
First of all, congratulations to everyone contributing to swsusp, great
work! Runs fast and stable here with 2.4.24, surely something I wouldn't
want to miss on my Laptop. Suspending takes about 15 sec, resuming about
half a minute. No problems with drivers, no unloading of modules is
necessary. Also bootsplash does look very 'sexy' with swsusp.
Secondly, and 'somewhat offtopic': How the heck do I get rid of this ditty
stuck in my head? ;-)
Elsewhere, several folks attempted to port the patch up to the full bleeding
edge of 2.6 development, with good success.
5. Linux 2.6.2-rc2-mm2 Released
30 Jan - 6 Feb (26 posts) Archive Link: "2.6.2-rc2-mm2"
Topics: FS: XFS, USB
People: Andrew Morton
Andrew Morton announced Linux 2.6.2-rc2-mm2, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc2/
2.6.2-rc2-mm2/
+ I added a few late-arriving patches. Usually this breaks things.
+ Added a few external development trees (USB, XFS).
+ PNP update
Various folks reported problems with some of Andrew's "late-arriving" patches,
and Andrew uploaded a fixed version "mm2-1".
6. CPU Hotplugging Code Update
31 Jan - 5 Feb (19 posts) Archive Link: "[PATCH 3/4] 2.6.2-rc2-mm2 CPU
Hotplug: The Core"
Topics: FS: sysfs, Hot-Plugging, SMP
People: Rusty Russell, Ingo Molnar, Dipankar Sarma, Zwane Mwaikambo
Rusty Russell posted a large patch to update CPU hotplugging. He listed the
status as still experimental, and gave this documentation:
This is the arch-indep hotplug cpu code, contributed by Matt Fleming, Zwane
Mwaikambo, Dipankar Sarma, Joel Schopp, Vatsa Vaddagiri and me.
Changes are designed to be NOOPs: usually by explicit use of
CONFIG_HOTPLUG_CPU
The way CPUs go down is:
1. Userspace writes 0 to sysfs ("online" attrib).
2. The cpucontrol mutex is grabbed.
3. The task moves onto the cpu.
4. cpu_online(cpu) is set to false.
5. Tasks are migrated, cpus_allowed broken if required (not kernel
threads)
6. We move back off the cpu.
7. CPU_OFFLINE notifier is called for the cpu (kernel threads clean up).
8. Arch-specific __cpu_die() is called.
9. CPU_DEAD notifier is called (caches drained, etc).
10. hotplug script is run
11. cpucontrol mutex released.
CPUs go up as before, except with CONFIG_HOTPLUG_CPU, they can go up after
boot.
Changes are:
+ drivers/base/cpu.c: Add an "online" attribute.
+ drivers/scsi/scsi.c: drain the scsi_done_q into current CPU on CPU_DEAD
+ fs/buffer.c: release buffer heads from bh_lrus on CPU_DEAD
+ linux/cpu.h: Add cpu_down(). Add hotcpu_notifier convenience macro. Add
cpu_is_offline() for when you know a cpu was (once) online: this is a
constant if !CONFIG_HOTPLUG_CPU.
+ linux/interrupt.h: Add tasklet_kill_immediate for RCU tasklet takedown
on dead CPU.
+ linux/mmzip.h: keep pointer to kswapd, in case we need to move it.
+ linux/sched.h: Add migrate_all_tasks() for cpu-down. Add migrate_to_cpu
for kernel threads to escape. Add wake_idle_cpu() for i386 hotplug
code.
+ kernel/cpu.c: Take cpucontrol lock around notifiers: notifiers have no
locking themselves. Implement cpu_down() and code to call sbin_hotplug.
+ kernel/kmod.c: As a bound kernel thread, take care of case where thread
is going down, before keventd() CPU_OFFLINE notifier can return.
+ kernel/kthread.c: Same as kmod.c, take care of race where CPU goes down
and we didn't get migrated.
+ kernel/rcupdate.c: Move rcu batch when cpu dies.
+ kernel/sched.c: Add wake_idle_cpu() for i386 hotplug.
Check everywhere to make sure we never move tasks onto an offline cpu:
we'll just be fighting migrate_all_tasks().
Change sched_migrate_task() to migrate_to_cpu and expose it for hotplug
cpu.
Take hotplug lock in sys_sched_setaffinity.
Return cpus_allowed masked by cpu_possible_map, not cpu_online_map in
sys_sched_getaffinity, otherwise tasks can't know about whether they
can run on currently-offline cpus.
Implement migrate_all_tasks() to push tasks off the dying cpu.
Add callbacks to stop migration thread.
+ kernel/softirq.c:
Handle case where interrupt tries to kick softirqd after it has exited.
Implement tasklet_kill_immediate for RCU.
Code to shut down ksoftirqd, and take over dead cpu's tasklets.
+ kernel/timer.c:
Code to migrate timers off dead CPU.
+ kernel/workqueue.c:
Keep all workqueue is list, with their name: when cpus come up we need
to create new threads for each one.
Lock cpu hotplug in flush_workqueue for simplicity.
create_workqueue_thread doesn't need name arg, now in struct.
Lock cpu hotplug when creating and destroying workqueues.
cleanup_workqueue_thread needs to block irqs: can now be called on live
workqueues.
Implement callbacks to add and delete threads, and take over work.
+ mm/page_alloc.c:
Drain local pages on CPU which is dead.
+ mm/slab.c:
Move free_block decl, ac_entry and ac_data earlier in file.
Stop reap timer on as cpu goes offline.
Neaten list_for_each into list_for_each_entry.
Free cache blocks and correct stats one CPU is dead.
Make reap_timer_fnc terminate if cpu goes offline.
+ mm/swap.c:
Fix up committed stats and drain lru cache when cpu dead.
+ mm/vmscan.c:
Keep kswapd on cpus within node unless all CPUs go offline, and restore
when they come back.
Record kswapd tasks for each pgdat upon creation.
+ net/core/dev.c:
Drain skb queues to this cpu when another cpu is dead.
+ net/core/flow.c:
Call __flow_cache_shrink() to shrink cache to zero when CPU dead.
Some folks (mainly Ingo Molnar) went over some of the technical details, and
offered some implementation criticisms. A couple days down the line, Rusty
posted a new patch, saying:
This is my first cut of a patch, still has some old code in it. As an
attachment since it's 70k (I'll split into multiple parts later, this is
the x86 part, too).
Patch against 2.6.2-rc2-mm2. Works basically, gives "APIC error on CPU1: 08
(08)" under stress. Clues welcome.
Basically consists of:
1. New file stop_machine.[ch] which takes logic out of module.c (I haven't
converted module.c code over yet though).
2. x86: arch_cpu_down_check (called before offlining) and arch_cpu_down
(called when machine stopped, moves irqs).
3. x86: idle loop code to play dead.
4. migrate_all_tasks() called with machine stopped, and migrates kernel
threads as well.
5. cpu.c fires off a thread to do the dirty work: it schedules with
interrupts still disabled on dead cpu.
6. Most threads are happy to run on "wrong" CPUs, but slab.c reap timer
needs a little fixing, and still needs to stop when CPU goes offline.
softirq threads are tied to CPU: I just hacked in a check so the do
nothing if CPU is offline. Moving the migration thread is safe since it
should have nothing to do.
7. Ugly change to finish_arch_switch so it doesn't re-enable interrupts if
the CPU is down (switching from take_cpu_down kthread to idle task).
__migrate_task() still needs check for cpu down, AFAICT.
Given it was about a day's work, I'm happy it works at all...
There were a couple more comments, but no real discussion in reply to this.
7. Working Around Buggy BIOSes That Incorrectly Report CPU Speeds
31 Jan - 6 Feb (13 posts) Archive Link: "[PATCH] powernow-k8 max speed sanity
check"
People: Tony Lindgren, Dave Jones, Pavel Machek
Tony Lindgren said:
Following is a little patch to do a sanity check on the max speed and
voltage values provided by the bios.
Some buggy bioses provide bad values if the cpu changes, for example, in my
case the bios claims the max cpu speed is 1600MHz, while it's running at
1800MHz. (Cheapo Emachines m6805 you know...) This could also happen on
machines where the cpu is upgraded.
These checks should be safe, as they only change things if the machine is
already running at a higher speed than the bios claims.
Dave Jones and Pavel Machek threw their hands in the air; Dave said, "ye gads,
yet another problem with eMachines PST tables." And Pavel said, "Someone should
really bug them to fix their BIOS." Pavel offered his own version of some of
Tony's work, and Tony picked it over for the best bits.
8. Uptime Rollover; Status Of 2.0
1 Feb - 4 Feb (26 posts) Archive Link: "Uptime counter"
People: Matthew Reppert, David Weinehall, Matti Aarnio
Markus Hostbacka wanted to know which kernels could record uptimes greater than
497 days. Matti Aarnio replied that no 64-bit machines suffered from that
limitation. Someone else said they were surprised to hear that any kernels had
that limitation, and Matthew Reppert explained:
On 32-bit architectures, the uptime counter is only 32 bits wide. Each
"tick" of the counter is worth 1/HZ seconds (IIRC). So, you can get the
number of seconds this will hold with simple math (2^32 * 1/HZ, HZ being
100 on i386). This is about 497.1 days.
Of course, on 64-bit architectures, the counter will hold 4 billion times
that, which is about as long as the Earth has existed. Apparently 2.6 has
come up with a way to deal with this on 32-bit architectures.
Christian Borntraeger pointed out that running any kernel for such a long
period would probably be a bad move for security, since kernel updates often
contain important security fixes.
In the course of discussion, David Weinehall got in on the act, indicating that
2.0.40 might be coming out very soon, and that there would be a 2.0.41 after
that as well.
9. Linux 2.6.2-rc4-mm1 Released; Status Of Possible ReiserFS Upgrade To Version
4
2 Feb - 4 Feb (19 posts) Archive Link: "2.6.2-rc3-mm1"
Topics: FS: ReiserFS, FS: XFS, Hot-Plugging
People: Andrew Morton, Hans Reiser, Tomas Szepe
Andrew Morton announced Linux 2.6.2-rc3-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc3/
2.6.2-rc3-mm1/
+ There is a debug patch in here which detects when someone calls
i_size_write() without holding the inode's i_sem. It generates a
warning and a stack backtrace. We know that XFS generates such a trace.
It will turn itself off after the first ten warnings. Please don't
report the XFS case.
+ Added the CPU hotplug code.
+ This kernel is currently broken on ppc64. Something to do with the
sched-domains patch although at this stage we do not know whether the
problem lies with that patch or with the ppc64 code.
+ A big Altix update
+ Latest versions of various other developers' trees. See below for
details.
+ Various other fixes
Vladimir Saveliev asked what Andrew would require, in order to get Reiser4
included in the 2.6 tree. Andrew replied:
I haven't looked at it. Please send me the two patches (core kernel diff
and the fs) along with complete usage instructions so that people know
where to find the userspace tools, how to run them etc. Also please ensure
that all mount options are documented and that any known bugs are
described.
Be aware that the barriers for a new filesystem are relatively high: each
one adds a significant maintenance burden to the VFS and MM developers. It
will need cautious review.
But that doesn't mean we cannot get it out there, get you some more testing
and exposure.
Hans Reiser replied, "Andrew, while it is your decision to make, it would be
very silly to not let us upgrade ReiserFS. V4 is 2-5x the speed of V3, has more
functionality, better security, is more maintainable, etc. Once V4 is as stable
and tested as V3, no one in their right mind will use V3 on a new install.
While we will be happy to read improvements and critiques of our
implementations from a clever coder such as yourself, we aren't exactly new to
the Linux Kernel, and we are one of the very few in that community who have a
real QA process that we systematically apply. That is why we did not send it in
many months ago: our testing is quite extensive, and we don't think users
should find bugs that we can find if we make the effort. Now we are running out
of bugs that we can hit. There are distros that would like to ship using
Reiser4 in April." Tomas Szepe replied that version 4 still seemed unreliable,
and Hans suggested grabbing the latest code, which might fix some of the
issues.
10. Linux 2.6.2 "Feisty Dunnary" Released
3 Feb - 6 Feb (14 posts) Archive Link: "Linux 2.6.2 aka "Feisty Dunnart""
People: Linus Torvalds, Ian Soboroff, John Bradford, Alastair Stevens
Linus Torvalds announced 2.6.2, or the "Feisty Dunnart", saying, "I just pushed
out the BK trees, and the tar-ball/patches are going out as I write this, for
Linux 2.6.2. The honor of naming it goes to Gernot Heiser, for reasons that are
largely alcoholic, I suspect. Good job! The changelog from -rc3 mainly contains
some ppc64 updates." Ian Soboroff replied:
For the benefit of those of you who, like me, didn't know what a dunnart
is, from http://library.thinkquest.org/28994/dunnart.html:
There are ten species of dunnart. Some of them are the common dunnart,
white-footed dunnart, and the Darling Downs dunnart. There is also the
fat-tailed dunnart. They are called the marsupial mouse and are usually
10 to 16 cm. long.
They live in Australia and New Guinea. These marsupial mice live in
deserts and rainforests and eat grasshopppers, spiders, lizards, mice
and small animals.
All dunnarts are fearless and will protect themselves if they are
scared or threatened. They all have litters of up to 10 babies about 3
to 4 times a year.
The fat-tailed dunnart is the smallest and has soft, fine, gray or
black fur. They also have large ears and thick tails with short, stiff
hairs. The dunnart stores all its fat in its tail.
According to that third paragraph, we need to up our release schedule a
bit.
Alastair Stevens noticed that in the kernel Makefile, "Feisty Dunnart" was
actually assigned to a real variable used for version numbering. John Bradford
remarked, "There was some discussion on the list about dropping version numbers
altogether during 2.7: http://marc.theaimsgroup.com/?l=linux-kernel&m=
107174577415393&w=2."
11. Providing Open Firmware Paths In SysFS
3 Feb - 5 Feb (14 posts) Archive Link: "[PATCH] PCI / OF linkage in sysfs"
Topics: FS: sysfs, Power Management: ACPI, USB
People: Benjamin Herrenschmidt, Linus Torvalds, Greg KH, Andrew Morton
Benjamin Herrenschmidt said to Andrew Morton and Greg KH:
This patch adds a "devspec" property to all PCI entries in sysfs that
provides the full "Open Firmware" path to each device on PPC and PPC64
platforms that have Open Firmware support.
For various reasons, the OF path is and will still be different than the
sysfs path, and userland needs the OF path for various things, ranging from
bootloader setup to XFree needing to access some OF properties provided by
the graphic card F-Code driver, etc...
The "devspec" name is what we already use for "macio" type devices, it
doesn't clash with anything else.
If you are happy with it, please apply (independently of the rest of the
PowerMac patch), I need that to fix various things in XFree (among others),
so it would be nice to have it in by 2.6.3 final
Linus Torvalds didn't like this approach, saying:
Wouldn't it make more sense to go the other way? Ie have the PCI devices be
pointed to from the OF paths?
I'd prefer to avoid having OF-specific files in a PCI directory. That just
leads to inherently unportable user mode stuff. In contrast, having the OF
directory entry that points to the hardware (PCI) entry makes perfect
sense.
Greg suggested, "Or, if you really want to be able to get the OF info from the
pci device in sysfs, why not create a symlink in the pci device directory
pointing to your OF path in sysfs? That would seem like the best option." But
Linus replied:
Where does this stop? Do we start doing the same for all different kinds of
buses, and all kinds of firmware?
In other words, instead of having <n> different buses all know about <m>
different kinds of firmware information that they really have nothing else
to do with, it's much better to just have the <m> different kinds of
firmware information export their own information.
It just sounds _wrong_ to have the PCI layer have knowledge of OF. It has
nothing to do with OF. For OF information, you should go to the /sys/of
tree, which has the information that OF knows about (which may, of course,
then include the information about PCI devices).
Greg saw the sense in this, but Benjamin said:
I don't quite agree... There are cases for example (USB, Firewire) where we
could construct an OF path to be used by the bootloader setup without
having the OF information in the first place (for devices that weren't
plugged during boot typically). I do no intend to go that way for 2.6
though.
In both cases, we don't "have" the information.
OF doesn't have informations about the linux PCI layout (bus numbering can
be different between OF and linux for example) and PCI doesn't have
information about OF (except that on ppc64, pci_dev->arch_data points to
the OF node).
However, the arch code provides a routine that can provide that mapping PCI
-> OF (and in _that_ direction, there is one to go the other way around,
but I hate it, it's not very reliable at the moment, though I could rewrite
it..., and on ppc64, this is the most efficient way too).
It's just about providing a pointer to OF node, not actual informations out
of the device-tree...
Linus replied:
Ok. Fair enough.
I think that I personally would be a lot happier with the situation if it
wasn't that PCI had magic knowledge about OF in particular. In other words,
you'd likely be able to sell me on an idea where the PCI layer just knows
about "let the firmware install a few files here", but is totally
firmware-agnostic per se.
In other words, you migth just rename the "OF" functionality as "platform"
functionality, and add dummy (empty) platform handlers for the other
platforms (eg BIOS/EFI whatever). Maybe some day EFI will want to have a
similar pointer..
So while I'd hate to have the PCI layer start having to learn details of
all the platforms out there, I don't think it's necessarily wrong that the
PCI layer knows about the _concept_ of a platform, as long as it doesn't
get too specific.
Benjamin asked, "What about adding a pcibios_add_platform_entries(device)
called by pci_sysfs then ? By default an empty inline on asm/* and on PPC, I
can add my devspec without having OF-aware code in drivers/pci" . Linus said
this would be fine. In his same post, Benjamin also asked if the name "devspec"
were OK, because it wasn't too late to change all occurrences before folks
started to use it. Linus replied:
I have to admit that "devspec" doesn't seem to do much for me, but I don't
think we should call it "firmware", since that would (to me) be more about
the firmware of the _device_ rather than the platform.
Maybe just "platform-data" or something. But if "devspec" has magic meaning
on a Mac, and since this would be inherently platform-specific _anyway_, I
don't actually see any reason to not use "devspec".
On some platforms, we might have multiple different entries (eg on a PC we
might have pointers to ACPI data, to PnP data and to EFI data, all at the
same time. I hope we never will, but maybe there would be reason for it).
That would argue _against_ a "generic" name like "platform", and for
something that is actually very much specific to the kind of data it points
to (eg "of-data" rather than "platform-data").
End result: I don't think we much care about the name. Whatever makes you
happy. As long as the source code is clean and something like
"pcibios_add_platform_entries()" at least makes that come true.
There was no further debate, and the discussion petered out quickly.
12. Some Kernel Release History
4 Feb - 6 Feb (2 posts) Archive Link: "Kernel releases 0.01 - 2.6.2"
People: Bill Davidsen
Terry Vessels created a couple of pages listing the history of as many Linux
kernel releases as he could track down. He offered an HTML (http://edge-op.org/
files/kernel-releases.html) version and a plain text (http://edge-op.org/files/
kernel-releases) version. Bill Davidsen said, "Thanks for the timeline, may it
continue! I can't believe how long I have run machines once they became
stable... my last 1.2.13 machine was taken down on Y2k-eve, I still have a
2.1.106 machine running, and a 2.0.33 machine was upgraded to RHEL-3.0 early
this year. Speaks well for stability that machines without security issues can
just run virtually forever."
13. forcedeth Network Driver Version 0.23 Submitted
4 Feb - 5 Feb (2 posts) Archive Link: "[PATCH] [2.4] forcedeth network driver
"
People: Carl-Daniel Hailfinger, Jeff Garzik, Manfred Spraul
Carl-Daniel Hailfinger said:
attached is the current version (0.23) of forcedeth, a network driver for
nForce{,2,3} chipsets which are fairly common today. So far, the only
support for nForce chipsets has been a binary-only driver from NVidia.
The previous patch I sent generated some criticism from Jeff Garzik et al.
which has been addressed in the current version. The current version has
been posted for review twice and nobody has complained about it for more
than a week.
This driver has received testing by over 200 people on nForce1, nForce2 and
nForce3 chipsets and has already been integrated into 2.6. Before that, it
has been in -mm for a few weeks. We currently don't have any unresolved bug
reports.
Credits for the driver go to:
Andrew de Quincey: Writing a spec for the chipset
Carl-Daniel Hailfinger: Co-author of the spec, driver fixes
Manfred Spraul: Writing the driver
Jeff Garzik replied, "I'll send to Marcelo... but it's up to him whether he
will include it in 2.4.25-pre ot 2.4.26-pre. He said he's planning on releasing
2.4.25-rc soon..."
14. uClinux Update
4 Feb (1 post) Archive Link: "[PATCH]: linux-2.6.2-uc0 (MMU-less fixups)"
People: Greg Ungerer, Randy Dunlap, Russell King
Greg Ungerer said:
An update of the uClinux (MMU-less) fixups against 2.6.2. A few new things,
and some previous patches now merged.
http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.2-uc0.patch.gz
New in this patch:
mcfserial tiocmget/set fixup Russell King
mcfserial cleanup Randy Dunlap/Domen Puncer
remove unused CONFIG_LEDMAN Randy Dunlap/Domen Puncer
68328 frame buffer fixups Georges Menie
m68k support for cs89x00 Georges Menie
15. Linux 2.6.2-mm1 "Geriatric Wombat" Released
5 Feb - 7 Feb (44 posts) Archive Link: "2.6.2-mm1 aka "Geriatric Wombat""
Topics: Version Control
People: Andrew Morton, Russell King, Jeff Garzik, Luis Miguel Garcia, Matthias
Urlichs
Andrew Morton announced:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2/
2.6.2-mm1/
+ Merged some page reclaim fixes from Nick and Nikita. These yield some
performance improvements in low memory and heavy paging situations.
+ Various random fixes.
Russell King asked:
Does this include the changes to all those PCMCIA net drivers which Jeff
has had for a while from me?
I'd like to get those patches into mainline so I can close bugme bug 1711,
but I think Jeff's waiting for responses from the individual net driver
maintainers first. ;(
Jeff Garzik confirmed that the release did contain Russell's patches; and added
that he hadn't been waiting for the net driver maintainers, he was "just
waiting for 2.6.2 to be released. The first post-262 batch has been merged, am
now sending the second batch. Yours is in the third batch :)"
Luis Miguel Garcia also asked, "Andrew, do you know if this acpi pull down has
nforce support fixed? Or perhaps it's even unnotified to the acpi team?" Andrew
said his release didn't appear to have the fix, and he didn't know if the
developers knew about the problem. Arjen Verweij asked Luis for more
information on the problem, but there was no discussion.
Elsewhere, Matthias Urlichs remarked, "Just for general elucidation: this tree
now touches 1854 files, or slightly more than ten percent of the kernel source,
with roughly 3500 changes, packaged in 1500 Bitkeeper changes and/or individual
patches. Feel free to draw unwarranted conclusions from these numbers...."
16. Linux 2.4.25-rc1 Released
5 Feb - 6 Feb (1 post) Archive Link: "Linux 2.4.25-rc1"
Topics: Big Memory Support, FS: XFS
People: Marcelo Tosatti
Marcelo Tosatti released 2.4.25-rc1, saying:
Here goes the first release candidate.
It contains mostly networking updates, XFS update, amongst others.
This release contains a fix for excessive inode memory pressure with
highmem boxes. Help is specially wanted with testing this on heavy-load
highmem machines.
17. FUSE (Filesystem In User Space) Update
5 Feb - 6 Feb (5 posts) Archive Link: "[ANNOUNCE] Filesystem in Userspace
(FUSE) 1.1 stable version"
Topics: FS: NFS
People: Szeredi Miklos
Szeredi Miklos announced FUSE 1.1, saying:
This release adds support for the 2.6 Linux kernel series. Other new
features include support for exporting FUSE filesystems over NFS, read
efficiency improvements, automatic lazy unmounting, the addition of the
fsync call, plus minor bugfixes and cleanups.
Download from:
http://sourceforge.net/project/showfiles.php?group_id=21636&package_id=
31956&release_id=214856
About:
FUSE is a combination of a kernel module and a userspace library that makes
the creation of filesystems in userspace very easy. A "Hello World"
filesystem implementation is just 59 lines long (excluding empty lines and
comments).
There are currently a number of applications using FUSE in the following
categories: exporting internal state of devices (OWFS, SieFS), exporting
existing userspace virtual filesystems (KIO - FUSE gateway, AVFS), network
filesystems (SMB for FUSE, FunFS), encrypted filesystems (EncFS,
PhoneBook), exporting internal data of applications (Run Time Access). For
more info about these see 'Filesystems' in the distribution.
In addition to the native C API, FUSE has bindings for a number of other
languages: Perl, Python, Java and C++.
FUSE was designed with the following goals in mind: very simple userspace
API, generic, efficient (but still simple) kernel API and ability for
non-root users to create and mount filesystems securely.
Future plans:
I plan to submit the next version (with a revised user - kernel interface)
for inclusion into the 2.6 and/or 2.7 kernels. Still to do is a
modification of the mount syscall to allow non-root users to mount FUSE
filesystems (currently done with a suid-root helper program).
18. Status Of INI9100U Driver In 2.6.2
5 Feb (2 posts) Archive Link: "2.6.2 and INI9100U"
People: Christoph Hellwig
Wojciech Cieciwa asked why the INI9100U driver was marked as broken in 2.6.2,
since it seemed to work perfectly for him; Christoph Hellwig explained,
"There's no error handling, so as soon as you hit some kind of bus error you're
screwed."
19. New rcu_barrier() Interface Possibly Useful For ReiserFS
5 Feb (3 posts) Archive Link: "[PATCH] RCU barrier"
Topics: FS: ReiserFS
People: Dipankar Sarma, Nikita Danilov
Dipankar Sarma said, "This patch introduces a new interface - rcu_barrier()
which waits until all the RCUs queued until this call have been completed.
Nikita asked for this quite a while ago for reiser4 jnodes. Sorry Nikita, if
you are still using RCU in new reiserfs, you don't need to use your own logic
for this now. Just call rcu_barrier() during umount. If Nikita or other users
use it, then I would like to push for including this." Nikita Danilov said,
"Yes, we are still using RCU in the reiser4 (bravely). rcu_barrier() would
allow us to get rid of some really ugly code." Dipankar said to let him know if
his patch would do the trick, and if so he'd push for inclusion.
20. HFS+ Driver Update For 2.6.1; 2.6 Inclusion Policies
5 Feb - 6 Feb (7 posts) Archive Link: "Re: HFSPLus driver for Linux 2.6."
People: Dylan Griffiths, Andrew Morton, Matthias Urlichs, Benjamin
Herrenschmidt, Roman Zippel
Dylan Griffiths said:
Hi. I've just recently cleaned up a copy of the HFS Plus driver to apply to
2.6.1. I'd like to submit it for inclusion in your -mm series, so I don't
have to keep maintaining something that's out of tree. HFS+ support is one
of those things I'd like to see in 2.6 soon, so things like my Mac iPod and
friend's HFS+ formatted firewire drives will work on my Linux machines :)
I don't remember where I grabbed this driver, I only know it's much more
current than the one at http://sourceforge.net/projects/linux-hfsplus. I've
used it a lot for my iPod on 2.4, and have had success with it on 2.6.
Andrew Morton said:
Sorry, that's a showstopper. We need to understand who the maintenance team
is, and evaluate their preparedness to maintain this code long-term.
We don't want to be adding yet another rarely-used filesystem which has no
visible maintenance team.
Matthias Urlichs said, "That probably was http://www.ardistech.com/hfsplus/.
Their latest release is from mid-December." He added, "The Mac-m68k and the
Mac-PPC people would probably disagree about the "rarely-used" part. I do agree
that adding a filesystem, no matter how widely used, without at least somebody
to liaise between the kernel people and the authors is a bad idea." Close by,
Benjamin Herrenschmidt put in:
It's a not-that-rarely used filesystem actually :) Been in my tree for a
few monthes and it's used by pmac users either for iPod's or for accessing
the MacOS X partitions.
It's written & maintained by Roman Zippel, and the latest snapshot is
available at http://www.ardistech.com/hfsplus/ but you probably want to ask
Roman if it's really the latest version before merging :)
One thing we absolutely need too is a port of Apple's fsck for HFS+,
currently, the driver will refuse to mount read/write a "dirty" HFS+
filesystem to avoid corruption, but that means we have to reboot MacOS to
fsck it then... But that limitation shouldn't prevent merging it.
I suppose it may be good to also merge Roman's cleanup/rewrite of the old
HFS filesytem...
21. Linux Test Project Release For February
6 Feb (1 post) Archive Link: "[ANNOUCE] Linux Test Project February Release"
People: Marty Ridgeway, Erik Andersen
Marty Ridgeway said:
The Linux Test Project test suite <http://www.linuxtestproject.org> has
been released. The latest version of the testsuite contains 2100+ tests for
the Linux OS. Our web site also contains other information such as: test
results, a Linux test tools matrix, technical papers and HowTos on Linux
testing, and a code coverage analysis tool.
Developers from the Linux Test Project co-authored the whitepaper, "Putting
Linux Reliability to the Test". This article documents the test results and
analysis of the Linux kernel and other core OS components, including
everything from libraries and device drivers to file systems and
networking, all under some fairly adverse conditions, over a period of 60
days. You can find the paper at: http://www.ibm.com/developerworks/linux/
library/l-rel
Release Highlights:
+ Code cleanups by Erik Andersen, Glen Foster, Jay Turner, and Ming Gao.
+ Improvements to allow tests to build and execute under more
environments and distributions.
We encourage the community to post results to [email protected], and
patches, new tests, or comments/questions to [email protected].
22. Linux 2.6.3-rc1; Status Of SysFS Support
6 Feb - 9 Feb (21 posts) Archive Link: "Linux 2.6.3-rc1"
Topics: Disks: SCSI, FS: sysfs, Framebuffer, Sound: ALSA
People: Linus Torvalds, Alexander Viro, Kevin O'Connor, Greg KH
Linus Torvalds announced Linux 2.6.3-rc1, saying:
Ok, this is another big merge of a number of pending patches, although to
some degree the patches have now moved "outwards" from the core, and most
of them are in driver land.
There's a lot of network driver updates (have been in -mm and Jeff's
testing trees for a while), and Al Viro has been fixing up not just network
drivers, but also cursing over parport interfaces ;)
Andrew's patches are all over, from fixing warnings with new versions of
gcc to merging things like the ppc updates he had in his tree, and
everything in between.
On and a big ALSA update, along with SCSI updates (big qla update, for
example).
So let's calm down and make sure all the updates are ok.
Alexander Viro said:
One note: please, please, let's put a moratorium on sysfs-related patches
that didn't go through review. We are just getting netdev situation in the
main tree under control. It took nearly half a year (if not more). And now
we've got *exact* *copy* of the change that had started that mess - this
time in fbdev. Sure, there's fewer fbdev drivers, so it shouldn't take that
long. But then it's not 2.5 anymore...
If you are doing any sysfs integration - *fix* *lifetime* *rules* *first*.
You can do that in a way that will avoid breakage or need to revisit the
drivers when kobjects get embedded - just have your my_subsystem_release()
defined as kfree() and on the last step replace its body with kobject_put
(), moving the actual freeing into ->release().
Even if you are sure that you can fix all drivers in one go, there's no
need to turn the entire series into "must merge at once" monster - if
nothing else, reordering it that way will make testing easier. Sigh...
Kevin O'Connor replied:
There appears to be a lot of developer activity concentrated on getting
sysfs support in various parts of the kernel, and this inevitably leads to
a reworking of kernel object lifetime rules. I have to wonder if making
these lifetime changes is really a good idea.
Sysfs appears to be mainly used for exporting various adhoc pieces of
information and occasionally for getting various tuning input. This
functionality is generally ancillary to the main purpose of the subsystems/
drivers that use sysfs. It seems backward to me that the lifetime rules of
an object should be dominated by this ancillary functionality.
So, my question - is it really a good idea to rework much of the kernel
object lifetime rules just to support sysfs?
Greg KH replied:
At this point in time, in the stable kernel series, I say no.
That is why I created the class_simple interface, which allows developers
to be able to export data through sysfs (like the dev_t data), without
having to change their lifetime rules at all.
Now when 2.7 starts up again, that's the proper time to be changing this
kind of stuff to work "properly". Until then, lets just live with the
lifetime rules that we have (if they work, and almost all of them seem to).
And remember, I'm the person who really _wants_ to see all of this stuff
fixed up properly...
23. Linux 2.0.40 "Moss-Covered Tortoise" Released
8 Feb (1 post) Archive Link: "[ANNOUNCE] Linux-kernel 2.0.40 aka ``The
Moss-covered Tortoise''"
Topics: FS: ext2
People: David Weinehall
David Weinehall said:
Hereby I wish to announce Linux-kernel v2.0.40, aka ``The Moss-covered
Tortoise''. This release fixes several remote information-leaks, a few
local exploits, possible group descriptor corruption for ext2fs, a few
network related issues, a few SUS/LSB compliance issues, and various other
minor changes. A complete changelog can be found at the same places the
kernel itself can be downloaded.
This upgrade is of medium urgency, and is a recommended upgrade if you
experience problems. This kernel is only maintained, not developed, and
hence, if you miss support for hardware/software or any feature, then you
should consider upgrading to either the latest v2.4.xx kernel or the latest
v2.6.xx kernel.
The kernel can be found at:
ftp.xx.kernel.org (ftp://ftp.us.kernel.org) (where xx is your country-code)
Complete tarballs (compressed with gz and bzip2 respectively):
/pub/linux/kernel/v2.0/linux-2.0.40.tar.gz (http://ftp.kernel.org/pub/linux
/kernel/v2.0/linux-2.0.40.tar.gz)
/pub/linux/kernel/v2.0/linux-2.0.40.tar.bz2 (http://ftp.kernel.org/pub/
linux/kernel/v2.0/linux-2.0.40.tar.bz2)
As a patch to be applied on top of the v2.0.39 kernel-tree (compressed with
gz and bzip2 respectively):
/pub/linux/kernel/v2.0/patch-2.0.40.gz (http://ftp.kernel.org/pub/linux/
kernel/v2.0/patch-2.0.40.gz)
/pub/linux/kernel/v2.0/patch-2.0.40.bz2 (http://ftp.kernel.org/pub/linux/
kernel/v2.0/patch-2.0.40.bz2)
Note that some mirrors might not keep both compression-formats.
We Hope You Enjoy Kernel Traffic
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.