[00:29] <mdeslaur> bjf: I was told you maintain this page: http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html
[00:30] <mdeslaur> bjf: it seems to be borked at the moment
[00:30] <bjf> mdeslaur: crap!
[01:09] <bjf> mdeslaur: it's slightly more sane but it's still being looked at
[01:32] <mdeslaur> bjf: hrm, yes, seems to be stuff still missing...ie: security
[01:32] <mdeslaur> bjf: of course, I _could_ pretend all our bugs are fixed :)
[02:43] <bjf> mdeslaur: it's back, i'll keep an eye on it
[03:18] <mdeslaur> bjf: awesome, thanks!
[03:24] <niksoft> hi, any devs in here who have a few minutes?
[09:41]  * apw waves to cking and smb
[09:42] <apw> ... and the tumbleweeds
[09:59] <ppisati>  whom shall i prod to get the new omap4 kernels moved into the archive?
[09:59] <ppisati> btw, tumbleweeds FTW! :)
[10:01] <apw> ppisati, i think they all just got done
[10:02] <apw> ppisati, i just asked for some of the main ones and they all got done by the looks of it
[10:03] <apw> ppisati, indeed rmadison seems to indicate nothing in proposed
[10:04] <ppisati> strange
[10:05] <apw> it would have possibly occurs visibly 4m ago though
[10:05] <ppisati> apt-get upgrade still suggets a 3.2.0-1403 instead of 3.2.0-1404
[10:05] <ppisati> uhm ok
[10:05] <apw> it might be mirroring delays then
[10:06] <ppisati> yep
[10:32] <ppisati> uhm
[10:32] <ppisati> on my desktop:
[10:32] <ppisati> [flag@newluxor ~]$ apt-cache show linux-image-3.0.0-14-generic | grep Filename
[10:32] <ppisati> Filename: pool/main/l/linux/linux-image-3.0.0-14-generic_3.0.0-14.23_amd64.deb
[10:33] <ppisati> wget http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-3.0.0-14-generic_3.0.0-14.23_amd64.deb
[10:33] <ppisati> find the file and download it
[10:33] <ppisati> but it's not the same for arm
[10:33] <ppisati> apt-cache show linux-image-3.2.0-1403-omap4 | grep Filename
[10:33] <ppisati> Filename: pool/main/l/linux-ti-omap4/linux-image-3.2.0-1403-omap4_3.2.0-1403.5_armel.deb
[10:34] <ppisati> wget http://archive.ubuntu.com/ubuntu/pool/main/l/linux-ti-omap4/linux-image-3.2.0-1403-omap4_3.2.0-1403.5_armel.deb
[10:34] <ppisati> ERROR 404: Not Found
[10:34] <ppisati> well, actually the entire directory "linux-ti-omap4"
[10:34] <ppisati> doesn't contain any .deb
[10:34] <ppisati> just .dsc and .tar.gz
[10:35] <apw> they've not gone to universe again have they?
[10:35] <ppisati> ah right
[10:35] <ppisati> didn't check universe
[10:35] <apw> or are they ports
[10:36] <ppisati> well, in ports.ubunt.com, i can find the .deb
[10:36] <ppisati> but under pool/main/l/linux-meta-ti-omap4/
[10:36] <apw> ok so i think that makes sense
[10:37] <ppisati> while pool/main/l/linux-ti-omap4 doens't exist at all
[10:37] <apw> oh no that doesn't
[10:37] <ppisati> wait
[10:37] <ppisati> bullshit
[10:37] <apw> if its meta only
[10:37] <ppisati> it does exist
[10:37] <ppisati> nevermind
[10:37] <ppisati> it does exist
[10:37] <ppisati> but cut&paste
[10:37] <ppisati> *bad
[10:40] <ppisati> btw, did you see linux-backports-modules-2.6.32?
[10:53] <apw> ppisati, whats up with 2.6.32
[10:53] <ppisati> broken build
[10:53] <ppisati> https://launchpadlibrarian.net/90500609/buildlog_ubuntu-lucid-i386.linux-backports-modules-2.6.32_2.6.32-38.39pre201201200400_FAILEDTOBUILD.txt.gz
[10:53] <ppisati> /build/buildd/linux-backports-modules-2.6.32-2.6.32/debian/build/build-generic/compat-wireless-3.2/drivers/net/wireless/libertas/if_usb.c: In function 'if_usb_suspend':
[10:53] <ppisati> /build/buildd/linux-backports-modules-2.6.32-2.6.32/debian/build/build-generic/compat-wireless-3.2/drivers/net/wireless/libertas/if_usb.c:1139: error: implicit declaration of function 'olpc_ec_wakeup_clear'
[10:53] <ppisati> /build/buildd/linux-backports-modules-2.6.32-2.6.32/debian/build/build-generic/compat-wireless-3.2/drivers/net/wireless/libertas/if_usb.c:1141: error: implicit declaration of function 'olpc_ec_wakeup_set'
[10:54] <apw> ppisati, ahh that i think is ogasawaras baby .. 
[10:54] <ppisati> oky doky
[11:03] <htorque> bryce: about bug 899159 - i can't seem to be able to cause the right gpu hang anymore. i tried for an hour and only got 0x7a000002 hangs (the one that's supposed to be fixed in xorg-edgers). should i still confirm it's gone with the ppa?
[11:03] <ubot2> Launchpad bug 899159 in xserver-xorg-video-intel "[snb-gt2] GPU lockup render.IPEHR: 0x7b009004 [Needs mesa 7.11+git]" [High,In progress] https://launchpad.net/bugs/899159
[12:27] <ppisati> no, the kernel is not there yet
[12:27] <ppisati> with whom shall i talk?
[12:33] <apw> ppisati, if you are talking to me there, then i normally talk to pitti
[12:34] <ppisati> anyone who knows, ok, i'll talk to pitti
[13:04] <tgardner> herton, how about adding an example to the maint-upload-mail help message ?
[13:05] <herton> tgardner, I'm not against it, would be better indeed to have one
[13:06] <herton> I'll put one in
[13:06] <tgardner> herton, there are enough options to that script that an example would help.
[13:07] <tgardner> especially because python is pretty unhelpful when it crashes
[13:17] <tgardner> paolo, apw, I uploaded the Precise meta packages for linux-ti-ompa4 and linux
[13:44] <ppisati> am i wrong or the headers are still stuck @ 1403?
[14:09] <tgardner> ppisati, http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-ti-omap4/linux-headers-3.2.0-1404-omap4_3.2.0-1404.6_armhf.deb looks right
[14:11] <ppisati> tgardner: just saw, but can't be upgraded
[14:11] <ppisati> "The following packages have been kept back: ..."
[14:11] <ppisati> among which there's the linux-headers
[14:12] <tgardner> ppisati, perhaps because the publisher hasn't run yet and meta is still in flight ?
[14:12] <tgardner> though I assume you're using the meta package I just uploaded....
[14:13] <ppisati> tgardner: yes, i'm using meta
[14:13] <ppisati> ii  linux-headers-omap4                    3.2.0.1403.3
[14:13] <ppisati> let's see when the new one is available
[14:17] <tgardner> ppisati, it appears to be right in the archive: 'rmadison -S linux-ti-omap4|grep precise|grep linux'
[14:21] <tgardner> ppisati, looks like the tools meta package binary went to universe, but everything else is OK: 'rmadison -S linux-meta-ti-omap4 | grep precise'
[14:21] <ppisati> ok
[16:15] <hallyn> yikes i'm getting flooded in syslog by oopses from /build/buildd/linux-3.2.0/drivers/net/wireless/ath/ath9k/rc.c:697 ath_rc_get_highest_rix.isra.19+0x15c/0x1e0 [ath9k
[17:11] <bryce> htorque, hmm
[17:12] <bryce> htorque, yeah there can be some variance in the id's returned  I guess.  Verify the ppa solves the 0x7a000002 bug at least
[17:13] <htorque> bryce: i was just surprised that i didn't get any crash files (apport was definitely running). updating now.
[17:31] <htorque> bryce: should i be able to do a full upgrade? dist-upgrade wants to remove xorg, xserver-xorg, and co. a partial upgrade didn't suffice to get rid of the 0x7a000002 hangs.
[17:35] <Sarvatt> htorque: i'm transitioning it to xserver 1.12 at the moment, dont upgrade
[17:36] <Sarvatt> i put a huge warning that shows up when you add the ppa, guess that wasn't enough :)
[17:36] <bryce> htorque, ok, in that case use the x-staging ppa
[17:36] <htorque> Sarvatt: thanks for the info. i'll ppa-purge and https://launchpad.net/~bryce/+archive/lp830136
[17:36] <Sarvatt> bryce: damage is done, can't ppa purge it at the moment
[17:36] <htorque> or that :)
[17:36] <bryce> Sarvatt, x-staging has new mesa right?
[17:36] <Sarvatt> ppa-purge doesn't work with multiarch
[17:36] <Sarvatt> nope
[17:36] <bryce> no?  hrm
[17:37] <Sarvatt> htorque: it'll be a few hours until everything builds, sorry about the trouble but theres no other way around the transition
[17:38] <htorque> Sarvatt: hehe, yeah, reading warnings... totally my fault, but i'm fine with breakage.
[17:39] <ohsix> i'm not, omg!
[17:39] <htorque> bryce: is your ppa for bug 830136 fine if i should be able to fix the mess? :-)
[17:39] <ubot2> Launchpad bug 830136 in xserver-xorg-video-intel "[sandybridge-m-gt2+] GPU lockup render.IPEHR: 0x7a000002" [High,In progress] https://launchpad.net/bugs/830136
[17:41] <jsalisbury> apw, I have a git question.  Is it possible to do multiple bisects in the same mainline linux src tree?  For example, I created two branches, one for each bug.  I started a bisect in one branch, but running 'git bisect log' in the other branch shows the bisect logs from the first branch.
[17:43] <ohsix> Sarvatt: is there a way to sign up and be notified when you change the ppa description?
[17:43] <Sarvatt> ohsix: i wish
[17:44] <Sarvatt> even better i wish i could stop publishing, but disabling publishing means new uploads wont build against the new packages and theres a big dependency chain in the x stack
[17:45] <Sarvatt> need to build protos, then libs against those protos, then xserver against all that, then drivers against the new xserver
[17:45] <ohsix> can you add a new fake series to do the build, then move it?
[17:47] <tgardner> jsalisbury, I don't think so. you'll have to clone the tree and run your second bisect out of that one.
[17:47] <jsalisbury> tgardner, cool, I can do that.  I'll use the -reference option to save disk space.
[17:48] <jsalisbury> tgardner, thanks for the help
[17:49] <bryce> htorque, the ppa for bug 830136 is really only for oneiric
[17:49] <ubot2> Launchpad bug 830136 in xserver-xorg-video-intel "[sandybridge-m-gt2+] GPU lockup render.IPEHR: 0x7a000002" [High,In progress] https://launchpad.net/bugs/830136
[17:50] <htorque> bryce: okay, in that case i'll wait. thanks!
[17:50] <bryce> Sarvatt, maybe if the text were trimmed down a bit, the warnings would be more noticeable?
[17:55] <Sarvatt> htorque: so the theory is that you remove the sources, apt-get update to get rid of the sources, and for every package installed that came from the ppa you need to sudo apt-get install package/release, like this for example http://pastebin.com/ewBeCnMR
[17:55] <Sarvatt> in case you want to try to fix it yourself without waiting
[17:56] <Sarvatt> that list wont work right now though, there are many libxcb libs installed also that need to be downgraded now too
[17:56] <Sarvatt> and you might not have all that installed
[17:57] <htorque> Sarvatt: thanks, already on it. ppa-purge might not work, but it seems to give me the right order in which i can mark the packages for a downgrade in synaptic. should be done soon. :)
[17:57] <Sarvatt> yeah the big problem with ppa-purge is it doesn't do :i386 packages, and things will be all kinds of screwed up if you leave those installed :)
[17:58] <ohsix> Sarvatt: is that a technical problem or has nobody got to it yet?
[17:58] <Sarvatt> unless you're on i386 and dont run into the problem :)
[17:58] <htorque> bryce: i simply didn't read the description. only i can fix that. ;-)
[18:01] <apw>  jsalisbury yep what rtg said
[18:01] <apw> js though actually now i think about it, you can git bisect log and save the output
[18:01] <jsalisbury> apw, thanks.  I'll do that from on.
[18:01] <apw> and switch to that one by running it
[18:01] <apw> though its not quick, you could use the git bisect log output as your 'store' for each one you are doing
[18:02]  * apw whines about how unity is GONE
[18:02] <jsalisbury> apw, hmm, right, and then restart the bisect everytime
[18:02] <apw> yeah quite slow to 'catch up' to the end each time on each tho.
[18:02] <apw> but if space is your issue then ...
[18:03] <jsalisbury> apw, yeah.  I think I'll have a seperate tree for each bug, then use the --reference option to point to a master tree.  That way I don't risk confusing multiple bugs ;-)
[18:49]  * tgardner --> lunch
[20:05] <niksoft> hi, is anyone actually here?
[20:17] <bryce> niksoft, nope
[20:18] <niksoft> thats what i thought
[20:22] <_ruben> this channel is rather bursty when it comes to activity: either no action at all, or a lot of it ;)
[20:22] <_ruben> gotta love them timezones/workdays/etc and all :)
[20:23] <niksoft> sorry, i generally never get a reply if i just ask the question. So i am working on an ubu server, i need it to be able to both serve at extreemely high throughput, and at extremely high tps, like higher than most people dream about in most datacenters. Does anyone have any experience with setting up the kernel stacks for 10+gbit/sec? 
[20:23] <geri> how can i remove dynamic kernel support?
[20:25] <_ruben> 10+gbps takes a bit of effort indeed, tho packet size distribution plays a large role here obviously .. is juniper looking to use linux instead of bsd? ;)
[20:26] <niksoft> lol i dont want to give in and build a bsd box, no juniper is, and will continue using bsd, though i cant comment where that's going ;)
[20:26] <_ruben> hehe
[20:26] <_ruben> was just a too easy remark to make ;)
[20:26] <niksoft> so max i can hit at the moment is 13 sustained and 16gbit max, with pretty huge fail rates
[20:27] <niksoft> this is on a 5mb file... oh fif i mention its a web server?
[20:27] <_ruben> the packetshader ppl do ~40gbps by offloading to the gpu 
[20:27] <niksoft> but i don't hit cpu perfomance issues, it is barely touched
[20:27] <_ruben> packetshader likely wont help there ;) 
[20:28] <_ruben> ic, interrupts?
[20:28] <niksoft> 24 cores, 96gb ram, no disk io
[20:28] <niksoft> yeah interrupts are around 30k
[20:28] <_ruben> tcp window scaling?
[20:28] <niksoft> on
[20:28] <niksoft> infact... let me dump sysctl.conf
[20:29] <_ruben> i assume the nic(s) is/are msi-x capable?
[20:30] <niksoft> http://pastebin.com/JHKftWzf
[20:33] <_ruben> seems you got the "usual suspects" covered .. does the loadavg shoot up ?
[20:33] <niksoft> no not really
[20:34] <niksoft> i am looking into msi atm
[20:34] <_ruben> almost sounds like a really low level, like broken nic or so
[20:34] <niksoft> nah both nics work          RX bytes:8560452364 (8.5 GB)  TX bytes:431279836182 (431.2 GB)
[20:35] <niksoft>           RX bytes:8532901172 (8.5 GB)  TX bytes:430141265520 (430.1 GB)
[20:35] <niksoft> ethtool doesnt seem to display MSI info at all... lets see maybe lspci will?
[20:36] <niksoft> there it is
[20:37] <niksoft> http://pastebin.com/apKNUzFg
[20:37] <niksoft> yes msi is supported
[20:38] <_ruben> tho if load's low as well as cpu usage, i doubt it'd be of any help :)
[20:39] <_ruben> as it'd help to spread the (interupt) load over the cores
[20:39] <niksoft> well that may help
[20:40] <niksoft> i mean i get sustained 30000 interrupts, and that's a fair amount of ticks if it's going to the same core
[20:40] <_ruben> well, does for instance 'top' show just one cpu being pegged?
[20:40] <_ruben> looking at the total load on a 24-way sys doesn't mean much :)
[20:40] <ohsix> theres an irq top too, that will read /proc/interrupts, don't remember the name of it tho
[20:41] <niksoft> there is a core that is used a lot more than others
[20:41] <ohsix> irqbalance (the daemon) can collect statistics too, i think
[20:41] <niksoft> i am using nmon
[20:41] <_ruben> irqbalance might help things, or make it worse, from what i've read about this stuff
[20:42] <_ruben> not really sure if it takes anything special (configuration wise or whatever) to make use of msi-x
[20:42] <niksoft> irqbalance is running
[20:42] <niksoft> yeah i read that too, i will try stopping it
[20:46] <niksoft> yeah i think you have to enable it manually
[20:49] <niksoft> ok one thing at a time
[20:49] <niksoft> running the tps test 1-10k tps on a 5kb file
[20:49] <niksoft> irqbalance off
[20:50] <niksoft> http://www.mjmwired.net/kernel/Documentation/MSI-HOWTO.txt on the msi
[20:51] <ohsix> there are some lwn articles on napi that tell you what's important for high pps, and how to see what thet driver does with respect to it
[20:53] <niksoft> ohsix, would you be able to point me in the right direction on that?
[20:56] <ohsix> lwn napi in the googles brings up some stuff; i'm looking where the in tree documentation ended up
[20:57] <niksoft> TY, also i am googling over here too
[21:00] <ohsix> most of the fancy nics seem to have a corresponding file in Documentation/networking
[21:01] <niksoft> wait i take that back  successful transactions went up by about 30k on a 3million transaction run thre from 1-10k tps
[21:01] <niksoft> i will look into that, just going to start this throughput test
[21:06] <niksoft> not much luck on that, the most i see in there is a setup for a gig nic
[21:07] <niksoft> qlogic driver is nowhere to be found atm
[21:09] <niksoft> grep to the rescue
[21:20] <niksoft> ok greping through i have some progress, but it needs testing
[21:47] <niksoft> enabling MSI-X, at least with these preliminary results gave me a 0.8% boost on throughput on a 5mb file
[21:48] <niksoft> trying something smaller (5kb file) at 1-10k rps, lets see if that about confirms these results
[21:50] <niksoft> so i increased the buffers further, following suit with the intel 10GbE driver notes in the kernel doc (though my values are higher yet, since i have 2 10 gig and 2 1 gig interfaces
[21:55] <niksoft> may not seem much, till you consider that it's roughly 100megabit difference
[22:55] <hallyn> is there a commonly used trick for getting vmlinux back from vmlinuz?
[22:55] <hallyn> (i remember finding one a few years ago, but it was not common nor reliable)
[22:55] <hallyn> looking for a way to run gdb against the kernel from linux-image.deb...
  followed http://www.codeguru.com/forum/showthread.php?t=415186  which is in fact what i did years ago
[23:03] <Sarvatt> hallyn: it's in the ddeb
[23:03] <hallyn> Sarvatt: thanks, I may use that in the future - though 'fakeroot debian/rules binary-generic' did not create a ddeb
[23:04] <hallyn> i suppose i should use that anyway as i appear to have no symbols
[23:20] <hallyn> Sarvatt: do you happen to know the rule to make the ddeb?
[23:25] <Sarvatt> hallyn: afraid not, looking through this crazy build system now though
[23:25] <hallyn> Sarvatt: no worries, don't waste time on my account - thanks for the tip
[23:28] <Sarvatt> hmm
[23:28] <Sarvatt> skipdbg=false?
[23:28] <Sarvatt> fdr binary-generic skipdbg=false
[23:28] <Sarvatt> not sure if you need pkg-create-dbgsym installed also
[23:39] <hallyn> cool will try, thx