=== BenC2 is now known as BenC
=== bjf is now known as bjf-afk
[03:49] <RAOF> Hi.  I'm trying to see how well nouveau works against the current drm in lucid's kernel; apparently it should (probably) work.
[03:50] <RAOF> This means I need to work out how to regenerate the configs for the kernel build; the wiki page https://wiki.ubuntu.com/KernelTeam/KernelMaintenance?highlight=(config)|(kernel)|(edit) seems to be out of date.
[04:01] <RAOF> Aha.  You just need to generate debian/control first.  Right.
[05:23] <akgraner> RAOF, just wait til later in the week, when the kernel team produces crack of the day nouveau builds...  It won't build natively in Lucid it requires the tip of drm from upstream
[05:32] <RAOF> akgraner: Does it actually require the tip of drm, or can it work against the drm as found in Lucid?  Because it _builds_ fine against Lucid's drm, and then my /home gets full :(
[05:32] <RAOF> akgraner: And darktama (nouveau dev, and fedora maintainer) suggested that it should work against 2.6.32's drm.
[09:10] <cwillu> bug 380807
[09:10] <ubot3> Malone bug 380807 in linux "[karmic, intel] Laptop locks up moments after resuming from suspend" [Medium,In progress] https://launchpad.net/bugs/380807
[09:15] <apw> cwillu, thats most bizarre.  why are you the only one who sees this.  i suspend machines with that confiurations 10's or more of times a week without issue
[09:16] <cwillu> which configuration?  I'm presuming you don't have the exact hardware :)
[09:17] <cwillu> the suspicion before was that there was something odd in the bios/whatever;  2.6.30 brought in suspend changes that were (obviously? maybe not...) thought to be responsible
[09:18] <cwillu> but my git bisect _did_ come back to the filesystem code, and the way that it crashed would seem to match that.
[09:18] <cwillu> I did a install to a fresh 4gb partition with an ext4 root, and still got the same crashing
[09:19] <cwillu> so it seems unlikely to just be some lingering metadata breaking stuff
[09:19] <cwillu> or corrupted whatever
[09:19] <cwillu> I'm open to suggestions for the next thing to try :p
[09:22] <apw> hrm ... i worry that btrfs is just lucky that its not affected.  which commit did your bisect finger
[09:23] <cwillu> a moment, haven't looked at it in a while
[09:27] <cwillu> sigh, can't find it.  I'll run the bisect again after work tomorrow :(
[09:40] <cwillu> just going through my irc logs, I'm pretty sure I mentioned it in here
[09:41] <amitk> cwillu: remember to add that info to the launchpad bug next time, so you don't have to suffer the bisect again :)
[09:43] <cwillu> I think I did, I just didn't add enough context to prove its the bisect I think it is :p
[09:43] <cwillu> I had two bugs crop up at the same time, an intel crasher, and this longer-acting one
=== shaharh is now known as soliko
[14:13] <slytherin> is there any ETA on when 2.6.31.6 will make into karmic-proposed?
[14:21] <mdz> I read about the low latency cfq scheduler in 2.6.32 on kernelnewbies: http://kernelnewbies.org/Linux_2_6_32#head-e07f19bb79beab04cb9e68b942c9041b490b71db
[14:21] <mdz> we use cfq in -generic, and deadline in -server, right?
[14:23] <rtg> mdz, yes, that is correct
[14:24] <mdz> rtg: thanks
[14:25] <rtg> mdz, I read the same article. it appears there have been some improvements which we need to explore.
[14:25] <mdz> rtg: sounds like good stuff for the desktop, but something we might want to opt out of on the server, so I wanted to confirm it didn't affect us(server)
[14:26] <mdz> I like the rename of KSM to a somewhat less confusing name
[14:26] <rtg> mdz, right, we haven't changed the I/O scheduler settings from Karmic.
[14:29] <rtg> mdz, I think KSM requires some userspace support to enable. dunno if the server team has that on its radar
[14:31] <mdz> rtg: does it? I thought it just worked.  if it requires some userspace support, I'd like to hear about it because we definitely want that functionality
[14:32] <rtg> mdz, there is some sysfs twiddling that needs to happen IIRC. I'll get smart about it and annoy kirkland with the details.
[14:33] <mdz> rtg: thanks. maybe you or jjohansen could bring the details to the server meeting on Wednesday
[14:33] <rtg> mdz, can do
[15:14] <rtg> mdz, https://lists.ubuntu.com/archives/kernel-team/2009-December/007969.html (in case you're not subscribed)
=== bjf-afk is now known as bjf
[16:00] <dandel> weird, i can't seem to disable the radeon module by blacklisting it 0o'
[16:44] <apw> Keybuk, u have mentioned a patch for listing modules which are builtin ... did that hit mainline, or do you still want it?
[16:45] <Keybuk> it hasn't hit mainline yet
[16:45] <Keybuk> but we want it
[16:47]  * Keybuk makes LCARS "working" noises
[16:48] <Keybuk> mmarek@suse.cz is the author
[16:48] <Keybuk> just trying to find his latest patch
[16:48] <apw> Keybuk, thanks
[16:49] <Keybuk> looks like it's in -mm
[16:50] <Keybuk> -next I mean obviously
[16:51] <CarlFK> what package should I bug this against?   [ 5355.182137] This should not happen.!! Data will be lost ... Call Trace: ext4_da_writepages+0x4cc/0x500  http://paste.ubuntu.com/336658/
=== stgraber_ is now known as stgraber
[16:52] <apw> linux (the kernel)
[16:52] <Keybuk> apw: basically this patch is in that strange limbo where it's scheduled for the .33 merge window
[16:52] <Keybuk> so it means I CANNOT FIND IT! :D
[16:53] <apw> most typical.  well i guess it'll be in linus soon enough then then i can pick it from there
[16:55] <Keybuk> according to akpm, these are the patch names:
[16:55] <Keybuk> kbuild-generate-modulesbuiltin.patch
[16:55] <Keybuk> kbuild-rebuild-fix-for-makefilemodbuiltin.patch
[16:55] <Keybuk> kbuild-generate-modulesbuiltin-fix-2.patch
[16:55] <Keybuk> kbuild-generate-modulesbuiltin-fix-2-checkpatch-fixes.patch
[16:55] <Keybuk> I don't know where he puts those though
[16:55] <Keybuk> they're in his queue
[16:56] <Keybuk> http://userweb.kernel.org/~akpm/mmotm/broken-out/
[16:56] <Keybuk> aha
[16:57] <Keybuk> they're all in there
[17:00] <mdz> rtg: thanks
=== Traxer is now known as Traxer|off
=== Traxer|off is now known as Traxer
[17:43] <Keybuk> apw: don't suppose you could build me a kernel with the current set of "performance" patches applied
[17:43] <Keybuk> Surbhi's populate_rootfs() patch obviously, also whatever you have for the isapnp stuff and the EDID cacheing for i915
[17:43] <Keybuk> (and anything else you're tracking)
[17:44] <apw> Keybuk, sure 
[17:45] <drpoo> Here is how ubuntu cancer cells are destoryed
[17:45] <drpoo> http://www.youtube.com/watch?v=6Q4JrmE50SU
[17:45] <Keybuk> apw: just interested what a difference it'll make :p
[17:46] <drpoo> the small blue things are cytotoxic t cells
[17:47] <apw> Keybuk, and there i was wanting to sneak it up on you straight after a-1
[17:47] <drpoo> http://www.youtube.com/watch?v=6Q4JrmE50SU
[17:47] <drpoo> the immune system seems to over power linux cancer cells.
[18:33] <CarlFK> who has the power to edit the text on https://bugs.edge.launchpad.net/ubuntu/+source/linux/+filebug
[18:33] <CarlFK> says "Please report a bug about the kernel using the following command in a terminal:  ubuntu-bug -p linux"
[18:34] <CarlFK> which throws "Warning: The options -p/-P are deprecated, please do not use them.  See /usr/bin/ubuntu-bug --help"
[18:39] <rtg> ogasawara, ^^ Isn't it just 'ubuntu-bug linux' ?
[18:39] <ogasawara> rtg, CarlFK:  yah, just use 'ubuntu-bug linux' instead
[18:40] <ogasawara> CarlFK: I'll follow up and see about getting the +filebug text updated
[18:41] <CarlFK> ogasawara: good - was trying to figure out how to file a bug report against the bug report instructions :)
[18:44] <ogasawara> CarlFK: so it'll get updated after Lucid releases since Hardy still requires the -p option
[18:46] <CarlFK> ogasawara: might want to add a note about that - I am on karmic, did ubuntu-bug linux, reviewed possible hits, got to that page, filled out report, scrolled down, saw the "use -p" and was grumpy that I needed to start over.  
[18:46] <CarlFK> out of lazyness I didn't close the browser, so when I got the "dont use -p" I could just go back and finish up
[21:53] <Keybuk> apw: I've just noticed a major thinko with our kernel config ;)
[21:53] <Keybuk> # CONFIG_DEVTMPFS is not set
[21:53]  * Keybuk has been assuming that was =y :p
[22:15] <MTecknology> Can anyone help me figure out how to fix this bug? 492719
[22:16] <MTecknology> bug 492719 *
[22:16] <ubot3> Malone bug 492719 in linux "Function keys not detected on Vaio VGN-FZ240E" [Undecided,New] https://launchpad.net/bugs/492719
[23:30] <RAOF> Gah.  The kernel-team meeting is at 4am for me.
[23:31] <dtchen> heh, I hardly ever make them unless I take a vacation day
[23:31] <dtchen> same with Development Membership Board, etc.
[23:39] <HardDrive> TAKE PUBLIC TRANSIT IT IS GREENER!
[23:53] <dtchen> RAOF: which hardware do you have that's driven by nouveau?
[23:53] <dtchen> last I tried it, this nVidia Corporation C67 [GeForce 7150M / nForce 630M] (rev a2) had really horrid stability
[23:56] <RAOF> dtchen: I've got a 7600go and a 6600gt; they're both nv4x chips, and neither is integrated (which is what yours is?).
[23:57] <dtchen> correct
[23:57] <RAOF> When did you last try nouveau?
[23:57] <dtchen> karmic
[23:57] <dtchen> err, maybe one month ago
[23:57] <RAOF> The packages from karmic universe?
[23:58] <dtchen> yes
[23:59] <RAOF> They're moderately old; it's entirely possible that stability will have improved for you.
[23:59] <dtchen> certainly.
[23:59] <RAOF> What stability problems were you seeing?
[23:59] <dtchen> I don't really relish hacking on sound/pci/hda/* via ssh, however