Re: [PATCH v2 2/9] arm: mvebu: Align the internal registers virtual base to support LPAE

On Friday 05 April 2013, Gregory CLEMENT wrote: > From: Lior Amsalem > > In order to be able to support he LPAE, the internal registers virtual > base must be aligned to 2MB. > > Signed-off-by: Lior Amsalem > Signed-off-by: Gregory CLEMENT This is a surprising limitation. Can you extend the a

Re: [PATCH v2 7/9] arm: dts: mvebu: introduce internal-regs node

On 04/05/2013 10:43 PM, Arnd Bergmann wrote: > On Friday 05 April 2013, Gregory CLEMENT wrote: >> Signed-off-by: Gregory CLEMENT > > The patch looks good but the description is a bit short. > It cannot be more brief! :) I explained the purpose of this patch in the cover letter and forgot to ad

Re: [PATCH v2 0/9] rm: mvebu: Enable LPAE support for Armada XP SoCs

On Friday 05 April 2013, Gregory CLEMENT wrote: > The Armada XP SoCs have LPAE support. This is the second version patch > set whixh allow to run kernel on this SoCs with LPAE support. > > The biggest changes are the conversion of the device tree file to 64 > bits in order to be able to use more t

Re: [PATCH v2 8/9] arm: dts: mvebu: fix cpus section indentation

On Friday 05 April 2013, Gregory CLEMENT wrote: > From: Thomas Petazzoni > > Signed-off-by: Thomas Petazzoni This should have a description, even though it's completely trivial. I would also recommend moving this patch first, as the general rule is to do cleanups first. Arnd -- To unsu

Re: [PATCH v2 7/9] arm: dts: mvebu: introduce internal-regs node

On Friday 05 April 2013, Gregory CLEMENT wrote: > Signed-off-by: Gregory CLEMENT The patch looks good but the description is a bit short. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo i

Re: [PATCHv2] rdma: add a new IB_ACCESS_GIFT flag

On Fri, Apr 5, 2013 at 1:17 PM, Michael R. Hines wrote: > I also removed the IBV_*_WRITE flags on the sender-side and activated > cgroups with the "memory.memsw.limit_in_bytes" activated and the migration > with RDMA also succeeded without any problems (both with *and* without GIFT > also worked).

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Fri, Apr 05, 2013 at 01:19:39PM -0700, Julien Tinnes wrote: > I think it'd be perfectly ok for OOPS to print out the kernel base. Yeah, ok, this still would need some massaging of the oops output per script, but it shouldn't be a big problem. Also, you probably need to make clear in the oops i

[PATCH 1/4] x86/gdt/64-bit: store/load GDT for ACPI S3 or hibernate/resume path is not needed.

During the ACPI S3 resume path the trampoline code handles it already. During the ACPI S3 suspend phase (acpi_suspend_lowlevel) we set: early_gdt_descr.address = (..)get_cpu_gdt_table(smp_processor_id()); which is then used during the resume path and has the same exact value as what the store/loa

[PATCH 2/4] x86/gdt/i386: store/load GDT for ACPI S3 or hibernation/resume path is not needed

During the ACPI S3 suspend, we store the GDT in the wakup_header (see wakeup_asm.s) field called 'pmode_gdt'. Which is then used during the resume path and has the same exact value as what the store/load_gdt do with the saved_context (which is saved/restored via save/restore_processor_state()). T

[RFC PATCH] axe the store_gdt() pvops call. (v1)

Long long time ago (way back in October 2012), when I posted the patches that would make it possible to do ACPI S3 with Xen, Peter pointed out that: "excellent set of pvops calls that should be nukable to Kingdom Come. There is no reason, ever, to read the IDT and GDT from the kernel... the kernel

[PATCH 4/4] x86/wakeup/sleep: Use pvops functions for changing GDT entries.

From: "kon...@kernel.org" We check the TSS descriptor before we try to dereference it. Also we document what the value '9' actually means using the AMD64 Architecture Programmer's Manual Volume 2, pg 90: "Hex value 9: Available 64-bit TSS" and pg 91: "The available 32-bit TSS (09h), which is rede

[PATCH 3/4] x86/xen/store_gdt: Remove the pvops variant of store_gdt.

The two use-cases where we needed to store the GDT were during ACPI S3 suspend and resume. As the patches: x86/gdt/i386: store/load GDT for ACPI S3 or hibernation/resume path is not needed x86/gdt/64-bit: store/load GDT for ACPI S3 or hibernate/resume path is not needed. have demonstrated - th

Re: [PATCH v2 1/9] arm: mvebu: Limit the DMA zone when LPAE is selected

