**** BEGIN LOGGING AT Wed Jun 06 03:00:11 2018 Jun 06 03:25:42 well. after 10 years of thinking about it, i finally have a little homemade embedded synth runnign linux. beaglebone green, usb audio interface, jackd, usb midi keyboard. Jun 06 03:26:34 sorry, beaglebone green wifi (has faster cpu). just some basic synth stuff uses about 8% CPU for jackd, and a simple soundfont-based sampler is about 10-15% CPU when played Jun 06 04:18:41 ehm, all beaglebone variants have exactly the same cpu Jun 06 04:19:23 (except for the old beaglebone white, which has an older revision SoC) Jun 06 09:29:36 Hi, is it correct eth0 stays up when cable is disconnected ? Jun 06 09:30:21 not really no, depending on what you mean by "up" Jun 06 09:30:45 it remains administratively up but not operationally up Jun 06 09:31:48 kenrestivo: other than that, neat! Jun 06 09:31:56 I'd expect that e.g. output of "ip addr" would show "state DOWN" for the interface Jun 06 09:32:23 kenrestivo: also, 47400000.dma-controller is the dma controller, so you're probably seeing continuous interrupts due to an audio stream? Jun 06 09:33:18 tbr: yup Jun 06 09:33:32 fred__tv: "eth0: ... state DOWN" something like that Jun 06 09:33:43 I have wlan0 and eth0 on different subnets but connected to same router , when I issue "ifconfig eth0 down" I can reach devices on eth0 subnet via wifi->router Jun 06 09:34:35 yep, that's why a router is called a router Jun 06 09:34:45 it routes Jun 06 09:34:46 If I simply disconnect ethernet cable, beagle still try to reach eth0 subnet devices with no luck as eth0 is still up in ifconfig Jun 06 09:35:09 then your network manager is just garbage Jun 06 09:35:37 plain rcn stretch console... Jun 06 09:35:44 that's not a network manager Jun 06 09:35:57 and that probably means you're using ifupdown, which is indeed garbage Jun 06 09:41:29 in the sort of situation you're describing: a more complicated routing setup *and* good behaviour under interfaces going dynamically up an down, I'd strongly suggest trying systemd-networkd Jun 06 09:42:00 in my experience it works quite well Jun 06 09:42:55 I do recommend using systemd 237 or later (i.e. buster or stretch-backports) Jun 06 09:43:17 the old 232 of stretch still had some bugs I ran into Jun 06 09:52:08 Doing so I would do something unknown to me (with risks/failure likely...) Jun 06 09:52:34 yep, expect some learning process as you get acquainted with it Jun 06 09:53:16 as per ifconfig: eth0: flags=4099 mtu 1500 with cable disconnected !!! :-((( Jun 06 09:53:33 yes, that's administratively up Jun 06 09:54:00 if that said "DOWN" then it wouldn't even care whether the cable is plugged in or not Jun 06 09:57:08 but , only a network manager has be used to follow the cable state ?? Jun 06 09:57:27 administrative state doesn't follow the cable state, operational state does Jun 06 09:57:33 check what ip link says Jun 06 09:57:49 (ifconfig is an obsolete utility and I'm not familiar with its exact output) Jun 06 09:59:06 2: eth0: mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 Jun 06 09:59:19 yep, that's exactly what I expect Jun 06 09:59:37 that's the expected state when the cable is unplugged Jun 06 10:00:38 yes, but route to its subnet is still there , causing packets to be lost Jun 06 10:01:33 setting administratively down, route is deleted and routing is through wlan0 Jun 06 10:03:28 yep, key phrase being "route is deleted" Jun 06 10:03:57 the fact that this isn't happening when ethernet is unplugged is your network manager's responsibility Jun 06 10:04:09 systemd-networkd does remove routes under those circumstances Jun 06 10:04:58 ifupdown just isn't great at handling dynamic network situations Jun 06 10:05:02 I even doubt a network manager is installed so... Jun 06 10:05:18 you have a network manager installed, otherwise you have no network Jun 06 10:05:31 there's nowhere to configure any network settings without one Jun 06 10:06:05 it may be a stupid network manager like ifupdown, but it's still a network manager Jun 06 10:06:29 ah ok Jun 06 10:10:10 anyway , it is stupid to keep route on when cable is disconnected Jun 06 10:10:22 so, yes, probably garbage.... Jun 06 10:11:19 well that's what you get when you network manager is basically just a pile of shell scripts Jun 06 10:11:22 *your Jun 06 10:11:57 (okay I don't know if it actually is, but it sure *felt* like it was back when I used it) Jun 06 10:14:24 I thouhgt allow-hotplug in /etc/network/interfaces was doing the trick , but it follows the hardware state , not the cable.... Jun 06 10:15:23 :) Jun 06 10:16:20 I really think you should consider ditching ifupdown instead of trying to fight it and attempting to coerce it into behaving sanely Jun 06 10:18:00 Well....this beagle has to be used wireless only.... it was just to have it back to be managed quickly if wireless is lost.... Jun 06 10:18:27 dynamic setups is where ifupdown sucks the hardest Jun 06 10:19:07 basically it was designed to bring the network up at boot and that's it... it's been stretched beyond that over time, but it is very clear that it's being stretched Jun 06 10:19:57 :-) Jun 06 10:20:03 lunch time ! Jun 06 10:20:11 see you, thanks Jun 06 11:43:40 zmatt: uhmm.. not deconfiguring your NIC because someone tripped over the cable is actually the sane thing to do ;) Jun 06 11:54:17 KotH: well there's no harm in doing so, and I'd say routing around the problem (if possible) until the cable is plugged back in is the saner thing to do Jun 06 11:57:40 and if you really do need it, you can set ConfigureWithoutCarrier=true Jun 06 11:58:10 but I think the default behaviour is the Right Thing in most cases Jun 06 12:11:50 plus, having automatic failover to wifi is essential to be able to have the system automatically send the killdrones after whoever tripped over the cable Jun 06 12:18:32 zmatt: do you remember I told you yesterday wpa_supplicant doesn't start automatically despite wifi adapter is plugged in ? Jun 06 12:19:49 Well, I have it running ok ONLY IF I comment the eth0 "gateway" line on /etc/network/interfaces Jun 06 12:20:51 why is this ? Jun 06 12:22:03 https://pastebin.com/gYZmArx8 Jun 06 12:23:44 fred__tv: I haven't used ifupdown in ages and don't pretend to know anything about its eccentricities Jun 06 12:23:56 :) Jun 06 12:24:10 the only thing I do with ifupdown on systems I manage is "apt-get purge" Jun 06 12:24:20 :-)))) Jun 06 12:25:20 and actually, back when I *did* use it, the mysery of trying to use it with wifi was a main motivation to switch to systemd-networkd Jun 06 12:26:43 wait , interface wlan0 is up anyway, is wpa_supplicant istance that doesn't start , unless gateway is removed from wired lan interface.... Jun 06 12:28:18 however, as I need wireless only , is not a problem to configure the only wlan0 interface.. Jun 06 12:28:27 try sacrificing a black chicken, maybe it helps Jun 06 12:54:57 zmatt: actually there is: an open connection is bound to an ip, if that ip is lost due to the nic being deconfigured, the kernel cuts that connection. so unless you have the ip configured on multiple nic's your connection is going to be lost Jun 06 13:10:41 uhh, no it doesn't Jun 06 13:10:45 kernel doesn't cut connections Jun 06 13:10:51 not even if dhcp is used Jun 06 13:11:23 as long as you reacquire the same ip you had before, open connections will recover (or not even notice, depending on how long the "outage" was) Jun 06 13:14:12 (just tested it to be sure: ssh -4 connection remains open after unplugging and replugging beaglebone) Jun 06 17:30:28 afternoon Jun 06 18:19:05 does linux ever spontaneously reboot? I'm looking at syslog and am seeing a reboot without any indication of a shutdown I think. Jun 06 18:19:35 it happened around the time when I noticed (through remote monitoring of an internet connection to the device) that it went offline then Jun 06 18:19:57 I don't see any indication that something was wrong in the log just that it suddenly restarted Jun 06 18:46:00 is there an "official" kernel for the beaglebone wireless? Jun 06 18:46:24 i cannot find a device tree in the kernel sources that i usually use (from buildroot) Jun 06 18:49:04 sgflt /opt/source/dtb-4.9-ti/src/arm/ ? Jun 06 18:49:38 and, https://github.com/RobertCNelson/dtb-rebuilder/tree/4.4-ti/src/arm Jun 06 18:50:02 note the correct branch to use there for your kernel version Jun 06 18:50:19 in my csae it's https://github.com/RobertCNelson/dtb-rebuilder/tree/4.9-ti/src/arm Jun 06 18:50:27 windsurf_: is that based on the f9f6f0db2d5e4f9d2ff46eb31a5a05276a92ed7d kernel? Jun 06 18:51:07 sorry, out of my depth now. I was guided to that spot by someone else when I needed to fix something for pocketbeagle Jun 06 18:51:36 alright, i'll compile the image and see if i can get a version info from it Jun 06 19:07:22 windsurf_: kernel panics may cause a reboot depending on how the kernel is configured. severe crashes in general can also trigger reboot if the watchdog is enabled Jun 06 19:08:47 sgflt: rcn maintains the official beaglebone kernels, both the -bone series (mainline + patches) and -ti series (TI kernel + patches) Jun 06 19:09:48 sgflt: the build repo for the -bone kernels (containing patches, config, and build scripts) is https://github.com/RobertCNelson/bb-kernel (pick branch corresponding to desired kernel series) Jun 06 19:10:01 the equivalent for the -ti series is https://github.com/RobertCNelson/ti-linux-kernel-dev Jun 06 19:10:20 you can also find snapshots of the patched kernel trees here: https://github.com/RobertCNelson/linux-stable-rcn-ee/releases Jun 06 19:14:01 sgflt: and like windsurf_ pointed out, there's also the dtb-rebuilder repository containing just the dtbs (with a branch per kernel series) Jun 06 19:14:16 *dts Jun 06 19:15:18 zmatt looks like my device rebooted a couple times but how can I tell if there was a panic / severe crash? Do I need to enable something to get a longer history for dmesg? Jun 06 19:15:47 dmesg is from the running system Jun 06 19:16:23 remote logging or something *might* catch various forms of crashes ... or logging to serial Jun 06 19:17:18 when a panic / severe crash occurs there's no way to log that information to eMMC or SD anymore. monitor the serial console instead Jun 06 19:18:01 (in theory crashes could be logged using kdump, but I've never tried to use kexec on a beaglebone let alone kdump) Jun 06 19:23:35 zmatt OK. these are out in the field when this happens... do you think radio interference (which we've already had trouble with for some GPIO pins) could cause a reboot? Jun 06 19:24:41 anything is possible Jun 06 19:25:45 it doesn't sound likely, but I don't know what sort of environment you're exposing your devices to, or whether you opted to attach a long wire to the reset line to act as antenna ;P Jun 06 19:26:38 (reset has a silly amount of capacitance though, so even with antenna it doesn't sound likely) Jun 06 19:34:04 the kernel i am using (4.4.41) is not listed at https://github.com/RobertCNelson/dtb-rebuilder/ -- any advice? Jun 06 19:34:42 mainline you mean? Jun 06 19:35:31 zmatt: well there's no tag with that specific version. i'm trying to figure out whether it is easier to add a missing dtc file or switch to a more common kernel version Jun 06 19:36:08 dtbs are not hugely kernel-version-specific Jun 06 19:36:17 zmatt: i have a kernel that someone pinned for the beaglebone in buildroot 2018.02 and i can't figure out why the picked that specific version - it is based off a dead-end branch (4.4.41) with 20 or so patches added over the course of two years Jun 06 19:36:34 yeah I wouldn't want to use that personally Jun 06 19:36:37 yeah, i'm guessing it is easiest to switch to a kernel that has the correct device tree already inside the kernel sources Jun 06 19:37:02 zmatt: "that" == that specific kernel version? or buildroot in general? =) Jun 06 19:37:41 an ancient patchlevel of an already old kernel Jun 06 19:38:00 no experience with buildroot Jun 06 19:38:18 i agree. my current approach now is downloading the latest debian image from the debian homepage, checking which kernel is used there, find the sources and throwing that into buildroot Jun 06 19:38:46 I use 4.14-bone series Jun 06 19:38:54 (with some custom patches and custom config) Jun 06 19:39:09 will it work out of the box? Jun 06 19:39:20 "it" ? Jun 06 19:39:28 the kernel Jun 06 19:39:36 I have no idea what you mean by that Jun 06 19:39:49 sorry, i meant, could i use that without your patches just fine? Jun 06 19:40:16 uhh obviously? I just mean I build it with some custom patches for our own purposes Jun 06 19:40:30 i see. any reason you are not using the -rt version? Jun 06 19:40:37 any reason I would be? Jun 06 19:40:50 -rt kernels are generally not a good thing unless you specifically need one Jun 06 19:41:08 well, i'm polling sensors and want very little jitter, i am guessing that qualifies? Jun 06 19:42:14 if merely giving your process realtime scheduling on a non-rt kernel still results in too much jitter you might try an -rt kernel to see if it helps Jun 06 19:43:39 zmatt: one thing i have been running into was large io pauses, writing log files to sd card. i saw a 60 ms write pause once =/ Jun 06 19:43:43 getting the most out of an -rt kernel might require carefully analyzing the situation and assigning appropriate priorities to elevate the kernel threads that matter for your application above those causing too much jitter Jun 06 19:44:25 this was pausing your sensor-polling thread and not just those thread(s) doing disk i/p ? Jun 06 19:44:29 *i/o Jun 06 19:44:46 did your sensor-polling thread have realtime scheduling? (SCHED_FIFO) Jun 06 19:44:48 in that case, it was pausing a controller thread that wrote packets on the bus Jun 06 19:45:03 i believe it did not, i will check again later =) Jun 06 19:45:53 also be careful to avoid accidently creating interlocks (e.g. mutexes) shared between non-rt threads (e.g. those doing emmc access or other slow i/o) from those needing low jitter Jun 06 19:46:28 use e.g. a ringbuffer to decouple them Jun 06 19:47:14 brb Jun 06 19:47:19 i hope i did okay there. well, at the very least i will ahve to get this dtb going. Jun 06 19:47:21 zmatt: thanks! Jun 06 20:10:14 (Beaglebone Blue) Hello, I am having an issue with the PRU on a beaglebone blue. Before I RMA the card I wanted to check here if maybe it was a software issue. Anyone can help ? Jun 06 20:11:45 well obviously noone can help you unless you explain what issue you're having, but it seems extremely unlikely that a hardware issue would affect just the PRU Jun 06 20:17:22 Hi zmatt, just wanted to check someone was there before I started to describe the problem. Here is the issue I am facing. When running ardupilot or the rc_test_servos the program fails with the following error in dmesg Jun 06 20:17:37 Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6fa7000 Jun 06 20:18:34 yeah that's just a software issue. the ardupilot code is assuming certain firmware is running on the pru cores but doesn't check this, and simply crashes if nothing is running on pru Jun 06 20:19:55 it also accesses pru in an unsafe way which doesn't ensure the pru subsystem is even enabled at all, which is why an external abort is caused Jun 06 20:20:10 just badly written software Jun 06 20:20:35 ok, the rc_test_servos from the robotics cape has the same issue Jun 06 20:21:15 that's possible. I don't have a blue nor any experience with the robotics stuff, so I have no idea what is normally supposed to be responsible for loading that firmware onto pruss or why this might not be happening Jun 06 20:22:35 generic things you can try is making sure you're running the latest image and have the latest robotics cape software Jun 06 20:23:38 ok, is the firmware running on the pru something that’s needs to be loaded at each boot or is it saved on a non volatile memory ? Jun 06 20:23:58 it is loaded either at boot or by the software that interacts with pruss Jun 06 20:25:21 ok so it might be a more complicated issue. I have another blue and if I boot it with the same SD card both aredupilot and the robotics test runs fine Jun 06 20:25:32 oh you're booting from sd card? Jun 06 20:25:37 yes Jun 06 20:25:50 try wiping eMMC using sudo blkdiscard /dev/mmcblk1 Jun 06 20:26:00 an old bootloader on eMMC can cause problems Jun 06 20:26:09 ah ah let me try Jun 06 20:27:46 zmatt Many Thanks !!! Jun 06 20:27:55 works now Jun 06 20:28:45 :) Jun 06 20:47:07 zmatt thanks re: reboot issues earlier. Jun 06 21:45:41 i couldn't compile the kernel tagged 4.14 on the beagleboard kernel repo, because an include was missing, causing a missing declaration, which was a warning turned into an error. adding the missing include fixed it - did anyone else run into that? Jun 06 22:00:59 sounds very weird, since those are snapshot of the trees from which actual kernels were built Jun 06 22:01:19 can you pastebin the exact error you were getting? Jun 06 22:09:56 I'm IT Manager for Hydropoint Data Systems, we had one of the Beagle Boards take over our Windows DNS. Dev assigned an in-use IP on our network. Do those boards run BIND or DNS ? Jun 06 22:10:23 uhh what? Jun 06 22:10:48 they might run dnsmasq, but that shouldn't normally ever affect any network Jun 06 22:10:52 does the beagle board run bind or dns server Jun 06 22:11:53 I don't see how a dns server would be a problem since noone should be performing dns queries to the beaglebone in the first place Jun 06 22:12:50 how would a beaglebone "take over" your dns? Jun 06 22:14:01 unless you mean someone assigned a static ip to a beaglebone that was equal to the ip of your dns server, in which case the problem is that static ip assignment Jun 06 22:14:24 (there's rarely if ever a good reason for static ip assignment anyway) Jun 06 22:30:56 zmatt: i'll try, if it pops up again (due to me mishandling the patch). adding an `#include ` to `of.h` did fix it though **** ENDING LOGGING AT Thu Jun 07 03:00:04 2018