Re: "Test object code reading" failing, debug messages don't help
On 11/11/13 21:58, Arnaldo Carvalho de Melo wrote:
> Em Mon, Nov 11, 2013 at 04:55:59PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Mon, Nov 11, 2013 at 04:51:17PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Hi Adrian,
>>>
>>> I have perf test failing here:
>>>
>>> [root@ssdandy ~]# perf test 21
>>> 21: Test object code reading : FAILED!
>>> [root@ssdandy ~]#
>>>
>>> Try it with -v, but all messages, except for that elf header, which I
>>> assume is for a previous entry that is not suitable and should not be
>>> considered, seems to say all is well, except that the test fails :-\
>>
>> If I try gdb on test__code_reading, go on stepping thru it to try to
>> figure out why it fails, it works :-\
>
> Why this is so is still unclear, but since the other problem I had was
> due to the kernel reducing the max sample_freq, I tried:
>
> [root@ssdandy ~]# echo 1 > /proc/sys/kernel/perf_event_max_sample_rate
> [root@ssdandy ~]# perf test 21
> 21: Test object code reading : Ok
> [root@ssdandy ~]# echo 7000 > /proc/sys/kernel/perf_event_max_sample_rate
> [root@ssdandy ~]# perf test 21
> 21: Test object code reading : FAILED!
> [root@ssdandy ~]#
From: Adrian Hunter
Subject: [PATCH] perf tests: Handle throttle events in 'object code reading'
test
Unhandled events cause an error that fails the test
Signed-off-by: Adrian Hunter
---
tools/perf/tests/code-reading.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index 6d9dc19..85d4919 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -275,8 +275,19 @@ static int process_event(struct machine *machine, struct
perf_evlist *evlist,
if (event->header.type == PERF_RECORD_SAMPLE)
return process_sample_event(machine, evlist, event, state);
- if (event->header.type < PERF_RECORD_MAX)
- return machine__process_event(machine, event, NULL);
+ if (event->header.type == PERF_RECORD_THROTTLE ||
+ event->header.type == PERF_RECORD_UNTHROTTLE)
+ return 0;
+
+ if (event->header.type < PERF_RECORD_MAX) {
+ int ret;
+
+ ret = machine__process_event(machine, event, NULL);
+ if (ret < 0)
+ pr_debug("machine__process_event failed, event type
%u\n",
+event->header.type);
+ return ret;
+ }
return 0;
}
--
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: [RFC 9/9] of/irq: create interrupts-extended property
Hi Grant, On Tue, Nov 12, 2013 at 4:54 PM, Grant Likely wrote: > On Tue, 12 Nov 2013 08:58:15 +1000, Peter Crosthwaite > wrote: >> Hi Grant, >> >> On Wed, Oct 16, 2013 at 6:39 AM, Grant Likely >> wrote: >> > The standard interrupts property in device tree can only handle >> > interrupts coming from a single interrupt parent. If a device is wired >> > to multiple interrupt controllers, then it needs to be attached to a >> > node with an interrupt-map property to demux the interrupt specifiers >> > which is confusing. It would be a lot easier if there was a form of the >> > interrupts property that allows for a separate interrupt phandle for >> > each interrupt specifier. >> > >> > This patch does exactly that by creating a new interrupts-extended >> > property which reuses the phandle+arguments pattern used by GPIOs and >> > other core bindings. >> > >> > Signed-off-by: Grant Likely >> > Cc: Rob Herring >> > --- >> > .../bindings/interrupt-controller/interrupts.txt | 29 +++-- >> > arch/arm/boot/dts/testcases/tests-interrupts.dtsi | 16 + >> > arch/arm/boot/dts/versatile-ab.dts | 2 +- >> > arch/arm/boot/dts/versatile-pb.dts | 2 +- >> > drivers/of/irq.c | 16 +++-- >> > drivers/of/selftest.c | 70 >> > ++ >> > 6 files changed, 122 insertions(+), 13 deletions(-) >> > >> > diff --git >> > a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> > b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> > index 72a06c0..1486497 100644 >> > --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> > +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> > @@ -4,16 +4,33 @@ Specifying interrupt information for devices >> > 1) Interrupt client nodes >> > - >> > >> > -Nodes that describe devices which generate interrupts must contain an >> > -"interrupts" property. This property must contain a list of interrupt >> > -specifiers, one per output interrupt. The format of the interrupt >> > specifier is >> > -determined by the interrupt controller to which the interrupts are >> > routed; see >> > -section 2 below for details. >> > +Nodes that describe devices which generate interrupts must contain an >> > either an >> > +"interrupts" property or an "interrupts-extended" property. These >> > properties >> > +contain a list of interrupt specifiers, one per output interrupt. The >> > format of >> > +the interrupt specifier is determined by the interrupt controller to >> > which the >> > +interrupts are routed; see section 2 below for details. >> > + >> > + Example: >> > + interrupt-parent = <>; >> > + interrupts = <5 0>, <6 0>; >> > >> > The "interrupt-parent" property is used to specify the controller to which >> > interrupts are routed and contains a single phandle referring to the >> > interrupt >> > controller node. This property is inherited, so it may be specified in an >> > -interrupt client node or in any of its parent nodes. >> > +interrupt client node or in any of its parent nodes. Interrupts listed in >> > the >> > +"interrupts" property are always in reference to the node's interrupt >> > parent. >> > + >> > +The "interrupts-extended" property is a special form for use when a node >> > needs >> > +to reference multiple interrupt parents. Each entry in this property >> > contains >> > +both the parent phandle and the interrupt specifier. "interrupts-extended" >> > +should only be used when a device has multiple interrupt parents. >> > + >> > + Example: >> > + interrupts-extended = < 5 1>, < 1 0>; >> > + >> >> A slightly different but related problem I am trying to solve with >> interrupt bindings, is to describe connection of a single device >> interrupt line to multiple interrupts controller, whereas this binding >> seems to be describing connection of different interrupt lines to >> different controllers. Can this syntax accommodate my case is any way? >> >> Bascially I think I'm asking for multiple interrupt specifiers for a >> single IRQ output if that's possible. >> >> Should I just be using the interrupt map syntax instead? >> >> interrupt-map-mask = < 0 0 63>; >> interrupt-map = < 0 0 25 ... >, < 0 0 25 ... >, > > Interrupt map doesn't actually help you here either since the core code > doesn't know what to do with it. It will probably only match and return > one of the options. > Yes I noticed that. Although we are a fair way off Linux patches for this just yet and all I want to solve near-term is the hardware description problem (what core Linux IRQ code is actually supposed to do when given such a wiring setup is probably an open question). > What I would do is describe both in your interrupts property and make > the driver know that the extra interrupt specifier is for the same > interrupt output. > So this is a
Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
Hi Oleg,
On Fri, 8 Nov 2013 18:00:17 +0100, Oleg Nesterov wrote:
> On 11/07, Namhyung Kim wrote:
>>
>> On Wed, 6 Nov 2013 19:24:08 +0100, Oleg Nesterov wrote:
>> >
>> > Note that instruction_pointer_set() is not really nice in any case,
>> > this can obviously confuse FETCH_MTD_reg("ip").
>>
>> Yes.
>>
>> >
>> > But lets ignore this. The solution is simple, we can pass/use this
>> > info via current->utask. We can either add the new member, or add
>> > a union. Or simply reuse xol_vaddr. Doesn't matter.
>>
>> Okay, I'll take a look.
>
> I guess we need the union in uprobe_task anyway... I'll send the patch
> soon.
>
> Until we have the new members in uprobe_task, you can reuse utask->vaddr,
> this is safe.
>
> IOW, you can use current->utask->vaddr instead of regs->ip (as we did
> in the previous discussin) to pass the necessary info to ->fetch().
Thanks for the info!
Namhyung
--
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] Staging: ft1000: ft1000_download: fixed coding style issues
Greg KH wrote: > On Sun, Nov 10, 2013 at 03:44:20PM +0200, Aldo Iljazi wrote: > > Fixed the following coding style issues: > > Note that I added the filename to the Subject:, please do so in the > future to make it easier to see what exactly you are changing. You are right. I'll do that. -- Aldo Iljazi -- 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: WARNING: CPU: 8 PID: 12860 at net/core/sock.c:313 sk_clear_memalloc+0x49/0x70()
CC'ing netdev@ to make more relative people know it. On 11/12/2013 11:16 AM, Zhouping Liu wrote: Hi All, I found the WARNING in the latest mainline with commint 8b5baa460b. [61323.305424] [ cut here ] [61323.310562] WARNING: CPU: 8 PID: 12860 at net/core/sock.c:313 sk_clear_memalloc+0x49/0x70() [61323.319779] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache sg nfsd netxen_nic hpilo sp5100_tco auth_rpcgss hpwdt amd64_edac_mod edac_mce_amd microcode pcspkr shpchp serio_raw i2c_piix4 edac_core ipmi_si k10temp nfs_acl lockd ipmi_msghandler acpi_power_meter acpi_cpufreq sunrpc xfs libcrc32c radeon i2c_algo_bit drm_kms_helper ttm sd_mod crc_t10dif ata_generic crct10dif_common drm pata_acpi ahci libahci pata_atiixp libata i2c_core hpsa dm_mirror dm_region_hash dm_log dm_mod [61323.368625] CPU: 8 PID: 12860 Comm: swapoff Not tainted 3.12.0+ #1 [61323.375452] Hardware name: HP ProLiant DL585 G7, BIOS A16 12/17/2012 [61323.382463] 0009 882dfce43e68 816204b7 [61323.390692] 882dfce43ea0 8106495d 88190b551d00 88080ff0b600 [61323.398940] 88080ff0b650 0001 880810fe64a0 882dfce43eb0 [61323.407188] Call Trace: [61323.409916] [] dump_stack+0x45/0x56 [61323.415616] [] warn_slowpath_common+0x7d/0xa0 [61323.422257] [] warn_slowpath_null+0x1a/0x20 [61323.428705] [] sk_clear_memalloc+0x49/0x70 [61323.435094] [] xs_swapper+0x41/0x60 [sunrpc] [61323.441671] [] nfs_swap_deactivate+0x2d/0x30 [nfs] [61323.448796] [] destroy_swap_extents+0x61/0x70 [61323.455436] [] SyS_swapoff+0x220/0x610 [61323.461420] [] ? do_page_fault+0x1a/0x70 [61323.467582] [] system_call_fastpath+0x16/0x1b [61323.474215] ---[ end trace 919f685513b38356 ]--- I found the warning during doing swapoff the swap over NFS mount, so if you need to reproduce it, you should do the following: 1. Open CONFIG_NFS_SWAP in testing machine 2. Create a NFS server, and create a swap file in NFS server in NFS server: # dd if=/dev/zero of=/NFS_FOLDER/swapfile bs=1M count=1024; mkswap swapfile 3. Inside testing machine, setup a swap over NFS, then swapoff it, the swapoff action will trigger the WARNING. -- 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 3.4 00/26] 3.4.69-stable review
On Mon, Nov 11, 2013 at 10:58:32AM -0700, Shuah Khan wrote: > On 11/08/2013 11:51 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.69 release. > > There are 26 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Mon Nov 11 06:50:22 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.69-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > 3.4.69 > > Patch applied cleanlyyes > Compile testpassed > Boot testpassed > dmesg regression testpassed > > dmesgs look good. No regressions compared to the previous dmesgs for > this release. dmesg emerg, crit, alert, err are clean. No regressions in > warn. Thanks for testing and letting me know. 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 4/7 v2] export more efi table variable to sysfs
On Tue, Nov 05, 2013 at 04:20:11PM +0800, dyo...@redhat.com wrote: > Export fw_vendor, runtime and config tables physical > addresses to /sys/firmware/efi/systab becaue kexec > kernel will need them. sysfs files are one-value-per-file. Please don't abuse this and add more values to this single file, in fact, it should be broken up into individual sysfs files as it is, because this isn't ok now. Sorry, you don't get to abuse this anymore :( 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 2/2] staging: cxt1e1: comet: fixed some brace coding style issues.
On Sun, Nov 10, 2013 at 04:13:05PM +0100, Joachim Adolf Schuetz wrote: > Fixed some coding style issues - a few braces and indentions. > > Signed-off-by: Joachim Adolf Schuetz > --- > drivers/staging/cxt1e1/comet.c | 31 +-- > 1 files changed, 13 insertions(+), 18 deletions(-) Someone beat you to this change, sorry, it's already in my tree. 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] Staging: ft1000: fixed a few styling issues
On Mon, Nov 04, 2013 at 01:32:20PM +0100, Ondrej Zary wrote: > > Shouldn't this be removed from the code, converted to a binary file and > loaded > by the kernel firmware loader instead? Yes it should, please send patches to do so. And don't quote the whole firmware blob when responding to patches where you just add 2 lines at the bottom of the email... 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] Staging: dgnc: dgnc_cls.c: fixed a brace coding style issue
On Tue, Nov 05, 2013 at 01:53:28AM +1300, Simon Crequer wrote: > Fixed a coding style issue. > > Signed-off-by: Simon Crequer > --- > drivers/staging/dgnc/dgnc_cls.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Someone else beat you to this change, sorry, it no longer applies to my tree :( 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] Staging: ft1000: ft1000_download: fixed coding style issues
On Sun, Nov 10, 2013 at 03:44:20PM +0200, Aldo Iljazi wrote: > Fixed the following coding style issues: Note that I added the filename to the Subject:, please do so in the future to make it easier to see what exactly you are changing. > > Lines 84-91,99-106,275,514: Replaced spaces at the start of the lines > with tabs. > > Lines 205,271: Inserted spaces after the commas. > Lines 275,1060,1065: Indented the code with tabs instead of spaces. That's funny, as the rest of those functions need to be indented using tabs instead of spaces. But I'll take this for now, no worries, 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: call_usermodehelper in containers
On Mon, Nov 11, 2013 at 07:18:25AM -0500, Jeff Layton wrote: > We have a bit of a problem wrt to upcalls that use call_usermodehelper > with containers and I'd like to bring this to some sort of resolution... > > A particularly problematic case (though there are others) is the > nfsdcltrack upcall. It basically uses call_usermodehelper to run a > program in userland to track some information on stable storage for > nfsd. I thought the discussion at the kernel summit about this issue was: - don't do this. - don't do it. - if you really need to do this, fix nfsd 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] Staging: ft1000: boot.h: fixed a few styling issues
On Mon, Nov 04, 2013 at 02:15:22PM +0200, Aldo Iljazi wrote: > Fixed the following styling issues: > > Line 30: > Removed space before open square bracket '[' > > Lines 31 to 155: > Moved the commas that were in the start of the lines, to the end of the lines. > Inserted spaces after the commas. > Inserted a one tab indentation to each line. > > Signed-off-by: Aldo Iljazi > Reviewed-by: Dan Carpenter I've applied this to the 'opw-next' branch of the staging.git tree for now, which will be merged into the staging-next branch when 3.13-rc1 is out. Same for your other ft1000 coding style cleanup. 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 v2] staging: zsmalloc: Ensure handle is never 0 on success
On Thu, Nov 07, 2013 at 05:58:03PM -0800, Olav Haugan wrote: > zsmalloc encodes a handle using the pfn and an object > index. On hardware platforms with physical memory starting > at 0x0 the pfn can be 0. This causes the encoded handle to be > 0 and is incorrectly interpreted as an allocation failure. Please list the known hardware platforms that have this issue, so that people have a chance to know if this patch is relevant for them or not. For example, should I include this in the stable releases because it affects systems that are shipping? Or is it just in "future" chips and it doesn't need to go there or not? Please make it easy for me to do this type of determination, I already asked you this question before, why didn't you include the information here as well (hint, that is why I asked you...) 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] staging: rts5208: add support for rts5208 and rts5288
On Fri, Nov 08, 2013 at 05:00:43PM +0800, micky_ch...@realsil.com.cn wrote: > --- /dev/null > +++ b/drivers/staging/rts5208/TODO > @@ -0,0 +1,5 @@ > +TODO: > +- use kernel coding style > +- checkpatch.pl fixes > +- We will use the stack in drivers/mmc to implement > + rts5208/5288 in the future In the TODO file, I need a name and email address of the person who is going to be responsible for doing the things in the TODO file to get it out of the staging tree. Can you please resend this patch with this change? 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] Staging: comedi: fix coding style issues in unioxx5.c
On Fri, Nov 01, 2013 at 06:01:56PM +0530, Conrad Gomes wrote: > This is a patch which fixes coding style issues in unioxx5.c found > by checkpatch.pl > > 1) Replaced printk with pr_info and pr_err Drivers should never call printk() as they all have access to a struct device somewhere. So please call dev_info() or dev_err() instead. > 2) Reinitialized n_subd before for loop to fix over 80 character >warning > 3) Reworded comment to fix 80 character warning > Patches should do one thing, not 3 things. Care to break this up into "one logical change per patch"? Yes, it's a small thing, but if you had done this already, I could have taken the other 2 patches and you would have just had to redo one patch in this series... 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: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
(2013/11/12 15:23), Sandeepa Prabhu wrote: OK, I've ensured that the hw_breakpoint (from perf) can work with kprobes (from ftrace) at the same address on x86. So if arm64 already support hw_breakpoint on perf, kprobes should work with it. >>> >>> Single-stepping on x86 is different to the step behaviour on arm64 afaik. On >>> ARM, we have to manually remove the breakpoint, perform a single-step, then >>> add the breakpoint again. If we re-enable debug exceptions in the kprobe >>> handler, the step will complete early and we'll never step off the >>> breakpoint. >> >> I'm unsure about arm64's debug feature behavior, what does happen when >> it performs a single-step on sw-breakpoint? >> >>> Sandeepa: I think you need to retry Masami's test on the arm64 model, since >>> I'm fairly sure it won't work as expected without some additional code. >> >> OK, anyway, for testing same one, we need to port ftrace first. So the next Sorry for confusion, s/next/fallback is what I meant. Making a kprobe module can be done without ftrace port. >> plan is to make a kprobe module to put a probe (which just printk something) >> on a specific function (e.g. vfs_symlink), and run perf record with >> hw-breakpoint as below >> >> $ perf record -e "mem:0xXX:k" ln -s /dev/null /tmp/foo >> >> Note that 0xXX is the address of vfs_symlink. >> >> After that, you can see the message in dmesg and also check the perf result >> with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if >> it works) > Thanks for steps, ARM64 ftrace patches are under review on arm mailing > list, I can contact the (linaro) developer implementing ftrace on > what's supported and then figure-out a way to test this concurrency of > kprobes breakpoint and hardware breakpoint. Would you mean this? :) http://www.spinics.net/lists/arm-kernel/msg278477.html Wow, it seems that this also has some works around instruction manipulation (and confusable filenames...) Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.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 3.11 00/94] 3.11.8-stable review
On Mon, Nov 11, 2013 at 10:57:52AM -0700, Shuah Khan wrote: > On 11/08/2013 11:51 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.11.8 release. > > There are 94 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Mon Nov 11 06:51:44 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.8-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > > 3.11.8: > > Patch applied cleanlyyes > Compile testpassed > Boot testpassed > dmesg regression testpassed > > dmesgs look good. No regressions compared to the previous dmesgs for > this release. dmesg emerg, crit, alert, err are clean. No regressions in > warn. Thanks for testing and letting me know. 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 3.10 00/74] 3.10.19-stable review
On Mon, Nov 11, 2013 at 10:56:18AM -0700, Shuah Khan wrote: > On 11/08/2013 11:51 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.10.19 release. > > There are 74 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Mon Nov 11 06:50:58 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.19-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > 3.10.19: > > Patch applied cleanlyyes > Compile testpassed > Boot testpassed > dmesg regression testpassed > > dmesgs look good. No regressions compared to the previous dmesgs for > this release. dmesg emerg, crit, alert, err are clean. No regressions in > warn. Thanks for testing and letting me know. 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 v7 14/21] scripts/gdb: Add is_target_arch helper
This helper caches to result of "show architecture" and matches the
provided arch (sub-)string against that output.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/utils.py | 13 +
1 file changed, 13 insertions(+)
diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py
index 808a265..71ee48c 100644
--- a/scripts/gdb/linux/utils.py
+++ b/scripts/gdb/linux/utils.py
@@ -106,3 +106,16 @@ def read_u64(buffer):
return read_u32(buffer[0:4]) + (read_u32(buffer[4:8]) << 32)
else:
return read_u32(buffer[4:8]) + (read_u32(buffer[0:4]) << 32)
+
+
+target_arch = None
+
+
+def is_target_arch(arch):
+if hasattr(gdb.Frame, 'architecture'):
+return arch in gdb.newest_frame().architecture().name()
+else:
+global target_arch
+if target_arch is None:
+target_arch = gdb.execute("show architecture", to_string=True)
+return arch in target_arch
--
1.8.1.1.298.ge7eed54
--
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 v7 09/21] scripts/gdb: Add get_target_endianness helper
Parse the target endianness from the output of "show endian" and cache
the result to return it via the new helper get_target_endiannes. We will
need it for reading integers from buffers that contain target memory.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/utils.py | 18 ++
1 file changed, 18 insertions(+)
diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py
index c9d705b..10a227b 100644
--- a/scripts/gdb/linux/utils.py
+++ b/scripts/gdb/linux/utils.py
@@ -67,3 +67,21 @@ Note that TYPE and ELEMENT have to be quoted as strings."""
elementname.string())
ContainerOf()
+
+
+BIG_ENDIAN = 0
+LITTLE_ENDIAN = 1
+target_endianness = None
+
+
+def get_target_endianness():
+global target_endianness
+if target_endianness is None:
+endian = gdb.execute("show endian", to_string=True)
+if "little endian" in endian:
+target_endianness = LITTLE_ENDIAN
+elif "big endian" in endian:
+target_endianness = BIG_ENDIAN
+else:
+raise gdb.GdgError("unknown endianness '{0}'".format(endian))
+return target_endianness
--
1.8.1.1.298.ge7eed54
--
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 v7 16/21] scripts/gdb: Add get_gdbserver_type helper
This helper probes the type of the gdb server. Supported are QEMU and
KGDB so far. Knowledge about the gdb server is required e.g. to retrieve
the current CPU or current task.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/utils.py | 35 +++
1 file changed, 35 insertions(+)
diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py
index 71ee48c..a4a1640 100644
--- a/scripts/gdb/linux/utils.py
+++ b/scripts/gdb/linux/utils.py
@@ -119,3 +119,38 @@ def is_target_arch(arch):
if target_arch is None:
target_arch = gdb.execute("show architecture", to_string=True)
return arch in target_arch
+
+
+GDBSERVER_QEMU = 0
+GDBSERVER_KGDB = 1
+gdbserver_type = None
+
+
+def get_gdbserver_type():
+def exit_handler(event):
+global gdbserver_type
+gdbserver_type = None
+gdb.events.exited.disconnect(exit_handler)
+
+def probe_qemu():
+try:
+return gdb.execute("monitor info version", to_string=True) != ""
+except:
+return False
+
+def probe_kgdb():
+try:
+thread_info = gdb.execute("info thread 2", to_string=True)
+return "shadowCPU0" in thread_info
+except:
+return False
+
+global gdbserver_type
+if gdbserver_type is None:
+if probe_qemu():
+gdbserver_type = GDBSERVER_QEMU
+elif probe_kgdb():
+gdbserver_type = GDBSERVER_KGDB
+if not gdbserver_type is None and hasattr(gdb, 'events'):
+gdb.events.exited.connect(exit_handler)
+return gdbserver_type
--
1.8.1.1.298.ge7eed54
--
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 v7 08/21] scripts/gdb: Add internal helper and convenience function to look up a module
Add the internal helper get_module_by_name to obtain the module
structure corresponding to the given name. Also export this service as a
convenience function.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/modules.py | 28
scripts/gdb/vmlinux-gdb.py | 1 +
2 files changed, 29 insertions(+)
diff --git a/scripts/gdb/linux/modules.py b/scripts/gdb/linux/modules.py
index 8a65c3d..531f763 100644
--- a/scripts/gdb/linux/modules.py
+++ b/scripts/gdb/linux/modules.py
@@ -37,3 +37,31 @@ class ModuleList:
return utils.container_of(entry, self.module_ptr_type, "list")
else:
raise StopIteration
+
+
+def find_module_by_name(name):
+for module in ModuleList():
+if module['name'].string() == name:
+return module
+return None
+
+
+class LxModule(gdb.Function):
+"""Find module by name and return the module variable.
+
+$lx_module("MODULE"): Given the name MODULE, iterate over all loaded modules
+of the target and return that module variable which MODULE matches."""
+
+def __init__(self):
+super(LxModule, self).__init__("lx_module")
+
+def invoke(self, mod_name):
+mod_name = mod_name.string()
+module = find_module_by_name(mod_name)
+if module:
+return module.dereference()
+else:
+raise gdb.GdbError("Unable to find MODULE " + mod_name)
+
+
+LxModule()
diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py
index 0b0faa4..cf2e716 100644
--- a/scripts/gdb/vmlinux-gdb.py
+++ b/scripts/gdb/vmlinux-gdb.py
@@ -24,3 +24,4 @@ except:
else:
import linux.utils
import linux.symbols
+import linux.modules
--
1.8.1.1.298.ge7eed54
--
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 9/9] of/irq: create interrupts-extended property
On Tue, 12 Nov 2013 08:58:15 +1000, Peter Crosthwaite wrote: > Hi Grant, > > On Wed, Oct 16, 2013 at 6:39 AM, Grant Likely wrote: > > The standard interrupts property in device tree can only handle > > interrupts coming from a single interrupt parent. If a device is wired > > to multiple interrupt controllers, then it needs to be attached to a > > node with an interrupt-map property to demux the interrupt specifiers > > which is confusing. It would be a lot easier if there was a form of the > > interrupts property that allows for a separate interrupt phandle for > > each interrupt specifier. > > > > This patch does exactly that by creating a new interrupts-extended > > property which reuses the phandle+arguments pattern used by GPIOs and > > other core bindings. > > > > Signed-off-by: Grant Likely > > Cc: Rob Herring > > --- > > .../bindings/interrupt-controller/interrupts.txt | 29 +++-- > > arch/arm/boot/dts/testcases/tests-interrupts.dtsi | 16 + > > arch/arm/boot/dts/versatile-ab.dts | 2 +- > > arch/arm/boot/dts/versatile-pb.dts | 2 +- > > drivers/of/irq.c | 16 +++-- > > drivers/of/selftest.c | 70 > > ++ > > 6 files changed, 122 insertions(+), 13 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > > b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > > index 72a06c0..1486497 100644 > > --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > > +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > > @@ -4,16 +4,33 @@ Specifying interrupt information for devices > > 1) Interrupt client nodes > > - > > > > -Nodes that describe devices which generate interrupts must contain an > > -"interrupts" property. This property must contain a list of interrupt > > -specifiers, one per output interrupt. The format of the interrupt > > specifier is > > -determined by the interrupt controller to which the interrupts are routed; > > see > > -section 2 below for details. > > +Nodes that describe devices which generate interrupts must contain an > > either an > > +"interrupts" property or an "interrupts-extended" property. These > > properties > > +contain a list of interrupt specifiers, one per output interrupt. The > > format of > > +the interrupt specifier is determined by the interrupt controller to which > > the > > +interrupts are routed; see section 2 below for details. > > + > > + Example: > > + interrupt-parent = <>; > > + interrupts = <5 0>, <6 0>; > > > > The "interrupt-parent" property is used to specify the controller to which > > interrupts are routed and contains a single phandle referring to the > > interrupt > > controller node. This property is inherited, so it may be specified in an > > -interrupt client node or in any of its parent nodes. > > +interrupt client node or in any of its parent nodes. Interrupts listed in > > the > > +"interrupts" property are always in reference to the node's interrupt > > parent. > > + > > +The "interrupts-extended" property is a special form for use when a node > > needs > > +to reference multiple interrupt parents. Each entry in this property > > contains > > +both the parent phandle and the interrupt specifier. "interrupts-extended" > > +should only be used when a device has multiple interrupt parents. > > + > > + Example: > > + interrupts-extended = < 5 1>, < 1 0>; > > + > > A slightly different but related problem I am trying to solve with > interrupt bindings, is to describe connection of a single device > interrupt line to multiple interrupts controller, whereas this binding > seems to be describing connection of different interrupt lines to > different controllers. Can this syntax accommodate my case is any way? > > Bascially I think I'm asking for multiple interrupt specifiers for a > single IRQ output if that's possible. > > Should I just be using the interrupt map syntax instead? > > interrupt-map-mask = < 0 0 63>; > interrupt-map = < 0 0 25 ... >, < 0 0 25 ... >, Interrupt map doesn't actually help you here either since the core code doesn't know what to do with it. It will probably only match and return one of the options. What I would do is describe both in your interrupts property and make the driver know that the extra interrupt specifier is for the same interrupt output. g. -- 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 v7 01/21] scripts/gdb: Add infrastructure
This provides the basic infrastructure to load kernel-specific python
helper scripts when debugging the kernel in gdb.
The loading mechanism is based on gdb loading for -gdb.py when
opening . Therefore, this places a corresponding link to the
main helper script into the output directory that contains vmlinux.
The main scripts will pull in submodules containing Linux specific gdb
commands and functions. To avoid polluting the source directory with
compiled python modules, we link to them from the object directory.
Due to gdb.parse_and_eval and string redirection for gdb.execute, we
depend on gdb >= 7.2.
This feature is enabled via CONFIG_GDB_SCRIPTS.
CC: Michal Marek
CC: linux-kbu...@vger.kernel.org
Signed-off-by: Jan Kiszka
---
Makefile | 5 -
lib/Kconfig.debug | 11 +++
scripts/Makefile | 3 ++-
scripts/gdb/Makefile | 11 +++
scripts/gdb/linux/Makefile| 9 +
scripts/gdb/linux/__init__.py | 0
scripts/gdb/vmlinux-gdb.py| 23 +++
7 files changed, 60 insertions(+), 2 deletions(-)
create mode 100644 scripts/gdb/Makefile
create mode 100644 scripts/gdb/linux/Makefile
create mode 100644 scripts/gdb/linux/__init__.py
create mode 100644 scripts/gdb/vmlinux-gdb.py
diff --git a/Makefile b/Makefile
index 67077ad..9196097 100644
--- a/Makefile
+++ b/Makefile
@@ -778,6 +778,9 @@ endif
ifdef CONFIG_BUILD_DOCSRC
$(Q)$(MAKE) $(build)=Documentation
endif
+ifdef CONFIG_GDB_SCRIPTS
+ $(Q)ln -fsn $(srctree)/scripts/gdb/vmlinux-gdb.py
+endif
+$(call if_changed,link-vmlinux)
# The actual objects are generated when descending,
@@ -1026,7 +1029,7 @@ MRPROPER_FILES += .config .config.old .version
.old_version $(version_h) \
Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
signing_key.priv signing_key.x509 x509.genkey \
extra_certificates signing_key.x509.keyid \
- signing_key.x509.signer
+ signing_key.x509.signer vmlinux-gdb.py
# clean - Delete most, but leave enough to build external modules
#
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ebef88f..fb15d00 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -143,6 +143,17 @@ config DEBUG_INFO_REDUCED
DEBUG_INFO build and compile times are reduced too.
Only works with newer gcc versions.
+config GDB_SCRIPTS
+ bool "Provide GDB scripts for kernel debugging"
+ select DEBUG_INFO
+ help
+ This creates the required links to GDB helper scripts in the
+ build directory. If you load vmlinux into gdb, the helper
+ scripts will be automatically imported by gdb as well, and
+ additional functions are available to analyze a Linux kernel
+ instance. See Documentation/gdb-kernel-debugging.txt for further
+ details.
+
config ENABLE_WARN_DEPRECATED
bool "Enable __deprecated logic"
default y
diff --git a/scripts/Makefile b/scripts/Makefile
index 01e7adb..672f65d 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -37,6 +37,7 @@ subdir-$(CONFIG_MODVERSIONS) += genksyms
subdir-y += mod
subdir-$(CONFIG_SECURITY_SELINUX) += selinux
subdir-$(CONFIG_DTC) += dtc
+subdir-$(CONFIG_GDB_SCRIPTS) += gdb
# Let clean descend into subdirs
-subdir-+= basic kconfig package selinux
+subdir-+= basic kconfig package selinux gdb
diff --git a/scripts/gdb/Makefile b/scripts/gdb/Makefile
new file mode 100644
index 000..c0e2fd3
--- /dev/null
+++ b/scripts/gdb/Makefile
@@ -0,0 +1,11 @@
+subdir-y := linux
+
+always := gdb-scripts
+
+$(obj)/gdb-scripts:
+ifneq ($(KBUILD_SRC),)
+ $(Q)ln -fsn $(srctree)/$(obj)/*.py $(objtree)/$(obj)
+endif
+ @:
+
+clean-files := *.pyc $(if $(KBUILD_SRC),*.py)
diff --git a/scripts/gdb/linux/Makefile b/scripts/gdb/linux/Makefile
new file mode 100644
index 000..34ccd06
--- /dev/null
+++ b/scripts/gdb/linux/Makefile
@@ -0,0 +1,9 @@
+always := gdb-scripts
+
+$(obj)/gdb-scripts:
+ifneq ($(KBUILD_SRC),)
+ $(Q)ln -fsn $(srctree)/$(obj)/*.py $(objtree)/$(obj)
+endif
+ @:
+
+clean-files := *.pyc $(if $(KBUILD_SRC),*.py)
diff --git a/scripts/gdb/linux/__init__.py b/scripts/gdb/linux/__init__.py
new file mode 100644
index 000..e69de29
diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py
new file mode 100644
index 000..c1d90ce
--- /dev/null
+++ b/scripts/gdb/vmlinux-gdb.py
@@ -0,0 +1,23 @@
+#
+# gdb helper commands and functions for Linux kernel debugging
+#
+# loader module
+#
+# Copyright (c) Siemens AG, 2012, 2013
+#
+# Authors:
+# Jan Kiszka
+#
+# This work is licensed under the terms of the GNU GPL version 2.
+#
+
+import os
+
+sys.path.insert(0, os.path.dirname(__file__) + "/scripts/gdb")
+
+try:
+gdb.parse_and_eval("0")
+gdb.execute("", to_string=True)
+except:
+gdb.write("NOTE: gdb
[PATCH v7 07/21] scripts/gdb: Add automatic symbol reloading on module insertion
This installs a silent breakpoint on the do_init_module function. The
breakpoint handler will try to load symbols from the module files found
during lx-symbols execution. This way, breakpoints can be set to module
initialization functions, and there is no need to explicitly call
lx-symbols after (re-)loading a module.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/symbols.py | 39 +++
1 file changed, 39 insertions(+)
diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py
index bd21a96..139841f 100644
--- a/scripts/gdb/linux/symbols.py
+++ b/scripts/gdb/linux/symbols.py
@@ -19,6 +19,30 @@ import string
from linux import modules, utils
+if hasattr(gdb, 'Breakpoint'):
+class LoadModuleBreakpoint(gdb.Breakpoint):
+def __init__(self, spec, gdb_command):
+super(LoadModuleBreakpoint, self).__init__(spec, internal=True)
+self.silent = True
+self.gdb_command = gdb_command
+
+def stop(self):
+module = gdb.parse_and_eval("mod")
+module_name = module['name'].string()
+cmd = self.gdb_command
+
+# enforce update if object file is not found
+cmd.module_files_updated = False
+
+if module_name in cmd.loaded_modules:
+gdb.write("refreshing all symbols to reload module "
+ "'{0}'\n".format(module_name))
+cmd.load_all_symbols()
+else:
+cmd.load_module_symbols(module)
+return False
+
+
class LxSymbols(gdb.Command):
"""(Re-)load symbols of Linux kernel and currently loaded modules.
@@ -30,6 +54,8 @@ lx-symbols command."""
module_paths = []
module_files = []
module_files_updated = False
+loaded_modules = []
+breakpoint = None
def __init__(self):
super(LxSymbols, self).__init__("lx-symbols", gdb.COMMAND_FILES,
@@ -87,6 +113,8 @@ lx-symbols command."""
addr=module_addr,
sections=self._section_arguments(module))
gdb.execute(cmdline, to_string=True)
+if not module_name in self.loaded_modules:
+self.loaded_modules.append(module_name)
else:
gdb.write("no module object found for '{0}'\n".format(module_name))
@@ -104,6 +132,7 @@ lx-symbols command."""
gdb.execute("symbol-file", to_string=True)
gdb.execute("symbol-file vmlinux")
+self.loaded_modules = []
module_list = modules.ModuleList()
if not module_list:
gdb.write("no modules found\n")
@@ -123,5 +152,15 @@ lx-symbols command."""
self.load_all_symbols()
+if hasattr(gdb, 'Breakpoint'):
+if not self.breakpoint is None:
+self.breakpoint.delete()
+self.breakpoint = None
+self.breakpoint = LoadModuleBreakpoint(
+"kernel/module.c:do_init_module", self)
+else:
+gdb.write("Note: symbol update on module loading not supported "
+ "with this gdb version\n")
+
LxSymbols()
--
1.8.1.1.298.ge7eed54
--
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 v7 11/21] scripts/gdb: Add lx-dmesg command
This pokes into the log buffer of the debugged kernel, dumping it to the
gdb console. Helping in case the target should or can no longer execute
dmesg itself.
CC: Kay Sievers
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/dmesg.py | 64 ++
scripts/gdb/vmlinux-gdb.py | 1 +
2 files changed, 65 insertions(+)
create mode 100644 scripts/gdb/linux/dmesg.py
diff --git a/scripts/gdb/linux/dmesg.py b/scripts/gdb/linux/dmesg.py
new file mode 100644
index 000..7650f24
--- /dev/null
+++ b/scripts/gdb/linux/dmesg.py
@@ -0,0 +1,64 @@
+#
+# gdb helper commands and functions for Linux kernel debugging
+#
+# kernel log buffer dump
+#
+# Copyright (c) Siemens AG, 2011, 2012
+#
+# Authors:
+# Jan Kiszka
+#
+# This work is licensed under the terms of the GNU GPL version 2.
+#
+
+import gdb
+import string
+
+from linux import utils
+
+
+class LxDmesg(gdb.Command):
+"""Print Linux kernel log buffer."""
+
+def __init__(self):
+super(LxDmesg, self).__init__("lx-dmesg", gdb.COMMAND_DATA)
+
+def invoke(self, arg, from_tty):
+log_buf_addr = int(str(gdb.parse_and_eval("log_buf")).split()[0], 16)
+log_first_idx = int(gdb.parse_and_eval("log_first_idx"))
+log_next_idx = int(gdb.parse_and_eval("log_next_idx"))
+log_buf_len = int(gdb.parse_and_eval("log_buf_len"))
+
+inf = gdb.inferiors()[0]
+start = log_buf_addr + log_first_idx
+if log_first_idx < log_next_idx:
+log_buf_2nd_half = -1
+length = log_next_idx - log_first_idx
+log_buf = inf.read_memory(start, length)
+else:
+log_buf_2nd_half = log_buf_len - log_first_idx
+log_buf = inf.read_memory(start, log_buf_2nd_half) + \
+inf.read_memory(log_buf_addr, log_next_idx)
+
+pos = 0
+while pos < log_buf.__len__():
+length = utils.read_u16(log_buf[pos + 8:pos + 10])
+if length == 0:
+if log_buf_2nd_half == -1:
+gdb.write("Corrupted log buffer!\n")
+break
+pos = log_buf_2nd_half
+continue
+
+text_len = utils.read_u16(log_buf[pos + 10:pos + 12])
+time_stamp = utils.read_u64(log_buf[pos:pos + 8])
+
+for line in log_buf[pos + 16:pos + 16 + text_len].splitlines():
+gdb.write("[{time:12.6f}] {line}\n".format(
+time=time_stamp / 10.0,
+line=line))
+
+pos += length
+
+
+LxDmesg()
diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py
index cf2e716..fa66d23 100644
--- a/scripts/gdb/vmlinux-gdb.py
+++ b/scripts/gdb/vmlinux-gdb.py
@@ -25,3 +25,4 @@ else:
import linux.utils
import linux.symbols
import linux.modules
+import linux.dmesg
--
1.8.1.1.298.ge7eed54
--
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 3/3] x86, boot: Change the BIOS corruption checker to scan 640K
On 11/11/2013 08:07 PM, Ingo Molnar wrote: > I agree with your patches so far, and I'd suggest we go even further: I'd > say the config option is now a misnomer, it should probably be renamed to > CONFIG_X86_FORCE_RESERVE_BIOS_LOW_1MB=y or so. Why is that? It doesn't seem to make much sense to me. I think the current option names seem to be just fine, but perhaps I'm missing something. > Btw., should we also force-reserve the remaining bits over 640K..1MB, if > they are not marked as reserved in the memory maps, or do we already > force-reserve them somewhere? We do, in trim_bios_range(). We treat it as available for I/O assignments, since that is necessary on some systems. > The CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y option and the > memory_corruption_check=1 boot option then allow the activation of the low > memory corrupion checker - which debug facility can be used on systems > where someone wants to live dangerously and not reserve the low 1MB of RAM > to the firmware. That is indeed what this patch does, I think... -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/
[PATCH v7 18/21] scripts/gdb: Add lx_current convenience function
This is a shorthand for *$lx_per_cpu("current_task"), i.e. a convenience
function to retrieve the currently running task of the active context.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/cpus.py | 17 +
1 file changed, 17 insertions(+)
diff --git a/scripts/gdb/linux/cpus.py b/scripts/gdb/linux/cpus.py
index 18337e0..b683da9 100644
--- a/scripts/gdb/linux/cpus.py
+++ b/scripts/gdb/linux/cpus.py
@@ -66,3 +66,20 @@ Note that VAR has to be quoted as string."""
PerCpu()
+
+
+class LxCurrentFunc(gdb.Function):
+"""Return current task.
+
+$lx_current([CPU]): Return the per-cpu task variable for the given CPU
+number. If CPU is omitted, the CPU of the current context is used."""
+
+def __init__(self):
+super(LxCurrentFunc, self).__init__("lx_current")
+
+def invoke(self, cpu=-1):
+var_ptr = gdb.parse_and_eval("_task")
+return per_cpu(var_ptr, cpu).dereference()
+
+
+LxCurrentFunc()
--
1.8.1.1.298.ge7eed54
--
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 v7 12/21] scripts/gdb: Add task iteration class
This class allows to iterate over all tasks of the target.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/tasks.py | 46 ++
1 file changed, 46 insertions(+)
create mode 100644 scripts/gdb/linux/tasks.py
diff --git a/scripts/gdb/linux/tasks.py b/scripts/gdb/linux/tasks.py
new file mode 100644
index 000..cd25984
--- /dev/null
+++ b/scripts/gdb/linux/tasks.py
@@ -0,0 +1,46 @@
+#
+# gdb helper commands and functions for Linux kernel debugging
+#
+# task & thread tools
+#
+# Copyright (c) Siemens AG, 2011-2013
+#
+# Authors:
+# Jan Kiszka
+#
+# This work is licensed under the terms of the GNU GPL version 2.
+#
+
+import gdb
+
+from linux import utils
+
+
+task_type = utils.CachedType("struct task_struct")
+
+
+class TaskList:
+def __init__(self):
+global task_type
+self.task_ptr_type = task_type.get_type().pointer()
+self.init_task = gdb.parse_and_eval("init_task")
+self.curr_group = self.init_task.address
+self.curr_task = None
+
+def __iter__(self):
+return self
+
+def next(self):
+t = self.curr_task
+if not t or t == self.curr_group:
+self.curr_group = \
+utils.container_of(self.curr_group['tasks']['next'],
+ self.task_ptr_type, "tasks")
+if self.curr_group == self.init_task.address:
+raise StopIteration
+t = self.curr_task = self.curr_group
+else:
+self.curr_task = \
+utils.container_of(t['thread_group']['next'],
+ self.task_ptr_type, "thread_group")
+return t
--
1.8.1.1.298.ge7eed54
--
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 v7 04/21] scripts/gdb: Add module iteration class
Will soon be used for loading symbols, printing global variables or
listing modules.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/modules.py | 39 +++
1 file changed, 39 insertions(+)
create mode 100644 scripts/gdb/linux/modules.py
diff --git a/scripts/gdb/linux/modules.py b/scripts/gdb/linux/modules.py
new file mode 100644
index 000..8a65c3d
--- /dev/null
+++ b/scripts/gdb/linux/modules.py
@@ -0,0 +1,39 @@
+#
+# gdb helper commands and functions for Linux kernel debugging
+#
+# module tools
+#
+# Copyright (c) Siemens AG, 2013
+#
+# Authors:
+# Jan Kiszka
+#
+# This work is licensed under the terms of the GNU GPL version 2.
+#
+
+import gdb
+
+from linux import utils
+
+
+module_type = utils.CachedType("struct module")
+
+
+class ModuleList:
+def __init__(self):
+global module_type
+self.module_ptr_type = module_type.get_type().pointer()
+modules = gdb.parse_and_eval("modules")
+self.curr_entry = modules['next']
+self.end_of_list = modules.address
+
+def __iter__(self):
+return self
+
+def next(self):
+entry = self.curr_entry
+if entry != self.end_of_list:
+self.curr_entry = entry['next']
+return utils.container_of(entry, self.module_ptr_type, "list")
+else:
+raise StopIteration
--
1.8.1.1.298.ge7eed54
--
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 v7 21/21] scripts/gdb: Add basic documentation
CC: Rob Landley
CC: linux-...@vger.kernel.org
Signed-off-by: Jan Kiszka
---
Documentation/gdb-kernel-debugging.txt | 160 +
1 file changed, 160 insertions(+)
create mode 100644 Documentation/gdb-kernel-debugging.txt
diff --git a/Documentation/gdb-kernel-debugging.txt
b/Documentation/gdb-kernel-debugging.txt
new file mode 100644
index 000..7050ce8
--- /dev/null
+++ b/Documentation/gdb-kernel-debugging.txt
@@ -0,0 +1,160 @@
+Debugging kernel and modules via gdb
+
+
+The kernel debugger kgdb, hypervisors like QEMU or JTAG-based hardware
+interfaces allow to debug the Linux kernel and its modules during runtime
+using gdb. Gdb comes with a powerful scripting interface for python. The
+kernel provides a collection of helper scripts that can simplify typical
+kernel debugging steps. This is a short tutorial about how to enable and use
+them. It focuses on QEMU/KVM virtual machines as target, but the examples can
+be transferred to the other gdb stubs as well.
+
+
+Requirements
+
+
+ o gdb 7.2+ (recommended: 7.4+) with python support enabled (typically true
+ for distributions)
+
+
+Setup
+-
+
+ o Create a virtual Linux machine for QEMU/KVM (see www.linux-kvm.org and
+ www.qemu.org for more details). For cross-development,
+ http://landley.net/aboriginal/bin keeps a pool of machine images and
+ toolchains that can be helpful to start from.
+
+ o Build the kernel with CONFIG_GDB_SCRIPTS enabled, but leave
+ CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports
+ CONFIG_FRAME_POINTER, keep it enabled.
+
+ o Install that kernel on the guest.
+
+ Alternatively, QEMU allows to boot the kernel directly using -kernel,
+ -append, -initrd command line switches. This is generally only useful if
+ you do not depend on modules. See QEMU documentation for more details on
+ this mode.
+
+ o Enable the gdb stub of QEMU/KVM, either
+- at VM startup time by appending "-s" to the QEMU command line
+ or
+- during runtime by issuing "gdbserver" from the QEMU monitor
+ console
+
+ o cd /path/to/linux-build
+
+ o Start gdb: gdb vmlinux
+
+ Note: Some distros may restrict auto-loading of gdb scripts to known safe
+ directories. In case gdb reports to refuse loading vmlinux-gdb.py, add
+
+add-auto-load-safe-path /path/to/linux-build
+
+ to ~/.gdbinit. See gdb help for more details.
+
+ o Attach to the booted guest:
+(gdb) target remote :1234
+
+
+Examples of using the Linux-provided gdb helpers
+
+
+ o Load module (and main kernel) symbols:
+(gdb) lx-symbols
+loading vmlinux
+scanning for modules in /home/user/linux/build
+loading @0xa002:
/home/user/linux/build/net/netfilter/xt_tcpudp.ko
+loading @0xa0016000:
/home/user/linux/build/net/netfilter/xt_pkttype.ko
+loading @0xa0002000:
/home/user/linux/build/net/netfilter/xt_limit.ko
+loading @0xa00ca000: /home/user/linux/build/net/packet/af_packet.ko
+loading @0xa003c000: /home/user/linux/build/fs/fuse/fuse.ko
+...
+loading @0xa000:
/home/user/linux/build/drivers/ata/ata_generic.ko
+
+ o Set a breakpoint on some not yet loaded module function, e.g.:
+(gdb) b btrfs_init_sysfs
+Function "btrfs_init_sysfs" not defined.
+Make breakpoint pending on future shared library load? (y or [n]) y
+Breakpoint 1 (btrfs_init_sysfs) pending.
+
+ o Continue the target
+(gdb) c
+
+ o Load the module on the target and watch the symbols being loaded as well as
+ the breakpoint hit:
+loading @0xa0034000: /home/user/linux/build/lib/libcrc32c.ko
+loading @0xa005: /home/user/linux/build/lib/lzo/lzo_compress.ko
+loading @0xa006e000:
/home/user/linux/build/lib/zlib_deflate/zlib_deflate.ko
+loading @0xa01b1000: /home/user/linux/build/fs/btrfs/btrfs.ko
+
+Breakpoint 1, btrfs_init_sysfs () at /home/user/linux/fs/btrfs/sysfs.c:36
+36 btrfs_kset = kset_create_and_add("btrfs", NULL, fs_kobj);
+
+ o Dump the log buffer of the target kernel:
+(gdb) lx-dmesg
+[ 0.00] Initializing cgroup subsys cpuset
+[ 0.00] Initializing cgroup subsys cpu
+[ 0.00] Linux version 3.8.0-rc4-dbg+ (...
+[ 0.00] Command line: root=/dev/sda2 resume=/dev/sda1 vga=0x314
+[ 0.00] e820: BIOS-provided physical RAM map:
+[ 0.00] BIOS-e820: [mem 0x-0x0009fbff]
usable
+[ 0.00] BIOS-e820: [mem 0x0009fc00-0x0009]
reserved
+
+
+ o Examine fields of the current task struct:
+(gdb) p $lx_current().pid
+$1 = 4998
+(gdb) p $lx_current().comm
+$2 = "modprobe\000\000\000\000\000\000\000"
+
+ o Make use of the per-cpu function for the current or a specified CPU:
+(gdb) p $lx_per_cpu("runqueues").nr_running
+$3 = 1
[PATCH v7 17/21] scripts/gdb: Add internal helper and convenience function for per-cpu lookup
This function allows to obtain a per-cpu variable, either of the current
or an explicitly specified CPU.
Note: sparc64 version is untested.
CC: "David S. Miller"
CC: sparcli...@vger.kernel.org
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/cpus.py | 68 ++
scripts/gdb/vmlinux-gdb.py | 1 +
2 files changed, 69 insertions(+)
create mode 100644 scripts/gdb/linux/cpus.py
diff --git a/scripts/gdb/linux/cpus.py b/scripts/gdb/linux/cpus.py
new file mode 100644
index 000..18337e0
--- /dev/null
+++ b/scripts/gdb/linux/cpus.py
@@ -0,0 +1,68 @@
+#
+# gdb helper commands and functions for Linux kernel debugging
+#
+# per-cpu tools
+#
+# Copyright (c) Siemens AG, 2011-2013
+#
+# Authors:
+# Jan Kiszka
+#
+# This work is licensed under the terms of the GNU GPL version 2.
+#
+
+import gdb
+
+from linux import tasks, utils
+
+
+MAX_CPUS = 4096
+
+
+def get_current_cpu():
+if utils.get_gdbserver_type() == utils.GDBSERVER_QEMU:
+return gdb.selected_thread().num - 1
+elif utils.get_gdbserver_type() == utils.GDBSERVER_KGDB:
+tid = gdb.selected_thread().ptid[2]
+if tid > (0x1 - MAX_CPUS - 2):
+return 0x1 - tid - 2
+else:
+return tasks.get_thread_info(tasks.get_task_by_pid(tid))['cpu']
+else:
+raise gdb.GdbError("Sorry, obtaining the current CPU is not yet "
+ "supported with this gdb server.")
+
+
+def per_cpu(var_ptr, cpu):
+if cpu == -1:
+cpu = get_current_cpu()
+if utils.is_target_arch("sparc:v9"):
+offset = gdb.parse_and_eval(
+"trap_block[{0}].__per_cpu_base".format(str(cpu)))
+else:
+try:
+offset = gdb.parse_and_eval(
+"__per_cpu_offset[{0}]".format(str(cpu)))
+except gdb.error:
+# !CONFIG_SMP case
+offset = 0
+pointer = var_ptr.cast(utils.get_long_type()) + offset
+return pointer.cast(var_ptr.type).dereference()
+
+
+class PerCpu(gdb.Function):
+"""Return per-cpu variable.
+
+$lx_per_cpu("VAR"[, CPU]): Return the per-cpu variable called VAR for the
+given CPU number. If CPU is omitted, the CPU of the current context is used.
+Note that VAR has to be quoted as string."""
+
+def __init__(self):
+super(PerCpu, self).__init__("lx_per_cpu")
+
+def invoke(self, var_name, cpu=-1):
+var_ptr = gdb.parse_and_eval("&" + var_name.string())
+return per_cpu(var_ptr, cpu)
+
+
+PerCpu()
diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py
index 4d7eb2c..4848928 100644
--- a/scripts/gdb/vmlinux-gdb.py
+++ b/scripts/gdb/vmlinux-gdb.py
@@ -27,3 +27,4 @@ else:
import linux.modules
import linux.dmesg
import linux.tasks
+import linux.cpus
--
1.8.1.1.298.ge7eed54
--
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 v7 06/21] module: Do not inline do_init_module
This provides a reliable breakpoint target, required for automatic
symbol loading via the gdb helper command 'lx-symbols'.
CC: Rusty Russell
Signed-off-by: Jan Kiszka
---
kernel/module.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index dc58274..a40d48a 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3035,8 +3035,13 @@ static void do_mod_ctors(struct module *mod)
#endif
}
-/* This is where the real work happens */
-static int do_init_module(struct module *mod)
+/*
+ * This is where the real work happens.
+ *
+ * Keep it uninlined to provide a reliable breakpoint target, e.g. for the gdb
+ * helper command 'lx-symbols'.
+ */
+static noinline int do_init_module(struct module *mod)
{
int ret = 0;
--
1.8.1.1.298.ge7eed54
--
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 v7 15/21] scripts/gdb: Add internal helper and convenience function to retrieve thread_info
Add the internal helper get_thread_info that calculates the thread_info
from a given task variable. Also export this service as a convenience
function.
Note: ia64 version is untested.
CC: Tony Luck
CC: Fenghua Yu
CC: linux-i...@vger.kernel.org
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/tasks.py | 35 +++
1 file changed, 35 insertions(+)
diff --git a/scripts/gdb/linux/tasks.py b/scripts/gdb/linux/tasks.py
index 13bb97c..63cd6c5 100644
--- a/scripts/gdb/linux/tasks.py
+++ b/scripts/gdb/linux/tasks.py
@@ -71,3 +71,38 @@ return that task_struct variable which PID matches."""
LxTaskByPidFunc()
+
+
+thread_info_type = utils.CachedType("struct thread_info")
+
+ia64_task_size = None
+
+
+def get_thread_info(task):
+global thread_info_type
+thread_info_ptr_type = thread_info_type.get_type().pointer()
+if utils.is_target_arch("ia64"):
+global ia64_task_size
+if ia64_task_size is None:
+ia64_task_size = gdb.parse_and_eval("sizeof(struct task_struct)")
+thread_info_addr = task.address + ia64_task_size
+thread_info = thread_info_addr.cast(thread_info_ptr_type)
+else:
+thread_info = task['stack'].cast(thread_info_ptr_type)
+return thread_info.dereference()
+
+
+class LxThreadInfoFunc (gdb.Function):
+"""Calculate Linux thread_info from task variable.
+
+$lx_thread_info(TASK): Given TASK, return the corresponding thread_info
+variable."""
+
+def __init__(self):
+super(LxThreadInfoFunc, self).__init__("lx_thread_info")
+
+def invoke(self, task):
+return get_thread_info(task)
+
+
+LxThreadInfoFunc()
--
1.8.1.1.298.ge7eed54
--
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 v7 20/21] scripts/gdb: Add lx-lsmod command
This adds a lsmod-like command to list all currently loaded modules of
the target.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/modules.py | 46 +++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/scripts/gdb/linux/modules.py b/scripts/gdb/linux/modules.py
index 531f763..e7c99e9 100644
--- a/scripts/gdb/linux/modules.py
+++ b/scripts/gdb/linux/modules.py
@@ -13,7 +13,7 @@
import gdb
-from linux import utils
+from linux import cpus, utils
module_type = utils.CachedType("struct module")
@@ -65,3 +65,47 @@ of the target and return that module variable which MODULE
matches."""
LxModule()
+
+
+class LxLsmod(gdb.Command):
+"""List currently loaded modules."""
+
+_module_use_type = utils.CachedType("struct module_use")
+
+def __init__(self):
+super(LxLsmod, self).__init__("lx-lsmod", gdb.COMMAND_DATA)
+
+def invoke(self, arg, from_tty):
+gdb.write(
+"Address{0}Module Size Used by\n".format(
+"" if utils.get_long_type().sizeof == 8 else ""))
+
+for module in ModuleList():
+ref = 0
+module_refptr = module['refptr']
+for cpu in cpus.CpuList("cpu_possible_mask"):
+refptr = cpus.per_cpu(module_refptr, cpu)
+ref += refptr['incs']
+ref -= refptr['decs']
+
+gdb.write("{address} {name:<19} {size:>8} {ref}".format(
+address=str(module['module_core']).split()[0],
+name=module['name'].string(),
+size=module['core_size'],
+ref=ref))
+
+source_list = module['source_list']
+t = self._module_use_type.get_type().pointer()
+entry = source_list['next']
+first = True
+while entry != source_list.address:
+use = utils.container_of(entry, t, "source_list")
+gdb.write("{separator}{name}".format(
+separator=" " if first else ",",
+name=use['source']['name'].string()))
+first = False
+entry = entry['next']
+gdb.write("\n")
+
+
+LxLsmod()
--
1.8.1.1.298.ge7eed54
--
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 v7 05/21] scripts/gdb: Add lx-symbols command
This is probably the most useful helper when debugging kernel modules:
lx-symbols first reloads vmlinux. Then it searches recursively for *.ko
files in the specified paths and the current directory. Finally it walks
the kernel's module list, issuing the necessary add-symbol-file command
for each loaded module so that gdb knows which module symbol corresponds
to which address. It also looks up variable sections (bss, data, rodata)
and appends their address to the add-symbole-file command line. This
allows to access global module variables just like any other variable.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/symbols.py | 127 +++
scripts/gdb/vmlinux-gdb.py | 1 +
2 files changed, 128 insertions(+)
create mode 100644 scripts/gdb/linux/symbols.py
diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py
new file mode 100644
index 000..bd21a96
--- /dev/null
+++ b/scripts/gdb/linux/symbols.py
@@ -0,0 +1,127 @@
+#
+# gdb helper commands and functions for Linux kernel debugging
+#
+# load kernel and module symbols
+#
+# Copyright (c) Siemens AG, 2011-2013
+#
+# Authors:
+# Jan Kiszka
+#
+# This work is licensed under the terms of the GNU GPL version 2.
+#
+
+import gdb
+import os
+import re
+import string
+
+from linux import modules, utils
+
+
+class LxSymbols(gdb.Command):
+"""(Re-)load symbols of Linux kernel and currently loaded modules.
+
+The kernel (vmlinux) is taken from the current working directly. Modules (.ko)
+are scanned recursively, starting in the same directory. Optionally, the module
+search path can be extended by a space separated list of paths passed to the
+lx-symbols command."""
+
+module_paths = []
+module_files = []
+module_files_updated = False
+
+def __init__(self):
+super(LxSymbols, self).__init__("lx-symbols", gdb.COMMAND_FILES,
+gdb.COMPLETE_FILENAME)
+
+def _update_module_files(self):
+self.module_files = []
+for path in self.module_paths:
+gdb.write("scanning for modules in {0}\n".format(path))
+for root, dirs, files in os.walk(path):
+for name in files:
+if name.endswith(".ko"):
+self.module_files.append(root + "/" + name)
+self.module_files_updated = True
+
+def _get_module_file(self, module_name):
+module_pattern = ".*/{0}\.ko$".format(
+string.replace(module_name, "_", r"[_\-]"))
+for name in self.module_files:
+if re.match(module_pattern, name) and os.path.exists(name):
+return name
+return None
+
+def _section_arguments(self, module):
+try:
+sect_attrs = module['sect_attrs'].dereference()
+except gdb.error:
+return ""
+attrs = sect_attrs['attrs']
+section_name_to_address = {
+attrs[n]['name'].string() : attrs[n]['address']
+for n in range(sect_attrs['nsections'])}
+args = []
+for section_name in [".data", ".data..read_mostly", ".rodata", ".bss"]:
+address = section_name_to_address.get(section_name)
+if address:
+args.append(" -s {name} {addr}".format(
+name=section_name, addr=str(address)))
+return "".join(args)
+
+def load_module_symbols(self, module):
+module_name = module['name'].string()
+module_addr = str(module['module_core']).split()[0]
+
+module_file = self._get_module_file(module_name)
+if not module_file and not self.module_files_updated:
+self._update_module_files()
+module_file = self._get_module_file(module_name)
+
+if module_file:
+gdb.write("loading @{addr}: {filename}\n".format(
+addr=module_addr, filename=module_file))
+cmdline = "add-symbol-file {filename} {addr}{sections}".format(
+filename=module_file,
+addr=module_addr,
+sections=self._section_arguments(module))
+gdb.execute(cmdline, to_string=True)
+else:
+gdb.write("no module object found for '{0}'\n".format(module_name))
+
+def load_all_symbols(self):
+gdb.write("loading vmlinux\n")
+
+# Dropping symbols will disable all breakpoints. So save their states
+# and restore them afterward.
+saved_states = []
+if hasattr(gdb, 'breakpoints') and not gdb.breakpoints() is None:
+for bp in gdb.breakpoints():
+saved_states.append({'breakpoint': bp, 'enabled': bp.enabled})
+
+# drop all current symbols and reload vmlinux
+gdb.execute("symbol-file", to_string=True)
+gdb.execute("symbol-file vmlinux")
+
+module_list = modules.ModuleList()
+if not module_list:
+gdb.write("no modules found\n")
+else:
+
[PATCH v7 10/21] scripts/gdb: Add read_u16/32/64 helpers
Add helpers for reading integers from target memory buffers. Required
when caching the memory access is more efficient than reading individual
values via gdb.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/utils.py | 21 +
1 file changed, 21 insertions(+)
diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py
index 10a227b..808a265 100644
--- a/scripts/gdb/linux/utils.py
+++ b/scripts/gdb/linux/utils.py
@@ -85,3 +85,24 @@ def get_target_endianness():
else:
raise gdb.GdgError("unknown endianness '{0}'".format(endian))
return target_endianness
+
+
+def read_u16(buffer):
+if get_target_endianness() == LITTLE_ENDIAN:
+return ord(buffer[0]) + (ord(buffer[1]) << 8)
+else:
+return ord(buffer[1]) + (ord(buffer[0]) << 8)
+
+
+def read_u32(buffer):
+if get_target_endianness() == LITTLE_ENDIAN:
+return read_u16(buffer[0:2]) + (read_u16(buffer[2:4]) << 16)
+else:
+return read_u16(buffer[2:4]) + (read_u16(buffer[0:2]) << 16)
+
+
+def read_u64(buffer):
+if get_target_endianness() == LITTLE_ENDIAN:
+return read_u32(buffer[0:4]) + (read_u32(buffer[4:8]) << 32)
+else:
+return read_u32(buffer[4:8]) + (read_u32(buffer[0:4]) << 32)
--
1.8.1.1.298.ge7eed54
--
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 v7 00/21] Add gdb python scripts as kernel debugging helpers
Another round, addressing the following review comments on v6: - introduce CONFIG_GDB_SCRIPTS to enable/disable this feature - adjust documentation and fix a minor detail See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for the original description and git://git.kiszka.org/linux.git queues/gdb-scripts for the latest version. Jan CC: "David S. Miller" CC: Fenghua Yu CC: Kay Sievers CC: linux-...@vger.kernel.org CC: linux-i...@vger.kernel.org CC: linux-kbu...@vger.kernel.org CC: Michal Marek CC: Rob Landley CC: Rusty Russell CC: sparcli...@vger.kernel.org CC: Tony Luck Jan Kiszka (21): scripts/gdb: Add infrastructure scripts/gdb: Add cache for type objects scripts/gdb: Add container_of helper and convenience function scripts/gdb: Add module iteration class scripts/gdb: Add lx-symbols command module: Do not inline do_init_module scripts/gdb: Add automatic symbol reloading on module insertion scripts/gdb: Add internal helper and convenience function to look up a module scripts/gdb: Add get_target_endianness helper scripts/gdb: Add read_u16/32/64 helpers scripts/gdb: Add lx-dmesg command scripts/gdb: Add task iteration class scripts/gdb: Add helper and convenience function to look up tasks scripts/gdb: Add is_target_arch helper scripts/gdb: Add internal helper and convenience function to retrieve thread_info scripts/gdb: Add get_gdbserver_type helper scripts/gdb: Add internal helper and convenience function for per-cpu lookup scripts/gdb: Add lx_current convenience function scripts/gdb: Add class to iterate over CPU masks scripts/gdb: Add lx-lsmod command scripts/gdb: Add basic documentation Documentation/gdb-kernel-debugging.txt | 160 +++ Makefile | 5 +- kernel/module.c| 9 +- lib/Kconfig.debug | 11 +++ scripts/Makefile | 3 +- scripts/gdb/Makefile | 11 +++ scripts/gdb/linux/Makefile | 9 ++ scripts/gdb/linux/__init__.py | 0 scripts/gdb/linux/cpus.py | 139 +++ scripts/gdb/linux/dmesg.py | 64 + scripts/gdb/linux/modules.py | 111 ++ scripts/gdb/linux/symbols.py | 166 + scripts/gdb/linux/tasks.py | 108 + scripts/gdb/linux/utils.py | 156 +++ scripts/gdb/vmlinux-gdb.py | 30 ++ 15 files changed, 978 insertions(+), 4 deletions(-) create mode 100644 Documentation/gdb-kernel-debugging.txt create mode 100644 scripts/gdb/Makefile create mode 100644 scripts/gdb/linux/Makefile create mode 100644 scripts/gdb/linux/__init__.py create mode 100644 scripts/gdb/linux/cpus.py create mode 100644 scripts/gdb/linux/dmesg.py create mode 100644 scripts/gdb/linux/modules.py create mode 100644 scripts/gdb/linux/symbols.py create mode 100644 scripts/gdb/linux/tasks.py create mode 100644 scripts/gdb/linux/utils.py create mode 100644 scripts/gdb/vmlinux-gdb.py -- 1.8.1.1.298.ge7eed54 -- 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 v7 13/21] scripts/gdb: Add helper and convenience function to look up tasks
Add the helper task_by_pid that can look up a task by its PID. Also
export it as a convenience function.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/tasks.py | 27 +++
scripts/gdb/vmlinux-gdb.py | 1 +
2 files changed, 28 insertions(+)
diff --git a/scripts/gdb/linux/tasks.py b/scripts/gdb/linux/tasks.py
index cd25984..13bb97c 100644
--- a/scripts/gdb/linux/tasks.py
+++ b/scripts/gdb/linux/tasks.py
@@ -44,3 +44,30 @@ class TaskList:
utils.container_of(t['thread_group']['next'],
self.task_ptr_type, "thread_group")
return t
+
+
+def get_task_by_pid(pid):
+for task in TaskList():
+if int(task['pid']) == pid:
+return task
+return None
+
+
+class LxTaskByPidFunc(gdb.Function):
+"""Find Linux task by PID and return the task_struct variable.
+
+$lx_task_by_pid(PID): Given PID, iterate over all tasks of the target and
+return that task_struct variable which PID matches."""
+
+def __init__(self):
+super(LxTaskByPidFunc, self).__init__("lx_task_by_pid")
+
+def invoke(self, pid):
+task = get_task_by_pid(pid)
+if task:
+return task.dereference()
+else:
+raise gdb.GdbError("No task of PID " + str(pid))
+
+
+LxTaskByPidFunc()
diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py
index fa66d23..4d7eb2c 100644
--- a/scripts/gdb/vmlinux-gdb.py
+++ b/scripts/gdb/vmlinux-gdb.py
@@ -26,3 +26,4 @@ else:
import linux.symbols
import linux.modules
import linux.dmesg
+import linux.tasks
--
1.8.1.1.298.ge7eed54
--
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 v7 19/21] scripts/gdb: Add class to iterate over CPU masks
Will be used first to count module references. It is optimized to read
the mask only once per stop.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/cpus.py | 54 +++
1 file changed, 54 insertions(+)
diff --git a/scripts/gdb/linux/cpus.py b/scripts/gdb/linux/cpus.py
index b683da9..c1441f2 100644
--- a/scripts/gdb/linux/cpus.py
+++ b/scripts/gdb/linux/cpus.py
@@ -50,6 +50,60 @@ def per_cpu(var_ptr, cpu):
return pointer.cast(var_ptr.type).dereference()
+cpu_mask = {}
+
+
+def cpu_mask_invalidate(event):
+global cpu_mask
+cpu_mask = {}
+gdb.events.stop.disconnect(cpu_mask_invalidate)
+if hasattr(gdb.events, 'new_objfile'):
+gdb.events.new_objfile.disconnect(cpu_mask_invalidate)
+
+
+class CpuList():
+def __init__(self, mask_name):
+global cpu_mask
+self.mask = None
+if mask_name in cpu_mask:
+self.mask = cpu_mask[mask_name]
+if self.mask is None:
+self.mask = gdb.parse_and_eval(mask_name + ".bits")
+if hasattr(gdb, 'events'):
+cpu_mask[mask_name] = self.mask
+gdb.events.stop.connect(cpu_mask_invalidate)
+if hasattr(gdb.events, 'new_objfile'):
+gdb.events.new_objfile.connect(cpu_mask_invalidate)
+self.bits_per_entry = self.mask[0].type.sizeof * 8
+self.num_entries = self.mask.type.sizeof * 8 / self.bits_per_entry
+self.entry = -1
+self.bits = 0
+
+def __iter__(self):
+return self
+
+def next(self):
+while self.bits == 0:
+self.entry += 1
+if self.entry == self.num_entries:
+raise StopIteration
+self.bits = self.mask[self.entry]
+if self.bits != 0:
+self.bit = 0
+break
+
+while self.bits & 1 == 0:
+self.bits >>= 1
+self.bit += 1
+
+cpu = self.entry * self.bits_per_entry + self.bit
+
+self.bits >>= 1
+self.bit += 1
+
+return cpu
+
+
class PerCpu(gdb.Function):
"""Return per-cpu variable.
--
1.8.1.1.298.ge7eed54
--
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 v7 02/21] scripts/gdb: Add cache for type objects
Type lookups are very slow in gdb-python which is often noticeable when
iterating over a number of objects. Introduce the helper class
CachedType that keeps a reference to a gdb.Type object but also
refreshes it after an object file has been loaded.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/utils.py | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 scripts/gdb/linux/utils.py
diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py
new file mode 100644
index 000..f883611
--- /dev/null
+++ b/scripts/gdb/linux/utils.py
@@ -0,0 +1,34 @@
+#
+# gdb helper commands and functions for Linux kernel debugging
+#
+# common utilities
+#
+# Copyright (c) Siemens AG, 2011-2013
+#
+# Authors:
+# Jan Kiszka
+#
+# This work is licensed under the terms of the GNU GPL version 2.
+#
+
+import gdb
+
+
+class CachedType:
+def __init__(self, name):
+self._type = None
+self._name = name
+
+def _new_objfile_handler(self, event):
+self._type = None
+gdb.events.new_objfile.disconnect(self._new_objfile_handler)
+
+def get_type(self):
+if self._type is None:
+self._type = gdb.lookup_type(self._name)
+if self._type is None:
+raise gdb.GdbError(
+"cannot resolve type '{0}'".format(self._name))
+if hasattr(gdb, 'events') and hasattr(gdb.events, 'new_objfile'):
+gdb.events.new_objfile.connect(self._new_objfile_handler)
+return self._type
--
1.8.1.1.298.ge7eed54
--
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 v7 03/21] scripts/gdb: Add container_of helper and convenience function
Provide an internal helper with container_of semantics. As type lookups
are very slow in gdb-python and we need a type "long" for this, cache
the reference to this type object. Then export the helper also as a
convenience function form use at the gdb command line.
Signed-off-by: Jan Kiszka
---
scripts/gdb/linux/utils.py | 35 +++
scripts/gdb/vmlinux-gdb.py | 2 ++
2 files changed, 37 insertions(+)
diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py
index f883611..c9d705b 100644
--- a/scripts/gdb/linux/utils.py
+++ b/scripts/gdb/linux/utils.py
@@ -32,3 +32,38 @@ class CachedType:
if hasattr(gdb, 'events') and hasattr(gdb.events, 'new_objfile'):
gdb.events.new_objfile.connect(self._new_objfile_handler)
return self._type
+
+
+long_type = CachedType("long")
+
+
+def get_long_type():
+global long_type
+return long_type.get_type()
+
+
+def offset_of(typeobj, field):
+element = gdb.Value(0).cast(typeobj)
+return int(str(element[field].address).split()[0], 16)
+
+
+def container_of(ptr, typeobj, member):
+return (ptr.cast(get_long_type()) -
+offset_of(typeobj, member)).cast(typeobj)
+
+
+class ContainerOf(gdb.Function):
+"""Return pointer to containing data structure.
+
+$container_of(PTR, "TYPE", "ELEMENT"): Given PTR, return a pointer to the
+data structure of the type TYPE in which PTR is the address of ELEMENT.
+Note that TYPE and ELEMENT have to be quoted as strings."""
+
+def __init__(self):
+super(ContainerOf, self).__init__("container_of")
+
+def invoke(self, ptr, typename, elementname):
+return container_of(ptr, gdb.lookup_type(typename.string()).pointer(),
+elementname.string())
+
+ContainerOf()
diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py
index c1d90ce..6495841 100644
--- a/scripts/gdb/vmlinux-gdb.py
+++ b/scripts/gdb/vmlinux-gdb.py
@@ -21,3 +21,5 @@ try:
except:
gdb.write("NOTE: gdb 7.2 or later required for Linux helper scripts to "
"work.\n")
+else:
+import linux.utils
--
1.8.1.1.298.ge7eed54
--
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] perf tools: Prevent condition that all sort keys are elided
Hi Ingo, On Mon, 11 Nov 2013 12:20:13 +0100, Ingo Molnar wrote: > * Namhyung Kim wrote: >> +/* >> + * It makes no sense to elide all of sort entries. >> + * Just revert them to show up again. >> + */ >> +list_for_each_entry(se, _entry__sort_list, list) >> +if (!se->elide) >> +return; > > (Nit: please use curly braces around multi-line statements.) Ah, okay. > >> + >> +list_for_each_entry(se, _entry__sort_list, list) >> +se->elide = false; > > Looks good otherwise - this is the first step in the sort/key behavior > improvements that we talked about a few days ago, right? Right. And I'd like to wait bit more to hear other's opinion on this. > > Acked-by: Ingo Molnar Thanks, Namhyung -- 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/
[tip:x86/kaslr] x86, kaslr: Add a circular multiply for better bit diffusion
Commit-ID: e8236c4d9338d52d0f2fcecc0b792ac0542e4ee9
Gitweb: http://git.kernel.org/tip/e8236c4d9338d52d0f2fcecc0b792ac0542e4ee9
Author: H. Peter Anvin
AuthorDate: Mon, 11 Nov 2013 22:45:20 -0800
Committer: H. Peter Anvin
CommitDate: Mon, 11 Nov 2013 23:05:49 -0800
x86, kaslr: Add a circular multiply for better bit diffusion
If we don't have RDRAND (in which case nothing else *should* matter),
most sources have a highly biased entropy distribution. Use a
circular multiply to diffuse the entropic bits. A circular multiply
is a good operation for this: it is cheap on standard hardware and
because it is symmetric (unlike an ordinary multiply) it doesn't
introduce its own bias.
Cc: Kees Cook
Signed-off-by: H. Peter Anvin
Link: http://lkml.kernel.org/r/2013222839.ga28...@www.outflux.net
---
arch/x86/boot/compressed/aslr.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index 8746487..38a07cc 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -64,6 +64,11 @@ static unsigned long get_random_boot(void)
static unsigned long get_random_long(void)
{
+#ifdef CONFIG_X86_64
+ const unsigned long mix_const = 0x5d6008cbf3848dd3UL;
+#else
+ const unsigned long mix_const = 0x3f39e593UL;
+#endif
unsigned long raw, random = get_random_boot();
bool use_i8254 = true;
@@ -90,6 +95,12 @@ static unsigned long get_random_long(void)
random ^= i8254();
}
+ /* Circular multiply for better bit diffusion */
+ asm("mul %3"
+ : "=a" (random), "=d" (raw)
+ : "a" (random), "rm" (mix_const));
+ random += raw;
+
debug_putstr("...\n");
return random;
--
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/
[tip:x86/kaslr] x86, kaslr: Mix entropy sources together as needed
Commit-ID: a653f3563c51c7bb7de63d607bef09d3baddaeb8
Gitweb: http://git.kernel.org/tip/a653f3563c51c7bb7de63d607bef09d3baddaeb8
Author: Kees Cook
AuthorDate: Mon, 11 Nov 2013 14:28:39 -0800
Committer: H. Peter Anvin
CommitDate: Mon, 11 Nov 2013 22:29:44 -0800
x86, kaslr: Mix entropy sources together as needed
Depending on availability, mix the RDRAND and RDTSC entropy together with
XOR. Only when neither is available should the i8254 be used. Update
the Kconfig documentation to reflect this. Additionally, since bits
used for entropy is masked elsewhere, drop the needless masking in
the get_random_long(). Similarly, use the entire TSC, not just the low
32 bits.
Finally, to improve the starting entropy, do a simple hashing of a
build-time versions string and the boot-time boot_params structure for
some additional level of unpredictability.
Signed-off-by: Kees Cook
Link: http://lkml.kernel.org/r/2013222839.ga28...@www.outflux.net
Signed-off-by: H. Peter Anvin
---
arch/x86/Kconfig| 14 +---
arch/x86/boot/compressed/aslr.c | 73 +++--
2 files changed, 65 insertions(+), 22 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 51f4399..596cd9e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1735,13 +1735,17 @@ config RANDOMIZE_BASE
deters exploit attempts relying on knowledge of the location
of kernel internals.
- Entropy is generated using the RDRAND instruction if it
- is supported. If not, then RDTSC is used, if supported. If
- neither RDRAND nor RDTSC are supported, then no randomness
- is introduced.
+ Entropy is generated using the RDRAND instruction if it is
+ supported. If RDTSC is supported, it is used as well. If
+ neither RDRAND nor RDTSC are supported, then randomness is
+ read from the i8254 timer.
The kernel will be offset by up to RANDOMIZE_BASE_MAX_OFFSET,
- and aligned according to PHYSICAL_ALIGN.
+ and aligned according to PHYSICAL_ALIGN. Since the kernel is
+ built using 2GiB addressing, and PHYSICAL_ALGIN must be at a
+ minimum of 2MiB, only 10 bits of entropy is theoretically
+ possible. At best, due to page table layouts, 64-bit can use
+ 9 bits of entropy and 32-bit uses 8 bits.
config RANDOMIZE_BASE_MAX_OFFSET
hex "Maximum ASLR offset allowed"
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index 0595798..8746487 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -5,6 +5,17 @@
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Simplified build-specific string for starting entropy. */
+static const char *build_str = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
+ LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
+
#define I8254_PORT_CONTROL 0x43
#define I8254_PORT_COUNTER00x40
#define I8254_CMD_READBACK 0xC0
@@ -25,34 +36,62 @@ static inline u16 i8254(void)
return timer;
}
+static unsigned long rotate_xor(unsigned long hash, const void *area,
+ size_t size)
+{
+ size_t i;
+ unsigned long *ptr = (unsigned long *)area;
+
+ for (i = 0; i < size / sizeof(hash); i++) {
+ /* Rotate by odd number of bits and XOR. */
+ hash = (hash << ((sizeof(hash) * 8) - 7)) | (hash >> 7);
+ hash ^= ptr[i];
+ }
+
+ return hash;
+}
+
+/* Attempt to create a simple but unpredictable starting entropy. */
+static unsigned long get_random_boot(void)
+{
+ unsigned long hash = 0;
+
+ hash = rotate_xor(hash, build_str, sizeof(build_str));
+ hash = rotate_xor(hash, real_mode, sizeof(*real_mode));
+
+ return hash;
+}
+
static unsigned long get_random_long(void)
{
- unsigned long random;
+ unsigned long raw, random = get_random_boot();
+ bool use_i8254 = true;
+
+ debug_putstr("KASLR using");
if (has_cpuflag(X86_FEATURE_RDRAND)) {
- debug_putstr("KASLR using RDRAND...\n");
- if (rdrand_long())
- return random;
+ debug_putstr(" RDRAND");
+ if (rdrand_long()) {
+ random ^= raw;
+ use_i8254 = false;
+ }
}
if (has_cpuflag(X86_FEATURE_TSC)) {
- uint32_t raw;
+ debug_putstr(" RDTSC");
+ rdtscll(raw);
- debug_putstr("KASLR using RDTSC...\n");
- rdtscl(raw);
+ random ^= raw;
+ use_i8254 = false;
+ }
- /* Only use the low bits of rdtsc. */
- random = raw & 0x;
- } else {
- debug_putstr("KASLR using i8254...\n");
- random = i8254();
Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
On 11/12/2013 08:09 AM, Dan Williams wrote:
On Mon, Nov 11, 2013 at 1:12 AM, Hongbo Zhang
wrote:
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct
fsldma_device
*fdev,
WARN_ON(fdev->feature != chan->feature);
chan->dev = fdev->dev;
-chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+chan->id = (res.start & 0xfff) < 0x300 ?
+ ((res.start - 0x100) & 0xfff) >> 7 :
+ ((res.start - 0x200) & 0xfff) >> 7;
if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
Isn't it a bit fragile to have this based on the resource address?
Can't device tree tell you the channel id directly by an index into
the "dma0: dma@100300" node?
Yes, both this way and putting a "cell-index" into device tree work.
This won't be fragile, because the resource address should always be defined
correctly, otherwise even if we can tell a channel id by "cell-index" but
with wrong resource address, nothing will work.
This piece of code only doesn't seem as neat as using "cell-index", but we
prefer the style that let the device tree describes as true as what hardware
really has. This doesn't mean "cell-index" isn't acceptable, if it is
necessary and unavoidable, we can send another patch to add it, but
currently there is no need and we don't have to do this.
I'm pointing it out because we just had a bug fix to another driver
motivated by the fact that resource addresses may move from one
implementation to another, whereas the cell index provided by device
tree is static. Just a note, no need to fix it now.
Get it, and will remember it, thank you Dan.
--
Dan
--
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] of: set dma_mask to point to coherent_dma_mask
On Mon, 11 Nov 2013 16:59:14 +, Stefano Stabellini wrote: > On Wed, 6 Nov 2013, Stefano Stabellini wrote: > > On Sat, 2 Nov 2013, Grant Likely wrote: > > > On Wed, 30 Oct 2013 00:05:22 -0500, Rob Herring > > > wrote: > > > > From: Rob Herring > > > > > > > > Platform devices created by DT code don't initialize dma_mask pointer to > > > > anything. Set it to coherent_dma_mask by default if the architecture > > > > code has not set it. > > > > > > > > Signed-off-by: Rob Herring > > > > > > I believe this is okay. I haven't done any testing to back up that > > > opinion though. > > > > Tested-by: Stefano Stabellini > > BTW I hope you are planning on sending this upstream soon, because > without it I can very easily corrupt my root fs by simply booting the system. Gah! That's pretty nasty. It is in Rob's for-next branch, but it hasn't been marked for backporting to stable. Best thing to do here is for either you or Rob to repost the patch to sta...@vger.kernel.org and include the commit id from Rob's tree. It's not upstream yet, but it will be soon. How far back in kernel releases do you want the patch backported to? g. -- 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 10/10] perf tests: Use lower sample_freq in sw clock event period test
On 11/11/13 22:22, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo
>
> We were using it at 10 kHz, which doesn't work in machines where somehow
> the max freq was auto reduced by the kernel:
>
> [root@ssdandy ~]# perf test 19
> 19: Test software clock events have valid period values: FAILED!
> [root@ssdandy ~]# perf test -v 19
> 19: Test software clock events have valid period values:
> --- start ---
> Couldn't open evlist: Invalid argument
> end
> Test software clock events have valid period values: FAILED!
> [root@ssdandy ~]#
>
> [root@ssdandy ~]# cat /proc/sys/kernel/perf_event_max_sample_rate
> 7000
>
> Reducing it to 500 Hz should be good enough for this test and also
> shouldn't affect what it is testing.
>
> But warn the user if it fails, informing the knob and the freq tried.
Doesn't work for me:
./perf test -v 19
19: Test software clock events have valid period values:
--- start ---
mmap size 528384B
mmap size 528384B
All (0) samples have period value of 1!
end
Test software clock events have valid period values: FAILED!
But this fixes it:
diff --git a/tools/perf/tests/sw-clock.c b/tools/perf/tests/sw-clock.c
index 93a7139..6664a7c 100644
--- a/tools/perf/tests/sw-clock.c
+++ b/tools/perf/tests/sw-clock.c
@@ -9,7 +9,7 @@
#include "util/cpumap.h"
#include "util/thread_map.h"
-#define NR_LOOPS 100
+#define NR_LOOPS 1000
/*
* This test will open software clock events (cpu-clock, task-clock)
>
> Cc: Adrian Hunter
> Cc: David Ahern
> Cc: Frederic Weisbecker
> Cc: Jiri Olsa
> Cc: Mike Galbraith
> Cc: Namhyung Kim
> Cc: Paul Mackerras
> Cc: Peter Zijlstra
> Cc: Stephane Eranian
> Link: http://lkml.kernel.org/n/tip-548rhj1uo6xbwnxa95kw3...@git.kernel.org
> Signed-off-by: Arnaldo Carvalho de Melo
> ---
> tools/perf/tests/sw-clock.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/tests/sw-clock.c b/tools/perf/tests/sw-clock.c
> index ed28dfe7..93a7139ff5f7 100644
> --- a/tools/perf/tests/sw-clock.c
> +++ b/tools/perf/tests/sw-clock.c
> @@ -34,7 +34,7 @@ static int __test__sw_clock_freq(enum perf_sw_ids clock_id)
> .freq = 1,
> };
>
> - attr.sample_freq = 1;
> + attr.sample_freq = 500;
>
> evlist = perf_evlist__new();
> if (evlist == NULL) {
> @@ -58,8 +58,11 @@ static int __test__sw_clock_freq(enum perf_sw_ids clock_id)
> }
>
> if (perf_evlist__open(evlist)) {
> + const char *knob =
> "/proc/sys/kernel/perf_event_max_sample_rate";
> +
> err = -errno;
> - pr_debug("Couldn't open evlist: %s\n", strerror(errno));
> + pr_debug("Couldn't open evlist: %s\nHint: check %s, using %"
> PRIu64 " in this test.\n",
> + strerror(errno), knob, (u64)attr.sample_freq);
> goto out_delete_maps;
> }
>
--
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/6] hardirq: Make hardirq bits generic
Thomas,
Finally found the issue. The patch below fixes the problem here. The
little missing detail is, that I zapped GET_CURRENT() assuming blindly
that this is only needed for the preempt_count hackery. But in fact
the world and some more depends on it which leads to interesting
explosions.
Thanks for debugging this - I won't speculate on why we attempt to
handle softirqs explicitly, as I have only a passing acquaintance with
this code, many years back.
Some more thoughts on this.
The whole nesting check in the exisiting low level entry code and what
I tried to resemble with the irq_exit_nested() is pretty pointless.
Let's look at auto_inthandler and ret_from_exception
ENTRY(auto_inthandler)
SAVE_ALL_INT
GET_CURRENT(%d0)
movel %d0,%a1
addqb #1,%a1@(TINFO_PREEMPT+1)
| put exception # in d0
bfextu %sp@(PT_OFF_FORMATVEC){#4,#10},%d0
subw#VEC_SPUR,%d0
movel %sp,%sp@-
movel %d0,%sp@- | put vector # on stack
auto_irqhandler_fixup = . + 2
jsr do_IRQ | process the IRQ
addql #8,%sp | pop parameters off stack
ret_from_interrupt:
movel %curptr@(TASK_STACK),%a1
subqb #1,%a1@(TINFO_PREEMPT+1)
jeq ret_from_last_interrupt
2: RESTORE_ALL
ALIGN
ret_from_last_interrupt:
moveq #(~ALLOWINT>>8)&0xff,%d0
andb%sp@(PT_OFF_SR),%d0
jne 2b
/* check if we need to do software interrupts */
tstlirq_stat+CPUSTAT_SOFTIRQ_PENDING
jeq .Lret_from_exception
pea ret_from_exception
jra do_softirq
ENTRY(ret_from_exception)
.Lret_from_exception:
btst#5,%sp@(PT_OFF_SR) | check if returning to kernel
bnes1f | if so, skip resched, signals
1: RESTORE_ALL
So in every interrupt exit path we check:
1) Whether the hardirq part of preempt_count is zero
2) Whether the interrupt prio mask of SR on stack is zero
and if we finally reach ret_from_exception we have the final check:
3) whether we return to kernel or user space.
And this final check is the only one which matters, really.
If you look at the probability of the first two checks catching
anything, then it's pretty low. Most interrupts returns go through
ret_from_exception. Yes, I added counters which prove that at least on
the aranym, but I doubt that it will make a real difference if you run
this on real hardware.
I'm happy to try that (indeed, verify your patch works on Atari
hardware first) - I trust the patch is relative to m68k git, not your
previous patches?
Cheers,
Michael
So what's the point of having these checks in the hotpath? The patch
below against 3.12 vanilla works nicely on the aranym and I don't see
a reason why this extra hackery is necessary at all. It's just code
bloat in a hotpath.
Now the only valid concern might be do_softirq itself, but that's
pointless as well. If the softirq is interrupted, then we do not
invoke it again. If the nested interrupt happens before irq_exit()
actually disables interrupts, then we won't invoke it either as the
hardirq part of preempt_count is still not zero.
As a side note: The do_softirq calls in the platform/68xxx entry
pathes are just copied leftovers as well. Both entry code pathes are
not fiddling with the preempt count and both call do_IRQ() which will
call irq_exit() at the end which will invoke do_softirq(), so the
check for more softirqs in the irq return path is just pointless.
Thanks,
tglx
---
kernel/entry.S | 40
kernel/ints.c |6 --
platform/68000/entry.S | 33 -
platform/68360/entry.S | 24 +++-
4 files changed, 15 insertions(+), 88 deletions(-)
Index: linux-2.6/arch/m68k/kernel/entry.S
===
--- linux-2.6.orig/arch/m68k/kernel/entry.S
+++ linux-2.6/arch/m68k/kernel/entry.S
@@ -45,7 +45,7 @@
.globl system_call, buserr, trap, resume
.globl sys_call_table
.globl __sys_fork, __sys_clone, __sys_vfork
-.globl ret_from_interrupt, bad_interrupt
+.globl bad_interrupt
.globl auto_irqhandler_fixup
.globl user_irqvec_fixup
@@ -275,8 +275,6 @@ do_delayed_trace:
ENTRY(auto_inthandler)
SAVE_ALL_INT
GET_CURRENT(%d0)
- movel %d0,%a1
- addqb #1,%a1@(TINFO_PREEMPT+1)
| put exception # in d0
bfextu %sp@(PT_OFF_FORMATVEC){#4,#10},%d0
subw#VEC_SPUR,%d0
@@ -286,32 +284,13 @@ ENTRY(auto_inthandler)
auto_irqhandler_fixup = . + 2
jsr do_IRQ | process the IRQ
addql #8,%sp | pop parameters off stack
-
-ret_from_interrupt:
- movel %curptr@(TASK_STACK),%a1
Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
On 11 November 2013 16:51, Will Deacon wrote:
> On Mon, Nov 11, 2013 at 05:35:37AM +, Sandeepa Prabhu wrote:
>> On 8 November 2013 22:26, Will Deacon wrote:
>> >> diff --git a/arch/arm64/include/asm/kprobes.h
>> >> b/arch/arm64/include/asm/kprobes.h
>> >> new file mode 100644
>> >> index 000..9b491d0
>> >> --- /dev/null
>> >> +++ b/arch/arm64/include/asm/kprobes.h
>> >> @@ -0,0 +1,59 @@
>> >> +/*
>> >> + * arch/arm64/include/asm/kprobes.h
>> >> + *
>> >> + * Copyright (C) 2013 Linaro Limited
>> >> + *
>> >> + * 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.
>> >> + *
>> >> + * This program is distributed in the hope that it will be useful,
>> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> >> + * General Public License for more details.
>> >> + */
>> >> +
>> >> +#ifndef _ARM_KPROBES_H
>> >> +#define _ARM_KPROBES_H
>> >> +
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +
>> >> +#define __ARCH_WANT_KPROBES_INSN_SLOT
>> >> +#define MAX_INSN_SIZE 2
>> >
>> > Why is this 2?
>> Second entry is to hold NOP instruction, absence of it cause abort
>> while instruction decode.
>
> Hmm, can you elaborate please? I'm not sure why you should get an abort
> decoding kernel addresses.
well, kprobes does not step from kernel address, but it prepares a
allocated memory(executable), copies the instruction and update the
single step address (ELR) to enable stepping while ERET.
So, don't we need NOP at next location after the instruction because
next instruction will be in decode stage and might throw "undefined
instruction" error?
I have removed the trailing NOP and tested single step and it worked
fine!, so I am not sure if MAX_INSN_SIZE can be 1, I would check v8
debug spec again.
>
>> >> +DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
>> >> +DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>> >> +
>> >> +static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
>> >> +{
>> >> + int i;
>> >> + /* prepare insn slot */
>> >> + p->ainsn.insn[0] = p->opcode;
>> >> + /* NOP for superscalar uArch decode */
>> >
>> > superscalar uArch?
>> well, the comment needs refining, what we mean is that one NOP should
>> follow the instruction in memory slot, for the decode stage(not to hit
>> undefined instruction).
>
> Is this undef related to your comment above?
[Yes, again, I don't know if trailing NOP is necessary as step is
working without it -decode stage for next location is not throwing
"undefined instruction" error while single stepping previous
instruction]
>
>> > NAK. Unmasking debug exceptions from within a debug exception is not safe.
>> > I'd much rather we returned from handling this exception, then took
>> > whatever
>> > other pending exception there was.
>> well, kprobes needs recursive breakpoints to be handled, and I am not
>> sure if this can be achieved other way than unmasking D-flag for a
>> shorter duration where we can expect re-entry (I would check if this
>> can be done without re-cursing)
>> I want to understand why unmasking D-flag is unsafe here, kprobes make
>> sure that recursion depth is only 2 (i.e. does not generate 3rd
>> Breakpoint trap) and interrupts are kept masked while recursion/single
>> stepping. Is it unsafe only if conflict with hardware breakpoint on
>> same CPU?
>
> Is this recursion only to support setting kprobes on the kprobe
> implementation? The problem is that the rest of the debug infrastructure is
> not set up to deal with recursive exceptions, so allowing them can break
> state machines maintained by code like hw_breakpoint.
No, upon one kprobe hit for an address, the subsystem can call the
user-defined handlers (pre- and -post) which can call same function
again. Example, if we place kprobe on "printk" entry, and registered
handler can invoke printk to print more info.
This will make kprobe to trigger again and re-enter, so the kprobe
subsystem need to handle the 2nd instance first, and then return back
to previous execution. D-flag is enabled only the duration when the
pre- and post- handler are called, so they they can recurse and handle
single stepping, after that, D-flag is kept disabled. I am yet to
test the concurrency with hw_breakpoint, would update once I run these
tests.
>
>> >
>> > In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
>> > places a hardware breakpoint on an instruction in the kernel for which
>> > kprobes has patched in a brk. We take the hardware breakpoint, disable the
>> > breakpoint and set up a single step before returning to the brk. The brk
>> > then traps, but we must take care not to disable single-step and/or unmask
>> > debug exceptions, because that will cause the hardware breakpoint code
RE: [PATCH] [sched]: pick the NULL entity caused the panic.
> -Original Message-
> From: Paul Turner [mailto:p...@google.com]
> Sent: Tuesday, November 12, 2013 11:10 AM
> To: Wang, Xiaoming
> Cc: Ingo Molnar; Peter Zijlstra; LKML; Liu, Chuansheng; Zhang, Dongxing
> Subject: Re: [PATCH] [sched]: pick the NULL entity caused the panic.
>
> On Tue, Nov 12, 2013 at 8:29 AM, Wang, Xiaoming
> wrote:
> > cfs_rq get its group run queue but the value of
> > cfs_rq->nr_running maybe zero, which will cause
> > the panic in pick_next_task_fair.
> > So the evaluated of cfs_rq->nr_running is needed.
> >
> > Signed-off-by: xiaoming wang
> > Signed-off-by: Zhang Dongxing
> > ---
> > kernel/sched/fair.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 7c70201..2d440f9 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -3708,7 +3708,7 @@ static struct task_struct
> *pick_next_task_fair(struct rq *rq)
> > se = pick_next_entity(cfs_rq);
> > set_next_entity(cfs_rq, se);
> > cfs_rq = group_cfs_rq(se);
> > - } while (cfs_rq);
> > + } while (cfs_rq && cfs_rq->nr_running);
> >
> > p = task_of(se);
> > if (hrtick_enabled(rq))
>
> This can only happen when something else has already corrupted the
> rb-tree. Breaking out here is going to cause you to instead try
> treating a group entity as a task, which will crash just as badly.
>
> Could you describe what was being run when this crash occurred?
>
> > --
> > 1.7.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/
Dear Paul
How about moving cfs_rq->nr_running into loop. What I worried is that
cfs_rq->nr_running
may zero because cfs_rq is coming from cfs_rq = group_cfs_rq(se) again. We
haven't known the
reproduction exactly, panic happened only on random test and unstable.
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2d440f9..7f2f8b6 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3701,14 +3701,13 @@ static struct task_struct *pick_next_task_fair(struct
rq *rq)
struct cfs_rq *cfs_rq = >cfs;
struct sched_entity *se;
- if (!cfs_rq->nr_running)
- return NULL;
-
do {
+ if (!cfs_rq->nr_running)
+ return NULL;
se = pick_next_entity(cfs_rq);
set_next_entity(cfs_rq, se);
cfs_rq = group_cfs_rq(se);
- } while (cfs_rq && cfs_rq->nr_running);
+ } while (cfs_rq);
p = task_of(se);
if (hrtick_enabled(rq))
--
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 v3] ARM: dts: Exynos5420: Add device nodes for TMU blocks
Exynos5420 SoC has per core thermal management unit.
5 TMU channels 4 for CPUs and 5th for GPU.
This patch adds the device tree nodes to the DT device list.
Nodes carry the misplaced second base address and the second
clock to access the misplaced base address.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Andrew Bresticker
---
Changes since v2:
3. uses the new compatible strings introduced along with adding
support for Exynso5420.
Changes since v1:
1. Nodes carry the misplaced second base address and the second
clock to access the misplaced base address.
2. Correct the clock number for the TMU4
arch/arm/boot/dts/exynos5420.dtsi | 48 +
1 file changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 6ffefd1..d736b40 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -369,4 +369,52 @@
clock-names = "gscl";
samsung,power-domain = <_pd>;
};
+
+ /* tmu for CPU0 */
+ tmu@1006 {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x1006 0x100>;
+ interrupts = <0 65 0>;
+ clocks = < 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for CPU1 */
+ tmu@10064000 {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x10064000 0x100>;
+ interrupts = <0 183 0>;
+ clocks = < 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = "samsung,exynos5420-tmu-triminfo";
+ /* 2nd reg is for the misplaced TRIMINFO register */
+ reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+ interrupts = <0 184 0>;
+ clocks = < 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for CPU3 */
+ tmu@1006c000 {
+ compatible = "samsung,exynos5420-tmu-triminfo-clk";
+ /* 2nd reg is for the misplaced TRIMINFO register */
+ reg = <0x1006c000 0x100>, <0x100a 0x4>;
+ interrupts = <0 185 0>;
+ clocks = < 318>, < 319>;
+ clock-names = "tmu_apbif", "tmu_apbif_triminfo";
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = "samsung,exynos5420-tmu-triminfo-clk";
+ /* 2nd reg is for the misplaced TRIMINFO register */
+ reg = <0x100a 0x100>, <0x10068000 0x4>;
+ interrupts = <0 215 0>;
+ clocks = < 319>, < 318>;
+ clock-names = "tmu_apbif", "tmu_apbif_triminfo";
+ };
};
--
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/
[PATCH] ARM: tegra: init fuse before setting reset handler
CPU reset handler was set before fuse is initialized, but
tegra_cpu_reset_handler_enable() uses tegra_chip_id, which is set by
tegra_init_fuse(). This patch reorders the calls so the CPU reset
handler code does not read an uninitialized variable.
Signed-off-by: Alexandre Courbot
---
arch/arm/mach-tegra/tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 80b801a94677..0fbdadcd96b7 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -92,9 +92,9 @@ static void __init tegra_init_cache(void)
static void __init tegra_init_early(void)
{
- tegra_cpu_reset_handler_init();
tegra_apb_io_init();
tegra_init_fuse();
+ tegra_cpu_reset_handler_init();
tegra_init_cache();
tegra_powergate_init();
tegra_hotplug_init();
--
1.8.4.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 3/4 v9] thermal: samsung: Add TMU support for Exynos5420 SoCs
Exynos5420 has 5 TMU channels, the TRIMINFO register is
misplaced for TMU channels 2, 3 and 4
TRIMINFO at 0x1006c000 contains data for TMU channel 3
TRIMINFO at 0x100a contains data for TMU channel 4
TRIMINFO at 0x10068000 contains data for TMU channel 2
This patch
1 Adds the neccessary register changes and arch information
to support Exynos5420 SoCs.
2. Handles the gate clock for misplaced TRIMINFO register
3. Updates the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Andrew Bresticker
---
Changes since v8:
1. rewrote the Documentation for device tree bindings
2. Merged the https://lkml.org/lkml/2013/11/7/262 (as this is a fix)
3. introduces "samsung,exynos5420-tmu-triminfo" and
"samsung,exynos5420-tmu-triminfo-clk" to handle the TMU channels on
Exynos5420 more appropriately
.../devicetree/bindings/thermal/exynos-thermal.txt | 45 +
drivers/thermal/samsung/exynos_tmu.c | 58 ++-
drivers/thermal/samsung/exynos_tmu.h |2 +
drivers/thermal/samsung/exynos_tmu_data.c | 106
drivers/thermal/samsung/exynos_tmu_data.h |8 ++
5 files changed, 215 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 116cca0..5055b31 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -6,6 +6,11 @@
"samsung,exynos4412-tmu"
"samsung,exynos4210-tmu"
"samsung,exynos5250-tmu"
+ "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
+ "samsung,exynos5420-tmu-triminfo" for TMU channel 2 Exynos5420
+ (Must pass triminfo base)
+ "samsung,exynos5420-tmu-triminfo-clk" for TMU channel 3 and 4
+ Exynos5420 (Must pass triminfo base and triminfo clock)
"samsung,exynos5440-tmu"
- interrupt-parent : The phandle for the interrupt controller
- reg : Address range of the thermal registers. For soc's which has multiple
@@ -13,6 +18,18 @@
interrupt related then 2 set of register has to supplied. First set
belongs to each instance of TMU and second set belongs to second set
of common TMU registers.
+
+ NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ channels 2, 3 and 4
+ Use "samsung,exynos5420-tmu-triminfo" in cases, there is a misplaced
+ register but no need of another clock to access that base.
+ Use "samsung,exynos5420-tmu-triminfo-clk" in cases where there is a
misplaced
+ register and we need another clock to access that base.
+
+ TRIMINFO at 0x1006c000 contains data for TMU channel 3
+ TRIMINFO at 0x100a contains data for TMU channel 4
+ TRIMINFO at 0x10068000 contains data for TMU channel 2
+
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
@@ -43,6 +60,34 @@ Example 2):
clock-names = "tmu_apbif";
};
+Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = "samsung,exynos5420-tmu-triminfo";
+ reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+ interrupts = <0 184 0>;
+ clocks = < 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for CPU3 */
+ tmu@1006c000 {
+ compatible = "samsung,exynos5420-tmu-triminfo-clk";
+ reg = <0x1006c000 0x100>, <0x100a 0x4>;
+ interrupts = <0 185 0>;
+ clocks = < 318>;
+ clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = "samsung,exynos5420-tmu-triminfo-clk";
+ reg = <0x100a 0x100>, <0x10068000 0x4>;
+ interrupts = <0 215 0>;
+ clocks = < 318>;
+ clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ };
+
Note: For multi-instance tmu each instance should have an alias correctly
numbered in "aliases" node.
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index bbd0fc3..826647c 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -47,6 +47,7 @@
* @irq_work: pointer to the irq work structure.
* @lock: lock to implement synchronization.
* @clk: pointer to the clock structure.
+ * @clk_sec: pointer to the clock structure for accessing the base_second.
* @temp_error1: fused value of the first point trim.
* @temp_error2: fused value of the second point trim.
* @regulator:
CONGRATULATIONS
YOUR EMAIL ID HAS WON 1000,000.00/GBP AND 2013 CHEVROLET CAR in the satellite software email lottery.On line Sweepstakes International program Conducted by CHEVROLET LOTTERY BOARD UK in which your e-mail address was picking up randomly by software powered by the Internet. Forward the following details to enable us clear your file for immediate payment and delivery of your winnings: 1.Full Names: 2.Home Address: 3.Age: 4.Sex: 5.Occupation: 6.Phone Numbers: 7.Country: 8.State: MR. A. ADAMS (CLAIMS DIRECTOR) MOBILE NUMBER: +448719156689 CHEVROLET LOTTERY DEPARTMENT -- 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 2/4 v9] thermal: samsung: change base_common to more meaningful base_second
On Exynos5440 and Exynos5420 there are registers common
across the TMU channels.
To support that, we introduced a ADDRESS_MULTIPLE flag in the
driver and the 2nd set of register base and size are provided
in the "reg" property of the node.
As per Amit's suggestion, this patch changes the base_common
to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v8:
None
.../devicetree/bindings/thermal/exynos-thermal.txt |4 ++--
drivers/thermal/samsung/exynos_tmu.c | 14 +++---
drivers/thermal/samsung/exynos_tmu.h |4 ++--
drivers/thermal/samsung/exynos_tmu_data.c|2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f530..116cca0 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -11,8 +11,8 @@
- reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
- belongs to each instance of TMU and second set belongs to common TMU
- registers.
+ belongs to each instance of TMU and second set belongs to second set
+ of common TMU registers.
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index c493245..bbd0fc3 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -41,7 +41,7 @@
* @id: identifier of the one instance of the TMU controller.
* @pdata: pointer to the tmu platform/configuration data
* @base: base address of the single instance of the TMU controller.
- * @base_common: base address of the common registers of the TMU controller.
+ * @base_second: base address of the common registers of the TMU controller.
* @irq: irq number of the TMU controller.
* @soc: id of the SOC type.
* @irq_work: pointer to the irq work structure.
@@ -56,7 +56,7 @@ struct exynos_tmu_data {
int id;
struct exynos_tmu_platform_data *pdata;
void __iomem *base;
- void __iomem *base_common;
+ void __iomem *base_second;
int irq;
enum soc_type soc;
struct work_struct irq_work;
@@ -297,7 +297,7 @@ skip_calib_data:
}
/*Clear the PMIN in the common TMU register*/
if (reg->tmu_pmin && !data->id)
- writel(0, data->base_common + reg->tmu_pmin);
+ writel(0, data->base_second + reg->tmu_pmin);
out:
clk_disable(data->clk);
mutex_unlock(>lock);
@@ -454,7 +454,7 @@ static void exynos_tmu_work(struct work_struct *work)
/* Find which sensor generated this interrupt */
if (reg->tmu_irqstatus) {
- val_type = readl(data->base_common + reg->tmu_irqstatus);
+ val_type = readl(data->base_second + reg->tmu_irqstatus);
if (!((val_type >> data->id) & 0x1))
goto out;
}
@@ -579,7 +579,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
* Check if the TMU shares some registers and then try to map the
* memory of common registers.
*/
- if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
+ if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
return 0;
if (of_address_to_resource(pdev->dev.of_node, 1, )) {
@@ -587,9 +587,9 @@ static int exynos_map_dt_data(struct platform_device *pdev)
return -ENODEV;
}
- data->base_common = devm_ioremap(>dev, res.start,
+ data->base_second = devm_ioremap(>dev, res.start,
resource_size());
- if (!data->base_common) {
+ if (!data->base_second) {
dev_err(>dev, "Failed to ioremap memory\n");
return -ENOMEM;
}
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 980859a..0d6b32f 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -60,7 +60,7 @@ enum soc_type {
* state(active/idle) can be checked.
* TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
* sample time.
- * TMU_SUPPORT_SHARED_MEMORY - This feature tells that the different TMU
+ * TMU_SUPPORT_ADDRESS_MULTIPLE - This feature tells that the different TMU
* sensors shares some common registers.
* TMU_SUPPORT - macro to compare the above features with the supplied.
*/
@@ -70,7 +70,7 @@ enum soc_type {
[PATCH 0/3] thermal: samsung: Clean up and add support for Exynos5420
This patchset does a little clean up of the existing code 1. [v9] thermal: samsung: replace inten_ bit fields with intclr_ 2. [v9] thermal: samsung: change base_common to more meaningful base_second adds support for Exynos5420 in the driver and 3. [v9] thermal: samsung: Add TMU support for Exynos5420 SoCs also adds the device tree nodes for the same to exynos5420.dtsi (linux-samsung.git) 4. [v3] ARM: dts: Exynos5420: Add device nodes for TMU blocks Naveen Krishna Chatradhi (3): thermal: samsung: replace inten_ bit fields with intclr_ thermal: samsung: change base_common to more meaningful base_second thermal: samsung: Add TMU support for Exynos5420 SoCs ARM: dts: Exynos5420: Add device nodes for TMU blocks .../devicetree/bindings/thermal/exynos-thermal.txt | 49 +++- drivers/thermal/samsung/exynos_tmu.c | 78 +--- drivers/thermal/samsung/exynos_tmu.h | 22 ++-- drivers/thermal/samsung/exynos_tmu_data.c | 126 ++-- drivers/thermal/samsung/exynos_tmu_data.h | 12 +- 5 files changed, 249 insertions(+), 38 deletions(-) -- 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/
[PATCH 1/4 v9] thermal: samsung: replace inten_ bit fields with intclr_
This patch replaces the inten_rise_shift/mask and inten_fall_shift/mask
with intclr_rise_shift/mask and intclr_fall_shift/mask respectively.
Currently, inten_rise_shift/mask and inten_fall_shift/mask bits are only used
to configure intclr related registers.
Description of H/W:
The offset for the bits in the CLEAR register are not consistent across TMU
modules in Exynso5250, 5420 and 5440.
On Exynos5250, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT registers and at an offset of
12 in INTCLEAR register.
On Exynos5420, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT and INTCLEAR registers.
On Exynos5440,
the FALL_IRQEN bits are at an offset of 4
and the RISE_IRQEN bits are at an offset of 0
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v8:
1. Modified the patch description,
2. replaces the inten_rise/fall_shift/mask with intclr_rise/fall_shift/mask
drivers/thermal/samsung/exynos_tmu.c |6 +++---
drivers/thermal/samsung/exynos_tmu.h | 16
drivers/thermal/samsung/exynos_tmu_data.c | 18 +-
drivers/thermal/samsung/exynos_tmu_data.h |4 ++--
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 32f38b9..c493245 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -237,7 +237,7 @@ skip_calib_data:
writeb(pdata->trigger_levels[i], data->base +
reg->threshold_th0 + i * sizeof(reg->threshold_th0));
- writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
+ writel(reg->intclr_rise_mask, data->base + reg->tmu_intclear);
} else {
/* Write temperature code for rising and falling threshold */
for (i = 0;
@@ -264,8 +264,8 @@ skip_calib_data:
writel(falling_threshold,
data->base + reg->threshold_th1);
- writel((reg->inten_rise_mask << reg->inten_rise_shift) |
- (reg->inten_fall_mask << reg->inten_fall_shift),
+ writel((reg->intclr_rise_mask << reg->intclr_rise_shift) |
+ (reg->intclr_fall_mask << reg->intclr_fall_shift),
data->base + reg->tmu_intclear);
/* if last threshold limit is also present */
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 3fb6554..980859a 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -122,10 +122,6 @@ enum soc_type {
* @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
* @tmu_inten: register containing the different threshold interrupt
enable bits.
- * @inten_rise_shift: shift bits of all rising interrupt bits.
- * @inten_rise_mask: mask bits of all rising interrupt bits.
- * @inten_fall_shift: shift bits of all rising interrupt bits.
- * @inten_fall_mask: mask bits of all rising interrupt bits.
* @inten_rise0_shift: shift bits of rising 0 interrupt bits.
* @inten_rise1_shift: shift bits of rising 1 interrupt bits.
* @inten_rise2_shift: shift bits of rising 2 interrupt bits.
@@ -136,6 +132,10 @@ enum soc_type {
* @inten_fall3_shift: shift bits of falling 3 interrupt bits.
* @tmu_intstat: Register containing the interrupt status values.
* @tmu_intclear: Register for clearing the raised interrupt status.
+ * @intclr_fall_shift: shift bits for interrupt clear fall 0
+ * @intclr_rise_shift: shift bits of all rising interrupt bits.
+ * @intclr_rise_mask: mask bits of all rising interrupt bits.
+ * @intclr_fall_mask: mask bits of all rising interrupt bits.
* @emul_con: TMU emulation controller register.
* @emul_temp_shift: shift bits of emulation temperature.
* @emul_time_shift: shift bits of emulation time.
@@ -191,10 +191,6 @@ struct exynos_tmu_registers {
u32 threshold_th3_l0_shift;
u32 tmu_inten;
- u32 inten_rise_shift;
- u32 inten_rise_mask;
- u32 inten_fall_shift;
- u32 inten_fall_mask;
u32 inten_rise0_shift;
u32 inten_rise1_shift;
u32 inten_rise2_shift;
@@ -207,6 +203,10 @@ struct exynos_tmu_registers {
u32 tmu_intstat;
u32 tmu_intclear;
+ u32 intclr_fall_shift;
+ u32 intclr_rise_shift;
+ u32 intclr_fall_mask;
+ u32 intclr_rise_mask;
u32 emul_con;
u32 emul_temp_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index 073c292..7cdb04e 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -40,13 +40,13 @@ static const struct exynos_tmu_registers
Re: [PATCH v2 3/3] firmware: Avoid bogus fallback warning
At Tue, 12 Nov 2013 09:40:24 +0800,
Ming Lei wrote:
At Tue, 12 Nov 2013 09:40:24 +0800,
Ming Lei wrote:
>
> On Mon, Nov 11, 2013 at 11:21 PM, Takashi Iwai wrote:
> > The commit [3e358ac2bb5b: firmware: Be a bit more verbose about direct
> > firmware loading failure] introduced a new warning message about
> > falling back to user helper, but this isn't true when
> > CONFIG_FW_LOADER_USER_HELPER isn't set.
> >
> > For avoiding the confusion, add a proper ifdef. And now we can remove
> > the dummy fw_load_from_user_helper(), too, since it's no longer called
> > with CONFIG_FW_LOADER_USER_HELPER=n.
> >
> > Signed-off-by: Takashi Iwai
> > ---
> > drivers/base/firmware_class.c | 10 ++
> > 1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > index 7f48a6ffb0df..bb03c71bd94d 100644
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@ -940,14 +940,6 @@ static void kill_requests_without_uevent(void)
> > #endif
> >
> > #else /* CONFIG_FW_LOADER_USER_HELPER */
> > -static inline int
> > -fw_load_from_user_helper(struct firmware *firmware, const char *name,
> > -struct device *device, bool uevent, bool nowait,
> > -long timeout)
> > -{
> > - return -ENOENT;
> > -}
> > -
> > /* No abort during direct loading */
> > #define is_fw_load_aborted(buf) false
> >
> > @@ -1097,11 +1089,13 @@ _request_firmware(const struct firmware
> > **firmware_p, const char *name,
> > if (ret) {
> > dev_warn(device, "Direct firmware load failed with error
> > %d\n",
> > ret);
> > +#ifdef CONFIG_FW_LOADER_USER_HELPER
> > if (fallback) {
> > dev_warn(device, "Falling back to user helper\n");
>
> I think it is simpler to put above line at the entry of
> fw_load_from_user_helper()
> since we always do direct-loading first, and code should be cleaner.
>
> Thanks,
> --
> Ming Lei
>
>
> On Mon, Nov 11, 2013 at 11:21 PM, Takashi Iwai wrote:
> > The commit [3e358ac2bb5b: firmware: Be a bit more verbose about direct
> > firmware loading failure] introduced a new warning message about
> > falling back to user helper, but this isn't true when
> > CONFIG_FW_LOADER_USER_HELPER isn't set.
> >
> > For avoiding the confusion, add a proper ifdef. And now we can remove
> > the dummy fw_load_from_user_helper(), too, since it's no longer called
> > with CONFIG_FW_LOADER_USER_HELPER=n.
> >
> > Signed-off-by: Takashi Iwai
> > ---
> > drivers/base/firmware_class.c | 10 ++
> > 1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > index 7f48a6ffb0df..bb03c71bd94d 100644
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@ -940,14 +940,6 @@ static void kill_requests_without_uevent(void)
> > #endif
> >
> > #else /* CONFIG_FW_LOADER_USER_HELPER */
> > -static inline int
> > -fw_load_from_user_helper(struct firmware *firmware, const char *name,
> > -struct device *device, bool uevent, bool nowait,
> > -long timeout)
> > -{
> > - return -ENOENT;
> > -}
> > -
> > /* No abort during direct loading */
> > #define is_fw_load_aborted(buf) false
> >
> > @@ -1097,11 +1089,13 @@ _request_firmware(const struct firmware
> > **firmware_p, const char *name,
> > if (ret) {
> > dev_warn(device, "Direct firmware load failed with error
> > %d\n",
> > ret);
> > +#ifdef CONFIG_FW_LOADER_USER_HELPER
> > if (fallback) {
> > dev_warn(device, "Falling back to user helper\n");
>
> I think it is simpler to put above line at the entry of
> fw_load_from_user_helper()
> since we always do direct-loading first, and code should be cleaner.
OK, that makes sense.
While looking back at the code, I think the first warning ("Direct
firmware load failed" should be suppressed, too, when no fallback is
set. For example, non-existing firmware is no error at all for
microcode driver, as a firmware is purely optional. Showing a warning
at each failure would result in lots of bogus warnings and it'd
confuse users as if something critical happened.
So, the first dev_warn() is better in the "if (fallback)" block, IMO.
I'm going to prepare the v3 patch series together with bit flags
change.
thanks,
Takashi
--
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 2/2] perf trace: Fix segfault on perf trace -i perf.data
From: Namhyung Kim
When replaying a previous record session, it'll get a segfault since
it doesn't initialize evsel->priv for finding syscall id. So fix it
by initialize sys_enter/exit evsel manually.
While at it, factor out perf_evsel__init_syscall_tp() to init a
syscall evsel and remove unused perf_session__has_tp().
Cc: David Ahern
Cc: Pekka Enberg
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-trace.c | 63 --
1 file changed, 38 insertions(+), 25 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index aeb6296a76bd..6a18ed0a3e2a 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -149,20 +149,28 @@ static void perf_evsel__delete_priv(struct perf_evsel
*evsel)
perf_evsel__delete(evsel);
}
-static struct perf_evsel *perf_evsel__syscall_newtp(const char *direction,
void *handler)
+static int perf_evsel__init_syscall_tp(struct perf_evsel *evsel, void *handler)
{
- struct perf_evsel *evsel = perf_evsel__newtp("raw_syscalls", direction);
+ evsel->priv = malloc(sizeof(struct syscall_tp));
- if (evsel) {
- evsel->priv = malloc(sizeof(struct syscall_tp));
+ if (evsel->priv == NULL)
+ return -ENOMEM;
- if (evsel->priv == NULL)
- goto out_delete;
+ if (perf_evsel__init_sc_tp_uint_field(evsel, id))
+ return -1;
- if (perf_evsel__init_sc_tp_uint_field(evsel, id))
- goto out_delete;
+ evsel->handler = handler;
+ return 0;
+}
+
+static struct perf_evsel *perf_evsel__syscall_newtp(const char *direction,
+ void *handler)
+{
+ struct perf_evsel *evsel = perf_evsel__newtp("raw_syscalls", direction);
- evsel->handler = handler;
+ if (evsel) {
+ if (perf_evsel__init_syscall_tp(evsel, handler) < 0)
+ goto out_delete;
}
return evsel;
@@ -1754,16 +1762,6 @@ static int trace__process_sample(struct perf_tool *tool,
return err;
}
-static bool
-perf_session__has_tp(struct perf_session *session, const char *name)
-{
- struct perf_evsel *evsel;
-
- evsel = perf_evlist__find_tracepoint_by_name(session->evlist, name);
-
- return evsel != NULL;
-}
-
static int parse_target_str(struct trace *trace)
{
if (trace->opts.target.pid) {
@@ -2000,8 +1998,6 @@ out_error:
static int trace__replay(struct trace *trace)
{
const struct perf_evsel_str_handler handlers[] = {
- { "raw_syscalls:sys_enter", trace__sys_enter, },
- { "raw_syscalls:sys_exit", trace__sys_exit, },
{ "probe:vfs_getname", trace__vfs_getname, },
};
struct perf_data_file file = {
@@ -2009,6 +2005,7 @@ static int trace__replay(struct trace *trace)
.mode = PERF_DATA_MODE_READ,
};
struct perf_session *session;
+ struct perf_evsel *evsel;
int err = -1;
trace->tool.sample= trace__process_sample;
@@ -2040,13 +2037,29 @@ static int trace__replay(struct trace *trace)
if (err)
goto out;
- if (!perf_session__has_tp(session, "raw_syscalls:sys_enter")) {
- pr_err("Data file does not have raw_syscalls:sys_enter
events\n");
+ evsel = perf_evlist__find_tracepoint_by_name(session->evlist,
+"raw_syscalls:sys_enter");
+ if (evsel == NULL) {
+ pr_err("Data file does not have raw_syscalls:sys_enter
event\n");
+ goto out;
+ }
+
+ if (perf_evsel__init_syscall_tp(evsel, trace__sys_enter) < 0 ||
+ perf_evsel__init_sc_tp_ptr_field(evsel, args)) {
+ pr_err("Error during initialize raw_syscalls:sys_enter
event\n");
+ goto out;
+ }
+
+ evsel = perf_evlist__find_tracepoint_by_name(session->evlist,
+"raw_syscalls:sys_exit");
+ if (evsel == NULL) {
+ pr_err("Data file does not have raw_syscalls:sys_exit event\n");
goto out;
}
- if (!perf_session__has_tp(session, "raw_syscalls:sys_exit")) {
- pr_err("Data file does not have raw_syscalls:sys_exit
events\n");
+ if (perf_evsel__init_syscall_tp(evsel, trace__sys_exit) < 0 ||
+ perf_evsel__init_sc_tp_uint_field(evsel, ret)) {
+ pr_err("Error during initialize raw_syscalls:sys_exit event\n");
goto out;
}
--
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/
[PATCH 1/2] perf trace: Beautify fifth argument of mmap() as fd
From: Namhyung Kim
The fifth argument of mmap syscall is fd and it often contains -1 as a
value for anon mappings. Without this patch it doesn't show the file
name as well as it shows -1 as 4294967295.
Cc: David Ahern
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-trace.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index c3008b1c369c..aeb6296a76bd 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -951,7 +951,8 @@ static struct syscall_fmt {
{ .name = "mmap", .hexret = true,
.arg_scnprintf = { [0] = SCA_HEX, /* addr */
[2] = SCA_MMAP_PROT, /* prot */
-[3] = SCA_MMAP_FLAGS, /* flags */ }, },
+[3] = SCA_MMAP_FLAGS, /* flags */
+[4] = SCA_FD,/* fd */ }, },
{ .name = "mprotect", .errmsg = true,
.arg_scnprintf = { [0] = SCA_HEX, /* start */
[2] = SCA_MMAP_PROT, /* prot */ }, },
--
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: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
>>> OK, I've ensured that the hw_breakpoint (from perf) can work >>> with kprobes (from ftrace) at the same address on x86. >>> So if arm64 already support hw_breakpoint on perf, kprobes should >>> work with it. >> >> Single-stepping on x86 is different to the step behaviour on arm64 afaik. On >> ARM, we have to manually remove the breakpoint, perform a single-step, then >> add the breakpoint again. If we re-enable debug exceptions in the kprobe >> handler, the step will complete early and we'll never step off the >> breakpoint. > > I'm unsure about arm64's debug feature behavior, what does happen when > it performs a single-step on sw-breakpoint? > >> Sandeepa: I think you need to retry Masami's test on the arm64 model, since >> I'm fairly sure it won't work as expected without some additional code. > > OK, anyway, for testing same one, we need to port ftrace first. So the next > plan is to make a kprobe module to put a probe (which just printk something) > on a specific function (e.g. vfs_symlink), and run perf record with > hw-breakpoint as below > > $ perf record -e "mem:0xXX:k" ln -s /dev/null /tmp/foo > > Note that 0xXX is the address of vfs_symlink. > > After that, you can see the message in dmesg and also check the perf result > with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if > it works) Thanks for steps, ARM64 ftrace patches are under review on arm mailing list, I can contact the (linaro) developer implementing ftrace on what's supported and then figure-out a way to test this concurrency of kprobes breakpoint and hardware breakpoint. Thanks, Sandeepa > > Thank you, > > -- > Masami HIRAMATSU > IT Management Research Dept. Linux Technology Center > Hitachi, Ltd., Yokohama Research Laboratory > E-mail: masami.hiramatsu...@hitachi.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/
[PATCH] add cond_resched() to shrink_dcache_for_umount_subtree()
Much like the other shrink_dcache_*() functions, shrink_dcache_for_umount_subtree() could run for a long time if the dcache has many entries, so an occasional "cond_resched" is needed to avoid stalls and soft-lockup warnings. Unlike the other shrinkers, there is no cond_resched call here. So add one. Signed-off-by: NeilBrown diff --git a/fs/dcache.c b/fs/dcache.c index ae6ebb88ceff..1811fa19b419 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1154,6 +1154,7 @@ static void shrink_dcache_for_umount_subtree(struct dentry *dentry) dentry = list_entry(dentry->d_subdirs.next, struct dentry, d_u.d_child); + cond_resched() } } signature.asc Description: PGP signature
Re: [PATCH 3/3 v8] thermal: samsung: Add TMU support for Exynos5420 SoCs
Hello Tomasz,
On 7 November 2013 20:39, Tomasz Figa wrote:
> Hi Naveen,
>
> On Thursday 07 of November 2013 11:23:32 Naveen Krishna Chatradhi wrote:
>> This patch adds the neccessary register changes and arch information
>> to support Exynos5420 SoCs
>> Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU
>>
>> Also updated the Documentation at
>> Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>>
>> Note: The platform data structure will be handled properly once the driver
>> moves to complete device driver solution.
>
> Huh? I'm not sure what do you mean here.
This driver is handling platform data from a predefined structs in driver files.
Platform data is better handled when sent via Device tree nodes.
Will take up the device tree migration once this set is done.
>
>> Signed-off-by: Naveen Krishna Chatradhi
>> ---
>> Changes since v1:
>> 1. modified the platform data structure in order to pass SHARED flag
>>for channels that need sharing of address space.
>> 2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
>>As the changes are minimum and can be added here.
>> Changes since v3:
>>a. Rearraged the code alphabetically, make exynso5420 come before
>> exynso5440
>>b. Reduce code duplication in passing platform data by introducing a
>> common macro
>> Bartlomiej Zolnierkiewicz Thanks for review and suggestions
>> Changes since v4:
>> None
>> Changes since v5:
>> None
>> Changes since v6:
>> - removed the unsued field "inten_fall_shift"
>> - defined EXYNOS5420_TMU_CLEAR_FALL_INT_SHIFT instead of using
>> EXYNOS_TMU_FALL_INT_SHIFT
>> Changes since v7:
>> - changes ins v6 were moved to the patch 1/3 of this patchset.
>> - defined EXYNOS5420_TMU_CLEAR_FALL_INT_SHIFT instead of using
>> EXYNOS_TMU_FALL_INT_SHIFT
>>
>> .../devicetree/bindings/thermal/exynos-thermal.txt | 39
>> drivers/thermal/samsung/exynos_tmu.c | 12 ++-
>> drivers/thermal/samsung/exynos_tmu.h |1 +
>> drivers/thermal/samsung/exynos_tmu_data.c | 98
>>
>> drivers/thermal/samsung/exynos_tmu_data.h |8 ++
>> 5 files changed, 157 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> index 116cca0..c5f9a74 100644
>> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> @@ -6,6 +6,7 @@
>> "samsung,exynos4412-tmu"
>> "samsung,exynos4210-tmu"
>> "samsung,exynos5250-tmu"
>> +"samsung,exynos5420-tmu"
>
> I would add a second compatible value here for TMU units that have
> misplaced TRIMINFO data, e.g. "samsung,exynos5420-tmu-broken-triminfo"
> and explicitly specify that second reg and clock-names entry is required
> for this compatible value.
Sure
>
>> "samsung,exynos5440-tmu"
>> - interrupt-parent : The phandle for the interrupt controller
>> - reg : Address range of the thermal registers. For soc's which has multiple
>> @@ -13,6 +14,16 @@
>> interrupt related then 2 set of register has to supplied. First set
>> belongs to each instance of TMU and second set belongs to second set
>> of common TMU registers.
>
> nit: A blank line here would be nice.
>
>> + NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
>> + channels 2, 3 and 4
>> +
>> + TRIMINFO at 0x1006c000 contains data for TMU channel 3
>> + TRIMINFO at 0x100a contains data for TMU channel 4
>> + TRIMINFO at 0x10068000 contains data for TMU channel 2
>> +
>> + The misplaced register address is passed through devicetree as the
>> + second base
>> +
>> - interrupts : Should contain interrupt for thermal system
>> - clocks : The main clock for TMU device
>> - clock-names : Thermal system clock name
>> @@ -43,6 +54,34 @@ Example 2):
>> clock-names = "tmu_apbif";
>> };
>>
>> +Example 3): (In case of Exynos5420)
>
> Maybe "in case of misplaced TRIMINFO register" would be better?
Sure
>
>> + /* tmu for CPU2 */
>> + tmu@10068000 {
>> + compatible = "samsung,exynos5420-tmu";
>> + reg = <0x10068000 0x100>, <0x1006c000 0x4>;
>> + interrupts = <0 184 0>;
>> + clocks = < 318>;
>> + clock-names = "tmu_apbif";
>> + };
>> +
>
> I believe that just a single example of a node for a TMU with misplaced
> TRIMINFO register will be enough.
right
>
>> + /* tmu for CPU3 */
>> + tmu@1006c000 {
>> + compatible = "samsung,exynos5420-tmu";
>> + reg = <0x1006c000 0x100>, <0x100a 0x4>;
>> + interrupts = <0 185 0>;
>> + clocks = < 318>;
>> + clock-names = "tmu_apbif";
>> + };
>> +
>> + /* tmu for GPU */
>> + tmu@100a {
>> +
Re: [PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio
On Friday 08 November 2013 12:15 PM, Prabhakar Lad wrote: > From: "Lad, Prabhakar" > > This patch fixes a check for offset in gpio_to_irq_unbanked() > and also assigns gpio_irq, gpio_unbanked of chips[0] to > appropriate values which is used in gpio_to_irq_unbanked() > function. > > Reported-by: Grygorii Strashko > Signed-off-by: Lad, Prabhakar You should note explicitly that this patch fixes broken unbanked IRQ support. You mostly just described what you are doing. I will fixup while committing. Thanks, Sekhar > --- > drivers/gpio/gpio-davinci.c |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c > index 8847adf..84be701 100644 > --- a/drivers/gpio/gpio-davinci.c > +++ b/drivers/gpio/gpio-davinci.c > @@ -327,7 +327,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip, > unsigned offset) >* NOTE: we assume for now that only irqs in the first gpio_chip >* can provide direct-mapped IRQs to AINTC (up to 32 GPIOs). >*/ > - if (offset < d->irq_base) > + if (offset < d->gpio_unbanked) > return d->gpio_irq + offset; > else > return -ENODEV; > @@ -419,6 +419,8 @@ static int davinci_gpio_irq_setup(struct platform_device > *pdev) > > /* pass "bank 0" GPIO IRQs to AINTC */ > chips[0].chip.to_irq = gpio_to_irq_unbanked; > + chips[0].gpio_irq = bank_irq; > + chips[0].gpio_unbanked = pdata->gpio_unbanked; > binten = BIT(0); > > /* AINTC handles mask/unmask; GPIO handles triggering */ > -- 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/2] DaVinci: GPIO: fixes
On Monday 11 November 2013 09:13 PM, Grygorii Strashko wrote: > Hi Sekhar, Prabhakar Lad > > On 11/08/2013 08:45 AM, Prabhakar Lad wrote:> From: "Lad, Prabhakar" > >> >> This patch series fixes gpio driver regestration >> and offset check for unbanked gpio. >> >> Lad, Prabhakar (2): >>gpio: davinci: Fix a check for unbanked gpio >>ARM: davinci: Fix number of resources passed to >> davinci_gpio_register() call > > I've verified both patches - looks ok. > Patch 1 - restores unbanked GPIO IRQs functionality > Patch 2 - allows to register GPIO Platform devices and boot without issues. > > Could we move forward with these patches? Prabhakar, both patches look good to me. Thanks for the fixes. Also Grygorii, have you actually verified that the unbanked IRQ support works? Only DM365 uses it. What do I add for you? Tested-by: or Acked-by: Thanks, Sekhar -- 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] cpufreq: cpufreq-cpu0: do not allow transitions with regulators suspended
Cc'ing Shawn as well.
Sorry for being really late.. I just forgot about it :(
On 24 October 2013 23:38, Nishanth Menon wrote:
> For platforms where regulators are used, regulator access tends to be
> disabled as part of the suspend path. In SMP systems such as OMAP,
> CPU1 is disabled as post suspend_noirq. This results in the following
> tail end sequence of actions:
> cpufreq_cpu_callback gets called with CPU_POST_DEAD
> __cpufreq_remove_dev_finish is invoked as a result
> __cpufreq_governor(policy, CPUFREQ_GOV_START) is
> triggered
>
> At this point, with ondemand governor, if the cpu entered suspend path
> at a lower OPP, this triggers a transition request. However, since
> irqs are disabled, typically, regulator control using I2C operations
> are not possible either, regulator operations will naturally fail
> (even though clk_set_rate might succeed depending on the platform).
>
> Unfortunately, cpufreq_driver->suspend|resume is too late as well, since
> they are invoked as part of syscore_ops (after CPU1 is hotplugged out).
>
> The proposal here is to use pm notifier suspend to disable any
> requests to target, as we may very well expect this to fail at a later
> suspend sequence.
Yes the problem looks real but there are issues with this patch.
- It doesn't solve your problem completely, because you returned -EBUSY,
your suspend operation failed and we resumed immediately.
- We can't make this solution true for everybody using cpu0 driver, it should
be platform specific.
- Its not a problem of cpu0 driver but all drivers. So, probably a better idea
would be not calling ->target() at all when drivers have marked them unusable
in suspend path..
But I think the problem can/should be solved some other way.. Looking closely,
we got to the problem because we called
__cpufreq_governor(policy, CPUFREQ_GOV_START)
at the first place. This happened because the policy structure had more than
one cpu to take care of and after stopping goveronr for CPU1 it has to start it
again for CPU0... But this is really not required as anyway we are going to
suspend.
Can you try attached patch? I will then repost it formally...
commit 2aecab9be85ceafdbab5f824eec5d1f81f3fa803
Author: Viresh Kumar
Date: Tue Nov 12 11:26:36 2013 +0530
cpufreq: don't start governor in suspend path
When we suspend our system, we remove all non-boot CPUs one by one. At this
point we actually STOP/START governor for each non-boot cpu, which
is a total
waste of time as we aren't going to use governor until the time we are back.
Also, this is causing problems for some platforms (like OMAP),
where governor
tries to change freq of core in suspend path which requires programming
regulators via I2C which isn't possible then.
So, to make it better for everybody don't start the governor again
in suspend
path.
Reported-by: Nishanth Menon
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02d534d..bec58cf 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1174,7 +1174,7 @@ static int __cpufreq_remove_dev_prepare(struct
device *dev,
return -EINVAL;
}
- if (has_target()) {
+ if (has_target() && (!frozen || policy->governor_enabled)) {
ret = __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
if (ret) {
pr_err("%s: Failed to stop governor\n", __func__);
@@ -1282,7 +1282,7 @@ static int __cpufreq_remove_dev_finish(struct device *dev,
if (!frozen)
cpufreq_policy_free(policy);
} else {
- if (has_target()) {
+ if (has_target() && !frozen) {
if ((ret = __cpufreq_governor(policy,
CPUFREQ_GOV_START)) ||
(ret =
__cpufreq_governor(policy, CPUFREQ_GOV_LIMITS))) {
pr_err("%s: Failed to start governor\n",
--
viresh
> Reported-by: J Keerthy
> Signed-off-by: Nishanth Menon
> ---
> based on: v3.12-rc6
> Tested on v3.12-rc6 vendor forked tree which supports suspend
> Platform: OMAP5uEVM
>
> Sample of the stack with i2c failure: http://pastebin.com/m5KxnB7a
> With i2c failure fixed: http://pastebin.com/8AfX4e7r
>
> I am open to alternative proposals if any - one option might be to
> introduce a similar behavior at cpufreq level as allowing cpufreq
> transitions in suspend path is probably not necessary.
>
> If folks think that respinning this patch such that there is no
> dependency on regulator to set is_suspended, it is fine with me as
> well.
>
> drivers/cpufreq/cpufreq-cpu0.c | 47
> +---
> 1 file changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c
Re: [PATCH 0/2] genirq: arm64: perf: support for percpu pmu interrupt
On Mon, Nov 11, 2013 at 4:14 PM, Will Deacon wrote: > On Sat, Nov 09, 2013 at 01:04:23AM +, Stephen Boyd wrote: >> On 11/06/13 04:07, Vinayak Kale wrote: >> > This patch series adds support to handle interrupt >> > registration/deregistration >> > in arm64 pmu driver when pmu interrupt type is percpu. >> > >> > Patches in this patch series were previously sent out as separate patches >> > [1]. >> > This patch series incorporates comments/fixes suggested for original >> > patches. >> > >> > [1] >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/205888.html >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/204414.html >> > >> > Vinayak Kale (2): >> > genirq: error reporting in request_percpu_irq() and >> > request_threaded_irq() >> > arm64: perf: add support for percpu pmu interrupt >> > >> > arch/arm64/kernel/perf_event.c | 109 >> > +--- >> > kernel/irq/manage.c| 12 +++-- >> > 2 files changed, 89 insertions(+), 32 deletions(-) >> > >> >> What ever happened to the approach here[1]? It doesn't look very nice to >> have to request the irq first as a per-cpu interrupt and then try as a >> non-percpu interrupt when genirq already knows if its per-cpu or not. >> >> [1] http://lkml.indiana.edu/hypermail/linux/kernel/1207.3/02955.html > > Hmm, I'd completely forgotten about that approach. Whilst it certainly looks > cleaner from a user perspective, I always get scared when I see > 'desc->status_use_accessors' since it tends to incur the wrath of tglx :) > > That said, I guess that should be fine in irqdesc.h (basically adding a new > accessor). Chris went missing after sending those initial patches, so > perhaps Vinayak could look at resurrecting those? > Okay, in next patch revision I will use that approach. -- 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] ath6kl: sdio: fix system panic when doing wifi stress test
When did the wifi iperf test, meet one following kernel panic:
command: iperf -c $TARGET_IP -i 5 -t 50 -w 1M
Unable to handle kernel paging request at virtual address 1a48
pgd = 80004000
[1a48] *pgd=
Internal error: Oops: 805 [#1] SMP ARM
Modules linked in: ath6kl_sdio ath6kl_core [last unloaded: ath6kl_core]
CPU: 0 PID: 1953 Comm: kworker/u4:0 Not tainted 3.10.9-1.0.0_alpha+dbf364b #1
Workqueue: ath6kl ath6kl_sdio_write_async_work [ath6kl_sdio]
task: dcc9a680 ti: dc9ae000 task.ti: dc9ae000
PC is at v7_dma_clean_range+0x20/0x38
LR is at dma_cache_maint_page+0x50/0x54
pc : [<8001a6f8>]lr : [<800170fc>]psr: 2093
sp : dc9afcf8 ip : 8001a748 fp : 0004
r10: r9 : 0001 r8 :
r7 : 0001 r6 : r5 : 80cb7000 r4 : 03f9a480
r3 : 001f r2 : 0020 r1 : 1a48 r0 : 1a48
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c53c7d Table: 6cc5004a DAC: 0015
Process kworker/u4:0 (pid: 1953, stack limit = 0xdc9ae238)
Stack: (0xdc9afcf8 to 0xdc9b)
fce0: 80c9b29c
fd00: 80017134 8001a748 dc302ac0 dc454a00 80c12ed8
fd20: dc115410 80017238 dc454a10 0001 80017588 0001
fd40: dc302ac0 dc9afe38 dc9afe68 0004 80c12ed8 dc454a00
fd60: 0004 80436f88 0600 000c 80c113c4
fd80: 80c9b29c 0001 0004 dc115470 6013 dc302ac0 dc46e000 dc302800
fda0: dc9afe10 dc302b78 6013 dc302ac0 dc46e000 0035 dc46e5b0 80438c90
fdc0: dc9afe10 dc302800 dc302800 dc9afe68 dc9afe38 80424cb4 0005 dc9afe10
fde0: dc9afe20 80424de8 dc9afe10 dc302800 dc46e910 80424e90 dc473c00 dc454f00
fe00: 01b5 7f619d64 dcc7c830 dc9afe38 dc9afe68
fe20: dc9afe28 dc9afe28 80424d80 0035 9cac0034
fe40: 01b5
fe60: dc9afe68 dc9afe10 3b9aca00 0080 0034 0100
fe80: dc9afe10 0004 dc454a00 dc46e010 dc46e96c
fea0: dc46e000 dc46e964 00200200 00100100 dc46e910 7f619ec0 0600 80c0e770
fec0: dc15a900 dcc7c838 dc46e954 8042d434 dcc44680 dc46e954 dc004400
fee0: dc454500 dc9ae038 dc004400 8003c450 dcc44680 dc004414
ff00: dc46e954 dc454500 0001 dcc44680 dc004414 dcc44698 dc9ae000 dc9ae030
ff20: 0001 dc9ae000 dc004400 8003d158 8003d020 80c53941
ff40: dc9aff64 dcb71ea0 dcc44680 8003d020
ff60: 80042480 00f8 dcc44680
ff80: dc9aff80 dc9aff80 dc9aff90 dc9aff90 dc9affac dcb71ea0
ffa0: 800423cc 8000e018
ffc0:
ffe0: 0013
[<8001a6f8>] (v7_dma_clean_range+0x20/0x38) from [<800170fc>]
(dma_cache_maint_page+0x50/0x54)
[<800170fc>] (dma_cache_maint_page+0x50/0x54) from [<80017134>]
(__dma_page_cpu_to_dev+0x34/0x9c)
[<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c) from [<80017238>]
(arm_dma_map_page+0x64/0x68)
[<80017238>] (arm_dma_map_page+0x64/0x68) from [<80017588>]
(arm_dma_map_sg+0x7c/0xf4)
[<80017588>] (arm_dma_map_sg+0x7c/0xf4) from [<80436f88>]
(sdhci_send_command+0x894/0xe00)
[<80436f88>] (sdhci_send_command+0x894/0xe00) from [<80438c90>]
(sdhci_request+0xc0/0x1ec)
[<80438c90>] (sdhci_request+0xc0/0x1ec) from [<80424cb4>]
(mmc_start_request+0xb8/0xd4)
[<80424cb4>] (mmc_start_request+0xb8/0xd4) from [<80424de8>]
(__mmc_start_req+0x60/0x84)
[<80424de8>] (__mmc_start_req+0x60/0x84) from [<80424e90>]
(mmc_wait_for_req+0x10/0x20)
[<80424e90>] (mmc_wait_for_req+0x10/0x20) from [<7f619d64>]
(ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio])
[<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) from
[<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio])
[<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) from
[<8003c450>] (process_one_work+0x10c/0x370)
[<8003c450>] (process_one_work+0x10c/0x370) from [<8003d158>]
(worker_thread+0x138/0x3fc)
[<8003d158>] (worker_thread+0x138/0x3fc) from [<80042480>] (kthread+0xb4/0xb8)
[<80042480>] (kthread+0xb4/0xb8) from [<8000e018>] (ret_from_fork+0x14/0x3c)
Code: e1a02312 e2423001 e1c3 f57ff04f (ee070f3a)
---[ end trace 0c038f0b8e0b67a3 ]---
Kernel panic - not syncing: Fatal exception
The kernel panic is caused by the sg_buf is not set correctly with the
following code when compiled with Yocto GCC 4.8.1:
drivers/net/wireless/ath/ath6kl/hif.h:
struct hif_scatter_req {
struct list_head list;
/* address for the read/write operation */
u32 addr;
...
/* bounce buffer for upper layers to copy to/from */
u8 *virt_dma_buf;
linux-next: Tree for Nov 12
Hi all, Please do *not* add any v3.14 material to linux-next until after v3.13-rc1 is released. Changes since 2013: The input tree gained a conflict against Linus' tree. The random tree gained a conflict against the net-next tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 210 trees (counting Linus' and 29 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (edae583a6d4d Merge tag 'arc-v3.13-rc1-part1' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc) Merging fixes/master (fa8218def1b1 Merge tag 'regmap-v3.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (737d5b980be8 ARC: [plat-arcfpga] defconfig update) Merging arm-current/fixes (6ecf830e5029 ARM: 7880/1: Clear the IT state independent of the Thumb-2 mode) CONFLICT (content): Merge conflict in arch/arm/mach-tegra/Kconfig Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated IRQF_DISABLED) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (8b5ede69d24d powerpc/irq: Don't switch to irq stack from softirq stack) Merging sparc/master (6d15ee492809 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging net/master (be408cd3e1fe Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (be408cd3e1fe Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging sound-current/for-linus (679605c768e8 ALSA: hda - hdmi: Fix wrong baseline length in ATI/AMD generated ELD) Merging pci-current/for-linus (67d470e0e171 Revert "x86/PCI: MMCONFIG: Check earlier for MMCONFIG region at address zero") Merging wireless/master (8e3ffa471091 prism54: set netdev type to "wlan") CONFLICT (content): Merge conflict in include/linux/netdevice.h Merging driver-core.current/driver-core-linus (31d141e3a666 Linux 3.12-rc6) Merging tty.current/tty-linus (6e757ad2c92c tty/serial: at91: fix uart/usart selection for older products) Merging usb.current/usb-linus (e1466ad5b1ae USB: serial: ftdi_sio: add id for Z3X Box device) Merging staging.current/staging-linus (31d141e3a666 Linux 3.12-rc6) Merging char-misc.current/char-misc-linus (31d141e3a666 Linux 3.12-rc6) Merging input-current/for-linus (5beea882e641 Input: ALPS - add support for model found on Dell XT2) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (f262f0f5cad0 crypto: s390 - Fix aes-cbc IV corruption) Merging ide/master (64110c16e012 ide: sgiioc4: Staticize ioc4_ide_attach_one()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (1931ee143b0a Revert "drivers: of: add initialization code for dma reserved memory") Merging rr-fixes/fixes (f6537f2f0eba scripts/kallsyms: filter symbols not in kernel address space) Merging mfd-f
Re: [PATCH] powerpc: add explicit OF includes for ppc4xx
On Sun, Nov 10, 2013 at 11:35:43PM -0600, Rob Herring wrote: > From: Rob Herring > > Commit b5b4bb3f6a11f9 (of: only include prom.h on sparc) removed implicit > includes of of_*.h headers by powerpc's prom.h. Some PPC4xx components > were missed in initial clean-up patch, so add the necessary includes > to fix ppc4xx builds. > > Signed-off-by: Rob Herring > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Tejun Heo > Cc: Matt Mackall > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Vinod Koul > Cc: Dan Williams > Cc: linuxppc-...@lists.ozlabs.org > Cc: linux-...@vger.kernel.org > Cc: linux-cry...@vger.kernel.org > --- > I intend to send this patch to Linus with the rest of the DT clean-up > series. > > Rob > > arch/powerpc/sysdev/ppc4xx_ocm.c | 1 + > arch/powerpc/sysdev/xilinx_intc.c| 1 + > drivers/ata/sata_dwc_460ex.c | 2 ++ > drivers/char/hw_random/ppc4xx-rng.c | 1 + > drivers/crypto/amcc/crypto4xx_core.c | 3 +++ > drivers/dma/ppc4xx/adma.c| 2 ++ For this: Acked-by Vinod Koul -- ~Vinod > 6 files changed, 10 insertions(+) > > diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c > b/arch/powerpc/sysdev/ppc4xx_ocm.c > index 1b15f93..b7c4345 100644 > --- a/arch/powerpc/sysdev/ppc4xx_ocm.c > +++ b/arch/powerpc/sysdev/ppc4xx_ocm.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/arch/powerpc/sysdev/xilinx_intc.c > b/arch/powerpc/sysdev/xilinx_intc.c > index f4fdc94..83f943a 100644 > --- a/arch/powerpc/sysdev/xilinx_intc.c > +++ b/arch/powerpc/sysdev/xilinx_intc.c > @@ -24,6 +24,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c > index 2e39173..523524b 100644 > --- a/drivers/ata/sata_dwc_460ex.c > +++ b/drivers/ata/sata_dwc_460ex.c > @@ -31,6 +31,8 @@ > #include > #include > #include > +#include > +#include > #include > #include > #include > diff --git a/drivers/char/hw_random/ppc4xx-rng.c > b/drivers/char/hw_random/ppc4xx-rng.c > index 732c330..521f76b 100644 > --- a/drivers/char/hw_random/ppc4xx-rng.c > +++ b/drivers/char/hw_random/ppc4xx-rng.c > @@ -13,6 +13,7 @@ > #include > #include > #include > +#include > #include > #include > > diff --git a/drivers/crypto/amcc/crypto4xx_core.c > b/drivers/crypto/amcc/crypto4xx_core.c > index f88e3d8..efaf630 100644 > --- a/drivers/crypto/amcc/crypto4xx_core.c > +++ b/drivers/crypto/amcc/crypto4xx_core.c > @@ -27,6 +27,9 @@ > #include > #include > #include > +#include > +#include > +#include > #include > #include > #include > diff --git a/drivers/dma/ppc4xx/adma.c b/drivers/dma/ppc4xx/adma.c > index 370ff82..e24b5ef 100644 > --- a/drivers/dma/ppc4xx/adma.c > +++ b/drivers/dma/ppc4xx/adma.c > @@ -42,6 +42,8 @@ > #include > #include > #include > +#include > +#include > #include > #include > #include > -- > 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 V3 7/7] ARM: DRA: Enable Crossbar IP support for DRA7XX
Hi Rajendra, On Tuesday 12 November 2013 11:11 AM, Rajendra Nayak wrote: > On Tuesday 05 November 2013 06:44 PM, Sricharan R wrote: >> Enable the crossbar IP support for DRA7xx soc. >> >> Cc: Santosh Shilimkar >> Cc: Rajendra Nayak >> Cc: Tony Lindgren >> Signed-off-by: Sricharan R >> --- >> arch/arm/mach-omap2/Kconfig|1 + >> arch/arm/mach-omap2/omap4-common.c |4 >> 2 files changed, 5 insertions(+) >> >> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig >> index b5fb5f7..2086c65 100644 >> --- a/arch/arm/mach-omap2/Kconfig >> +++ b/arch/arm/mach-omap2/Kconfig >> @@ -141,6 +141,7 @@ config SOC_DRA7XX >> select ARM_GIC >> select HAVE_SMP >> select COMMON_CLK >> +select IRQ_CROSSBAR >> >> comment "OMAP Core Type" >> depends on ARCH_OMAP2 >> diff --git a/arch/arm/mach-omap2/omap4-common.c >> b/arch/arm/mach-omap2/omap4-common.c >> index 5791143..274cbfa 100644 >> --- a/arch/arm/mach-omap2/omap4-common.c >> +++ b/arch/arm/mach-omap2/omap4-common.c >> @@ -22,6 +22,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> >> @@ -282,9 +283,12 @@ void __init omap_gic_of_init(void) >> >> skip_errata_init: >> omap_wakeupgen_init(); >> +if (soc_is_dra7xx()) >> +crossbar_init(); > Its good if this is called irqcrossbar_init() to avoid confusion > with the dma crossbar which also exists in dra7 devices. > Ya makes sense. Will change this. Regards, Sricharan -- 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/3] rcar-hpbdma: fixup patches for double plane
On Mon, Oct 28, 2013 at 11:51:28PM -0700, Kuninori Morimoto wrote: > > Hi Vinod > Cc: Simon, Max > > These patches fixup R-Car HBPDMA driver > for double plane. > > I tested these patches on my R-Car sound driver in local environment. > It doesn't work without these patches. Applied, thanks -- ~Vinod > > Kuninori Morimoto (3): > rcar-hpbdma: add max transfer size > rcar-hpbdma: initialise plane information when halted > rcar-hpbdma: fixup channel busy check for double plane > > drivers/dma/sh/rcar-hpbdma.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > > Best regards > --- > Kuninori Morimoto -- -- 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 01/28] dmaengine: use DMA_COMPLETE for dma completion status
On Mon, Nov 11, 2013 at 09:11:18PM -0800, Olof Johansson wrote: > On Mon, Nov 11, 2013 at 8:00 PM, Vinod Koul wrote: > > On Mon, Nov 11, 2013 at 11:13:39AM -0800, Olof Johansson wrote: > >> On Wed, Oct 30, 2013 at 06:33:25PM +0530, Vinod Koul wrote: > >> > On Tue, Oct 29, 2013 at 09:47:55AM -0700, Olof Johansson wrote: > >> > > This patch broke some TI platforms (using edma) due to namespace > >> > > conflicts. The error is: > >> > > > >> > > ../../include/linux/dmaengine.h:54:2: error: expected identifier > >> > > before numeric constant (for DMA_COMPLETE) > >> > > > >> > > .. it's because they define DMA_COMPLETE in > >> > > include/platform_data/edma.h. > >> > > > >> > > The edma driver seems to overall lack prefixes and thus pollutes > >> > > global namespaces, so it should be fixed up. > >> > Yup this needs some work. > >> > > >> > I fixed up the error with below, can you pls verify. Pls note this is > >> > compile > >> > tested only! > >> > > >> > -><8--- > >> > > >> > From: Vinod Koul > >> > Date: Wed, 30 Oct 2013 18:22:30 +0530 > >> > Subject: [PATCH] dmanengine: fix edma driver to not define DMA_COMPLETE > >> > > >> > edma header defines DMA_COMPLETE, this causes issues as commit > >> > adfedd9a32e4 move > >> > DMA_SUCCESS to DMA_COMPLETE. edma should properly namespace its defines > >> > and > >> > needs a future fix > >> > > >> > Reported-by: Olof Johansson > >> > Signed-off-by: Vinod Koul > >> > >> Thanks, I've applied this to fixes together with the follow-up from > >> Sebastian. Cc:ing Mark since it touches drivers/soc. > > I had applied this a while back and pushed only thing remaining was > > Sebastian's > > patch. Since this is dependent on the series I am sending to Linus in a > > day ro > > two, would prefer things to go thru this tree only. > > > > Let me know if you are okay and will apply Sebastian fix on my next > > Ah, go ahead -- I thought it hadn't been picked up yet since there > were still failures (i.e. due to Sebastian's fixes). Feel free to add > my Acked-by where you still can. :-) Sure, applied this one > I have a couple of small fixes to take care of warnings with LPAE > configs that I hope to get out tonight or tomorrow morning, it'd be > nice to see them go in too (just printk format warning fixes). Sure, I will hold off for few more days for more coverage. Also if you/Sebastian can check more if anything still breaks and we fix it before sending would be good too -- ~Vinod -- 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 7/7] ARM: DRA: Enable Crossbar IP support for DRA7XX
On Tuesday 05 November 2013 06:44 PM, Sricharan R wrote:
> Enable the crossbar IP support for DRA7xx soc.
>
> Cc: Santosh Shilimkar
> Cc: Rajendra Nayak
> Cc: Tony Lindgren
> Signed-off-by: Sricharan R
> ---
> arch/arm/mach-omap2/Kconfig|1 +
> arch/arm/mach-omap2/omap4-common.c |4
> 2 files changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index b5fb5f7..2086c65 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -141,6 +141,7 @@ config SOC_DRA7XX
> select ARM_GIC
> select HAVE_SMP
> select COMMON_CLK
> + select IRQ_CROSSBAR
>
> comment "OMAP Core Type"
> depends on ARCH_OMAP2
> diff --git a/arch/arm/mach-omap2/omap4-common.c
> b/arch/arm/mach-omap2/omap4-common.c
> index 5791143..274cbfa 100644
> --- a/arch/arm/mach-omap2/omap4-common.c
> +++ b/arch/arm/mach-omap2/omap4-common.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -282,9 +283,12 @@ void __init omap_gic_of_init(void)
>
> skip_errata_init:
> omap_wakeupgen_init();
> + if (soc_is_dra7xx())
> + crossbar_init();
Its good if this is called irqcrossbar_init() to avoid confusion
with the dma crossbar which also exists in dra7 devices.
> irqchip_init();
> }
>
> +
> #if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
> static int omap4_twl6030_hsmmc_late_init(struct device *dev)
> {
>
--
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: [PATCHv2.1] net: wireless: iwlwifi: remove minor dead code
On 11/12/2013 02:01 AM, Michal Nazarewicz wrote: > inta is checked to be zero in a IRQ_NONE branch so afterwards it > cannot be zero as it is never modified. > > Signed-off-by: Michal Nazarewicz > --- > drivers/net/wireless/iwlwifi/pcie/rx.c | 24 +--- > 1 file changed, 9 insertions(+), 15 deletions(-) > > On Mon, Nov 11 2013, Johannes Berg wrote: >> no signed-off-by > > Sorry, fixed. Interestingly, I did not forget about it in my first patch. > no worries - I picked it up in our internal tree. 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/
[f2fs-dev] [PATCH 2/2] f2fs: read contiguous sit entry pages by merging for mount performance
Previously we read sit entries page one by one, this method lost the chance of
reading contiguous page together.
So we read pages as contiguous as possible for better mount performance.
Signed-off-by: Chao Yu
---
fs/f2fs/f2fs.h|2 ++
fs/f2fs/segment.c | 65 ++---
fs/f2fs/segment.h |2 ++
3 files changed, 66 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 0afdcec..bfe9d87 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1113,6 +1113,8 @@ struct page *find_data_page(struct inode *, pgoff_t,
bool);
struct page *get_lock_data_page(struct inode *, pgoff_t);
struct page *get_new_data_page(struct inode *, struct page *, pgoff_t, bool);
int f2fs_readpage(struct f2fs_sb_info *, struct page *, block_t, int);
+void f2fs_submit_read_bio(struct f2fs_sb_info *, int);
+void submit_read_page(struct f2fs_sb_info *, struct page *, block_t, int);
int do_write_data_page(struct page *);
/*
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 86dc289..414c351 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1474,19 +1474,72 @@ static int build_curseg(struct f2fs_sb_info *sbi)
return restore_curseg_summaries(sbi);
}
+static int ra_sit_pages(struct f2fs_sb_info *sbi, int start,
+ int nrpages, bool *is_order)
+{
+ struct address_space *mapping = sbi->meta_inode->i_mapping;
+ struct sit_info *sit_i = SIT_I(sbi);
+ struct page *page;
+ block_t blk_addr;
+ int blkno, readcnt = 0;
+ int sit_blk_cnt = SIT_BLK_CNT(sbi);
+
+ for (blkno = start; blkno < start + nrpages; blkno++) {
+
+ if (blkno >= sit_blk_cnt)
+ goto out;
+ if ((!f2fs_test_bit(blkno, sit_i->sit_bitmap) ^ !*is_order)) {
+ *is_order = !*is_order;
+ goto out;
+ }
+
+ blk_addr = sit_i->sit_base_addr + blkno;
+ if (*is_order)
+ blk_addr += sit_i->sit_blocks;
+repeat:
+ page = grab_cache_page(mapping, blk_addr);
+ if (!page) {
+ cond_resched();
+ goto repeat;
+ }
+ if (PageUptodate(page)) {
+ f2fs_put_page(page, 1);
+ readcnt++;
+ goto out;
+ }
+
+ submit_read_page(sbi, page, blk_addr, READ_SYNC);
+
+ page_cache_release(page);
+ readcnt++;
+ }
+out:
+ f2fs_submit_read_bio(sbi, READ_SYNC);
+ return readcnt;
+}
+
static void build_sit_entries(struct f2fs_sb_info *sbi)
{
struct sit_info *sit_i = SIT_I(sbi);
struct curseg_info *curseg = CURSEG_I(sbi, CURSEG_COLD_DATA);
struct f2fs_summary_block *sum = curseg->sum_blk;
- unsigned int start;
+ bool is_order = f2fs_test_bit(0, sit_i->sit_bitmap) ? true : false;
+ int sit_blk_cnt = SIT_BLK_CNT(sbi);
+ int bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+ unsigned int i, start, end;
+ unsigned int readed, start_blk = 0;
- for (start = 0; start < TOTAL_SEGS(sbi); start++) {
+next:
+ readed = ra_sit_pages(sbi, start_blk, bio_blocks, _order);
+
+ start = start_blk * sit_i->sents_per_block;
+ end = (start_blk + readed) * sit_i->sents_per_block;
+
+ for (; start < end && start < TOTAL_SEGS(sbi); start++) {
struct seg_entry *se = _i->sentries[start];
struct f2fs_sit_block *sit_blk;
struct f2fs_sit_entry sit;
struct page *page;
- int i;
mutex_lock(>curseg_mutex);
for (i = 0; i < sits_in_cursum(sum); i++) {
@@ -1497,6 +1550,7 @@ static void build_sit_entries(struct f2fs_sb_info *sbi)
}
}
mutex_unlock(>curseg_mutex);
+
page = get_current_sit_page(sbi, start);
sit_blk = (struct f2fs_sit_block *)page_address(page);
sit = sit_blk->entries[SIT_ENTRY_OFFSET(sit_i, start)];
@@ -1509,6 +1563,11 @@ got_it:
e->valid_blocks += se->valid_blocks;
}
}
+
+ start_blk += readed;
+ if (start_blk >= sit_blk_cnt)
+ return;
+ goto next;
}
static void init_free_segmap(struct f2fs_sb_info *sbi)
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 269f690..ad5b9f1 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -83,6 +83,8 @@
(segno / SIT_ENTRY_PER_BLOCK)
#defineSTART_SEGNO(sit_i, segno) \
(SIT_BLOCK_OFFSET(sit_i, segno) * SIT_ENTRY_PER_BLOCK)
+#define SIT_BLK_CNT(sbi) \
+ ((TOTAL_SEGS(sbi) + SIT_ENTRY_PER_BLOCK - 1) / SIT_ENTRY_PER_BLOCK)
#define f2fs_bitmap_size(nr) \
[f2fs-dev] [PATCH 1/2] f2fs: add a new function to support for merging contiguous read
For better read performance, we add a new function to support for merging
contiguous read as the one for write.
Signed-off-by: Chao Yu
---
fs/f2fs/data.c | 45 +
fs/f2fs/f2fs.h |2 ++
2 files changed, 47 insertions(+)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index aa3438c..f30060b 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -404,6 +404,51 @@ int f2fs_readpage(struct f2fs_sb_info *sbi, struct page
*page,
return 0;
}
+void f2fs_submit_read_bio(struct f2fs_sb_info *sbi, int rw)
+{
+ down_read(>bio_sem);
+ if (sbi->read_bio) {
+ submit_bio(rw, sbi->read_bio);
+ sbi->read_bio = NULL;
+ }
+ up_read(>bio_sem);
+}
+
+void submit_read_page(struct f2fs_sb_info *sbi, struct page *page,
+ block_t blk_addr, int rw)
+{
+ struct block_device *bdev = sbi->sb->s_bdev;
+ int bio_blocks;
+
+ verify_block_addr(sbi, blk_addr);
+
+ down_read(>bio_sem);
+
+ if (sbi->read_bio && sbi->last_read_block != blk_addr - 1) {
+ submit_bio(rw, sbi->read_bio);
+ sbi->read_bio = NULL;
+ }
+
+alloc_new:
+ if (sbi->read_bio == NULL) {
+ bio_blocks = MAX_BIO_BLOCKS(max_hw_blocks(sbi));
+ sbi->read_bio = f2fs_bio_alloc(bdev, bio_blocks);
+ sbi->read_bio->bi_sector = SECTOR_FROM_BLOCK(sbi, blk_addr);
+ sbi->read_bio->bi_end_io = read_end_io;
+ }
+
+ if (bio_add_page(sbi->read_bio, page, PAGE_CACHE_SIZE, 0) <
+ PAGE_CACHE_SIZE) {
+ submit_bio(rw, sbi->read_bio);
+ sbi->read_bio = NULL;
+ goto alloc_new;
+ }
+
+ sbi->last_read_block = blk_addr;
+
+ up_read(>bio_sem);
+}
+
/*
* This function should be used by the data read flow only where it
* does not check the "create" flag that indicates block allocation.
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 89dc750..0afdcec 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -359,6 +359,8 @@ struct f2fs_sb_info {
/* for segment-related operations */
struct f2fs_sm_info *sm_info; /* segment manager */
+ struct bio *read_bio; /* read bios to merge */
+ sector_t last_read_block; /* last read block number */
struct bio *bio[NR_PAGE_TYPE]; /* bios to merge */
sector_t last_block_in_bio[NR_PAGE_TYPE]; /* last block number */
struct rw_semaphore bio_sem;/* IO semaphore */
--
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 01/28] dmaengine: use DMA_COMPLETE for dma completion status
On Mon, Nov 11, 2013 at 8:00 PM, Vinod Koul wrote: > On Mon, Nov 11, 2013 at 11:13:39AM -0800, Olof Johansson wrote: >> On Wed, Oct 30, 2013 at 06:33:25PM +0530, Vinod Koul wrote: >> > On Tue, Oct 29, 2013 at 09:47:55AM -0700, Olof Johansson wrote: >> > > This patch broke some TI platforms (using edma) due to namespace >> > > conflicts. The error is: >> > > >> > > ../../include/linux/dmaengine.h:54:2: error: expected identifier >> > > before numeric constant (for DMA_COMPLETE) >> > > >> > > .. it's because they define DMA_COMPLETE in include/platform_data/edma.h. >> > > >> > > The edma driver seems to overall lack prefixes and thus pollutes >> > > global namespaces, so it should be fixed up. >> > Yup this needs some work. >> > >> > I fixed up the error with below, can you pls verify. Pls note this is >> > compile >> > tested only! >> > >> > -><8--- >> > >> > From: Vinod Koul >> > Date: Wed, 30 Oct 2013 18:22:30 +0530 >> > Subject: [PATCH] dmanengine: fix edma driver to not define DMA_COMPLETE >> > >> > edma header defines DMA_COMPLETE, this causes issues as commit >> > adfedd9a32e4 move >> > DMA_SUCCESS to DMA_COMPLETE. edma should properly namespace its defines and >> > needs a future fix >> > >> > Reported-by: Olof Johansson >> > Signed-off-by: Vinod Koul >> >> Thanks, I've applied this to fixes together with the follow-up from >> Sebastian. Cc:ing Mark since it touches drivers/soc. > I had applied this a while back and pushed only thing remaining was > Sebastian's > patch. Since this is dependent on the series I am sending to Linus in a day > ro > two, would prefer things to go thru this tree only. > > Let me know if you are okay and will apply Sebastian fix on my next Ah, go ahead -- I thought it hadn't been picked up yet since there were still failures (i.e. due to Sebastian's fixes). Feel free to add my Acked-by where you still can. :-) I have a couple of small fixes to take care of warnings with LPAE configs that I hope to get out tonight or tomorrow morning, it'd be nice to see them go in too (just printk format warning fixes). -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/
Re: [PATCH 01/28] dmaengine: use DMA_COMPLETE for dma completion status
On Mon, Nov 11, 2013 at 11:13:39AM -0800, Olof Johansson wrote: > On Wed, Oct 30, 2013 at 06:33:25PM +0530, Vinod Koul wrote: > > On Tue, Oct 29, 2013 at 09:47:55AM -0700, Olof Johansson wrote: > > > This patch broke some TI platforms (using edma) due to namespace > > > conflicts. The error is: > > > > > > ../../include/linux/dmaengine.h:54:2: error: expected identifier > > > before numeric constant (for DMA_COMPLETE) > > > > > > .. it's because they define DMA_COMPLETE in include/platform_data/edma.h. > > > > > > The edma driver seems to overall lack prefixes and thus pollutes > > > global namespaces, so it should be fixed up. > > Yup this needs some work. > > > > I fixed up the error with below, can you pls verify. Pls note this is > > compile > > tested only! > > > > -><8--- > > > > From: Vinod Koul > > Date: Wed, 30 Oct 2013 18:22:30 +0530 > > Subject: [PATCH] dmanengine: fix edma driver to not define DMA_COMPLETE > > > > edma header defines DMA_COMPLETE, this causes issues as commit adfedd9a32e4 > > move > > DMA_SUCCESS to DMA_COMPLETE. edma should properly namespace its defines and > > needs a future fix > > > > Reported-by: Olof Johansson > > Signed-off-by: Vinod Koul > > Thanks, I've applied this to fixes together with the follow-up from > Sebastian. Cc:ing Mark since it touches drivers/soc. I had applied this a while back and pushed only thing remaining was Sebastian's patch. Since this is dependent on the series I am sending to Linus in a day ro two, would prefer things to go thru this tree only. Let me know if you are okay and will apply Sebastian fix on my next -- ~Vinod -- 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/
linux-next: manual merge of the random tree with the net-next tree
Hi Ted,
Today's linux-next merge of the random tree got a conflict in
drivers/char/random.c between commit 0244ad004a54 ("random32: add
prandom_reseed_late() and call when nonblocking pool becomes
initialized") from the net-next tree and commit 301f0595c0e7 ("random:
printk notifications for urandom pool initialization") from the random
tree.
I fixed it up (probably not properly - see below) and can carry the fix
as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/char/random.c
index 4fe5609eeb72,cdf4cfb2da4d..
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@@ -255,8 -255,12 +255,9 @@@
#include
#include
#include
+#include
+ #include
-#ifdef CONFIG_GENERIC_HARDIRQS
-# include
-#endif
-
#include
#include
#include
@@@ -601,12 -654,14 +651,16 @@@ retry
if (cmpxchg(>entropy_count, orig, entropy_count) != orig)
goto retry;
+ r->entropy_total += nbits;
if (!r->initialized && nbits > 0) {
- r->entropy_total += nbits;
if (r->entropy_total > 128) {
+ if (r == _pool)
+ pr_notice("random: %s pool is initialized\n",
+ r->name);
r->initialized = 1;
+ if (r == _pool)
+ prandom_reseed_late();
+ r->entropy_total = 0;
}
}
pgpIqA9GW5QB4.pgp
Description: PGP signature
Re: Linux kernel API about sector count
On Tue, 2013-11-12 at 10:52 +0800, 韩磊 wrote: > I need a API in linux kernel about the disk's total count of > sector,not the sector size. > thank you! Have you even tried searching through the code? Take a look at how fdisk or blockdev or any other tool that deals with devices get the total sectors, ie: blockdev --getsize /dev/sda1 Then follow the path for such ioctl in the in the kernel source. > > > 2013/11/11 韩磊 : > > Thank you! I need disk's total count of sector,not the sector size. > > > > 2013/11/11 Mihai Donțu : > >> On Mon, 11 Nov 2013 20:31:14 +0800 韩磊 wrote: > >>> Can you tell me the API about the count of sector in linux kernel? > >>> > >>> which .h file and function? > >>> > >> > >> Looking at fdisk (util-linux) there are several ioctls: > >> * HDIO_GETGEO (linux/hdreg.h) > >> * BLKGETSIZE64 (linux/fs.h), sector size is assumed 512 > >> > >> The HDIO interface *seems* to be legacy: > >> http://www.mjmwired.net/kernel/Documentation/ioctl/hdio.txt > >> > >> Also see: > >> https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/fdisks/fdisk.c > >> > >> I hope this helps a bit. > >> > >> -- > >> Mihai Donțu > -- > 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/ -- 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 3/8] dma: mmp_tdma: use gen_pool_dma_alloc() to allocate descriptor
On Fri, Nov 01, 2013 at 07:48:16PM +0800, Nicolin Chen wrote: > Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Acked-by: Vinod Koul -- ~Vinod -- 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] dma: edma: Add support for Cyclic DMA
On Thu, Oct 31, 2013 at 04:31:23PM -0500, Joel Fernandes wrote: > Using the PaRAM configuration function that we split for reuse by the > different DMA types, we implement Cyclic DMA support. > For the cyclic case, we pass different configuration parameters to this > function, and handle all the Cyclic-specific functionality separately. > > Callbacks to the DMA users are handled using vchan_cyclic_callback in > the virt-dma layer. Linking is handled the same way as the slave SG case > except for the last slot where we link it back to the first one in a > cyclic fashion. > > For continuity, we check for cases where no.of periods is great than the > MAX number of slots the driver can allocate for a particular descriptor > and error out on such cases. Applied, thanks ~Vinod -- 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 1/2] ARC: Add perf support for ARC700 cores
On 11/11/2013 09:57 PM, Peter Zijlstra wrote: > On Thu, Nov 07, 2013 at 02:55:11PM +0100, Mischa Jonker wrote: >> This adds basic perf support for ARC700 cores. Most PERF_COUNT_HW* events >> are supported now. > I don't see anything particularly weird, but then I don't know/have the > hardware so I suppose you know what you're doing :-) > > Acked-by: Peter Zijlstra Thanks Peter. This is now queued for next batch for arc 3.13-rc1 changes since we've been using this internally for quite some time now. -Vineet -- 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 01/14] sched: add sched_class->task_dead.
On Thu, Nov 7, 2013 at 5:43 AM, Juri Lelli wrote:
> From: Dario Faggioli
>
> Add a new function to the scheduling class interface. It is called
> at the end of a context switch, if the prev task is in TASK_DEAD state.
>
> It might be useful for the scheduling classes that want to be notified
> when one of their task dies, e.g. to perform some cleanup actions.
We could also usefully use this within SCHED_FAIR to remove a task's
load contribution when it completes.
>
> Signed-off-by: Dario Faggioli
> Signed-off-by: Juri Lelli
> ---
> kernel/sched/core.c |3 +++
> kernel/sched/sched.h |1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 5ac63c9..850a02c 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1890,6 +1890,9 @@ static void finish_task_switch(struct rq *rq, struct
> task_struct *prev)
> if (mm)
> mmdrop(mm);
> if (unlikely(prev_state == TASK_DEAD)) {
> + if (prev->sched_class->task_dead)
> + prev->sched_class->task_dead(prev);
> +
> /*
> * Remove function-return probe instances associated with this
> * task and put them back on the free list.
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index b3c5653..64eda5c 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -992,6 +992,7 @@ struct sched_class {
> void (*set_curr_task) (struct rq *rq);
> void (*task_tick) (struct rq *rq, struct task_struct *p, int queued);
> void (*task_fork) (struct task_struct *p);
> + void (*task_dead) (struct task_struct *p);
>
> void (*switched_from) (struct rq *this_rq, struct task_struct *task);
> void (*switched_to) (struct rq *this_rq, struct task_struct *task);
Reviewed-by: Paul Turner
> --
> 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/
--
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: [tip:x86/asm] x86, bitops: Change bitops to be native operand size
On Tue, 2013-11-12 at 12:15 +0900, Linus Torvalds wrote: > Talking about "ideal implementation" is also singularly stupid. I just want the various arch implementations to match the docs. I know that's stupid. Maybe if you really don't want to discuss things, you should fix the documentation. Documentation/atomic_ops.txt -- 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 3/3] x86, boot: Change the BIOS corruption checker to scan 640K
* H. Peter Anvin wrote: > From: "H. Peter Anvin" > > Change the BIOS corruption checker to scan 640K if enabled. This is > the normal amount that we otherwise would reserve with the new default > settings; change the Kconfig help message to indicate that this is now > intended as a diagnostic tool when one is considering enabling any > chunk of low memory. > > Signed-off-by: H. Peter Anvin > Cc: Olof Johansson > Link: http://lkml.kernel.org/r/528168cb.7070...@linux.intel.com > --- > arch/x86/Kconfig| 25 +++-- > arch/x86/kernel/check.c | 10 +- > 2 files changed, 16 insertions(+), 19 deletions(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 7631122..554aedd 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1384,24 +1384,21 @@ config HIGHPTE > config X86_CHECK_BIOS_CORRUPTION > bool "Check for low memory corruption" > ---help--- > + Periodically check for memory corruption in low memory, > + which is suspected to be caused by BIOS. Even when enabled > + in the configuration, it is disabled at runtime. Enable it > + by setting "memory_corruption_check=1" on the kernel command > + line. By default it reserves and scans the low 640K of > + memory every 60 seconds; see the > + memory_corruption_check_size and > memory_corruption_check_period parameters in > Documentation/kernel-parameters.txt to adjust this. I agree with your patches so far, and I'd suggest we go even further: I'd say the config option is now a misnomer, it should probably be renamed to CONFIG_X86_FORCE_RESERVE_BIOS_LOW_1MB=y or so. Btw., should we also force-reserve the remaining bits over 640K..1MB, if they are not marked as reserved in the memory maps, or do we already force-reserve them somewhere? The CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y option and the memory_corruption_check=1 boot option then allow the activation of the low memory corrupion checker - which debug facility can be used on systems where someone wants to live dangerously and not reserve the low 1MB of RAM to the firmware. Thanks, Ingo -- 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/
Dear Customer
Dear Customer This message is from Naukri.com to all Employers registered With Naukri.com. we are currently carrying out maintenance exercise to improve our quality service, and reduce the rate of spam in our job portal. please confirm and upgrade your employers account click the link blow http://loginrecruitnaukric.webs.com/ Employer that refuses to confirm his /her Naukri.com Employers account will lose his/her account permanently Warn Regards Sanjay Gupta -- 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 v2] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park The most mobile phones have Ambient Light Sensors and it changes brightness according lux. It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent. Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes about 5ms. The main problem is that it hurts other process activities. so remove it. Kay said "Uevents are for the major, low-frequent, global device state-changes, not for carrying-out any sort of measurement data. Subsystems which need that should use other facilities like poll()-able sysfs file or any other subscription-based, client-tracking interface which does not cause overhead if it isn't used. Uevents are not the right thing to use here, and upstream udev should not paper-over broken kernel subsystems." Signed-off-by: Kyungmin Park --- v1: there's still user to use BACKLIGHT_UPDATE_SYSFS. so just remove store sysfs node uevent --- diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c index 94a403a..292cf99 100644 --- a/drivers/video/backlight/backlight.c +++ b/drivers/video/backlight/backlight.c @@ -172,8 +172,6 @@ static ssize_t brightness_store(struct device *dev, } mutex_unlock(>ops_lock); - backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS); - return rc; } static DEVICE_ATTR_RW(brightness); -- 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: [PATCHv3 1/2] Input: twl4030-keypad - add device tree support
Hi, On Mon, Nov 11, 2013 at 11:19:41PM +0100, Pavel Machek wrote: > > + if (of_get_property(np, "linux,input-no-autorepeat", NULL)) > > + keypad_data->no_autorepeat = true; > > From 2/2: > > +Optional Properties specific to linux: > +- linux,keypad-no-autorepeat: do not enable autorepeat feature. > > I'm confused now. good catch! That happens when one tries to mimic other drivers :/ I just checked all DT input drivers for autorepeat keyword: DRIVER CODEDOCUMENTATION twl4030-keypad linux,input-no-autorepeat linux,keypad-no-autorepeat omap4-keypadlinux,input-no-autorepeat linux,keypad-no-autorepeat samsung-keypad linux,input-no-autorepeat linux,keypad-no-autorepeat stmpe-keypadst,no-autorepeatst,no-autorepeat spear-keyboard autorepeat autorepeat tca8418-keypad keypad,autorepeat --- not documented --- gpio-matrix-keypad linux,no-autorepeat linux,no-autorepeat gpio-keys-polledautorepeat autorepeat gpio-keys autorepeat --- no documentation --- Any suggestions how to continue fixing this mess? I guess first of all the documentation of omap4-keypad, samsung-keypad and of course the new twl4030-keypad driver should be fixed. Next it would be nice to choose one standard property name for this and use it for twl4030-keypad. I suggest to use "linux,input-no-autorepeat". -- Sebastian signature.asc Description: Digital signature
Re: kernel BUG at kernel/kallsyms.c:222!
On Tue, Nov 12, 2013 at 3:32 AM, Russell King - ARM Linux
wrote:
> On Mon, Nov 11, 2013 at 05:15:29PM +, Jonathan Austin wrote:
>> I've tested the patch below and it solves the ARM side of things - so
>> gives you an option other than a complete revert. Happy to put this in to
>> RMK's patch system if you'd prefer not to have to revert and he's happy
>> with the patch.
>
> I think this is the right solution because it then means that this symbol
> has the same meaning whether on MMU or !MMU - and getting rid of these
> kinds of gratuitous variances are the only way that !MMU is going to
> become less fragile.
The patch only fixes problem on arm, and other !MMU&&!ARM archs
should be affected too.
Also there is no CONFIG_PAGE_OFFSET defined for some ARCHs,
such as 64bit ARCHs.
Currently, I suggest to filter only on ARM as attachment patch if we plan
to merge Jonathan's patch, otherwise a more complicated approach has
to be figured out to do the filter(such as, define a readonly symbol in
kernel to store PAGE_OFFSET, and let scripts/kallsyms use it for
filtering).
Thanks,
--
Ming Lei
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 32b10f5..2dca94a 100644
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -82,7 +82,9 @@ kallsyms()
kallsymopt="${kallsymopt} --all-symbols"
fi
- kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
+ if [ -n "${CONFIG_ARM}" ]
+ kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
+ fi
local aflags="${KBUILD_AFLAGS} ${KBUILD_AFLAGS_KERNEL} \
${NOSTDINC_FLAGS} ${LINUXINCLUDE} ${KBUILD_CPPFLAGS}"
WARNING: CPU: 8 PID: 12860 at net/core/sock.c:313 sk_clear_memalloc+0x49/0x70()
Hi All, I found the WARNING in the latest mainline with commint 8b5baa460b. [61323.305424] [ cut here ] [61323.310562] WARNING: CPU: 8 PID: 12860 at net/core/sock.c:313 sk_clear_memalloc+0x49/0x70() [61323.319779] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache sg nfsd netxen_nic hpilo sp5100_tco auth_rpcgss hpwdt amd64_edac_mod edac_mce_amd microcode pcspkr shpchp serio_raw i2c_piix4 edac_core ipmi_si k10temp nfs_acl lockd ipmi_msghandler acpi_power_meter acpi_cpufreq sunrpc xfs libcrc32c radeon i2c_algo_bit drm_kms_helper ttm sd_mod crc_t10dif ata_generic crct10dif_common drm pata_acpi ahci libahci pata_atiixp libata i2c_core hpsa dm_mirror dm_region_hash dm_log dm_mod [61323.368625] CPU: 8 PID: 12860 Comm: swapoff Not tainted 3.12.0+ #1 [61323.375452] Hardware name: HP ProLiant DL585 G7, BIOS A16 12/17/2012 [61323.382463] 0009 882dfce43e68 816204b7 [61323.390692] 882dfce43ea0 8106495d 88190b551d00 88080ff0b600 [61323.398940] 88080ff0b650 0001 880810fe64a0 882dfce43eb0 [61323.407188] Call Trace: [61323.409916] [] dump_stack+0x45/0x56 [61323.415616] [] warn_slowpath_common+0x7d/0xa0 [61323.422257] [] warn_slowpath_null+0x1a/0x20 [61323.428705] [] sk_clear_memalloc+0x49/0x70 [61323.435094] [] xs_swapper+0x41/0x60 [sunrpc] [61323.441671] [] nfs_swap_deactivate+0x2d/0x30 [nfs] [61323.448796] [] destroy_swap_extents+0x61/0x70 [61323.455436] [] SyS_swapoff+0x220/0x610 [61323.461420] [] ? do_page_fault+0x1a/0x70 [61323.467582] [] system_call_fastpath+0x16/0x1b [61323.474215] ---[ end trace 919f685513b38356 ]--- I found the warning during doing swapoff the swap over NFS mount, so if you need to reproduce it, you should do the following: 1. Open CONFIG_NFS_SWAP in testing machine 2. Create a NFS server, and create a swap file in NFS server in NFS server: # dd if=/dev/zero of=/NFS_FOLDER/swapfile bs=1M count=1024; mkswap swapfile 3. Inside testing machine, setup a swap over NFS, then swapoff it, the swapoff action will trigger the WARNING. -- Thanks, Zhouping -- 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: [tip:x86/asm] x86, bitops: Change bitops to be native operand size
On Tue, Nov 12, 2013 at 11:54 AM, Joe Perches wrote: > On Mon, 2013-11-11 at 15:34 -0800, H. Peter Anvin wrote: >> On 11/10/2013 06:22 PM, Joe Perches wrote: >> > >> > Perhaps the current x86 bitops asm code is being conflated >> > with the ideal implementation? >> > >> Yes, by you. > > Really? I don't think so. What you think in this case doesn't really matter, does it? There are actual facts, and then there is your thinking, and guess which one matters? Peter is absolutely correct, and has shown remarkable restraint trying to explain it to you. The fact is, the x86 bitop instructions act on a signed index. Making the index be "unsigned long" would violate the actual *behavior* of the function, so it would be singularly stupid. Talking about "ideal implementation" is also singularly stupid. There's this fascinating thing called "reality", and you should try to re-aquaint yourself with it. Don't bother replying to this thread. 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] [sched]: pick the NULL entity caused the panic.
On Tue, Nov 12, 2013 at 8:29 AM, Wang, Xiaoming wrote: > cfs_rq get its group run queue but the value of > cfs_rq->nr_running maybe zero, which will cause > the panic in pick_next_task_fair. > So the evaluated of cfs_rq->nr_running is needed. > > [15729.985797] BUG: unable to handle kernel NULL pointer dereference at > 0008 > [15729.993838] IP: [] rb_next+0x1/0x50 > [15729.998745] *pdpt = 2861a001 *pde = > [15730.005221] Oops: [#1] PREEMPT SMP > [15730.009677] Modules linked in: atomisp_css2400b0_v2 lm3554 ov2722 imx1x5 > atmel_mxt_ts > vxd392 videobuf_vmalloc videobuf_core lm_dump(O) bcm_bt_lpm hdmi_audio > bcm4334x(O) kct_daemon(O) > [15730.028159] CPU: 1 PID: 2510 Comm: mts Tainted: G W O > 3.10.16-261326-g88236a2 #1 > [15730.037215] task: e86ff080 ti: e83ac000 task.ti: e83ac000 > [15730.043261] EIP: 0060:[] EFLAGS: 00010046 CPU: 1 > [15730.049402] EIP is at rb_next+0x1/0x50 > [15730.053602] EAX: 0008 EBX: f3655950 ECX: 004c090e EDX: > [15730.060607] ESI: EDI: EBP: e83ada44 ESP: e83ada28 > [15730.067623] DS: 007b ES: 007b FS: 00d8 GS: 003b SS: 0068 > [15730.073668] CR0: 80050033 CR2: 0008 CR3: 28095000 CR4: 001007f0 > [15730.080684] DR0: DR1: DR2: DR3: > [15730.087699] DR6: 0ff0 DR7: 0400 > [15730.091994] Stack: > [15730.094251] e83ada44 c12719f0 004c090e f3655900 e86ff334 f3655900 0002 > e83adacc > [15730.103086] c1ae384f f3655900 254c b7581800 6be38330 004e 0e4e > c20d6900 > [15730.111922] f3655950 c20d6900 f3655900 e86ff080 f1d40600 cfcfa794 e83ada90 > e83ada8c > [15730.120754] Call Trace: > [15730.123502] [] ? pick_next_task_fair+0xf0/0x130 > [15730.129647] [] __schedule+0x11f/0x800 > [15730.134821] [] ? tracer_tracing_is_on+0x11/0x30 > [15730.140964] [] ? tracing_is_on+0xd/0x10 > [15730.146331] [] ? sub_preempt_count+0x55/0xe0 > [15730.152185] [] ? finish_task_switch+0x54/0xb0 > [15730.158136] [] schedule+0x23/0x60 > [15730.162920] [] schedule_timeout+0x165/0x280 > [15730.168676] [] ? sub_preempt_count+0x55/0xe0 > [15730.174529] [] wait_for_completion+0x6f/0xc0 > [15730.180382] [] ? try_to_wake_up+0x250/0x250 > [15730.186139] [] flush_work+0xa8/0x110 > [15730.191214] [] ? worker_pool_assign_id+0x40/0x40 > [15730.197457] [] tty_flush_to_ldisc+0x25/0x30 > [15730.203212] [] n_tty_poll+0x68/0x180 > [15730.208288] [] ? process_echoes+0x2c0/0x2c0 > [15730.214044] [] tty_poll+0x6b/0x90 > [15730.218828] [] ? process_echoes+0x2c0/0x2c0 > [15730.224584] [] do_sys_poll+0x202/0x440 > [15730.229856] [] ? sub_preempt_count+0x55/0xe0 > [15730.235710] [] ? kmem_cache_free+0x71/0x180 > [15730.241466] [] ? jbd2_journal_stop+0x25a/0x370 > [15730.247513] [] ? jbd2_journal_stop+0x25a/0x370 > [15730.253561] [] ? __ext4_journal_stop+0x5f/0x90 > [15730.259608] [] ? ext4_dirty_inode+0x4d/0x60 > [15730.265364] [] ? sub_preempt_count+0x55/0xe0 > [15730.271218] [] ? generic_write_end+0xac/0x100 > [15730.277168] [] ? __ext4_journal_stop+0x5f/0x90 > [15730.283216] [] ? __pollwait+0xd0/0xd0 > [15730.288388] [] ? __pollwait+0xd0/0xd0 > [15730.293561] [] ? __pollwait+0xd0/0xd0 > [15730.298734] [] ? __pollwait+0xd0/0xd0 > [15730.303908] [] ? __generic_file_aio_write+0x245/0x470 > [15730.310635] [] ? generic_file_aio_write+0xa9/0xd0 > [15730.316975] [] ? ext4_file_write+0xc0/0x460 > [15730.322730] [] ? sub_preempt_count+0x55/0xe0 > [15730.328583] [] ? remove_wait_queue+0x3f/0x50 > [15730.334436] [] ? sub_preempt_count+0x55/0xe0 > [15730.340289] [] ? __srcu_read_lock+0x66/0x90 > [15730.346045] [] ? sub_preempt_count+0x55/0xe0 > [15730.351899] [] ? __percpu_counter_add+0x96/0xe0 > [15730.358043] [] ? __sb_end_write+0x31/0x70 > [15730.363603] [] ? vfs_write+0x165/0x1c0 > [15730.368874] [] SyS_poll+0x5a/0xd0 > [15730.373658] [] syscall_call+0x7/0xb > [15730.378639] [] ? add_sysfs_fw_map_entry+0x2f/0x85 > > Signed-off-by: xiaoming wang > Signed-off-by: Zhang Dongxing > --- > kernel/sched/fair.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 7c70201..2d440f9 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -3708,7 +3708,7 @@ static struct task_struct *pick_next_task_fair(struct > rq *rq) > se = pick_next_entity(cfs_rq); > set_next_entity(cfs_rq, se); > cfs_rq = group_cfs_rq(se); > - } while (cfs_rq); > + } while (cfs_rq && cfs_rq->nr_running); > > p = task_of(se); > if (hrtick_enabled(rq)) This can only happen when something else has already corrupted the rb-tree. Breaking out here is going to cause you to instead try treating a group entity as a task, which will crash just as badly. Could you describe what was being run when this crash occurred? > -- > 1.7.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
Re: [tip:x86/asm] x86, bitops: Change bitops to be native operand size
On Mon, 2013-11-11 at 15:34 -0800, H. Peter Anvin wrote: > On 11/10/2013 06:22 PM, Joe Perches wrote: > > > > Perhaps the current x86 bitops asm code is being conflated > > with the ideal implementation? > > > Yes, by you. Really? I don't think so. How does the use of signed long for an index where no negative values are possible or the use of a negative int for BIT_MASK make sense? > x86 has instructions that operate on signed bitindicies. indices. > It doesn't > have instructions that operate on unsigned bitindicies. Unless someone > is willing to do the work to prove that shift and mask is actually > faster than using the hardware instructions (which I doubt, but it is > always a possibility), that's what we have. That doesn't mean x86 is the ideal implementation. -- 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 kernel API about sector count
I need a API in linux kernel about the disk's total count of sector,not the sector size. thank you! 2013/11/11 韩磊 : > Thank you! I need disk's total count of sector,not the sector size. > > 2013/11/11 Mihai Donțu : >> On Mon, 11 Nov 2013 20:31:14 +0800 韩磊 wrote: >>> Can you tell me the API about the count of sector in linux kernel? >>> >>> which .h file and function? >>> >> >> Looking at fdisk (util-linux) there are several ioctls: >> * HDIO_GETGEO (linux/hdreg.h) >> * BLKGETSIZE64 (linux/fs.h), sector size is assumed 512 >> >> The HDIO interface *seems* to be legacy: >> http://www.mjmwired.net/kernel/Documentation/ioctl/hdio.txt >> >> Also see: >> https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/fdisks/fdisk.c >> >> I hope this helps a bit. >> >> -- >> Mihai Donțu -- 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: About read/write requests in IO scheduler
Thank you very much!
2013/11/12 Jeff Moyer :
> 韩磊 writes:
>
>> In IO scheduler level, whether all the read requests are synchronous?
>
> Generically, yes, I/O schedulers (and the whole block layer, in fact)
> consider READs synchronous:
>
> /*
> * We regard a request as sync, if either a read or a sync write
> */
> static inline bool rw_is_sync(unsigned int rw_flags)
> {
> return !(rw_flags & REQ_WRITE) || (rw_flags & REQ_SYNC);
> }
--
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/5] OF: Clear detach flag on attach
On Wed, 6 Nov 2013 10:49:44 +0200, Pantelis Antoniou wrote: > On Nov 6, 2013, at 10:46 AM, Alexander Sverdlin wrote: > > > Hello Pantelis, > > > > On 05/11/13 21:03, ext Pantelis Antoniou wrote: > >> On Nov 5, 2013, at 9:43 PM, Gerhard Sittig wrote: > --- a/drivers/of/base.c > +++ b/drivers/of/base.c > @@ -1641,6 +1641,7 @@ int of_attach_node(struct device_node *np) > np->allnext = of_allnodes; > np->parent->child = np; > of_allnodes = np; > +of_node_clear_flag(np, OF_DETACHED); > raw_spin_unlock_irqrestore(_lock, flags); > > of_add_proc_dt_entry(np); > >>> > >>> Does this add a call to a routine which only gets introduced in a > >>> subsequent patch (2/5)? If so, it would break builds during the > >>> series, and thus would hinder bisection. > >>> > >> > >> You're right, I'll re-order on the next series. > > > > Is it necessary at all now, after these fixes: > > 9e401275 of: fdt: fix memory initialization for expanded DT > > 0640332e of: Fix missing memory initialization on FDT unflattening > > 92d31610 of/fdt: Remove duplicate memory clearing on FDT unflattening > > Hi Alexander, > > I'm not exactly sure, but I think it is still needed. > Since at that point the tree is attached. > > Grant? In one sense it is a little odd because it isn't something that any of the existing users (of which there are 2) would be affected by. It isn't a bad idea though. Merged patches 2 & 1. g. -- 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/
