| 00:50 | cbxbiker61 | i finally got around to building some code to use OpenCL on cubox-i |
| 00:51 | cbxbiker61 | ImageMagick seems to work |
| 00:52 | cbxbiker61 | it seems that imx6 OpenCL doesn't support the image formats necessary for x264 encoding, but i'm going to look a bit deeper into that |
| 16:53 | balrog | rabeeh: are you around? I'm having a weird intermittent problem with Ethernet |
| 16:53 | rabeeh | here |
| 16:54 | rabeeh | what is the problem? |
| 17:42 | balrog | rabeeh: Mar 24 10:54:50 blackbox kernel: fec 2188000.ethernet eth0: MDIO read timeout |
| 17:42 | balrog | I get this intermittently; when it happens, ethernet cuts out |
| 17:42 | balrog | this is an i4pro |
| 17:56 | balrog | rabeeh: intermittently as in it works for a few weeks or a month |
| 17:56 | balrog | then boom |
| 17:57 | balrog | only way to resolve is a reboot |
| 18:10 | balrog | rabeeh: I'm not sure if this is defective hardware, or a kernel issue. |
| 18:18 | rabeeh | balrog: what are you running? |
| 18:18 | rabeeh | which distro? which kernel? patch level? |
| 18:18 | balrog | rabeeh: Arch Linux |
| 18:18 | rabeeh | recent ones? |
| 18:18 | balrog | yes, the 3.14.36-1-ARCH imx6-dt kernel |
| 18:19 | rabeeh | there was a bug in the dt that we fixed |
| 18:19 | rabeeh | that puts mdio signal as open drain as it should; but that was ages ago |
| 18:19 | balrog | linux-imx6-cubox-dt 3.14.36-1 is what I'm running. |
| 18:20 | balrog | I had a much older revision, just updated, rebooted, day later, boom |
| 18:25 | balrog | rabeeh: are there any patches that this version misses, or is there any way I can debug? |
| 18:26 | rabeeh | just make sure the following patch is included - |
| 18:26 | rabeeh | https://github.com/linux4kix/linux-linaro-stable-mx6/commit/26d3cf45a60082ffa2dd2cec266238dec035c68f |
| 18:33 | balrog | https://github.com/moonman/linux-imx6-3.14/commit/26d3cf45a60082ffa2dd2cec266238dec035c68f -- yes it's applied |
| 18:36 | jnettlet | balrog, also try running a straight 3.14.14 kernel. There are a few upstream patches I am dropping from the recent 3.14.xx kernels because they tend to cause problems |
| 18:36 | balrog | jnettlet: their mainline kernel is now 3.19 |
| 18:36 | balrog | are most of the patches upstreamed by now? |
| 18:37 | balrog | (their meaning the one in arch) |
| 18:37 | balrog | I was suggested that and will probably do that |
| 18:38 | jnettlet | actually the 3.19 driver has some fixes as well as some new problems |
| 18:38 | balrog | this problem is *extremely* intermittent |
| 18:39 | balrog | it will go a month or more without happening |
| 18:39 | jnettlet | the current maintainer is favoring minor performance increases over reliability |
| 18:39 | balrog | I've experienced it since I got the box, though |
| 18:39 | balrog | hmm :/ |
| 18:39 | jnettlet | I have a box here with my kernel that has been connected for over two months without any interruptions |
| 18:40 | jnettlet | although I am working on fixing a couple of problems I have found regarding udp performance |
| 18:40 | jnettlet | but I haven't seen the MDIO timeout since the end of last summer. |
| 18:40 | wrexem | balrog, not to approach a complicated problem with a hammer... but have you considered a daily or weekly reboot? do you know if a soft-boot mitigates the issue? |
| 18:41 | balrog | wrexem: a soft reboot mitigates the issue |
| 18:41 | wrexem | That would suggest to me that it's a software problem, at least. |
| 18:41 | balrog | I dislike periodic reboots; that's a hack around the problem. |
| 18:41 | balrog | wrexem: not certain because it seems like the PHY gets upset about something and then won't come back without reboot |
| 18:41 | wrexem | Abosolutely concur. Just wondered if perhaps it would be "good enough" for the moment. |
| 18:41 | balrog | is the PHY physically reset on reboot? |
| 18:42 | balrog | I have the thing on a PDU so I can remote in and power it down and back up when it happens |
| 18:42 | jnettlet | balrog, all I can recommend is either stick with our release kernel, or track upstream and report problems against that. |
| 18:42 | wrexem | (I'm not qualified to answer that, re PHY) jnettlet, rabeeh ? |
| 18:42 | jnettlet | I know ARCH loves patching the latest "stable" patches but nobody reviews them to see what they effect |
| 18:43 | jnettlet | and there just aren't enough of me to track all the random stuff each distro wants to do |
| 18:43 | balrog | https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-imx6-cubox-dt/PKGBUILD |
| 18:43 | jnettlet | yes the PHY is reset on reboot |
| 18:43 | balrog | it seems the only patches they're using are for aufs3, bluetooth, and CEC? |
| 18:44 | balrog | (lines 47 through 63) |
| 18:44 | jnettlet | well and the entire upstream stable patchsets |
| 18:44 | jnettlet | my testing is at 3.14.30 and I have already found a few problems |
| 18:44 | balrog | https://github.com/moonman/linux-imx6-3.14 has upstream stable patches, right? |
| 18:44 | jnettlet | we don't track a straight stable kernel because we need a lot of upstream patches |
| 18:45 | jnettlet | don't know. that isn't a SolidRun repo |
| 18:47 | jnettlet | balrog, I run QA machines against my kernel only. Your best bet is to report a bug for the ARCH maintainer to take care of. If you run my kernel and see the problem then I will look into it more. |
| 18:48 | jnettlet | Ubuntu taught me this a long time ago. You can't chase random distro bugs, because distro maintainers break things unknowingly all the time. Unfortuanately most distros have given up any sort of QA at all. |
| 18:50 | jnettlet | sorry to diatribe, just explaining where I am coming from. |
| 18:51 | WarheadsS | 18:51 * WarheadsSE waves |
| 18:51 | balrog | hey WarheadsSE |
| 18:52 | WarheadsSE | moonman's otherwise unavailable atm |
| 18:52 | WarheadsSE | I'm just walking back the tree of changes he's got since forking |
| 18:53 | WarheadsSE | Also, it isn't "ARCH" it is Arch Linux ARM |
| 18:55 | balrog | jnettlet: I get where you're coming from; that said the SolidRun repo is three months old |
| 18:55 | balrog | (unless you're referring to a different repo that I'm not aware of) |
| 18:56 | jnettlet | balrog, yes I am working on a refresh. The stable backports only actually have 3 fixes that are relevant to our hardware |
| 18:56 | jnettlet | and none of them are critical |
| 18:56 | jnettlet | people confuse newer with better |
| 18:57 | WarheadsSE | or other features that are not SoC specific. |
| 18:58 | jnettlet | that is what distros are for, but then they need to take responsibility and do first line debugging if something breaks |
| 18:58 | WarheadsSE | Yes, and I am digging around now. I simply asked blarog to come see if you have ever seen this. |
| 18:58 | jnettlet | not for half a year |
| 18:59 | balrog | I've experienced this issue for a while |
| 18:59 | WarheadsSE | I have seen it happen on custom hardware where the clocks shifted the tiniest bit |
| 18:59 | WarheadsSE | mind you, that on also had a bad cap, which caused the RGMII to belly up |
| 18:59 | balrog | let me go through all my logs; will take a while though since journalctl grep on how long |
| 18:59 | balrog | That's what I'm afraid, that it's bad hardware |
| 19:00 | WarheadsSE | I can easily spawn him a kernel image from your tree alone, with a config to match our current one (and systemd needs) if we can't rule anything else out. |
| 19:01 | balrog | I won't know if it crashes for a while :/ |
| 19:01 | WarheadsSE | Yeah, that's the annoying part. |
| 19:01 | balrog | unless you have a suggestion to make it crash sooner. |
| 19:02 | jnettlet | iperf3 24-7 while compiling a kernel mounted via NFS? |
| 19:03 | balrog | there's quite a bit of network chatter here as-is |
| 19:03 | balrog | not constant, but... |
| 19:49 | balrog | WarheadsSE: is there anything in the tree with patches that affects this device? |
| 19:56 | WarheadsSE | not directly, that I am aware |
| 20:11 | Falcon_ | Any geexboxer here? |
| 20:20 | Falcon_ | I'm running GeexBox on the original cubox (Marvell). And my remote is not registered as HID. 0766:0204 |
| 20:20 | Falcon_ | Should work: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f14f526d02b14fd0b8c1ac4ec413e4577ad5f62e |
| 20:20 | Falcon_ | Works on my Intel Ubuntu laptop |
| 20:20 | Falcon_ | Any pointers? |
| 20:41 | Falcon_ | Okay I've found it registers a /dev/input/event1 but using 'cat /dev/input/event1' it shows nothing. On my intel ubuntu laptop it works. |
| 21:07 | Falcon_ | cubox-i same |
| 21:57 | Falcon_ | Xbian on cubox-i work ok. Ergo must be somthing in geexbox config |