IRC logs for #cip for Thursday, 2019-08-08

*** rajm has joined #cip01:51
*** helmut has quit IRC05:35
*** therisen has joined #cip06:33
*** therisen has quit IRC07:42
*** therisen has joined #cip07:42
*** toscalix has joined #cip07:48
*** pave1 has joined #cip08:56
*** kazu has joined #cip08:59
szlin#startmeeting CIP IRC weekly meeting09:00
brloggerMeeting started Thu Aug  8 09:00:02 2019 UTC and is due to finish in 60 minutes.  The chair is szlin. Information about MeetBot at http://wiki.debian.org/MeetBot.09:00
brloggerUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.09:00
brloggerThe meeting name has been set to 'cip_irc_weekly_meeting'09:00
*** brlogger changes topic to " (Meeting topic: CIP IRC weekly meeting)"09:00
szlin#topic rollcall09:00
*** brlogger changes topic to "rollcall (Meeting topic: CIP IRC weekly meeting)"09:00
szlinplease say hi if you're around09:00
patersonchi09:00
*** yamamodo has joined #cip09:00
iwamatsuhi09:00
yamamodohi09:00
kazuhi09:00
wagihi09:00
szlin#topic AI review09:00
*** brlogger changes topic to "AI review (Meeting topic: CIP IRC weekly meeting)"09:00
pave1hi09:01
szlin1. Work out a solution for LAVA master backups - patersonc09:01
patersoncNo update. Probably won't be done for a little while. It's on my tasklist, I'm not sure if it's worth removing from these actions?09:01
szlinOk, I will remove it. Please notice me if you're ready.09:02
patersoncThanks09:02
szlin2. Provide the cases to cip-testing to build up the test environment - Iwamatsu-san09:02
iwamatsuszlin: I am working about this.09:03
szliniwamatsu: thank you09:03
szlin3. Ask cip-dev which configurations need testing - patersonc09:03
szlinpatersonc: I will reply you after the meeting.09:03
patersoncAction is in progress. People beginning to reply now09:04
szlinpatersonc: thank you09:04
szlin4. Confirm we can enable high-res timers for every board - pavel09:04
pave1I sent an email to the list. No replies so far.09:05
szlinpave1: It seems like there is no objection so far.09:05
patersoncI have no objections :)09:05
iwamatsuI have no objections too.09:05
szlinpave1: +109:05
pave1:-). Ok, good. Looks like "enable it and see if anything breaks" is the way to go.09:05
szlinDo you want to discuss with Chris in cyclictest after the meeting?09:06
szlinIIRC, you mentioned you need some assistance09:07
pave1We can talk, but I don't think I'm ready to do much at this moment.09:07
szlinpave1: got it.09:07
szlin5. Add support for PowerPC (4.4 Toshiba config) - patersonc09:07
szlinpatersonc: this AI should be closed09:07
patersoncThis is done, or at least ready to be merged. However Toshiba have said they don't need their powerpc config anymore :)09:08
patersoncSo please close09:08
szlinpatersonc: thank you for your rapid development09:08
szlin6. Test LTS (pre)releases directly - patersonc09:08
patersoncNo progress. May be a few weeks away tbh, I'm a bit busy atm09:08
szlin7. Discuss the primary repository in CIP kernel development (kernel.org or gitlab) - kernel team09:09
szlinI've sent email to discuss this topic.09:09
szlinpave1: bwh ^ Please provide your feedback when you're available.09:09
szlin8. Review and merge "gitlab-ci.yml" - pavel09:09
patersoncDone09:10
patersoncThanks pave109:10
szlinthanks.09:10
szlin#topic Kernel maintenance updates09:10
*** brlogger changes topic to "Kernel maintenance updates (Meeting topic: CIP IRC weekly meeting)"09:10
szliniwamatsu: pave1 do you have any update on kernel maintenance09:11
pave1I've reviewed v4.19.64 and v4.19.65. It is interesting how different can the different releases be.09:11
iwamatsuszlin: I have no update.09:12
szlinpave1: iwamatsu thank you09:12
szlinany other topics?09:12
patersonco/09:12
szlinpatersonc: please go ahead09:12
patersoncI hit a build issue with one of the configs: https://lists.cip-project.org/pipermail/cip-dev/2019-August/002816.html09:13
patersoncIt would be good if someone could take a look.09:13
pave1Yup, sorry about that. Yes, I'll take a look.09:13
patersoncThanks09:13
szlinpave1: thank you09:14
szlin309:14
szlin209:14
pave1Actually,09:14
szlin109:14
pave1this is something we should discuss.09:14
pave1-stable rules say "for serious bugs only".09:14
pave1[They are not being followed by the -stable team, but that's different topic.]09:15
pave1It even has a list of bugs it considers serious, and warnings are ... not bugs in the first place and definitely not on the list.09:15
pave1So my tendency would be to deal with warnings in a simple way that does not risk creating new problems...09:16
patersoncSure09:16
szlinpave1: Some unsuitable patches were merged by AUTOSEL mechanism09:16
pave1...which would be "turn off -Werror" in this particular case.09:16
pave1I just wanted to confirm that this is okay with you?09:16
pave1szlin: Yes, AUTOSEL is by far the worst offender.09:17
patersoncNote that this issue is only with the -rt branch, so perhaps Werror was enabled by the RT project?09:17
iwamatsuWe need to decide on default compiler's options.09:18
pave1patersonc: I'll need to take a detailed look, maybe it is just an config issue.09:18
patersoncThanks09:18
szlin#action Discuss and make a decision on default compiler's options - kernel team09:19
pave1patersonc: Anyway my point is that -Werror is good for development, but not good for keeping branch stable, especially in presence of different compiler versions.09:19
patersoncpave1: Sure09:19
patersoncDo we need a way to formalising reporting issues like this from the CI process? Or are emails to cip-dev enough?09:19
iwamatsuindeed.09:19
pave1patersonc: I believe cip-dev is ok.09:19
patersoncOkay09:19
szlinany objections?09:20
szlin#agree The CI issues should send to cip-dev mailing list09:20
szlin#topic Kernel testing09:20
*** brlogger changes topic to "Kernel testing (Meeting topic: CIP IRC weekly meeting)"09:20
szlinpatersonc: the floor is yours09:20
patersonc#info linux-cip-ci has been moved to cip-project/cip-testing09:20
patersonc#info Kanban board created to keep track of pending tasks for linux-cip-ci. Please feel free to make requests/pick up tasks.09:20
patersonc#link https://gitlab.com/cip-project/cip-testing/linux-cip-ci/-/boards09:21
patersonc#info The main CIP Kernel branches are now build testing all of the CIP configs (apart from the RT ones).09:21
patersonc#info Started to add some wiki content for the LAVA & CI setups.09:21
patersoncThat's it from me this week. Any comments?09:21
szlin309:21
szlin209:21
szlin109:21
szlin#topic CIP Core09:22
*** brlogger changes topic to "CIP Core (Meeting topic: CIP IRC weekly meeting)"09:22
kazuNo techical updates from the last TSC meeting09:22
kazuI'm refining the package decision process document based on members' feedbacks09:22
kazuthen will release rev2 soon09:22
szlinthanks09:22
szlinany other points?09:22
szlin309:22
kazuI've just sent email to cip-members09:22
patersonco/09:22
kazuabout this topic09:22
szlinpatersonc: yes, please09:23
kazuIf you have any opinions about the update for rev2, please reply09:23
kazupatersonc please go ahead09:23
patersoncWere any decisions made with regards to compiler versions etc. in the end?09:23
kazunot yet in cip core, but in toshiba...09:23
kazuat least, CIP will support the following version combinations: 4.4 + stretch, 4.19 + stretch, 4.19 + buster09:24
kazuSo, the above kernel versions should be tested with gcc of each Debian version09:24
wagipatersonc: (LAVA & CI setup): I'll cleanup my build/submit scripts for -rt soon. Most stuff I needed from test-definitions are now upstream. Last missing feature is 'background command'. Still in discussion. After that all my stuff is ready to be abused :)09:25
patersoncwagi: Thanks09:25
patersonckazu: Will this testing happen as part of cip-core testing?09:25
patersonckazu: Or do I need to build each Kernel config with multiple GCC versions?09:25
szlinkazu: so we can assume that the gcc version will be 8.309:25
szlin6.3 (stretch( and 8.3 (buster)09:26
kazupatersonc please give me time to decide where we do that09:26
szlinkazu: got it, thanks.09:26
patersonckazu: Okay. I'll let you pick up the action :)09:26
patersoncThanks09:26
szlinany other topics?09:26
szlin309:26
szlin209:26
szlin109:26
szlin#topic Software update09:27
*** brlogger changes topic to "Software update (Meeting topic: CIP IRC weekly meeting)"09:27
szlinkazu: do you or Daniel have any update on this topic?09:27
kazuCIP wiki has been updated09:27
kazuThe loadmap will be released soon09:27
szlinkazu: thanks.09:27
szlinany other points?09:27
kazuroadmap09:28
szlin309:28
szlin209:28
szlin109:28
szlin#topic AOB09:28
*** brlogger changes topic to "AOB (Meeting topic: CIP IRC weekly meeting)"09:28
szlinAny other business?09:28
szlin309:28
szlin209:28
szlin109:28
szlin#endmeeting09:28
brloggerMeeting ended Thu Aug  8 09:28:41 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)09:28
brloggerMinutes:        https://irclogs.baserock.org/meetings/cip/2019/08/cip.2019-08-08-09.00.html09:28
brloggerMinutes (text): https://irclogs.baserock.org/meetings/cip/2019/08/cip.2019-08-08-09.00.txt09:28
brloggerLog:            https://irclogs.baserock.org/meetings/cip/2019/08/cip.2019-08-08-09.00.log.html09:28
*** brlogger changes topic to "Civil Infrastructure Platform Project. Find the logs at https://irclogs.baserock.org/cip/"09:28
szlinthank you all09:28
szlinwagi: hi!!! (greeting09:28
kazuthank you09:28
pave1thank you!09:28
iwamatsuthank you09:28
patersoncThanks szlin09:29
yamamodothank you09:29
szlinwagi: I've sent bunch of questions to ask the maintenance of realtime kernel09:29
wagiszlin: hey. Got your emails. sorry for the delay, will try to answer today09:30
pave1wagi: BTW thanks for all the help.09:30
wagiyou're welcome :)09:30
wagiI should be more around from now on.09:31
pave1I did not get the python to run, but I was able to release a kernel, and I believe I'll be able to do it again :-).09:31
wagiis this the stable-rt-tools script?09:31
szlinwagi: thank you very much09:31
wagiszlin: glad to help out :)09:32
pave1wagi: Yes. It requires newer python AFAICT... and I should really know how to do stuff manually before I use the automation.09:32
pave1I have local access to some kind of socfpga, so I can also do basic testing.09:32
wagiah, yeah, it might be some dependency to Python 3.4 or even higher09:33
wagimaybe adding some unit testing would be cool09:34
pave1What I wanted to ask... The socfpga board has say 15 usec average latency, 85 usec latency under normal workloads.09:34
pave1Those numbers seem more or less consistent with what rest of the world is seeing.09:35
pave1But I can see 255 usec latencies if I intentionally overload the system.09:36
pave1wagi: Would that be considered a problem?09:36
wagiwhat type of cpu? armv7?09:37
pave1armv7, yes.09:37
wagisingle core?09:37
pave1Dual core, I believe09:37
wagimy expierence with bbb is that a single core armv7 tends to have a heigh latency value under load compared to idle09:38
wagie.g. idle 20us, under load 180us is not that far off09:38
wagidepends a lot of the workload09:38
pave1wagi: Well, its more like 40usec idle, 80usec kernel build.09:39
wagiwith the iwg20m dual cpu I saw also big latency peaks but not not so high as with a bbb09:39
pave1250usec if I do make -j build of kernel, with OOM killer eventually triggering.09:40
wagilet me check the values on my system, I tend to forget those things :L)09:40
pave1I kind of think that higher latencies are expected with make -j, but wanted to make sure :-).09:40
wagiso for a bbb, I have 17us idle and 129us with hackbench over 5 minutes09:41
wagiavarage around 55us09:41
wagidepends a bit. do you use a rootfs backed by flash?09:43
wagifor example all my system are using a rootfs via nfs09:43
pave1wagi: Ok, bbb numbers are not that different.09:43
pave1wagi: I'm using SD card here.09:43
wagithat means I stress more the netwoking stack09:43
wagithat could be an source of problems09:44
wagithere are a few very cool tracing tools for IO09:44
patersoncWon't that be the same for all of the tests done in the RT LAVA lab?09:44
wagigood point, if you have the same hardware setup and some kernels show how values than I would also point to the kernel09:45
wagis/how/high/09:45
pave1wagi: Is "overloading the machine to the point of OOM killer triggering" considered fair test of -rt kernel?09:46
wagihehe, don't think so09:46
wagias soon you have OOM going around it will surely have a negative impact on rt09:47
wagias soon we hit any sort of allocation path we have a problem09:47
pave1wagi: Ok, I thought so. I just wanted to verify :-).09:48
waginot sure what OOM exactly does, but sounds highly dangerous :)09:49
pave1wagi: Oh, sorry. "Out of memory".09:50
wagiI was referring to the implementation of OOM. It got several rewrites and improvements from the Google and FB guys over the last few years. It is something non trivial which is something dangerous in my eyes :)09:51
pave1wagi: Selecting right proccess to kill is not easy, agreed. And if it selects the realtime task, that means the task now failed.09:52
pave1Ok, I should go, bye for now!09:55
wagicuy09:57
*** pave1 has quit IRC10:12
*** kazu has quit IRC11:09
*** yamamodo has quit IRC11:32
*** therisen has quit IRC15:12
*** angeloc has joined #cip16:50
*** toscalix has quit IRC17:44
*** angeloc has quit IRC18:39
*** angeloc has joined #cip20:12
*** angeloc has quit IRC21:30
*** rajm has quit IRC22:07

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!