login
Search
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):
...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 --
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 --
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 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/ --
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... :)
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 ...
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/ --
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
ignore ...(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/ --
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 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 ...
|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 ! --
