[01:32] <psusi> I've noticed that Ubuntu kernels use a lot more memory than mainline ppa builds... I've compared the output of free and ps aux on both and can see no substantial difference in the rss total in ps, but free -m reports 545mb more used ram under the Ubuntu kernel
[01:32] <psusi> are there some reporting files in /sys or /proc somewhere I can't find to get more information on kernel memory usage?
[01:35] <jjohansen> psusi: /proc/slab/
[01:35] <psusi> jjohansen, no such dir...
[01:35] <jjohansen> err make that /proc/slabinfo
[01:35] <psusi> ahh ;)
[01:35] <psusi> nope, not there either
[01:36] <jjohansen> what kernel?
[01:36] <psusi> 2.6.35-rc3+
[01:36] <jjohansen> hrmm, ubuntu or mainline
[01:36] <psusi> mainline currently
[01:36] <jjohansen> I think its a config option
[01:37] <psusi> I built it with the config file taken from the current maverick kernel
[01:37] <jjohansen> psusi: can you open a bug, and report the disparity
[01:37] <psusi> yea... I intend do, was just hoping for some advice on getting more info that could be helpful for the report
[01:37] <jjohansen> hrmm, okay I'll have a look once my maverick install is done
[01:38] <jjohansen> /proc/slabinfo should be there
[01:38] <psusi> I was just looking in the kernel documentation and found slabinfo.c...
[01:41] <psusi> seems useful... going to check ubuntu kernel...
[01:44] <psusi> oh great... NOW it ISN'T hogging memory....
[02:11] <psusi> man it sure takes ages for the build farm to build the kernel... 3 hours and still going... iirc it takes me about an hour...
=== ericm-Zzz is now known as ericm
[03:04] <kees> ogasawara, JFo: this bug report isn't very great, but I don't know what to say beyond what I've put here: 597075.  any ideas to help me debug this?
[03:06] <ogasawara> kees: hrm, removing quiet and splash help show anything like a panic?
[03:07] <ogasawara> kees: can you attach lspci from when you boot 2.6.34?
=== jjohansen is now known as jjohansen-afk
[03:54] <psusi> jesus... the build farm is coming up on 5 hours compiling the kernel... what is it, a pentium-133? heh...
[04:40] <kees> ogasawara: yeah, no panic, nothing.  on a normal boot, the framebuffer loads, clears the screen and nothing else ever happens.  if I break=top, I get an initramfs prompt and it hangs.
[04:41] <kees> ogasawara: I've done a full apport-collect on that bug now.
=== ricotz_ is now known as ricotz
[08:18]  * smb waves good morning to .*
[08:18] <jk-> smb! just the guy...
[08:18] <cking> morning smb
[08:18] <jk-> do you have an ETA for the alsa backports to hit -proposed ?
[08:18] <smb> jk-, Uh oh... :)
[08:19] <jk-> :)
[08:19] <smb> which ones that did not?
[08:19] <jk-> oh, an update has gone up?
[08:19]  * jk- looks
[08:20] <smb> jk-, should be in proposed as you whished. :)
[08:20] <smb> IF you talking of Lucid of course
[08:22] <smb> linux-backports-modules-2.6.32 | 2.6.32-23.16 | lucid-proposed | source
[08:22] <jk-> smb: yep, Lucid
[08:22] <jk-> thanks :)
[08:24] <smb> jk-, NP. Actually the ALSA stuff was in -23.15 but it seems in minorly messed up and did not include the whole changelog since updates. :/
[08:25] <slytherin> On powerpc, power management in gnome-power-manager does not work correctly without loading pmu_battery module. What can be done to make it work out of box?
[08:29] <smb> slytherin, Hm, is there any bus information / IDs that could be used in module alias definitions
[08:29] <slytherin> smb: I don't know. I only know for sure this bug is affecting a lot of people and is open since karmic.
[08:31] <smb> The usual way in the kernel would be to have something like this but that might be better answered by someone who actually is doing work on ppc
[08:32] <slytherin> bug 458004 has relevant info. I can do necessary testing on my ibook. But I don't know enough to try kernel changes myself.
[08:32] <ubot2> Launchpad bug 458004 in linux (Ubuntu) (and 1 other project) "gnome-power-manger does not work in karmic ppc (affects: 2) (heat: 27)" [Medium,Triaged] https://launchpad.net/bugs/458004
[08:43] <kraut> moin
[08:49] <amitk> lag: nice overview of the suspend/resume debugging! :)
[08:49] <amitk> lag: did you discuss this with upstream?
[08:49] <lag> amitk: Thank you
[08:50] <lag> amitk: I believe it has. It has been passed to Matt? @ -mm
[08:52] <cooloney> lag: your email is quite helpful, since i also got suspend/resume on fsl-imx51
[08:57] <apw> smb, morning
[08:59] <smb> apw, morning
[09:00] <slytherin> smb: Can you please take a look at the bug and comment on what the next step should be?
[09:00]  * apw suspects it would be easier for him to do that if slytherin included bug #nnnn so that ubbotu could do her thing
[09:01] <smb> its above
[09:01] <smb> but i cannot really comment on ppc
[09:03] <slytherin> Should I bug TheMuso then?
[09:04] <apw> slytherin, i would say its a lack of a module alias, but presumably there is a simple work around of adding modules to /etc/modules
[09:05] <slytherin> apw: There is. But users want power management to work out of box.
[09:05] <slytherin> Specifically on laptops (ibook/powerbook etc).
[09:06] <apw> apple really should help the community to keep their laptops working shouldn't they
[09:07] <slytherin> They did till OS X 10.5. Now there is no powerpc support.
[09:08] <apw> slytherin, thats apple for you, don't care about their customers once the kit is a year old
[09:08] <slytherin> Anyway, what I was looking for is what is the best way to make it work out of box in Ubuntu. Sine we already know which module is needed, what is the next step.
[09:09] <apw> slytherin, you need to work out what feature of the platform indicates that that module is needed
[09:09] <apw> the module in the kernel has no load triggers.  there is no 'if this h/w exists you should load'
[09:11] <slytherin> How do I go about that. As per comment in bug 458004, "To make DeviceKit see the battery, pmu_battery kernel module needs to be  loaded."
[09:11] <ubot2> Launchpad bug 458004 in linux (Ubuntu) (and 1 other project) "gnome-power-manger does not work in karmic ppc (affects: 2) (heat: 27)" [Medium,Triaged] https://launchpad.net/bugs/458004
[09:15] <smb> I was trying look a bit at the whole thing, but my problem is that I don't see a pmu_battery module at all on the only ppc machine I can access (ppc64 though). There are battery modules but also have no alias . The only other mchanism other that matchin dmi information
[09:15] <smb> which ppc does not have, would be bus ids, which batteries usually also not have
[09:15] <smb> So probably some devicekit magic might be reasonable
[09:26] <slytherin> smb: What kind of magic?
[09:28] <smb> slytherin, Well, find out that the machine you are running is a ppc. The problem is, and that should be answered by someone who really understand ppc. How do you decide which battery module should be loaded and when. As I saw on that ppc64 machine there is no pmu_battery modules provided (at least not for Karmic). So what should be loaded then. And when. 
[09:28] <smb> And when not
[09:29] <slytherin> I can't say I understand ppc. I will check if anyone in Debian knows what to do.
[09:30] <apw> slytherin, normally such a module has aliases to load based on the machine type, so you would need to find a computer readable identifier for the machine which has this, the equivalent of dmi-decode on x86
[09:30] <apw> you can then tie the module to that existance.  you can tell if there is such a thing by 1) trying dmidecode, 2) looking at the udev logs to see if it fired an event for the device
[09:30] <apw> for the battery
[09:33] <slytherin> Will it be sufficient to check difference between udev log when module is loaded vs not loaded.
[09:33] <apw> slytherin, nope, the event would have fired if it exists
[09:34] <apw> slytherin, the way auto loading works is that the kernel detects things in the machine and triggers uevents, those go to udev which tries to match modules to them and autoload them
[09:34] <slytherin> hmm
[09:34] <apw> to be loaded a module has to advertise it understands something, some h/w attribute so that the udev triggers it
[09:35] <apw> now the module you want loaded doesn't do that so udev will never load it whether there is a trigger or not
[09:35] <slytherin> Ok.
[09:35] <apw> so you need to look a tthe udev log and see what h/w triggers appeared and see if there is one for the specific machine type or better for the battery
[09:36] <apw> slytherin, i would advise adding the udev log to the bug
[09:37] <slytherin> Doing that right now. Please note that I have already loaded the module.
[09:37] <jk-> slytherin: and maybe poke around in /proc/device-tree to see if there's a directory that describes the battery ?
[09:44] <slytherin> jk-: http://paste.ubuntu.com/453282/
[09:44] <slytherin> apw: Added udev log to the bug.
[09:48] <apw> jk-, any idea what this means: MODALIAS=ssb:v4243id0812rev05
[09:50] <apw> slytherin, its probabally not very convienient, but it would be helpful if the log didn't have the battery autoloaded
[09:50] <slytherin> apw: Ok. Let me reboot without the module.
=== ogra_ is now known as ogra
[10:01] <slytherin> apw: Attached the udev log without module loaded. If there is any more info needed, let me know.
[10:03]  * slytherin will be out for some time
[10:08] <apw> jk-, is there a machine identifier in of ?
=== smb is now known as smb-afk
[11:29] <jk-> apw: it should be in /proc/device-tree/model
[11:30] <jk-> it should contain something like PowerBook5,2
[11:30] <jk-> IIRC
=== smb-afk is now known as smb
[14:34] <BenC> wow, you guys have a ToS for IRC now
=== sconklin-gone is now known as sconklin
[14:53] <bjf> moin all
[14:59] <JFo> moin bjf
[14:59] <JFo> apw, this looks potentially important: bug 596257
[14:59] <ubot2> Launchpad bug 596257 in linux (Ubuntu) "MAJOR CRASH POSSIBLE: sysrq remains active with 2.6.35 (affects: 3) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/596257
[15:03] <JFo> hmm, they reference the patch that apparently fixes it
[15:46] <simar> Bug 569122 . Please help regarding the triaging  ... Logs can help ..
[15:46] <ubot2> Launchpad bug 569122 in linux (Ubuntu) "Resuming from hibernation fails (video garbage with nouveau, no progress/hibernation with nvidia-current) (affects: 2) (dups: 1) (heat: 68)" [Medium,Confirmed] https://launchpad.net/bugs/569122
[15:57] <tseliot> mjg59: what would be the right place to look at if my dell laptop's Print key behaves like SysRq when I press "Alt+Print"?
[15:59] <mjg59> showkey on the console is the easiest
[16:01] <tseliot> right, I was thinking in terms of code
[16:06] <tseliot> mjg59: it gives me code 56 and 99, which is not SysRq
[16:07] <tseliot> showkey -k, that is
=== ericm_ is now known as ericm-Zzz
=== jjohansen-afk is now known as jjohansen
[16:22] <JFo> ogasawara, do you want me to tag config request bugs with a kconfig tag?
[16:22] <JFo> I saw that you did that on one
[16:22]  * bjf is meeting the rest of the pdx mafia downtown, will be back online in a bit
[16:24] <ogasawara> JFo: that's what I'd been using in the past
[16:24] <JFo> cool
[16:24] <JFo> I can add that to the tagging wiki
[16:24] <ogasawara> JFo: sounds good
[16:24] <JFo> :)
[16:35] <tazz> i have a x86_64 i5 processor, would it be possible for me to compile a i386 kernel ? 
[16:50] <JFo> tgardner, what were the packages we wanted to add to bug metrics for the team meeting?
[16:50] <JFo> omap and what?
[16:50]  * JFo forgets
[16:50] <tgardner> ti-omap4 ?
[16:50] <tgardner> JFo, ^^
[16:50] <JFo> yeah, I have that one, wasn't there another?
[16:51] <tgardner> JFo, was it in the notes from last week IRC meeting?
[16:51] <JFo> think it was in e-mail, but I can't find it now
[16:51] <tgardner> 'cause I'm not really remembering what you're talking about
[16:51] <JFo> heh
[16:52] <JFo> you were telling the guys you wanted a status during the meeting for 2 projects
[16:52] <JFo> and I only remember the one
[16:52] <JFo> I'm sure it was an e-mail you sent out
[16:57] <tgardner> JFo, just looked through the notes. nothing is jumping out at me
[16:57] <JFo> ah well
[16:57] <JFo> I'll add the omap and maybe someone will remember during the meeting for next week
[17:09] <simar> hello
[17:15]  * bjf is back
[17:15] <jjohansen> be back in 5
[17:17] <gnomefreak> i have 2 bugs that seem to be the same (same error code and same problem) except they are not on the same version of kernel, one is 2.6.32-22 and the other is -23
[17:17] <gnomefreak> does that sound like the same? i can give bug numbers if you like
[17:22] <gnomefreak> see bug 596557 and bug 596293
[17:22] <ubot2> Launchpad bug 596557 in grub2 (Ubuntu) "package linux-image-2.6.32-22-generic 2.6.32-22.36 failed to install/upgrade: subprocess installed post-installation script returned error exit status 127 (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/596557
[17:22] <ubot2> Launchpad bug 596293 in grub2 (Ubuntu) "package linux-image-2.6.32-23-generic-pae 2.6.32-23.37 failed to install/upgrade: podproces instalovaný post-installation skript vrátil chybový status 127 (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/596293
[17:23] <manjo> cking, around ? 
[17:23] <cking> manjo, yep
[17:24] <cking> wassup?
[17:24] <manjo> cking, at the plugfest 
[17:24] <ogra> gnomefreak, these are users that followed very likely the ubuntugeek blog and broke their /etc/default/grub file by copy pasting 
[17:24] <ogra> gnomefreak, we have 100s of duplicates of that bug
[17:24] <manjo> cking, you said you were able to boot iso on virtual box 
[17:24] <manjo> was that the one with the modified grub ?
[17:24] <gnomefreak> ogra: ok thanks if i run into them i will mark them. Do you have a master bug #?
[17:24] <ogra> thanks to the blog software ubuntugeek uses which replaces quotes qith double backticks
[17:24] <JFo> did the team meeting time change?
[17:25] <bjf> JFo, no why?
[17:25] <cking> manjo, I was mistaken - my UEFI flag got flipped back to non-UEFI
[17:25] <JFo> just looked odd to me
[17:25] <JFo> maybe I just had too much coffee this AM
[17:25] <JFo> :)
[17:25] <bjf> JFo, 35 minutes from now
[17:25] <JFo> hmmm
[17:26] <manjo> cking, ok so we don't know yet if the new isos work... ok so I will make copies of the livecd iso and hand those out
[17:26] <ogra> gnomefreak, not from the top of my head, there is a guy (Jean-Baptiste Lallement) who did the collecting of these bugs for the last few weeks. i guess he has a master
[17:26] <JFo> the calendar shows it an hour and 35 from now bjf
[17:26] <JFo> so it did look funny to me
[17:26] <gnomefreak> ogra: thanks
[17:26] <JFo> whoops
[17:26] <JFo> nevermind bjf
[17:27] <JFo> figured out what it was
[17:27] <cking> manjo, well, may be worth trying it with one first before handing out a load
[17:27] <manjo> cking, yeah I have tried the livecd at home 
[17:27] <JFo> bjf, the KTeam cal hadn't loaded, so I was seeing the call on the Eng Cal
[17:27] <manjo> this is based on the iso that was prior last weekend 
[17:27] <JFo> heh
[17:27] <manjo> so last Thursday etc 
[17:29] <ogasawara> manjo: any progress with the new firewire stack bits?  will it make Alpha 2?
[17:29] <manjo> ogasawara, I sent out the patch to the ukml ... 
[17:30] <ogasawara> manjo: right, just curious if it's been applied and uploaded
[17:30] <manjo> tgardner, ^^ ?
[17:30] <ogasawara> manjo: I assume the second work item "add basic tests to kernel-qa to test new firewire stack." will slip to Alpha3?
[17:31] <manjo> ogasawara, yeah unfortunately I am out this week.. so next week I will be able to add some 
[17:31] <cking> manjo, looks like you may need to "wing it" a bit then
[17:32] <ogasawara> manjo: the tests aren't A2 release critical so I'll reset it to the A3 milestone
[17:33] <manjo> ogasawara, sure 
[17:33] <manjo> ogasawara, tests are not even part of the OS so its ok to slip I think 
[17:33] <ogasawara> manjo: ack
[17:34] <manjo> cking, intel just asked me if I have any server isos
[17:34] <manjo> cking, :) 
[17:34] <cking> not today
[17:35] <cking> manjo, suppose it's not out of the question is it?
[17:35] <manjo> cking, yeah they wanted us to show case the cloud stuff... 
[17:35] <manjo> cking there is another plugfest in October 13-15 Taipei
[17:35] <cking> manjo, nothing like being put on the spot
[17:36] <cking> Now that sounds like a good opportunity
[17:36] <manjo> cking, we should get someone out there for that one with maverick desktop & servers
[17:36] <manjo> cking, 2.2TB HDD looks like a big new thing that EFI supports and there is seagate & WD here with 2.2 drivers 
[17:36] <manjo> drives
[17:37] <cking> manjo, agree - want to forward the details of the Taipei plugfest to hugh and me?
[17:37] <manjo> cking, will do
[17:37] <cking> cheers
[17:43] <bjf> ##
[17:43] <bjf> ## Kernel team meeting in 20 minutes
[17:43] <bjf> ##
[17:56] <bjf> ##
[17:56] <bjf> ## Kernel team meeting in 5 minutes
[17:56] <bjf> ##
[18:03] <manjo> bjf, I won't make it to the meeting 
=== sconklin is now known as sconklin-lunch
[18:32] <slangasek> apw: hi, I have a stack of issues with the ti-omap4 kernel packages that I'm trying to unwind; the first is that I can't clone git from the documented URL :)
[18:35] <tgardner> slangasek, git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git
[18:38] <slangasek> tgardner, apw: so here are the main lintian problems that I'm concerned about in the ti-omap4 package:
[18:38] <slangasek> W: linux-image-2.6.34-900-omap4: postrm-does-not-purge-debconf
[18:38] <slangasek> W: linux-image-2.6.34-900-omap4: missing-debconf-dependency-for-preinst
[18:38] <slangasek> there's also a lot of changelog noise which probably just needs some tuning to whatever script generates those
[18:39] <slangasek> the postrm stuff ought to be fixable by making sure the maint script has a #DEBHELPER# token in it
[18:40] <slangasek> assuming you're using debhelper in debian/rules... which I hope you are :)
[18:41] <slangasek> the lintian warning wouldn't be there if you're not using debconf
[18:42] <apw> slangasek, ok thanks .... hrm
[18:43] <slangasek> apw: debian/control-scripts/preinst - inherited from kernel-package, blaaah
[18:44] <apw> see we get to blame debian :)
[18:45] <slangasek> heh
[18:48] <apw> i see all the debian kernels have the same warnings ... whee
[18:49]  * apw cries at how slow lintian is on a kernle package
[18:49] <slangasek> ick
[18:52] <apw> produce some output dammit
[18:54] <apw> no really i'd love to know your oppinion on my package, today
[18:55] <cking> patience is a virtual, apparently, but I've never gotten around to prove it.
[18:55] <apw> FINALLY
[18:55] <apw> slangasek, is there a way to say some warnings are wrong?
[18:55] <apw> W: linux source: native-package-with-dash-version
[18:55] <apw> W: linux source: changelog-should-mention-nmu
[18:56] <apw> its not clear we can avoid either of those
[18:56] <apw> W: linux-image-2.6.35-5-generic: windows-devel-file-in-package lib/firmware/2.6.35-5-generic/korg/k1212.dsp
[18:56] <apw> or indeed that one
[18:57] <slangasek> apw: yes, lintian overrides - I agree those should be overridden
[18:57] <slangasek> I think the lintian manpage documents how to declare overrides
[18:59] <apw> slangasek, yep found it, will get those added and get the others on the list to squash
[19:01] <JFo> bjf, you want that ftraceable bugs item on the arsenal BP?
[19:02] <bjf> JFo, we were maintaining a wiki page with arsenal todo items on it, that's where it should go so we don't loose track of it
[19:03] <JFo> k
[19:03]  * JFo goes to look for the page
[19:04] <JFo> hmmm, bjf do you have the link handy?
[19:04] <JFo> I apparently don't have it bookmarked and my wiki search fu is weak today
[19:04] <bjf> JFo, damn, i just knew you were going to ask... now i've got to go hunt for it :-)
[19:04] <JFo> heh
[19:05] <bjf> HA! too easy ... http://wiki.canonical.com/Kernel/Arsenal
[19:06] <JFo> nice
[19:06] <JFo> hmmm
[19:07] <JFo> bjf, you big kidder
[19:07] <JFo> I suppose that means you want me to create it :-P
[19:07] <bjf> JFo, just a sec
[19:07] <JFo> k
[19:07] <JFo> :)
[19:07] <bjf> https://wiki.ubuntu.com/Kernel/Arsenal
[19:08] <bjf> user error
[19:08] <JFo> cool
[19:08]  * tgardner lunches
[19:13] <JFo> cnd, do you think it would be possible for you to give me some ideas on what bugs you want to see in the 'ftraceable bugs'?
[19:13] <JFo> I suspect this is something where you want us to identify them and then ask them to do a specific set of commands
[19:13] <JFo> to provide the output to the bug
[19:20] <apw> slangasek, i am not seeing any whinges about our changelog format, have you an example
[19:24] <slangasek> apw: in the ti-omap4 package: W: linux-image-2.6.34-900-omap4: debian-changelog-line-too-long line 31
[19:25] <apw> slangasek, thanks
[19:36] <JFo> apw, do you see a use-case for mainline -server kernel builds?
[19:37] <JFo> someone is asking about them in a bug
[19:37] <apw> i don't know of any, do they have one?
[19:37] <tgardner> about the only differenxces are HZ and def scheduler and I/O settings
[19:38] <JFo> it made me wonder if it were something worthwhile for us to build as an unsupported test case for server users
[19:39] <shadeslayer> hi,can someone look at 593041
[19:39] <shadeslayer> bug 593041
[19:39] <ubot2> Launchpad bug 593041 in linux (Ubuntu) "New 2.6.35 kernel keeps toggling bluetooth radio (affects: 1) (heat: 6)" [Undecided,Triaged] https://launchpad.net/bugs/593041
[19:39] <shadeslayer> its getting worse with each kernel upgrade :P
[19:39] <jjohansen> what is the magic url for opening bugs again?
[19:40] <JFo> +filebug iirc jjohansen 
[19:40]  * JFo checks
[19:40] <ogasawara> jjohansen: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+filebug
[19:40] <tgardner> https://bugs.edge.launchpad.net/ubuntu/+filebug
[19:40] <jjohansen> thanks
[19:40]  * JFo ticks a point
[19:40] <JFo> ;)
[19:52] <jjohansen> -> rebooting and then switching venues
[19:56] <apw> $ lintian linux_2.6.35-5.7.dsc
[19:56] <apw> N: 2 tags overridden (2 warnings)
[19:57] <apw> $
[19:57] <apw> better me think
[20:20] <tgardner> ogasawara, Maverick git URLs in LP bugs become invalid the next time you rebase
[20:21] <tgardner> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/594382/comments/8
[20:21] <ubot2> Launchpad bug 594382 in linux (Ubuntu Maverick) (and 1 other project) "Wake up daisy chain activation failed on omap3 (affects: 1) (heat: 8)" [Critical,Fix committed]
[20:22] <ogasawara> tgardner: bah, you're right
[20:23] <tgardner> ogasawara, that particular commit also has a bogus buglink, I emailed you about it.
[20:24] <ogasawara> tgardner: I'll fix that up
=== sconklin-lunch is now known as sconklin
[20:54] <Azelphur> Hi, i keep getting an issue with my pc which i think is to do with kernel usb support, my keyboard/mouse will randomly start going very slowly, keystrokes arrive very slowly and often in the wrong order or not at all, mouse position seems to update twice a second, i tried replugging my keyboard, it took 3 minutes to be powered up again
[20:54] <Azelphur> i can only solve the issue by restarting my pc, restarting X does not solve it
[20:55] <Azelphur> and it happens seemingly at random
[20:55] <Azelphur> running 10.04 64bit
[21:05] <ogasawara> tgardner: was trying to schroot into maverick-armel on tangerine, but get the following error
[21:05] <ogasawara> tgardner: $ schroot -c maverick-armel
[21:05] <ogasawara> mmap: Operation not permitted
[21:06] <ogasawara> tgardner: no hurry on needing to get it fixed, was just testing if I could use the chroot to do a test build
[21:08]  * ogasawara lunch
[21:14] <tgardner> ogasawara, ack, looking into it
[21:16] <kees> ogasawara: your mmap_min_addr is too high.  install qemu-kvm-extras-static
[21:17] <tgardner> kees, rtg@tangerine:~$ dpkg -l|grep qemu
[21:17] <tgardner> ii  qemu-kvm-extras-static          0.12.3+noroms-0ubuntu9            static QEMU user mode emulation binaries
[21:17] <kees> hm, check /etc/sysctl.d/ ?  do you have 30-qemu-kvm-extras-static.conf ?
[21:18] <tgardner> kees, yep
[21:18] <tgardner> vm.mmap_min_addr = 4097
[21:18] <kees> what does   cat /proc/sys/vm/mmap_min_addr 
[21:18] <kees> say?
[21:19] <tgardner> 65536
[21:19] <kees> sounds like qemu-kvm-extras-static's packaging doesn't reload sysctl correctly.
[21:19] <kees> sudo service procps start    shoudl fix it
[21:19] <tgardner> 4097
[21:20] <kees> now the schroot should work
[21:20] <tgardner> kees, success!
[21:20] <kees> \o/
[21:20] <tgardner> kees, so, basically you need a reboot after installing qemu-kvm-extras-static.
[21:21] <kees> no, qemu-kvm-extras-static needs to call "start procps" in its postinst
[21:21] <tgardner> kees, I saw this on one other machine after a fresh install, so I think you're right
[21:22] <kees> tgardner: open a bug, should be a really easy fix for hallyn :)
[21:22] <tgardner> kees, doing so as we speak
[21:23] <tgardner> kees, its got this:
[21:23] <tgardner> # apply /etc/sysctl.d settings
[21:23] <tgardner> if [ "$1" = configure ]; then
[21:23] <tgardner>     invoke-rc.d procps start
[21:23] <tgardner> fi
[21:25] <kees> invoke-rc.d is wrong.  :)
[21:25] <tgardner> kees, so, change it to 'service procps start' ?
[21:25] <kees> the whole line should be "start procps"   (upstart fully broke invoke-rc.d, which was always wrong, iiuc)
[21:26] <kees> yeah, "service procps start" is more portable (to Debian) than just "start procs" but both will worki.
[21:39] <tgardner> ogasawara, tangerine armel schroot issue fixed thanks to kees
[21:39] <bguthro> Is anyone here particularly versed on the i915 driver?
[21:40] <bguthro> I've got a Dell Latitude E6410, that when switched to an external VGA display at the BIOS, will come up properly...but if left to its own devices, never displays on the LVDS connector
[21:41] <slangasek> kees: nooooooooo
[21:41] <kees> slangasek: ?
[21:41] <bguthro> lspci looks like its the "Ironlake" chip, referred to in drivers/gpu/drm/i915
[21:42] <kees> slangasek: but invoke-rc.d doesn't work...
[21:42] <kees> O_o
[21:42] <kees> tgardner: everything I said about invoke-rc.d is wrong.
[21:43] <kees> tgardner: something is still wrong in the qemu-... package though
[21:43] <tgardner> I'm getting that. how come?
[21:43] <kees> it looks like invoke-rc.d still works, and slangasek is trying to reach across the table here to hurt me
[21:43] <slangasek> tgardner: invoke-rc.d is still the only suitable interface for use in maintainer scripts.  Keybuk doesn't want this to be the interface for upstart jobs, but hasn't implemented its replacement yet
[21:43] <kees> tgardner: but something still didn't actually fire procps after qemu... installed.
[21:44] <slangasek> if there are any cases where invoke-rc.d currently fails, we should fix that instead of calling a different command
[21:44] <tgardner> kees, exactly
[21:46] <kees> slangasek: this has been a problem in other packages (wine) too.
[21:46] <slangasek> tgardner: was there any output in the dpkg log?
[21:46] <slangasek> then we shall fix it! :)
[21:47] <tgardner> slangasek, where is the dpkg log?
[21:47] <slangasek> tgardner: /var/log/dpkg.log
[21:47] <tgardner> nm
[21:47] <slangasek> actually, /var/log/apt/term.log is more useful
[21:48] <tgardner> kees, slangasek:
[21:48] <tgardner> Selecting previously deselected package qemu-kvm-extras-static.^M
[21:48] <tgardner> Unpacking qemu-kvm-extras-static (from .../qemu-kvm-extras-static_0.12.3+noroms-0ubuntu9_amd64.deb) ...^M
[21:48] <tgardner> Processing triggers for man-db ...^M
[21:48] <tgardner> Processing triggers for ureadahead ...^M
[21:48] <tgardner> Setting up binfmt-support (1.2.18) ...^M
[21:48] <tgardner>  * Enabling additional executable binary formats binfmt-support^M
[21:48] <tgardner>    ...done.^M
[21:48] <tgardner> ^M
[21:48] <tgardner> Setting up qemu-kvm-extras-static (0.12.3+noroms-0ubuntu9) ...^M
[21:48] <tgardner> update-binfmts: warning: /var/lib/binfmts/arm does not exist; nothing to do! ^M
[21:48] <tgardner> procps stop/waiting^M
[21:48] <tgardner> ^M
[21:49] <tgardner> Log ended: 2010-06-19  15:11:20
[21:49] <tgardner> I see that procps _was_ restarted
[21:49]  * kees scratches his head
[21:50]  * kees tries to reproduce locally
[21:51]  * slangasek nods
[21:52] <kees> worked correctly for me.  :(
[21:53] <tgardner> kees, me too. huh. the failure was on a 64 CPU machine. timing?
[21:53] <kees> O_o uhm
[21:53] <tgardner> kees, I can try it on that machine.
[21:54] <kees> basically, installing and purging qemu-kvm-extras-static each time it should change /proc/sys/vm/mmap_min_addr
[21:56] <tgardner> kees, dang, it worked that time. I purged and restored /proc/sys/vm/mmap_min_addr to 64K, then reinstalled.
[21:57] <kees> tgardner: purging should restore mmap_min_addr on it's own (due to /etc/sysctl.d/10-zeropage.conf)
[21:58] <tgardner> kees, I didn't actually check first
[21:59] <slangasek> and there's a bug in the postrm, purge will fail if the procps package has been uninstalled :)
[22:00] <tgardner> kees, slangasek: well, I'm gonna let you wizards deal with it. Its EOD for me.
[22:00] <kees> if procps has been uninstalled I won't debug that system.  :)
[22:01] <kees> tgardner: cool, thanks.  weirdness.
[22:01] <tgardner> kees, non-sequitur, I think it should be YAMAC (Yet Another Mandantory Access Control) LVM
[22:02] <kees> it's not a MAC!  :)  It's a NAC.   NAKed Access Control system
[22:02] <tgardner> maybe this attempt will get some traction
[22:20] <kamal> jjohansen: ping
[22:21] <jjohansen> kamal: pong
[22:21] <kamal> is the atop patch being considered for lucid kernel, or just maverick?  (I have it working in lucid with just one tiny change)
[22:21] <jjohansen> maverick
[22:22] <jjohansen> it isn't something we will sru
[22:22] <kamal> that was my guess (but was easier for me to test / play with in lucid :)   ok, I'll check applying it to maverick.
[22:23] <jjohansen> yeah, completely understood.  I had considered that too
[23:18] <bjf> JFo, around?
[23:43] <stenten> For bug reports, what subsystem are Oopses under? kernel-core?
[23:46] <ogasawara> stenten: if you're not sure which subsystem the oops is coming from I'd use kernel-uncat
[23:46] <ogasawara> stenten: we review those weekly and it'll then get shuffled to the right category
[23:50] <stenten> ogasawara: ok, thanks!