| 11:47 | heap_ | hi is it safe if i plug into cuboxi powered 2,5"disk via usb? because i uplagged main power from cubox i and the light was still on until i unplugged the power from that disk also. |
| 11:48 | jnettlet | heap_, yes. The USB is powered directly by the 5V rail. So if you have a powered USB hub then it can bleed enough power back on the 5V rail to run the SOC |
| 11:48 | jnettlet | since USB is 5V that is completely safe |
| 11:57 | mWaltari | I had an issue with 2.5" external disk, it didn't get enough power, and did not wotjk properly, I then bought eclosure which has extra 5V plug for external power supply (Would be even better if there would be enclosure with MicroUSG poerplug because there are tons of Cell phone chargers in every house). But anyways this extra Power solved all my problems... |
| 12:03 | heap_ | well i have 2.5" enclosure, i powered that enclosure plugged into cuboxi + also i plugged into cubox adaptor and its running but after some time period lets say 5hours device is dead and i have to reboot. so i have no idea what issue it could be |
| 12:03 | heap_ | needles to say im running badblocks -b 4096 -c 98304 -p 0 -w -s -v /dev/sdb |
| 12:03 | heap_ | and i got 3th crash of the cubox |
| 12:05 | mWaltari | It could be power fluctuation etc... Try some USB hub that will give enough power for the external disk, for me it did not start (always) |
| 12:06 | heap_ | is separate 1.5A adaptor |
| 12:06 | heap_ | that i use for powering the disk |
| 12:25 | mWaltari | OH, then possibly not that then... |
| 12:46 | jnettlet | heap_, can you please post your dmesg output after it has died? |
| 12:46 | heap_ | jnettlet: even serial link is dead |
| 12:47 | jnettlet | sounds like a kernel crash |
| 12:47 | jnettlet | this is the disk running btrfs right? |
| 12:59 | heap_ | hm Os is on ext4 |
| 12:59 | heap_ | and three is mounted btrfs |
| 12:59 | heap_ | but no activity on btrfs |
| 13:04 | heap_ | jnettlet: that device is fully of kernel crashes |
| 13:04 | heap_ | all the day |
| 13:04 | heap_ | all the time |
| 13:06 | heap_ | i really dont know |
| 13:07 | jnettlet | heap_, well that sounds like bugs that come from 4.1...I have 3.14 devices that have been up for months |
| 13:10 | heap_ | is really 4.1 that buggy? |
| 13:10 | heap_ | jnettlet: why you dont plan to tune 4.1 rather then 3x? |
| 13:11 | jnettlet | because we chose 3.14 as our LTS kernel. You choose an LTS kernel for long term maintenance and stability. |
| 13:12 | jnettlet | I have way more platforms to support than just iMX6. Debugging a new kernel is way too much invested time for almost no benefits. |
| 13:17 | heap_ | ah ok;/ |
| 13:18 | heap_ | and are there any backports of btrfs 4x into 3x |
| 13:18 | heap_ | ? |
| 13:18 | jnettlet | I doubt it since most sane people don't find btrfs as production ready |
| 13:29 | mk001 | heap_: make sure your eSata cable is not sliding / wiggling in the port. It's pullout needed force is quite low (as the board itself is deep inside the box's outer shell. |
| 13:29 | mk001 | btrfs up to 3.19 kernels is very much broken |
| 13:36 | jnettlet | well considering that Facebook who hired many of the top BTRFS developers is only thinking about starting to roll it out to corner case production systems for testing now...I would still consider it "in progress" |
| 13:38 | mk001 | jnettlet: sure, ... 10 years of mileage for FS will put a stability cert. but with BROKEN I mean really BROKEN |
| 13:38 | jnettlet | correct |
| 13:39 | topi` | even xfs has had some odd bug, though xfs has been in production for what, 20 years? |
| 13:40 | mk001 | topi: I have the feeling by accident I must have had to hit them all when I was evaluating LVM + XFS 3-4 years ago |
| 13:41 | jnettlet | I will wait until RHEL accepts it. RedHat usually jumps on the new big thing if there is good reason. The fact they haven't touched it yet is enough to keep me away |
| 13:41 | jnettlet | my data and time are far to valuable |
| 13:42 | mk001 | hopefully your data are still your data (bit-wise) :) |
| 13:48 | topi` | jnettlet: did you take time to test the mikrobus uarts on HB2? |
| 13:49 | topi` | I'm working on another project now since we lost the customer, but it's still good to find out |
| 13:51 | jnettlet | topi`, yes it worked fine. Although I don't have the rs485 connector |
| 13:51 | topi` | ok so I need to debug it further on my side |
| 13:51 | topi` | are we using the same kernel? probably not, since I compiled my onw |
| 14:09 | heap_ | jnettlet: thats not true, btrfs is pretty stable these days |
| 14:10 | jnettlet | except for it possibly crashing your device every 5 hours |
| 14:12 | heap_ | jnettlet: i can mount btrfs in 3.x and run badblocks and it survives. |
| 14:13 | heap_ | if i do same use-case with 4.x it crashes |
| 14:13 | heap_ | there is no activity on btrfs volume, only badblocks is running |
| 14:14 | jnettlet | it seems like running badblocks on a COW filesystem is a bad idea |
| 14:16 | bencoh | ? |
| 14:16 | bencoh | ah |
| 14:18 | heap_ | jnettlet: why? |
| 14:18 | heap_ | jnettlet: i run it in r/w mode |
| 14:18 | heap_ | so everything is rewritten |
| 14:20 | jnettlet | don't they have a specific btrfs utility to do this...something like btrfs scrub |
| 14:21 | heap_ | i though doesnt matter what do oyu use in write mode |
| 14:21 | heap_ | all is rewritten |
| 14:21 | heap_ | all data |
| 14:22 | heap_ | so i dont think the fs type matters at all |
| 14:22 | jnettlet | it is but it will be less optimal because you are going through block by block, not file by file |
| 14:22 | heap_ | i want to go block by block |
| 14:22 | jnettlet | again I don't know specifics on btrfs only read random articles here and there |
| 14:23 | heap_ | im testing/warmming up drive |
| 14:23 | heap_ | and during that cuboxi dies since time to time |
| 14:23 | heap_ | also last time i got badblock as part of the compare operation ... so probably issue with RAM? |
| 14:24 | heap_ | it compares written/read data... in second run all was ok |
| 14:25 | jnettlet | if mk001, hasn't had any other reports similar for his kernel, then we would need to look at what is different. Could very well be a bug in btrfs |
| 14:26 | heap_ | ;-/ |
| 14:26 | jnettlet | http://www.spinics.net/lists/linux-btrfs/msg45211.html |
| 14:26 | jnettlet | make sure you are up to date |
| 14:26 | jnettlet | could be something else though |
| 14:27 | heap_ | but its dedup not btrfs |
| 14:27 | heap_ | i dont know |
| 14:31 | jnettlet | An ioctl dedicated to batch deduplication was merged in Linux 3.12. It brings in-kernel locking (btrfs guarantees that the deduplicated data is identical without the need for outside locks), better support for read-only snapshots, and retains the features and much of the implementation of the clone ioctl. There is an experimental bedup branch using the new ioctl, but it is not the default because it can trigger kernel crashes as of Linux 4.2. |
| 16:33 | topi` | jnettlet: would you recommend me (regarding testing the mikrobus uarts) grabbing a newer SR image? |
| 16:34 | topi` | I'm running one from November |
| 16:34 | topi` | I guess it's the kernel and the .dts which ultimately decide what and how the HW works? |
| 17:10 | jnettlet | topi`, are you using a 5v or 3.3v rs485 module? |
| 17:10 | jnettlet | or the big board? |
| 17:29 | topi` | I haven't tried out the rs485 module yet, since I have nothing to talk to :) but I tried to hook up a 3.3V uart to that mikrobus connector |
| 17:29 | topi` | and see if something comes to minicom's screen |
| 17:37 | jnettlet | and you ran agetty on /dev/ttymxc3? |
| 18:29 | topi` | jnettlet: yeah, and got nothing. actually agetty times out. |
| 18:29 | topi` | did you give special arguments to agetty? I just tried it with "agetty /dev/ttymxc3 115200" |
| 20:21 | jnettlet | topi`, I feel stupid. I mixed up the info I was giving you with another customer using the onboard rs485 |
| 20:21 | jnettlet | the linux device numbers are all uart - 1, so the mikrobus is actually /dev/ttymxc2 |