Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23
On Friday, 21 of December 2007, Johannes Weiner wrote: > Hi, > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > > > This message contains a list of some regressions from 2.6.23 reported since > > 2.6.24-rc1 was released, for which there are no fixes in the mainline I know > > of. If any of them have been fixed already, please let me know. > > > > If you know of any other unresolved regressions from 2.6.23, please let me > > know > > either and I'll add them to the list. Also, please let me know if any of > > the > > entries below are invalid. > > I still have a bug with cpufreq when using ondemand governor as default. Added as http://bugzilla.kernel.org/show_bug.cgi?id=9615 . Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23
btw, here is the oops as I pencil-copied it: NULL pointer deref EIP: wq_per_cpu queue_delayed_work_on() do_dbs_timer() cpufreq_governor_dbs() __cpufreq_governor() __cpufreq_set_policy() speedstep_get() cpufreq_add_dev() handle_update() sysdev_driver_register() cpufreq_register_driver() speedstep_init() kernel_init() ... HTH Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23
Hi, Michael Tokarev <[EMAIL PROTECTED]> writes: > By the way, is there any real need to specify default governor at > a compile time in the first place? Performance governor (which was > the only default so far) is a very simple one (not large to consider > its size effects for embedded systems for example), and switching > governors at run time is trivial as well. What's the motivation > behind this new config option? I think it is just convenient. If you never use the performance governor, there is no need to compile it. I have no need for an init script that changes the governor on runtime, too. I just say, use this and nothing else, ever. Don't know if this convenience is worth the trouble, though ;) >> This migrates all governors from module_init() to fs_initcall() when >> being the default, as was already done in cpufreq_performance when it >> was the only possible choice. > > Oh well. Which leads to more surprises in the future, I think... It appears a bit hackish. I would be interested in a cleaner way to force an earlier call to a module's init function. Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23
Johannes Weiner wrote: [] > I still have a bug with cpufreq when using ondemand governor as default. > > The performance governor, which has been the essential default until > 1c2562459faedc35927546cfa5273ec6c2884cce, was initialized with > fs_initcall() instead of module_init() to make sure the driver is up and > running when the bootcode (speedstep_init in my case) calls into it. > > Since the above mentioned commit, other governors can also be chosen to > be the default but they are not correctly initialized before first use > then. By the way, is there any real need to specify default governor at a compile time in the first place? Performance governor (which was the only default so far) is a very simple one (not large to consider its size effects for embedded systems for example), and switching governors at run time is trivial as well. What's the motivation behind this new config option? [] > This migrates all governors from module_init() to fs_initcall() when > being the default, as was already done in cpufreq_performance when it > was the only possible choice. Oh well. Which leads to more surprises in the future, I think... Thanks. /mjt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23
Hi, "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > This message contains a list of some regressions from 2.6.23 reported since > 2.6.24-rc1 was released, for which there are no fixes in the mainline I know > of. If any of them have been fixed already, please let me know. > > If you know of any other unresolved regressions from 2.6.23, please let me > know > either and I'll add them to the list. Also, please let me know if any of the > entries below are invalid. I still have a bug with cpufreq when using ondemand governor as default. The performance governor, which has been the essential default until 1c2562459faedc35927546cfa5273ec6c2884cce, was initialized with fs_initcall() instead of module_init() to make sure the driver is up and running when the bootcode (speedstep_init in my case) calls into it. Since the above mentioned commit, other governors can also be chosen to be the default but they are not correctly initialized before first use then. I poked Dave (added to CC) but no response since a few days. I am getting edgy now because this really breaks stuff and the attached patch should get into .24 or at least the problem should be taken more seriously. I have not yet seen a discussion about this particular problem, so if I missed something, please tell me and consider this mail obsolete. Hannes From: Johannes Weiner <[EMAIL PROTECTED]> Date: Tue, 18 Dec 2007 13:03:49 +0100 Subject: [PATCH] cpufreq: Initialise default governor before use When the cpufreq driver starts up at boot time, it calls into the default governor which might not be initialised yet. This hurts when the governor's worker function relies on memory that is not yet set up by its init function. This migrates all governors from module_init() to fs_initcall() when being the default, as was already done in cpufreq_performance when it was the only possible choice. Fixes at least one actual oops where ondemand is the default governor and cpufreq_governor_dbs() uses the uninitialised kondemand_wq work-queue during boot-time. Signed-off-by: Johannes Weiner <[EMAIL PROTECTED]> --- drivers/cpufreq/cpufreq_conservative.c |4 drivers/cpufreq/cpufreq_ondemand.c |5 - drivers/cpufreq/cpufreq_performance.c |4 drivers/cpufreq/cpufreq_userspace.c|4 4 files changed, 16 insertions(+), 1 deletions(-) diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c index 1bba997..5d3a04b 100644 --- a/drivers/cpufreq/cpufreq_conservative.c +++ b/drivers/cpufreq/cpufreq_conservative.c @@ -603,5 +603,9 @@ MODULE_DESCRIPTION ("'cpufreq_conservative' - A dynamic cpufreq governor for " "optimised for use in a battery environment"); MODULE_LICENSE ("GPL"); +#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE +fs_initcall(cpufreq_gov_dbs_init); +#else module_init(cpufreq_gov_dbs_init); +#endif module_exit(cpufreq_gov_dbs_exit); diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c index 369f445..d2af20d 100644 --- a/drivers/cpufreq/cpufreq_ondemand.c +++ b/drivers/cpufreq/cpufreq_ondemand.c @@ -610,6 +610,9 @@ MODULE_DESCRIPTION("'cpufreq_ondemand' - A dynamic cpufreq governor for " "Low Latency Frequency Transition capable processors"); MODULE_LICENSE("GPL"); +#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND +fs_initcall(cpufreq_gov_dbs_init); +#else module_init(cpufreq_gov_dbs_init); +#endif module_exit(cpufreq_gov_dbs_exit); - diff --git a/drivers/cpufreq/cpufreq_performance.c b/drivers/cpufreq/cpufreq_performance.c index e8e1451..df5fca3 100644 --- a/drivers/cpufreq/cpufreq_performance.c +++ b/drivers/cpufreq/cpufreq_performance.c @@ -60,5 +60,9 @@ MODULE_AUTHOR("Dominik Brodowski <[EMAIL PROTECTED]>"); MODULE_DESCRIPTION("CPUfreq policy governor 'performance'"); MODULE_LICENSE("GPL"); +#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE fs_initcall(cpufreq_gov_performance_init); +#else +module_init(cpufreq_gov_performance_init); +#endif module_exit(cpufreq_gov_performance_exit); diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c index 51bedab..f8cdde4 100644 --- a/drivers/cpufreq/cpufreq_userspace.c +++ b/drivers/cpufreq/cpufreq_userspace.c @@ -231,5 +231,9 @@ MODULE_AUTHOR ("Dominik Brodowski <[EMAIL PROTECTED]>, Russell King <[EMAIL PROTECTED] MODULE_DESCRIPTION ("CPUfreq policy governor 'userspace'"); MODULE_LICENSE ("GPL"); +#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE fs_initcall(cpufreq_gov_userspace_init); +#else +module_init(cpufreq_gov_userspace_init); +#endif module_exit(cpufreq_gov_userspace_exit); -- 1.5.3.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23
Hi, Rafael J. Wysocki [EMAIL PROTECTED] writes: This message contains a list of some regressions from 2.6.23 reported since 2.6.24-rc1 was released, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. I still have a bug with cpufreq when using ondemand governor as default. The performance governor, which has been the essential default until 1c2562459faedc35927546cfa5273ec6c2884cce, was initialized with fs_initcall() instead of module_init() to make sure the driver is up and running when the bootcode (speedstep_init in my case) calls into it. Since the above mentioned commit, other governors can also be chosen to be the default but they are not correctly initialized before first use then. I poked Dave (added to CC) but no response since a few days. I am getting edgy now because this really breaks stuff and the attached patch should get into .24 or at least the problem should be taken more seriously. I have not yet seen a discussion about this particular problem, so if I missed something, please tell me and consider this mail obsolete. Hannes From: Johannes Weiner [EMAIL PROTECTED] Date: Tue, 18 Dec 2007 13:03:49 +0100 Subject: [PATCH] cpufreq: Initialise default governor before use When the cpufreq driver starts up at boot time, it calls into the default governor which might not be initialised yet. This hurts when the governor's worker function relies on memory that is not yet set up by its init function. This migrates all governors from module_init() to fs_initcall() when being the default, as was already done in cpufreq_performance when it was the only possible choice. Fixes at least one actual oops where ondemand is the default governor and cpufreq_governor_dbs() uses the uninitialised kondemand_wq work-queue during boot-time. Signed-off-by: Johannes Weiner [EMAIL PROTECTED] --- drivers/cpufreq/cpufreq_conservative.c |4 drivers/cpufreq/cpufreq_ondemand.c |5 - drivers/cpufreq/cpufreq_performance.c |4 drivers/cpufreq/cpufreq_userspace.c|4 4 files changed, 16 insertions(+), 1 deletions(-) diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c index 1bba997..5d3a04b 100644 --- a/drivers/cpufreq/cpufreq_conservative.c +++ b/drivers/cpufreq/cpufreq_conservative.c @@ -603,5 +603,9 @@ MODULE_DESCRIPTION ('cpufreq_conservative' - A dynamic cpufreq governor for optimised for use in a battery environment); MODULE_LICENSE (GPL); +#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE +fs_initcall(cpufreq_gov_dbs_init); +#else module_init(cpufreq_gov_dbs_init); +#endif module_exit(cpufreq_gov_dbs_exit); diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c index 369f445..d2af20d 100644 --- a/drivers/cpufreq/cpufreq_ondemand.c +++ b/drivers/cpufreq/cpufreq_ondemand.c @@ -610,6 +610,9 @@ MODULE_DESCRIPTION('cpufreq_ondemand' - A dynamic cpufreq governor for Low Latency Frequency Transition capable processors); MODULE_LICENSE(GPL); +#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND +fs_initcall(cpufreq_gov_dbs_init); +#else module_init(cpufreq_gov_dbs_init); +#endif module_exit(cpufreq_gov_dbs_exit); - diff --git a/drivers/cpufreq/cpufreq_performance.c b/drivers/cpufreq/cpufreq_performance.c index e8e1451..df5fca3 100644 --- a/drivers/cpufreq/cpufreq_performance.c +++ b/drivers/cpufreq/cpufreq_performance.c @@ -60,5 +60,9 @@ MODULE_AUTHOR(Dominik Brodowski [EMAIL PROTECTED]); MODULE_DESCRIPTION(CPUfreq policy governor 'performance'); MODULE_LICENSE(GPL); +#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE fs_initcall(cpufreq_gov_performance_init); +#else +module_init(cpufreq_gov_performance_init); +#endif module_exit(cpufreq_gov_performance_exit); diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c index 51bedab..f8cdde4 100644 --- a/drivers/cpufreq/cpufreq_userspace.c +++ b/drivers/cpufreq/cpufreq_userspace.c @@ -231,5 +231,9 @@ MODULE_AUTHOR (Dominik Brodowski [EMAIL PROTECTED], Russell King [EMAIL PROTECTED] MODULE_DESCRIPTION (CPUfreq policy governor 'userspace'); MODULE_LICENSE (GPL); +#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE fs_initcall(cpufreq_gov_userspace_init); +#else +module_init(cpufreq_gov_userspace_init); +#endif module_exit(cpufreq_gov_userspace_exit); -- 1.5.3.7 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23
Hi, Michael Tokarev [EMAIL PROTECTED] writes: By the way, is there any real need to specify default governor at a compile time in the first place? Performance governor (which was the only default so far) is a very simple one (not large to consider its size effects for embedded systems for example), and switching governors at run time is trivial as well. What's the motivation behind this new config option? I think it is just convenient. If you never use the performance governor, there is no need to compile it. I have no need for an init script that changes the governor on runtime, too. I just say, use this and nothing else, ever. Don't know if this convenience is worth the trouble, though ;) This migrates all governors from module_init() to fs_initcall() when being the default, as was already done in cpufreq_performance when it was the only possible choice. Oh well. Which leads to more surprises in the future, I think... It appears a bit hackish. I would be interested in a cleaner way to force an earlier call to a module's init function. Hannes -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23
Johannes Weiner wrote: [] I still have a bug with cpufreq when using ondemand governor as default. The performance governor, which has been the essential default until 1c2562459faedc35927546cfa5273ec6c2884cce, was initialized with fs_initcall() instead of module_init() to make sure the driver is up and running when the bootcode (speedstep_init in my case) calls into it. Since the above mentioned commit, other governors can also be chosen to be the default but they are not correctly initialized before first use then. By the way, is there any real need to specify default governor at a compile time in the first place? Performance governor (which was the only default so far) is a very simple one (not large to consider its size effects for embedded systems for example), and switching governors at run time is trivial as well. What's the motivation behind this new config option? [] This migrates all governors from module_init() to fs_initcall() when being the default, as was already done in cpufreq_performance when it was the only possible choice. Oh well. Which leads to more surprises in the future, I think... Thanks. /mjt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23
btw, here is the oops as I pencil-copied it: NULL pointer deref EIP: wq_per_cpu queue_delayed_work_on() do_dbs_timer() cpufreq_governor_dbs() __cpufreq_governor() __cpufreq_set_policy() speedstep_get() cpufreq_add_dev() handle_update() sysdev_driver_register() cpufreq_register_driver() speedstep_init() kernel_init() ... HTH Hannes -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23
On Friday, 21 of December 2007, Johannes Weiner wrote: Hi, Rafael J. Wysocki [EMAIL PROTECTED] writes: This message contains a list of some regressions from 2.6.23 reported since 2.6.24-rc1 was released, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. I still have a bug with cpufreq when using ondemand governor as default. Added as http://bugzilla.kernel.org/show_bug.cgi?id=9615 . Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc5-git7: Reported regressions from 2.6.23
[Note: From December 22 to December 29 inclusive I will be traveling with (most probably) limited Internet access, so the next report will likely be posted after December 30. I also may be unresponsive next week. ;-)] This message contains a list of some regressions from 2.6.23 reported since 2.6.24-rc1 was released, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Listed regressions statistics - Date Total Pending Unresolved Today 118 21 13 2007-12-18 115 29 15 2007-12-12 106 31 17 2007-12-08 98 29 19 2007-12-01 85 29 18 2007-11-24 75 25 21 2007-11-19 68 26 21 2007-11-17 65 25 20 Unresolved regressions -- Subject : EHCI causes system to resume instantly from S4 Submitter : Maxim Levitsky <[EMAIL PROTECTED]> Date: 2007-10-28 14:56 References : http://lkml.org/lkml/2007/10/27/66 http://bugzilla.kernel.org/show_bug.cgi?id=9258 Handled-By : "Rafael J. Wysocki" <[EMAIL PROTECTED]> David Brownell <[EMAIL PROTECTED]> Alan Stern <[EMAIL PROTECTED]> Patch : Workaround : http://bugzilla.kernel.org/show_bug.cgi?id=9258#c30 Subject : v2.6.24-rc2-409-g9418d5d: attempt to access beyond end of device Submitter : Thomas Meyer <[EMAIL PROTECTED]> Date: 2007-11-13 13:11 References : http://lkml.org/lkml/2007/11/13/250 http://bugzilla.kernel.org/show_bug.cgi?id=9370 Handled-By : Matthew Wilcox <[EMAIL PROTECTED]> Patch : Subject : SError: { DevExch } occuring and causing disruption Submitter : Avuton Olrich <[EMAIL PROTECTED]> Date: 2007-11-15 22:39 References : http://bugzilla.kernel.org/show_bug.cgi?id=9393 Handled-By : Tejun Heo <[EMAIL PROTECTED]> Mark Lord <[EMAIL PROTECTED]> Patch : Subject : 2+ wake-ups/second in 2.6.24 Submitter : Mark Lord <[EMAIL PROTECTED]> Date: 2007-12-02 04:23 References : http://lkml.org/lkml/2007/12/1/141 http://bugzilla.kernel.org/show_bug.cgi?id=9489 Handled-By : Arjan van de Ven <[EMAIL PROTECTED]> Patch : Subject : 2.6.24: false double-clicks from USB mouse Submitter : Mark Lord <[EMAIL PROTECTED]> Date: 2007-12-02 12:05 References : http://lkml.org/lkml/2007/12/2/86 http://bugzilla.kernel.org/show_bug.cgi?id=9492 Handled-By : Jiri Kosina <[EMAIL PROTECTED]> Dmitry Torokhov <[EMAIL PROTECTED]> Patch : Subject : kobject ->k_name memory leak Submitter : Alexey Dobriyan <[EMAIL PROTECTED]> Date: 2007-12-03 13:42 References : http://lkml.org/lkml/2007/12/3/20 http://bugzilla.kernel.org/show_bug.cgi?id=9496 Handled-By : Greg KH <[EMAIL PROTECTED]> Patch : Subject : 2.6.24-rc4 hwmon it87 probe fails Submitter : Mike Houston <[EMAIL PROTECTED]> Date: 2007-12-06 17:10 References : http://lkml.org/lkml/2007/12/4/466 http://bugzilla.kernel.org/show_bug.cgi?id=9514 Handled-By : Shaohua Li <[EMAIL PROTECTED]> Patch : Subject : soft lockup - CPU#1 stuck for 15s! [swapper:0] Submitter : "Parag Warudkar" <[EMAIL PROTECTED]> Date: 2007-12-07 18:14 References : http://lkml.org/lkml/2007/12/7/299 http://bugzilla.kernel.org/show_bug.cgi?id=9525 Handled-By : "Pallipadi, Venkatesh" <[EMAIL PROTECTED]> Thomas Gleixner <[EMAIL PROTECTED]> Ingo Molnar <[EMAIL PROTECTED]> Patch : Subject : BUG: bad unlock balance detected! Submitter : Krzysztof Oledzki <[EMAIL PROTECTED]> Date: 2007-12-11 03:17 References : http://bugzilla.kernel.org/show_bug.cgi?id=9542 Handled-By : Andrew Morton <[EMAIL PROTECTED]> Herbert Xu <[EMAIL PROTECTED]> Patch : Subject : PATA_HPT37X embezzles two ports Submitter : "Bjoern Olausson" <[EMAIL PROTECTED]> Date: 2007-12-12 11:05 References : http://lkml.org/lkml/2007/12/12/161 http://bugzilla.kernel.org/show_bug.cgi?id=9551 Handled-By : Patch : Subject : Could not set non-blocking flag with 2.6.24-rc5 Submitter : Tino Keitel <[EMAIL PROTECTED]> Date: 2007-12-13 16:27
2.6.24-rc5-git7: Reported regressions from 2.6.23
[Note: From December 22 to December 29 inclusive I will be traveling with (most probably) limited Internet access, so the next report will likely be posted after December 30. I also may be unresponsive next week. ;-)] This message contains a list of some regressions from 2.6.23 reported since 2.6.24-rc1 was released, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.23, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Listed regressions statistics - Date Total Pending Unresolved Today 118 21 13 2007-12-18 115 29 15 2007-12-12 106 31 17 2007-12-08 98 29 19 2007-12-01 85 29 18 2007-11-24 75 25 21 2007-11-19 68 26 21 2007-11-17 65 25 20 Unresolved regressions -- Subject : EHCI causes system to resume instantly from S4 Submitter : Maxim Levitsky [EMAIL PROTECTED] Date: 2007-10-28 14:56 References : http://lkml.org/lkml/2007/10/27/66 http://bugzilla.kernel.org/show_bug.cgi?id=9258 Handled-By : Rafael J. Wysocki [EMAIL PROTECTED] David Brownell [EMAIL PROTECTED] Alan Stern [EMAIL PROTECTED] Patch : Workaround : http://bugzilla.kernel.org/show_bug.cgi?id=9258#c30 Subject : v2.6.24-rc2-409-g9418d5d: attempt to access beyond end of device Submitter : Thomas Meyer [EMAIL PROTECTED] Date: 2007-11-13 13:11 References : http://lkml.org/lkml/2007/11/13/250 http://bugzilla.kernel.org/show_bug.cgi?id=9370 Handled-By : Matthew Wilcox [EMAIL PROTECTED] Patch : Subject : SError: { DevExch } occuring and causing disruption Submitter : Avuton Olrich [EMAIL PROTECTED] Date: 2007-11-15 22:39 References : http://bugzilla.kernel.org/show_bug.cgi?id=9393 Handled-By : Tejun Heo [EMAIL PROTECTED] Mark Lord [EMAIL PROTECTED] Patch : Subject : 2+ wake-ups/second in 2.6.24 Submitter : Mark Lord [EMAIL PROTECTED] Date: 2007-12-02 04:23 References : http://lkml.org/lkml/2007/12/1/141 http://bugzilla.kernel.org/show_bug.cgi?id=9489 Handled-By : Arjan van de Ven [EMAIL PROTECTED] Patch : Subject : 2.6.24: false double-clicks from USB mouse Submitter : Mark Lord [EMAIL PROTECTED] Date: 2007-12-02 12:05 References : http://lkml.org/lkml/2007/12/2/86 http://bugzilla.kernel.org/show_bug.cgi?id=9492 Handled-By : Jiri Kosina [EMAIL PROTECTED] Dmitry Torokhov [EMAIL PROTECTED] Patch : Subject : kobject -k_name memory leak Submitter : Alexey Dobriyan [EMAIL PROTECTED] Date: 2007-12-03 13:42 References : http://lkml.org/lkml/2007/12/3/20 http://bugzilla.kernel.org/show_bug.cgi?id=9496 Handled-By : Greg KH [EMAIL PROTECTED] Patch : Subject : 2.6.24-rc4 hwmon it87 probe fails Submitter : Mike Houston [EMAIL PROTECTED] Date: 2007-12-06 17:10 References : http://lkml.org/lkml/2007/12/4/466 http://bugzilla.kernel.org/show_bug.cgi?id=9514 Handled-By : Shaohua Li [EMAIL PROTECTED] Patch : Subject : soft lockup - CPU#1 stuck for 15s! [swapper:0] Submitter : Parag Warudkar [EMAIL PROTECTED] Date: 2007-12-07 18:14 References : http://lkml.org/lkml/2007/12/7/299 http://bugzilla.kernel.org/show_bug.cgi?id=9525 Handled-By : Pallipadi, Venkatesh [EMAIL PROTECTED] Thomas Gleixner [EMAIL PROTECTED] Ingo Molnar [EMAIL PROTECTED] Patch : Subject : BUG: bad unlock balance detected! Submitter : Krzysztof Oledzki [EMAIL PROTECTED] Date: 2007-12-11 03:17 References : http://bugzilla.kernel.org/show_bug.cgi?id=9542 Handled-By : Andrew Morton [EMAIL PROTECTED] Herbert Xu [EMAIL PROTECTED] Patch : Subject : PATA_HPT37X embezzles two ports Submitter : Bjoern Olausson [EMAIL PROTECTED] Date: 2007-12-12 11:05 References : http://lkml.org/lkml/2007/12/12/161 http://bugzilla.kernel.org/show_bug.cgi?id=9551 Handled-By : Patch : Subject : Could not set non-blocking flag with 2.6.24-rc5 Submitter : Tino Keitel [EMAIL PROTECTED] Date: 2007-12-13 16:27 References : http://lkml.org/lkml/2007/12/13/392