[05:48] Hello world! :) [07:29] * apw yawns at the world [07:49] apw: goodmorning sweetheart :) [07:49] ppisati, morning my lovely [07:50] :) === lag` is now known as lag [08:58] weren't dtb supposed to be treated like a stable ABI? weren't old dtb supposed to be supported by newer kernels?!?!? [09:01] bah, it boots at least... [09:53] ppisati, heh ... yeah right [10:01] apw: besides, the answer is no: http://lwn.net/Articles/560523/ [10:04] ppisati, so the answer is yes they should, but not they don't cause we are crap at it [10:04] apw: right, so to be on the safe side, always update kernel and dtb together, else your board could stop booting [10:05] as the dts comes with the kernle in the main, that isn't so difficult, but it really really shouldn't [10:16] apw: well, problem is that on some platform the dtb is buried in the firmware so, everytime you install a new kernel, you *should* reflash the firmware [10:16] apw: but this time around, i just lost one day on my new bone, because the dtb that came with a 3.8 kernel [10:16] ppisati, sign [10:16] ppisati, sigh [10:16] apw: hanged 3.11 and i spent the entire yesterday debugging it [10:17] what a royal pain in the ass, and something we need to socialise that there are real risks in upgrading [10:17] apw: and when i woke this morning i thought "well, what if it's the dtb?!?!?" [10:17] ppisati, that is the "shower brain" in action [10:17] apw: and that's it, now it kind of boot [10:17] right [10:18] it took me, one day to learn that the serial cable (a usb with an embedded ftdi chip) doesn't work if connected to a usb cable extension [10:19] another one to find out that the board provided dtb doesn't work with recent kernel [10:19] and now let's see... [10:41] ppisati, a struggle indeed [10:43] apw: well, not really, it's just that i loose way too much time on stupid details... [10:44] apw: anyhow, it's gym time! :) [10:44] see u later [11:07] Sep 17 22:47:01 juju-prodstack-pes-r2-instance-1 kernel: [17844307.966142] INFO: rcu_sched detected stall on CPU 3 (t=1078390 jiffies) [11:07] Sep 17 22:47:01 juju-prodstack-pes-r2-instance-1 kernel: [17844307.967042] sending NMI to all CPUs: [11:07] ^-- does that interrupt userland [11:07] err [11:08] ^-- does that interrupt system calls at all? e.g. could it interrupt an fsync()? [11:54] elmo, i would not expect that to affect userland at all indeed, i would expect that to make all CPUs to service the NMI and continue where they left off [11:57] apw: cool, thanks [13:10] apw, hi there, I want to build a custom kernel in my PPA. But everytime I bump the changelog and build a source pakcage, it blows away my changelog entry. [13:10] apw, what is the correct way to do this? [13:11] ChickenCutlass, you need to change the changelog in debian./changelog not debian/changelog [13:11] apw, ah [13:12] apw, one more question. [13:12] apw, I have a new MacBook Air 6,2. The haswell one [13:12] apw, and after applying 2 patches -- acpi and sound work [13:12] apw, can we get those into saucy? [13:13] what is the policy there [13:13] ChickenCutlass, its cirtainly possible, if they fix a bug, get them up on kernel-team@ with why they are needed [13:14] apw, ack [13:17] and the provenance [13:18] cking, right. === Guest72565 is now known as mfisch === mfisch is now known as Guest1225 === kentb-out is now known as kentb [14:19] infinity: ping === fmasi_afk is now known as fmasi === fmasi is now known as Guest80183 [15:04] ppisati: To be fair, the dtb/kernel dependencies are something that we're desperately trying to socialize as unnecessary and fix. So, for the short term, we might want to upgrade in lockstep, but I disagree that we want to pass that knowledge on to end users, as it will become cargo-cult misinformation. [15:06] infinity: well, the problem is not that we want or not, if the kernel requires a new dtb, you better deliver it or be ready to debug your boot [15:06] infinity: anyhow, i pinged you about the flash-kernel patch [15:07] infinity: can you give it a look? [15:07] ppisati: Right, but if the kernel requires a new DTB, it's because the previous one was broken. Ultimately, they should be (and will be) decoupled. [15:07] ppisati: I'll give the patch a look this morning. [15:07] infinity: that was the promise, but it doesn't work like that [15:13] ppisati: No, no. I know it doesn't work like that today, I'm talking about what the future is meant to look like, however. And socializing "you'll need to pay attention or fix this" to end users sets up a bad expectation. We should JFDI silently where we can, and in cases where vendors actually SHIP a firmware dtb that breaks with their newer kernels honestly, that's their fault. [15:15] infinity: agreed [15:27] ppisati, infinity, it is not obvious one can even change the thing when it is in the firmware [15:28] they should so contain a version number === Guest1225 is now known as mfisch === cnd` is now known as cnd [16:17] ppisati: Your awk magic for kvers comparisons is somewhat suspect. [16:17] ppisati: I'm not so good with arithmetic, but I'm pretty sure that 2638 >> 311 >> 40, for instance. [16:18] infinity: hold on [16:18] infinity: i use just the first 2 number [16:18] infinity: 26 < 311 < 40 [16:19] Well, your first half is true. :P [16:19] infinity: ah right :) [16:19] infinity: well, when 4.0 is out we'll think about it :) [16:20] Or we can just do it right now. [16:20] I think I have some shell hackery in glibc to get this right. [16:20] infinity: nice [16:21] Or you could just use dpkg --compare-versions, since having f-k without dpkg seems like an unlikely scenario. [16:22] infinity: but then i need to know against which pkg i'm installing/overwriting [16:22] Eh? [16:23] No, dpkg --compare-versions just takes version arguments. [16:24] Or, there's this, from my glibc preinst: [16:24] linux_compare_versions () { [16:24] verA=$(($(echo "$1" | sed 's/^$[0-9]*\.[0-9]*$$[^.0-9]\|$$/\1.0\2/; s/$[0-9]*$\.$[0-9]*$\.$[0-9]*$.*/\1 \* 10000 + \2 \* 100 + \3/'))) [16:24] verB=$(($(echo "$3" | sed 's/^$[0-9]*\.[0-9]*$$[^.0-9]\|$$/\1.0\2/; s/$[0-9]*$\.$[0-9]*$\.$[0-9]*$.*/\1 \* 10000 + \2 \* 100 + \3/'))) [16:24] test $verA -$2 $verB [16:24] } [16:24] CAUSE THAT'S SUPER READABLE. [16:24] OH MY GOD!!! [16:25] I think I'll just use compare-versions. I do that in initramfs-tools too. It comes close enough to doing the right thing. [16:31] ppisati: http://paste.ubuntu.com/6128952/ [16:32] infinity: way better, ack [16:33] I have no way to test that this actually works, but it looks sane enough to me. [16:33] infinity: hold on [16:33] (I mean the overall patch, not my change) [16:35] infinity: i tested the overll patch going from 2.6.35 to 3.11 (and back) [16:37] ppisati: It will fail if $kernel already points to $tmpdir/kernel before your code triggers. [16:37] ppisati: Which would happen in the machine_id case. [16:38] ppisati: (Since you can't do "cat $foo > $foo") [16:42] infinity: you mean the "append_dtb "$kernel" "$dtb" "$tmpdir/kernel"" [16:42] ppisati: Yeah, cause the previous block could have set $kernel to $tmpdir/kernel [16:42] infinity: right [16:42] append_dtb "$kernel" "$dtb" "$tmpdir/kernel.dtb" [16:42] mv "$tmpdir/kernel.dtb" "$tmpdir/kernel" [16:43] That seems like it would solve the issue. [16:43] Though maybe append_dtb itself should be more robust, so it doesn't let you do this. [16:44] infinity: debian has the same problem [16:44] http://anonscm.debian.org/gitweb/?p=d-i/flash-kernel.git;a=blob;f=functions;h=febf0d4af61dd59bb543798663f3f324d3c4fe68;hb=HEAD [16:44] line 502 [16:44] Indeed. [16:45] Well, I'll fix it here for now. :P [17:00] hi, i'm having throuble using the full power of a bulldozer cpu: with sensors i see that when fam15h_power-pci-00c4 power1 reaches the crit value (125w) the cpu is slowed down and i get a serius performance drop. it's a kernel configuration thing? [17:14] infinity: going out for dinner, see you later/tomorrow [19:11] Notch-1, those thresholds normally come out of the cpu ... reaching crit thresholds normally are a very serious boundary and we would expect throttling === smb` is now known as smb [19:20] apw: any way around that? [19:25] apw: anyway it's odd: with another cpu with half the cores i have almost the same performance... and with this one the core/performance ratio it's stable until i use 5 core or more (out of 8). in other words i don't tink i'm getting the full power... [21:19] Notch-1, or the pysical envelope isn't able to disipate the heat that device can produce efficiently enough [21:19] ie 6 cores can outstrip the cooling ... [21:31] apw: not a cooling issue, the heatpipe keeps the temperature below 60°... === kentb is now known as kentb-afk === smb` is now known as smb