[02:05] <panda|ac100> jk-: ping :)
[02:05] <jk-> panda|ac100: pong
[02:38] <ohsix> hey, does anyone know what mlockall does when the rlimit for mlock doesn't cover all of it? does it preserve the hottest pages? (would be magic, but also nice)
[06:46] <ohsix> wow, addpart/delpart is neat
[07:32]  * smb thinks apw stuggles to get online
[07:33] <apw> struggling with unity actually which is about to get removed if it doesn't detect my screen without crashing
[07:33]  * apw is not finding it acceptable that pluging in an external screen now causes unity to crash
[07:33] <smb> apw, Must be a scary screen
[07:34] <apw> this is a natty regression
[07:53] <RAOF> As in: a regression in natty, or a regression from natty?  That said, I find unity in Oneiric is exactly as terrible at handling multiple monitors as in Natty :/
[07:53] <ppisati> back in 10mins...
[08:02] <apw> RAOF, as in i believe it used to work in natty ... or its better with hdmi than vga not sure yet
[08:04]  * RAOF finds it hard to believe unity's monitor hotplug has got *worse* from natty.
[08:04] <apw> RAOF, no it has gotten worse in natty in my experience
[08:04] <cking> progress... but not in the right direction
[08:05] <RAOF> Once it's sufficiently broken it'll look fixed?
[08:05] <apw> RAOF, i had to reboot with the monitor attached to have a hope of logging in without unity crashing in a heap
[08:06] <RAOF> Oh, yeah.  Who doesn't?
[08:06]  * cking has to walk downstairs *again*, working from the loft conversion is getting me super fit
[08:06]  * smb thinks they are in danger of "when it is sufficiently broken, nobody cares whether it gets fixed". Because all use something else
[08:07] <RAOF> It *very* occasionally works without restarting unity.
[08:07] <smb> cking is becoming the step-master
[08:10] <cking> just training to walk all the stairs in millbank without dying
[08:12] <smb> Though I think they stopped doing that... But anyway, always good to have some exercise.
[08:13] <amitk> smb: they stopped? any particular reason?
[08:14] <smb> amitk, Thought they had. But don't know of a specific reason. Maybe just got bored.
[08:17] <smb> amitk, Not hearing much of you lately. How are you? 
[08:19] <amitk> smb: i know :-/ Been a busy summer so far. Too many thing happening in the PM working group in Linaro keeping me busy. Plus some home renovations..
[08:19] <amitk> smb: how was Dublin?
[08:22] <smb> amitk, Yeah, there usually is no lack of something to do. The usual hive of bees (though no mankini incidents). Surprisingly I seem to have succeeded in looking at the things I planned to (which does not always happen).
[08:23] <smb> Must be because the moved out all those noisy HWE guys to a different room. ;-P
[08:23] <amitk> smb: same hotel?
[08:24] <smb> amitk, Yep, which I had no memories any more about the lack of AC in the rooms. Which we could have used this time
[08:25] <amitk> smb: hehe. They must've posted guards to avoid the mankini incidents :)
[08:26] <smb> Well, those probably would not have been as bad as before as there were no horse show people but Bon Jovi fans around. They are much less likely to worry about such a thing. :)
[08:31] <apw> more likely to be doing it themselves frankly
[10:26] <jussi> Hrm, http://wstaw.org/m/2011/07/11/2011-07-11_10-24-33_21_Oulu.jpg
[10:27] <jussi> :(
[10:35] <apw> why would you be running a 3.0.0-rc3 kernel anyhow ?
[10:35] <apw> jussi, ^^ ? 
[10:35] <Tommeh> -rc6 maybe.
[10:36] <Tommeh> But 3.0.0 for radeon r600+ does give some nice performance increases in gnome-shell/unity
[10:36] <apw> yeah i am asking why he is running an out of date mainline kernel
[10:36] <jussi> apw: because I was told here to try it. (a couple of weeks ago). I thought the trace may be of use, so I posted the screenshot. If its useless, I will throw it away :)
[10:37] <apw> jussi, i would update to the latest and see if its still there, as thats quite early 3.0.0
[10:38] <jussi> apw: ok. have we been building 3.0's for natty yet? or should I still be trying the oneiric builds? (as mentioned here before)
[10:38] <apw> we don't build them for natty, we have some for lucid as we do backports to there, otherwise its oneiric ones
[10:40] <jussi> apw: ok. could you again link me to the site with all the debs? I seems to have misplaced it :(
[10:40] <apw> http://voices.canonical.com/user/76
[10:41] <apw> ARRRG WHY DOES X HAVE TWO PASTE BUFFERS ..> WHY
[10:41] <apw> https://launchpad.net/ubuntu/+source/linux
[11:18] <ppisati> any debian package expert around?
[11:18] <ppisati> basically, my omap4 kernel package refers to the wrong module directory
[11:19] <ppisati> (wait for the pastebin...)
[11:20] <ppisati> http://pastebin.ubuntu.com/641814/
[11:21] <ppisati> any idea where i should look for?
[11:21] <ppisati> i know it's something in debian/*
[11:21] <ppisati> but i don't know what's exactly...
[11:23]  * apw looks
[11:23] <smb> ppisati, I would guess it would be somewhere in rules.d. Either defining a version string wrongly in 0-* or using a wrong one in the binary rules...
[11:24] <apw> that + on the end is classicly added by the kernel itself when it is unsure of its own version number
[11:24] <apw> we normally override that in rules however
[11:24] <apw>         LOCALVERSION= localver-extra=
[11:25] <apw> i have that on my kmake variable in debian/rules.d/0-*
[11:25] <apw> does your have that ?
[11:25] <apw> cirtainly the main kernels are at those version numbers and do not suffer this problem
[11:25] <apw> ppisati, ^^
[11:26] <ppisati> apw: [flag@newluxor ubuntu-oneiric]$ grep -R LOCALVERSION debian/rules.d
[11:26] <ppisati> debian/rules.d/0-common-vars.mk:        LOCALVERSION= localver-extra=
[11:26] <apw> ppisati, is your branch up to date on ti-omap4-next
[11:27] <ppisati> apw: this morning i rebased the new stuff from TI on top of oneiric/master-next
[11:27] <apw> ppisati, oh one thing do you have updated module init tools installed ?  for the 3.0 prefix bug
[11:27] <ppisati> previous to your 3.0.0-rc6 push
[11:27] <ppisati> uhm no
[11:28] <apw> that might explain the error as you may be using the running kernel version in error then
[11:28] <apw> though note if you rebase to the latest tip the version number moved to 3.0.0 anyhow
[11:28] <apw> and the problem is removed
[11:29] <ppisati> so i can try to do another rebase
[11:29] <ppisati> ok, i'll do
[11:36]  * ppisati goes for a dist-upgrade, kiss me goodbye...
[11:41] <apw> ppisati, see you
[11:42] <nigelr> I'm getting an oops caused by uvcvideo and I think it might be related to the problem fixed by this patch: https://lkml.org/lkml/2011/7/8/87
[11:42] <nigelr> any chance of it being included in the stable natty kernel? :)
[11:43] <nigelr> I'm just trying it out now
[12:00] <vish> i'm trying to bisect and build a kernel, I see the following error during sub-make : http://paste.ubuntu.com/641831/ and the kernel does not build. how do I fix this?
[12:00] <vish> when i check the directory, i see no file named "..debian/stamps/stamp-build-generic"
[12:01] <vish> just have ../debian/stamps/stamp-prepare-generic and ../debian/stamps/stamp-prepare-tree-generic
[12:01] <smb> vish, The real error is actually somewhere above that. The stamp file would just be created if the build went ok
[12:02] <vish> hmm, /me looks 
[12:08] <apw> nigelr, if a simple patch like that fixes an obviously triggered oops then its possible to SRU it
[12:09] <apw> vish, the error would have been much before the end of the log as we build in parallel, search back for 'error'
[12:10] <vish> hmm, looks like there are quite a few "errors"
[12:11]  * ppisati -> reboot
[12:14] <vish> bah, i dont think i see anything related to 'stamp' and 'error' , maybe I'm not looking at the right thing.. could someone check what went wrong? » http://paste.ubuntu.com/641841/
[12:14] <smb> apw, Not sure, wasn't git bisect skip the thing probably needed if a certain revision just is not buildable but you would not want to say bad or good?
[12:15] <apw> vish, pastebin the output, you'd not see a stamp file as that only gets made if the make is successful, which it is not
[12:15] <smb> /home/vish/ubuntu-maverick/fs/ceph/msgpool.c:173: error: implicit declaration of function ‘kref_set’
[12:16] <vish> smb: /em has no clue what that means :D
[12:16] <vish>  */me
[12:16] <smb> vish, That was the error that caused the build to fail
[12:16] <vish> smb: k, how do I fix it?
[12:16] <smb> Apparently there is no previous definition of kref_set
[12:17] <apw> vish if you cannot build a revision then saying git bisect skip will ask it to find another to test without taking this one as good or bad
[12:17] <smb> cauld be either a missing include or the patch that introduced it came in the wrong order
[12:18] <vish> apw: k, great! :) will probably have to do that, if i cant fix this..
[12:19] <vish>  bleh, finding the include or patch, might just take longer when I have no clue.. /me skips! 
[12:24] <lamont> why does my machine wish to schedule while atomic?
[12:25] <smb> Naughty developers...
[12:26] <ohsix> lamont: do you have an intel video card?
[12:28] <ohsix> theres a 4500mhd regression in mesa that causes a panic; and switching the tty to display the panic triggers the scheduling while atomic panic
[12:29] <ohsix> it's fun ;]
[12:29] <smb> lamont, Very generically somthing allows disruptions (interrupts) where it should not. But some info around it might be useful...
[12:31] <ohsix> lamont: do you have an intel video card?
[12:40] <lamont> 01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9500 GT] (rev a1)
[12:53]  * lamont tries a maverick kernel to see if that's any better
[12:59] <lamont> the latest failure was in netfilter code, "kernel stack corrupted"
[13:00] <lamont> I'll get the jpgs somewhere and file a bug later today
[13:08] <apw> oooh nasty
[13:26] <lamont> something like that
[13:57]  * apw needs to find someone who has played with ipv6 tunnels
[15:22] <ppisati> apw: smb: btw, moving the pkg to a 3 digits 3.0.0-x kernel pkg _seems_ to have fixed my problem... let's see...
[15:24] <apw> ppisati, good stuff
[15:33] <tgardner> bjf, where is that bug repo you were talking about at the rally ? the one with clear text files, etc.
[15:34] <bjf> tgardner, on zinc at /x/bradf/lp-data.git
[15:35] <tgardner> bjf, ack
[15:39] <apw> bjf, you should so symlink that into your home
[15:44] <bjf> apw, done
[16:53] <dupondje> http://paste.ubuntu.com/642025/ => could this be a kernel bug or surely hw issue?
[16:53] <dupondje> i'm on oneiric btw
[17:11] <jjohansen> rebooting
[17:29] <jjohansen> oneiric update this morning, made my machine none functional, it doesn't appear to be a kernel issue (tried previous oneiric and natty kernels) if other people start complaining
[17:59]  * tgardner --> lunch
[18:58]  * bjf -> lunch
[20:24]  * lamont manages to land on bug 809000
[20:24] <ubot2> Launchpad bug 809000 in linux "kernel stack corrupted in 2.6.38-8" [Undecided,New] https://launchpad.net/bugs/809000
[20:36] <tgardner> lamont, its suspicious that both traces involve network functions. I think you also have the accursed r8169 ethernet driver.
[20:36] <lamont> I do
[20:37] <lamont>  lsmod | grep 8169
[20:37] <lamont> r8169                  39714  0 
[20:37] <lamont> mii                     5237  1 r8169
[20:37] <tgardner> lamont, it has undergone serious renovation for 3.0.0, perhaps you could try the Oneiric kernel
[20:37] <lamont> I do have room and a spare network card that I could kill 8169 with fire and see if it makes any difference
[20:37] <lamont> or I could do that
[20:37] <lamont> how stable otherwise is oneiric's kernel?
[20:38] <tgardner> lamont, It seems to be doing pretty well. we're all using it on various platforms
[20:38] <tgardner> lamont, of course, knowing you, you'll have some bizarre HW that borks it right away
[20:39] <lamont> well... there is a vlan bridge on the box
[20:39] <lamont> Build needed 08:08:03, 1618388k disk space
[20:39] <lamont> I know that's a total lie, since I saw it up over 20GB of footprint sometime during that build
[20:39] <lamont> did we lose the patch that removed the intermediate build trees again?
[20:40] <lamont> (on a different note, that is)
[20:40] <tgardner> lamont, not that I know of. lemme check
[20:41] <tgardner> lamont, was this an oneiric build ?
[20:43] <lamont> dist-upgraded the machine to  natty over the weekend
[20:43] <lamont> worked around the "3 crashes in 20 minutes" feature by tossing the maverick kernel on the box
[20:43] <tgardner> lamont, um, I was talking about the build space issue.
[20:44] <lamont> oh build-space
[20:44] <lamont> yeah
[20:44] <lamont> that was the 3.0.0-4.5 build
[20:44] <tgardner> lamont, the patch that removes intermediate files is still in the oneiric rules
[20:44] <dupondje> http://paste.ubuntu.com/642025/ => could this be a kernel bug or surely hw issue?
[20:44] <lamont> the machine in question had some old cruft in someones home directory that resulted in a disk space alarm that made me (1) boggle, (2) look at the build tree and boggle, and (3) clean out said homedir's cruft
[20:45] <lamont> tgardner: ok.  I'll check into it more sometime, don't worry about it
[20:45] <lamont> at least not for a week or 3
[20:45] <tgardner> lamont, ok, holler if it gets too annoying
[20:47] <lamont> well, it's more "if we release and it really is that big, it may well be that it doesn't build in a (virtualized) ppa".  that would suck
[20:48] <tgardner> lamont, I'll have a closer look at it. every release accrues more modules, more drivers, more stuff
[20:49] <lamont> yeah
[20:49] <lamont> pretty soon, there could be a valid complaint of "bloat"
[20:50] <tgardner> herton, keep an eye on bug #809000. Its another lamont special. I'm suspecting the root cause is r8169
[20:50] <ubot2> Launchpad bug 809000 in linux "kernel stack corrupted in 2.6.38-8" [Undecided,In progress] https://launchpad.net/bugs/809000
[20:50] <lamont> I'm still trying to understand how my last one somehow wound up closed as invalid
[20:51] <lamont> that one at least has the 82546EB chipset
[20:51] <herton> ok. lamont, isn't this on the same machine which had the NAT issue?
[20:51] <lamont> herton: no
[20:52] <jwi> tgardner: uh - bad time to ask about enabling some experimental drivers/configs? :)
[20:52] <lamont> it's a tower which hosts a kvm guest that lives on a different vlan than the primary IP of the box, while also having an IP on that subnet too, since it doesn't like to talk to the guest via the router
[20:52] <tgardner> jwi, as a matter of policy we generally do not enable drivers that are EXPERIMENTAL
[20:53] <jwi> right, but there's still a whole bunch of them enabled
[20:55] <tgardner> jwi, I acknowledge that there have been exceptions. I'm mostly not interested in supporting (or taking bugs for) experimental drivers and features. we've already gotten bit by network name spaces in 2.6.32
[20:55] <jwi> RTL8192CU seems like a good candidate, considering its experimental rtlwifi siblings are enabled
[20:56] <tgardner> staging is different then experimental.
[20:56] <jwi> its not in staging
[20:58] <jwi> i saw the network name space issue, the ones i was thinking about really are "experimental or no device driver at all" cases
[20:59] <tgardner> jwi, shit, all the rtlwifi drivers are experimental. how;d they get enabled ? (I probably did it)
[21:00] <tgardner> hmm, we probably got them for free when they moved out of staging.
[21:01] <jwi> i don't think they ever have been in staging - rtlwifi is a new "project"
[21:02] <tgardner> jwi, the config option wasn't though. I think it got reused.
[21:02] <jwi> urgh, that might be true
[21:06] <tgardner> jwi, ok, committed 'UBUNTU: [Config] CONFIG_RTL8192CU=m'
[21:06] <tgardner> now, back to what I was doing...
[21:06] <jwi> ty - now hold on, that wasn't the only one ;)
[21:07] <tgardner> jwi, that looks like it was the only one not enabled for x86en
[21:09] <jwi> if you got the time, see bug 238208 for MEMSTICK_R592 - it seems like it got quite some testing
[21:09] <ubot2> Launchpad bug 238208 in linux "Need MemoryStick driver Ricoh R5C592 (part of R5C832/822chipset)" [Wishlist,Confirmed] https://launchpad.net/bugs/238208
[21:13] <tgardner> jwi, looks like it went in 2.6.39 ?
[21:13] <jwi> yep
[21:20]  * herton --> eod
[21:20]  * tgardner --> eod
[22:46] <Q-FUNK> howdy!  is left_control+K mapped to some SysReq key on ubuntu?  every time I press these, the CPU kills all power immediately without proper shutdown.  it's annoying since control-K is "cut" in 'nano'.
[22:49] <charlie-tca> Q-FUNK: according to the shortcuts lists, it shouldn't be
[22:49] <charlie-tca> http://askubuntu.com/questions/28086/unity-keyboard-mouse-shortcuts/28087#28087
[22:49] <Q-FUNK> I'm not using unity.
[22:49] <charlie-tca> http://www.techdrivein.com/2011/04/31-useful-ubuntu-1104-unity.html
[22:50] <Q-FUNK> and the issue also affects vcons operation.
[22:50] <charlie-tca> Still shouldn't be, without SysReq key also
[22:52] <Q-FUNK> hmm.. ok
[23:15] <Q-FUNK> another issue I have:  on my ubuntu+1 host, kernel 3.0.0 makes the CPU overheat.  it has become a significant issue that I've had to go back and run 2.6.38 instead.
[23:16] <Q-FUNK> is this a known feature of current 3.0 kernels?
[23:23] <jjohansen> Q-FUNK: In general the 3.0 kernel should be better than .38, a couple bugs have been found that fix some problems with the scheduler keeping the processor for entering into lower power states
[23:25] <jjohansen> Q-FUNK: you can try booting with pcie_aspm=force  as a kernel parameter and see if that reduces your power problems, but I doubt it will as .38 should suffer from that problem as well
[23:26] <Q-FUNK> it's just that since .38 the whole casing is burning hot. I've kept an older kernel  (.36 IIRC) and going back to that significantly reduces the temperature.
[23:26] <jjohansen> Q-FUNK: and no left-ctrl-K is not mapped to sysrq in Ubuntu
[23:27] <jjohansen> Q-FUNK: ah then pcie_aspm=force might just work for you
[23:27] <jjohansen> it was introduced in .38
[23:28] <jjohansen> that is the problem, before linux was ignoring the bios which wasn't really correct, but some buggy bioses see significant power regressions because of the newer behavior
[23:29] <jjohansen> passing pcie_aspm=force restores the old pre .38 behavior for those systems
[23:30] <jjohansen> Q-FUNK: I am not sure what to say about your left ctrl-k behavior besides open a bug, it shouldn't be happening and doesn't happen for me
[23:31] <Q-FUNK> mind you, that red-hot host doesn't have any pcie bus
[23:32] <Q-FUNK> didn't I read somewhere that kernels since after 2.6.32 consume a heck of a lot more power and that it's a known issue, though?
[23:33] <jjohansen> Q-FUNK: I think you are thinking of the phoronix article
[23:33] <Q-FUNK> could be
[23:33] <jjohansen> his figures don't really back up some of his assertions about power usage
[23:33] <jjohansen> he did find a regression see the pcie_aspm=force from above
[23:34] <jjohansen> but as I said that is really more of a bios issue
[23:34] <jjohansen> there are other regressions, like the scheduler one I mentioned
[23:34] <Q-FUNK> afaik he was quoting some upstream developer as knowing that the increased power consumption was introduced some time back, but wasn't seen as such a priority issue
[23:34] <jjohansen> that should be fixed in the latest kernel
[23:37] <jjohansen> Q-FUNK: hrmm, there have been things that increased power consumption but where not major regressions
[23:37] <jjohansen> an hence were not high priority
[23:38] <Q-FUNK> well, considering that my +1 host is suddenly burning hot but never was before, I'd have to doubt that assumption
[23:38] <jjohansen> part of the problem with power is every machine is different so it is hard to test for regressions
[23:38] <jjohansen> that is it works for me and on my machines ...
[23:39] <jjohansen> Q-FUNK: not claiming you aren't seeing a major regression, just the general picture as seen by the kernel community
[23:39] <Q-FUNK> also, since recent kernels, 'dpkg' regularly manages to segfault.  it doesn't occur if I boot into an older kernel.
[23:39] <Q-FUNK> ok, fair enough :)
[23:39] <jjohansen> Q-FUNK: that sounds like a processor overheating
[23:40] <Q-FUNK> yup
[23:40] <Q-FUNK> but again, doesn't happen if I reboot into ... was it 2.6.38
[23:40] <jjohansen> Q-FUNK: well we can try bisecting the problem
[23:40] <Q-FUNK> 2.6.38-8-generic
[23:41] <jjohansen> but that is going to take installing more than a few kernels
[23:41] <Q-FUNK> it started happening sometimes during 2.6.39, but it was not too frequent.  now, with 3.0.0, it's nearly at every update
[23:42] <Q-FUNK> ... at every 'apt-get upgrade'
[23:42] <jjohansen> Q-FUNK: the tighter the range you can provide the better.  If you want me to bisect this, open a bug and subscribe me to it/point me to it
[23:43] <jjohansen> I can provide you kernels to test, I need to know a known good point and a known bad
[23:43] <Q-FUNK> jjohansen: that sounds good. I'm away from my +1 host this week, but I could return to the issue during the weekend and add you then.
[23:44] <jjohansen> Q-FUNK: okay, I'll keep an eye out for it
[23:45] <Q-FUNK> the control-k issue is on my natty laptop, though.  I haven't seen if it affects my +1 host too or not.
[23:46] <jjohansen> that one is just bizarre, I've never heard of such a problem
[23:47] <Q-FUNK> well, it could also be triggering some model-specific key combination.  this laptop is a dell, if it helps any.