Hi Sebastian,
any progress on your side?
Do you think the patch could be applied for the next versions?
Regards,
Thomas
On Fri, 2020-07-10 at 10:59 +, Thomas Graziadei wrote:
> Hi Sebastian,
>
> thanks for looking into this.
>
> We could reproduce the issue with QEMU.
&
lity to get it?
Regards,
Thomas
-Original Message-
From: Sebastian Andrzej Siewior [mailto:bige...@linutronix.de]
Sent: Monday, July 06, 2020 6:50 PM
To: Mark Marshall
Cc: linux-rt-users ; Mark Marshall
; Thomas Graziadei
; Thomas Gleixner ;
linux-kernel@vger.kernel.org; rost...@
From: Thomas Graziadei
The link state is not correctly set in the case that the network driver
is reconfigured while the link state changes. The phy informs the gianfar
driver, but gfar_update_link_state just exits and therefore looses the
change event. The network driver remains in the old
From: Thomas Graziadei
The phy layer sets the link status initially to 1 to also support phyless
systems, therefore we set the gianfar drivers initial link status also to
1. This prevents the gfar_update_link_state() method to be called when the
driver and phy have just been initialized but no
On 06/01/2016 01:11 AM, John Stultz wrote:
On Tue, May 31, 2016 at 6:06 AM, Thomas Graziadei
wrote:
From: Thomas Graziadei
The user notices the problem in a raw and real time drift, calling
clock_gettime with CLOCK_REALTIME / CLOCK_MONOTONIC_RAW on a system
with no ntp correction taking
From: Thomas Graziadei
The user notices the problem in a raw and real time drift, calling
clock_gettime with CLOCK_REALTIME / CLOCK_MONOTONIC_RAW on a system
with no ntp correction taking place (no ntpd or ptp stuff running).
The problem is, that old_vsyscall_fixup adds an extra 1ns even though
6 matches
Mail list logo