| 06:07 | dab_ | jnettlet: Rabeeh has now received my misbehaving router |
| 06:26 | jnettlet | dab_, oh great to know. I hope to figure out some sort of workaround for this issue |
| 06:49 | Juggie | whats the issue? |
| 06:51 | jnettlet | flow control on the gigabit port is not detected properly so performance is garbage. |
| 06:52 | dab_ | jnettlet: I figure rabeeh can at least now see the problem |
| 06:52 | Juggie | this is common to just one perticular router/switch |
| 06:52 | jnettlet | well we know what the problem is. we just don't know why it is happening |
| 06:52 | Juggie | or all gbit switches |
| 06:52 | jnettlet | just some of them |
| 06:53 | Juggie | only routers, or actual dumb switches as well |
| 06:53 | jnettlet | the problem is that some switches aren't negotiating gigabit flow control properly |
| 06:53 | Juggie | i understand that. |
| 06:53 | jnettlet | the switch ports in routers are generally similar devices. but it seems to be a problem with certain chipsets |
| 06:54 | Juggie | i was asking if it was the built in switch on some routers only, or if some plain jane switches were also affected. |
| 06:54 | dab_ | plain switches too |
| 06:54 | Juggie | k.. interesting. |
| 06:54 | jnettlet | the underlying problem is that on the iMX6 you have to have flow control to support gigabit speeds because the bus speed is not as fast as the line speed. |
| 06:55 | jnettlet | which reminds me, I was going to talk to rmk about disabling gigabit speeds if the flow control negotiation fails |
| 06:55 | dab_ | jn, any advance on slow UDP? |
| 06:56 | jnettlet | dab_, nothing yet. That is the same problem. |
| 06:56 | Juggie | im not sure why gbit is even relevant |
| 06:56 | Juggie | for this device |
| 06:57 | jnettlet | the switch tries to ram udp at line level, or a little slower and it fills the buffer, but because it is udp the host needs to figure that it needs to send more packets much later. |
| 06:57 | jnettlet | at this point the game is over and we are dropping 50% of the packets and the retransmissions kill the overall rate |
| 06:57 | Juggie | udp doesnt make a habbit of waiting usually :) |
| 06:58 | jnettlet | Juggie, that is what the gigabit flow control does. It happens below the IP level. |
| 06:58 | jnettlet | but even then the performance isn't as fast as it should be. |
| 07:00 | jnettlet | Juggie, greater than 100Mbps is relevant for file-sharing, using it as a NAS, or streaming/decoding files to multiple clients. |
| 07:01 | dab_ | the old cubox with marvell mv ethernet was/is very good. gigabit makes thin clients viable |
| 07:02 | Juggie | wonder if you'd get better performance out of a usb-ethernet |
| 07:04 | jnettlet | dab_, yes but the Dove chip was designed for that sort of application. |
| 07:04 | jnettlet | the MX6 was designed for automotive applications in mind |
| 07:05 | jnettlet | not much gigabit there :-) |
| 07:06 | Juggie | whos the ethernet controller, part of freescale or something else? |
| 07:06 | jnettlet | it is an atheros phy, but fsl controller |
| 07:06 | jnettlet | the problem isn't the ethernet controller but the bus it uses to connect to the SOC |
| 07:10 | Juggie | fixable in fw/software hopefully |
| 07:15 | jnettlet | it works fine when flow control gets negotiated properly, which is most routers. It just seems to be a particular chipset or two that it has a problem with |
| 07:16 | dab_ | jnettlet: I have the udp hassle on everything. e.g. i4pro direct to old cubox |
| 07:17 | dab_ | I just realized why excuse me |
| 07:18 | jnettlet | dab_, yes. That is because of the problem I described above. By the time flow control can cut things off it is already too late because the host has already dumped as many packets as there are buffers along the way. |
| 07:19 | jnettlet | and then it is just a packet loss nightmare because the host has to figure out what is missing and retransmit and hope it doesn't get dropped again. |
| 07:19 | jnettlet | this should just be on receiving packets. transmitting shouldn't be a problem. |
| 07:24 | Juggie | i don't see this being a regular switch related problem |
| 07:25 | Juggie | its going to cause buffering issues end to end |
| 07:25 | Juggie | a dumb switch certainly cant buffer, it can only pass along the flow control request |
| 07:28 | Juggie | so in a local lan, i'm willing to bet the problem lies with the device sending the data |
| 07:28 | Juggie | as opposed to the router, that is unless of course your internet connection is >200mbit |
| 07:29 | Juggie | as well, when you use a router as your local switch, the packets never enter ram/soc, they stay on the ethernet controller |
| 07:30 | Juggie | assuming your typical home router, and no vlans setup |
| 08:27 | Guest54900 | mk01 : is the xbian image for cubox-i based on 3.10 kernel ? |
| 08:33 | Guest54900 | mk01_ : is the xbian image for cubox-i based on 3.10 kernel ? |
| 09:56 | smark_ | Has anyone tried the new XBian image? |
| 12:06 | mk01_ | Guest54900: yes |
| 12:10 | mk01_ | smark_what problem you have ? |
| 13:13 | smark_ | mk01: I've reported one problem on the forum: http://imx.solid-run.com/forums/viewtopic.php?f=7&t=1127#p8415 |
| 13:14 | smark_ | Another, more serious problem is that I can't even tell if the Cubox-i boots successfully with the XBian image... |
| 13:15 | smark_ | ...because it doesn't seem to be requesting an IP address via DHCP, and it doesn't show up on the network (wired) with an ARP scan. |
| 13:16 | smark_ | However, given that I can't even mount the second partition on a PC, I wonder if the image is not corrupt in some way. |
| 13:18 | mk01_ | what kernel you have on PC ? |
| 13:18 | smark_ | 3.13.0-24-generic #47-Ubuntu SMP |
| 13:18 | smark_ | (Kubuntu Trusty) |
| 13:19 | mk01_ | smark_: with tiny metadata support and lz4 ? |
| 13:19 | smark_ | MD5sum of xbian-20140515.img.7z is 7bb111a34efb1f3ecdbeb1a6bd5bf6e8 |
| 13:19 | smark_ | mk01: it's the stock Ubuntu kernel. How can I tell if it supports those features? |
| 13:20 | mk01_ | 7bb111a34efb1f3ecdbeb1a6bd5bf6e8 xbian-20140515.img.7z |
| 13:21 | smark_ | Okay, the MD5SUM checks out. |
| 13:21 | smark_ | Problem must be elsewhere... |
| 13:21 | smark_ | My Cubox-i is version 2ultra, though I doubt that is the issue... |
| 13:22 | smark_ | Question: does XBian enable DHCP by default? |
| 13:22 | mk01_ | I can rebuild img with ext4, that's not a technical issue. but it was never requested to have it like this accessible on other machines |
| 13:22 | mk01_ | yes, there is eth0 configured as auto dhcp |
| 13:23 | smark_ | Being accessible on other machines is not strictly required. It's just a sanity check I like to run to make sure the image is OK. |
| 13:23 | mk01_ | you don't have screen at all ? |
| 13:23 | smark_ | I haven't checked with a screen. |
| 13:24 | smark_ | Steps I performed: |
| 13:24 | mk01_ | there was/is an issue with latest u-boot |
| 13:24 | mk01_ | that if eth0 is being configured early |
| 13:24 | mk01_ | dhcp is failing |
| 13:25 | smark_ | Okay: that might be the issue. |
| 13:25 | smark_ | Is there a fix? |
| 13:25 | mk01_ | exactly the img you have was build with removed "hack" - sleep of 10s for eth0 |
| 13:25 | mk01_ | as for test cases it looked fine. obviously not for everyone |
| 13:26 | mk01_ | but |
| 13:26 | smark_ | mk01: I'll get the Cubox-i and try again. I'll report soon... (thanks for your help, btw!) |
| 13:27 | mk01_ | give me 2m |
| 13:28 | mk01_ | edit kernel command line |
| 13:28 | mk01_ | boot.scr.txt file on P1 |
| 13:29 | mk01_ | putting "ip=192.168.1.12::192.168.1.1:255.255.255.0::eth0:" into 3rd line |
| 13:29 | mk01_ | (change the IPs accordingly |
| 13:29 | mk01_ | run "./mks" on the same partition |
| 13:30 | mk01_ | this will update boot script from txt form to u-boot mkimage |
| 13:30 | mk01_ | and try booting |
| 13:30 | smark_ | I'm reflashing first: dd bs=4k conv=fsync if=xbian-20140515.img of=/dev/sdf |
| 13:30 | smark_ | (...waiting for reflash to finish...) |
| 13:30 | mk01_ | also |
| 13:31 | mk01_ | without screen you can recognize XBian booting ok |
| 13:31 | mk01_ | that LED firstly is just ON |
| 13:31 | mk01_ | then on 13-20s of boot it should FLASH |
| 13:31 | mk01_ | that's when networking is configured |
| 13:32 | mk01_ | also first boot can take longer |
| 13:32 | mk01_ | as partitions are resized |
| 13:32 | mk01_ | swap partitoin created and swap prepared |
| 13:32 | mk01_ | also after you get network, ssh server will re-generate all KEYS |
| 13:33 | mk01_ | and depending on available random content on random generators this can take even minutes ! |
| 13:33 | mk01_ | normally it is all shown on screen with progress bars |
| 13:34 | mk01_ | smark: just still as you have card in linux, update the boot.scr |
| 13:34 | mk01_ | just to be sure |
| 13:35 | mk01_ | you don;t have to do it tqwice |
| 13:35 | smark_ | mk01: Okay, reflashing is complete. Before I change boot.scr.txt, I'm first trying to boot the Cubox-i with the unmodified XBian image... |
| 13:36 | smark_ | I am now running "arp-scan -l" (as root) every 10 seconds... So far no signs of life from Cubox-i... |
| 13:38 | mk01_ | and the LED ? |
| 13:38 | smark_ | The LED has stayed bright red from the beginning... |
| 13:39 | smark_ | I didn't see it blink (though it may have done so while I was busy typing) |
| 13:39 | smark_ | Still no signs of life from ARP scan, btw... |
| 13:39 | smark_ | Should I try plugging it into a TV, or should i try your modifications to boot.scr.txt first? |
| 13:40 | mk01_ | smark_: kernel should be able to configure DHCP in cca 10s after start |
| 13:40 | mk01_ | according my tests |
| 13:41 | mk01_ | athough it is a while back when i have seen clean img deployement |
| 13:41 | smark_ | Is it the same kernel as the other distros? I've tried OpenElec, Geexbox, and Archlinux, and they all successfully made a DHCP request. |
| 13:42 | mk01_ | 3.10.30 tag is the same |
| 13:42 | mk01_ | differences should not be big |
| 13:42 | smark_ | Still no sings of life from ARP scan, btw. I think I'll try plugging it into a TV and see what shows up on screen. |
| 13:42 | mk01_ | but great deal of difference can make SPL / u-boot |
| 13:44 | mk01_ | smark_: And maybe you will find that the last IMG ius broken |
| 13:44 | mk01_ | the one generated week ago was FINE though |
| 13:45 | mk01_ | will test later |
| 13:45 | smark_ | mk01: I've tried booting again after connecting to TV |
| 13:46 | smark_ | I cannot see the bottom part due to overscan, but it seems XBian entered a "Recovery boot console" |
| 13:46 | smark_ | Is this normal? |
| 13:46 | mk01_ | NOPE |
| 13:46 | mk01_ | if you put the IP configuration as param |
| 13:47 | smark_ | Should I try the old image and do an "apt-get upgrade"? |
| 13:47 | mk01_ | and "rescue" as anotjer param |
| 13:47 | mk01_ | you could TELNET into the recovery console |
| 13:47 | mk01_ | smark_: yes, you will get the same image |
| 13:48 | smark_ | Then perhaps I should try the old image first. If it works fine, then we know there's a problem somewhere in new image. OK? |
| 13:49 | mk01_ | I will test it within an hour |
| 13:49 | smark_ | Is this the previosu image: http://cubox-i.cf/files/xbian-20140315-cuboxi.img.xz |
| 13:50 | mk01_ | yes |
| 13:50 | mk01_ | or |
| 13:50 | smark_ | File not available! |
| 13:51 | smark_ | Moved location? |
| 13:52 | mk01_ | http://xbian.brantje.com/others/cubox-25-mar-2014.img.xz |
| 13:53 | smark_ | Thanks! Downloading as we speak... Will report back in an hour so... :-) |
| 13:54 | mk01_ | ok |
| 15:03 | smark_ | mk01: cubox-25-mar-2014.img boots successfully! Upon first sshing (user: xbian, pass: raspberry) I am presented with a config application! |
| 15:03 | smark_ | It seems there is indeed something fishy going on with the latest image... |
| 15:04 | mk01_ | OK will sure check that |
| 15:04 | mk01_ | can you just simply post this fact to forum ? I will corrrect today |
| 15:06 | smark_ | OK! |
| 15:07 | mk01_ | thx |
| 15:14 | smark_ | Question: is XBian configured out-of-the-box (repos, etc) such that a "apt-get update & dist-upgrade" will bring it up-to-date, including kernel, boot, etc? |
| 15:14 | mk01_ | yes |
| 15:16 | smark_ | OK. apt-get update hist the http://xbian.brantje.com and http://ftp.sk.debian.org repos. Better change that last one for something closer to me... |
| 15:16 | mk01_ | feel free |
| 15:17 | smark_ | apt-get dist-upgrade needs to get 155MB of archives (!). My connection is a bit slow. This may take a while. Will report later... |
| 15:17 | mk01_ | Debian had DNS issues once and that one was working on old records. and stayed inside sources list |
| 15:18 | mk01_ | as jessie is still devel release - they are like crazy |
| 15:19 | mk01_ | daily huge updates to almost same packages |
| 15:19 | smark_ | Something funny: it seems the root paritition was automatically resised to occupy all 8GB of microSD... |
| 15:19 | mk01_ | you maybe get better updating only xbian* packages |
| 15:19 | mk01_ | otherwise you end up with 50-100mb daily |
| 15:20 | mk01_ | smark: autoresize on first boot is default with XBian for months |
| 15:21 | mk01_ | you can disable this by putting "noresizesd" to kernel command line |
| 15:21 | smark_ | Yeah, I'll only update everything today to get the latest kernal+XBMC. Afterwards I'll only update xbian* packages every now and then and others much less frequently. |
| 15:21 | mk01_ | for you convinience |
| 15:21 | smark_ | The auto-resize was not a problem: just a nice surprise! |
| 15:21 | smark_ | Thank you! |
| 15:22 | mk01_ | just run xbian-config, then menu 5 and 3 and you arwe presented with table with updates available where yoiu just "mark" the one you want |
| 15:23 | smark_ | I think the Cubox-i forum thread will be a good place for you to post updates concerning new kernel versions. |
| 15:23 | mk01_ | smark: XBian is updating APT repo inventories automatically |
| 15:23 | smark_ | Every now and then users can check that thread to see if they should upgrade because the newer kernel is so much better and/or fixes some bugs. |
| 15:23 | mk01_ | and in case of xbian* available |
| 15:23 | mk01_ | you will be informed in XBMC about that |
| 15:25 | mk01_ | but yes, when I consider some updates as needed or nice to have I'm dropping a line into forum |
| 15:25 | smark_ | Yes, but I usually disable APT auto-updating to avoid surprises... |
| 15:25 | smark_ | Particularly on debian testing |
| 15:26 | smark_ | Thanks! |
| 15:26 | smark_ | Question: is XBian kernel more-or-less the same as Arch/Geexbox/Openelec? |
| 15:27 | mk01_ | yes. but as I;'m developing some parts of it myself, can be it's different (or ahead) sometimes |
| 15:27 | mk01_ | but generaly speaking yes, the same |
| 15:57 | smark_ | [XBian] something weird reported by dmesg: "systemd-udevd[1033]: renamed network interface wlan0 to wlan2". Why did it do this? |
| 16:08 | smark_ | [XBian] apt-get dist-upgrade reported an error: |
| 16:08 | smark_ | Setting up util-linux (2.20.1-5.7) ... update-rc.d: error: unable to read /etc/init.d/hwclock.sh dpkg: error processing package util-linux (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: util-linux E: Sub-process /usr/bin/dpkg returned an error code (1) |
| 16:10 | smark_ | Workaround: touch /etc/init.d/hwclock.sh && chmod +x /etc/init.d/hwclock.sh && apt-get -f install |
| 16:13 | mk01_ | smark_: yes, use workaround . to get latest xbian-update installed. it is fixing Debians broken upstart_job and update-rc.d scripts so it should not appear again on not properly written dpkg scripts in debs |
| 16:14 | mk01_ | this happens now and then . even on plain Jessie :-/ |
| 16:15 | smark_ | Alright... |
| 16:15 | smark_ | Do you have any idea why udev renamed wlan0 to wlan2? |
| 16:15 | mk01_ | nope |
| 16:15 | mk01_ | oh maybe yes |
| 16:16 | mk01_ | check /etc/udev/rules.d/70-persistent-net.rules |
| 16:16 | smark_ | Yes, I've checked it... |
| 16:16 | mk01_ | proably wlan0 assigned to different MAC address already |
| 16:16 | mk01_ | rename there or rm the file completeluy |
| 16:17 | smark_ | Funny, /etc/udev/rules.d/70-persistent-net.rules reports that wlan0 and wlan1 are assigned to other MAc addresses |
| 16:25 | smark_ | Anyway, after deleting /etc/udev/rules.d/70-persistent-net.rules and rebooting, wifi now uses wlan0... :-) |
| 18:03 | vivek_ | How to enable external cd drive support on Cubox-i ? |
| 18:03 | vivek_ | I am using Debian Jessie 3.0.35 |