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
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 -
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
>>> 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
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
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
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
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
---
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
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
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
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
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 |
> 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 =
> 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 =
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
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.
-*/
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
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
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:
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
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
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
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,
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
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
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
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
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
>>> ---
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
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.
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
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
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
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
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
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
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
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
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
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
---
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
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 +--
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
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
[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()
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
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
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 +
(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
>
(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
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
> 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
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
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:
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
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.
(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
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
---
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
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
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
---
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
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
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
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
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,
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
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:
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
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
On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> On Fri, 5 Apr 2013, Nicolas Pitre wrote:
> > On Fri, 5 Apr 2013, Stefano Stabellini wrote:
> >
> > > Split xen_guest_init in two functions, one of them (xen_early_init) is
> > > going to be called very early from setup_arch.
> > >
> > > Change
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
---
Good point regarding timestamp.
When it comes to feature bitmap do you have an example of such a
bitmap from carl9170? Why not to rely always on major version?
2013/4/5 Christian Lamparter :
> On Friday 05 April 2013 10:19:00 Luis R. Rodriguez wrote:
>> On Thu, Apr 4, 2013 at 11:27 AM, Adrian
On Fri, 5 Apr 2013, Nicolas Pitre wrote:
> On Fri, 5 Apr 2013, Stefano Stabellini wrote:
>
> > Split xen_guest_init in two functions, one of them (xen_early_init) is
> > going to be called very early from setup_arch.
> >
> > Change machine_desc->smp_init to xen_smp_init if Xen is present on the
On 5 Apr 2013 at 18:17, Jan-Simon Möller wrote:
> Cleanup a variable name reuse.
>
>
> Fix suggested by PaX Team
Reviewed-by: PaX Team
> Signed-off-by: Jan-Simon Möller
> ---
> arch/x86/kernel/cpu/perf_event_intel_uncore.c | 16
> 1 file changed, 8 insertions(+), 8
> @@ -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();
> - ret =
Hello,
This is another attempt (previous one was [1]) to implement support for
memory snapshot for the the checkpoint-restore project (http://criu.org).
Let me remind what the issue is.
<< EOF
To create a dump of an application(s) we save all the information about it
to files, and the biggest
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 look.
FWIW, I've just pushed there a tentative patch that switches to
On Friday 05 April 2013 10:19:00 Luis R. Rodriguez wrote:
> On Thu, Apr 4, 2013 at 11:27 AM, Adrian Chadd wrote:
> > Here's my first take on the version number policy:
> >
> > https://github.com/qca/open-ath9k-htc-firmware/wiki/VersionPolicy
> > The summary:
> >
> > * major version number changes
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git
tags/spi-fix-v3.9-rc5
for you to fetch changes up to
101 - 200 of 1014 matches
Mail list logo
