[00:46] <infinity> xnox: Those tasks are added by a script that the security team uses to track CVEs.  They tend to prefer if others don't touch them. :P
[00:47] <infinity> xnox: Also, we maintain some kernels upstream (3.13, 3.16, 3.19, 4.2), and we absolutely apply CVE fixes for arches we don't ship in our upstream stable trees.
[00:47] <infinity> xnox: (Not everything is about contracts)
[01:14] <xnox> infinity, oh.
[01:14] <xnox> sbeattie, in that case i probably did more harm than good.
[01:16] <xnox> sbeattie, i'm sorry if i messed things up.
[06:47] <sbeattie> xnox: yeah, sorry, script on autopilot. I don't think you did any harm (well, it'll gripe at me about the deleted tasks, but that just means it goes on a list of other bugs that have the same issue)
[11:43] <xnox> =/
[12:10] <tjaalton> is there a known issue with the keyboard getting stuck on resume?
[12:11] <tjaalton> hmm, maybe it's just with my test versions.. I blame libinput
[12:23] <apw> tjaalton, not seen that here
[12:24] <tjaalton> i have that on two systems, it's actually hard to resume if it's suspended by hotkey.. since it keeps suspending a number of times
[12:24] <tjaalton> and that then seems to break iwlwifi, nice
[12:24] <apw> tjaalton, sounds about right to me :)
[12:24] <tjaalton> i really don't understand those who demand intel wifi.. it's been nothing but crap on all my systems
[12:26] <apw> tjaalton, but at least it is open source crap ... i have much worse experiences with things that needed wl
[12:26] <tjaalton> that's true, but then there's the fw component too
[12:26] <apw> yep, we get regular updates for iwlfw, it is clearly a work in progress
[12:27] <apw> and if you are holding the suspend button down, i am sure that is ripping and reinstalling and ripping the h/w out every time
[12:27] <apw> which is bound to push the races in teh driver to their limit
[12:28] <tjaalton> right, iwlwifi seems to crap itself on it's own though, after a few cycles. but then again this is intel sdp so all bets are off as always
[12:34] <apw> and that
[14:56] <netikras> Hello boys
[14:56] <netikras> Is this the right channel for queries regd http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
[14:58] <netikras> Whichever 4.x version I try to install (.deb), I get a few error messages: due to -Werror virtualbox-client and ndiswrapper fail to install
[15:04] <netikras> I can dump logs here or I could fill-in a bug report. I just can't find where to register a new bug.....
[16:02] <apw> nelhage, those are mainline kernels, they are for testing only, it is highly likely they are ahead of teh supported versions in dkms packages ...
[16:39] <kernelbug> Could someone do a bisection between 3.18.26 and .27 ?????
[16:39] <kernelbug> I think I found a bug.
[16:39] <kernelbug> I use Mint and .27 hangs on the logo screen, .26 works fine.
[16:41] <kernelbug> http://expirebox.com/download/b57059eb53fedc4d8fd6f85da506a242.html
[16:41] <kernelbug> Here are the dmesg files.
[16:41] <kernelbug> I guess they won't help but anyway.
[16:46] <kernelbug> Am I in a wrong channel?
[16:47] <ogra_> for mint questions ? perhaps ...
[16:47] <kernelbug> I'm using Ubuntu mainline kernel!
[16:47] <kernelbug> FFS!
[16:47] <ogra_> mainline ?
[16:47] <ogra_> or ubuntu ? 
[16:47] <mamarley> I think there may be a regression in suspend functionality for the Thinkpad T530 between Wily and Xenial.  On Wily, suspend works great but on Xenial if I suspend more that two times, it hangs while suspending.  I am about to try the 4.2 mainline kernel on Xenial and see if that makes a difference.
[16:47] <kernelbug> These... http://kernel.ubuntu.com/~kernel-ppa/mainline/
[16:47] <ogra_> (the mainline build is completely unsupported ... )
[16:48] <ogra_> (it is just to verify bugs)
[16:48] <kernelbug> Hehheh...
[16:48] <kernelbug> I need to verify a bug then. :)
[16:48] <ogra_> also pleaae watch your language 
[16:49] <kernelbug> What language? Check all the three-letter acronyms and their meanings... :)
[16:49] <ogra_> against which ubuntu kernel are you verifying ?
[16:50] <kernelbug> Between 3.18.26 and 3.18.27... .27 is which fails.
[16:50] <ogra_> there is no ubuntu version in that list 
[16:50] <ogra_> you seem to compare one mainline build against another ?
[16:51] <kernelbug> Yes.
[16:51] <kernelbug> I use mainline kernels in Mint.
[16:51] <ogra_> yes, you said so ... 
[16:51] <apw> why 3.18 of all versions ?
[16:51] <kernelbug> They won't support those kernels either. ;)
[16:51] <ogra_> and i said mainline kernels are not supported ... they exist to veryfy bugs against the ubuntu kernels 
[16:52] <kernelbug> I prefer stability.
[16:52] <kernelbug> 3.18 is LTS anyway.
[16:53] <kernelbug> That's another selling point for me. :)
[16:53] <apw> why not use an ubuntu kernle which is an lts
[16:53] <kernelbug> I'm using Mint.
[16:53] <apw> and mint uses ubuntu kernels right ?
[16:53] <kernelbug> It's a modified Ubuntu kernel anyway.
[16:53] <kernelbug> Yes, slightly modifies ones.
[16:53] <ogra_> apw, i dont think tehy do ... 
[16:53] <kernelbug> Yes they do.
[16:53] <ogra_> they hack them up like theyy hack up half of the libs (while keeping versions and sonames)
[16:54] <kernelbug> ogra don't ruin this conversation
[16:54] <kernelbug> you are not very helpful
[16:54] <kernelbug> go to hockey game if you want brainless entertainment :)
[16:55] <ogra_> kernelbug, this channnel is about ubuntu kernels ... you came here, cursing and trolling about stability to get support with a mainline build that isnt supported, what do you expect ? 
[16:56] <kernelbug> I need your help with the bisection.
[16:58] <kernelbug> In other words how to do a git-bisect to generate Ubuntu mainline kernels to test bugs ?????
[16:58] <ogra_> https://wiki.ubuntu.com/Kernel/KernelBisection
[16:59] <kernelbug> OK.
[16:59] <apw> kernelbug, you need to pull the .config out of your current version and use that to build kernels using those two tags as bisect end points
[16:59] <kernelbug> Maybe it's "userspace" issue though.
[17:00] <kernelbug> apw, OK. :)
[17:00] <kernelbug> Lots of work anyway.
[17:00] <kernelbug> I'm already burning out.
[17:00] <kernelbug> I'm too old for this shit! ;)
[17:01] <kernelbug> Gotta talk with the Mint folks now.
[17:01] <kernelbug> Sorry. ;)
[17:01] <ogra_> (they will probably tell you to use a mint kernel :) ... you are kind of between the worlds)
[17:02] <mamarley> Looks like I am going to have to bisect a kernel too.  Mainline 4.2.8 (and Wily 4.2) has working suspend support on my T530, but Xenial 4.4 has broken suspend support.  Now I shall try 4.3...
[17:02] <kernelbug> ogra_ yeah...
[17:03] <kernelbug> Like a child from a dysfunctional family, which I am...
[17:05] <apw> mamarley, if that is an ubuntu kernel you should file a bug, and someone will likely be able help
[17:08] <mamarley> apw: I will once I isolate when it was introduced a bit more.  I am about to try 4.3 to see if the bug was introduced in 4.3 or 4.4.
[17:09] <apw> sounds good.  let us know the bug# here when you do
[17:09] <mamarley> Sure.  I don't need someone to build the kernels for me though; I have a pretty beefy box that I can do it on.
[17:12] <mamarley> I suppose I should probably try the 4.4 mainline kernel as well so I can figure out if the regression was introduced by something backported from 4.5.
[17:12] <apw> mamarley, if you are able to do it yourself, all the better
[17:12] <mamarley> It wouldn'
[17:12] <mamarley> t be the first time :)
[17:13] <kernelbug> apw, you could help me too...
[17:13] <kernelbug> apw, even if it's mainline ;(
[17:13] <apw> it wouldn't be me, it would be someone who does those kinds of things when he finds bugs to work on
[17:20] <mamarley> The regression is definitely between 4.3 and 4.4 in mainline.
[17:20] <kernelbug> mamarley, we have similar problems.
[17:21] <mamarley> kernelbug: No, we do not.  Your login screen fails to display, my laptop fails to suspend.  I am running 4.4, you are running 3.18.  I am running Ubuntu Xenial, you are running Mint.
[17:21] <kernelbug> mamarley, how can you know?
[17:22] <kernelbug> mamarley, maybe the same bug applies to 4.4. :)
[17:22] <mamarley> The only similarity between our problems is that both require a bisect.
[17:22] <kernelbug> hehe
[17:23] <kernelbug> bisection sounds brutal
[17:36] <mamarley> It isn't fun.
[18:06] <mck182> hi, I wanted to give a try to the latest mainline kernel to debug some issues I have with suspend, but it appears that installing it fails on compiling i915 dkms - http://paste.ubuntu.com/15416510/ - I'm not entirely sure how to proceed from here - is there any way to fix that issue?
[18:08] <apw> mck182, it is common for mainline kernels beyond ubuntu devleopment versions to break dkms packages and those won't get updated until the kernel moves forward in YY most likley
[18:08] <mck182> ah
[18:08] <mck182> apw: so no way for me to test the latest kernel until the intel driver is available for YY?
[18:09] <apw> depends what the dkms package is
[18:09] <mck182> I don't even know tbh
[18:09] <apw> then you might not be using it
[18:09] <apw> it might be cruft
[18:09] <mck182> I do have it loaded, I would assume it's the graphics driver
[18:12] <apw> mck182, hmm, that is an i915 driver ... i have literally no idea where that has come from
[18:12] <apw> mck182, can you tell me the package name ?
[18:13] <apw> though i would say you don't need it with later kernels ... probaballyu
[18:13] <mck182> apw: which package? the kernel? or the dkms?
[18:13] <apw> the dkms package which is exploding, i assume it has i915 in its name
[18:13] <mck182> apw: i915-4.0.4-3.19-dkms
[18:13]  * mck182 looks for where it came from
[18:14] <apw> so i'd say that is redundant with any kernel after 3.19, but its not an archive package as far as i know
[18:15] <apw> is this a dell by any chance ?
[18:15] <mck182> apw: ah, then it may have come from the intel-linux-driver-installer thing...or the xorg-edgers
[18:15] <mck182> apw: no, macbook pro
[18:15] <apw> tjaalton, is thatone of yours ^ ?
[18:15] <apw> mck182, it has to be very old compared to xenial and later kernels
[18:15] <apw> so i would just rip it for those
[18:15] <tjaalton> no intel provided dkms's at one point
[18:15] <mck182> apw: I'm runing wily fwiw
[18:16] <apw> tjaalton, they did?  woh, how do i not know this ... :/
[18:16] <tjaalton> ignorance is bliss
[18:16] <apw> tjaalton, are they in a PPA somewhere or off in intel.com somewhere
[18:16] <tjaalton> 01.org
[18:16] <tjaalton> their quarterly stack
[18:16] <apw> ugg
[18:17] <mck182> so, if I reboot into the newly installed mainline kernel (4.5), I should be fine without that dkms?
[18:17] <mck182> actually
[18:17] <mck182> that error I posted above is related only to the dkms, not the kernel itself, right?
[18:17] <apw> i'd say anything above 3.19 from the name
[18:17] <apw> looks to be yes
[18:17] <mck182> alright
[18:18] <mck182> well I'll just try :)
[18:18]  * mck182 reboots
[18:19] <tjaalton> looks like they still ship a dkms.. https://download.01.org/gfx/ubuntu/15.10/main/pool/main/i/
[18:20] <mck182> hah, yeah, it works without any problem :)
[18:24] <apw> tjaalton, i thought we were sorting that for them via the i915_bpo nightmare we are carrying in everything
[18:25] <tjaalton> they have this DIY-thing for users
[18:26] <tjaalton> and we're doing this for oem's not intel
[18:26]  * mck182 still has a wonky suspend...so much for trying newer kernel
[18:27]  * mck182 still has a wonky suspend...so much for trying newer kernel
[18:27] <apw> mck182, 100% wonkey or randomly so
[18:27] <mck182> apw: no change from the stock ubuntu kernel; my laptop wakes up after 4 seconds of suspend
[18:27] <mck182> is there any way to get the wakeup reason?
[18:28] <mck182> I'd like to know what is causing the wakeup
[18:28] <apw> mck182, there might be info in the order of the words in the dmesg output
[18:28] <apw> mck182, i would check the rtc alarm
[18:28] <apw> windows tends to set that to wake up the machine now and again so it an check the battery and make it hibernate harder
[18:28] <mck182> apw: there's nothing :S I also tried the pm_trace, but that hangs the wakeup altogether and says /base/power/main
[18:30] <mck182> the only interesting thing from dmesg is "xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI" when suspending
[18:31] <mck182> which is in line with /proc/acpi/wakeup
[18:31] <mck182> but I have no devices connected to this laptop
[18:31] <mck182> so must be something internal
[18:34] <apw> what does the rtc alarm say
[18:35] <mck182> apw: that's /sys/class/rtc/rtc0/wakealarm right?
[18:35] <apw> that sounds believeable, i think you can cat it
[18:36] <mck182> apw: so that's empty
[18:36] <apw> likely not that then
[18:37] <mck182> well then there's /proc/driver/rtc
[18:37] <mck182> which has some stuff http://paste.ubuntu.com/15416793/
[18:38] <mck182> but I've no idea what that means or if it's relevant
[18:40] <mck182> also, rtcwake -m show says "alarm: off"
[18:40] <apw> that sounds definative to me
[18:41] <mck182> unless it is set by something at suspend time
[18:41] <mck182> which would be strange
[18:46] <mck182> disabling the XHC1 wakeup disables the open-lid-wakeup -.-
[18:46]  * mck182 wonders how did apple design this thing
[18:46] <apw> with as little h/w as possible to make it cheap
[18:51] <mck182> looks like this bug btw https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1391476
[18:52] <apw> mck182, sounds liek there is at least something to try in there
[18:53] <apw> mck182, the echo thing, if that works then you could encode that in the pmsuspend world somewhere i am sure
[18:53] <mck182> apw: yeah it suggests disabling XHC1 from wakeup
[18:53] <apw> which sounds rather similar to your problem
[18:53] <mck182> apw: but as I sad above, that also breaks lid-open wakeup for me ( ._.)
[18:53] <apw> well presumably you open lid and hit function and win
[18:54] <apw> or app or whatever dumb name the clover-leaf is called
[18:54] <apw> but it may well be a programming the h/w problem, a problem that is hard to fix because the h/w is undocumented
[18:54] <mck182> indeed
[18:54] <apw> delbieratly by apple to make sure their own os is better
[18:54] <mck182> although disabling the XHC1 also disables keyboard wakup
[18:55] <mck182> so the only way is to hit the power button...no big deal but...
[18:56] <apw> its prolly the touchpad, the screen touching it and waking the machine
[18:56] <apw> you prolly have to turn the touchpad off somehow, and not the keyboard
[18:56] <mck182> hmmm
[18:56] <apw> to get the mac behaviour
[18:56] <apw> but they are renound for randomness, like to use the SD card slot
[18:57] <apw> you have to power up the phy for the ethernet
[18:57] <mck182> lemme test suspending without the lid closed and pressing the touchpad if that actually wakes it
[18:57] <apw> good idea
[18:58] <mck182> well, didn't even have to get close to the touchpad, it wakes up all on its own without touching anything
[18:59] <apw> not that then, but to be honest you are likely to never have a fix for that unless someone gets epically lucky
[18:59] <mck182> yeah, I guess
[19:00] <apw> such is the fate of those who buy macs :(
[19:00] <apw> shame they are so nice
[19:00] <mck182> well fwiw I do have a 2011 mac as well and that one works 140% great
[19:00] <mck182> but true, they did design these new ones from scratch
[19:01] <apw> the only way to keep ahead of linux :)
[19:01] <mck182> heh
[19:01] <mamarley> I don't even consider them nice.  They are impossible to work on and have everything soldered down on the mobo.
[19:02] <mck182> the latter is a real downside, but working on them...never had a problem really
[19:02] <mck182> and the touchpad is awesome
[19:06] <mamarley> Kernel bisection sucks.  This is going to take all weekend. :/
[19:06] <apw> mamarley, that sounds about right, builds are not quick
[19:06] <apw> even with an enormous hoover
[19:07]  * mamarley has an i5-6600K box with an SSD.
[19:07] <mamarley> It can definitely heat up the room when I compile stuff.  I am glad I am not actually there right now. :)
[19:09] <apw> mamarley, how long does a build take ...
[19:09] <mamarley> apw: Not sure, my last one got interrupted because the terminal application crashed.  I am measuring this one.  I will try -j8 instead of -j4 on the next one and see if that makes a difference.
[19:10] <apw> mck182, i've moved that bug back to Confirmed as you asre still seeing it
[19:10] <apw> mck182, feel free to add some info there
[19:10] <mck182> apw: yeah, the mainline 4.5.0 kernel definitely still has it
[19:10] <mck182> I can share my findings in there, sure
[19:10] <mck182> if I can remember my login... :P
[19:13] <mck182> ok done
[19:41] <martink3> tested the latest xenial iso on a file server featuring a ARC1882 RAID controller - got weird timeout issues.
[19:42] <martink3> Found out that mailine 4.4 features a buggy arcmsr driver, which "supports" the 1882, but not really... Areca seems to have managed to get a fixed driver into mainline 4.5
[19:44] <martink3> any chance that the xenial kernel could backport that driver before release? what is the policy for that? it seems to be a small patch on arcmsr.h and arcmsr_hba.c ...
[19:45] <apw> martink3, file a bug against the linux package, and put the infomration and proposed patches in there, and let me know the bug # here, and i'll get someone to make formal test kernel and if that works we can submit the patches for inclusion
[19:46] <martink3> will do tonight, thx!
[19:46] <mamarley> apw: This build took 43m4.491s, though a good half of that it spent building the -dbg package.
[19:46] <mamarley> Is there perhaps some way I can tell it not to build that particular package?
[19:48] <apw> yep do_debug=false or something grep for debug in debian/rules
[19:48] <mamarley> OK, thanks!
[19:49] <mamarley> Except there is no debian/rules here, I am building the mainline kernel with deb-pkg...
[19:50] <mamarley> Wait nevermind, there is a debian directory.
[19:51] <mamarley> But it is very minimalistic and doesn't have anything about debug in it.
[19:52] <mamarley> It doesn't really matter.  -dbg is the last thing it builds, so I can just kill it after it builds the packages I actually need.
[20:01] <apw> ahh ok