*** rajm has joined #cip | 07:15 | |
* rajm runs a successful BBB health check with email to the list | 07:54 | |
*** toscalix has joined #cip | 07:54 | |
*** vidda_ has joined #cip | 08:46 | |
*** moxavictor has joined #cip | 08:51 | |
szlin | The meeting will be started after 5 minutes | 08:55 |
---|---|---|
*** Tzongyen_Lin has joined #cip | 08:55 | |
szlin | #startmeeting | 09:00 |
szlin | #topic roll call | 09:00 |
gavinlai | hi | 09:00 |
szlin | please say hi if you're in this meeting | 09:00 |
moxavictor | hi | 09:00 |
szlin | ._./~\ | 09:00 |
vidda_ | hi | 09:00 |
Tzongyen_Lin | hi | 09:00 |
bwh | hi | 09:00 |
szlin | #topic kernel patch review update | 09:01 |
weshuang | hi | 09:01 |
szlin | Moxa team is still reviewing patch 4.4.130 | 09:02 |
toscalix | hi | 09:02 |
szlin | we do have some questions while reivewing it | 09:02 |
szlin | gavinlai: please go ahead | 09:03 |
gavinlai | I have two questions | 09:03 |
rajm | hi (sorry I'm late) | 09:03 |
gavinlai | when we review the code, do we need to write some code to test them? I'm not very confident to just 'review' it | 09:04 |
gavinlai | the second question is: If a bug needs time to reproduce or hard to reproduce, how do we make sure the bug is fixed correctly? | 09:04 |
bwh | gavinlai: If you want to, you could write a test. In some cases there is a relevant selftest in the kernel (maybe only upstream, not in 4.4) | 09:05 |
szlin | sometime we need to backport the selftest first if there are not in the 4.4 | 09:06 |
bwh | Generally I think we should assume that the fix was tested when the patch was originally applied. And we are looking for reasons why that fix might not be valid for 4.4, or might cause regressions. | 09:06 |
gavinlai | A friend told me I can put functions into userspace. And, input all kinds of input to function to verify the function is robust. | 09:08 |
bwh | szlin: Well maybe, but that isn't being done consistently. I generally use the selftests from the current upstream kernel with minimal changes | 09:08 |
gavinlai | Is that a good way to test the functions? | 09:09 |
bwh | Those will produce lots of failures due to missing features in the older version I'm looking at, but I can still test for regressions | 09:09 |
bwh | gavinlai: It really depends on what is being fixed. Only a few parts of the kernel have good selftests. | 09:09 |
szlin | bwh: I see, thanks. | 09:11 |
bwh | gavinlai: Sorry, I missed your previous comment ("A friend tod me ...") | 09:11 |
bwh | Yes, that can work for some functions where you can easily isolate inputs and outputs | 09:11 |
gavinlai | A friend told me I can put functions into userspace. | 09:11 |
gavinlai | And, input all kinds of input to function to verify the function is robust. | 09:11 |
*** HarryYJ_Jhou has joined #cip | 09:13 | |
gavinlai | If a feature is lack of selftests, is there any good way to verify them? | 09:14 |
bwh | In some cases there are external tests like LTP and xfstests (which is for all filesystems, not just xfs) | 09:14 |
bwh | But those can take a long time to set up and run | 09:15 |
moxavictor | I have a question. Now we review kernel foundation to CIP. Some day foundation does not maintion version 4.4. How we review the applied code OK or fail ? | 09:15 |
bwh | moxavictor: It's really just Greg, not the Linux Foundation (even though they employ him). CIP will have to take over Greg's role too. | 09:16 |
bwh | There are scripts for maintaining stable branches - Greg K-H, Alexander Levin and I have published ours | 09:17 |
moxavictor | Do we need to test CIP kernel ? | 09:18 |
toscalix | yes | 09:18 |
toscalix | moxavictor: you will catch bugs | 09:18 |
szlin | Now rajm is testing CIP kernel via kernelci & lava | 09:18 |
szlin | https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting | 09:18 |
toscalix | some of them due to platform specific patches applied only to the CIP kernel but other also affecting 4.4 or even other versions | 09:19 |
rajm | indeed - we've just had a fire practice - sorry if there was a delay here! | 09:19 |
bwh | Right, but rajm is mostly occupied just keeping the automation going. We need to add test cases/test suites | 09:19 |
toscalix | bwh: is correct, we are in need to adding tests and inspecting results for CIP specific platforms | 09:19 |
toscalix | I would love to see us also helping upstream in evaluating the bugs out of kernelci | 09:20 |
toscalix | in kernelci.org for 4.4-stable on BBB | 09:20 |
toscalix | or even add renesas board to that pull | 09:20 |
toscalix | Renesas is working with the Linux Foundation in our own kernelci set up | 09:21 |
toscalix | we can do it there and help upstream at the same time | 09:21 |
szlin | AFAIK, Daniel from Toshiba had used LTP to test kernel | 09:21 |
toscalix | having a lab in Moxa facilities | 09:21 |
moxavictor | The testing need hardware. Could we offer some hardware and let tester remote to test it ? | 09:21 |
toscalix | with CIP platforms | 09:21 |
szlin | and he had sent some patches afterwards. | 09:21 |
toscalix | moxavictor: the first point is to include your hardware as CIP hardware | 09:22 |
toscalix | which will require that you include the hardware support updtream | 09:22 |
toscalix | we had a meeting a while back about it | 09:22 |
toscalix | we would love to have Moxa hardware as an official CIP platform. I assume that is a great movivation for Moxa to join as well | 09:23 |
toscalix | there is just some homework to be done to reach that point | 09:24 |
toscalix | just like Renesas did | 09:24 |
moxavictor | Good. We also like to be a CIP hardware. | 09:24 |
szlin | any questions? | 09:24 |
moxavictor | I have a question | 09:25 |
szlin | bwh: How do you think with Kernel Self Protection Project? | 09:26 |
moxavictor | I mean if Moxa platform is a CIP hardware, and put it In Taiwan, can you remote to control and test it ? | 09:26 |
bwh | szlin: It's good, but hard to backport the features it's adding so it will be more useful to the next CIP kernel branch | 09:27 |
toscalix | rajm: is the LAVA guy, I will let him answer the question | 09:27 |
rajm | the question - abt remote control? the existing setup with b@d is very much a local environment | 09:29 |
szlin | bwh: thanks. | 09:29 |
moxavictor | yes | 09:29 |
toscalix | but the set up Renesas is building for CIP is similar to AGL one, based on kernelci.org | 09:30 |
toscalix | in that set up, labs are distributed | 09:30 |
toscalix | and developers can access those labs remotely and execute tests | 09:30 |
moxavictor | yes, do we want to create it ? | 09:31 |
toscalix | so yes, you will be able to have the hardware at your office and have developers around the world accessing to it to test | 09:31 |
toscalix | it will be up to Moxa to decide if you want to create your own lab or not and report results to the CIP dashboard | 09:31 |
toscalix | at Codethink, we will try to work on adapting B@D to the CIP set up so you ca publish the results you get locally without needing to set up a lab | 09:32 |
moxavictor | you can remote to get the testing report | 09:32 |
toscalix | yes you can | 09:33 |
toscalix | but you can also restrict what you share | 09:33 |
szlin | Next step we will setup the B@D. | 09:33 |
toscalix | B@D is meant to be cheap and easy to maintain, a development resource, not a delivery (QA) resource | 09:34 |
toscalix | but you guys are used to the concept of a lab since you manufacture hardware, so I guess you will welcome both | 09:34 |
szlin | Indeed | 09:35 |
toscalix | It will not surprise me if you end up setting your own internal kernelci service, like other big companies have | 09:35 |
szlin | any questions? | 09:36 |
szlin | #topic Miscellaneous | 09:36 |
moxavictor | I want to offer some hardware to let some people to test it. | 09:36 |
szlin | toscalix: as victor mentioned, we will follow the procedure and to let our board become CIP board. | 09:37 |
moxavictor | Could I ask a question about kernel graphic device driver ? | 09:37 |
moxavictor | Now I try i.MX8MQ EVK to start XWindows. But I run startx to get a error "No screen found". What happens it ? | 09:39 |
moxavictor | I can enable text mode login terminal by HDMI monitor. | 09:40 |
bwh | moxavictor: There are many reasons why they could happen. I don't think it makes sense to debug in this meeting | 09:40 |
szlin | any questions? | 09:41 |
moxavictor | yes, I know, Could I talk with you some where ? | 09:41 |
moxavictor | Thanks | 09:41 |
bwh | moxavictor: After the meeting | 09:42 |
bwh | hjere | 09:42 |
szlin | #endmeeting | 09:42 |
moxavictor | OK. Thank you. | 09:42 |
* szlin thank you all for attending this meeting | 09:42 | |
toscalix | bye | 09:42 |
gavinlai | thanks | 09:42 |
Tzongyen_Lin | thanks | 09:42 |
*** Tzongyen_Lin has quit IRC | 09:43 | |
bwh | thanks | 09:43 |
rajm | ty | 09:43 |
moxavictor | bwh: could we talk about my graphic issue at now ? | 09:43 |
bwh | moxavictor: Firstly, is the X server properly installed? You need the core X server and video and input drivers for your devices | 09:44 |
moxavictor | Yes, I install it. | 09:44 |
bwh | If you use startx, then the X server might need to be installed setuid | 09:44 |
moxavictor | setuid ? a utility ? | 09:44 |
bwh | It should have the setuid file attribute | 09:45 |
moxavictor | I run the same process in another board TI AM437x EVK OK. | 09:46 |
bwh | (but this isn't always needed, and the X server is usually run as non-root now, which is good) | 09:46 |
moxavictor | I try fbtest OK. | 09:46 |
moxavictor | I got a device node /dev/fb0. | 09:46 |
bwh | OK, well there should be a log file in either /var/log/Xorg.0.log or ~/.local/share/xorg/Xorg.0.log | 09:46 |
moxavictor | Yes. It has | 09:47 |
bwh | and that should give you some details of what went wrong | 09:47 |
moxavictor | OK. I post it. | 09:47 |
moxavictor | (II) LoadModule: "fbdevhw" | 09:48 |
moxavictor | [ 25.094] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so | 09:48 |
moxavictor | [ 25.095] (II) Module fbdevhw: vendor="X.Org Foundation" | 09:48 |
moxavictor | [ 25.096] compiled for 1.19.2, module version = 0.0.2 | 09:48 |
moxavictor | [ 25.096] ABI class: X.Org Video Driver, version 23.0 | 09:48 |
moxavictor | [ 25.096] (EE) No devices detected. | 09:48 |
moxavictor | [ 25.096] (EE) | 09:48 |
moxavictor | Fatal server error: | 09:48 |
moxavictor | [ 25.096] (EE) no screens found(EE) | 09:49 |
moxavictor | [ 25.096] (EE) | 09:49 |
bwh | That's all? | 09:49 |
moxavictor | NO. | 09:49 |
moxavictor | [ 24.965] X Protocol Version 11, Revision 0 | 09:49 |
moxavictor | [ 24.965] Build Operating System: Linux 4.9.0-4-arm64 aarch64 Debian | 09:49 |
moxavictor | [ 24.965] Current Operating System: Linux imx8m 4.9.80-rt62-victor+ #9 SMP Th | 09:49 |
moxavictor | u May 31 14:19:25 HKT 2018 aarch64 | 09:49 |
moxavictor | [ 24.965] Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk1p2 roo | 09:49 |
moxavictor | tfstype=ext4 rootwait rw cma=800M video=HDMI-A-1:1920x1080-32@60 | 09:49 |
moxavictor | [ 24.965] Build Date: 16 October 2017 08:11:43AM | 09:49 |
moxavictor | [ 24.965] xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support) | 09:49 |
moxavictor | [ 24.965] Current version of pixman: 0.34.0 | 09:49 |
moxavictor | [ 24.965] Before reporting problems, check http://wiki.x.org | 09:50 |
moxavictor | to make sure that you have the latest version. | 09:50 |
moxavictor | [ 24.965] Markers: (--) probed, (**) from config file, (==) default setting, | 09:50 |
moxavictor | (++) from command line, (!!) notice, (II) informational, | 09:50 |
moxavictor | (WW) warning, (EE) error, (NI) not implemented, (??) unknown. | 09:50 |
moxavictor | [ 24.965] (==) Log file: "/var/log/Xorg.0.log", Time: Thu May 31 16:22:44 201 | 09:50 |
moxavictor | 8 | 09:50 |
moxavictor | [ 24.972] (==) Using system config directory "/usr/share/X11/xorg.conf.d" | 09:50 |
moxavictor | [ 24.975] (==) No Layout section. Using the first Screen section. | 09:50 |
moxavictor | [ 24.975] (==) No screen section available. Using defaults. | 09:50 |
moxavictor | [ 24.976] (**) |-->Screen "Default Screen Section" (0) | 09:50 |
moxavictor | [ 24.976] (**) | |-->Monitor "<default monitor>" | 09:50 |
moxavictor | [ 24.979] (==) No monitor specified for screen "Default Screen Section". | 09:50 |
moxavictor | Using a default monitor configuration. | 09:50 |
moxavictor | [ 24.979] (==) Automatically adding devices | 09:50 |
moxavictor | [ 24.979] (==) Automatically enabling devices | 09:50 |
moxavictor | [ 24.979] (==) Automatically adding GPU devices | 09:50 |
moxavictor | [ 24.979] (==) Max clients allowed: 256, resource mask: 0x1fffff | 09:50 |
moxavictor | [ 24.989] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. | 09:50 |
moxavictor | [ 24.989] Entry deleted from font path. | 09:50 |
moxavictor | [ 25.000] (==) FontPath set to: | 09:50 |
moxavictor | /usr/share/fonts/X11/misc, | 09:50 |
moxavictor | /usr/share/fonts/X11/100dpi/:unscaled, | 09:50 |
moxavictor | /usr/share/fonts/X11/75dpi/:unscaled, | 09:50 |
moxavictor | /usr/share/fonts/X11/Type1, | 09:51 |
moxavictor | /usr/share/fonts/X11/100dpi, | 09:51 |
moxavictor | /usr/share/fonts/X11/75dpi, | 09:51 |
moxavictor | built-ins | 09:51 |
moxavictor | [ 25.000] (==) ModulePath set to "/usr/lib/xorg/modules" | 09:51 |
moxavictor | [ 25.000] (II) The server relies on udev to provide the list of input devices | 09:51 |
moxavictor | . | 09:51 |
moxavictor | If no devices become available, reconfigure udev or disable AutoAddDevic | 09:51 |
moxavictor | es. | 09:51 |
moxavictor | [ 25.000] (II) Loader magic: 0xaaaad7488dc8 | 09:51 |
moxavictor | [ 25.000] (II) Module ABI versions: | 09:51 |
moxavictor | [ 25.000] X.Org ANSI C Emulation: 0.4 | 09:51 |
moxavictor | [ 25.000] X.Org Video Driver: 23.0 | 09:51 |
moxavictor | [ 25.000] X.Org XInput driver : 24.1 | 09:51 |
moxavictor | [ 25.000] X.Org Server Extension : 10.0 | 09:51 |
moxavictor | [ 25.002] (--) using VT number 2 | 09:51 |
moxavictor | [ 25.002] (II) systemd-logind: logind integration requires -keeptty and -keep | 09:51 |
moxavictor | tty was not provided, disabling logind integration | 09:51 |
moxavictor | [ 25.003] (II) xfree86: Adding drm device (/dev/dri/card1) | 09:51 |
moxavictor | [ 25.004] (II) xfree86: Adding drm device (/dev/dri/card0) | 09:51 |
moxavictor | [ 25.006] (II) no primary bus or device found | 09:51 |
moxavictor | [ 25.006] falling back to /sys/devices/platform/38000000.gpu/drm/card1 | 09:51 |
moxavictor | [ 25.006] (II) LoadModule: "glx" | 09:51 |
moxavictor | [ 25.009] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so | 09:51 |
moxavictor | [ 25.045] (II) Module glx: vendor="X.Org Foundation" | 09:52 |
moxavictor | [ 25.045] compiled for 1.19.2, module version = 1.0.0 | 09:52 |
moxavictor | [ 25.045] ABI class: X.Org Server Extension, version 10.0 | 09:52 |
moxavictor | [ 25.046] (==) Matched modesetting as autoconfigured driver 0 | 09:52 |
moxavictor | [ 25.046] (==) Matched fbdev as autoconfigured driver 1 | 09:52 |
moxavictor | [ 25.046] (==) Assigned the driver to the xf86ConfigLayout | 09:52 |
moxavictor | [ 25.046] (II) LoadModule: "modesetting" | 09:52 |
moxavictor | [ 25.046] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so | 09:52 |
moxavictor | [ 25.049] (II) Module modesetting: vendor="X.Org Foundation" | 09:52 |
moxavictor | [ 25.049] compiled for 1.19.2, module version = 1.19.2 | 09:52 |
moxavictor | [ 25.049] Module class: X.Org Video Driver | 09:52 |
moxavictor | [ 25.049] ABI class: X.Org Video Driver, version 23.0 | 09:52 |
moxavictor | [ 25.049] (II) LoadModule: "fbdev" | 09:52 |
moxavictor | [ 25.049] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so | 09:52 |
moxavictor | [ 25.051] (II) Module fbdev: vendor="X.Org Foundation" | 09:52 |
moxavictor | [ 25.051] compiled for 1.19.0, module version = 0.4.4 | 09:52 |
moxavictor | [ 25.051] Module class: X.Org Video Driver | 09:52 |
moxavictor | [ 25.051] ABI class: X.Org Video Driver, version 23.0 | 09:52 |
moxavictor | [ 25.051] (II) modesetting: Driver for Modesetting Kernel Drivers: kms | 09:52 |
moxavictor | [ 25.051] (II) FBDEV: driver for framebuffer: fbdev | 09:52 |
moxavictor | [ 25.089] (II) modeset(G0): using drv /dev/dri/card0 | 09:52 |
moxavictor | [ 25.089] (WW) Falling back to old probe method for fbdev | 09:52 |
moxavictor | [ 25.089] (II) Loading sub module "fbdevhw" | 09:52 |
moxavictor | [ 25.089] (II) LoadModule: "fbdevhw" | 09:52 |
moxavictor | [ 25.094] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so | 09:53 |
szlin | moxavictor: you can post log into here -> https://pastebin.com | 09:53 |
moxavictor | [ 25.095] (II) Module fbdevhw: vendor="X.Org Foundation" | 09:53 |
moxavictor | [ 25.096] compiled for 1.19.2, module version = 0.0.2 | 09:53 |
moxavictor | [ 25.096] ABI class: X.Org Video Driver, version 23.0 | 09:53 |
moxavictor | [ 25.096] (EE) No devices detected. | 09:53 |
moxavictor | [ 25.096] (EE) | 09:53 |
moxavictor | Fatal server error: | 09:53 |
moxavictor | [ 25.096] (EE) no screens found(EE) | 09:53 |
moxavictor | [ 25.096] (EE) | 09:53 |
moxavictor | Please consult the The X.Org Foundation support | 09:53 |
moxavictor | at http://wiki.x.org | 09:53 |
moxavictor | for help. | 09:53 |
moxavictor | [ 25.096] (EE) Please also check the log file at "/var/log/Xorg.0.log" for ad | 09:53 |
moxavictor | ditional information. | 09:53 |
moxavictor | [ 25.096] (EE) | 09:53 |
moxavictor | [ 25.201] (EE) Server terminated with error (1). Closing log file. | 09:53 |
moxavictor | that's all | 09:53 |
moxavictor | any idea ? | 09:53 |
moxavictor | OK. | 09:53 |
bwh | I notice there's a /dev/dri/card0 and card1. Why two? | 09:54 |
moxavictor | I have the same question | 09:55 |
bwh | :-) | 09:55 |
bwh | and the server appears to only try to use /dev/dri/card0, but maybe it should be using card1 | 09:55 |
moxavictor | This board can support HDMI and another interface | 09:57 |
bwh | Yes, but there arne't normally multiple device nodes for multiple outputs | 09:58 |
moxavictor | I view /sys/class/drm has directory following : | 09:58 |
moxavictor | card0 card0-HDMI-A-1 card1 controlD64 renderD128 version | 09:59 |
moxavictor | There are card0 & card1 ? | 09:59 |
bwh | OK, so that confirms that card0 actually has the HDMI connector | 09:59 |
bwh | What do "readlink /sys/class/drm/card0/device/driver" and the same with card1, say? | 10:00 |
moxavictor | I can normal tty1 ~ tty6 in HDMI | 10:00 |
moxavictor | NO | 10:02 |
moxavictor | card0 is linked to gpu device driver | 10:02 |
moxavictor | card1 is linked to galcore device driver | 10:02 |
bwh | galcore is the Vivante GPU driver, no? | 10:05 |
moxavictor | I know i.MX is usually to use galcore | 10:06 |
moxavictor | but the i.MX8 is a new SoC | 10:06 |
moxavictor | I am not sure it is still to use galcore | 10:07 |
moxavictor | may it duplicate the device driver ? | 10:10 |
moxavictor | I mean that it should use one driver galcore or gpu ? | 10:10 |
bwh | I'm not familiar with this hardware, but isn't the first driver for the display engine, not the GPU? | 10:11 |
bwh | If those are two separate IP blocks it seems to be common to have two separate drivers for them | 10:13 |
moxavictor | yes | 10:13 |
moxavictor | Ok. Thank your help. I go to get more information. | 10:15 |
moxavictor | Do you usually in this channel ? | 10:15 |
moxavictor | Could I discuss with you here after ? | 10:16 |
moxavictor | Or where I can discuss with you ? | 10:16 |
moxavictor | bwh: Bye. See you next time. Thanks. | 10:18 |
bwh | Sorry, had to go away from the computer. | 10:21 |
bwh | I'm always on this channel, but not necessarily at the computer | 10:21 |
moxavictor | bwh: that's OK. | 10:24 |
*** vidda_ has quit IRC | 10:34 | |
*** weshuang has quit IRC | 11:45 | |
*** weshuang has joined #cip | 11:56 | |
*** tpollard has quit IRC | 12:02 | |
*** tpollard has joined #cip | 12:07 | |
*** tpollard has quit IRC | 13:46 | |
*** tpollard has joined #cip | 13:53 | |
*** toscalix has quit IRC | 14:24 | |
*** toscalix has joined #cip | 14:25 | |
*** rajm has quit IRC | 14:30 | |
*** rajm has joined #cip | 14:44 | |
*** rajm has quit IRC | 14:52 | |
*** rajm has joined #cip | 15:14 | |
*** rajm has quit IRC | 15:47 | |
*** toscalix has quit IRC | 17:09 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!