Linux 2.6.24

Linux 2.6.24

[Linus Torvalds]

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):
      hwmon: (it87) request only Environment Controller ports

Carlos Martín (2):
      agp/intel: add support for E7221 chipset
      drm/i915: add support for E7221 chipset

Carsten Otte (1):
      #ifdef very expensive debug check in page fault path

Cyrill Gorcunov (1):
      CRIS: add missed local_irq_restore call

Dan Williams (1):
      [ARM] 4748/1: dca: source drivers/dca/Kconfig in arch/arm/Kconfig to fix warning

Daniel Ritz (1):
      Input: usbtouchscreen - fix buffer overflow, make more egalax work

Daniel Walker (2):
      fix wrong sized spinlock flags argument
      ARM: OMAP1: Fix compile for board-nokia770

Dave Young (1):
      [BLUETOOTH]: Move children of connection device to NULL before connection down.

David Fries (2):
      W1: w1_therm.c ds18b20 decode freezing temperatures correctly
      W1: w1_therm.c is flagging 0C etc as invalid

David S. Miller (8):
      [NET]: Fix TX timeout regression in Intel drivers.
      [NIU]: Fix 1G PHY link state handling.
      [SPARC64]: Fix hypervisor TLB operation error reporting.
      [NET]: Fix interrupt semaphore corruption in Intel drivers.
      [NEIGH]: Revert 'Fix race between neigh_parms_release and neightbl_fill_parms'
      [TULIP] DMFE: Fix SROM parsing regression.
      [IPV4]: Add missing skb->truesize increment in ip_append_page().
      [SPARC64]: Partially revert "Constify function pointer tables."

Denis V. Lunev (1):
      [NETNS]: Re-export init_net via EXPORT_SYMBOL.

Dmitri Vorobiev (1):
      [MIPS] Malta: Fix reading the PCI clock frequency on big-endian

Dmitry Torokhov (1):
      Input: ALPS - fix sync loss on Acer Aspire 5720ZG

Eric Dumazet (1):
      [IPV4] FIB_HASH : Avoid unecessary loop in fn_hash_dump_zone()

Eric Paris (1):
      rfkill: call rfkill_led_trigger_unregister() on error

Eric Sandeen (1):
      hfs: fix coverity-found null deref

Eric W. Biederman (1):
      sysctl: kill binary sysctl KERN_PPC_L2CR

Francois Romieu (8):
      ipg: balance locking in irq handler
      ipg: plug Tx completion leak
      ipg: fix queue stop condition in the xmit handler
      ipg: fix Tx completion irq request
      sis190: add cmos ram access code for the SiS19x/968 chipset pair
      sis190: remove duplicate INIT_WORK
      sis190: mdio operation failure is not correctly detected
      sis190: scheduling while atomic error

Frank Rowand (1):
      [MIPS] SMTC: Fix build error.

Herbert Xu (1):
      [INET]: Fix truesize setting in ip_append_data

Ingo Molnar (1):
      sched: group scheduler, set uid share fix

Ivan Kokshaysky (1):
      alpha: fix conversion from denormal float to double

Ivo van Doorn (1):
      rt2x00: Fix ieee80211 payload alignment

Jan Engelhardt (1):
      [SPARC]: Constify function pointer tables.

Jason Uhlenkott (1):
      e1000e Kconfig: remove ref to nonexistant docs

Jay Cliburn (1):
      atl1: fix frame length bug

Jay Vosburgh (7):
      bonding: fix locking in sysfs primary/active selection
      bonding: fix ASSERT_RTNL that produces spurious warnings
      bonding: fix locking during alb failover and slave removal
      bonding: release slaves when master removed via sysfs
      bonding: Fix up parameter parsing
      bonding: fix lock ordering for rtnl and bonding_rwsem
      bonding: Don't hold lock when calling rtnl_unlock

Jeremy Fitzhardinge (1):
      xen: disable vcpu_info placement for now

Jesper Juhl (1):
      [IrDA]: af_irda memory leak fixes

Jesper Nilsson (1):
      CRIS v10: vmlinux.lds.S: ix kernel oops on boot and use common defines

Johann Felix Soden (1):
      Fix file references in documentation and Kconfig

Johannes Berg (1):
      lockdep: fix workqueue creation API lockdep interaction

Johannes Weiner (1):
      cpufreq: Initialise default governor before use

Jonas Bonn (1):
      jbd: do not try lock_acquire after handle made invalid

Joonwoo Park (2):
      [IPV4] fib_hash: fix duplicated route issue
      [IPV4] fib_trie: fix duplicated route issue

Jordan Crouse (1):
      x86: GEODE fix a race condition in the MFGPT timer tick

Josef 'Jeff' Sipek (1):
      arch: Ignore arch/i386 and arch/x86_64

