Date   

Re: Request for guidance: removal of old config files [was: Kernel configurations for 4.19?]

Zoran
 

>> Good point.  I have not yet tried running 4.19 on the BBB, but I can
>> look at adding one - or perhaps Nobuhiro or Pavel already has a
>> suitable config?

Excellent point, which spares me time to begin the new email thread
about 4.19 BBB rt-config file.

Actually, I have one 4.19 BBB rt-config file, which at the end of trimming
goes to cycles (not able to set three parameters).

git clone git://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
cd linux-cip
git checkout -b cip_v4.19.13-cip1-rt1-rebase v4.19.13-cip1-rt1-rebase
export TREE_NAME=cip-example
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
make -j4 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm omap2plus_defconfig

I did adjust all the RT parameters, and at the end of three cycles of
compiling, I've got the following CONFIG file (attached to this email).

My problem is, that I ended with cyclic loop, since every time I start
compiling with:
make -j4 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm

I end up with changed .config, with always three parameters changed:

vagrant@stretch:~/git-repos/linux-cip/build-arm$ diff -c .config CONFIG
*** .config 2019-07-21 17:31:28.524419156 +0000
--- CONFIG 2019-07-20 18:29:58.349570260 +0000
***************
*** 73,78 ****
--- 73,79 ----
  # Timers subsystem
  #
  CONFIG_TICK_ONESHOT=y
+ CONFIG_NO_HZ_COMMON=y
  CONFIG_HZ_PERIODIC=y
  # CONFIG_NO_HZ_IDLE is not set
  # CONFIG_NO_HZ is not set
***************
*** 585,591 ****
  #
  # CONFIG_SUSPEND is not set
  # CONFIG_HIBERNATION is not set
! CONFIG_PM=y <<== (should be # CONFIG_PM is not set)
  CONFIG_PM_DEBUG=y
  # CONFIG_PM_ADVANCED_DEBUG is not set
  # CONFIG_APM_EMULATION is not set
--- 586,592 ----
  #
  # CONFIG_SUSPEND is not set
  # CONFIG_HIBERNATION is not set
! # CONFIG_PM is not set
  CONFIG_PM_DEBUG=y
  # CONFIG_PM_ADVANCED_DEBUG is not set
  # CONFIG_APM_EMULATION is not set
***************
*** 2319,2325 ****
  # CONFIG_HSI_CHAR is not set
  CONFIG_PPS=y
  # CONFIG_PPS_DEBUG is not set
- CONFIG_NTP_PPS=y
 
  #
  # PPS clients support
--- 2320,2325 ----
***************
*** 5469,5476 ****
  CONFIG_DEBUG_SPINLOCK=y
  CONFIG_DEBUG_MUTEXES=y
  CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y
! CONFIG_DEBUG_LOCK_ALLOC=y <<== (should be # CONFIG_DEBUG_LOCK_ALLOC is not set)
! CONFIG_LOCKDEP=y<<== (should be # CONFIG_LOCKDEP is not set)

  # CONFIG_DEBUG_LOCKDEP is not set
  CONFIG_DEBUG_ATOMIC_SLEEP=y
  # CONFIG_LOCK_TORTURE_TEST is not set
--- 5469,5476 ----
  CONFIG_DEBUG_SPINLOCK=y
  CONFIG_DEBUG_MUTEXES=y
  CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y
! # CONFIG_DEBUG_LOCK_ALLOC is not set
! # CONFIG_LOCKDEP is not set
  # CONFIG_DEBUG_LOCKDEP is not set
  CONFIG_DEBUG_ATOMIC_SLEEP=y
  # CONFIG_LOCK_TORTURE_TEST is not set

What I am doing/setting wrong here???

Thank you,
Zoran
_______

On Sun, Jul 21, 2019 at 6:26 PM Pavel Machek <pavel@...> wrote:
On Fri 2019-07-12 17:34:47, Ben Hutchings wrote:
> On Thu, 2019-07-11 at 18:51 +0200, Jan Kiszka wrote:
> [...]
> > > 4.19/arm/hitachi_omap_defconfig
> > > 4.19/arm/moxa_mxc_defconfig
> > > 4.19/arm/siemens_am335x-axm2_defconfig
> > > 4.19/arm/siemens_am335x-draco_defconfig
> > > 4.19/arm/siemens_am335x-dxr2_defconfig
> > > 4.19/arm/siemens_am335x-etamin_defconfig
> > > 4.19/arm/siemens_am57xx-pxm3_defconfig
> >
> > Those can go, I'm not aware of their usage on 4.19. But do we have one for the
> > am335-x-based BBB, our reference board?
>
> Good point.  I have not yet tried running 4.19 on the BBB, but I can
> look at adding one - or perhaps Nobuhiro or Pavel already has a
> suitable config?

No easy access to BBB here, sorry.

I have added directory 4.19-rt and added config for socfpga I'd like
to be used for testing in Lava lab. It is not configuration that needs
to be officially supported with CIP project.

I hope that is okay.

If someone uses rt on some other hardware, I'd like to know.

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@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Explanation for cip-kernel-config

Zoran
 

I've commited suitable config for socfpga board. (And added it to the
README).
For the starters, could you, please, forward to me the public (I
assume so, somewhere on CIP pages) web pointer of the README file you
are talking about?

I know that I fell on this list out of nowhere... So I did not follow
the recent conversations for months. ;-)

If you need some kind of help with kernel configuration (etc), just
let me know.
The email about BBB 4.19-rt .config file woes will come right after
this one... Indeed! :-)

