Kernel Traffic #225 For 31 Jul 2003

By Zack Brown

If you like Kernel Traffic and want to send me a little money, click here:

Table Of Contents

Mailing List Stats For This Week

We looked at 1290 posts in 5843K.

There were 431 different contributors. 211 posted more than once. 218 posted last week too.

The top posters of the week were:

1. Linux 2.6.0-test1-mm1 Released

15 Jul 2003 - 20 Jul 2003 (33 posts) Archive Link: "2.6.0-test1-mm1"

Topics: Disks: IDE, Disks: SCSI, Hyperthreading

People: Andrew MortonThomas DowningMark Haverkamp

Andrew Morton announced:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test1/2.6.0-test1-mm1/

Thomas Downing replied:

I have been testing interactivity now for for a while. The only symptom (subjective) that I can see is occasional but repeatable (if you get what I mean) video _only_ skips in xine. The audio does not skip. The video skips are very short, only a 4-5 frames at most.

They occur _only_ when performing such operations as rendering a large bitmap to the screen. They do _not_ occur when dragging windows (with contents visible during drag,) nor does CPU load seem to have an effect.

Playing games with nice/renice on xine or on other processes, especially GIMP etc., does not seem to have an effect.

>From this it seems to my limited view that the remaining skips might be XFree86 issues?

Some pertinent details:

2 x P4 Xeon 2.4 Mhz, 512Mb ram.
Radeon VQ + Matrox Mystique.
Premptive kernel
Hyperthreading enabled.
IDE DVD, no SCSI in system.

No problems at all, only minor niggles since 2.5.67. (I have been following -mm patches.)

Thanks for the wonderful work!

2. Status Of The KDB Kernel Debugger

18 Jul 2003 - 21 Jul 2003 (9 posts) Archive Link: "KDB in the mainstream 2.4.x kernels?"

People: Andi KleenKeith OwensDavid S. MillerLinas Vepstas

Linas Vepstas asked when or if the KDB kernel debugger would make it into the main tree. Andi Kleen replied:

One argument i have against it: KDB is incredibly ugly code. Before it could be even considered for merging it would need quite a lot of cleanup. I actually started on porting the KDB backtracer recently to get reliable frame pointer based backtraces, but it turns out the code for that is so complicated and ugly that the chances of ever merging it would be very slim.

[...]

KDB is usually not useful for debugging hangs on desktop boxes (and even many servers) because you have usually X running. When the machine crashes and goes in KDB you cannot see the text output and debug anything. I learned to type "go<return>" blind when I had still an KDB aware kernel, but it's not very useful overall.

On a development machine you can avoid that by connecting a serial cable, but that's usually not easily possible for a desktop box. Doing a post-mortem after reboot is more practical. That is what LKCD/mcore do.

Disadvantage is that the current crash dump mechanisms (lkcd, mcore crash, netdump) are all still not very reliable and have horrible error handling. And you can eat a lot of disk space for the dumps and they tend to overflow your file systems. But still it's the only realistic option for "desktop bugs"

BTW debugging on the X server works on linuxppc/mac with xmon because it has a fbcon based console and X server. The debugger can just work on the X background while the X server is stopped. Very nifty. But I don't see the x86 XFree86 switching to a similar fbcon model any time soon, so it's unlikely to help.

Linas looked at kdb/kdbmain.c and kdb/kdb_bt.c and didn't see anything particularly ugly about the code. He asked Andi to give an example, and Andi said, "Check the kdbsupport.c code too. All the code together for the i386 backtracer is approaching 1000 LOC and it's quite ugly."

Keith Owens also replied to Andi's tale of porting woe, explaining that the ugliness was "Mainly because the kernel is full of special cases and i386 provides no unwind data to help decode those special cases, so all the special case code ends up in kdba_bt.c. Compare the complexity of i386 kdba_bt.c with ia64 kdba_bt.c, the latter is significantly simpler because ia64 mandates unwind data. Without unwind data, kdb has to use lots of awkward heuristics to even guess at an accurate backtrace. Don't blame kdb for the lack of i386 unwind data." Andi agreed it was an ugly problem, which, he said, generally resulted in ugly solutions.

