[PATCH 1/1] intel-iommu: Disable DMA Remapping when intel_iommu=off
On a VT-d capable machine Linux will enable IOMMU by default. If it
then kexec's a second kernel with intel_iommu=off, this second kernel
will leave the DMA remapping engine on with no code handling it. The
symptom is at least USB and SATA drives stop working. This patch fixes
the problem by always disabling DMA remapping when intel_iommu=off.
Signed-off-by: Wei Hu
---
drivers/iommu/intel-iommu.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0099667..0b8f8bb 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3681,8 +3681,12 @@ int __init intel_iommu_init(void)
return -ENODEV;
}
- if (no_iommu || dmar_disabled)
+ if (no_iommu || dmar_disabled) {
+ struct dmar_drhd_unit *drhd;
+ for_each_drhd_unit(drhd)
+ iommu_disable_translation(drhd->iommu);
return -ENODEV;
+ }
if (iommu_init_mempool()) {
if (force_on)
--
1.7.4.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/
RE: [PATCH] mfd:rtsx: Support RTL8411B
>On Fri, Apr 19, 2013 at 09:52:42PM +0800, rogera...@realtek.com wrote: >> From: Roger Tseng >> >> Adding support of model RTL8411B. Since the model is similar to RTL8411, >> differences are implemented in rtl8411.c. >> > >What tree is this against? > >regards, >dan carpenter It should be the mfd-next tree. Best regards, Roger Tseng-- 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] kref: minor cleanup
Hi
On Fri, Apr 19, 2013 at 7:24 PM, Greg KH wrote:
> On Fri, Apr 19, 2013 at 06:33:54PM -0700, Anatol Pomozov wrote:
>> Follow-up for https://lkml.org/lkml/2013/4/12/391
>>
>> * make warning smp-safe
>> * result of atomic _unless_zero functions should be checked by caller
>> to avoid use-after-free error
>>
>> Signed-off-by: Anatol Pomozov
>> ---
>> include/linux/kref.h | 9 ++---
>> lib/kobject.c| 3 ++-
>> 2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/linux/kref.h b/include/linux/kref.h
>> index 4972e6e..092529a 100644
>> --- a/include/linux/kref.h
>> +++ b/include/linux/kref.h
>> @@ -39,8 +39,11 @@ static inline void kref_init(struct kref *kref)
>> */
>> static inline void kref_get(struct kref *kref)
>> {
>> - WARN_ON(!atomic_read(&kref->refcount));
>> - atomic_inc(&kref->refcount);
>> + /* If refcount was 0 before incrementing then we have a race
>> + * condition when this kref is freing by some other thread right now.
>> + * In this case one should use kref_get_unless_zero()
>> + */
>> + WARN_ON(atomic_inc_return(&kref->refcount) < 2);
>
> What happens if you disable WARN_ON(), does the atomic_inc_return() go
> away as well? Or did we fix that?
If we disable warnings then expression still evaluated, this is true
for BUG_ON as well. It is how the functions are implemented now.
Tejun Heo once mentioned that such behavior is specification of the
functions. So I believe it is safe to execute code inside WARN_ON.
>> /**
>> @@ -100,7 +103,7 @@ static inline int kref_put_mutex(struct kref *kref,
>>struct mutex *lock)
>> {
>> WARN_ON(release == NULL);
>> -if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
>> + if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
>> mutex_lock(lock);
>> if (unlikely(!atomic_dec_and_test(&kref->refcount))) {
>> mutex_unlock(lock);
>> diff --git a/lib/kobject.c b/lib/kobject.c
>> index a654866..bbd7362 100644
>> --- a/lib/kobject.c
>> +++ b/lib/kobject.c
>> @@ -529,7 +529,8 @@ struct kobject *kobject_get(struct kobject *kobj)
>> return kobj;
>> }
>>
>> -static struct kobject *kobject_get_unless_zero(struct kobject *kobj)
>> +static struct kobject *__must_check kobject_get_unless_zero(
>> + struct kobject *kobj)
>
> __must_check needs to be in the .h file, not the .c file.
This function is static and defined in *.c. But I think the function
should be declared in *.h as it might be useful for others. I'll
resend patch tomorrow.
--
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] regulator: tps6586x: Convert to use regulator_map_voltage_ascend
All regulators have ascendant voltage list in this driver.
Thus use regulator_map_voltage_ascend is more efficient than the default
regulator_map_voltage_iterate.
Signed-off-by: Axel Lin
---
drivers/regulator/tps6586x-regulator.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/tps6586x-regulator.c
b/drivers/regulator/tps6586x-regulator.c
index b813d21..d8fa37d 100644
--- a/drivers/regulator/tps6586x-regulator.c
+++ b/drivers/regulator/tps6586x-regulator.c
@@ -70,6 +70,7 @@ static inline struct device *to_tps6586x_dev(struct
regulator_dev *rdev)
static struct regulator_ops tps6586x_regulator_ops = {
.list_voltage = regulator_list_voltage_table,
+ .map_voltage = regulator_map_voltage_ascend,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
.set_voltage_sel = regulator_set_voltage_sel_regmap,
--
1.7.10.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/
Re: [PATCH] ARM64: kernel: compiling issue: need define readq and writeq for driver module using.
On 2013年04月19日 20:13, Arnd Bergmann wrote: > On Friday 19 April 2013, Chen Gang wrote: >> > when compiling with allmodconfig, CONFIG_64BIT=y >> > the file drivers/base/regmap/regmap-mmio.c will use readq and writeq. >> > >> > so we need implement these functions. >> > >> > BTW: >> > the coding style can not pass ./scripts/checkpatch.pl. >> > it seems better to provide additional patch for beautifying code. >> > >> > Signed-off-by: Chen Gang > Acked-by: Arnd Bergmann thanks. -- Chen Gang Flying Transformer -- 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] regulator: tps65910: Convert to use regulator_map_voltage_ascend
All regulators have ascendant voltage list in this driver.
Some regulators have more than 200 supported voltages.
e.g.
For TPS65910_REG_VDD1 and TPS65910_REG_VDD2:
n_voltages = VDD1_2_NUM_VOLT_FINE * VDD1_2_NUM_VOLT_COARSE
= 73 * 3
= 219
Thus it worth converting to regulator_map_voltage_ascend rather than use
default regulator_map_voltage_iterate.
For consistent, convert all regulators to regulator_map_voltage_ascend.
Signed-off-by: Axel Lin
---
drivers/regulator/tps65910-regulator.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/regulator/tps65910-regulator.c
b/drivers/regulator/tps65910-regulator.c
index 6ba6931..45c1644 100644
--- a/drivers/regulator/tps65910-regulator.c
+++ b/drivers/regulator/tps65910-regulator.c
@@ -748,6 +748,7 @@ static struct regulator_ops tps65910_ops_dcdc = {
.set_voltage_sel= tps65910_set_voltage_dcdc_sel,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
.list_voltage = tps65910_list_voltage_dcdc,
+ .map_voltage= regulator_map_voltage_ascend,
};
static struct regulator_ops tps65910_ops_vdd3 = {
@@ -758,6 +759,7 @@ static struct regulator_ops tps65910_ops_vdd3 = {
.get_mode = tps65910_get_mode,
.get_voltage= tps65910_get_voltage_vdd3,
.list_voltage = regulator_list_voltage_table,
+ .map_voltage= regulator_map_voltage_ascend,
};
static struct regulator_ops tps65910_ops = {
@@ -769,6 +771,7 @@ static struct regulator_ops tps65910_ops = {
.get_voltage_sel= tps65910_get_voltage_sel,
.set_voltage_sel= tps65910_set_voltage_sel,
.list_voltage = regulator_list_voltage_table,
+ .map_voltage= regulator_map_voltage_ascend,
};
static struct regulator_ops tps65911_ops = {
@@ -780,6 +783,7 @@ static struct regulator_ops tps65911_ops = {
.get_voltage_sel= tps65911_get_voltage_sel,
.set_voltage_sel= tps65911_set_voltage_sel,
.list_voltage = tps65911_list_voltage,
+ .map_voltage= regulator_map_voltage_ascend,
};
static int tps65910_set_ext_sleep_config(struct tps65910_reg *pmic,
--
1.7.10.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/
Re: [Suggestion] ARM64: kernel: compiling issue, need implement cmpxchg64 with assembler language.
On 2013年04月19日 20:12, Arnd Bergmann wrote:
> On Friday 19 April 2013, Chen Gang wrote:
>> in arch/arm64/include/asm, not define the function cmpxchg64
>>
>> when compiling with allmodconfig,
>> drivers/block/blockconsole.c will need this function.
>>
>> I am not quite familiar with ARM64 (neither ARM64 assembler)
>>
>> can any member helps to send related patch ?
>> if no one have time to send related patch, I should try.
>> and I am glad to try, but need additional time resources,
>> if I try, I should finish it within this month (2013-4-30).
>>
>> welcome any suggestions or completions.
>
> cmpxchg64 is the same as cmpxchg on 64-bit platforms, can't the
> driver be changed to use the latter?
>
> Arnd
>
>
can we be sure that cmpxchg64 is equal to cmpchg on all 64-bit platforms ?
(I guess, the driver may need cross multiple platforms)
(it seems, under x86, s390, better use cmpxchg64, at least they define it).
whether we can be sure or not,
I still prefer to define the macro cmpxchg64 just the alias of cmpxchg.
(and I also guess ARM64 is always on 64-bit platform)
the related patch may be like below.
---patch begin--
diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
index 968b5cb..b572d2b 100644
--- a/arch/arm64/include/asm/cmpxchg.h
+++ b/arch/arm64/include/asm/cmpxchg.h
@@ -170,4 +170,6 @@ static inline unsigned long __cmpxchg_mb(volatile void
*ptr, unsigned long old,
(unsigned long)(n), \
sizeof(*(ptr
+#define cmpxchg64(ptr,o,n) cmpxchg((ptr),(o),(n))
+
#endif /* __ASM_CMPXCHG_H */
---patch end
I think, we can also reference the implementation of s390:
it is in arch/s390/include/asm/cmpxchg.h.
since we are ARM64, excluding ARM(32,16...), we can only consider 64-bit.
if in the future, ARM64 and ARM are merged together:
we can use CONFIG_64BIT to switch the cmpxchg64 definition.
if define CONFIG_64BIT, use cmpxchg instead of cmpxchg64.
else, use the definition of ARM (arch/arm/include/asm/cmpxchg.h already
defines cmpxchg64)
---reference begin--
#ifdef CONFIG_64BIT
#define cmpxchg64(ptr, o, n)\
({ \
cmpxchg((ptr), (o), (n)); \
})
#else /* CONFIG_64BIT */
...
---reference end
:-)
--
Chen Gang
Asianux Corporation
--
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] kref: minor cleanup
On Fri, Apr 19, 2013 at 06:33:54PM -0700, Anatol Pomozov wrote:
> Follow-up for https://lkml.org/lkml/2013/4/12/391
>
> * make warning smp-safe
> * result of atomic _unless_zero functions should be checked by caller
> to avoid use-after-free error
>
> Signed-off-by: Anatol Pomozov
> ---
> include/linux/kref.h | 9 ++---
> lib/kobject.c| 3 ++-
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/kref.h b/include/linux/kref.h
> index 4972e6e..092529a 100644
> --- a/include/linux/kref.h
> +++ b/include/linux/kref.h
> @@ -39,8 +39,11 @@ static inline void kref_init(struct kref *kref)
> */
> static inline void kref_get(struct kref *kref)
> {
> - WARN_ON(!atomic_read(&kref->refcount));
> - atomic_inc(&kref->refcount);
> + /* If refcount was 0 before incrementing then we have a race
> + * condition when this kref is freing by some other thread right now.
> + * In this case one should use kref_get_unless_zero()
> + */
> + WARN_ON(atomic_inc_return(&kref->refcount) < 2);
What happens if you disable WARN_ON(), does the atomic_inc_return() go
away as well? Or did we fix that?
> }
>
> /**
> @@ -100,7 +103,7 @@ static inline int kref_put_mutex(struct kref *kref,
>struct mutex *lock)
> {
> WARN_ON(release == NULL);
> -if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
> + if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
> mutex_lock(lock);
> if (unlikely(!atomic_dec_and_test(&kref->refcount))) {
> mutex_unlock(lock);
> diff --git a/lib/kobject.c b/lib/kobject.c
> index a654866..bbd7362 100644
> --- a/lib/kobject.c
> +++ b/lib/kobject.c
> @@ -529,7 +529,8 @@ struct kobject *kobject_get(struct kobject *kobj)
> return kobj;
> }
>
> -static struct kobject *kobject_get_unless_zero(struct kobject *kobj)
> +static struct kobject *__must_check kobject_get_unless_zero(
> + struct kobject *kobj)
__must_check needs to be in the .h file, not the .c file.
thanks,
greg k-h
--
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] ARM64: kernel: compiling issue, duplicate definition of early_console
On 2013年04月19日 20:15, Arnd Bergmann wrote: > On Friday 19 April 2013, Chen Gang wrote: >> > when compiling with allmodconfig. >> > early_console is already defined as an extern global pointer. >> > >> > need let it point to the object which we intend to (like ARM32 done). >> > >> > >> > Signed-off-by: Chen Gang > Acked-by: Arnd Bergmann > > thanks -- Chen Gang Asianux Corporation -- 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] ARM64: kernel: compiling issue, duplicate definition of early_console
On 2013年04月19日 20:31, Catalin Marinas wrote: > On Fri, Apr 19, 2013 at 11:53:07AM +0100, Chen Gang wrote: >> when compiling with allmodconfig. >> early_console is already defined as an extern global pointer. >> >> need let it point to the object which we intend to (like ARM32 done). >> >> >> Signed-off-by: Chen Gang > > Thanks for the patch. > :-) -- Chen Gang Asianux Corporation -- 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] ARM64: kernel: compiling issue: need define readq and writeq for driver module using.
On 2013年04月19日 20:35, Catalin Marinas wrote: > On Fri, Apr 19, 2013 at 12:24:37PM +0100, Chen Gang wrote: >> > >> > when compiling with allmodconfig, CONFIG_64BIT=y >> > the file drivers/base/regmap/regmap-mmio.c will use readq and writeq. >> > >> > so we need implement these functions. >> > >> > BTW: >> > the coding style can not pass ./scripts/checkpatch.pl. >> > it seems better to provide additional patch for beautifying code. > If it complains about long lines, just ignore it. I wouldn't worry too > much about checkpatch.pl and coding style warnings ;) > ok, I can understand. :-) -- Chen Gang Asianux Corporation -- 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] kref: minor cleanup
Follow-up for https://lkml.org/lkml/2013/4/12/391
* make warning smp-safe
* result of atomic _unless_zero functions should be checked by caller
to avoid use-after-free error
Signed-off-by: Anatol Pomozov
---
include/linux/kref.h | 9 ++---
lib/kobject.c| 3 ++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 4972e6e..092529a 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -39,8 +39,11 @@ static inline void kref_init(struct kref *kref)
*/
static inline void kref_get(struct kref *kref)
{
- WARN_ON(!atomic_read(&kref->refcount));
- atomic_inc(&kref->refcount);
+ /* If refcount was 0 before incrementing then we have a race
+* condition when this kref is freing by some other thread right now.
+* In this case one should use kref_get_unless_zero()
+*/
+ WARN_ON(atomic_inc_return(&kref->refcount) < 2);
}
/**
@@ -100,7 +103,7 @@ static inline int kref_put_mutex(struct kref *kref,
struct mutex *lock)
{
WARN_ON(release == NULL);
-if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
+ if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
mutex_lock(lock);
if (unlikely(!atomic_dec_and_test(&kref->refcount))) {
mutex_unlock(lock);
diff --git a/lib/kobject.c b/lib/kobject.c
index a654866..bbd7362 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -529,7 +529,8 @@ struct kobject *kobject_get(struct kobject *kobj)
return kobj;
}
-static struct kobject *kobject_get_unless_zero(struct kobject *kobj)
+static struct kobject *__must_check kobject_get_unless_zero(
+ struct kobject *kobj)
{
if (!kref_get_unless_zero(&kobj->kref))
kobj = NULL;
--
1.8.2.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 09/10] cpuset: allow to keep tasks in empty cpusets
On 2013/4/20 4:58, Tejun Heo wrote:
> Hello,
>
> On Fri, Apr 19, 2013 at 08:29:24PM +0800, Li Zefan wrote:
>> +static void update_tasks_cpumask_hier(struct cpuset *root_cs,
>> + bool update_root, struct ptr_heap *heap)
>> +{
>> +struct cpuset *cp;
>> +struct cgroup *pos_cgrp;
>> +
>> +if (update_root)
>> +update_tasks_cpumask(root_cs, heap);
>> +
>> +rcu_read_lock();
>> +cpuset_for_each_descendant_pre(cp, pos_cgrp, root_cs) {
>> +/* skip the whole subtree if @cp have some CPU */
>> +if (!cpumask_empty(cp->cpus_allowed)) {
>> +pos_cgrp = cgroup_rightmost_descendant(pos_cgrp);
>> +continue;
>> +}
>> +
>> +update_tasks_cpumask(cp, heap);
>> +}
>> +rcu_read_unlock();
>
> I don't think we can call update_tasks_cpumask() under
> rcu_read_lock(). It calls into set_cpus_allowed_ptr() which may
> block, so you'll probably have to punt it to a work item like how
Oh, will fix.
> migration is being done. Another approach would be converting cgroup
> to use SRCU instead, which would lessen pain on other places too. The
> only problem there would be that srcu_read_lock() is a bit more
> expensive than rcu_read_lock(). I'm not sure whether that'd show up
> in some hot path or not. Ideas?
>
I guess we can live with rcu_read_lock() for now, and see if we can
change it to srcu when other significant changes are done in all
cgroup controllers. (hierarchy support in blkcg, etc..)
--
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 05/10] cpuset: don't update tasks' cpumask and nodemask in an empty cpuset
On 2013/4/20 2:36, Tejun Heo wrote: > Hello, Li. > > On Fri, Apr 19, 2013 at 08:27:05PM +0800, Li Zefan wrote: >> I think this was introduced unintentionally when cpuset hotplug was >> made asynchronous. Fortunately it does no harm, as updating tasks' >> cpumask will just return failure and there's a guarantee_online_mems() >> when updating nodemask, and then the tasks will be moved to an ancestor >> cpuset. > > Yeah, which will update the masks to the proper values anyway, so it > was intentionally written that way as it didn't really matter either > way. I suppose this helps future changes? Maybe update the > description a bit? > I was trying to fix a bug: before moving tasks out of empty cpusets, update_tasks_nodemask() is called, which calls do_migrate_pages(xx, from, to) finally, from == node_to_be_offlined, to == empty_nodeamsk, so I guess no pages will be migrated. Then when those tasks are moving to an ancestor, do_migrate_pages(xx, from, to) is called again, from == empty_nodemask, to == ancestor's nodemask, so I guess again no pages will be migrated. This bug exists even before your changes. -- 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: No serial since kernel 3.8
On Thursday, April 18, 2013 01:15:27 PM Stephan von Krawczynski wrote: > On Wed, 17 Apr 2013 20:55:04 +0200 > "Rafael J. Wysocki" wrote: > > > On Wednesday, April 17, 2013 11:38:30 AM Bjorn Helgaas wrote: > > > [+cc Rafael & linux-acpi] > > > > Thanks. > > > > > On Tue, Apr 16, 2013 at 10:14 AM, Stephan von Krawczynski > > > wrote: > > > > On Tue, 16 Apr 2013 10:59:53 -0400 > > > > Josh Boyer wrote: > > > > > > > >> On Tue, Apr 16, 2013 at 04:55:25PM +0200, richard -rw- weinberger > > > >> wrote: > > > >> >On Tue, Apr 16, 2013 at 4:20 PM, Stephan von Krawczynski > > > >> > wrote: > > > >> >> Hello, > > > >> >> > > > >> >> can some kind soul please explain how I can get my serial port back > > > >> >> under > > > >> >> kernel 3.8.X. Earlier kernels showed: > > > >> >> > > > >> >> Jan 10 13:57:18 mybox kernel: [0.712829] serial8250: ttyS0 at > > > >> >> I/O 0x3f8 > > > >> >> (irq = 4) is a 16550A > > > >> >> > > > >> >> But 3.8.4: > > > >> >> > > > >> >> Mar 26 10:39:14 admin kernel: [0.603647] serial 00:0a: disabled > > > >> >> > > > >> >> Only kernel is replaced, no change in distro > > > >> >> Is there some kernel boot parameter needed now? > > > >> >> I tried 3.4.X and it works, even 3.7.X works... > > > >> > > > > >> >So, 3.8.3 worked and 3.8.4 introduced a regression? > > > >> >If so please confirm. > > > >> > > > > >> >CC'ing gregkh, just in case... > > > >> > > > >> We had a report of this in Fedora that was fixed with 3.8.7. An > > > >> upstream > > > >> change had been brought back to the 3.8.x series, and it was > > > >> subsequently > > > >> reverted. 3.8.7 picked up the revert. > > > >> > > > >> josh > > > > > > > > 3.8.7 does not work either. I just checked it. I tried shared and not > > > > shared IRQ: > > > > > > > > Apr 16 17:47:05 mybox kernel: [0.604826] Serial: 8250/16550 driver, > > > > 8 ports, IRQ sharing disabled > > > > > > > > and another test: > > > > > > > > Apr 16 18:07:08 mybox kernel: [0.601203] Serial: 8250/16550 driver, > > > > 8 ports, IRQ sharing enabled > > > > > > > > I must say that 3.8.7 does not even tell the "serial 00:0a: disabled" > > > > any more. > > > > This is no special board, it is a pretty mainstream asus xeon board > > > > with onboard serial. > > > > Loading 3.4.24 (just an example) makes the port work immediately. > > > > Anything else I can test? > > > > > > 3.7.6 works, and 3.8.3, 3.8.4, 3.8.7 all fail. So it looks like a > > > regression between 3.7.6 and 3.8.3. > > > > > > The "serial 00:0a: disabled" message is from PNP, so I added Rafael > > > and linux-acpi. Complete dmesg logs from 3.7.6 and 3.8.4 would be a > > > place to start. Also maybe an acpidump, since the 00:0a PNP device > > > probably came from PNPACPI. You could attach all these to a > > > https://bugzilla.kernel.org report if you want a place to stash them. > > > > > > Josh, do you have a pointer (URL) to the Fedora issue so we can rule > > > that in or out? > > > > Stephan, below is a list of commits touching the PNP code between 3.7 and > > 3.8. > > > > Can you please check if any of them has triggered the problem you're seeing? > > > > Rafael > > > > > > 13cde3b PNP: Handle IORESOURCE_BITS in resource allocation > > c937766 PNP: Simplify setting of resources > > cdc87c5 pnpacpi: fix incorrect TEST_ALPHA() test > > a6b5e88 ACPI / PNP: Do not crash due to stale pointer use during system > > resume > > 38de279 pnpbios: remove CONFIG_HOTPLUG ifdefs > > 2905875 ACPI / PNP: skip ACPI device nodes associated with physical nodes > > already > > 046d9ce ACPI: Move device resources interpretation code from PNP to ACPI > > core > > > > Hello all, > > I checked 3.8.8 today and it _does_ work. Great! > Shall we burn some time to find out why? Only if you want to know. :-) > The only significant output difference between working and not working we > could find is: > > not working: > Apr 2 17:28:23 mybox kernel: [0.603270] serial 00:0a: disabled > > working (3.8.8): > Apr 18 12:58:50 mybox kernel: [2.855929] 00:0a: ttyS0 at I/O 0x3f8 (irq = > 4) is a 16550A Thanks for the info Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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 4/4] ARM: arch_timer: Move to setup_sched_clock_64()
Register with the ARM sched_clock framework now that it supports
64 bits. This also fixes two problems with the current sched_clock
support for machines using the archited timers. First off, we
don't subtract the start value from subsequent sched_clock calls
so we can potentially start off with sched_clock returning
gigantic numbers. Second, there is no support for suspend/resume
handling so problems such as discussed in 6a4dae5 (ARM: 7565/1:
sched: stop sched_clock() during suspend, 2012-10-23) can happen.
Signed-off-by: Stephen Boyd
---
arch/arm/include/asm/sched_clock.h | 3 ---
arch/arm/kernel/arch_timer.c | 14 ++
arch/arm/kernel/sched_clock.c | 3 ++-
3 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/sched_clock.h
b/arch/arm/include/asm/sched_clock.h
index 7fcd2ee..e6f765a 100644
--- a/arch/arm/include/asm/sched_clock.h
+++ b/arch/arm/include/asm/sched_clock.h
@@ -10,9 +10,6 @@
extern void sched_clock_postinit(void);
extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
-
-extern unsigned long long (*sched_clock_func)(void);
-
extern void setup_sched_clock_64(u64 (*read)(void), int bits,
unsigned long rate);
#endif
diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index 59dcdce..b45250b 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -22,13 +22,6 @@ static unsigned long arch_timer_read_counter_long(void)
return arch_timer_read_counter();
}
-static u32 sched_clock_mult __read_mostly;
-
-static unsigned long long notrace arch_timer_sched_clock(void)
-{
- return arch_timer_read_counter() * sched_clock_mult;
-}
-
static struct delay_timer arch_delay_timer;
static void __init arch_timer_delay_timer_register(void)
@@ -48,11 +41,8 @@ int __init arch_timer_arch_init(void)
arch_timer_delay_timer_register();
- /* Cache the sched_clock multiplier to save a divide in the hot path. */
- sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
- sched_clock_func = arch_timer_sched_clock;
- pr_info("sched_clock: ARM arch timer >56 bits at %ukHz, resolution
%uns\n",
- arch_timer_rate / 1000, sched_clock_mult);
+ /* 56 bits minimum, so we assume worst case rollover */
+ setup_sched_clock_64(arch_timer_read_counter, 56, arch_timer_rate);
return 0;
}
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 7875e9e..b6067d8 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -181,7 +181,8 @@ static unsigned long long notrace sched_clock_32(void)
return cyc_to_sched_clock(cyc, sched_clock_mask);
}
-unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
+static unsigned long long __read_mostly
+(*sched_clock_func)(void) = sched_clock_32;
static unsigned long long notrace sched_clock_64(void)
{
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 3/4] ARM: sched_clock: Add support for >32 bit sched_clock
The arm architected system counter has at least 56 bits of
useable bits. Add support to ARM's sched_clock implementation for
counters with more than 32 bits so we can avoid the complexity of
dealing with wraparound on these devices while benefiting from
the irqtime accounting and suspend/resume handling that the ARM
sched_clock code already has.
Signed-off-by: Stephen Boyd
---
Maybe we need a union for the epoch_ns usage?
arch/arm/include/asm/sched_clock.h | 2 +
arch/arm/kernel/sched_clock.c | 101 +++--
2 files changed, 77 insertions(+), 26 deletions(-)
diff --git a/arch/arm/include/asm/sched_clock.h
b/arch/arm/include/asm/sched_clock.h
index 3d520dd..7fcd2ee 100644
--- a/arch/arm/include/asm/sched_clock.h
+++ b/arch/arm/include/asm/sched_clock.h
@@ -13,4 +13,6 @@ extern void setup_sched_clock(u32 (*read)(void), int bits,
unsigned long rate);
extern unsigned long long (*sched_clock_func)(void);
+extern void setup_sched_clock_64(u64 (*read)(void), int bits,
+unsigned long rate);
#endif
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 29ac613..7875e9e 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -44,6 +44,7 @@ static u32 notrace jiffy_sched_clock_read(void)
}
static u32 __read_mostly (*read_sched_clock)(void) = jiffy_sched_clock_read;
+static u64 __read_mostly (*read_sched_clock_64)(void);
static inline u64 cyc_to_ns(u64 cyc, u32 mult, u32 shift)
{
@@ -104,24 +105,12 @@ static void sched_clock_poll(unsigned long wrap_ticks)
update_sched_clock();
}
-void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
+static u64 __init sched_clock_calc_wrap(int bits, unsigned long rate)
{
- unsigned long r, w;
+ unsigned long r;
u64 res, wrap;
char r_unit;
- if (cd.rate > rate)
- return;
-
- BUG_ON(bits > 32);
- WARN_ON(!irqs_disabled());
- read_sched_clock = read;
- sched_clock_mask = (1 << bits) - 1;
- cd.rate = rate;
-
- /* calculate the mult/shift to convert counter ticks to ns. */
- clocks_calc_mult_shift(&cd.mult, &cd.shift, rate, NSEC_PER_SEC, 0);
-
r = rate;
if (r >= 400) {
r /= 100;
@@ -135,12 +124,39 @@ void __init setup_sched_clock(u32 (*read)(void), int
bits, unsigned long rate)
/* calculate how many ns until we wrap */
wrap = cyc_to_ns((1ULL << bits) - 1, cd.mult, cd.shift);
do_div(wrap, NSEC_PER_MSEC);
- w = wrap;
/* calculate the ns resolution of this counter */
res = cyc_to_ns(1ULL, cd.mult, cd.shift);
- pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps
every %lums\n",
- bits, r, r_unit, res, w);
+ pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps
every %llums\n",
+ bits, r, r_unit, res, wrap);
+
+ return wrap;
+}
+
+static void __init try_to_enable_irqtime(unsigned long rate)
+{
+ /* Enable IRQ time accounting if we have a fast enough sched_clock */
+ if (irqtime > 0 || (irqtime == -1 && rate >= 100))
+ enable_sched_clock_irqtime();
+}
+
+void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
+{
+ unsigned long w;
+
+ if (cd.rate > rate)
+ return;
+
+ BUG_ON(bits > 32);
+ WARN_ON(!irqs_disabled());
+ read_sched_clock = read;
+ sched_clock_mask = (1 << bits) - 1;
+ cd.rate = rate;
+
+ /* calculate the mult/shift to convert counter ticks to ns. */
+ clocks_calc_mult_shift(&cd.mult, &cd.shift, rate, NSEC_PER_SEC, 0);
+
+ w = sched_clock_calc_wrap(bits, rate);
/*
* Start the timer to keep sched_clock() properly updated and
@@ -154,9 +170,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits,
unsigned long rate)
*/
cd.epoch_ns = 0;
- /* Enable IRQ time accounting if we have a fast enough sched_clock */
- if (irqtime > 0 || (irqtime == -1 && rate >= 100))
- enable_sched_clock_irqtime();
+ try_to_enable_irqtime(rate);
pr_debug("Registered %pF as sched_clock source\n", read);
}
@@ -169,6 +183,32 @@ static unsigned long long notrace sched_clock_32(void)
unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
+static unsigned long long notrace sched_clock_64(void)
+{
+ u64 cyc = read_sched_clock_64() - cd.epoch_ns;
+ return cyc * cd.mult;
+}
+
+void __init
+setup_sched_clock_64(u64 (*read)(void), int bits, unsigned long rate)
+{
+ if (cd.rate > rate)
+ return;
+
+ BUG_ON(bits <= 32);
+ WARN_ON(!irqs_disabled());
+ read_sched_clock_64 = read;
+ sched_clock_func = sched_clock_64;
+ cd.rate = rate;
+ cd.mult = NSEC_PER_SEC / rate;
+ cd.epoch_ns = r
[PATCH 2/4] ARM: sched_clock: Return suspended count earlier
If we're suspended and sched_clock() is called we're going to
read the hardware one more time and throw away that value and
return back the cached value we saved during the suspend
callback. This is wasteful, let's short circuit all that and
return the cached value if we're suspended as early as possible.
Signed-off-by: Stephen Boyd
---
arch/arm/kernel/sched_clock.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 48ab64a..29ac613 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -55,9 +55,6 @@ static unsigned long long cyc_to_sched_clock(u32 cyc, u32
mask)
u64 epoch_ns;
u32 epoch_cyc;
- if (cd.suspended)
- return cd.epoch_ns;
-
/*
* Load the epoch_cyc and epoch_ns atomically. We do this by
* ensuring that we always write epoch_cyc, epoch_ns and
@@ -174,6 +171,9 @@ unsigned long long __read_mostly (*sched_clock_func)(void)
= sched_clock_32;
unsigned long long notrace sched_clock(void)
{
+ if (cd.suspended)
+ return cd.epoch_ns;
+
return sched_clock_func();
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 0/4] ARM 64 bit sched_clock take #2
This is what I was thinking. I don't see why we can't move this to generic code and have arm64 use it too. Those patches will follow once I find an arm64 compiler. First two patches should probably go in even if the 64 bit stuff doesn't go in at the same time. Stephen Boyd (4): ARM: sched_clock: Remove unused needs_suspend member ARM: sched_clock: Return suspended count earlier ARM: sched_clock: Add support for >32 bit sched_clock ARM: arch_timer: Move to setup_sched_clock_64() arch/arm/include/asm/sched_clock.h | 5 +- arch/arm/kernel/arch_timer.c | 14 + arch/arm/kernel/sched_clock.c | 111 ++--- 3 files changed, 84 insertions(+), 46 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 1/4] ARM: sched_clock: Remove unused needs_suspend member
The needs_suspend member is unused now that we always do the
suspend/resume handling (see 6a4dae5 (ARM: 7565/1: sched: stop
sched_clock() during suspend, 2012-10-23)).
Signed-off-by: Stephen Boyd
---
arch/arm/kernel/sched_clock.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 8805848..48ab64a 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -24,7 +24,6 @@ struct clock_data {
u32 mult;
u32 shift;
bool suspended;
- bool needs_suspend;
};
static void sched_clock_poll(unsigned long wrap_ticks);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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: [RFC PATCH 0/2] cpufreq/regulator: Limit minimum voltage only
On 04/19/2013 07:21 PM, Nishanth Menon wrote: > On 14:55-20130419, Taras Kondratiuk wrote: >> Using a "voltage tolerance" for doing DVFS is not a proper way. >> It leads to a few issues: >> - voltage is limited to a narrow range near OPP voltage, >> so other consumers of the same regulator can't set their own constraints >> if they don't overlap with this narrow range. No ganged rails :( >> - usually OPP voltage is an absolute minimum voltage >> necessary for correct work (not taking into account AVS). >> Applying plus/minus tolerance can lead to an unstable device. >> For example omap-cpufreq has 4% tolerance configured, >> so for OMAP4430 MPU OPP50 we get 0.984V instead of 1.025V. > there is a reason for this - board level IRDROP and the real PMIC > accuracy compared to the SoC assumption about the PMIC accuracy. I don't see how current implementation of voltage-tolerance can help with this. > > That said, I had been always been a little confused with the usage > in AM335x. For that matter, I dont even think this is constrainted to > TI SoC usage, other SoCs also probably have the same pain. > > How does it actually work? I think this is a question to Afzal as he is an original author of commit 42daffd2d6c665716d442d518022ecaad17ddf64 which later migrated to cpufreq-cpu0 driver. I can only guess... Without tolerance cpufreq requests the same value for min_uV and max_uV. So regulator have to set an exact voltage value on the rail, which is not always possible if different PMICs can be used for the SoC. For example in v3.9-rc7 voltage-tolerance is used *only* in AM33xx which can use two PMICs: TPS65217 and TPS65910. These PMICs have different voltage steps so they can't set the same voltage. I think this was the reason for adding voltage-tolerance. *But* there is a trick. If you compare MPU OPP voltages in AM335x datasheet and am33xx.dtsi you will see that am33xx.dtsi has already applied tolerance (2%) on top of nominal voltages. So final range passed to regulator is [Vnom; Vnom+2*tol] instead of [Vnom-tol; Vnom+tol]. That's why it works for AM335x, but IMHO it is a hack. That patch broke omap-cpufreq functionality, since mach-omap2/opp_data.c files doesn't have tolerance added on top of nominal voltages. regulator_set_voltage_min() should solve AM335x issue without introducing voltage-tolerance hack. Probably I need to add one more patch to the series which will remove voltage-tolerance from am335x.dtsi and set CPU voltages back to nominal. > > Lets say ntarget/Vnom has PMIC tolerance of 5% (SoC tolerance assumed > for OPP voltage documented in data manual for the SoC), say the > OPP voltage is 1.2V - that translates to an voltage of 1.14V on a perfect > PMIC (with 0 drop or perfect accuracy) for the SoC. Even if you have a perfect PMIC it worth to set 1.2V. For example OMAP4 DM states clearly about what nominal voltage is: "Nominal voltage value documented in this table corresponds to the voltage to be applied at power IC (PMIC) level. Whereas minimum and maximum voltage values correspond to the possible voltage at OMAP ball level." > Now, the real world is never perfect. So, lets take the following cases: > a) PMIC with 2% variance > b) PMIC with 5% variance (usually the reference PMIC we put on SoC >vendor platform) In two cases above PMIC tolerance fits into SoC tolerance, so no issue. Just set nominal voltage to PMIC and that's all. > c) PMIC with 10% variance. This is "out of specification" use-case. It should be possible to add a knowledge about tolerance into regulator framework and then add a new constraint type "guarantee-minimum", but I don't think we need some generic solution for this specific case. You can override OPPs from board dts and add some margin on top of nominal voltages if bad PMIC is used. > > How does this translate to dts definition? As you stated, with 5% > variance(b), the call will become min_uV=1.14V max_uV=1.26V when > the tolerance translation is done. with (a) and (c) tolernace value > chooses a different value. > > In short, > a) we need to be able to describe in some form the assumption for > board variances in the OPP voltage in the SoC data manual. > b) we need some way for board/PMIC definitions to be able to influence > and adjust for assumption. Why do we need this? Most board designs has a proper PMIC that matches SoC tolerance requirements. Is there any example where PMIC tolerance is less than required by SoC? > > This is what I believe is achieved using voltage_tolerance. > > > regulator_set_voltage_min is not really the way to do it IMHO. What issues do you see with regulator_set_voltage_min() approach? PS: I have to sent this email from Outlook web interface :( Sorry if
[tip:x86/urgent] x86, microcode: Verify the family before dispatching microcode patching
Commit-ID: 74c3e3fcf350b2e7e3eaf9550528ee3f74e44b37
Gitweb: http://git.kernel.org/tip/74c3e3fcf350b2e7e3eaf9550528ee3f74e44b37
Author: H. Peter Anvin
AuthorDate: Fri, 19 Apr 2013 16:36:03 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 19 Apr 2013 16:36:03 -0700
x86, microcode: Verify the family before dispatching microcode patching
For each CPU vendor that implements CPU microcode patching, there will
be a minimum family for which this is implemented. Verify this
minimum level of support.
This can be done in the dispatch function or early in the application
functions. Doing the latter turned out to be somewhat awkward because
of the ineviable split between the BSP and the AP paths, and rather
than pushing deep into the application functions, do this in
the dispatch function.
Reported-by: "Bryan O'Donoghue"
Suggested-by: Borislav Petkov
Cc: Fenghua Yu
Link:
http://lkml.kernel.org/r/1366392183-4149-1-git-send-email-bryan.odonoghue.l...@nexus-software.ie
---
arch/x86/kernel/microcode_core_early.c | 38 +++---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/microcode_core_early.c
b/arch/x86/kernel/microcode_core_early.c
index 577db84..833d51d 100644
--- a/arch/x86/kernel/microcode_core_early.c
+++ b/arch/x86/kernel/microcode_core_early.c
@@ -45,9 +45,6 @@ static int __cpuinit x86_vendor(void)
u32 eax = 0x;
u32 ebx, ecx = 0, edx;
- if (!have_cpuid_p())
- return X86_VENDOR_UNKNOWN;
-
native_cpuid(&eax, &ebx, &ecx, &edx);
if (CPUID_IS(CPUID_INTEL1, CPUID_INTEL2, CPUID_INTEL3, ebx, ecx, edx))
@@ -59,18 +56,45 @@ static int __cpuinit x86_vendor(void)
return X86_VENDOR_UNKNOWN;
}
+static int __cpuinit x86_family(void)
+{
+ u32 eax = 0x0001;
+ u32 ebx, ecx = 0, edx;
+ int x86;
+
+ native_cpuid(&eax, &ebx, &ecx, &edx);
+
+ x86 = (eax >> 8) & 0xf;
+ if (x86 == 15)
+ x86 += (eax >> 20) & 0xff;
+
+ return x86;
+}
+
void __init load_ucode_bsp(void)
{
- int vendor = x86_vendor();
+ int vendor, x86;
+
+ if (!have_cpuid_p())
+ return;
- if (vendor == X86_VENDOR_INTEL)
+ vendor = x86_vendor();
+ x86 = x86_family();
+
+ if (vendor == X86_VENDOR_INTEL && x86 >= 6)
load_ucode_intel_bsp();
}
void __cpuinit load_ucode_ap(void)
{
- int vendor = x86_vendor();
+ int vendor, x86;
+
+ if (!have_cpuid_p())
+ return;
+
+ vendor = x86_vendor();
+ x86 = x86_family();
- if (vendor == X86_VENDOR_INTEL)
+ if (vendor == X86_VENDOR_INTEL && x86 >= 6)
load_ucode_intel_ap();
}
--
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: [GIT PULL] EFI fixes for v3.10
On 04/19/2013 10:38 AM, Matt Fleming wrote: > > Richard Weinberger (2): > x86,efi: Check max_size only if it is non-zero. > x86,efi: Implement efi_no_storage_paranoia parameter > OK, I'll pull this for now, but this *really* need to be an automatic quirk of some sort, especially when there is a named board in the mix... -hpa -- 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 1/3] Tools: hv: fix warnings in hv_vss_daemon
On Tue, Mar 26, 2013 at 04:28:27PM +0100, Olaf Hering wrote: > This change fixes a few compile errors: > > hv_vss_daemon.c:64:15: warning: unknown escape sequence '\/' > hv_vss_daemon.c:64:15: warning: unknown escape sequence '\/' > hv_vss_daemon.c: In function 'vss_operate': > hv_vss_daemon.c:66: warning: 'return' with no value, in function returning > non-void > hv_vss_daemon.c: In function 'main': > hv_vss_daemon.c:130: warning: ignoring return value of 'daemon', declared > with attribute warn_unused_result > hv_vss_daemon.c: In function 'vss_operate': > hv_vss_daemon.c:47: warning: 'fs_op' may be used uninitialized in this > function > > Signed-off-by: Olaf Hering For some reason, all of your hv tools patches ended up in my spam filter. KY, can you resend me any that I didn't apply, and you have tested? thanks, greg k-h -- 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] x86: kaslr: move ELF relocation handling to C
Moves the relocation handling into C, after decompression. Only
kernels that need relocation support will use the code. The new
CONFIG_RANDOMIZE_BASE does not yet do anything except turn on this logic
for 64-bit kernels.
Based on work by Neill Clift and Michael Davidson.
Signed-off-by: Kees Cook
---
In case it wasn't clear, this is for the tip/kaslr tree.
---
arch/x86/Kconfig | 10 +++--
arch/x86/Makefile|8 ++--
arch/x86/boot/compressed/head_32.S | 31 ++
arch/x86/boot/compressed/head_64.S |1 +
arch/x86/boot/compressed/misc.c | 77 +-
arch/x86/include/asm/page_32_types.h |2 +
arch/x86/include/asm/page_64_types.h |5 ---
arch/x86/include/asm/page_types.h|6 +++
8 files changed, 99 insertions(+), 41 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 70c0f3d..9063733 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1698,13 +1698,17 @@ config RELOCATABLE
it has been loaded at and the compile time physical address
(CONFIG_PHYSICAL_START) is ignored.
-# Relocation on x86-32 needs some additional build support
+config RANDOMIZE_BASE
+ def_bool n
+ depends on RELOCATABLE
+
+# Relocation on x86 needs some additional build support
config X86_NEED_RELOCS
def_bool y
- depends on X86_32 && RELOCATABLE
+ depends on RANDOMIZE_BASE || (X86_32 && RELOCATABLE)
config PHYSICAL_ALIGN
- hex "Alignment value to which kernel should be aligned" if X86_32
+ hex "Alignment value to which kernel should be aligned"
default "0x100"
range 0x2000 0x100
---help---
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5c47726..43f8cef 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -16,6 +16,10 @@ endif
# e.g.: obj-y += foo_$(BITS).o
export BITS
+ifdef CONFIG_X86_NEED_RELOCS
+LDFLAGS_vmlinux := --emit-relocs
+endif
+
ifeq ($(CONFIG_X86_32),y)
BITS := 32
UTS_MACHINE := i386
@@ -25,10 +29,6 @@ ifeq ($(CONFIG_X86_32),y)
KBUILD_AFLAGS += $(biarch)
KBUILD_CFLAGS += $(biarch)
-ifdef CONFIG_RELOCATABLE
-LDFLAGS_vmlinux := --emit-relocs
-endif
-
KBUILD_CFLAGS += -msoft-float -mregparm=3 -freg-struct-return
# Never want PIC in a 32-bit kernel, prevent breakage with GCC built
diff --git a/arch/x86/boot/compressed/head_32.S
b/arch/x86/boot/compressed/head_32.S
index 1e3184f..5d6f689 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -181,8 +181,9 @@ relocated:
/*
* Do the decompression, and jump to the new kernel..
*/
- lealz_extract_offset_negative(%ebx), %ebp
/* push arguments for decompress_kernel: */
+ pushl $z_output_len /* decompressed length */
+ lealz_extract_offset_negative(%ebx), %ebp
pushl %ebp/* output address */
pushl $z_input_len/* input_len */
lealinput_data(%ebx), %eax
@@ -191,33 +192,7 @@ relocated:
pushl %eax/* heap area */
pushl %esi/* real mode pointer */
calldecompress_kernel
- addl$20, %esp
-
-#if CONFIG_RELOCATABLE
-/*
- * Find the address of the relocations.
- */
- lealz_output_len(%ebp), %edi
-
-/*
- * Calculate the delta between where vmlinux was compiled to run
- * and where it was actually loaded.
- */
- movl%ebp, %ebx
- subl$LOAD_PHYSICAL_ADDR, %ebx
- jz 2f /* Nothing to be done if loaded at compiled addr. */
-/*
- * Process relocations.
- */
-
-1: subl$4, %edi
- movl(%edi), %ecx
- testl %ecx, %ecx
- jz 2f
- addl%ebx, -__PAGE_OFFSET(%ebx, %ecx)
- jmp 1b
-2:
-#endif
+ addl$24, %esp
/*
* Jump to the decompressed kernel.
diff --git a/arch/x86/boot/compressed/head_64.S
b/arch/x86/boot/compressed/head_64.S
index c1d383d..81ca174 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -340,6 +340,7 @@ relocated:
leaqinput_data(%rip), %rdx /* input_data */
movl$z_input_len, %ecx /* input_len */
movq%rbp, %r8 /* output target address */
+ movq$z_output_len, %r9 /* decompressed length */
calldecompress_kernel
popq%rsi
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 7cb56c6..b756a04 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -267,6 +267,79 @@ static void error(char *x)
asm("hlt");
}
+#if CONFIG_X86_NEED_RELOCS
+static void handle_relocations(void *output, unsigned long output_len)
+{
+ int *reloc;
+ unsigned long delta, map, ptr;
+ unsigned long min_addr = (unsigned long)output;
+
Re: [PATCH] x86: Add check for P5 to microcode_intel_early
On 04/19/2013 02:44 PM, Bryan O'Donoghue wrote:
> On 19/04/13 22:25, Borislav Petkov wrote:
>> On Fri, Apr 19, 2013 at 10:55:15PM +0200, Borislav Petkov wrote:
>>> Just filter out P5 and earlier. The code already does that for CPUs
>>> which don't have CPUID.
>>
>> Actually, an alternative - more practical albeit not very accurate
>
> More practical ? Hmm - the MSRs don't exist for < P5
>
>> solution would be to check for which families Intel delivers microcode
>> and do the cut off there with a comment as to why you do it like
>> that.void
>
> You mean return !intel so this function will never be called.
>
> __init load_ucode_bsp(void)
> {
> int vendor = x86_vendor();
>
> if (vendor == X86_VENDOR_INTEL)
> load_ucode_intel_bsp();
> }
>
> Ah yes. That would work and be less code.
>
> We should do it that way.
Do you think you can have a patch for me in the next few hours?
-hpa
--
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 2/2] dma:of: Use a mutex to protect the of_dma_list
On Saturday 20 April 2013, Jon Hunter wrote: > Change also means that of_dma_request_slave_channel() cannot be called > from a context where it is not possible to sleep too, right? May be > worth mentioning this in the changelog as well. You already cannot do that, because it requires dma_list_mutex. Arnd -- 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: Device driver memory 'mmap()' function helper cleanup
On Fri, Apr 19, 2013 at 8:43 AM, Michel Lespinasse wrote: > > Just a suggestion: when file->f_op->mmap returns an error code, > mmap_region() currently has to call unmap_region() to undo any partial > mappings that might have been created by the device driver. Would it > make more sense to ask that the few drivers that create such messes to > clean up after themselves on their error paths ? No. We basically want to assume the least competence humanly (simianly?) possible from driver writers. The problem the helper is trying to solve is exactly the fact that driver writers shouldn't have to even know about all the subtleties with page offsets etc. So if a driver returns an error code, we should assume they screwed up potentially half-way and clean up. We should *not* assume that we don't need to. Linus -- 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: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]
On Fri, Apr 19, 2013 at 3:55 PM, Sedat Dilek wrote: > > Davidlohr pointed to this patch (tested the triplet): > > ipc, sem: do not call sem_lock when bogus sma: > https://lkml.org/lkml/2013/3/31/12 > > Is that what you mean? Yup. Linus -- 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: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]
On Sat, Apr 20, 2013 at 12:50 AM, Linus Torvalds wrote: > On Fri, Apr 19, 2013 at 3:34 PM, Sedat Dilek wrote: >> >> See attached dmesg. > > This still has the bug Davidlohr pointed at: > >>> This looks like what Emmanuel was/is running into: >>> https://lkml.org/lkml/2013/3/30/1 > > you need to move the "IS_ERR()" check before the sem_lock. > Davidlohr pointed to this patch (tested the triplet): ipc, sem: do not call sem_lock when bogus sma: https://lkml.org/lkml/2013/3/31/12 Is that what you mean? - Sedat - > Linus -- 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 v2 0/7] pcmcia: at91_cf: clean up and add DT support
On Wed, Apr 17, 2013 at 10:51:23AM +0200, Nicolas Ferre wrote: > On 04/17/2013 10:39 AM, Fabio Porcedda : > > On Thu, Mar 21, 2013 at 12:40 PM, Nicolas Ferre > > wrote: > >> These patches clean up at91_cf a bit and add DT bindings. > >> It is based on a previous series from Joachim Eastwood and other cleanup > >> patches by Fabio and Laurent. > >> I have collected them together as they are lying around for some time. > >> > >> Please tell me if It can go through PCMCIA tree or if Andrew or Greg can > >> take them. > >> Note that they are not bug fixes, so you can stack them for 3.10. > >> > >> Thanks for your help, best regards. > >> > >> v2: add 2 more cleanup patches: > >> - move to module_platform_driver_probe() > >> - little trivial indentation fix > >> > >> Fabio Porcedda (1): > >> pcmcia: at91_cf: use module_platform_driver_probe() > >> > >> Joachim Eastwood (5): > >> pcmcia: at91_cf: fix gpio_get_value in at91_cf_get_status > >> pcmcia: at91_cf: convert to dev_ print functions > >> pcmcia: at91_cf: use devm_ functions for allocations > >> pcmcia: at91_cf: clean up header includes > >> pcmcia: at91_cf: add support for DT > >> > >> Laurent Navet (1): > >> pcmcia/trivial: at91_cf: fix checkpatch error > >> > >> .../devicetree/bindings/ata/atmel-at91_cf.txt | 19 +++ > >> drivers/pcmcia/Kconfig | 2 +- > >> drivers/pcmcia/at91_cf.c | 176 > >> ++--- > >> 3 files changed, 108 insertions(+), 89 deletions(-) > >> create mode 100644 Documentation/devicetree/bindings/ata/atmel-at91_cf.txt > >> > >> -- > >> 1.8.0 > >> > > > > Ping? > > Andrew, Greg, can you please take this series? > > Here is the post on lkml: > https://lkml.org/lkml/2013/3/21/246 > > Here is the first patch in patchwork (1/7): > https://patchwork.kernel.org/patch/2312691/ > > Tell me if I can do something else to make this applied upstream... The PCMCIA maintainer should take these, not me. thanks, greg k-h -- 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: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]
On Fri, Apr 19, 2013 at 3:34 PM, Sedat Dilek wrote: > > See attached dmesg. This still has the bug Davidlohr pointed at: >> This looks like what Emmanuel was/is running into: >> https://lkml.org/lkml/2013/3/30/1 you need to move the "IS_ERR()" check before the sem_lock. Linus -- 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 2/2] dma:of: Use a mutex to protect the of_dma_list
On 04/19/2013 04:42 AM, Lars-Peter Clausen wrote:
> Currently the OF DMA code uses a spin lock to protect the of_dma_list from
> concurrent access and a per controller reference count to protect the
> controller
> from being freed while a request operation is in progress. If
> of_dma_controller_free() is called for a controller who's reference count is
> not
> zero it will return -EBUSY and not remove the controller. This is fine up
> until
> here, but leaves the question what the caller of of_dma_controller_free() is
> supposed to do if the controller couldn't be freed. The only viable solution
> for the caller is to spin on of_dma_controller_free() until it returns
> success.
> E.g.
>
> do {
> ret = of_dma_controller_free(dev->of_node)
> } while (ret != -EBUSY);
>
> This is rather ugly and unnecessary and non of the current users of
> of_dma_controller_free() check it's return value anyway. Instead protect the
> list by a mutex. The mutex will be held as long as a request operation is in
> progress. So if of_dma_controller_free() is called while a request operation
> is
> in progress it will be put to sleep and only wake up once the request
> operation
> has finished.
>
> This means that it is no longer possible to register or unregister OF DMA
> controllers from a context where it's not possible to sleep. But I doubt that
> we'll ever need this.
Change also means that of_dma_request_slave_channel() cannot be called
from a context where it is not possible to sleep too, right? May be
worth mentioning this in the changelog as well.
> Also rename of_dma_get_controller back to of_dma_find_controller.
>
> Signed-off-by: Lars-Peter Clausen
> ---
> drivers/dma/of-dma.c | 76
> +-
> include/linux/of_dma.h | 6 ++--
> 2 files changed, 22 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
> index 2882403..7aa0864 100644
> --- a/drivers/dma/of-dma.c
> +++ b/drivers/dma/of-dma.c
> @@ -13,38 +13,31 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
>
> static LIST_HEAD(of_dma_list);
> -static DEFINE_SPINLOCK(of_dma_lock);
> +static DEFINE_MUTEX(of_dma_lock);
>
> /**
> - * of_dma_get_controller - Get a DMA controller in DT DMA helpers list
> + * of_dma_find_controller - Get a DMA controller in DT DMA helpers list
> * @dma_spec:pointer to DMA specifier as found in the device tree
> *
> * Finds a DMA controller with matching device node and number for dma cells
> - * in a list of registered DMA controllers. If a match is found the use_count
> - * variable is increased and a valid pointer to the DMA data stored is
> retuned.
> - * A NULL pointer is returned if no match is found.
> + * in a list of registered DMA controllers. If a match is found a valid
> pointer
> + * to the DMA data stored is retuned. A NULL pointer is returned if no match
> is
> + * found.
> */
> -static struct of_dma *of_dma_get_controller(struct of_phandle_args *dma_spec)
> +static struct of_dma *of_dma_find_controller(struct of_phandle_args
> *dma_spec)
> {
> struct of_dma *ofdma;
>
> - spin_lock(&of_dma_lock);
> -
> list_for_each_entry(ofdma, &of_dma_list, of_dma_controllers)
> if ((ofdma->of_node == dma_spec->np) &&
> - (ofdma->of_dma_nbcells == dma_spec->args_count)) {
> - ofdma->use_count++;
> - spin_unlock(&of_dma_lock);
> + (ofdma->of_dma_nbcells == dma_spec->args_count))
> return ofdma;
> - }
> -
> - spin_unlock(&of_dma_lock);
>
> pr_debug("%s: can't find DMA controller %s\n", __func__,
>dma_spec->np->full_name);
> @@ -53,22 +46,6 @@ static struct of_dma *of_dma_get_controller(struct
> of_phandle_args *dma_spec)
> }
>
> /**
> - * of_dma_put_controller - Decrement use count for a registered DMA
> controller
> - * @of_dma: pointer to DMA controller data
> - *
> - * Decrements the use_count variable in the DMA data structure. This function
> - * should be called only when a valid pointer is returned from
> - * of_dma_get_controller() and no further accesses to data referenced by that
> - * pointer are needed.
> - */
> -static void of_dma_put_controller(struct of_dma *ofdma)
> -{
> - spin_lock(&of_dma_lock);
> - ofdma->use_count--;
> - spin_unlock(&of_dma_lock);
> -}
> -
> -/**
> * of_dma_controller_register - Register a DMA controller to DT DMA helpers
> * @np: device node of DMA controller
> * @of_dma_xlate:translation function which converts a phandle
> @@ -114,12 +91,11 @@ int of_dma_controller_register(struct device_node *np,
> ofdma->of_dma_nbcells = nbcells;
> ofdma->of_dma_xlate = of_dma_xlate;
> ofdma->of_dma_data = data;
> - ofdma->use_count = 0;
>
> /* Now queue of_dma controller
Re: [GIT PULL] EFI fixes for v3.10
On 04/19/2013 10:38 AM, Matt Fleming wrote: > Hi guys, > > There's a few bug fixes sitting in the EFI urgent branch. Please > consider pulling. > We are *post -rc7* and days away from release. I can't push this to Linus without a detailed description of what this is and why we need it now. Yes, I can wing it, but I shouldn't *have to* especially not when half out of my gourd... -hpa -- 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 1/2] dma: of: Fix of_node reference leak
On 04/19/2013 05:10 AM, Arnd Bergmann wrote: > On Friday 19 April 2013, Lars-Peter Clausen wrote: >> of_dma_request_slave_channel() currently does not drop the reference to the >> dma_spec of_node if no DMA controller matching the of_node could be found. >> This >> patch fixes it by always calling of_node_put(). >> >> Signed-off-by: Lars-Peter Clausen > > Acked-by: Arnd Bergmann Thanks! FWIW ... Reviewed-by: Jon Hunter Cheers Jon -- 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] ext4: unregister extents status shrinker if mount failed
On 04/20/2013 06:05 AM, Alexey Khoroshilov wrote:
> If ext4_fill_super() failed after extents status shrinker
> has been registered, the shrinker is left in a global list
> while the memory, it sits in, is already freed.
> Oops is not so bad scenario after that.
>
> Found by Linux File System Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
Thanks for your patch. This problem has been fixed in dev branch of
ext4 tree, but has not push into mainline kernel yet. Here is the
commit id (a75ae78f087f933ab3432e98bb4dbbf2196cf6d5).
Thanks,
- Zheng
> ---
> fs/ext4/super.c |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 5d6d5357..5f9cb30 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -3757,7 +3757,7 @@ static int ext4_fill_super(struct super_block *sb, void
> *data, int silent)
> if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_MMP) &&
> !(sb->s_flags & MS_RDONLY))
> if (ext4_multi_mount_protect(sb, le64_to_cpu(es->s_mmp_block)))
> - goto failed_mount3;
> + goto failed_mount_shr;
>
> /*
>* The first inode we look at is the journal inode. Don't try
> @@ -3766,7 +3766,7 @@ static int ext4_fill_super(struct super_block *sb, void
> *data, int silent)
> if (!test_opt(sb, NOLOAD) &&
> EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_HAS_JOURNAL)) {
> if (ext4_load_journal(sb, es, journal_devnum))
> - goto failed_mount3;
> + goto failed_mount_shr;
> } else if (test_opt(sb, NOLOAD) && !(sb->s_flags & MS_RDONLY) &&
> EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_RECOVER)) {
> ext4_msg(sb, KERN_ERR, "required journal recovery "
> @@ -4009,6 +4009,8 @@ failed_mount_wq:
> jbd2_journal_destroy(sbi->s_journal);
> sbi->s_journal = NULL;
> }
> +failed_mount_shr:
> + ext4_es_unregister_shrinker(sb);
> failed_mount3:
> del_timer(&sbi->s_err_report);
> if (sbi->s_flex_groups)
>
--
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: tg3: possible irq lock inversion dependency detected
Hi Rob,
On 19.04.2013 [14:23:21 -0500], Rob Herring wrote:
> On 04/19/2013 02:01 PM, Nishanth Aravamudan wrote:
> > Running 3.9-rc7-ish, tripped the following (also being seen in FC19
> > alpha) on ppc64:
> >
> > [ 117.026196] =
> > [ 117.026216] [ INFO: possible irq lock inversion dependency detected ]
> > [ 117.026238] 3.9.0-rc7+ #8 Not tainted
> > [ 117.026251] -
> > [ 117.026271] swapper/7/0 just changed the state of lock:
> > [ 117.026286] (&(&tp->lock)->rlock){+.-...}, at: []
> > .tg3_timer+0x9c/0x10f0
> > [ 117.026334] but this lock took another, SOFTIRQ-unsafe lock in the past:
> > [ 117.026353] (devtree_lock){+.+...}
> >
> > and interrupts could create inverse lock ordering between them.
> >
> > [ 117.026389]
> > other info that might help us debug this:
> > [ 117.026409] Chain exists of:
> > &(&tp->lock)->rlock --> pci_lock --> devtree_lock
> >
> > [ 117.026452] Possible interrupt unsafe locking scenario:
> >
> > [ 117.026472]CPU0CPU1
> > [ 117.026488]
> > [ 117.026503] lock(devtree_lock);
> > [ 117.026521]local_irq_disable();
> > [ 117.026540]lock(&(&tp->lock)->rlock);
> > [ 117.026567]lock(pci_lock);
> > [ 117.026591]
> > [ 117.026600] lock(&(&tp->lock)->rlock);
> > [ 117.026621]
> > *** DEADLOCK ***
> >
> > [ 117.026644] 1 lock held by swapper/7/0:
> > [ 117.026657] #0: ((&tp->timer)){+.-...}, at: []
> > .call_timer_fn+0x0/0x3e0
> > [ 117.026698]
> > the shortest dependencies between 2nd lock and 1st lock:
> > [ 117.026722] -> (devtree_lock){+.+...} ops: 13864154431488 {
> > [ 117.026758] HARDIRQ-ON-W at:
> > [ 117.026772] SOFTIRQ-ON-W at:
> > [ 117.026786] INITIAL USE at:
> > [ 117.026799]}
> > [ 117.026809]... key at: []
> > devtree_lock+0x18/0x48
> > [ 117.026835]... acquired at:
> >
> > [ 117.026857] -> (pci_lock){..} ops: 3955664879616 {
> > [ 117.026893] INITIAL USE at:
> > [ 117.026906] }
> > [ 117.026915] ... key at: [] pci_lock+0x18/0x48
> > [ 117.026942] ... acquired at:
> >
> > [ 117.026963] -> (&(&tp->lock)->rlock){+.-...} ops: 154618822656 {
> > [ 117.027001]HARDIRQ-ON-W at:
> > [ 117.027015]IN-SOFTIRQ-W at:
> > [ 117.027029]INITIAL USE at:
> > [ 117.027042] }
> > [ 117.027051] ... key at: [] __key.48770+0x0/0x8
> > [ 117.027078] ... acquired at:
> >
> > [ 117.027100]
> > stack backtrace:
> > [ 117.027116] Call Trace:
> > [ 117.027129] [c003a7c7ad10] [c0016ee0] .show_stack+0xd0/0x1f0
> > (unreliable)
> > [ 117.027161] [c003a7c7ade0] [c0137d78]
> > .print_irq_inversion_bug+0x298/0x2f0
> > [ 117.027189] [c003a7c7ae80] [c0137e70]
> > .check_usage_forwards+0xa0/0x150
> > [ 117.027217] [c003a7c7af70] [c0138b68] .mark_lock+0x258/0x7b0
> > [ 117.027242] [c003a7c7b030] [c01396f8]
> > .__lock_acquire+0x638/0x1c20
> > [ 117.027270] [c003a7c7b1b0] [c013b480]
> > .lock_acquire+0xb0/0x250
> > [ 117.027296] [c003a7c7b290] [c093a1cc]
> > ._raw_spin_lock+0x5c/0xc0
> > [ 117.027321] [c003a7c7b320] [c064effc] .tg3_timer+0x9c/0x10f0
> > [ 117.027345] [c003a7c7b3d0] [c00bbd0c]
> > .call_timer_fn+0xbc/0x3e0
> > [ 117.027369] [c003a7c7b4b0] [c00bc328]
> > .run_timer_softirq+0x2f8/0x440
> > [ 117.027398] [c003a7c7b5c0] [c00afef8]
> > .__do_softirq+0x1b8/0x540
> > [ 117.027423] [c003a7c7b6f0] [c00b04e8] .irq_exit+0xe8/0x100
> > [ 117.027448] [c003a7c7b770] [c0020464]
> > .timer_interrupt+0x174/0x510
> > [ 117.027477] [c003a7c7b830] [c00024f4]
> > decrementer_common+0x174/0x180
> > [ 117.027509] --- Exception: 901 at .plpar_hcall_norets+0x84/0xd4
> > LR = .check_and_cede_processor+0x48/0x80
> > [ 117.027544] [c003a7c7bb20] [c0085168]
> > .check_and_cede_processor+0x18/0x80 (unreliable)
> > [ 117.027577] [c003a7c7bb90] [c0085258]
> > .dedicated_cede_loop+0x88/0x150
> > [ 117.027606] [c003a7c7bc50] [c075808c]
> > .cpuidle_enter+0x2c/0x40
> > [ 117.027632] [c003a7c7bcc0] [c07589bc]
> > .cpuidle_idle_call+0xfc/0x4e0
> > [ 117.027660] [c003a7c7bd70] [c0074be8] .pSeries_idle+0x18/0x40
> > [ 117.027685] [c003a7c7bde0] [c0018ec0] .cpu_idle+0x180/0x360
> > [ 117.027711] [c003a7c7bea0] [c095391c]
> > .start_secondary+0x534/0x53c
> > [ 117.027739] [c003a7c7bf90] [c00097fc]
> > .start_secondary_prolog+0x10/0x14
> >
>
> It might be related to this commit. Can you revert and try it.
With commit d6d3c4e656513dcea61ce900f0ecb9ca820ee7cd reverted, I do not see the
message above, but I do see:
[
[PATCH] ext4: unregister extents status shrinker if mount failed
If ext4_fill_super() failed after extents status shrinker
has been registered, the shrinker is left in a global list
while the memory, it sits in, is already freed.
Oops is not so bad scenario after that.
Found by Linux File System Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
fs/ext4/super.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 5d6d5357..5f9cb30 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3757,7 +3757,7 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_MMP) &&
!(sb->s_flags & MS_RDONLY))
if (ext4_multi_mount_protect(sb, le64_to_cpu(es->s_mmp_block)))
- goto failed_mount3;
+ goto failed_mount_shr;
/*
* The first inode we look at is the journal inode. Don't try
@@ -3766,7 +3766,7 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
if (!test_opt(sb, NOLOAD) &&
EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_HAS_JOURNAL)) {
if (ext4_load_journal(sb, es, journal_devnum))
- goto failed_mount3;
+ goto failed_mount_shr;
} else if (test_opt(sb, NOLOAD) && !(sb->s_flags & MS_RDONLY) &&
EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_RECOVER)) {
ext4_msg(sb, KERN_ERR, "required journal recovery "
@@ -4009,6 +4009,8 @@ failed_mount_wq:
jbd2_journal_destroy(sbi->s_journal);
sbi->s_journal = NULL;
}
+failed_mount_shr:
+ ext4_es_unregister_shrinker(sb);
failed_mount3:
del_timer(&sbi->s_err_report);
if (sbi->s_flex_groups)
--
1.7.9.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] x86: Add check for P5 to microcode_intel_early
On 04/19/2013 02:44 PM, Bryan O'Donoghue wrote:
> On 19/04/13 22:25, Borislav Petkov wrote:
>> On Fri, Apr 19, 2013 at 10:55:15PM +0200, Borislav Petkov wrote:
>>> Just filter out P5 and earlier. The code already does that for CPUs
>>> which don't have CPUID.
>>
>> Actually, an alternative - more practical albeit not very accurate
>
> More practical ? Hmm - the MSRs don't exist for < P5
Yes, and that is definitional.
I like doing this check before boring down in the code too far, however,
I want to make it so that it is structurally clear that this is for
Intel; other CPU vendors might theoretically have other criteria.
Architecturally, I would prefer to do this check early in
load_ucode_intel_{bsp,ap}() but I would be okay with putting it in
load_ucode_bsp()/local_ucode_ap() as well as long as the test is
conditional on the Intel vendor check.
More importantly, though: I really would like to get a fix *today*.
-hpa
--
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 -next] ceph: fix printk format warnings in file.c
Applied, thanks!
sage
On Fri, 19 Apr 2013, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix printk format warnings by using %zd for 'ssize_t' variables:
>
> fs/ceph/file.c:751:2: warning: format '%ld' expects argument of type 'long
> int', but argument 11 has type 'ssize_t' [-Wformat]
> fs/ceph/file.c:762:2: warning: format '%ld' expects argument of type 'long
> int', but argument 11 has type 'ssize_t' [-Wformat]
>
> Signed-off-by: Randy Dunlap
> Cc: Sage Weil
> Cc: ceph-de...@vger.kernel.org
> ---
> fs/ceph/file.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-next-20130419.orig/fs/ceph/file.c
> +++ linux-next-20130419/fs/ceph/file.c
> @@ -748,7 +748,7 @@ retry_snap:
> goto out;
> }
>
> - dout("aio_write %p %llx.%llx %llu~%ld getting caps. i_size %llu\n",
> + dout("aio_write %p %llx.%llx %llu~%zd getting caps. i_size %llu\n",
>inode, ceph_vinop(inode), pos, count, inode->i_size);
> if (fi->fmode & CEPH_FILE_MODE_LAZY)
> want = CEPH_CAP_FILE_BUFFER | CEPH_CAP_FILE_LAZYIO;
> @@ -759,7 +759,7 @@ retry_snap:
> if (err < 0)
> goto out;
>
> - dout("aio_write %p %llx.%llx %llu~%ld got cap refs on %s\n",
> + dout("aio_write %p %llx.%llx %llu~%zd got cap refs on %s\n",
>inode, ceph_vinop(inode), pos, count, ceph_cap_string(got));
>
> if ((got & (CEPH_CAP_FILE_BUFFER|CEPH_CAP_FILE_LAZYIO)) == 0 ||
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
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 v9 00/12] Driver for Si476x series of chips
On Fri, Apr 19, 2013 at 2:31 PM, Samuel Ortiz wrote: > Hi Andrey, > > On Thu, Apr 18, 2013 at 09:58:26AM -0700, Andrey Smirnov wrote: >> Driver for Si476x series of chips >> >> This is a eight version of the patchset originaly posted here: >> https://lkml.org/lkml/2012/9/13/590 >> >> Second version of the patch was posted here: >> https://lkml.org/lkml/2012/10/5/598 >> >> Third version of the patch was posted here: >> https://lkml.org/lkml/2012/10/23/510 >> >> Fourth version of the patch was posted here: >> https://lkml.org/lkml/2013/2/18/572 >> >> Fifth version of the patch was posted here: >> https://lkml.org/lkml/2013/2/26/45 >> >> Sixth version of the patch was posted here: >> https://lkml.org/lkml/2013/2/26/257 >> >> Seventh version of the patch was posted here: >> https://lkml.org/lkml/2013/2/27/22 >> >> Eighth version of the patch was posted here: >> https://lkml.org/lkml/2013/3/26/891 >> >> To save everyone's time I'll repost the original description of it: >> >> This patchset contains a driver for a Silicon Laboratories 476x series >> of radio tuners. The driver itself is implemented as an MFD devices >> comprised of three parts: >> 1. Core device that provides all the other devices with basic >> functionality and locking scheme. >> 2. Radio device that translates between V4L2 subsystem requests into >> Core device commands. >> 3. Codec device that does similar to the earlier described task, but >> for ALSA SoC subsystem. >> >> v9 of this driver has following changes: >>- MFD part of the driver no longer depends on the header file added >> by the radio driver(media/si476x.h) which should potential >> restore the bisectability of the patches > I applied all the MFD patches from this patchset (All 4 first ones), plus a > follow up one for fixing the i2c related warning. > I also squashed the REGMAP_I2C dependency into patch #4. > It's all in mfd-next now, I'd appreciate if you could double check it's all > fine. > > Mauro will take the rest, we made sure there won't be any merge conflict > between our trees. > Thanks, I will try to test it today or tomorrow(20/04) at the latest. > Cheers, > Samuel. > > -- > Intel Open Source Technology Centre > http://oss.intel.com/ -- 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 documentation 1/2] nohz1: Add documentation.
On Fri, Apr 19, 2013 at 02:01:49PM -0700, Kevin Hilman wrote: > "Paul E. McKenney" writes: > > > +KNOWN ISSUES > > [...] > > > +o Unless all CPUs are idle, at least one CPU must keep the > > + scheduling-clock interrupt going in order to support accurate > > + timekeeping. > > At least with the implementation I'm using (Frederic's 3.9-nohz1 > branch), at least one CPU is forced to stay out of dyntick-idle > *always*, even if all CPUs are idle. > > IMO, this is important to list as a known issue since this will have > its own power implications when the system is mostly idle. Good point! I added the following at the end of the known issues: o If there are adaptive-ticks CPUs, there will be at least one CPU keeping the scheduling-clock interrupt going, even if all CPUs are otherwise idle. > Otherwise, document looks great. > > Reviewed-by: Kevin Hilman Added, thank you for the review and comments! Thanx, Paul -- 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 v3] tracepoints: prevents null probe from being added
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Mon, 2013-04-15 at 11:13 +0900, kpark3...@gmail.com wrote:
> > From: Sahara
> >
> > Somehow tracepoint_entry_add_probe function allows a null probe function.
> > And, this may lead to unexpected result since the number of probe
> > functions in an entry can be counted by checking whether probe is null
> > or not in for-loop.
> > This patch prevents the null probe from being added.
> > In tracepoint_entry_remove_probe function, checking probe parameter
> > within for-loop is moved out for code efficiency leaving the null probe
> > feature which removes all probe functions in the entry.
> >
> > Signed-off-by: Sahara
> > Reviewed-by: Steven Rostedt
> > Reviewed-by: Mathieu Desnoyers
>
> BTW, do not add tags that were not given to you. "Reviewed-by" has a
> meaning, more than just someone that reviewed your patch. It means that
> they not only reviewed your patch but couldn't find anything wrong with
> it. As both Mathieu and I had comments, that does not deserve a
> "Reviewed-by" tag.
>
> I'm not even sure that Mathieu gave an "Acked-by". I thought he did, but
> I can't seem to find it. Mathieu?
I don't recall, but all my comments were addressed. In order to clear
any confusion:
Reviewed-by: Mathieu Desnoyers
Acked-by: Mathieu Desnoyers
Thanks,
Mathieu
>
> Anyway, I'll start testing this patch as it seems fine with me (although
> I still wouldn't give a Reviewed-by tag).
>
> Thanks,
>
> -- Steve
>
> > ---
> > kernel/tracepoint.c | 21 +
> > 1 files changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
> > index 0c05a45..29f2654 100644
> > --- a/kernel/tracepoint.c
> > +++ b/kernel/tracepoint.c
> > @@ -112,7 +112,8 @@ tracepoint_entry_add_probe(struct tracepoint_entry
> > *entry,
> > int nr_probes = 0;
> > struct tracepoint_func *old, *new;
> >
> > - WARN_ON(!probe);
> > + if (WARN_ON(!probe))
> > + return ERR_PTR(-EINVAL);
> >
> > debug_print_probes(entry);
> > old = entry->funcs;
> > @@ -152,13 +153,18 @@ tracepoint_entry_remove_probe(struct tracepoint_entry
> > *entry,
> >
> > debug_print_probes(entry);
> > /* (N -> M), (N > 1, M >= 0) probes */
> > - for (nr_probes = 0; old[nr_probes].func; nr_probes++) {
> > - if (!probe ||
> > - (old[nr_probes].func == probe &&
> > -old[nr_probes].data == data))
> > - nr_del++;
> > + if (probe) {
> > + for (nr_probes = 0; old[nr_probes].func; nr_probes++) {
> > + if (old[nr_probes].func == probe &&
> > +old[nr_probes].data == data)
> > + nr_del++;
> > + }
> > }
> >
> > + /*
> > +* If probe is NULL, then nr_probes = nr_del = 0, and then the
> > +* entire entry will be removed.
> > +*/
> > if (nr_probes - nr_del == 0) {
> > /* N -> 0, (N > 1) */
> > entry->funcs = NULL;
> > @@ -173,8 +179,7 @@ tracepoint_entry_remove_probe(struct tracepoint_entry
> > *entry,
> > if (new == NULL)
> > return ERR_PTR(-ENOMEM);
> > for (i = 0; old[i].func; i++)
> > - if (probe &&
> > - (old[i].func != probe || old[i].data != data))
> > + if (old[i].func != probe || old[i].data != data)
> > new[j++] = old[i];
> > new[nr_probes - nr_del].func = NULL;
> > entry->refcount = nr_probes - nr_del;
>
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
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] x86: Add check for P5 to microcode_intel_early
On 19/04/13 22:25, Borislav Petkov wrote:
On Fri, Apr 19, 2013 at 10:55:15PM +0200, Borislav Petkov wrote:
Just filter out P5 and earlier. The code already does that for CPUs
which don't have CPUID.
Actually, an alternative - more practical albeit not very accurate
More practical ? Hmm - the MSRs don't exist for < P5
solution would be to check for which families Intel delivers microcode
and do the cut off there with a comment as to why you do it like that.void
You mean return !intel so this function will never be called.
__init load_ucode_bsp(void)
{
int vendor = x86_vendor();
if (vendor == X86_VENDOR_INTEL)
load_ucode_intel_bsp();
}
Ah yes. That would work and be less code.
We should do it that way.
--
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: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]
On Fri, Apr 19, 2013 at 02:24:10PM -0700, Linus Torvalds wrote: > On Fri, Apr 19, 2013 at 2:09 PM, Sedat Dilek wrote: > > > > I have applied all three patches and see still call-traces. > > New are apparmor related messages. > > Can you try the crazy rcu double-free debug hack? > > See > > https://lkml.org/lkml/2013/3/30/113 > > and I'm re-attaching the ugly-ass crazy hack patch here too.. > > Linus For whatever it is worth, CONFIG_DEBUG_OBJECTS_RCU_HEAD=y is intended to detect RCU double-freeing. But if it isn't helping for whatever reason, please let me know! Thanx, Paul -- 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 v3] tracepoints: prevents null probe from being added
On Mon, 2013-04-15 at 11:13 +0900, kpark3...@gmail.com wrote:
> From: Sahara
>
> Somehow tracepoint_entry_add_probe function allows a null probe function.
> And, this may lead to unexpected result since the number of probe
> functions in an entry can be counted by checking whether probe is null
> or not in for-loop.
> This patch prevents the null probe from being added.
> In tracepoint_entry_remove_probe function, checking probe parameter
> within for-loop is moved out for code efficiency leaving the null probe
> feature which removes all probe functions in the entry.
>
> Signed-off-by: Sahara
> Reviewed-by: Steven Rostedt
> Reviewed-by: Mathieu Desnoyers
BTW, do not add tags that were not given to you. "Reviewed-by" has a
meaning, more than just someone that reviewed your patch. It means that
they not only reviewed your patch but couldn't find anything wrong with
it. As both Mathieu and I had comments, that does not deserve a
"Reviewed-by" tag.
I'm not even sure that Mathieu gave an "Acked-by". I thought he did, but
I can't seem to find it. Mathieu?
Anyway, I'll start testing this patch as it seems fine with me (although
I still wouldn't give a Reviewed-by tag).
Thanks,
-- Steve
> ---
> kernel/tracepoint.c | 21 +
> 1 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
> index 0c05a45..29f2654 100644
> --- a/kernel/tracepoint.c
> +++ b/kernel/tracepoint.c
> @@ -112,7 +112,8 @@ tracepoint_entry_add_probe(struct tracepoint_entry *entry,
> int nr_probes = 0;
> struct tracepoint_func *old, *new;
>
> - WARN_ON(!probe);
> + if (WARN_ON(!probe))
> + return ERR_PTR(-EINVAL);
>
> debug_print_probes(entry);
> old = entry->funcs;
> @@ -152,13 +153,18 @@ tracepoint_entry_remove_probe(struct tracepoint_entry
> *entry,
>
> debug_print_probes(entry);
> /* (N -> M), (N > 1, M >= 0) probes */
> - for (nr_probes = 0; old[nr_probes].func; nr_probes++) {
> - if (!probe ||
> - (old[nr_probes].func == probe &&
> - old[nr_probes].data == data))
> - nr_del++;
> + if (probe) {
> + for (nr_probes = 0; old[nr_probes].func; nr_probes++) {
> + if (old[nr_probes].func == probe &&
> + old[nr_probes].data == data)
> + nr_del++;
> + }
> }
>
> + /*
> + * If probe is NULL, then nr_probes = nr_del = 0, and then the
> + * entire entry will be removed.
> + */
> if (nr_probes - nr_del == 0) {
> /* N -> 0, (N > 1) */
> entry->funcs = NULL;
> @@ -173,8 +179,7 @@ tracepoint_entry_remove_probe(struct tracepoint_entry
> *entry,
> if (new == NULL)
> return ERR_PTR(-ENOMEM);
> for (i = 0; old[i].func; i++)
> - if (probe &&
> - (old[i].func != probe || old[i].data != data))
> + if (old[i].func != probe || old[i].data != data)
> new[j++] = old[i];
> new[nr_probes - nr_del].func = NULL;
> entry->refcount = nr_probes - nr_del;
--
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 2/2] perf, amd: support for AMD NB and L2I "uncore" counters.
On Fri, Apr 19, 2013 at 08:55:24PM +0200, Peter Zijlstra wrote:
> On Fri, 2013-04-19 at 09:41 -0500, Jacob Shin wrote:
> >
> > Thank you again, for taking the time.
>
> Ah something I just remembered, could you do a patch like the below
> one? That makes things like perf stat -A work as expected.
Ah, okay. Here is V3 that also creates "cpumask" sysfs file. Tested
that the "perf stat -a .." works as expected.
Thanks again,
V3:
- Added "cpumask" attribute to sysfs to get "perf stat -a .." working
correctly
V2:
- Added event migration if possible when CPU goes offline
>From fc8a5328069496187f7749a32acbe319dedbb548 Mon Sep 17 00:00:00 2001
From: Jacob Shin
Date: Sun, 14 Apr 2013 04:12:42 -0500
Subject: [PATCH V3 2/2] perf, amd: support for AMD NB and L2I "uncore" counters.
Add support for AMD Family 15h [and above] northbridge performance
counters. MSRs 0xc0010240 ~ 0xc0010247 are shared across all cores
that share a common northbridge.
Add support for AMD Family 16h L2 performance counters. MSRs
0xc0010230 ~ 0xc0010237 are shared across all cores that share a
common L2 cache.
We do not enable counter overflow interrupts. Sampling mode and
per-thread events are not supported.
Signed-off-by: Jacob Shin
---
arch/x86/include/asm/cpufeature.h |2 +
arch/x86/include/uapi/asm/msr-index.h |4 +
arch/x86/kernel/cpu/Makefile|2 +-
arch/x86/kernel/cpu/perf_event_amd_uncore.c | 546 +++
4 files changed, 553 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/kernel/cpu/perf_event_amd_uncore.c
diff --git a/arch/x86/include/asm/cpufeature.h
b/arch/x86/include/asm/cpufeature.h
index 93fe929..ac10df7 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -168,6 +168,7 @@
#define X86_FEATURE_TOPOEXT(6*32+22) /* topology extensions CPUID leafs */
#define X86_FEATURE_PERFCTR_CORE (6*32+23) /* core performance counter
extensions */
#define X86_FEATURE_PERFCTR_NB (6*32+24) /* NB performance counter extensions
*/
+#define X86_FEATURE_PERFCTR_L2 (6*32+28) /* L2 performance counter extensions
*/
/*
* Auxiliary flags: Linux defined - For features scattered in various
@@ -311,6 +312,7 @@ extern const char * const x86_power_flags[32];
#define cpu_has_pclmulqdq boot_cpu_has(X86_FEATURE_PCLMULQDQ)
#define cpu_has_perfctr_core boot_cpu_has(X86_FEATURE_PERFCTR_CORE)
#define cpu_has_perfctr_nb boot_cpu_has(X86_FEATURE_PERFCTR_NB)
+#define cpu_has_perfctr_l2 boot_cpu_has(X86_FEATURE_PERFCTR_L2)
#define cpu_has_cx8boot_cpu_has(X86_FEATURE_CX8)
#define cpu_has_cx16 boot_cpu_has(X86_FEATURE_CX16)
#define cpu_has_eager_fpu boot_cpu_has(X86_FEATURE_EAGER_FPU)
diff --git a/arch/x86/include/uapi/asm/msr-index.h
b/arch/x86/include/uapi/asm/msr-index.h
index bf7bb68..b575788 100644
--- a/arch/x86/include/uapi/asm/msr-index.h
+++ b/arch/x86/include/uapi/asm/msr-index.h
@@ -196,6 +196,10 @@
#define MSR_AMD64_IBSBRTARGET 0xc001103b
#define MSR_AMD64_IBS_REG_COUNT_MAX8 /* includes MSR_AMD64_IBSBRTARGET */
+/* Fam 16h MSRs */
+#define MSR_F16H_L2I_PERF_CTL 0xc0010230
+#define MSR_F16H_L2I_PERF_CTR 0xc0010231
+
/* Fam 15h MSRs */
#define MSR_F15H_PERF_CTL 0xc0010200
#define MSR_F15H_PERF_CTR 0xc0010201
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index a0e067d..0074572 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -31,7 +31,7 @@ obj-$(CONFIG_CPU_SUP_UMC_32) += umc.o
obj-$(CONFIG_PERF_EVENTS) += perf_event.o
ifdef CONFIG_PERF_EVENTS
-obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd.o
+obj-$(CONFIG_CPU_SUP_AMD) += perf_event_amd.o
perf_event_amd_uncore.o
obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_p6.o perf_event_knc.o
perf_event_p4.o
obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_lbr.o
perf_event_intel_ds.o perf_event_intel.o
obj-$(CONFIG_CPU_SUP_INTEL)+= perf_event_intel_uncore.o
diff --git a/arch/x86/kernel/cpu/perf_event_amd_uncore.c
b/arch/x86/kernel/cpu/perf_event_amd_uncore.c
new file mode 100644
index 000..6dc6227
--- /dev/null
+++ b/arch/x86/kernel/cpu/perf_event_amd_uncore.c
@@ -0,0 +1,546 @@
+/*
+ * Copyright (C) 2013 Advanced Micro Devices, Inc.
+ *
+ * Author: Jacob Shin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define NUM_COUNTERS_NB4
+#define NUM_COUNTERS_L24
+#define MAX_COUNTERS NUM_COUNTERS_NB
+
+#define RDPMC_BASE_NB 6
+#define RDPMC_BASE_L2 10
+
+#define COUNTER_SHIFT 16
+
+struct amd_uncore {
+
Re: [PATCH v9 00/12] Driver for Si476x series of chips
Hi Andrey, On Thu, Apr 18, 2013 at 09:58:26AM -0700, Andrey Smirnov wrote: > Driver for Si476x series of chips > > This is a eight version of the patchset originaly posted here: > https://lkml.org/lkml/2012/9/13/590 > > Second version of the patch was posted here: > https://lkml.org/lkml/2012/10/5/598 > > Third version of the patch was posted here: > https://lkml.org/lkml/2012/10/23/510 > > Fourth version of the patch was posted here: > https://lkml.org/lkml/2013/2/18/572 > > Fifth version of the patch was posted here: > https://lkml.org/lkml/2013/2/26/45 > > Sixth version of the patch was posted here: > https://lkml.org/lkml/2013/2/26/257 > > Seventh version of the patch was posted here: > https://lkml.org/lkml/2013/2/27/22 > > Eighth version of the patch was posted here: > https://lkml.org/lkml/2013/3/26/891 > > To save everyone's time I'll repost the original description of it: > > This patchset contains a driver for a Silicon Laboratories 476x series > of radio tuners. The driver itself is implemented as an MFD devices > comprised of three parts: > 1. Core device that provides all the other devices with basic > functionality and locking scheme. > 2. Radio device that translates between V4L2 subsystem requests into > Core device commands. > 3. Codec device that does similar to the earlier described task, but > for ALSA SoC subsystem. > > v9 of this driver has following changes: >- MFD part of the driver no longer depends on the header file added > by the radio driver(media/si476x.h) which should potential > restore the bisectability of the patches I applied all the MFD patches from this patchset (All 4 first ones), plus a follow up one for fixing the i2c related warning. I also squashed the REGMAP_I2C dependency into patch #4. It's all in mfd-next now, I'd appreciate if you could double check it's all fine. Mauro will take the rest, we made sure there won't be any merge conflict between our trees. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 Resend v6] sched: fix wrong rq's runnable_avg update with rt tasks
On Thu, 2013-04-18 at 18:34 +0200, Vincent Guittot wrote: > The current update of the rq's load can be erroneous when RT tasks are > involved > > The update of the load of a rq that becomes idle, is done only if the avg_idle > is less than sysctl_sched_migration_cost. If RT tasks and short idle duration > alternate, the runnable_avg will not be updated correctly and the time will be > accounted as idle time when a CFS task wakes up. > > A new idle_enter function is called when the next task is the idle function > so the elapsed time will be accounted as run time in the load of the rq, > whatever the average idle time is. The function update_rq_runnable_avg is > removed from idle_balance. > > When a RT task is scheduled on an idle CPU, the update of the rq's load is > not done when the rq exit idle state because CFS's functions are not > called. Then, the idle_balance, which is called just before entering the > idle function, updates the rq's load and makes the assumption that the > elapsed time since the last update, was only running time. > > As a consequence, the rq's load of a CPU that only runs a periodic RT task, > is close to LOAD_AVG_MAX whatever the running duration of the RT task is. > > A new idle_exit function is called when the prev task is the idle function > so the elapsed time will be accounted as idle time in the rq's load. > > Changes since V5: > - Rename idle_enter/exit function to idle_enter/exit_fair > > Changes since V4: > - Rebase on v3.9-rc6 instead of Steven Rostedt's patches Acked-by: Steven Rostedt -- Steve > - Create the post_schedule_idle function that was previously created by > Steven's patches > > Changes since V3: > - Remove dependancy with CONFIG_FAIR_GROUP_SCHED > - Add a new idle_enter function and create a post_schedule callback for > idle class > - Remove the update_runnable_avg from idle_balance > > Changes since V2: > - remove useless definition for UP platform > - rebased on top of Steven Rostedt's patches : > https://lkml.org/lkml/2013/2/12/558 > > Changes since V1: > - move code out of schedule function and create a pre_schedule callback for > idle class instead. > > Signed-off-by: Vincent Guittot > --- -- 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] x86: Add check for P5 to microcode_intel_early
On Fri, Apr 19, 2013 at 10:55:15PM +0200, Borislav Petkov wrote: > Just filter out P5 and earlier. The code already does that for CPUs > which don't have CPUID. Actually, an alternative - more practical albeit not very accurate solution would be to check for which families Intel delivers microcode and do the cut off there with a comment as to why you do it like that. I very much doubt, Intel will add microcode for *older* families to the package :-). IOW, in the linux intel-microcode package we currently have: $ tree /lib/firmware/intel-ucode/ ├── 06-0f-02 ├── 06-0f-06 ├── 06-0f-07 ├── 06-0f-0a ├── 06-0f-0b ├── 06-0f-0d ├── 06-16-01 ├── 06-17-06 ├── 06-17-07 ├── 06-17-0a ├── 06-1a-04 ├── 06-1c-02 ├── 06-1c-0a ├── 06-1d-01 ├── 06-1e-04 ├── 06-1e-05 ├── 06-25-02 ├── 06-25-05 ├── 06-2a-07 ├── 06-2d-06 ├── 06-2d-07 ├── 06-2f-02 ├── 06-3a-09 ├── 0f-04-01 ├── 0f-04-03 ├── 0f-04-04 ├── 0f-04-07 ├── 0f-04-08 ├── 0f-04-09 ├── 0f-04-0a ├── 0f-06-02 ├── 0f-06-04 ├── 0f-06-05 └── 0f-06-08 So < 6 should be fine. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]
On Fri, Apr 19, 2013 at 2:09 PM, Sedat Dilek wrote: > > I have applied all three patches and see still call-traces. > New are apparmor related messages. Can you try the crazy rcu double-free debug hack? See https://lkml.org/lkml/2013/3/30/113 and I'm re-attaching the ugly-ass crazy hack patch here too.. Linus rcu-double-free-hack.patch Description: Binary data
Re: [PATCH] i2c-designware: fix RX FIFO overrun
It does. The bug appears with fairly-sized read transactions (in the order of kB) returning corrupted data. Josef > Josef. > > This fixes a real bug for us does it not, some failure case with a > sustained amount of traffic ? > > > Bryan > > -- 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 -next] ceph: fix printk format warnings in file.c
From: Randy Dunlap
Fix printk format warnings by using %zd for 'ssize_t' variables:
fs/ceph/file.c:751:2: warning: format '%ld' expects argument of type 'long
int', but argument 11 has type 'ssize_t' [-Wformat]
fs/ceph/file.c:762:2: warning: format '%ld' expects argument of type 'long
int', but argument 11 has type 'ssize_t' [-Wformat]
Signed-off-by: Randy Dunlap
Cc: Sage Weil
Cc: ceph-de...@vger.kernel.org
---
fs/ceph/file.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20130419.orig/fs/ceph/file.c
+++ linux-next-20130419/fs/ceph/file.c
@@ -748,7 +748,7 @@ retry_snap:
goto out;
}
- dout("aio_write %p %llx.%llx %llu~%ld getting caps. i_size %llu\n",
+ dout("aio_write %p %llx.%llx %llu~%zd getting caps. i_size %llu\n",
inode, ceph_vinop(inode), pos, count, inode->i_size);
if (fi->fmode & CEPH_FILE_MODE_LAZY)
want = CEPH_CAP_FILE_BUFFER | CEPH_CAP_FILE_LAZYIO;
@@ -759,7 +759,7 @@ retry_snap:
if (err < 0)
goto out;
- dout("aio_write %p %llx.%llx %llu~%ld got cap refs on %s\n",
+ dout("aio_write %p %llx.%llx %llu~%zd got cap refs on %s\n",
inode, ceph_vinop(inode), pos, count, ceph_cap_string(got));
if ((got & (CEPH_CAP_FILE_BUFFER|CEPH_CAP_FILE_LAZYIO)) == 0 ||
--
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 -next] nilfs2: fix printk format warning in page.c
From: Randy Dunlap
Fix printk format warning by using %zu for 'size_t':
fs/nilfs2/page.c:430:6: warning: format '%lu' expects argument of type 'long
unsigned int', but argument 5 has type 'size_t' [-Wformat]
Signed-off-by: Randy Dunlap
Cc: KONISHI Ryusuke
Cc: linux-ni...@vger.kernel.org
---
fs/nilfs2/page.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20130419.orig/fs/nilfs2/page.c
+++ linux-next-20130419/fs/nilfs2/page.c
@@ -426,7 +426,7 @@ void nilfs_clear_dirty_page(struct page
lock_buffer(bh);
if (!silent) {
nilfs_warning(sb, __func__,
- "discard block %llu, size %lu",
+ "discard block %llu, size %zu",
(u64)bh->b_blocknr, bh->b_size);
}
clear_buffer_dirty(bh);
--
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 documentation 1/2] nohz1: Add documentation.
"Paul E. McKenney" writes: > +KNOWN ISSUES [...] > +oUnless all CPUs are idle, at least one CPU must keep the > + scheduling-clock interrupt going in order to support accurate > + timekeeping. At least with the implementation I'm using (Frederic's 3.9-nohz1 branch), at least one CPU is forced to stay out of dyntick-idle *always*, even if all CPUs are idle. IMO, this is important to list as a known issue since this will have its own power implications when the system is mostly idle. Otherwise, document looks great. Reviewed-by: Kevin Hilman Kevin -- 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 09/10] cpuset: allow to keep tasks in empty cpusets
Hello,
On Fri, Apr 19, 2013 at 08:29:24PM +0800, Li Zefan wrote:
> +static void update_tasks_cpumask_hier(struct cpuset *root_cs,
> + bool update_root, struct ptr_heap *heap)
> +{
> + struct cpuset *cp;
> + struct cgroup *pos_cgrp;
> +
> + if (update_root)
> + update_tasks_cpumask(root_cs, heap);
> +
> + rcu_read_lock();
> + cpuset_for_each_descendant_pre(cp, pos_cgrp, root_cs) {
> + /* skip the whole subtree if @cp have some CPU */
> + if (!cpumask_empty(cp->cpus_allowed)) {
> + pos_cgrp = cgroup_rightmost_descendant(pos_cgrp);
> + continue;
> + }
> +
> + update_tasks_cpumask(cp, heap);
> + }
> + rcu_read_unlock();
I don't think we can call update_tasks_cpumask() under
rcu_read_lock(). It calls into set_cpus_allowed_ptr() which may
block, so you'll probably have to punt it to a work item like how
migration is being done. Another approach would be converting cgroup
to use SRCU instead, which would lessen pain on other places too. The
only problem there would be that srcu_read_lock() is a bit more
expensive than rcu_read_lock(). I'm not sure whether that'd show up
in some hot path or not. Ideas?
Thanks.
--
tejun
--
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 net] hyperv: Fix a compiler warning in netvsc_send()
> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Friday, April 19, 2013 4:50 PM > To: Haiyang Zhang > Cc: net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de; > jasow...@redhat.com; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org > Subject: Re: [PATCH net] hyperv: Fix a compiler warning in netvsc_send() > > From: Haiyang Zhang > Date: Tue, 16 Apr 2013 15:25:50 -0700 > > > Fixed: warning: cast from pointer to integer of different size > > > > The Hyper-V hosts always use 64 bit request id. The guests can have 32 > > or 64 bit pointers which equal to the ulong type size. So we cast it to > > ulong > type. > > And, assigning 32bit integer to 64 bit variable works fine. > > > > The VMBus returns the same id in the completion packet. But the value > > has no effect on the host side. > > > > Reported-by: kbuild test robot > > Signed-off-by: Haiyang Zhang > > Reviewed-by: K. Y. Srinivasan > > Such build warning fixes are not appropriate for 'net' at this time, and this > patch does not apply to 'net-next', so I'm dropping this entirely. OK. I will re-submit it to net-next after the recent patch causing the warning is merged into the net-next tree. Thanks, - Haiyang -- 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] x86: Add check for P5 to microcode_intel_early
On Fri, Apr 19, 2013 at 09:35:18PM +0100, Bryan O'Donoghue wrote: > Just returning X86_VENDOR_UNKNOWN - won't fix the bug though - after > all MSR_IA32_UCODE_REV is also x86_family() >= 6 What are you talking about? If you return X86_VENDOR_UNKNOWN from x86_vendor(), load_ucode_intel_bsp() and load_ucode_intel_ap() won't be called and no non-existing MSRs will be accessed. Just filter out P5 and earlier. The code already does that for CPUs which don't have CPUID. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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: mdadm raid1 regression
On Thu, Apr 18, 2013 at 02:38:53PM +0400, Vasiliy Tolstov wrote: > Hello. I'm using linux 3.8.6 and mdadm 3.2.6 (from git). > I have many raid1 arrays that have data offset 2048 (metadata 1.2, > created with various mdadm versions but mostly 3.2.1 on linux 2.6.32). > If i create raid1 with never mdadm on 3.8.6 i have data offset 8192?? Why? Please try asking this on the mailing list for the raid developers (linux-r...@vger.kernel.org). -- 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 net] hyperv: Fix a compiler warning in netvsc_send()
From: Haiyang Zhang Date: Tue, 16 Apr 2013 15:25:50 -0700 > Fixed: warning: cast from pointer to integer of different size > > The Hyper-V hosts always use 64 bit request id. The guests can have 32 or 64 > bit pointers which equal to the ulong type size. So we cast it to ulong type. > And, assigning 32bit integer to 64 bit variable works fine. > > The VMBus returns the same id in the completion packet. But the value has no > effect on the host side. > > Reported-by: kbuild test robot > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan Such build warning fixes are not appropriate for 'net' at this time, and this patch does not apply to 'net-next', so I'm dropping this entirely. -- 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] x86: Add check for P5 to microcode_intel_early
On 19/04/13 20:11, Borislav Petkov wrote:
On Fri, Apr 19, 2013 at 06:23:03PM +0100, Bryan O'Donoghue wrote:
Architectural MSRs associated with microcode are for P6 or higher.
Add a check to early microcode to detect< P6.
Without a check for< P6 - we end up reading from unimplemented MSRs
on Pentium.
Is this something you're actually seeing on some box or just found by
staring at the code?
We actually see this on a P5 alright.
The code path is reachable, no question.
In any case, the family checks should go into the ucode driver entry
points in arch/x86/kernel/microcode_core_early.c. AFAICT, x86_vendor()
is a good candidate to be taught to read out the family too and return
X86_VENDOR_UNKNOWN if< P6. Or something to that effect.
Hmm
Just returning X86_VENDOR_UNKNOWN - won't fix the bug though - after all
MSR_IA32_UCODE_REV is also x86_family() >= 6
x86 = get_x86_family(csig.sig);
x86_model = get_x86_model(csig.sig);
if (x86 < 6)
return UCODE_ERROR;
if ((x86_model >= 5) || (x86 > 6)) {
/* get processor flags from MSR 0x17 */
native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
csig.pf = 1 << ((val[1] >> 18) & 7);
}
native_wrmsr(MSR_IA32_UCODE_REV, 0, 0);
/* As documented in the SDM: Do a CPUID 1 here */
sync_core();
/* get the current revision from MSR 0x8B */
native_rdmsr(MSR_IA32_UCODE_REV, val[0], val[1]);
Peter - what's your take ?
--
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] Fix prototype definitions of sha256_transform_asm, sha512_transform_asm
Herbert, This is a follow on patch to the optimized sha256 and sha512 patch series that's just merged into the crypto-dev. Let me know if you prefer me to respin the patch series. This patch corrects the prototype of sha256_transform_asm and sha512_transform_asm function pointer declaration to static. It also fixes a typo in sha512_ssse3_final function that affects the computation of upper 64 bits of the buffer size. Thanks. Tim Signed-off-by: Tim Chen --- arch/x86/crypto/sha256_ssse3_glue.c | 2 +- arch/x86/crypto/sha512_ssse3_glue.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/crypto/sha256_ssse3_glue.c b/arch/x86/crypto/sha256_ssse3_glue.c index fa65453..8a0b711 100644 --- a/arch/x86/crypto/sha256_ssse3_glue.c +++ b/arch/x86/crypto/sha256_ssse3_glue.c @@ -53,7 +53,7 @@ asmlinkage void sha256_transform_rorx(const char *data, u32 *digest, u64 rounds); #endif -asmlinkage void (*sha256_transform_asm)(const char *, u32 *, u64); +static void (*sha256_transform_asm)(const char *, u32 *, u64); static int sha256_ssse3_init(struct shash_desc *desc) diff --git a/arch/x86/crypto/sha512_ssse3_glue.c b/arch/x86/crypto/sha512_ssse3_glue.c index 295f790..3c844f2 100644 --- a/arch/x86/crypto/sha512_ssse3_glue.c +++ b/arch/x86/crypto/sha512_ssse3_glue.c @@ -52,7 +52,7 @@ asmlinkage void sha512_transform_rorx(const char *data, u64 *digest, u64 rounds); #endif -asmlinkage void (*sha512_transform_asm)(const char *, u64 *, u64); +static void (*sha512_transform_asm)(const char *, u64 *, u64); static int sha512_ssse3_init(struct shash_desc *desc) @@ -141,7 +141,7 @@ static int sha512_ssse3_final(struct shash_desc *desc, u8 *out) /* save number of bits */ bits[1] = cpu_to_be64(sctx->count[0] << 3); - bits[0] = cpu_to_be64(sctx->count[1] << 3) | sctx->count[0] >> 61; + bits[0] = cpu_to_be64(sctx->count[1] << 3 | sctx->count[0] >> 61); /* Pad out to 112 mod 128 and append length */ index = sctx->count[0] & 0x7f; -- 1.7.11.7 -- 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: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]
On Fri, 2013-04-19 at 15:19 -0400, Rik van Riel wrote: > On 04/19/2013 02:53 PM, Sedat Dilek wrote: > > On Fri, Apr 19, 2013 at 6:43 PM, Sedat Dilek wrote: > > > >> I tried to switch from SLUB to SLAB... > >> > >> ...and also from VIRT_CPU_ACCOUNTING_GEN to TICK_CPU_ACCOUNTING. > >> > >> 2x NOPE. > >> > >> In one kernel-build I saw in my console... > >> > >> semop(1): encountered an error: Identifier removed This looks like what Emmanuel was/is running into: https://lkml.org/lkml/2013/3/30/1 > >> > >> ...if this says sth. to you. > >> > > [ CC folks from below thread ] > > > > I have found a thread called "Re: ipc,sem: sysv semaphore scalability" > > on LKML with a screenshot that shows the same call-trace. > > I followed it a bit. > > There is a patch in [3]... unconfirmed. > > > > Comments on the rcu read-lock and "sem_lock()" vs "sem_unlock()" from Linus. > > > > What's the status of this discussion? > > > > - Sedat - > > > > [1] https://lkml.org/lkml/2013/3/30/6 > > [2] http://i.imgur.com/uk6gmq1.jpg > > [3] https://lkml.org/lkml/2013/3/31/12 > > [4] https://lkml.org/lkml/2013/3/31/77 > > > I am at a conference right now, but when I get > back I will check linux-next vs. all the fixes from > the semaphore scalability email thread. I'm back from the collab. summit, so AFAICT these still need to go in linux-next: ipc,sem: untangle RCU locking with find_alloc_undo: https://lkml.org/lkml/2013/3/28/275 ipc,sem: fix lockdep false positive: https://lkml.org/lkml/2013/3/29/119 ipc, sem: do not call sem_lock when bogus sma: https://lkml.org/lkml/2013/3/31/12 Thanks, Davidlohr -- 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: [tpmdd-devel] [PATCH v2] drivers/tpm: add xen tpmfront interface
Hi Daniel - this looks good, only one minor comment below...
On Thu, Apr 11, 2013 at 10:56:01AM -0400, Daniel De Graaf wrote:
> This is a complete rewrite of the Xen TPM frontend driver, taking
> advantage of a simplified frontend/backend interface and adding support
> for cancellation and timeouts. The backend for this driver is provided
> by a vTPM stub domain using the interface in Xen 4.3.
>
> Signed-off-by: Daniel De Graaf
> Acked-by: Matthew Fioravante
> ---
>
> Changes from v1:
> - Add locality sysfs attribute
>
> Documentation/xen-tpmfront.txt | 116 ++
> drivers/char/tpm/Kconfig | 11 +
> drivers/char/tpm/Makefile| 1 +
> drivers/char/tpm/xen-tpmfront.c | 460
> +++
> include/xen/interface/io/tpmif.h | 50 +
> 5 files changed, 638 insertions(+)
> create mode 100644 Documentation/xen-tpmfront.txt
> create mode 100644 drivers/char/tpm/xen-tpmfront.c
> create mode 100644 include/xen/interface/io/tpmif.h
>
> diff --git a/Documentation/xen-tpmfront.txt b/Documentation/xen-tpmfront.txt
> diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
> index a3736c9..eb41ff9 100644
> --- a/drivers/char/tpm/Makefile
> +++ b/drivers/char/tpm/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_TCG_ATMEL) += tpm_atmel.o
> obj-$(CONFIG_TCG_INFINEON) += tpm_infineon.o
> obj-$(CONFIG_TCG_IBMVTPM) += tpm_ibmvtpm.o
> obj-$(CONFIG_TCG_ST33_I2C) += tpm_i2c_stm_st33.o
> +obj-$(CONFIG_TCG_XEN) += xen-tpmfront.o
> diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
> new file mode 100644
> index 000..6801937
> --- /dev/null
> +++ b/drivers/char/tpm/xen-tpmfront.c
> @@ -0,0 +1,460 @@
> +/*
> + * Implementation of the Xen vTPM device frontend
> + *
> + * Author: Daniel De Graaf
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2,
> + * as published by the Free Software Foundation.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "tpm.h"
> +
> +struct tpm_private {
> + struct tpm_chip *chip;
> + struct xenbus_device *dev;
> +
> + struct vtpm_shared_page *shr;
> +
> + unsigned int evtchn;
> + int ring_ref;
> + domid_t backend_id;
> +};
> +
> +enum status_bits {
> + VTPM_STATUS_RUNNING = 0x1,
> + VTPM_STATUS_IDLE = 0x2,
> + VTPM_STATUS_RESULT = 0x4,
> + VTPM_STATUS_CANCELED = 0x8,
> +};
> +
> +static u8 vtpm_status(struct tpm_chip *chip)
> +{
> + struct tpm_private *priv = TPM_VPRIV(chip);
> + switch (priv->shr->state) {
> + case VTPM_STATE_IDLE:
> + return VTPM_STATUS_IDLE | VTPM_STATUS_CANCELED;
> + case VTPM_STATE_FINISH:
> + return VTPM_STATUS_IDLE | VTPM_STATUS_RESULT;
> + case VTPM_STATE_SUBMIT:
> + case VTPM_STATE_CANCEL: /* cancel requested, not yet canceled */
> + return VTPM_STATUS_RUNNING;
> + default:
> + return 0;
> + }
> +}
> +
> +static bool vtpm_req_canceled(struct tpm_chip *chip, u8 status)
> +{
> + return status & VTPM_STATUS_CANCELED;
> +}
> +
> +static void vtpm_cancel(struct tpm_chip *chip)
> +{
> + struct tpm_private *priv = TPM_VPRIV(chip);
> + priv->shr->state = VTPM_STATE_CANCEL;
> + notify_remote_via_evtchn(priv->evtchn);
> +}
> +
> +static int vtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
> +{
> + struct tpm_private *priv = TPM_VPRIV(chip);
> + struct vtpm_shared_page *shr = priv->shr;
> + unsigned int offset = sizeof(*shr) + 4*shr->nr_extra_pages;
It looks like 4 should be sizeof(u32). You also might consider making
a macro for the value of offset since you use it in a few places.
Thanks,
Kent
> +
> + u32 ordinal;
> + unsigned long duration;
> +
> + if (count < TPM_HEADER_SIZE)
> + return -EIO;
> +
> + if (offset > PAGE_SIZE)
> + return -EIO;
> +
> + if (offset + count > PAGE_SIZE)
> + return -EIO;
> +
> + /* Wait for completion of any existing command or cancellation */
> + if (wait_for_tpm_stat(chip, VTPM_STATUS_IDLE, chip->vendor.timeout_c,
> + &chip->vendor.read_queue, true) < 0) {
> + vtpm_cancel(chip);
> + return -ETIME;
> + }
> +
> + memcpy(offset + (u8 *)shr, buf, count);
> + shr->length = count;
> + barrier();
> + shr->state = VTPM_STATE_SUBMIT;
> + notify_remote_via_evtchn(priv->evtchn);
> +
> + ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
> + duration = tpm_calc_ordinal_duration(chip, ordinal);
> +
> + if (wait_for_tpm_stat(chip, VTPM_STATUS_IDLE, duration,
> + &chip->vendor.read_queue, true) < 0) {
> + /* got a signal or timeout, try to cancel */
> + vtpm_cancel(chip);
> +
Re: fanotify: fix support of large files
On Sat, Apr 13, 2013 at 4:54 AM, Heinrich Schuchardt wrote: > Dear Justin, > > looking at the example at > http://www.lanedo.com/~aleksander/fanotify/fanotify-example.c > the large file support is enabled by passing O_LARGEFILE to fanotify_init: > > if ((fanotify_fd = fanotify_init (FAN_CLOEXEC, > O_RDONLY | O_CLOEXEC | O_LARGEFILE)) < > 0) > > Could you, please, check if this solves your issue. > > (I am resending this message because HTML was rejected by > linux-kernel@vger.kernel.org). > > Best regards > > Heinrich Schuchardt > No, unfortunately that doesn't help. I slightly modifed fanotify-example.c to call perror() when read() fails, and here's the output: jmaggard@jmaggard-W520:~/fanotify-test$ sudo ./fanotify-example . & [1] 7248 jmaggard@jmaggard-W520:~/fanotify-test$ Started monitoring directory '.'... truncate -s 2047m 2047m Received event in path '/home/jmaggard/fanotify-test/2047m' pid=7250 (unknown): FAN_OPEN FAN_CLOSE_WRITE jmaggard@jmaggard-W520:~/fanotify-test$ truncate -s 2048m 2048m read: Value too large for defined data type -Justin -- 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: tg3: possible irq lock inversion dependency detected
On 04/19/2013 02:01 PM, Nishanth Aravamudan wrote:
> Running 3.9-rc7-ish, tripped the following (also being seen in FC19
> alpha) on ppc64:
>
> [ 117.026196] =
> [ 117.026216] [ INFO: possible irq lock inversion dependency detected ]
> [ 117.026238] 3.9.0-rc7+ #8 Not tainted
> [ 117.026251] -
> [ 117.026271] swapper/7/0 just changed the state of lock:
> [ 117.026286] (&(&tp->lock)->rlock){+.-...}, at: []
> .tg3_timer+0x9c/0x10f0
> [ 117.026334] but this lock took another, SOFTIRQ-unsafe lock in the past:
> [ 117.026353] (devtree_lock){+.+...}
>
> and interrupts could create inverse lock ordering between them.
>
> [ 117.026389]
> other info that might help us debug this:
> [ 117.026409] Chain exists of:
> &(&tp->lock)->rlock --> pci_lock --> devtree_lock
>
> [ 117.026452] Possible interrupt unsafe locking scenario:
>
> [ 117.026472]CPU0CPU1
> [ 117.026488]
> [ 117.026503] lock(devtree_lock);
> [ 117.026521]local_irq_disable();
> [ 117.026540]lock(&(&tp->lock)->rlock);
> [ 117.026567]lock(pci_lock);
> [ 117.026591]
> [ 117.026600] lock(&(&tp->lock)->rlock);
> [ 117.026621]
> *** DEADLOCK ***
>
> [ 117.026644] 1 lock held by swapper/7/0:
> [ 117.026657] #0: ((&tp->timer)){+.-...}, at: []
> .call_timer_fn+0x0/0x3e0
> [ 117.026698]
> the shortest dependencies between 2nd lock and 1st lock:
> [ 117.026722] -> (devtree_lock){+.+...} ops: 13864154431488 {
> [ 117.026758] HARDIRQ-ON-W at:
> [ 117.026772] SOFTIRQ-ON-W at:
> [ 117.026786] INITIAL USE at:
> [ 117.026799]}
> [ 117.026809]... key at: [] devtree_lock+0x18/0x48
> [ 117.026835]... acquired at:
>
> [ 117.026857] -> (pci_lock){..} ops: 3955664879616 {
> [ 117.026893] INITIAL USE at:
> [ 117.026906] }
> [ 117.026915] ... key at: [] pci_lock+0x18/0x48
> [ 117.026942] ... acquired at:
>
> [ 117.026963] -> (&(&tp->lock)->rlock){+.-...} ops: 154618822656 {
> [ 117.027001]HARDIRQ-ON-W at:
> [ 117.027015]IN-SOFTIRQ-W at:
> [ 117.027029]INITIAL USE at:
> [ 117.027042] }
> [ 117.027051] ... key at: [] __key.48770+0x0/0x8
> [ 117.027078] ... acquired at:
>
> [ 117.027100]
> stack backtrace:
> [ 117.027116] Call Trace:
> [ 117.027129] [c003a7c7ad10] [c0016ee0] .show_stack+0xd0/0x1f0
> (unreliable)
> [ 117.027161] [c003a7c7ade0] [c0137d78]
> .print_irq_inversion_bug+0x298/0x2f0
> [ 117.027189] [c003a7c7ae80] [c0137e70]
> .check_usage_forwards+0xa0/0x150
> [ 117.027217] [c003a7c7af70] [c0138b68] .mark_lock+0x258/0x7b0
> [ 117.027242] [c003a7c7b030] [c01396f8]
> .__lock_acquire+0x638/0x1c20
> [ 117.027270] [c003a7c7b1b0] [c013b480] .lock_acquire+0xb0/0x250
> [ 117.027296] [c003a7c7b290] [c093a1cc] ._raw_spin_lock+0x5c/0xc0
> [ 117.027321] [c003a7c7b320] [c064effc] .tg3_timer+0x9c/0x10f0
> [ 117.027345] [c003a7c7b3d0] [c00bbd0c] .call_timer_fn+0xbc/0x3e0
> [ 117.027369] [c003a7c7b4b0] [c00bc328]
> .run_timer_softirq+0x2f8/0x440
> [ 117.027398] [c003a7c7b5c0] [c00afef8] .__do_softirq+0x1b8/0x540
> [ 117.027423] [c003a7c7b6f0] [c00b04e8] .irq_exit+0xe8/0x100
> [ 117.027448] [c003a7c7b770] [c0020464]
> .timer_interrupt+0x174/0x510
> [ 117.027477] [c003a7c7b830] [c00024f4]
> decrementer_common+0x174/0x180
> [ 117.027509] --- Exception: 901 at .plpar_hcall_norets+0x84/0xd4
> LR = .check_and_cede_processor+0x48/0x80
> [ 117.027544] [c003a7c7bb20] [c0085168]
> .check_and_cede_processor+0x18/0x80 (unreliable)
> [ 117.027577] [c003a7c7bb90] [c0085258]
> .dedicated_cede_loop+0x88/0x150
> [ 117.027606] [c003a7c7bc50] [c075808c] .cpuidle_enter+0x2c/0x40
> [ 117.027632] [c003a7c7bcc0] [c07589bc]
> .cpuidle_idle_call+0xfc/0x4e0
> [ 117.027660] [c003a7c7bd70] [c0074be8] .pSeries_idle+0x18/0x40
> [ 117.027685] [c003a7c7bde0] [c0018ec0] .cpu_idle+0x180/0x360
> [ 117.027711] [c003a7c7bea0] [c095391c]
> .start_secondary+0x534/0x53c
> [ 117.027739] [c003a7c7bf90] [c00097fc]
> .start_secondary_prolog+0x10/0x14
>
It might be related to this commit. Can you revert and try it.
commit d6d3c4e656513dcea61ce900f0ecb9ca820ee7cd
Author: Thomas Gleixner
Date: Wed Feb 6 15:30:56 2013 -0500
OF: convert devtree lock from rw_lock to raw spinlock
With the locking cleanup in place (from "OF: Fixup resursive
locking code paths"), we can now do the conversion from the
rw_lock to a raw spinlock as required for preempt-rt.
The previous cleanup and this conversion were
Re: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]
On 04/19/2013 02:53 PM, Sedat Dilek wrote: On Fri, Apr 19, 2013 at 6:43 PM, Sedat Dilek wrote: I tried to switch from SLUB to SLAB... ...and also from VIRT_CPU_ACCOUNTING_GEN to TICK_CPU_ACCOUNTING. 2x NOPE. In one kernel-build I saw in my console... semop(1): encountered an error: Identifier removed ...if this says sth. to you. [ CC folks from below thread ] I have found a thread called "Re: ipc,sem: sysv semaphore scalability" on LKML with a screenshot that shows the same call-trace. I followed it a bit. There is a patch in [3]... unconfirmed. Comments on the rcu read-lock and "sem_lock()" vs "sem_unlock()" from Linus. What's the status of this discussion? - Sedat - [1] https://lkml.org/lkml/2013/3/30/6 [2] http://i.imgur.com/uk6gmq1.jpg [3] https://lkml.org/lkml/2013/3/31/12 [4] https://lkml.org/lkml/2013/3/31/77 I am at a conference right now, but when I get back I will check linux-next vs. all the fixes from the semaphore scalability email thread. I will gather up the not-yet-in-linux-next fixes, and will send them to Andrew for inclusion. No guarantee that those fixes are related to your problem, of course :) -- 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] iommu: Include linux/err.h
On Fri, Apr 19, 2013 at 09:38:04AM +0800, Wang YanQing wrote: > The linux/iommu.h header uses ERR_PTR defined > in linux/err.h but doesn't include it. > > Cc:j...@8bytes.org > Reviewed-by: Alex Williamson > Signed-off-by: Wang YanQing Applied to core branch, thanks. -- 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] x86: Add check for P5 to microcode_intel_early
On Fri, Apr 19, 2013 at 06:23:03PM +0100, Bryan O'Donoghue wrote: > Architectural MSRs associated with microcode are for P6 or higher. > Add a check to early microcode to detect < P6. > > Without a check for < P6 - we end up reading from unimplemented MSRs > on Pentium. Is this something you're actually seeing on some box or just found by staring at the code? In any case, the family checks should go into the ucode driver entry points in arch/x86/kernel/microcode_core_early.c. AFAICT, x86_vendor() is a good candidate to be taught to read out the family too and return X86_VENDOR_UNKNOWN if < P6. Or something to that effect. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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/
[PATCHv2 2/2] sched: move update_load_[add/sub/set] from sched.h to fair.c
These inlines are only used by kernel/sched/fair.c so they do not
need to be present in the main kernel/sched/sched.h file.
Cc: Ingo Molnar
Cc: Peter Zijlstra
Signed-off-by: Paul Gortmaker
---
kernel/sched/fair.c | 18 ++
kernel/sched/sched.h | 18 --
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 68324a9..82f160c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -113,6 +113,24 @@ unsigned int __read_mostly sysctl_sched_shares_window =
1000UL;
unsigned int sysctl_sched_cfs_bandwidth_slice = 5000UL;
#endif
+static inline void update_load_add(struct load_weight *lw, unsigned long inc)
+{
+ lw->weight += inc;
+ lw->inv_weight = 0;
+}
+
+static inline void update_load_sub(struct load_weight *lw, unsigned long dec)
+{
+ lw->weight -= dec;
+ lw->inv_weight = 0;
+}
+
+static inline void update_load_set(struct load_weight *lw, unsigned long w)
+{
+ lw->weight = w;
+ lw->inv_weight = 0;
+}
+
/*
* Increase the granularity value when there are more CPUs,
* because with more CPUs the 'effective latency' as visible
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 49d4114..c9c1cdb 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -888,24 +888,6 @@ static inline void finish_lock_switch(struct rq *rq,
struct task_struct *prev)
#define WF_FORK0x02/* child wakeup after fork */
#define WF_MIGRATED0x4 /* internal use, task got migrated */
-static inline void update_load_add(struct load_weight *lw, unsigned long inc)
-{
- lw->weight += inc;
- lw->inv_weight = 0;
-}
-
-static inline void update_load_sub(struct load_weight *lw, unsigned long dec)
-{
- lw->weight -= dec;
- lw->inv_weight = 0;
-}
-
-static inline void update_load_set(struct load_weight *lw, unsigned long w)
-{
- lw->weight = w;
- lw->inv_weight = 0;
-}
-
/*
* To aid in avoiding the subversion of "niceness" due to uneven distribution
* of tasks with abnormal "nice" values across CPUs the contribution that
--
1.8.1.2
--
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/
[PATCHv2 1/2] sched: fork load calculation code from sched/core --> sched/proc
This large chunk of load calculation code can be easily divorced from
the main core.c scheduler file, with only a couple prototypes and
externs added to a kernel/sched header.
Some recent commits expanded the code and the documentation of it,
making it large enough to warrant separation. For example, see:
556061b, "sched/nohz: Fix rq->cpu_load[] calculations"
5aaa0b7, "sched/nohz: Fix rq->cpu_load calculations some more"
5167e8d, "sched/nohz: Rewrite and fix load-avg computation -- again"
More importantly, it helps reduce the size of the main sched/core.c
by yet another significant amount (~600 lines).
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: Thomas Gleixner
Signed-off-by: Paul Gortmaker
---
kernel/sched/Makefile | 2 +-
kernel/sched/core.c | 569 -
kernel/sched/proc.c | 578 ++
kernel/sched/sched.h | 8 +
4 files changed, 587 insertions(+), 570 deletions(-)
create mode 100644 kernel/sched/proc.c
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index deaf90e..54adcf3 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -11,7 +11,7 @@ ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
CFLAGS_core.o := $(PROFILING) -fno-omit-frame-pointer
endif
-obj-y += core.o clock.o cputime.o idle_task.o fair.o rt.o stop_task.o
+obj-y += core.o proc.o clock.o cputime.o idle_task.o fair.o rt.o stop_task.o
obj-$(CONFIG_SMP) += cpupri.o
obj-$(CONFIG_SCHED_AUTOGROUP) += auto_group.o
obj-$(CONFIG_SCHEDSTATS) += stats.o
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4278fca..fc29a24 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2034,575 +2034,6 @@ unsigned long nr_iowait_cpu(int cpu)
return atomic_read(&this->nr_iowait);
}
-unsigned long this_cpu_load(void)
-{
- struct rq *this = this_rq();
- return this->cpu_load[0];
-}
-
-
-/*
- * Global load-average calculations
- *
- * We take a distributed and async approach to calculating the global load-avg
- * in order to minimize overhead.
- *
- * The global load average is an exponentially decaying average of nr_running +
- * nr_uninterruptible.
- *
- * Once every LOAD_FREQ:
- *
- * nr_active = 0;
- * for_each_possible_cpu(cpu)
- * nr_active += cpu_of(cpu)->nr_running + cpu_of(cpu)->nr_uninterruptible;
- *
- * avenrun[n] = avenrun[0] * exp_n + nr_active * (1 - exp_n)
- *
- * Due to a number of reasons the above turns in the mess below:
- *
- * - for_each_possible_cpu() is prohibitively expensive on machines with
- *serious number of cpus, therefore we need to take a distributed approach
- *to calculating nr_active.
- *
- *\Sum_i x_i(t) = \Sum_i x_i(t) - x_i(t_0) | x_i(t_0) := 0
- * = \Sum_i { \Sum_j=1 x_i(t_j) - x_i(t_j-1) }
- *
- *So assuming nr_active := 0 when we start out -- true per definition, we
- *can simply take per-cpu deltas and fold those into a global accumulate
- *to obtain the same result. See calc_load_fold_active().
- *
- *Furthermore, in order to avoid synchronizing all per-cpu delta folding
- *across the machine, we assume 10 ticks is sufficient time for every
- *cpu to have completed this task.
- *
- *This places an upper-bound on the IRQ-off latency of the machine. Then
- *again, being late doesn't loose the delta, just wrecks the sample.
- *
- * - cpu_rq()->nr_uninterruptible isn't accurately tracked per-cpu because
- *this would add another cross-cpu cacheline miss and atomic operation
- *to the wakeup path. Instead we increment on whatever cpu the task ran
- *when it went into uninterruptible state and decrement on whatever cpu
- *did the wakeup. This means that only the sum of nr_uninterruptible over
- *all cpus yields the correct result.
- *
- * This covers the NO_HZ=n code, for extra head-aches, see the comment below.
- */
-
-/* Variables and functions for calc_load */
-static atomic_long_t calc_load_tasks;
-static unsigned long calc_load_update;
-unsigned long avenrun[3];
-EXPORT_SYMBOL(avenrun); /* should be removed */
-
-/**
- * get_avenrun - get the load average array
- * @loads: pointer to dest load array
- * @offset:offset to add
- * @shift: shift count to shift the result left
- *
- * These values are estimates at best, so no need for locking.
- */
-void get_avenrun(unsigned long *loads, unsigned long offset, int shift)
-{
- loads[0] = (avenrun[0] + offset) << shift;
- loads[1] = (avenrun[1] + offset) << shift;
- loads[2] = (avenrun[2] + offset) << shift;
-}
-
-static long calc_load_fold_active(struct rq *this_rq)
-{
- long nr_active, delta = 0;
-
- nr_active = this_rq->nr_running;
- nr_active += (long) this_rq->nr_uninterruptible;
-
- if (nr_active != this_rq->calc_load_active) {
- delta = nr_active - this_rq->calc_load_active;
- this_rq->calc_load_a
[PATCHv2 0/2] sched: move content out of core files for load calculations
Recent activity has had a focus on moving functionally related blocks of stuff out of sched/core.c into stand-alone files. The code relating to load calculations has grown significantly enough recently to warrant placing it in a separate file. Here we do that, and in doing so, we shed ~20k of code from sched/core.c (~10%). A couple small static functions in the core sched.h header were also localized to their singular user in sched/fair.c at the same time, with the goal to also reduce the amount of "broadcast" content in that sched.h file. Paul. --- v2 changes: 1) rebase from tip's sched/core (v3.9-rc1-38-gb329fd5) to today's tip master (v3.9-rc6-2031-g27f8b76). 2) rename file from load_avg.c to proc.c --- The following changes since commit 27f8b769cba5a97ffcbaae92fd4c0ed84f00e214: manual merge of tools/kvm (2013-04-19 13:05:17 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git for-ingo for you to fetch changes up to dac25445169ff97142ae4f7174e3d94ce7036ad3: sched: move update_load_[add/sub/set] from sched.h to fair.c (2013-04-19 14:38:11 -0400) Paul Gortmaker (2): sched: fork load calculation code from sched/core --> sched/proc sched: move update_load_[add/sub/set] from sched.h to fair.c kernel/sched/Makefile | 2 +- kernel/sched/core.c | 569 - kernel/sched/fair.c | 18 ++ kernel/sched/proc.c | 578 ++ kernel/sched/sched.h | 26 +-- 5 files changed, 605 insertions(+), 588 deletions(-) create mode 100644 kernel/sched/proc.c -- 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/
[char-misc-next 3/3 V2 RESEND] mei: reseting -> resetting
From: Bill Nottingham
This enum leaks out to userspace via error messages, so fix the spelling.
Signed-off-by: Bill Nottingham
Signed-off-by: Tomas Winkler
---
V2: rebased
drivers/misc/mei/hbm.c | 8
drivers/misc/mei/hw-me.c | 2 +-
drivers/misc/mei/init.c| 4 ++--
drivers/misc/mei/mei_dev.h | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index 4de80d9..db605f5 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -52,7 +52,7 @@ static void mei_hbm_me_cl_allocate(struct mei_device *dev)
sizeof(struct mei_me_client), GFP_KERNEL);
if (!clients) {
dev_err(&dev->pdev->dev, "memory allocation for ME clients
failed.\n");
- dev->dev_state = MEI_DEV_RESETING;
+ dev->dev_state = MEI_DEV_RESETTING;
mei_reset(dev, 1);
return;
}
@@ -167,7 +167,7 @@ int mei_hbm_start_req(struct mei_device *dev)
dev->hbm_state = MEI_HBM_IDLE;
if (mei_write_message(dev, mei_hdr, dev->wr_msg.data)) {
dev_err(&dev->pdev->dev, "version message writet failed\n");
- dev->dev_state = MEI_DEV_RESETING;
+ dev->dev_state = MEI_DEV_RESETTING;
mei_reset(dev, 1);
return -ENODEV;
}
@@ -196,7 +196,7 @@ static void mei_hbm_enum_clients_req(struct mei_device *dev)
enum_req->hbm_cmd = HOST_ENUM_REQ_CMD;
if (mei_write_message(dev, mei_hdr, dev->wr_msg.data)) {
- dev->dev_state = MEI_DEV_RESETING;
+ dev->dev_state = MEI_DEV_RESETTING;
dev_err(&dev->pdev->dev, "enumeration request write failed.\n");
mei_reset(dev, 1);
}
@@ -249,7 +249,7 @@ static int mei_hbm_prop_req(struct mei_device *dev)
prop_req->address = next_client_index;
if (mei_write_message(dev, mei_hdr, dev->wr_msg.data)) {
- dev->dev_state = MEI_DEV_RESETING;
+ dev->dev_state = MEI_DEV_RESETTING;
dev_err(&dev->pdev->dev, "properties request write failed\n");
mei_reset(dev, 1);
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 3d6dfa3..fc03227 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -481,7 +481,7 @@ irqreturn_t mei_me_irq_thread_handler(int irq, void *dev_id)
/* check if ME wants a reset */
if (!mei_hw_is_ready(dev) &&
- dev->dev_state != MEI_DEV_RESETING &&
+ dev->dev_state != MEI_DEV_RESETTING &&
dev->dev_state != MEI_DEV_INITIALIZING) {
dev_dbg(&dev->pdev->dev, "FW not ready.\n");
mei_reset(dev, 1);
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index 59159e0..713d89f 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -33,7 +33,7 @@ const char *mei_dev_state_str(int state)
MEI_DEV_STATE(INITIALIZING);
MEI_DEV_STATE(INIT_CLIENTS);
MEI_DEV_STATE(ENABLED);
- MEI_DEV_STATE(RESETING);
+ MEI_DEV_STATE(RESETTING);
MEI_DEV_STATE(DISABLED);
MEI_DEV_STATE(POWER_DOWN);
MEI_DEV_STATE(POWER_UP);
@@ -146,7 +146,7 @@ void mei_reset(struct mei_device *dev, int
interrupts_enabled)
if (dev->dev_state != MEI_DEV_INITIALIZING) {
if (dev->dev_state != MEI_DEV_DISABLED &&
dev->dev_state != MEI_DEV_POWER_DOWN)
- dev->dev_state = MEI_DEV_RESETING;
+ dev->dev_state = MEI_DEV_RESETTING;
mei_cl_all_disconnect(dev);
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index c91c492..4de5140 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -97,7 +97,7 @@ enum mei_dev_state {
MEI_DEV_INITIALIZING = 0,
MEI_DEV_INIT_CLIENTS,
MEI_DEV_ENABLED,
- MEI_DEV_RESETING,
+ MEI_DEV_RESETTING,
MEI_DEV_DISABLED,
MEI_DEV_POWER_DOWN,
MEI_DEV_POWER_UP
--
1.8.1.2
--
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] i2c-designware: fix RX FIFO overrun
From a969728248c3b439dc97a69e7dac133b5efa34e7 Mon Sep 17 00:00:00 2001
From: Josef Ahmad
Date: Fri, 19 Apr 2013 17:28:10 +0100
Subject: [PATCH] i2c-designware: fix RX FIFO overrun
i2c_dw_xfer_msg() pushes a number of bytes to transmit/receive
to/from the bus into the TX FIFO.
For master-rx transactions, the maximum amount of data that can be
received is calculated depending solely on TX and RX FIFO load.
This is racy - TX FIFO may contain master-rx data yet to be
processed, which will eventually land into the RX FIFO. This
data is not taken into account and the function may request more
data than the controller is actually capable of storing.
This patch ensures the driver takes into account the outstanding
master-rx data in TX FIFO to prevent RX FIFO overrun.
Signed-off-by: Josef Ahmad
---
drivers/i2c/busses/i2c-designware-core.c | 11 ++-
drivers/i2c/busses/i2c-designware-core.h |2 ++
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
index 94fd818..8dbeef1 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -426,8 +426,14 @@ i2c_dw_xfer_msg(struct dw_i2c_dev *dev)
cmd |= BIT(9);
if (msgs[dev->msg_write_idx].flags & I2C_M_RD) {
+
+ /* avoid rx buffer overrun */
+ if (rx_limit - dev->rx_outstanding <= 0)
+ break;
+
dw_writel(dev, cmd | 0x100, DW_IC_DATA_CMD);
rx_limit--;
+ dev->rx_outstanding++;
} else
dw_writel(dev, cmd | *buf++, DW_IC_DATA_CMD);
tx_limit--; buf_len--;
@@ -480,8 +486,10 @@ i2c_dw_read(struct dw_i2c_dev *dev)
rx_valid = dw_readl(dev, DW_IC_RXFLR);
- for (; len > 0 && rx_valid > 0; len--, rx_valid--)
+ for (; len > 0 && rx_valid > 0; len--, rx_valid--) {
*buf++ = dw_readl(dev, DW_IC_DATA_CMD);
+ dev->rx_outstanding--;
+ }
if (len > 0) {
dev->status |= STATUS_READ_IN_PROGRESS;
@@ -539,6 +547,7 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
dev->msg_err = 0;
dev->status = STATUS_IDLE;
dev->abort_source = 0;
+ dev->rx_outstanding = 0;
ret = i2c_dw_wait_bus_not_busy(dev);
if (ret < 0)
diff --git a/drivers/i2c/busses/i2c-designware-core.h
b/drivers/i2c/busses/i2c-designware-core.h
index 9c1840e..e761ad1 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -60,6 +60,7 @@
* @adapter: i2c subsystem adapter node
* @tx_fifo_depth: depth of the hardware tx fifo
* @rx_fifo_depth: depth of the hardware rx fifo
+ * @rx_outstanding: current master-rx elements in tx fifo
*/
struct dw_i2c_dev {
struct device *dev;
@@ -88,6 +89,7 @@ struct dw_i2c_dev {
u32 master_cfg;
unsigned inttx_fifo_depth;
unsigned intrx_fifo_depth;
+ int rx_outstanding;
};
#define ACCESS_SWAP0x0001
--
1.7.0.7
--
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/
[char-misc-next 1/3] mei: revamp mei_irq_read_client_message function
1. Rename the function and change parameters order,
so that first parameter is mei_device
2. Simplify the function code flow
3. Rename helper functions to more self descriptive names
4. Use helpers common functions where possible
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/interrupt.c | 124 +++
1 file changed, 66 insertions(+), 58 deletions(-)
diff --git a/drivers/misc/mei/interrupt.c b/drivers/misc/mei/interrupt.c
index 8e4db3d..9bf64c0 100644
--- a/drivers/misc/mei/interrupt.c
+++ b/drivers/misc/mei/interrupt.c
@@ -82,80 +82,90 @@ void mei_irq_compl_handler(struct mei_device *dev, struct
mei_cl_cb *compl_list)
}
}
EXPORT_SYMBOL_GPL(mei_irq_compl_handler);
+
/**
- * _mei_irq_thread_state_ok - checks if mei header matches file private data
+ * mei_cl_hbm_equal - check if hbm is addressed to the client
*
- * @cl: private data of the file object
+ * @cl: host client
* @mei_hdr: header of mei client message
*
- * returns !=0 if matches, 0 if no match.
+ * returns true if matches, false otherwise
+ */
+static inline int mei_cl_hbm_equal(struct mei_cl *cl,
+ struct mei_msg_hdr *mei_hdr)
+{
+ return cl->host_client_id == mei_hdr->host_addr &&
+ cl->me_client_id == mei_hdr->me_addr;
+}
+/**
+ * mei_cl_is_reading - checks if the client
+ is the one to read this message
+ *
+ * @cl: mei client
+ * @mei_hdr: header of mei message
+ *
+ * returns true on match and false otherwise
*/
-static int _mei_irq_thread_state_ok(struct mei_cl *cl,
- struct mei_msg_hdr *mei_hdr)
+static bool mei_cl_is_reading(struct mei_cl *cl, struct mei_msg_hdr *mei_hdr)
{
- return (cl->host_client_id == mei_hdr->host_addr &&
- cl->me_client_id == mei_hdr->me_addr &&
+ return mei_cl_hbm_equal(cl, mei_hdr) &&
cl->state == MEI_FILE_CONNECTED &&
- MEI_READ_COMPLETE != cl->reading_state);
+ cl->reading_state != MEI_READ_COMPLETE;
}
/**
- * mei_irq_thread_read_client_message - bottom half read routine after ISR to
- * handle the read mei client message data processing.
+ * mei_irq_read_client_message - process client message
*
- * @complete_list: An instance of our list structure
* @dev: the device structure
* @mei_hdr: header of mei client message
+ * @complete_list: An instance of our list structure
*
* returns 0 on success, <0 on failure.
*/
-static int mei_irq_thread_read_client_message(struct mei_cl_cb *complete_list,
- struct mei_device *dev,
- struct mei_msg_hdr *mei_hdr)
+static int mei_cl_irq_read_msg(struct mei_device *dev,
+ struct mei_msg_hdr *mei_hdr,
+ struct mei_cl_cb *complete_list)
{
struct mei_cl *cl;
- struct mei_cl_cb *cb_pos = NULL, *cb_next = NULL;
+ struct mei_cl_cb *cb, *next;
unsigned char *buffer = NULL;
- dev_dbg(&dev->pdev->dev, "start client msg\n");
- if (list_empty(&dev->read_list.list))
- goto quit;
-
- list_for_each_entry_safe(cb_pos, cb_next, &dev->read_list.list, list) {
- cl = cb_pos->cl;
- if (cl && _mei_irq_thread_state_ok(cl, mei_hdr)) {
- cl->reading_state = MEI_READING;
- buffer = cb_pos->response_buffer.data + cb_pos->buf_idx;
-
- if (cb_pos->response_buffer.size <
- mei_hdr->length + cb_pos->buf_idx) {
- dev_dbg(&dev->pdev->dev, "message overflow.\n");
- list_del(&cb_pos->list);
- return -ENOMEM;
- }
- if (buffer)
- mei_read_slots(dev, buffer, mei_hdr->length);
-
- cb_pos->buf_idx += mei_hdr->length;
- if (mei_hdr->msg_complete) {
- cl->status = 0;
- list_del(&cb_pos->list);
- dev_dbg(&dev->pdev->dev,
- "completed read H cl = %d, ME cl = %d,
length = %lu\n",
- cl->host_client_id,
- cl->me_client_id,
- cb_pos->buf_idx);
-
- list_add_tail(&cb_pos->list,
- &complete_list->list);
- }
+ list_for_each_entry_safe(cb, next, &dev->read_list.list, list) {
+ cl = cb->cl;
+ if (!cl || !mei_cl_is_reading(cl, mei_hdr))
+ continue;
- break;
+ cl->reading_state = MEI_READING;
+
+ if (cb->response_buffer.size == 0 ||
+ cb->response_buffer.data
[char-misc-next 2/3 RESEND] mei: fix reading large reposnes
While writting to device is limitted to max_msg_length advertized
in client properites the read can be much longer delivered consequiting chunks.
We use krealloc to enlarge the buffer when needed.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus.c | 8
drivers/misc/mei/client.c| 7 ---
drivers/misc/mei/client.h| 2 +-
drivers/misc/mei/interrupt.c | 18 +++---
drivers/misc/mei/main.c | 7 +++
5 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 834ceeb..1e935ea 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -286,7 +286,7 @@ int __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t length)
mutex_lock(&dev->device_lock);
if (!cl->read_cb) {
- err = mei_cl_read_start(cl);
+ err = mei_cl_read_start(cl, length);
if (err < 0) {
mutex_unlock(&dev->device_lock);
return err;
@@ -378,7 +378,7 @@ static void mei_bus_event_work(struct work_struct *work)
device->events = 0;
/* Prepare for the next read */
- mei_cl_read_start(device->cl);
+ mei_cl_read_start(device->cl, 0);
}
int mei_cl_register_event_cb(struct mei_cl_device *device,
@@ -392,7 +392,7 @@ int mei_cl_register_event_cb(struct mei_cl_device *device,
device->event_context = context;
INIT_WORK(&device->event_work, mei_bus_event_work);
- mei_cl_read_start(device->cl);
+ mei_cl_read_start(device->cl, 0);
return 0;
}
@@ -436,7 +436,7 @@ int mei_cl_enable_device(struct mei_cl_device *device)
mutex_unlock(&dev->device_lock);
if (device->event_cb && !cl->read_cb)
- mei_cl_read_start(device->cl);
+ mei_cl_read_start(device->cl, 0);
if (!device->ops || !device->ops->enable)
return 0;
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 9541aa9..7189274 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -624,7 +624,7 @@ int mei_cl_flow_ctrl_reduce(struct mei_cl *cl)
*
* returns 0 on success, <0 on failure.
*/
-int mei_cl_read_start(struct mei_cl *cl)
+int mei_cl_read_start(struct mei_cl *cl, size_t length)
{
struct mei_device *dev;
struct mei_cl_cb *cb;
@@ -657,8 +657,9 @@ int mei_cl_read_start(struct mei_cl *cl)
if (!cb)
return -ENOMEM;
- rets = mei_io_cb_alloc_resp_buf(cb,
- dev->me_clients[i].props.max_msg_length);
+ /* always allocate at least client max message */
+ length = max_t(size_t, length, dev->me_clients[i].props.max_msg_length);
+ rets = mei_io_cb_alloc_resp_buf(cb, length);
if (rets)
goto err;
diff --git a/drivers/misc/mei/client.h b/drivers/misc/mei/client.h
index e890c8b..cfdb144 100644
--- a/drivers/misc/mei/client.h
+++ b/drivers/misc/mei/client.h
@@ -87,7 +87,7 @@ int mei_cl_flow_ctrl_reduce(struct mei_cl *cl);
bool mei_cl_is_other_connecting(struct mei_cl *cl);
int mei_cl_disconnect(struct mei_cl *cl);
int mei_cl_connect(struct mei_cl *cl, struct file *file);
-int mei_cl_read_start(struct mei_cl *cl);
+int mei_cl_read_start(struct mei_cl *cl, size_t length);
int mei_cl_write(struct mei_cl *cl, struct mei_cl_cb *cb, bool blocking);
void mei_host_client_init(struct work_struct *work);
diff --git a/drivers/misc/mei/interrupt.c b/drivers/misc/mei/interrupt.c
index 9bf64c0..7473071 100644
--- a/drivers/misc/mei/interrupt.c
+++ b/drivers/misc/mei/interrupt.c
@@ -145,9 +145,21 @@ static int mei_cl_irq_read_msg(struct mei_device *dev,
}
if (cb->response_buffer.size < mei_hdr->length + cb->buf_idx) {
- dev_warn(&dev->pdev->dev, "message overflow.\n");
- list_del(&cb->list);
- return -ENOMEM;
+ dev_dbg(&dev->pdev->dev, "message overflow. size %d len
%d idx %ld\n",
+ cb->response_buffer.size,
+ mei_hdr->length, cb->buf_idx);
+ cb->response_buffer.data =
+ krealloc(cb->response_buffer.data,
+ mei_hdr->length + cb->buf_idx,
+ GFP_KERNEL);
+
+ if (!cb->response_buffer.data) {
+ dev_err(&dev->pdev->dev, "allocation
failed.\n");
+ list_del(&cb->list);
+ return -ENOMEM;
+ }
+ cb->response_buffer.size =
+ mei_hdr->length + cb->buf_idx;
}
buffer = cb->response_buffer.data + cb->buf_idx;
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index 78b4da5..7c44c8d 100644
tg3: possible irq lock inversion dependency detected
Running 3.9-rc7-ish, tripped the following (also being seen in FC19
alpha) on ppc64:
[ 117.026196] =
[ 117.026216] [ INFO: possible irq lock inversion dependency detected ]
[ 117.026238] 3.9.0-rc7+ #8 Not tainted
[ 117.026251] -
[ 117.026271] swapper/7/0 just changed the state of lock:
[ 117.026286] (&(&tp->lock)->rlock){+.-...}, at: []
.tg3_timer+0x9c/0x10f0
[ 117.026334] but this lock took another, SOFTIRQ-unsafe lock in the past:
[ 117.026353] (devtree_lock){+.+...}
and interrupts could create inverse lock ordering between them.
[ 117.026389]
other info that might help us debug this:
[ 117.026409] Chain exists of:
&(&tp->lock)->rlock --> pci_lock --> devtree_lock
[ 117.026452] Possible interrupt unsafe locking scenario:
[ 117.026472]CPU0CPU1
[ 117.026488]
[ 117.026503] lock(devtree_lock);
[ 117.026521]local_irq_disable();
[ 117.026540]lock(&(&tp->lock)->rlock);
[ 117.026567]lock(pci_lock);
[ 117.026591]
[ 117.026600] lock(&(&tp->lock)->rlock);
[ 117.026621]
*** DEADLOCK ***
[ 117.026644] 1 lock held by swapper/7/0:
[ 117.026657] #0: ((&tp->timer)){+.-...}, at: []
.call_timer_fn+0x0/0x3e0
[ 117.026698]
the shortest dependencies between 2nd lock and 1st lock:
[ 117.026722] -> (devtree_lock){+.+...} ops: 13864154431488 {
[ 117.026758] HARDIRQ-ON-W at:
[ 117.026772] SOFTIRQ-ON-W at:
[ 117.026786] INITIAL USE at:
[ 117.026799]}
[ 117.026809]... key at: [] devtree_lock+0x18/0x48
[ 117.026835]... acquired at:
[ 117.026857] -> (pci_lock){..} ops: 3955664879616 {
[ 117.026893] INITIAL USE at:
[ 117.026906] }
[ 117.026915] ... key at: [] pci_lock+0x18/0x48
[ 117.026942] ... acquired at:
[ 117.026963] -> (&(&tp->lock)->rlock){+.-...} ops: 154618822656 {
[ 117.027001]HARDIRQ-ON-W at:
[ 117.027015]IN-SOFTIRQ-W at:
[ 117.027029]INITIAL USE at:
[ 117.027042] }
[ 117.027051] ... key at: [] __key.48770+0x0/0x8
[ 117.027078] ... acquired at:
[ 117.027100]
stack backtrace:
[ 117.027116] Call Trace:
[ 117.027129] [c003a7c7ad10] [c0016ee0] .show_stack+0xd0/0x1f0
(unreliable)
[ 117.027161] [c003a7c7ade0] [c0137d78]
.print_irq_inversion_bug+0x298/0x2f0
[ 117.027189] [c003a7c7ae80] [c0137e70]
.check_usage_forwards+0xa0/0x150
[ 117.027217] [c003a7c7af70] [c0138b68] .mark_lock+0x258/0x7b0
[ 117.027242] [c003a7c7b030] [c01396f8]
.__lock_acquire+0x638/0x1c20
[ 117.027270] [c003a7c7b1b0] [c013b480] .lock_acquire+0xb0/0x250
[ 117.027296] [c003a7c7b290] [c093a1cc] ._raw_spin_lock+0x5c/0xc0
[ 117.027321] [c003a7c7b320] [c064effc] .tg3_timer+0x9c/0x10f0
[ 117.027345] [c003a7c7b3d0] [c00bbd0c] .call_timer_fn+0xbc/0x3e0
[ 117.027369] [c003a7c7b4b0] [c00bc328]
.run_timer_softirq+0x2f8/0x440
[ 117.027398] [c003a7c7b5c0] [c00afef8] .__do_softirq+0x1b8/0x540
[ 117.027423] [c003a7c7b6f0] [c00b04e8] .irq_exit+0xe8/0x100
[ 117.027448] [c003a7c7b770] [c0020464]
.timer_interrupt+0x174/0x510
[ 117.027477] [c003a7c7b830] [c00024f4]
decrementer_common+0x174/0x180
[ 117.027509] --- Exception: 901 at .plpar_hcall_norets+0x84/0xd4
LR = .check_and_cede_processor+0x48/0x80
[ 117.027544] [c003a7c7bb20] [c0085168]
.check_and_cede_processor+0x18/0x80 (unreliable)
[ 117.027577] [c003a7c7bb90] [c0085258]
.dedicated_cede_loop+0x88/0x150
[ 117.027606] [c003a7c7bc50] [c075808c] .cpuidle_enter+0x2c/0x40
[ 117.027632] [c003a7c7bcc0] [c07589bc]
.cpuidle_idle_call+0xfc/0x4e0
[ 117.027660] [c003a7c7bd70] [c0074be8] .pSeries_idle+0x18/0x40
[ 117.027685] [c003a7c7bde0] [c0018ec0] .cpu_idle+0x180/0x360
[ 117.027711] [c003a7c7bea0] [c095391c]
.start_secondary+0x534/0x53c
[ 117.027739] [c003a7c7bf90] [c00097fc]
.start_secondary_prolog+0x10/0x14
--
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] events: Protect access via task_subsys_state_check()
The following RCU splat indicates lack of RCU protection:
[ 953.267649] ===
[ 953.267652] [ INFO: suspicious RCU usage. ]
[ 953.267657] 3.9.0-0.rc6.git2.4.fc19.ppc64p7 #1 Not tainted
[ 953.267661] ---
[ 953.267664] include/linux/cgroup.h:534 suspicious rcu_dereference_check()
usage!
[ 953.267669]
[ 953.267669] other info that might help us debug this:
[ 953.267669]
[ 953.267675]
[ 953.267675] rcu_scheduler_active = 1, debug_locks = 0
[ 953.267680] 1 lock held by glxgears/1289:
[ 953.267683] #0: (&sig->cred_guard_mutex){+.+.+.}, at: []
.prepare_bprm_creds+0x34/0xa0
[ 953.267700]
[ 953.267700] stack backtrace:
[ 953.267704] Call Trace:
[ 953.267709] [c001f0d1b6e0] [c0016e30] .show_stack+0x130/0x200
(unreliable)
[ 953.267717] [c001f0d1b7b0] [c01267f8]
.lockdep_rcu_suspicious+0x138/0x180
[ 953.267724] [c001f0d1b840] [c01d43a4]
.perf_event_comm+0x4c4/0x690
[ 953.267731] [c001f0d1b950] [c027f6e4] .set_task_comm+0x84/0x1f0
[ 953.267737] [c001f0d1b9f0] [c0280414] .setup_new_exec+0x94/0x220
[ 953.267744] [c001f0d1ba70] [c02f665c]
.load_elf_binary+0x58c/0x19b0
[ 953.267751] [c001f0d1bbc0] [c027e724]
.search_binary_handler+0x254/0x680
[ 953.267758] [c001f0d1bca0] [c02800dc]
.do_execve_common.isra.17+0x76c/0x860
[ 953.267764] [c001f0d1bd90] [c0280698] .SyS_execve+0x58/0x90
[ 953.267771] [c001f0d1be30] [c0009e60] syscall_exit+0x0/0x98
This commit therefore adds the required RCU read-side critical section to
perf_event_comm().
Reported-by: Adam Jackson
Signed-off-by: Paul E. McKenney
Tested-by: Gustavo Luiz Duarte
diff --git a/kernel/events/core.c b/kernel/events/core.c
index b0cd865..8db9551 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4593,6 +4593,7 @@ void perf_event_comm(struct task_struct *task)
struct perf_event_context *ctx;
int ctxn;
+ rcu_read_lock();
for_each_task_context_nr(ctxn) {
ctx = task->perf_event_ctxp[ctxn];
if (!ctx)
@@ -4600,6 +4601,7 @@ void perf_event_comm(struct task_struct *task)
perf_event_enable_on_exec(ctx);
}
+ rcu_read_unlock();
if (!atomic_read(&nr_comm_events))
return;
--
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: [char-misc-next 2/3] mei: fix reading large reposnes
> > On Fri, Apr 19, 2013 at 09:16:54PM +0300, Tomas Winkler wrote: > > While writting to device is limitted to max_msg_length advertized in > > client properites the read can be much longer delivered consequiting > chunks. > > > > We use krealloc to enlarge the buffer when needed. > > > > Signed-off-by: Tomas Winkler > > Patch 1/3 had some fuzz in interrupt.c, so I fixed that up by hand, but this > one just fails to apply at all: > checking file drivers/misc/mei/bus.c > checking file drivers/misc/mei/client.c > checking file drivers/misc/mei/client.h > checking file drivers/misc/mei/interrupt.c > Hunk #1 FAILED at 145. > 1 out of 1 hunk FAILED > checking file drivers/misc/mei/main.c > > So something is out of sync between us. > > Care to refresh this patch based on my latest tree, and 3/3, and resend > them? Grrr, I sent you one patch less, I've rebased this new spelling fix and missed to count it in. I'm resending the missing patches. Tomas -- 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 2/2] perf, amd: support for AMD NB and L2I "uncore" counters.
On Fri, 2013-04-19 at 09:41 -0500, Jacob Shin wrote:
>
> Thank you again, for taking the time.
Ah something I just remembered, could you do a patch like the below
one? That makes things like perf stat -A work as expected.
---
commit 314d9f63f385096580e9e2a06eaa0745d92fe4ac
Author: Yan, Zheng
Date: Mon Sep 10 15:53:49 2012 +0800
perf/x86: Add cpumask for uncore pmu
This patch adds a cpumask file to the uncore pmu sysfs directory. The
cpumask file contains one active cpu for every socket.
Signed-off-by: "Yan, Zheng"
Acked-by: Peter Zijlstra
Acked-by: Ingo Molnar
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: "Yan, Zheng"
Link:
http://lkml.kernel.org/r/1347263631-23175-2-git-send-email-zheng.z@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 0a55710..62ec3e6 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -2341,6 +2341,27 @@ int uncore_pmu_event_init(struct perf_event *event)
return ret;
}
+static ssize_t uncore_get_attr_cpumask(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int n = cpulist_scnprintf(buf, PAGE_SIZE - 2, &uncore_cpu_mask);
+
+ buf[n++] = '\n';
+ buf[n] = '\0';
+ return n;
+}
+
+static DEVICE_ATTR(cpumask, S_IRUGO, uncore_get_attr_cpumask, NULL);
+
+static struct attribute *uncore_pmu_attrs[] = {
+ &dev_attr_cpumask.attr,
+ NULL,
+};
+
+static struct attribute_group uncore_pmu_attr_group = {
+ .attrs = uncore_pmu_attrs,
+};
+
static int __init uncore_pmu_register(struct intel_uncore_pmu *pmu)
{
int ret;
@@ -2378,8 +2399,8 @@ static void __init uncore_type_exit(struct
intel_uncore_type *type)
free_percpu(type->pmus[i].box);
kfree(type->pmus);
type->pmus = NULL;
- kfree(type->attr_groups[1]);
- type->attr_groups[1] = NULL;
+ kfree(type->events_group);
+ type->events_group = NULL;
}
static void __init uncore_types_exit(struct intel_uncore_type **types)
@@ -2431,9 +2452,10 @@ static int __init uncore_type_init(struct
intel_uncore_type *type)
for (j = 0; j < i; j++)
attrs[j] = &type->event_descs[j].attr.attr;
- type->attr_groups[1] = events_group;
+ type->events_group = events_group;
}
+ type->pmu_group = &uncore_pmu_attr_group;
type->pmus = pmus;
return 0;
fail:
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.h
b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
index 5b81c18..e68a455 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.h
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
@@ -369,10 +369,12 @@ struct intel_uncore_type {
struct intel_uncore_pmu *pmus;
struct intel_uncore_ops *ops;
struct uncore_event_desc *event_descs;
- const struct attribute_group *attr_groups[3];
+ const struct attribute_group *attr_groups[4];
};
-#define format_group attr_groups[0]
+#define pmu_group attr_groups[0]
+#define format_group attr_groups[1]
+#define events_group attr_groups[2]
struct intel_uncore_ops {
void (*init_box)(struct intel_uncore_box *);
--
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: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]
On Fri, Apr 19, 2013 at 6:43 PM, Sedat Dilek wrote: > On Fri, Apr 19, 2013 at 12:27 PM, Sedat Dilek wrote: >> On Fri, Apr 19, 2013 at 12:19 PM, Sedat Dilek wrote: >>> On Thu, Apr 18, 2013 at 11:59 PM, Sedat Dilek wrote: >>>> On Thu, Apr 18, 2013 at 9:48 PM, Daniel Vetter >>>> wrote: >>>>> On Thu, Apr 18, 2013 at 3:05 PM, Sedat Dilek >>>>> wrote: >>>>>> On Thu, Apr 18, 2013 at 10:28 AM, Stephen Rothwell >>>>>> wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Changes since 20130417: >>>>>>> >>>>>>> New Trees: rpmsg (actually added yesterday) >>>>>>> ppc-temp (replacing powerpc for this week) >>>>>>> >>>>>>> The ceph tree gained a conflict against Linus' tree. >>>>>>> >>>>>>> The net-next tree gained a conflict against the infiniband tree. >>>>>>> >>>>>>> The usb tree gained a build failure so I used the version from >>>>>>> next-20130417. >>>>>>> >>>>>>> I added two merge fix patches after the gen-gpio tree. >>>>>>> >>>>>>> The ppc-temp tree gained a conflict against the metag tree. >>>>>>> >>>>>>> The akpm tree lost a patch that turned up elsewhere. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Not sure what the root-cause for this call-trace is (see screenshot). >>>>>> >>>>>> This is reproducible when running my kernel build-script (4 >>>>>> parallel-make-jobs). >>>>>> >>>>>> Any hints welcome! >>>>> >>>>> The panic handlers in our modeset code are pretty decent fubar - they >>>>> take mutexes all over the place. So I think the backtrace you see >>>>> there is actually a secondary effect. I've looked into fixing this up, >>>>> but the issue is that drivers themselves have tons of state protected >>>>> with mutexes, which all potentially affects the panic handler. So I've >>>>> given up on that for now ... >>>> >>>> Thanks for taking care. >>>> >>>> On suspicion [1] I have reverted [2]... NOPE. >>>> >>>> - Sedat - >>>> >>>> [1] http://marc.info/?l=linux-kernel&m=136631921208895&w=2 >>>> [2] >>>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=5a90d1a95356de7a32acb2e5309ac579a891af8f >>>> >>> >>> Hmmm, the issue seems to be gone with today's Linux-Next (next-20130419). >>> My kernel-build is still running with no call-trace... >>> >> >> NO, It's no good. >> > > I tried to switch from SLUB to SLAB... > > ...and also from VIRT_CPU_ACCOUNTING_GEN to TICK_CPU_ACCOUNTING. > > 2x NOPE. > > In one kernel-build I saw in my console... > > semop(1): encountered an error: Identifier removed > > ...if this says sth. to you. > [ CC folks from below thread ] I have found a thread called "Re: ipc,sem: sysv semaphore scalability" on LKML with a screenshot that shows the same call-trace. I followed it a bit. There is a patch in [3]... unconfirmed. Comments on the rcu read-lock and "sem_lock()" vs "sem_unlock()" from Linus. What's the status of this discussion? - Sedat - [1] https://lkml.org/lkml/2013/3/30/6 [2] http://i.imgur.com/uk6gmq1.jpg [3] https://lkml.org/lkml/2013/3/31/12 [4] https://lkml.org/lkml/2013/3/31/77 > - Sedat - > > - Sedat - > >> - Sedat - >> >> [1] http://www.youtube.com/watch?v=LwicaralvS0 >> >>> - Sedat - >>> >>>>> -Daniel >>>>> -- >>>>> Daniel Vetter >>>>> Software Engineer, Intel Corporation >>>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: [GIT PULL] at91: soc for 3.10 #3
Hi Nicolas, On Thu, Apr 18, 2013 at 04:51:42PM +0200, Nicolas Ferre wrote: > Arnd, Olof, > > Third pull-request for AT91 SoC support based on material that you already > have > in your arm-soc/at91/soc branch. > Not very core changes here but interesting enhancements. > > Thanks, best regards, > > The following changes since commit 471c9e786596c4f028c67c7e9de0703b49cab2a9: > > ARM: at91: add defconfig for SAMA5 (2013-03-26 12:18:05 +0100) > > are available in the git repository at: > > git://github.com/at91linux/linux-at91.git tags/at91-soc The warning makes sense to pick up now, and the other patch seems well contained and harmless. I'll merge this branch into late/cleanup even though it is getting very close to the merge window. -Olof -- 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/
[RFC PATCH] Fix: remove stale include/linux/version.h in toplevel Makefile
With a kernel tree that contains a generated include/linux/version.h, if someone just does a git pull to update to a newer kernel version that includes commit 10b63956fce7f369cc37fd4d994f09bd5203efe4 "UAPI: Plumb the UAPI Kbuilds into the user header installation and checking" and commit d183e6f570f3c0c23d253fd262c90244e72d7ffd "UAPI: Move linux/version.h" Any newer build will fail to overwrite or remove the stale version.h file. The new include/generated/uapi/linux/version.h is indeed generated, but the stale file in include/linux has precedence. This leads to very unfortunate consequences for any user relying on version.h to expose the kernel version accurately, since the old "stale" kernel version will be seen by the build. Ensure that stale include/linux/version.h is removed whenever the new version.h is generated. Signed-off-by: Mathieu Desnoyers CC: David Howells CC: Arnd Bergmann CC: Thomas Gleixner CC: "Paul E. McKenney" CC: Dave Jones CC: Linus Torvalds --- Makefile |2 ++ 1 file changed, 2 insertions(+) Index: linux/Makefile === --- linux.orig/Makefile +++ linux/Makefile @@ -823,8 +823,10 @@ endif # prepare2 creates a makefile if using a separate output directory prepare2: prepare3 outputmakefile asm-generic +# Includes removal of stale version.h from earlier kernel versions. prepare1: prepare2 $(version_h) include/generated/utsrelease.h \ include/config/auto.conf + $(Q)rm -f include/linux/version.h $(cmd_crmodverdir) archprepare: archheaders archscripts prepare1 scripts_basic -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- 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 wireless-next V2] rt2x00: Use more current logging styles, shrink object size
On 04/19/13 17:33, Joe Perches wrote: > Reduce object space ~2% using more current logging styles. > > Neaten and simplify logging macros. > Use wiphy_ where appropriate. > Coalesce formats. > > Convert ERROR/WARNING/INFO macros to rt2x00_ > Convert EEPROM to rt2x00_eeprom_dbg > Convert PROBE_ERROR to rt2x00_probe_err > Convert DEBUG to rt2x00_dbg > Convert EEPROM to rt2x00_eeprom_dbg > > $ size drivers/net/wireless/rt2x00/built-in.o* >text data bss dec hex filename > 245639 71696 69584 386919 5e767 > drivers/net/wireless/rt2x00/built-in.o.new > 240609 70096 68944 379649 5cb01 > drivers/net/wireless/rt2x00/built-in.o.new.nodyndbg > 240609 70096 68944 379649 5cb01 > drivers/net/wireless/rt2x00/built-in.o.new.no_rt2x00_debug > 249198 70096 70352 389646 5f20e > drivers/net/wireless/rt2x00/built-in.o.old > 249198 70096 70352 389646 5f20e > drivers/net/wireless/rt2x00/built-in.o.old.nodyndbg > 244222 70096 69712 384030 5dc1e > drivers/net/wireless/rt2x00/built-in.o.old.no_rt2x00_debug > > Signed-off-by: Joe Perches Acked-by: Gertjan van Wingerde > --- > V2 differences: > > Correct copy/paste error in rt2x00_info/warn macros > Reorder macro definitions > Use embedded prefix in rt2x00_eeprom_dbg > > Object size increased from v1 ~100 bytes x86/32. > Object size may be slightly smaller this way for x86/64 > > --- Gertjan -- 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 05/10] cpuset: don't update tasks' cpumask and nodemask in an empty cpuset
Hello, Li. On Fri, Apr 19, 2013 at 08:27:05PM +0800, Li Zefan wrote: > I think this was introduced unintentionally when cpuset hotplug was > made asynchronous. Fortunately it does no harm, as updating tasks' > cpumask will just return failure and there's a guarantee_online_mems() > when updating nodemask, and then the tasks will be moved to an ancestor > cpuset. Yeah, which will update the masks to the proper values anyway, so it was intentionally written that way as it didn't really matter either way. I suppose this helps future changes? Maybe update the description a bit? Thanks. -- tejun -- 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: Re: [PATCH] I2C: Change the value of octeon i2c adapter timeout value
On Fri, Apr 19, 2013 at 09:13:54AM +, EUNBONG SONG wrote: > > > On Fri, Apr 19, 2013 at 12:01:04AM +, EUNBONG SONG wrote: > >> > >> I think HZ/50 is better than 2 for adapter timeout. > > > Basically OK. But why HZ/50? Most drivers use HZ. > > Actually, I just translated 2 jiffies because HZ is 100 in default cavium > config. > You can find that in "arch/mips/configs/cavium_octeon_defconfig". > And i have been using this value over 1 year in octeon board without problem. Have you been writing to EEPROMS? Their erase/write cycle might be longer. But I am not forcing you to change the value, just giving some suggestions. -- 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] I2C: Fix i2c fail problem when a process is terminated by a signal on octeon in 3.8
On Thu, Apr 18, 2013 at 07:40:16AM +, 송은봉 wrote: > > I rewrite my patch because the patch before i sent have many white space. > Thanks! This should have been below the "---" after the sigend-off. > --- > I've been debugging the abnormal operation of i2c on octeon. > If a process is terminated by signal in the middle of i2c operation, > next i2c read operation which is done by another process was failed. > So i changed to ignore signal in the middle of i2c operation. > After that the problem was not reproduced. > > Signed-off-by: Eunbong Song Applied to for-next, thanks! -- 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] mtd: Convert logging messages
On Fri, 2013-04-19 at 12:55 -0400, Jörn Engel wrote:
> On Fri, 19 April 2013 10:59:35 -0700, Joe Perches wrote:
> > }
> > list_add(&dev->list, &blkmtd_device_list);
> > - INFO("mtd%d: [%s] erase_size = %dKiB [%d]", dev->mtd.index,
> > - dev->mtd.name + strlen("block2mtd: "),
> > - dev->mtd.erasesize >> 10, dev->mtd.erasesize);
> > + pr_info("mtd%d: [%s] erase_size = %dKiB [%d]\n",
> > + dev->mtd.index,
> > + dev->mtd.name + strlen("block2mtd: "),
> > + dev->mtd.erasesize >> 10, dev->mtd.erasesize);
>
> I personally dislike the indent-to-braces style because it causes
> unnecessary churn in patches like this.
It comes from an automated emacs conversion.
> The reindenting improves nothing at all.
Debatable.
> It will waste time when people care about revision history because
> they encounter a bug, want a fix quick and are pressed for time.
Not really if you use existing tools with options.
Try:
git diff -w
git blame -w
> If you care about my ack, please remove random churn. This is not a
> competition about who gets the most lines in git blame.
I care not at all about commit counts,
nor things like lines added or removed.
--
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 04/10] cpuset: remove cpuset_test_cpumask()
On Fri, Apr 19, 2013 at 08:26:15PM +0800, Li Zefan wrote: > The test is done in set_cpus_allowed_ptr(), so it's redundant. > > Signed-off-by: Li Zefan For 0001-0004, Acked-by: Tejun Heo I'll apply these into for-3.11 once v3.10-rc1 drops. Thanks. -- tejun -- 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: [char-misc-next 2/3] mei: fix reading large reposnes
On Fri, Apr 19, 2013 at 09:16:54PM +0300, Tomas Winkler wrote: > While writting to device is limitted to max_msg_length advertized > in client properites the read can be much longer delivered consequiting > chunks. > > We use krealloc to enlarge the buffer when needed. > > Signed-off-by: Tomas Winkler Patch 1/3 had some fuzz in interrupt.c, so I fixed that up by hand, but this one just fails to apply at all: checking file drivers/misc/mei/bus.c checking file drivers/misc/mei/client.c checking file drivers/misc/mei/client.h checking file drivers/misc/mei/interrupt.c Hunk #1 FAILED at 145. 1 out of 1 hunk FAILED checking file drivers/misc/mei/main.c So something is out of sync between us. Care to refresh this patch based on my latest tree, and 3/3, and resend them? thanks, greg k-h -- 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: Kernel bug: opensuse 12.3, lenovo 3000 n100 laptop
Is this easy to reproduce? Do you know whether the same thing happens > with an upstream kernel, e.g., v3.8 or v3.9-rc7? If it turns out that > this bug still exists in the upstream kernel, Zhang will probably be > interested in it. It isn't easy to simulate. It only happened to me one. I'll file with the OpenSUSE guys and see what they say. I don't know if it happens with the upstream kernels. Thanks. -- 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: [NEW DRIVER V6 6/7] drivers/hwmon: DA9058 HWMON driver
Same comment as before, I'd like to see this using the generic IIO to HWMON
bridge instead of recreating it.
On 04/19/2013 06:56 PM, Anthony Olech wrote:
> This patch is relative to next-20130419 of linux-next
>
> This is the HWMON component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC driver.
> It depends on the CORE and ADC component drivers of the DA9058 MFD.
>
> Please note that this driver does use regmap via the CORE and ADC
> component drivers of the DA9058 MFD.
>
> Changes relative to V5 of this patch:
> - rebased to next-20130419 in
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> - removed redundant #include
> - corrected dates on copyright statements
> Documentation/hwmon/da9058
> - removed trailing blank line to prevent 'git apply' warning
> drivers/hwmon/da9058-hwmon.c
> - put spaces aount the '*' multiply operator
> - use the word 'extract' rather than 'recover' in a comment
> - use da9058_labels[] in show_label instead of switch case
> - use multiple exit points in functions when no common code
> is to be executed.
> - aligned continuation lines to preceeding '(' or indent + 2 tabs
> - removed redundant mutex hwmon_lock
> - merged 6 duplicate lines from 2 branches of if statement
>
> Signed-off-by: Anthony Olech
> Signed-off-by: David Dajun Chen
> ---
> Documentation/hwmon/da9058 | 38 +
> drivers/hwmon/Kconfig| 10 ++
> drivers/hwmon/Makefile |3 +-
> drivers/hwmon/da9058-hwmon.c | 330
> ++
> 4 files changed, 380 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/hwmon/da9058
> create mode 100644 drivers/hwmon/da9058-hwmon.c
>
> diff --git a/Documentation/hwmon/da9058 b/Documentation/hwmon/da9058
> new file mode 100644
> index 000..841148f
> --- /dev/null
> +++ b/Documentation/hwmon/da9058
> @@ -0,0 +1,38 @@
> +Kernel driver da9058-hwmon
> +==
> +
> +Supported chips:
> + * Dialog Semiconductor DA9058 PMIC
> +Prefix: 'da9058'
> +Datasheet:
> + http://www.dialog-semiconductor.com/products/power-management/da9058
> +
> +Authors: Opensource [Anthony Olech]
> +
> +Description
> +---
> +
> +The DA9058 PMIC contains a 5 channel ADC which can be used to monitor a
> +range of system operating parameters, including the battery voltage and
> +temperature. The ADC measures voltage, but two of the ADC channels can
> +be configured to supply a current, so that if an NTC termister is connected
> +then the voltage reading can be converted to a temperature. Currently the
> +driver provides reporting of all the input values but does not provide any
> +alarms.
> +
> +Voltage Monitoring
> +--
> +
> +Voltages are sampled in either 'automatic' or 'manual' mode, which is an
> +initialization parameter set in the platform data by the machine driver.
> +In manual mode the ADC conversion is 12 bit and in automatic mode it is
> +10 bit. However all the raw readings are reported as 12 bit numbers.
> +
> +Physical Limits
> +---
> +
> +vbat 2500 - 4500 milliVolts
> +tbat 0- 2500 milliVolts
> +adc0- 2500 milliVolts
> +vfpin 0- 4095 milliVolts
> +tjunc there is a correction factor programmed during manufacturing
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 79bc431..cb074c4 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -337,6 +337,16 @@ config SENSORS_ATXP1
> This driver can also be built as a module. If so, the module
> will be called atxp1.
>
> +config SENSORS_DA9058
> + tristate "Dialog Semiconductor DA9058 ADC"
> + depends on MFD_DA9058 && DA9058_ADC
> + help
> + If you say yes here you get support for the hardware monitoring
> + functionality of the Dialog Semiconductor DA9058 PMIC.
> +
> + This driver can also be built as a module. If so, the module
> + will be called da9058-hwmon.
> +
> config SENSORS_DS620
> tristate "Dallas Semiconductor DS620"
> depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index d17d3e6..6001549 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -47,7 +47,8 @@ obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o
> obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o
> obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o
> obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o
> -obj-$(CONFIG_SENSORS_DA9055)+= da9055-hwmon.o
> +obj-$(
Re: [PATCH] mtd: Convert logging messages
On Fri, 19 April 2013 10:59:35 -0700, Joe Perches wrote:
> }
> list_add(&dev->list, &blkmtd_device_list);
> - INFO("mtd%d: [%s] erase_size = %dKiB [%d]", dev->mtd.index,
> - dev->mtd.name + strlen("block2mtd: "),
> - dev->mtd.erasesize >> 10, dev->mtd.erasesize);
> + pr_info("mtd%d: [%s] erase_size = %dKiB [%d]\n",
> + dev->mtd.index,
> + dev->mtd.name + strlen("block2mtd: "),
> + dev->mtd.erasesize >> 10, dev->mtd.erasesize);
I personally dislike the indent-to-braces style because it causes
unnecessary churn in patches like this. The reindenting improves
nothing at all. On the contrary, when going through revision history
at some point in the future I have to waste brain time to verify
whether any function change has slipped in or not. It doesn't just
waste my time right now, it will continue to waste time in the future.
It will waste time when people care about revision history because
they encounter a bug, want a fix quick and are pressed for time.
If you care about my ack, please remove random churn. This is not a
competition about who gets the most lines in git blame.
Jörn
--
Public Domain - Free as in Beer
General Public - Free as in Speech
BSD License- Free as in Enterprise
Shared Source - Free as in "Work will make you..."
--
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] mei: reseting -> resetting
> > Why do you ack a patch that doesn't apply? :) Sorry for that didn't check it much ...it was just spelling which others are obviously better in than me. Anyhow I took a liberty to rebase it myself Thanks Tomas -- 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: [NEW DRIVER V6 2/7] drivers/iio/adc: DA9058 ADC driver
Same issues as in v5 plus one more ...
On 04/19/2013 06:56 PM, Anthony Olech wrote:
> This patch is relative to next-20130419 of linux-next
>
> This is the ADC component driver of the Dialog DA9058 PMIC.
> This driver is just one component of the whole DA9058 PMIC
> driver. It depends on the DA9058 CORE component driver.
> The HWMON component driver depends on this ADC component driver.
>
> This component driver recieves the actual platform data from
> the DA9058 CORE driver, whose settings may be overridden from
> the platform data supplied from the machine driver.
>
> Changes relative to V5 of this patch:
> - rebased to next-20130419 in
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> - removed redundant #include
> - changed to using devm_request_threaded_irq()
This creates a race condition...
> - corrected dates on copyright statements
>
> Signed-off-by: Anthony Olech
> Signed-off-by: David Dajun Chen
> ---
> drivers/iio/adc/Kconfig | 12 ++
> drivers/iio/adc/Makefile |1 +
> drivers/iio/adc/da9058-adc.c | 396
> ++
> 3 files changed, 409 insertions(+)
> create mode 100644 drivers/iio/adc/da9058-adc.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index ab0767e6..68162bf 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -111,6 +111,18 @@ config EXYNOS_ADC
> of SoCs for drivers such as the touchscreen and hwmon to use to share
> this resource.
>
> +config DA9058_ADC
> + tristate "Dialog DA9058 PMIC ADC"
> + depends on MFD_DA9058
> + select SYSFS
> + help
> + Say yes here to build support for the ADC component of
> + the DAILOG DA9058 PMIC.
> + If unsure, say N (but it's safe to say "Y").
> +
> + To compile this driver as a module, choose M here: the
> + module will be called da9058-adc.
> +
> config LP8788_ADC
> bool "LP8788 ADC driver"
> depends on MFD_LP8788
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 0a825be..ad04a7d 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_AD7791) += ad7791.o
> obj-$(CONFIG_AD7793) += ad7793.o
> obj-$(CONFIG_AD7887) += ad7887.o
> obj-$(CONFIG_AT91_ADC) += at91_adc.o
> +obj-$(CONFIG_DA9058_ADC) += da9058-adc.o
> obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> obj-$(CONFIG_MAX1363) += max1363.o
> diff --git a/drivers/iio/adc/da9058-adc.c b/drivers/iio/adc/da9058-adc.c
> new file mode 100644
> index 000..872eaba
> --- /dev/null
> +++ b/drivers/iio/adc/da9058-adc.c
> @@ -0,0 +1,396 @@
> +/*
> + * Copyright (C) 2012, 2013 Dialog Semiconductor Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct da9058_adc {
> + struct da9058 *da9058;
> + struct platform_device *pdev;
> + struct rtc_device *rtc_dev;
> + int use_automatic_adc;
> + int irq;
> +};
> +
> +/*
> + * if the PMIC is in automatic ADC consersion mode we have the choice
> + * of just getting the last (automatic) conversion or doing a manual
> + * conversion anyway.
> + *
> + * if the PMIC is not in automatic ADC consersion mode we have no choice
> + * we just have to ignore the requested mode and just do a manual
> + * ADC conversion.
> + */
> +static int da9058_automatic_adc_conversion(struct da9058 *da9058,
> + const int channel, unsigned int *value)
> +{
> + unsigned int adc_msh, adc_lsh;
> + int ret;
> +
> + switch (channel) {
> + case DA9058_ADCMAN_MUXSEL_VBAT:
> + ret = da9058_reg_read(da9058, DA9058_VBATRES_REG_MSB,
> + &adc_msh);
> + if (ret)
> + return ret;
> +
> + ret = da9058_reg_read(da9058, DA9058_AUTORES_REG_1,
> + &adc_lsh);
> + if (ret)
> + return ret;
> +
> + *value = (adc_lsh & 0x0F) | (adc_msh << 4);
> +
> + return 0;
> + case DA9058_ADCMAN_
[char-misc-next 2/3] mei: fix reading large reposnes
While writting to device is limitted to max_msg_length advertized
in client properites the read can be much longer delivered consequiting chunks.
We use krealloc to enlarge the buffer when needed.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus.c | 8
drivers/misc/mei/client.c| 7 ---
drivers/misc/mei/client.h| 2 +-
drivers/misc/mei/interrupt.c | 18 +++---
drivers/misc/mei/main.c | 7 +++
5 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 834ceeb..1e935ea 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -286,7 +286,7 @@ int __mei_cl_recv(struct mei_cl *cl, u8 *buf, size_t length)
mutex_lock(&dev->device_lock);
if (!cl->read_cb) {
- err = mei_cl_read_start(cl);
+ err = mei_cl_read_start(cl, length);
if (err < 0) {
mutex_unlock(&dev->device_lock);
return err;
@@ -378,7 +378,7 @@ static void mei_bus_event_work(struct work_struct *work)
device->events = 0;
/* Prepare for the next read */
- mei_cl_read_start(device->cl);
+ mei_cl_read_start(device->cl, 0);
}
int mei_cl_register_event_cb(struct mei_cl_device *device,
@@ -392,7 +392,7 @@ int mei_cl_register_event_cb(struct mei_cl_device *device,
device->event_context = context;
INIT_WORK(&device->event_work, mei_bus_event_work);
- mei_cl_read_start(device->cl);
+ mei_cl_read_start(device->cl, 0);
return 0;
}
@@ -436,7 +436,7 @@ int mei_cl_enable_device(struct mei_cl_device *device)
mutex_unlock(&dev->device_lock);
if (device->event_cb && !cl->read_cb)
- mei_cl_read_start(device->cl);
+ mei_cl_read_start(device->cl, 0);
if (!device->ops || !device->ops->enable)
return 0;
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 9541aa9..7189274 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -624,7 +624,7 @@ int mei_cl_flow_ctrl_reduce(struct mei_cl *cl)
*
* returns 0 on success, <0 on failure.
*/
-int mei_cl_read_start(struct mei_cl *cl)
+int mei_cl_read_start(struct mei_cl *cl, size_t length)
{
struct mei_device *dev;
struct mei_cl_cb *cb;
@@ -657,8 +657,9 @@ int mei_cl_read_start(struct mei_cl *cl)
if (!cb)
return -ENOMEM;
- rets = mei_io_cb_alloc_resp_buf(cb,
- dev->me_clients[i].props.max_msg_length);
+ /* always allocate at least client max message */
+ length = max_t(size_t, length, dev->me_clients[i].props.max_msg_length);
+ rets = mei_io_cb_alloc_resp_buf(cb, length);
if (rets)
goto err;
diff --git a/drivers/misc/mei/client.h b/drivers/misc/mei/client.h
index e890c8b..cfdb144 100644
--- a/drivers/misc/mei/client.h
+++ b/drivers/misc/mei/client.h
@@ -87,7 +87,7 @@ int mei_cl_flow_ctrl_reduce(struct mei_cl *cl);
bool mei_cl_is_other_connecting(struct mei_cl *cl);
int mei_cl_disconnect(struct mei_cl *cl);
int mei_cl_connect(struct mei_cl *cl, struct file *file);
-int mei_cl_read_start(struct mei_cl *cl);
+int mei_cl_read_start(struct mei_cl *cl, size_t length);
int mei_cl_write(struct mei_cl *cl, struct mei_cl_cb *cb, bool blocking);
void mei_host_client_init(struct work_struct *work);
diff --git a/drivers/misc/mei/interrupt.c b/drivers/misc/mei/interrupt.c
index 9bf64c0..7473071 100644
--- a/drivers/misc/mei/interrupt.c
+++ b/drivers/misc/mei/interrupt.c
@@ -145,9 +145,21 @@ static int mei_cl_irq_read_msg(struct mei_device *dev,
}
if (cb->response_buffer.size < mei_hdr->length + cb->buf_idx) {
- dev_warn(&dev->pdev->dev, "message overflow.\n");
- list_del(&cb->list);
- return -ENOMEM;
+ dev_dbg(&dev->pdev->dev, "message overflow. size %d len
%d idx %ld\n",
+ cb->response_buffer.size,
+ mei_hdr->length, cb->buf_idx);
+ cb->response_buffer.data =
+ krealloc(cb->response_buffer.data,
+ mei_hdr->length + cb->buf_idx,
+ GFP_KERNEL);
+
+ if (!cb->response_buffer.data) {
+ dev_err(&dev->pdev->dev, "allocation
failed.\n");
+ list_del(&cb->list);
+ return -ENOMEM;
+ }
+ cb->response_buffer.size =
+ mei_hdr->length + cb->buf_idx;
}
buffer = cb->response_buffer.data + cb->buf_idx;
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index 78b4da5..7c44c8d 100644
[char-misc-next 3/3 V2] mei: reseting -> resetting
From: Bill Nottingham
This enum leaks out to userspace via error messages, so fix the spelling.
Signed-off-by: Bill Nottingham
Signed-off-by: Tomas Winkler
---
V2: rebased
drivers/misc/mei/hbm.c | 8
drivers/misc/mei/hw-me.c | 2 +-
drivers/misc/mei/init.c| 4 ++--
drivers/misc/mei/mei_dev.h | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index 4de80d9..db605f5 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -52,7 +52,7 @@ static void mei_hbm_me_cl_allocate(struct mei_device *dev)
sizeof(struct mei_me_client), GFP_KERNEL);
if (!clients) {
dev_err(&dev->pdev->dev, "memory allocation for ME clients
failed.\n");
- dev->dev_state = MEI_DEV_RESETING;
+ dev->dev_state = MEI_DEV_RESETTING;
mei_reset(dev, 1);
return;
}
@@ -167,7 +167,7 @@ int mei_hbm_start_req(struct mei_device *dev)
dev->hbm_state = MEI_HBM_IDLE;
if (mei_write_message(dev, mei_hdr, dev->wr_msg.data)) {
dev_err(&dev->pdev->dev, "version message writet failed\n");
- dev->dev_state = MEI_DEV_RESETING;
+ dev->dev_state = MEI_DEV_RESETTING;
mei_reset(dev, 1);
return -ENODEV;
}
@@ -196,7 +196,7 @@ static void mei_hbm_enum_clients_req(struct mei_device *dev)
enum_req->hbm_cmd = HOST_ENUM_REQ_CMD;
if (mei_write_message(dev, mei_hdr, dev->wr_msg.data)) {
- dev->dev_state = MEI_DEV_RESETING;
+ dev->dev_state = MEI_DEV_RESETTING;
dev_err(&dev->pdev->dev, "enumeration request write failed.\n");
mei_reset(dev, 1);
}
@@ -249,7 +249,7 @@ static int mei_hbm_prop_req(struct mei_device *dev)
prop_req->address = next_client_index;
if (mei_write_message(dev, mei_hdr, dev->wr_msg.data)) {
- dev->dev_state = MEI_DEV_RESETING;
+ dev->dev_state = MEI_DEV_RESETTING;
dev_err(&dev->pdev->dev, "properties request write failed\n");
mei_reset(dev, 1);
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 3d6dfa3..fc03227 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -481,7 +481,7 @@ irqreturn_t mei_me_irq_thread_handler(int irq, void *dev_id)
/* check if ME wants a reset */
if (!mei_hw_is_ready(dev) &&
- dev->dev_state != MEI_DEV_RESETING &&
+ dev->dev_state != MEI_DEV_RESETTING &&
dev->dev_state != MEI_DEV_INITIALIZING) {
dev_dbg(&dev->pdev->dev, "FW not ready.\n");
mei_reset(dev, 1);
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index 59159e0..713d89f 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -33,7 +33,7 @@ const char *mei_dev_state_str(int state)
MEI_DEV_STATE(INITIALIZING);
MEI_DEV_STATE(INIT_CLIENTS);
MEI_DEV_STATE(ENABLED);
- MEI_DEV_STATE(RESETING);
+ MEI_DEV_STATE(RESETTING);
MEI_DEV_STATE(DISABLED);
MEI_DEV_STATE(POWER_DOWN);
MEI_DEV_STATE(POWER_UP);
@@ -146,7 +146,7 @@ void mei_reset(struct mei_device *dev, int
interrupts_enabled)
if (dev->dev_state != MEI_DEV_INITIALIZING) {
if (dev->dev_state != MEI_DEV_DISABLED &&
dev->dev_state != MEI_DEV_POWER_DOWN)
- dev->dev_state = MEI_DEV_RESETING;
+ dev->dev_state = MEI_DEV_RESETTING;
mei_cl_all_disconnect(dev);
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index c91c492..4de5140 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -97,7 +97,7 @@ enum mei_dev_state {
MEI_DEV_INITIALIZING = 0,
MEI_DEV_INIT_CLIENTS,
MEI_DEV_ENABLED,
- MEI_DEV_RESETING,
+ MEI_DEV_RESETTING,
MEI_DEV_DISABLED,
MEI_DEV_POWER_DOWN,
MEI_DEV_POWER_UP
--
1.8.1.2
--
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/
[char-misc-next 1/3] mei: revamp mei_amthif_irq_read_message
Rename the function to mei_amthif_irq_read_msg
and change parameters order
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/amthif.c| 10 +-
drivers/misc/mei/interrupt.c | 2 +-
drivers/misc/mei/mei_dev.h | 9 +
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/mei/amthif.c b/drivers/misc/mei/amthif.c
index 9a5e8c7..31a6212 100644
--- a/drivers/misc/mei/amthif.c
+++ b/drivers/misc/mei/amthif.c
@@ -505,14 +505,15 @@ int mei_amthif_irq_write_complete(struct mei_device *dev,
s32 *slots,
* mei_amthif_irq_read_message - read routine after ISR to
* handle the read amthif message
*
- * @complete_list: An instance of our list structure
* @dev: the device structure
* @mei_hdr: header of amthif message
+ * @complete_list: An instance of our list structure
*
* returns 0 on success, <0 on failure.
*/
-int mei_amthif_irq_read_message(struct mei_cl_cb *complete_list,
- struct mei_device *dev, struct mei_msg_hdr *mei_hdr)
+int mei_amthif_irq_read_msg(struct mei_device *dev,
+ struct mei_msg_hdr *mei_hdr,
+ struct mei_cl_cb *complete_list)
{
struct mei_cl_cb *cb;
unsigned char *buffer;
@@ -530,8 +531,7 @@ int mei_amthif_irq_read_message(struct mei_cl_cb
*complete_list,
if (!mei_hdr->msg_complete)
return 0;
- dev_dbg(&dev->pdev->dev,
- "amthif_message_buffer_index =%d\n",
+ dev_dbg(&dev->pdev->dev, "amthif_message_buffer_index =%d\n",
mei_hdr->length);
dev_dbg(&dev->pdev->dev, "completed amthif read.\n ");
diff --git a/drivers/misc/mei/interrupt.c b/drivers/misc/mei/interrupt.c
index 653fcfb..9bf64c0 100644
--- a/drivers/misc/mei/interrupt.c
+++ b/drivers/misc/mei/interrupt.c
@@ -427,7 +427,7 @@ int mei_irq_read_handler(struct mei_device *dev,
dev_dbg(&dev->pdev->dev, "call
mei_irq_thread_read_iamthif_message.\n");
dev_dbg(&dev->pdev->dev, MEI_HDR_FMT, MEI_HDR_PRM(mei_hdr));
- ret = mei_amthif_irq_read_message(cmpl_list, dev, mei_hdr);
+ ret = mei_amthif_irq_read_msg(dev, mei_hdr, cmpl_list);
if (ret)
goto end;
} else {
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 56dee56..c91c492 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -502,6 +502,15 @@ struct mei_cl_cb *mei_amthif_find_read_list_entry(struct
mei_device *dev,
void mei_amthif_run_next_cmd(struct mei_device *dev);
+int mei_amthif_irq_write_complete(struct mei_device *dev, s32 *slots,
+ struct mei_cl_cb *cb, struct mei_cl_cb *cmpl_list);
+
+void mei_amthif_complete(struct mei_device *dev, struct mei_cl_cb *cb);
+int mei_amthif_irq_read_msg(struct mei_device *dev,
+ struct mei_msg_hdr *mei_hdr,
+ struct mei_cl_cb *complete_list);
+int mei_amthif_irq_read(struct mei_device *dev, s32 *slots);
+
/*
* NFC functions
*/
--
1.8.1.2
--
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/8] workqueue: advance concurrency management
Hey, On Fri, Apr 19, 2013 at 06:10:57AM +0800, Lai Jiangshan wrote: > Ping. Sorry, I've been at collab summit / lsf. Plus, it's a bit too late for for-3.10 anyway. Anyways, after glancing over it, here are my preliminary thoughts. The first one looks good but I'm not sure about dropping nr_running adjustment. The only real benefit coming from that is dropping a sched callback and if there's any performance / overhead impact, I'm afraid it's gonna be negative. There are actual benefits in using as few tasks as possible - the cache footprint gets smaller, so unless there's a clear indication that the suggested behavior is better in some way, I'm not sure what we're buying with the proposed changes. Thanks. -- tejun -- 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] process cputimer is moving faster than its corresponding clock
On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro wrote: >> I feel we are hitting the same issue than this patch: >> https://lkml.org/lkml/2013/4/5/116 >> >> I'm adding Kosaki in Cc, who proposed roughly the same fix. > > Thanks to CCing. I'm now sitting LSF and I can't read whole tons emails. > However the fix is definitely same and I definitely agree this approach. > > thank you. And if I understand correctly, update_gt_cputime() is no longer necessary after this patch because time never makes backward. What do you think? -- 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/