Kalle Valo (1):
      spi: omap2_mcspi PIO RX fix

Larry Woodman (1):
      fix hugepages leak due to pagetable page sharing

Len Brown (10):
      pnpacpi: print resource shortage message only once (more)
      DMI: move dmi_available declaration to linux/dmi.h
      DMI: create dmi_get_slot()
      ACPI: create acpi_dmi_dump()
      ACPI: on OSI(Linux), print needed DMI rather than requesting dmidecode output
      ACPI: Delete Intel Customer Reference Board (CRB) from OSI(Linux) DMI list
      ACPI: make _OSI(Linux) console messages smarter
      ACPI: Add ThinkPad R61, ThinkPad T61 to OSI(Linux) white-list
      ACPI: DMI blacklist to reduce console warnings on OSI(Linux) systems.
      Revert "ACPI: Fan: Drop force_power_state acpi_device option"

Li Zefan (1):
      Revert "local_t Documentation update"

Linus Nilsson (1):
      Makefile: Change typoed 'behavour' to 'behaviour'

Linus Torvalds (2):
      Revert "mac80211: warn when receiving frames with unaligned data"

Marc Pignat (1):
      wireless/libertas support for 88w8385 sdio older revision

Matteo Croce (1):
      Replace cpmac fix

Matti Linnanvuori (1):
      Documentation: add a guideline for hard_start_xmit method

Mel Gorman (1):
      slab: partially revert list3 changes

Micah Parrish (1):
      Input: mousedev - handle mice that use absolute coordinates

Márton Németh (2):
      ACPI: EC: add leading zeros to debug messages
      ACPI: EC: "DEBUG" needs to be defined earlier

Nick Piggin (1):
      lockdep: fix internal double unlock during self-test

Nigel Cunningham (1):
      Fix unbalanced helper_lock in kernel/kmod.c

Patrick McHardy (3):
      [NETFILTER]: bridge-netfilter: fix net_device refcnt leaks
      [AF_KEY]: Fix skb leak on pfkey_send_migrate() error
      [NET]: rtnl_link: fix use-after-free

Paul Moore (1):
      selinux: fix memory leak in netlabel code

Pavel Emelyanov (1):
      [IPV6]: Mischecked tw match in __inet6_check_established.

Peter Zijlstra (1):
      lockdep: more hardirq annotations for notify_die()

Ralph Campbell (1):
      IB/ipath: Fix receiving UD messages with immediate data

Randy Dunlap (4):
      hostap: section mismatch warning
      hrtimer: fix section mismatch
      timer: fix section mismatch
      rcu: fix section mismatch

Reinette Chatre (1):
      iwlwifi: fix possible read attempt on ucode that is not available

Russell King (1):
      [ARM] pxa: don't rely on r2 being preserved over a function call

Rusty Russell (2):
      Selecting LGUEST should turn on Guest support, as in 2.6.23.
      Remove bogus duplicate CONFIG_LGUEST_GUEST entry.

Sam Ravnborg (3):
      mm: fix section mismatch warning in page_alloc.c
      [SPARC64]: Fix of section mismatch warnings.
      [SPARC64]: Fix section error in sparcspkr

Sreenivasa Honnur (1):
      S2io: Fixed synchronization between scheduling of napi with card reset and close

Stefan Schmidt (1):
      s3c2410_fb: fix line length calculation

Stefano Brivio (2):
      ipw2200: fix typo in kerneldoc
      b43: fix use-after-free rfkill bug

Stephen Hemminger (1):
      Revert "sky2: remove check for PCI wakeup setting from BIOS"

Stuart Swales (1):
      [SCSI] initio: fix module hangs on loading

Tejun Heo (2):
      sysfs: make sysfs_lookup() return ERR_PTR(-ENOENT) on failed lookup
      sysfs: fix bugs in sysfs_rename/move_dir()

Thomas Gleixner (1):
      Revert "x86: fix NMI watchdog & 'stopped time' problem"

Vivek Kutal (1):
      ARM: OMAP1: Keymap fix for f-sample and p2-sample

Wang Chen (3):
      [IPV6]: ICMP6_MIB_OUTMSGS increment duplicated
      [IPV6]: RFC 2011 compatibility broken
      [ICMP]: ICMP_MIB_OUTMSGS increment duplicated

Wim Van Sebroeck (1):
      [WATCHDOG] Revert "Stop looking for device as soon as one is found"

YOSHIFUJI Hideaki (1):
      [IPV6] ROUTE: Make sending algorithm more friendly with RFC 4861.

Re: Linux 2.6.24

[Linus Torvalds]

On Thu, 24 Jan 2008, Linus Torvalds wrote:
> 
> 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.

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

Re: Linux 2.6.24

[Giacomo A. Catenazzi]

