[03:03] <abhijit> I am seeing an issue here  have 25G of RAM, and swapiness is set 0 , with no swap device.  I see that when the free memory reaches 500M the kswapd kicks in and starts freeing around 13G  and the CPU utilisation shoots to 100%  I have also tried adding 24G of swap and I see the same issue (when the swapiness is 0)  ..  I dont like the cpu utilisation shooting to 100% and freeing such a huge 13G size.  Is there a way to reduce both of
[03:03] <abhijit> them?   I am on 2.6.38.6
[04:09] <LLStarks> hi, is iwlwifi missing from 3.2 debs? i can't find it outside of the precise.git repo.
[08:55] <TeTeT> hello, one of our customers experiences random crashes on a x220 with the lowell build. They are adding drm.debug=0x06 to the grub command line to get more logging from drm. Are there any other options that can be enabled to increase log verbosity? Note that the system freezes completely, neither ssh nor sysreq key have any effect
[09:12] <ppisati> morning *
[09:23] <smb> morning +*
[09:26] <smb> TeTeT, If you replace the "quiet" with "debug" you generically raise the log level. Not sure that will make that much of a difference.
[09:26] <smb> (in the grub command line that is)
[09:26] <TeTeT> smb: thanks, I'll recommend that
[09:28]  * apw yawns
[09:48] <smb> apw, morning 
[09:55] <apw> heloo
[12:46] <diwic> smb` or apw, do you have a sense for the response to https://lists.ubuntu.com/archives/kernel-team/2011-November/017692.html ? The answer of that question would sort of dictate what I'll do next week
[12:49] <apw> they are pretty huge.  if we think overall that support is easier with them then we might be persuaded
[12:49] <apw> i assume there is no hope stable would take them which might make life tricker longer term
[12:49] <smb> And doing so sooner than later can help to find out how much pain this gains...
[12:50]  * smb assumes we are talking about precide
[12:50] <apw> yes, this is for precise
[12:50] <apw> we are in more of a position to take them and see how painful things are at this stage
[12:52] <apw> diwic, ^^
[12:53] <diwic> apw, hmm
[12:54] <diwic> apw, I do think they'll fix up the jack detection stuff for a lot of people; with jack detection meaning exposing the stuff to userspace rather than in-kernel automute
[12:54] <apw> it is a risk tradeoff, ease of kernel maintenance due to being closer to mainline, against ease of support of users h/w which might just work, plus a component on how hard pulse is to make work in each case
[12:54] <apw> we are in your hands for the ease part for pulse and for new quirks as you do both
[12:56] <diwic> ok, so from my side of things we should definitely take them (once they've been tested a little bit more upstream), but then I don't see much of the "kernel maintenance" part
[12:56] <apw> diwic, also does that imply that with jack handling moving to userspace that pulse with work but if you use jack et al your sockets will stop muting etc
[12:56] <diwic> apw, automute is still done in kernel space
[12:56] <apw> well i guess we get a lot of audio stuff from stable which would likely collide with these changes yes?
[12:57] <apw> though a lot of that comes from you anyhow
[12:57] <apw> and perhaps with this added we won't get them
[12:57] <diwic> most stable stuff will be oneliners and at quite different places compared to this one
[12:58] <smb> apw, Hm, one argument may be that if that all lands 3.3 then any stable updates will be rather fix the new than the old style (for the maintaining thoughts)
[12:59] <diwic> so you might ask, if automute is done in the kernel, how does this affect people? Well, pulseaudio is involved with port selection, which in practice means that when you plug your headphones in, changing volume on your media keys will start to control your headphone volume instead of your speaker volume
[13:00] <diwic> instead of manually have to go to speaker -> sound preferences -> output -> connector -> change to headphones 
[13:01] <diwic> every time you plug your headphones in
[13:01] <apw> ahh i see
[13:01] <diwic> smb, that's actually an interesting point
[13:01] <apw> so overall i am not anti, just wary of it
[13:03] <diwic> I'll work on the pulse parts next week, and then the question would be if I should spend time testing the old or new kernel interface
[13:04] <diwic> but I guess I'll go with the working theory of that we're taking the new interface (that could use some testing either way!)
[13:06] <smb> diwic, Generally this is something to weight risk against use. P is an LTS, so of course we all try to minimize the risk of very new things. However if you as the expert in that area have the feeling the gains are big enough we should consider it. And rather early so we see any problems soon enough to have time for plan b...
[13:12] <diwic> smb, risk wise the old interface was tested in oneiric and turned out to be stable but not adding enough jacks for many devices, so PulseAudio would not pick it up. The new interface will be used by other upcoming distros (as it's being blessed by upstreams) so in time it'll be more stable than the old one. Question is what "in time" really means here
[13:12] <diwic> smb, I do have faith in Takashi here, he's very good in writing code that does not randomly screw up things
[13:14] <smb> diwic, I guess in time sort of is defined as how much you will hear me and apw cursing about pa at the next ralley... ;)
[13:16] <smb> But yeah, I guess I tentatively would go forward and see the outcome
[13:17] <diwic> ok, thanks for the answers!
[13:39] <Nafallo> hi! I'm looking for some information about a regression in the iwl3945 driver I've discovered on my laptop.
[13:40] <Nafallo> first I thought it was my old hardware getting flakey, but the common denominator struck me this morning.
[13:41] <Nafallo> when the AP is a UDS-style Cisco, I keep loosing the connection and re-associating ever so often.
[13:41] <Nafallo> is there a bug open about it yet?
[13:41] <Nafallo> this is up-to-date oneiric, with -proposed.
[14:00] <brendand> Nafallo - which wireless card do you have?
[14:02] <Nafallo> brendand: 03:00.0 0280: 8086:4227 (rev 02)
[14:02] <Nafallo> "Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)"
[14:03] <Nafallo> I'm happy to file a bug and help debug this, both using new unreleased test kernels and with older kernel ABIs to try and determine when this issue first appeared.
[14:04] <Nafallo> it's only oneiric. that much I'm sure of, but I can't remember when it started. I upgraded around beta1.
[14:05] <apw> Nafallo, are you saying on a cisco, or on those ciscos in the UDS environment
[14:06] <apw> (there are typically many more stations and more APs with the same SSID etc
[14:07] <Nafallo> apw: the same type of ciscos in the UDS environment. I'm on a linksys WRT54GL 1.1 right now just to prove it doesn't happen with them, and it's stable.
[14:08] <Nafallo> apw: I see this in the millbank office, with four APs (IIRC) and also in one more place running the same AP, but just a single one.
[14:08] <Nafallo> apw: same issue on both b/g and a bands (different SSIDs)
[14:08] <apw> ok, so some interaction between the two, that won't be hard to fix oh no
[14:08] <Nafallo> heh.
[14:08] <Nafallo> this is why I want to narrow it down to a specific kernel ABI at least :-)
[14:09] <apw> if you can find a kernel which it works with that'd be great
[14:09] <brendand> i'm curious to know if it's a regression
[14:09] <Nafallo> brendand: it is. this all worked fine in natty :-)
[14:10] <Nafallo> well. any previous release I have had installed would be more correct, and I've had this hardware since 7.10 :-P
[14:10] <brendand> Nafallo - well, I meant a -proposed regression or whether it also doesn't work with the release kernel
[14:10] <apw> Nafallo, its possible there is a firmware change between natty and oneiric too
[14:10] <Nafallo> brendand: ah. yes.
[14:10] <brendand> Nafallo - 3.0.0-12-generic-pae #20
[14:10] <brendand> (pae not being important)
[14:10] <Nafallo> brendand: I've got ABIs 11, 12 and 13 installed, and I plan to try next time I'm close to one of these Ciscos.
[14:11] <Nafallo> oh, this is also x86_64. not sure if that matters.
[14:11] <Nafallo> hrm. I should probably try the precise kernel on my 11.10 installation as well? just to see if it has been fixed upstream?
[14:11] <apw> Nafallo, if it failes with one, make sure you take one of them with you home so we can continue to test :)
[14:12] <apw> Nafallo, yep, all good tests, find a bracket in which it broke
[14:12] <brendand> Nafallo - can I have the exact details of the router involved?
[14:13] <Nafallo> brendand: Cisco AIR-AP1131AG-E-K9
[14:13] <Nafallo> (Cisco Aironet 1130AG series)
[14:13] <apw> Nafallo, i assume we can borrow one for testing and you are the clear ideal person
[14:13] <tjaalton> how can i verify that a certain version of a module is used (with dkms replacing some)
[14:14] <Nafallo> apw: yeah. I just need to confirm I can clear the config of the ones I have in the DC with my manager, but I think it shouldn't be a problem.
[14:14] <Nafallo> apw: I've got ~24 of them a few metres away in a flight case ;-)
[14:15] <smb> tjaalton, "modinfo" would print a path, I guess you mean that
[14:15] <tjaalton> smb: excellent, thanks
[14:15] <tjaalton> just what i needed
[14:16] <tjaalton> a silly drm-dkms backport worked after all :)
[14:16] <smb> Always good when things finally work
[14:16] <smb> :)
[14:16] <tjaalton> yes, especially when it's friday and soon to be beer o'clock
[14:16] <apw> Nafallo, thought you might :)
[14:17] <smb> tjaalton, Ah good point. :) 
[14:17] <tjaalton> :)
[14:18] <smb> apw, We need to both switch to the Finland tz. Its so much more convenient...
[14:18] <Nafallo> I also found https://launchpad.net/ubuntu/oneiric/+source/linux, which should be helpful in my testing ;-)
[14:19] <apw> its cirtainly feasable as our beer-meter time zone
[14:22] <Nafallo> that's UTC+2, right?
[14:24] <apw> yeah
[14:24] <Nafallo> the linksys connection is fine for sure. grabbed a ~630MB file while chatting to you guys ;-)
[14:24] <Nafallo> no drop outs.
[14:24] <Nafallo> science!
[14:54] <ppisati> herton: is the verify-release-ready tool supposed to work with maverick/mvl-dove or not?
[14:55] <herton> ppisati: nope, it fails. I'm not sure it's worth fixing just for it
[14:55] <ppisati> ah ok
[14:57] <herton> as maverick/mvl-dove is non standard in respect to the abi  files it tries to find, just ignore it, we can check by hand for now
[14:59]  * herton -> lunch
[15:08]  * ogasawara back in 20
[17:46] <cwillu_at_work> what's up with the missing -i386 mainline kernel debs?
[19:25] <komputes> Hi everyone, I see the two the i386 mainline kernel packages I expected are missing. Any ideas why this is?: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc1-oneiric/
[19:29] <Sarvatt> komputes: its in the build.log there, some drivers failed to build on i386
[19:29] <komputes> Sarvatt: ah, who to report this to?
[19:31] <Sarvatt> the dailies will start building soon, looks like theres an upstream fix http://www.gossamer-threads.com/lists/linux/kernel/1453092
[19:32] <komputes> great, looking forward to it, cheers Sarvatt 
[19:36] <LLStarks> sarvatt, iwlwifi hasn't been building for amd64
[19:50] <Sarvatt> brcmsmac either
[20:12]  * herton -> eow