[07:32]  * smb waits for some theatrical moves from northerly directions
[07:42]  * apw yawns very sensibly
[08:57] <zequence> infinity: Is the precise 3.2 kernel no longer being SRUd?
[09:11] <infinity> zequence: It is, it just didn't have any updates last cycle.  It has some this time.
[09:11] <infinity> zequence: See launchpad.net/bugs/1300871
[09:16] <zequence> infinity: ah, sorry. I missed it.
[10:50] <apw_> cking: just lost some of my Internet or a vps or something
[10:51] <cking> apw_, ack
[14:02] <ogasawara> rtg, apw: pmcgowan is telling me his kernel is causing panics this morning.  it started yesterday.  he says it's networking related.  I'm having him snag a picture to throw in a bug report.
[14:02] <ogasawara> rtg, apw: will also have him test on an older kernel to confirm it goes away
[14:03] <rtg> ogasawara, brcm ?
[14:03] <ogasawara> rtg: am grabbing his system info
[14:03]  * apw wonders what release he is on
[14:03]  * apw thought yesterdays update was pretty benign ?
[14:05] <ogasawara> I've asked pmcgowan to jump in here
[14:06] <pmcgowan_> ogasawara, the problem cannot be reported, this is not an official Ubuntu package
[14:06] <apw> ?
[14:06] <pmcgowan_> linux-image-3.13.0-20-generic
[14:07] <apw> it really is
[14:07] <ogasawara> that's a bit odd
[14:07] <apw> what version is it .... dpkg -l linux-image-3.13.0-20-generic
[14:07] <rtg> it should be 3.13.0-22.44
[14:08] <pmcgowan_> its 3.13.0-20.42
[14:08] <apw> so that was not yesterdays kernel, nor indeed the one before ?
[14:08] <pmcgowan_> I would have been running it for days then
[14:09] <apw> is -20.42 the good one, or the new bad one
[14:10] <pmcgowan_> the one that panic'd
[14:10] <apw> did you get a piccy, leann mentioned you were putting it in the bug, what was the # / link to the piccy
[14:11] <pmcgowan_> no pic sorry, I had shut it down by then
[14:11] <pmcgowan_> and ubuntu-bug wont let me report
[14:12] <pmcgowan_> I can dist-upgrade and see if it occurs again, then properly record it
[14:13] <pmcgowan_> apw, I dont have anything for you guys right now, so how about I get the newer kernel
[14:16] <apw> works for me
[14:18] <pmcgowan_> oops there it goes
[14:19] <pmcgowan_> maybe its this bt device
[14:37] <pmcgowan_> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1301990
[14:37] <ubot2> Launchpad bug 1301990 in linux (Ubuntu) "Samsung N9 Kernel panic" [Undecided,New]
[14:40] <apw> pmcgowan_, that is still -20.42 btw
[14:45] <pmcgowan_> apw, right it crashed before I got to upgrade
[14:45] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1301990/comments/3
[14:45] <ubot2> Launchpad bug 1301990 in linux (Ubuntu) "Samsung N9 Kernel panic" [Undecided,New]
[14:46] <pmcgowan_> apw, must be this bt trackpad, thats whats different
[14:46] <Sarvatt> theres a patch on lkml and that bug for it if it didn't just start happening recently, should have been broken from 3.11 and up http://www.spinics.net/lists/linux-bluetooth/msg41725.html
[14:47] <pmcgowan_> Sarvatt, I have not paired this device for months so I would not have seen it
[14:49] <Sarvatt> ah https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1252874 too, sheesh
[14:49] <ubot2> Launchpad bug 1252874 in linux (Ubuntu) "Kernel panic shortly after pairing Apple Magic Touchpad" [High,In progress]
[14:49] <apw> Sarvatt, ok this would be fixed in 3.14-rc8 then ...
[14:50] <apw> pmcgowan_, i'll pull that in if i can and let you have a test kernle, though i suspect it wont' make the release kerenl
[14:50] <apw> but it owuld be eligable to sru anyhoo
[14:50] <pmcgowan_> apw, ok cool
[14:50]  * pmcgowan_ finds his paperclip
[14:54] <bjf> rtg, hatch pinged us yesterday about bug #1284085 which seems bad. haswell macbooks (pro and air) not booting trusty
[14:54] <ubot2> Launchpad bug 1284085 in linux (Ubuntu) "unable to boot after install on 2013 macbook air" [High,Confirmed] https://launchpad.net/bugs/1284085
[14:54]  * hatch waves
[14:54] <rtg> bjf, does it work on yours ?
[14:54] <hatch> I'll do the acpi dump tonight 
[14:54] <bjf> rtg, yes but mine isn't haswell
[14:54] <bjf> rtg, however, my haswell desktop and one other haswell system work just fine
[14:55] <hatch> re the comment from sforshee, both of us in the bug are using rEFInd
[14:55] <rtg> hmm, I've got a haswell desktop
[14:55] <bjf> yes you do
[14:55] <rtg> hatch, your workaround was to use something other then grub, right ?
[14:55] <rtg> IIRC
[14:56] <apw> rtg, bjf, ok i was involved in this many moons ago, one good thing is there is a work around "nr_cpus=1" or something
[14:56] <hatch> rtg I've never been able to get it to boot
[14:56] <sforshee> I've got a couple of haswell systems which are fine
[14:56] <apw> so it can be fixed postumously
[14:56] <hatch> I'll try the nr_cpus again because I think I was using it incorrectly
[14:56] <apw> sforshee, i see you commented just an hour back or something
[14:56] <bjf> sforshee, do you have a haswell macbook?
[14:56] <sforshee> bjf: not a macbook
[14:56] <hatch> but a single cpu is kind of.....not acceptable :)
[14:56] <sforshee> but there's an upstream bugzilla that indicates that only csm boot is affected, native efi boots fine
[14:56] <apw> hatch, yes but if there is a way to boot it a later update can be installed to fix it
[14:57] <apw> if it cannot be booted at all we are in a hole
[14:57] <apw> which is why the first thing we didi was find a way to boot it
[14:57] <hatch> yeah - ok I'll try to boot it in about 30mins and see what happens
[14:58] <sforshee> hatch: I looked at your dmesg and I'm pretty sure it was not an efi boot
[14:58] <hatch> I just guessed where to put the nr_cpus in the list
[14:58] <hatch> sforshee not my dmesg
[14:58] <hatch> :)
[14:58] <sforshee> okay, well the one on the bug then :-)
[14:59] <hatch> haha, ok so is there a specific place the nr_cpus=1 should go?
[14:59] <apw> hatch, on the kernel command line, so whereever you specifiy that 
[14:59] <hatch> apw in grub I put it at the top of the command list and nothing happened
[15:00] <apw> i asume you have grub installed, so yuoo can hold shift to talk to that
[15:00] <apw> and put it where the otehr kernelly bits are
[15:00] <apw> at the top, no, i think hte line starts "linux"
[15:00] <sforshee> grep quiet /boot/grub/grub.cfg
[15:00] <sforshee> er
[15:00] <apw> yeah where quiet is in that output, on the same horizontal line as that
[15:01] <hatch> ok thanks, after the calls this am I'll get on that 
[15:09] <bjf> if he can't boot how is he going to make these changes?
[15:12] <hatch> bjf I can get to grub
[15:12] <hatch> so hopefully I can get nr_cpus to work
[15:16] <bjf> hatch are you using the +mac iso ?
[15:17] <hatch> bjf I tried both
[15:17] <hatch> should I be?
[15:17] <bjf> hatch, i have to use the +mac on mine, so that's the one i'd use
[15:17] <hatch> ok sure
[15:17] <bjf> hatch, remember mine is not haswell
[15:19] <hatch> yeah, I read online somewhere that I shouldn't use the +mac for haswell...but so far the outcome has been the same
[15:19] <bjf> hatch, are you using bootcamp, refit, something else ?
[15:19] <hatch> I'm not sure what the difference is
[15:19] <hatch> rEFInd
[15:20] <sforshee> hatch: which install image did you use? The normal desktop one or the mac one?
[15:20] <hatch> I tried both last night - I think the currently installed is the 13.10 from the public download page
[15:20] <sforshee> hatch: oops, I see bjf already asked
[15:23] <apw> hatch, when you are booted successfully could you find out which grub bits are installed 'dpkg -l | grep grub'
[15:33] <rtg> bjf, sforshee - looks like another failure to boot on Apple: https://bugs.launchpad.net/bugs/1301590
[15:33] <ubot2> Launchpad bug 1301590 in linux (Ubuntu) "System does not boot" [High,Confirmed]
[16:08] <hatch> 13.10 runs surprisingly well on a single core
[16:08] <hatch> adding the acpi, dmesg, and grub outputs to the ticket
[16:11] <hatch> hope those help solve the problem :) anything else let me know and I can try it out https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284085
[16:11] <ubot2> Launchpad bug 1284085 in linux (Ubuntu) "unable to boot after install on 2013 macbook air" [High,Confirmed]
[17:20] <hatch> sforshee so are you saying that I'm choosing the incorrect option in rEFInd after creating the livecd? There were three options, I just picked the one which actually made sense, the others were just paths to grub if I remember correctly
[17:20] <hatch> this is the instructions followed for creating the bootable usb stick http://www.ubuntu.com/download/desktop/create-a-usb-stick-on-mac-osx
[18:09] <sforshee> hatch: so all that stuff in those instructions are completely unnecessary nowadays, at least for recent macs
[18:09] <sforshee> you can just dd the image to the usb stick
[18:09] <hatch> well then.... lol
[18:10] <sforshee> and the option which is a path to grub is what you really want
[18:10] <sforshee> we should probably still be able to boot the way you did it though, unless apple really screwed something up in the bios emulation
[18:10] <hatch> entirely possible
[18:10] <hatch> haha
[18:11] <sforshee> but I don't recommend using bios emulation, sometimes they turn off features there
[18:11] <hatch> and should I use the +mac image? I don't know what the difference is
[18:11] <hatch> http://cdimage.ubuntu.com/daily-live/current/
[18:11] <sforshee> I've been using the desktop image for at least a year now on macs without any problems
[18:11] <hatch> ok sounds like a plan
[18:12] <hatch> well I hope this was just me screwing this up all along
[18:12] <sforshee> hatch: once you've booted efi though I'd like to get another acpi table dump to compare with the one under bios emulation
[18:13] <hatch> you bet - I won't be able to do that until tonight though
[18:13] <sforshee> because really assuming that Windows can boot under the Apple emulation, we should be able to also
[18:13] <sforshee> but it's also curious that you can do it from the live image, which makes me wonder if grub is doing something to contribute to the problem
[18:14] <hatch> yeah the liveimage boots just fine
[18:14] <hatch> any grub related commands you'd like the output from?
[18:15] <sforshee> not off the top of my head, I'm no grub guru
[18:16] <hatch> I found it odd that rEFInd dumps me into grub after selecting the Ubuntu install.
[18:16] <hatch> so maybe using the EFI install that will also be fixed
[18:19] <sforshee> hatch: I believe displaying the grub prompt is the default whenever other OSes are detected
[18:19] <sforshee> or the grub menu, rather
[18:20] <hatch> ohh ok
[19:59] <rtg> dannf, do we generate arm64 installation images somewhere ? I found some stuff here: http://cloud-images.ubuntu.com/trusty/current/
[20:03] <dannf> rtg: http://ports.ubuntu.com/ubuntu-ports/dists/trusty/main/installer-arm64/current/images/generic/
[20:03] <rtg> dannf, thanks
[22:36] <the_fifteenth> Just wanted to let y'all know, there might be a bug
[22:36] <the_fifteenth> Holding alt+sysrq and pressing r then j crashes the kernel. B won't even reboot
[22:36] <the_fifteenth> J is supposed to do an emergency thaw by the way
[23:16] <dannf> apw: LP: #1063895 - should i move that to fix-released ?
[23:16] <ubot2> Launchpad bug 1063895 in linux (Ubuntu) "arm64 support to generate linux-source for crosstool bulds" [Medium,In progress] https://launchpad.net/bugs/1063895