Linus Torvalds wrote:
> 
> On Thu, 24 Jan 2008, Linus Torvalds wrote:
>> 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.
> 
> 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.

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

Re: Linux 2.6.24

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

On Fri, 25 Jan 2008 10:10:11 +0100, "Giacomo A. Catenazzi" said:

> As a tester I would like:
> - slow merges, so that developer could rebase and test
>    (compile test) the interaction of the new code.

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
-rc1 releases would be truly horrific.. ;)

> - 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.

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.



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Linux 2.6.24

[Rafael J. Wysocki]

On Friday, 25 of January 2008, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 25 Jan 2008 10:10:11 +0100, "Giacomo A. Catenazzi" said:
> 
> > As a tester I would like:
> > - slow merges, so that developer could rebase and test
> >    (compile test) the interaction of the new code.
> 
> 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
> -rc1 releases would be truly horrific.. ;)
> 
> > - 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.
> 
> It's true that a compile on x86 and a compile on PowerPC

Please add IA-64 and ARM at the very least.

> 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.

That's correct, but I'm not sure how to enforce it.

> 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

Re: Linux 2.6.24

[Giacomo A. Catenazzi]

Rafael J. Wysocki wrote:
> On Friday, 25 of January 2008, Valdis.Kletnieks@vt.edu wrote:
>> On Fri, 25 Jan 2008 10:10:11 +0100, "Giacomo A. Catenazzi" said:
>>
>>> - 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.
>> It's true that a compile on x86 and a compile on PowerPC
> 
> Please add IA-64 and ARM at the very least.

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,
also run time tests).

>> 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.

few hours, but a lot of changeset will broke bisect (few doc tell
us how to continue bisecting on compile errors).
But I agree with you.

> 
> That's correct, but I'm not sure how to enforce it.

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.

Re: Linux 2.6.24

[Stefan Richter]

Giacomo A. Catenazzi wrote:
>> On Friday, 25 of January 2008, Valdis.Kletnieks@vt.edu wrote:
[-mm]
>>> 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.
> 
> few hours, but a lot of changeset will broke bisect (few doc tell
> us how to continue bisecting on compile errors).
[...]
> 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/

using LKML for subsystem development (was Re: Linux 2.6.24)

[Stefan Richter]

(I already deleted the posting I'm going to reply to, therefore
References and In-Reply-To are wrong.  Sorry.)

On 2008-01-25, Ingo Molnar wrote in http://lkml.org/lkml/2008/1/25/320:
> * Giacomo A. Catenazzi <cate@cateee.net> wrote:
>> 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).
> 
> 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:
[...]
> 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. We deferred it to v2.6.26,

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
in the making, without experience or personal interest in the domain?

> but had we tried to cram it into v2.6.25 
> and had it broken boxes left and right, we'd rightfully be confronted 
> with all the existing lkml track record that suggested bad PAT related 
> problems and predicted the outcome. For subsystems that do not develop 
> on lkml, no such lkml track record exists and the danger of introducing 
> bad patches and ruining early -rc's increases.

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/

Re: using LKML for subsystem development (was Re: Linux 2.6.24)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On Sat, 26 Jan 2008 01:42:43 +0100, Stefan Richter said:

> 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
> in the making, without experience or personal interest in the domain?

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....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: using LKML for subsystem development

[Stefan Richter]

Valdis.Kletnieks@vt.edu wrote:
> On Sat, 26 Jan 2008 01:42:43 +0100, Stefan Richter said:
> 
>> 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
>> in the making, without experience or personal interest in the domain?
> 
> 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/

Re: using LKML for subsystem development

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Sat, 26 Jan 2008 14:31:01 +0100, Stefan Richter said:
> Does your laptop have for example chained sg lists?  :-)

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... :)




[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: using LKML for subsystem development (was Re: Linux 2.6.24)

[Ingo Molnar]

* Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> [...] 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.

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 filter down a too verbose source of 
information, than to put scattered, inaccessible pieces of information 
back together. It's far easier to get a cup of water from the open 
firehose than it is to gather the drops once they spilled on the ground. 
Sure, it all seems easier if you get everything presented on a nice 
little mailing list, with just the right people subscribed - but that 
isolation is the same kind of "closed source" thinking that causes so 
many problems in computing today.

lkml is about using this whole "open development" idea and pushing it to 
its logical conclusion. "Domain experts" hiding away in caves is just a 
fancy excuse for something much different and it can be really harmful 
to the end result (the kernel's quality). Most of the subsystems already 
do their development on lkml, but it could be further improved upon.

	Ingo

Re: using LKML for subsystem development

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Sat, 26 Jan 2008 12:28:20 +0100

> 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.

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.

Re: using LKML for subsystem development

[Stefan Richter]

David Miller wrote:
> From: Ingo Molnar <mingo@elte.hu>
> Date: Sat, 26 Jan 2008 12:28:20 +0100
> 
>> 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.
> 
> 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.

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
this.  Which might actually be a good move anyway.  :-)

> 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.

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/

Re: using LKML for subsystem development

[Stefan Richter]

Ingo Molnar wrote:
> * Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> 
>> [...] 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.
> 
> 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.

A better analogy to subsystem development discussions is -mm rather than
Linus' tree.

> You use filters such as:
> 
>    git-log drivers/net/
[...]
> 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,
[...]
> 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.

I would like this variant the most.  All firewire bugs would be closed
by now.  :-)