Thank you,
Zoran
_______


On Sat, Jul 20, 2019 at 10:24 PM Pavel Machek <pavel@denx.de> wrote:

Hi!

Yup... I am very interested in this one, I should say. ;-)

Let us see what will come out of this effort. :-)
I've commited suitable config for socfpga board. (And added it to the
README).

If you need some kind of help with kernel configuration (etc), just
let me know.

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


Re: Request for guidance: removal of old config files [was: Kernel configurations for 4.19?]

Pavel Machek
 

On Fri 2019-07-12 17:34:47, Ben Hutchings wrote:
On Thu, 2019-07-11 at 18:51 +0200, Jan Kiszka wrote:
[...]
4.19/arm/hitachi_omap_defconfig
4.19/arm/moxa_mxc_defconfig
4.19/arm/siemens_am335x-axm2_defconfig
4.19/arm/siemens_am335x-draco_defconfig
4.19/arm/siemens_am335x-dxr2_defconfig
4.19/arm/siemens_am335x-etamin_defconfig
4.19/arm/siemens_am57xx-pxm3_defconfig
Those can go, I'm not aware of their usage on 4.19. But do we have one for the
am335-x-based BBB, our reference board?
Good point. I have not yet tried running 4.19 on the BBB, but I can
look at adding one - or perhaps Nobuhiro or Pavel already has a
suitable config?
No easy access to BBB here, sorry.

I have added directory 4.19-rt and added config for socfpga I'd like
to be used for testing in Lava lab. It is not configuration that needs
to be officially supported with CIP project.

I hope that is okay.

If someone uses rt on some other hardware, I'd like to know.

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


Re: Explanation for cip-kernel-config

Pavel Machek
 

Hi!

Yup... I am very interested in this one, I should say. ;-)

Let us see what will come out of this effort. :-)
I've commited suitable config for socfpga board. (And added it to the
README).

If you need some kind of help with kernel configuration (etc), just
let me know.

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


