Dave Hansen wrote:
> On 04/15/2013 11:17 AM, Kirill A. Shutemov wrote:
> > I run iozone using mmap files (-B) with different number of threads.
> > The test machine is 4s Westmere - 4x10 cores + HT.
>
> How did you run this, exactly? Which iozone arguments?
iozone -B -s 2186/$threads -t
This patch replace dma_length in "lib/swiotlb.c" to sg_dma_len() macro, because
the build error can occur
if CONFIG_NEED_SG_DMA_LENGTH is not set, and CONFIG_SWIOTLB is set.
I confirmed compile only.
Singed-off-by: EunBong Song
---
lib/swiotlb.c |8
1 files changed, 4
We can extend kexec-tools to support multiple "Crash kernel" in /proc/iomem
instead.
So we can use "Crash kernel" instead of "Crash kernel low" in /proc/iomem.
Suggested-by: Vivek Goyal
Signed-off-by: Yinghai Lu
Acked-by: Vivek Goyal
---
kernel/kexec.c |2 +-
1 file changed, 1
Per hpa, use crashkernel=X,high crashkernel=Y,low instead of
crashkernel_hign=X crashkernel_low=Y. As that could be extensible.
-v2: according to Vivek, change delimiter to ;
-v3: let hign and low only handle simple form and it conforms to
description in kernel-parameters.txt
still
Vivek found some problems with old kexec-tools.
We keep the old crashkernel=X to old behavoir, so it will not break
old kexec-tools.
Add crashkernel=X,high to support new kexec-tools that supports loading high.
when high is used, memblock will search from top to low.
if the allocated one is above
Vivek found old kexec-tools does not work new kernel anymore.
So change back crashkernel= back to old behavoir, and add crashkernel_high=
to let user decide if buffer could be above 4G, and also new kexec-tools will
be needed.
-v2: let crashkernel=X override crashkernel_high=
update
Chao said that kdump does does work well on his system on 3.8
without extra parameter, even iommu does not work with kdump.
And now have to append crashkernel_low=Y in first kernel to make
kdump work.
We have now modified crashkernel=X to allocate memory beyong 4G (if
available) and do not
From 4d629cfb265beece1aae2e3fdf603e36a321f785 Mon Sep 17 00:00:00 2001
From: Runzhen Wang
Date: Mon, 15 Apr 2013 23:17:15 -0400
Subject: [PATCH] perf tool: fix the perf --version bug
The perf --version can't print the right version
information when reset it to an earlier commit.
For example,
From 4d629cfb265beece1aae2e3fdf603e36a321f785 Mon Sep 17 00:00:00 2001
From: Runzhen Wang
Date: Mon, 15 Apr 2013 23:17:15 -0400
Subject: [PATCH] perf tool: fix the perf --version bug
The perf --version can't print the right version
information when reset it to an earlier commit.
For example,
Quoting Stephen Rothwell (2013-04-15 17:55:13)
> Hi Sebastian,
>
> On Mon, 15 Apr 2013 09:00:14 +0200 Sebastian Hesselbarth
> wrote:
> >
> > Calling clk-si5351 driver non-OF ready was too early. This patch
> > makes clk-si5351 depend on CONFIG_OF again, until things get sorted out.
> >
> >
On Tue, 16 Apr 2013 03:45:15 + "Pan, Zhenjie" wrote:
> > Overall the patch looks desirable, but it increases the kernel size by
> > several
> > hundred bytes when CONFIG_CPU_FREQ=n. It should produce no code in
> > this case! Take a look at the magic in register_hotcpu_notifier(), the way
On 4/15/13 7:14 PM, Namhyung Kim wrote:
Makefile:755: The path '/usr/bin/python-config' is not executable.
Makefile:755: *** Please set 'PYTHON_CONFIG' appropriately. Stop.
The problem is that I didn't have python-devel package installed and
get-executable-or-default decides to error out
On Mon, 2013-04-15 at 10:37 -0400, Waiman Long wrote:
[...]
> +typedef struct mspin_node {
> + struct mspin_node *next;
> + intlocked; /* 1 if lock acquired */
> +} mspin_node_t;
> +
> +typedef mspin_node_t *mspin_lock_t;
I think we could do without the typedefs,
From: Thomas Abraham
With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.
Signed-off-by: Thomas Abraham
Signed-off-by: Doug Anderson
Acked-by: Linus Walleij
Reviewed-by: Doug Anderson
>
> On 2013/4/1 17:22, Yijing Wang wrote:
>> Use pci_hp_add_bridge() like most other hotplug drivers
>> rather than call pci_scan_bridge() directly.
>>
>> Signed-off-by: Yijing Wang
>> ---
>> drivers/pci/hotplug/acpiphp_glue.c | 24 ++--
>> 1 files changed, 10
Hello,
The futex-keys of processes share futex determined by page-offset,
mapping-host, and
mapping-index of the user space address.
User appications using hugepage for futex may lead to futex-key conflict.
Assume there
are two or more futexes in diffrent normal pages of the hugepage, and
Thanks for your detail comments, Andrew.
Please see my comments below.
> -Original Message-
> From: Andrew Morton [mailto:a...@linux-foundation.org]
> Sent: Tuesday, April 16, 2013 7:31 AM
> To: Pan, Zhenjie
> Cc: a.p.zijls...@chello.nl; pau...@samba.org; mi...@redhat.com;
>
On 04/14/2013 12:42 AM, Minchan Kim wrote:
Hi KOSAKI,
On Thu, Apr 11, 2013 at 11:01:11AM -0400, KOSAKI Motohiro wrote:
and adding new syscall invokation is unwelcome.
Sure. But one more system call could be cheaper than page-granuarity
operation on purged range.
I don't think
Thanks, Don.
First, I think the frequency of CPU frequency change is depend on the special
platform.
I tested it on Atom Android platform.
When the system is idle(800MHz) or very busy(2000MHz), it's the easiest case.
If do some user operations like move the screen by finger, the cpu will change
On Tue, 9 Apr 2013, Antti Palosaari wrote:
> On 04/08/2013 08:47 PM, Randy Dunlap wrote:
> > From: Randy Dunlap
> >
> > Fix randconfig error when USB is not enabled:
> >
> > ERROR: "usb_control_msg" [drivers/media/common/cypress_firmware.ko]
> > undefined!
> >
> > Signed-off-by: Randy Dunlap
Hi Marcelo,
On 04/16/2013 08:54 AM, Marcelo Tosatti wrote:
> On Mon, Apr 01, 2013 at 05:56:43PM +0800, Xiao Guangrong wrote:
>> Changelog in v2:
>> - rename kvm_mmu_invalid_mmio_spte to kvm_mmu_invalid_mmio_sptes
>> - use kvm->memslots->generation as kvm global generation-number
>> - fix
Commit 3de4ad210387 ("perf/x86: Fix offcore_rsp valid mask for SNB/IVB")
in perf/urgent breaks the build:
arch/x86/kernel/cpu/perf_event_intel.c:158:2: error: implicit declaration of
function 'INTEL_UEVENT_PEBS_LDLAT_EXTRA_REG'
[-Werror=implicit-function-declaration]
From: Eric Dumazet
On Mon, 2013-04-15 at 17:37 -0700, Eric Dumazet wrote:
> On Mon, 2013-04-15 at 16:57 +0300, Vitaly V. Bursov wrote:
> > Hello,
> >
> > I have a bonding device (mode=802.3ad xmit_hash_policy=layer2+3 miimon=300)
> > and
> > for kernels <3.7 forwarded IPv4 traffic distributed
From: Zhang Yi
Hello,
The function handle_futex_death just wakes one thread, which may be not
enough when the owner process is dead. Think about this scene：
1. A robust futex is shared for two processes, each process has multi
threads try to get the lock.
2. One of the threads gets the lock,
On Mon, Apr 15, 2013 at 12:14:29PM -0500, Robin Holt wrote:
> We recently noticed that reboot of a 1024 cpu machine takes approx 16
> minutes of just stopping the cpus. The slowdown was tracked to commit
> f96972f.
>
> The current implementation does all the work of hot removing the cpus
> before
On Mon, Apr 15, 2013 at 7:36 PM, H. Peter Anvin wrote:
> On 04/15/2013 03:00 PM, Yinghai Lu wrote:
>>
>> looks you are trying redo the work for bootloader to pick loaded phys addr.
>>
>
> Well, that is exactly what they are doing. On top of that they also
> need to randomize the 64-bit virtual
On Mon, Apr 15, 2013 at 6:44 PM, Wang YanQing wrote:
>
> The parameter of memblock_reserve is start address,
> and size, not address range.
>
> Signed-off-by: Wang YanQing
> ---
> drivers/acpi/osl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/osl.c
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in
drivers/acpi/scan.c between commit 5c0b04e3d913 ("PCI/ACPI: Handle PCI
slot devices when creating/destroying PCI buses") from the pci tree and
commit 0a34764411aa ("ACPI / scan: Make memory hotplug driver use struct
On 04/15/2013 07:31 PM, H. Peter Anvin wrote:
>
> I also am starting to think that this really would be done better being
> integrated with the decompressor code, since that code already ends up
> moving the code around... no reason to do this again.
>
Another good reason to do this in the
On 04/15/2013 03:00 PM, Yinghai Lu wrote:
>
> looks you are trying redo the work for bootloader to pick loaded phys addr.
>
Well, that is exactly what they are doing. On top of that they also
need to randomize the 64-bit virtual mapping.
I wonder if we need a bootloader bit to inhibit kaslr
On 04/15/2013 03:38 PM, Yinghai Lu wrote:
> On Mon, Apr 15, 2013 at 3:07 PM, Kees Cook wrote:
>> On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu wrote:
>>> also do not overlap with boot_param, command_line, and initrd.
>>>
>>> and need to double check setup_header.init_size to make sure bss and
>>>
On 04/15/2013 02:59 PM, Kees Cook wrote:
>>
>> The *physical* mapping, where it lands in RAM, is completely
>> independent, and if you're going to randomize the latter, there is no
>> reason it has to match the former. Instead, randomize it freely.
>
> Ah, gotcha. I don't see much benefit in
On Mon, Apr 01, 2013 at 05:56:43PM +0800, Xiao Guangrong wrote:
> Changelog in v2:
> - rename kvm_mmu_invalid_mmio_spte to kvm_mmu_invalid_mmio_sptes
> - use kvm->memslots->generation as kvm global generation-number
> - fix comment and codestyle
> - init kvm generation close to mmio
Hi Pekka,
On Mon, 15 Apr 2013 13:58:50 +0300, Pekka Enberg wrote:
> Hello,
>
> I'm seeing this when I try to build perf in v3.9-rc7:
>
> [penberg@golgotha perf]$ make
> CHK -fstack-protector-all
> CHK -Wstack-protector
> CHK -Wvolatile-register-var
> CHK -D_FORTIFY_SOURCE=2
>
Haojian,
> -Original Message-
> From: Neil Zhang
> Sent: 2013年4月15日 19:10
> To: 'Haojian Zhuang'
> Cc: Grant Likely; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; Chao Xie
> Subject: RE: [PATCH 1/4] ARM: mmp: add wakeup function for ICU
>
>
>
>
>
> >
On 2013/4/15 22:15, Jonghwan Choi wrote:
> From: libin
>
> This patch looks like it should be in the 3.8-stable tree, should we apply
> it?
>
yes, I think this patch should be applied to the 3.8-stable tree. Thanks.
Libin
> --
>
> From: "libin "
>
> commit
Hi Yinghai,
Any comments about this patch? I searched the code history and found
you introduced pci_hp_add_bridge() function at commit a8e4b9c10. In your
patchset use pci_hp_add_bridge() for all pci hotplug drivers except acpiphp.
So I use pci_hp_add_bridge() in acpiphp instead of using
Sarah,
Thanks so much for improving the REPORTING-BUGS file. With your
changes it looks way better!
- Ted
--
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
The parameter of memblock_reserve is start address,
and size, not address range.
Signed-off-by: Wang YanQing
---
drivers/acpi/osl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 586e7e9..bcb7a3b 100644
--- a/drivers/acpi/osl.c
On Fri, Apr 12, 2013 at 12:36:00PM -0700, Kent Overstreet wrote:
> It would be nice if we had unsigned atomic types... but given that we
> don't and I'm pretty sure overflow in atomic types happens all over the
> place that part honestly seems fine to me...
>
> That said, I suppose a comment
The memblock_find_in_range return value, addr, will
make sure "addr + aper_size" not beyond GART_MAX_ADDR.
Signed-off-by: Wang YanQing
---
arch/x86/kernel/aperture_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/aperture_64.c
On Mon, 2013-04-15 at 09:30 -0400, Eduardo Valentin wrote:
> On 13-04-2013 19:46, Ville Syrjälä wrote:
> > On Sun, Apr 14, 2013 at 12:44:00AM +0300, Ville Syrjälä wrote:
> >> On Sat, Apr 13, 2013 at 10:02:21AM -0600, Jake Edge wrote:
> >>> Hi Zhang Rui,
> >>>
> >>> The problem reported in
Andrew Morton writes:
> On Fri, 12 Apr 2013 15:28:56 -0700 Kent Overstreet
> wrote:
>> Those are the main changes (besides adding attributes, of course) that
>> I've made so far.
>>
>> * Get rid of the parallel syscall interface
>>
>>AIO really shouldn't be implementing its own
On Mon, 15 Apr 2013, Michel Lespinasse wrote:
> On Mon, Apr 15, 2013 at 2:47 PM, Hugh Dickins wrote:
> > --- 3.9-rc7/mm/mlock.c 2013-04-01 09:08:05.736012852 -0700
> > +++ linux/mm/mlock.c2013-04-15 14:20:24.454773245 -0700
> > @@ -397,8 +397,7 @@ int __mm_populate(unsigned long start, u
> >
I think the linux.git "system hang" isn't really a hang. For some reason the
panic text wasn't displayed on the console. I've seen this behaviour a few
times now ... maybe there's a bug in the panic output path?
I also haven't determined why I'm seeing a thermal interrupt during a CPU
hotplug
On 2013年04月15日 13:48, Rusty Russell wrote:
> Chen Gang writes:
>
>> > We don't export any symbols > 128 characters, but if we did then
>> > kallsyms_expand_symbol() would overflow the buffer handed to it.
>> > So we need check destination buffer length when copying.
>> >
>> > the related
Update debugging messages to a more current style.
Emit these debugging messages at KERN_DEBUG instead
of KERN_DEFAULT.
Add and use neigh_dbg(level, fmt, ...) macro
Add dynamic_debug capability via pr_debug
Convert embedded function names to "%s: ", __func__
Signed-off-by: Joe Perches
---
When hot removing memory presented at boot time, following messages are shown:
[ 296.867031] [ cut here ]
[ 296.922273] kernel BUG at mm/slub.c:3409!
[ 296.970229] invalid opcode: [#1] SMP
[ 297.019453] Modules linked in: ebtable_nat ebtables xt_CHECKSUM
On Sun, Mar 10, 2013 at 07:41:06PM +0100, Jiri Olsa wrote:
> Adding RF EFLAGS bit to be restored on return from signal from
> the original register context before the signal was entered.
>
> This will prevent the RF flag to disappear when returning
> from exception due to the signal handler being
Hi Sebastian,
On Mon, 15 Apr 2013 09:00:14 +0200 Sebastian Hesselbarth
wrote:
>
> Calling clk-si5351 driver non-OF ready was too early. This patch
> makes clk-si5351 depend on CONFIG_OF again, until things get sorted out.
>
> Signed-off-by: Sebastian Hesselbarth
> Reported-by: Stephen
On Tuesday, April 16, 2013 8:07 AM, Andrew Morton wrote:
>
> On Thu, 11 Apr 2013 13:24:50 -0700 Andrew Bresticker
> wrote:
>
> > Platform LCD devices may need to do some device-specific
> > initialization before they can be used (regulator or GPIO setup,
> > for example), but currently the
On 2013/4/15 20:48, Libin wrote:
> (*->vm_end - *->vm_start) >> PAGE_SHIFT operation is implemented
> as a inline funcion vma_pages() in linux/mm.h, so using it.
>
> Signed-off-by: Libin
> ---
> drivers/char/mspec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Sun, Apr 14, 2013 at 09:12:32PM +0200, Oleg Nesterov wrote:
> ptrace_write_dr7() skips ptrace_modify_breakpoint(disabled => true)
> unless second_pass, this buys nothing but complicates the code and
> means that we always do the main loop twice even if "disabled" was
> never true.
>
> The
On Mon, Apr 15, 2013 at 04:02:56PM -0700, Yinghai Lu wrote:
> On Mon, Apr 15, 2013 at 3:41 PM, 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
> >
>
> > diff
On Mon, Apr 15, 2013 at 4:59 PM, Rob Herring wrote:
> On 04/15/2013 05:21 PM, Colin Cross wrote:
>> On Wed, Apr 10, 2013 at 6:30 AM, Rob Herring wrote:
>>> On 04/09/2013 10:53 PM, Colin Cross wrote:
On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring wrote:
> From: Rob Herring
>
>
Quoting Sebastian Hesselbarth (2013-04-15 00:03:23)
> On 04/15/2013 07:04 AM, Stephen Rothwell wrote:
> > After merging the clk tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > ERROR: "of_clk_add_provider" [drivers/clk/clk-si5351.ko] undefined!
> > ERROR:
On Mon, 2013-04-15 at 16:57 +0300, Vitaly V. Bursov wrote:
> Hello,
>
> I have a bonding device (mode=802.3ad xmit_hash_policy=layer2+3 miimon=300)
> and
> for kernels <3.7 forwarded IPv4 traffic distributed fine across multiple
> physical
> links. Ethernet cards are Intel 82576 with igb driver
Hi Toshi,
2013/04/16 5:01, Toshi Kani wrote:
On Mon, 2013-04-15 at 11:15 +0900, Yasuaki Ishimatsu wrote:
When hot removing memory presented at boot time, following messages are shown:
:
The reason why the messages are shown is to release a resource structure,
allocated by bootmem, by
On 04/16/2013 07:12 AM, Borislav Petkov wrote:
> On Mon, Apr 15, 2013 at 09:50:22PM +0800, Alex Shi wrote:
>> For fairness and total threads consideration, powersaving cost quit
>> similar energy on kbuild benchmark, and even better.
>>
>> 17348.850 27400.458
On Mon, Apr 15, 2013 at 2:47 PM, Hugh Dickins wrote:
> --- 3.9-rc7/mm/mlock.c 2013-04-01 09:08:05.736012852 -0700
> +++ linux/mm/mlock.c2013-04-15 14:20:24.454773245 -0700
> @@ -397,8 +397,7 @@ int __mm_populate(unsigned long start, u
> long ret = 0;
>
> VM_BUG_ON(start &
Greg KH twisted the bytes to say:
>> http://o.cs.uvic.ca:20810/perl/next.pl
Greg> Yes, that's a great thing. Maybe the ability to see the subject: line
Greg> of the commit somewhere easier than having to click through to the patch
Greg> would be nice, so we can just glance at the report
Hi Ohad,
On Mon, 15 Apr 2013 09:28:17 +0300 Ohad Ben-Cohen wrote:
>
> Could you please add:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next
>
> to linux-next to include new stuff coming from Rob?
Well, you could tell me something about it. Like what is in it and how
On Sun, Apr 14, 2013 at 09:12:28PM +0200, Oleg Nesterov wrote:
> ptrace_write_dr7() looks unnecessarily overcomplicated. We can
> factor out ptrace_modify_breakpoint() and do not do "continue"
> twice, just we need to pass the proper "disabled" argument to
> ptrace_modify_breakpoint().
>
>
On 04/15/2013 05:21 PM, Colin Cross wrote:
> On Wed, Apr 10, 2013 at 6:30 AM, Rob Herring wrote:
>> On 04/09/2013 10:53 PM, Colin Cross wrote:
>>> On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring wrote:
From: Rob Herring
Atomic operations are undefined behavior on ARM for device or
On Mon, 15 Apr 2013 14:46:19 -0700 Andrew Morton
wrote:
>
> Well, this is also a thing arch maintainers can do when they feel a
> need to support the feature on their architecture. To support them at
> that time we should provide them with a) adequate information in an
> easy-to-find place (eg,
This adds a generic async_memcpy() for the DMA engines that cannot do channel
switch. Previously it would exclude all DMA engines that don't have all equal
capabilities for all ops with the DMA_ASYNC_TX check. The RAID version of
async memcpy will only request RAID capable channels. This allow us
2013/04/16 6:00, Toshi Kani wrote:
On Mon, 2013-04-15 at 14:48 +0900, Yasuaki Ishimatsu wrote:
When hot removing a memory, a firmware_map_entry which has memory range
of the memory is released by release_firmware_map_entry(). If the entry
is allocated by bootmem, release_firmware_map_entry()
2013/04/15 18:03, Tang Chen wrote:
>
> Reviewed-by: Tang Chen
Thank you for your review.
Thanks,
Yasuaki Ishimatsu
>
> Thanks. :)
>
> On 04/15/2013 01:48 PM, Yasuaki Ishimatsu wrote:
>> When hot removing a memory, a firmware_map_entry which has memory range
>> of the memory is released by
On Sun, Apr 14, 2013 at 09:12:05PM +0200, Oleg Nesterov wrote:
> Hello.
>
> On top of "[PATCH 0/5] kill ptrace_{get,put}_breakpoints()".
> Cleanup and preparation for the potential fix, see below.
>
> --
> Now the
On Mon, 1 Apr 2013 03:47:42 + "Pan, Zhenjie" wrote:
> Watchdog use performance monitor of cpu clock cycle to generate NMI to detect
> hard lockup.
> But when cpu's frequency changes, the event period will also change.
> It's not as expected as the configuration.
> For example, set the NMI
On Tue, Apr 09, 2013 at 12:21:48PM -0500, Jacob Shin wrote:
> The following patchset adds address masks to existing perf hardware
> breakpoint mechanism to allow trapping on an address range (currently
> only single address) on supported architectures.
>
> perf uapi is updated, x86 AMD
On 04/15/2013 11:17 AM, Kirill A. Shutemov wrote:
> I run iozone using mmap files (-B) with different number of threads.
> The test machine is 4s Westmere - 4x10 cores + HT.
How did you run this, exactly? Which iozone arguments? It was run on
ramfs, since that's the only thing that transparent
Chen Gang writes:
> We don't export any symbols > 128 characters, but if we did then
> kallsyms_expand_symbol() would overflow the buffer handed to it.
> So we need check destination buffer length when copying.
>
> the related test:
> if we define an EXPORT function which name more
Sasha Levin writes:
> Add basic documentation for virtio-9p. I can expand more on device operation,
> but I don't think there's anything significant enough for the spec to be
> mentioned there. Please let me know if I'm wrong.
>
> Signed-off-by: Sasha Levin
Hmm, I guess so. I was happy to
On Mon, Apr 15, 2013 at 09:50:22PM +0800, Alex Shi wrote:
> For fairness and total threads consideration, powersaving cost quit
> similar energy on kbuild benchmark, and even better.
>
> 17348.850 27400.458 15973.776
> 13737.493
On Mon, 15 Apr 2013, Greg Kroah-Hartman wrote:
> > The positive numbers are used to return information on the remaining
> > cache size (again, see the comment I pasted above). We could use
> > -EBUSY, but we'd have to change vmscan.c, which checks specifically
> > for -1. I can't see a technical
On Mon, Apr 15, 2013 at 02:49:34PM -0700, D M German wrote:
>
>
> Greg KH twisted the bytes to say:
>
> Greg> But, for the linux-next stuff, that could be very interesting. We
> Greg> always like seeing what commits in a -rc1 release did NOT previously
> Greg> show up in linux-next.
On Thu, 11 Apr 2013 13:24:50 -0700 Andrew Bresticker
wrote:
> Platform LCD devices may need to do some device-specific
> initialization before they can be used (regulator or GPIO setup,
> for example), but currently the driver does not support any way of
> doing this. This patch adds a probe()
On Mon, Apr 15, 2013 at 3:41 PM, 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 errata
>
On Sun, Apr 14, 2013 at 06:05:41PM +0200, Oleg Nesterov wrote:
> This reverts commit bf26c018490c2fce7fe9b629083b96ce0e6ad019.
>
> The patch was fine but we can no longer race with SIGKILL after
> 9899d11f "ptrace: ensure arch_ptrace/ptrace_request can never race
> with SIGKILL", the
On Mon, Apr 15, 2013 at 3:42 PM, Kees Cook wrote:
> On Mon, Apr 15, 2013 at 3:38 PM, Yinghai Lu wrote:
>
>> so the decompressed image is not moved high?
>
> No, I mean the size of the relocated image is using z_extract_offset
> as the end size of the relocated memory. See select_aslr_address. It
When CONFIG_XHCI_HCD_DEBUGGING is activated, the XHCI driver can dump
device and input contexts to the console. The endpoint contexts in that
dump are labeled "Endpoint N Context", where N is the XHCI endpoint
index (DCI - 1). This can be very confusing, especially for people who
are not that
On Sun, Apr 14, 2013 at 06:05:26PM +0200, Oleg Nesterov wrote:
> This reverts commit 87dc669ba25777b67796d7262c569429e58b1ed4.
>
> The patch was fine but we can no longer race with SIGKILL after
> 9899d11f "ptrace: ensure arch_ptrace/ptrace_request can never race
> with SIGKILL", the
On Mon, Apr 15, 2013 at 04:55:04PM -0400, Don Zickus wrote:
> On Fri, Apr 12, 2013 at 02:30:24PM -0700, Guenter Roeck wrote:
> > On Fri, Apr 12, 2013 at 05:16:27PM -0400, Don Zickus wrote:
> > > On Wed, Apr 10, 2013 at 08:10:41AM -0700, Guenter Roeck wrote:
> > > > > have no idea how to even find
On Mon, Apr 15, 2013 at 3:38 PM, Yinghai Lu wrote:
> On Mon, Apr 15, 2013 at 3:07 PM, Kees Cook wrote:
>> On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu wrote:
>>> also do not overlap with boot_param, command_line, and initrd.
>>>
>>> and need to double check setup_header.init_size to make sure
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 Mon, Apr 15, 2013 at 3:07 PM, Kees Cook wrote:
> On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu wrote:
>> also do not overlap with boot_param, command_line, and initrd.
>>
>> and need to double check setup_header.init_size to make sure bss and
>> etc will not
>> fall into memory hole or reserved
On Mon, Apr 15, 2013 at 09:55:20PM +0100, David Woodhouse wrote:
> On Sun, 2013-04-14 at 19:17 -0700, Greg Kroah-Hartman wrote:
> > 3.0-stable review patch. If anyone has any objections, please let me know.
>
> Please use f5cf8f07423b2677cebebcebc863af77223a4972 instead (for 3.4
> too).
Really?
On Fri, 12 Apr 2013 15:28:56 -0700 Kent Overstreet
wrote:
> So, awhile back I posted about an extensible AIO attributes mechanism
> I'd been cooking up: http://article.gmane.org/gmane.linux.kernel/1367969
>
> Since then, more uses for the thing have been popping up, but I ran into
> a
Built next-20130415 and got this on ia64 early in boot:
WARNING: at kernel/cpu/idle.c:94 cpu_idle_loop+0x360/0x380()
Hardware name: server rx2620
Modules linked in:
Call Trace:
[] show_stack+0x80/0xa0
sp=a00101287c50 bsp=a00101280e48
[] dump_stack+0x30
On Mon, Apr 08, 2013 at 05:18:25PM -0700, Julius Werner wrote:
> diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
> index 5f3a7c7..16a8272 100644
> --- a/drivers/usb/host/xhci-dbg.c
> +++ b/drivers/usb/host/xhci-dbg.c
> @@ -503,11 +503,14 @@ static void xhci_dbg_ep_ctx(struct
Andrew Murray, Thomas,
On Thu, Apr 11, 2013 at 04:26:06PM +0100, Andrew Murray wrote:
> This patchset factors out duplicated code associated with parsing PCI
> DT "ranges" properties across the architectures and introduces a
> "ranges" parser. This parser "of_pci_range_parser" can be used
On Wed, Apr 10, 2013 at 6:30 AM, Rob Herring wrote:
> On 04/09/2013 10:53 PM, Colin Cross wrote:
>> On Tue, Apr 9, 2013 at 8:08 PM, Rob Herring wrote:
>>> From: Rob Herring
>>>
>>> Atomic operations are undefined behavior on ARM for device or strongly
>>> ordered memory types. So use
On Mon, Apr 15, 2013 at 3:00 PM, Yinghai Lu wrote:
> On Mon, Apr 15, 2013 at 2:46 PM, H. Peter Anvin wrote:
>> On 04/15/2013 02:41 PM, Kees Cook wrote:
>
>> Please read what I wrote.
>>
>> The 2 GB limit is for the *virtual* mapping.
>>
>> The *physical* mapping, where it lands in RAM, is
On Mon, Apr 15, 2013 at 05:54:15PM +0200, Borislav Petkov wrote:
> On Mon, Apr 15, 2013 at 12:18:25PM +0200, Ingo Molnar wrote:
> > It was tip:master with x86/cpu merged in freshly.
>
> Ok, some more observations. I can trigger some oops similar yours (I
> haven't caught mine yet over serial or
On Mon, Apr 15, 2013 at 2:46 PM, H. Peter Anvin wrote:
> On 04/15/2013 02:41 PM, Kees Cook wrote:
> Please read what I wrote.
>
> The 2 GB limit is for the *virtual* mapping.
>
> The *physical* mapping, where it lands in RAM, is completely
> independent, and if you're going to randomize the
On Mon, Apr 15, 2013 at 2:46 PM, H. Peter Anvin wrote:
> On 04/15/2013 02:41 PM, Kees Cook wrote:
>>>
>>> You seem to be missing something here...
>>>
>>> There are *two* mappings in 64-bit mode. Physically, if you're going to
>>> randomize you might as well randomize over the entire range...
Benjamin, All,
On Mon, Apr 15, 2013 at 10:13:50AM -0400, Benjamin Poirier wrote:
> Fixes the memory leak of struct jump_key allocated in get_prompt_str()
Queued into:
https://git.gitorious.org/linux-kconfig/linux-kconfig.git yem-kconfig-rc-fixes
Although this is strictly a bug fix, I would lean
On Fri, 12 Apr 2013 16:49:50 +0200 Matthieu CASTET
wrote:
> Hi Andrew,
>
> thanks for your quick review.
>
> Andrew Morton a __crit :
> > On Thu, 11 Apr 2013 15:53:09 +0200 Matthieu CASTET
> > wrote:
> >
> >> The current code return the address instead of using PTR_ERR.
> >
> > I don't
Greg KH twisted the bytes to say:
Greg> But, for the linux-next stuff, that could be very interesting. We
Greg> always like seeing what commits in a -rc1 release did NOT previously
Greg> show up in linux-next. Stephen has some tools on how to do this, it
Greg> would be interesting to see
1 - 100 of 1152 matches
Mail list logo
