On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote:
> On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
>
> > Acked-by: Darren Hart (VMware)
> >
> > As for a longer term solution, would it be possible to init fops in such
> > a way that the
ons wmi_fops = {
> .read = wmi_char_read,
> .open = wmi_char_open,
> .unlocked_ioctl = wmi_ioctl,
> - .compat_ioctl = wmi_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
For platform/drivers/x86:
Acked-by: Darren Hart (VMware)
simplicity (it gets
> optimized away anyway).
>
This required a minor manual merge for ARM on the tip of Linus' tree today. The
reduced duplication is a welcome improvement.
Reviewed-by: Darren Hart (VMware)
--
Darren Hart
VMware Open Source Technology Center
\
> BUILD_TARGET=$(OUTPUT)/$$DIR; \
> mkdir $$BUILD_TARGET -p; \
> make OUTPUT=$$BUILD_TARGET -C $$DIR $@;\
> done
> +endef
Taking the move of clean into lib.mk as a given,
Acked-by: Darren Hart (VMware)
--
Darren Hart
VMware Open Source Technology Center
On Wed, Jun 03, 2015 at 07:37:13AM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, Jun 3, 2015, at 00:34, Darren Hart wrote:
> > On Tue, Jun 02, 2015 at 07:09:28AM -0300, Henrique de Moraes Holschuh
> > wrote:
> > > Test results were sent to me privately,
r
pull request.
Reviewed-by: Darren Hart
--
Darren Hart
Intel Open Source Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
> enabled. This is tied to backlight, as ACPI_VIDEO depends on
> BACKLIGHT_CLASS_DEVICE.
>
> * Replace a couple of select INPUT/VT with depends as it seemed to be
> necessary.
>
> Reference:
> http://lkml.kernel.org/r/ca+r1zhhmt4drwtf6mbrqo5eqxwx+lxcqh15vsu_d9wpftl
o update
> + * these in the struct page.
> + *
> + * This is important for some architectures where those bits also
> + * gate the access permission to the page because their are
s/their/they/
Thanks,
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
_
icked started this CPU
>> back to life (bring the CPU back online), set the preempt count on the
>> task of that CPU to 0, and screwed everything up.
>
> /me goes to checks where this came from...
>
> It's been in the kernel since hotplug CPU suppor
7e30] [c0008278] .start_secondary_resume+0x10/0x14
I'll spend tomorrow collecting traces and trying to see who's groping who this
time...
--
Darren
>
> -- Steve
>
>
>>
>> if (get_cpu_current_state(lcpu) == CPU_STATE_INACTIVE)
>> goto o
On 09/01/2010 12:59 PM, Steven Rostedt wrote:
> On Wed, 2010-09-01 at 11:47 -0700, Darren Hart wrote:
>
>> from tip/rt/2.6.33 causes the preempt_count() to change across the cede
>> call. This patch appears to prevents the proxy preempt_count assignment
>> from happe
On 09/01/2010 08:10 AM, Darren Hart wrote:
> On 08/31/2010 10:54 PM, Michael Ellerman wrote:
>> On Tue, 2010-08-31 at 00:12 -0700, Darren Hart wrote:
>> ..
>>>
>>> When running with the function plugin I had to stop the trace
>>> immediately before ente
On 08/31/2010 10:54 PM, Michael Ellerman wrote:
> On Tue, 2010-08-31 at 00:12 -0700, Darren Hart wrote:
> ..
>>
>> When running with the function plugin I had to stop the trace
>> immediately before entering start_secondary after an online or my traces
>> would not in
On 08/19/2010 08:58 AM, Ankita Garg wrote:
> Hi Darren,
>
> On Thu, Jul 22, 2010 at 11:24:13AM -0700, Darren Hart wrote:
>>
>> With some instrumentation we were able to determine that the
>> preempt_count() appears to change across the extended_cede_processor()
>&g
On 08/19/2010 08:58 AM, Ankita Garg wrote:
Hi Darren,
On Thu, Jul 22, 2010 at 11:24:13AM -0700, Darren Hart wrote:
With some instrumentation we were able to determine that the
preempt_count() appears to change across the extended_cede_processor()
call. Specifically across the
On 07/22/2010 11:38 AM, Thomas Gleixner wrote:
On Thu, 22 Jul 2010, Darren Hart wrote:
Also of interest is that this path
cpu_idle()->cpu_die()->pseries_mach_cpu_die() to start_secondary()
enters with a preempt_count=1 if it wasn't corrupted across the hcall.
That triggers the
On 08/05/2010 10:09 PM, Vaidyanathan Srinivasan wrote:
> * Darren Hart [2010-08-05 19:19:00]:
>
>> On 07/22/2010 10:09 PM, Benjamin Herrenschmidt wrote:
>>> On Thu, 2010-07-22 at 21:44 -0700, Darren Hart wrote:
>>>
>>>>suggestion I
On 07/22/2010 10:09 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2010-07-22 at 21:44 -0700, Darren Hart wrote:
>
>> suggestion I updated the instrumentation to display the
>> local_save_flags and irqs_disabled_flags:
>
>> Jul 22 23:36:58 igoort1 kernel: local flags:
extended_cede_processor() cpu, but may be
marked pending when we get out of this state eventually. I will find
more information on this event and update.
Hi Vaidy, have you been able to dig anything up about the decrementer
expiry?
Thanks,
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
From: Signed-off-by: Darren Hart
All IRQs are migrated away from a CPU that is being offlined so the
following messages suggest a problem when the system is behaving as
designed:
IRQ 262 affinity broken off cpu 1
IRQ 17 affinity broken off cpu 0
IRQ 18 affinity broken off cpu 0
IRQ 19 affinity
From: Signed-off-by: Darren Hart
During CPU offline/online tests __cpu_up would flood the logs with
the following message:
Processor 0 found.
This provides no useful information to the user as there is no context
provided, and since the operation was a success (to this point) it is expected
From: Signed-off-by: Darren Hart
start_secondary() is called shortly after _start and also via
cpu_idle()->cpu_die()->pseries_mach_cpu_die()
start_secondary() expects a preempt_count() of 0. pseries_mach_cpu_die() is
called via the cpu_idle() routine with preemption disabled, resulting
The following patch series addresses several issues detected during intense CPU
offline/online testing on the mainline kernel with CONFIG_PREEMPT=y. These
patches require the following patch from Brian King:
http://patchwork.ozlabs.org/patch/59645/
Tested against linux-2.6.git master with and wit
On 07/22/2010 03:25 PM, Benjamin Herrenschmidt wrote:
On Thu, 2010-07-22 at 11:24 -0700, Darren Hart wrote:
1) How can the preempt_count() get mangled across the H_CEDE hcall?
2) Should we call preempt_enable() in cpu_idle() prior to cpu_die() ?
The preempt count is on the thread info at the
On 07/22/2010 04:57 PM, Darren Hart wrote:
> On 07/22/2010 03:25 PM, Benjamin Herrenschmidt wrote:
>> On Thu, 2010-07-22 at 11:24 -0700, Darren Hart wrote:
>>>
>>> 1) How can the preempt_count() get mangled across the H_CEDE hcall?
>>> 2) Should we call pre
On 07/22/2010 03:25 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2010-07-22 at 11:24 -0700, Darren Hart wrote:
>>
>> 1) How can the preempt_count() get mangled across the H_CEDE hcall?
>> 2) Should we call preempt_enable() in cpu_idle() prior to cpu_die() ?
>
> The pre
On 07/22/2010 11:24 AM, Darren Hart wrote:
The following patch is most certainly not correct, but it does eliminate
the situation on mainline 100% of the time (there is still a 25%
reproduction rate on PREEMPT_RT). Can someone comment on:
Apologies. This particular issue is also 100
_CEDE hcall?
2) Should we call preempt_enable() in cpu_idle() prior to cpu_die() ?
Hacked-up-by: Darren Hart
Index: linux-2.6.33.6/arch/powerpc/platforms/pseries/hotplug-cpu.c
===
--- linux-2.6.33.6.orig/arch/powerpc/platforms/pser
top_cpu+0x154/0x1ec
[c00084d03d40] c000000a8b84 .worker_thread+0x25c/0x338
[c00084d03e60] c00af8c8 .kthread+0xb8/0xc4
[c00084d03f90] c0034408 .kernel_thread+0x54/0x70
Thanks,
Darren Hart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
k of detailed hardware knowledge on my side.
Thanks,
tglx
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 05/18/2010 06:25 PM, Michael Ellerman wrote:
On Tue, 2010-05-18 at 15:22 -0700, Darren Hart wrote:
On 05/18/2010 02:52 PM, Brian King wrote:
Is IRQF_NODELAY something specific to the RT kernel? I don't see it in
mainline...
Yes, it basically says "don't make this h
m.com wrote:
> From ad81664794e33d785f533c5edee37aaba20dd92d Mon Sep 17 00:00:00 2001
From: Darren Hart
Date: Tue, 18 May 2010 11:07:13 -0700
Subject: [PATCH RT] ehea: make receive irq handler non-threaded (IRQF_NODELAY)
The underlying hardware is edge triggered but presented by XICS as level
triggered. The edge t
32 matches
Mail list logo