FW: [Linaro/test-definitions] Preempt rt v1 review (#85)

Chris Paterson
 

Hello Pavel,

 

This PR from Daniel is probably of interest to you.

 

Kind regards, Chris

 

From: Daniel Wagner <notifications@...>
Sent: 19 July 2019 23:51
To: Linaro/test-definitions <test-definitions@...>
Cc: Subscribed <subscribed@...>
Subject: [Linaro/test-definitions] Preempt rt v1 review (#85)

 

I am maintaining the v4.4-rt stable tree and using LAVA with the test-definition to verify my work.

With a Python script I create several tests jobs. All started very small but nowadays I a pretty happy with what I got. Still a lot to do but it's a good starting point

Anyway, I improved (obviously it's a point of view thing) the current test scripts in test-definition slightly:

·        introduce MAX_LATENCY: fail if the max latency is reached

·        added a bunch of command options (e,g. duration)

·        extended the error parsing for the test tools

The first point is important to my work. I really need the test to fail if on a given board the values go above MAX_LATENCY.

Hope this makes any sense.


You can view, comment on, or merge this pull request online at:

  https://github.com/Linaro/test-definitions/pull/85

Commit Summary

·        cyclictest: Update parameters

·        signaltest: Update parameters

·        rt-migrate-test: Parse pass/fail result

·        cyclictest: Add MAX_LATENCY argument

·        signaltest: Add MAX_LATENCY argument

·        pi-stress: Check for errors in the log file

·        pmqtest: Add MAX_LATENCY argument

·        sh-test-lib: Add convert_to_sec helper

·        cyclictest: Introduce duration option

·        pi-stress: Introduce duration option

·        pmqtest: Introduce duration option

·        rt-migrate-test: Introduce duration option

·        signaltest: Introduce duration option

File Changes

·        M automated/lib/sh-test-lib (23)

·        M automated/linux/cyclictest/cyclictest.sh (26)

·        M automated/linux/cyclictest/cyclictest.yaml (15)

·        A automated/linux/cyclictest/parse_results.py (54)

·        M automated/linux/pi-stress/pi-stress.sh (22)

·        M automated/linux/pi-stress/pi-stress.yaml (6)

·        A automated/linux/pmqtest/parse_results.py (60)

·        M automated/linux/pmqtest/pmqtest.sh (16)

·        M automated/linux/pmqtest/pmqtest.yaml (7)

·        M automated/linux/rt-migrate-test/rt-migrate-test.sh (9)

·        M automated/linux/rt-migrate-test/rt-migrate-test.yaml (3)

·        A automated/linux/signaltest/parse_results.py (54)

·        M automated/linux/signaltest/signaltest.sh (20)

·        M automated/linux/signaltest/signaltest.yaml (10)

Patch Links:

·        https://github.com/Linaro/test-definitions/pull/85.patch

·        https://github.com/Linaro/test-definitions/pull/85.diff


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Re: [OBSOLETE?] CONFIG_PREEMPT_RT_FULL config parameter in 4.19?!

Daniel Wagner <wagi@...>
 

On 7/19/19 9:03 PM, Zoran S wrote:
v4.19.58-cip6
v4.19.58-cip6-rebase
There is also a corresponding branch for those tags.

- linux-4.4.y-cip-rt:
contains the -rt patchses. no rebases, just merges.
- linux-4.4.y-cip-rt-rebase:
has the -rt patches on top of the last cip release.


Re: [OBSOLETE?] CONFIG_PREEMPT_RT_FULL config parameter in 4.19?!

Zoran
 

OK, I see. Wrong check-out!

git checkout -b cip_v4.19.58-cip6 v4.19.58-cip6

Yup... This is the root cause of the problem!

v4.19.13-cip1
v4.19.13-cip1-rt1
v4.19.13-cip1-rt1-rebase

v4.19.13-cip2
v4.19.13-cip2-rebase
v4.19.50-cip3
v4.19.50-cip3-rebase
v4.19.52-cip4
v4.19.52-cip4-rebase
v4.19.56-cip5
v4.19.56-cip5-rebase
v4.19.58-cip6
v4.19.58-cip6-rebase

Psychological mislead! Well... Blind trust in what I see (and I do see NOT reality, just what I did expect! ;-)

Well, I need to fix this psychosocial problems with my brain! :-)

Case Closed!

Thank you,
Zoran
_______


On Fri, Jul 19, 2019 at 8:11 PM Ben Hutchings <ben.hutchings@...> wrote:
On Fri, 2019-07-19 at 19:58 +0200, Zoran S wrote:
> > This never existed in the upstream kernel, only in -rt branches.
> > It still exists in 4.19-rt.
>
> Sure. The following is done by me:
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
>
> Isn't this CIP RT-kernel real-time tree?
[...]

It's the CIP kernel repository.  Only the branches with "-rt" in the
name include the real-time patch set.

Ben.

--
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom


Re: [OBSOLETE?] CONFIG_PREEMPT_RT_FULL config parameter in 4.19?!

Ben Hutchings <ben.hutchings@...>
 

On Fri, 2019-07-19 at 19:58 +0200, Zoran S wrote:
This never existed in the upstream kernel, only in -rt branches.
It still exists in 4.19-rt.
Sure. The following is done by me:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git

Isn't this CIP RT-kernel real-time tree?
[...]

It's the CIP kernel repository. Only the branches with "-rt" in the
name include the real-time patch set.

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


Re: Explanation for cip-kernel-config

Zoran
 

Yup... I am very interested in this one, I should say. ;-)

Let us see what will come out of this effort. :-)

Thank you,
Zoran Stojsavljevic
_______

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

Hi!

I started README.md file in cip-kernel-config. It should provide some
explanation and I believe we should also provide table with mapping of
boards (their names and their codes in Lava) and config files.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: [OBSOLETE?] CONFIG_PREEMPT_RT_FULL config parameter in 4.19?!

Zoran
 

Are you sure you have your kernel patched with -rt patches?
CONFIG_PREEMPT_RT_FULL=y was still needed in 4.19, AFAICT.
Please, could you refer to reply above (practical exercises using
lava_server_vm VM) to Ben and Daniel? You can also check and verify
it...

Maybe, after all, I am doing something very wrong. But I do not
see/not aware what?!

Zoran
_______


On Fri, Jul 19, 2019 at 3:59 PM Pavel Machek <pavel@ucw.cz> wrote:

Hi!

I started my own investigation about RT kernels, namely 4.19. I
proceed very carefully over the kernel config parameters... BUt the
last one I inspected today got me nowhere!?

Seems, that the following config parameters are obsolete in 4.19:
CONFIG_PREEMPT_RT_FULL

This one (CONFIG_PREEMPT_RT_FULL) is still present in 4.4 .

