[01:49] <TheMuso> pgraner: Have you managed to try the patch I attached to bug 331589 yet?
[01:49] <ubot3> Malone bug 331589 in alsa-utils "system beep in jaunty is the most annoying sound known to man" [Medium,Fix released] https://launchpad.net/bugs/331589
[03:32] <Yasumoto> hey guys, I'm trying to build a vanilla kernel (from the git repo) using make-kpkg, and seem to be running into issues running make http://paste.ubuntu.com/129064 
[03:33] <Yasumoto> Should I be applying ubuntu-specific patches for this? I'm not sure if this is a typically supported method of compiling
[03:39] <dtchen> Yasumoto: see CONCURRENCY_LEVEL
[03:39] <dtchen> (in the appropriate man page version at http://manpages.ubuntu.com/cgi-bin/search.py?cx=003883529982892832976%3A5zl6o8w6f0s&cof=FORID%3A9&ie=UTF-8&q=make-kpkg&titles=Title)
[03:40] <Yasumoto> dtchen: will do, thank
[03:40] <Yasumoto> *thanks
[03:42] <Yasumoto> oh wow, I set it to N by not reading https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
[03:42] <Yasumoto> dtchen: thank you
[03:42] <Yasumoto> I think I assumed N=no or something
[04:55] <foxbuntu> Hi all. I am working on a few dev issues surrounding MythTV on the Mythbuntu project and one is HDMI audio on my ALC1200, I am curious if someone can enlighten me why alsa 1.0.19 can't be included for 9.04 release? (asking nicely please dont take offense, I really dont know the reasons)
[04:56] <dtchen> TheMuso: looks like http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commitdiff;h=ed3da3d9a0ef13c6fe1414ec73c9c1be12747b62 is worth looking over
[04:56] <TheMuso> dtchen: thanks looking
[04:57] <dtchen> foxbuntu: 1) are you positive the enablement patch(es) can't be backported? 2) Alsa-kernel generally requires a corresponding bump in userland [Alsa-lib].
[04:57] <TheMuso> dtchen: hrm thats a big diff. I think we will have to put a good argument to get it in.
[04:58] <dtchen> TheMuso: yeah, i'm not positive it's a winner yet, but i'll test it locally this week. it's not as vital given we've disabled glitch-free in PA by default.
[04:58] <foxbuntu> dtchen, I have not looked at the patches being back-ported yet, I was just curious from the kernel standpoint why it isn't going to be done
[04:58] <TheMuso> dtchen: right
[04:59] <dtchen> (anyhoo, Z -> work)
[04:59] <foxbuntu> dtchen, the 1.0.18 in A5 + patches does not work with my ALC1200 however 1.0.19 does, thats why I was asking
[05:11] <JanC> foxbuntu: we're in version freeze, so new versions must bring clear advantages and (almost) no disadvantages (that's why)
[05:11] <foxbuntu> JanC, well, thats a pretty clear reason right?
[05:11] <foxbuntu> :)
[05:12] <foxbuntu> so back-ports it is
[05:12] <foxbuntu> thanks guys
[05:12] <JanC> foxbuntu: extra hardware works = advantage, but can you prove no disadvantage (like breaking other hardware) ?  ツ
[05:28] <foxbuntu> JanC, at this point, no I need the extra hardware to test on, and/or spend some time looking at the patches
[09:05] <apw> foxbuntu, generally because if we can keep the kernel the same as upstream we gain advantages when fixes come along, and from the testing that was and is being done on that kernel as a unit, plus there are kernel/userspace dependancies to keep in sync which are not necesasrily possible
[09:06] <apw> the more delta we carry the more work it is for us rather than the general kernel community to carry
[11:45] <riham> hi all , anybody here with experience in Kernel AIO .. I have been trying to work it out using libaio but I dont get enhancement in performance 
[12:43] <riham> hi all , anybody here with experience in Kernel AIO .. I have been trying to work it out using libaio but I dont get enhancement in performance
[17:34] <cj> hey all.  bryce recommended that I report suspend/resume issues here.  anyone want to have a crack at it?  I'm dist-upgrading to jaunty now, but it didn't work in intrepid.
[17:37] <cj> http://rafb.net/p/2Q6UwD92.html
[17:44] <Keybuk> mjg59: I notice a 10s boot speed difference between the "ondemand" and "performance" scaling governors
[17:44] <Keybuk> mjg59: is this to be expected?
[17:47] <cj> Keybuk: which way?  performance 10s less?
[17:47] <Keybuk> in the obvious way
[17:49] <anubhav>  Keybuk:what are the available freq's for the cpu?
[17:50] <Keybuk> anubhav: 1600000, 1333000, 1067000, 800000
[17:52] <anubhav> imo most of the boot time is due to IO i can't see a connection,but maybe bootchart can be helpful
[17:53] <Keybuk> yes, thankyou
[17:53] <Keybuk> I'm past all that and now at the "err, Matthew" stage of debugging
[17:53] <Keybuk> :p
[17:54] <johanbr> For some reason, the ondemand governor is really slow to trigger for me in recent kernels. Even when compiling, it goes back and forth between highest and lowest frequencies.
[17:55] <johanbr> Maybe that's what's happening to you too?
[17:56] <anubhav> in that case the stats would also help
[17:57] <Keybuk> what stats would you like?
[17:57] <anubhav> cpufreq/stats
[17:57] <Keybuk> do you know much about the cpu frequency scaling part of the kernel?
[17:59] <Keybuk> ie. can you fix the problem?
[17:59] <anubhav> wrote a driver once
[18:30] <anubhav> johanbr:maybe you can tweak the "up_threshold" parameter within "/sys/devices/system/cpu/cpu0/cpufreq/ondemand"
[18:38] <johanbr> anubhav: sure, I'll try that, thanks
[18:38] <johanbr> initial stats: http://pastebin.ca/1357538
[18:38] <johanbr> stats an hour or so later, just after compiling a program: http://pastebin.ca/1357539
[18:40] <anubhav> whats the current "up_threshold"
[18:41] <johanbr> 95
[18:41] <anubhav> ohh
[18:41] <anubhav> no wonder
[18:41] <johanbr> that's not good?
[18:41] <anubhav> try 30
[18:42] <johanbr> I'll give that a try. Thanks again. :)
[18:49] <mjg59> Keybuk: No, not in the slightest
[18:50] <mjg59> Keybuk: For certain workloads you'll see reduced io throughput with ondemand, but not significant
[19:48] <Omegamoon> anyone here with experience with the sharp zaurus?
[19:49] <Omegamoon> I'm trying to get the 2.6.28 kernel working for some time now on spitz
[19:49] <Omegamoon> I finally got the device to suspend when pressing the on/off key
[19:50] <Omegamoon> but it won't resume after doing a suspend, no matter what I do
[19:50] <Omegamoon> I have to do a hard reset to get the device back to life
[19:51] <Omegamoon> any clues?
[19:56] <anubhav> Omegamoon: can you get a console on the device
[19:57] <Omegamoon> anubhav: yes, no problem
[19:57] <Omegamoon> 99% works just fine, only suspend/resume has problem(s)
[19:58] <anubhav>  Omegamoon: are you using some distro?
[19:58] <Omegamoon> ubuntu jaunty
[19:59] <anubhav> so you can check the kernel logs and get some hints
[20:01] <Omegamoon> I'll check again... one moment
[20:10] <Omegamoon> anubhav: last line is "apm-power: Requesting system suspend"
[20:17] <anubhav> Omegamoon: whats the output of " cat /sys/power/state"
[20:19] <Omegamoon> anubhav: mem
[20:20] <anubhav> on the device do you have a serial console?
[20:20] <Omegamoon> yes I do
[20:22] <anubhav> are you sure that the device suspends successfully ?
[20:24] <Omegamoon> ehm, how can I check, it turns off
[20:24] <anubhav> some devices have blinking LEDs 
[20:25] <Omegamoon> the zaurus has leds, but they aren't used for that kind of things
[20:25] <anubhav> also on the serial console you can check the output of "echo  mem > /sys/power/state "
[20:26] <anubhav> do you get some messages on the console after issuiing that command?
[20:29] <Omegamoon> no, unfortunately not
[20:30] <anubhav> does it go to sleep after that command?
[20:30] <Omegamoon> yes, it does
[20:31] <anubhav> unfortunately its like permanent sleep :)
[20:31] <Omegamoon> but after that it's dead, no resume :-(
[20:31] <Omegamoon> verrrry sleepy, like me actually :-)
[20:32]  * Omegamoon is resetting the zaurus again
[20:33] <anubhav> can you try "echo 7 > /proc/sys/kernel/printk" before  "echo  mem > /sys/power/state "
[20:39] <Omegamoon> rebooting, 1 moment
[20:44] <Omegamoon> anubhav: zaurus is dead again, have to reset, reboot and check the kernel log
[21:00] <anubhav> Omegamoon:Chk this http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-02/msg09570.html
[21:01] <Omegamoon> anubhav: the 'echo 7...' doesn't show up anything
[21:02]  * Omegamoon is checking the link
[21:05] <Omegamoon> anubhav: I saw that one earlier. It has a follow-up too (http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-02/msg09934.html)
[21:06] <anubhav> Omegamoon: so it seems that with newer kernel suspend got broken
[21:11] <Omegamoon> anubhav: yeah, there was a huge clean-up
[21:12] <anubhav> Omegamoon: after suspend does it wake up if you insert the charger?
[21:13] <Omegamoon> anubhav: believe me, back-porting is not a good plan
[21:14] <anubhav> Omegamoon: suspend/wakeup stuff is difficult to debug.
[21:15] <Omegamoon> anubhav: it doesn't wake up when inserting the charger
[21:16] <anubhav> Omegamoon: i think you should get in touch with Pavel and find out if he is looking  into this issue.
[21:19] <Omegamoon> anubhav: I'll do that
[21:19] <Omegamoon> anubhav: thanks for your help, I have to go now
[21:20] <anubhav> Omegamoon: sure :)
[22:28] <bdmurray> rtg: http://qa.ubuntu.com/reports/bug-fixing/canonical-kernel-team-jaunty-fixes-report.html
[22:52] <lool> Does someone know whether the lpia kernel config was changed similarly to the i386/amd64 ones for cpufreq modules?
[22:52] <lool> (I'd like to drop powernowd from the mid seed)
[23:03] <lool> The same changes were done, great