|
[Git][cip-project/cip-kernel/cip-kernel-sec][master] 2 commits: Fill in commit lists for some issues
Agustin Benito Bethencourt
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
Commits:
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
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
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
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/106On 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
|
|
|
Re: [ANNOUNCE] v4.19.50-cip3-rt2
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
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
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
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
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
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
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
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
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@...>
|
|
|
Re: [ANNOUNCE] v4.19.50-cip3-rt2
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-coreThanks, 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
(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.confMore 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
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
|
|
|