[vuser@fedora30-ssd kernel-config]$ cat CONFIG-4.4.120-rt-bbb | grep PREEMPT
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_RT_BASE=y
CONFIG_HAVE_PREEMPT_LAZY=y
CONFIG_PREEMPT_LAZY=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT__LL is not set
# CONFIG_PREEMPT_RTB is not set
CONFIG_PREEMPT_RT_FULL=y <<======= Obsolete in 4.19 ?
CONFIG_PREEMPT_COUNT=y
CONFIG_DEBUG_PREEMPT=y
[vuser@fedora30-ssd kernel-config]$

What I should do to maintain RT-kernel-4.19? It is obvious, I must/need to set:
CONFIG_PREEMPT=y
Are you sure you have your kernel patched with -rt patches?
CONFIG_PREEMPT_RT_FULL=y was still needed in 4.19, AFAICT.

Note that not every piece of hardware has suitable characteristics for
realtime / low latencies.

Best regards,
Pavel

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


Re: [OBSOLETE?] CONFIG_PREEMPT_RT_FULL config parameter in 4.19?!

Zoran
 

> This never existed in the upstream kernel, only in -rt branches.
> It still exists in 4.19-rt.

Sure. The following is done by me:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git

Isn't this CIP RT-kernel real-time tree?

cd linux-cip
git checkout -b cip_v4.19.58-cip6 v4.19.58-cip6

make -j4 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm omap2plus_defconfig

Please, check the folllowing:

Linux stretch 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64

vagrant@stretch:~/git-repos/linux-cip/build-arm$ pwd
/home/vagrant/git-repos/linux-cip/build-arm
vagrant@stretch:~/git-repos/linux-cip/build-arm$ ls -al .config
-rw-r--r-- 1 vagrant vagrant 148183 Jul 18 04:25 .config
vagrant@stretch:~/git-repos/linux-cip/build-arm$ cat .config | grep PREEMPT
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPTIRQ_TRACEPOINTS=y
# CONFIG_PREEMPTIRQ_EVENTS is not set
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set
vagrant@stretch:~/git-repos/linux-cip/build-arm $

And, finally:

vagrant@stretch:~/git-repos/linux-cip$ pwd
/home/vagrant/git-repos/linux-cip
vagrant@stretch:~/git-repos/linux-cip$ ack CONFIG_PREEMPT_RT_FULL
vagrant@stretch:~/git-repos/linux-cip$

Hmmmmmm... Strange, isn't it??? Please, advise?

Thank you,
Zoran Stojsavljevic
_______


On Fri, Jul 19, 2019 at 3:58 PM Ben Hutchings <ben.hutchings@...> wrote:
On Fri, 2019-07-19 at 15:31 +0200, Zoran S wrote:
> Hello  Ben, Daniel,
>
> I started my own investigation about RT kernels, namely 4.19. I
> proceed very carefully over the kernel config parameters... BUt the
> last one I inspected today got me nowhere!?
>
> Seems, that the following config parameters are obsolete in 4.19:
> CONFIG_PREEMPT_RT_FULL
[...]

This never existed in the upstream kernel, only in -rt branches.  It
still exists in 4.19-rt.

Ben.

--
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom


Explanation for cip-kernel-config

Pavel Machek
 

Hi!

I started README.md file in cip-kernel-config. It should provide some
explanation and I believe we should also provide table with mapping of
boards (their names and their codes in Lava) and config files.

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


Re: [OBSOLETE?] CONFIG_PREEMPT_RT_FULL config parameter in 4.19?!

Pavel Machek
 

Hi!

I started my own investigation about RT kernels, namely 4.19. I
proceed very carefully over the kernel config parameters... BUt the
last one I inspected today got me nowhere!?

Seems, that the following config parameters are obsolete in 4.19:
CONFIG_PREEMPT_RT_FULL

This one (CONFIG_PREEMPT_RT_FULL) is still present in 4.4 .

[vuser@fedora30-ssd kernel-config]$ cat CONFIG-4.4.120-rt-bbb | grep PREEMPT
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_RT_BASE=y
CONFIG_HAVE_PREEMPT_LAZY=y
CONFIG_PREEMPT_LAZY=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT__LL is not set
# CONFIG_PREEMPT_RTB is not set
CONFIG_PREEMPT_RT_FULL=y <<======= Obsolete in 4.19 ?
CONFIG_PREEMPT_COUNT=y
CONFIG_DEBUG_PREEMPT=y
[vuser@fedora30-ssd kernel-config]$

What I should do to maintain RT-kernel-4.19? It is obvious, I must/need to set:
CONFIG_PREEMPT=y
Are you sure you have your kernel patched with -rt patches?
CONFIG_PREEMPT_RT_FULL=y was still needed in 4.19, AFAICT.