Close by, David S. Miller suggested, "We could tell gcc to emit dwarf2 unwind tables on x86 for debugging kernel builds." But Keith replied, "C code is not really an issue. Most of the unwind complexity is handling the special case asm code, interrupt handlers, out of line lock contention paths, anything in entry.S. Much of the IA64 asm code has explicit unwind directives in the asm code, i386 asm would need equivalent kernel changes."

Elsewhere, under the Subject: Re: Announce: kdb v4.3 is available for kernels 2.4.20, 2.4.21 (http://www.uwsg.indiana.edu/hypermail/linux/kernel/0307.2/1398.html) , Keith announced KDB 4.3 (ftp://oss.sgi.com/projects/kdb/download/v4.3/) .

3. Filesystem Support For Arbitrary Block Devices

18 Jul 2003 - 20 Jul 2003 (7 posts) Archive Link: "Re: [PATCH] General filesystem cache"

Topics: FS: CacheFS, FS: NFS, Ottawa Linux Symposium, Samba, Version Control

People: David HowellsLinus TorvaldsDavid ChowJeff Garzik

David Howells said privately to Linus Torvalds:

Here's a patch to add a quasi-filesystem ("CacheFS") that turns a block device into a general cache for any other filesystem that cares to make use of its facilities.

This is primarily intended for use with my AFS filesystem, but I've designed it such that it needs to know nothing about the filesystem it's backing, and so it may also be useful for NFS, SMB and ISO9660 for example.

Linus replied publically:

Ok. Sounds good. In fact, it's something I've wanted for a while, since it's also potentially the solution to performance-critical things like virtual filesystems based on revision control logic etc (traditionally done with fake NFS servers).

I did a very very quick scan, and didn't see anything that raised my hackles. But it's late in the 2.6.x game, and as a result I'm not going to apply it until I get a lot of feedback from actual users too.

David Chow was very excited to hear about this, and asked if the patch was available for the 2.4 tree. David replied, "Not yet. There are plans to backport it at some point - possibly by me though I may be able to twist Jeff Garzik's arm sufficiently that he'll do the work." Close by, he did ask Jeff to do a 2.4 port, but Jeff didn't reply on the list. Elsewhere, someone asked where the patch could actually be found (Linus hadn't quoted that part in his email), and David said:

The message containing the patches doesn't seem to have made it into either the LKML or the linux-fsdevel mailing lists.

The basic code can be found in:

http://cvs.infradead.org/cgi-bin/cvsweb.cgi/afs/

In directories:

Documentations/filesystems/
include/linux/
fs/cachefs/

I'll see about putting the patch up for download when I get to OLS.

4. Status Of SquashFS In 2.6

19 Jul 2003 - 22 Jul 2003 (14 posts) Archive Link: "[PATCH] Port SquashFS to 2.6"

Topics: FS: SquashFS, FS: ext3, FS: initramfs, FS: ramfs

People: Junio C HamanoPhillip Lougher

Junio C Hamano announced:

The following is a straight port of Phillip Lougher's SquashFS (http://squashfs.sf.net). The port is based on squashfs 1.2 for 2.4.20.

The patch is on top of, and tested with, 2.6.0-test1-ac2. It applies cleanly on vanilla 2.6.0-test1 (since -ac2 is mostly bugfixes, there is not much point testing with vanilla, though).

There are four things that are different from the 2.4 version (is there "notes on porting filesystems from 2.4 to 2.6" somewhere, btw?).

A number of folks posted suggestions, and elsewhere, under the Subject: [PATCH] Port SquashFS to 2.6 (take 2) (http://www.uwsg.indiana.edu/hypermail/linux/kernel/0307.2/1417.html) , Junio posted a new version, saying:

This is the second round of the port. I have fixed the following, based on suggestions from the list, since the initial patch:

 

 

 

 

 

 

Sharon And Joy
 

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