Date   

[Git][cip-project/cip-kernel/cip-kernel-sec][master] 2 commits: Fill in commit lists for some issues

Agustin Benito Bethencourt
 

Ben Hutchings pushed to branch master at cip-project / cip-kernel / cip-kernel-sec

Commits:

  • 3a19e752
    by Ben Hutchings at 2019-07-28T23:13:41Z
    Fill in commit lists for some issues
    
  • 37622ea9
    by Ben Hutchings at 2019-07-28T23:14:39Z
    Mark some issues to be ignored for CIP branches
    
    Ignore issues on CIP branches where the affected kernel code is not
    enabled by any members' submitted configuration files.
    

9 changed files:

Changes:

  • issues/CVE-2017-18379.yml
    1 1
     description: 'nvmet-fc: ensure target queue id within range'
    
    2
    +introduced-by:
    
    3
    +  mainline: [c53432030d86429dc9fe5adc3d68cb9d1343b0b2]
    
    2 4
     fixed-by:
    
    3 5
       mainline: [0c319d3a144d4b8f1ea2047fd614d2149b68f889]

  • issues/CVE-2018-12928.yml
    ... ... @@ -17,3 +17,8 @@ comments:
    17 17
       Ubuntu-tyhicks: As of 2018-11-19, there is no upstream fix available
    
    18 18
     reporters:
    
    19 19
     - Sergej Schumilo
    
    20
    +ignore:
    
    21
    +  linux-4.19.y-cip: No member enables the hfs filesystem
    
    22
    +  linux-4.19.y-cip-rt: No member enables the hfs filesystem
    
    23
    +  linux-4.4.y-cip: No member enables the hfs filesystem
    
    24
    +  linux-4.4.y-cip-rt: No member enables the hfs filesystem

  • issues/CVE-2018-20854.yml
    ... ... @@ -6,3 +6,7 @@ references:
    6 6
     - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20854
    
    7 7
     - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6acb47d1a318e5b3b7115354ebc4ea060c59d3a1
    
    8 8
     - https://github.com/torvalds/linux/commit/6acb47d1a318e5b3b7115354ebc4ea060c59d3a1
    
    9
    +introduced-by:
    
    10
    +  mainline: [51f6b410fc220d8a5a4fae00ebfd8243b6c11d4e]
    
    11
    +fixed-by:
    
    12
    +  mainline: [6acb47d1a318e5b3b7115354ebc4ea060c59d3a1]

  • issues/CVE-2018-20855.yml
    ... ... @@ -6,3 +6,8 @@ references:
    6 6
     - https://github.com/torvalds/linux/commit/0625b4ba1a5d4703c7fb01c497bd6c156908af00
    
    7 7
     fixed-by:
    
    8 8
       mainline: [0625b4ba1a5d4703c7fb01c497bd6c156908af00]
    
    9
    +ignore:
    
    10
    +  linux-4.19.y-cip: No member enables the mlx5_ib driver
    
    11
    +  linux-4.19.y-cip-rt: No member enables the mlx5_ib driver
    
    12
    +  linux-4.4.y-cip: No member enables the mlx5_ib driver
    
    13
    +  linux-4.4.y-cip-rt: No member enables the mlx5_ib driver

  • issues/CVE-2018-20856.yml
    ... ... @@ -4,6 +4,8 @@ references:
    4 4
     - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.18.7
    
    5 5
     - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=54648cf1ec2d7f4b6a71767799c45676a138ca24
    
    6 6
     - https://github.com/torvalds/linux/commit/54648cf1ec2d7f4b6a71767799c45676a138ca24
    
    7
    +introduced-by:
    
    8
    +  mainline: [7c94e1c157a227837b04f02f5edeff8301410ba2]
    
    7 9
     fixed-by:
    
    8 10
       linux-4.14.y: [0affbaece6d0b7c75c5166732d0481ae9a28be60]
    
    9 11
       mainline: [54648cf1ec2d7f4b6a71767799c45676a138ca24]

  • issues/CVE-2019-13631.yml
    ... ... @@ -8,3 +8,8 @@ fixed-by:
    8 8
       linux-4.19.y: [d657077eda7b5572d86f2f618391bb016b5d9a64]
    
    9 9
       linux-5.2.y: [63fabf4287b23da069986b7a7fdc6ad0b202f00a]
    
    10 10
       mainline: [2a017fd82c5402b3c8df5e3d6e5165d9e6147dc1]
    
    11
    +ignore:
    
    12
    +  linux-4.19.y-cip: No members enable the gtco driver
    
    13
    +  linux-4.19.y-cip-rt: No members enable the gtco driver
    
    14
    +  linux-4.4.y-cip: No members enable the gtco driver
    
    15
    +  linux-4.4.y-cip-rt: No members enable the gtco driver

  • issues/CVE-2019-13648.yml
    ... ... @@ -12,3 +12,6 @@ introduced-by:
    12 12
       mainline: [2b0a576d15e0e14751f00f9c87e46bad27f217e7]
    
    13 13
     fixed-by:
    
    14 14
       mainline: [f16d80b75a096c52354c6e0a574993f3b0dfbdfe]
    
    15
    +ignore:
    
    16
    +  linux-4.19.y-cip: No members are using powerpc
    
    17
    +  linux-4.19.y-cip-rt: No members are using powerpc

  • issues/CVE-2019-14283.yml
    ... ... @@ -3,3 +3,6 @@ fixed-by:
    3 3
       linux-4.19.y: [ff54c44f103825a426e46d08b5d3d76e44791a87]
    
    4 4
       linux-5.2.y: [d39c2e97277229970fe2ae56dcbf67a535e14873]
    
    5 5
       mainline: [da99466ac243f15fbba65bd261bfc75ffa1532b6]
    
    6
    +ignore:
    
    7
    +  linux-4.19.y-cip: No members enable the floppy driver
    
    8
    +  linux-4.19.y-cip-rt: No members enable the floppy driver

  • issues/CVE-2019-14284.yml
    ... ... @@ -3,3 +3,6 @@ fixed-by:
    3 3
       linux-4.19.y: [6e34fd07484a0622a17b40e0ca89ed451260ef45]
    
    4 4
       linux-5.2.y: [697c0af7468a941522c1e26345aa5128fa2a4815]
    
    5 5
       mainline: [f3554aeb991214cbfafd17d55e2bfddb50282e32]
    
    6
    +ignore:
    
    7
    +  linux-4.19.y-cip: No members enable the floppy driver
    
    8
    +  linux-4.19.y-cip-rt: No members enable the floppy driver


  • [Git][cip-project/cip-kernel/cip-kernel-sec][master] Import more data

    Agustin Benito Bethencourt
     

    Ben Hutchings pushed to branch master at cip-project / cip-kernel / cip-kernel-sec

    Commits:

    • ceaff914
      by Ben Hutchings at 2019-07-28T22:52:16Z
      Import more data
      

    24 changed files:

    Changes:

  • issues/CVE-2017-18379.yml
    1
    +description: 'nvmet-fc: ensure target queue id within range'
    
    2
    +fixed-by:
    
    3
    +  mainline: [0c319d3a144d4b8f1ea2047fd614d2149b68f889]

  • issues/CVE-2018-20836.yml
    ... ... @@ -2,6 +2,7 @@ description: 'scsi: libsas: fix a race condition when smp task timeout'
    2 2
     references:
    
    3 3
     - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20836
    
    4 4
     - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b90cd6f2b905905fb42671009dc0e27c310a16ae
    
    5
    +- https://usn.ubuntu.com/usn/usn-4076-1
    
    5 6
     comments:
    
    6 7
       Debian-bwh: |-
    
    7 8
         Note that the fix depends on the low-level device drivers setting the
    

  • issues/CVE-2018-20854.yml
    1
    +description: |-
    
    2
    +  An issue was discovered in the Linux kernel before 4.20.
    
    3
    +  drivers/phy/mscc/phy-ocelot-serdes.c has an off-by-one error with a
    
    4
    +  resultant ctrl->phys out-of-bounds read.
    
    5
    +references:
    
    6
    +- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20854
    
    7
    +- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6acb47d1a318e5b3b7115354ebc4ea060c59d3a1
    
    8
    +- https://github.com/torvalds/linux/commit/6acb47d1a318e5b3b7115354ebc4ea060c59d3a1

  • issues/CVE-2018-20855.yml
    1
    +description: 'IB/mlx5: Fix leaking stack memory to userspace'
    
    2
    +references:
    
    3
    +- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20855
    
    4
    +- https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.18.7
    
    5
    +- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0625b4ba1a5d4703c7fb01c497bd6c156908af00
    
    6
    +- https://github.com/torvalds/linux/commit/0625b4ba1a5d4703c7fb01c497bd6c156908af00
    
    7
    +fixed-by:
    
    8
    +  mainline: [0625b4ba1a5d4703c7fb01c497bd6c156908af00]

  • issues/CVE-2018-20856.yml
    1
    +description: 'block: blk_init_allocated_queue() set q->fq as NULL in the fail case'
    
    2
    +references:
    
    3
    +- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20856
    
    4
    +- https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.18.7
    
    5
    +- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=54648cf1ec2d7f4b6a71767799c45676a138ca24
    
    6
    +- https://github.com/torvalds/linux/commit/54648cf1ec2d7f4b6a71767799c45676a138ca24
    
    7
    +fixed-by:
    
    8
    +  linux-4.14.y: [0affbaece6d0b7c75c5166732d0481ae9a28be60]
    
    9
    +  mainline: [54648cf1ec2d7f4b6a71767799c45676a138ca24]

  • issues/CVE-2019-10126.yml
    ... ... @@ -7,6 +7,7 @@ fixed-by:
    7 7
       linux-3.16.y: [a62393d7eb63bd075c51154002825cc7ab4dd3eb]
    
    8 8
       linux-4.14.y: [b1459fb34061337efbf0d47a3ba6208f2f59829d]
    
    9 9
       linux-4.19.y: [c7e427e28a3a2d1b89b8f9fa7c3f559774d91a7b]
    
    10
    +  linux-4.19.y-cip: [c7e427e28a3a2d1b89b8f9fa7c3f559774d91a7b]
    
    10 11
       linux-4.4.y: [3a611df229a90247c9a5159d136c60f4008c29a2]
    
    11 12
       linux-4.9.y: [f70d411e2ecd1f8297e1fd7e91108ca220986784]
    
    12 13
       linux-5.1.y: [e9111176d9c195ba709245f1bf1d3d1dae5cd22a]
    

  • issues/CVE-2019-10142.yml
    ... ... @@ -4,6 +4,7 @@ references:
    4 4
     - https://www.openwall.com/lists/oss-security/2019/05/22/5
    
    5 5
     - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10142
    
    6 6
     - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10142
    
    7
    +- https://usn.ubuntu.com/usn/usn-4076-1
    
    7 8
     comments:
    
    8 9
       Debian-carnil: CONFIG_FSL_HV_MANAGER not enabled, so only affected source-wise.
    
    9 10
       Ubuntu-sbeattie: depends on freescale (ppc) only
    

  • issues/CVE-2019-10207.yml
    1
    +description: 'bluetooth: hci_uart: 0x0 address  execution as nonprivileged user'
    
    2
    +references:
    
    3
    +- https://www.openwall.com/lists/oss-security/2019/07/25/1
    
    4
    +- https://lore.kernel.org/linux-bluetooth/20190725120909.31235-1-vdronov@.../T/#u

  • issues/CVE-2019-10638.yml
    ... ... @@ -15,6 +15,12 @@ comments:
    15 15
         Versions older than 4.1 might need 55f0fc7a02de ("inet: update
    
    16 16
         the IP ID generation algorithm to higher standards.").
    
    17 17
         This needs clarifying on the fixing commits.
    
    18
    +  Ubuntu-tyhicks: |-
    
    19
    +    Kernels prior to 4.1 also need the following commit
    
    20
    +     https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-3.16.y&id=8b197d3ce585d6777197e0633d71e5af7d98cb35
    
    21
    +reporters:
    
    22
    +- Amit Klein
    
    23
    +- Benny Pinkas
    
    18 24
     fixed-by:
    
    19 25
       linux-3.16.y: [188da790e1f4d164bcfdea486e91fd47e1ba59c5]
    
    20 26
       linux-4.14.y: [adbb8bdd392db14dc80ad1ac29f8f1d37ab57a62]
    

  • issues/CVE-2019-10639.yml
    ... ... @@ -12,6 +12,11 @@ comments:
    12 12
         leak through IPv4 IDs since commit b6a7719aedd7 "ipv4: hash net ptr
    
    13 13
         into fragmentation bucket selection" in Linux 4.1.  However, other
    
    14 14
         uses may also leak the address in 3.16.
    
    15
    +reporters:
    
    16
    +- Amit Klein
    
    17
    +- Benny Pinkas
    
    18
    +introduced-by:
    
    19
    +  mainline: [0b4419162aa6c4204843f3a13b48d9ab821d3167]
    
    15 20
     fixed-by:
    
    16 21
       linux-3.16.y: [188da790e1f4d164bcfdea486e91fd47e1ba59c5]
    
    17 22
       linux-4.14.y: [adbb8bdd392db14dc80ad1ac29f8f1d37ab57a62]
    

  • issues/CVE-2019-11085.yml
    ... ... @@ -6,6 +6,8 @@ references:
    6 6
     - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11085
    
    7 7
     - https://git.kernel.org/linus/51b00d8509dc69c98740da2ad07308b630d3eb7d
    
    8 8
     - https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00249.html
    
    9
    +- https://usn.ubuntu.com/usn/usn-4068-1
    
    10
    +- https://usn.ubuntu.com/usn/usn-4068-2
    
    9 11
     comments:
    
    10 12
       Debian-carnil: |-
    
    11 13
         Commit fixes 659643f7d814 ("drm/i915/gvt/kvmgt: add vfio/mdev
    

  • issues/CVE-2019-11487.yml
    ... ... @@ -13,6 +13,7 @@ references:
    13 13
     - https://github.com/torvalds/linux/commit/88b1a17dfc3ed7728316478fae0f5ad508f50397
    
    14 14
     - https://github.com/torvalds/linux/commit/8fde12ca79aff9b5ba951fce1a2641901b8d8e64
    
    15 15
     - https://github.com/torvalds/linux/commit/f958d7b528b1b40c44cfda5eabe2d82760d868c3
    
    16
    +- https://usn.ubuntu.com/usn/usn-4069-1
    
    16 17
     comments:
    
    17 18
       Debian-bwh: |-
    
    18 19
         I'm having trouble backporting to this to 3.16 because we don't
    

  • issues/CVE-2019-11599.yml
    ... ... @@ -7,6 +7,7 @@ references:
    7 7
     - http://www.openwall.com/lists/oss-security/2019/04/29/1
    
    8 8
     - http://www.openwall.com/lists/oss-security/2019/04/29/2
    
    9 9
     - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=04f5866e41fb70690e28397487d8bd8eea7d712a
    
    10
    +- https://usn.ubuntu.com/usn/usn-4069-1
    
    10 11
     comments:
    
    11 12
       Debian-bwh: |-
    
    12 13
         The backports to 4.4 and 4.9 are still under discussion.
    

  • issues/CVE-2019-11815.yml
    ... ... @@ -9,6 +9,8 @@ references:
    9 9
     - https://usn.ubuntu.com/usn/usn-4005-1
    
    10 10
     - https://usn.ubuntu.com/usn/usn-4008-1
    
    11 11
     - https://usn.ubuntu.com/usn/usn-4008-3
    
    12
    +- https://usn.ubuntu.com/usn/usn-4068-1
    
    13
    +- https://usn.ubuntu.com/usn/usn-4068-2
    
    12 14
     comments:
    
    13 15
       Debian-bwh: |-
    
    14 16
         Introduced in 4.3 by commit 467fa15356ac "RDS-TCP: Support multiple
    

  • issues/CVE-2019-11833.yml
    ... ... @@ -3,6 +3,10 @@ references:
    3 3
     - https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?id=592acbf16821288ecdc4192c47e3774a4c48bb64
    
    4 4
     - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11833
    
    5 5
     - https://github.com/torvalds/linux/commit/592acbf16821288ecdc4192c47e3774a4c48bb64
    
    6
    +- https://usn.ubuntu.com/usn/usn-4068-1
    
    7
    +- https://usn.ubuntu.com/usn/usn-4068-2
    
    8
    +- https://usn.ubuntu.com/usn/usn-4069-1
    
    9
    +- https://usn.ubuntu.com/usn/usn-4076-1
    
    6 10
     introduced-by:
    
    7 11
       mainline: [a86c61812637c7dd0c57e29880cffd477b62f2e7]
    
    8 12
     fixed-by:
    

  • issues/CVE-2019-11884.yml
    ... ... @@ -4,6 +4,10 @@ references:
    4 4
     - https://git.kernel.org/linus/a1616a5ac99ede5d605047a9012481ce7ff18b16
    
    5 5
     - https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.0.15
    
    6 6
     - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a1616a5ac99ede5d605047a9012481ce7ff18b16
    
    7
    +- https://usn.ubuntu.com/usn/usn-4068-1
    
    8
    +- https://usn.ubuntu.com/usn/usn-4068-2
    
    9
    +- https://usn.ubuntu.com/usn/usn-4069-1
    
    10
    +- https://usn.ubuntu.com/usn/usn-4076-1
    
    7 11
     comments:
    
    8 12
       Debian-carnil: similar issue to CVE-2011-1079.
    
    9 13
     fixed-by:
    

  • issues/CVE-2019-12456.yml
    ... ... @@ -10,6 +10,7 @@ references:
    10 10
     - https://lkml.org/lkml/2019/5/29/1164
    
    11 11
     - https://bugzilla.redhat.com/show_bug.cgi?id=1717182#c3
    
    12 12
     comments:
    
    13
    +  Debian-bwh: The double-fetched value is not used after the second fetch
    
    13 14
       Ubuntu-tyhicks: |-
    
    14 15
         There seems to be no security impact as the ioc_number is never used
    
    15 16
          after the "double fetch"
    

  • issues/CVE-2019-13272.yml
    ... ... @@ -21,6 +21,7 @@ introduced-by:
    21 21
       linux-4.9.y: [e747b4ae3b6bca205d82e86366e140cdcbfb7731]
    
    22 22
       mainline: [64b875f7ac8a5d60a4e191479299e931ee949b67]
    
    23 23
     fixed-by:
    
    24
    +  linux-3.16.y: [d5d5bd909a4f03f132ee3fd3f6f0568c8344eee5]
    
    24 25
       linux-4.14.y: [bf71ef9655d25e8b275ec6ed649b6bd719231ddc]
    
    25 26
       linux-4.19.y: [54435b7fff7bfb9515cc457b71c3734c1c3fff76]
    
    26 27
       linux-4.19.y-cip: [54435b7fff7bfb9515cc457b71c3734c1c3fff76]
    

  • issues/CVE-2019-13631.yml
    ... ... @@ -5,4 +5,6 @@ references:
    5 5
     introduced-by:
    
    6 6
       mainline: [a19ceb56cbd1e1beff3e9cf6042e1f31f6487aa6]
    
    7 7
     fixed-by:
    
    8
    +  linux-4.19.y: [d657077eda7b5572d86f2f618391bb016b5d9a64]
    
    9
    +  linux-5.2.y: [63fabf4287b23da069986b7a7fdc6ad0b202f00a]
    
    8 10
       mainline: [2a017fd82c5402b3c8df5e3d6e5165d9e6147dc1]

  • issues/CVE-2019-13648.yml
    ... ... @@ -2,3 +2,13 @@ description: 'powerpc/tm: Fix oops on sigreturn on systems without TM'
    2 2
     references:
    
    3 3
     - https://patchwork.ozlabs.org/patch/1133904/
    
    4 4
     - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13648
    
    5
    +comments:
    
    6
    +  Debian-bwh: |-
    
    7
    +    We have disabled CONFIG_PPC_TRANSACTIONAL_MEM in 4.9.184-1 for
    
    8
    +    other reasons, which I think will also fix this.
    
    9
    +reporters:
    
    10
    +- Praveen Pandey
    
    11
    +introduced-by:
    
    12
    +  mainline: [2b0a576d15e0e14751f00f9c87e46bad27f217e7]
    
    13
    +fixed-by:
    
    14
    +  mainline: [f16d80b75a096c52354c6e0a574993f3b0dfbdfe]

  • issues/CVE-2019-14283.yml
    1
    +description: 'floppy: fix out-of-bounds read in copy_buffer'
    
    2
    +fixed-by:
    
    3
    +  linux-4.19.y: [ff54c44f103825a426e46d08b5d3d76e44791a87]
    
    4
    +  linux-5.2.y: [d39c2e97277229970fe2ae56dcbf67a535e14873]
    
    5
    +  mainline: [da99466ac243f15fbba65bd261bfc75ffa1532b6]

  • issues/CVE-2019-14284.yml
    1
    +description: 'floppy: fix div-by-zero in setup_format_params'
    
    2
    +fixed-by:
    
    3
    +  linux-4.19.y: [6e34fd07484a0622a17b40e0ca89ed451260ef45]
    
    4
    +  linux-5.2.y: [697c0af7468a941522c1e26345aa5128fa2a4815]
    
    5
    +  mainline: [f3554aeb991214cbfafd17d55e2bfddb50282e32]

  • issues/CVE-2019-3846.yml
    ... ... @@ -11,6 +11,7 @@ fixed-by:
    11 11
       linux-3.16.y: [a24ac7326f38ffab2b63141496d075da144cec7d]
    
    12 12
       linux-4.14.y: [d50f6b58d7ad30ad8e96c0bbc3e5ecfe9b91ba77]
    
    13 13
       linux-4.19.y: [d4c0f752c1d2c6383cc7582c19b2ed7159d45937]
    
    14
    +  linux-4.19.y-cip: [d4c0f752c1d2c6383cc7582c19b2ed7159d45937]
    
    14 15
       linux-4.4.y: [5d43b417e60ab25984fc7c41175f3ce8cee992bd]
    
    15 16
       linux-4.9.y: [58ec3690a908494f7a7c3e8a302eb491bef9d979]
    
    16 17
       linux-5.1.y: [cb48f5e50582bf44f63599b78941b325a17fa1ec]
    

  • issues/CVE-2019-9503.yml
    ... ... @@ -7,6 +7,7 @@ references:
    7 7
     - https://usn.ubuntu.com/usn/usn-3981-1
    
    8 8
     - https://usn.ubuntu.com/usn/usn-3980-2
    
    9 9
     - https://usn.ubuntu.com/usn/usn-3981-2
    
    10
    +- https://usn.ubuntu.com/usn/usn-4076-1
    
    10 11
     comments:
    
    11 12
       Debian-bwh: |-
    
    12 13
         For 3.16, a related fix for PCIe and SDIO needs to be applied first:
    


  • Re: powerpc build with Kernel v4.4

    Pavel Machek
     

    Hi!

    I'm trying to build the toshiba_defconfig [1] for the powerpc architecture using the CIP v4.4 Kernel but I'm hitting some problems. The log from the build can be seen on GitLab [2].

    Has anyone tried building this configuration recently?

    I'm using gcc compiler v8.1.0. I mention this because I've see a half-related discussion [3] when Googling. From this mail thread I wonder if there are some patches we need to backport?
    Is there chance to use different gcc? Because this looks like gcc
    bug... but workaround seems simple enough. Let me investigate some
    more.
    Workaround seems simple, but won't easily apply on top of 4.4 kernel

    Can you simply set

    CONFIG_PPC_DISABLE_WERROR=y

    to make the problem go away?

    Best regards,

    Pavel
    --
    DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
    HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


    Re: powerpc build with Kernel v4.4

    Pavel Machek
     

    Hi!

    I'm trying to build the toshiba_defconfig [1] for the powerpc architecture using the CIP v4.4 Kernel but I'm hitting some problems. The log from the build can be seen on GitLab [2].

    Has anyone tried building this configuration recently?

    I'm using gcc compiler v8.1.0. I mention this because I've see a half-related discussion [3] when Googling. From this mail thread I wonder if there are some patches we need to backport?
    Is there chance to use different gcc? Because this looks like gcc
    bug... but workaround seems simple enough. Let me investigate some
    more.

    Pavel





    commit 9d2e929c3bae4c30afd1b00fdbe6f7d477e13e8c
    Author: Michael Ellerman <mpe@ellerman.id.au>
    Date: Thu Feb 14 11:08:29 2019 +1100

    powerpc/ptrace: Simplify vr_get/set() to avoid GCC warning

    commit ca6d5149d2ad0a8d2f9c28cbe379802260a0a5e0 upstream.

    GCC 8 warns about the logic in vr_get/set(), which with -Werror
    breaks
    the build:

    In function ‘user_regset_copyin’,
    inlined from ‘vr_set’ at
    arch/powerpc/kernel/ptrace.c:628:9:
    include/linux/regset.h:295:4: error: ‘memcpy’
    offset [-527, -529] is
    out of the bounds [0, 16] of object ‘vrsave’
    with type ‘union
    <anonymous>’ [-Werror=array-bounds]
    arch/powerpc/kernel/ptrace.c: In function
    ‘vr_set’:
    arch/powerpc/kernel/ptrace.c:623:5: note:
    ‘vrsave’ declared here
    } vrsave;

    This has been identified as a regression in GCC, see GCC bug
    88273.

    However we can avoid the warning and also simplify the logic and
    make
    it more robust.



    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


    Re: powerpc build with Kernel v4.4

    Zoran
     

    Quick ad-hoc observation:

    [1] From https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/260410825
    /opt/build_kernel.sh: line 123: [: /opt/cip-kernel-config/4.4/powerpc/toshiba_defconfig: unary operator expected
    Interesting line...WTH is wrong with the line 123 (CONFIG_SPI_DEBUG=y)?

    [2] From https://lkml.org/lkml/2019/2/27/106
    On Tue, Feb 26, 2019 at 09:29:40AM -0800, Guenter Roeck wrote:
    In function ‘user_regset_copyin’,
    inlined from ‘vr_set’ at arch/powerpc/kernel/ptrace.c:490:9:
    include/linux/regset.h:258:4: error:
    ‘memcpy’ offset [-527, -529] is out of the bounds [0, 16] of object ‘vrsave’
    with type ‘union <anonymous>’

    The problem is not new. It is seen now because I switched to use
    gcc 8.3.0. The problem is fixed in linux-next.
    You should contact Guenter Roeck and ask him about the following:
    The problem is not new. It is seen now because I switched to use
    gcc 8.3.0. The problem is fixed in linux-next.
    Stress on: "The problem is fixed in linux-next".

    My two cent worth thinking,
    Zoran
    _______

    On Sat, Jul 27, 2019 at 11:29 PM Chris Paterson
    <Chris.Paterson2@renesas.com> wrote:

    Hello all,

    I'm trying to build the toshiba_defconfig [1] for the powerpc architecture using the CIP v4.4 Kernel but I'm hitting some problems. The log from the build can be seen on GitLab [2].

    Has anyone tried building this configuration recently?

    I'm using gcc compiler v8.1.0. I mention this because I've see a half-related discussion [3] when Googling. From this mail thread I wonder if there are some patches we need to backport?


    [1] https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/blob/master/4.4/powerpc/toshiba_defconfig
    [2] https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/260410825
    [3] https://lkml.org/lkml/2019/2/27/106

    Kind regards, Chris

    _______________________________________________
    cip-dev mailing list
    cip-dev@lists.cip-project.org
    https://lists.cip-project.org/mailman/listinfo/cip-dev


    powerpc build with Kernel v4.4

    Chris Paterson
     

    Hello all,

    I'm trying to build the toshiba_defconfig [1] for the powerpc architecture using the CIP v4.4 Kernel but I'm hitting some problems. The log from the build can be seen on GitLab [2].

    Has anyone tried building this configuration recently?

    I'm using gcc compiler v8.1.0. I mention this because I've see a half-related discussion [3] when Googling. From this mail thread I wonder if there are some patches we need to backport?


    [1] https://gitlab.com/cip-project/cip-kernel/cip-kernel-config/blob/master/4.4/powerpc/toshiba_defconfig
    [2] https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/260410825
    [3] https://lkml.org/lkml/2019/2/27/106

    Kind regards, Chris


    Re: [ANNOUNCE] v4.19.50-cip3-rt2

    Zoran
     

    Your log is corrupted, see?
    You are correct, I should write that these are preliminary WTH/ad-hoc
    results (I need to fix/rerun these in the correct setup, I know).

    It is usec, not nsec, AFAICT.
    Again, correct. I wrote nsec instead usec, having in mind INTEL
    technology per asm instruction. INTEL illusions/delusions in my brain.
    I am trying to catch up on armv7, A8 and A9, since these gadgets
    started ruling the embedded industry.

    Thank you,
    Zoran
    _______

    On Fri, Jul 26, 2019 at 11:05 PM Pavel Machek <pavel@denx.de> wrote:

    On Wed 2019-07-24 18:06:46, Zoran S wrote:
    (limitations): I could NOT connect with ETH to target (something is
    wrongly set with my local.conf for YOCTO rootfs)...

    Here is my approximate recipe for rootfs I am using for the test
    (initramfs) for your inspection (it is thud, local.conf moved to
    warrior):
    https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/local.conf

    More or/and less, here are results after approximately 63 minutes of
    running rt-tests:

    root@beaglebone:~# uname -a
    Linux beaglebone 4.19.13-cip1-rt1 #1 PREEMPT RT Tue Jul 23 12:18:18
    GMT 2019 armv7l GNU/Linux
    _______
    policy: fifo: loadavg: 291.28 287.63 267.78 21/486 30014
    policy: fifo: loadavg: 186.97 215.90 243.41 5/458 22788
    policy: fifo: loadavg: 248.16 243.95 244.63 194/486 8800
    policy: fifo: loadavg: 283.55 240.50 243.74 9/318 2383
    T: 0 (13903) P:80 I:1000 C:3942593 Min: 19 Act: 52 Avg: 45 Max: 93
    T: 0 (13903) P:80 I:1000 C:3785664 Min: 19 Act: 44 Avg: 45 Max: 935
    T: 0 (13903) P:80 I:1000 C:3716107 Min: 19 Act: 60 Avg: 45 Max: 936
    policy: fifo: loadavg: 222.11 176.72 90.66 5/213 21249
    T: 0 (13903) P:80 I:1000 C:2213895 Min: 19 Act: 38 Avg: 46 Max: 905
    T: 0 (13903) P:80 I:1000 C: 181403 Min: 21 Act: 49 Avg: 45 Max: 90
    T: 0 (13903) P:80 I:1000 C: 181320 Min: 21 Act: 29 Avg: 45 Max: 90
    Your log is corrupted, see?

    If it was real, it would be

    Max: 905
    Max: 90

    But you have

    Max: 905
    Max: 90

    Notice the whitespace.

    MIN 19 ns, MAX 936 ns (3x over 900 ns)... I would be really concerned
    about MAX over > 900 ns!
    It is usec, not nsec, AFAICT.

    Best regards,
    Pavel

    --
    DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
    HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


    [ANNOUNCE] Release 4.19.60-cip7

    Nobuhiro Iwamatsu
     

    Hi all,

    CIP kernel team has released Linux kernel 4.19.60-cip7.

    Linux-4.19.y-cip has been updated from base version from 4.19.58 to 4.19.60,
    and applied renesas's patches.

    You can get this release via the git tree at:

    4.19.60-cip7:

    repository: https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
    branch: linux-4.19.y-cip
    commit: 2951eded01232408c8fc845d2ae30c9d4ce81807

    Best regards,
    Nobuhiro


    Re: [ANNOUNCE] v4.19.50-cip3-rt2

    Pavel Machek
     

    On Wed 2019-07-24 18:06:46, Zoran S wrote:
    (limitations): I could NOT connect with ETH to target (something is
    wrongly set with my local.conf for YOCTO rootfs)...

    Here is my approximate recipe for rootfs I am using for the test
    (initramfs) for your inspection (it is thud, local.conf moved to
    warrior):
    https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/local.conf

    More or/and less, here are results after approximately 63 minutes of
    running rt-tests:

    root@beaglebone:~# uname -a
    Linux beaglebone 4.19.13-cip1-rt1 #1 PREEMPT RT Tue Jul 23 12:18:18
    GMT 2019 armv7l GNU/Linux
    _______
    policy: fifo: loadavg: 291.28 287.63 267.78 21/486 30014
    policy: fifo: loadavg: 186.97 215.90 243.41 5/458 22788
    policy: fifo: loadavg: 248.16 243.95 244.63 194/486 8800
    policy: fifo: loadavg: 283.55 240.50 243.74 9/318 2383
    T: 0 (13903) P:80 I:1000 C:3942593 Min: 19 Act: 52 Avg: 45 Max: 93
    T: 0 (13903) P:80 I:1000 C:3785664 Min: 19 Act: 44 Avg: 45 Max: 935
    T: 0 (13903) P:80 I:1000 C:3716107 Min: 19 Act: 60 Avg: 45 Max: 936
    policy: fifo: loadavg: 222.11 176.72 90.66 5/213 21249
    T: 0 (13903) P:80 I:1000 C:2213895 Min: 19 Act: 38 Avg: 46 Max: 905
    T: 0 (13903) P:80 I:1000 C: 181403 Min: 21 Act: 49 Avg: 45 Max: 90
    T: 0 (13903) P:80 I:1000 C: 181320 Min: 21 Act: 29 Avg: 45 Max: 90
    Your log is corrupted, see?

    If it was real, it would be

    Max: 905
    Max: 90

    But you have

    Max: 905
    Max: 90

    Notice the whitespace.

    MIN 19 ns, MAX 936 ns (3x over 900 ns)... I would be really concerned
    about MAX over > 900 ns!
    It is usec, not nsec, AFAICT.

    Best regards,
    Pavel

    --
    DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
    HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


    Re: [ANNOUNCE] v4.4.185-cip35-rt24

    Daniel Wagner <wagi@...>
     

    Hi,

    It should be reproducable on a TK1:
    Today I got from Jan the TK1 for testing. After the usual WTF with u-boot and kernel configs, I am able to reproduce it. Let's see what's going wrong.

    Thanks,
    Daniel


    Re: [ANNOUNCE] v4.4.185-cip35-rt24

    Ralf Ramsauer <ralf.ramsauer@...>
     

    Hi,

    On 7/25/19 11:12 AM, Daniel Wagner wrote:
    Hi Jan,

    On 7/25/19 11:06 AM, Jan Kiszka wrote:
    So if someone is willing to lend me a board, I can't try to reproduce
    it.
    Which one do you need? I have a TK1 in reach, Ralf should have a TX1
    with the
    potential of remote access.
    Yep, he does.


    It should be reproducable on a TK1:

    https://lore.kernel.org/stable/f32de22f-c928-2eaa-ee3f-d2b26c184dd4@nvidia.com/


    So if I could get hands on one of those, it would really help.
    You can either get your hands dirty on your own, or you simply give me a
    .config together with a commit hash and a short description what I
    should test. The latter is probably the easier choice, if the test isn't
    that complex.


    Remote access is also good, if the uplink from the board is reasonable
    fast. I finally got a fast uplink (400MBit/s) :)
    Come on, 400Mbit/s... But it should be fast enough to tease our 1GBit/s
    DFN network ;-)

    Ralf


    Thanks,
    Daniel


    Re: [ANNOUNCE] v4.4.185-cip35-rt24

    Daniel Wagner <wagi@...>
     

    Hi Jan,

    On 7/25/19 11:06 AM, Jan Kiszka wrote:
    So if someone is willing to lend me a board, I can't try to reproduce it.
    Which one do you need? I have a TK1 in reach, Ralf should have a TX1 with the
    potential of remote access.
    It should be reproducable on a TK1:

    https://lore.kernel.org/stable/f32de22f-c928-2eaa-ee3f-d2b26c184dd4@nvidia.com/

    So if I could get hands on one of those, it would really help.

    Remote access is also good, if the uplink from the board is reasonable fast. I finally got a fast uplink (400MBit/s) :)

    Thanks,
    Daniel


    Re: [ANNOUNCE] v4.4.185-cip35-rt24

    Jan Kiszka
     

    On 25.07.19 10:50, Daniel Wagner wrote:
    Hi,

    On 7/23/19 11:12 PM, Pavel Machek wrote:
    v4.4.185-cip35-rt24 should be available at kernel.org.

    Daniel says:
    # in the v4.4-rt is still a problem with f01f17d3705b ("mm,
    # vmstat: make quiet_vmstat lighter"). It is needed to boot on x86_64
    # but it breaks on NVIDIA's boards, e.g. Jetson. Unfortunately, I don't
    # have a NVIDIA board in my lab to figure out what is missing. So I
    # suspect there is a still a problem hidden in the current v4.4-rt tree.

    I did nothing to solve that problem. If someone uses NVIDIA boards,
    let me know.
    I still try to get hands on a NVIDIA board. They are not terrible expensive but
    I still don't want to buy it myself :)

    So if someone is willing to lend me a board, I can't try to reproduce it.
    Which one do you need? I have a TK1 in reach, Ralf should have a TX1 with the
    potential of remote access.

    Jan

    --
    Siemens AG, Corporate Technology, CT RDA IOT SES-DE
    Corporate Competence Center Embedded Linux


    Re: [ANNOUNCE] v4.4.185-cip35-rt24

    Daniel Wagner <wagi@...>
     

    Hi,

    On 7/23/19 11:12 PM, Pavel Machek wrote:
    v4.4.185-cip35-rt24 should be available at kernel.org.
    Daniel says:
    # in the v4.4-rt is still a problem with f01f17d3705b ("mm,
    # vmstat: make quiet_vmstat lighter"). It is needed to boot on x86_64
    # but it breaks on NVIDIA's boards, e.g. Jetson. Unfortunately, I don't
    # have a NVIDIA board in my lab to figure out what is missing. So I
    # suspect there is a still a problem hidden in the current v4.4-rt tree.
    I did nothing to solve that problem. If someone uses NVIDIA boards,
    let me know.
    I still try to get hands on a NVIDIA board. They are not terrible expensive but I still don't want to buy it myself :)

    So if someone is willing to lend me a board, I can't try to reproduce it.

    Thanks,
    Daniel


    Re: [RFC/RFT] -cip-rt kernels for review/testing

    Daniel Wagner <wagi@...>
     

    Hi Pavel,

    The srt tool is available here: https://github.com/igaw/stable-rt-tools
    It a few lines around git to make the steps consist. It is based on Steven
    Rostedt workflow. Tom Zanussi (also -rt stable maintainer) and I am using
    the tool to maintain the -rt trees.
    Thanks for pointer. It does not want to run here (incompatible version
    of python 3?), so let me try to do one more manual attempt, and if
    that fails I'll try to fix/workaround python problems.
    stable-rt-tools might depend on a newer version of Python3. I am running Python 3.7 here. I can't remember if there are any dependencies on newer version of Python3. What's the error message?

    Thanks,
    Daniel


    Re: [ANNOUNCE] v4.19.50-cip3-rt2

    Zoran
     

    Why don't you use ISAR CIP Core?
    https://gitlab.com/cip-project/cip-core/isar-cip-core
    With all due respect (and I do really respect prominent CIP founders),
    I need to make this problem solved solely by myself...

    But, anyway, thank you for the advise! :-)

    Zoran
    _______

    On Thu, Jul 25, 2019 at 2:22 AM <daniel.sangorrin@toshiba.co.jp> wrote:

    Hello Zoran

    From: cip-dev-bounces@lists.cip-project.org <cip-dev-
    (limitations): I could NOT connect with ETH to target (something is
    wrongly set with my local.conf for YOCTO rootfs)...
    Why don't you use ISAR CIP Core?
    https://gitlab.com/cip-project/cip-core/isar-cip-core

    Thanks,
    Daniel


    Here is my approximate recipe for rootfs I am using for the test
    (initramfs) for your inspection (it is thud, local.conf moved to
    warrior):
    https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/local.conf

    More or/and less, here are results after approximately 63 minutes of
    running rt-tests:

    root@beaglebone:~# uname -a
    Linux beaglebone 4.19.13-cip1-rt1 #1 PREEMPT RT Tue Jul 23 12:18:18
    GMT 2019 armv7l GNU/Linux
    _______
    policy: fifo: loadavg: 291.28 287.63 267.78 21/486 30014
    policy: fifo: loadavg: 186.97 215.90 243.41 5/458 22788
    policy: fifo: loadavg: 248.16 243.95 244.63 194/486 8800
    policy: fifo: loadavg: 283.55 240.50 243.74 9/318 2383
    T: 0 (13903) P:80 I:1000 C:3942593 Min: 19 Act: 52 Avg: 45 Max: 93
    T: 0 (13903) P:80 I:1000 C:3785664 Min: 19 Act: 44 Avg: 45 Max: 935
    T: 0 (13903) P:80 I:1000 C:3716107 Min: 19 Act: 60 Avg: 45 Max: 936
    policy: fifo: loadavg: 222.11 176.72 90.66 5/213 21249
    T: 0 (13903) P:80 I:1000 C:2213895 Min: 19 Act: 38 Avg: 46 Max: 905
    T: 0 (13903) P:80 I:1000 C: 181403 Min: 21 Act: 49 Avg: 45 Max: 90
    T: 0 (13903) P:80 I:1000 C: 181320 Min: 21 Act: 29 Avg: 45 Max: 90

    MIN 19 ns, MAX 936 ns (3x over 900 ns)... I would be really concerned
    about MAX over > 900 ns!

    On 4.4 RT kernel I had some much better # such as: Min: 19 Act:
    44 Avg: 42 Max: 81

    I need to do more... No time anymore now!

    Best Regards,
    Zoran
    _______


    On Wed, Jul 24, 2019 at 3:00 PM Zoran S
    <zoran.stojsavljevic.de@gmail.com> wrote:

    No problem. You should be able to use same .config
    with the new kernel...
    U R targeting 4.19.50-cip3-rt2... I do agree 100%, but I have some
    problems to do rt-tests (connecting BBB target to my VM).

    Please, stay tuned. I'll resolve these problems ASAP (if ?, then Ill
    publish the results) . Then I need to leave it for the time been.

    Zoran
    _______

    On Wed, Jul 24, 2019 at 1:53 PM Pavel Machek <pavel@denx.de> wrote:

    Hi!

    I finally was able to make the viable .config... For the previous
    rt-kernel for BBB.

    root@beaglebone:~# uname -a
    Linux beaglebone 4.19.13-cip1-rt1 #1 PREEMPT RT Tue Jul 23 12:18:18
    GMT 2019 armv7l GNU/Linux

    It was very tough and rough... But I have it! Now I need to abandon
    this effort, since I have another immediate things to do!
    No problem. You should be able to use same .config with the new
    kernel...

    Best regards,
    Pavel
    --
    DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
    HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
    _______________________________________________
    cip-dev mailing list
    cip-dev@lists.cip-project.org
    https://lists.cip-project.org/mailman/listinfo/cip-dev


    CIP IRC weekly meeting today

    SZ Lin (林上智) <SZ.Lin@...>
     

    Hi all,

    Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

    *Please note that IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
    https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=7&day25&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=248

    US-West US-East   UK     DE     TW     JP
    02:00    05:00   10:00   11:00   17:00   18:00

    Channel:
    * irc:chat.freenode.net:6667/cip

    Agenda:

    * Action item
    1. Provide the script for CIP kernel config collection - bwh
    #link https://lists.cip-project.org/pipermail/cip-dev/2019-June/002506.html
    2. Try updating CIP RT kernel to 4.19.50 - Pavel
    #link https://lists.cip-project.org/pipermail/cip-dev/2019-June/002548.html
    3. Fix release number in CIP RT kernel - pavel
    4. Work out a solution for LAVA master backups - patersonc
    5. Review "gitlab-ci.yml" patches before OSS-J - pavel
    * Kernel maintenance updates
    * Kernel testing
    * CIP Core
    * Software update
    * AOB

    The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

    Best regards,

    SZ Lin, Moxa.


    Re: [ANNOUNCE] v4.19.50-cip3-rt2

    daniel.sangorrin@...
     

    Hello Zoran

    From: cip-dev-bounces@lists.cip-project.org <cip-dev-
    (limitations): I could NOT connect with ETH to target (something is
    wrongly set with my local.conf for YOCTO rootfs)...
    Why don't you use ISAR CIP Core?
    https://gitlab.com/cip-project/cip-core/isar-cip-core

    Thanks,
    Daniel


    Here is my approximate recipe for rootfs I am using for the test
    (initramfs) for your inspection (it is thud, local.conf moved to
    warrior):
    https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/local.conf

    More or/and less, here are results after approximately 63 minutes of
    running rt-tests:

    root@beaglebone:~# uname -a
    Linux beaglebone 4.19.13-cip1-rt1 #1 PREEMPT RT Tue Jul 23 12:18:18
    GMT 2019 armv7l GNU/Linux
    _______
    policy: fifo: loadavg: 291.28 287.63 267.78 21/486 30014
    policy: fifo: loadavg: 186.97 215.90 243.41 5/458 22788
    policy: fifo: loadavg: 248.16 243.95 244.63 194/486 8800
    policy: fifo: loadavg: 283.55 240.50 243.74 9/318 2383
    T: 0 (13903) P:80 I:1000 C:3942593 Min: 19 Act: 52 Avg: 45 Max: 93
    T: 0 (13903) P:80 I:1000 C:3785664 Min: 19 Act: 44 Avg: 45 Max: 935
    T: 0 (13903) P:80 I:1000 C:3716107 Min: 19 Act: 60 Avg: 45 Max: 936
    policy: fifo: loadavg: 222.11 176.72 90.66 5/213 21249
    T: 0 (13903) P:80 I:1000 C:2213895 Min: 19 Act: 38 Avg: 46 Max: 905
    T: 0 (13903) P:80 I:1000 C: 181403 Min: 21 Act: 49 Avg: 45 Max: 90
    T: 0 (13903) P:80 I:1000 C: 181320 Min: 21 Act: 29 Avg: 45 Max: 90

    MIN 19 ns, MAX 936 ns (3x over 900 ns)... I would be really concerned
    about MAX over > 900 ns!

    On 4.4 RT kernel I had some much better # such as: Min: 19 Act:
    44 Avg: 42 Max: 81

    I need to do more... No time anymore now!

    Best Regards,
    Zoran
    _______


    On Wed, Jul 24, 2019 at 3:00 PM Zoran S
    <zoran.stojsavljevic.de@gmail.com> wrote:

    No problem. You should be able to use same .config
    with the new kernel...
    U R targeting 4.19.50-cip3-rt2... I do agree 100%, but I have some
    problems to do rt-tests (connecting BBB target to my VM).

    Please, stay tuned. I'll resolve these problems ASAP (if ?, then Ill
    publish the results) . Then I need to leave it for the time been.

    Zoran
    _______

    On Wed, Jul 24, 2019 at 1:53 PM Pavel Machek <pavel@denx.de> wrote:

    Hi!

    I finally was able to make the viable .config... For the previous
    rt-kernel for BBB.

    root@beaglebone:~# uname -a
    Linux beaglebone 4.19.13-cip1-rt1 #1 PREEMPT RT Tue Jul 23 12:18:18
    GMT 2019 armv7l GNU/Linux

    It was very tough and rough... But I have it! Now I need to abandon
    this effort, since I have another immediate things to do!
    No problem. You should be able to use same .config with the new
    kernel...

    Best regards,
    Pavel
    --
    DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
    HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
    _______________________________________________
    cip-dev mailing list
    cip-dev@lists.cip-project.org
    https://lists.cip-project.org/mailman/listinfo/cip-dev


    Re: [ANNOUNCE] v4.19.50-cip3-rt2

    Zoran
     

    (limitations): I could NOT connect with ETH to target (something is
    wrongly set with my local.conf for YOCTO rootfs)...

    Here is my approximate recipe for rootfs I am using for the test
    (initramfs) for your inspection (it is thud, local.conf moved to
    warrior):
    https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/local.conf

    More or/and less, here are results after approximately 63 minutes of
    running rt-tests:

    root@beaglebone:~# uname -a
    Linux beaglebone 4.19.13-cip1-rt1 #1 PREEMPT RT Tue Jul 23 12:18:18
    GMT 2019 armv7l GNU/Linux
    _______
    policy: fifo: loadavg: 291.28 287.63 267.78 21/486 30014
    policy: fifo: loadavg: 186.97 215.90 243.41 5/458 22788
    policy: fifo: loadavg: 248.16 243.95 244.63 194/486 8800
    policy: fifo: loadavg: 283.55 240.50 243.74 9/318 2383
    T: 0 (13903) P:80 I:1000 C:3942593 Min: 19 Act: 52 Avg: 45 Max: 93
    T: 0 (13903) P:80 I:1000 C:3785664 Min: 19 Act: 44 Avg: 45 Max: 935
    T: 0 (13903) P:80 I:1000 C:3716107 Min: 19 Act: 60 Avg: 45 Max: 936
    policy: fifo: loadavg: 222.11 176.72 90.66 5/213 21249
    T: 0 (13903) P:80 I:1000 C:2213895 Min: 19 Act: 38 Avg: 46 Max: 905
    T: 0 (13903) P:80 I:1000 C: 181403 Min: 21 Act: 49 Avg: 45 Max: 90
    T: 0 (13903) P:80 I:1000 C: 181320 Min: 21 Act: 29 Avg: 45 Max: 90

    MIN 19 ns, MAX 936 ns (3x over 900 ns)... I would be really concerned
    about MAX over > 900 ns!

    On 4.4 RT kernel I had some much better # such as: Min: 19 Act:
    44 Avg: 42 Max: 81

    I need to do more... No time anymore now!

    Best Regards,
    Zoran
    _______


    On Wed, Jul 24, 2019 at 3:00 PM Zoran S
    <zoran.stojsavljevic.de@gmail.com> wrote:

    No problem. You should be able to use same .config
    with the new kernel...
    U R targeting 4.19.50-cip3-rt2... I do agree 100%, but I have some
    problems to do rt-tests (connecting BBB target to my VM).

    Please, stay tuned. I'll resolve these problems ASAP (if ?, then Ill
    publish the results) . Then I need to leave it for the time been.

    Zoran
    _______

    On Wed, Jul 24, 2019 at 1:53 PM Pavel Machek <pavel@denx.de> wrote:

    Hi!

    I finally was able to make the viable .config... For the previous
    rt-kernel for BBB.

    root@beaglebone:~# uname -a
    Linux beaglebone 4.19.13-cip1-rt1 #1 PREEMPT RT Tue Jul 23 12:18:18
    GMT 2019 armv7l GNU/Linux

    It was very tough and rough... But I have it! Now I need to abandon
    this effort, since I have another immediate things to do!
    No problem. You should be able to use same .config with the new
    kernel...

    Best regards,
    Pavel
    --
    DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
    HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


    Re: [ANNOUNCE] v4.19.50-cip3-rt2

    Zoran
     

    No problem. You should be able to use same .config
    with the new kernel...
    U R targeting 4.19.50-cip3-rt2... I do agree 100%, but I have some
    problems to do rt-tests (connecting BBB target to my VM).

    Please, stay tuned. I'll resolve these problems ASAP (if ?, then Ill
    publish the results) . Then I need to leave it for the time been.

    Zoran
    _______

    On Wed, Jul 24, 2019 at 1:53 PM Pavel Machek <pavel@denx.de> wrote:

    Hi!

    I finally was able to make the viable .config... For the previous
    rt-kernel for BBB.

    root@beaglebone:~# uname -a
    Linux beaglebone 4.19.13-cip1-rt1 #1 PREEMPT RT Tue Jul 23 12:18:18
    GMT 2019 armv7l GNU/Linux

    It was very tough and rough... But I have it! Now I need to abandon
    this effort, since I have another immediate things to do!
    No problem. You should be able to use same .config with the new
    kernel...

    Best regards,
    Pavel
    --
    DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
    HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

    5601 - 5620 of 8382