Note that not every piece of hardware has suitable characteristics for
realtime / low latencies.

Best regards,
Pavel

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


Re: [OBSOLETE?] CONFIG_PREEMPT_RT_FULL config parameter in 4.19?!

Ben Hutchings <ben.hutchings@...>
 

On Fri, 2019-07-19 at 15:31 +0200, Zoran S wrote:
Hello Ben, Daniel,

I started my own investigation about RT kernels, namely 4.19. I
proceed very carefully over the kernel config parameters... BUt the
last one I inspected today got me nowhere!?

Seems, that the following config parameters are obsolete in 4.19:
CONFIG_PREEMPT_RT_FULL
[...]

This never existed in the upstream kernel, only in -rt branches. It
still exists in 4.19-rt.

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


[OBSOLETE?] CONFIG_PREEMPT_RT_FULL config parameter in 4.19?!

Zoran
 

Hello Ben, Daniel,

I started my own investigation about RT kernels, namely 4.19. I
proceed very carefully over the kernel config parameters... BUt the
last one I inspected today got me nowhere!?

Seems, that the following config parameters are obsolete in 4.19:
CONFIG_PREEMPT_RT_FULL

This one (CONFIG_PREEMPT_RT_FULL) is still present in 4.4 .

[vuser@fedora30-ssd kernel-config]$ cat CONFIG-4.4.120-rt-bbb | grep PREEMPT
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_RT_BASE=y
CONFIG_HAVE_PREEMPT_LAZY=y
CONFIG_PREEMPT_LAZY=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT__LL is not set
# CONFIG_PREEMPT_RTB is not set
CONFIG_PREEMPT_RT_FULL=y <<======= Obsolete in 4.19 ?
CONFIG_PREEMPT_COUNT=y
CONFIG_DEBUG_PREEMPT=y
[vuser@fedora30-ssd kernel-config]$

What I should do to maintain RT-kernel-4.19? It is obvious, I must/need to set:
CONFIG_PREEMPT=y

Anything else?

Any viable/reasonable explanation why CONFIG_PREEMPT_RT_FULL was
removed in 4.19?

Thank you,
Zoran Stojsavljevic
_______


[CANCEL] CIP IRC meeting today

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

Hi all,

 

The CIP IRC weekly meeting today is canceled since we are getting together in OSS-J event now.

 

SZ


Re: [PATCH 4.4.y-cip 05/10] rtc: pcf85363: Add support for NXP pcf85263 rtc

Nobuhiro Iwamatsu
 

Hi,

-----Original Message-----
From: Biju Das [mailto:biju.das@bp.renesas.com]
Sent: Wednesday, July 17, 2019 4:16 PM
To: iwamatsu nobuhiro(岩松 信洋 ○SWC□OST)
<nobuhiro1.iwamatsu@toshiba.co.jp>; cip-dev@lists.cip-project.org
Subject: RE: [cip-dev] [PATCH 4.4.y-cip 05/10] rtc: pcf85363: Add support
for NXP pcf85263 rtc

Hi Nobuhiro,

Thanks for the feedback.

Subject: RE: [cip-dev] [PATCH 4.4.y-cip 05/10] rtc: pcf85363: Add
support for NXP pcf85263 rtc

