[09:08]  * ppisati -> reboot
[09:28] <diwic> ppisati, hi, how did the pulseaudio beep go?
[09:29] <ppisati> diwic: using puleaudio from ppa:pulseaudio-testing i couldn't reproduce it anymore
[09:30] <ppisati> diwic: any plans to backport it to R?
[09:30] <diwic> ppisati, but I thought it was with 3.99 you got the beep?
[09:31] <ppisati> diwic: i got two different problems
[09:31] <ppisati> diwic: one was with the stock pulseaudio + e.g. skype, and the ppa stuf xied it
[09:31] <ppisati> *fixed it
[09:32] <ppisati> diwic: but then, two times, it happened that while i was playing some music
[09:32] <ppisati> diwic: the audio got stuck and i heard this noisy 'beeeeeeeeeeep'
[09:32] <ppisati> diwic: but i can't reproduce it anymore
[09:33] <diwic> ppisati, okay
[09:36] <diwic> ppisati, there are no plans to backport 3.99 into raring. I could possibly try to backport the actual minreq patch once we have 3.99/4.0 in saucy
[09:36] <diwic> ppisati, but then if 3.99 causes beeeeeeeeep, I want to fix that before releasing it into saucy
[09:36] <ppisati> diwic: :)
[09:37] <ppisati> diwic: i think you better release it, and let some more people try it out
[09:37] <ppisati> diwic: it happened to me two times in a row
[09:37] <ppisati> diwic: and then, after a day of usage, i didn't it anymore
[09:37] <ppisati> *hit it
[09:38] <diwic> ppisati, hmm, was there a reboot in between?
[09:38] <ppisati> diwic: a lot
[09:38] <diwic> ppisati, maybe the system was in some inconsistent state after installation but before reboot
[09:38] <ppisati> diwic: could be
[09:38] <ppisati> diwic: but the second time, it was after a reboot
[09:38] <diwic> ppisati, ah ok, then we rule that out
[11:31] <apw> ppisati, try reboots with and without power, i have seen inconsistent behaviour with those
[11:31] <apw> at times
[12:12]  * henrix -> lunch
[13:58] <ppisati> lp 1173073
[13:58] <ubot2> Launchpad bug 1173073 in skype (Ubuntu) "Broken sounds in Skype" [Undecided,Confirmed] https://launchpad.net/bugs/1173073
[13:58] <ppisati> diwic: FYI ^
[13:58] <diwic> ppisati, six users affected
[13:59] <diwic> ppisati, maybe worth the effort to try to backport to raring then
[14:00] <ppisati> diwic: i think there are more than 6 skype users running ubuntu :)
[14:01] <diwic> ppisati, I wonder if it really is the minreq patch that fixes it...
[14:02] <ppisati> diwic: another variable is that we got a new version of skype lately
[14:03] <diwic> ppisati, ok
[14:05] <diwic> ppisati, do you think I should package 3.0 plus the minreq patch up and ask people to test?
[14:06] <ppisati> diwic: let's first see which version of skype they were running
[14:07] <ppisati> diwic: if it's the latest, you can try packaging the fix
[14:08] <diwic> ppisati, is the current version 4.2 ?
[14:09] <ppisati> diwic: yes
[14:09] <diwic> ppisati, that's what's reported upstream
[14:09] <diwic> http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-May/017414.html
[16:56] <slangasek> smb: hi, around?
[16:57] <smb> slangasek, somewhat. whats up?
[16:57] <slangasek> smb: I have a very serious problem with kernel caches here which is just murdering my productivity; I've filed a bug but haven't made any headway on getting to the bottom of it.  I was wondering if you could help
[16:59] <smb> slangasek, Its rather the end of a day here and I would be off to a long weekend. But why don't you post the bug number here? Maybe someone has ideas
[17:00] <slangasek> smb: bug #1152736
[17:00] <ubot2> Launchpad bug 1152736 in linux (Ubuntu) "system swapping itself to death in raring for no good reason" [High,Confirmed] https://launchpad.net/bugs/1152736
[17:00] <slangasek> this first started affecting me in raring /that I'm aware of/; but I'm not sure if it was actually a regression in the raring kernel or if raring userspace was just the first one that started hitting the memory limit for me
[17:01] <smb> bjf, sconklin ^ at least I guess you wanna know about this
[17:01] <bjf> smb, i see it :-(
[17:02] <sconklin> ack
[17:03] <slangasek> currently updating the bug with comments based on my latest explorations
[17:03] <slangasek> can anyone tell me what the expected behavior of /proc/sys/vm/drop_caches is?
[17:06] <slangasek> bjf, sconklin: ok, added a note there
[17:09] <bjf> slangasek, i've read your latest comment. i have no good suggestions to make at this time.
[17:10] <slangasek> bjf, sconklin: FYI this issue is so bad in saucy that I had to SAK my desktop several times yesterday, and it's become virtually impossible for me to run a Google Hangout on this machine.  It could be getting worse due to regressions in the desktop footprint (e.g., firefox), but it's definitely not because of any changes in my usage patterns.  As I said above, this is destroying my productivity, so I would really appreciate any support
[17:11] <bjf> slangasek, i hear you
[17:12] <smb> I don't know the dm-crypt target internals to be able to say whether it does eat up those amounts of mem. Some targets (if they have to extend or rewrite io) can create an additional cache pool with some pre-allocated minimum
[17:12] <slangasek> smb: right... except the size of the cache changes depending on what apps are running, so it doesn't seem to be a fixed pool
[17:13] <smb> It would not be, just a minimum lower reserve 
[17:14]  * slangasek nods
[17:15] <slangasek> so the 'drop_cache' bit looks very suspicious to me... I would expect this to reset to 0 once the caches had been dropped
[17:15] <slangasek> and the fact that it never does smells funny
[17:18] <smb> slangasek, So that does not say anything but dm-crypt does create some mempools 
[17:19] <slangasek> I guess my next step is to try downgrading to precise/quantal kernels to see if it's reproducible
[17:20] <smb> Or manually install previous raring kernels (before you think it regressed)
[17:20] <smb> If it is something that slipped through stable it may affect current older releases too...
[17:22] <smb> slangasek, Also maybe /proc/slabinfo or /proc/meminfo may give some hints
[17:22] <slangasek> I think it regressed when I first upgraded to raring, fwiw
[17:23] <slangasek> I'll attach /proc/meminfo - nothing looked suspicious to me, but maybe one of you has better eyes
[17:24] <apw> i am not sure i would expect drop_caches to ever be able to make things go to 0
[17:24] <smb> slangasek, slabinfo might be more useful (but both dont hurt)
[17:25] <slangasek> smb: attached both
[17:25] <smb> slangasek, ta
[17:25] <slangasek> apw: you wouldn't expect 'cat /proc/sys/vm/drop_caches' to at some point return to 0 after it's decided it's done all it can?
[17:25]  * apw wonders what slangasek is doing different as he has not seen raring 'swap itself to death'
[17:25] <apw> slangasek, nope
[17:25] <slangasek> ok
[17:25] <slangasek> so what does it mean when it sticks at 3 - that it will forever after try and fail to drop all the caches? :)
[17:26] <apw> slangasek, hmm, i may be miss understanding your question
[17:27] <slangasek> apw: ok - I'm not saying I would expect the cache to drop to 0 after drop_caches, but that I would expect echo 3 > drop_caches to be a one-time instruction to the kernel to dump everything it can... after which I would expect things to reset to 0
[17:27] <apw> slangasek, i know why don't i look :)
[17:27] <apw> slangasek, i would it expect to dump things yes, i am supprised you can read it at all
[17:27] <slangasek> whereas what I'm seeing is that whatever value I echo there, persists... and it rejects an 'echo 0'
[17:29] <apw> slangasek, i see the same semantics indeed
[17:29] <slangasek> apw: I'm doing a *lot* of things different, but I've ruled out a lot of them as the cause. 1) using nfs mounts with krb5 authentication, 2) using LVM (for main filesystem, and also with snapshots), 3) using LUKS encryption for / and /home, 4) pretending that 4GB is enough RAM for a 64-bit desktop? :)
[17:29] <apw> slangasek, the behaviour is triggered on 'write' so what the value shows at is not particularly relevant
[17:30] <slangasek> NFS - I see the problem even if I unmount all NFS and shut down all the nfs-common services.  LVM snapshots - I see the problem even when no snapshots are active, or have been created since boot. LVM - lots of other people using LVM.
[17:30] <slangasek> apw: ok.
[17:30] <apw> slangasek, and yes as it is really a sysctl, it will only take 1 to 3 as a value, and so once you use it it is stuck at whatever value you used
[17:30] <slangasek> ok
[17:31] <apw> slangasek, but the kernel action is not taken on the value of the sysctl, but on the value at the time you write to it
[17:31] <apw> (which is vile and confusing, but at least safe)
[17:32] <apw> so you have 'swapping like a pig' as your symptom, and trigger is unknown
[17:32] <apw> and this is raring, i have a VM machine which runs raring with lots of vms and lvm things etc
[17:32] <apw> and don't see this, and a number of other raring boxes, nothing similar
[17:33] <apw> hmm
[17:34] <smb> slangasek, Hmm, at least in the attached meminfo Swaptotal and Swapfree are the same. Which somewhat is confusing...
[17:35] <slangasek> smb: it's a fresh boot, a) nothing's been swapped out yet because I haven't started to get memory pressure, b) I may have swappiness set to 0 right now :P
[17:36] <slangasek> apw: not just "swapping like a pig" - "failing to release 1.5GB of cache for a more appropriate use"
[17:36] <smb> slangasek, Well, when looking for a memory hog, the output of those _when_ it is swapping to death might be more useful. :-)
[17:36]  * rtg -> lunch
[17:36] <slangasek> smb: ok
[17:38] <apw> slangasek, but as your machine has 200MB of free ram, it can't be swapping anyhow, it doesn't make sense
[17:39] <slangasek> apw: it's not /currently/ swapping...
[17:39] <slangasek> apw: and when it does start to swap, it becomes difficult to capture useful snapshots of the state :P
[17:41] <apw> slangasek, yep so i would say, take the latest Q kernel and slam that on and see if that is any better
[17:41] <apw> as you are in a big hole right now
[17:41] <slangasek> yep
[17:42]  * apw doesn't expect drop_caches to make Cached go to 0, on my machine it dropped some 300MB though
[17:44] <apw> slangasek, drop_caches is just iterating the filesystem caches and dropping things not in actual use
[17:44] <slangasek> right
[17:44] <apw> slangasek, and putting pressure on the slab caches to try and make them shring, no guarentee that will do anything
[17:44] <slangasek> so on my machine, it will drop *some* cache, but it still bottoms out at 1.4GB in the pathological case
[17:44] <apw> if you are using your pages cause they are mapped, they are still mapped and drop_caches won't drop them
[17:45] <apw> so .. what has a big rss, which is holding them in
[17:45] <slangasek> hmmm, ok
[17:45] <apw> its not a 'remove pages i could not be using' option, it is 'remove pages i am not using'
[17:45] <slangasek> I guess I should check that too - I checked mappings for the LUKS-backed filesystems, but not for all of them
[17:45] <apw> which is why swapping might help as it were as it moves things to being 'not used'
[17:46] <apw> now what is the rsstop thing called
[17:49] <slangasek> smem?
[17:50] <slangasek> # smem -s rss -r | head -n2
[17:50] <slangasek>   PID User     Command                         Swap      USS      PSS      RSS 
[17:50] <slangasek>  4320 vorlon   /usr/lib/firefox/firefox --        0   702624   709561   729028 
[17:50] <slangasek> not really surprising
[17:51] <slangasek> except for the bit where that's a grotesque footprint
[17:51] <slangasek> (why are icon theme caches so big?)
[18:00] <apw> is that the best part of a 1G ?
[18:01] <apw> 24050 apw      chromium-browser               30988    97560   100071   114064 
[18:01] <slangasek> ayup
[18:02] <apw> even if i add all the chromium's together it is more like 200M
[18:02] <apw> with 20 odd tabs
[18:09] <cking> browsing ain't cheap
[18:12] <nsfx> Ahoy, I'm attempting to apply a patch to and re-install the kernel. I've followed https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel but I only end up with 1 deb instead of 3 as stated in the instructions
[18:12] <nsfx> Are there more up to date instructions somewhere?
[18:19] <apw> nsfx, i would expect those to be pretty close, which .deb did you end up with
[18:19] <nsfx> apw: I ended up with linux-headers-3.8.0-22_3.8.0-22.33_all.deb
[18:19] <nsfx> The double version scares me a bit, aheh
[18:20] <apw> that would be binary-headers, binary-generic did you include that ?
[18:20] <apw> the double version is deliberate
[18:20] <apw> so you can install more than one kernel
[18:20] <nsfx> apw: Yeah I ran: fakeroot debian/rules clean binary-headers binary-generic
[18:21] <nsfx> Actually the last step of that failed trying to stat a directory
[18:21] <apw> nsfx, then you probabally need to capture the output and pastebin it
[18:21] <apw> as it clearly failed
[18:21] <nsfx> apw: https://gist.github.com/adsr/7071d8f94e444525c926
[18:22] <nsfx> I'd named the kernel differently in menuconfig
[18:22] <nsfx> The directory it tried to stat did not include the label I appended
[18:22] <apw> the kernel packaging will not cope with that
[18:22] <nsfx> Ack, ok
[18:22] <apw> add something to debian.master/changelog, to the last version there
[18:23] <apw> like ~mine1
[18:25] <nsfx> apw: Cool, something like https://gist.github.com/adsr/ad558a541e9dbd29b0eb then ?
[18:26] <nsfx> Will that make it to the package name / allow me to differentiate between kernels in boot after installing?
[18:27] <apw> nsfx, not really no, that only shows up to the ABI number
[18:29] <nsfx> apw: Ah ok. If I make no modifications at all (besides applying the kernel patch) will it replace the current kernel or install alongside?
[18:29] <apw> it will replace the kernel of the same ABI number, whether you add ~foo or not
[18:30] <nsfx> Adding ~foo in changelog will change the ABI number? Sorry if I'm being thick :)
[18:31] <apw> no it will not
[18:31] <apw> there is no easy way to do that, and maintain any semblance of 'being based on' an ubuntu version
[18:31] <apw> we don't have a good derivative story there
[18:32] <nsfx> Maybe I should just wait for a bleeding edge release
[18:33] <nsfx> The patch is from 2010 actually and applies to quirks-table in ALSA for getting a USB MIDI device to work
[18:37] <nsfx> apw: Do you suggest filing a bug on launchpad?
[18:37] <nsfx> Not sure if that is the appropriate channel
[20:20]  * rtg -> EOD