> (or if that's still too much, follow the 
> time-deferred lkml updates of lwn.net)
> 
> Realize it: it's _far_ easier to filter down a too verbose source of 
> information, than to put scattered, inaccessible pieces of information 
> back together. It's far easier to get a cup of water from the open 
> firehose than it is to gather the drops once they spilled on the ground.

Correct.

> Sure, it all seems easier if you get everything presented on a nice 
> little mailing list, with just the right people subscribed - but that 
> isolation is the same kind of "closed source" thinking that causes so 
> many problems in computing today.

Wrong.  The topic mailinglists are not about closed circles.  At least
not those which do not require subscription and which have proper list
archives.  These mailinglists are...

> lkml is about using this whole "open development" idea and pushing it to 
> its logical conclusion. "Domain experts" hiding away in caves is just a 
> fancy excuse for something much different

...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 non-subscriber lists and lists without usable archives for a
moment.  I as IEEE 1394 kernel subsystem maintainer would be hopelessly
incapable to get anything done if there weren't the sort of people
helping me who don't know much about the kernel but a lot about IEEE
1394; along with the very very few people who know and are interested in
both.  That latter sort of people had been 0 (read: zero) at times.

> and it can be really harmful 
> to the end result (the kernel's quality). Most of the subsystems already 
> do their development on lkml, but it could be further improved upon.

Granted.

But we can't fully replace lists like linux1394-devel by LKML.

(linux1394-devel is not an ideal example in this discussion though
because what we break, breaks only the IEEE 1394 subsystems but nothing
else.  ---  Correction:  We did break suspend/resume at two occasions or
so on systems which have one of our low-level drivers loaded.  Hard to
tell whether channeling all of linux1394-devel's discussions over LKML
would have had an effect on this.)

Back to the -mm analogy:

What about a meta list which is subscribed to the lot of subsystem lists?

People who are interested in the Linux kernel as a whole could subscribe
to that aggregated meta list.  Of course this would only fully work with
the subsystem development lists which don't require subscription to post.
-- 
Stefan Richter
-=====-==--- ---= ==-=-
http://arcgraph.de/sr/

Re: using LKML for subsystem development

[Ingo Molnar]

(a late reply - the merge window made me ignore this thread ;-)

* Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> > (or if that's still too much, follow the time-deferred lkml updates 
> > of lwn.net)
> > 
> > Realize it: it's _far_ easier to filter down a too verbose source of 
> > information, than to put scattered, inaccessible pieces of 
> > information back together. It's far easier to get a cup of water 
> > from the open firehose than it is to gather the drops once they 
> > spilled on the ground.
> 
> Correct.

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 
argument:

> [ 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),

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

Re: using LKML for subsystem development

[Stefan Richter]

Ingo Molnar wrote:
> and your solution: you advocate destroying information by pulling it off 
> lkml

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/

Re: Linux 2.6.24

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

On Sat, 26 Jan 2008 00:50:44 +0100, Stefan Richter said:
> How often is "bisectability" being broken already before merge in
> subsystem trees, and how often only in the context of the merge result?

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.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Linux 2.6.24

[Ingo Molnar]

* Giacomo A. Catenazzi <cate@cateee.net> wrote:

> Linus Torvalds wrote:
>>
>> On Thu, 24 Jan 2008, Linus Torvalds wrote:
>>> 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.
>>
>> 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.
>
> 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).

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. We deferred it to v2.6.26, but had we tried to cram it into v2.6.25 
and had it broken boxes left and right, we'd rightfully be confronted 
with all the existing lkml track record that suggested bad PAT related 
problems and predicted the outcome. For subsystems that do not develop 
on lkml, no such lkml track record exists and the danger of introducing 
bad patches and ruining early -rc's increases.

	Ingo

[PATCH] linux-2.6.24/drivers/hid/hid-input.c

[Philipp Matthias Hahn]

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

Re: [PATCH] linux-2.6.24/drivers/hid/hid-input.c

[Jiri Kosina]

On Fri, 25 Jan 2008, Philipp Matthias Hahn wrote:

> 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))

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

Re: Linux 2.6.24

[Jan Engelhardt]

On Jan 24 2008 15:17, Linus Torvalds wrote:
>
>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.

|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 !