2.6.28-rc3-git6: Reported regressions 2.6.26 -> 2.6.27 - Kernel

This is a discussion on 2.6.28-rc3-git6: Reported regressions 2.6.26 -> 2.6.27 - Kernel ; This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 46

Thread: 2.6.28-rc3-git6: Reported regressions 2.6.26 -> 2.6.27

  1. [Bug #11876] RCU hang on cpu re-hotplug with 2.6.27rc8

    This message has been generated automatically as a part of a report
    of regressions introduced between 2.6.26 and 2.6.27.

    The following bug entry is on the current list of known regressions
    introduced between 2.6.26 and 2.6.27. Please verify if it still should
    be listed and let me know (either way).


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11876
    Subject : RCU hang on cpu re-hotplug with 2.6.27rc8
    Submitter : Andi Kleen
    Date : 2008-10-06 23:28 (35 days old)
    References : http://marc.info/?l=linux-kernel&m=122333610602399&w=2
    Handled-By : Paul E. McKenney


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. [Bug #11476] failure to associate after resume from suspend to ram

    This message has been generated automatically as a part of a report
    of regressions introduced between 2.6.26 and 2.6.27.

    The following bug entry is on the current list of known regressions
    introduced between 2.6.26 and 2.6.27. Please verify if it still should
    be listed and let me know (either way).


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11476
    Subject : failure to associate after resume from suspend to ram
    Submitter : Michael S. Tsirkin
    Date : 2008-09-01 13:33 (70 days old)
    References : http://marc.info/?l=linux-kernel&m=122028529415108&w=4
    Handled-By : Zhu Yi
    Dan Williams
    Jouni Malinen


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. [Bug #11843] usb hdd problems with 2.6.27.2

    This message has been generated automatically as a part of a report
    of regressions introduced between 2.6.26 and 2.6.27.

    The following bug entry is on the current list of known regressions
    introduced between 2.6.26 and 2.6.27. Please verify if it still should
    be listed and let me know (either way).


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11843
    Subject : usb hdd problems with 2.6.27.2
    Submitter : Luciano Rocha
    Date : 2008-10-22 16:22 (19 days old)
    References : http://marc.info/?l=linux-kernel&m=122469318102679&w=4


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. [Bug #11209] 2.6.27-rc1 process time accounting

    This message has been generated automatically as a part of a report
    of regressions introduced between 2.6.26 and 2.6.27.

    The following bug entry is on the current list of known regressions
    introduced between 2.6.26 and 2.6.27. Please verify if it still should
    be listed and let me know (either way).


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11209
    Subject : 2.6.27-rc1 process time accounting
    Submitter : Lukas Hejtmanek
    Date : 2008-07-31 10:43 (102 days old)
    References : http://marc.info/?l=linux-kernel&m=121750102917490&w=4
    http://lkml.org/lkml/2008/9/30/199
    http://marc.info/?l=linux-kernel&m=122470441624295&w=4
    Handled-By : Peter Zijlstra


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. [Bug #11569] Panic stop CPUs regression

    This message has been generated automatically as a part of a report
    of regressions introduced between 2.6.26 and 2.6.27.

    The following bug entry is on the current list of known regressions
    introduced between 2.6.26 and 2.6.27. Please verify if it still should
    be listed and let me know (either way).


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11569
    Subject : Panic stop CPUs regression
    Submitter : Andi Kleen
    Date : 2008-09-02 13:49 (69 days old)
    References : http://marc.info/?l=linux-kernel&m=122036356127282&w=4


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. [Bug #11983] iwlagn: wrong command queue 31, command id 0x0

    This message has been generated automatically as a part of a report
    of regressions introduced between 2.6.26 and 2.6.27.

    The following bug entry is on the current list of known regressions
    introduced between 2.6.26 and 2.6.27. Please verify if it still should
    be listed and let me know (either way).


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11983
    Subject : iwlagn: wrong command queue 31, command id 0x0
    Submitter : Matt Mackall
    Date : 2008-11-06 4:16 (4 days old)
    References : http://marc.info/?l=linux-kernel&m=122598672815803&w=4
    http://www.intellinuxwireless.org/bu...ug.cgi?id=1703
    Handled-By : reinette chatre


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. [Bug #11407] suspend: unable to handle kernel paging request

    This message has been generated automatically as a part of a report
    of regressions introduced between 2.6.26 and 2.6.27.

    The following bug entry is on the current list of known regressions
    introduced between 2.6.26 and 2.6.27. Please verify if it still should
    be listed and let me know (either way).


    Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11407
    Subject : suspend: unable to handle kernel paging request
    Submitter : Vegard Nossum
    Date : 2008-08-21 17:28 (81 days old)
    References : http://marc.info/?l=linux-kernel&m=121933974928881&w=4
    Handled-By : Rafael J. Wysocki
    Pekka Enberg
    Pavel Machek


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [Bug #11404] BUG: in 2.6.23-rc3-git7 in do_cciss_intr

    Rafael J. Wysocki wrote:
    > This message has been generated automatically as a part of a report
    > of regressions introduced between 2.6.26 and 2.6.27.
    >
    > The following bug entry is on the current list of known regressions
    > introduced between 2.6.26 and 2.6.27. Please verify if it still should
    > be listed and let me know (either way).


    Yes, it should still be listed.

    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11404
    > Subject : BUG: in 2.6.23-rc3-git7 in do_cciss_intr
    > Submitter : rdunlap
    > Date : 2008-08-21 5:52 (81 days old)
    > References : http://marc.info/?l=linux-kernel&m=121929819616273&w=4
    > http://marc.info/?l=linux-kernel&m=121932889105368&w=4
    > Handled-By : Miller, Mike (OS Dev)
    > James Bottomley


    --
    ~Randy
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [Bug #11830] disk statistics issue in 2.6.27

    On Sun, 2008-11-09 at 20:43 +0100, Rafael J. Wysocki wrote:
    > This message has been generated automatically as a part of a report
    > of regressions introduced between 2.6.26 and 2.6.27.
    >
    > The following bug entry is on the current list of known regressions
    > introduced between 2.6.26 and 2.6.27. Please verify if it still should
    > be listed and let me know (either way).


    The cause has been found - a bug in the dpt_i2o driver that was hidden
    until 2.6.27.

    I've submitted a patch for 2.6.28 which will be included in the next
    -rc, at which point I will submit it for 2.6.27-stable as well.

    Thanks

    Mike.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [Bug #11830] disk statistics issue in 2.6.27

    On Monday, 10 of November 2008, Miquel van Smoorenburg wrote:
    > On Sun, 2008-11-09 at 20:43 +0100, Rafael J. Wysocki wrote:
    > > This message has been generated automatically as a part of a report
    > > of regressions introduced between 2.6.26 and 2.6.27.
    > >
    > > The following bug entry is on the current list of known regressions
    > > introduced between 2.6.26 and 2.6.27. Please verify if it still should
    > > be listed and let me know (either way).

    >
    > The cause has been found - a bug in the dpt_i2o driver that was hidden
    > until 2.6.27.
    >
    > I've submitted a patch for 2.6.28 which will be included in the next
    > -rc, at which point I will submit it for 2.6.27-stable as well.


    Thanks for the info.

    Can you please put a pointer to the patch into the Bugzilla entry?

    Rafael
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [Bug #11830] disk statistics issue in 2.6.27

    On Mon, 2008-11-10 at 00:49 +0100, Miquel van Smoorenburg wrote:
    > On Sun, 2008-11-09 at 20:43 +0100, Rafael J. Wysocki wrote:
    > > This message has been generated automatically as a part of a report
    > > of regressions introduced between 2.6.26 and 2.6.27.
    > >
    > > The following bug entry is on the current list of known regressions
    > > introduced between 2.6.26 and 2.6.27. Please verify if it still should
    > > be listed and let me know (either way).

    >
    > The cause has been found - a bug in the dpt_i2o driver that was hidden
    > until 2.6.27.
    >
    > I've submitted a patch for 2.6.28 which will be included in the next
    > -rc, at which point I will submit it for 2.6.27-stable as well.


    Actually, that's not quite the way it works anymore. As long as the
    patch is similar for both trees, the way it's done now is to tag stable
    patches with cc: Stable Tree so they have automatic
    notifies to the stable tree.

    I'm assuming this patch should be so tagged?

    James


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [Bug #11830] disk statistics issue in 2.6.27

    On Sun, 2008-11-09 at 18:13 -0600, James Bottomley wrote:
    > On Mon, 2008-11-10 at 00:49 +0100, Miquel van Smoorenburg wrote:
    > > On Sun, 2008-11-09 at 20:43 +0100, Rafael J. Wysocki wrote:
    > > > This message has been generated automatically as a part of a report
    > > > of regressions introduced between 2.6.26 and 2.6.27.
    > > >
    > > > The following bug entry is on the current list of known regressions
    > > > introduced between 2.6.26 and 2.6.27. Please verify if it still should
    > > > be listed and let me know (either way).

    > >
    > > The cause has been found - a bug in the dpt_i2o driver that was hidden
    > > until 2.6.27.
    > >
    > > I've submitted a patch for 2.6.28 which will be included in the next
    > > -rc, at which point I will submit it for 2.6.27-stable as well.

    >
    > Actually, that's not quite the way it works anymore. As long as the
    > patch is similar for both trees, the way it's done now is to tag stable
    > patches with cc: Stable Tree so they have automatic
    > notifies to the stable tree.


    Oh OK, I did not know that. The patch applies indeed to .27 and .28 .

    > I'm assuming this patch should be so tagged?


    Yes, thank you.

    Mike.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [Bug #11380] lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16


    * Rafael J. Wysocki wrote:

    > This message has been generated automatically as a part of a report
    > of regressions introduced between 2.6.26 and 2.6.27.
    >
    > The following bug entry is on the current list of known regressions
    > introduced between 2.6.26 and 2.6.27. Please verify if it still should
    > be listed and let me know (either way).
    >
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11380
    > Subject : lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16
    > Submitter : Ingo Molnar
    > Date : 2008-08-20 6:44 (82 days old)
    > References : http://marc.info/?l=linux-kernel&m=121921480931970&w=4


    had a quick look again: i believe this one still triggers, and it's
    caused by some interaction between input code and workqueue code. I
    think it started triggering when Oleg's workqueue annotation patches
    went upstream:

    6af8bf3: workqueues: add comments to __create_workqueue_key()
    8448502: workqueues: do CPU_UP_CANCELED if CPU_UP_PREPARE fails
    8de6d30: workqueues: schedule_on_each_cpu() can use schedule_work_on()
    ef1ca23: workqueues: queue_work() can use queue_work_on()
    a67da70: workqueues: lockdep annotations for flush_work()
    3da1c84: workqueues: make get_online_cpus() useable for work->func()
    8616a89: workqueues: schedule_on_each_cpu: use flush_work()
    db70089: workqueues: implement flush_work()
    1a4d9b0: workqueues: insert_work: use "list_head *" instead of "int tail"

    plus when the cpu_active_map changes went upstream:

    e761b77: cpu hotplug, sched: Introduce cpu_active_map and redo sched domain ma

    so it's possibly an old input layer locking problem that only got
    exposed via current changes. It's not an input layer bug that got
    introduced ~80 days ago, but possibly an input layer problem. Or a CPU
    hotplug bug. Or a workqueue bug.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [Bug #11380] lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16

    On 11/10, Ingo Molnar wrote:
    >
    > * Rafael J. Wysocki wrote:
    >
    > > This message has been generated automatically as a part of a report
    > > of regressions introduced between 2.6.26 and 2.6.27.
    > >
    > > The following bug entry is on the current list of known regressions
    > > introduced between 2.6.26 and 2.6.27. Please verify if it still should
    > > be listed and let me know (either way).
    > >
    > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11380
    > > Subject : lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16
    > > Submitter : Ingo Molnar
    > > Date : 2008-08-20 6:44 (82 days old)
    > > References : http://marc.info/?l=linux-kernel&m=121921480931970&w=4

    >
    > had a quick look again: i believe this one still triggers, and it's
    > caused by some interaction between input code and workqueue code. I
    > think it started triggering when Oleg's workqueue annotation patches
    > went upstream:
    >
    > 6af8bf3: workqueues: add comments to __create_workqueue_key()
    > 8448502: workqueues: do CPU_UP_CANCELED if CPU_UP_PREPARE fails
    > 8de6d30: workqueues: schedule_on_each_cpu() can use schedule_work_on()
    > ef1ca23: workqueues: queue_work() can use queue_work_on()
    > a67da70: workqueues: lockdep annotations for flush_work()
    > 3da1c84: workqueues: make get_online_cpus() useable for work->func()
    > 8616a89: workqueues: schedule_on_each_cpu: use flush_work()
    > db70089: workqueues: implement flush_work()
    > 1a4d9b0: workqueues: insert_work: use "list_head *" instead of "int tail"


    "make get_online_cpus() useable for work->func()" changed the locking.
    destroy_workqueue() was changed to take cpu_maps_update_begin() instead
    of get_online_cpus(). Other patches can't make any difference afaics.

    Currently I don't understand why lockdep complains, will try to do
    more grepping later.

    Oleg.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [Bug #11543] kernel panic: softlockup in tick_periodic() ???

    [Rafael J. Wysocki - Sun, Nov 09, 2008 at 08:43:19PM +0100]
    | This message has been generated automatically as a part of a report
    | of regressions introduced between 2.6.26 and 2.6.27.
    |
    | The following bug entry is on the current list of known regressions
    | introduced between 2.6.26 and 2.6.27. Please verify if it still should
    | be listed and let me know (either way).
    |
    |
    | Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11543
    | Subject : kernel panic: softlockup in tick_periodic() ???
    | Submitter : Joshua Hoblitt
    | Date : 2008-09-11 16:46 (60 days old)
    | References : http://marc.info/?l=linux-kernel&m=122117786124326&w=4
    | Handled-By : Thomas Gleixner
    | Cyrill Gorcunov
    | Ingo Molnar
    | Cyrill Gorcunov
    |
    |

    Waiting for info from Joshua

    - Cyrill -
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [Bug #11380] lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16

    > On 11/10, Ingo Molnar wrote:
    > >
    > > * Rafael J. Wysocki wrote:
    > >
    > > > This message has been generated automatically as a part of a report
    > > > of regressions introduced between 2.6.26 and 2.6.27.
    > > >
    > > > The following bug entry is on the current list of known regressions
    > > > introduced between 2.6.26 and 2.6.27. Please verify if it still should
    > > > be listed and let me know (either way).
    > > >
    > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11380
    > > > Subject : lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16
    > > > Submitter : Ingo Molnar
    > > > Date : 2008-08-20 6:44 (82 days old)
    > > > References : http://marc.info/?l=linux-kernel&m=121921480931970&w=4

    > >
    > > had a quick look again: i believe this one still triggers, and it's
    > > caused by some interaction between input code and workqueue code. I
    > > think it started triggering when Oleg's workqueue annotation patches
    > > went upstream:
    > >
    > > 6af8bf3: workqueues: add comments to __create_workqueue_key()
    > > 8448502: workqueues: do CPU_UP_CANCELED if CPU_UP_PREPARE fails
    > > 8de6d30: workqueues: schedule_on_each_cpu() can use schedule_work_on()
    > > ef1ca23: workqueues: queue_work() can use queue_work_on()
    > > a67da70: workqueues: lockdep annotations for flush_work()
    > > 3da1c84: workqueues: make get_online_cpus() useable for work->func()
    > > 8616a89: workqueues: schedule_on_each_cpu: use flush_work()
    > > db70089: workqueues: implement flush_work()
    > > 1a4d9b0: workqueues: insert_work: use "list_head *" instead of "int tail"

    >
    > "make get_online_cpus() useable for work->func()" changed the locking.
    > destroy_workqueue() was changed to take cpu_maps_update_begin() instead
    > of get_online_cpus(). Other patches can't make any difference afaics.
    >
    > Currently I don't understand why lockdep complains, will try to do
    > more grepping later.


    I check original report.
    Is this really cpu hotplug related warnings?

    it seem simple ABBA lock, right?


    -> #4 (&dev->mutex){--..}:
    [] validate_chain+0x831/0xaa2
    [] __lock_acquire+0x67a/0x6e0
    [] lock_acquire+0x5b/0x81
    [] mutex_lock_interruptible_nested+0xde/0x2f8
    [] input_register_handle+0x26/0x7a dev->mutex
    [] kbd_connect+0x64/0x8d
    [] input_attach_handler+0x38/0x6b
    [] input_register_handler+0x74/0xc3 input_mutex
    [] kbd_init+0x66/0x91
    [] vty_init+0xce/0xd7
    [] tty_init+0x193/0x197
    [] do_one_initcall+0x42/0x133
    [] kernel_init+0x16e/0x1d5
    [] kernel_thread_helper+0x7/0x10
    [] 0xffffffff

    -> #3 (input_mutex){--..}:
    [] validate_chain+0x831/0xaa2
    [] __lock_acquire+0x67a/0x6e0
    [] lock_acquire+0x5b/0x81
    [] mutex_lock_interruptible_nested+0xde/0x2f8
    [] input_register_device+0xff/0x17f input_mutex
    [] acpi_button_add+0x31e/0x429
    [] acpi_device_probe+0x43/0xde
    [] driver_probe_device+0xa5/0x120
    [] __driver_attach+0x42/0x64 dev->sem
    [] bus_for_each_dev+0x43/0x65
    [] driver_attach+0x19/0x1b
    [] bus_add_driver+0x9e/0x1a1
    [] driver_register+0x76/0xd2
    [] acpi_bus_register_driver+0x3f/0x41
    [] acpi_button_init+0x32/0x51
    [] do_one_initcall+0x42/0x133
    [] do_async_initcalls+0x1a/0x2a
    [] run_workqueue+0xc3/0x193
    [] worker_thread+0xbb/0xc7
    [] kthread+0x40/0x66
    [] kernel_thread_helper+0x7/0x10
    [] 0xffffffff


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [Bug #11829] Kernel 2.6.26.5 -> 2.6.27.2 [USB REGRESSION] (USB -> D_STATE)

    On Sun, Nov 09, 2008 at 08:43:22PM +0100, Rafael J. Wysocki wrote:
    > This message has been generated automatically as a part of a report
    > of regressions introduced between 2.6.26 and 2.6.27.
    >
    > The following bug entry is on the current list of known regressions
    > introduced between 2.6.26 and 2.6.27. Please verify if it still should
    > be listed and let me know (either way).
    >
    >
    > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11829
    > Subject : Kernel 2.6.26.5 -> 2.6.27.2 [USB REGRESSION] (USB -> D_STATE)
    > Submitter : Justin Piszcz
    > Date : 2008-10-19 11:26 (22 days old)
    > References : http://marc.info/?l=linux-kernel&m=122441560120027&w=4
    > Handled-By : Alan Stern
    > Mike Isely
    > Patch : http://linuxtv.org/hg/~mcisely/pvrusb2/rev/0bb411d8d2e4


    This has been fixed already in .27 and in mainline with a patch from
    Alan.

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [PATCH] sched: release buddies on yield


    * Peter Zijlstra wrote:

    > Clear buddies on yield, so that the buddy rules don't schedule them
    > despite them being placed right-most.
    >
    > This fixed a performance regression with yield-happy binary JVMs.
    >
    > Signed-off-by: Peter Zijlstra
    > Tested-by: Lin Ming
    > ---
    > kernel/sched_fair.c | 17 ++++++++++++-----
    > 1 files changed, 12 insertions(+), 5 deletions(-)


    applied to tip/sched/urgent, thanks guys!

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. [PATCH] sched: release buddies on yield

    Clear buddies on yield, so that the buddy rules don't schedule them
    despite them being placed right-most.

    This fixed a performance regression with yield-happy binary JVMs.

    Signed-off-by: Peter Zijlstra
    Tested-by: Lin Ming
    ---
    kernel/sched_fair.c | 17 ++++++++++++-----
    1 files changed, 12 insertions(+), 5 deletions(-)

    diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
    index 51aa3e1..98345e4 100644
    --- a/kernel/sched_fair.c
    +++ b/kernel/sched_fair.c
    @@ -716,6 +716,15 @@ enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int wakeup)
    __enqueue_entity(cfs_rq, se);
    }

    +static void clear_buddies(struct cfs_rq *cfs_rq, struct sched_entity *se)
    +{
    + if (cfs_rq->last == se)
    + cfs_rq->last = NULL;
    +
    + if (cfs_rq->next == se)
    + cfs_rq->next = NULL;
    +}
    +
    static void
    dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int sleep)
    {
    @@ -738,11 +747,7 @@ dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int sleep)
    #endif
    }

    - if (cfs_rq->last == se)
    - cfs_rq->last = NULL;
    -
    - if (cfs_rq->next == se)
    - cfs_rq->next = NULL;
    + clear_buddies(cfs_rq, se);

    if (se != cfs_rq->curr)
    __dequeue_entity(cfs_rq, se);
    @@ -977,6 +982,8 @@ static void yield_task_fair(struct rq *rq)
    if (unlikely(cfs_rq->nr_running == 1))
    return;

    + clear_buddies(cfs_rq, se);
    +
    if (likely(!sysctl_sched_compat_yield) && curr->policy != SCHED_BATCH) {
    update_rq_clock(rq);
    /*

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [Bug #11380] lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16

    On 11/11, KOSAKI Motohiro wrote:
    >
    > it seem simple ABBA lock, right?
    >
    > -> #4 (&dev->mutex){--..}:
    > [] validate_chain+0x831/0xaa2
    > [] __lock_acquire+0x67a/0x6e0
    > [] lock_acquire+0x5b/0x81
    > [] mutex_lock_interruptible_nested+0xde/0x2f8
    > [] input_register_handle+0x26/0x7a dev->mutex

    ^^^^^^^^^^
    > [] kbd_connect+0x64/0x8d
    > [] input_attach_handler+0x38/0x6b
    > [] input_register_handler+0x74/0xc3 input_mutex
    > [] kbd_init+0x66/0x91
    > [] vty_init+0xce/0xd7
    > [] tty_init+0x193/0x197
    > [] do_one_initcall+0x42/0x133
    > [] kernel_init+0x16e/0x1d5
    > [] kernel_thread_helper+0x7/0x10
    > [] 0xffffffff
    >
    > -> #3 (input_mutex){--..}:
    > [] validate_chain+0x831/0xaa2
    > [] __lock_acquire+0x67a/0x6e0
    > [] lock_acquire+0x5b/0x81
    > [] mutex_lock_interruptible_nested+0xde/0x2f8
    > [] input_register_device+0xff/0x17f input_mutex
    > [] acpi_button_add+0x31e/0x429
    > [] acpi_device_probe+0x43/0xde
    > [] driver_probe_device+0xa5/0x120
    > [] __driver_attach+0x42/0x64 dev->sem

    ^^^^^^^^
    input_dev->mutex != device->sem

    > ...
    > [] do_async_initcalls+0x1a/0x2a
    > [] run_workqueue+0xc3/0x193
    > [] worker_thread+0xbb/0xc7
    > [] kthread+0x40/0x66


    What is the kernel version, btw? I can't find do_async_initcalls
    in 2.6.27 or 2.6.28.

    Anyway, this really looks like lockdep bug to me. Even if we really
    have the circular dependency (will try to grep more) I can't understand
    why lockdep claims that polldev_mutex depends on cpu_add_remove_lock.

    Oleg.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast