**** BEGIN LOGGING AT Tue Sep 09 02:59:59 2014 **** ENDING LOGGING AT Tue Sep 09 18:02:05 2014 **** BEGIN LOGGING AT Tue Sep 09 18:04:19 2014 Sep 09 18:29:43 I'm trying to get perf counters to work with perf on my pandaboard. it looks like they're disabled on the 3.2.0-1452-omap4 kernel that I have. Sep 09 18:30:14 does anyone know if 14.04's kernel has working perf counters on the pandaboard? Sep 09 18:42:56 ok, new question Sep 09 18:43:02 why is the interrupt-based perf drunk? Sep 09 20:43:14 mjrosenb: 14.04's generic kernel should perforate fine. Sep 09 20:57:28 well, a-upgrading I a-go! Sep 09 21:20:31 infinity: do you happen to know the state of softfp support on 14.04? Sep 09 21:21:53 mjrosenb: Nonexistent, outside a biarch gcc/libc. Sep 09 21:22:30 mjrosenb: We dropped armel after quantal (12.10), and it's all armhf all the time now. Sep 09 21:23:05 mjrosenb: But -mfloat-abi=soft{,fp} should work with gcc-multilib installed. Sep 09 21:23:22 You just have no libraries other than glibc to help you out. Sep 09 21:28:45 ok, but at least there is still the multilib. Sep 09 21:57:52 wow, that was a lot of fetch errors! Sep 09 21:58:24 hah, do-release upgrade trusts itself to not kill X, but not to not kill ssh Sep 09 22:00:53 https://gist.github.com/52081b6b88509ae478dc ok, are the errors that it is talking about towards the end just the warnings that it spewed right afterwards? Sep 09 22:01:01 I don't see any other things that look like errors. Sep 10 00:13:03 mjrosenb: There is no armel in trusty, so those errors are entirely expected. Sep 10 00:13:13 mjrosenb: If that's an armel machine, there's no sane upgrade path. Sep 10 00:13:29 infinity: no, that was done with multiarch Sep 10 00:13:42 back when multiarch seemed like the one true path. Sep 10 00:13:50 mjrosenb: If it's an armhf machine with some armel multiarch action going on, you'll probably need to tear out 'dpkg -l *\:armel' before you start. Sep 10 00:14:12 mjrosenb: multiarch is the one true path, just not for architectures we've dropped. :P Sep 10 00:14:30 (I use it to great success with amd64/i386/armhf/arm64/ppc64el/powerpc....) Sep 10 00:15:09 infinity: well, I just removed the line from the multiarch file Sep 10 00:15:44 Also, if that machine's running X, I hope you don't love PowerVR accelerated 3D drivers, cause PVR and TI dropped support for them long ago, and we no longer have binary blobs to ship. Sep 10 00:15:52 So, trusty has no binary drivers for Pandas. Sep 10 00:15:56 do-release-upgrade complained about: https://gist.github.com/bd8a05405f3e4be74f18 Sep 10 00:16:16 so as long as plymouth being broken doesn't mean I can't boot, I don't care. Sep 10 00:16:29 infinity: does X still work with a frame buffer of sorts? Sep 10 00:16:34 Well, "apt-get -f install" and see what it does, or is grumpy about. Sep 10 00:16:58 mjrosenb: I believe X still works nominally via an FB, yeah, though unity (which is 3D-only in trusty) will really not. Sep 10 00:17:11 Other desktops, like xfce, probably work alright. Sep 10 00:17:47 Sadly, our hands were tied on this. It was either support a 3.5 kernel forever, or drop Panda 3D support. We opted for the saner route. :/ Sep 10 00:17:52 Yay, non-free drivers. Sep 10 00:18:09 infinity: hooking a monitor up to the machine is like 90% a last-ditch-effort. Sep 10 00:18:32 Yeah, mine ocasionally gets a monitor hooked up, but only to look at the console. There's no X. Sep 10 00:18:42 My Panda's pretty much a really crappy server. Sep 10 00:18:47 well, when I installed ubuntu, X came with it. Sep 10 00:18:57 mine is a debugging/benchmarking machine. Sep 10 00:19:03 Ahh, yeah, if you used on the desktop images. Sep 10 00:19:12 So, you might be happier with a fresh install. Sep 10 00:19:14 although about half the time, I'm actually running inside of a debian chroot that is still softfp. Sep 10 00:19:38 If you have a USB hard drive hooked up to it, slapping in a 14.04 d-i image in the SD card and just installing fresh might give you a saner (and leaner) system. Sep 10 00:20:33 infinity: if this goes pear shaped, that'll be my first step. Sep 10 00:20:43 * infinity nods. Sep 10 00:20:46 * mjrosenb is very tenacious about not re-installing. Sep 10 00:21:04 Yeah, I have a machine that's been upgraded since potato, I know the feeling. Sep 10 00:21:34 potato, woody, hoary, (many Ubuntu releases), trusty. Sep 10 00:21:36 I think. Sep 10 00:21:43 * mjrosenb is somewhat sure that is from before I started using linux. Sep 10 00:21:52 infinity: how did the debian->ubuntu switch go? Sep 10 00:22:15 Went fine back in the warty/hoary days, since sidegrading was a goal when we were starting fresh. Sep 10 00:22:21 These days, I'm not sure I'd attempt it. Sep 10 00:22:48 at my last job, the sysadmin that set up my machine gave me a 32-bit non-pae install, and 8 gigs of ram. Sep 10 00:23:10 convincing debian to do a 32->64 bit transition was /fun/ Sep 10 00:23:23 Although, on a simple text-only serverish install, wheezy->precise would probably upgrade fine. Sep 10 00:23:32 I wouldn't dare try it on a desktop with a bunch of fancy installed, though. Sep 10 00:24:04 right so, no plymouth -> no fancy boot gui or no plymouth -> no boot? Sep 10 00:24:17 Depends on the state of the no plymouth. Sep 10 00:24:35 If it's half broken, it could lead to no framebuffer consoles. Sep 10 00:24:48 file /sbin/plymouthd Sep 10 00:24:49 /sbin/plymouthd: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x868f0842a830948469aa2a0650a9d8a492703912, stripped Sep 10 00:24:51 It *probably* should still boot and give you serial and SSH, however, unless it's really, really broken. Sep 10 00:25:40 my first experience with plymouth was sub-par. Sep 10 00:25:41 DId "apt-get -f install" not shed light on what was broken? Sep 10 00:25:42 to say the least. Sep 10 00:26:32 plymouth is somewhat overengineered, IMO, but it does do one thing better than what we had before, which is multiplexing console input at early boot, so you can reliably do things like ask for luks passwords. Sep 10 00:26:38 Which is why we use it even on text consoles. Sep 10 00:27:44 my first experience with it was on gentoo, since I was setting up an htpc, and i wanted a pretty boot. Sep 10 00:28:00 and it always hung Sep 10 00:28:03 very quickly. Sep 10 00:28:16 Yeah, I'm still not convinced it handles the simple job of "pretty boot" any better than the old attempts like usplash or splashy. Sep 10 00:28:31 But the input stuff is gold, if you can be bothered to wind through the maze of how the heck it works. Sep 10 00:29:06 turns out, openrc was attempting to read from its stdin, which it assumed was a tty (because why would it not be a tty) Sep 10 00:29:27 Derp. Sep 10 00:29:45 Everyone assumes everything's a TTY still, despite this being 2014. Sep 10 00:29:52 It's depressing how often I see that class of bug. Sep 10 00:29:52 and tried to get it to get no blocking by twiddling the terminal bits. Sep 10 00:30:27 turns out, stdin was being provided by plymouth, so setting it to noblock did *nothing* Sep 10 00:30:44 then it read from stdin, and plymouth didn't have anything for it Sep 10 00:30:54 Shockingly. :) Sep 10 00:31:10 (it read from stdin so the user could interrupt the boot process) Sep 10 00:31:17 which is normally a very useful featur. Sep 10 00:31:22 On the other hand, I expect this sort of learning experience from a build-your-own OS like Gentoo or Arch. Sep 10 00:31:35 I'd be filing bugs like a crazy person if this happened to me on Ubuntu or Fedora. Sep 10 00:32:21 infinity: true. I'm mostly used to it, but that was the first time I ever had to modify init to find out what was failing. Sep 10 00:32:22 And yes, the whole "press any key to interrupt" sort of thing needs to be handled by plymouth in a plymouth world. Sep 10 00:32:43 Which is both bad and good, depending on viewpoint. Sep 10 00:33:09 Bad, cause it's added complexity, good, cause you can have it listen literally EVERYWHERE for that key, and serialize input, and deal with it somewhat sanely. Sep 10 00:34:17 (Well, more important than the listening everywhere is the notifying everywhere, so you get output on text consoles, serial, etc, telling you that a key might need to be pressed) Sep 10 00:34:34 Handy for things like filesystem check progress (and cancellation), for instance. Sep 10 00:35:01 But, yeah. Despite all the above, I'm not a big plymouth advocate. I like what it provides, but I desperately want someone to NIH it with something less crap with similar features. Sep 10 00:35:16 Sadly, I suspect that someone will be Lennart, and it will have a taint to it that I don't appreciate. Sep 10 00:36:45 The taint likely being that it'll end up in the systemd binary because, hey, why shouldn't your init system have complicated framebuffer and font rendering code? Sep 10 01:09:30 is plymouth systemd-only yet? Sep 10 01:11:43 *snort* Sep 10 01:18:13 infinity: ok, very different question, do you know if gcc supports TCO on arm? Sep 10 01:25:48 also, re: apt-get install -f, it did not shed any light on the issue Sep 10 01:25:50 https://gist.github.com/43ac4b97ba79207e216e Sep 10 01:25:54 but I'm pretty ok with that. Sep 10 01:47:51 mjrosenb: Well, it looks like it fixed it up, so that works. Sep 10 01:48:37 yup. and it booted to some form of gui. Sep 10 02:55:46 infinity: gaaah :-( Sep 10 02:55:49 perf doesn't work. Sep 10 02:56:11 wait, what? Sep 10 02:56:16 why is my kernel still 3.2? Sep 10 02:56:53 3.2.0-1452-omap4 #72-Ubuntu SMP PREEMPT Tue Aug 19 20:46:59 UTC 2014 Sep 10 02:56:58 this *is* a new kernel. Sep 10 02:57:04 mjrosenb: Oh, cause we didn't forcefully upgrade people from the TI kernel, specifically because of the 3D issue. Sep 10 02:57:24 mjrosenb: apt-get install linux-generic linux-tools-generic Sep 10 02:57:37 mjrosenb: SHould get you the non-TI kernel and matching perf. Sep 10 02:59:36 I'm kind of surprised that a 3.2 kernel still works. **** ENDING LOGGING AT Wed Sep 10 02:59:58 2014