Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > Jan Kiszka wrote:
> > > Philippe,
> > >
> > > you recently said there is a bug in the x86_64 support when syscall
> > > tracing is enabled. Now I think I stepped on it as well: In order to
> > > validate my APIC frequency patches for th
I must suspend the search for this problem for a while. The specific
hardware (computer) is unavailable to me for about a week.
Jeroen.
> Could there be any reason why e.g. a pci_config_read_dword() call would
> > fail in Xenomai context (because when still in the module probe code, I
> > can
I have a setup which apparently suffers from long interrupt-disabled
sections during heavy load (make -j16 of a kernel). I have instrumented the
__ipipe_unstall_iret_root() function with the tracer as follows:
asmlinkage void __ipipe_unstall_iret_root(struct pt_regs regs)
{
ipipe_trace_specia
Jeroen Van den Keybus wrote:
> I have a setup which apparently suffers from long interrupt-disabled
> sections during heavy load (make -j16 of a kernel). I have instrumented the
> __ipipe_unstall_iret_root() function with the tracer as follows:
>
>
> asmlinkage void __ipipe_unstall_iret_root(stru
> So, unless the IRQ below
> should have been raised much earlier, there is no issue here.
The point is: I actually do have interrupts (not the IPI that is visible
here) that are being withheld (on average 80 us late) during this period. On
this particular setup, I have seen numbers exceeding 300
Jeroen Van den Keybus wrote:
>> So, unless the IRQ below
>> should have been raised much earlier, there is no issue here.
>
>
> The point is: I actually do have interrupts (not the IPI that is visible
> here) that are being withheld (on average 80 us late) during this period. On
> this particular
[Save the CCs!]
Jeroen Van den Keybus wrote:
>> Indeed, 300 us are too long. Maybe long DMA bursts on your PCI bus? Can
>> you exclude certain devices from your load to check for this (no hardisk
>> load e.g., use nfs instead, then no network load, etc.)?
>
>
> I already tried setting PCI latenc
>
> Ouch, this shouldn't be allowed in user space! WBINVD is a privileged
> instruction. Do we leak privileges to user land??? Please check if your
> execution mode (privilege ring) is correct there.
No, I rather meant a kernel-mode program that was controlled from the user
space. Sorry for upset
Jeroen Van den Keybus wrote:
>> Ouch, this shouldn't be allowed in user space! WBINVD is a privileged
>> instruction. Do we leak privileges to user land??? Please check if your
>> execution mode (privilege ring) is correct there.
>
>
> No, I rather meant a kernel-mode program that was controlled
Hi,
while the syscall tracing thing still puzzles me, I was now at least
able to check that my patches do what they are supposed to. So here
comes a flush of (most of) the stuff that piled up on my side, fixing or
enhancing the following aspects:
- x86 hal refactoring (-v2) - I decided to base m
This is v2 of my already posted refactoring of the x86 HAL. Saves
duplicates and actually makes following fixes/reworks simpler.
Jan
---
include/asm-x86/hal.h | 14 +
include/asm-x86/hal_32.h | 42
include/asm-x86/hal_64.h | 20 ++
include/asm-x86/wrappers_64.h |3
This patch exploits the reworked ipipe_request_tickdev API that will be
posted in a separate series. This way we can overcome the inaccuracy of
Xenomai's current APIC timer frequency calibration. For
!CONFIG_GENERIC_CLOCKEVENTS, the patch tries to obtain the frequency via
the intermediate IPIPE_API
As recently suggested, this patch arms the __must_check logic behind
__xn_copy_to_user, __xn_copy_from_user (not on i386 due to lacking
instrumentation of Linux service), __xn_strncpy_from_user.
This patch is only intended to point out what remains to be addressed,
the huge number of warnings make
Here comes my favourite approach to report the frequency of the timer
that an I-pipe user takes over: via the very same API. This patch
extends ipipe_request_tickdev by a pointer to a variable that shall
receive the timer frequency as the hijacked clock_event_device carries it.
This is the most ge
I-pipe's current hooking into the GENERIC_CLOCKEVENTS infrastructure
contains an ugly out-of-band argument passing via the device structure
(delta...) and unneeded indirections of the intercepted services. This
patches overcomes both by cleanly modifying relevant properties of the
clock_event_devic
This patch introduces the intermediate IPIPE_APIC_TIMER_FREQ API, that
can be used by I-pipe users to obtain the accurate APIC timer frequency
as Linux calibrated it. This API is scheduled to be removed with
x86-ipipe for kernel 2.6.24. ipipe_request_tickdev is meant to be used then.
Note that a s
Given the current multitude of timer/clock combinations on i386, but
also considering that we may provide HPET clocks on x86 in the future or
may face other archs with multiple options, this patch reports the
configured timer and clock devices via /proc/xenomai/timer. Example:
# cat /proc/xenomai/
A separately posted I-pipe patch refactors the tickdev emulation API.
This patch updates Xenomai to the new prototypes without changing any
functionality.
Jan
---
include/asm-generic/bits/pod.h | 14 +++---
include/asm-generic/hal.h |6 +++---
ksrc/arch/generic/hal.c|
18 matches
Mail list logo