On Friday 05 April 2013, Gregory CLEMENT wrote: > When LPAE is activated on Armada XP, all registers and IOs are still > 32bit, the 40bit extension is on the CPU to DRAM path (windows) only. > That means that all the DMA transfer are restricted to the low 32 bits > address space. This is limitation

Re: [PATCH 02/10] migrate: make core migration code aware of hugepage

>>> There doesn't seem to be any caller for this function. Please move it to >>> the patch which uses it. >> >> I would do like that if there's only one user of this function, but I thought >> that it's better to separate this part as changes of common code >> because this function is commonly used

[GIT] Networking

1) Fix erroneous sock_orphan() leading to crashes and double kfree_skb() in NFC protocol. From Thierry Escande and Samuel Ortiz. 2) Fix use after free in remain-on-channel mac80211 code, from Johannes Berg. 3) nf_reset() needs to reset the NF tracing cookie, otherwise we can leak it fr

Re: [PATCH 1/3] pci: Add PCI ROM helper for platform-provided ROM images

On Apr 2, 2013, at 2:10 PM, Bjorn Helgaas wrote: > On Mon, Apr 1, 2013 at 11:47 AM, Matthew Garrett > wrote: >> On Mon, 2013-04-01 at 11:39 -0600, Bjorn Helgaas wrote: >> >>> Chris still has problems (see >>> https://bugzilla.redhat.com/show_bug.cgi?id=927451), but I don't know >>> whether the

[PATCH] mrf24j40: Enable link-layer acknowledgement and retry

On the MRF24J40, link-layer acknowledgment request and retry must be turned on explicitly for each packet. Turn this on in the hardware based on the FC_ACK_REQ bit being set in the packet. Also, now that failure to receive an ACK will cause the hardware to report failure of transmission, change t

[PATCH] mac802154: Keep track of the channel when changed

Prevent set_channel() from getting called every time a packet is sent. This looks like it was an oversight. Signed-off-by: Alan Ott --- net/mac802154/tx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c index 3fd3e07..6d16473 100644 --- a/net/mac802

Re: [PATCH 1/3] pci: Add PCI ROM helper for platform-provided ROM images

On Fri, Apr 5, 2013 at 2:31 PM, Chris Murphy wrote: > > On Apr 2, 2013, at 2:10 PM, Bjorn Helgaas wrote: > >> On Mon, Apr 1, 2013 at 11:47 AM, Matthew Garrett >> wrote: >>> On Mon, 2013-04-01 at 11:39 -0600, Bjorn Helgaas wrote: >>> Chris still has problems (see https://bugzilla.redhat

[PATCH 0/3] mm: fixup changers of per cpu pageset's ->high and ->batch

In one case while modifying the ->high and ->batch fields of per cpu pagesets we're unneededly using stop_machine() (patches 1 & 2), and in another we don't have any syncronization at all (patch 3). This patchset fixes both of them. Note that it results in a change to the behavior of zone_pcp_up

[PATCH 3/3] mm: when handling percpu_pagelist_fraction, use on_each_cpu() to set percpu pageset fields.

In free_hot_cold_page(), we rely on pcp->batch remaining stable. Updating it without being on the cpu owning the percpu pageset potentially destroys this stability. Change for_each_cpu() to on_each_cpu() to fix. Signed-off-by: Cody P Schafer --- mm/page_alloc.c | 21 +++-- 1 fil

[PATCH 2/3] mm/page_alloc: convert zone_pcp_update() to use on_each_cpu() instead of stop_machine()

No off-cpu users of the percpu pagesets exist. zone_pcp_update()'s goal is to adjust the ->high and ->mark members of a percpu pageset based on a zone's ->managed_pages. We don't need to drain the entire percpu pageset just to modify these fields. Avoid calling setup_pageset() (and the draining re

[PATCH 1/3] mm/page_alloc: factor out setting of pcp->high and pcp->batch.

Creates pageset_set_batch() for use in setup_pageset(). pageset_set_batch() imitates the functionality of setup_pagelist_highmark(), but uses the boot time (percpu_pagelist_fraction == 0) calculations for determining ->high based on ->batch. Signed-off-by: Cody P Schafer --- mm/page_alloc.c | 12

Re: [PATCH 01/10] migrate: add migrate_entry_wait_huge()

> diff --git v3.9-rc3.orig/mm/hugetlb.c v3.9-rc3/mm/hugetlb.c > index 0a0be33..98a478e 100644 > --- v3.9-rc3.orig/mm/hugetlb.c > +++ v3.9-rc3/mm/hugetlb.c > @@ -2819,7 +2819,7 @@ int hugetlb_fault(struct mm_struct *mm, struct > vm_area_struct *vma, > if (ptep) { > entry = huge_

Re: [PATCH 01/10] migrate: add migrate_entry_wait_huge()

> diff --git v3.9-rc3.orig/mm/hugetlb.c v3.9-rc3/mm/hugetlb.c > index 0a0be33..98a478e 100644 > --- v3.9-rc3.orig/mm/hugetlb.c > +++ v3.9-rc3/mm/hugetlb.c > @@ -2819,7 +2819,7 @@ int hugetlb_fault(struct mm_struct *mm, struct > vm_area_struct *vma, > if (ptep) { > entry = huge_

Re: [PATCH 3/3] x86: kernel base offset ASLR

On 04/05/2013 01:19 PM, Yinghai Lu wrote: > On Fri, Apr 5, 2013 at 1:05 PM, H. Peter Anvin wrote: > >> That makes zero difference, since the issue at hand is the *virtual* >> addresses the kernel are running at. Currently, the 64-bit kernel >> always runs at 0x8100 virtual. We can't

Re: [PATCH v2 1/4] dcache: Don't take unnecessary lock in d_count update

On 04/05/2013 01:12 PM, Al Viro wrote: @@ -635,22 +640,14 @@ struct dentry *dget_parent(struct dentry *dentry) { struct dentry *ret; -repeat: - /* -* Don't need rcu_dereference because we re-check it was correct under -* the lock. -*/ rcu_read_lock

[PATCH v2 4/9] arm: dts: Add a 64 bits version of the skeleton device tree

From: Lior Amsalem In order to be able to use more than 4GB address-cells and size-cells have to be set to 2 Signed-off-by: Gregory CLEMENT Signed-off-by: Lior Amsalem --- arch/arm/boot/dts/skeleton64.dtsi | 13 + 1 file changed, 13 insertions(+) create mode 100644 arch/arm/boo

[PATCH v2 5/9] arm: dts: mvebu: move all peripherals inside soc

From: Thomas Petazzoni Signed-off-by: Thomas Petazzoni --- arch/arm/boot/dts/armada-370-xp.dtsi | 26 +- arch/arm/boot/dts/armada-370.dtsi| 23 --- arch/arm/boot/dts/armada-xp.dtsi | 32 3 files changed,

[PATCH v2 2/9] arm: mvebu: Align the internal registers virtual base to support LPAE

From: Lior Amsalem In order to be able to support he LPAE, the internal registers virtual base must be aligned to 2MB. Signed-off-by: Lior Amsalem Signed-off-by: Gregory CLEMENT --- arch/arm/include/debug/mvebu.S |2 +- arch/arm/mach-mvebu/armada-370-xp.h |2 +- 2 files changed,

[PATCH v2 3/9] arm: mvebu: Enable pj4b on LPAE compilations

From: Lior Amsalem pj4b cpus are LPAE capable so enable them on LPAE compilations Signed-off-by: Lior Amsalem Tested-by: Franklin Signed-off-by: Gregory CLEMENT --- arch/arm/mm/proc-v7.S |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mm/proc-v7.S b/arch/arm

[PATCH v2 1/9] arm: mvebu: Limit the DMA zone when LPAE is selected

When LPAE is activated on Armada XP, all registers and IOs are still 32bit, the 40bit extension is on the CPU to DRAM path (windows) only. That means that all the DMA transfer are restricted to the low 32 bits address space. This is limitation is achieved by selecting ZONE_DMA. Signed-off-by: Greg

[PATCH v2 0/9] rm: mvebu: Enable LPAE support for Armada XP SoCs

Hello, The Armada XP SoCs have LPAE support. This is the second version patch set whixh allow to run kernel on this SoCs with LPAE support. The biggest changes are the conversion of the device tree file to 64 bits in order to be able to use more than 4GB of memory (without this the LPAE is pointl

[PATCH v2 9/9] arm: dts: mvebu: Convert mvebu device tree files to 64 bits

In order to be able to use more than 4GB of RAM when the LPAE is activated, the dts must be converted in 64 bits. Armada XP and Armada 370 share a dtsi file which have also be converted to 64 bits. This lead to convert all the device tree files to 64 bits even the one used for Armada 370 (which do

[PATCH v2 7/9] arm: dts: mvebu: introduce internal-regs node

Signed-off-by: Gregory CLEMENT --- arch/arm/boot/dts/armada-370-db.dts | 108 +- arch/arm/boot/dts/armada-370-mirabox.dts | 78 arch/arm/boot/dts/armada-370-rd.dts |2 + arch/arm/boot/dts/armada-370-xp.dtsi | 228 +++--

[PATCH v2 8/9] arm: dts: mvebu: fix cpus section indentation

From: Thomas Petazzoni Signed-off-by: Thomas Petazzoni --- arch/arm/boot/dts/armada-xp-mv78230.dtsi | 28 arch/arm/boot/dts/armada-xp-mv78260.dtsi | 28 arch/arm/boot/dts/armada-xp-mv78460.dtsi | 54 +++--- 3 files changed, 55 inse

[PATCH v2 6/9] arm: dts: mvebu: Convert all the mvebu files to use the range property

This conversion will allow to keep 32 bits addresses for the internal registers whereas the memory of the system will be 64 bits. Later it will also ease the move of the mvebu-mbus driver to the device tree support. Signed-off-by: Gregory CLEMENT --- arch/arm/boot/dts/armada-370-db.dts

Re: [PATCH 1/1] Introduce Intel RAPL cooling device driver

On Wed, Apr 03, 2013 at 11:03:08AM -0700, Jacob Pan wrote: > On Wed, 3 Apr 2013 09:30:52 -0700 > Greg KH wrote: > > > On Tue, Apr 02, 2013 at 05:17:14PM -0700, Jacob Pan wrote: > > > On Tue, 2 Apr 2013 16:48:05 -0700 > > > Greg KH wrote: > > > > > > > On Tue, Apr 02, 2013 at 04:33:57PM -0700, J

Re: [PATCH 1/1] Introduce Intel RAPL cooling device driver

On Wed, Apr 03, 2013 at 10:35:51AM -0700, Jacob Pan wrote: > On Wed, 3 Apr 2013 09:35:09 -0700 > Greg KH wrote: > > > On Tue, Apr 02, 2013 at 09:48:18PM -0700, Jacob Pan wrote: > > > > Let's step back and start over, what exactly are you trying to > > > > tell userspace? What data do you have th

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Fri, Apr 5, 2013 at 1:05 PM, H. Peter Anvin wrote: > That makes zero difference, since the issue at hand is the *virtual* > addresses the kernel are running at. Currently, the 64-bit kernel > always runs at 0x8100 virtual. We can't run out of > arbitrary bits of the 64-bit addres

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Fri, Apr 5, 2013 at 7:49 AM, Borislav Petkov wrote: > On Thu, Apr 04, 2013 at 01:07:35PM -0700, Kees Cook wrote: >> This creates CONFIG_RANDOMIZE_BASE, so that the base offset of the kernel >> can be randomized at boot. > > Right, > > if I'm reading this whole deal correctly, I have an issue wi

Re: [PATCHv2] rdma: add a new IB_ACCESS_GIFT flag

The userland part of the patch was missing (IBV_ACCESS_GIFT). I added flag that to /usr/include in addition to this patch and did a test RDMA migrate and it seems to work without any problems. I also removed the IBV_*_WRITE flags on the sender-side and activated cgroups with the "memory.memsw

Re: [PATCH] ARM: arch_timer: Silence debug preempt warnings

On 04/05/13 03:04, Marc Zyngier wrote: > >>> drivers/clocksource/arm_arch_timer.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/clocksource/arm_arch_timer.c >>> b/drivers/clocksource/arm_arch_timer.c >>> index d7ad425..5928c29 100644 >>> --- a/drivers/cloc

Re: hang while add block device to raid1

2013/4/5 Greg KH : > Which is no longer supported, can you duplicate this on the 3.8 stable > tree? > > thanks, > > greg k-h I will try today and send results. Thanks! -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- To unsubscribe from this list: send the line "unsubscr

Re: [PATCH 3/3] x86: kernel base offset ASLR

On 04/05/2013 01:01 PM, Yinghai Lu wrote: > On Thu, Apr 4, 2013 at 1:21 PM, H. Peter Anvin wrote: >> I have to admit to being somewhat skeptical toward KASLR with only 8 >> bits of randomness. There are at least two potential ways of >> dramatically increasing the available randomness: >> >> 1. a

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

On 04/05/2013 01:37 PM, Simon Glass wrote: > HI Wolfram, > > On Wed, Apr 3, 2013 at 12:19 PM, Wolfram Sang wrote: >> Doug, >> >>> Separately from a discussion of the technical merits, I'd say that >>> this patch is needed because the Embedded Controller (EC) on the ARM >>> Chromebook shipped expe

Re: [PATCH 3/3] x86: kernel base offset ASLR

On Thu, Apr 4, 2013 at 1:21 PM, H. Peter Anvin wrote: > I have to admit to being somewhat skeptical toward KASLR with only 8 > bits of randomness. There are at least two potential ways of > dramatically increasing the available randomness: > > 1. actually compose the kernel of multiple independen

Re: [RFC] rootmpfs

Rob, FWIW I have a patch to do something like this. It even gives you a rdsize=xxx tunable kernel parameter that lets you specify the size of the tmpfs, which acts like the -osize= mount flag (so phrases like 100M or 20% works). So doing things like 'cat /dev/zero > filename' will not run you out

Re: [RFC] revoke(2) and generic handling of things like remove_proc_entry()

On Fri, Apr 05, 2013 at 05:29:32AM +0100, Al Viro wrote: > After some digging in procfs logics for revoking further file IO after > remove_proc_entry() (and figuring out what to do for debugfs - it also > needs something similar), I think I've got something that has potential > to become a working

Re: n_tty_write() going into schedule but NOT coming out

[ --cc Ingo and Peter Z. as this is not scheduler-related] On Tue, 2013-04-02 at 18:56 +0530, Vineet Gupta wrote: > On 04/01/2013 08:40 PM, Peter Hurley wrote: > > On Mon, 2013-04-01 at 19:27 +0530, Vineet Gupta wrote: > >> Hi, > >> > >> Any thoughts: I observe the same issue even with CONFIG_PREE

Re: [PATCH] THP: fix comment about memory barrier

On Fri, 5 Apr 2013, Minchan Kim wrote: > Now, memory barrier in __do_huge_pmd_anonymous_page doesn't work. > Because lru_cache_add_lru uses pagevec so it could miss spinlock > easily so above rule was broken so user might see inconsistent data. > > I was not first person who pointed out the probl

Re: [PATCH v3 linux-next] cpufreq: ondemand: Calculate gradient of CPU load to early increase frequency

Hi Viresh, On 04/04/2013 07:54 AM, Viresh Kumar wrote: > Hi Stratos, > > Yes, your results show some improvements. BUT if performance is the only thing > we were looking for, then we will never use ondemand governor but performance > governor. > > I suspect this little increase in performance mu

Re: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen

On Fri, 5 Apr 2013, Stefano Stabellini wrote: > On Fri, 5 Apr 2013, Stefano Stabellini wrote: > > - we are running on Xen > > Xen is running on the platform, we are running as a guest on Xen and an > > hypervisor node is available on device tree. > > Let's also assume that there aren't any "arm,cc

net_dropmon usage documentation/examples?

Hi Neil, I'm wondering if you have or know of any public documentation/examples for using net_dropmon. If not, I'll figure it out on my own at some point. Thanks in advance! (Not a very high priority project for me, my network connectivity problems are sadly _very_ obvious at the moment :x) --

Re: [PATCH v6 4/4] xen/arm: introduce xen_early_init, use PSCI on xen

On Fri, 5 Apr 2013, Stefano Stabellini wrote: > This is what happens: > > - No Xen > Xen is not running on the platform and a Xen hypervisor node is not > available on device tree. > Everything keeps working seamlessly, this patch doesn't change anything. > > - we are running on Xen > Xen is run

[PATCH v6] irq: add quirk for broken interrupt remapping on 55XX chipsets

A few years back intel published a spec update: http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf For the 5520 and 5500 chipsets which contained an errata (specificially errata 53), which noted that these chipsets can't properly do interru

Re: [PATCH v5] irq: add quirk for broken interrupt remapping on 55XX chipsets

On Fri, Apr 05, 2013 at 03:25:54PM -0400, Neil Horman wrote: > A few years back intel published a spec update: > http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf > > For the 5520 and 5500 chipsets which contained an errata (specificially

[PATCH 2/3] nfc: Convert nfc_dev_info and nfc_dev_err to nfc_

Use a more standard kernel style macro logging name. Standardize the spacing of the "NFC: " prefix. Add \n to uses, remove from macro. Fix the defective uses that already had a \n. Signed-off-by: Joe Perches --- drivers/nfc/nfcwilink.c | 44 +++--- drivers/nfc/pn533.c | 156 +++

[PATCH 3/3] nfc: Standardize logging style

Use standardized styles to minimize coding defects. Always use nfc_ where feasible. Add \n to formats where appropriate. Tyop "it it" correction. Add #define pr_fmt where appropriate. Remove function tracing logging messages. Remove OOM messages. Signed-off-by: Joe Perches --- drivers/nfc/micro

[PATCH 1/3] nfc: Replace nfc_dev_dbg with dev_dbg, remove function tracing

Use the generic kernel function instead of a home-grown one that does the same thing. Remove empty function tracing style uses as the kernel function tracer does that too. Add \n to uses not at the macro. Don't add \n where the nfc_dev_dbg macro mistakenly had them already. Signed-off-by: Joe P

[PATCH 0/3] nfc: standardize logging styles

Fix some defects in the logging too Joe Perches (3): nfc: Replace nfc_dev_dbg with dev_dbg, remove function tracing nfc: Convert nfc_dev_info and nfc_dev_err to nfc_ nfc: Standardize logging style drivers/nfc/microread/i2c.c | 32 ++--- drivers/nfc/microread/mei.c | 20 +-- d

[PATCH v5] irq: add quirk for broken interrupt remapping on 55XX chipsets

A few years back intel published a spec update: http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf For the 5520 and 5500 chipsets which contained an errata (specificially errata 53), which noted that these chipsets can't properly do interru

RE: [PATCH v12 3/3] trace,x86: code-sharing between non-trace and trace irq handlers

Steven, I confirmed that smp_apic_timer_interrupt is traced in a function graph tracing below. If additional testing is needed, please let me know. trace-cmd start -p function_graph -g "smp_trace_apic_timer_interrupt"-g "smp_apic_timer_interrupt" -e irq_vectors plugin function_graph Seij

[PATCH v12 3/3] trace,x86: code-sharing between non-trace and trace irq handlers

[Issue] Currently, irq vector handlers for tracing are just copied non-trace handlers by simply inserting tracepoints. It is difficult to manage the codes. [Solution] This patch shares common codes between non-trace and trace handlers as follows to make them manageable and readable. Non-trace

[PATCH v12 2/3] trace,x86: add x86 irq vector tracepoints

[Purpose of this patch] As Vaibhav explained in the thread below, tracepoints for irq vectors are useful. http://www.spinics.net/lists/mm-commits/msg85707.html The current interrupt traces from irq_handler_entry and irq_handler_exit provide when an interrupt is handled. They provide good data

[PATCH v12 1/3] tracing: Add DEFINE_EVENT_FN() macro

From: Steven Rostedt Each TRACE_EVENT() adds several helper functions. If two or more trace events share the same structure and print format, they can also share most of these helper functions and save a lot of space from duplicate code. This is why the DECLARE_EVENT_CLASS() and DEFINE_EVENT() we

[PATCH v12 0/3] trace,x86: irq vector tracepoint support

Change log v11 -> v12 - Rebase to 3.9-rc5 v10 -> v11 - Rebase to 3.9-rc2 - Add a modification for hyperv_callback vector. (patch 2/3) - Change a way to switch idt to check the table in use instead of saving/restoring it, because saving/restoring functions will break if we have to add ano

Re: Version number policy!

The point here is that once we hit a new major version, all the previous version checks can go away. So, if we decide to change some WMI message formats, it'll be in 2.x rather than 1.x. For example, has talked about killing off rate control in the NIC and doing it on the host. I'm happy with tha

[char-misc-next V3] mei: add debugfs hooks

debugfs exposes device state and list of me clients and their properties Signed-off-by: Tomas Winkler --- V3: 1. remove DEBUGFS_ADD_FILE macro V2: 1. don't use DEBUGFS_ADD_FILE macro 2. compile debugfs.c only if CONFIG_DEBUG_FS is set drivers/misc/mei/Makefile | 1 + drivers/misc/mei/debugfs

Re: [PATCH v3 2/3] fix hugetlb memory check in vma_dump_size()

(4/3/13 2:35 PM), Naoya Horiguchi wrote: > Documentation/filesystems/proc.txt says about coredump_filter bitmask, > > Note bit 0-4 doesn't effect any hugetlb memory. hugetlb memory are only > effected by bit 5-6. > > However current code can go into the subsequent flag checks of bit 0-4 > for

Re: [PATCH v3 3/3] hugetlbfs: add swap entry check in follow_hugetlb_page()

(4/3/13 2:35 PM), Naoya Horiguchi wrote: > With applying the previous patch "hugetlbfs: stop setting VM_DONTDUMP in > initializing vma(VM_HUGETLB)" to reenable hugepage coredump, if a memory > error happens on a hugepage and the affected processes try to access > the error hugepage, we hit VM_BUG_O

Re: [GIT PULL] dt: run C pre-processor on *.dts, create some standard headers

On 04/05/2013 01:46 PM, Stephen Warren wrote: > Rob, it might be worth keeping this in a separate branch in linux-next > so you can pull it out if it causes any issues. I've been using these > patches for quite a while now, but there's always opportunity for > surprises on architectures I don't use

Re: [PATCH] firmware,IB/qib: revert firmware file move

> Commit e2eed58 ("IB/qib: change QLogic to Intel") moved a firmware file > potentially breaking the ABI. > > This patch reverts that aspect of the fix as well as reverting the > firmware name as used in qib. > > Reported-by: David Woodhouse > Signed-off-by: Mike Marciniszyn Thanks. I think the

[GIT PULL] dt: run C pre-processor on *.dts, create some standard headers

Rob, it might be worth keeping this in a separate branch in linux-next so you can pull it out if it causes any issues. I've been using these patches for quite a while now, but there's always opportunity for surprises on architectures I don't use. I did just fix a bug when building with O= a few day

Re: [PATCH v3 1/3] hugetlbfs: stop setting VM_DONTDUMP in initializing vma(VM_HUGETLB)

On Fri, Apr 05, 2013 at 02:32:08PM -0400, KOSAKI Motohiro wrote: > (4/3/13 2:35 PM), Naoya Horiguchi wrote: > > Currently we fail to include any data on hugepages into coredump, > > because VM_DONTDUMP is set on hugetlbfs's vma. This behavior was recently > > introduced by commit 314e51b98 "mm: kil

Re: control on cpu/core

ok thanks lucas ;) i'm not on writing functions loading yet but it will come (i don't have a more efficient format than elf in good shape in my mind ...) 2013/4/5 Lucas De Marchi : > On Fri, Apr 5, 2013 at 1:30 PM, christophe malvasio > wrote: >> hi all >> i want to give the control of one core

Re: [PATCH RFC] watchdog: core: don't try to stop device if not running

On Fri, Apr 05, 2013 at 06:09:44PM +0200, Hector Palacios wrote: > A watchdog device may be stopped from userspace using WDIOC_SETOPTIONS > ioctl and flag WDIOS_DISABLECARD. If the device is closed after this > operation, watchdog_release() is called and status bits checked for > stopping it. Besid

Re: [PATCH v3 1/3] hugetlbfs: stop setting VM_DONTDUMP in initializing vma(VM_HUGETLB)

(4/3/13 2:35 PM), Naoya Horiguchi wrote: > Currently we fail to include any data on hugepages into coredump, > because VM_DONTDUMP is set on hugetlbfs's vma. This behavior was recently > introduced by commit 314e51b98 "mm: kill vma flag VM_RESERVED and > mm->reserved_vm counter". This looks to me a

[PATCH v3] firmware,IB/qib: revert firmware file move

Commit e2eed58 ("IB/qib: change QLogic to Intel") moved a firmware file potentially breaking the ABI. This patch reverts that aspect of the fix as well as reverting the firmware name as used in qib. Reported-by: David Woodhouse Signed-off-by: Mike Marciniszyn --- drivers/infiniband/hw/qib/qib_

Re: [PATCH 3/3] x86: kernel base offset ASLR

On 04/05/2013 01:04 AM, Ingo Molnar wrote: > > The cost of 64-bit RIPs is probably measurable both in cache footprint and > in execution speed. > Well, "probably" usually translates to "worth measuring" to me. > Random runtime shuffling of the kernel image - is that possible with > existing t

Re: [PATCH v2] firmware,IB/qib: revert firmware file move

On Fri, Apr 5, 2013 at 11:15 AM, Mike Marciniszyn wrote: > Commit e2eed58 ("IB/qib: change QLogic to Intel") moved a firmware file > potentially breaking the ABI. Please send things like this generated with the "-M" flag so that you can see it as a rename, instead of a huge add/del patch. Sure,

Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples

On Thu, 2013-04-04 at 17:29 +0100, Pawel Moll wrote: > > Maybe can we extend the dynamic posix clock code to work on more then > > just the chardev? > > The idea I'm following now is to make the dynamic clock framework even > more generic, so there could be a clock associated with an arbitrary >

Re: [PATCH 1/3] x86: routines to choose random kernel base offset

On 04/05/2013 12:36 AM, Ingo Molnar wrote: > > * Ingo Molnar wrote: > >> >> * Kees Cook wrote: >> >>> This provides routines for selecting a randomized kernel base offset, >>> bounded by e820 details. It tries to use RDRAND and falls back to RDTSC. >>> If "noaslr" is on the kernel command lin

[PATCH v2] firmware,IB/qib: revert firmware file move

Commit e2eed58 ("IB/qib: change QLogic to Intel") moved a firmware file potentially breaking the ABI. This patch reverts that aspect of the fix as well as reverting the firmware name as used in qib. Reported-by: David Woodhouse Signed-off-by: Mike Marciniszyn --- drivers/infiniband/hw/qib/qib_

Re: [PATCH v4 0/7] Add O_DENY* support for VFS and CIFS/NFS

2013/4/5 Pavel Shilovsky : > Main changes from the previous one: > 1) O_DENYMAND is removed, sharelock mount option is introduced. > 2) Patch fcntl.h and VFS patches are united into one. > 3) flock/LOCK_MAND is disabled for sharelock mounts. > > This patchset adds support of O_DENY* flags for Linux

Re: [PATCH v3 00/22] x86, ACPI, numa: Parse numa info early

On Fri, Apr 5, 2013 at 9:36 AM, Thomas Renninger wrote: > > From acpi overriding parts: > Tested-by: Thomas Renninger Thanks a lot for testing. > > I also went through the override related patches and from > what I can judge (certainly not the early memory, flat 32 bit memory you call > it? >

Re: Version number policy!

On Friday 05 April 2013 19:23:54 Eugene Krasnikov wrote: > When it comes to feature bitmap do you have an example of such a > bitmap from carl9170? That's a weird way of asking. No, I don't have an example?! But carl9170fw_feature_list is used in "production". Anyway, there is one defined in:

[PATCH] process cputimer is moving faster than its corresponding clock

Process timers are moving fasters than their corresponding cpu clock for various reasons: 1. There is a race condition when getting a timer sample that makes the sample be smaller than it should leading to setting the timer expiration to soon. 2. When initializing the cputimer, by including t

Re: PROBLEM: IPv6 TCP-Connections resetting

On Fri, 2013-04-05 at 17:48 +0200, Tetja Rediske wrote: > Hi, > CC netdev and Duan Jiong (author of bad commit) > [1.] One line summary of the problem: > > IPv6 TCP-Connections resetting > > [2.] Full description of the problem/report: > > In the last weeks we updated some of our systems to

Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs

On 04/04/2013 07:41 PM, Tony Lindgren wrote: * Roger Quadros [130404 00:39]: On 04/04/2013 02:42 AM, Tony Lindgren wrote: --- a/arch/arm/mach-omap2/cclock44xx_data.c +++ b/arch/arm/mach-omap2/cclock44xx_data.c @@ -27,6 +27,7 @@ #include #include #include +#include #include "soc.

Re: GFS2: Pull request (fixes)

Hi, I've dropped out the patch which shouldn't have made it into the previous pull request, so this set should be ok now. Apologies for not spotting that issue sooner, Steve. - There are two patches which fix up a couple of

Re: control on cpu/core

On Fri, Apr 5, 2013 at 1:30 PM, christophe malvasio wrote: > hi all > i want to give the control of one core to a module > that is the kernel have to not schedule/interrupt execution on this > core and also my module have to be the only thing to send execution on > this core > i'm not sure if i ca

Re: PROBLEM: IPv6 TCP-Connections resetting

On Fri, Apr 5, 2013 at 11:48 AM, Tetja Rediske wrote: > I tracked it down with 'git bisect' to commit: > > 093d04d42fa094f6740bb188f0ad0c215ff61e2c ... Thanks for the detailed report! > 11:52:04.634656 IP6 fe80::92e2:baff:fe00:c120 > 2a00:1828:1000:1102::2: > ICMP6, redirect, 2a00:1828:0:1::1

Re: [RFC] drivers/staging/silicom/bp_proc.c removal

On Fri, Apr 05, 2013 at 10:31:56AM -0700, Puff . wrote: > No reason not to. Done (in vfs.git#for-next, should propagate in a few) -- 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.ker

Linux 3.0.72

I'm announcing the release of the 3.0.72 kernel. All users of the 3.0 kernel series must upgrade. The updated 3.0.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.0.y and can be browsed at the normal kernel.org git web browser:

Linux 3.4.39

I'm announcing the release of the 3.4.39 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser:

Re: [PATCHv3] driver: serial: prevent UART console idle on suspend while using "no_console_suspend"

Sourav Poddar writes: > With dt boot, uart wakeup after suspend is non functional while using > "no_console_suspend" in the bootargs. With "no_console_suspend" used, we > should prevent the runtime suspend of the uart port which is getting used > as an console. > > Cc: Santosh Shilimkar > Cc: Fel

Linux 3.8.6

I'm announcing the release of the 3.8.6 kernel. All users of the 3.8 kernel series must upgrade. The updated 3.8.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.8.y and can be browsed at the normal kernel.org git web browser:

Re: [RFC] drivers/staging/silicom/bp_proc.c removal

On Fri, Apr 05, 2013 at 10:31:56AM -0700, Puff . wrote: > No reason not to. > > ~~ > DanielC > > On Thu, Apr 4, 2013 at 12:12 PM, Al Viro wrote: > >         It's all ifdefed out (on BYPASS_SUPPORT), severely bitrotten (try > to remove the ifdef and watch what happens on attempt to b

Re: [PATCH resend] fs/proc: Move kfree outside pde_unload_lock

On Fri, Apr 05, 2013 at 12:05:26PM -0500, Nathan Zimmer wrote: > On 04/04/2013 03:44 PM, Al Viro wrote: > >On Thu, Apr 04, 2013 at 12:12:05PM -0500, Nathan Zimmer wrote: > > > >>Ok I am cloning the tree now. > >>It does look like the patches would conflict. > >>I'll run some tests and take a deeper

<    1   2   3   4   5   >