ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc5/2.6.12-rc5-mm2/

• Dropped bk-acpi.patch. Too old, too much breakage.
• A few more subsystem trees have moved to using git
• There are a large number of patches here which fix patches which people have already sent. A very large number. Are we getting a bit careless?

Have you considered publishing -mm using git?

I guess your workflow prevents you from really using git, but even just publishing releases using git would be great.

(Just now I'm tracking Linus with my tree. git makes that quite easy. Tracking -mm is ugly manual work with diff, patch and ketchup...)

I have written a script (actually a leftover from the mm-to-BK import days) that pulls -mm into git as individual commits.

Andrew: Could you prefix the patches you pull from git with this line:

GIT SHA1-of-their-top-commit URL-of-their-archive

so that I can annotate the commits with an appropriate second parent?

If you never do any changes oon top of -mm, but only merge with it (or them), then this works out quite well.

OK, I've finally got this to the point where I can publish it.

http://ftp.kernel.org/pub/linux/kernel/people/mbligh/abat/regression_matrix.html

Currently it builds and boots any mainline, -mjb, -mm kernel within about 15 minutes of release. runs dbench, tbench, kernbench, reaim and fsx. Currently I'm using a 4x AMD64 box, a 16x NUMA-Q, 4x NUMA-Q, 32x x440 (ia32) PPC64 Power 5 LPAR, PPC64 Power 4 LPAR, and PPC64 Power 4 bare metal system. The config files it uses are linked by the machine names in the column headers.

Andrew, you should be able to see build failures in -mm more easily now ;-) I'll work on some automatic email triggers to you if you want them.

Thanks to all the other IBM people who've worked on the ABAT test system that this stuff relies on - too many to list, but especially Andy, Adam, and Enrique, who have fixed endless bugs, and put up with my incessant bitching about it all not working as it should ;-)

It will do various other bits and pieces ... more profiling, more tests, it'll do patches, etc as well. I don't want to push much volume up to kernel.org (I just copy a small subset of the generated files right now), but there are more runs queued with some fixup patches on top of -mm tree, for example. It did also do -bk and -git nightly builds, they're not in this matrix, but I'll add them back soon.

Andrew, if you want some other test added to the mix, please let me know ... though theoretically we can do multi-machine tests (eg networked), I want to stick with single-machine ones for now. There's a huge pile of tests we intend to add ... but I thought I'd throw the general results mechanism out there for people to look at.

Clicking on the failure ones error codes should take you to somewhere vaguely helpful to diagnose it. Clicking on the job number just below that takes you to the info I'm publishing right now, which should include perf results and profiles, etc. I'll add graphs, etc later, comparing performance across kernels (I have them ... just not automated).

there's performance graphs out there for tbench, dbench, kernbench, and reaim now.

http://ftp.kernel.org/pub/linux/kernel/people/mbligh/abat/perf/perf_matrix.html

-mm seems to be rather sucky on kernbench recently, I'll have a drill down into why, and try to send out some more data later on. The vertical bars on the kernbench graph are std deviation between sets of runs (a rough error margin).

sdparm is a command line utility designed to get and set SCSI device parameters (cf hdparm for ATA disks). Apart from SCSI devices (e.g. disks, tapes and enclosures) sdparm can be used on any device that uses a SCSI command set (e.g. CD/DVD drives). sdparm also can list VPD pages including the device identification page.

The major addition in version 0.93 is transport protocol specific modes pages for FCP, SPI and SAS.

For more information and downloads see: http://www.torque.net/sg/sdparm.html

ChangeLog: http://www.torque.net/sg/p/sdparm.ChangeLog

Current plan is -rc6 in a few days, 2.6.12 a week after that.

My things-to-worry-about folder still has 244 entries. Nobody seems to care much. Poor me.

Lots of USB problems, quite a few input problems. fbdev, ACPI, ATAPI. All the usual suspects.

Attached is the 'git-shortlog' script I whipped up, to mimic the shortlog script that was used back in the BitKeeper days.

shortlog reads a changelog in the 'git-whatchanged' format, such as

git-whatchanged | git-shortlog
or
git-shortlog changes.txt

and outputs the changes sorted by author:

        author1:
          cset 1-line desc
          cset 1-line desc
          ...
        author2:
          cset 1-line desc
          ...
        ...

Since git distinguishes 'author' from 'committer', I ran

git-whatchanged | git-shortlog > changes.txt

to look at the kernel authors throughout the entire history [of which is in git].

