On Wed, Jul 15, 2020 at 3:46 AM Sedat Dilek wrote:
>
> On Wed, Jul 15, 2020 at 2:41 AM Arvind Sankar wrote:
> >
> > The compressed kernel currently contains bogus run-time relocations in
> > the startup code in head_{32,64}.S, which are generated by the linker,
>
On Wed, Jul 15, 2020 at 2:41 AM Arvind Sankar wrote:
>
> The compressed kernel currently contains bogus run-time relocations in
> the startup code in head_{32,64}.S, which are generated by the linker,
> but must not actually be processed at run-time.
>
> This generates warnings
The assembly code in head_{32,64}.S, while meant to be
position-independent, generates run-time relocations because it uses
instructions such as
lealgdt(%edx), %eax
which make the assembler and linker think that the code is using %edx as
an index into gdt, and hence gdt needs to be
Add a linker script check that there are no run-time relocations, and
remove the old one that tries to check via looking for specially-named
sections in the object files.
Drop the tests for -fPIE compiler option and -pie linker option, as they
are available in all supported gcc and binutils
The compressed kernel currently contains bogus run-time relocations in
the startup code in head_{32,64}.S, which are generated by the linker,
but must not actually be processed at run-time.
This generates warnings when linking with the BFD linker, and errors
with LLD, which defaults to erroring
The BFD linker generates run-time relocations for z_input_len and
z_output_len, even though they are absolute symbols.
This is fixed for binutils-2.35 [1]. Work around this for earlier
versions by defining two variables input_len and output_len in addition
to the symbols, and use them via
From: Adrian Hunter
commit f18d5cf86cdb58eb50cafb5a5e20943ec7a61b1f upstream.
Using Python version 3.8.2 and PySide2 version 5.14.0, time chart call tree
would not expand the tree to the result. Fix by using setExpanded().
Example:
$ perf record -e intel_pt//u uname
Linux
[ perf record
Fix support for external PTP-aware devices such as DSA or PTP PHY:
Make sure we never time stamp tx packets when hardware time stamping
is disabled.
Check for PTP PHY being in use and then pass ioctls related to time
stamping of Ethernet packets to the PTP PHY rather than handle them
ourselves
Vladimir Oltean writes:
[...]
>> Acked-by: Vladimir Oltean
>>
>> Thanks,
>> -Vladimir
>
> Of course, it would be good if you sent a new version with the sha1sum
> of the Fixes: tag having the right length, otherwise people will
> complain.
Ah, thanks for reminding! I entirely forgot about it
>
> > >> > From the perspective of the mainline kernel, that can never happen.
> > >>
> > >> Yet in happened to me, and in some way because of the UAPI deficiencies
> > >> I've mentioned, as ethtool has entirely separate code path
perspective of the mainline kernel, that can never happen.
>> >>
>> >> Yet in happened to me, and in some way because of the UAPI
>> >> deficiencies
>> >> I've mentioned, as ethtool has entirely separate code path, that
>> >> happens
>> >&g
Richard Cochran writes:
> On Sat, Jul 11, 2020 at 03:08:42PM +0300, Sergey Organov wrote:
>> Fix support for external PTP-aware devices such as DSA or PTP PHY:
>>
>> Make sure we never time stamp tx packets when hardware time stamping
>> is disabled.
>>
>
t;
> >> Yet in happened to me, and in some way because of the UAPI deficiencies
> >> I've mentioned, as ethtool has entirely separate code path, that happens
> >> to be correct for a long time already.
> >>
> >
> > Yup, you are right:
> >
On Sat, Jul 11, 2020 at 03:08:42PM +0300, Sergey Organov wrote:
> Fix support for external PTP-aware devices such as DSA or PTP PHY:
>
> Make sure we never time stamp tx packets when hardware time stamping
> is disabled.
>
> Check for PTP PHY being in use and then pass ioct
The MC firmware will enable the switch interfaces at DPSW creation
without waiting for an 'ifconfig up' on the switch interfaces. When this
happens, the states held by the Linux software vs the firmware are not
in sync. Make sure to disable the switch ports at probe time to not
enco
On Mon, Jun 29, 2020 at 4:09 PM Arvind Sankar wrote:
>
> The assembly code in head_{32,64}.S, while meant to be
> position-independent, generates run-time relocations because it uses
> instructions such as
> lealgdt(%edx), %eax
> which make the assembler and linker t
mentioned, as ethtool has entirely separate code path, that happens
>> to be correct for a long time already.
>>
>
> Yup, you are right:
>
[...]
> Very bad design choice indeed...
> Given the fact that the PHY timestamping needs massaging from MAC driver
> for plenty of
The assembly code in head_{32,64}.S, while meant to be
position-independent, generates run-time relocations because it uses
instructions such as
lealgdt(%edx), %eax
which make the assembler and linker think that the code is using %edx as
an index into gdt, and hence gdt needs to be
On Sat, Jul 04, 2020 at 11:40:55PM -0700, Andrei Vagin wrote:
> On Wed, Jun 24, 2020 at 01:33:15AM -0700, Andrei Vagin wrote:
> > Allocate the time namespace page among VVAR pages and add the logic
> > to handle faults on VVAR properly.
> >
> > If a task belongs to a t
Certain watchdogs require the watchdog only to be pinged within a
specific time window, pinging too early or too late cause the watchdog
to fire. In cases where this sort of watchdog has been started before
kernel comes up, we must adjust the watchdog keepalive window to match
the actually running
On 05/07/2020 17:58, Guenter Roeck wrote:
On 7/3/20 5:04 AM, Tero Kristo wrote:
Certain watchdogs require the watchdog only to be pinged within a
specific time window, pinging too early or too late cause the watchdog
to fire. In cases where this sort of watchdog has been started before
kernel
v4l2-compliance expects the driver to adjust the time per frame if it is
invalid (numerator or denominator set to 0). Adjust it to the default
value in these cases.
Signed-off-by: Alexandre Courbot
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 12
1 file changed, 8
The time per frame was left initialized to 0/0, which make the driver
fail v4l2-compliance, and also leaves it potentially exposed to doing a
division by zero.
Signed-off-by: Alexandre Courbot
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 5 +
1 file changed, 5 insertions
by fec1 built-in PTP code instead of being
> forwarded to the external PHY, and that this happens despite the call to
>
>info.cmd = ETHTOOL_GET_TS_INFO;
>ioctl(fd, SIOCETHTOOL, &ifr);
>
> returning phc_index = 1 that corresponds to external PHY, and reports
> features of the ex
hardware together),
>>
>> As a side note, I tried, but didn't find a way to get 2 timestamps,
>> software and hardware, for the same packet. It looks like once upon a
>> time it was indeed supported by:
>>
>> SOF_TIMESTAMPING_SYS_HARDWARE: This option is
didn't find a way to get 2 timestamps,
> software and hardware, for the same packet. It looks like once upon a
> time it was indeed supported by:
>
> SOF_TIMESTAMPING_SYS_HARDWARE: This option is deprecated and ignored.
>
With SO_TIMESTAMPING, it is supported through
SOF_TIMEST
for external PTP-aware devices such as DSA or PTP PHY:
>> >>
>> >> Make sure we never time stamp tx packets when hardware time stamping
>> >> is disabled.
>> >>
>> >> Check for PTP PHY being in use and then pass ioctls related to time
>> >&
On Sun, Jul 12, 2020 at 05:16:56PM +0300, Sergey Organov wrote:
> Vladimir Oltean writes:
>
> > Hi Sergey,
> >
> > On Sat, Jul 11, 2020 at 03:08:42PM +0300, Sergey Organov wrote:
> >> Fix support for external PTP-aware devices such as DSA or PTP PHY:
> >&
> I did as you suggested:
>
> [pretty]
> fixes = Fixes: %h (\"%s\")
> [alias]
> fixes = show --no-patch --pretty='Fixes: %h (\"%s\")'
>
> And that's what it gave me. Dunno, maybe its Git version that is
> responsible?
[core]
abbrev = 12
Andrew
Vladimir Oltean writes:
> Hi Sergey,
>
> On Sat, Jul 11, 2020 at 03:08:42PM +0300, Sergey Organov wrote:
>> Fix support for external PTP-aware devices such as DSA or PTP PHY:
>>
>> Make sure we never time stamp tx packets when hardware time stamping
>> is d
Hi Sergey,
On Sat, Jul 11, 2020 at 03:08:42PM +0300, Sergey Organov wrote:
> Fix support for external PTP-aware devices such as DSA or PTP PHY:
>
> Make sure we never time stamp tx packets when hardware time stamping
> is disabled.
>
> Check for PTP PHY being in use and then p
This adds an option '--graph-opts nosleep-time' which allow us
only to measure on-CPU time. This option is function_graph tracer
only.
Signed-off-by: Changbin Du
---
v3: switch to uniform option --graph-opts.
v2: option name '--nosleep-time' -> '--graph-no
Fix support for external PTP-aware devices such as DSA or PTP PHY:
Make sure we never time stamp tx packets when hardware time stamping
is disabled.
Check for PTP PHY being in use and then pass ioctls related to time
stamping of Ethernet packets to the PTP PHY rather than handle them
ourselves
Change the debug logging (when used with the --time option) to time filter
logged perf events, but allow that to be overridden by using "d+a" instead
of plain "d".
That can reduce the size of the log file.
Signed-off-by: Adrian Hunter
---
tools/perf/Documentation/pe
This adds an option '--graph-opts nosleep-time' which allow us
only to measure on-CPU time. This option is function_graph tracer
only.
Signed-off-by: Changbin Du
---
v3: switch to uniform option --graph-opts.
v2: option name '--nosleep-time' -> '--graph-no
Change the debug logging (when used with the --time option) to time filter
logged perf events, but allow that to be overridden by using "d2" instead
of plain "d".
By default that can greatly reduce the size of the log file.
Signed-off-by: Adrian Hunter
---
tools/perf/Docu
On 7/8/20 6:04 PM, Nick Desaulniers wrote:
> From: Jakub Kicinski
>
> When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
> compiler to deduce a case where _val can only have the value of -1 at
> compile time. Specifically,
>
> /* struct bpf_i
From: Jakub Kicinski
When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
compiler to deduce a case where _val can only have the value of -1 at
compile time. Specifically,
/* struct bpf_insn: _s32 imm */
u64 imm = insn->imm; /* sign extend */
if (imm >> 32) { /*
On Wed, 8 Jul 2020 10:56:43 -0700 Nick Desaulniers wrote:
> On Wed, Jul 8, 2020 at 10:34 AM Alex Elder wrote:
> >
> > I understand why something needs to be done to handle that case.
> > There's fancy macro gymnastics in "bitfield.h" to add convenient
> &g
On Wed, Jul 8, 2020 at 10:34 AM Alex Elder wrote:
>
> I understand why something needs to be done to handle that case.
> There's fancy macro gymnastics in "bitfield.h" to add convenient
> build-time checks for usage problems; I just thought there might
> be somethi
In order to prevent issues during the firmware to KMS transition, we need
to make sure the pixelvalve are disabled at boot time so that the DRM state
matches the hardware state.
Reviewed-by: Eric Anholt
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 25
he
>>> compiler to deduce a case where _val can only have the value of -1 at
>>> compile time. Specifically,
>>>
>>> /* struct bpf_insn: _s32 imm */
>>> u64 imm = insn->imm; /* sign extend */
>>> if (imm >> 32) { /* non-zero only if insn-
>> >> any less confusing.
>> >
>> > +1
>> >
>> > For a PHC, the user of the clock must check the PTP stack's
>> > synchronization flags via the management interface to know the status
>> > of the time signal.
>>
>>
On Tue, Jul 7, 2020 at 3:43 PM Alex Elder wrote:
>
> On 7/7/20 4:16 PM, Nick Desaulniers wrote:
> > From: Jakub Kicinski
> >
> > When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
> > compiler to deduce a case where _val can only have
This adds an option '--graph-opts nosleep-time' which allow us
only to measure on-CPU time. This option is function_graph tracer
only.
Signed-off-by: Changbin Du
---
v3: switch to uniform option --graph-opts.
v2: option name '--nosleep-time' -> '--graph-no
From: Anson Huang
[ Upstream commit b45fd13be340e4ed0a2a9673ba299eb2a71ba829 ]
After finishing using cpu node got from of_get_cpu_node(), of_node_put()
needs to be called.
Signed-off-by: Anson Huang
Signed-off-by: Daniel Lezcano
Link:
https://lore.kernel.org/r/1585232945-23368-1-git-send-ema
From: Anson Huang
[ Upstream commit b45fd13be340e4ed0a2a9673ba299eb2a71ba829 ]
After finishing using cpu node got from of_get_cpu_node(), of_node_put()
needs to be called.
Signed-off-by: Anson Huang
Signed-off-by: Daniel Lezcano
Link:
https://lore.kernel.org/r/1585232945-23368-1-git-send-ema
; >
> > For a PHC, the user of the clock must check the PTP stack's
> > synchronization flags via the management interface to know the status
> > of the time signal.
>
> Actually, as I just realized, the right solution for my original problem
> would rather be a
wrote:
> > > > This adds an option '--graph-nosleep-time' which allow us only to
> > > > measure
> > > > on-CPU time. This option is function_graph tracer only.
>
> > > I'd suggest --graph-sleep-time instead and set it by default.
> >
re investigating it in the first place is a driver bug.
>> Also, I don't really see how your change to use Jan 1st 1970 makes it
>> any less confusing.
>
> +1
>
> For a PHC, the user of the clock must check the PTP stack's
> synchronization flags via the mana
re investigating it in the first place is a driver bug.
>> Also, I don't really see how your change to use Jan 1st 1970 makes it
>> any less confusing.
>
> +1
>
> For a PHC, the user of the clock must check the PTP stack's
> synchronization flags via the managem
Richard Cochran writes:
> On Tue, Jul 07, 2020 at 08:56:41PM +0300, Sergey Organov wrote:
>> It won't. Supposedly it'd force clock (that doesn't tick by default and
>> stays at 0) to start ticking.
>
> No existing clockid_t has this behavior. Consider CLOCK_REALTIME or
> CLOCK_MONOTONIC.
>
> T
On Tue, Jul 07, 2020 at 08:56:41PM +0300, Sergey Organov wrote:
> It won't. Supposedly it'd force clock (that doesn't tick by default and
> stays at 0) to start ticking.
No existing clockid_t has this behavior. Consider CLOCK_REALTIME or
CLOCK_MONOTONIC.
The PHC must act the same as the other P
> I agree with the basic fact that zero is a simpler and more consistent
> value to initialize a PHC with, than the system time. As I've already
> shown to you, I even attempted to make a similar change to the ptp_qoriq
> driver which was rejected. So I hoped that you could bring
a driver bug.
> Also, I don't really see how your change to use Jan 1st 1970 makes it
> any less confusing.
+1
For a PHC, the user of the clock must check the PTP stack's
synchronization flags via the management interface to know the status
of the time signal.
Thanks,
Richard
On Tue, Jul 07, 2020 at 10:04:37AM +0300, Vladimir Oltean wrote:
> > > We do it like this:
> > > - DSA: If there is a timestamping switch stacked on top of a
> > > timestamping Ethernet MAC, the switch hijacks the .ndo_do_ioctl of the
> > > host port, and you are supposed to use the PTP clock o
o use. The assumption is that you'd always
> > want to use the outermost one, and that things in the kernel side always
> > collaborate towards that end.
+1
In addition, for PHY time stamping you must enable the costly
CONFIG_NETWORK_PHY_TIMESTAMPING option at compile time, and so
On 7/7/20 4:16 PM, Nick Desaulniers wrote:
> From: Jakub Kicinski
>
> When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
> compiler to deduce a case where _val can only have the value of -1 at
> compile time. Specifically,
>
> /* struct bpf_i
On Tue, Jul 07, 2020 at 02:16:41PM -0700, Nick Desaulniers wrote:
> From: Jakub Kicinski
>
> When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
> compiler to deduce a case where _val can only have the value of -1 at
> compile time. Specifically,
>
>
From: Jakub Kicinski
When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
compiler to deduce a case where _val can only have the value of -1 at
compile time. Specifically,
/* struct bpf_insn: _s32 imm */
u64 imm = insn->imm; /* sign extend */
if (imm >> 32) { /*
t;> > What do you mean 'no ticking', and what do you mean by 'non-initialized
>> >> > clock' exactly? I don't know if the fec driver is special in any way, do
>> >> > you mean that multiple runs of $(phc_ctl /dev/ptp0 get) from user space
, and what do you mean by 'non-initialized
> >> > clock' exactly? I don't know if the fec driver is special in any way, do
> >> > you mean that multiple runs of $(phc_ctl /dev/ptp0 get) from user space
> >> > all return 0? That is not at all what is to b
f the fec driver is special in any way, do
>> > you mean that multiple runs of $(phc_ctl /dev/ptp0 get) from user space
>> > all return 0? That is not at all what is to be expected, I think. The
>> > PHC is always ticking. Its time is increasing.
>>
>> That&#x
; > you mean that multiple runs of $(phc_ctl /dev/ptp0 get) from user space
> > all return 0? That is not at all what is to be expected, I think. The
> > PHC is always ticking. Its time is increasing.
>
> That's how it is right now. My point is that it likely shouldn'
Em Tue, Jul 07, 2020 at 11:35:14PM +0800, Changbin Du escreveu:
> On Fri, Jul 03, 2020 at 03:40:59PM +0900, Namhyung Kim wrote:
> > On Sat, Jun 27, 2020 at 10:38 PM Changbin Du wrote:
> > > This adds an option '--graph-nosleep-time' which allow us only to measure
>
Vladimir Oltean writes:
> On Mon, Jul 06, 2020 at 09:24:24PM +0300, Sergey Organov wrote:
>> Vladimir Oltean writes:
>>
>> > Hi Sergey,
>> >
>> > On Mon, Jul 06, 2020 at 05:26:14PM +0300, Sergey Organov wrote:
>> >> Initializing wi
On Fri, Jul 03, 2020 at 03:40:59PM +0900, Namhyung Kim wrote:
> On Sat, Jun 27, 2020 at 10:38 PM Changbin Du wrote:
> >
> > This adds an option '--graph-nosleep-time' which allow us only to measure
> > on-CPU time. This option is function_graph tracer only.
>
6605b730c061f67c44113391e5af5125d0672e99 --pretty=fixes
>
> Then you copy the first line of the generated output to the patch, right
> above your Signed-off-by: tag. Like this:
>
> Fixes: 6605b730c061 ("FEC: Add time stamping code and a PTP hardware clock")
>
> Note t
Andy Duan writes:
> From: Sergey Organov Sent: Monday, July 6, 2020 10:26 PM
>> PPS feature could be useful even when hardware time stamping of network
>> packets is not in use, so remove offending check for this condition from
>> fec_ptp_enable_pps().
>
> If hardwa
Previously, once we update one block in segment, we will update mtime of
segment to last time, making aged segment becoming freshest, result in
that GC with cost benefit algorithm missing such segment, So this patch
changes to record mtime as average block updating time instead of last
updating
Mon, Jul 06, 2020 at 05:26:12PM +0300, Sergey Organov wrote:
> >> >> When external PTP-aware PHY is in use, it's that PHY that is to time
> >> >> stamp network packets, and it's that PHY where configuration requests
> >> >> of time stamping features a
On Mon, Jul 06, 2020 at 09:24:24PM +0300, Sergey Organov wrote:
> Vladimir Oltean writes:
>
> > Hi Sergey,
> >
> > On Mon, Jul 06, 2020 at 05:26:14PM +0300, Sergey Organov wrote:
> >> Initializing with 0 makes it much easier to identify time stamps from
&
From: Sergey Organov Sent: Monday, July 6, 2020 10:26 PM
> PPS feature could be useful even when hardware time stamping of network
> packets is not in use, so remove offending check for this condition from
> fec_ptp_enable_pps().
If hardware time stamping of network packets is not in us
" and it will disable the BPF_LSM.
> >
> > - KP
> >
> > >
> > > Thanks,
> > > Daniel
>
> Hi,
> Thanks Daniel and KP for looking into this, I really appreciate it!
>
> The *why* I need it is because I need to ship the kernel with BPF LS
Commits c0d0381ade79 and 87bf91d39bb5 changed the way huegtlb locking
was performed to address BUGs. One specific change was to always take
the i_mmap_rwsem in read mode during fault processing. One result of
this change was a 33% regression for anon non-shared page faults [1].
Technically, i_mm
d line
> with the lsm= parameter. So you can just pass lsm="selinux,capabilities" etc
> and not pass "bpf" and it will disable the BPF_LSM.
>
> - KP
>
> >
> > Thanks,
> > Daniel
Hi,
Thanks Daniel and KP for looking into this, I really a
On Mon, Jul 6, 2020 at 8:51 PM Daniel Borkmann wrote:
>
> On 7/6/20 6:57 PM, Lorenzo Fontana wrote:
> > This option adds a kernel parameter 'bpf_lsm',
> > which allows the BPF LSM to be disabled at boot.
> > The purpose of this option is to allow a single kernel
> > image to be distributed with th
On 7/6/20 6:57 PM, Lorenzo Fontana wrote:
This option adds a kernel parameter 'bpf_lsm',
which allows the BPF LSM to be disabled at boot.
The purpose of this option is to allow a single kernel
image to be distributed with the BPF LSM built in,
but not necessarily enabled.
Signed-off-by: Lorenzo
Vladimir Oltean writes:
> On Mon, Jul 06, 2020 at 06:21:59PM +0300, Sergey Organov wrote:
>> Vladimir Oltean writes:
>> > Hi Sergey,
>> >
>> > On Mon, Jul 06, 2020 at 05:26:12PM +0300, Sergey Organov wrote:
>> >> When external PTP-aware PHY is i
Vladimir Oltean writes:
> Hi Sergey,
>
> On Mon, Jul 06, 2020 at 05:26:14PM +0300, Sergey Organov wrote:
>> Initializing with 0 makes it much easier to identify time stamps from
>> otherwise uninitialized clock.
>>
>> Initialization of PTP clock with current
fig option.
+ bpf_lsm=[BPF_LSM] Disable or enable LSM Instrumentation
+ with BPF at boot time.
+ Format: { "0" | "1" }
+ See init/Kconfig help text.
+ 0 -- disable.
+
On Mon, Jul 06, 2020 at 06:21:59PM +0300, Sergey Organov wrote:
> Vladimir Oltean writes:
>
> > Hi Sergey,
> >
> > On Mon, Jul 06, 2020 at 05:26:12PM +0300, Sergey Organov wrote:
> >> When external PTP-aware PHY is in use, it's that PHY that is to time
>
Hi Sergey,
On Mon, Jul 06, 2020 at 05:26:14PM +0300, Sergey Organov wrote:
> Initializing with 0 makes it much easier to identify time stamps from
> otherwise uninitialized clock.
>
> Initialization of PTP clock with current kernel time makes little sense as
> PTP time scale d
Vladimir Oltean writes:
> Hi Sergey,
>
> On Mon, Jul 06, 2020 at 05:26:12PM +0300, Sergey Organov wrote:
>> When external PTP-aware PHY is in use, it's that PHY that is to time
>> stamp network packets, and it's that PHY where configuration requests
>> of ti
Hi Sergey,
On Mon, Jul 06, 2020 at 05:26:12PM +0300, Sergey Organov wrote:
> When external PTP-aware PHY is in use, it's that PHY that is to time
> stamp network packets, and it's that PHY where configuration requests
> of time stamping features are to be routed.
>
&g
PPS feature could be useful even when hardware time stamping
of network packets is not in use, so remove offending check
for this condition from fec_ptp_enable_pps().
Signed-off-by: Sergey Organov
---
drivers/net/ethernet/freescale/fec_ptp.c | 5 -
1 file changed, 5 deletions(-)
diff --git
When external PTP-aware PHY is in use, it's that PHY that is to time
stamp network packets, and it's that PHY where configuration requests
of time stamping features are to be routed.
To achieve these goals:
1. Make sure we don't time stamp packets when external PTP PHY is in use
Initializing with 0 makes it much easier to identify time stamps from
otherwise uninitialized clock.
Initialization of PTP clock with current kernel time makes little sense as
PTP time scale differs from UTC time scale that kernel time represents.
It only leads to confusion when no actual PTP
On 7/3/20 5:04 AM, Tero Kristo wrote:
> Certain watchdogs require the watchdog only to be pinged within a
> specific time window, pinging too early or too late cause the watchdog
> to fire. In cases where this sort of watchdog has been started before
> kernel comes up, we must adjust
On Wed, Jun 24, 2020 at 01:33:15AM -0700, Andrei Vagin wrote:
> Allocate the time namespace page among VVAR pages and add the logic
> to handle faults on VVAR properly.
>
> If a task belongs to a time namespace then the VVAR page which contains
> the system wide VDSO data is
; >
> > > swap(rela[i++], rela[j]);
> > >
> > > here so the next iteration of the loop will not call
> > > branch_rela_needs_plt() on rela[i] redundantly. But the current code
> > > is also correct.
> >
> > Oh yeah, I noticed that unnece
>
> > swap(rela[i++], rela[j]);
> >
> > here so the next iteration of the loop will not call
> > branch_rela_needs_plt() on rela[i] redundantly. But the current code
> > is also correct.
>
> Oh yeah, I noticed that unnecessary repeat of branch_rela_needs_plt()
skipped entirely
> > because PLTs are not allocated for R_AARCH64_CALL26 and R_AARCH64_JUMP26
> > if it's disabled.
> >
> > This gives significant reduction in module load time for modules with
> > large number of relocations with no measurable impact on mod
This is the call for proposals for the Real-Time Micro Conference (RT-MC) at the
Linux Plumbers Conference 2020. It will take place online during the Linux
Plumbers Conference on August 24th-28th, 2020.
The real-time micro-conference targets discussions about new features or open
problems related
t; the timing data stored in the ring buffer that is used to produced the time
> > stamps of the records.
> >
> > This is useful for tools like trace-cmd to be able to display the content of
> > the read data to understand why the records show the time stamps that they
&
There are few issues on Zynq SOC observed in the stress tests causing
timeout errors. Even though all the data is received, timeout error
is thrown. This is due to an IP bug in which the COMP bit in ISR is
not set at end of transfer and completion interrupt is not generated.
This bug is seen on Zy
Certain watchdogs require the watchdog only to be pinged within a
specific time window, pinging too early or too late cause the watchdog
to fire. In cases where this sort of watchdog has been started before
kernel comes up, we must adjust the watchdog keepalive window to match
the actually running
Em Thu, Jul 02, 2020 at 02:53:45PM -0400, Steven Rostedt escreveu:
> From: "Steven Rostedt (Red Hat)"
>
> Add the functions kbuffer_subbuf_timestamp() and kbuffer_ptr_delta() to get
> the timing data stored in the ring buffer that is used to produced the time
> stamps
On Sat, Jun 27, 2020 at 10:38 PM Changbin Du wrote:
>
> This adds an option '--graph-nosleep-time' which allow us only to measure
> on-CPU time. This option is function_graph tracer only.
I'd suggest --graph-sleep-time instead and set it by default.
Then we can have --no-
On 2020/7/2 0:19, Jaegeuk Kim wrote:
> On 06/30, Chao Yu wrote:
>> Previously, once we update one block in segment, we will update mtime of
>> segment to last time, making aged segment becoming freshest, result in
>> that GC with cost benefit algorithm missing such s
1301 - 1400 of 10949 matches
Mail list logo
