[03:17] <cwillu> dtchen, interested in hearing about 100%cpu pulseaudio bugs in snd-intel-hda on karmic?
[03:18] <dtchen> sure
[03:18] <dtchen> it'll be somewhat more useful if you have a current bug filed with https://wiki.ubuntu.com/PulseAudio/Log attached
[03:18] <cwillu> does ubuntu-bug supply that?
[03:19] <dtchen> everything but the stuff referenced in the URL
[03:19] <cwillu> okay
[03:19] <dtchen> of course, a description of what you were doing to trigger it would be useful as well
[03:20] <dtchen> OTOH, if you're talking about something libsdl-based, don't even bother filing a bug.
[03:20] <cwillu> oh
[03:20] <cwillu> sdl is a known issue?
[03:20] <dtchen> sdl is a known issue. It's resolved in libsdl svn trunk.
[03:21] <cwillu> upstream's sdl trunk I take it?
[03:21] <dtchen> yes
[03:21] <dtchen> I'll roll some debs in the ubuntu-audio-dev PPA sometime this weekend
[03:22] <dtchen> you essentially need to lift src/audio/{alsa,pulse} from svn trunk
[03:23] <cwillu> dtchen, a tarball from oct27 is probably recent enough?, or should I do a full checkout?
[03:24] <TheMuso> dtchen: Interesting. I think we will need sed patches into lucid early.
[03:24] <dtchen> cwillu: oct27 will suffice
[03:26]  * cwillu ./configure's
[03:29] <dtchen> TheMuso: sed or sdl?
[03:30] <dtchen> (or sid? I'm a bit confused)
[03:30] <cwillu> dtchen, or said
[03:30] <cwillu> "I think we will need said patches"
[03:32] <dtchen> ah, yes
[03:33] <dtchen> well, with any luck, I won't be chained to my $work desk this weekend
[03:34] <TheMuso> dtchen: SDL
[03:34] <dtchen> TheMuso: ok, right
[03:35] <cwillu> once of those rare occurrences where almost all the possible completions rendered into the same meaning :p
[03:37] <panda|phenom> ericm-Zzzz, hi, still awake :) ? 
[03:37] <ericm> panda|phenom, I'm awake :)
[03:37] <panda|phenom> ericm, morning, i have find a strange issue, which lead me suspect timer is not accurate on my board
[03:38] <panda|phenom> ericm, is there any quick and easy to check whether kernel have time shifting?
[03:38] <ericm> panda|phenom, which clock source are you using?
[03:38] <ericm> check your arch/arm/mach-xxx/time.c
[03:39] <ericm> I don't know any tool to check time drift - some ntp tool may help
[03:44] <panda|phenom> ericm, em, i see, i will check with LTP for timer test case
[03:46] <ericm> the most inaccurate clock source is normally the onchip PLL generated signals, which cannot simply be 10ms per jiffy, check that - or if you need absolute accuracy, use RTC or NTP (provided you have network connection)
[03:49] <panda|phenom> ericm, well, the streaming server running in my system use event mechnism to send out packets
[03:50] <panda|phenom> ericm, calculate the next packet expected send out time and then set to a timer chain
[03:51] <ericm> panda|phenom, OK I see
[03:51] <panda|phenom> ericm, those timer are all around 40~60 ms, so if there is a tiny time shift
[03:51] <panda|phenom> ericm, then client will complain about those delayed packets and ask server to re-post 
[03:52] <panda|phenom> ericm, which may cause my system very chokeniess ...
[03:53] <ericm> panda|phenom, I know - any source of your time.c to check?
[09:36] <dholbach> hi guys
[09:36] <dholbach> can anybody try to shed some light on https://bugs.launchpad.net/ubuntu/+bug/464411 ?
[09:36] <ubot3`> Malone bug 464411 in linux "After upgrade to Karmic, root partition (sda1) is missing /dev/sda1 is missing from /dev/disk/by-uuid" [Undecided,New] 
[09:47] <smb> dholbach, From what I read in the bug, not really much more than it sounds like a userspace problem
[09:47] <smb> as the partition shows up in proc/partitions and can be mounted manually
[09:47] <dholbach> smb: do you think you could pinpoint it to some package?
[09:47] <smb> Just getting the uuid fails
[09:48] <smb> whatever package blkid is in
[09:48] <smb> i believe that is udev but lemme check
[09:49] <smb> dholbach, ah, util-linux
[09:49] <dholbach> great
[09:50]  * dholbach updated the bug report
[09:50] <apw> dholbach, yeah it seems that udev saw the partition and made the device as they can mount it manually ... so i think its userspace after udev which has failed.  from the output in the bug i think blkid is bust
[09:51] <dholbach> what can they do to debug / fix it?
[09:51] <smb> dholbach, apw has added some comments
[09:52] <smb> basically check with dumpe2fs, to see what that returns
[09:52] <dholbach> thanks a bunch smb and apw
[09:52] <dholbach> it's a guy I know from the Berlin team
[09:52] <apw> dholbach, np.  who owns util-linux
[09:52] <dholbach> apw: somebody who touched it last :/
[09:53] <dholbach> or Keybuk maybe, I dunno?
[09:53] <apw> yeah keybuk is fingered
[09:57] <apw> dholbach, might be worth having it have a task on both that an linux till its confirmed either way, so we can continue to track it
[09:58] <dholbach> sure
[10:14] <MsMaco> smb: quite a bit of blkid fail it sounds like
[10:14] <MsMaco> was someone in #ubuntu-bugs earlier saying debian stable's blkid recognizes zfs & ufs, but karmic does not
[10:14] <MsMaco> said arch's worked right too. arch & karmic are both using 2.16
[10:16] <smb> MsMaco, Generally it should not be a complete fail, as at least mine does find my sda1. On the other hand I have ext4 here.
[10:17] <smb> Hopefully the e2fsdump shows what is in those headers to compare
[10:17] <MsMaco> oh im not saying it always fails :P just "wow, ive heard about 2 bugs in it in less than 12 hours!"
[10:18] <smb> If it is not more, then I am glad. :) Nevertheless quite shocking when you reboot and get told your partition went away
[10:34] <^arky^> Hi, Anyone seen these ALSA underrun and wake errors http://pastebin.ubuntu.com/304936/
[11:17] <apw> dholbach, ok thats pretty much confirmed as a bug in blkid, it seems there is a patch upstream for it now ... so we likely need to get scott on the case
[11:18] <dholbach> apw: nice
[11:18] <dholbach> that'll make the world a better place
[11:55] <bigon> hi, is it "normal" that there is no iwlagn driver on the alternate cd?
[14:58] <Keybuk> apw, cking_: http://people.canonical.com/~scott/new-open-sort.png
[14:59] <cking_> Keybuk, nice peak on the first second or so
[14:59] <apw> Keybuk, woh ... what sort order you using for open?
[15:00] <Keybuk> apw: an obvious one
[15:00] <cking_> how much improvement is that?
[15:00] <Keybuk> so obvious it never occurred to us
[15:00] <Keybuk> it's still "slow", but not as slow
[15:00] <Keybuk> takes about a second off the dead bit
[15:00] <apw> heh ... so tell telll
[15:00] <cking_> ..we want to know :-)
[15:02] <Keybuk> sorted the paths by e2fs inode group, and ino_t
[15:02] <apw> doh ... pretty obvious
[15:03] <apw> Keybuk, nice one
[15:03] <apw> Keybuk, why is there two sets?  dirs and then files ?
[15:04] <Keybuk> inode preloads, then opens
[15:04] <Keybuk> not sure what the third ghost set is
[15:04] <ghostcube> -_-
[15:05] <cking_> 3rd set @ ~5 secs/
[15:05] <cking_> ?
[15:07] <Keybuk> right
[15:07] <cking_> w/o further analysis it's hard to say from a graph
[15:09] <Keybuk> yeah
[18:39] <ricklerre1> Hey guys, I just fresh installed Karmic desktop. On Jaunty I had to install and then boot into the server kernel in order to run vmware player with a 64-bit guest.  that vm currently won't run in the karmic linux-generic kernel.  I installed the linux-server kernel, but it won't boot into it.  any suggestions on how to boot into the kernel OR how to make vmware player run? 
[20:50] <ricklerre> Hey all, I tried to install linux-server kernel on a desktop install of karmic, but it didn't boot into that kernel and the option doesn't exist appear on the grub menu, is there soemthing further that I need to do?
[21:06] <MsMaco> ricklerre: run "sudo update-grub"? we're not sure why grub's not updating its list of kernels properly
[21:13] <ricklerre> I gave that a try
[21:14] <ricklerre> I also ran "os probe" and then "update-grub", both non-starters
[21:15] <ricklerre> is there a manual method?
[21:27] <joaopinto> ricklerre, /etc/grub.d/40_custom
[21:27] <joaopinto> ricklerre, but you should file a bug report
[21:27] <ricklerre> ok, will do
[21:28] <ricklerre> any particular project?
[21:33] <joaopinto> ricklerre, ubuntu-bug grub-common
[21:33] <joaopinto> erm wait
[21:33] <joaopinto> I guess the detection is a task from os-prober
[21:33] <joaopinto> for
[21:34] <ricklerre> so `ubuntu-bug os-prober` ?
[21:35] <joaopinto> yup
[21:35] <joaopinto> ricklerre, well, to be honest, is not clear for me
[21:36] <joaopinto> there is a /etc/grub.d/10_linux which does check on /boot
[21:36] <joaopinto> and that one belongs to the grub-common package