[00:00]  * bjf off to a meeting
=== bjf is now known as bjf-afk
[00:37] <dtchen> ogasawara: hi, did you have a laptop that experienced bug 279478?
[00:37] <ubot3> Malone bug 279478 in linux "alsa sound fades out when headphones are plugged in until you inaudible" [Low,Triaged] https://launchpad.net/bugs/279478
[00:38] <ogasawara> dtchen: not that I know of, but let me test really quick
[00:39] <dtchen> ogasawara: seems to hit Dell Dimension E52x
[00:39] <dtchen> anything with SSID 0x102801?d
[00:41] <ogasawara> dtchen: I've got a 1420 here, 1028:01f3
[00:42] <dtchen> excellent, same codec
[00:42] <dtchen> it defaults to the model=dell-bios quirk, however
[00:42] <dtchen> so I don't think you'll have the same symptoms
[00:42] <ogasawara> dtchen: sound remains after I insert headphones
[00:43] <dtchen> ogasawara: do you have a separate Headphone profile when you right-click the speaker icon in the lower GNOME panel and choose Sound Preferences > Hardware ?
[00:45] <dtchen> regardless, you have a completely different quirk, so this bug wouldn't be relevant 
[00:45] <ogasawara> dtchen: I don't see it
[00:45] <dtchen> mmkay
[00:46] <dtchen> how about: echo autospawn = no|tee -a ~/.pulse/client.conf && killall pulseaudio && sudo alsa force-unload && sudo modprobe snd-hda-intel model=3stack && rm ~/.pulse/client.conf
[00:47] <dtchen> jack sense is such a mess right now :(
[00:48]  * MsMaco gives dtchen cookies
[00:48] <ogasawara> ogasawara@emiko:~$ echo autospawn = no|tee -a ~/.pulse/client.conf && killall pulseaudio && sudo alsa force-unload && sudo modprobe snd-hda-intel model=3stack && rm ~/.pulse/client.conf
[00:48] <ogasawara> autospawn = no
[00:48] <ogasawara> [sudo] password for ogasawara: 
[00:48] <ogasawara> lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/ogasawara/.gvfs
[00:48] <ogasawara>       Output information may be incomplete.
[00:48] <ogasawara> lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/ogasawara/.gvfs
[00:48] <ogasawara>       Output information may be incomplete.
[00:48] <ogasawara> Unloading ALSA sound driver modules: snd-hda-codec-idt snd-hda-intel snd-hda-codec snd-hwdep snd-pcm-oss snd-mixer-oss snd-pcm snd-seq-dummy snd-seq-oss snd-seq-midi snd-rawmidi snd-seq-midi-event snd-seq snd-timer snd-seq-device snd-page-alloc (failed: modules still loaded: snd-hda-codec-idt snd-hda-codec snd-hwdep snd-pcm snd-timer snd-page-alloc).
[00:49] <dtchen> barf 
[00:49] <dtchen> sudo fuser -v /dev/dsp* /dev/snd/* /dev/seq*
[00:49] <ogasawara> ogasawara@emiko:~$ sudo fuser -v /dev/dsp* /dev/snd/* /dev/seq*
[00:49] <ogasawara> Cannot stat /dev/dsp*: No such file or directory
[00:49] <ogasawara> Cannot stat /dev/dsp*: No such file or directory
[00:49] <ogasawara> Cannot stat /dev/seq*: No such file or directory
[00:49] <ogasawara> Cannot stat /dev/seq*: No such file or directory
[00:50] <dtchen> ok, and sudo alsa force-unload
[00:51] <ogasawara> ogasawara@emiko:~$ sudo alsa force-unload
[00:51] <ogasawara> lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/ogasawara/.gvfs
[00:51] <ogasawara>       Output information may be incomplete.
[00:51] <ogasawara> lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/ogasawara/.gvfs
[00:51] <ogasawara>       Output information may be incomplete.
[00:51] <ogasawara> Unloading ALSA sound driver modules: snd-hda-codec-idt snd-hda-codec snd-hwdep snd-pcm snd-timer snd-page-alloc.
[00:52] <dtchen> excellent
[00:52] <dtchen> sudo modprobe snd-hda-intel model=3stack && rm ~/.pulse/client.conf
[00:53] <ogasawara> ogasawara@emiko:~$ sudo modprobe snd-hda-intel model=3stack && rm ~/.pulse/client.conf
[00:53] <ogasawara> ogasawara@emiko:~$ 
[00:53] <dtchen> so let's try: speaker-test -c2 -l4 -Dplug:front:0
[00:53] <dtchen> try inserting headphones
[00:53] <dtchen> do the internal speakers mute properly?
[00:54] <ogasawara> yup
[00:54] <dtchen> and unplugging unmutes the int speakers, correct?
[00:54] <ogasawara> yup
[00:54] <dtchen> sigh
[00:54] <dtchen> would you please add your /proc/asound/card0/codec* to the bug?
[00:55] <ogasawara> will do
[00:55] <dtchen> thanks!
[01:03] <ogasawara> dtchen: posted my info, let me know if you need any other testing from my end.
[01:04] <dtchen> I just need a big hammer
[01:04] <dtchen> thanks, regardless
[01:21] <stavrob> hey guys, why is ubuntu configured with 100hz timers for the standard desktop kernel?
[01:26] <ikepanhc> stavrob: you are using amd64 arch?
[01:26] <stavrob> ikepanhc: yes
[01:27] <ikepanhc> stavrob: 250hz timer in i386 and 100hz timer in amd64
[01:27] <stavrob> im wondering why
[01:28] <ikepanhc> let me check out
[01:28] <stavrob> 100hz timers really do introduce actual noticeable latency problems, its visible as little stutters and jerks, occasionally music skipping etc
[01:28] <stavrob> dunno about 250hz but i compiled the ubuntu kernel again with 1000hz and it's streets better
[01:33] <ikepanhc> Some discuss about set CONFIG_HZ to 1000 for a more "real-time" environment, I will check if there is discuss about why set to 100MHz for amd64 :-) 
[01:36] <stavrob> personally i think 1000hz timers for desktop kernels for both arch's would be lovely, but if we can at least get the timer resolution up on amd64 it'd be a nice start
[01:37] <stavrob> it really is a noticeable difference, compile your kernel with 100hz and then with 1000hz and just use each one for a bit. i know desktop interactivity is quite a woolly thing but trust me it's very noticeable
[01:37] <ikepanhc> stavrob: ya, I think so, but maybe there is some story behind this (digging for story)
[01:37] <stavrob> ikepanhc: ok cool
[05:37] <phenompanda> hi, ericm 
[05:38] <phenompanda> i see sa1100 defconfig have CONFIG_ARCH_DISCONTIGMEM_ENABLE =y
[05:39] <phenompanda> ericm, is there any special purpose for add this feature in ARM arch?
[06:19] <ericm> phenompanda, no - we are moving to sparsemem
[10:22] <stavrob> ikepanhc: did you find anything in the end
[10:23] <ikepanhc> stavrob: not yet, is there anyone know why CONFIG_HZ=100 in arch amd64?
[10:24] <apw> ikepanhc, cause the higher HZ is the more expensive tick handing is
[10:25] <apw> and where you have any sort of high res timer a high HZ is just useless noise
[10:25] <apw> so on amd64 where highres timeres are always present there is no point in maintaining a high HZ
[10:25] <ikepanhc> apw: you mean cost cpu time on content switch?
[10:25] <apw> it contributes many %'s of SPU usage
[10:25] <apw> i mean the cost of taking the interrupts to handle it and update the jiffies
[10:26] <apw> which we don't use in the main even
[10:26] <Appiah> 100 isnt that typical server usage?
[10:26] <apw> therefore the recomendation was 250 for i386 where highres timers are not present
[10:26] <apw> and 100 for amd64 where you have highres timers which form the bases for everything
[10:27] <apw> Appiah, my understanding is that when you have high res timers the HZ value is no longer relevant for scheduling
[10:27] <apw> and most times and timing uses the tick + high-res offset for accuracy
[10:27] <apw> so it matters little how often tick changes within the resolution of the high-res timer
[10:28] <apw> ie ... updating it less often has no downside, and much upside in overall cost
[10:28] <Appiah> oki
[10:29] <Appiah> I just remeber from putting my kernel togheter myself on gentoo where you could choose between 100 , 512 or 1000 where it said 1000 recommended higher for desktop/workstations and lower for servers
[10:29] <apw> which kernel version tho?
[10:30] <Appiah> last time I used gentoo was about little less then a year ago
[10:30] <apw> moving HZ to 1000 from 250 was tested recently as the pulse peopel were shouting for it.  a full 8% cost in CPU alone
[12:21] <stavrob> apw: according to con, high res timers are mostly broken in the kernel atm so are disabled, they're apparently still limited by tick resolution for scheduling timeout decisions
[12:24] <apw> i seem to have timers enabled in my kernel ... the recomendation for the HZ change came down from mainline developers
[12:28] <stavrob> my bad, it seems highres timers are actually enabled, just not for scheduling decisions
[12:28] <stavrob> which unfortunately has a noticeable impact on responsiveness
[14:33] <ghostcube> simple question why is there an grub2 now
[14:36] <ghostcube> i hate it 
[14:36] <ghostcube> i just hate it
[14:36] <ghostcube> :|
[14:37] <_ruben> then dont use it?
[14:37] <ghostcube> on new karmic install its defaulted so i wanted to test
[14:37] <ghostcube> but it pure bah
[14:37] <_ruben> and supposedly grub2 has more to offer than grub(1) .. then again, i havent played with it myself, yet
[14:38] <ghostcube> _ruben: try it 
[14:39] <ghostcube> to configure it it drives you nuts :D
[14:39] <_ruben> i only have 1 karmic box, and it was upgraded step by step from uhm .. hardy i think
[14:39] <apw> ghostcube, whats is so bad about it
[14:40] <apw> it seems almost identicle user interface wise
=== hggdh_ is now known as hggdh
[14:47] <smb> The config file format is different but not necessarily worse. You now mostly do changes in /etc/default/grub and do update-grub. The only thing that is a bit annoying is the persistence it tries to go for the master boot record by default
[15:02] <smb> jjohansen, Is that virtio thingy from bug 458521 going to require a kernel patch too or is that more or less done with the kvm package update. (I believe they included dkms modules, but I am not sure)
[15:02] <ubot3> Malone bug 458521 in qemu "kvm crash when using virtio for network, hardy guest" [Medium,In progress] https://launchpad.net/bugs/458521
[15:06] <smb> Keybuk, around?
[15:06] <ghostcube> apw: the config is pure horror
[15:06] <ghostcube> old grub had one file and all worked
[15:06] <ghostcube> new grub2 is script and file based daemon thingy
[15:06] <ghostcube> i dont like this 
[15:07] <apw> ghostcube, it has a slightly different syntax.  and yes it uses cat to make a file out of it
[15:07] <apw> its split config, but its not that different
[15:07] <smb> ghostcube, err do you generally need more than grub.cfg?
[15:07] <ghostcube> smb: iam not only talking about me :)
[15:07] <ghostcube> i have oure linux install
[15:07] <ghostcube> p
[15:07] <Keybuk> smb: briefly ;)
[15:07] <Keybuk> what's up?
[15:07] <ghostcube> no need for any features of grub2 
[15:08] <ghostcube> but i think its not the best solution to make linux boot stage easier or ?
[15:08] <smb> Keybuk, Just wanted to make sure we do the right thing on the next Karmic upload. I got the modified trace patch in that took out the uselib part, but the ureadahead from the ubuntu-boot ppa does not like this much
[15:09] <Keybuk> yeah, I have another one to upload
[15:10] <Keybuk> there you go, uploaded ;)
[15:10] <smb> Keybuk, ah, so you won't yell (at me) when I upload that kernel without uselib. :) Good
[15:11] <Keybuk> no
[15:11] <Keybuk> it'd only break tracing anyway
[15:11] <Keybuk> go right ahead
[15:11]  * smb goes off to test the new ureadahead and then upload the kernel
[15:13] <smb> hrm... actually... with the speed of the ppa builders atm, I should probably just upload... :-P
[15:28] <apw> smb what else can you do
=== bjf-afk is now known as bjf
=== MsMaco is now known as maco
[16:25] <jjohansen> smb: it looks like it probably requires a kernel patch but I hadn't gotten to it yet
[16:25] <smb> jjohansen, Ok, ta. Just wanted to make sure I not forget about it
[16:26] <jjohansen> smb: right
[16:34] <bjf> dtchen, are we marking all the grub audio bugs as duplicates of 470265?
=== sconklin-afk is now known as sconklin
=== maco__ is now known as maco
=== zul_ is now known as zul
[21:43] <HorsePunchKid> I have a somewhat obscure problem with a non-ubuntu kernel. The problem does not occur when I use the ubuntu kernel from the minimal installation CD. Is this a place where I might find some help discovering what has fixed the problem in the ubuntu sources?
[22:05] <dtchen> bjf: yes, please
=== bjf is now known as bjf-afk