* bjf off to a meeting | 00:00 | |
=== bjf is now known as bjf-afk | ||
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:37 |
ogasawara | dtchen: not that I know of, but let me test really quick | 00:38 |
dtchen | ogasawara: seems to hit Dell Dimension E52x | 00:39 |
dtchen | anything with SSID 0x102801?d | 00:39 |
ogasawara | dtchen: I've got a 1420 here, 1028:01f3 | 00:41 |
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:42 |
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:43 |
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:45 |
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:46 |
dtchen | jack sense is such a mess right now :( | 00:47 |
* 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:48 |
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:49 |
dtchen | ok, and sudo alsa force-unload | 00:50 |
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:51 |
dtchen | excellent | 00:52 |
dtchen | sudo modprobe snd-hda-intel model=3stack && rm ~/.pulse/client.conf | 00:52 |
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:53 |
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:54 |
ogasawara | will do | 00:55 |
dtchen | thanks! | 00:55 |
ogasawara | dtchen: posted my info, let me know if you need any other testing from my end. | 01:03 |
dtchen | I just need a big hammer | 01:04 |
dtchen | thanks, regardless | 01:04 |
stavrob | hey guys, why is ubuntu configured with 100hz timers for the standard desktop kernel? | 01:21 |
ikepanhc | stavrob: you are using amd64 arch? | 01:26 |
stavrob | ikepanhc: yes | 01:26 |
ikepanhc | stavrob: 250hz timer in i386 and 100hz timer in amd64 | 01:27 |
stavrob | im wondering why | 01:27 |
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:28 |
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:33 |
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:36 |
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 | 01:37 |
phenompanda | hi, ericm | 05:37 |
phenompanda | i see sa1100 defconfig have CONFIG_ARCH_DISCONTIGMEM_ENABLE =y | 05:38 |
phenompanda | ericm, is there any special purpose for add this feature in ARM arch? | 05:39 |
ericm | phenompanda, no - we are moving to sparsemem | 06:19 |
stavrob | ikepanhc: did you find anything in the end | 10:22 |
ikepanhc | stavrob: not yet, is there anyone know why CONFIG_HZ=100 in arch amd64? | 10:23 |
apw | ikepanhc, cause the higher HZ is the more expensive tick handing is | 10:24 |
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:25 |
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:26 |
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:27 |
apw | ie ... updating it less often has no downside, and much upside in overall cost | 10:28 |
Appiah | oki | 10:28 |
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:29 |
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 | 10:30 |
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:21 |
apw | i seem to have timers enabled in my kernel ... the recomendation for the HZ change came down from mainline developers | 12:24 |
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 | 12:28 |
ghostcube | simple question why is there an grub2 now | 14:33 |
ghostcube | i hate it | 14:36 |
ghostcube | i just hate it | 14:36 |
ghostcube | :| | 14:36 |
_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:37 |
ghostcube | _ruben: try it | 14:38 |
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:39 |
apw | it seems almost identicle user interface wise | 14:40 |
=== hggdh_ is now known as hggdh | ||
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 | 14:47 |
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:02 |
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:06 |
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:07 |
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:08 |
Keybuk | yeah, I have another one to upload | 15:09 |
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:10 |
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:11 | |
smb | hrm... actually... with the speed of the ppa builders atm, I should probably just upload... :-P | 15:13 |
apw | smb what else can you do | 15:28 |
=== bjf-afk is now known as bjf | ||
=== MsMaco is now known as maco | ||
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:25 |
jjohansen | smb: right | 16:26 |
bjf | dtchen, are we marking all the grub audio bugs as duplicates of 470265? | 16:34 |
=== sconklin-afk is now known as sconklin | ||
=== maco__ is now known as maco | ||
=== zul_ is now known as zul | ||
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? | 21:43 |
dtchen | bjf: yes, please | 22:05 |
=== bjf is now known as bjf-afk |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!