* Re: [PATCH v3] drm/i915: Fix recursive calls to unmap
From: Daniel Vetter @ 2012-01-17 11:15 UTC (permalink / raw)
To: Ben Widawsky; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <20111103152339.46fe6ce8@bwidawsk.net>
On Thu, Nov 03, 2011 at 03:23:39PM -0700, Ben Widawsky wrote:
> On Thu, 3 Nov 2011 20:19:23 +0000
> Dave Airlie <airlied@gmail.com> wrote:
>
> > >> >
> > >> > The solution here is to add a new flag to the call chain which gives the
> > >> > routines the information they need to possibly defer actions which may
> > >> > cause us to recurse. A macro has been defined to replace i915_gpu_idle
> > >> > which defaults to the old behavior.
> > >> >
> > >> > Kudos to Chris for tracking this one down.
> > >>
> > >> So this fixes the non-VTd case, the VT-d case still hits a recursion
> > >> here, for posterity its below.
> >
> > Okay I take that back, I got my EL6 kernel rock stable with the
> > correct blend of backported bits.
> >
> > So ignore that backtrace, however I did get another IOMMU hang on my
> > upstream kernel with gem_linear_blits,
> >
> > so this should be fine to merge but I'm guessing we have more
> > debugging to do on the VT-d cases.
> >
> > Dave.
>
> Does it pass your original failing case?
Hi Ben,
Is v3 of this patch the right one to merge or do we still have some
outstanding issues on this? Also, have you looked at the recent ilk dmar
fallout, I think strict dmar iotlb flushing doesn't sit too well with our
gpus. My snb dies almost immediately with that (even when I do not enable
rc6 nor semaphores).
Cheers, Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* RE: [PATCH] omap3 towards thumb2 support
From: Premi, Sanjeev @ 2012-01-17 11:14 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox@lists.infradead.org
In-Reply-To: <E28AAFD00EFAA646AE3DF9B89CD24A89317FB2B7@DBDE01.ent.ti.com>
[-- Attachment #1: Type: text/plain, Size: 3403 bytes --]
> -----Original Message-----
> From: barebox-bounces@lists.infradead.org
> [mailto:barebox-bounces@lists.infradead.org] On Behalf Of
> Premi, Sanjeev
> Sent: Monday, January 16, 2012 9:47 PM
> To: Sascha Hauer
> Cc: barebox@lists.infradead.org
> Subject: RE: [PATCH] omap3 towards thumb2 support
>
> (responding via webmail. Won't be able to quote properly)
> ________________________________________
> From: Sascha Hauer [s.hauer@pengutronix.de]
> Sent: Monday, January 16, 2012 9:16 PM
> To: Premi, Sanjeev
> Cc: barebox@lists.infradead.org
> Subject: Re: [PATCH] omap3 towards thumb2 support
>
> On Mon, Jan 16, 2012 at 12:42:36PM +0000, Premi, Sanjeev wrote:
> >
> > > -----Original Message-----
> > > From: barebox-bounces@lists.infradead.org
> > > [mailto:barebox-bounces@lists.infradead.org] On Behalf Of
> > > Premi, Sanjeev
> > > Sent: Monday, January 16, 2012 5:32 PM
> > > To: Sascha Hauer
> > > Cc: barebox@lists.infradead.org
> > > Subject: RE: [PATCH] omap3 towards thumb2 support
> > >
> >
> > [snip]
> >
> > > > >
> > > > > I was able to pull in your branch and encountered a minor
> > > > > issue - fixed by the patch at end of this mail.
> > > > >
> > > > > How can I enable thumb2? Didn't find aything obvious in
> > > > > omap3530_beagle_xload_defconfig.
> > > >
> > > > Did you merge the work/thumb2 branch into your branch? Then
> > > you should
> > > > find THUMB2_BAREBOX in menuconfig.
> > >
> > > Found it. I was searching in a "cached" version of the
> file already
> > > in my editor. Will try immediately.
> > >
> >
> > I discarded the patches that I had manually merged last week and
> > pulled work/thumb2 instead.
> >
> > The size of MLO dropped from 47604 to 35052 bytes. However,
> it didn't
> > boot successfully on the board. The MLO generated after removing
> > CONFIG_THUMB2_BAREBOX came up fine.
>
> Please check that CONFIG_STACK_BASE really is 0x4020F000. It
> may be set
> differently if you started from an older config.
>
> [sp} Already did this.
>
> Also, the resulting binary should also be startable as a second stage
> loader in which case you might get some stack trace if you
> have enabled
> this in the first stage.
>
> [sp] Okay, this could be the issue. I was always building as
> first stage
> bootloader only - as i was looking for the banner to appear.
>
> Will try using emulator tomorrow to debug further.
>
> >
> > BTW, I while merging this patch, I saw a warning that could be fixed
> > before merging the patch into master.
> > 8917ac1 : Applying: ARM: move exception vectors away from
> start of binary
> >
> > /home/premi/barebox/.git/rebase-apply/patch:236: new blank
> line at EOF.
> > +
> > warning: 1 line adds whitespace errors.
>
> Ok, will fix.
>
> I attached my binary MLO file. Could you check if it works for you? I
> just checked this binary and it comes up with:
>
> [sp] I will try tomorrow morning.
Sascha,
Your MLO boots fine. But I couldn't make repeat success on either
beagle or the omap3evem on my side.
Each time there is an exception on entry of setup_auxcr() on both
boards. See attached image.
I noticed that the size of the generated MLO for beagle were different
for us - 35224(yours) vs. 35572(mine).
I am building with CodeSourcery 2011.03-41.
~sanjeev
[-- Attachment #2: barebox_err.jpg --]
[-- Type: image/jpeg, Size: 140279 bytes --]
[-- Attachment #3: Type: text/plain, Size: 149 bytes --]
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH] drm/i915: Mask the ring->head offset using the ring->size
From: Chris Wilson @ 2012-01-17 11:14 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx, stable
In-Reply-To: <20120117105927.GI4093@phenom.ffwll.local>
On Tue, 17 Jan 2012 11:59:27 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Nov 08, 2011 at 11:13:12PM +0000, Chris Wilson wrote:
> > Rather than relying on the hardware to do this correctly, we can
> > trivially do it ourselves.
> >
> > This fixes a very reliable crash on d-i-n with all bits enabled during a
> > cairo-trace replay. The symptoms of the crash is that we continue to
> > write commands into the render ring buffer past the active head
> > position, leading to undefined operations.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: stable@kernel.org
>
> I guess this is just the usual "snb doesn't like being pushed to hard bug"
> resulting in random crashes with confusing error_states. So I think I'll
> drop this. Correct?
I could find no other reason for this to have any effect other than the
hw not playing fair so don't apply it until some one else starts
experiencing random hangs on their SNB and can confirm whether this
patch helps.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* [PATCH] ARM: mach-shmobile: IRQ driven GPIO key support for Kota2
From: Magnus Damm @ 2012-01-17 11:14 UTC (permalink / raw)
To: linux-sh
From: Magnus Damm <damm@opensource.se>
Now when GPIO IRQs are supported on sh73a0 modify the Kota2
board code to switch from the polled "gpio-keys-polled" driver
to the IRQ driven "gpio-keys" driver.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/board-kota2.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- 0001/arch/arm/mach-shmobile/board-kota2.c
+++ work/arch/arm/mach-shmobile/board-kota2.c 2012-01-17 20:00:13.000000000 +0900
@@ -143,11 +143,10 @@ static struct gpio_keys_button gpio_butt
static struct gpio_keys_platform_data gpio_key_info = {
.buttons = gpio_buttons,
.nbuttons = ARRAY_SIZE(gpio_buttons),
- .poll_interval = 250, /* polled for now */
};
static struct platform_device gpio_keys_device = {
- .name = "gpio-keys-polled", /* polled for now */
+ .name = "gpio-keys",
.id = -1,
.dev = {
.platform_data = &gpio_key_info,
^ permalink raw reply
* Re: [PATCH v2] NFC: Export new attributes sensb_res and sensf_res
From: Samuel Ortiz @ 2012-01-17 11:19 UTC (permalink / raw)
To: ilanelias78
Cc: lauro.venancio, aloisio.almeida, linville, linux-wireless,
Ilan Elias
In-Reply-To: <1326791203-10990-1-git-send-email-ilane@ti.com>
Hi Ilan,
On Tue, 2012-01-17 at 11:06 +0200, ilanelias78@gmail.com wrote:
> From: Ilan Elias <ilane@ti.com>
>
> Export new attributes sensb_res for tech B and sensf_res
> for tech F in the target info (returned as a response to
> NFC_CMD_GET_TARGET).
> The max size of the attributes nfcid1, sensb_res and sensf_res
> is exported to user space though include/linux/nfc.
>
> Signed-off-by: Ilan Elias <ilane@ti.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Cheers,
Samuel.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 1/6] qtest: add test framework
From: Stefan Hajnoczi @ 2012-01-17 11:13 UTC (permalink / raw)
To: Anthony Liguori
Cc: Kevin Wolf, Anthony Liguori, Stefan Hajnoczi, qemu-devel,
Avi Kivity, Paolo Bonzini
In-Reply-To: <4F1459AA.5070402@codemonkey.ws>
On Mon, Jan 16, 2012 at 5:08 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 01/16/2012 10:59 AM, Stefan Hajnoczi wrote:
>>
>> On Fri, Jan 13, 2012 at 6:32 PM, Anthony Liguori<aliguori@us.ibm.com>
>> wrote:
>>>
>>> + if (strcmp(words[0], "outb") == 0 ||
>>> + strcmp(words[0], "outw") == 0 ||
>>> + strcmp(words[0], "outl") == 0) {
>>> + uint16_t addr;
>>> + uint32_t value;
>>> +
>>> + g_assert(words[1]&& words[2]);
>>> + addr = strtol(words[1], NULL, 0);
>>> + value = strtol(words[2], NULL, 0);
>>> +
>>> + if (words[0][3] == 'b') {
>>> + cpu_outb(addr, value);
>>> + } else if (words[0][3] == 'w') {
>>> + cpu_outw(addr, value);
>>> + } else if (words[0][3] == 'l') {
>>> + cpu_outl(addr, value);
>>> + }
>>> + qtest_send_prefix(chr);
>>> + qtest_send(chr, "OK\n");
>>> + } else if (strcmp(words[0], "inb") == 0 ||
>>> + strcmp(words[0], "inw") == 0 ||
>>> + strcmp(words[0], "inl") == 0) {
>>> + uint16_t addr;
>>> + uint32_t value = -1U;
>>> +
>>> + g_assert(words[1]);
>>> + addr = strtol(words[1], NULL, 0);
>>> +
>>> + if (words[0][2] == 'b') {
>>> + value = cpu_inb(addr);
>>> + } else if (words[0][2] == 'w') {
>>> + value = cpu_inw(addr);
>>> + } else if (words[0][2] == 'l') {
>>> + value = cpu_inl(addr);
>>> + }
>>> + qtest_send_prefix(chr);
>>> + qtest_send(chr, "OK 0x%04x\n", value);
>>
>>
>> Endianness is a little weird here. memory.c will byteswap if target
>> and device endianness differ.
>>
>> Imagine the case where we're on an x86 host, running a ppc guest,
>> reading from PCI configuration space (little-endian).
>
>
> These functions expect to get host native endian. The qtest wire protocol
> is a string (which has no endianness) and converts it to host native endian.
The cpu_inl() return value is not host native endian. We perform a
byteswap if the memory region endianness is different from the target
endianness. For example, big-endian target and little-endian device
means we byteswap. Little-endian target and little-endian device
means we do not byteswap.
Running the same test binary against qemu-system-x86_64 and
qemu-system-$be_arch results in 0 and 1 byteswaps, respectively. Both
can't be right.
>> Since ppc
>> (target endian) is big-endian and the device is little-endian the
>> value read/written will be byteswapped. However, our qtest runs on
>> the host and therefore we don't want that automatic swap (or we need
>> to neutralize it by performing another byteswap on top).
>
>
> ppc wouldn't use outb/inb. It would do mmio to the PIO region which would
> send it through the host controller (which would do byte swapping as
> necessary).
>
> So a qtest test case would have to do little endian MMIO to interact with
> the PCI bus.
Maybe ppc is a bad example, but are there other targets where in/out is used?
Stefan
^ permalink raw reply
* Re: [PATCH v9 3.2 7/9] tracing: uprobes trace_event interface
From: Srikar Dronamraju @ 2012-01-17 11:03 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jiri Olsa, Arnaldo Carvalho de Melo, Peter Zijlstra,
Linus Torvalds, Oleg Nesterov, Andrew Morton, LKML, Linux-mm,
Andi Kleen, Christoph Hellwig, Steven Rostedt, Roland McGrath,
Thomas Gleixner, Masami Hiramatsu, Arnaldo Carvalho de Melo,
Anton Arapov, Ananth N Mavinakayanahalli, Jim Keniston,
Stephen Rothwell
In-Reply-To: <20120117105916.GA3664@elte.hu>
* Ingo Molnar <mingo@elte.hu> [2012-01-17 11:59:16]:
>
> btw., i'd write the CONFIG_UPROBE_EVENT .config help text:
>
> This allows the user to add tracing events on top of userspace
> dynamic events (similar to tracepoints) on the fly via the
> traceevents interface. Those events can be inserted wherever
> uprobes can probe, and record various registers.
>
> This option is required if you plan to use perf-probe
> subcommand of perf tools on user space applications.
>
> In a clearer form:
>
> This allows the user to add user-space dynamic events on the
> fly, similar to tracepoints. These events can be inserted
> into just about any user-space code transparently, and can
> record register state there on the fly, which is then used by
> instrumentation tools.
>
> This option is required if you plan to use the "perf probe"
> subcommand of the perf tool on user space applications.
>
Okay, Will change as suggested.
--
Thanks and Regards
Srikar
^ permalink raw reply
* Re: [PATCH v9 3.2 7/9] tracing: uprobes trace_event interface
From: Srikar Dronamraju @ 2012-01-17 11:03 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jiri Olsa, Arnaldo Carvalho de Melo, Peter Zijlstra,
Linus Torvalds, Oleg Nesterov, Andrew Morton, LKML, Linux-mm,
Andi Kleen, Christoph Hellwig, Steven Rostedt, Roland McGrath,
Thomas Gleixner, Masami Hiramatsu, Arnaldo Carvalho de Melo,
Anton Arapov, Ananth N Mavinakayanahalli, Jim Keniston,
Stephen Rothwell
In-Reply-To: <20120117105916.GA3664@elte.hu>
* Ingo Molnar <mingo@elte.hu> [2012-01-17 11:59:16]:
>
> btw., i'd write the CONFIG_UPROBE_EVENT .config help text:
>
> This allows the user to add tracing events on top of userspace
> dynamic events (similar to tracepoints) on the fly via the
> traceevents interface. Those events can be inserted wherever
> uprobes can probe, and record various registers.
>
> This option is required if you plan to use perf-probe
> subcommand of perf tools on user space applications.
>
> In a clearer form:
>
> This allows the user to add user-space dynamic events on the
> fly, similar to tracepoints. These events can be inserted
> into just about any user-space code transparently, and can
> record register state there on the fly, which is then used by
> instrumentation tools.
>
> This option is required if you plan to use the "perf probe"
> subcommand of the perf tool on user space applications.
>
Okay, Will change as suggested.
--
Thanks and Regards
Srikar
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: unable to capture an expected page fault
From: Tim Deegan @ 2012-01-17 11:12 UTC (permalink / raw)
To: Study Xen; +Cc: xen-devel
In-Reply-To: <CAJEOSFtHjhU1=eQ8ghDTcKvErso46OgAqOL8-jKeae0QnywDjw@mail.gmail.com>
Hi,
At 03:08 -0500 on 17 Jan (1326769684), Study Xen wrote:
> I was trying to modify part of Xen and faced a page fault missing issue.
>
> I am testing a PV Linux 64-bit guest (kernel 3.1.1, as dom0, the only
> domain in my setting) atop Xen 4.1.2. In an unmodified Xen, the Linux
> kernel's "native_set_pte" in "arch/x86/include/asm/pgtable_64.h" traps into
> Xen due to Xen's write-protection of the pagetable page. But in our
> modified version, this expected page fault seems missing.
Well, I suppose it must be something you changed. :) But since you don't
say what you changed I'm not sure how much we can help you. If the
pagetables are indeed correct then maybe you're missing a TLB flush
somewhere?
Tim.
^ permalink raw reply
* Re: [PATCH] NFC: Increase NCI deactivate timeout
From: Samuel Ortiz @ 2012-01-17 11:18 UTC (permalink / raw)
To: ilanelias78
Cc: aloisio.almeida, lauro.venancio, linville, linux-wireless,
Ilan Elias
In-Reply-To: <1326022982-30205-1-git-send-email-ilane@ti.com>
Hi Ilan,
On Sun, 2012-01-08 at 13:43 +0200, ilanelias78@gmail.com wrote:
> From: Ilan Elias <ilane@ti.com>
>
> Increase NCI deactivate timeout from 5 sec to 30 sec.
> NCI deactivate procedure might take a long time,
> depending on the local and remote parameters.
>
> Signed-off-by: Ilan Elias <ilane@ti.com>
Thanks for the explanations:
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Cheers,
Samuel.
^ permalink raw reply
* [PATCH] ARM: mach-shmobile: sh73a0 IRQ sparse alloc fix
From: Magnus Damm @ 2012-01-17 11:10 UTC (permalink / raw)
To: linux-sh
From: Magnus Damm <damm@opensource.se>
Fix the sh73a0 external IRQ pin code to properly support
CONFIG_SPARSE_IRQ=y by allocating IRQ descriptors for the
cascaded IRQs associated with external IRQ pins.
Without this fix it is impossible to request IRQ0->IRQ31
on the Kota2 board when sparse IRQs are enabled.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/intc-sh73a0.c | 2 ++
1 file changed, 2 insertions(+)
--- 0001/arch/arm/mach-shmobile/intc-sh73a0.c
+++ work/arch/arm/mach-shmobile/intc-sh73a0.c 2012-01-17 19:59:22.000000000 +0900
@@ -19,6 +19,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/interrupt.h>
+#include <linux/module.h>
#include <linux/irq.h>
#include <linux/io.h>
#include <linux/sh_intc.h>
@@ -445,6 +446,7 @@ void __init sh73a0_init_irq(void)
setup_irq(gic_spi(1 + k), &sh73a0_irq_pin_cascade[k]);
n = intcs_evt2irq(to_intc_vect(gic_spi(1 + k)));
+ WARN_ON(irq_alloc_desc_at(n, numa_node_id()) != n);
irq_set_chip_and_handler_name(n, &intca_gic_irq_chip,
handle_level_irq, "level");
set_irq_flags(n, IRQF_VALID); /* yuck */
^ permalink raw reply
* Re: [PATCH v2] NFC: Add NCI data exchange timer
From: Samuel Ortiz @ 2012-01-17 11:16 UTC (permalink / raw)
To: ilanelias78
Cc: lauro.venancio, aloisio.almeida, linville, linux-wireless,
Ilan Elias
In-Reply-To: <1326794630-11151-1-git-send-email-ilane@ti.com>
Hi Ilan,
On Tue, 2012-01-17 at 12:03 +0200, ilanelias78@gmail.com wrote:
> From: Ilan Elias <ilane@ti.com>
>
> Add NCI data exchange timer to catch timeouts,
> and call the data exchange callback with an error.
>
> Signed-off-by: Ilan Elias <ilane@ti.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Cheers,
Samuel.
^ permalink raw reply
* Re: [PATCH 5/5] ACPI processor: Remove unneeded variable passed by acpi_processor_hotadd_init
From: Len Brown @ 2012-01-17 11:10 UTC (permalink / raw)
To: Thomas Renninger; +Cc: linux-acpi, Bjorn Helgaas, Jiang, Yunhong
In-Reply-To: <1321569421-46220-6-git-send-email-trenn@suse.de>
On 11/17/2011 05:37 PM, Thomas Renninger wrote:
> This is a very small part taken from patches which afaik
> are coming from Yunhong Jiang for Xen.
> Xen CPU hotplug things not existing in Linus kernel yet were
> removed.
>
> Cleanup only: no functional change.
>
> Signed-off-by: Thomas Renninger <trenn@suse.de>
> CC: Len Brown <lenb@kernel.org>
> CC: linux-acpi@vger.kernel.org
> CC: Bjorn Helgaas <bhelgaas@google.com>
> CC: Jiang, Yunhong <yunhong.jiang@intel.com>
> ---
> drivers/acpi/processor_driver.c | 17 ++++++++---------
> 1 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index 3e5763f..66887a5 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -82,7 +82,7 @@ MODULE_LICENSE("GPL");
> static int acpi_processor_add(struct acpi_device *device);
> static int acpi_processor_remove(struct acpi_device *device, int type);
> static void acpi_processor_notify(struct acpi_device *device, u32 event);
> -static acpi_status acpi_processor_hotadd_init(acpi_handle handle, int *p_cpu);
> +static acpi_status acpi_processor_hotadd_init(struct acpi_processor *pr);
> static int acpi_processor_handle_eject(struct acpi_processor *pr);
>
>
> @@ -330,10 +330,8 @@ static int acpi_processor_get_info(struct acpi_device *device)
> * they are physically not present.
> */
> if (pr->id == -1) {
> - if (ACPI_FAILURE
> - (acpi_processor_hotadd_init(pr->handle, &pr->id))) {
> + if (ACPI_FAILURE (acpi_processor_hotadd_init(pr->handle)))
> return -ENODEV;
> - }
> }
> /*
> * On some boxes several processors use the same processor bus id.
> @@ -727,18 +725,19 @@ processor_walk_namespace_cb(acpi_handle handle,
> return (AE_OK);
> }
>
> -static acpi_status acpi_processor_hotadd_init(acpi_handle handle, int *p_cpu)
> +static acpi_status acpi_processor_hotadd_init(struct acpi_processor *pr)
> {
> + acpi_handle handle = pr->handle;
>
> if (!is_processor_present(handle)) {
> return AE_ERROR;
> }
>
> - if (acpi_map_lsapic(handle, p_cpu))
> + if (acpi_map_lsapic(handle, &pr-id))
eh?
> return AE_ERROR;
>
> - if (arch_register_cpu(*p_cpu)) {
> - acpi_unmap_lsapic(*p_cpu);
> + if (arch_register_cpu(pr->id)) {
> + acpi_unmap_lsapic(pr->id);
> return AE_ERROR;
> }
>
> @@ -755,7 +754,7 @@ static int acpi_processor_handle_eject(struct acpi_processor *pr)
> return (0);
> }
> #else
> -static acpi_status acpi_processor_hotadd_init(acpi_handle handle, int *p_cpu)
> +static acpi_status acpi_processor_hotadd_init(struct acpi_processor *pr)
> {
> return AE_ERROR;
> }
^ permalink raw reply
* Re: [PATCH] [RFC] drm/i915: Warning when reads or writes are dropped
From: Daniel Vetter @ 2012-01-17 11:08 UTC (permalink / raw)
To: Ben Widawsky; +Cc: intel-gfx
In-Reply-To: <1320451434-16655-1-git-send-email-ben@bwidawsk.net>
On Fri, Nov 04, 2011 at 05:03:54PM -0700, Ben Widawsky wrote:
> The GTFIFODBG register gives us 3 error types when the fifo is accessed
> and full. Whenever we do a forcewake_put we can check this register to
> see if any of the CPU related errors occurred.
>
> Of more interest is perhaps the bit I am not checking which tells when
> some other part of the chip makes a request and the FIFO is full. I
> couldn't really decide on a good place to put that check.
>
> This patch seems to have value to me, but I'm not sure it's worth the
> cost of the extra MMIO read`. (I've yet to see this occur, but I haven't
> actually been running with it for very long).
>
This looks like a nice little patch here. Care to update it for
spinlocked and multithreaded forcewake and maybe also check the other
errors? And also add it to the error_state output (just base it on top of
danvet/my-next to avoid conflicts with the oustanding error_state
cleanup).
Thanks, Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: Problems calling HVMOP_flush_tlbs
From: Tim Deegan @ 2012-01-17 11:08 UTC (permalink / raw)
To: Antony Saba; +Cc: xen-devel@lists.xen.org
In-Reply-To: <4F14C5B9.9080501@mandiant.com>
Hi,
At 00:50 +0000 on 17 Jan (1326761401), Antony Saba wrote:
> Hello xen-devel,
>
> I am using xen 4.2.1 and have tried the following with kernel 3.0.0 and
> 3.2.1.
>
> I am trying to invoke the HVMOP_flush_tlbs hypercall but have been
> unsuccessful. I am basing my call on the functions in in xc_misc.c,
> trying to guess what is meant by "@arg must be null" in the comment
> where HVMOP_flush_tlbs is defined. What is the correct way to invoke
> this hypercall?
>
> If I call it like this, I receive an invalid parameter (EINVAL) error:
> struct privcmd_hypercall
> {
> uint64_t op;
> uint64_t arg[5];
> } hypercall;
> hypercall.op = __HYPERVISOR_hvm_op;
> hypercall.arg[0] = HVMOP_flush_tlbs;
> hypercall.arg[1] = 0;
> ret = do_xen_hypercall(xch, (void*)&hypercall);
>
>
> If I call it like this, I get function not implemented (ENOSYS), where 3
> is a valid domain id:
> hypercall.op = __HYPERVISOR_hvm_op;
> hypercall.arg[0] = HVMOP_flush_tlbs;
> hypercall.arg[1] = 3; /* 3 is the domain whose tlbs should be
> flushed */
> hypercall.arg[2] = 0;
Did you look at the code of Xen? A quick grep finds this:
case HVMOP_flush_tlbs:
rc = guest_handle_is_null(arg) ? hvmop_flush_tlb_all() : -ENOSYS;
break;
So that's what "@arg must ne null" means: if you provide an argument,
you get ENOSYS. And just inside hvmop_flush_tlb_all() is this:
if ( !is_hvm_domain(d) )
return -EINVAL;
So if you call from a non-HVM domain, you get EINVAL. That matches what
you're seeing.
I think the important detail is that HVMOP_flush_tlbs doesn't take a target
domain - it always flushes the _caller's_ TLBs. I guess you want to
flush the TLBs of another domain for some reason? AFAICS the version in
mainline Xen has never taken an argument so perhaps you could add one
(making sure to keep backward compatibility, of course).
Cheers,
Tim.
^ permalink raw reply
* [LTP] [PATCH] syslog-lib: support distros running systemd
From: Jan Stancek @ 2012-01-17 11:08 UTC (permalink / raw)
To: ltp-list
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]
init.d/ scripts may not be available on distros
using systemd, for example Fedora16.
This patch is using 'systemctl' to restart syslog daemon
on distros running systemd. If systemctl is not available
it falls back to directly calling init script.
Also it drops few upstart TODO comments, current code
works OK with upstart (tested on RHEL6).
Signed-off-by: Jan Stancek <jstancek@redhat.com>
---
testcases/kernel/syscalls/syslog/syslog-lib.sh | 40
+++++++++++++----------
1 files changed, 23 insertions(+), 17 deletions(-)
[-- Attachment #2: 0001-syslog-lib-support-distros-running-systemd.patch --]
[-- Type: text/x-patch, Size: 2525 bytes --]
diff --git a/testcases/kernel/syscalls/syslog/syslog-lib.sh b/testcases/kernel/syscalls/syslog/syslog-lib.sh
index 91a2e62..3d0c189 100755
--- a/testcases/kernel/syscalls/syslog/syslog-lib.sh
+++ b/testcases/kernel/syscalls/syslog/syslog-lib.sh
@@ -29,11 +29,15 @@ CONFIG_FILE=""
# rsyslogd .conf specific args.
RSYSLOG_CONFIG=
-# Command for syslog daemon.
-SYSLOG_COMMAND=
+# Command to restart syslog daemon.
+SYSLOG_RESTART_COMMAND=
-# Args to pass to $SYSLOG_COMMAND when restarting the daemon.
-SYSLOG_RESTART_COMMAND_ARGS=
+# running under systemd?
+if command -v systemctl >/dev/null 2>&1; then
+ HAVE_SYSTEMCTL=1
+else
+ HAVE_SYSTEMCTL=0
+fi
# number of seconds to wait for another syslog test to complete
WAIT_COUNT=60
@@ -82,31 +86,33 @@ setup()
CONFIG_FILE="/etc/rsyslog.conf"
SYSLOG_INIT_SCRIPT="/etc/init.d/rsyslog"
RSYSLOG_CONFIG='$ModLoad imuxsock.so'
- #elif <detect-upstart-jobfile-here>; then
- # TODO: upstart
else
tst_resm TCONF "couldn't find syslogd, syslog-ng, or rsyslogd"
cleanup 0
fi
- if [ -z "$SYSLOG_INIT_SCRIPT" ]; then
- # TODO: upstart
- :
+ SVCNAME=$(basename $SYSLOG_INIT_SCRIPT)
+ if [ $HAVE_SYSTEMCTL == 1 ]; then
+ for svc in "$SVCNAME" "syslog"; do
+ if systemctl is-enabled $svc.service >/dev/null 2>&1; then
+ SYSLOG_RESTART_COMMAND="systemctl restart $svc.service"
+ break
+ fi
+ done
else
# Fallback to /etc/init.d/syslog if $SYSLOG_INIT_SCRIPT
# doesn't exist.
for SYSLOG_INIT_SCRIPT in "$SYSLOG_INIT_SCRIPT" "/etc/init.d/syslog"; do
if [ -x "$SYSLOG_INIT_SCRIPT" ]; then
+ SYSLOG_RESTART_COMMAND="$SYSLOG_INIT_SCRIPT restart"
break
fi
done
- if [ ! -x "$SYSLOG_INIT_SCRIPT" ]; then
- tst_resm TBROK "$SYSLOG_INIT_SCRIPT - no such script"
- cleanup 1
- fi
+ fi
- SYSLOG_COMMAND=$SYSLOG_INIT_SCRIPT
- SYSLOG_RESTART_COMMAND_ARGS=restart
+ if [ -z "$SYSLOG_RESTART_COMMAND" ]; then
+ tst_resm TBROK "Don't know how to restart $SVCNAME"
+ cleanup 1
fi
# Back up configuration file
@@ -146,9 +152,9 @@ restart_syslog_daemon()
cleanup_command=$1
fi
- tst_resm TINFO "restarting syslog daemon via $SYSLOG_COMMAND $SYSLOG_RESTART_COMMAND_ARGS"
+ tst_resm TINFO "restarting syslog daemon via $SYSLOG_RESTART_COMMAND"
- if $SYSLOG_COMMAND $SYSLOG_RESTART_COMMAND_ARGS >/dev/null 2>&1; then
+ if $SYSLOG_RESTART_COMMAND >/dev/null 2>&1; then
# XXX: this really shouldn't exist; if *syslogd isn't ready
# once the restart directive has been issued, then it needs to
# be fixed.
[-- Attachment #3: Type: text/plain, Size: 381 bytes --]
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
[-- Attachment #4: Type: text/plain, Size: 155 bytes --]
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 3/3] configure: add '--disable-cocoa' switch
From: Andreas Färber @ 2012-01-17 11:06 UTC (permalink / raw)
To: Andrzej Zaborowski; +Cc: Rui Carmo, Pavel Borzenkov, Ben Leslie, qemu-devel
In-Reply-To: <CAOq732Jk6_Juf2ceW4FhJPvVKsia8ZzcKU1+21qSuywdODsGrQ@mail.gmail.com>
Am 17.01.2012 00:46, schrieb Andrzej Zaborowski:
> On 14 January 2012 01:42, Andreas Färber <andreas.faerber@web.de> wrote:
>> Am 08.12.2011 01:41, schrieb Andreas Färber:
>>> Am 10.11.2011 19:40, schrieb Pavel Borzenkov:
>>>> When SDL support is disabled, there is no way to build QEMU without
>>>> Cocoa support on MacOS X. This patch adds '--disable-cocoa' switch and
>>>> allows to build QEMU without both SDL and Cocoa frontends.
>>>>
>>>> Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
>>>> ---
>>>> configure | 7 ++++++-
>>>> 1 files changed, 6 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/configure b/configure
>>>> index 401d9a6..4720bb2 100755
>>>> --- a/configure
>>>> +++ b/configure
>>>> @@ -670,6 +670,8 @@ for opt do
>>>> ;;
>>>> --enable-profiler) profiler="yes"
>>>> ;;
>>>> + --disable-cocoa) cocoa="no"
>>>> + ;;
>>>> --enable-cocoa)
>>>> cocoa="yes" ;
>>>> sdl="no" ;
>>>
>>> Tested-by: Andreas Färber <andreas.faerber@web.de>
>>>
>>>> @@ -980,7 +982,10 @@ echo " --disable-sdl disable SDL"
>>>> echo " --enable-sdl enable SDL"
>>>> echo " --disable-vnc disable VNC"
>>>> echo " --enable-vnc enable VNC"
>>>> -echo " --enable-cocoa enable COCOA (Mac OS X only)"
>>>> +if test "$darwin" = "yes" ; then
>>>> + echo " --disable-cocoa disable COCOA"
>>>> + echo " --enable-cocoa enable COCOA (default)"
>>>> +fi
>>>> echo " --audio-drv-list=LIST set audio drivers list:"
>>>> echo " Available drivers: $audio_possible_drivers"
>>>> echo " --audio-card-list=LIST set list of emulated audio cards [$audio_card_list]"
>>>
>>> I see no prior art of any conditional help output in configure. Anthony?
>>> Andrzej?
>>
>> Ping? Should we keep command line options a flat list with comments on
>> applicability or start introducing tests like above?
>>
>> Me, I'd prefer not doing this since the switch cases above don't check.
>
> Perhaps --diable-cocoa should be allowed on any platform. You're
> right we don't have such checks now, but then it's hard to see
> downsides of doing them, so I'm quite ambivalent.
>
> I still don't see the purpose of the following test in configure though:
> if test "$cocoa" = "no" ; then
> sdl=yes
> fi
The reason is that SDL and Cocoa must not both be detected due to the
way it is handled in vl.c. Given that Cocoa is enabled by default, SDL
must not be detected in that case. If Cocoa is disabled, then detecting
SDL is fine of course.
The alternative would be to check for SDL and, if present, disable
Cocoa. Still collides with Pavel's patch though - we need to sort out
how to merge them.
> With it in place and no --disable-cocoa there's no way to compile SDL.
> --enable-cocoa is also broken as fas as I can tell.
I've been using it for historic reasons without noticeable problems.
Andreas
^ permalink raw reply
* [PATCH] libxl: remove _libxl_json_internal.h from libxl_json.h
From: Ian Campbell @ 2012-01-17 11:08 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326798471 0
# Node ID 8032df4baf729fc215de7bf8d3015c4ddc107a00
# Parent 120035806c1bf1ab81bdc1664e84302c8c0066c6
libxl: remove _libxl_json_internal.h from libxl_json.h
libxl_json.h is intended as a user-includable header for applications which
would like to use libyajl directly with libxl types. It should not expose libxl
internals.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r 120035806c1b -r 8032df4baf72 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h Tue Jan 17 11:04:46 2012 +0000
+++ b/tools/libxl/libxl_internal.h Tue Jan 17 11:07:51 2012 +0000
@@ -61,8 +61,10 @@
#include "flexarray.h"
#include "libxl_utils.h"
+#include "libxl_json.h"
+
#include "_libxl_types_internal.h"
-#include "libxl_json.h"
+#include "_libxl_types_internal_json.h"
#define LIBXL_DESTROY_TIMEOUT 10
#define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
diff -r 120035806c1b -r 8032df4baf72 tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h Tue Jan 17 11:04:46 2012 +0000
+++ b/tools/libxl/libxl_json.h Tue Jan 17 11:07:51 2012 +0000
@@ -18,6 +18,5 @@
#include <yajl/yajl_gen.h>
#include <_libxl_types_json.h>
-#include <_libxl_types_internal_json.h>
#endif /* LIBXL_JSON_H */
^ permalink raw reply
* Re: [PATCH 3/5] intel_idle: Split up and provide per CPU initialization func
From: Len Brown @ 2012-01-17 11:06 UTC (permalink / raw)
To: Thomas Renninger; +Cc: linux-acpi
In-Reply-To: <1321569421-46220-4-git-send-email-trenn@suse.de>
On 11/17/2011 05:36 PM, Thomas Renninger wrote:
> Function split up, should have no functional change
benefit?
^ permalink raw reply
* [PATCH 2/2] gnutls.inc: set libz prefix
From: Martin Jansa @ 2012-01-17 10:58 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1326797712.git.Martin.Jansa@gmail.com>
* without this patch host's zlib is used, similar to issue with
libreadline it's important if host's zlib is compatible with MACHINE
and in this case zlib was in DEPENDS so header was always available in
sysroot
lib/config.log:
configure:18288: checking whether to include zlib compression support
configure:18291: result: yes
configure:18786: checking for libz
configure:18808: x86_64-oe-linux-gcc -m64 --sysroot=/OE/shr-core/tmp-eglibc/sysroots/qemux86-64 -o conftest -O2 -pipe -g -feliminate-unused-debug-types -I/OE/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/include -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c /usr/lib/libz.so >&5
configure:18808: $? = 0
configure:18818: result: yes
configure:18825: checking how to link with libz
configure:18827: result: /usr/lib/libz.so
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
meta/recipes-support/gnutls/gnutls.inc | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-support/gnutls/gnutls.inc b/meta/recipes-support/gnutls/gnutls.inc
index 820faf6..5991540 100644
--- a/meta/recipes-support/gnutls/gnutls.inc
+++ b/meta/recipes-support/gnutls/gnutls.inc
@@ -3,7 +3,7 @@ HOMEPAGE = "http://www.gnu.org/software/gnutls/"
BUGTRACKER = "https://savannah.gnu.org/support/?group=gnutls"
DEPENDS = "zlib lzo libtasn1 libgcrypt (>= 1.4.2) libcap readline"
-INC_PR = "r3"
+INC_PR = "r4"
LICENSE = "GPLv3+ & LGPLv2.1+"
LICENSE_${PN} = "LGPLv2.1+"
@@ -25,6 +25,7 @@ EXTRA_OECONF="--with-included-opencdk --with-included-libcfg --disable-rpath \
--with-libdl-prefix=${STAGING_DIR_HOST}${prefix} \
--with-libpthread-prefix=${STAGING_DIR_HOST}${prefix} \
--with-libreadline-prefix=${STAGING_DIR_HOST}${prefix} \
+ --with-libz-prefix=${STAGING_DIR_HOST}${prefix} \
--with-lzo --disable-guile \
--without-p11-kit \
"
--
1.7.8.3
^ permalink raw reply related
* [PATCH 1/2] gnutls: add readline to DEPENDS and add --with-libreadline-prefix
From: Martin Jansa @ 2012-01-17 10:58 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1326797712.git.Martin.Jansa@gmail.com>
* without this patch it looks for readline in host's /usr/lib
a) and fails if readline wasn't built before gnutls, because -I is set
and cannot find header file, this case is better
configure:33131: checking for readline
configure:33156: x86_64-oe-linux-gcc -m64 --sysroot=/OE/oe-core/tmp-eglibc/sysroots/qemux86-64 -std=gnu99 -o conftest -O2 -pipe -g -feliminate-unused-debug-types -I/OE/oe-core/tmp-eglibc/sysroots/qemux86-64/usr/include -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c /usr/lib/libreadline.so >&5
conftest.c:240:31: fatal error: readline/readline.h: No such file or directory
b) and finds usable version there if readline was built and MACHINE is compatible with host
(like qemux86-64 on amd64 host) and then it's passing -L/usr/lib (without sysroot prefix)
to every build using libgnutls.la
configure:33131: checking for readline
configure:33156: x86_64-oe-linux-gcc -m64 --sysroot=/OE/shr-core/tmp-eglibc/sysroots/qemux86-64 -std=gnu99 -o conftest -O2 -pipe -g -feliminate-unused-debug-types -I/OE/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/include -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c /usr/lib/libreadline.so >&5
configure:33156: $? = 0
configure:33173: result: yes
configure:33185: checking how to link with libreadline
configure:33187: result: /usr/lib/libreadline.so
configure:33199: checking readline/readline.h usability
configure:33199: x86_64-oe-linux-gcc -m64 --sysroot=/OE/shr-core/tmp-eglibc/sysroots/qemux86-64 -std=gnu99 -c -O2 -pipe -g -feliminate-unused-debug-types -I/OE/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/include conftest.c >&5
configure:33199: $? = 0
configure:33199: result: yes
configure:33199: checking readline/readline.h presence
configure:33199: x86_64-oe-linux-gcc -E --sysroot=/OE/shr-core/tmp-eglibc/sysroots/qemux86-64 -m64 -I/OE/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/include conftest.c
configure:33199: $? = 0
configure:33199: result: yes
configure:33199: checking for readline/readline.h
configure:33199: result: yes
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
meta/recipes-support/gnutls/gnutls.inc | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-support/gnutls/gnutls.inc b/meta/recipes-support/gnutls/gnutls.inc
index cdcf85b..820faf6 100644
--- a/meta/recipes-support/gnutls/gnutls.inc
+++ b/meta/recipes-support/gnutls/gnutls.inc
@@ -1,7 +1,7 @@
DESCRIPTION = "GNU Transport Layer Security Library"
HOMEPAGE = "http://www.gnu.org/software/gnutls/"
BUGTRACKER = "https://savannah.gnu.org/support/?group=gnutls"
-DEPENDS = "zlib lzo libtasn1 libgcrypt (>= 1.4.2) libcap"
+DEPENDS = "zlib lzo libtasn1 libgcrypt (>= 1.4.2) libcap readline"
INC_PR = "r3"
@@ -24,6 +24,7 @@ EXTRA_OECONF="--with-included-opencdk --with-included-libcfg --disable-rpath \
--with-libgcrypt --with-libgcrypt-prefix=${STAGING_DIR_HOST}${prefix} \
--with-libdl-prefix=${STAGING_DIR_HOST}${prefix} \
--with-libpthread-prefix=${STAGING_DIR_HOST}${prefix} \
+ --with-libreadline-prefix=${STAGING_DIR_HOST}${prefix} \
--with-lzo --disable-guile \
--without-p11-kit \
"
--
1.7.8.3
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 2/2] qemu-ga: Add the guest-suspend command
From: Jamie Lokier @ 2012-01-17 11:05 UTC (permalink / raw)
To: Michael Roth; +Cc: Eric Blake, jcody, qemu-devel, Luiz Capitulino
In-Reply-To: <4F149F75.1030405@linux.vnet.ibm.com>
Michael Roth wrote:
> >STDIO is one of the major areas of code that is definitely not
> >async signal safe. Consider Thread A doing something like
> >fwrite(stderr, "Foo\n"), while another thread forks, and then
> >its child also does an fwrite(stderr, "Foo\n"). Given that
> >every stdio function will lock/unlock a mutex, you easily get
> >this sequence of events:
> >
> >1. Thread A: lock(stderr)
> >2. Thread A: write(stderr, "foo\n");
> >3. Thread B: fork() -> Process B1
> >4. Thread A: unlock(stderr)
> >5. Process B1: lock(stderr)
> >
> >When the child process is started at step 3, the FILE *stderr
> >object will be locked by thread A. When Thread A does the
> >unlock in step 4, it has no effect on Process B1. So process
> >B1 hangs forever in step 5.
>
> Ahh, thanks for the example. I missed that these issues were
> specifically WRT to code that was fork()'d from a multi-threaded
> application. Seemed pretty scary otherwise :)
The pthread_atfork() mechanism, or equivalent in libc, should be
sorting out those stdio locks, but I don't know for sure what Glibc does.
I do know it traverses a stdio list on fork() though:
http://sourceware.org/bugzilla/show_bug.cgi?id=4737#c4
Which is why Glibc's fork() is not async-signal-safe even though it's
supposed to be.
stdio in a fork() child is historical unix stuff; I expect there are
quite a lot of old applications that use stdio in a child process.
Not multi-threaded applications, but they can link to multi-threaded
libraries these without knowing.
Still there are bugs around (like Glibc's fork() not being
async-signal-safe). It pays to be cautious.
-- Jamie
^ permalink raw reply
* [PATCH] ARM: mach-shmobile: sh73a0 PINT IRQ base fix
From: Magnus Damm @ 2012-01-17 11:05 UTC (permalink / raw)
To: linux-sh
From: Magnus Damm <damm@opensource.se>
Bump up the sh73a0 PINT IRQ base from 768 to 800 to avoid
collision with INTCS vectors for IRQ16->IRQ32 at 0x3xxx.
Without this fix the sh73a0 IRQ pin handling code collides
with the PINT code which results in hangs on Kota2 during boot.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/include/mach/sh73a0.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 0001/arch/arm/mach-shmobile/include/mach/sh73a0.h
+++ work/arch/arm/mach-shmobile/include/mach/sh73a0.h 2012-01-17 19:34:48.000000000 +0900
@@ -515,8 +515,8 @@ enum {
SHDMA_SLAVE_MMCIF_RX,
};
-/* PINT interrupts are located at Linux IRQ 768 and up */
-#define SH73A0_PINT0_IRQ(irq) ((irq) + 768)
-#define SH73A0_PINT1_IRQ(irq) ((irq) + 800)
+/* PINT interrupts are located at Linux IRQ 800 and up */
+#define SH73A0_PINT0_IRQ(irq) ((irq) + 800)
+#define SH73A0_PINT1_IRQ(irq) ((irq) + 832)
#endif /* __ASM_SH73A0_H__ */
^ permalink raw reply
* Re: [xen-unstable bisection] complete test-i386-i386-xl
From: Paul Durrant @ 2012-01-17 11:05 UTC (permalink / raw)
To: Paul Durrant, Ian Jackson
Cc: xen-devel@lists.xensource.com, Keir (Xen.org), Ian Campbell,
Stefano Stabellini
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BECAD@LONPMAILBOX01.citrite.net>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Paul Durrant
> Sent: 17 January 2012 10:05
> To: Ian Jackson
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Ian Campbell; Stefano
> Stabellini
> Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
>
> So far I've been unable to repro. with a build of staging tip from yesterday
> (running a 512MB PV debian guest with a 3.2.0-rc2+ kernel). I'll revert to the
> appropriate c/s and see if I can repro. with that. The errors unfortunately
> don't give much away other than the receiving process clearly didn't like
> something about the migration data stream.
>
> libxl: error: libxl_utils.c:409:libxl_read_exactly: file/stream truncated
> reading ready message from migration receiver stream
> libxl: info: libxl_exec.c:124:libxl_report_child_exitstatus: migration target
> process [14446] exited with error status 255
>
Apologies for the previous top-post; it seems impossible to configure outlook to not do that by default :-(
I reproduced the problem. The bug has been identified and a fix verified. I posted the patch a couple of minutes ago.
Paul
^ permalink raw reply
* [PATCH 0/2] gnutls fixes
From: Martin Jansa @ 2012-01-17 10:57 UTC (permalink / raw)
To: openembedded-core
Hi,
nobody likes when it's trying to use host's libraries and even worse
when it succeeds and pulls them to rest of OE builds through .la files.
The following changes since commit 91e17c0c0ac2330f826b95e762542cd0d0c82385:
pango: Use gnomebase class, not gnome (2012-01-16 18:01:31 +0000)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib jansa/gnutls
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/gnutls
Martin Jansa (2):
gnutls: add readline to DEPENDS and add --with-libreadline-prefix
gnutls.inc: set libz prefix
meta/recipes-support/gnutls/gnutls.inc | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
--
1.7.8.3
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.