[13:20] <mamarley> Quick question:  Why does 4.2.0-13 disable HWP support for Skylake-S?  I saw it in the changelog but there isn't a bug report linked and I can't find the change upstream anywhere.
[13:21] <apw> mamarley, that was discuessed on the kernel-team@ mailing list iirc
[13:21] <mamarley> Ah, OK.  Thanks, I will look there.
[13:21] <apw> mamarley, and the tl;dr was "it causes some kit to hang really really early in boot, and we are waiting for fixes"
[13:22] <mamarley> Thanks!
[13:23] <apw> mamarley, https://lists.ubuntu.com/archives/kernel-team/2015-September/063132.html is the thread i believe
[13:27]  * rtg should have put that list URL in the changelog
[13:28] <apw> rtg, actually i should add it to the annotations, but as i have utterly redone them in my s390x bits, i might need to do it there
[13:37] <apw> rtg, with hindsight i think that that should have a commandline override if we are releasing with it
[13:38] <apw> rtg, and its not an annotations thing, we should rewrite that commit to contain the link at least
[13:38] <rtg> apw, perhaps. I was just going with the upstream expert
[13:38] <apw> rtg, as you'll be rebasing for stable "some time"
[13:38] <apw> rtg, yeah but when its fixed they won't be able to test it is fixed without a way to turn it off
[13:39] <rtg> apw, I didn't propagate that change into unstable, which is where I'll likely start from for X
[13:42] <rtg> apw, non sequitur. How do you update the kernel on your raspberry pi ? flash-kernel does not appear to have support for pi2 in Wily
[13:43] <rtg> this is in a pure Ubuntu install (no Snappy)
[13:51] <mamarley> apw: I agree, my Skylake-S system is completely stable with it, so being able to manually override would be nice.  For now I am just compiling the kernel myself.
[13:52] <apw> rtg, i don't know if i have had an update as yet
[13:52] <apw> rtg, though i might have a special flash-kernel from pp's ppa
[13:53] <ogra_> rtg, there is a bug with patch from ppisati somewhere 
[13:53] <rtg> apw, so you're on a 3.18 kernel ?
[13:53] <ogra_> rtg, https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1494719
[13:53] <ubot5`> Ubuntu bug 1494719 in flash-kernel (Ubuntu) "Support for the RaspberryPi2 platform" [Undecided,New]
[13:53] <rtg> ogra_, cool, thanks
[13:53] <ogra_> but i think that needs name adjustments :P 
[13:53] <ogra_> uses rpi2 instead of raspi2
[13:54] <rtg> ogra_, I just happen to have a platform for testing.
[13:54] <ogra_> heh
[14:01] <apw> rtg, yes, i think i am stil on pp's kernel, i can switch if we have bits to test
[14:02] <rtg> apw, the wily archive raspi2 kernel should work. I'm busily confirming, though ogra_ has been using it in Snappy.
[14:02] <ogra_> yeah, works fine in snappy 
[14:03] <ogra_> no idea how it would work in any other setups, i'm not even sure what these other setups use as bootloader
[14:03] <ogra_> (snappy chainloads uboot)
[14:31] <PHLin> jsalisbury, hello
[14:32] <PHLin> jsalisbury, bjf suggested me to ask you for some help on this bug  https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1498743
[14:32] <ubot5`> Ubuntu bug 1498743 in wpasupplicant (Ubuntu) "[BCM4313][14e4:4727] Unable to connect to the network with proprietary driver installed" [Undecided,New]
[14:33] <PHLin> jsalisbury, it's about the wifi issue on a specific Broadcom chip
[14:44] <tjaalton> hum, upgraded a machine from precise to trusty, but now networking is busted. r8169 is loaded but no eth0 available
[14:45] <tjaalton> oh, says link down
[14:45] <tjaalton> which is weird
[14:45] <arges> sforshee: hey. LP: #1497070, what kind of testing have you done with it
[14:45] <ubot5`> Launchpad bug 1497070 in HWE Next "please update i915 firmware" [Undecided,New] https://launchpad.net/bugs/1497070
[14:46] <arges> or perhaps tjaalton has already verified the above ^^^
[14:46] <arges> unfortunately i am away from my kit at the moment otherwise I'd fire it up and try it out
[14:46] <sforshee> arges: yeah I don't have hw, tjaalton is the one who has tested
[14:46] <arges> sforshee: oh and I see the comment now. : )
[14:47] <tjaalton> new fw fixed at least one hang-after-resume bu
[14:47] <tjaalton> bug
[14:47] <arges> tjaalton: ok and its been in wily for a bit (which I have been testing with)
[14:48] <arges> looks good to me
[14:48] <tjaalton> yep
[14:49] <jsalisbury> PHLin, I'll take a look at the bug now
[14:49] <PHLin> jsalisbury, thanks!
[14:49] <jsalisbury> np
[14:53] <jsalisbury> PHLin, it looks like your not seeing this bug anymore on this system, per comment #11.  Is that correct, or does it require some time to reproduce?
[14:54] <PHLin> jsalisbury, let me try the Wireless Internet connection again now
[14:54] <jsalisbury> PHLin, ack, thanks
[15:05] <PHLin> jsalisbury, yeap, it failed again
[15:05] <tjaalton> reloading the r8169 module restored network, huh
[15:05] <PHLin> jsalisbury, with "wpa_supplicant[1251]: Association request to the driver failed"
[15:06] <PHLin> jsalisbury, it's quite random I must say
[15:08] <jsalisbury> PHLin, would you say it's specific to a kernel version?  Does this not happen if you boot back into a prior kernel?
[15:09] <PHLin> jsalisbury, hmmm, we didn't notice this issue during the last cycle
[15:09] <PHLin> jsalisbury, maybe it's because it just failed so we noticed that in this one
[15:10] <jsalisbury> PHLin, That would be a good thing to test next.  Boot back into the prior kernel version and see if the bug can be reproduced
[15:12] <PHLin> jsalisbury, let me install the prior kernel first
[15:12] <PHLin> jsalisbury, I did switch to 3.2.0-90 before, but the driver seems not working at all
[15:12] <jsalisbury> PHLin, great thanks.  We should confirm if this is a regression or not.  
[15:15] <PHLin> jsalisbury, the previous result for 3.2.0-90 is in comment #9, but it's useless as the driver is not working
[15:16] <jsalisbury> PHLin, ok.  Do you happen to know if the driver was ever working prior to 3.2.0-90?
[15:17] <PHLin> jsalisbury, yes, it passed the last cycle SRU testing
[15:18] <PHLin> jsalisbury, http://people.canonical.com/~hwcert/sru-testing/precise/3.2.0-90.128/precise-proposed-froze.html
[15:18] <jsalisbury> PHLin, Can you try that prior kernel and see if this bug can be reproduced?  If we can identify the last good kernel and first bad one, I can perform a kernel bisect.
[15:24] <PHLin> jsalisbury, ok
[15:24] <PHLin> jsalisbury, btw, do you know how to boot into a specific kernel remotely?
[15:26] <jsalisbury> PHLin, do you have access to the console, if so, you can use the GRUB menu.  Another way would be to change the value of GRUB_DEFAULT and re-run update-grub 
[15:27] <PHLin> jsalisbury, ok I will try the GRUB_DEFAULT stuff, I'm not in the lab now
[15:27] <jsalisbury> PHLin, do you only have ssh access and not console access?
[15:28] <PHLin> jsalisbury, I have only ssh access, for console, you mean if I can hit shift / esc to enter the grub menu, right?
[15:28] <jsalisbury> PHLin, yes
[15:29] <PHLin> jsalisbury, yeah, that system is in the lab, I can only ssh into it now
[15:30] <jsalisbury> PHLin, ok.  there should be a wiki on changing the GRUB_DEFAULT setting.  
[15:30] <PHLin> jsalisbury, ok
[15:31] <jsalisbury> PHLin, this one might be helpful: https://help.ubuntu.com/community/Grub2
[15:34] <PHLin> jsalisbury, hmmm, I think I mistakenly boot it into the recovery mode
[15:34] <PHLin> jsalisbury, it's not accessible anymore
[15:35] <PHLin> jsalisbury, I will need to check it tomorrow
[15:35] <jsalisbury> PHLin, ack
[15:36] <PHLin> jsalisbury, for the bisect, a tricky thing is that we only began to test it with the Broadcom driver since 3.2.0-90
[15:36] <PHLin> jsalisbury, it was certified with the Broadcom driver
[15:37] <PHLin> (at the very beginning)
[15:37] <PHLin> jsalisbury, and later on, it works without the driver, so we didn't test the driver until 3.2.0-90
[15:40] <PHLin> jsalisbury, anyway, thanks for your help, I will ask my colleague to take over this on tomorrow morning
[15:40] <PHLin> jsalisbury, any specific information that you want to know?
[15:42] <henrix> PHLin: just to clarify: the wl driver wasn't working with 3.2.0-90, but it was never tested before that (except from the "very beginning").
[15:42] <jsalisbury> PHLin, If this is specific to the kernel version, it would be good to know the last kernel version that did not exhibit this bug and the first version that does.  Or if this bug is specific to bcmwl regardless of the kernel version.
[15:42] <henrix> PHLin: by "very beginning" you mean early Precise kernel releases?
[15:43] <PHLin> henrix, the wl driver may be not working when this system was certified https://certification.canonical.com/certificates/1206-4010/
[15:44] <PHLin> henrix, it's 3.2.0-23.36
[15:45] <PHLin> henrix, and after it was chosen as a precise sru system
[15:45] <PHLin> henrix, we test it with the wl driver as it works without any issue
[15:47] <PHLin> henrix, I think it's in the test pool since 3.2.0-39.62
[15:47] <PHLin> henrix, just randomly checked some test report, no sign of bcmwl-kernel-source
[15:48] <bjf> PHLin, it's hard for me to see this as a Precise regression.
[15:48] <PHLin> henrix, and recently we found this system should be tested with the Broadcom driver, as it's certified with that
[15:48] <PHLin> bjf, ok
[15:49] <bjf> PHLin, jsalisbury can help you out a bit with the bug but let's get the precise kernel out.
[15:50] <PHLin> bjf, no problem, should I push the result to the kernel tracking bug?
[15:50] <bjf> yes
[15:50] <PHLin> bjf, ack
[15:50] <henrix> PHLin: ok, thanks for the clarification.  i guess this info should go into the bug report, along with the latest working kernel version (as jsalisbury suggested)
[15:52] <PHLin> henrix, okok
[15:52] <PHLin> bjf, tracker bug updated
[15:54] <bjf> PHLin, thanks
[16:14] <rtg> lool, the patch for bug #1494719 does not contain a flash method. Should it be "generic" for rpi2  ?
[16:14] <ubot5`> bug 1494719 in flash-kernel (Ubuntu) "Support for the RaspberryPi2 platform" [Undecided,New] https://launchpad.net/bugs/1494719
[16:17] <lool> rtg: that's a good question
[16:18] <rtg> lool, guess I can just try it. it can only brick my system :)
[16:18] <lool> rtg: generic is the default, so you dont need to specify it, but feel free to
[16:19] <lool> rtg: I tried a slightly different version on Mark's rpi2, but this should work
[16:19] <lool> His version was just 4 lines:
[16:19] <lool> Machine: Raspberry pi 2 Model B
[16:19] <lool> Machine: BCM2709
[16:19] <lool> Method: rpi2
[16:19] <lool> Kernel-Flavors: rpi2 raspi2
[16:19] <rtg> lool, it looks like it just falls through in the code if a methid is not specified in the DB
[16:19] <lool> method="$(get_machine_field "$machine" "Method")" || method="generic"
[16:19] <lool> is what I see in the flash-kernel on the rpi2 here
[16:20] <rtg> lool, ah, ok
[16:20] <rtg> I'll look closer at the log