[PATCH] dmi_scan: proper buf type in dmi_present()
buf needs to be unsigned in dmi_present(), otherwise dmi_base calculation
doesn't work properly leading to a wraparound during dmi_ioremap:
[0.00] [ cut here ]
[0.00] WARNING: at arch/x86/mm/ioremap.c:524
__early_ioremap+0x85/0x18a()
[0.00] Modules linked in:
[0.00] Pid: 0, comm: swapper Not tainted 3.9.0-rc2-next-20130312 #283
[0.00] Call Trace:
[0.00] [] warn_slowpath_common+0x72/0xa0
[0.00] [] ? __early_ioremap+0x85/0x18a
[0.00] [] ? __early_ioremap+0x85/0x18a
[0.00] [] warn_slowpath_null+0x22/0x30
[0.00] [] __early_ioremap+0x85/0x18a
[0.00] [] ? __early_ioremap+0xfc/0x18a
[0.00] [] early_ioremap+0xd/0xf
[0.00] [] dmi_present+0xf5/0x22a
[0.00] [] dmi_scan_machine+0xbf/0x11c
[0.00] [] setup_arch+0x4db/0xca0
[0.00] [] ? printk+0x3d/0x3f
[0.00] [] start_kernel+0x7b/0x329
[0.00] [] i386_start_kernel+0x137/0x13a
[0.00] ---[ end trace 4eaa2a86a8e2da22 ]---
[0.00] DMI not present or invalid.
Introduced in "dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()"
Signed-off-by: Artem Savkov
---
drivers/firmware/dmi_scan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 3439f59..40e940d 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -410,7 +410,7 @@ static void __init dmi_dump_ids(void)
printk(KERN_CONT "\n");
}
-static int __init dmi_present(const char *buf)
+static int __init dmi_present(const u8 *buf)
{
int smbios_ver;
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dmi_scan: proper buf type in dmi_present()
buf needs to be unsigned in dmi_present(), otherwise dmi_base calculation
doesn't work properly leading to a wraparound during dmi_ioremap:
[0.00] [ cut here ]
[0.00] WARNING: at arch/x86/mm/ioremap.c:524
__early_ioremap+0x85/0x18a()
[0.00] Modules linked in:
[0.00] Pid: 0, comm: swapper Not tainted 3.9.0-rc2-next-20130312 #283
[0.00] Call Trace:
[0.00] [c1036992] warn_slowpath_common+0x72/0xa0
[0.00] [c19cc176] ? __early_ioremap+0x85/0x18a
[0.00] [c19cc176] ? __early_ioremap+0x85/0x18a
[0.00] [c10369e2] warn_slowpath_null+0x22/0x30
[0.00] [c19cc176] __early_ioremap+0x85/0x18a
[0.00] [c19cc1ed] ? __early_ioremap+0xfc/0x18a
[0.00] [c19cc412] early_ioremap+0xd/0xf
[0.00] [c19fbba9] dmi_present+0xf5/0x22a
[0.00] [c19fbd9d] dmi_scan_machine+0xbf/0x11c
[0.00] [c19bd781] setup_arch+0x4db/0xca0
[0.00] [c168105c] ? printk+0x3d/0x3f
[0.00] [c19ba763] start_kernel+0x7b/0x329
[0.00] [c19ba361] i386_start_kernel+0x137/0x13a
[0.00] ---[ end trace 4eaa2a86a8e2da22 ]---
[0.00] DMI not present or invalid.
Introduced in dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()
Signed-off-by: Artem Savkov artem.sav...@gmail.com
---
drivers/firmware/dmi_scan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 3439f59..40e940d 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -410,7 +410,7 @@ static void __init dmi_dump_ids(void)
printk(KERN_CONT \n);
}
-static int __init dmi_present(const char *buf)
+static int __init dmi_present(const u8 *buf)
{
int smbios_ver;
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thinkpad-acpi: fix potential suspend blocking issue
On Wed, Mar 06, 2013 at 04:50:39PM +0100, Oleg Nesterov wrote: > On 03/05, Andrew Morton wrote: > > > > Basically the same as > > http://ozlabs.org/~akpm/mmots/broken-out/drivers-platform-x86-thinkpad_acpic-move-hotkey_thread_mutex-lock-after-set_freezable.patch. > > I think Artem's patch is a little better. There doesn't appear to be > > any locking protocol for tpacpi_lifecycle. > > Which seems to have the same problem, hotkey_kthread() still calls > kthread_freezable_should_stop() under hotkey_thread_mutex. > > IOW, we have two try_to_freeze's here, the patch moves only one of > them outside of the hotkey_thread_mutex. It's hard for me to judge but this lock does indeed look like it has been used to block until the thread exits. I'm trying out the "remove hotkey_thread_mutex completely" approach and everything looks fine so far. -- Regards, Artem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thinkpad-acpi: fix potential suspend blocking issue
On Wed, Mar 06, 2013 at 04:50:39PM +0100, Oleg Nesterov wrote: On 03/05, Andrew Morton wrote: Basically the same as http://ozlabs.org/~akpm/mmots/broken-out/drivers-platform-x86-thinkpad_acpic-move-hotkey_thread_mutex-lock-after-set_freezable.patch. I think Artem's patch is a little better. There doesn't appear to be any locking protocol for tpacpi_lifecycle. Which seems to have the same problem, hotkey_kthread() still calls kthread_freezable_should_stop() under hotkey_thread_mutex. IOW, we have two try_to_freeze's here, the patch moves only one of them outside of the hotkey_thread_mutex. It's hard for me to judge but this lock does indeed look like it has been used to block until the thread exits. I'm trying out the remove hotkey_thread_mutex completely approach and everything looks fine so far. -- Regards, Artem -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thinkpad_acpi: moved hotkey_thread_mutex lock after set_freezable()
On Mon, Feb 25, 2013 at 03:54:45PM -0800, Andrew Morton wrote: > On Sun, 24 Feb 2013 13:22:02 +0400 > Artem Savkov wrote: > > > set_freezable() checks freezing during which no locks should be held. > > hotkey_thread_mutex lock should be moved closer to where it is actually > > needed. > > > > Thanks. > > When fixing a bug, we always like to see a full description of that bug > so we can better work out which kernel versions need the fix. Sorry, will do thah in future. > Did you actually hit a lockup because of this? Or was it just from > code inspection? Or ... ? I didn't hit an actual lockup, but I did hit a warning during boot. The warning was added by "lockdep: check that no locks held at freeze time" patch (2f2ff7b8979c50491b3cbce622d7bea4d44a8682 in linux-next.git) -- Kind regards, Artem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thinkpad_acpi: moved hotkey_thread_mutex lock after set_freezable()
On Mon, Feb 25, 2013 at 03:54:45PM -0800, Andrew Morton wrote: On Sun, 24 Feb 2013 13:22:02 +0400 Artem Savkov artem.sav...@gmail.com wrote: set_freezable() checks freezing during which no locks should be held. hotkey_thread_mutex lock should be moved closer to where it is actually needed. Thanks. When fixing a bug, we always like to see a full description of that bug so we can better work out which kernel versions need the fix. Sorry, will do thah in future. Did you actually hit a lockup because of this? Or was it just from code inspection? Or ... ? I didn't hit an actual lockup, but I did hit a warning during boot. The warning was added by lockdep: check that no locks held at freeze time patch (2f2ff7b8979c50491b3cbce622d7bea4d44a8682 in linux-next.git) -- Kind regards, Artem -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad_acpi: moved hotkey_thread_mutex lock after set_freezable()
set_freezable() checks freezing during which no locks should be held. hotkey_thread_mutex lock should be moved closer to where it is actually needed. Signed-off-by: Artem Savkov --- drivers/platform/x86/thinkpad_acpi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index 22d8936..ffed96cd 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -2463,13 +2463,13 @@ static int hotkey_kthread(void *data) unsigned int poll_freq; bool was_frozen; - mutex_lock(_thread_mutex); - if (tpacpi_lifecycle == TPACPI_LIFE_EXITING) goto exit; set_freezable(); + mutex_lock(_thread_mutex); + so = 0; si = 1; t = 0; @@ -2523,8 +2523,8 @@ static int hotkey_kthread(void *data) si ^= 1; } -exit: mutex_unlock(_thread_mutex); +exit: return 0; } -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad_acpi: moved hotkey_thread_mutex lock after set_freezable()
set_freezable() checks freezing during which no locks should be held. hotkey_thread_mutex lock should be moved closer to where it is actually needed. Signed-off-by: Artem Savkov artem.sav...@gmail.com --- drivers/platform/x86/thinkpad_acpi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index 22d8936..ffed96cd 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -2463,13 +2463,13 @@ static int hotkey_kthread(void *data) unsigned int poll_freq; bool was_frozen; - mutex_lock(hotkey_thread_mutex); - if (tpacpi_lifecycle == TPACPI_LIFE_EXITING) goto exit; set_freezable(); + mutex_lock(hotkey_thread_mutex); + so = 0; si = 1; t = 0; @@ -2523,8 +2523,8 @@ static int hotkey_kthread(void *data) si ^= 1; } -exit: mutex_unlock(hotkey_thread_mutex); +exit: return 0; } -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: 64bit divide in intel_pstate_calc_busy()
intel_pstate.c won't compile on i686 because of a linking error: drivers/cpufreq/intel_pstate.c:459: undefined reference to `__udivdi3' Signed-off-by: Artem Savkov --- drivers/cpufreq/intel_pstate.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 86ad482..dc43208 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -456,7 +456,9 @@ static inline void intel_pstate_calc_busy(struct cpudata *cpu, core_pct = div64_u64(sample->aperf * 100, sample->mperf); sample->freq = cpu->pstate.turbo_pstate * core_pct * 1000; - sample->core_pct_busy = sample->pstate_pct_busy * core_pct / 100; + sample->core_pct_busy = div64_u64( + sample->pstate_pct_busy * core_pct, + 100); } static inline void intel_pstate_sample(struct cpudata *cpu) -- 1.8.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: 64bit divide in intel_pstate_calc_busy()
intel_pstate.c won't compile on i686 because of a linking error: drivers/cpufreq/intel_pstate.c:459: undefined reference to `__udivdi3' Signed-off-by: Artem Savkov artem.sav...@gmail.com --- drivers/cpufreq/intel_pstate.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 86ad482..dc43208 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -456,7 +456,9 @@ static inline void intel_pstate_calc_busy(struct cpudata *cpu, core_pct = div64_u64(sample-aperf * 100, sample-mperf); sample-freq = cpu-pstate.turbo_pstate * core_pct * 1000; - sample-core_pct_busy = sample-pstate_pct_busy * core_pct / 100; + sample-core_pct_busy = div64_u64( + sample-pstate_pct_busy * core_pct, + 100); } static inline void intel_pstate_sample(struct cpudata *cpu) -- 1.8.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm: missing idr_preload_end in drm_gem_flink_ioctl
Added missing idr_preload_end calls in drm_gem_flink_ioctl().
Without those preemption stays disabled resulting in lots of "scheduling while
atomic" BUGs.
Introduced in 4e486fae707d9a79c76f1be6dcacffc4a721cc1b (linux-next.git)
Signed-off-by: Artem Savkov
---
drivers/gpu/drm/drm_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 6577514..f1700ef 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -456,6 +456,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
obj->name = ret;
args->name = (uint64_t) obj->name;
spin_unlock(>object_name_lock);
+ idr_preload_end();
if (ret < 0)
goto err;
@@ -465,6 +466,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
} else {
args->name = (uint64_t) obj->name;
spin_unlock(>object_name_lock);
+ idr_preload_end();
ret = 0;
}
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm: missing idr_preload_end in drm_gem_flink_ioctl
Added missing idr_preload_end calls in drm_gem_flink_ioctl().
Without those preemption stays disabled resulting in lots of scheduling while
atomic BUGs.
Introduced in 4e486fae707d9a79c76f1be6dcacffc4a721cc1b (linux-next.git)
Signed-off-by: Artem Savkov artem.sav...@gmail.com
---
drivers/gpu/drm/drm_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 6577514..f1700ef 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -456,6 +456,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
obj-name = ret;
args-name = (uint64_t) obj-name;
spin_unlock(dev-object_name_lock);
+ idr_preload_end();
if (ret 0)
goto err;
@@ -465,6 +466,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
} else {
args-name = (uint64_t) obj-name;
spin_unlock(dev-object_name_lock);
+ idr_preload_end();
ret = 0;
}
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] CPUFreq Fixes for 3.9
On Fri, Feb 08, 2013 at 10:39:13AM +0530, Viresh Kumar wrote:
> On 8 February 2013 04:37, Rafael J. Wysocki wrote:
> > BTW, there still are locking problems in linux-next. Why do we need
> > to take cpufreq_driver_lock() around driver->init() in cpufreq_add_dev(),
> > in particular?
> I thought a bit more and realized there is no such limitation on
> cpufreq_driver->ops about calling routines which can sleep. And thus
> we shoudln't
> have locks around any of these. I have got a patch for it, that i
> would fold-back into
> the original patch that introduced locking fixes (attached too for testing):
Tested this patch on top of linux-pm.git/bleeding-edge
Now everything seems to be alright.
> From: Viresh Kumar
> Date: Fri, 8 Feb 2013 10:35:31 +0530
> Subject: [PATCH] cpufreq: Remove unnecessary locking
>
> I have placed some locks intentionally around calls to driver->ops
> (init/exit),
> which look to be wrong as these calls can call routines that potentially
> sleep.
>
> Lets remove these locks.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/cpufreq.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 5d8a422..04aab05 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -795,10 +795,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
>
> if (ret) {
> pr_debug("setting policy failed\n");
> - spin_lock_irqsave(_driver_lock, flags);
> if (driver->exit)
> driver->exit(policy);
> - spin_unlock_irqrestore(_driver_lock, flags);
> }
> return ret;
>
> @@ -920,17 +918,14 @@ static int cpufreq_add_dev(struct device *dev,
> struct subsys_interface *sif)
> init_completion(>kobj_unregister);
> INIT_WORK(>update, handle_update);
>
> - spin_lock_irqsave(_driver_lock, flags);
> /* call driver. From then on the cpufreq must be able
>* to accept all calls to ->verify and ->setpolicy for this CPU
>*/
> ret = driver->init(policy);
> if (ret) {
> pr_debug("initialization failed\n");
> - spin_unlock_irqrestore(_driver_lock, flags);
> goto err_set_policy_cpu;
> }
> - spin_unlock_irqrestore(_driver_lock, flags);
>
> /* related cpus should atleast have policy->cpus */
> cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
> @@ -1100,10 +1095,8 @@ static int __cpufreq_remove_dev(struct device
> *dev, struct subsys_interface *sif
> wait_for_completion(cmp);
> pr_debug("wait complete\n");
>
> - spin_lock_irqsave(_driver_lock, flags);
> if (driver->exit)
> driver->exit(data);
> - spin_unlock_irqrestore(_driver_lock, flags);
>
> free_cpumask_var(data->related_cpus);
> free_cpumask_var(data->cpus);
Tested-by: Artem Savkov
--
Kind regards,
Artem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] CPUFreq Fixes for 3.9
On Thu, Feb 07, 2013 at 03:57:42PM +0530, Viresh Kumar wrote:
> Hi Rafael,
>
> This is another unplanned patchset for all the platforms that i broke. :)
>
> Okay, there are two important fixes (1 & 4) and two general cleanups (2 & 3).
> I
> hope most of the issues would be resolved by these and we would be able to
> push
> clean cpufreq core into 3.9.
>
> I have pushed them in my for-rafael branch at:
>
> http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/for-rafael
>
> @Artem & Valdis: Please test them and reply with your Tested-by's (in case
> they
> work :) ).
>
> Viresh Kumar (4):
> cpufreq: governors: Fix WARN_ON() for multi-policy platforms
> cpufreq: Remove unused HOTPLUG_CPU code
> cpufreq: Create a macro for unlock_policy_rwsem{read,write}
> cpufreq: Fix locking issues
>
> drivers/cpufreq/cpufreq.c | 126
> ++---
> drivers/cpufreq/cpufreq_governor.c | 32 ++
> 2 files changed, 79 insertions(+), 79 deletions(-)
Tested out linux-pm.git/linux-next with this patches pulled. It seems
that my systemd-sleep issue is fixed, however there is a new 'sleeping
in invalid context' bug during boot:
[ 12.736484] BUG: sleeping function called from invalid context at
mm/slub.c:925
[ 12.739727] in_atomic(): 1, irqs_disabled(): 1, pid: 1799, name:
systemd-modules
[ 12.742961] 2 locks held by systemd-modules/1799:
[ 12.746153] #0: (subsys mutex#3){..}, at: []
subsys_interface_register+0x36/0xb0
[ 12.749499] #1: (cpufreq_driver_lock){..}, at: []
cpufreq_add_dev+0x22b/0x3d0
[ 12.752865] Pid: 1799, comm: systemd-modules Not tainted 3.8.0-rc6+ #1
[ 12.756175] Call Trace:
[ 12.759538] [] __might_sleep+0xe0/0x100
[ 12.762156] [] kmem_cache_alloc_trace+0xb1/0x150
[ 12.765432] [] ? acpi_cpufreq_cpu_init+0x73/0x5c0 [acpi_cpufreq]
[ 12.768780] [] acpi_cpufreq_cpu_init+0x73/0x5c0 [acpi_cpufreq]
[ 12.772161] [] ? cpufreq_add_dev+0x22b/0x3d0
[ 12.775549] [] ? _raw_spin_lock_irqsave+0x77/0x90
[ 12.778932] [] ? cpufreq_add_dev+0x22b/0x3d0
[ 12.782307] [] cpufreq_add_dev+0x238/0x3d0
[ 12.785652] [] subsys_interface_register+0x75/0xb0
[ 12.788989] [] ? do_drv_write+0x80/0x80 [acpi_cpufreq]
[ 12.792325] [] cpufreq_register_driver+0x7b/0x150
[ 12.795657] [] ? 0xf8074fff
[ 12.798971] [] acpi_cpufreq_init+0xae/0x1b3 [acpi_cpufreq]
[ 12.802346] [] do_one_initcall+0x112/0x160
[ 12.805723] [] ? __blocking_notifier_call_chain+0x4a/0x80
[ 12.809123] [] load_module+0xd7e/0x1460
[ 12.812515] [] ? error_code+0x5a/0x60
[ 12.815891] [] sys_init_module+0x78/0xb0
[ 12.819249] [] sysenter_do_call+0x12/0x2d
[ 12.822924] [ cut here ]
[ 12.826275] WARNING: at kernel/smp.c:327
smp_call_function_single+0x104/0x130()
[ 12.829668] Hardware name: 0578A21
[ 12.833020] Modules linked in: acpi_cpufreq(+) mperf thinkpad_acpi
[ 12.836456] Pid: 1799, comm: systemd-modules Not tainted 3.8.0-rc6+ #1
[ 12.839891] Call Trace:
[ 12.843268] [] warn_slowpath_common+0x72/0xa0
[ 12.846617] [] ? smp_call_function_single+0x104/0x130
[ 12.849921] [] ? smp_call_function_single+0x104/0x130
[ 12.853149] [] ? acpi_cpufreq_target+0x280/0x280 [acpi_cpufreq]
[ 12.856361] [] warn_slowpath_null+0x22/0x30
[ 12.859518] [] smp_call_function_single+0x104/0x130
[ 12.862691] [] smp_call_function_any+0x44/0xb0
[ 12.865788] [] ? acpi_cpufreq_target+0x280/0x280 [acpi_cpufreq]
[ 12.868893] [] get_cur_val+0x7e/0x100 [acpi_cpufreq]
[ 12.871957] [] get_cur_freq_on_cpu+0x4b/0x70 [acpi_cpufreq]
[ 12.874987] [] acpi_cpufreq_cpu_init+0x3d8/0x5c0 [acpi_cpufreq]
[ 12.877998] [] ? cpufreq_add_dev+0x22b/0x3d0
[ 12.880982] [] cpufreq_add_dev+0x238/0x3d0
[ 12.883931] [] subsys_interface_register+0x75/0xb0
[ 12.886840] [] ? do_drv_write+0x80/0x80 [acpi_cpufreq]
[ 12.889717] [] cpufreq_register_driver+0x7b/0x150
[ 12.892550] [] ? 0xf8074fff
[ 12.895339] [] acpi_cpufreq_init+0xae/0x1b3 [acpi_cpufreq]
[ 12.898169] [] do_one_initcall+0x112/0x160
[ 12.900988] [] ? __blocking_notifier_call_chain+0x4a/0x80
[ 12.903820] [] load_module+0xd7e/0x1460
[ 12.906631] [] ? error_code+0x5a/0x60
[ 12.909418] [] sys_init_module+0x78/0xb0
[ 12.912193] [] sysenter_do_call+0x12/0x2d
[ 12.914956] ---[ end trace e15032846f0195a0 ]---
--
Kind regards,
Artem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] CPUFreq Fixes for 3.9
On Thu, Feb 07, 2013 at 03:57:42PM +0530, Viresh Kumar wrote:
Hi Rafael,
This is another unplanned patchset for all the platforms that i broke. :)
Okay, there are two important fixes (1 4) and two general cleanups (2 3).
I
hope most of the issues would be resolved by these and we would be able to
push
clean cpufreq core into 3.9.
I have pushed them in my for-rafael branch at:
http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/for-rafael
@Artem Valdis: Please test them and reply with your Tested-by's (in case
they
work :) ).
Viresh Kumar (4):
cpufreq: governors: Fix WARN_ON() for multi-policy platforms
cpufreq: Remove unused HOTPLUG_CPU code
cpufreq: Create a macro for unlock_policy_rwsem{read,write}
cpufreq: Fix locking issues
drivers/cpufreq/cpufreq.c | 126
++---
drivers/cpufreq/cpufreq_governor.c | 32 ++
2 files changed, 79 insertions(+), 79 deletions(-)
Tested out linux-pm.git/linux-next with this patches pulled. It seems
that my systemd-sleep issue is fixed, however there is a new 'sleeping
in invalid context' bug during boot:
[ 12.736484] BUG: sleeping function called from invalid context at
mm/slub.c:925
[ 12.739727] in_atomic(): 1, irqs_disabled(): 1, pid: 1799, name:
systemd-modules
[ 12.742961] 2 locks held by systemd-modules/1799:
[ 12.746153] #0: (subsys mutex#3){..}, at: [c13f4056]
subsys_interface_register+0x36/0xb0
[ 12.749499] #1: (cpufreq_driver_lock){..}, at: [c14ba53b]
cpufreq_add_dev+0x22b/0x3d0
[ 12.752865] Pid: 1799, comm: systemd-modules Not tainted 3.8.0-rc6+ #1
[ 12.756175] Call Trace:
[ 12.759538] [c1068150] __might_sleep+0xe0/0x100
[ 12.762156] [c112a481] kmem_cache_alloc_trace+0xb1/0x150
[ 12.765432] [f804e653] ? acpi_cpufreq_cpu_init+0x73/0x5c0 [acpi_cpufreq]
[ 12.768780] [f804e653] acpi_cpufreq_cpu_init+0x73/0x5c0 [acpi_cpufreq]
[ 12.772161] [c14ba53b] ? cpufreq_add_dev+0x22b/0x3d0
[ 12.775549] [c1695af7] ? _raw_spin_lock_irqsave+0x77/0x90
[ 12.778932] [c14ba53b] ? cpufreq_add_dev+0x22b/0x3d0
[ 12.782307] [c14ba548] cpufreq_add_dev+0x238/0x3d0
[ 12.785652] [c13f4095] subsys_interface_register+0x75/0xb0
[ 12.788989] [f804ec20] ? do_drv_write+0x80/0x80 [acpi_cpufreq]
[ 12.792325] [c14b986b] cpufreq_register_driver+0x7b/0x150
[ 12.795657] [f8075000] ? 0xf8074fff
[ 12.798971] [f80750ae] acpi_cpufreq_init+0xae/0x1b3 [acpi_cpufreq]
[ 12.802346] [c1001222] do_one_initcall+0x112/0x160
[ 12.805723] [c106145a] ? __blocking_notifier_call_chain+0x4a/0x80
[ 12.809123] [c10a048e] load_module+0xd7e/0x1460
[ 12.812515] [c1696d82] ? error_code+0x5a/0x60
[ 12.815891] [c10a0be8] sys_init_module+0x78/0xb0
[ 12.819249] [c169d67a] sysenter_do_call+0x12/0x2d
[ 12.822924] [ cut here ]
[ 12.826275] WARNING: at kernel/smp.c:327
smp_call_function_single+0x104/0x130()
[ 12.829668] Hardware name: 0578A21
[ 12.833020] Modules linked in: acpi_cpufreq(+) mperf thinkpad_acpi
[ 12.836456] Pid: 1799, comm: systemd-modules Not tainted 3.8.0-rc6+ #1
[ 12.839891] Call Trace:
[ 12.843268] [c1036a82] warn_slowpath_common+0x72/0xa0
[ 12.846617] [c109b154] ? smp_call_function_single+0x104/0x130
[ 12.849921] [c109b154] ? smp_call_function_single+0x104/0x130
[ 12.853149] [f804eea0] ? acpi_cpufreq_target+0x280/0x280 [acpi_cpufreq]
[ 12.856361] [c1036ad2] warn_slowpath_null+0x22/0x30
[ 12.859518] [c109b154] smp_call_function_single+0x104/0x130
[ 12.862691] [c109b5b4] smp_call_function_any+0x44/0xb0
[ 12.865788] [f804eea0] ? acpi_cpufreq_target+0x280/0x280 [acpi_cpufreq]
[ 12.868893] [f804e13e] get_cur_val+0x7e/0x100 [acpi_cpufreq]
[ 12.871957] [f804e5bb] get_cur_freq_on_cpu+0x4b/0x70 [acpi_cpufreq]
[ 12.874987] [f804e9b8] acpi_cpufreq_cpu_init+0x3d8/0x5c0 [acpi_cpufreq]
[ 12.877998] [c14ba53b] ? cpufreq_add_dev+0x22b/0x3d0
[ 12.880982] [c14ba548] cpufreq_add_dev+0x238/0x3d0
[ 12.883931] [c13f4095] subsys_interface_register+0x75/0xb0
[ 12.886840] [f804ec20] ? do_drv_write+0x80/0x80 [acpi_cpufreq]
[ 12.889717] [c14b986b] cpufreq_register_driver+0x7b/0x150
[ 12.892550] [f8075000] ? 0xf8074fff
[ 12.895339] [f80750ae] acpi_cpufreq_init+0xae/0x1b3 [acpi_cpufreq]
[ 12.898169] [c1001222] do_one_initcall+0x112/0x160
[ 12.900988] [c106145a] ? __blocking_notifier_call_chain+0x4a/0x80
[ 12.903820] [c10a048e] load_module+0xd7e/0x1460
[ 12.906631] [c1696d82] ? error_code+0x5a/0x60
[ 12.909418] [c10a0be8] sys_init_module+0x78/0xb0
[ 12.912193] [c169d67a] sysenter_do_call+0x12/0x2d
[ 12.914956] ---[ end trace e15032846f0195a0 ]---
--
Kind regards,
Artem
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] CPUFreq Fixes for 3.9
On Fri, Feb 08, 2013 at 10:39:13AM +0530, Viresh Kumar wrote:
On 8 February 2013 04:37, Rafael J. Wysocki r...@sisk.pl wrote:
BTW, there still are locking problems in linux-next. Why do we need
to take cpufreq_driver_lock() around driver-init() in cpufreq_add_dev(),
in particular?
I thought a bit more and realized there is no such limitation on
cpufreq_driver-ops about calling routines which can sleep. And thus
we shoudln't
have locks around any of these. I have got a patch for it, that i
would fold-back into
the original patch that introduced locking fixes (attached too for testing):
Tested this patch on top of linux-pm.git/bleeding-edge
Now everything seems to be alright.
From: Viresh Kumar viresh.ku...@linaro.org
Date: Fri, 8 Feb 2013 10:35:31 +0530
Subject: [PATCH] cpufreq: Remove unnecessary locking
I have placed some locks intentionally around calls to driver-ops
(init/exit),
which look to be wrong as these calls can call routines that potentially
sleep.
Lets remove these locks.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5d8a422..04aab05 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -795,10 +795,8 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
if (ret) {
pr_debug(setting policy failed\n);
- spin_lock_irqsave(cpufreq_driver_lock, flags);
if (driver-exit)
driver-exit(policy);
- spin_unlock_irqrestore(cpufreq_driver_lock, flags);
}
return ret;
@@ -920,17 +918,14 @@ static int cpufreq_add_dev(struct device *dev,
struct subsys_interface *sif)
init_completion(policy-kobj_unregister);
INIT_WORK(policy-update, handle_update);
- spin_lock_irqsave(cpufreq_driver_lock, flags);
/* call driver. From then on the cpufreq must be able
* to accept all calls to -verify and -setpolicy for this CPU
*/
ret = driver-init(policy);
if (ret) {
pr_debug(initialization failed\n);
- spin_unlock_irqrestore(cpufreq_driver_lock, flags);
goto err_set_policy_cpu;
}
- spin_unlock_irqrestore(cpufreq_driver_lock, flags);
/* related cpus should atleast have policy-cpus */
cpumask_or(policy-related_cpus, policy-related_cpus, policy-cpus);
@@ -1100,10 +1095,8 @@ static int __cpufreq_remove_dev(struct device
*dev, struct subsys_interface *sif
wait_for_completion(cmp);
pr_debug(wait complete\n);
- spin_lock_irqsave(cpufreq_driver_lock, flags);
if (driver-exit)
driver-exit(data);
- spin_unlock_irqrestore(cpufreq_driver_lock, flags);
free_cpumask_var(data-related_cpus);
free_cpumask_var(data-cpus);
Tested-by: Artem Savkov artem.sav...@gmail.com
--
Kind regards,
Artem
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] cpufreq: sleeping function called from invalid context at kernel/workqueue.c:2811
On Thu, Feb 07, 2013 at 01:41:57AM +0100, Rafael J. Wysocki wrote: > On Wednesday, February 06, 2013 10:11:25 PM Rafael J. Wysocki wrote: > > On Thursday, February 07, 2013 12:25:13 AM Artem Savkov wrote: > > > I get the following BUG on suspend using systemd-sleep(this doesn't > > > happen with pm-suspend). This seems to be introduced by some of the > > > Viresh's patches. > > > > Which branch from which day? The log is from linux-next-20130205, still reproducible on -20130206 > OK, I've reproduced it and the appended patch fixes it for me. Can you please > try it and report back? I've tried the patch and the bug is still reproducible. I might be wrong but it seems that the bug happens on first __cpufreq_remove_dev call(CPU1) on __cpufreq_governor(data, CPUFREQ_GOV_STOP) call (line ~1050) but changes in your patch are all below that call. -- Kind regards, Artem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] cpufreq: sleeping function called from invalid context at kernel/workqueue.c:2811
I get the following BUG on suspend using systemd-sleep(this doesn't
happen with pm-suspend). This seems to be introduced by some of the
Viresh's patches.
[ 94.908046] Disabling non-boot CPUs ...
[ 94.908416] BUG: sleeping function called from invalid context at
kernel/workqueue.c:2811
[ 94.908419] in_atomic(): 1, irqs_disabled(): 1, pid: 4038, name:
systemd-sleep
[ 94.908421] 7 locks held by systemd-sleep/4038:
[ 94.908439] #0: (>mutex){..}, at: []
sysfs_write_file+0x29/0x100
[ 94.908448] #1: (s_active#179){..}, at: []
sysfs_write_file+0x8d/0x100
[ 94.908459] #2: (pm_mutex){..}, at: [] pm_suspend+0x40/0x1e0
[ 94.908469] #3: (cpu_add_remove_lock){..}, at: []
cpu_maps_update_begin+0x14/0x20
[ 94.908476] #4: (cpu_hotplug.lock){..}, at: []
cpu_hotplug_begin+0x22/0x50
[ 94.908487] #5: (_cpu(cpu_policy_rwsem, cpu)){..}, at:
[] lock_policy_rwsem_write+0x3d/0x70
[ 94.908495] #6: (cpufreq_driver_lock){..}, at: []
__cpufreq_remove_dev.isra.10+0x26/0x270
[ 94.908500] Pid: 4038, comm: systemd-sleep Not tainted
3.8.0-rc6-next-20130205+ #200
[ 94.908501] Call Trace:
[ 94.908511] [] __might_sleep+0xe0/0x100
[ 94.908518] [] flush_work+0x5f/0x230
[ 94.908523] [] ? insert_work+0x50/0x50
[ 94.908528] [] ? del_timer+0x47/0x70
[ 94.908533] [] ? del_timer+0x47/0x70
[ 94.908538] [] ? try_to_grab_pending+0xa8/0x120
[ 94.908543] [] __cancel_work_timer+0x59/0x80
[ 94.908548] [] cancel_delayed_work_sync+0x12/0x20
[ 94.908555] [] cpufreq_governor_dbs+0x2cd/0x490
[ 94.908561] [] od_cpufreq_governor_dbs+0x16/0x20
[ 94.908565] [] __cpufreq_governor+0x41/0x100
[ 94.908570] [] ? __cpufreq_remove_dev.isra.10+0x26/0x270
[ 94.908575] [] __cpufreq_remove_dev.isra.10+0x56/0x270
[ 94.908580] [] ? lock_policy_rwsem_write+0x3d/0x70
[ 94.908589] [] cpufreq_cpu_callback+0x50/0x65
[ 94.908596] [] notifier_call_chain+0x47/0x90
[ 94.908606] [] __raw_notifier_call_chain+0x1e/0x30
[ 94.908610] [] __cpu_notify+0x24/0x50
[ 94.908615] [] _cpu_down+0x6d/0x250
[ 94.908621] [] disable_nonboot_cpus+0x6c/0xf0
[ 94.908625] [] suspend_devices_and_enter+0x175/0x2b0
[ 94.908629] [] pm_suspend+0x1d7/0x1e0
[ 94.908633] [] state_store+0x5d/0xb0
[ 94.908638] [] ? pm_trace_dev_match_show+0x20/0x20
[ 94.908644] [] kobj_attr_store+0x1b/0x30
[ 94.908650] [] sysfs_write_file+0xa3/0x100
[ 94.908655] [] ? sysfs_open_file+0x1f0/0x1f0
[ 94.908662] [] vfs_write+0x88/0x140
[ 94.908667] [] ? sysfs_open_file+0x1f0/0x1f0
[ 94.908672] [] sys_write+0x47/0x90
[ 94.908679] [] sysenter_do_call+0x12/0x2d
[ 94.911067] smpboot: CPU 1 is now offline
[ 94.915585] smpboot: CPU 2 is now offline
[ 94.917500] smpboot: CPU 3 is now offline
--
Kind regards,
Artem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[BUG] cpufreq: sleeping function called from invalid context at kernel/workqueue.c:2811
I get the following BUG on suspend using systemd-sleep(this doesn't
happen with pm-suspend). This seems to be introduced by some of the
Viresh's patches.
[ 94.908046] Disabling non-boot CPUs ...
[ 94.908416] BUG: sleeping function called from invalid context at
kernel/workqueue.c:2811
[ 94.908419] in_atomic(): 1, irqs_disabled(): 1, pid: 4038, name:
systemd-sleep
[ 94.908421] 7 locks held by systemd-sleep/4038:
[ 94.908439] #0: (buffer-mutex){..}, at: [c11908e9]
sysfs_write_file+0x29/0x100
[ 94.908448] #1: (s_active#179){..}, at: [c119094d]
sysfs_write_file+0x8d/0x100
[ 94.908459] #2: (pm_mutex){..}, at: [c107f990] pm_suspend+0x40/0x1e0
[ 94.908469] #3: (cpu_add_remove_lock){..}, at: [c103ab04]
cpu_maps_update_begin+0x14/0x20
[ 94.908476] #4: (cpu_hotplug.lock){..}, at: [c103a9e2]
cpu_hotplug_begin+0x22/0x50
[ 94.908487] #5: (per_cpu(cpu_policy_rwsem, cpu)){..}, at:
[c14bfbfd] lock_policy_rwsem_write+0x3d/0x70
[ 94.908495] #6: (cpufreq_driver_lock){..}, at: [c14bfe06]
__cpufreq_remove_dev.isra.10+0x26/0x270
[ 94.908500] Pid: 4038, comm: systemd-sleep Not tainted
3.8.0-rc6-next-20130205+ #200
[ 94.908501] Call Trace:
[ 94.908511] [c1067ce0] __might_sleep+0xe0/0x100
[ 94.908518] [c1050f3f] flush_work+0x5f/0x230
[ 94.908523] [c1050ee0] ? insert_work+0x50/0x50
[ 94.908528] [c1046277] ? del_timer+0x47/0x70
[ 94.908533] [c1046277] ? del_timer+0x47/0x70
[ 94.908538] [c1052b08] ? try_to_grab_pending+0xa8/0x120
[ 94.908543] [c1053b49] __cancel_work_timer+0x59/0x80
[ 94.908548] [c1053b82] cancel_delayed_work_sync+0x12/0x20
[ 94.908555] [c14c32ed] cpufreq_governor_dbs+0x2cd/0x490
[ 94.908561] [c14c26c6] od_cpufreq_governor_dbs+0x16/0x20
[ 94.908565] [c14bfd21] __cpufreq_governor+0x41/0x100
[ 94.908570] [c14bfe06] ? __cpufreq_remove_dev.isra.10+0x26/0x270
[ 94.908575] [c14bfe36] __cpufreq_remove_dev.isra.10+0x56/0x270
[ 94.908580] [c14bfbfd] ? lock_policy_rwsem_write+0x3d/0x70
[ 94.908589] [c1686c20] cpufreq_cpu_callback+0x50/0x65
[ 94.908596] [c16966c7] notifier_call_chain+0x47/0x90
[ 94.908606] [c1060fee] __raw_notifier_call_chain+0x1e/0x30
[ 94.908610] [c103a974] __cpu_notify+0x24/0x50
[ 94.908615] [c167bf7d] _cpu_down+0x6d/0x250
[ 94.908621] [c103ac7c] disable_nonboot_cpus+0x6c/0xf0
[ 94.908625] [c107f815] suspend_devices_and_enter+0x175/0x2b0
[ 94.908629] [c107fb27] pm_suspend+0x1d7/0x1e0
[ 94.908633] [c107ebed] state_store+0x5d/0xb0
[ 94.908638] [c107eb90] ? pm_trace_dev_match_show+0x20/0x20
[ 94.908644] [c12c074b] kobj_attr_store+0x1b/0x30
[ 94.908650] [c1190963] sysfs_write_file+0xa3/0x100
[ 94.908655] [c11908c0] ? sysfs_open_file+0x1f0/0x1f0
[ 94.908662] [c112dc28] vfs_write+0x88/0x140
[ 94.908667] [c11908c0] ? sysfs_open_file+0x1f0/0x1f0
[ 94.908672] [c112def7] sys_write+0x47/0x90
[ 94.908679] [c169a0fa] sysenter_do_call+0x12/0x2d
[ 94.911067] smpboot: CPU 1 is now offline
[ 94.915585] smpboot: CPU 2 is now offline
[ 94.917500] smpboot: CPU 3 is now offline
--
Kind regards,
Artem
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] cpufreq: sleeping function called from invalid context at kernel/workqueue.c:2811
On Thu, Feb 07, 2013 at 01:41:57AM +0100, Rafael J. Wysocki wrote: On Wednesday, February 06, 2013 10:11:25 PM Rafael J. Wysocki wrote: On Thursday, February 07, 2013 12:25:13 AM Artem Savkov wrote: I get the following BUG on suspend using systemd-sleep(this doesn't happen with pm-suspend). This seems to be introduced by some of the Viresh's patches. Which branch from which day? The log is from linux-next-20130205, still reproducible on -20130206 OK, I've reproduced it and the appended patch fixes it for me. Can you please try it and report back? I've tried the patch and the bug is still reproducible. I might be wrong but it seems that the bug happens on first __cpufreq_remove_dev call(CPU1) on __cpufreq_governor(data, CPUFREQ_GOV_STOP) call (line ~1050) but changes in your patch are all below that call. -- Kind regards, Artem -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] asmlinkage tag for sys_iopl
On Sun, Feb 03, 2013 at 07:04:35PM +, Al Viro wrote: > On Sun, Feb 03, 2013 at 07:59:12PM +0100, Ingo Molnar wrote: > > > > * Artem Savkov wrote: > > > > > asmlinkage tag seems to be missing from sys_iopl prototype rendering iopl > > > syscalls unusable, i.e. every call returns -EINVAL. Most likely > > > introduced in > > > 9e0b2428bc6a6c6df90bb701ca843820727cadf0. > > > > What commit is 9e0b2428bc6a6c6df90bb701ca843820727cadf0? It's > > certainly not upstream nor in the x86 tree. > > It's in signal.git; proper fix is to use SYSCALL_DEFINE1(). I'll push it > tonight. It is also in linux-next.git, so it would be nice to have a fix merged there too. Thanks. -- Kind regards, Artem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] asmlinkage tag for sys_iopl
asmlinkage tag seems to be missing from sys_iopl prototype rendering iopl
syscalls unusable, i.e. every call returns -EINVAL. Most likely introduced in
9e0b2428bc6a6c6df90bb701ca843820727cadf0.
Signed-off-by: Artem Savkov
---
arch/x86/include/asm/syscalls.h | 2 +-
arch/x86/kernel/ioport.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/syscalls.h b/arch/x86/include/asm/syscalls.h
index 13f078c..6cf0a9c 100644
--- a/arch/x86/include/asm/syscalls.h
+++ b/arch/x86/include/asm/syscalls.h
@@ -18,7 +18,7 @@
/* Common in X86_32 and X86_64 */
/* kernel/ioport.c */
asmlinkage long sys_ioperm(unsigned long, unsigned long, int);
-long sys_iopl(unsigned int);
+asmlinkage long sys_iopl(unsigned int);
/* kernel/ldt.c */
asmlinkage int sys_modify_ldt(int, void __user *, unsigned long);
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 5f98381..b1127a0 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -93,7 +93,7 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long
num, int turn_on)
* on system-call entry - see also fork() and the signal handling
* code.
*/
-long sys_iopl(unsigned int level)
+asmlinkage long sys_iopl(unsigned int level)
{
struct pt_regs *regs = current_pt_regs();
unsigned int old = (regs->flags >> 12) & 3;
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] asmlinkage tag for sys_iopl
asmlinkage tag seems to be missing from sys_iopl prototype rendering iopl
syscalls unusable, i.e. every call returns -EINVAL. Most likely introduced in
9e0b2428bc6a6c6df90bb701ca843820727cadf0.
Signed-off-by: Artem Savkov artem.sav...@gmail.com
---
arch/x86/include/asm/syscalls.h | 2 +-
arch/x86/kernel/ioport.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/syscalls.h b/arch/x86/include/asm/syscalls.h
index 13f078c..6cf0a9c 100644
--- a/arch/x86/include/asm/syscalls.h
+++ b/arch/x86/include/asm/syscalls.h
@@ -18,7 +18,7 @@
/* Common in X86_32 and X86_64 */
/* kernel/ioport.c */
asmlinkage long sys_ioperm(unsigned long, unsigned long, int);
-long sys_iopl(unsigned int);
+asmlinkage long sys_iopl(unsigned int);
/* kernel/ldt.c */
asmlinkage int sys_modify_ldt(int, void __user *, unsigned long);
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 5f98381..b1127a0 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -93,7 +93,7 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long
num, int turn_on)
* on system-call entry - see also fork() and the signal handling
* code.
*/
-long sys_iopl(unsigned int level)
+asmlinkage long sys_iopl(unsigned int level)
{
struct pt_regs *regs = current_pt_regs();
unsigned int old = (regs-flags 12) 3;
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] asmlinkage tag for sys_iopl
On Sun, Feb 03, 2013 at 07:04:35PM +, Al Viro wrote: On Sun, Feb 03, 2013 at 07:59:12PM +0100, Ingo Molnar wrote: * Artem Savkov artem.sav...@gmail.com wrote: asmlinkage tag seems to be missing from sys_iopl prototype rendering iopl syscalls unusable, i.e. every call returns -EINVAL. Most likely introduced in 9e0b2428bc6a6c6df90bb701ca843820727cadf0. What commit is 9e0b2428bc6a6c6df90bb701ca843820727cadf0? It's certainly not upstream nor in the x86 tree. It's in signal.git; proper fix is to use SYSCALL_DEFINE1(). I'll push it tonight. It is also in linux-next.git, so it would be nice to have a fix merged there too. Thanks. -- Kind regards, Artem -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel paging request at 00010016
On Sat, Aug 18, 2012 at 11:25:43PM -0500, Shaun Ruffell wrote: > Adding linux-net to the CC list. > > On Fri, Aug 17, 2012 at 11:57:56PM +0100, Dave Haywood wrote: > > [1.] One line summary of the problem: > > BUG: unable to handle kernel paging request at 00010016 > > > > System boots then crashes a 5-10 or so seconds after getting to the > > login prompt > > Booting without the network cable attached prevents the crash (no > > evidence beyond 10 minutes after boot) > > > > Diagnostics: > > Captured the boot and managed a login + dmesg before the crash > > Some of the log looks corrupted. Probably my crappy usb dongle serial > > flow control but left it in anyway > > [snip] > > Just a note that I see this as well. It happens reliably for me after trying > to > login to the machine via ssh. > > Here is the back trace I collected on the serial port. There is a patch posted on netdev that fixes this for me: http://patchwork.ozlabs.org/patch/178525/ -- Kind regards, Artem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel paging request at 00010016
On Sat, Aug 18, 2012 at 11:25:43PM -0500, Shaun Ruffell wrote: Adding linux-net to the CC list. On Fri, Aug 17, 2012 at 11:57:56PM +0100, Dave Haywood wrote: [1.] One line summary of the problem: BUG: unable to handle kernel paging request at 00010016 System boots then crashes a 5-10 or so seconds after getting to the login prompt Booting without the network cable attached prevents the crash (no evidence beyond 10 minutes after boot) Diagnostics: Captured the boot and managed a login + dmesg before the crash Some of the log looks corrupted. Probably my crappy usb dongle serial flow control but left it in anyway [snip] Just a note that I see this as well. It happens reliably for me after trying to login to the machine via ssh. Here is the back trace I collected on the serial port. There is a patch posted on netdev that fixes this for me: http://patchwork.ozlabs.org/patch/178525/ -- Kind regards, Artem -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