Hi,

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
[mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Biju Das
Sent: Tuesday, July 16, 2019 5:15 PM
To: cip-dev@lists.cip-project.org
Cc: Biju Das <biju.das@bp.renesas.com>
Subject: [cip-dev] [PATCH 4.4.y-cip 05/10] rtc: pcf85363: Add
support for NXP pcf85263 rtc

commit fc979933bcf162595b6004d0de4effb64c323152 upstream.

Add support for NXP pcf85263 real-time clock. pcf85263 rtc is
compatible with pcf85363,except that pcf85363 has additional 64
bytes of
RAM.

1 byte of nvmem is supported and exposed in sysfs (# is the instance
number,starting with 0): /sys/bus/nvmem/devices/pcf85x63-#/nvmem

Signed-off-by: Biju Das <biju.das@bp.renesas.com> [ Removed rtc
nvmem support. Added I2C ID table for rtc-pcf85263 ]
You've deleted Alexandre's Signed-off-by tag from original patch.
Thanks for pointing this out. It is a mistake. Can you please fix this
while applying to the tree?

Or

Do you want me to send another patch fixing this? Please let me know.
Pavel applied this patch with signed-off-by tag. Thanks Pavel.

Best regards,
Nobuhiro


[Git][cip-project/cip-kernel/cip-kernel-sec][master] Mark some issues to be ignored for 4.4

Agustin Benito Bethencourt
 

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

Commits:

  • 7c70981f
    by Ben Hutchings at 2019-07-17T22:24:27Z
    Mark some issues to be ignored for 4.4
    

3 changed files:

Changes:

  • issues/CVE-2018-3646.yml
    ... ... @@ -177,3 +177,6 @@ fixed-by:
    177 177
         07d981ad4cf1e78361c6db1c28ee5ba105f96cc1]
    
    178 178
     ignore:
    
    179 179
       linux-3.16.y: Too invasive and risky to apply
    
    180
    +  linux-4.4.y: Too invasive and risky to apply
    
    181
    +  linux-4.4.y-cip: Too invasive and risky to apply
    
    182
    +  linux-4.4.y-cip-rt: Too invasive and risky to apply

  • issues/CVE-2018-ebpf-filter-dos.yml
    ... ... @@ -20,3 +20,4 @@ fixed-by:
    20 20
     ignore:
    
    21 21
       linux-4.4.y: Unprivileged BPF JIT should not be enabled
    
    22 22
       linux-4.4.y-cip: Unprivileged BPF JIT should not be enabled
    
    23
    +  linux-4.4.y-cip-rt: Unprivileged BPF JIT should not be enabled

  • issues/CVE-2019-2054.yml
    ... ... @@ -10,3 +10,6 @@ fixed-by:
    10 10
       mainline: [0f3912fd934cdfd03d93f2dc6f064099795bf638]
    
    11 11
     ignore:
    
    12 12
       linux-3.16.y: Documented limitation
    
    13
    +  linux-4.4.y: Documented limitation
    
    14
    +  linux-4.4.y-cip: Documented limitation
    
    15
    +  linux-4.4.y-cip-rt: Documented limitation


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

    Agustin Benito Bethencourt
     


    [Git][cip-project/cip-kernel/cip-kernel-sec][master] 2 commits: report_affected: add support for reporting on tags

    Agustin Benito Bethencourt
     

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

    Commits:

    • 40329eb5
      by Daniel Sangorrin at 2019-07-17T17:30:41Z
      report_affected: add support for reporting on tags
      
      Reporting on tags is useful for product engineers that
      have shipped a kernel with a specific tag and need to know
      which issues affect their product after some time.
      
      Examples:
      $ ./scripts/report_affected.py v4.4 v4.4.107 v4.4.181-cip33
      $ cd ../kernel
      $ git tag myproduct-v1 0f13d9b4d0efa9e87381717c113df57718bc92d6
      $ cd ../cip-kernel-sec
      $ ./scripts/report_affected.py linux-4.19.y-cip:myproduct-v1 v4.19.50-cip3
      
      Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
      Signed-off-by: Ben Hutchings <ben.hutchings@...>
      
    • d202dc5b
      by Daniel Sangorrin at 2019-07-17T17:30:41Z
      report_affected: add show-description option
      
      Rather than looking up each issue file, I would like
      to have an overview of what each CVE ID means.
      
      Example:
      $ ./scripts/report_affected.py --show-description linux-4.4.y-cip
      
      Signed-off-by: Daniel Sangorrin <daniel.sangorrin@...>
      Signed-off-by: Ben Hutchings <ben.hutchings@...>
      

    4 changed files:

    Changes:

  • README.md
    ... ... @@ -41,7 +41,8 @@ current or previous year or that are already tracked here.
    41 41
     stable and other configured branches, by reading the git commit logs.
    
    42 42
     
    
    43 43
     * `scripts/report_affected.py` - report which issues affect the
    
    44
    -specified branches, or all active branches.
    
    44
    +specified branches, or all active branches. You can use --show-description
    
    45
    +to obtain a short description for each CVE ID.
    
    45 46
     
    
    46 47
     * `scripts/validate.py` - validate all issue files against the
    
    47 48
     schema.
    
    ... ... @@ -72,6 +73,7 @@ keys:
    72 73
     * `base_ver`: Stable version that the branch is based on, e.g.
    
    73 74
       "4.4". This needs to be quoted so that it's a string not a
    
    74 75
       number.
    
    76
    +* `tag_regexp`: A regular expression that matches tags on a branch.
    
    75 77
     
    
    76 78
     ### Remotes
    
    77 79
     
    

  • conf/branches.yml
    ... ... @@ -2,7 +2,9 @@
    2 2
       base_ver: "4.4"
    
    3 3
       git_remote: cip
    
    4 4
       git_name: linux-4.4.y-cip
    
    5
    +  tag_regexp: '^v4\.4\.\d+-cip\d+$'
    
    5 6
     - short_name: linux-4.19.y-cip
    
    6 7
       base_ver: "4.19"
    
    7 8
       git_remote: cip
    
    8 9
       git_name: linux-4.19.y-cip
    
    10
    +  tag_regexp: '^v4\.19\.\d+-cip\d+$'

  • scripts/kernel_sec/branch.py
    ... ... @@ -23,11 +23,13 @@ from . import version
    23 23
     
    
    24 24
     def get_base_ver_stable_branch(base_ver):
    
    25 25
         branch_name = 'linux-%s.y' % base_ver
    
    26
    +    esc_base_ver = re.escape(base_ver)
    
    26 27
         return {
    
    27 28
             'short_name': branch_name,
    
    28 29
             'git_remote': 'stable',
    
    29 30
             'git_name': branch_name,
    
    30
    -        'base_ver': base_ver
    
    31
    +        'base_ver': base_ver,
    
    32
    +        'tag_regexp' : r'(^v%s$|^v%s\.\d+$)' % (esc_base_ver, esc_base_ver)
    
    31 33
             }
    
    32 34
     
    
    33 35
     
    
    ... ... @@ -141,7 +143,7 @@ def get_sort_key(branch):
    141 143
         return version.get_sort_key(base_ver)
    
    142 144
     
    
    143 145
     
    
    144
    -def _get_commits(git_repo, end, start=None):
    
    146
    +def iter_rev_list(git_repo, end, start=None):
    
    145 147
         if start:
    
    146 148
             list_expr = '%s..%s' % (start, end)
    
    147 149
         else:
    
    ... ... @@ -170,7 +172,7 @@ class CommitBranchMap:
    170 172
                                      branch['git_name'])
    
    171 173
                 else:
    
    172 174
                     end = 'v' + branch['base_ver']
    
    173
    -            for commit in _get_commits(git_repo, end, start):
    
    175
    +            for commit in iter_rev_list(git_repo, end, start):
    
    174 176
                     self._commit_sort_key[commit] \
    
    175 177
                         = self._branch_sort_key[branch_name]
    
    176 178
                 start = end
    

  • scripts/report_affected.py
    ... ... @@ -9,28 +9,53 @@
    9 9
     # Report issues affecting each stable branch.
    
    10 10
     
    
    11 11
     import argparse
    
    12
    +import copy
    
    12 13
     import subprocess
    
    14
    +import re
    
    13 15
     
    
    14 16
     import kernel_sec.branch
    
    15 17
     import kernel_sec.issue
    
    16 18
     import kernel_sec.version
    
    17 19
     
    
    18 20
     
    
    19
    -def main(git_repo, remotes,
    
    20
    -         only_fixed_upstream, include_ignored, *branch_names):
    
    21
    +def main(git_repo, remotes, only_fixed_upstream,
    
    22
    +         include_ignored, show_description, *branch_names):
    
    21 23
         live_branches = kernel_sec.branch.get_live_branches()
    
    22 24
         if branch_names:
    
    23 25
             branches = []
    
    24 26
             for branch_name in branch_names:
    
    27
    +            tag = None
    
    25 28
                 if branch_name[0].isdigit():
    
    26 29
                     # 4.4 is mapped to linux-4.4.y
    
    27 30
                     name = 'linux-%s.y' % branch_name
    
    31
    +            elif branch_name[0] == 'v':
    
    32
    +                # an official tag, e.g. v4.4.92-cip11
    
    33
    +                # infer branch from tag (regexp's must be specific)
    
    34
    +                for branch in live_branches:
    
    35
    +                    if 'tag_regexp' not in branch:
    
    36
    +                        # no tag_regexp defined, or mainline
    
    37
    +                        continue
    
    38
    +
    
    39
    +                    # predefined in branches.yml or a stable branch
    
    40
    +                    if re.match(branch['tag_regexp'], branch_name):
    
    41
    +                        tag = branch_name
    
    42
    +                        name = branch['short_name']
    
    43
    +                        break
    
    44
    +                else:
    
    45
    +                    raise ValueError('Failed to match tag %r' % branch_name)
    
    46
    +            elif ':' in branch_name:
    
    47
    +                # a possibly custom tag, e.g. linux-4.19.y-cip:myproduct-v1
    
    48
    +                name, tag = branch_name.split(':', 1)
    
    28 49
                 else:
    
    29 50
                     name = branch_name
    
    30 51
     
    
    31 52
                 for branch in live_branches:
    
    32 53
                     if branch['short_name'] == name:
    
    33
    -                    branches.append(branch)
    
    54
    +                    # there could be multiple tags for the same branch
    
    55
    +                    branch_copy = copy.deepcopy(branch)
    
    56
    +                    if tag:
    
    57
    +                        branch_copy['tag'] = tag
    
    58
    +                    branches.append(branch_copy)
    
    34 59
                         break
    
    35 60
                 else:
    
    36 61
                     msg = "Branch %s could not be found" % branch_name
    
    ... ... @@ -45,6 +70,18 @@ def main(git_repo, remotes,
    45 70
     
    
    46 71
         c_b_map = kernel_sec.branch.CommitBranchMap(git_repo, remotes, branches)
    
    47 72
     
    
    73
    +    # cache tag commits and set full_name to show the tag
    
    74
    +    tag_commits = {}
    
    75
    +    for branch in branches:
    
    76
    +        if 'tag' in branch:
    
    77
    +            start = 'v' + branch['base_ver']
    
    78
    +            end = branch['tag']
    
    79
    +            tag_commits[end] = set(
    
    80
    +                kernel_sec.branch.iter_rev_list(git_repo, end, start))
    
    81
    +            branch['full_name'] = ':'.join([branch['short_name'], end])
    
    82
    +        else:
    
    83
    +            branch['full_name'] = branch['short_name']
    
    84
    +
    
    48 85
         branch_issues = {}
    
    49 86
         issues = set(kernel_sec.issue.get_list())
    
    50 87
     
    
    ... ... @@ -65,15 +102,32 @@ def main(git_repo, remotes,
    65 102
                 if not include_ignored and ignore.get(branch_name):
    
    66 103
                     continue
    
    67 104
     
    
    105
    +            # Check if the branch is affected. If not and the issue was fixed
    
    106
    +            # on that branch, then make sure the tag contains that fix
    
    68 107
                 if kernel_sec.issue.affects_branch(
    
    69 108
                         issue, branch, c_b_map.is_commit_in_branch):
    
    70
    -                branch_issues.setdefault(branch_name, []).append(cve_id)
    
    109
    +                branch_issues.setdefault(
    
    110
    +                    branch['full_name'], []).append(cve_id)
    
    111
    +            elif 'tag' in branch and fixed:
    
    112
    +                if fixed.get(branch_name, 'never') == 'never':
    
    113
    +                    continue
    
    114
    +                for commit in fixed[branch_name]:
    
    115
    +                    if commit not in tag_commits[branch['tag']]:
    
    116
    +                        branch_issues.setdefault(
    
    117
    +                            branch['full_name'], []).append(cve_id)
    
    118
    +                        break
    
    71 119
     
    
    72 120
         for branch in branches:
    
    73
    -        branch_name = branch['short_name']
    
    74
    -        print('%s:' % branch_name,
    
    75
    -              *sorted(branch_issues.get(branch_name, []),
    
    76
    -                      key=kernel_sec.issue.get_id_sort_key))
    
    121
    +        sorted_cve_ids = sorted(
    
    122
    +            branch_issues.get(branch['full_name'], []),
    
    123
    +            key=kernel_sec.issue.get_id_sort_key)
    
    124
    +        if show_description:
    
    125
    +            print('%s:' % branch['full_name'])
    
    126
    +            for cve_id in sorted_cve_ids:
    
    127
    +                print(cve_id, '=>',
    
    128
    +                      kernel_sec.issue.load(cve_id).get('description', 'None'))
    
    129
    +        else:
    
    130
    +            print('%s:' % branch['full_name'], *sorted_cve_ids)
    
    77 131
     
    
    78 132
     
    
    79 133
     if __name__ == '__main__':
    
    ... ... @@ -102,15 +156,20 @@ if __name__ == '__main__':
    102 156
         parser.add_argument('--include-ignored',
    
    103 157
                             action='store_true',
    
    104 158
                             help='include issues that have been marked as ignored')
    
    159
    +    parser.add_argument('--show-description',
    
    160
    +                        action='store_true',
    
    161
    +                        help='show the issue description')
    
    105 162
         parser.add_argument('branches',
    
    106 163
                             nargs='*',
    
    107
    -                        help=('specific branch to report on '
    
    108
    -                              '(default: all active branches)'),
    
    109
    -                        metavar='BRANCH')
    
    164
    +                        help=('specific branch[:tag] or stable tag to '
    
    165
    +                              'report on (default: all active branches). '
    
    166
    +                              'e.g. linux-4.14.y linux-4.4.y:v4.4.107 '
    
    167
    +                              'v4.4.181-cip33 linux-4.19.y-cip:myproduct-v33'),
    
    168
    +                        metavar='[BRANCH[:TAG]|TAG]')
    
    110 169
         args = parser.parse_args()
    
    111 170
         remotes = kernel_sec.branch.get_remotes(args.remote_name,
    
    112 171
                                                 mainline=args.mainline_remote_name,
    
    113 172
                                                 stable=args.stable_remote_name)
    
    114 173
         kernel_sec.branch.check_git_repo(args.git_repo, remotes)
    
    115
    -    main(args.git_repo, remotes,
    
    116
    -         args.only_fixed_upstream, args.include_ignored, *args.branches)
    174
    +    main(args.git_repo, remotes, args.only_fixed_upstream,
    
    175
    +         args.include_ignored, args.show_description, *args.branches)

  • 5661 - 5680 of 8411