[00:02] <Notch-1> hi, any news about the loop module? still =y?
[01:29] <MTecknology> Notch-1: it is by default
[01:29] <MTecknology> Notch-1: I'm running w/o it
[01:30] <MTecknology> 1.5hr later..
[02:04] <geoff918> I recently tested my system, which works, and I can't add it to this page: xbRiAnNa o7x
[02:04] <geoff918> oops
[02:04] <geoff918> this page: https://wiki.ubuntu.com/KernelTeam#Contacts
[02:05] <geoff918> https://wiki.ubuntu.com/KernelTeam/Grub2Testing
[02:05] <geoff918> geeze...
[02:05] <geoff918> Anyway, I have an Acer Aspire 5610
[02:07] <Notch-1> MTecknology: yeah, i'm recompiling, again :D
[02:08] <MTecknology> Notch-1: I think I'm done tweaking for now - the kernel size is down to 2.2MB
[02:08] <Notch-1> this really sucks, i could use a clean default normally-upgradable kernel...
[02:09] <Notch-1> i don't want to tweak
[02:10] <MTecknology> Notch-1: why aren't you using that?
[02:11] <Notch-1> i need to use loop-aes..
[02:13] <Notch-1> my life was seriously better when it was =m
[02:13] <MTecknology> did you file a bug about it?
[02:14] <Notch-1> yeah, it's an old story...
[02:15] <Notch-1> in few words, some people care too much about some microseconds at boottime
[02:16] <MTecknology> you mean me?s
[02:19] <Notch-1> i don't think so, since you seem to don't know the problem yet, but i don't know so much... look here if you want to know... https://bugs.launchpad.net/ubuntu/+source/loop-aes-source/+bug/342902
[02:19] <ubot3> Malone bug 342902 in loop-aes-source "Build error: ‘struct bio’ has no member named ‘bi_hw_front_size’" [Medium,Triaged] 
[02:25] <Notch-1> beside, the original real compiling bug, indipendent of the the kernel configuration, was never fixed because this thread ended in nothing. so even if i recompile the kernel without loop, i still need to download the loop-aes source from sourceforge because the repositorys one is bugged... there are 2 unhandled problems with loop-aes since jaunty
[02:28] <Notch-1> i hope that you used the correct version for karmic, there were 2 or 3 bugged ones, i don't have the versions now... this will solve one problem, at least...
[02:30] <MTecknology> sorry - internet died
[02:30] <MTecknology> I didn't even know if that sent
[02:31] <MTecknology> Notch-1: I meant the millisecond thing - I now have a 10sec boot across the area I care about
[02:31]  * MTecknology hoping that I didn't remove something I need
[02:34] <Notch-1> ah you did that for the boottime? :D
[02:36] <MTecknology> hm?
[02:41] <Notch-1> you recompiled the kernel to speed up the boot? i will never do that :D anyway i was talking about the default configuration, the people that make decisions that should be best for everybody... sigh...
[02:42] <MTecknology> sorry :(
[02:42] <MTecknology> how is it that you're recompiling it?
[02:43] <Notch-1> i told you, this freakin loop module...
[02:43] <MTecknology> how is it that you're recompiling it? - not what are you trying to do
[02:44] <MTecknology> I just pulled the git branch, grabbed the default .config (tossed it together from 3 .configs), make menuconfig, make all modules_install install && update-grub
[02:44] <Notch-1> ah
[02:44] <Notch-1> not exactly, it's very hard to find the original formula :D
[02:45] <MTecknology> the ubuntu kernel is rolled out differently, but that's because it reaches a larger base
[02:45] <Notch-1> anyway yes with git, the exact current version
[02:45] <Notch-1> with AUTOBUILD=1 skipabi=true skipmodule=true fakeroot debian/rules binary-debs
[02:45] <Notch-1> after a menuconfig and a clean off course
[02:46] <MTecknology> sounds harder than what I did
[02:46] <Notch-1> what you mean?
[02:46] <MTecknology> did you wind up making a .deb?
[02:47] <Notch-1> hard it's not good, i prefer soft :D
[02:48] <Notch-1> you mean just rebuild the kernel and replace it by hand?
[02:48] <MTecknology> When you finished creating the kernel, did you have a .deb package you could install with dpkg?
[02:48] <Notch-1> yes
[02:49] <MTecknology> then you went the hard route ;)
[02:49] <MTecknology> do you have ccache installed?
[02:49] <Notch-1> i understand, but wich is the softer one?
[02:49] <MTecknology> softer?
[02:50] <MTecknology> I mean that you went through more effort than you needed to if you're making a kernel for your system only
[02:50] <Notch-1> ah ccache, i read about it...
[02:51] <MTecknology> You should install it - it makes a difference when you compile
[02:51] <MTecknology> What proc do you have?
[02:51] <MTecknology> how many cores
[02:51] <Notch-1> softer=better
[02:51] <Notch-1> just one
[02:51] <MTecknology> 1cpu with 1core ?
[02:52] <Notch-1> this is not the real problem, i recompile on an old notebook, i just don't want to
[02:52] <MTecknology> After you finish doig make menuconfig, then run this command and you will have your new kernel built and installed  -->  export CONCURRENCY_LEVEL=3; export MAKEFLAGS="HOSTCC=/usr/bin/gcc CCACHE_PREFIX=distcc"; make all modules_install install && update-grub
[02:52] <Notch-1> i don't want to speed up the recompile, i just wish to not have to at all... it's not a matter of time
[02:53] <MTecknology> You can copy the .config from the existing kernel too..
[02:53] <Notch-1> noted, thanks
[02:53] <MTecknology> I'm tryiing ot find the command I used
[02:54] <Notch-1> but i don't know if i will use it, i want the simplest way possible...
[02:54] <MTecknology> that is the simplest
[02:54] <MTecknology> You can just use  "make all modules_install install && update-grub" if you want
[02:55] <Notch-1> anyway my grub can't be reached from my booted system, i'm inside a kexec :D
[02:55] <MTecknology> Here's what I used to get the .config cat debian.master/config/config.common.ubuntu debian.master/config/amd64/config.common.amd64 debian.master/config/amd64/config.flavour.generic > .config
[02:55] <MTecknology> I've been building the kernel from my home directory :P
[02:56] <MTecknology> the git branch is at ~/Downloads/ubuntu-kermic
[02:56] <MTecknology> s/e/a/
[02:56] <Notch-1> :D
[02:56] <Notch-1> i'm not bash :D
[02:56] <MTecknology> I learned how to compile a kernel on Gentoo
[02:57] <MTecknology> You can ommit && update-grub
[02:57] <Notch-1> commit && update-grub to recompile?
[02:59] <MTecknology> This part uses 3 compile processes which is good for 2 cores; it uses gcc to compile, and it sets the compile to use ccache which helps emilinate redundant processor calls -> export CONCURRENCY_LEVEL=3; export MAKEFLAGS="HOSTCC=/usr/bin/gcc CCACHE_PREFIX=distcc";
[03:00] <MTecknology> This part compiles the kernel, compiles the kernel modules, and installs them where they need to go -> make all modules_install install
[03:00] <MTecknology> this part updates grub configs so the newly installed kernel will be used update-grub
[03:00] <MTecknology> this part updates grub configs so the newly installed kernel will be used -> update-grub **
[03:01] <MTecknology> hopefully that all made sense
[03:02] <MTecknology> This can help you too - https://wiki.ubuntu.com/KernelTeam/KernelGitGuide
[03:02] <MTecknology> I'm going to go watch tv w/ my gf - bbl
[03:03] <Notch-1> yes yes, thanks, i understand but i already know that, i messed up my last question, sorry :P
[03:04] <Notch-1> i was thinking that you were saying that on gentoo is different
[03:06] <Notch-1> enjoy, see you
[03:08] <Notch-1> and thanks for the tips, next time i'll try to speed it up, maybe it will be less painful..
[04:09] <MTecknology> Notch-1: gentoo actually lets you pull the kernel sources using the package manager - some things are different - but what I told you is universal across most any distro
[05:48] <MTecknology> now... what is it in the kernel that I don't have that makes the system run cooler
[10:52] <marcriera> hello everybody. does anyone know why karmic koala release candidate is shipped with a vanilla kernel?
[11:32] <marcriera> pgraner: hello, i have a question about kernel versions on 9.10. I was wondering if when the final release comes it will come with the actual 2.6.31 or it will switch to another kernel release. Many thanks.
[11:42] <marcriera> to myself : http://en.wikipedia.org/wiki/Linux_kernel#Versions    . I understand that the even-odd stile is not working any more. so 31 is not vanilla. i guess ubuntu will remain on it for a while. 
[11:55] <pgraner> marcriera: I'm not sure what you mean. 9.10 has 2.6.31.4 plus some backported fixes.
[11:56] <pgraner> marcriera: it was announced back May that 9.10 will ship with 2.6.31
[11:57] <marcriera> pgraner: i'm sorry i bother you. I work with a group of researchers and the like the 2.6.31 improvements, and i was not sure ubuntu will stay with 2.6.31 when it passes from RC to final release. I was still thinking about the even-odd vanilla-stable stile releases. 
[11:59] <marcriera> pgraner: thanks for you clarification. We will migrate to 9.10 , starting tomorrow , and start using the 2.6.31 for developing pourposes. thanks again.
[15:57] <dtchen> oh, oops
[15:57] <dtchen> bah, wrong channel
[16:39] <RainCT> Hi
[16:40] <RainCT> Touchpad and WLAN don't work anymore on Karmic with the new kernel (-14), the previous one (-13) still works. Any idea?
[16:44] <ogasawara> RainCT: can you tell me the specific kernel version where it's failing (cat /proc/version_signature)
[16:44] <ogasawara> RainCT: some rfkill patches went in recently
[16:45] <ogasawara> RainCT: and are you on a Dell?
[16:45] <RainCT> no, ASUS EeePC 1005HA
[16:46] <ogasawara> RainCT: hrm, can you open me a bug using "ubuntu-bug linux"
[16:46] <ogasawara> RainCT: that'll get me all your specific hw info etc
[16:46] <RainCT> no connection :)
[16:46] <ogasawara> RainCT: no wired?
[16:47] <RainCT> awesome, USB mouse doesn't work either o_O
[16:50] <RainCT> ogasawara: connecting it to the router with an Ethernet cable doesn't seem to do anything either
[16:51] <RainCT> (ethernet didn't work on Jaunty, but did with previous Karmic kernels)
[16:51] <ogasawara> RainCT: hrm, what about saving to a USB and then attach to a launchpad bug
[16:51] <ogasawara> RainCT: want to see dmesg, sudo lspci -vnvn, and the /proc/version_signature
[16:52] <RainCT> ok I think that'll work (running ubuntu-bug just said "no such file or directory: /proc/asound/cards" btw)
[16:53] <RainCT> (and someone with another eeepc just confirmed he has the same problem with today's update)
[16:53] <dtchen> you've got some serious resource contention, then
[16:55] <ogasawara> RainCT: if you can, point any others with the same issue to your bug in lp
[16:56] <apw> RainCT, can you also attach a dmesg output from the -13 (clearly marked as from the working one)
[16:56] <ogasawara> RainCT: and the USB mouse regression, is that also between -13 and -14?
[16:57] <RainCT> I believe so, haven't tried it with -13
[16:57] <dtchen> RainCT: err, wait. is this issue reproducible with linux-backports-modules-alsa-2.6.31-14-generic purged?
[16:57] <apw> RainCT, and is it directly connected or via a hub
[16:58] <RainCT> directly. USB sticks aren't showing up as /dev/{s,h}d* either
[16:58] <RainCT> dtchen: trying that now
[16:58]  * apw wonders if udev is still running
[16:59] <RainCT> ps shows 1 upstart-udev-bridge and 3 udevd
[16:59] <apw> on the usb sticks, does anything appear at the end of the dmesg when you shove them in?
[17:00] <RainCT> dtchen: postrm gives "Exec format error"
[17:02] <RainCT> (disregard someone else having the same problem, he asked for a bug number but hasn't tried updating yet.. doing so now)
[17:03] <RainCT> dtchen: actually the files in /var/lib/dpkg/info/linux-backports-mod../* are all empty
[17:04] <RainCT> fsck complained when I rebooted after the update so it may be because of file corruption
[17:05] <dtchen> RainCT: ext4 for /var ?
[17:06] <RainCT> yes
[17:06] <dtchen> RainCT: what version of upstart?
[17:07] <RainCT> dtchen: 0.6.3-9
[17:07] <dtchen> RainCT: regardless, it sounds eerily like the sync() issue that Keybuk mentioned for ext4, although it should have been worked around in that version of upstart that you have installed
[17:08] <dtchen> RainCT: http://pastebin.com/d3d01c4bf has the contents of /var/lib/dpkg/info/linux-backports-modules-alsa-2.6.31-14-generic.postrm
[17:12] <Keybuk> that was only a guess
[17:12] <Keybuk> I took the sync() out ages ago, and only noticed corruption recently
[17:12] <Keybuk> so I put it back on the basis lots of things in the kernel source said THOU SHALT SYNC!
[17:12] <Keybuk> it's entirely possible we have an O M G ext4 bug in there
[17:14] <Keybuk> at some point, we should probably mention it to slangasek
[17:16] <dtchen> i know i've been able to trigger it in 2.6.32-rc1, but uh, that was 2.6.32-rc1
[17:18] <Keybuk> rtg: have you been naughtily backporting patches again? :p
[17:18] <RainCT> OK, reinstalling the kernel fixed everything
[17:18] <ogasawara> RainCT: sweet, so no regressions now?
[17:18] <RainCT> ogasawara: nope :)
[17:18] <rtg> Keybuk, I love being naughty, but I'd like to know what for?
[17:19] <Keybuk> rtg: ext4
[17:19] <rtg> not recently.
[17:19] <rtg> perhaps in stable, lemme check
[17:19] <Keybuk> colin says he's getting reports of grubenv being zero sized too
[17:19] <Keybuk> which would bit the "not written before reboot" pattern too
[17:19] <Keybuk> (and I've seen that!)
[17:20] <RainCT> WLAN is worse than using the latest drivers (even with backports-modules-wireless installed), but that isn't a regression from previous Ubuntu kernels (and it's certainly better than Jaunty, where it didn't work at all)
[17:20] <rtg> Keybuk, "xt4: Don't update superblock write time when filesystem is read-only" is the most recent in the changelog
[17:20] <Keybuk> right, it won't be that one
[17:21] <rtg> thats also the last touch in git
[17:21] <Keybuk> hmm, that's annoying
[17:22] <rtg> git log fs doesn't show anything either. I thought maybe jbd might have been messed with
[18:25] <dtchen> rtg: / apw: thanks very much for the wireless and alsa backports, BTW
[18:26] <rtg> dtchenno problem. did the ALSA stuff actually help?
[18:26] <rtg> dtchen: ^^
[18:27] <dtchen> rtg: some people so far
[18:28] <dtchen> trying to get everyone to test it
[18:28] <dtchen> at least jerone's problem with the dells is progressing
[18:28] <dtchen> alsa-side it's fixed, just need to twiddle the right PA bits now
[18:37] <apw> rtg i thought the alsa in there was alsa-stable, and so pretty close to .31
[18:38] <rtg> apw, its whateveris in alsa-drivers snapshot 1.0.21
[18:38] <rtg> which is what dtchen suggested I use
[18:39] <apw> fair enough
[18:39] <dtchen> apw: pretty far from .31
[18:40] <dtchen> it's much closer to .32
[18:40] <dtchen> so it's 2.6.32 + quirks and fixes from 20091012
[18:41] <dtchen> i.e., no core changes from .32
[18:43] <apw> dtchen, cool
[18:44] <apw> dtchen, is it me or did the last updates trigger some alsa control lossage agian... i had to go enable a bunch of capture things on dell
[18:47] <dtchen> apw: meaning alsa-utils upload?
[18:48] <dtchen> apw: it shouldn't have, but there're too many reports of further regressions
[18:48] <apw> last couple of times i've updates things alsa things have gone haywire, no idea if kernel or userspace much
[18:48] <apw> i do seem to have a bunch more alsa controls than last time i looked
[18:49] <dtchen> apw: in your case, is it mixer settings being muted?
[18:49] <apw> i had a couple of those muted, and a couple of captures without the red CAPTURE L R at the bottom
[18:49] <apw> never seen that CAPTURE thing before ...
[18:51] <dtchen> apw: hmm, is it just capture elements being muted or playback elements as well?
[18:51] <apw> streaching my memory now, likely just capture elements
[18:52] <apw> i think the speaker mute was me
[18:53] <dtchen> if it's just capture elements, that's likely the symptom that jerone described
[18:53] <dtchen> particularly if you've a model affected by the latest quirk changes (HP dv series)
[19:37] <RainCT> dtchen: (ah, installing the alsa backports thing worked here to get the microphone working on the eeepc 1005ha)
[19:37] <dtchen> RainCT: yes, as expected
[19:38] <dtchen> that's part of the massive mic-switching infrastructure that was dumped into 2.6.32
[19:38] <dtchen> hence why lbm is a good idea for newer HDA
[20:02] <rtg> apw, we should go through our list of UBUNTU patches (once again) and figure out which ones should go upstream and/or stable.
[20:03] <apw> yep we should next week?
[20:03] <rtg> seems about right
[20:04] <apw> excellent
[20:04] <rtg> I'll wait until you are bleary eyed Wed night, after a few beers. then we can do it.
[20:04] <apw> heheh
[21:31] <h00k> I'm having terrible kernel panics on my laptop, I was wondering where linux-crashdump actually dumps useful information to?
[21:37] <ogasawara> h00k: the following might help https://wiki.ubuntu.com/KernelTeam/CrashdumpRecipe
[21:38] <h00k> ogasawara: ahha, thank you!
[21:38] <h00k> ogasawara: it must not be able to figure out what is going on because I don't get anything with apport :(
[21:39] <h00k> standby
[21:41] <h00k> lemme play around and see what I can do
[21:44] <h00k> am I assuming that when it freezes and the numlock/capslock light flash that its a kernel panic?
[21:45] <h00k> yeah, forcing the kernel oops is not having my laptop reboot itself.
[21:57] <h00k> Yeah, I'm not having any luck :( I really hope that other people aren't having this problem, I'd like to get as much info to the developers as I can