Kernel Traffic #213 For 13 Apr 2003

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1749 posts in 8784K.

There were 426 different contributors. 227 posted more than once. 150 posted last week too.

The top posters of the week were:

1. Framebuffer Fixes; Header File Reorganization

26 Mar 2003 - 4 Apr 2003 (16 posts) Archive Link: "Framebuffer fixes."

Topics: Framebuffer

People: James SimmonsAntonino DaplasBenjamin HerrenschmidtUlrich DrepperPete ZaitcevChristoph HellwigGeert Uytterhoeven

James Simmons posted a patch against 2.5.66 and said, "I tested to see if it applied. It does. Basically I added back in the static buffers in accel_cursor in fbcon.c. Now the cursor will work just like it did before. The draw back is that if you have more than one framebuffer then the cursors will be messed up. So for single headed frmaebuffer systems it will work perfectly. It is not that big of a deal since the console layer is broken for multi-head and pre-emptive support anyways. Plus fbcon has issues as well. The proper fix would require a huge amount of work. I have a few updated drivers as well. Please test." Antonino Daplas had some technical objections, and posted an additional patch, and Geert Uytterhoeven also raised some technical points. At one point James mentioned, "last night I displayed the 16 color logo perfectly fine on a 16 bpp display!!!! The mono display still has bugs tho. The new logo tries to pick the best image to display. Say for example we have two video cards. One running VESA fbdev at 16 bpp and a another at vga 4 planar via vga16fb. This way we can have the both the 16 color and 224 color logo compiled in. The correct logo will be displayed then on the correct display. Now say we only have a mono display but all the cards support 8 bpp or better. That logo still gets displayed." But Antonino objected, "What I see is a problem with the new code. What if the display is set at 16-bpp DirectColor? The code will choose clut224 for it, but that is not correct and may even crash due to an "out of bounds" error in the pseudo_palette. Directcolor 565, for instance, will only have 32 entries for red and blue, and 64 entries for green, greatly exceeding 224. Similarly, Directcolor < 12bpp, will actually need monochrome, not even 4bpp, and definitely not clut224. There are other obvious and non-obvious examples that I can enumerate."

Elsewhere, Benjamin Herrenschmidt asked James:

Why did you move the driver includes to include/video ? What is the reasoning here ?

For example, drivers/video/radeon.h moved to include/video/radeon.h

Is this to be able to share register definitions with the DRM drivers ? (I doubt this will ever happen as the DRM is rather self contained)

I would have preferred those includes to stay next to their respective drivers (though renaming radeon.h to radeonfb.h might have made some sense).

James confirmed that one motivation was sharing register definitions with the DRM drivers. He added, "The other big reason was so userland could have a standard set of hardware header files to program graphics hardware. Now SDL and directfb etc can use the same header files." Pete Zaitcev thought this had nothing to do with the kernel, and really belonged in glibc. But Ulrich Drepper said, "Headers like have no place in glibc either. There should be one or more separate packages which distribute kernel headers." Pete replied, "I can see your point, but imagine how many packages this is going to create. Shall we plead with Arjan to maintain glibc-kernelheaders as a community package, to be a clearinghouse for these things?" And Christoph Hellwig replied, "Yes. It would be nice to have a tarball of it on kernel.org instead of only the SRPM on rawhide, btw.."

2. ATM (Asynchronous Transfer Mode) Cleanup

27 Mar 2003 - 3 Apr 2003 (9 posts) Archive Link: "[ATM] second pass at fixing atm spinlock"

Topics: Networking, SMP

People: Chas WilliamsTill Immanuel PatzschkeDuncan Sands

Chas Williams said:

here is a further attempt at fixing the smp problems in the linux-atm stack. things have been moved around in net/atm:

ftp://ftp.cmf.nrl.navy.mil/pub/chas/linux-atm/2_5_64_atm_dev_lock.patch

[i will try to get a 2.5.65 version available this weekend]

Later he also said:

i have made an equivalent version of these patches for 2.4.20 in hopes of getting more feedback.

ftp://ftp.cmf.nrl.navy.mil/pub/chas/linux-atm/2_4_20_atm_dev_lock.patch

(only the nicstar, fore200e, eni and he (included) driver support the new smp 'safe' locking)

Duncan Sands and Till Immanuel Patzschke were both enthusiastic about the work Chas had put in on this. Till said, "thanks for having taken the job of cleaning this up!!! I've merged your 2.4 patch w/ my changes and check w/ a couple of thousand PPPoA sessions created and destroyed over night (which always triggered the locking/unlocking vcc problems on my SMP box). I'll let you know how it goes by tomorrow." Chas cautioned, "you might still see problem. i didnt fix the race when opening to prevent vpi/vci collisions. however, i should have a patch tomorrow to address this."

3. Linux 2.5.66-mm2 Released

1 Apr 2003 - 7 Apr 2003 (11 posts) Archive Link: "2.5.66-mm2"

Topics: Disks: SCSI

People: Andrew Morton

Andrew Morton announced:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.66/2.5.66-mm2/

4. Kernel Debugging Markers

3 Apr 2003 - 5 Apr 2003 (4 posts) Archive Link: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0304.0/0546.html

People: Werner AlmesbergerKarim Yaghmour

Werner Almesberger said:

A while ago, there was some discussion on various mechanisms for inserting taps for debuggers, tracing, security monitors, etc. into the kernel.

Here's a pretty light-weight approach I call "reliable markers":

I'm using them for umlsim, http://umlsim.sourceforge.net/ The umlsim control process reads the usual DWARF2 debugging information, and can then also do things like:

Below is a patch with the markers and two usage examples in the kernel. On the umlsim side (uses a Perl/C-ish script language), they would be used like this:

run/ping-peek.umlsim:

...
$brk_a_out = break($a.daemon_write.entry);      <--- breakpoint
...
        $pkt = $grab_outgoing_packet();         (see below)
        $enqueue($$,$pkt,$delay);
        $$.return (*skb)->len;                  <--- return from function
...

include/nettap.umlsim:

global $grab_outgoing_packet = function
{
    return (unsigned char [(*skb)->len]) (*skb)->data; <-- access arg & var
};

umlsim is still in its infancy, but this should illustrate how much can be done with such simple breakpoint support, plus the debugging information gcc already provides.

Karim Yaghmour replied:

Very interesting.

We've already got a small program that does this for LTT statements which we plan to use in the future: genevent.
http://www.listserv.shafik.org/pipermail/ltt-dev/2003-January/000408.html

genevent is pretty much straight forward. You type:

$ ./genevent default.event
$ ls default*
-rw-rw-r--    1 karim    karim         392 Apr  5 11:58 default.c
-rw-rw-r--    1 karim    karim        6892 Apr  5 11:56 default.event
-rw-rw-r--    1 karim    karim       18328 Apr  5 11:58 default.h

The default.event file contains declarations about each event. Here's an example:

//TRACE_EV_SYSCALL_ENTRY
event(TRACE_EV_SYSCALL_ENTRY, "Entry in a given system call",
      field(syscall_id, "Syscall entry number in entry.S", uint(1)),
      field(address, "Address from which call was made", uint(4))
     );

And genevent creates the following entries in the default.h for it:

/****  structure and trace function for event: TRACE_EV_SYSCALL_ENTRY  ****/

__attribute__((packed)) struct TRACE_EV_SYSCALL_ENTRY_default_1{
  uint8_t syscall_id; /* Syscall entry number in entry.S */
  uint32_t address; /* Address from which call was made */
};

