The release is out there (both git trees and as tarballs/patches), and for

the next week many kernel developers will be at (or flying into/out of)

LCA in Melbourne, so let's hope it's a good one.
Nothing earth-shattering happened since -rc8, although the new set of ACPI

blacklist entries and some network driver updates makes the diffstat show

that there was more than the random sprinkling of one-liners all over the

tree.
But most of it really is one-liners, and mostly not very exciting ones at

that.
The appended shortlog is obviously just the changes from -rc8, if you want

the full ChangeLog (all 5.8MB of it) from 2.6.23 it's available in the

usual places.
			Linus
---

Adrian Bunk (2):

      [ATM] atm/idt77105.c: Fix section mismatch.

      [ATM] atm/suni.c: Fix section mismatch.
Al Viro (9):

      dscc4 endian fixes

      wan/lmc bitfields fixes

      sbni endian fixes

      3c574, 3c515 bitfields abuse

      dl2k: BMCR_t fixes

      dl2k: ANAR, ANLPAR fixes

      dl2k: BMSR fixes

      dl2k: MSCR, MSSR, ESR, PHY_SCR fixes

      dl2k: the rest
Alan Cox (2):

      pata_pdc202xx_old: Fix crashes with ATAPI

      keyspan: fix oops
Alex (1):

      fix radeonfb regression with Xpress 200m 5955
Alexey Starikovskiy (2):

      ACPI: processor: Fix null pointer dereference in throttling

      ACPI: EC: fix dmesg spam regression
Andres Salomon (2):

      Input: psmouse - fix potential memory leak in psmouse_connect()

      Input: psmouse - fix input_dev leak in lifebook driver
Andrew Dyer (1):

      [WATCHDOG] clarify watchdog operation in documentation
Andrew G. Morgan (1):

      Fix filesystem capability support
Anton Salikhmetov (1):

      Update ctime and mtime for memory-mapped files
Arjan van de Ven (2):

      x86: add support for the latest Intel processors to Oprofile

      lockdep: fix kernel crash on module unload
Atsushi Nemoto (1):

      tc35815: Use irq number for tc35815-mac platform device id
Bjorn Helgaas (1):

     ...
[ message continues ]

|type commit

|tag v2.6.24

|tagger Linus Torvalds <...> 1201215533 -0800

|

|Linux 2.6.24

|

|No new name? What's up with that? Have we run out of ridiculous animals

|or human behaviour? Talk like a pirate day was long long ago.  We need

|the bug-free Weasel-series naming back!
What happened to the cunning ideas of http://lkml.org/lkml/2006/5/25/120 !

--

Since I already had two kernel developers asking about the merge window

and whether people (including me) traveling will impact it, the plan right

now is to keep the impact pretty minimal. So yes, it will probably extend

the window from the regular two weeks, but *hopefully* not by more than a

few days.
I'm going to try to merge at least some stuff while I'm in Melbourne, and

I'd expect that most of the stuff that happens during LCA is code that is

already pending to be merged (that's how the merge window is _supposed_ to

work, after all, but with the 2.6.24 release cycle being longer than usual

I suspect it's actually true in practice too).
And the second week of the merge window I'll be back again.
If I have bad bandwidth or am just goofing off during LCA, or if I end up

being too jetlagged to merge well after, that will obviously push out

things. And the same thing obviously goes for any other maintainer in the

same condition. 
I'd hope that the git users to be in fairly good condition (with hopefully

much of the stuff pending for 2.6.25 ready to go), and would worry more

about people like Andrew in particular. So let's see how this works out.
In short: I'm hoping that there won't be a big impact, but hey, let's be

flexible. Who knows what happens..
			Linus

--

As a tester, I'm not so happy.

The last few merge windows were a nightmare for us (the tester).

It remember me the 2.1.x times, but with few differences:

- more changes, so bugs are unnoticed/ignored in the first weeks or

- or people are pushing more patches possible, so they delay

   bug corrections to later times (after merge windows).
If it continues so, I should stop testing the kernel on the

merge windows (but it seems that other testers already give up

the early merge phase).
As a tester I would like:

- slow merges, so that developer could rebase and test

   (compile test) the interaction of the new code.

- you will introduce a new step on git management:

   Every changeset is compile-tested before going out to the world.

   I think this can be done automatically, and I think that one or

   two configurations are enough to find most of the problems.
Happy LCA,

ciao

	cate

--

i think this heavily varies per subsystem.
v2.6.24-rc was pretty bad due to the sglist design bug that crept in and

that kept most of the IO hackers busy for a few weeks, while testsystems

kept crashing and no progress was made on _other_ bugs. v2.6.24 early

