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