It's fun to browse, since this is the first time we've been able to get a better picture who is actually writing the patches, versus committing them. See changes.txt.bz2, attached.

Thanks, I'll add this to the git stuff, and next kernel release will have a proper shortlog.

Btw, it shows how broken your merge script is: you don't fill in the AUTHOR field properly for some reason:

 <jgarzik@pretzel.yyz.us>:
  Automatic merge of /spare/repo/netdev-2.6 branch r8169-fix
  Automatic merge of /spare/repo/linux-2.6/.git branch HEAD
  Automatic merge of /spare/repo/netdev-2.6 branch use-after-unmap
  Automatic merge of rsync://rsync.kernel.org/.../torvalds/linux-2.6.git branch HEAD

but "committer" is right. Pls fix.

the reason you didn't notice is that "git-whatchanged" normally ignores merges. Do

git-rev-list --pretty HEAD ^v2.6.12-rc5 | git-shortlog | less -S

to see what I'm talking about ("show shortlog of all the changes since v2.6.12-rc5").

sg3_utils is a package of command line utilities for sending SCSI commands to devices. This package targets the lk 2.6 and lk 2.4 series. In the lk 2.6 series these utilities (except sgp_dd) can be used with any devices that support the SG_IO ioctl.

This version includes minor enhancements, bug fixes and man page improvements. See CHANGELOG for more information.

A tarball, rpm and deb can be found on (see table 2): http://www.torque.net/sg

For an overview of sg3_utils see this page: http://www.torque.net/sg/u_index.html

The sg_dd utility has its own page at: http://www.torque.net/sg/sg_dd.html

A changelog can be found at: http://www.torque.net/sg/p/sg3_utils.CHANGELOG

A release announcement has been sent to freshmeat.net.

It's being uploaded right now, the git tree is already up-to-date, and by the time this hits the mailing list the mirroring of the tar-ball will hopefully be done too.

And since Jeff wrote me a shortlog script for git, the easist way to tell what's new since -rc5 is to just do the shortlog and diffstat output. Network drivers, USB and CPU-freq stand out.

And the good news is that people do seem to have taken my rumblings about calming down for 2.6.12 seriously. Let's hope that pans out, and I can release that one asap.. But give this a good beating first, and holler (again, if you must) about any issues you have

My scripts definitely do the expected thing.

In git, the author is always in the fixed header, and you never look for it anywhere else. However, in order for the author to _get_ there in the first place, the person who commits the thing needs to haev the author info.

In this case it was me, and I get the author information from the email when I commit an emailed patch. I take it from the first line of the body if that one is a valid "From:" line, and otherwise I fall back to taking it from the headers of the email.

So in this case you got tagged, either because the patch came through Andrew (it has his sign-off) and _he_ sent the email but incorrectly had you as the "From:" person, or alternatively because you sent the email and took Andrew's sign-off but didn't put the "From:" in the right spot.

i have released the -V0.7.47-20 Real-Time Preemption patch, which can be downloaded from the usual place:

http://redhat.com/~mingo/realtime-preempt/

i've implemented two new features:

• new debugging feature: CONFIG_DEBUG_RT_LOCKING_MODE, which adds the /proc/sys/kernel/preempt_locks flag (default: 0). This way the 'locking model' can be switched runtime - very useful for debugging and profiling. Value 0 means that all spinlocks and rwlocks are implemented via raw spinlocks/rwlocks. (which disable preemption, increase latency, but improve throughput) Value 1 means the kernel will fully preempt all locks again. (NOTE: the only safe runtime switching of the locking model can be done while the system is idle, so i've implemented the flag via two flags where the idle thread propagates the new value from the user-flag to the kernel-flag. You should put a "sleep 1" into scripts that switch the locking mode, to guarantee that the new flag value is picked up.)
• performance feature: i've implemented a new scheduler feature called 'delayed preemption', which turns sync wakeups into guaranteed wakeups, while preserving their workload-batching properties. A delayed preemption request is implemented via the TIF_NEED_RESCHED_DELAYED flag, which runs in parallel to the "immediate preemption" TIF_NEED_RESCHED flag. If this works out fine then it will be a suitable replacement for the upstream sync-wakeups facility as well.

delayed preemption already improved the performance of 'hackbench' under PREEMPT_RT quite signifiantly.

to build a -V0.7.47-20 tree, the following patches have to be applied:

http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc6.bz2
http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc6-V0.7.47-20