[00:46] 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] 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] xnox: (Not everything is about contracts) [01:14] infinity, oh. [01:14] sbeattie, in that case i probably did more harm than good. [01:16] sbeattie, i'm sorry if i messed things up. [06:47] 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] =/ [12:10] is there a known issue with the keyboard getting stuck on resume? [12:11] hmm, maybe it's just with my test versions.. I blame libinput [12:23] tjaalton, not seen that here [12:24] 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] and that then seems to break iwlwifi, nice [12:24] tjaalton, sounds about right to me :) [12:24] i really don't understand those who demand intel wifi.. it's been nothing but crap on all my systems [12:26] tjaalton, but at least it is open source crap ... i have much worse experiences with things that needed wl [12:26] that's true, but then there's the fw component too [12:26] yep, we get regular updates for iwlfw, it is clearly a work in progress [12:27] 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] which is bound to push the races in teh driver to their limit [12:28] 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] and that [14:56] Hello boys [14:56] Is this the right channel for queries regd http://kernel.ubuntu.com/~kernel-ppa/mainline/ ? [14:58] 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] 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] 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] Could someone do a bisection between 3.18.26 and .27 ????? [16:39] I think I found a bug. [16:39] I use Mint and .27 hangs on the logo screen, .26 works fine. [16:41] http://expirebox.com/download/b57059eb53fedc4d8fd6f85da506a242.html [16:41] Here are the dmesg files. [16:41] I guess they won't help but anyway. [16:46] Am I in a wrong channel? [16:47] for mint questions ? perhaps ... [16:47] I'm using Ubuntu mainline kernel! [16:47] FFS! [16:47] mainline ? [16:47] or ubuntu ? [16:47] 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] These... http://kernel.ubuntu.com/~kernel-ppa/mainline/ [16:47] (the mainline build is completely unsupported ... ) [16:48] (it is just to verify bugs) [16:48] Hehheh... [16:48] I need to verify a bug then. :) [16:48] also pleaae watch your language [16:49] What language? Check all the three-letter acronyms and their meanings... :) [16:49] against which ubuntu kernel are you verifying ? [16:50] Between 3.18.26 and 3.18.27... .27 is which fails. [16:50] there is no ubuntu version in that list [16:50] you seem to compare one mainline build against another ? [16:51] Yes. [16:51] I use mainline kernels in Mint. [16:51] yes, you said so ... [16:51] why 3.18 of all versions ? [16:51] They won't support those kernels either. ;) [16:51] and i said mainline kernels are not supported ... they exist to veryfy bugs against the ubuntu kernels [16:52] I prefer stability. [16:52] 3.18 is LTS anyway. [16:53] That's another selling point for me. :) [16:53] why not use an ubuntu kernle which is an lts [16:53] I'm using Mint. [16:53] and mint uses ubuntu kernels right ? [16:53] It's a modified Ubuntu kernel anyway. [16:53] Yes, slightly modifies ones. [16:53] apw, i dont think tehy do ... [16:53] Yes they do. [16:53] they hack them up like theyy hack up half of the libs (while keeping versions and sonames) [16:54] ogra don't ruin this conversation [16:54] you are not very helpful [16:54] go to hockey game if you want brainless entertainment :) [16:55] 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] I need your help with the bisection. [16:58] In other words how to do a git-bisect to generate Ubuntu mainline kernels to test bugs ????? [16:58] https://wiki.ubuntu.com/Kernel/KernelBisection [16:59] OK. [16:59] 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] Maybe it's "userspace" issue though. [17:00] apw, OK. :) [17:00] Lots of work anyway. [17:00] I'm already burning out. [17:00] I'm too old for this shit! ;) [17:01] Gotta talk with the Mint folks now. [17:01] Sorry. ;) [17:01] (they will probably tell you to use a mint kernel :) ... you are kind of between the worlds) [17:02] 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] ogra_ yeah... [17:03] Like a child from a dysfunctional family, which I am... [17:05] mamarley, if that is an ubuntu kernel you should file a bug, and someone will likely be able help [17:08] 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] sounds good. let us know the bug# here when you do [17:09] 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] 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] mamarley, if you are able to do it yourself, all the better [17:12] It wouldn' [17:12] t be the first time :) [17:13] apw, you could help me too... [17:13] apw, even if it's mainline ;( [17:13] it wouldn't be me, it would be someone who does those kinds of things when he finds bugs to work on [17:20] The regression is definitely between 4.3 and 4.4 in mainline. [17:20] mamarley, we have similar problems. [17:21] 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] mamarley, how can you know? [17:22] mamarley, maybe the same bug applies to 4.4. :) [17:22] The only similarity between our problems is that both require a bisect. [17:22] hehe [17:23] bisection sounds brutal [17:36] It isn't fun. [18:06] 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] 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] ah [18:08] apw: so no way for me to test the latest kernel until the intel driver is available for YY? [18:09] depends what the dkms package is [18:09] I don't even know tbh [18:09] then you might not be using it [18:09] it might be cruft [18:09] I do have it loaded, I would assume it's the graphics driver [18:12] mck182, hmm, that is an i915 driver ... i have literally no idea where that has come from [18:12] mck182, can you tell me the package name ? [18:13] though i would say you don't need it with later kernels ... probaballyu [18:13] apw: which package? the kernel? or the dkms? [18:13] the dkms package which is exploding, i assume it has i915 in its name [18:13] apw: i915-4.0.4-3.19-dkms [18:13] * mck182 looks for where it came from [18:14] 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] is this a dell by any chance ? [18:15] apw: ah, then it may have come from the intel-linux-driver-installer thing...or the xorg-edgers [18:15] apw: no, macbook pro [18:15] tjaalton, is thatone of yours ^ ? [18:15] mck182, it has to be very old compared to xenial and later kernels [18:15] so i would just rip it for those [18:15] no intel provided dkms's at one point [18:15] apw: I'm runing wily fwiw [18:16] tjaalton, they did? woh, how do i not know this ... :/ [18:16] ignorance is bliss [18:16] tjaalton, are they in a PPA somewhere or off in intel.com somewhere [18:16] 01.org [18:16] their quarterly stack [18:16] ugg [18:17] so, if I reboot into the newly installed mainline kernel (4.5), I should be fine without that dkms? [18:17] actually [18:17] that error I posted above is related only to the dkms, not the kernel itself, right? [18:17] i'd say anything above 3.19 from the name [18:17] looks to be yes [18:17] alright [18:18] well I'll just try :) [18:18] * mck182 reboots [18:19] looks like they still ship a dkms.. https://download.01.org/gfx/ubuntu/15.10/main/pool/main/i/ [18:20] hah, yeah, it works without any problem :) [18:24] tjaalton, i thought we were sorting that for them via the i915_bpo nightmare we are carrying in everything [18:25] they have this DIY-thing for users [18:26] 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] mck182, 100% wonkey or randomly so [18:27] apw: no change from the stock ubuntu kernel; my laptop wakes up after 4 seconds of suspend [18:27] is there any way to get the wakeup reason? [18:28] I'd like to know what is causing the wakeup [18:28] mck182, there might be info in the order of the words in the dmesg output [18:28] mck182, i would check the rtc alarm [18:28] 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] apw: there's nothing :S I also tried the pm_trace, but that hangs the wakeup altogether and says /base/power/main [18:30] the only interesting thing from dmesg is "xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI" when suspending [18:31] which is in line with /proc/acpi/wakeup [18:31] but I have no devices connected to this laptop [18:31] so must be something internal [18:34] what does the rtc alarm say [18:35] apw: that's /sys/class/rtc/rtc0/wakealarm right? [18:35] that sounds believeable, i think you can cat it [18:36] apw: so that's empty [18:36] likely not that then [18:37] well then there's /proc/driver/rtc [18:37] which has some stuff http://paste.ubuntu.com/15416793/ [18:38] but I've no idea what that means or if it's relevant [18:40] also, rtcwake -m show says "alarm: off" [18:40] that sounds definative to me [18:41] unless it is set by something at suspend time [18:41] which would be strange [18:46] disabling the XHC1 wakeup disables the open-lid-wakeup -.- [18:46] * mck182 wonders how did apple design this thing [18:46] with as little h/w as possible to make it cheap [18:51] looks like this bug btw https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1391476 [18:51] Launchpad bug 1391476 in linux (Ubuntu) "[MacBookPro11,1] Laptop wakes up while lid closed" [Medium,Expired] [18:52] mck182, sounds liek there is at least something to try in there [18:53] mck182, the echo thing, if that works then you could encode that in the pmsuspend world somewhere i am sure [18:53] apw: yeah it suggests disabling XHC1 from wakeup [18:53] which sounds rather similar to your problem [18:53] apw: but as I sad above, that also breaks lid-open wakeup for me ( ._.) [18:53] well presumably you open lid and hit function and win [18:54] or app or whatever dumb name the clover-leaf is called [18:54] 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] indeed [18:54] delbieratly by apple to make sure their own os is better [18:54] although disabling the XHC1 also disables keyboard wakup [18:55] so the only way is to hit the power button...no big deal but... [18:56] its prolly the touchpad, the screen touching it and waking the machine [18:56] you prolly have to turn the touchpad off somehow, and not the keyboard [18:56] hmmm [18:56] to get the mac behaviour [18:56] but they are renound for randomness, like to use the SD card slot [18:57] you have to power up the phy for the ethernet [18:57] lemme test suspending without the lid closed and pressing the touchpad if that actually wakes it [18:57] good idea [18:58] well, didn't even have to get close to the touchpad, it wakes up all on its own without touching anything [18:59] not that then, but to be honest you are likely to never have a fix for that unless someone gets epically lucky [18:59] yeah, I guess [19:00] such is the fate of those who buy macs :( [19:00] shame they are so nice [19:00] well fwiw I do have a 2011 mac as well and that one works 140% great [19:00] but true, they did design these new ones from scratch [19:01] the only way to keep ahead of linux :) [19:01] heh [19:01] I don't even consider them nice. They are impossible to work on and have everything soldered down on the mobo. [19:02] the latter is a real downside, but working on them...never had a problem really [19:02] and the touchpad is awesome [19:06] Kernel bisection sucks. This is going to take all weekend. :/ [19:06] mamarley, that sounds about right, builds are not quick [19:06] even with an enormous hoover [19:07] * mamarley has an i5-6600K box with an SSD. [19:07] It can definitely heat up the room when I compile stuff. I am glad I am not actually there right now. :) [19:09] mamarley, how long does a build take ... [19:09] 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] mck182, i've moved that bug back to Confirmed as you asre still seeing it [19:10] mck182, feel free to add some info there [19:10] apw: yeah, the mainline 4.5.0 kernel definitely still has it [19:10] I can share my findings in there, sure [19:10] if I can remember my login... :P [19:13] ok done [19:41] tested the latest xenial iso on a file server featuring a ARC1882 RAID controller - got weird timeout issues. [19:42] 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] 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] 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] will do tonight, thx! [19:46] apw: This build took 43m4.491s, though a good half of that it spent building the -dbg package. [19:46] Is there perhaps some way I can tell it not to build that particular package? [19:48] yep do_debug=false or something grep for debug in debian/rules [19:48] OK, thanks! [19:49] Except there is no debian/rules here, I am building the mainline kernel with deb-pkg... [19:50] Wait nevermind, there is a debian directory. [19:51] But it is very minimalistic and doesn't have anything about debug in it. [19:52] 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] ahh ok