[17:09] <tseliot> apw: I'm uploading nvidia 340 and 346 (and their -updates flavours). They all have patches to support linux 3.19 but they will need somebody to approve them when they end up in NEW
[17:19] <cristian_c> tseliot, apw I've found the regression commit
[17:19] <cristian_c> a strange thing happens
[17:20] <cristian_c> 3.13.0rc1 is not affected from regression
[17:20] <cristian_c> 3.13.0rc2 breaks all
[17:20] <cristian_c> wifi button is not working anymore
[17:20] <cristian_c> and strange events happen
[17:21] <cristian_c> same situation with 3.13.0rc3
[17:21] <cristian_c> in 3.13.0rc5 the regression appears
[17:22] <cristian_c> tseliot, apw I've looked at the CHANGES files
[17:22] <cristian_c> and i've found:
[17:23] <cristian_c>       hp-wmi: detect "2009 BIOS or later" flag by WMI 0x0d for wireless cmd
[17:23] <cristian_c> for rc2
[17:24] <cristian_c> and:
[17:24] <cristian_c>       drivers: phy: Fix memory leak
[17:24] <cristian_c> for rc5
[17:27] <tseliot> cristian_c: sorry but I'm not a kernel engineer. You definitely want somebody from the kernel team
[17:28] <cristian_c> tseliot, can I ask info for the report, anyway?
[17:29] <cristian_c> I've to report to kernel mantainers
[17:29] <brightkn1> Gardener around
[17:29] <brightkn1> ?
[17:30] <apw> jsalisbury, ^^ that looks like somethign we could do a bisect for to confirm the commit at issue in 3.13-rc5
[17:30] <apw> brightknight314, as in Tim ?  he likely is not
[17:30] <cristian_c> apw, I've found the regression commit, anyway
[17:30] <cristian_c> :)
[17:30] <cristian_c> trying various mainline kernels
[17:31] <apw> How do you know it is the ones you have picked out ?
[17:31] <brightknight314> Yes Tim.
[17:31] <brightknight314> apw: the update server is broke, secure this machine.
[17:32] <cristian_c> apw, I've not understood very well (I don't know if you are talking with me)
[17:32] <brightknight314> I don't like when remote admins abandon work.
[17:32] <brightknight314> Leave a bunch of sockets hanging open.
[17:33] <apw> cristian_c, you say you tested -rc4 and -rc5 and then jump to a specific commit as at issue in that range, and i am wondering why that one is the one you picked
[17:33] <brightknight314> Leaves a bunch of sockets hanging open.
[17:34] <brightknight314> apw: ssh in and install the updates
[17:34] <apw> brightknight314, ok Tim isn't likely to be about
[17:34] <cristian_c> apw, rc4 is not present in mainline (rc4 contains only the alldeb package)
[17:34] <brightknight314> The machine admin bailed.
[17:34] <cristian_c> apw, anyway the commit is an hypothesis
[17:34] <brightknight314> apw: Why is Tim unlikely to be about?
[17:34] <cristian_c> apw, for commit, I mean the COMMIT file
[17:34] <cristian_c> :)
[17:35] <cristian_c> apw, http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc2-trusty/COMMIT
[17:35] <apw> cristian_c, right ... and jsalisbury is a wizard at doing bisects to a specific change in the range, and can help do the last bit for you
[17:35] <cristian_c> apw, ok
[17:35] <tjaalton> sigh, 3.18 is quite eager on disk cache.. 10GB used for it and apps failing because of OOM
[17:36] <apw> tjaalton, try v3.19 in the CKT PPA
[17:36] <tjaalton> yeah I've got it installed, just need to reboot.. hope it helps
[17:36] <apw> brightknight314, he just isn't likely to be here at the moment
[17:36] <apw> brightknight314, and i don't think other than that i understand your question
[17:38] <brightknight314> Does apw do kernel hacking?
[17:39] <apw> many of the people here are experience in kernel topics
[17:39] <brightknight314> plug in
[17:40] <brightknight314> apw: hurry up
[17:40] <jsalisbury> apw, cristian_c I'd be happy to help with a bisect
[17:41] <cristian_c> jsalisbury, ok
[17:42] <jsalisbury> cristian_c, is there a bug open ?
[17:42] <cristian_c> jsalisbury, on launchpad, yes
[17:42] <cristian_c> jsalisbury, but today I've found the kernel version that breaks all
[17:43] <cristian_c> and the beginning version of the regression
[17:43] <apw> cristian_c, it just makes jsalisbury life easier if he has the lp# to work against, keeps them straight when doing mroe than one
[17:43] <cristian_c> but I've to do tow reports
[17:43] <jsalisbury> cristian_c, great.  The bug is helpful to keep track of where we are in the bisect.
[17:43] <cristian_c> one for the original bug and one for the regression
[17:43] <cristian_c> ok, I post the lp url
[17:44] <jsalisbury> cristian_c, ok, I've probably already commented on it, but don't remember :-)
[17:44] <brightknight314> apw: plug in
[17:44] <cristian_c> jsalisbury, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
[17:44] <cristian_c> jsalisbury, but I've to report upstream
[17:45] <cristian_c> jsalisbury, I've already prepared the information collected in kernel.org format, for the original bug
[17:46] <jsalisbury> cristian_c, ok.  if you can post the last kernel version that did not have the bug, and the first that does, I can start a bisect
[17:46] <jsalisbury> cristian_c, a bisect will tell us the exact commit that is causing it
[17:46] <cristian_c> and today I've found the kernel beginning with the regression
[17:47] <jsalisbury> cristian_c, and it's usually good to test the lastest mainline kernel, just to see if the bug was already fixed.  Then we can find the commit that fixes it
[17:47] <cristian_c> jsalisbury, the original bug has always been
[17:48] <cristian_c> jsalisbury, no, the original bug has never not been fixed
[17:48] <cristian_c> original bug exists from many years
[17:49] <jsalisbury> cristian_c, ok, but you now know that last 'good' kernel and the first 'bad' one?
[17:49] <cristian_c> jsalisbury, for the original bug doesn't exist a last good
[17:49] <cristian_c> jsalisbury, for the regression I can say it
[17:50] <cristian_c> 3.13.0rc1 not affected
[17:50] <cristian_c> 3.13.0rc5 affected
[17:50] <cristian_c> 3.13.rc2 and 3.13rc3 broken
[17:51] <cristian_c> *3.13.0rc5 and further
[17:51] <cristian_c> *3.13.0rc1 and previous
[17:51] <jsalisbury> cristian_c, broken, meaning they have the bug too, or they have another bug and you can't test them?
[17:52] <cristian_c> jsalisbury, today, I've found that rc2 and rc3 have strange behavours
[17:52] <cristian_c> the wifi connection doesn't work anymore if I press the wifi button
[17:53] <cristian_c> but this issue is limited to these two releases
[17:53] <jsalisbury> cristian_c, are you able to tell if rc2 and rc3 exhibit bug 972604 ?  Where the wireless led does not switch colors ?
[17:54] <cristian_c> 3.13..0rc1 and previous are affected from the original bug
[17:54] <cristian_c> 3.13.0rc5 and further are affected from original bug + regression
[17:54] <cristian_c> jsalisbury, rc2 and rc3 are unusable for this test
[17:55] <cristian_c> because they break other things
[17:55] <jsalisbury> cristian_c, do you have a bug number for the 'original' bug ?
[17:55] <cristian_c> as the wifi connection itslef
[17:55] <cristian_c> *itself
[17:55] <cristian_c> jsalisbury, I've reported both in that launchpad report
[17:56] <cristian_c> jsalisbury, regression is reported in the #21 comment
[17:56] <cristian_c> at the same page
[17:57] <cristian_c> jsalisbury, that launchpad report was created for the original bug
[17:57] <cristian_c> while I was testing the new kernels, I've found the regression
[17:57] <cristian_c> comment #21
[17:59] <jsalisbury> cristian_c, ok, so you are seeing a new regression as of 3.13.0-031300rc5, but it sounds like this version is also exhibiting the 'original' bug ?
[17:59] <cristian_c> yes
[17:59] <cristian_c> exactly
[18:00] <cristian_c> so, I was told to open two upstream reports
[18:00] <cristian_c> instead only one
[18:00] <cristian_c> one for the original, the other for the regression
[18:00] <jsalisbury> cristian_c, and version 3.13.0rc1 also has the 'original' bug?  
[18:00] <cristian_c> yes
[18:01] <cristian_c> jsalisbury, all the kernel versions are affected by the original bug
[18:01] <cristian_c> I' tried also 2.6.x
[18:01] <cristian_c> for test
[18:02] <jsalisbury> cristian_c, ok, so it sounds like we would not be able to bisect, since the original bug always happened.  Can you give this kernel a test:
[18:02] <jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/
[18:02] <cristian_c> jsalisbury, comment #6
[18:02] <cristian_c> *26
[18:02] <cristian_c> jsalisbury, I've tried the 3.19 rc6
[18:02] <cristian_c> and I've collected the information in kernel format for 3.19 rc6
[18:03] <cristian_c> as described in the ubuntu wiki page
[18:03] <jsalisbury> cristian_c, ahh, ok and that was to report the bug upstream?
[18:03] <cristian_c> jsalisbury, I was told to report the bug upstream
[18:03] <cristian_c> jsalisbury, but I've to execute the step 2
[18:04] <cristian_c> Second step: E-mail the maintainer mailinglist with Kernel.org format
[18:04] <cristian_c> jsalisbury, I've to find the maintainer mailing list for the original bug
[18:05] <cristian_c> Not graphics card driver bug
[18:05] <apw> cristian_c, it would be helpful to know exactly which fix broke things for you, which is what a bisect will do
[18:05] <jsalisbury> cristian_c, you have not been able to find the maintainers email address ?
[18:05] <cristian_c> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS
[18:05] <cristian_c> apw, ah, ok
[18:05] <apw> cristian_c, as the maintainer will change depending on wherre the fix was
[18:06] <cristian_c> jsalisbury, apw I'd be happy to know how to do it
[18:06] <cristian_c> apw, ok
[18:07] <cristian_c> apw, so, i've to find the fix
[18:07] <cristian_c> for the regression
[18:07] <jsalisbury> cristian_c, ok, I think we can bisect for the 'second' issue
[18:07] <cristian_c> apw, but for the origjnal bug, what have I to do?
[18:09] <jsalisbury> cristian_c, the 'original' bug will be difficult to track down, since we don't know when it started(It sounds like it always existed).  But bisecting the second issue, might tell us which files were changed that caused the regression.  That will then tell us who the maintainer is
[18:09] <cristian_c> apw, for the regression, I've found some interesting lines in CHANGES files (rc2 and rc5) but they are hypothesis
[18:10] <cristian_c> jsalisbury, ok
[18:10] <cristian_c> jsalisbury, for the original bug, I think it always existed too
[18:11] <jsalisbury> cristian_c, Can you test the 3.19 'final' kernel to see if the second issue still happens:
[18:11] <jsalisbury> cristian_c, it is available here:
[18:11] <jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/
[18:11] <cristian_c> jsalisbury, ok, I test it, anyway it will surely happen :P
[18:11] <jsalisbury> cristian_c, if it does still happen, we can bisect the earlier 3.13 kernels.  If it is fixed, we can then "Reverse" bisect to find what fixes it.
[18:12] <cristian_c> I download it immediately
[18:12] <jsalisbury> cristian_c, great thanks.  If it still has the bug, I'll start a bisect and build some test kernels
[18:13] <cristian_c> ok
[18:14] <brightknight314> When is Tim around?
[18:14] <jsalisbury> cristian_c, we can focus on the second issue, which is a regression.  Finding what commit caused the second regression, may provide some insights into the original issue.
[18:15] <cristian_c> jsalisbury, probably the regression is a fix for the rc2 and rc3 issues
[18:15] <brightknight314> Is Tim around?
[18:16] <apw> brightknight314, there is no likelyhood of tim being around
[18:16] <brightknight314> Did Tim pass on?
[18:18] <apw> brightknight314, waiting for him is not going to be a profitable use of your time, if you have a question then ask it
[18:19] <cristian_c> jsalisbury, ok, download is finished, now I install the three packages
[18:20] <jsalisbury> cristian_c, great.  you should only need this one: 
[18:20] <jsalisbury> linux-image-3.19.0-031900-generic_3.19.0-031900.201502091451_amd64.deb
[18:20] <jsalisbury> cristian_c, oh, what you have 32 bit
[18:20] <jsalisbury> cristian_c, this one then:
[18:20] <jsalisbury> 	linux-image-3.19.0-031900-generic_3.19.0-031900.201502091451_i386.deb
[18:21] <cristian_c> jsalisbury, mmm, I'm installing also the headers
[18:25] <cristian_c> jsalisbury, ok, installed, I'm rebooting
[18:25] <cristian_c> now, I test the regression
[18:29] <cristian_c> jsalisbury, 3.19 stable similar issues as 3.13rc2 and 3.13rc3
[18:29] <cristian_c> I try to reboot in a previous version
[18:31] <jsalisbury> cristian_c, ok, thanks for testing.  Similar issues, meaning it has the regression, or other problems that cause you not to be able to tell?
[18:33] <cristian_c> jsalisbury, I'm trying again the last kernels installed
[18:33] <jsalisbury> cristian_c, ok
[18:35] <cristian_c> JanC, I can tell more
[18:36] <brightknight314> apw: When was Tim last seen?
[18:36] <cristian_c> jsalisbury, I can tell more: I notice that in 3.19rc6 and 3.19 stable now, and also in 3.13.0rc2 and rc3, I see in rfkill list the lack of hp-wifi interface
[18:37] <cristian_c> jsalisbury, but there is only phy0
[18:37] <cristian_c> jsalisbury, if for example immeditely after login I type: dmesg | tail in a terminal, I get a (back)trace
[18:37] <cristian_c> simlar to a crash/kernel panic / etc...
[18:38] <cristian_c> now, i try again with 3.19 stable
[18:38] <jsalisbury> cristian_c, and 3.13-rc1 does not exhibit this?
[18:38] <cristian_c> jsalisbury, 3.13.0rc2 and 3.13.0rc3 have also only phy0 in rfkill list output
[18:39] <cristian_c> jsalisbury, I know that rc1 has got phy0 and hp-wifi interfaces, but I boot now in rc1 also
[18:39] <jsalisbury> cristian_c, great, we may now be getting somewhere :-)
[18:41] <cristian_c> jsalisbury, ok, tried now, 3.19 the same as 3.19rc6, trace with ioctl  lines
[18:41] <cristian_c> and phy0 only
[18:41] <cristian_c> now, I try again with 3.13.0rc1
[18:42] <jsalisbury> great
[18:44] <cristian_c> jsalisbury, ok, 3.13.rc1 tried now
[18:44] <cristian_c> jsalisbury, dmesg | tail does not show trace
[18:44] <cristian_c> and there are both hp-wifi and phy0 interfaces in rfkill list output
[18:45] <jsalisbury> cristian_c, great, so I think we should bisect between 3.13-rc1 and 3.13-rc2.  I'll start the bisect and build the first test kernel.
[18:45] <cristian_c> jsalisbury, now, I test again the original bug and the regression in rc1
[18:45] <cristian_c> jsalisbury, ok
[18:50] <cristian_c> jsalisbury, ok, 3.13.0rc1 original bug only, no regressions
[18:50] <cristian_c> now I try again 3.13.0rc5
[18:51] <jsalisbury> cristian_c, ok.  I started a bisect and I have the first test kernel building.  We'll have to test about 7 kernels to get to the commit that caused the regression.  
[18:53] <jsalisbury> cristian_c, the steps will be:
[18:53] <jsalisbury> 1. Test first kernel.
[18:53] <jsalisbury> 2. Feed test result back into the bisect(Whether it has the regression or not).
[18:53] <jsalisbury> 3. Build the next test kernel.
[18:53] <jsalisbury> 4. Test again.
[18:53] <jsalisbury> 5. Feed result back into bisect again.
[18:53] <jsalisbury> etc
[18:54] <jsalisbury> cristian_c, I'll update the bug with each test result, and a link to the current test kernel.
[18:54] <cristian_c> uhm
[19:01] <cristian_c> jsalisbury, ok, I've tried now with 3.13.0rc5
[19:02] <cristian_c> jsalisbury, hpwifi interface not present in rfkill list output, but no trace in dmesg | tail
[19:02] <cristian_c> jsalisbury, original bug exists and also regression exists, as expected
[19:02] <cristian_c> jsalisbury, anyway, about your steps:
[19:03] <cristian_c> jsalisbury, 'd like to know exactly how to execute these steps
[19:03] <cristian_c> :)
[19:04] <jsalisbury> cristian_c, basically, I'll build a test kernel and post a link where it can be downloaded from.  You can download it and test to see if it has the regression / and is missing hpwifi.  Then let me know the test results and I'll build the next kernel.
[19:05] <jsalisbury> cristian_c, and repeat this for about 7 test kernels.  In the end, we should know the exact commit that caused the regression.  Then decide what to do based on what the commit does.
[19:15] <jsalisbury> cristian_c, ok, I finished building the first test kernel and posted a link to it in the bug report.
[19:17] <cristian_c> jsalisbury, ok, i've understood
[19:18] <cristian_c> jsalisbury, ok
[19:19] <cristian_c> I've found the comment
[19:20] <cristian_c> I download the test kernel, now
[19:21] <jsalisbury> ok
[19:23] <cristian_c> I'm downloading, I think I can test it immediately
[19:32] <cristian_c> jsalisbury, i'm installing that , but you've told 'Feed test result back into the bisect'
[19:32] <cristian_c> = let you know the results
[19:33] <jsalisbury> cristian_c, correct.  I'll tell the bisect the results, and it will tell me which kernel to build next.
[19:34] <cristian_c> ok
[20:15] <cristian_c> jsalisbury, I don't know if I can tell the results here
[20:16] <cristian_c> I've tried the first kernel: similar behaviout as 3.13.0rc2
[20:16] <cristian_c> only phy0 in rfkill list, no trace in dmesg | tail
[20:17] <cristian_c> original bug + regression
[20:18] <cristian_c> jsalisbury, but, as in rc2, no signs in network manager applet or rfkill list if I press the switch button
[20:43] <jsalisbury> cristian_c, ok, I would say that one is bad, since only phy0 is listed.  I'll build the next kernel.
[20:44] <cristian_c> jsalisbury, ok, one question: have I to report the next results in launchpad?
[20:44] <cristian_c> *the bug page
[20:45] <jsalisbury> cristian_c, It would be helpful, so we can keep track of which kernels were good and which ones were bad.  That's where I'll post the next test kernels too, so if one of us is not on IRC we can continue progress.
[20:49] <cristian_c> jsalisbury, ok, I'll expect the next kernel, and then I'll post the results on that launchpad page
[20:49] <cristian_c> jsalisbury, thanks for the the spent time
[20:49] <jsalisbury> cristian_c, no problem.  thanks for your help too
[20:50] <cristian_c> I'm learning
[20:50] <jsalisbury> cristian_c, and doing quite well at it :-)
[20:50] <cristian_c> in future, it will more simple for me
[20:50] <cristian_c> ok, thanks again
[21:24]  * jdstrand hugs arges (bug 1292234)
[21:24] <arges> jdstrand: that was a fun bug. : )
[21:25] <jdstrand> heh, yeah :)
[21:41] <w-flo> hi, are there regular android goldfish -> ubuntu goldfish kernel syncs / rebases? I hit a kernel panic in the ubuntu emulator that is probably fixed upstream
[22:46] <w-flo> If anyone reads my question and wants to answer, I'll read the irclogs.ubuntu.com tomorrow, but you can also comment on my bug report at bug 1420366
[23:02] <mdeck> I'm having a problem installing kernel 3.18.7 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.7-vivid/
[23:03] <mdeck> reading files list for package 'linux-headers-3.18.3-031803': Input/output error
[23:04] <mdeck> not sure if it's something on my end or in the package
[23:05] <tmpRAOF> mdeck: Likely your end.
[23:05] <mdeck> alrighty i'll start with a reboot and go from there.
[23:08] <mdeck> reboot did the trick.  weirdness. thanks.