[08:01] rozie: hi! i've just commented bug #1492146 about a new kernel available in -proposed [08:01] bug 1492146 in linux-lts-utopic (Ubuntu) "igb Detected Tx Unit Hang" [High,Confirmed] https://launchpad.net/bugs/1492146 [08:01] rozie: it would be great if you could check if that kernel fixes the issue [08:04] gimme like... 15 minutes [08:08] rozie: awesome! thanks ;) [08:18] henrix: can you give me direct link to packages? I see it's in the proposed, but would like to avoid adding repos [08:26] rozie: here's the links: [08:26] http://archive.ubuntu.com/ubuntu/pool/main/l/linux-lts-utopic/linux-image-3.16.0-49-generic_3.16.0-49.65~14.04.1_amd64.deb [08:26] http://archive.ubuntu.com/ubuntu/pool/main/l/linux-lts-utopic/linux-image-extra-3.16.0-49-generic_3.16.0-49.65~14.04.1_amd64.deb [08:26] rozie: not sure if at this moment you care about other packages (headers, for example) [08:27] thx. I dont care about headers. just got lost in complicated Ubuntu repo structure ;/ [08:28] rozie: heh, no prob [08:28] just kidding, but got use to Debian, as it's my primary OS and Ubuntu is... different [08:29] but haven't found this kernel on packages.ubuntu... [08:30] anyway, rebooting... [08:33] looks fine at first glance, but let it work for 5 mins [08:35] rozie: sure, not in a rush. I really want to make sure the bug is fixed ;) [08:35] henrix, was that the wholesale revert ? [08:36] apw: yep [08:36] apw: 14 patches being revert [08:36] ouch [08:37] did the bug get shoved out of fix-released at the saem time ? [08:38] we'll need to take another look at these backports. and... i'm not sure i changed it to 'triagged' again (although i remember i commented on the bug) [08:38] * henrix goes check [08:39] henrix, thanks ... i'd not want that to get lost as a result [08:40] apw: no, iirc joe is currently working on that bug so he probably actually changed it back [08:42] 523 packets transmitted, 523 received, 0% packet loss, time 526808ms - looks fine :-) [08:43] rozie: awesome! thanks for testing ;) [08:44] rozie: would you please add a comment to the bug, and change the 'verification-needed-trusty' to 'verification-done-trusty' tag? [08:44] rozie: (i can do that for you if you're busy) [08:46] already commented, pls change tag [08:47] rozie: cool, thanks [08:47] infinity: fyi ^^ [10:52] Hi, I don't remember who handles the virtualbox kernel modules [10:52] but virtualbox 5.0.4 is out, claiming full compatibility with kernel 4.2 [10:52] you might want to sync changes [10:58] LocutusOfBorg1, sounds good, thanks [10:58] LocutusOfBorg1, mostly i do for what it is worth [13:30] Anyone noticed massive slowdown on 4.2? My desktop is pretty much unusable while doing IO [13:31] 15s to open a terminal [13:44] i've noticed something similar, building a kernel and doing anything is very sluggish [13:48] popey, I'll sort out some testing against 4.2 and see what's going on [13:49] popey, what's your config in terms of system / CPUs/ HDD/SSDs etc [13:51] and what kind of I/O are you doing? [13:52] tjaalton, you ought to be able to provide some numbers if you're doing builds. [13:52] that seems pretty deterministic [13:54] numbers? [13:54] cking: i7 / one HDD (spinning rust) / 8GB RAM [13:54] I have ivybridge, 240GB ssd, but home is on btrfs.. [13:54] only thing it's doing is an rsync backup to another machine over gbe [13:54] kernel trees on ssd [13:54] sandybridge cpu, ext4 filesystem [13:54] tjaalton, build times with 4.1 v.s. 4.2 ? [13:55] why does my heart sink when btrfs is mentioned... [13:55] backup seems to be chugging along, load average is 4.5 [13:55] ah, well the build is fine I think, just that doing anything interactive at the same time is sluggish [13:55] no btrfs here :) [13:55] cking: hehe [13:56] ok, let me do ext4 first as that's our default ;-) [13:56] thanks [13:56] np [13:56] cking: https://i2.wp.com/ak-hdl.buzzfed.com/static/2014-10/7/19/enhanced/webdr05/anigif_original-grid-image-18241-1412725925-4.gif [13:57] hrm [14:00] cking: just visualising the the heart sinking :) [14:00] ah, yes ;-) [14:04] more specifically, my $HOME is on a four-disk btrfs HDD RAID [14:04] raid10-ish [15:09] thanks apw [15:14] apw, where are the sources for the module? [15:14] here? http://kernel.ubuntu.com/git/ubuntu/linux.git [15:15] LocutusOfBorg1, so we update the module directly from the binaries the dksm package produce [15:15] though right now i assume we ahve it patched locally [15:15] so you provide a .ko module? [15:16] thanks [15:16] yes [15:16] but we need the real dkms package updated, which i htink was what you were telling me i hsould (and will) do [15:16] I thought you were copy-pasting the sources in the kernel tree and providing a build during install :) [15:16] exactly, I guess this is the best way to do [15:16] like we do with vbox-dkms [15:17] having them inside the kernel is really awesome :) [15:18] we are indeed pasting in the sources, but i do that from the result of the virtualbox package making the source for the dkms package [15:18] if any of that makes any sense [15:18] yeah needed for some clouds apparently [15:46] popey, i've kicked of a range of file systems tests, i'll get back to you once they are complete (probably next week) [15:46] s/of/off [15:48] cking: super, thanks [18:59] Hi. Old kernels aren't being autoremoved despite being marked as auto and not being in "APT::NeverAutoRemove"... any hint on how can I debug this issue? [19:03] debugging autoremove I can see this lines [19:03] Following dep: systemtap:amd64 2.3-1ubuntu1 Suggests linux-image:amd64 , provided by linux-image-3.2.0-59-generic:amd64 3.2.0-59.90Marking: linux-image-3.2.0-59-generic:amd64 3.2.0-59.90, Curr=3.2.0-59.90, Inst=3.2.0-59.90 [19:04] it's like the old kernel aren't removed because they're suggested by systemap [19:07] those all do provides:linux-image .... infinity ^ [19:12] apw: systemtap's dep is bogus. [19:12] "we recommend you have a kernel installed" is about the most useless dep I can think of. [19:12] "Depends: computer". [19:12] yeah it cirtainly is ... [19:12] ok so we should get that ripped [19:13] rul_, can you file a bug against systemtap please and tell me the number [19:13] rul_: To confirm, if you remove systemtap, do kernels autoremove happily afterward? [19:16] apw: It's also possible that our provides is a bit overzealous there, and we should be providing virtuals like linux-image and linux-headers from the metapackages instead of the real packages. [19:16] apw: But can't go back in time and fix all the old kernels to do that. [19:20] infinity, moving the provides to the to the meta-pacakge is an interesting idea [19:23] apw: It would get us the behaviour we'd prefer if something did depend on one of those virtuals. We don't want a one-off ABI-versioned package installed, we want the meta, so people actually get upgrades. [19:23] infinity, yes, seems appropriate [19:23] apw: (I still think it's a bug for anything to depend on the virtuals anyway, but some stuff from Debian does, and it's not worth the delta to fix them all) [19:24] when rul_ gives me his bug, i'll file one off that for linux/etc to move them [19:24] apw: Anyhow, only something we could fix for >= wily, since stable releases have tons of kernels with the provides already baked in. [19:31] infinity, right get it fixed before the next lts [20:27] yup, I've marked systemtap package as auto and suddenly all old kernels can be autoremoved [20:27] filling the bug [20:45] #1494481 [20:47] bug #1494481 [20:47] bug 1494481 in systemtap (Ubuntu) "linux-image Suggests cripples old kernel cleanup" [Undecided,New] https://launchpad.net/bugs/1494481