| trippeh | Soval: pretty sure h264 requires UVC 2.0 support. mainline linux only supports 1.x mode | 00:02 |
|---|---|---|
| trippeh | for UVC cameras like the c930e that is | 00:03 |
| Soval | Okay. Thank you. I'm guessing that work is being done to add uvc 2.0 support down the line? I mean, it'll probably show up in a year or two, right? | 00:05 |
| trippeh | I did see some patches for it floating on some mailing list some months ago | 00:05 |
| Soval | So I'd probably have to find a patch or instructions on the internet for compiling my own kernel, if I want UVC 2.0 support, right now, right? | 00:08 |
| Soval | Not that I'm necessarily going to do that... I'm just wondering. | 00:09 |
| Soval | Okay. Thank you. | 00:10 |
| trippeh | Pretty much. And you'd be lucky if it applies to a current kernel. | 00:21 |
| guite | hello everyone, I’m currently trying to use message queues, my sample code is here http://pastebin.com/i4Q5PLKm and the call to mq_open is failing with the EMFILE code. This is a bit strange because “cat /proc/sys/fs/mqueue/msg_max” is 100 (I raised it for the test) and “cat /proc/sys/fs/mqueue/msgsize_max” is 8192 (not modified) | 09:34 |
| guite | Have you got any hint on why this is failing or what are the highest values I can set on msg_max and msgsize_max on my ubuntu | 09:35 |
| guite | ? | 09:35 |
| guite | any advice is welcome, don’t hesitate :) | 09:36 |
| apw | quite, it EINVALs for me on vivid | 09:43 |
| apw | guite, ^ | 09:43 |
| apw | ok with msg_max raised it does the same for me | 09:45 |
| guite | I tried to read the kernel code, I’m not familiar with it, the only reference to EMFILE I see is on a code I think that shouldn’t be called… | 09:47 |
| guite | in mqueue.c | 09:47 |
| apw | your mode being in decimal is most confusing | 09:51 |
| guite | yes sorry… | 09:52 |
| guite | it’s 600 | 09:52 |
| guite | I don’t know how to set it properly… maybe should I write 600o | 09:52 |
| apw | 0600 would be the normal form indeed | 09:54 |
| apw | guite, ok you are hitting your rlimit on message queue bytes | 09:57 |
| guite | (ok, I’m discovering this 0600 form to write octal code >_< don’t blame me please, I don’t write much C code) | 09:57 |
| apw | you have arbitrarily exactly hit the per process limit | 09:58 |
| guite | hmmmm… what is rlimit :s | 09:58 |
| guite | ? | 09:58 |
| apw | $ ulimit -q | 09:58 |
| apw | 819200 | 09:58 |
| guite | ha ha :D | 09:58 |
| guite | exactly | 09:58 |
| apw | process limits on "things" like open files, message queue reservations etc etc | 09:58 |
| guite | I swear I choosed 100 arbitrarily :D | 09:58 |
| guite | ok | 09:59 |
| apw | you happend to pick the exact limit, i switched it to 10 (also randomly) and it works | 09:59 |
| apw | you would want to either up the limit or drop your queue to 99 | 09:59 |
| guite | that’s nice, is it a way to raise this rlimit ? | 09:59 |
| apw | root can up the limit using ulimit | 09:59 |
| guite | yes | 09:59 |
| guite | apw: is there a C way to raise it… | 09:59 |
| guite | or I can ask google | 09:59 |
| ohsix | posix ipc is really not great, you should look for alternatives over knobs | 10:00 |
| apw | setrlimit | 10:00 |
| guite | ok thanks | 10:00 |
| apw | though you need to be priviledged to raise a limit, your program likely running as you won't be able to | 10:01 |
| guite | yes indeed | 10:01 |
| apw | you could also make the buffers smaller to get more of them | 10:01 |
| guite | in fact, I should more check this limit to adapt message sizes and count | 10:02 |
| guite | ohsix: I will check if there is a way we can use an alternative, thanks for the information | 10:03 |
| guite | apw: did you try the same code, rising the ulimit -q | 10:07 |
| guite | apw: someone tried for me and said he gets the same result | 10:07 |
| apw | nope, i just looked at the kernel code, and it checks against that limit | 10:07 |
| guite | (I’ll try too, but I’m trying to find the command-line for setrlimit) | 10:08 |
| guite | apw: could you give me the line and file in the kernel that performs this check ? | 10:08 |
| guite | I have a 3.13.0 kernel on my ubuntu | 10:09 |
| apw | guite, but i did just test it, and yes, if i raised the ulimit your 100/8192 version passes | 10:09 |
| guite | ok, I need to check, sorry :) | 10:09 |
| apw | guite, transcript of my test in pm | 10:10 |
| apw | guite, and this is the code which is tripping | 10:11 |
| apw | if (u->mq_bytes + mq_bytes < u->mq_bytes || | 10:11 |
| apw | u->mq_bytes + mq_bytes > rlimit(RLIMIT_MSGQUEUE)) { | 10:11 |
| apw | spin_unlock(&mq_lock); | 10:11 |
| apw | /* mqueue_evict_inode() releases info->messages */ | 10:11 |
| apw | ret = -EMFILE; | 10:11 |
| guite | ok, what I thought, thank you very much :) | 10:13 |
| apw | and whoever did your testing and said it didn't work ... be suspicious | 10:13 |
| ohsix | looks like people have used unix domain sockets and _seqpacket as alternatives (you can use peercred to see if they are supposed to be listened to) | 10:14 |
| guite | ohsix: in fact, we are more using python here, if we don’t find a wrapper for a library, we rarely code our own | 10:16 |
| guite | but I’ll check if there is a wrapper on unix socket, there should be one… | 10:17 |
| ohsix | may i ask what you need to do? | 10:17 |
| guite | I unfortunately don’t have all the information on this part of our code, in fact, it is another team that is working on it, but it seems they want processes to exchange files | 10:18 |
| apw | it is not clear why that would need such a very large buffer | 10:19 |
| ohsix | ah, you have a world of options nonetheless | 10:19 |
| guite | I don’t know how big… I suggested them to not touch ulimit and just use default parameters, but I wanted to understand a bit more | 10:19 |
| guite | apw: indeed :) | 10:19 |
| ohsix | there are lifecycle problems that are very annoying with posix ipc that you might only ignore if the way permissions work and how they're namespaced is useful | 10:19 |
| apw | of course i am hearing "exchange file descriptors" when you say exchange files, and that might not be so | 10:20 |
| guite | apw: I think not, I think they mean “real file like images for instances” | 10:20 |
| guite | apw: but let’s say I know too less about their needs | 10:21 |
| ohsix | there is object based storage stuff that are neat for vm images | 10:21 |
| guite | I know they had trouble with their message queues | 10:21 |
| apw | though sending a file descriptor over may well make sense, anyhow, not my problem :) that is user code, ick | 10:21 |
| * apw washes his hands obessivly ... | 10:22 | |
| guite | apw: thanks for the advice | 10:22 |
| amitk | can anybody point me to a ubuntu tarball for armhf (the whole desktop, not just ubuntu-core)? | 11:02 |
| ogra_ | amitk, i dont think anything like that exists anymore | 11:06 |
| ogra_ | arm UI stuff is all ubuntu-touch | 11:06 |
| amitk | ogra_: that's a shame, so the last tarball on this page is the closest? http://cdimage.ubuntu.com/ubuntu-touch/saucy/daily-preinstalled/20131127/ | 11:06 |
| ogra_ | amitk, no, thats touch | 11:07 |
| amitk | ogra_: ok, I guess i could apt-get install ubuntu-deskop from ubuntu-core | 11:08 |
| ogra_ | yeah | 11:08 |
| amitk | ... but that requires fixing networking first on this device | 11:09 |
| amitk | bah, I'll see if debian has something ready-to-use | 11:09 |
| NikTh | Hello, anyone knows how to prepare a git Ubuntu kernel in order to upload it in Launchpad ? Is there a script somewhere or a guide ? | 11:13 |
| NikTh | iirc there was a prepare-personal-ppa or something in earlier Ubuntu versions.. but I cannot see it right now. | 11:14 |
| ogra_ | amitk, use qemu-debootstrap and then chroot to install ubuntu-desktop ... tar it up and dump on SD | 11:15 |
| amitk | ogra_: that's a good idea | 11:16 |
| apw | NikTh, you need to make sure the tree is clean of extra files, then "clean" it to generate all the files with "debian/rules clean", then you can package it as normal "dpkg-buildpackage -S -nc" | 12:12 |
| NikTh | apw: Here http://pastebin.com/Hf1YqHeR . The comments with two hashes and capital letters are mine. When you have time to take a look.. Thanks. | 13:10 |
| NikTh | Maybe the raw format is better... for the eyes :-) http://pastebin.com/raw.php?i=Hf1YqHeR | 13:19 |
| apw | <<<<<<< HEAD | 13:31 |
| apw | looks like you didn't handle the cherry-pick right to me | 13:32 |
| apw | NikTh, ^ | 13:32 |
| NikTh | cherry-pick -m2 -x COMMIT | 13:32 |
| NikTh | then is asks me to add the files | 13:33 |
| NikTh | git add . | 13:33 |
| NikTh | and then | 13:33 |
| NikTh | cherry-pick --continue | 13:33 |
| NikTh | and it commits the files. | 13:33 |
| NikTh | I did the same for the upstream kernel (bug updated https://bugs.launchpad.net/linux/+bug/1386695) and it gave me no errors in the building | 13:34 |
| ubot5 | Ubuntu bug 1386695 in linux (Ubuntu) "[3.16.0-23] Resume from suspend/hibernation, GPU lock - possible regression" [Medium,Triaged] | 13:34 |
| apw | yeah but it only asks you to add the files when it _failed_ to apply correctly, and some action is required then | 13:34 |
| apw | in your case there is a merge failure marker in there <<<<< ===== and >>>>> mark the merge issue | 13:35 |
| NikTh | yes, the action it required is the cherry-pick --continues .. in order to commit the files. | 13:35 |
| apw | no the action it required was to fix the merge, add the files and continue | 13:35 |
| apw | you just did 2, and 3 | 13:35 |
| apw | as there is still a merge conflict marker in your log | 13:35 |
| apw | /tmp/buildd/linux-3.16.0/sound/soc/soc-compress.c:102:1: error: expected expression before '<<' token | 13:35 |
| apw | <<<<<<< HEAD | 13:35 |
| NikTh | So, there is a difference between Ubuntu git and lets say Linus git when you want to merge a commit ? | 13:36 |
| NikTh | I used the same method in the upstream kernel, and it didn't fail. | 13:36 |
| apw | yes, but that is because the commit happened to apply cleanly | 13:36 |
| apw | or possibly didn't but you arn't building the broken bits | 13:37 |
| apw | the ubuntu kernel is rather different from a vanilla kernel in the sense it has other things applied, stables, fixes, etc | 13:37 |
| apw | a cherry-pick which "works" does not ask you to add and continue, it just applies the fix cleanly | 13:38 |
| NikTh | Is there any other action needed after the cherry-pick --continue ? It showed me git status (working directory clean) | 13:39 |
| NikTh | But the same asked me on vanilla kernel. To fix the conflicts (with git add . ) and then cherry-pick --continue , | 13:39 |
| NikTh | but there has been worked without issues. I have built and installed the kernel and tested of course. | 13:40 |
| apw | then you must not be building that bit, as if it asks regarding conflicts the code is not compilable | 13:40 |
| apw | as git has shoved <<<<<< etc into the osurce, which is not valid C | 13:40 |
| NikTh | Yes, I thought of this, maybe I cant' merge this code into Ubuntu kernel, because of the ...code itself. It doesn't fit..or something. (I'm not codding by the way :-) ) | 13:41 |
| apw | whihc commit are you trying to apply to which kernel | 13:42 |
| NikTh | on 3.16.0-23.31 this one: http://tinyurl.com/ot59yh5 | 13:43 |
| NikTh | That's the actual commit that solves the problem in 3.17-rc7 | 13:44 |
| NikTh | Maybe I need to pick the specific patches only, (nouveau_fbcon.c ...etc) and apply them as a patches. | 13:45 |
| apw | NikTh, what is the commit id, that link isn't working for me | 13:46 |
| NikTh | apw: 7d1419f30cc5106196e54a282d7e115e698c95f6 | 13:48 |
| apw | yes it makes much more sense to cherry pick the two commits individually | 13:48 |
| apw | on the assumption your issue is an smbfs related one | 13:49 |
| NikTh | Yes, the second parent fixes the issue : 1209bbdff2f6bbffa6eb5823033bbd7b8799a5e2 | 13:49 |
| NikTh | Heh, I think is not. If you see the actual commit 1209bbd , you will see how many files unrelated with samba have been changed. Unrelated with samba but related with nouveau/drm | 13:51 |
| apw | nope that commit only affects fs/cifs/file.c | 13:53 |
| apw | the entire merge only pulls in cifs fixes, 2x to be precise | 13:54 |
| apw | i take i tyou have a graphics issue, have you files a bug on it? | 13:54 |
| NikTh | hmm, then something weird happened here, because I remember when I cherry-picked this commit, it pulled a bunch of files (nouveau_fbcon.c ..etc). | 13:57 |
| NikTh | up until to some samba related files. | 13:58 |
| apw | well you were cherry-picking a merge, so you get allll of its history, not just one commit which is what you are tryin to find in a bisect | 13:58 |
| apw | what is your bug | 13:58 |
| NikTh | 1386695 | 13:59 |
| NikTh | You will see the page there also, without tinyurl (maybe that's the problem and the page does not load). | 14:00 |
| apw | first bad commit: [5838ae610ff36777b8fce6f353c2417980c1a1fa] drm/nv50/disp: fix dpms regression on certain boards | 14:01 |
| apw | is that the sort of card you have ? | 14:01 |
| apw | and did you try just that commit cherry-picked ? | 14:02 |
| NikTh | Yes, I tested all the commits one by one up to the merge | 14:02 |
| NikTh | cherry-picked one by one, built, installed, tested.. nothing | 14:02 |
| NikTh | until this one with the merge. When I cherry-picked this one and built the kernel, then it has worked. | 14:02 |
| apw | that really doesn't tell you much as you merged in most of v3.17 final at that point | 14:03 |
| NikTh | What I thought yesterday and asked here (but probably you were not here), is if I tried to cherry-pick the 3 relevant (with my card and nouveau) commits together ? | 14:04 |
| apw | so your bisect took you to the first commit after v3.17-rc7, which seems unlikely, that osunds like the bisect going wrong to me | 14:05 |
| NikTh | doh! again ? :P | 14:05 |
| apw | the bisect claimed 5838ae610ff36777b8fce6f353c2417980c1a1fa was good, did you ever build and boot that to confirm it was good ? | 14:06 |
| NikTh | Yes, I began from this first bad (good) commit and up. | 14:07 |
| apw | you build that specific commit and it was successful | 14:08 |
| NikTh | one by one. cherry-pick , then build , then install.. the nothing | 14:08 |
| NikTh | Than it says so, as the other ones. | 14:09 |
| NikTh | That | 14:09 |
| apw | no not as a cherry-pick, did you actually test what the bisect claimed was the fix, in its original osition | 14:10 |
| NikTh | Yes, I have tested them all, after the cherry-pick, I have built the kernels again one by one with the bad(good) commits. | 14:10 |
| apw | git bisect bad 5838ae610ff36777b8fce6f353c2417980c1a1fa | 14:11 |
| NikTh | I have built almost 35-40 kernels in last 2 days :P | 14:11 |
| apw | so you said that one worked, and yet v3.17-rc7 didn't | 14:11 |
| apw | hmmm | 14:11 |
| NikTh | git bisect bad (without the number) | 14:11 |
| NikTh | git pick it up automatically, as I saw. | 14:12 |
| NikTh | What I want to test now, is if I cherry-pick 3 commits from the first bad and up, and combined ? | 14:13 |
| NikTh | I mean all the nouveau/drm related ones. | 14:13 |
| NikTh | I'm pretty sure that it's something to graphics related and nouveau specifically, because I have tested the resume/hibernate with nouveau blacklisted (vesa only) and it worked quite well. | 14:15 |
| apw | the chances are it is going to be the first drm/nouveau fix, which claims to fix lots of s/r races... though that commit completely rewrites the drivers, sigh | 14:15 |
| apw | 52 files changed, 875 insertions(+), 517 deletions(-) | 14:16 |
| apw | that is never going to make it into an older release | 14:16 |
| NikTh | The "fix regressions" or the "punt fbcon" ? | 14:16 |
| NikTh | Yeah, because 3.17-rc7 and 3.17 are too close each other, maybe it has worked there, but in an older kernel...hmm | 14:17 |
| apw | well the bisect says that you need the first commit in that sequence, but as that fix itself does not work you must need some of other commits to the same files, the issue is they mostly seem dependant on the first one, which is "a whole new notification system" which is massive | 14:19 |
| NikTh | The firs commit I have marked as bad (the merge one) is the first I cherry-picked , built and tested. From this point an on, all the other commits have been worked.. maybe I did something wrong ? | 14:19 |
| NikTh | I just followed your instructions.. cherry-pick bad (or good depends) , then build - install - test.. until the end. | 14:21 |
| apw | now i am confused as to what you did | 14:21 |
| NikTh | heah,heah.. | 14:21 |
| apw | you did the bisect which said you needed 5838ae610ff36777b8fce6f353c2417980c1a1fa | 14:21 |
| apw | what did you do after that | 14:22 |
| NikTh | if you look at the log , you will see the order I bisect the commits | 14:22 |
| NikTh | The first two commits did nothing, so I've marked them as good | 14:23 |
| apw | yes ... after the bisect completed and told you which commit it thinks fixes things ... what did you do then | 14:23 |
| NikTh | I have cherry-picked this one, (the first bad) and built - install - test the kernel. | 14:23 |
| apw | you cherry-picked it on top of what, 3.16 ubuntu ? | 14:24 |
| NikTh | And I did that for the other commits as well, one by one.. all the bad marked commits. | 14:24 |
| NikTh | no, on top of the good marked kernel which was v.317-rc7 | 14:24 |
| NikTh | good means bad of course (because of reverse bisect) | 14:25 |
| apw | ok it doesn't make sense to grab all of the "good" ones like that | 14:25 |
| apw | you are taking a random subset of changes based on the bisect stride | 14:25 |
| apw | after you checked out 3.17-rc7 and cherrypicked 5838ae610ff36777b8fce6f353c2417980c1a1fa ... that was a failure ? | 14:25 |
| NikTh | Yes, I didn't know that.. so I m sure I have built kernels in vain.. but it's ok. | 14:26 |
| NikTh | Yes it was. | 14:26 |
| apw | it did't fix it, ok | 14:26 |
| NikTh | Then I cherry picked the next in the row.. of course in v3.17-rc7 checkout.. and tried again..but it was a failure also.. | 14:28 |
| apw | ok this does not make sense | 14:28 |
| apw | you built and tested 5838ae610ff36777b8fce6f353c2417980c1a1fa and that worked | 14:28 |
| NikTh | Then the other one.. and again...failure | 14:28 |
| apw | you then reset to v3.17-rc7 and cherry-picked 5838ae610ff36777b8fce6f353c2417980c1a1fa on top and that did not work | 14:29 |
| apw | is that a correct statement | 14:29 |
| NikTh | Until I reached the 7d1419f30cc5106196e54a282d7e115e698c95f6 , and it was a success. | 14:29 |
| NikTh | reset ? | 14:29 |
| apw | you said you started from v3.17-rc7 and added just 5838ae610ff36777b8fce6f353c2417980c1a1fa and that was a failure | 14:29 |
| apw | (reset == make tree be at a specific commit) | 14:30 |
| NikTh | hmm, I don't remember if I did a reset, probably I didn't. | 14:30 |
| NikTh | GOD :P | 14:30 |
| apw | 14:24:46 NikTh | no, on top of the good marked kernel which was v.317-rc7 | 14:31 |
| apw | what did that mena you did do | 14:31 |
| NikTh | checkout v3.17-rc7 | 14:31 |
| NikTh | then cherry pick the first bad commit | 14:31 |
| apw | and htat did not work, and yet the build you did of the bisect at 5838ae610ff36777b8fce6f353c2417980c1a1fa did ? | 14:32 |
| NikTh | but then, I didn't reset , I just continued to the second cherry-pick | 14:32 |
| apw | that doesn't matter as those do not make sense anyhow | 14:32 |
| apw | i need to bottom out on this testing as you say you | 14:32 |
| apw | built and tested 5838ae610ff36777b8fce6f353c2417980c1a1fa and that worked (in the bisect) | 14:33 |
| NikTh | Ok, give me the command , after bisect. The bisect is over..lets say is correct. | 14:33 |
| apw | and you "git checkout v3.17-rc7 && git cherry-pick 5838ae610ff36777b8fce6f353c2417980c1a1fa" and that build did not | 14:33 |
| apw | is that what you are saying | 14:33 |
| NikTh | Yes. | 14:33 |
| apw | ok then something is wrong with your methodology, as that simply cannot make sense | 14:34 |
| apw | as 5838ae610ff36777b8fce6f353c2417980c1a1fa is the very next comit after v3.17-rc7, so those trees | 14:34 |
| apw | would be identicle, and the binaries the same and the result, neceearily the same | 14:34 |
| NikTh | After the bisect, what is this reset command you said before ? | 14:35 |
| apw | git checkout v3.17-rc7 would have done the same, though leaving you lost not on a branch | 14:35 |
| apw | which for these purposes does not matter | 14:35 |
| NikTh | Ok, I will try it again.. maybe I was wrong. I remember I did a checkout, but I will do it again, second time, just to be completely sure | 14:36 |
| NikTh | git checkout v3.17-rc7 && cherry-pick -x COMMIT | 14:37 |
| apw | your other option is to take jsalisbury up on his offer to help with the bisect | 14:37 |
| NikTh | and then I will build the kernel again | 14:37 |
| apw | he has a fast build box at his disposal | 14:38 |
| NikTh | Yes, I didn't reject his offer :-) | 14:39 |
| apw | i didn't read it such that you were asking for it either, so i am sure he'll be assuming he has to do nothing :) | 14:39 |
| NikTh | heah.. ok. I will try again with the building.. and when I see him here I will tell him, or I will leave a comment at the bug report. | 14:41 |
| apw | luck | 14:42 |
| NikTh | apw: Thanks again for you patience .. I have to go away for now.. I will come back later :-) | 14:43 |
| stgraber | apw: hey, so I'm testing the 3.16 lts backport on trusty (from the PPA) and I'm getting about one oops a second, I'm assuming someone on your team would want to hear about that? :) | 14:45 |
| stgraber | (I may still stick with that kernel for now because one oops a second beats btrfs hanging every couple of hours so far) | 14:46 |
| apw | stgraber, yep we'd want to hear about that | 14:46 |
| apw | please do file bugs against linux-lts-utopic if it will let you | 14:47 |
| apw | and give us the numbers here | 14:47 |
| stgraber | apw: can't file bugs from that box since LP doesn't do IPv6 and that's on an IPv6 only subnet, but I'll file one manually | 14:49 |
| stgraber | a 10min kernel.log looks like: https://dl.stgraber.org/oops-3.16-trusty.log | 14:49 |
| stgraber | oh, those aren't oops actually, just warnings, but still, lots of them :) | 14:50 |
| rtg | stgraber, what kind of NIC ? | 14:51 |
| apw | in theory you can "pot" them i think | 14:51 |
| rtg | guess I could look | 14:51 |
| apw | yeah ... offload failures | 14:51 |
| rtg | igb | 14:52 |
| apw | stgraber, ok you are getting those for each and every packet you send i think, luckily they are rate limited to 1/s | 14:53 |
| * rtg wonders if there is a knob to turn off GRO | 14:53 | |
| rtg | otr rather, transmit offload | 14:54 |
| stgraber | rtg: Intel I350 | 14:54 |
| stgraber | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1388118 | 14:54 |
| ubot5 | Ubuntu bug 1388118 in linux (Ubuntu) "linux-lts-utopic-3.16 spamming dmesg with warnings every few seconds in skb_warn_bad_offload" [Undecided,New] | 14:54 |
| apw | stgraber, is this box fungible, can you test kernels easily ? | 14:57 |
| stgraber | apw: yeah, I don't mind rebooting it | 14:58 |
| rtg | apw, are you thinking about having him try the 3.16.7 kernel ? | 14:59 |
| apw | rtg, well i was going to look at the delta first, but leaning to that | 14:59 |
| rtg | apw, Utopic master-next has 3.16.[5,6,7] stacked up. maybe something in there would help. | 15:00 |
| apw | of IP_CSUM/IPV6_CSUM. The same is needed in netif_skb_features() | 15:00 |
| apw | in order to avoid offloading mismatch warning when vlan is | 15:00 |
| apw | that sounds slightly suspicious | 15:00 |
| apw | thouhg i think it requires a bond which stgraber prolly doesn't have | 15:02 |
| apw | hmmm | 15:02 |
| rtg | apw, yeah, I think trying a 3.16.7 mainline kernel makes sense. there are quite a few net bug fixes sine the last Utopic kernel was released | 15:02 |
| apw | rtg, ack i'll build some test kernles for him now | 15:02 |
| rtg | apw, don't we have a vanilla mainline already ? | 15:03 |
| stgraber | apw: I sure do have a bond on there | 15:03 |
| stgraber | apw: that server has two bonded gigabit NICs, then about a dozen vlan on top of that and each vlan is then bridged into its own bridge with a bunch of containers and vms in each of those | 15:03 |
| apw | rtg, yeah we do, but knowing stgraber he is using everything we add on | 15:04 |
| rtg | yeah | 15:04 |
| apw | stgraber, ok then you are likley hitting that bug ... i'll get you a kernel to test | 15:04 |
| stgraber | apw: thanks | 15:04 |
| === Trevinho_ is now known as Trevinho | ||
| cmagina | what is the abi version for the trusty-updates kernel. seems to be something strange with the meta package being 39.46 and the image package being 39.66 | 15:28 |
| rtg | cmagina, the last number of those versions are the upload number and are unrelated. the only import number is the ABI | 15:33 |
| rtg | i.e., the first number | 15:33 |
| cmagina | rtg: ah, ok, thanks for the info | 15:39 |
| apw | stgraber, ok http://people.canonical.com/~apw/lp1388118+lts-backport-utopic-trusty/ has the likely fix applied, if that shuts your machine up then the next upload will too :) | 15:44 |
| stgraber | apw: ok, kernel installed. Waiting for a Jenkins build to finish before I reboot. | 15:53 |
| ppf | hi, trying to build a kernel with a new custom flavour | 16:03 |
| ppf | quite late during compilation i get "previous or current modules file missing!" | 16:04 |
| ppf | what did i miss? | 16:04 |
| apw | ppf, you need the abi files (debian.<branch>/abi/*) for the previous build, or as in your case there is no such thing, you need to mark them to skip | 16:13 |
| NikTh | ppf https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Module_lists | 16:14 |
| ppf | can't i copy the abi files from somewhere? | 16:15 |
| ppf | or shouldn | 16:15 |
| ppf | 't one do that | 16:15 |
| NikTh | ppf : https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Overriding_ABI_check_failures | 16:16 |
| NikTh | apw: Guess what.. | 16:17 |
| NikTh | Just finished the second build. The first was a failure for me, again. Then one with 5838ae610ff36777b8fce6f353c2417980c1a1fa , was a failure. | 16:18 |
| NikTh | In the second build I combined the 3 relevant commits (cherry-pick them together) and the test is successful ! | 16:19 |
| NikTh | 634ffcccfbe59d77652804e1beb415d3329b1bc6 , f2f9a2cbaf019481feefe231f996d3602612fa99 , 5838ae610ff36777b8fce6f353c2417980c1a1fa | 16:19 |
| apw | and you built those against v3.17-rc7 ? or ? | 16:21 |
| NikTh | So maybe needs the 3 commits combined in order to work. This is not too much code (changes,deletions,additions), and maybe it could merge them to an Ubuntu kernel | 16:21 |
| NikTh | Yes, against v3.17-rc7 | 16:22 |
| NikTh | This time I "git reset --hard" to be sure :) | 16:22 |
| NikTh | I think these three commits could made it into Ubuntu kernel. I will try later, to build 3.16-current with these commits. | 16:23 |
| NikTh | I will update the bug, if you agree, just to inform for the developments here. | 16:24 |
| apw | yeah shove that info in, i'll se if those three will apply on 3.16 | 16:25 |
| NikTh | Ok. | 16:25 |
| stgraber | apw: dmesg looks good | 16:37 |
| apw | stgraber, awsome, will mark the bug up apropriatly, that will be fixed in the next upload, and i assuem the current version isn't going out anyhow | 16:37 |
| apw | stgraber, actually as lts-utopic is in a bit of limbo, it might not be the "next", it might be the one after, but its coming | 16:47 |
| apw | NikTh, ok shortly there will be some kernels in http://people.canonical.com/~apw/lp1386695-utopic/ to test. one of the fixes you identified actually isn't applicable back in U and i have pulled in a foundational patch for antoher. i actually suspect (and likely will test) only the last two are needed. | 17:45 |
| apw | NikTh, anyhow give that one a whirl and let me know | 17:45 |
| NikTh | apw: Now I saw your message and right now I'm building the same Kernel as you, I assume. The commit that break things in building (for me) is f2f9a2cbaf019481feefe231f996d3602612fa99 | 18:10 |
| NikTh | apw: so I'm building with the other two..but of course I will test yours as well. | 18:10 |
| NikTh | Thanks | 18:10 |
| === freyes is now known as zz_freyes | ||
| NikTh | apw: My build failed, once again, another bit of C broke it. | 18:30 |
| NikTh | <apw> as git has shoved <<<<<< etc into the osurce, which is not valid C | 18:30 |
| NikTh | But your kernel WORKS !! :-) | 18:30 |
| NikTh | You detected the correct .patches .. :-) | 18:31 |
| apw | yes i had to pull another commit in, and backport the other one ... | 18:31 |
| apw | so you booted that one ok yes ? | 18:31 |
| apw | i'll do another one without the extra patch in a sec | 18:31 |
| NikTh | Yes, booted, tested, and resume works. | 18:32 |
| * NikTh waiting for the next kernel | 18:32 | |
| apw | ok good, we are making some progress, wel done for finding that triumvate of fixes | 18:32 |
| NikTh | Nah.. without your help I would probably give up. | 18:34 |
| apw | NikTh, kernels are syncing now, will be about another 5m, will be in http://people.canonical.com/~apw/lp1386695-2-utopic/ | 18:47 |
| apw | note that this is a _new_ directory | 18:47 |
| apw | i am hopful this simpler one will also fix your issue ... and make life easier for SRUing | 18:49 |
| * NikTh downloading :-) | 18:49 | |
| apw | let me know if that one works, here | 18:50 |
| NikTh | Ok | 18:53 |
| NikTh | apw: Yes, it works pretty well :-) | 18:56 |
| rtg | apw, uploaded Utopic LTS | 19:11 |
| apw | NikTh, great ... | 20:06 |
| apw | rtg, excellent, to the ppa or archive | 20:07 |
| rtg | ppa | 20:07 |
| apw | ack, ta | 20:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!