On Wed, Aug 19, 2020 at 7:01 PM John Stultz wrote:
>
> On Wed, Aug 19, 2020 at 2:36 PM John Stultz wrote:
> >
> > On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
> > wrote:
> > > So, IMO, the best is to keep it on staging for a while, until those
On Wed, Aug 19, 2020 at 2:36 PM John Stultz wrote:
>
> On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
> wrote:
> > So, IMO, the best is to keep it on staging for a while, until those
> > remaining bugs gets solved.
> >
> > I added this series, together wi
On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab
wrote:
> So, IMO, the best is to keep it on staging for a while, until those
> remaining bugs gets solved.
>
> I added this series, together with the regulator driver and
> a few other patches (including a hack to fix a Kernel 5.8
> regression
driver and
> a few other patches (including a hack to fix a Kernel 5.8
> regression at WiFi ) at:
>
>
> https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master
>
>
> Chen Feng (1):
> staging: hikey9xx: Add hisilicon DRM driver for hikey960/970
>
>
On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart
wrote:
> On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote:
> > On Wed, Aug 19, 2020 at 01:45:28PM +0200, Mauro Carvalho Chehab wrote:
> > > This patch series port the out-of-tree driver for Hikey 970 (which
> > > should also support Hike
On Fri, Aug 7, 2020 at 3:18 PM Kees Cook wrote:
>
> On Fri, Aug 07, 2020 at 01:29:24PM -0700, John Stultz wrote:
> > On Thu, Jul 9, 2020 at 11:28 AM Kees Cook wrote:
> > >
> > > Duplicate the cleanups from commit 2618d530dd8b ("net/scm: cleanup
> >
On Thu, Jul 9, 2020 at 11:28 AM Kees Cook wrote:
>
> Duplicate the cleanups from commit 2618d530dd8b ("net/scm: cleanup
> scm_detach_fds") into the compat code.
>
> Replace open-coded __receive_sock() with a call to the helper.
>
> Move the check added in commit 1f466e1f15cf ("net: cleanly handle
On Fri, Aug 7, 2020 at 12:19 AM Christoph Hellwig wrote:
>
> On Thu, Aug 06, 2020 at 11:23:34PM -0700, John Stultz wrote:
> > So I've finally rebase-bisected it down to:
> > a31edb2059ed ("net: improve the user pointer check in init_user_sockptr")
> > http
On Thu, Aug 6, 2020 at 11:23 PM John Stultz wrote:
>
> On Thu, Aug 6, 2020 at 5:32 PM John Stultz wrote:
> >
> > On Thu, Aug 6, 2020 at 4:17 PM Eric Dumazet wrote:
> > > On 8/6/20 2:39 PM, John Stultz wrote:
> > > > [ 19.709492] Unable to hand
On Thu, Aug 6, 2020 at 5:32 PM John Stultz wrote:
>
> On Thu, Aug 6, 2020 at 4:17 PM Eric Dumazet wrote:
> > On 8/6/20 2:39 PM, John Stultz wrote:
> > > [ 19.709492] Unable to handle kernel access to user memory outside
> > > uaccess routines at vi
On Thu, Aug 6, 2020 at 6:52 AM Thierry Reding wrote:
>
> On Wed, Apr 22, 2020 at 08:32:43PM +, John Stultz wrote:
> > This patch addresses a regression in 5.7-rc1+
> >
> > In commit c8c43cee29f6 ("driver core: Fix
> > driver_deferred_probe_check_state()
On Thu, Aug 6, 2020 at 4:17 PM Eric Dumazet wrote:
> On 8/6/20 2:39 PM, John Stultz wrote:
> > [ 19.709492] Unable to handle kernel access to user memory outside
> > uaccess routines at virtual address 006f53337070
> > [ 19.726539] Mem abort info:
> > [ 19
On Wed, Aug 5, 2020 at 6:57 PM David Miller wrote:
> There is a minor conflict in net/ipv6/ip6_flowlabel.c, it's because of
> the commit that did the tree-wide removal of uninitialized_var(). The
> resolution is simple, kill all of the conflict markers and content
> within, and remove the uniniti
On Mon, Jul 6, 2020 at 1:15 PM Daniel Borkmann wrote:
> On 7/6/20 10:11 PM, John Stultz wrote:
> >Just wanted to follow up on this as I've not seen the regression fix
> > land in 5.8-rc4 yet? Is it still pending, or did it fall through a
> > gap?
>
> No, it&
On Tue, Jun 23, 2020 at 5:54 PM Alexei Starovoitov
wrote:
> On Mon, Jun 22, 2020 at 12:44 PM John Stultz wrote:
> > On Sat, Jun 20, 2020 at 2:26 PM Maciej Żenczykowski
> > wrote:
> > > From: Maciej Żenczykowski
> > >
> > > This is a fix for a regressio
N but not SYS_ADMIN).
>
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Reported-by: John Stultz
> Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF")
> Signed-off-by: Maciej Żenczykowski
Thanks so much for helping narrow this regression down and submitting this fix!
It's much appreciated!
Tested-by: John Stultz
thanks
-john
On Wed, Apr 29, 2020 at 6:52 AM Mark Brown wrote:
> On Wed, Apr 29, 2020 at 03:46:04PM +0200, Marek Szyprowski wrote:
> > On 22.04.2020 22:32, John Stultz wrote:
>
> > > Fixes: c8c43cee29f6 ("driver core: Fix
> > > driver_deferred_probe_check_state() logic
On Fri, Aug 11, 2017 at 5:31 PM, John Stultz wrote:
> On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang wrote:
>>> If after Cong's fix, the issue still happens, could you help try the
>>> patch attached and collect all logs when you try the reproduce the
>>> issue?
On Fri, Aug 11, 2017 at 5:10 PM, Wei Wang wrote:
>> If after Cong's fix, the issue still happens, could you help try the
>> patch attached and collect all logs when you try the reproduce the
>> issue? It would be great to have logs for both success case and the
>> failure case.
>>
>> Thanks so muc
On Wed, Aug 9, 2017 at 10:41 PM, Wei Wang wrote:
> Hi John,
>
> Is it possible to try the attached patch?
Thanks so much for the quick turn around!
So I dropped all the reverts you suggested, and applied this one
against 4.13-rc4, but I'm still seeing the problematic behavior.
> I am not sure i
On Wed, Aug 9, 2017 at 5:36 PM, Wei Wang wrote:
> On Wed, Aug 9, 2017 at 4:44 PM, John Stultz wrote:
>> On Wed, Aug 9, 2017 at 4:34 PM, Cong Wang wrote:
>>> (Cc'ing Wei whose commit was blamed)
>>>
>>> On Mon, Aug 7, 2017 at 2:15 PM, John Stultz wrote:
On Wed, Aug 9, 2017 at 5:36 PM, Wei Wang wrote:
>
> Does your USB adapter get an IPv6 address?
Yes, it does.
> If you see the problem starts to happen on commit
> 9514528d92d4cbe086499322370155ed69f5d06c, could you try reverting all
> the following commits:
> (from new to old)
> 1eb04e7c9e63 net
On Wed, Aug 9, 2017 at 4:34 PM, Cong Wang wrote:
> (Cc'ing Wei whose commit was blamed)
>
> On Mon, Aug 7, 2017 at 2:15 PM, John Stultz wrote:
>> On Mon, Aug 7, 2017 at 2:05 PM, John Stultz wrote:
>>> So, with recent testing with my HiKey board, I've been noti
On Mon, Aug 7, 2017 at 2:05 PM, John Stultz wrote:
> So, with recent testing with my HiKey board, I've been noticing some
> quirky behavior with my USB eth adapter.
>
> Basically, pluging the usb eth adapter in and then removing it, when
> plugging it back in I often find t
So, with recent testing with my HiKey board, I've been noticing some
quirky behavior with my USB eth adapter.
Basically, pluging the usb eth adapter in and then removing it, when
plugging it back in I often find that its not detected, and the system
slowly spits out the following message over and
On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng wrote:
> On Thu, Jun 1, 2017 at 6:22 PM, Arnd Bergmann wrote:
>> On Thu, Jun 1, 2017 at 11:56 AM, Yan, Zheng wrote:
>>> On Sat, Apr 8, 2017 at 8:57 AM, Deepa Dinamani
>>> wrote:
>>
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index
On Tue, Dec 6, 2016 at 10:23 AM, Tejun Heo wrote:
> Hello,
>
> On Tue, Dec 06, 2016 at 10:13:53AM -0800, Andy Lutomirski wrote:
>> > Delegation is an explicit operation and reflected in the ownership of
>> > the subdirectories and cgroup interface files in them. The
>> > subhierarchy containment
On Tue, Nov 22, 2016 at 4:57 PM, John Stultz wrote:
> On Tue, Nov 8, 2016 at 4:12 PM, Andy Lutomirski wrote:
>> On Tue, Nov 8, 2016 at 4:03 PM, Alexei Starovoitov
>> wrote:
>>> On Tue, Nov 08, 2016 at 03:51:40PM -0800, Andy Lutomirski wrote:
>>>>
>>&g
On Tue, Nov 8, 2016 at 4:12 PM, Andy Lutomirski wrote:
> On Tue, Nov 8, 2016 at 4:03 PM, Alexei Starovoitov
> wrote:
>> On Tue, Nov 08, 2016 at 03:51:40PM -0800, Andy Lutomirski wrote:
>>>
>>> I hate to say it, but I think I may see a problem. Current
>>> developments are afoot to make cgroups d
> Acked-by: Thomas Gleixner
Ok.. ran the series through the kselftest/timers series and the results look ok.
Acked-by: John Stultz
thanks
-john
On Tue, Nov 8, 2016 at 10:19 AM, Nicolas Pitre wrote:
> On Tue, 8 Nov 2016, John Stultz wrote:
>
>> One spot of concern is that the
>> tools/testing/selftests/timers/posix_timers.c test hangs testing
>> virtual itimers. Looking through the code I'm not seeing whe
On Mon, Nov 7, 2016 at 2:14 PM, Nicolas Pitre wrote:
> Some embedded systems have no use for them. This removes about
> 22KB from the kernel binary size when configured out.
>
> Corresponding syscalls are routed to a stub logging the attempt to
> use those syscalls which should be enough of a clu
Cc: Mark Craske
Cc: Emil Goode
Cc: "David S. Miller"
Cc: YongQin Liu
Cc: Guodong Xu
Cc: Ivan Vecera
Cc: linux-...@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: stable #4.4+
Reported-by: Yongqin Liu
Signed-off-by: John Stultz
---
drivers/net/usb/asix_common.c | 2 +-
1 file
On Wed, May 11, 2016 at 3:00 PM, Dean Jenkins wrote:
>
> Your observations are consistent with missing URBs from the USB host
> controller.
>
> Here is a summary of what I think is happening in your case:
>
> Good case:
> URB #1: 1514 octets of 1514 Ethernet frame (A)
> URB #2: 1514 octets of 1514
On Tue, May 3, 2016 at 2:16 PM, Dean Jenkins wrote:
>
> [ 239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header
> synchronisation was lost, remaining 988
>
> This error message consistently shows the remaining value to be 988, at
> least for the 3 examples provided by John. This does not s
On Tue, May 3, 2016 at 2:16 PM, Dean Jenkins wrote:
> A good test would be to run "ping -c 1 -s $packet_length $ip_address" inside
> a script which has a loop with an increasing payload length $packet_length
> with a small delay between ping calls. This will show whether particular
> packet sizes
On Fri, May 6, 2016 at 8:00 AM, Dean Jenkins wrote:
> My conclusion is that your USB to Ethernet Adaptor is not running at high
> speed (480Mbps) mode which is causing a partial loss (corruption) of
> Ethernet frames across the USB link. A USB Protocol Analyser or software
> tool usbmon could be u
On Thu, May 5, 2016 at 1:11 AM, Dean Jenkins wrote:
> On 05/05/16 00:45, John Stultz wrote:
>>
>> Just as a sample point, I have managed to reproduce exactly this issue
>> on an x86_64 system by simply scp'ing a large file.
>
> Please tell us the x86_64 kernel
ike a straightforward
> substitution in areas which will get plenty of testing
Yea. My main concern is just not stepping on any other maintainers toes.
> I'll grab the patches for now to get them some external testing.
I'd be just as happy if the set went through you Andrew.
For the set: Acked-by: John Stultz
thanks
-john
On Tue, May 3, 2016 at 3:54 AM, Dean Jenkins wrote:
> On 03/05/16 11:04, Guodong Xu wrote:
>>
>> did you test on ARM 64-bit system or ARM 32-bit? I ask because HiKey
>> is an ARM 64-bit system. I suggest we should be careful on that. I saw
>> similar issues when transferring to a 64-bit system in
On Wed, May 4, 2016 at 12:24 PM, Deepa Dinamani wrote:
> struct timespec is not y2038 safe.
> Even though timespec might be sufficient to represent
> timeouts, use struct timespec64 here as the plan is to
> get rid of all timespec reference in the kernel.
>
> The patch transitions the common funct
On Tue, May 3, 2016 at 7:42 AM, David B. Robins wrote:
> On 2016-05-03 00:55, John Stultz wrote:
>>
>> Looking through the commits since the v4.1 kernel where we didn't see
>> this, I narrowed the regression down, and reverting the following two
>> co
In testing with HiKey, we found that since commit 3f30b158eba5c60
(asix: On RX avoid creating bad Ethernet frames), we're seeing lots of
noise during network transfers:
[ 239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header
synchronisation was lost, remaining 988
[ 239.037310] asix 1-1.1
t; Signed-off-by: Bjorn Andersson
I've been using this with my nexus7 tree, and its avoided issues I was
seeing without it.
Tested-by: John Stultz
thanks
-john
Hey Thomas,
So again, here is Christopher's cross-timestamp
infrastructure patchset which I wanted to send along for 4.6.
(Including the minor tweaks you suggested). These apply
against tip/timers/core.
Let me know if you have any objections.
thanks
-john
Cc: Prarit Bhargava
Cc: Richard
lnar
Cc: Andy Lutomirski
Cc: kevin.b.stan...@intel.com
Cc: kevin.j.cla...@intel.com
Cc: h...@zytor.com
Cc: jeffrey.t.kirs...@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner
Signed-off-by: Christopher S. Hall
[jstultz: Reworked to remove extra structures and simplify calling]
S
stopher S. Hall
[jstultz: Moved structure definitions around to clean things up,
fixed cycles_t/cycle_t confusion.]
Signed-off-by: John Stultz
---
include/linux/timekeeping.h | 18 ++
kernel/time/timekeeping.c | 30 ++
2 files changed, 48 insertions(+
ngo Molnar
Cc: Andy Lutomirski
Cc: kevin.b.stan...@intel.com
Cc: kevin.j.cla...@intel.com
Cc: h...@zytor.com
Cc: jeffrey.t.kirs...@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner
Signed-off-by: Christopher S. Hall
Signed-off-by: John Stultz
---
include/linux/pps_ker
argava
Cc: Richard Cochran
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Andy Lutomirski
Cc: kevin.b.stan...@intel.com
Cc: kevin.j.cla...@intel.com
Cc: h...@zytor.com
Cc: jeffrey.t.kirs...@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner
Signed-off-by: Christopher S. Hall
Signed-of
om
Cc: jeffrey.t.kirs...@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner
Signed-off-by: Christopher S. Hall
[jstultz: Fixed up cycles_t/cycle_t type confusion]
Signed-off-by: John Stultz
---
include/linux/timekeeper_internal.h | 2 +
include/linux/timekeeping.h |
y: Richard Cochran
Signed-off-by: Christopher S. Hall
[jstultz: Commit subject tweaks]
Signed-off-by: John Stultz
---
Documentation/ptp/testptp.c | 6 --
drivers/ptp/ptp_chardev.c| 27 +++
include/linux/ptp_clock_kernel.h | 8
include/
effrey.t.kirs...@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner
Signed-off-by: Christopher S. Hall
[jstultz: Tweaked to fix build issue, also reworked math for
64bit division on 32bit systems, as well as !CONFIG_CPU_FREQ build
fixes]
Signed-off-by: John Stultz
---
arch/x8
mirski
Cc: Jeff Kirsher
Cc: kevin.b.stan...@intel.com
Cc: kevin.j.cla...@intel.com
Cc: h...@zytor.com
Cc: jeffrey.t.kirs...@intel.com
Cc: netdev@vger.kernel.org
Acked-by: Jeff Kirsher
Signed-off-by: Christopher S. Hall
[jstultz: Reworked to use new interface, commit message tweaks]
Signed-off-by: J
On Thu, Mar 3, 2016 at 2:27 PM, Jeff Kirsher
wrote:
> Since you are making changes to patch 6's title, then you should fix
> this patch title as well, it should be:
>
> [PATCH 8/8] e1000e: Adds hardware supported...
Ack
-john
On Thu, Mar 3, 2016 at 2:21 AM, Thomas Gleixner wrote:
> On Wed, 2 Mar 2016, John Stultz wrote:
>
> Subject: x86: tsc: Always Running ...
>
> Please make that:
>
> Subject: x86/tsc: Always Running ...
Will do.
>
>>
>> +#else
>> +
>> +#define
stopher S. Hall
[jstultz: Moved structure definitions around to clean things up,
fixed cycles_t/cycle_t confusion.]
Signed-off-by: John Stultz
---
include/linux/timekeeping.h | 18 ++
kernel/time/timekeeping.c | 30 ++
2 files changed, 48 insertions(+
Hey Thomas,
So here is Christopher's cross-timestamp infrastructure
patchset which I wanted to send along for 4.6. These apply against
tip/timers/core.
Let me know if you have any objections.
thanks
-john
Cc: Prarit Bhargava
Cc: Richard Cochran
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc:
ngo Molnar
Cc: Andy Lutomirski
Cc: kevin.b.stan...@intel.com
Cc: kevin.j.cla...@intel.com
Cc: h...@zytor.com
Cc: jeffrey.t.kirs...@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner
Signed-off-by: Christopher S. Hall
Signed-off-by: John Stultz
---
include/linux/pps_ker
lnar
Cc: Andy Lutomirski
Cc: kevin.b.stan...@intel.com
Cc: kevin.j.cla...@intel.com
Cc: h...@zytor.com
Cc: jeffrey.t.kirs...@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner
Signed-off-by: Christopher S. Hall
[jstultz: Reworked to remove extra structures and simplify calling]
S
om
Cc: jeffrey.t.kirs...@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner
Signed-off-by: Christopher S. Hall
[jstultz: Fixed up cycles_t/cycle_t type confusion]
Signed-off-by: John Stultz
---
include/linux/timekeeper_internal.h | 2 +
include/linux/timekeeping.h |
argava
Cc: Richard Cochran
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Andy Lutomirski
Cc: kevin.b.stan...@intel.com
Cc: kevin.j.cla...@intel.com
Cc: h...@zytor.com
Cc: jeffrey.t.kirs...@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner
Signed-off-by: Christopher S. Hall
Signed-of
effrey.t.kirs...@intel.com
Cc: netdev@vger.kernel.org
Reviewed-by: Thomas Gleixner
Signed-off-by: Christopher S. Hall
[jstultz: Tweaked to fix build issue, also reworked math for
64bit division on 32bit systems, as well as !CONFIG_CPU_FREQ build
fixes]
Signed-off-by: John Stultz
---
arch/x8
mirski
Cc: Jeff Kirsher
Cc: kevin.b.stan...@intel.com
Cc: kevin.j.cla...@intel.com
Cc: h...@zytor.com
Cc: jeffrey.t.kirs...@intel.com
Cc: netdev@vger.kernel.org
Acked-by: Jeff Kirsher
Signed-off-by: Christopher S. Hall
[jstultz: Reworked to use new interface, commit message tweaks]
Signed-off-by: J
y: Richard Cochran
Signed-off-by: Christopher S. Hall
[jstultz: Commit subject tweaks]
Signed-off-by: John Stultz
---
Documentation/ptp/testptp.c | 6 --
drivers/ptp/ptp_chardev.c| 27 +++
include/linux/ptp_clock_kernel.h | 8
include/
On Wed, Feb 24, 2016 at 2:56 AM, Thomas Gleixner wrote:
> On Mon, 22 Feb 2016, Christopher S. Hall wrote:
>> +{
>> + struct timekeeper *tk = &tk_core.timekeeper;
>> + bool interp_forward;
>> + u64 corr_raw, corr_real;
>> + int ret;
>
> Once more:
>
> struct timekeeper *tk =
On Mon, Feb 22, 2016 at 10:33 AM, Christopher Hall
wrote:
> I just sent another patchset (v8). I corrected the comment problems pointed
> out by Richard Cochran. I also changed the arch/x86 code to use "non-stop"
> TSC rather than "invariant" TSC. They are *exactly* the same thing (i.e.
> read fro
On Thu, Feb 18, 2016 at 2:17 PM, Richard Cochran
wrote:
> On Fri, Feb 12, 2016 at 12:25:26PM -0800, Christopher S. Hall wrote:
>> /**
>> * get_device_system_crosststamp - Synchronously capture system/device
>> timestamp
>> - * @sync_devicetime: Callback to get simultaneous device time and
>> +
On Fri, Feb 12, 2016 at 12:25 PM, Christopher S. Hall
wrote:
> Modern Intel hardware adds an Always Running Timer (ART) that allows the
> network and audio device clocks to precisely cross timestamp the device
> clock with the system clock. This allows a precise correlation of the
> device time an
On Mon, Jan 4, 2016 at 4:45 AM, Christopher S. Hall
wrote:
> @@ -13,6 +13,9 @@
> /**
> * struct tk_read_base - base structure for timekeeping readout
> * @clock: Current clocksource used for timekeeping.
> + * @cs_seq:Clocksource sequence is incremented per clocksource change.
> + *
On Mon, Jan 4, 2016 at 4:45 AM, Christopher S. Hall
wrote:
> The code in ktime_get_snapshot() is a superset of the code in
> ktime_get_raw_and_real() code. Changes the latter to call the former. A
> side effect of this is that ktime_get_raw_and_real() returns two clock
> times corresponding to the
On Mon, Jan 4, 2016 at 4:45 AM, Christopher S. Hall
wrote:
> ACKNOWLEDGMENT: The original correlated clock source and cross
> timestamp code was developed by Thomas Gleixner
> . It has changed considerably and any mistakes are
> mine.
>
> The precision with which events on multiple networked syste
On Tue, Nov 3, 2015 at 11:18 AM, Stanton, Kevin B
wrote:
> On Wed, 21 Oct 2015, Thomas Gleixner wrote:
>> On Tue, 20 Oct 2015, John Stultz wrote:
>>> Being able to have various hardware sharing a time base is quite
>>> useful, and methods for correlating timestamps tog
On Tue, Oct 20, 2015 at 12:11 PM, Thomas Gleixner wrote:
> On Tue, 20 Oct 2015, Richard Cochran wrote:
>> On Tue, Oct 20, 2015 at 01:51:13PM +0200, Richard Cochran wrote:
>> > You can, in fact, achieve "proper" correlation by sampling. As John
>> > said, the question is whether the method in the
On Mon, Oct 19, 2015 at 5:18 PM, Christopher Hall
wrote:
> On Thu, 15 Oct 2015 01:15:57 -0700, Thomas Gleixner
> wrote:
>>>
>>> >
>>> > > +#define SHADOW_HISTORY_DEPTH 7
>>> >
>>> > And that number is 7 because?
>>>
>>> Due to power of 2 it will be 8 instead. As above the useful history is
>>> 8-
the ptp subsystem), so
>> > I have to convert that driver at the same time.
>> >
>> > The patches should ideally stay together as a series, but they do
>> > span multiple subsystems, so I'm also looking for the right person
>> > to merge them.
>
On Thu, Sep 3, 2015 at 4:20 PM, Hall, Christopher S
wrote:
> For example, supply the ART value as an argument and, in the case of the
> realtime
> clock, keep a short history of clock changes. It would fail in cases where
> there
> are a lot of calls to adjtimex(), but it will would work most o
On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall
wrote:
> +static bool checked_art_to_tsc(cycle_t *tsc)
> +{
> + if (!has_art())
> + return false;
> + *tsc = art_to_tsc(*tsc);
> + return true;
> +}
> +
> +static int art_to_rawmono64(struct timespec64 *rawmono, cycl
On Mon, Jul 27, 2015 at 8:44 PM, John Stultz wrote:
> On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall
> wrote:
>> * counter_to_rawmono64
>> * counter_to_mono64
>> * counter_to_realtime64
>>
>> Enables drivers to translate a captured system clock counter t
On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall
wrote:
> * counter_to_rawmono64
> * counter_to_mono64
> * counter_to_realtime64
>
> Enables drivers to translate a captured system clock counter to system
> time. This is useful for network and audio devices that capture timestamps
> in terms of bo
m this patch it looks like the FRV arch could be trivially converted
to GENERIC_TIME.
Would you consider the following, totally untested patch?
Signed-off-by: John Stultz <[EMAIL PROTECTED]>
Kconfig |4 ++
kernel/time.c | 81 ---
Both of these were seen on my laptop w/ the current (as of this writing)
-git tree using the e1000 driver after a suspend/resume cycle.
thanks
-john
BUG: warning at net/core/dev.c:1171/skb_checksum_help()
[] show_trace_log_lvl+0x149/0x170
[] show_trace+0x1b/0x20
[] dump_stack+0x24/0x30
[] skb
81 matches
Mail list logo
