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
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
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
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
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
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).
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
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
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
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
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
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
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
>>> 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
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
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
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
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
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
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
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
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
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
> 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_
> 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_
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
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
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
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,
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,
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
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
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
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
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 +++--
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[ --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
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
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
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
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)
--
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
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
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
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 +++
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
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
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
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
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
[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
[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
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
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
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
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
(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
(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
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
> 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
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
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
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
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
(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
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_
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
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,
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
>
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
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_
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
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?
>
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:
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
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
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.
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
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
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
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
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:
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:
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
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:
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
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
101 - 200 of 498 matches
Mail list logo