rc's were also marred by half-cooked networking patches messing up

bisectability. I've seen a number of testers give up on that alone.

There was an unusually high flux of networking fixes throughout v2.6.24,

up to the very last day before the release.
Since it's Friday already, i put the blame for that on all the

subsystems that do not develop on lkml! :-)
It is _very_ hard for us to judge the stability and sanity of a

subsystem (and the risk factor of upcoming features!) if it's not

developed on lkml. Observing the bugs alone helps in getting a picture,

but it does not help the testers of early -rc's: it is a few

weeks/months after the fact and hence too late. We need to be able to

observe the development activities, but that's hard with all these

detached development lists. (Not only hard, it is in fact impossible,

given the sheer number of mailing list addresses in MAINTAINERS. I know,

i tried it.)
so -rc stability is usually a function of the feature/fix ratio of a

given subsystem's changes for a kernel, and those are very hard to

predict if they are not done on lkml. Getting good -mm coverage for the

subsystem git trees helps quite a bit as Andrew does a heroic job

herding all the cats, but still there's way too much 'surprise factor'

in the git merges and all the hidden development that is not directly

visible on lkml. The 'surprise factor' is not even come mainly from

combining all the trees together (that is relatively easy), it is in the

cumulative risk factor that is hard to get right due to development not

always being done on lkml.
Case point from arch/x86: everyone who follows lkml could have predicted

it from the PAT development discussions that PAT is simply not ready

yet. W...
[ message continues ]

An amazing amount of stuff gets caught when it's tested in Andrew Morton's -mm

tree.  You think -rc1's are bad now, consider that much of what will be

25-rc1 already got tried as 24-rc6-mm1 and 24-rc8-mm1.  Without those, the
It's true that a compile on x86 and a compile on PowerPC should flush out

most of the truly stupid mistakes, but those are usually found and fixed

literally within hours.  Anyhow, the proper time for test compiles is *before*

it goes into the git trees at all - it should have been tested before it

gets sent to a maintainer for inclusion.
Plus, there's a *lot* of issues that "one or two configurations" won't

find - we continually find build issues that literally depend on 3 or 4

different CONFIG_* settings, and only misbehave for one specific combination.

And all the things that compile clean but explode at runtime.

Absolutely.
I whish there would be more time for testing things during merge windows.
Greetings,

Rafael

--

My point was about "obvious" errors, and I really think that one

or two configuration will found most of these, doing in an

automatic way, and without delay the process.

Anyway more test are surely better.

BTW, IIRC there are already few "testing farms" which tests

automatically  a lot of environment and configuration (IIRC,
few hours, but a lot of changeset will broke bisect (few doc tell

us how to continue bisecting on compile errors).
As usual, "One level more indirections" ;-) . Along a spamfilter,

we (or Linus) need a patch filter.
ciao

	cate
PS: I don't want to be pessimistic. I only want to raise the problem,

to see if it is possible to improve testing environment without

affecting the development of Linux.

--

How often is "bisectability" being broken already before merge in

subsystem trees, and how often only in the context of the merge result?

(Probably impossible to answer because nobody has the data.)
Much of the former type of breakage (if we really have such breakage)

could probably be found in mostly automated ways and by volunteer

testers, by regularly testing the subsystem trees.

--

Stefan Richter

-=====-==--- ---= ==-=-

http://arcgraph.de/sr/

--

I don't bisect git trees often - but I'd say that at least half the time

I have to bisect -mm, I'll hit a busticated bisection point and need to

move several one way or another.  Fortunately, Andrew does a good job

of keeping fixes near their parents, so it's usually not *that* hard to

clean up (at least for me - but I recently realized that I had passed the

3-decade mark of breaking and fixing software).  Newcomer kernel testers

are likely in for a rude awakening if they hit one of those points.

(I already deleted the posting I'm going to reply to, therefore

References and In-Reply-To are wrong.  Sorry.)
The remedy can't just be to Cc: LKML all the time.  This would shift the

burden of directing the "general public's" attention from the domain

experts to the general public.  How will subscribers of LKML decide

which discussion threads in the huge amount of traffic are worth to

glance at?  Each of us has only a limited amount of time for LKML

consumption.
Even if you only look at the Subject: and number of postings in a

thread, how to judge whether there is a stability risk for the next -rc
Having a track record in list archives doesn't prevent bugs from happen,

at least not directly.  It might help to clarify who's responsible, if

the changelog doesn't tell us already, and thus might have a positive

long term effect on quality.  (I work in an industry where it is often

hard to identify responsibilities which IMO contributes to chronic

quality issues in that industry.)
Anyhow, I will try to remember to add a list archive pointer into my

