[06:03] <ppisati> moin
[07:31] <dholbach> hiya
[07:32] <dholbach> do you know of any reports of e1000e not working in raring?
[07:54] <smb> dholbach, not me, maybe some of the others
[07:55] <dholbach> smb, a friend in the office just told me about it and I just yesterday noticed the same at home
[07:56] <smb> dholbach, I should have some boxes myself. not sure I noticed, but maybe I have not upgraded latest enough
[07:56] <dholbach> for me it's on a x220, the friend of mine downgraded to 12.04 already :-/
[07:57]  * cking has a x220, will sanity check this
[07:57] <smb> dholbach, did you have that with all versions of raring and quantal?
[07:57] <smb> 12.04 would be precise...
[07:57] <dholbach> cking, not sure if you saw the original question - it's about ethernet not working
[07:58] <dholbach> smb, no - I haven't used ethernet in a long while - just noticed it yesterday
[07:59] <apw> cking, yours is a ... oh you said that :)
[08:01] <apw> diwic, about?  this = false thing ...
[08:01] <diwic> apw, any news?
[08:01] <smb> dholbach, one box is using e1000e in raring and still working but the kernel is back at 3.8.0-13. upgrading now
[08:01] <apw> diwic, so i think this is a race, a race caused by the now double clear of that variable
[08:02] <apw> diwic, i note that later you have produced a patch set adding locking in this area
[08:02] <apw> so clearly there is some race potential here
[08:02] <apw> but the main point is actuall that variable is = false and made so by the memset just above
[08:02]  * cking just upgrading his x220i - confirming it has e1000e and currently working
[08:02] <apw> and i think the double adds a window where it gets cleared twice
[08:03] <diwic> apw, what I don't get is how any kind of race related to eld_valid could affect analog (non-HDMI) playback
[08:04] <apw> all true, ... its hard to fathom, but the patch as is seems redundant
[08:06] <apw> diwic, the only other reasonable inference (for me) is that the code layout changes it causes affects one of the other routines in the same file, and that is scarey
[08:06] <diwic> apw, that memset looks weird. 
[08:06] <apw> cking and i looked it over yesterday, it seemed to do something sane ish
[08:07] <apw> ie. it clears out the first 3/4 of the structure, but not the buffers at the end
[08:07] <diwic> apw, ah, now I understand it
[08:07] <apw> a little odd i concur
[08:07] <cking> the memset() does the job
[08:08] <Kano> hi, does anybody update the unstable-3.9 branch soon?
[08:09] <apw> Kano, it is likely to be a little delayed, we are in freezes right now and have other priorities
[08:10] <Kano> basically it would be interesting to combine it with the uvd patches
[08:10] <diwic> apw, or the additional = false causes a gcc bug because it tries to optimise it away having seen the memset, but fails in some weird way?
[08:10] <apw> diwic, we read the asm for both forms and they seemed right to us
[08:11] <diwic> apw, oh, you went that deep
[08:11]  * diwic bows down in admiration
[08:11] <apw> diwic, yeah we found pretty  much any addition to the routine also  avoided whatever the issue
[08:12] <apw> diwic, there is clearly something nasty in there, whether it is related to races your new locking (in later kernels) avoid or not ... how to tell
[08:13] <cking> it certainly seemed racy
[08:13] <diwic> apw, is it easy for you to file up a broken and a working kernel and attach alsa-info for both to compare for differences?
[08:14] <diwic> apw, for best reference alsa-info should be taken while playback is in progress
[08:14] <apw> yet, the code in question on the machine in question should be static as there is nothing in the port, ...
[08:20] <diwic> apw, did I miss anything?
[08:20] <diwic> apw, latest is <apw> yet, the code in question on the machine in question should be static as there is nothing in the port, ...
[08:20] <apw> diwic, noope you miseed nothing
[08:21] <apw> diwic, i'll try and get what you wanted.  it's my main machine
[08:21] <ppisati> brb
[08:26] <smb> cking, dholbach, server now on 3.8.0-17 and e1000e still working (82574L NIC)
[08:26] <dholbach> what kind of info would you need in a bug report?
[08:26] <dholbach> I'll double check in a bit
[08:27] <cking> hrm, my X220i with e1000e and latest kernel works OK
[08:27] <smb> dholbach, whatever ubuntu-bug linux collects. Though you probably need to work via apport-cli as you have no network at that time
[08:28] <dholbach> all right, will do - thanks
[08:35] <infinity> apw: I assume you noticed that lowlatency exploded in make oldconfig?
[08:36] <apw> flaps
[08:36] <apw> how is that even possible
[08:36] <infinity> https://launchpadlibrarian.net/136658295/buildlog_ubuntu-raring-amd64.linux-lowlatency_3.8.0-17.10_FAILEDTOBUILD.txt.gz
[08:36] <infinity> Cause there was something new? :P
[08:36] <apw> i don't doubt that it did so, but ... the configs are made from the main ones on rebase, and those would have to explode too... in theory
[08:36] <infinity> And you didn't sync configs when you rebased?  I'm guessing?
[08:37] <apw> that happens on rebase as part of the rebase
[08:37] <apw> but i will go and poke it, as this 'cannot' happen
[08:57] <Laney> hello kernel friends. Is there some badness with the -17 kernel in raring? I'm seeing nvidia-310 now not compiling: http://paste.ubuntu.com/5691789/ and http://paste.ubuntu.com/5691769/
[09:16] <apw> Laney, i don't think we expect it to be significantly different from the previous version, which worked i assume
[09:17] <Laney> indeed
[09:21] <Laney> hmm, it's checking for SUBLEVEL -le 5 and that's now 6
[09:22] <apw> Laney, so an issue with nvidia then?
[09:22] <Laney> well, assuming that SUBLEVEL increase is right then I guess so
[09:26] <Laney> tseliot: ^ looks like bug #1166639; do you know if n-g-d-310 needs an update?
[09:26] <ubot2> Launchpad bug 1166639 in nvidia-graphics-drivers-310 (Ubuntu) "nvidia-310 310.32-0ubuntu2: nvidia-310 kernel module failed to build" [Undecided,New] https://launchpad.net/bugs/1166639
[09:27] <tseliot> Laney: I guess the correct headers were simply not installed: *** Unable to determine the target kernel version. ***
[09:27] <tseliot> Laney: or the DKMS log is bogus
[09:28] <Laney> tseliot: They are - I got a set -x log of conftest.sh and it's failing when (presumably) checking the kernel version at line 1706
[09:30] <tseliot> Laney: I'll have a look at it here. Thanks
[09:31] <Laney> Seems like that check should be reworked a bit
[09:31] <Laney> thanks tseliot 
[09:38] <ppisati> mumble down?
[09:48] <cking> ppisati, seems to be borked
[09:48] <ppisati> cking: i'm back in
[09:48] <ppisati> cking: yep
[10:26]  * ppisati -> out for lunch
[13:54] <tseliot> Laney, apw, ogasawara: do you know why SUBLEVEL was changed to 6 in the Makefile in 3.8.0-17.27? It was previously set to 5. This makes nvidia's build fail
[13:55] <tseliot> http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-raring.git&a=search&h=HEAD&st=grep&s=SUBLEVEL
[13:55] <tseliot> and by previously I mean in ABI 16
[13:56] <apw> tseliot, it is the third number of the upstream version, it changes when that changes
[13:56] <apw> VERSION = 3
[13:56] <apw> PATCHLEVEL = 8
[13:56] <apw> SUBLEVEL = 6
[13:56] <ogasawara> tseliot: what apw said, we rebased to upstream stable v3.8.6
[13:56] <apw> so that says this is based on 3.8.6 stable update from upstream
[13:57] <apw> it would be a completely normal action when we are in rebase territory, ie before release
[13:57] <apw> and actaully any time we apply stable we'd do it, so expect it :)
[13:58] <tseliot> apw: does this check make any sense to you? http://pastebin.ubuntu.com/5692393/
[13:58] <tseliot> I don't see why sublevel should be less than or equal to 5
[14:00] <apw> so i think that is probabally designed for the 2.x days, it feels like it is trying to check for versions greater than 2.6.5 when perhaps the makefile name changed? something like that, it also just lookes borkes
[14:00] <apw> borked
[14:01] <tseliot> hmm... removing the "-a $SUBLEVEL -le 5" part gets it to work... I'll send NVIDIA a patch
[14:01] <Laney> it is borked
[14:01] <Laney> probably ought to check the major version too?
[14:01] <apw> tseliot, yeah i think ... it assumes the first digit is always 2, then it says for 2.6.x where .x < 5 then we need to change makefile to the old one
[14:02] <apw> but ... as it doesn't check the 2, that means it now hits for 3.6 and above
[14:02] <apw> (i think)
[14:03] <tseliot> the comments in the code look a bit dated: http://pastebin.ubuntu.com/5692404/
[14:09] <apw> tseliot, so that matches what I guessed i think, i suspect just zapping the whole lot is reasonable now, we don't have anything that old any more
[14:11] <tseliot> apw: are you suggesting that I skip the entire check or just the -le 5 thing (which seems less risky)?
[14:12] <apw> if the comments concur that they intended to select one bit of code for 2.6.5 and older and one for 2.6.6 and later, then we can rip out the decision en toto and use the code for 2.6.6 and above
[14:16] <tseliot> apw: here's the complete picture (with some code ripped out), just to give you an idea: http://pastebin.ubuntu.com/5692420/ (and we're hitting the "else"
[14:21] <ppisati> lp 1164074
[14:21] <ubot2> Launchpad bug 1164074 in linux (Ubuntu Raring) "[Highbank] Quantal to Raring upgrade issues" [High,Confirmed] https://launchpad.net/bugs/1164074
[14:21] <ppisati> rtg_: ^
[14:22] <ppisati> rtg_: there's a patch attached, can you give it a look? it's for raring-meta
[14:22] <rtg_> ppisati, will do
[14:22] <apw> rtg_, are you applying patches ?
[14:23] <rtg_> apw, haven't started yet, but did push some updates this AM (to existing patches)
[14:23] <apw> rtg_, i was going to apply jj's patch but don't want to step on our bags of man sausage
[14:23] <rtg_> apw, go ahead, I'll look at ppisati's upgrade bug
[14:23] <apw> rtg_, ack
[14:25] <apw> rtg_, forget that ... ogasawara is on the case anyhow
[14:26] <ogasawara> apw: ah yep, applied both jj's and piti's patches to Raring
[14:26]  * ppisati goes for an apple...
[14:26] <ogasawara> apw: I didn't touch Lucid, Precise, or Quantal, was gonna leave that to bjf and his minions
[14:27] <bjf> ack
[14:29] <Gen0me> Hi
[14:30] <apw> ogasawara, ta
[14:31] <Gen0me> guys;)
[14:32] <bjf> Gen0me, we are not a very touchy-feely channel, if you have a question, ask it
[14:39] <apw> Gen0me, yep we are pretty passive
[14:40] <rtg_> some are more aggressively passive then others
[14:40] <Nafallo> hey... what happened to chumby kernels? ;-)
[14:40] <ogra_> Nafallo, we dropped support for armel quite a while ago ...
[14:40] <Nafallo> seems these things are dead-weight unless someone revive them :-)
[14:40] <ogra_> mine still runs fine 
[14:41] <ogra_> showing the LCARS clock in my living room 
[14:41] <Nafallo> oh? I thought the server it syncs with died?
[14:41] <Nafallo> company went bust or whatever
[14:41] <ogra_> there is a hacked image you can install that doesnt require the network
[14:41] <Nafallo> aha
[14:41] <Nafallo> that's the answer I was looking for I guess ;-)
[14:41]  * ogra_ forgot how it was named, i did that right when they shot down ... was a while ago
[14:43] <Nafallo> zurk perhaps?
[14:43] <Nafallo> oh
[14:43] <Nafallo> actually.
[14:43] <ogra_> Nafallo, http://sourceforge.net/projects/chumby/ and http://sourceforge.net/projects/zurk/
[14:43] <Nafallo> I've already binned that device :-P
[14:44] <Nafallo> how pointless
[14:44] <Nafallo> sorry
[14:44] <ogra_> still does its job for me (being a nice start trek clock) 
[14:44] <Nafallo> thought it was still hiding in a corner somewhere, but I didn't realise it would be at a tip ;-)
[14:45] <ogra_> you could have proted ubuntu touch to it :P
[14:45]  * ogasawara back in 20
[14:45] <Nafallo> lol
[14:45] <Nafallo> yeah... :-P
[14:58] <jsalisbury> **
[14:58] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:58] <jsalisbury> **
[15:06] <rtg_> ppisati, https://bugs.launchpad.net/ubuntu/raring/+source/linux-meta/+bug/1164074/comments/6 , uploaded linux-meta
[15:06] <ubot2> Launchpad bug 1164074 in linux-meta (Ubuntu Raring) "[Highbank] Quantal to Raring upgrade issues" [High,Fix committed]
[15:07] <ppisati> rtg_: nice, thanks
[15:42] <Gen0me> help : Run `bundle install` to install missing gems.
[15:42] <Gen0me> Could not find pg-0.15.0 in any of the sources
[15:42] <Gen0me> bundel install -> Bundler::GemfileNotFound
[15:43] <Gen0me> help
[15:44] <rtg_> Gen0me, try #ubuntu-devel
[15:45] <bjf> jsalisbury, i think bug 1140716 can be removed from the hotlist. henrix will be submitting patches to the mailing list shortly
[15:45] <ubot2> Launchpad bug 1140716 in linux (Ubuntu Quantal) "[regression] 3.5.0-26-generic and 3.2.0-39-generic GPU hangs on Sandybridge" [Critical,Confirmed] https://launchpad.net/bugs/1140716
[15:48] <jsalisbury> bjf, will do, thanks
[15:48] <Gen0me> rtg_, ubuntu-devel -> not found
[15:50] <bjf> Gen0me, ubuntu-devel is an irc channel on this same server, try  '/join ubuntu-devel'
[15:50] <Gen0me> bjf, ;) thanks
[15:54] <ppisati> apw: assuming 'ubuntu-raring' is an up to date ubuntu-raring got tree
[15:55] <apw> ppisati, ?
[15:56] <ppisati> apw: is './kteam-tools/devel/devel-config-summary --html ubuntu-raring foobar' the correct rune to invoke your review script?
[15:56] <ppisati> apw: sorry i'm juggling between different things :P
[15:56] <apw> ppisati, yep that would do it
[15:56] <apw> ppisati, assuming the branch you want to check is checked out
[15:59] <ppisati> apw: http://paste.ubuntu.com/5692711/
[15:59] <apw> ppisati, ahh i fixed that somewhere one sec
[16:02] <apw> ppisati, ok pushed, try that
[16:02] <apw> (kteam-tools)
[16:21] <rtg_> henrix, how about a pull request for the i915 regression patch sets ?
[16:21] <henrix> rtg_: ack, will do that
[16:28] <bjf> rtg_, you can still ack/nak and let sconklin deal with them since he's trying to turn the crank
[16:28] <rtg_> bjf, I'm busy reading them
[16:29] <bjf> rtg_, i wasn't trying to rush you
[16:30] <rtg_> bjf, I just prefer pull requests when there are more then a couple of patches 'cause using thunderbird is a PITA
[16:31] <bjf> rtg_, ack
[16:39] <rtg_> sconklin, i915 patch sets applied. crank away.
[16:39] <sconklin> rtg_: thanks
[16:40] <rtg_> now, back to figuring out why mumble is borked
[16:45]  * henrix is also a little bit nervous about the i915 patchset...
[16:48] <rtg_> henrix, has it been tested to show that the regression is at least mitigated ?
[16:50] <henrix> rtg_: no, not really. Chris commented on the bug 2 or 3 times identifying these patches as the solution
[16:50] <rtg_> yeah, that bug report is getting to be kind of a mess
[16:52] <henrix> rtg_: yep, there are definitely different bugs being reported there and its hard to follow all the discussions/reports
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ## Meeting starting now
[17:00] <jsalisbury> ##
[17:12]  * henrix -> out for a bit
[17:17] <rtg_> ogasawara, re: Minutes from the Ubuntu Kernel Team meeting, 2013-04-09. Where is that work item 'rtg       || hardware-r-delta-review' actually defined ?
[17:22]  * rtg_ -> lunch
[17:42]  * smb mischief accomplished -> EOD
[17:54]  * cking EOT (rewind)
[19:58]  * rtg_ -> EOD
[23:30] <charlie> I just had another kernel panic from here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1165985 but using the upstream kernel instead. I've still got it displayed on the screen, and was wondering what would be the most useful information to transcribe from it before I reboot the machine.
[23:30] <ubot2> Launchpad bug 1165985 in linux (Ubuntu) "13.04 - kernel panic - unable to handle kernel paging request ffffffec -- Dell Inspiron 9300" [High,Confirmed]