static inline void trace_default_TRACE_EV_SYSCALL_ENTRY(uint8_t syscall_id,
uint32_t address){
  int bufLength = sizeof(struct TRACE_EV_SYSCALL_ENTRY_default_1);
  char buff[bufLength];
  struct TRACE_EV_SYSCALL_ENTRY_default_1 * __1 = (struct
TRACE_EV_SYSCALL_ENTRY_default_1 *)buff;

  //initialize structs
  __1->syscall_id =  syscall_id;
  __1->address =  address;


  //call trace function
  trace_new(facility_default, TRACE_EV_SYSCALL_ENTRY, bufLength, buff);
};

Also, genevent automatically generates an enum for all the events
described in the .event file:
enum default_event {
  TRACE_EV_START,
  TRACE_EV_SYSCALL_ENTRY,
  TRACE_EV_SYSCALL_EXIT,
  TRACE_EV_TRAP_ENTRY,
...

Obviously the word "trace" is used throughout, but it can easily be replaced by "marker" if this mechanism were generalized.

The intent is to have a .event file in every directory where there are traced events in files (which are the equivalent of "markers" in your scheme). During the build, the various headers would be created and all the code would be generated on the fly.

Of course this is just a begining. We're open to suggestions and contributions.

And Werner said:

This looks like a clear improvement, and the markup needed in the kernel is also pretty straightforward.

But my approach actually goes a bit further: I don't even need to know types, because I can extract them from debugging information. Clearly, there is a limit on how useful this is. E.g. if a variable changes its type from "int" to "struct something *", anything using it will need to know. But at least changes like "int" -> "unsigned long" or -> "whatever_t" don't need to be synchronized.

Furthermore, the markers are for desperate cases, where the debugging information does not allow us to find arguments or variables, or even the location for placing the breakpoint. On function entry, it should be possible to access arguments without any markup in the code. I'll examine that part soon.

Generally, my idea is to gather as much useful information from debugging data as possible. A few observations so far (based on using DWARF2 information; all this is on the kernel, with the usual optimizations):

The numbers in square brackets are the gcc PRs I've submitted. (http://gcc.gnu.org/cgi-bin/gnatsweb.pl)

Without optimization, some things look better, of course.

I'm not sure how much help we can expect from the gcc side. Some of these things may just be too hard to fix. And others can't be usefully fixed at all (e.g. the markers tell gcc where the focal points are, where it has to relax optimization for accessibility).

Some thing I haven't looked at yet:

And he added:

My goal is to reduce the markup that has to be done on the kernel to the bare minimum. The "reliable markers" are the least intrusive way I could think of for handling those cases where nothing else works (e.g. in the middle of a function).

It would be nice to have a "global" clobber, though. I.e. one that flushes and invalidates all values cached in registers, and that forces all evaluations happening prior in the nominal execution flow to be carried out, including initialization of function-local variables. That way, reliable markers wouldn't need the list of things that might be looked at.

5. IPMI (Intelligent Platform Management Interface) Driver Update

3 Apr 2003 (3 posts) Archive Link: "IPMI driver version 19 release"

Topics: Version Control

People: Corey MinyardJeff Garzik

Corey Minyard announced:

This is a new release of the IPMI driver that fixes some performance problems. Some vendors implement firmware updates over IPMI, and this speeds up that process quite a bit.

Linus, please apply.

Alan, I will send you the 2.4 patch, so you don't have to fetch it from SF.

This release:

The patch is a 2.5 version against what is current in Bitkeeper (well, what is current in bk-CVS, thanks for the tool, Larry). The 2.5.66 and 2.4.20 versions are at: http://sourceforge.net/projects/openipmi/

Jeff Garzik noticed that Corey's patch contained code that implemented a delay within a tight loop, with interrupts disabled so no other code could be scheduled until it finished; not only that, but the same code called a function that also implemented a delay. He felt this could result in a complete system lockup, and asked why Corey had done it. Corey explained, "This only occurs in "run to completion" mode, which is a special mode the driver goes into after a panic. This allows the driver to get messages out during a panic to do things like extend the watchdog timer and send panic information."

6. Cleaning Up The Cache-Flushing Code

3 Apr 2003 (5 posts) Archive Link: "[PATCH] flush flush_page_to_ram"

People: Hugh DickinsRalf BaechleMiles BaderDavid S. MillerRoman Zippel

Hugh Dickins said:

This patch removes the long deprecated flush_page_to_ram. We have two different schemes for doing this cache flushing stuff, the old flush_page_to_ram way and the not so old flush_dcache_page etc. way: see DaveM's Documentation/cachetlb.txt. Keeping flush_page_to_ram around is confusing, and makes it harder to get this done right.

All architectures are updated, but the only ones where it amounts to more than deleting a line or two are m68k, mips, mips64 and v850.

I followed a prescription from DaveM (though not to the letter), that those arches with non-nop flush_page_to_ram need to do what it did in their clear_user_page and copy_user_page and flush_dcache_page.

Dave is consterned that, in the v850 nb85e case, this patch leaves its flush_dcache_page as was, uses it in clear_user_page and copy_user_page, instead of making them all flush icache as well. That may be wrong: I'm just hesitant to add cruft blindly, changing a flush_dcache macro to flush icache too; and naively hope that the necessary flush_icache calls are already in place. Miles, please let us know which way is right for v850 nb85e - thanks.

David S. Miller and Roman Zippel were very grateful for this work, and thanked Hugh. Ralf Baechle remarked, "As of about two weeks ago I've eleminated flush_page_to_ram() from the MIPS code - it was indeed a huge patch ..." And Miles Bader said:

I recently changed the v850's nb85e_cache.h to make flush_page_to_ram a nop anyway (however since Linus hasn't applied my patch, I guess you won't have seen that change ... HEY LINUS, PLEASE APPLY MY PATCHES! Ahem.).

What's in the old version of nb85e_cache.h is incorrect anyway; until recently I didn't have any working hardware, so it's basically all just random cruft.

[To be honest, I'm not sure my new version is correct either -- just _exactly_* what's expected from these macros is very hard to guess from the documentation, and only a little more clear from perusing the source -- however it does seem to work in practice, unlike the old version. * I could just make all of them flush everything, but that's very * inefficient.

7. RadeonFB Update For 2.4

3 Apr 2003 (1 post) Archive Link: "New version of radeonfb for 2.4, please test !"

Topics: PCI, Version Control

People: Benjamin Herrenschmidt

Benjamin Herrenschmidt announced:

I made a patch (against current Marcelo bk) that contains a bunch of fixes to the radeonfb driver. Among others, it includes new PCI IDs, fix problem with some TFT panels, fix 800x600 mode acceleration, and so on... It also brings the PowerMac PM code up to date.

Please, test it and let me know, especially if I broke an existing working setup. If it didn't work for you before and still doesn't let me know of course too, but I don't expect that to delay a merge with Marcelo.

This driver have been diffing for too long, with patches too scattered, this is an attempt to consolidate all. Without news from Ani in the upcoming week(s), I'll probably just consider myself as the new maintainer for this driver.

Patch can be found at http://penguinppc.org/~benh/radeonfb_ben.diff

Please, send me comments asap, as I intend to ask Marcelo to merge this version soon. I'll send those patches to James directly for the 2.5 version since the port in there seem to already be the one I did a few monthes ago.

8. CML2 Postmortem

4 Apr 2003 (3 posts) Archive Link: "Eric Raymond`s CML2 configuration generator"

Topics: Kernel Build System

People: Samium GromoffAlan CoxDave JonesRoman Zippel

Samium Gromoff asked:

The question is why the utterly beautiful generator was dropped?

Its good side was in its inability to get an invalid kernel configuration.

One of the obvious problems is that it was python-based, and thus being slow and requiring python to be installed.

So what if it was written in C?

Is it possible for it to get in before 2.6?

Alan Cox said that CML2 had other problems as well:

It required a complete mangling of the config files
It didn't include automated tools to do it
It required python2
It didn't support alternative config tools
And a few other things

He suggested Samium work on improving the existing graphical configuration tools. Dave Jones also replied to Samium, saying that CML2 suffered from "overengineering, and not listening to the requests of people that would spend the most time using it, instead pandoring to the needs of figments of Erics imagination. The day Eric stopped listening to kernel developers, kernel developers stopped listening to Eric." He said it would make no difference if CML2 were rewritten in C; and that in any case, it couldn't get in before 2.6; Dave said, "we're well into freeze now, and ripping out something of that size would be a major step backwards. Besides, Roman Zippel's kconfig work got merged instead, which is a large improvement over what we had in 2.4"

9. Status Of Software Suspend

4 Apr 2003 - 5 Apr 2003 (6 posts) Archive Link: "New Software Suspend Patch for testing."

Topics: Disks: IDE, FS: sysfs, Software Suspend

People: Nigel CunninghamPavel MachekAlan CoxAndrew Morton

Nigel Cunningham announced:

A new 2.5 port of the 2.4 version is available on www.sourceforge.net/projects/swsusp (http://www.sourceforge.net/projects/swsusp) .

The changes from the last version are not huge; perhaps most significant is that the dynamically allocated bitmaps (in place of pageflags) are implemented. This won't mean anything to most people, but Andrew Morton, Pavel and Patrick should be happy. Note for Patrick: The driver code was using KERN_EMERGENCY to print when devices were suspended/resumed. Can we lower this to INFO (I did something alone these lines in this patch). It mucks up the nice display :>

Hopefully I'll soon find time to start bombarding Pavel, Patrick and Linus with incremental patches for merging :>. In the meantime, please give it a go.

Under 2.4, we use scripts that unload problematic drivers, switch to a text console and so on before starting the process. Hopefully this will end up being unneeded in 2.5 once the driver model is complete. In the meantime, however (especially if you get problems!), you might like to try first with a minimal load, and slowly add things. It does work fine on my Omnibook XE3! YMMV.

Brief howto:

(Assuming you've applied the patch against 2.5.66 - other versions may work too).

  1. Patch, compile as normal.
  2. Ensure your kernel commandline includes resume=/dev/hdaX where X is a swap partition you will be using. More than one swap partition can be used. This just specifies which will have its header used to indicate that the system is suspended and where to find the data.
  3. If you want debugging info: echo 1 20 15 31 > /proc/sys/kernel/swsusp (See line 201ff of kernel/suspend.c for what the numbers mean).
  4. echo 4 > /proc/acpi/sleep to start the process. The system should save the image and powerdown. If you choose the debugging info, you'll have to press SHIFT at the end of each step. If you press SHIFT at other times, you can toggle this pausing on and off. Whether you selected the debugging info or not, you can press ALT to cancel the process.
  5. To resume, reboot with the same kernel. The image should be detected and reloaded without you needing to do anything special. Pausing or not is state-persistent from when you suspended.
  6. You should (DV) get your system back to where it was when you started the process.

Please report success/failure/questions on the swsusp mailing list. See Florent's home page for details.

Pavel Machek felt the code wasn't entirely ready, and Alan Cox agreed; but along the way, Pavel noticed a part of Nigel's code that "looks like you are fixing generic bug, which could make kernel do something very wrong even without swsusp, right? If so, submit it to Alan, ASAP." Alan replied, "I'll grab the older ATA spec and take a look. The other changes are broken, but this one looks quite beliavable"

10. Framebuffer Enhancements

4 Apr 2003 - 6 Apr 2003 (7 posts) Archive Link: "[PATCH] interlaced packed pixels"

Topics: Framebuffer

People: Geert UytterhoevenAlan CoxRussell King

Geert Uytterhoeven posted a very small patch and said, "I'd like to introduce a new frame buffer type to accommodate packed pixel frame buffers that store the even and odd fields separately. This is typically used in graphics hardware for TV output (e.g. set-top boxes)." Alan Cox asked, "While we are at it can we also get an FB_TYPE_MJPEG ?" Geert asked, "What's the exact format description for MJPEG? YUV 4:*:*? Shouldn't that be a FB_VISUAL_MJPEG?" And Alan said, "The frame buffer holds a jpeg frame. At the moment text mode is problematic but doable (you encode each dct square the same size for each charater and write in a carefully sized font 8))"

Elsewhere, Russell King also replied to Geert's initial post:

While we're on the subject of framebuffers, one area which needs to be looked into is the pixel layout for all of:

We currently do not support all these combinations, and so far I haven't looked into it. It is on my (great long) to do list.

And Geert replied:

Yes, this is still a (hard) problem.

BTW, more combinations are possible. E.g. swapped bytes in 16-bit words or swapped 16-bit words in 32-bit words, due to hardware swapping of data bus lines. And things get really fishy on such a system for 24-bit wide pixels.

The order within a pixel can already be specified using fb_bitfield.msb_right. But how pixels are laid out in the frame buffer is a different thing.

I thought about adding the following FB_TYPE_* flags a few years ago, but I'm not sure they'll allow us to handle all cases:

These are supposed to be OR'ed with the current FB_TYPE_* definitions, e.g. FB_TYPE_SWAP_32_IN_64 | FB_TYPE_SWAP_16_IN_32 | FB_TYPE_SWAP_8_IN_16 | FB_TYPE_PACKED_PIXELS would indicate a completely swapped video bus.

An alternative solution moves more processing into the kernel. Since the actual fbdev driver knows about all this (it has to provide fb_ops), it can provide the following operations to userspace:

This would allow a user space application to perform all simple drawing operations without having to care at all about the actual frame buffer layout.

For more complex operations, these can be performed by the application on a shadow frame buffer in a simple packed format, while letting the kernel take care of the actual drawing, including necessary chunky-to-planar conversions and bit mangling.

For performance reasons, the driver should report optimal positional and size alignments for {put,get}_image().

11. Status Of linux-kernel Mailing List

4 Apr 2003 (4 posts) Archive Link: "VGER's filters.."

Topics: Spam

People: Matti Aarnio

Matti Aarnio offered some explanation about the linux-kernel mailing list's behavior:

VGER runs email processing with two layers of filters. That we need any such thing is due to the sorry state of email (all manner of spamming all around).

VGER has web-pages where various aspects of the system are shown, _including_ present filter-rules in Majordomo. ( http://vger.kernel.org/ and onwards.. )

We have added also some synchronous filters into VGER's MTA, so that incoming email gets rejected VERBOSELY to its sender, when couple common cases are encountered.

How do these filters work, then ?

Our filters are line-based one-match keyword trigger thingies. Majordomo 1.x does not have any sort of scoring system. Nor have we had much interest in integrating something else, like SpamAssassin, into our MTA environment to make scorings.

We are treating things like messages of TEXT/PLAIN type with BASE64 encoded content, or messages with HTML in them as obfuscated and potentially spam. Our rather simple filters don't decode BASE64 (nor QP, but our MTA decodes that).

I recall that I have myself tried to use Hotmail, and found quite easily the setups so that my outgoing email will never have HTML in them. -- Current version of HM does not appear to send HTML, nor did I find any settings for it.

Current Yahoo does not send HTML attachments either, unless poster WANTS to send HTML by activating "Allow HTML tags" thingie at right underside of the message body entry box. Turning that off will not send HTML. Plain and simple.

(Making these tests took me about an hour, most of the time to get thru all those foobar verifiers.)

With Yahoo I had at first immense problems to get any email from them, as their SMTP email sender uses INVALID protocol:

<<- MAIL FROM: <yahoo-dev-null@yahoo-inc.com>
->> 501 5.1.7 strangeness between ':' and '<': <yahoo-dev-null@yahoo-inc.com>

When you read really carefully RFC 821 / 2821 syntax about that, you will see that it does not allow space in that place. Sendmail does, and that has forced others to extend the syntax alike.

That happens only during the registration if alternate address is given. Actual web-mail sending works as it should.

Yahoo is the only legitimate email source doing that of what I have seen. (Tons of spammers do it, of course.)

12. Testing Simultaneous I/O On 4000 Disks

4 Apr 2003 - 7 Apr 2003 (5 posts) Archive Link: "Testing with 4000 disks"

Topics: FS: ext2, FS: ext3

People: Badari PulavartyJakob OestergaardDave Hansen

Continuing from Issue #212, Section #1  (21 Mar 2003: Support For More Than 256 Disks (Thousands, Really)) , Badari Pulavarty reported:

I am trying to do IO on 4000 disks simulataneously. Since I don't really have 4000 disks, this is what I did.

I faked disks using scsi_debug. scsi_debug shares a single 8 MB chunk for all disks. So, I created a filesystem and made a 6MB file on it. Then I mounted all the filesystems.

He went on:

I did "read" forever on all the mounted filesystems. Machine hosed up. I was able to start only 300 processes (each process doing IO on a single filesystem).

I ran out of lowmem. I am wondering why I have so much ext3_inode_cache. All 4000 filesystems are ext2.

Dave Hansen asked what /proc/mounts said, and Badari replied with "/dev/root_/_ext3_rw_0_0/index.html" . A couple hours later, he also reported:

Okay !! I just made all my filesystem except root ext2. (I couldn't boot when I configed out ext3 - mounting root failed).

Anyway, problem seem to have gone away.. Machine is really slow while trying to do IO on all 4000 filesystems. It is slowly creating processes. System is 100% busy. (so far, it created 461 processes out of 4000). But we are not running out of lowmem and inode caches seems to be reasonable..

So, it must be some leak in ext3..

Jakob Oestergaard pointed out, "Or bad things happening because you have hundreds of processes all updating the same physical journal... You mounted rw, and reading a file causes a write due to atime updates."

13. Linux Test Project 20030404 Released

4 Apr 2003 (1 post) Archive Link: "[ANNOUNCE] The Linux Test Project ltp-20030404 released"

Topics: Bug Tracking, Version Control

People: Robert WilliamsonAndreas JaegerDan Kegel

Robert Williamson announced:

The Linux Test Project test suite ltp-full-20030404.tgz has been released. Visit our website (http://ltp.sourceforge.net) to download the latest version of the testsuite that contains 1000+ tests for the Linux OS. Our site also contains other information such as: test results, a Linux test tools matrix, an area for keeping up with fixes for known blocking problems in the 2.5 kernel releases, technical papers and HowTos on Linux testing, and a code coverage analysis tool.

Lists of test cases that are expected to fail for specific architectures and kernels are located at: http://ltp.sourceforge.net/expected-errors.php . These lists also contain expected LTP compiler warnings for each architecture and kernel.

Highlights:

A revised and updated LTP HowTo is in its final stages of review and should be available later this month. Plus, an ncurses-type GUI is also in the works for inclusion into the May release.

We encourage the community to post results, patches, or new tests on our mailing list, and to use the CVS bug tracking facility to report problems that you might encounter. More details available at our web-site.

14. Backport Of Scheduler Interactivity Patches To 2.4

7 Apr 2003 (9 posts) Archive Link: "Interactivity backport to 2.4.20-ck*"

Topics: Big O Notation, Scheduler

People: Con KolivasMarc-Christian Petersen

Con Kolivas said:

I've had numerous requests for a backport of the interactivity changes to the O(1) scheduler for the -ck* kernels. I have resisted posting my backport because people had described real problems with these patches. However it seems most, if not all of the problems are related to one patch.

I've posted a special split out patch (001_o1_int_pe_ll_030407_ck_2.4.20.patch) for ck that includes the new interactivity changes, with the one patch responsible for problems backed out. No desktop tuning patch is supposed to be necessary for this so I've removed it from the site.Note that the full -ck4 patch does not include this update. I would like some feedback from people using it before I make a more substantial update to bring out a -ck5. The patches must be applied manually in order as they're desired. I've been using them for a little while without any problems.

Get them here:

http://kernel.kolivas.org

Marc-Christian Petersen asked, "Why isn't this patch completely backed out from the main O(1) so we can see what is new?" And Con gave a link to a compressed patch (http://kernel.kolivas.org/scheda3_ck4.bz2) .

15. Linux 2.5.67 Released

7 Apr 2003 - 9 Apr 2003 (17 posts) Archive Link: "Linux 2.5.67"

Topics: I2C

People: Linus Torvalds

Linus Torvalds announced Linux 2.5.67 (http://www.kernel.org/pub/linux/kernel/v2.5/ChangeLog-2.5.67) , saying, "All over the place as usual - there's definitely a lot of small things going on. PCMCIA and i2c updates may be the most noticeable ones."

16. Replacing BitKeeper

7 Apr 2003 - 9 Apr 2003 (13 posts) Archive Link: "Re: BitBucket: GPL-ed KitBeeper clone"

Topics: Version Control

People: Petr BaudisChuck EbbertLarry McVoy

Petr Baudis mentioned, "the SVN and Arch folks have set up a mailing list for discussion about generic "smarter patch" format, see http://www.red-bean.com/mailman/listinfo/changesets for details/subscription." Chuck Ebbert replied:

Have you looked at Stellation at all? I know the code itself is Java but they have some neat ideas about being able to take 'slices' across the repository and treat the slice as a single file for things like revision tracking. In some ways this is like a changeset; I could see wanting to track revisions this way, for example:

  1. Changeset 'fix broken ptrace' gets applied
  2. Other stuff gets changed
  3. Changeset 'fix fix broken ptrace' is applied

I would want to be able to treat 1 and 3 as a single changeset with two revision levels.

Larry McVoy replied, "Except that those are ideas as far as I can tell, not actual code. In the for what it is worth department, we've done this internally and found it doesn't work as well as you might hope. Sometimes there are clear delinations and you really can move stuff around but most of the time there is stuff built on top of the stuff you want to move and there is no way for a program to tell the difference between enhancements vs fixes to the original change. Because of this, we've developed a policy, which is very hard to make stick, which is "one idea, one changeset, no fixes"." Chuck said that the last he'd seen, the Stellation folks had a pretty good prototype. But he also admitted, "The whole Eclipse/CDT/Stellation assemblage takes so much work just to get off the ground it's not even funny, not to mention their directions for putting Stellation on Oracle are curiously empty."

17. OpenSSI 0.9.6 Released

9 Apr 2003 (1 post) Archive Link: "[ANNOUNCE]OpenSSI 0.9.6 is now available"

Topics: FS: NFS, FS: devfs

People: Brian J. Watson

Aneesh Kumar K.V quoted a post from Brian J. Watson from the ssic-linux-devel mailing list:

Since 0.8.0, OpenSSI has been booted on more than 67 IA-32 nodes. It includes a first cut of HA-CFS, which allows the cluster to lose its CFS root filesystem server node and continue running, if another node is attached to the same disk. The Lustre and NFS clients were integrated (non-root). LVS now automatically registers any socket that does a listen(). Unix domain sockets, SysV shared memory, and SysV semaphores are all clusterwide.

A /proc interface can now be used to migrate a process, rather than SIGMIGRATE. An ssidevfs mount is now done for every node, and /dev is a context symlink into the ssidevfs for a process' node. CFS now supports file locking via fcntl(). The SSI version of util-linux has been merged with 2.11z. The xinetd server is now run on all nodes by default.

Various bugs have been fixed, including races, hangs, panics, and problems with strace on IA64 and Alpha.

The latest version of OpenSSI is 0.9.6. Both binary RPMs and source code can be found on http://openssi.org/.

 

 

 

 

 

 

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.