future "what's in abc123-2.6.git" messages, so that those who care can

browse over the topics and threads to get at least a superficial

impression of what went on on the development list behind LKML's back.
(I usually also add Cc: LKML to discussions when I get the feeling that

the expertise and judgment on the development list might not be

sufficient during a respective stage of development --- but of course my

judgment of when to involve LKML isn't objective and perfect.  That is,

I /don't/ claim this to be the best way to handle subsystem development

discussions.)

--

Stefan Richter

-=====-==--- ---= ==-=-

http://arcgraph.de/sr/

--

uhm. How do you decide which of the 10000 git commits per upstream

kernel release (more than 100 a day) you'll look at?
easy: you download the full git tree from Linus, to have all the

information in one place, but you then you use filters, because you are

not interested in the whole 9 million lines of kernel code.
You use filters such as:
   git-log drivers/net/
Note what you dont get: you dont get to download just drivers/net and

nothing else. It makes no sense in isolation because this is a single

kernel codebase that is released as one logical unit. Everyone who finds

a bug in the kernel can be assumed to have access to the full kernel

source. If we talk about the "upstream kernel", we all can rely on all

of us having access to the full body of information we do development

on. This unified information base is _powerful_ stuff.
and by logical extension, the public development "metadata" of that

unified source tree should be ... just as easily accessible. Such as ...

a single forum of discussion - an email list for example.
People who dont want to follow the whole, will ... filter.
For example they will only open the threads they are interested in.
Or you dont even have to read all the subjects: you can filter on "net"

subjects for example, that filter took 2 seconds to apply for my mailer,

on 37119 mails in my lkml folder, and this reduced the number of

messages to 3959 - about 10% of the total size.
Or filter on _people_. The "domain experts" you are interested in.

Filter on all mails from David S. Miller if you are interested in

networking topics. You'll have a really good grasp of what's going on in

that area, without having to invest too much time.
Or subscribe to lwn.net who do weekly updates with links to lkml. If you

dont have the time, you might have the money to pay people who have the

time to do work for you. (or if that's still too much, follow the

time-deferred lkml updates of lwn.net)
Realize it: it's _far_ easier to fil...
[ message continues ]

A better analogy to subsystem development discussions is -mm rather than
I would like this variant the most.  All firewire bugs would be closed
Wrong.  The topic mailinglists are not about closed circles.  At least

not those which do not require subscription and which have proper list
...not an excuse for anything.  They lower the barrier for people to

participate.  Notably people
  - who are afraid of subscribing to a high-volume mailinglist (even if

    they have the technical means at their disposal to manage that

    volume),

  - who have low bandwidth internet service,

  - whose mail service provider doesn't server-side, user-configurable

    filtering,

  - who don't want to come up with sophisticated mail filters,

  - who don't want to reconfigure filters or temporarily unsubscribe

    when they go on a trip to locations without cheap connectivity,
but most importantly,
  - who are interested a lot in how gadget xyz works (and can contribute

    a lot due to their knowledge in that field) but don't know much

    about and/or aren't interested a lot in the Linux kernel (yet).
The linux1394-devel mailinglist for example is by far not only dedicated

to Linux IEEE 1394 kernel driver development.  It is also about

development and maintenance of Linux IEEE 1394 userspace libraries and

application programs.  Should we separate these topics out into a

different mailinglist?  No, we shouldn't, because these discussions are

often closely related.  Actually we have a similar problem like you are

pointing out about LKML vs. kernel subsystem lists:  We regularly have

discussions jumping around linux1394-devel, linux1394-user,

libdc1394-devel, coriander-devel, coriander-user, kino-dev, and even

linux-scsi.
So, there is traffic which is on-topic at linux1394-devel but would be

very off-topic on linux-kernel.
BTW, you misplaced the quotation marks in >>"Domain experts" hiding away

in caves<<.  These experts exist, but the "caves" generally don't, if we

igno...
[ message continues ]

(a late reply - the merge window made me ignore this thread ;-)
so you agree with me on this one? Even though you clearly do not realize

it, you've in essence conceded my whole point.
The "off-lkml" practice makes us lose information, in a largely

irreversible way - and that's the end of the argument. Q.E.D.
just let me show you an example of the conflict of logic in your 
on one side you have people who are _willing_ to participate, who'd like

to help out, who'd like to follow the development of Linux, but cannot

for some areas because it's split into 150 small mailing lists with no

coherent way to access and manage them.
on the other side you talk about people who are 'afraid' of

participating in Linux development, even though "they have the technical

means at their disposal to manage that volume". I.e., they "could"

