From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2722AC432C0 for ; Wed, 27 Nov 2019 13:53:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3CE4520678 for ; Wed, 27 Nov 2019 13:53:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=goldelico.com header.i=@goldelico.com header.b="k/94Cqjb" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726655AbfK0Nx3 (ORCPT ); Wed, 27 Nov 2019 08:53:29 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.20]:13223 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726320AbfK0Nx3 (ORCPT ); Wed, 27 Nov 2019 08:53:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1574862802; s=strato-dkim-0002; d=goldelico.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=PPfP9mcJWSMHbHZqS0bO2czGghIr6I3dL5HsA0oLoIM=; b=k/94Cqjbxx07BvkSczailp9egoLObssDj2r2bmrjjPCfw1x0YL7ay+Rx/Ylf8wS1oa qa5elIZx45+g8uOfurXsGRKszzLaPInKdKXLCc8b8EcCvC+Zr1smpqXuWSHDKG+SUj4+ q3frNHcYVX0As3iJRe3ZppkN8DF5iyAjnDmt1Hgxm9w3WPjsNjoWqE+CfO6GMtcM2KSG rr1jWdKcjiAOGhZEfT3ZDnQ7U0xzONsZcFZ+noL9yvM/zjbK6nCKusZZXnqABe5BpIPP UF+KYtoECS4F/Vmy6PTdLMda9UQeSRnc4JIeRUhSJiEBMI6N5ajAomACmqGw+1+6IoHt tBSQ== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBj4Qpw9iZeHmMjw47pbCs=" X-RZG-CLASS-ID: mo00 Received: from imac.fritz.box by smtp.strato.de (RZmta 45.0.2 DYNA|AUTH) with ESMTPSA id y07703vARDrKDnf (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Wed, 27 Nov 2019 14:53:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: MIPS: bug: gettimeofday syscall broken on CI20 board From: "H. Nikolaus Schaller" In-Reply-To: <3190d1a4-96c4-1843-3ae1-bae3a97af9fb@arm.com> Date: Wed, 27 Nov 2019 14:53:20 +0100 Cc: Ralf Baechle , Paul Burton , linux-mips@vger.kernel.org, Linux Kernel Mailing List , MIPS Creator CI20 Development , Discussions about the Letux Kernel Content-Transfer-Encoding: quoted-printable Message-Id: <8D151C34-41A1-4DFE-92D6-D1B27AEC8730@goldelico.com> References: <18788C50-F29B-4BD7-89F6-B056FF490214@goldelico.com> <703DC004-96E8-463D-8870-3CC410FE1C5E@goldelico.com> <3190d1a4-96c4-1843-3ae1-bae3a97af9fb@arm.com> To: Vincenzo Frascino X-Mailer: Apple Mail (2.3124) Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org Hi Vincenzo, > Am 26.11.2019 um 11:52 schrieb Vincenzo Frascino = : >=20 > Hi Nikolaus, >=20 > sorry for the delay in answering to your email but due to personal = reasons I had > to pull off the linux development for few weeks. No problem. >=20 > On 17/11/2019 13:14, H. Nikolaus Schaller wrote: >> Hi Vincenzo, >>=20 >=20 > [...] >=20 >>=20 >> If I look at the definition of vdso_data it *is* significantly = differen >> from mips_vdso_data. >>=20 >> What I would assume is that the struct mips_vdso_data is embossed in = user >> space code and therefore using vdso_data instead is breaking API. >>=20 >=20 > vdso_data and mips_vdso_data before are not part of the ABI hence they = are not > bind by a contract with the userspace. >=20 > This means that they can change at any point and if a userspace = software relies > on a specific layout of these data structures is doing something = wrong. Maybe the libs are clever enough to find that out dynamically but I have = no idea about how gettimeofday() and user-space VDSO is implemented to = handle such changes. >=20 >> Please advise what I should try or check to narrow down further. >>=20 >=20 > I had a look at [1] line 200 and seems that the error you are seeing = is > generated by: > if (gettimeofday(&tv, NULL) =3D=3D -1) { ... } Yes. > I do not have a CI20 hence I can't do the test myself: could you = please write a > small application that invokes gettimeofday() as per above and report = the > behavior (I am even interested in the value returned). If we can = reproduce the > problem in a smaller environment it is easier to debug and get to the = solution. >=20 > [1] = http://users.isc.org/~each/doxygen/bind9/isc_2unix_2time_8c-source.html >=20 >> BR and thanks, >> Nikolaus Schaller >>=20 >=20 > Let me know. I have done this and it seems as if tv_usec reports something that is = beyond 1e6 us or remains unchanged by the syscall. tv_sec seems to be set correctly. = And, gettimeofday() reports -1. hwclock isn't set on 45.4 kernel because I have no ethernet connection = due to the bug. BR, Nikolaus Here is the log a) with 5.4 kernel root@letux:~# cat gettime.c=20 #include #include #include int main(void) { struct timeval tv; int r =3D gettimeofday(&tv, NULL); time_t t; int rt =3D time(&t); printf("r =3D %d\n", r); printf("tv.sec =3D %ld\n", tv.tv_sec); printf("tv.usec =3D %d\n", tv.tv_usec); printf("rt =3D %d\n", rt); printf("t =3D %ld\n", t); } root@letux:~# make gettime cc gettime.c -o gettime root@letux:~# ./gettime=20 r =3D -1 tv.sec =3D 1431857456 tv.usec =3D 2012065500 rt =3D 1478206565 t =3D 1478206565 root@letux:~# ./gettime=20 r =3D -1 tv.sec =3D 1431873840 tv.usec =3D 2012065500 rt =3D 1478206573 t =3D 1478206573 root@letux:~# uname -a Linux letux 5.4.0-letux-l400+ #1485 PREEMPT Wed Nov 27 10:23:16 CET 2019 = mips GNU/Linux root@letux:~# cat /proc/cpuinfo=20 system type : JZ4780 machine : img,ci20 processor : 0 cpu model : Ingenic JZRISC V4.15 FPU V0.0 BogoMIPS : 1196.85 wait instruction : yes microsecond timers : no tlb_entries : 32 extra interrupt vector : yes hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff] isa : mips1 mips2 mips32r1 mips32r2 ASEs implemented : shadow register sets : 1 kscratch registers : 0 package : 0 core : 0 VCED exceptions : not available VCEI exceptions : not available root@letux:~# dpkg -l | grep libc6 ii libc6:mipsel 2.24-11+deb9u4 mipsel = GNU C Library: Shared libraries ii libc6-dev:mipsel 2.24-11+deb9u4 mipsel = GNU C Library: Development Libraries and Header Files root@letux:~# cat /etc/debian_version=20 9.11 root@letux:~#=20 b) same system booted with 4.19 kernel: root@letux:~# ./gettime=20 r =3D 0 tv.sec =3D 1574862135 tv.usec =3D 27974 rt =3D 1574862135 t =3D 1574862135 root@letux:~# uname -a Linux letux 4.19.86-letux-l400+ #1450 PREEMPT Sun Nov 24 17:17:19 CET = 2019 mips GNU/Linux root@letux:~# cat /proc/cpuinfo=20 system type : JZ4780 machine : img,ci20 processor : 0 cpu model : Ingenic JZRISC V4.15 FPU V0.0 BogoMIPS : 1196.85 wait instruction : yes microsecond timers : no tlb_entries : 32 extra interrupt vector : yes hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff] isa : mips1 mips2 mips32r1 mips32r2 ASEs implemented : shadow register sets : 1 kscratch registers : 0 package : 0 core : 0 VCED exceptions : not available VCEI exceptions : not available root@letux:~# cat /etc/debian_version=20 9.11 root@letux:~#=20