From: Bartlomiej Zolnierkiewicz
Subject: [PATCH] DMA: add cpu_relax() to busy-loop in dma_sync_wait()
Removal of the busy-loop from dma_sync_wait() is not a trivial
task so just add cpu_relax() to the loop for now.
Cc: Vinod Koul
Cc: Dan Williams
Cc: Tomasz Figa
Signed-off-by: Bartlomiej
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH] DMA: remove unused support for MEMSET operations
There have never been any real users of MEMSET operations
since they have been introduced in January 2007 (commit
7405f74badf46b5d023c5d2b670b4471525f6c91 "dmaengine: refactor
dmaengine around
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH] async_tx: fix checking of dma_wait_for_async_tx() return value
dma_wait_for_async_tx() can also return DMA_PAUSED (which
should be considered as error).
Cc: Vinod Koul
Cc: Dan Williams
Cc: Tomasz Figa
Signed-off-by: Bartlomiej Zolnierkiewicz
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH 2/2] DMA: remove dma_async_memcpy_complete() macro
Just use dma_async_is_tx_complete() directly.
Cc: Vinod Koul
Cc: Dan Williams
Cc: Tomasz Figa
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH 1/2] DMA: remove dma_async_memcpy_issue_pending() macro
Just use dma_async_issue_pending() directly.
Cc: Vinod Koul
Cc: Dan Williams
Cc: Tomasz Figa
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
Hi,
> It happens on several machines and this only seem to happen if there
> was a wrap around in the log buffer (it's a first observation on a
> limited number of sample so it might be a coincidence)
I think the culprit is print_time and has nothing to do with wrap
around, just the uptime.
sg_virt() on highmem pages won't work. This WARN_ON() should catch some
that still try.
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/scatterlist.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index
Hi Federico,
Em 04-12-2012 23:12, Federico Vaga escreveu:
On Tuesday 04 December 2012 14:15:15 Mauro Carvalho Chehab wrote:
Em 24-09-2012 07:58, Federico Vaga escreveu:
This patch re-write the driver and use the videobuf2
interface instead of the old videobuf. Moreover, it uses also
the
On 05.12.2012 13:13, Thierry Reding wrote:
> What I propose is to move the client registration code that is currently
> in drivers/gpu/drm/tegra/host1x.c to the host1x driver, which may or may
> not end up in drivers/gpu/host1x.
Ok.
>
>> host1x hardware access must be encapsulated in host1x
2012/12/5, OGAWA Hirofumi :
> Namjae Jeon writes:
>
Let me think, if ‘subtree’ checking is enabled then we should check
the length condition over here also? Please share if there are any
other comments also.
>>>
>>> I'm not sure what did you mean. Where is "subtree" check you are
From: Lad, Prabhakar
add support for per color component digital/analog gain controls
and also their corresponding offset.
Signed-off-by: Lad, Prabhakar
Cc: Sakari Ailus
Cc: Laurent Pinchart
Cc: Kyungmin Park
Cc: Guennadi Liakhovetski
Cc: Sylwester Nawrocki
Cc: Hans Verkuil
Cc: Hans de
2012/12/5, OGAWA Hirofumi :
> Namjae Jeon writes:
>
> This became much better than before. However, we have to consolidate
> the
> code with fat_search_long() finally.
>
> E.g. this version is having the issue already fixed. If there is
> corruption in fat cluster-chain,
Am Mittwoch, den 05.12.2012, 13:47 +0200 schrieb Terje Bergström:
[...]
>
> > The problem that this solves is that the DRM driver needs to be bound to
> > a specific platform device. None of the DRM subdevices are suitable
> > because they are only part of the whole DRM device. I think that
On Mon 26-11-12 14:55:09, Herton Ronaldo Krzesinski wrote:
> 3.5.7u1 -stable review patch. If anyone has any objections, please let me
> know.
Note that this fix causes another problem which is fixed by
25389bb207987b5774182f763b9fb65ff08761c8 upstream.
On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström wrote:
> You're right in that binding to a sub-device is not a nice way. DRM
> framework just needs a "struct device" to bind to. exynos seems to solve
> this by introducing a virtual device and bind to that. I'm not sure if
> this is the best way,
Hi Avinash,
On 11/29/2012 5:16 PM, Philip, Avinash wrote:
> Update number of errors using nand ecc strength.
> Also add macro definitions BCH8_ERROR_MAX & BCH4_ERROR_MAX
Can you please describe why the original method of setting nerrors was
incorrect? Was it causing any issues in any particular
On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
> On 05.12.2012 13:13, Thierry Reding wrote:
[...]
> > Oh well, at the time nobody from NVIDIA was involved so I wrote that
> > code in preparation for proper host1x support that I thought I would
> > have to add myself at some
On Wed, Dec 5, 2012 at 1:03 PM, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström
> wrote:
>> You're right in that binding to a sub-device is not a nice way. DRM
>> framework just needs a "struct device" to bind to. exynos seems to solve
>> this by introducing a virtual
On 2012/12/5 7:23, Toshi Kani wrote:
> On Tue, 2012-12-04 at 17:16 +0800, Hanjun Guo wrote:
>> On 2012/12/4 8:10, Toshi Kani wrote:
>>> On Mon, 2012-12-03 at 12:25 +0800, Hanjun Guo wrote:
On 2012/11/30 6:27, Toshi Kani wrote:
> On Thu, 2012-11-29 at 12:48 +0800, Hanjun Guo wrote:
>>
Namjae Jeon writes:
>> I can understand what is doing. I'm asking why there is difference.
>>
>> 1) generic_fh_to_dentry() allows (*_PARENT && fh_len == 2).
>> 2) fat_fh_to_dentry_nostale() doesn't allows (*_PARENT && fh_len == 3).
>>
>> Why does logic has difference?
>
> When we consider the
On Mon 26-11-12 18:17:40, Darrick J. Wong wrote:
> On Thu, Nov 22, 2012 at 10:12:40AM +0100, Jan Kara wrote:
> > On Wed 21-11-12 17:47:55, Darrick J. Wong wrote:
> > > On Thu, Nov 22, 2012 at 08:47:13AM +1100, NeilBrown wrote:
> > > > On Wed, 21 Nov 2012 22:33:33 +0100 Jan Kara wrote:
> > > >
>
(resend without HTML formatting)
On Wed 5 December 2012 12:49:29 Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> add support for per color component digital/analog gain controls
> and also their corresponding offset.
Some obvious questions below...
>
> Signed-off-by: Lad, Prabhakar
> Cc:
Thank you Mauro for the good explanation
> Yeah, there are many changes there that justifies adding you at its
> authorship, and that's ok. Also, anyone saying the size of your patch
> will recognize your and ST efforts to improve the driver.
>
> However, as some parts of the code were
As they are used from diff and event group report, add a test case to
verify their behaviors.
In this test I made a fake machine and two evsel. Each evsel got 10
samples (so hist entries) - 5 are common and the rests are not. So
after hists__match() both of them will have 5 entries with pair
On Wed, Dec 05, 2012 at 01:03:14PM +0100, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström
> wrote:
> > You're right in that binding to a sub-device is not a nice way. DRM
> > framework just needs a "struct device" to bind to. exynos seems to solve
> > this by introducing
On Wed, Dec 5, 2012 at 1:22 PM, Thierry Reding
wrote:
> Maybe something more elaborate could help, though. Suppose we add
> functionality to DRM to instantiate a DRM device. We could call such a
> function from the host1x driver to add a device which the tegra-drm
> driver could bind to. This
Hi!
> >Agreed. If I understand you correctly though, your approach is specific
> >to a particular hardware implementation (Zynq) on the user interface layer,
> >which I think is exactly what we should avoid. Obviously, there is
> >always a driver involved that is specific to the IP block you load
Takashi Iwai wrote:
> From: Takashi Iwai
> Subject: [PATCH v2] MODSIGN: Avoid using .incbin in C source
>
> Using the asm .incbin statement in C sources breaks any gcc wrapper which
> assumes that preprocessed C source is self-contained. Use a separate .S
> file to include the siging key and
On 12/05/2012 03:40 AM, Andrew Morton wrote:
> On Tue, 04 Dec 2012 14:23:41 +0530
> "Srivatsa S. Bhat" wrote:
>
>> From: Michael Wang
>>
>> There are places where preempt_disable() is used to prevent any CPU from
>> going offline during the critical section. Let us call them as "atomic
>>
On 12/05/2012 03:47 AM, Andrew Morton wrote:
> On Tue, 04 Dec 2012 14:24:28 +0530
> "Srivatsa S. Bhat" wrote:
>
>> From: Michael Wang
>>
>> With stop_machine() gone from the CPU offline path, we can't depend on
>> preempt_disable() to prevent CPUs from going offline from under us.
>>
>> Use the
On Wed, Dec 05, 2012 at 12:08:12PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The header of acpi_dev_pm_detach() in include/linux/acpi.h has an
> incorrect return type, which should be void. Fix that.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mika Westerberg
>
On Wed, Dec 05, 2012 at 17:33:37, Nori, Sekhar wrote:
> Hi Avinash,
>
> On 11/29/2012 5:16 PM, Philip, Avinash wrote:
> > Update number of errors using nand ecc strength.
> > Also add macro definitions BCH8_ERROR_MAX & BCH4_ERROR_MAX
>
> Can you please describe why the original method of setting
On 12/05/2012 05:09 AM, Rusty Russell wrote:
> "Srivatsa S. Bhat" writes:
>> From: Michael Wang
>>
>> With stop_machine() gone from the CPU offline path, we can't depend on
>> preempt_disable() to prevent CPUs from going offline from under us.
>
> Minor gripe: I'd prefer this paragraph to use
On Tuesday 04 December 2012 14:04:22 Mauro Carvalho Chehab wrote:
> Em 24-09-2012 09:44, Marek Szyprowski escreveu:
> > Hello,
> >
> > On Monday, September 24, 2012 12:59 PM Federico Vaga wrote:
> >> The DMA streaming allocator is similar to the DMA contig but it use the
> >> DMA streaming
I am deeply sorry.
I was busy first time I read this, so I postponed answering and ended up
forgetting.
Sorry
>>
>> include/linux/sched.h:
>> unsigned long long run_delay; /* time spent waiting on a runqueue */
>>
>> So if you are out of the runqueue, you won't get steal time accounted,
>> and
Hi!
> I've seen the LTP open posix mmap/{11-4,11-5} issues in the past myself
> and was something I wanted to discuss on the lists myself. Thanks for
> bringing this up.
>
> Jut to reiterate: the expectations are
>
> 1. zero filling of unmapped (trailing) partial page
> 2. NO Writeout (to disk)
The root of problem is carelessly zeroing pointer(in function
__tty_buffer_flush()),
when another thread can use it. It can be cause of "NULL pointer dereference".
Main idea of the patch, this is never free last (struct tty_buffer) in the
active buffer.
Only flush the data for
The i2c_device_id table is supposed to be zero-terminated.
Signed-off-by: Axel Lin
---
drivers/mfd/tps80031.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/tps80031.c b/drivers/mfd/tps80031.c
index f64005e..10b51f7 100644
--- a/drivers/mfd/tps80031.c
+++
Ping!!!
On 1 December 2012 00:33, Viresh Kumar wrote:
> On 30 November 2012 21:15, Lee Jones wrote:
>> But ... I don't see how the changes in the -i2c and -spi files
>> are of benefit either. When I boot without the ID table I still
>> get "stmpe-i2c 0-0040: stmpe1601 detected, chip id: 0x212".
Em 05-12-2012 10:24, Federico Vaga escreveu:
Thank you Mauro for the good explanation
Yeah, there are many changes there that justifies adding you at its
authorship, and that's ok. Also, anyone saying the size of your patch
will recognize your and ST efforts to improve the driver.
However, as
Dear Jan,
> x86 debug registers are already very scarce. Besides that userland
> applications know they have 4 of them available so it would also break
> them.
If a userland application wants to cheat, then it has no need to bypass
the debug registers: even if there were 4096 of them, covering
> Ping!!!
Documentation/development-process/2.Process:
- Avoid top-posting (the practice of putting your answer above the quoted
text you are responding to). It makes your response harder to read and
makes a poor impression.
:)
> On 1 December 2012 00:33, Viresh Kumar wrote:
> > On 30
This driver uses regmap_irq APIs, thus need to select REGMAP_IRQ.
IRQ_DOMAIN will be selected if select REGMAP_IRQ, thus remove it here.
This fixes below build errors:
drivers/built-in.o: In function `tps80031_remove':
drivers/mfd/tps80031.c:534: undefined reference to `regmap_del_irq_chip'
> > Ok, I understand. I will write something like this.
> >
> > * Copyright (C) 2012 ST Microelectronics
> > * author: Federico Vaga
> > * Copyright (C) 2010 WindRiver Systems, Inc.
> > * authors: Andreas Kies
> > * Vlad Lungu
>
> Sounds perfect
On 5 December 2012 18:49, Lee Jones wrote:
>> Ping!!!
>
> Documentation/development-process/2.Process:
>
> - Avoid top-posting (the practice of putting your answer above the quoted
> text you are responding to). It makes your response harder to read and
> makes a poor impression.
Yes, i
On Wed, Dec 05, 2012 at 01:31:54PM +0100, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 1:22 PM, Thierry Reding
> wrote:
> > Maybe something more elaborate could help, though. Suppose we add
> > functionality to DRM to instantiate a DRM device. We could call such a
> > function from the host1x
Em 05-12-2012 11:27, Federico Vaga escreveu:
Ok, I understand. I will write something like this.
* Copyright (C) 2012 ST Microelectronics
* author: Federico Vaga
* Copyright (C) 2010 WindRiver Systems, Inc.
* authors: Andreas Kies
* Vlad
> Not sure if you got my point: the main point of removing MODULE_AUTHOR
> and other copyright stuff is that such patch may easily be doing something
> that could be considered a copyright violation, being bad not only to
> the affected driver, but to the entire Kernel.
>
> So, we need to handle
File descriptors (even those for writing) do not hold freeze protection.
Thus mark_files_ro() must call __mnt_drop_write() to only drop protection
against remount read-only. Calling mnt_drop_write_file() as we do now
results in:
[ BUG: bad unlock balance detected! ]
3.7.0-rc6-00028-g88e75b6 #101
The "%5lu" part of the sprintf only guarantees a minimum length,
not a maximum one. This patch should make it correct for any
possible timestamp.
Signed-off-by: Sylvain Munaut
---
kernel/printk.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git
On Wed 05-12-12 02:36:44, azurIt wrote:
> >The following should print the traces when we hand over ENOMEM to the
> >caller. It should catch all charge paths (migration is not covered but
> >that one is not important here). If we don't see any traces from here
> >and there is still global OOM
During some experiments with an external clock (in a FPGA), we saw that
the TSC clock drifted approx. 2.5ms per second.
This drift was caused by the current way of calculating the scale.
In our case cpu_khz had a value of 3292725. This resulted in a scale
value of 310. But when doing the
On 04/12/12 11:45, Dan Carpenter wrote:
I don't understand this, and I'm going to embarrass myself by
displaying my ignorance for all to see. Why is this code so
different from all the other 32 bit compat code that we have in the
kernel?
On Tue, Dec 04, 2012 at 10:44:14AM +, Serban
On 5 December 2012 00:04, Takashi Iwai wrote:
> At Tue, 4 Dec 2012 23:54:39 +0800,
> Daniel J Blueman wrote:
>>
>> On 4 December 2012 23:03, Takashi Iwai wrote:
>> > At Tue, 4 Dec 2012 22:46:47 +0800,
>> > Daniel J Blueman wrote:
>> >>
>> >> On 4 December 2012 21:55, Takashi Iwai wrote:
>> >> >
Em 05-12-2012 10:50, Federico Vaga escreveu:
On Tuesday 04 December 2012 14:04:22 Mauro Carvalho Chehab wrote:
Em 24-09-2012 09:44, Marek Szyprowski escreveu:
Hello,
On Monday, September 24, 2012 12:59 PM Federico Vaga wrote:
The DMA streaming allocator is similar to the DMA contig but it
On Wed, Dec 05, 2012 at 08:09:01AM +0100, Andreas Mohr wrote:
> Hi,
>
> drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi':
> drivers/pnp/pnpacpi/core.c:65:2: warning: logical 'or' of collectively
> exhaustive tests is always true [-Wlogical-op]
> drivers/pnp/pnpacpi/core.c:66:2: warning:
This commit changes the CMA early initialization code to use phys_addr_t
for representing physical addresses instead of unsigned long.
Without this change, among other things, dma_declare_contiguous() simply
discards any memory regions whose address is not representable as unsigned
long.
This is
On 04/12/12 16:17, Greg KH wrote:
On Tue, Dec 04, 2012 at 10:44:13AM +, Serban Constantinescu wrote:
Android's IPC, Binder, does not support calls from a 32-bit userspace
in a 64 bit kernel. This patch adds support for syscalls coming from a
32-bit userspace in a 64-bit kernel.
Most of the
On Tue, Dec 04, 2012 at 02:03:12PM -0700, Lance Ortiz wrote:
> This patch will provide a more reliable and easy way for user-space
> applications to have access to AER logs rather than reading them from the
> message buffer. It also provides a way to notify user-space when an AER
> event occurs.
>
On Sun 02-12-12 01:40:28, Cong Ding wrote:
> it's not necessary to lock the buffers because no one touches them
> beyond the file system.
Although I agree those locks are not strictly necessary, I prefer to keep
them because the general rula is buffer contents should be changed under
buffer lock
Em Tue, 04 Dec 2012 14:03:18 -0700
Lance Ortiz escreveu:
Hmm... I did a reply to v6 of this patch, but i pressed the wrong button
and it went only to Joe. Excuse-me for that. Let me resend the
comments to everybody:
On Tue, 2012-12-04 at 16:33 -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 04
On Tue, Dec 04, 2012 at 02:03:18PM -0700, Lance Ortiz wrote:
> These changes make cper_print_aer more consistent with aer_print_error
> which is called in the AER interrupt case. The string in the variable
> 'prefix' is printed at the beginning of each print statement in
> cper_print_aer(). The
On 05/12/12 00:26, Arve Hjønnevåg wrote:
On Tue, Dec 4, 2012 at 2:44 AM, Serban Constantinescu
wrote:
Android's IPC, Binder, does not support calls from a 32-bit userspace
in a 64 bit kernel. This patch adds support for syscalls coming from a
32-bit userspace in a 64-bit kernel.
It also
When printing, use a prefix of the PCI domain, bus, device and function
as in other drivers, to differentiate multiple devices.
Important for reporting and debugging. A future step is to tidy this up with
dev_printk et al.
v2: Move conversion specifier into call site, preventing build issues
v3:
On 12/04/2012 07:22 PM, David Miller :
> From: Nicolas Ferre
> Date: Mon, 3 Dec 2012 13:15:43 +0100
>
>> Macb Ethernet controller requires a RX buffer of 128 bytes. It is
>> highly sub-optimal for Gigabit-capable GEM that is able to use
>> a bigger DMA buffer. Change this constant and associated
On Wed, Dec 05, 2012 at 02:31:02PM +, Serban Constantinescu wrote:
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
>
At Wed, 5 Dec 2012 23:04:21 +0800,
Daniel J Blueman wrote:
>
> When printing, use a prefix of the PCI domain, bus, device and function
> as in other drivers, to differentiate multiple devices.
>
> Important for reporting and debugging. A future step is to tidy this up with
> dev_printk et al.
>
On 12/05/2012 10:35 AM, David Laight :
>> If I understand well, you mean that the call to:
>>
>> dma_sync_single_range_for_device(>pdev->dev, phys,
>> pg_offset, frag_len, DMA_FROM_DEVICE);
>>
>> in the rx path after having copied the data to skb is not
On Wed, 5 Dec 2012 15:29:35 +0100
Borislav Petkov wrote:
> On Wed, Dec 05, 2012 at 08:09:01AM +0100, Andreas Mohr wrote:
> > Hi,
> >
> > drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi':
> > drivers/pnp/pnpacpi/core.c:65:2: warning: logical 'or' of collectively
> > exhaustive tests is
> Well, for the 10/100 MACB interface, I am stuck with 128 Bytes buffers!
> So this use of pages seems sensible.
If you have dma coherent memory you can make the rx buffer space
be an array of short buffers referenced by adjacent ring entries
(possibly with the last one slightly short to allow
Unbinding an RTC chip driver from its device leads to the error
message:
|ida_remove called for id=0 which is not allocated.
This is caused by a redundant call to ida_simple_remove() in
rtc_device_unregister().
Eliminate the call in rtc_device_unregister() and only call the
function in
On Wed, Dec 05, 2012 at 03:27:56PM +, Alan Cox wrote:
> On Wed, 5 Dec 2012 15:29:35 +0100
> Borislav Petkov wrote:
>
> > On Wed, Dec 05, 2012 at 08:09:01AM +0100, Andreas Mohr wrote:
> > > Hi,
> > >
> > > drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi':
> > >
Hello.
We have several servers with mongodb running. Each server has several mongodb
instances. Mongodb dataset is larger then availiable memory (mongodb uses
memory-mapped files for all disk I/O).
2.6.32 and 2.6.38 kernels periodically crash and crash happens only with mongodb
servers.
On Tue 27-11-12 18:14:42, Marcus Sundman wrote:
> On 22.11.2012 01:30, Jan Kara wrote:
> >On Fri 16-11-12 03:11:22, Marcus Sundman wrote:
> >>On 13.11.2012 15:51, Jan Kara wrote:
> >>>On Fri 09-11-12 15:12:43, Marcus Sundman wrote:
> On 09.11.2012 01:41, Marcus Sundman wrote:
> >On
compiling the i.MX pwm driver produces the following warning:
|drivers/pwm/pwm-imx.c: In function 'imx_pwm_probe':
|drivers/pwm/pwm-imx.c:281:7: warning: assignment discards qualifiers from
pointer target type
Apply a 'const' attribute to the affected variable declaration.
Signed-off-by: Lothar
On 12/04/2012 06:34 PM, Bryan Wu wrote:
> What's best thing I can do is I can merge these patchset into my
> -devel branch, after 3.8 merge window close I will move this -devel
> branch to my for-next branch for 3.9 merge window.
>
> Does this make sense to you?
Not sure if I can get changes
> Hillarious!
>
> Andrew, would you please pick up Alan's patch? It clearly fixes an
> ancient bug in the pnpacpi code.
And yes btw we should turn this option on in -next, and get these sort of
things out of the tree for good. More importantly it'll mean anyone
adding another one gets a whine on
On 05.12.2012 14:04, Thierry Reding wrote:
> On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
> Yes, but there's more. For instance I went to great lengths to make sure
> there's no global data whatsoever. So all the data is bound to the
> host1x device in the current code. I know
If we make "movablecore_map" take precedence over "movablecore/kernelcore",
the logic could be simplified. I think it's not so attractive to support
both "movablecore_map" and "movablecore/kernelcore" at the same time.
On 11/23/2012 06:44 PM, Tang Chen wrote:
> If kernelcore or movablecore is
On Tue, Dec 04, 2012 at 08:43:18PM +, Arnd Bergmann wrote:
> On Tuesday 04 December 2012, Eli Billauer wrote:
> > I'm currently writing some documentation which will cover the API and
> > also help reading the code, I hope. It takes some time...
> >
> > Until it's done, let's look at a usage
On Wed, Dec 5, 2012 at 2:48 AM, Martin Steigerwald wrote:
>
> Linus, while I am interested in an answer I think that Dave and Christoph
> as Linux filesystem developers actually deserve one (instead of silently
> being ignored which is also a decision in this matter).
>
> I did not see an answer
On 11/23/2012 06:44 PM, Tang Chen wrote:
> This patch introduces a new array zone_movable_limit[] to store the
> ZONE_MOVABLE limit from movablecore_map boot option for all nodes.
> The function sanitize_zone_movable_limit() will find out to which
> node the ranges in movable_map.map[] belongs,
On Wed, Dec 05, 2012 at 10:22:08PM +0700, Bokhan Artem wrote:
> Hello.
>
> We have several servers with mongodb running. Each server has
> several mongodb instances. Mongodb dataset is larger then availiable
> memory (mongodb uses memory-mapped files for all disk I/O).
> 2.6.32 and 2.6.38 kernels
On 05.12.2012 22:53, Borislav Petkov wrote:
On Wed, Dec 05, 2012 at 10:22:08PM +0700, Bokhan Artem wrote:
Hello.
We have several servers with mongodb running. Each server has
several mongodb instances. Mongodb dataset is larger then availiable
memory (mongodb uses memory-mapped files for all
Below is the list of build error/warning regressions/improvements in
v3.7-rc8[1] compared to v3.6[2].
To make this mail fit in the lkml limit, I deleted
- 6016 lines about __mcount_loc on sparc64
- all error and warning improvements
Summarized:
- build errors: +13/-952
- build warnings:
On Thu, Nov 29, 2012 at 04:46:05PM +0800, Lai Jiangshan wrote:
> SRCU is based on its own statemachine and it doesn't
> relies on normal RCU now, its read critical section can be used in
> offline cpu, so we remove the check and the comments.
>
> It partially reverts c0d6d01b(the part for SRCU).
On Wed, Dec 05, 2012 at 03:47:49PM +, Alan Cox wrote:
> > Hillarious!
> >
> > Andrew, would you please pick up Alan's patch? It clearly fixes an
> > ancient bug in the pnpacpi code.
>
> And yes btw we should turn this option on in -next, and get these sort of
> things out of the tree for
Dear RT Folks,
I'm pleased to announce the 3.6.9-rt21 release. 3.6.7-rt18, 3.6.8-rt19
and 3.6.9-rt20 are not announced updates to the respective 3.6.y
stable releases without any RT changes
Changes since 3.6.9-rt20:
* Fix the PREEMPT_LAZY implementation on ARM
* Fix the RCUTINY issues
Including from prevents
cacheflush.h being able to use I/O functions like readl and writel due
to circular include dependencies. It doesn't appear as if anything from
cacheflush.h is actually used by the generic io.h, so remove the
include.
I've compile tested a defconfig compilation of
On 64 bit architectures with no efficient unaligned access, taskstats
has to add some padding to a reply to prevent unaligned access warnings.
However this also needs to apply to 32 bit architectures with 64 bit
struct alignment such as metag (which has 64 bit memory accesses).
This is solved by
The commit "binfmt_elf: cleanups"
(f670d0ecda73b7438eec9ed108680bc5f5362ad8) removed an ifndef elf_map but
this breaks compilation for metag which does define elf_map.
This adds the ifndef back in as it was before, but does not affect the
other cleanups made by that patch.
Signed-off-by: James
The "powervr" prefix which is currently described as "Imagination
Technologies" isn't really appropriate for non-PowerVR hardware, so
deprecate it, changing the description of "powervr" to "PowerVR
(deprecated, use img)", and add a separate "img" prefix for "Imagination
Technologies Ltd.".
The ptrace interface for metag provides access to some core register
sets using the PTRACE_GETREGSET and PTRACE_SETREGSET operations. The
details of the internal context structures is abstracted into user API
structures to both ease use and allow flexibility to change the internal
context layouts.
Commit cc2383ec06be093789469852e1fe96e1148e9a2c ("mm: introduce
arch-specific vma flag VM_ARCH_1") merged in v3.7-rc1.
The above commit combined several arch-specific vma flags into one, and
in the process it changed the VM_GROWSUP definition to depend on
specific architectures rather than
Add [!]METAG to various Kconfig dependencies in generic code, as
described below:
- Kconfig.debug: don't allow stack utilization instrumentation on
metag, and allow building with frame pointers.
- char: don't build rtc or genrtc on METAG
The metag architecture doesn't have a PC
Add the IMG Debug Adapter File System (DAFS) for metag, which uses
SWITCH operations to communicate with a file server on a host computer
via a JTAG debug adapter.
Signed-off-by: James Hogan
Cc: Alexander Viro
Cc: linux-fsde...@vger.kernel.org
---
MAINTAINERS |1 +
Add a TTY driver for communicating over a Meta DA (Debug Adapter)
channel using the bios channel SWITCH operation.
Signed-off-by: James Hogan
Cc: Greg Kroah-Hartman
---
MAINTAINERS|1 +
arch/metag/Kconfig |4 +-
Add basic JTAG Debug Adapter (DA) support so that drivers which
communicate with the DA can detect whether one is actually present
(otherwise the target will halt indefinitely).
Signed-off-by: James Hogan
---
arch/metag/Kconfig |9 ++
Add oprofile support for metag.
Signed-off-by: James Hogan
---
arch/metag/Kconfig|1 +
arch/metag/Makefile |2 +
arch/metag/oprofile/Makefile | 16 ++
arch/metag/oprofile/backtrace.c | 134 ++
Adapt checkstack.pl so that it works for metag.
Signed-off-by: James Hogan
---
scripts/checkstack.pl |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/scripts/checkstack.pl b/scripts/checkstack.pl
index 17e3843..544aa56 100755
--- a/scripts/checkstack.pl
+++
601 - 700 of 1044 matches
Mail list logo