participate, but they "dont want to" - for time constraints or just

excuses like "it's difficult to filter".
and your solution: you advocate destroying information by pulling it off

lkml for the sake of the _second_ group of people? That's perverse.
all the other arguments you say are just totally immaterial. Yes, we

could and should make lkml a better place (you could have volunteered to

summarize lkml discussions of your favorite topic on a separate list,

you could forward interesting topics to people you know dont read all of

it, etc. etc.,) but your proposed solution of _destroying lkml_ by

pulling off development into those lists is just about the most stupid

solution a person could have come up with.
	Ingo

--

I did not propose to pull anything off of LKML.
I argued that LKML's topic is not a true superset of some of those other

lists' topics, hence cannot truly replace those lists.

--

Stefan Richter

-=====-==--- --=- ----=

http://arcgraph.de/sr/

--

From: Ingo Molnar <mingo@elte.hu>
That's a very poor filter, I don't write much code lately in the

networking.
I only provide theoretical direction in a few specific areas I care

about.
As Ingo already knows, I think this "put everything on lkml" argument

is bogus.
And about bisectability, every time I apply a networking patch I do at

the very least a "allmodconfig" build with just that new patch added,

for every patch.  Often I do more extensive build testing.
And when I rebase the tree, I rerun this check after each

patch gets re-applied to a new base tree.
In fact I'm working on such issues as I fly over the Australia

for LCA08 :-)
So this isn't an issue that posting to lkml is going to help.

--

If people started filtering by stefanr to follow IEEE 1394 subsystem

development, I would have to stop drawing myself into SCSI/ Kconfig menu

layout/ coding style related discussions and meta discussions such as
Well, bisectability issues apparently occur primarily in the merge

result after merges of cross-subsystem changes.  So, things like the new

pre-merge tree which James Bottomley set up might actually help with

this issue.

--

Stefan Richter

-=====-==--- ---= ==-=-

http://arcgraph.de/sr/

--

My general rule of thumb is "if my laptop has one of those on it, I look

at it more, even if I don't have the foggiest idea how it works".  Of

course, this only works for threads with semi-sane Subject: headers....

Does your laptop have for example chained sg lists?  :-)

Or are BIDI(rectional SCSI commands) relevant to you?  (Not at all,

except if the eventual merge of the SCSI bidi will break something.)

--

Stefan Richter

-=====-==--- ---= ==-=-

http://arcgraph.de/sr/

--

Beats me - I don't see it on an 'lspci' ;)  But I'm pretty sure it doesn't

have a 'powerpc' in it, so those threads get *totally* skipped...
My point was "personal interest in the domain" may not be a great way to

tell if a given thread has a stability risk - but I suspect that for the vast

majority of testers like myself who aren't paid to be kernel hackers, if it

isn't something they can trip over on the one or two machines they can easily

test on, it isn't code they're going to review....
(Note that it extends past just hardware too - my config has selinux in it,

so those threads at least *might* get looked at.  cpusets or ocfs2?  If I

read those threads, it's probably by accident... :)

In hidinput_configure_usage(device), IS_CHICONY_TACTICAL_PAD(devic) gets

passed the 'device' parameter. But that macro still references its

parameter by 'device' instead of by its local name 'x'.
Signed-off-by: Philipp Matthias Hahn <pmhahn@titan.lahn.de>
--- linux/drivers/hid/hid-input.c	2008-01-25 09:57:17.000000000 +0100

+++ linux/drivers/hid/hid-input.c	2008-01-25 10:56:35.835871529 +0100

@@ -87,7 +87,7 @@

 #define map_key_clear(c)	do { map_key(c); clear_bit(c, bit); } while (0)
 /* hardware needing special handling due to colliding MSVENDOR page usages */

-#define IS_CHICONY_TACTICAL_PAD(x) (x->vendor == 0x04f2 && device->product == 0x0418)

+#define IS_CHICONY_TACTICAL_PAD(x) (x->vendor == 0x04f2 && x->product == 0x0418)

 #define IS_MS_KB(x) (x->vendor == 0x045e && (x->product == 0x00db || x->product == 0x00f9))
 #ifdef CONFIG_USB_HIDINPUT_POWERBOOK

--

  / /  (_)__  __ ____  __ Philipp Hahn

 / /__/ / _ \/ // /\ \/ /

/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de

--

Hi Philipp,
thanks a lot for spotting this. I have however rewritten the ugly handling

of hid-input mapping quirks code, so this bug is not present anymore

(please see hid-input-quirks branch of my git tree, if interested).
Thanks,
--

Jiri Kosina

SUSE Labs

--