* Re: [PATCH] libceph: fix protocol feature mismatch failure path
From: Alex Elder @ 2012-12-28 0:30 UTC (permalink / raw)
To: Sage Weil; +Cc: ceph-devel
In-Reply-To: <1356653240-23146-1-git-send-email-sage@inktank.com>
On 12/27/2012 06:07 PM, Sage Weil wrote:
> We should not set con->state to CLOSED here; that happens in ceph_fault()
> in the caller, where it first asserts that the state is not yet CLOSED.
I'm not seeing the code path you're talking about.
Do you mean in the LOSSYTX case?
(I don't doubt you're right, I'm just trying to follow
along at home.)
> Avoids a BUG when the features don't match.
Is this related to the crashes reported here?
http://tracker.newdream.net/issues/3657
> Signed-off-by: Sage Weil <sage@inktank.com>
> ---
> net/ceph/messenger.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
> index 4d111fd..24a5c86 100644
> --- a/net/ceph/messenger.c
> +++ b/net/ceph/messenger.c
> @@ -1508,9 +1508,9 @@ static int process_banner(struct ceph_connection *con)
>
> static void fail_protocol(struct ceph_connection *con)
> {
> + dout("fail_protocol %p\n", con);
> reset_connection(con);
> BUG_ON(con->state != CON_STATE_NEGOTIATING);
Since fail_protocol becomes essentially a trivial wrapper
for reset_connection(), I think it should just go away
and call reset_connection() directly. The assertion that
it's in NEGOTIATING state is not very useful at the moment;
fail_protocol() is only called from process_connect(),
and that's only called from try_read when the state
is NEGOTIATING.
-Alex
> - con->state = CON_STATE_CLOSED;
> }
>
> static int process_connect(struct ceph_connection *con)
>
^ permalink raw reply
* Re: [PATCH v5 14/14] memory-hotplug: free node_data when a node is offlined
From: Kamezawa Hiroyuki @ 2012-12-28 0:28 UTC (permalink / raw)
To: Wen Congyang
Cc: Tang Chen, akpm, rientjes, liuj97, len.brown, benh, paulus, cl,
minchan.kim, kosaki.motohiro, isimatu.yasuaki, wujianguo, hpa,
linfeng, laijs, mgorman, yinghai, x86, linux-mm, linux-kernel,
linuxppc-dev, linux-acpi, linux-s390, linux-sh, linux-ia64,
cmetcalf, sparclinux
In-Reply-To: <50DC3C26.6060308@cn.fujitsu.com>
(2012/12/27 21:16), Wen Congyang wrote:
> At 12/26/2012 11:55 AM, Kamezawa Hiroyuki Wrote:
>> (2012/12/24 21:09), Tang Chen wrote:
>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>
>>> We call hotadd_new_pgdat() to allocate memory to store node_data. So we
>>> should free it when removing a node.
>>>
>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>>
>> I'm sorry but is it safe to remove pgdat ? All zone cache and zonelists are
>> properly cleared/rebuilded in synchronous way ? and No threads are visinting
>> zone in vmscan.c ?
>
> We have rebuilt zonelists when a zone has no memory after offlining some pages.
>
How do you guarantee that the address of pgdat/zone is not on stack of any kernel
threads or other kernel objects without reference counting or other syncing method ?
Thanks,
-Kame
^ permalink raw reply
* Re: [PATCH v5 14/14] memory-hotplug: free node_data when a node is offlined
From: Kamezawa Hiroyuki @ 2012-12-28 0:28 UTC (permalink / raw)
To: Wen Congyang
Cc: linux-ia64, linux-sh, Tang Chen, linux-mm, paulus, hpa,
sparclinux, cl, linux-s390, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, liuj97, len.brown,
cmetcalf, wujianguo, yinghai, laijs, linux-kernel, minchan.kim,
akpm, linuxppc-dev
In-Reply-To: <50DC3C26.6060308@cn.fujitsu.com>
(2012/12/27 21:16), Wen Congyang wrote:
> At 12/26/2012 11:55 AM, Kamezawa Hiroyuki Wrote:
>> (2012/12/24 21:09), Tang Chen wrote:
>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>
>>> We call hotadd_new_pgdat() to allocate memory to store node_data. So we
>>> should free it when removing a node.
>>>
>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>>
>> I'm sorry but is it safe to remove pgdat ? All zone cache and zonelists are
>> properly cleared/rebuilded in synchronous way ? and No threads are visinting
>> zone in vmscan.c ?
>
> We have rebuilt zonelists when a zone has no memory after offlining some pages.
>
How do you guarantee that the address of pgdat/zone is not on stack of any kernel
threads or other kernel objects without reference counting or other syncing method ?
Thanks,
-Kame
^ permalink raw reply
* Re: [PATCH v5 14/14] memory-hotplug: free node_data when a node is offlined
From: Kamezawa Hiroyuki @ 2012-12-28 0:28 UTC (permalink / raw)
To: Wen Congyang
Cc: Tang Chen, akpm, rientjes, liuj97, len.brown, benh, paulus, cl,
minchan.kim, kosaki.motohiro, isimatu.yasuaki, wujianguo, hpa,
linfeng, laijs, mgorman, yinghai, x86, linux-mm, linux-kernel,
linuxppc-dev, linux-acpi, linux-s390, linux-sh, linux-ia64,
cmetcalf, sparclinux
In-Reply-To: <50DC3C26.6060308@cn.fujitsu.com>
(2012/12/27 21:16), Wen Congyang wrote:
> At 12/26/2012 11:55 AM, Kamezawa Hiroyuki Wrote:
>> (2012/12/24 21:09), Tang Chen wrote:
>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>
>>> We call hotadd_new_pgdat() to allocate memory to store node_data. So we
>>> should free it when removing a node.
>>>
>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>>
>> I'm sorry but is it safe to remove pgdat ? All zone cache and zonelists are
>> properly cleared/rebuilded in synchronous way ? and No threads are visinting
>> zone in vmscan.c ?
>
> We have rebuilt zonelists when a zone has no memory after offlining some pages.
>
How do you guarantee that the address of pgdat/zone is not on stack of any kernel
threads or other kernel objects without reference counting or other syncing method ?
Thanks,
-Kame
^ permalink raw reply
* Re: [PATCH v5 14/14] memory-hotplug: free node_data when a node is offlined
From: Kamezawa Hiroyuki @ 2012-12-28 0:28 UTC (permalink / raw)
To: Wen Congyang
Cc: Tang Chen, akpm, rientjes, liuj97, len.brown, benh, paulus, cl,
minchan.kim, kosaki.motohiro, isimatu.yasuaki, wujianguo, hpa,
linfeng, laijs, mgorman, yinghai, x86, linux-mm, linux-kernel,
linuxppc-dev, linux-acpi, linux-s390, linux-sh, linux-ia64,
cmetcalf, sparclinux
In-Reply-To: <50DC3C26.6060308@cn.fujitsu.com>
(2012/12/27 21:16), Wen Congyang wrote:
> At 12/26/2012 11:55 AM, Kamezawa Hiroyuki Wrote:
>> (2012/12/24 21:09), Tang Chen wrote:
>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>
>>> We call hotadd_new_pgdat() to allocate memory to store node_data. So we
>>> should free it when removing a node.
>>>
>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>>
>> I'm sorry but is it safe to remove pgdat ? All zone cache and zonelists are
>> properly cleared/rebuilded in synchronous way ? and No threads are visinting
>> zone in vmscan.c ?
>
> We have rebuilt zonelists when a zone has no memory after offlining some pages.
>
How do you guarantee that the address of pgdat/zone is not on stack of any kernel
threads or other kernel objects without reference counting or other syncing method ?
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v4 0/3] Support volatile for anonymous range
From: Kamezawa Hiroyuki @ 2012-12-28 0:24 UTC (permalink / raw)
To: Minchan Kim
Cc: Andrew Morton, linux-kernel, linux-mm, Michael Kerrisk,
Arun Sharma, sanjay, Paul Turner, David Rientjes, John Stultz,
Christoph Lameter, Android Kernel Team, Robert Love, Mel Gorman,
Hugh Dickins, Dave Hansen, Rik van Riel, Dave Chinner, Neil Brown,
Mike Hommey, Taras Glek, KOSAKI Motohiro
In-Reply-To: <20121226034600.GB2453@blaptop>
(2012/12/26 12:46), Minchan Kim wrote:
> Hi Kame,
>
> What are you doing these holiday season? :)
> I can't believe you sit down in front of computer.
>
Honestly, my holiday starts tomorrow ;) (but until 1/5 in the next year.)
>>
>> Hm, by the way, the user need to attach pages to the process by causing page-fault
>> (as you do by memset()) before calling mvolatile() ?
>
> For effectiveness, Yes.
>
Isn't it better to make page-fault by get_user_pages() in mvolatile() ?
Calling page fault in userland seems just to increase burden of apps.
>>
>> I think your approach is interesting, anyway.
>
> Thanks for your interest, Kame.
>
> あけましておめでとう.
>
A happy new year.
Thanks,
-Kame
^ permalink raw reply
* Re: [RFC v4 0/3] Support volatile for anonymous range
From: Kamezawa Hiroyuki @ 2012-12-28 0:24 UTC (permalink / raw)
To: Minchan Kim
Cc: Andrew Morton, linux-kernel, linux-mm, Michael Kerrisk,
Arun Sharma, sanjay, Paul Turner, David Rientjes, John Stultz,
Christoph Lameter, Android Kernel Team, Robert Love, Mel Gorman,
Hugh Dickins, Dave Hansen, Rik van Riel, Dave Chinner, Neil Brown,
Mike Hommey, Taras Glek, KOSAKI Motohiro
In-Reply-To: <20121226034600.GB2453@blaptop>
(2012/12/26 12:46), Minchan Kim wrote:
> Hi Kame,
>
> What are you doing these holiday season? :)
> I can't believe you sit down in front of computer.
>
Honestly, my holiday starts tomorrow ;) (but until 1/5 in the next year.)
>>
>> Hm, by the way, the user need to attach pages to the process by causing page-fault
>> (as you do by memset()) before calling mvolatile() ?
>
> For effectiveness, Yes.
>
Isn't it better to make page-fault by get_user_pages() in mvolatile() ?
Calling page fault in userland seems just to increase burden of apps.
>>
>> I think your approach is interesting, anyway.
>
> Thanks for your interest, Kame.
>
> a??a??a? 3/4 a??a?|a??a??a??a??a??.
>
A happy new year.
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
From: David R. Piegdon @ 2012-12-27 23:55 UTC (permalink / raw)
To: linux-kernel; +Cc: Zlatko Calusic
In-Reply-To: <50DC622B.7000802@iskon.hr>
Hi,
NOTE to everyone debugging this: reproduced quickly with X + firefox +
youtube (adobe flash plugin)
> Would you be so kind to test the following patch and report results?
> Apply the patch to the latest mainline.
I've had probably the same problem (dmesg below) and currently am trying
your patch applied to current mainline (101e5c7470eb7f). so far it looks
very good. (before: bug after 5-30 minutes, right now 1h and counting)
thanks!
[ 105.164610] ------------[ cut here ]------------
[ 105.164614] kernel BUG at mm/huge_memory.c:1798!
[ 105.164617] invalid opcode: 0000 [#1] PREEMPT SMP
[ 105.164621] Modules linked in: fuse sha256_generic xt_owner xt_LOG xt_limit xt_recent xt_conntrack xt_multiport iptable_mangle xt_DSCP iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack fbcon font bitblit softcursor fb fbdev hwmon_vid btrfs zlib_deflate zlib_inflate xfs libcrc32c snd_usb_audio uvcvideo snd_usbmidi_lib videobuf2_core snd_rawmidi videobuf2_vmalloc videobuf2_memops hid_kensington iTCO_wdt joydev gpio_ich iTCO_vendor_support raid1 fglrx(PO) coretemp kvm_intel kvm skge acpi_cpufreq lpc_ich serio_raw asus_atk0110 snd_hda_codec_hdmi intel_agp snd_hda_intel mperf intel_gtt processor snd_hda_codec sky2 agpgart snd_hwdep [last unloaded: iTCO_wdt]
[ 105.164672] CPU 1
[ 105.164677] Pid: 4091, comm: XPCOM CC Tainted: P O 3.8.0-rc1+ #43 System manufacturer System Product Name/P5B-Deluxe
[ 105.164679] RIP: 0010:[<ffffffff81120fb6>] [<ffffffff81120fb6>] __split_huge_page+0x216/0x240
[ 105.164688] RSP: 0018:ffff880091511c48 EFLAGS: 00010297
[ 105.164690] RAX: 0000000000000001 RBX: ffff8800a210c000 RCX: 0000000000000042
[ 105.164692] RDX: 00000000000000cb RSI: 0000000000000046 RDI: ffffffff81b28a20
[ 105.164694] RBP: ffff880091511ca8 R08: 000000000000ffff R09: 0000000000000000
[ 105.164696] R10: 000000000000043d R11: 0000000000000001 R12: ffff8800a2295c60
[ 105.164698] R13: ffffea00021e0000 R14: 0000000000000000 R15: 00000007f5134600
[ 105.164701] FS: 00007f514991e700(0000) GS:ffff8800bfc80000(0000) knlGS:0000000000000000
[ 105.164703] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 105.164705] CR2: 00007f5123bff000 CR3: 000000009531b000 CR4: 00000000000007e0
[ 105.164707] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 105.164709] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 105.164712] Process XPCOM CC (pid: 4091, threadinfo ffff880091510000, task ffff8800953616b0)
[ 105.164713] Stack:
[ 105.164715] ffff880000000000 ffff8800b9c834b0 00007f5134800000 000000008158c4a5
[ 105.164719] ffff8800a210c064 00007f5134600000 ffff880091511ca8 ffffea00021e0000
[ 105.164723] ffff8800b9c83480 ffff8800a210c000 ffff88009fdc1d18 ffff8800a210c064
[ 105.164727] Call Trace:
[ 105.164732] [<ffffffff81121048>] split_huge_page+0x68/0xb0
[ 105.164736] [<ffffffff81121d48>] __split_huge_page_pmd+0x1a8/0x220
[ 105.164740] [<ffffffff810f72f6>] unmap_page_range+0x1b6/0x2d0
[ 105.164744] [<ffffffff810f746b>] unmap_single_vma+0x5b/0xe0
[ 105.164747] [<ffffffff810f7e6c>] zap_page_range+0xbc/0x120
[ 105.164752] [<ffffffff8108f556>] ? futex_wake+0x116/0x130
[ 105.164756] [<ffffffff8106e396>] ? pick_next_task_fair+0x36/0xb0
[ 105.164760] [<ffffffff810f4367>] madvise_vma+0xf7/0x140
[ 105.164764] [<ffffffff810fddc2>] ? find_vma_prev+0x12/0x60
[ 105.164767] [<ffffffff810f45ed>] sys_madvise+0x23d/0x330
[ 105.164772] [<ffffffff8158e712>] system_call_fastpath+0x16/0x1b
[ 105.164774] Code: 48 89 df e8 ed 10 ff ff e9 ab fe ff ff 0f 0b 41 8b 55 18 8b 75 bc ff c2 48 c7 c7 38 0e 7d 81 31 c0 e8 13 9b 46 00 e9 15 ff ff ff <0f> 0b 41 8b 4d 18 89 da ff c1 8b 75 bc 48 c7 c7 58 0e 7d 81 31
[ 105.164814] RIP [<ffffffff81120fb6>] __split_huge_page+0x216/0x240
[ 105.164818] RSP <ffff880091511c48>
[ 105.164823] ---[ end trace 00c060fd7d17a3d4 ]---
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
From: Sedat Dilek @ 2012-12-28 0:24 UTC (permalink / raw)
To: Zlatko Calusic; +Cc: LKML, linux-mm
In-Reply-To: <50DCDEE5.9000700@iskon.hr>
On Fri, Dec 28, 2012 at 12:51 AM, Zlatko Calusic
<zlatko.calusic@iskon.hr> wrote:
> On 28.12.2012 00:42, Sedat Dilek wrote:
>>
>> On Fri, Dec 28, 2012 at 12:39 AM, Zlatko Calusic
>> <zlatko.calusic@iskon.hr> wrote:
>>>
>>> On 28.12.2012 00:30, Sedat Dilek wrote:
>>>>
>>>>
>>>> Hi Zlatko,
>>>>
>>>> I am not sure if I hit the same problem as described in this thread.
>>>>
>>>> Under heavy load, while building a customized toolchain for the Freetz
>>>> router project I got a BUG || NULL pointer derefence || kswapd ||
>>>> zone_balanced || pgdat_balanced() etc. (details see my screenshot).
>>>>
>>>> I will try your patch from [1] ***only*** on top of my last
>>>> Linux-v3.8-rc1 GIT setup (post-v3.8-rc1 mainline + some net-fixes).
>>>>
>>>
>>> Yes, that's the same bug. It should be fixed with my latest patch, so I'd
>>> appreciate you testing it, to be on the safe side this time. There should
>>> be
>>> no difference if you apply it to anything newer than 3.8-rc1, so go for
>>> it.
>>> Thanks!
>>>
>>
>> Not sure how I can really reproduce this bug as one build worked fine
>> within my last v3.8-rc1 kernel.
>> I increased the parallel-make-jobs-number from "4" to "8" to stress a
>> bit harder.
>> Just building right now... and will report.
>>
>> If you have any test-case (script or whatever), please let me/us know.
>>
>
> Unfortunately not, I haven't reproduced it yet on my machines. But it seems
> that bug will hit only under heavy memory pressure. When close to OOM, or
> possibly with lots of writing to disk. It's also possible that fragmentation
> of memory zones could provoke it, that means testing it for a longer time.
>
I tested successfully by doing simultaneously...
- building Freetz with 8 parallel make-jobs
- building Linux GIT with 1 make-job
- 9 tabs open in firefox
- In one tab I ran YouTube music video
- etc.
I am reading [1] and [2] where another user reports success by reverting this...
commit cda73a10eb3f493871ed39f468db50a65ebeddce
"mm: do not sleep in balance_pgdat if there's no i/o congestion"
BTW, this machine has also 4GiB RAM (Ubuntu/precise AMD64).
Feel free to add a "Reported-by/Tested-by" if you think this is a
positive report.
- Sedat -
[1] http://marc.info/?l=linux-mm&m=135652835931174&w=2
[2] http://marc.info/?l=linux-mm&m=135653399800655&w=2
> --
> Zlatko
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
From: Sedat Dilek @ 2012-12-28 0:24 UTC (permalink / raw)
To: Zlatko Calusic; +Cc: LKML, linux-mm
In-Reply-To: <50DCDEE5.9000700@iskon.hr>
On Fri, Dec 28, 2012 at 12:51 AM, Zlatko Calusic
<zlatko.calusic@iskon.hr> wrote:
> On 28.12.2012 00:42, Sedat Dilek wrote:
>>
>> On Fri, Dec 28, 2012 at 12:39 AM, Zlatko Calusic
>> <zlatko.calusic@iskon.hr> wrote:
>>>
>>> On 28.12.2012 00:30, Sedat Dilek wrote:
>>>>
>>>>
>>>> Hi Zlatko,
>>>>
>>>> I am not sure if I hit the same problem as described in this thread.
>>>>
>>>> Under heavy load, while building a customized toolchain for the Freetz
>>>> router project I got a BUG || NULL pointer derefence || kswapd ||
>>>> zone_balanced || pgdat_balanced() etc. (details see my screenshot).
>>>>
>>>> I will try your patch from [1] ***only*** on top of my last
>>>> Linux-v3.8-rc1 GIT setup (post-v3.8-rc1 mainline + some net-fixes).
>>>>
>>>
>>> Yes, that's the same bug. It should be fixed with my latest patch, so I'd
>>> appreciate you testing it, to be on the safe side this time. There should
>>> be
>>> no difference if you apply it to anything newer than 3.8-rc1, so go for
>>> it.
>>> Thanks!
>>>
>>
>> Not sure how I can really reproduce this bug as one build worked fine
>> within my last v3.8-rc1 kernel.
>> I increased the parallel-make-jobs-number from "4" to "8" to stress a
>> bit harder.
>> Just building right now... and will report.
>>
>> If you have any test-case (script or whatever), please let me/us know.
>>
>
> Unfortunately not, I haven't reproduced it yet on my machines. But it seems
> that bug will hit only under heavy memory pressure. When close to OOM, or
> possibly with lots of writing to disk. It's also possible that fragmentation
> of memory zones could provoke it, that means testing it for a longer time.
>
I tested successfully by doing simultaneously...
- building Freetz with 8 parallel make-jobs
- building Linux GIT with 1 make-job
- 9 tabs open in firefox
- In one tab I ran YouTube music video
- etc.
I am reading [1] and [2] where another user reports success by reverting this...
commit cda73a10eb3f493871ed39f468db50a65ebeddce
"mm: do not sleep in balance_pgdat if there's no i/o congestion"
BTW, this machine has also 4GiB RAM (Ubuntu/precise AMD64).
Feel free to add a "Reported-by/Tested-by" if you think this is a
positive report.
- Sedat -
[1] http://marc.info/?l=linux-mm&m=135652835931174&w=2
[2] http://marc.info/?l=linux-mm&m=135653399800655&w=2
> --
> Zlatko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH RESEND] regulator: lp3972: Convert to get_voltage_sel
From: Axel Lin @ 2012-12-28 0:23 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, linux-kernel
regulator_list_voltage_table() returns -EINVAL if selector >= n_voltages.
Thus we don't need to check if reg is greater than LP3972_BUCK_VOL_MAX_IDX in
lp3972_[ldo|dcdc]_get_voltage_sel.
LP3972_BUCK_VOL_MIN_IDX and LP3972_BUCK_VOL_MAX_IDX are not used, remove them.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
---
Hi Mark,
This patch was sent on https://lkml.org/lkml/2012/12/10/283 ,
and you replied it's applied.
But it seems not (yet) in regulator tree, so I resend it.
Axel
drivers/regulator/lp3972.c | 22 ++++++----------------
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/regulator/lp3972.c b/drivers/regulator/lp3972.c
index 69c42c3..0baabcf 100644
--- a/drivers/regulator/lp3972.c
+++ b/drivers/regulator/lp3972.c
@@ -165,8 +165,6 @@ static const int buck_base_addr[] = {
#define LP3972_BUCK_VOL_ENABLE_REG(x) (buck_vol_enable_addr[x])
#define LP3972_BUCK_VOL1_REG(x) (buck_base_addr[x])
#define LP3972_BUCK_VOL_MASK 0x1f
-#define LP3972_BUCK_VOL_MIN_IDX(x) ((x) ? 0x01 : 0x00)
-#define LP3972_BUCK_VOL_MAX_IDX(x) ((x) ? 0x19 : 0x1f)
static int lp3972_i2c_read(struct i2c_client *i2c, char reg, int count,
u16 *dest)
@@ -257,7 +255,7 @@ static int lp3972_ldo_disable(struct regulator_dev *dev)
mask, 0);
}
-static int lp3972_ldo_get_voltage(struct regulator_dev *dev)
+static int lp3972_ldo_get_voltage_sel(struct regulator_dev *dev)
{
struct lp3972 *lp3972 = rdev_get_drvdata(dev);
int ldo = rdev_get_id(dev) - LP3972_LDO1;
@@ -267,7 +265,7 @@ static int lp3972_ldo_get_voltage(struct regulator_dev *dev)
reg = lp3972_reg_read(lp3972, LP3972_LDO_VOL_CONTR_REG(ldo));
val = (reg >> LP3972_LDO_VOL_CONTR_SHIFT(ldo)) & mask;
- return dev->desc->volt_table[val];
+ return val;
}
static int lp3972_ldo_set_voltage_sel(struct regulator_dev *dev,
@@ -314,7 +312,7 @@ static struct regulator_ops lp3972_ldo_ops = {
.is_enabled = lp3972_ldo_is_enabled,
.enable = lp3972_ldo_enable,
.disable = lp3972_ldo_disable,
- .get_voltage = lp3972_ldo_get_voltage,
+ .get_voltage_sel = lp3972_ldo_get_voltage_sel,
.set_voltage_sel = lp3972_ldo_set_voltage_sel,
};
@@ -353,24 +351,16 @@ static int lp3972_dcdc_disable(struct regulator_dev *dev)
return val;
}
-static int lp3972_dcdc_get_voltage(struct regulator_dev *dev)
+static int lp3972_dcdc_get_voltage_sel(struct regulator_dev *dev)
{
struct lp3972 *lp3972 = rdev_get_drvdata(dev);
int buck = rdev_get_id(dev) - LP3972_DCDC1;
u16 reg;
- int val;
reg = lp3972_reg_read(lp3972, LP3972_BUCK_VOL1_REG(buck));
reg &= LP3972_BUCK_VOL_MASK;
- if (reg <= LP3972_BUCK_VOL_MAX_IDX(buck))
- val = dev->desc->volt_table[reg];
- else {
- val = 0;
- dev_warn(&dev->dev, "chip reported incorrect voltage value."
- " reg = %d\n", reg);
- }
- return val;
+ return reg;
}
static int lp3972_dcdc_set_voltage_sel(struct regulator_dev *dev,
@@ -402,7 +392,7 @@ static struct regulator_ops lp3972_dcdc_ops = {
.is_enabled = lp3972_dcdc_is_enabled,
.enable = lp3972_dcdc_enable,
.disable = lp3972_dcdc_disable,
- .get_voltage = lp3972_dcdc_get_voltage,
+ .get_voltage_sel = lp3972_dcdc_get_voltage_sel,
.set_voltage_sel = lp3972_dcdc_set_voltage_sel,
};
--
1.7.9.5
^ permalink raw reply related
* How to pair device from CLI?
From: Kamil Jońca @ 2012-12-28 0:23 UTC (permalink / raw)
To: linux-bluetooth
I don't know if this is proper list, but I cannot find any (active) bluez users
list.
I tried to pair my phone:
--8<---------------cut here---------------start------------->8---
$hcitool scan
Scanning ...
D4:E8:B2:AA:15:FA theta
$bluez-simple-agent hci0 D4:E8:B2:AA:15:FA
RequestPasskey (/org/bluez/3086/hci0/dev_D4_E8_B2_AA_15_FA)
Enter passkey: 0000
Creating device failed: org.bluez.Error.AuthenticationFailed: Authentication Failed
--8<---------------cut here---------------end--------------->8---
What do I should check? (s)trace?
Distribution is pretty fresh debian sid.
--
http://blogdebart.pl/2012/06/24/hiena/
We're overpaying him, but he's worth it. -Samuel Goldwyn
^ permalink raw reply
* Re: HID battery strength does not emit power_suppy udev events
From: Daniel Nicoletti @ 2012-12-28 0:16 UTC (permalink / raw)
To: Jeremy Fitzhardinge, Jiri Kosina, Przemo Firszt, linux-input
In-Reply-To: <CACo8zOeSf_0ump=ChJKvgLQL1_OVoOE5Ts0ybw=5S3ZFMzZcGw@mail.gmail.com>
Hi, I've sent this message a while ago but forgot to add
linux-input, I'm really willing to give it a final fix to the issue
but I need directions, I really can't see what's wrong with
the udev thing, so again (with linux-input):
The problem is that when a HID device that has a battery
is added to the system it doesn't emit the udev events
for the battery added or removed, which breaks upower..
I reviewed all my previous patch, looked at input-wacom
to see if they did it differently for the battery issue, but
I couldn't find any problem, since I don't have a wacom
tablet maybe it also has the udev bug.
Well I looked through a lots of kernel code paths,
but the best I could find was:
"int kobject_uevent(struct kobject *kobj, enum kobject_action action);
Use the KOBJ_ADD action for when the kobject is first added to the kernel.
This should be done only after any attributes or children of the kobject
have been initialized properly, as userspace will instantly start to look
for them when this call happens."
Which might mean that a call like
kobject_uevent(&dev->kobj, KOBJ_ADD);
that I could only find in base/core.c is called
before the hid power_supply is registered,
I'm not a kernel dev so I might be totally wrong,
I also don't know the exact code path when the
device is added, could someone please give me
a hand on this?
Thanks,
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
^ permalink raw reply
* Re: [PATCH v3 01/11] kexec: introduce kexec firmware support
From: Daniel Kiper @ 2012-12-28 0:18 UTC (permalink / raw)
To: ebiederm
Cc: kexec, xen-devel, konrad.wilk, tglx, maxim.uvarov, andrew.cooper3,
hpa, jbeulich, mingo, x86, virtualization, vgoyal, linux-kernel
> Daniel Kiper <daniel.kiper@oracle.com> writes:
>
> > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default
> > Linux infrastructure and require some support from firmware and/or hypervisor.
> > To cope with that problem kexec firmware infrastructure was introduced.
> > It allows a developer to use all kexec/kdump features of given firmware
> > or hypervisor.
>
> As this stands this patch is wrong.
>
> You need to pass an additional flag from userspace through /sbin/kexec
> that says load the kexec image in the firmware. A global variable here
> is not ok.
>
> As I understand it you are loading a kexec on xen panic image. Which
> is semantically different from a kexec on linux panic image. It is not
> ok to do have a silly global variable kexec_use_firmware.
Earlier we agreed that /sbin/kexec should call kexec syscall with
special flag. However, during work on Xen kexec/kdump v3 patch
I stated that this is insufficient because e.g. crash_kexec()
should execute different code in case of use of firmware support too.
Sadly syscall does not save this flag anywhere. Additionally, I stated
that kernel itself has the best knowledge which code path should be
used (firmware or plain Linux). If this decision will be left to userspace
then simple kexec syscall could crash system at worst case (e.g. when
plain Linux kexec will be used in case when firmware kaxec should be used).
However, if you wish I could add this flag to syscall. Additionally, I could
add function which enables firmware support and then kexec_use_firmware
variable will be global only in kexec.c module.
> Furthermore it is not ok to have a conditional
> code outside of header files.
I agree but how to dispatch execution e.g. in crash_kexec()
if we would like (I suppose) compile kexec firmware
support conditionally?
Daniel
^ permalink raw reply
* Re: [PATCH v3 01/11] kexec: introduce kexec firmware support
From: Daniel Kiper @ 2012-12-28 0:18 UTC (permalink / raw)
To: ebiederm
Cc: xen-devel, linux-kernel, konrad.wilk, andrew.cooper3, hpa, kexec,
x86, virtualization, mingo, jbeulich, maxim.uvarov, tglx, vgoyal
> Daniel Kiper <daniel.kiper@oracle.com> writes:
>
> > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default
> > Linux infrastructure and require some support from firmware and/or hypervisor.
> > To cope with that problem kexec firmware infrastructure was introduced.
> > It allows a developer to use all kexec/kdump features of given firmware
> > or hypervisor.
>
> As this stands this patch is wrong.
>
> You need to pass an additional flag from userspace through /sbin/kexec
> that says load the kexec image in the firmware. A global variable here
> is not ok.
>
> As I understand it you are loading a kexec on xen panic image. Which
> is semantically different from a kexec on linux panic image. It is not
> ok to do have a silly global variable kexec_use_firmware.
Earlier we agreed that /sbin/kexec should call kexec syscall with
special flag. However, during work on Xen kexec/kdump v3 patch
I stated that this is insufficient because e.g. crash_kexec()
should execute different code in case of use of firmware support too.
Sadly syscall does not save this flag anywhere. Additionally, I stated
that kernel itself has the best knowledge which code path should be
used (firmware or plain Linux). If this decision will be left to userspace
then simple kexec syscall could crash system at worst case (e.g. when
plain Linux kexec will be used in case when firmware kaxec should be used).
However, if you wish I could add this flag to syscall. Additionally, I could
add function which enables firmware support and then kexec_use_firmware
variable will be global only in kexec.c module.
> Furthermore it is not ok to have a conditional
> code outside of header files.
I agree but how to dispatch execution e.g. in crash_kexec()
if we would like (I suppose) compile kexec firmware
support conditionally?
Daniel
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH v3 01/11] kexec: introduce kexec firmware support
From: Daniel Kiper @ 2012-12-28 0:18 UTC (permalink / raw)
To: ebiederm
Cc: xen-devel, linux-kernel, konrad.wilk, andrew.cooper3, hpa, kexec,
x86, virtualization, mingo, jbeulich, maxim.uvarov, tglx, vgoyal
> Daniel Kiper <daniel.kiper@oracle.com> writes:
>
> > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default
> > Linux infrastructure and require some support from firmware and/or hypervisor.
> > To cope with that problem kexec firmware infrastructure was introduced.
> > It allows a developer to use all kexec/kdump features of given firmware
> > or hypervisor.
>
> As this stands this patch is wrong.
>
> You need to pass an additional flag from userspace through /sbin/kexec
> that says load the kexec image in the firmware. A global variable here
> is not ok.
>
> As I understand it you are loading a kexec on xen panic image. Which
> is semantically different from a kexec on linux panic image. It is not
> ok to do have a silly global variable kexec_use_firmware.
Earlier we agreed that /sbin/kexec should call kexec syscall with
special flag. However, during work on Xen kexec/kdump v3 patch
I stated that this is insufficient because e.g. crash_kexec()
should execute different code in case of use of firmware support too.
Sadly syscall does not save this flag anywhere. Additionally, I stated
that kernel itself has the best knowledge which code path should be
used (firmware or plain Linux). If this decision will be left to userspace
then simple kexec syscall could crash system at worst case (e.g. when
plain Linux kexec will be used in case when firmware kaxec should be used).
However, if you wish I could add this flag to syscall. Additionally, I could
add function which enables firmware support and then kexec_use_firmware
variable will be global only in kexec.c module.
> Furthermore it is not ok to have a conditional
> code outside of header files.
I agree but how to dispatch execution e.g. in crash_kexec()
if we would like (I suppose) compile kexec firmware
support conditionally?
Daniel
^ permalink raw reply
* [PATCH v2 0/4] ARM: pxa: palmtreo: a few treo fixes
From: Tomas Cech @ 2012-12-28 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356631340-30328-1-git-send-email-mikedunn@newsguy.com>
Hi,
On Thu, Dec 27, 2012 at 10:02:16AM -0800, Mike Dunn wrote:
>Some miscellaneous fixes to the treo code.
>
>Change log:
>v2:
> patch 1: gpio initialization separated out from lcd initialization, per
> Marek's suggestion (lcd still initializes correctly this way).
> patch 2: Removed #ifdef CONFIG_MACH_TREO680 from around defines in
> both palmtreo.h and leds-gpio device data in palmtreo.c, per Marek's
> suggestion, and let compiler optimize out unused data (verified).
> patch 3: Use IS_EMABLED macro, per Sergei's suggestion
> patch 4: new patch for v2: use IS_ENABLED elsewhere in file
>
>Mike Dunn (4):
> ARM: palmtreo: fix lcd initilialization on treo680
> ARM: palmtreo: fix #ifdefs for leds-gpio device
> ARM: palmtreo: add docg4 device initialization
> ARM: palmtreo: replace #if defined with IF_ENABLED
>
> arch/arm/mach-pxa/include/mach/palmtreo.h | 5 +-
> arch/arm/mach-pxa/palmtreo.c | 101 ++++++++++++++++++++++++++---
> 2 files changed, 94 insertions(+), 12 deletions(-)
>
>--
>1.7.8.6
>
for all the patches
Acked-by: Tomas Cech <sleep_walker@suse.cz>
Thanks for these fixes!
Best regards,
Tomas Cech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121228/a4e5fc21/attachment.sig>
^ permalink raw reply
* Re: [PATCH 01/23] uvc: Replace memcpy with struct assignment
From: Mauro Carvalho Chehab @ 2012-12-27 23:49 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: linux-kernel, linux-media, Julia.Lawall, kernel-janitors,
Laurent Pinchart, Peter Senna Tschudin
In-Reply-To: <CALF0-+VQKxu7_-=aJeW-FxmM4fdVX1nBE7AA5-0d9SRgRqqM1g@mail.gmail.com>
Em Thu, 27 Dec 2012 18:12:46 -0300
Ezequiel Garcia <elezegarcia@gmail.com> escreveu:
> Mauro,
>
> On Tue, Oct 23, 2012 at 4:57 PM, Ezequiel Garcia <elezegarcia@gmail.com> wrote:
> > This kind of memcpy() is error-prone. Its replacement with a struct
> > assignment is prefered because it's type-safe and much easier to read.
> >
> > Found by coccinelle. Hand patched and reviewed.
> > Tested by compilation only.
> >
> > A simplified version of the semantic match that finds this problem is as
> > follows: (http://coccinelle.lip6.fr/)
> >
> > // <smpl>
> > @@
> > identifier struct_name;
> > struct struct_name to;
> > struct struct_name from;
> > expression E;
> > @@
> > -memcpy(&(to), &(from), E);
> > +to = from;
> > // </smpl>
> >
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
> > Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com>
> > ---
> > drivers/media/usb/uvc/uvc_v4l2.c | 6 +++---
> > 1 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
> > index f00db30..4fc8737 100644
> > --- a/drivers/media/usb/uvc/uvc_v4l2.c
> > +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> > @@ -314,7 +314,7 @@ static int uvc_v4l2_set_format(struct uvc_streaming *stream,
> > goto done;
> > }
> >
> > - memcpy(&stream->ctrl, &probe, sizeof probe);
> > + stream->ctrl = probe;
> > stream->cur_format = format;
> > stream->cur_frame = frame;
> >
> > @@ -386,7 +386,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming *stream,
> > return -EBUSY;
> > }
> >
> > - memcpy(&probe, &stream->ctrl, sizeof probe);
> > + probe = stream->ctrl;
> > probe.dwFrameInterval =
> > uvc_try_frame_interval(stream->cur_frame, interval);
> >
> > @@ -397,7 +397,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming *stream,
> > return ret;
> > }
> >
> > - memcpy(&stream->ctrl, &probe, sizeof probe);
> > + stream->ctrl = probe;
> > mutex_unlock(&stream->mutex);
> >
> > /* Return the actual frame period. */
> > --
> > 1.7.4.4
> >
>
> It seems you've marked this one as "Changes requested" [1].
> However, Laurent didn't request any change,
> but just pointed out we missed one memcpy replacement candidate.
>
> I believe it's safe to apply the patch (together with the other 20 patches)
> and we can fix the missing spot in another patch.
The other patches got applied already. Well just do whatever Laurent asked you
and re-submit this one ;)
Regards,
Mauro
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
From: Zlatko Calusic @ 2012-12-28 0:09 UTC (permalink / raw)
To: David R. Piegdon; +Cc: linux-kernel, linux-mm
In-Reply-To: <20121227235514.GA7166@ganymede>
On 28.12.2012 00:55, David R. Piegdon wrote:
> Hi,
>
> NOTE to everyone debugging this: reproduced quickly with X + firefox +
> youtube (adobe flash plugin)
>
>> Would you be so kind to test the following patch and report results?
>> Apply the patch to the latest mainline.
>
> I've had probably the same problem (dmesg below) and currently am trying
> your patch applied to current mainline (101e5c7470eb7f). so far it looks
> very good. (before: bug after 5-30 minutes, right now 1h and counting)
>
That's good news, except the oops you've attached belongs to another
bug, it seems. :P
People report good results when applying Hillf Danton suggestion to
revert 5a505085f0 and 4fc3f1d66b1. So, if the bug reappears, you could
help testing with the same procedure.
[Cc: linux-mm list]
> thanks!
>
>
> [ 105.164610] ------------[ cut here ]------------
> [ 105.164614] kernel BUG at mm/huge_memory.c:1798!
> [ 105.164617] invalid opcode: 0000 [#1] PREEMPT SMP
> [ 105.164621] Modules linked in: fuse sha256_generic xt_owner xt_LOG xt_limit xt_recent xt_conntrack xt_multiport iptable_mangle xt_DSCP iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack fbcon font bitblit softcursor fb fbdev hwmon_vid btrfs zlib_deflate zlib_inflate xfs libcrc32c snd_usb_audio uvcvideo snd_usbmidi_lib videobuf2_core snd_rawmidi videobuf2_vmalloc videobuf2_memops hid_kensington iTCO_wdt joydev gpio_ich iTCO_vendor_support raid1 fglrx(PO) coretemp kvm_intel kvm skge acpi_cpufreq lpc_ich serio_raw asus_atk0110 snd_hda_codec_hdmi intel_agp snd_hda_intel mperf intel_gtt processor snd_hda_codec sky2 agpgart snd_hwdep [last unloaded: iTCO_wdt]
> [ 105.164672] CPU 1
> [ 105.164677] Pid: 4091, comm: XPCOM CC Tainted: P O 3.8.0-rc1+ #43 System manufacturer System Product Name/P5B-Deluxe
> [ 105.164679] RIP: 0010:[<ffffffff81120fb6>] [<ffffffff81120fb6>] __split_huge_page+0x216/0x240
> [ 105.164688] RSP: 0018:ffff880091511c48 EFLAGS: 00010297
> [ 105.164690] RAX: 0000000000000001 RBX: ffff8800a210c000 RCX: 0000000000000042
> [ 105.164692] RDX: 00000000000000cb RSI: 0000000000000046 RDI: ffffffff81b28a20
> [ 105.164694] RBP: ffff880091511ca8 R08: 000000000000ffff R09: 0000000000000000
> [ 105.164696] R10: 000000000000043d R11: 0000000000000001 R12: ffff8800a2295c60
> [ 105.164698] R13: ffffea00021e0000 R14: 0000000000000000 R15: 00000007f5134600
> [ 105.164701] FS: 00007f514991e700(0000) GS:ffff8800bfc80000(0000) knlGS:0000000000000000
> [ 105.164703] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 105.164705] CR2: 00007f5123bff000 CR3: 000000009531b000 CR4: 00000000000007e0
> [ 105.164707] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 105.164709] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 105.164712] Process XPCOM CC (pid: 4091, threadinfo ffff880091510000, task ffff8800953616b0)
> [ 105.164713] Stack:
> [ 105.164715] ffff880000000000 ffff8800b9c834b0 00007f5134800000 000000008158c4a5
> [ 105.164719] ffff8800a210c064 00007f5134600000 ffff880091511ca8 ffffea00021e0000
> [ 105.164723] ffff8800b9c83480 ffff8800a210c000 ffff88009fdc1d18 ffff8800a210c064
> [ 105.164727] Call Trace:
> [ 105.164732] [<ffffffff81121048>] split_huge_page+0x68/0xb0
> [ 105.164736] [<ffffffff81121d48>] __split_huge_page_pmd+0x1a8/0x220
> [ 105.164740] [<ffffffff810f72f6>] unmap_page_range+0x1b6/0x2d0
> [ 105.164744] [<ffffffff810f746b>] unmap_single_vma+0x5b/0xe0
> [ 105.164747] [<ffffffff810f7e6c>] zap_page_range+0xbc/0x120
> [ 105.164752] [<ffffffff8108f556>] ? futex_wake+0x116/0x130
> [ 105.164756] [<ffffffff8106e396>] ? pick_next_task_fair+0x36/0xb0
> [ 105.164760] [<ffffffff810f4367>] madvise_vma+0xf7/0x140
> [ 105.164764] [<ffffffff810fddc2>] ? find_vma_prev+0x12/0x60
> [ 105.164767] [<ffffffff810f45ed>] sys_madvise+0x23d/0x330
> [ 105.164772] [<ffffffff8158e712>] system_call_fastpath+0x16/0x1b
> [ 105.164774] Code: 48 89 df e8 ed 10 ff ff e9 ab fe ff ff 0f 0b 41 8b 55 18 8b 75 bc ff c2 48 c7 c7 38 0e 7d 81 31 c0 e8 13 9b 46 00 e9 15 ff ff ff <0f> 0b 41 8b 4d 18 89 da ff c1 8b 75 bc 48 c7 c7 58 0e 7d 81 31
> [ 105.164814] RIP [<ffffffff81120fb6>] __split_huge_page+0x216/0x240
> [ 105.164818] RSP <ffff880091511c48>
> [ 105.164823] ---[ end trace 00c060fd7d17a3d4 ]---
>
--
Zlatko
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
From: Zlatko Calusic @ 2012-12-28 0:09 UTC (permalink / raw)
To: David R. Piegdon; +Cc: linux-kernel, linux-mm
In-Reply-To: <20121227235514.GA7166@ganymede>
On 28.12.2012 00:55, David R. Piegdon wrote:
> Hi,
>
> NOTE to everyone debugging this: reproduced quickly with X + firefox +
> youtube (adobe flash plugin)
>
>> Would you be so kind to test the following patch and report results?
>> Apply the patch to the latest mainline.
>
> I've had probably the same problem (dmesg below) and currently am trying
> your patch applied to current mainline (101e5c7470eb7f). so far it looks
> very good. (before: bug after 5-30 minutes, right now 1h and counting)
>
That's good news, except the oops you've attached belongs to another
bug, it seems. :P
People report good results when applying Hillf Danton suggestion to
revert 5a505085f0 and 4fc3f1d66b1. So, if the bug reappears, you could
help testing with the same procedure.
[Cc: linux-mm list]
> thanks!
>
>
> [ 105.164610] ------------[ cut here ]------------
> [ 105.164614] kernel BUG at mm/huge_memory.c:1798!
> [ 105.164617] invalid opcode: 0000 [#1] PREEMPT SMP
> [ 105.164621] Modules linked in: fuse sha256_generic xt_owner xt_LOG xt_limit xt_recent xt_conntrack xt_multiport iptable_mangle xt_DSCP iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack fbcon font bitblit softcursor fb fbdev hwmon_vid btrfs zlib_deflate zlib_inflate xfs libcrc32c snd_usb_audio uvcvideo snd_usbmidi_lib videobuf2_core snd_rawmidi videobuf2_vmalloc videobuf2_memops hid_kensington iTCO_wdt joydev gpio_ich iTCO_vendor_support raid1 fglrx(PO) coretemp kvm_intel kvm skge acpi_cpufreq lpc_ich serio_raw asus_atk0110 snd_hda_codec_hdmi intel_agp snd_hda_intel mperf intel_gtt processor snd_hda_codec sky2 agpgart snd_hwdep [last unloaded: iTCO_wdt]
> [ 105.164672] CPU 1
> [ 105.164677] Pid: 4091, comm: XPCOM CC Tainted: P O 3.8.0-rc1+ #43 System manufacturer System Product Name/P5B-Deluxe
> [ 105.164679] RIP: 0010:[<ffffffff81120fb6>] [<ffffffff81120fb6>] __split_huge_page+0x216/0x240
> [ 105.164688] RSP: 0018:ffff880091511c48 EFLAGS: 00010297
> [ 105.164690] RAX: 0000000000000001 RBX: ffff8800a210c000 RCX: 0000000000000042
> [ 105.164692] RDX: 00000000000000cb RSI: 0000000000000046 RDI: ffffffff81b28a20
> [ 105.164694] RBP: ffff880091511ca8 R08: 000000000000ffff R09: 0000000000000000
> [ 105.164696] R10: 000000000000043d R11: 0000000000000001 R12: ffff8800a2295c60
> [ 105.164698] R13: ffffea00021e0000 R14: 0000000000000000 R15: 00000007f5134600
> [ 105.164701] FS: 00007f514991e700(0000) GS:ffff8800bfc80000(0000) knlGS:0000000000000000
> [ 105.164703] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 105.164705] CR2: 00007f5123bff000 CR3: 000000009531b000 CR4: 00000000000007e0
> [ 105.164707] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 105.164709] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 105.164712] Process XPCOM CC (pid: 4091, threadinfo ffff880091510000, task ffff8800953616b0)
> [ 105.164713] Stack:
> [ 105.164715] ffff880000000000 ffff8800b9c834b0 00007f5134800000 000000008158c4a5
> [ 105.164719] ffff8800a210c064 00007f5134600000 ffff880091511ca8 ffffea00021e0000
> [ 105.164723] ffff8800b9c83480 ffff8800a210c000 ffff88009fdc1d18 ffff8800a210c064
> [ 105.164727] Call Trace:
> [ 105.164732] [<ffffffff81121048>] split_huge_page+0x68/0xb0
> [ 105.164736] [<ffffffff81121d48>] __split_huge_page_pmd+0x1a8/0x220
> [ 105.164740] [<ffffffff810f72f6>] unmap_page_range+0x1b6/0x2d0
> [ 105.164744] [<ffffffff810f746b>] unmap_single_vma+0x5b/0xe0
> [ 105.164747] [<ffffffff810f7e6c>] zap_page_range+0xbc/0x120
> [ 105.164752] [<ffffffff8108f556>] ? futex_wake+0x116/0x130
> [ 105.164756] [<ffffffff8106e396>] ? pick_next_task_fair+0x36/0xb0
> [ 105.164760] [<ffffffff810f4367>] madvise_vma+0xf7/0x140
> [ 105.164764] [<ffffffff810fddc2>] ? find_vma_prev+0x12/0x60
> [ 105.164767] [<ffffffff810f45ed>] sys_madvise+0x23d/0x330
> [ 105.164772] [<ffffffff8158e712>] system_call_fastpath+0x16/0x1b
> [ 105.164774] Code: 48 89 df e8 ed 10 ff ff e9 ab fe ff ff 0f 0b 41 8b 55 18 8b 75 bc ff c2 48 c7 c7 38 0e 7d 81 31 c0 e8 13 9b 46 00 e9 15 ff ff ff <0f> 0b 41 8b 4d 18 89 da ff c1 8b 75 bc 48 c7 c7 58 0e 7d 81 31
> [ 105.164814] RIP [<ffffffff81120fb6>] __split_huge_page+0x216/0x240
> [ 105.164818] RSP <ffff880091511c48>
> [ 105.164823] ---[ end trace 00c060fd7d17a3d4 ]---
>
--
Zlatko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* N/A
From: mrs philips Rita @ 2012-12-22 22:13 UTC (permalink / raw)
Dear
friend please i need your quick reply do not ignore this email for no reason
i am Mrs.Rita Philips
Thanks and God Be with you
Best Regards
^ permalink raw reply
* Re: bugreport Connectivity problems with rtl8192cu
From: Larry Finger @ 2012-12-28 0:04 UTC (permalink / raw)
To: Alden Page; +Cc: linux-wireless
In-Reply-To: <CABLZTyB12FX3e_yAoH7XOfhhA-pcv4GqzpfkBDNi64jdh5eCXA@mail.gmail.com>
On 12/27/2012 05:43 PM, Alden Page wrote:
What is this doing here? You need to have either the in-kernel driver available,
or the vendor driver. This bit shows you have both.
> [ 5.448046] rtw driver version=v3.4.4_4749.20121105
> [ 5.448049] Build at: Dec 20 2012 21:30:41
> [ 5.448052] Error: Driver 'rtl8192cu' is already registered, aborting...
I doubt that this bit is the reason for any problems, but why tempt fate?
Larry
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Sascha Hauer @ 2012-12-28 0:04 UTC (permalink / raw)
To: Rob Clark
Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list,
Benjamin Gaignard, Tom Gall, Kyungmin Park,
dri-devel@lists.freedesktop.org, Ragesh Radhakrishnan,
Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan,
Sumit Semwal, Sebastien Guiriec, linux-media@vger.kernel.org
In-Reply-To: <CAF6AEGtWOoNjKuUgu=AaZn3Jj8g_D807Ycyjtu5bro8ZLL1NNg@mail.gmail.com>
On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote:
> On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
> >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
> >
> > This implies that the master driver knows all potential subdevices,
> > something which is not true for SoCs which have external i2c encoders
> > attached to unrelated i2c controllers.
>
> well, it can be brute-forced.. ie. drm driver calls common
> register_all_panels() fxn, which, well, registers all the
> panel/display subdev's based on their corresponding CONFIG_FOO_PANEL
> defines. If you anyways aren't building the panels as separate
> modules, that would work. Maybe not the most *elegant* approach, but
> simple and functional.
>
> I guess it partly depends on the structure in devicetree. If you are
> assuming that the i2c encoder belongs inside the i2c bus, like:
>
> &i2cN {
> foo-i2c-encoder {
> ....
> };
> };
>
> and you are letting devicetree create the devices, then it doesn't
> quite work. I'm not entirely convinced you should do it that way.
> Really any device like that is going to be hooked up to at least a
> couple busses.. i2c, some sort of bus carrying pixel data, maybe some
> gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and
> then use phandle stuff to link it to the various other busses it
> needs:
>
> mydrmdev {
> foo-i2c-encoder {
> i2c = <&i2cN>;
> gpio = <&gpioM 2 3>
> ...
> };
> };
This seems to shift initialization order problem to another place.
Here we have to make sure the controller is initialized before the drm
driver. Same with suspend/resume.
It's not only i2c devices, also platform devices. On i.MX for example we
have a hdmi transmitter which is somewhere on the physical address
space.
I think grouping the different units together in a devicetree blob
because we think they might form a logical virtual device is not going
to work. It might make it easier from a drm perspective, but I think
doing this will make for a lot of special cases. What will happen for
example if you have two encoder devices in a row to configure? The
foo-i2c-encoder would then get another child node.
Right now the devicetree is strictly ordered by (control-, not data-)
bus topology. Linux has great helper code to support this model. Giving
up this help to brute force a different topology and then trying to fit
the result back into the Linux Bus hierarchy doesn't sound like a good
idea to me.
>
> ok, admittedly that is a bit different from other proposals about how
> this all fits in devicetree.. but otoh, I'm not a huge believer in
> letting something that is supposed to make life easier (DT), actually
> make things harder or more complicated. Plus this CDF stuff all needs
> to also work on platforms not using OF/DT.
Right, but every other platform I know of is also described by its bus
topology, be it platform device based or PCI or maybe even USB based.
CDF has to solve the same problem as ASoC and soc-camera: subdevices for
a virtual device can come from many different corners of the system. BTW
one example for a i2c encoder would be the SiI9022 which could not only
be part of a drm device, but also of an ASoC device.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Sascha Hauer @ 2012-12-28 0:04 UTC (permalink / raw)
To: Rob Clark
Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list,
Benjamin Gaignard, Tom Gall, Kyungmin Park,
dri-devel@lists.freedesktop.org, Ragesh Radhakrishnan,
Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan,
Sumit Semwal, Sebastien Guiriec, linux-media@vger.kernel.org
In-Reply-To: <CAF6AEGtWOoNjKuUgu=AaZn3Jj8g_D807Ycyjtu5bro8ZLL1NNg@mail.gmail.com>
On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote:
> On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
> >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
> >
> > This implies that the master driver knows all potential subdevices,
> > something which is not true for SoCs which have external i2c encoders
> > attached to unrelated i2c controllers.
>
> well, it can be brute-forced.. ie. drm driver calls common
> register_all_panels() fxn, which, well, registers all the
> panel/display subdev's based on their corresponding CONFIG_FOO_PANEL
> defines. If you anyways aren't building the panels as separate
> modules, that would work. Maybe not the most *elegant* approach, but
> simple and functional.
>
> I guess it partly depends on the structure in devicetree. If you are
> assuming that the i2c encoder belongs inside the i2c bus, like:
>
> &i2cN {
> foo-i2c-encoder {
> ....
> };
> };
>
> and you are letting devicetree create the devices, then it doesn't
> quite work. I'm not entirely convinced you should do it that way.
> Really any device like that is going to be hooked up to at least a
> couple busses.. i2c, some sort of bus carrying pixel data, maybe some
> gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and
> then use phandle stuff to link it to the various other busses it
> needs:
>
> mydrmdev {
> foo-i2c-encoder {
> i2c = <&i2cN>;
> gpio = <&gpioM 2 3>
> ...
> };
> };
This seems to shift initialization order problem to another place.
Here we have to make sure the controller is initialized before the drm
driver. Same with suspend/resume.
It's not only i2c devices, also platform devices. On i.MX for example we
have a hdmi transmitter which is somewhere on the physical address
space.
I think grouping the different units together in a devicetree blob
because we think they might form a logical virtual device is not going
to work. It might make it easier from a drm perspective, but I think
doing this will make for a lot of special cases. What will happen for
example if you have two encoder devices in a row to configure? The
foo-i2c-encoder would then get another child node.
Right now the devicetree is strictly ordered by (control-, not data-)
bus topology. Linux has great helper code to support this model. Giving
up this help to brute force a different topology and then trying to fit
the result back into the Linux Bus hierarchy doesn't sound like a good
idea to me.
>
> ok, admittedly that is a bit different from other proposals about how
> this all fits in devicetree.. but otoh, I'm not a huge believer in
> letting something that is supposed to make life easier (DT), actually
> make things harder or more complicated. Plus this CDF stuff all needs
> to also work on platforms not using OF/DT.
Right, but every other platform I know of is also described by its bus
topology, be it platform device based or PCI or maybe even USB based.
CDF has to solve the same problem as ASoC and soc-camera: subdevices for
a virtual device can come from many different corners of the system. BTW
one example for a i2c encoder would be the SiI9022 which could not only
be part of a drm device, but also of an ASoC device.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [U-Boot] [PATCH 01/15] fdt: Use sed instead of cpp to pre-process the dtc
From: Stephen Warren @ 2012-12-28 0:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1356560913-2205-2-git-send-email-sjg@chromium.org>
On 12/26/2012 03:28 PM, Simon Glass wrote:
> Include file support in dtc is still not available in common distributions
> so we need to keep our preprocessing arrangement around for a little
> longer.
>
> But # is commonly used in FDT files, so use sed instead of cpp for this
> preprocessing.
This sounds like the wrong approach to me. I'd suggest using what I
proposed for the kernel:
> cmd_dtc_cpp = $(CPP) $(cpp_flags) -D__DTS__ -x assembler-with-cpp -o $(dtc-tmp) $< ; \
> $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $(dtc-tmp)
The "-x assembler-with-cpp" is what solves the # problem IIRC.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.