[01:41] <Guest86749> How can the kernel be told to lock the CPU into low power mode?
[01:42] <Guest86749> I take it the kernel overrides all bios settings, is that so?
[02:02] <Guest86749> Is there something I can add to the grub config to set this in kernel or do I need to use userspace tools?
[02:10] <Guest86749> infinity
[09:54] <who_me> hi, for some reason generating .deb packages for kernel 4.1.8 fails. I'm using the sources from kernel.org and the patches from here http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1.8-unstable/. The build log is here: https://dl.dropboxusercontent.com/u/3371527/results_4.1.8.txt
[10:45] <apw> who_me, you need to disable split packaging when building mainline builds
[10:46] <apw> do_extras_package=false
[10:57] <who_me> but I do want the extras package
[10:58] <who_me> and this worked fine up until kernel 4.1.8
[10:59] <apw> who_me, turning extras off just merges its content into the main package you don't lose anything
[11:00] <apw> we never build the mainline kernels with the extras package turned on because we cannot guarentee the interdependancies are the same, as you have just found
[11:01] <who_me> apw, ok. would this change affect me if using non-free modules like the nvidia one?
[11:01] <apw> it has no relevance to that no
[11:02] <who_me> cool . thank you.
[11:03] <apw> who_me, i don't suppose i want to know why you want to run an old mainline release, let alone build your own
[11:04] <who_me> apw, 4.1.8 is recent. 4.2 probably still has the regression which makes it impossible to use the nvidia driver
[11:05] <who_me> unless a simple patch is applied
[11:05] <apw> who_me, mainline 4.2 perhaps but nvidia is building in wily with 4.2
[11:06] <who_me> with the mainline kernel or the ubuntu patched kernel?
[11:06] <apw> who_me, and those patches for nvidia are always simple, except that they change the export status of a symbol
[11:06] <apw> which is a legal issue not a technical one
[11:06] <apw> who_me, nvidia builds in wily with teh wily kernel
[11:08] <who_me> apw, any reason not to use the mainline kernels? For example, I saw that VLC had a tendency to hang on close... I have not seen it do that since I started using the mainline kernels
[11:09] <apw> who_me, you can use any kernel you like, such is the joy of linux, but you get to do it the hard way if its not the archive kernels, so i was trying to work out why you were using them
[11:11] <who_me> Hmm, at first it started because I just wanted to see how to roll my own kernel in an easier fashion. After that I experimented with the BFS/BFQ schedulers... but now I'm sticking to vanilla builds.
[11:13] <who_me> apw, so now when building the mainline kernel the line should look like: fakeroot debian/rules binary-headers binary-generic do_extras_package=false ?
[11:13] <apw> who_me, something like that, i normally put it before the binary-* as thats the order it applys in my mind
[11:13] <apw> prolly doesn't mattter
[11:16] <who_me> And I wanted to see how much work it would be to roll my own kernel because it always rubbed me the wrong way when people suggested "oh just use Arch" when people needed a newer kernel for better hardware support
[11:16] <apw> who_me, all reasons to have kernel fun for sure
[11:17] <who_me> it turns out it was not much work at all, and I even created a how-to, which I will now have to amend :)
[11:17] <apw> no they build pretty easy if you have schroot particularly
[11:18] <who_me> https://dl.dropboxusercontent.com/u/3371527/how_to_build_kernel_on_Ubuntu.txt <-- this is it. Pointers and suggestions welcome :)
[11:22] <apw> who_me, not sure why you need to add +x on the scripts, we expect those to not have x as we ship V1 packages normally
[11:23] <who_me> I know for sure I need to +x the debian/rules file the others I picked up from here: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[11:24] <who_me> granted they recommend doing it if the intention is to edit the configs
[11:31] <apw> that makes more sense
[11:31] <davmor2> apw: Hey dude, quick question, can I stop b43 from trying to own the card on the dell xps 13 in wily so it install the bcmwl-kernel-sources package and actually works?  If so how please
[11:31] <apw> davmor2, blacklist b43 ?
[11:32] <davmor2> apw: I meant more to go on the cdrom image, I'm assuming we don't want to wholesale blacklist b43
[11:32] <apw> when will dell stop putting things without good drivers in their kit
[11:33] <apw> davmor2, as far as i know you owuld have to modify b43 then to stop it matching on that kit, as it cleanly thinks it can drive it
[11:35] <apw> clearly even
[11:36] <apw> davmor2, though i thought that wl blacklisted b43 when it was installed, so wouldn't that happen when jockey wacks it on ?
[11:36] <apw> and i thought jockey worked on machine identifiers etc
[11:37] <apw> davmor2, and ... what is the symptoms with b43, and what device is it
[11:38] <davmor2> apw: all I know is ubuntu-drivers list is not showing it as an option and after digging around the system for a while discovered it was trying to be driven by b43, although the macbook pro I have for testing that needs the bcmwl driver is correctly saying it needs to install it
[11:39] <apw> davmor2, and i assume b43 is not driving it satisfactorily ?
[11:39] <apw> davmor2, and that on the macbook it does not load b43 ?
[11:40] <davmor2> apw: it just doesn't there is no wifi at all and ofcourse there is only wifi on the xps13
[11:40] <davmor2> apw: if I install the driver manually it all works fine, but that isn't going to hell on automatically installing it with the 3rd party drivers
[11:41] <davmor2> s/hell/help
[11:41] <apw> so .. we need to know what the criteria for installing them is in jockey, ie why does it think that this isn't neeed
[11:42] <apw> davmor2, also what are the two bcm chipsets in question, pci ids, for the broken and working ones
[11:52] <davmor2> apw: http://paste.ubuntu.com/12520646/ top is the dell, bottom is the mac
[12:04] <apw> davmor2, that needs more -vvvv's to get the actual ids
[12:05] <davmor2> apw: no worries I'll hit that after Lunch then
[13:14] <davmor2> apw: are we any closer?
[13:14] <davmor2> http://paste.ubuntu.com/12520958/
[13:16] <apw> davmor2, apparently -nnvv is the correct incationation
[13:16] <davmor2> apw: right on it in a second then
[13:27] <davmor2> apw: http://paste.ubuntu.com/12521056/
[13:38] <qq[IrcCity]> hello.  Linux 4.3.0-040300rc2 SMP x86_64 (from kernel.ubuntu.com) apparently has some bugs related to the page table (revealing especially when swap file is on).     RAM was testing with Memtest86+ and nothing suspicious found.
[13:38] <qq[IrcCity]> should I enable more dedugging?   but I don’t know how these things are achieved in modern Linux.
[13:54] <apw> qq[IrcCity], well we'd normally wait a bit as that is a very very early -rc
[13:57] <qq[IrcCity]> apw, simultaneously aiming to switch to a state-of-the-art “nouveau” driver available only there; see http://askubuntu.com/questions/674426/installing-linux-4-3-on-existing-ubuntu-release
[13:58] <qq[IrcCity]> stable Linux 3.16 behaves not better screwing the console up.
[13:59] <qq[IrcCity]> one possible solution is throw GeForce 8600 GTS away, but it’s the last resort.
[14:04] <apw> qq[IrcCity], if you are getting stack traces we might have some ideas, but its tricky with such unstable versions
[14:25] <qq[IrcCity]> apw: http://www.superstructure.info/linux/4.3/kern.log.txt  there is a dozen of Linux 4.3 boots and many error reports, with some call traces.   note that two boots with Linux 3.16 are present in the log.
[14:28] <qq[IrcCity]> a page file was sometimes (but not always) activated.
[14:30] <UNIm95> apw: What does it mean: Status: Confirmed => Invalid in my Bug report? Is this panic fixed? And patched to upstream?
[14:31] <UNIm95> In Thrysty -proposed?
[14:31] <UNIm95> Thrusty8
[14:31] <apw> UNIm95, remind me of the bug number
[14:31] <UNIm95> https://bugs.launchpad.net/bugs/1497184 
[14:32] <apw> UNIm95, that is the wily task, the fix beleived to sort this problem is alreday applied there
[14:32] <apw> trusty and vivid are both in progress, they are Fix Committed
[14:34] <UNIm95> apw: when in would be as update in repository? When status of bug report will cchange to closed?
[14:34] <apw> as the previous version is only in -proposed it will get replaced pretty much as soon as the new one is built, i recon
[14:36] <henrix> apw: UNIm95: yeah, they should hit -proposed "soon" (as in today or tomorrow)
[14:38] <UNIm95> apw henrix Thanks! It is one of the best supports that i ever seen.
[15:26] <jsalisbury> **
[15:26] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:26] <jsalisbury> **
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:56] <jsalisbury> ##
[17:11] <jsalisbury> Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Sep 29th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
[17:14] <ricotz> apw, hi, jfyi, wrong pocket for those https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+sourcepub/5403817/+listing-archive-extra
[17:22] <bjf> infinity, random question ... i just installed ubuntu server daily on an intel nuc. during install it detects and uses "em1" as the nic. post install & reboot the interface is "eno1" which isn't what's in /etc/network/interfaces
[17:22] <bjf> infinity, what package get's the bug?
[17:23] <bjf> infinity, "debian-installer" ?
[17:23] <mjg59> jsalisbury: I think you meant to put a /topic in front of that
[17:23] <infinity> bjf: Yeah, d-i for now, and point it out to me.  It could be any of a number of things.
[17:24] <jsalisbury> mjg59, whoops I did.  Thanks!
[17:24] <infinity> bjf: In theory, we're using the same detection method in d-i and in the installed system.  Theory and practice don't always align so well.
[17:25] <infinity> bjf: If you could, can you redo the install, but when it asks to reboot, cancel out of that, hit a shell, and grab syslog and dmesg for me, and then let the installer reboot and get the post-boot dmesg for me?
[17:26] <bjf> infinity, yes, i'll do that
[17:26] <bjf> infinity, LP: #1498595
[17:27] <infinity> bjf: Ta.  I've never even seen "enoX" before.  I kinda want to blame systemd for making things up, but I'll get $someone to sort this out.
[17:29] <bjf> infinity, i'm wondering if that's someone's "funny" -ENOONE
[17:31] <infinity> bjf: Heh.  It'll be me, pitti, or cyphermox, or some combination of the three.
[17:32] <cyphermox> yeah, that'd be one of those fun new device names
[17:35] <cyphermox> bjf: finishing up with grub-installer, then I can look at why the naming is different
[17:37] <bjf> cyphermox, ack, working on gathering logs
[17:38] <infinity> cyphermox: In theory, this should have been resolved with the systemd uploads I did in late vivid to make sure the udev rules matched in d-i and the installed system.
[17:38] <infinity> cyphermox: But, as I said, enoX doesn't look sane.
[17:38] <cyphermox> yeah
[17:38] <cyphermox> well enoX is a valid onboard name of some sort
[17:39] <infinity> bjf: Hrm.  The installed system doesn't have biosdevname installed, does it?
[17:39] <infinity> It's in universe, I'd hope not.
[17:39] <infinity> cyphermox: Anyhow, if you want to take this one, be my guest.  But feel free to pair-whine at me in /msg, cause I'd like to know what broke and what you're suggesting as a solution.
[17:40] <cyphermox> ack
[17:48] <bjf> cyphermox, logs attached
[17:48] <cyphermox> thanks
[18:16] <cyphermox> bjf: so, nearly certain you had biosdevname in the installer.
[18:17] <cyphermox> I can't find anything else that tries to get you 'emX' names
[18:23] <bjf> cyphermox, i just downloaded today's live server iso and used that
[18:24] <cyphermox> bjf: yeah, we tracked it down. it will be fixed in tomorrow's image
[18:25] <bjf> cyphermox, cool
[18:43] <cyphermox> bjf: https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu393