[03:49] <balaraja> Hi All, I am trying to debug Ubuntu 10.04 (2.6.32) running inside a VM with KGDB using a serial connection. But when I boot through the kgdb vmlinux its not waiting for remote connection. Any help,plz?!?
[03:50] <balaraja> I did add the kgdbwait parameter in grub.cfg.
[03:53] <balaraja> My question is almost similar to this post (http://askubuntu.com/questions/4230/how-to-modify-grub-entry-for-supporting-kgdb-kernel-image). Any help, plz??
[09:24] <diwic> apw, the fix for bug 825709 seems to have made its way into the precise kernel (see 645e9035 ), how come it is not automatically closed?
[09:24] <ubot2`> Launchpad bug 825709 in linux "[Asus 1101HA] Choppy sound due to excessive rewinding on Atom chipsets" [Undecided,Fix committed] https://launchpad.net/bugs/825709
[09:25] <smb> diwic, You suppose apw is around... :)
[09:25] <apw> smb, oh he is, in spirit at least
[09:26] <smb> But its only closed when something in the buglink magic would be correct...
[09:26] <apw> i would guess the change came down as a stable and yours got lost in the process
[09:27] <diwic> apw, I thought you made some fix which made the stuff that comes down as a stable to be closed as well?
[09:27] <apw> oh hmm, but then it does have the BugLink in it
[09:27] <apw>     BugLink: https://bugs.launchpad.net/bugs/825709
[09:27] <ubot2`> Launchpad bug 825709 in linux "[Asus 1101HA] Choppy sound due to excessive rewinding on Atom chipsets" [Undecided,Fix committed]
[09:27] <apw> oh bugger, but leann rebased onto it ... and that takes manual updates ...
[09:27]  * apw will take care of it
[09:29] <diwic> apw, thanks
[09:35] <ohsix> diwic: there are cases where a rewind can never complete due to whatever circumstance, are those the same rewinds ratelimited by the patch?
[09:36] <diwic> ohsix, the patch is about changing the controller driver to report better dma positions
[09:36] <ohsix> ah
[09:37] <ohsix> hadn't got to the bottom yet, i've seen problems on my netbook with the default resampler before, resampling 6 channels from a dvd was too expensive, it would eventually kill itself after failing rewinds and using a lot of cpu for a while
[09:38] <ohsix> i've seen logs from other people with rewinds that don't have any chance of finishing and pulse not killing itself though, it would be nice if pulse could measure that and change the resampler if it happens
[09:40] <ohsix> i'll investigate a bit closer next time i see it :]
[09:43] <ohsix> how you inferred that pulse took 8 seconds to wake up will be useful for a problem i've been having for ages too
[09:43] <ohsix> i hadn't thought to look at it like that
[09:43] <snadge> wow people talking :)
[09:45] <snadge> where were you guys the other day when i was building a custom kernel.. never mind.. i figured it out myself, and it turns out bulldozer just sucks (not news)
[09:45] <snadge> it seems to have higher than average system usage when building source.. approx twice that of a phenom 2 x4
[09:46] <diwic> ohsix, PulseAudio should detect (IMO) when the sample position drifts too much from the expected one (i e system clock) and give a warning, or something like that
[09:46] <snadge> i thought i could be clever and specifically optimise for that architecture, but of course it makes no statistical difference
[09:47] <ohsix> it does already doesn't it? i was just reading them as errors from alsa and presuming the driver reported it, not that there was 5 seconds between the last event :>
[09:47] <snadge> that is -march=bdver1 .. turning off all intel related options.. hyperthreading etc.. turned off all debugging.. compiled with -fomit-frame-pointer... pretty much makes zero difference
[09:47] <ohsix> it's weird people are still using poulsbo stuff
[09:47] <snadge> oh and -Ofast
[09:48] <snadge> dont worry im not a gentoo user.. its okay, it was just to satisfy my own curiosity ;)
[09:49] <ohsix> detecting when a rewind will never finish covers a few classes of problems though ... would be nice to have some sort of message pointing out the resampler, but other things can cause it as well
[09:51] <snadge> also the kernel build documentation doesnt tell you how to update the version string.. it seems the control file or whatever, overrides the version string in the kernel makefile.. what is the "correct" way to change that?
[09:52] <ohsix> the rewind scenario i'm thinking of settles max rewind and max possible rewind down to a number that won't change "soon", leading to idempotenet volume changes, just a running tally from the cached old values and incrementing something that aborts the rewind and warns the user after it's happened 2000 times or so would work ok
[09:53] <snadge> also i had to patch out the test in the makefile for .config and include/config or else it errors out and complains that i should run "make mrproper" .. i cant see reference to that in the documentation :/
[09:53] <ohsix> snadge: typically you don't want to touch EXTRA_VERSION like you would if you were building the kernel from a tarball, since it's part of the package name proper; but the control file does offer you a way to set custom package versions, which can include arbitrary strings
[09:54] <snadge> right i just wanted my kernel to be very obviously different from a standard ubuntu one.. so that it didnt conflict
[09:54] <snadge> eg -snadge
[09:54] <ohsix> also i'm pretty sure apt-build works for the kernel and if you just wanted to build a bulldozer version you could have used it, independent discovery of the uselessness of the thing is always good though
[09:55] <snadge> but its called 3.2.0-9 even though its a 3.2.1 kernel from git
[09:55] <diwic> ohsix, the volume changes are also a stupid rewind case. I mean, in most cases that just translates to hw volume changes, so we shouldn't have to rewind in the first place. But that's another story (and slightly off-topic in #ubuntu-kernel anyway!)
[09:55] <snadge> i was just following https://help.ubuntu.com/community/Kernel/Compile
[09:56] <snadge> so im assuming when 3.2.0-9 is released.. its going to override or conflict with the one i just built ;)
[09:58] <ohsix> snadge: the name resolution policy for package versions is pretty understandable, and documented; so you can pick versions for whatever behaviour you desire, or you could just pin your version; there's really nothing stopping you from doing it however you'd like, many different ways
[09:59] <snadge> i just thought there might be a simple way to do it.. eg "some-script-myversion 3.2.1-snadge"
[10:00] <snadge> or i just do a simple string replace in the control file?
[10:10] <snadge> yay freenode ;)
[10:18]  * diwic thanks apw for updating the ones I forgot to reassign from alsa-driver to linux as well
[10:19] <apw> diwic, this demonstrates the manual nature of my 'fix' :)
[10:19] <apw> though i am fixing it for next time round
[13:44]  * ppisati -> coffe, back in 5mins
[14:15] <tgardner> apw, interesting thread on linux-wireless list: "calling request_firmware() from module init will not work with recent/future udev versions"
[14:16] <apw> tgardner, yea
[14:16] <apw> tgardner, yeah i was copied, came out of the udev stuff i was doing for nbx2
[14:16] <tgardner> apw, it should be backward compatible when  we start backporting LTS kernels again
[14:17] <apw> yeah indeed, as we have more features in udev not fewer
[17:50] <apw> snadge, normally one adds like newpsmouse1 to the end of the version
[17:50] <apw> so that yours falls between the official versions
[17:50] <apw> foo1 for after ~foo1 for before the version you are appending to
[19:25] <cking> yawn
[20:01] <DBO> so I am getting a crash with the nvidia drivers in precise if I dont start my kernel with iommu=no
[20:02] <DBO> is there something I can do to avoid this issue (other than disabling the mmu subsystem)?
[20:13] <DBO> rebuilding the nvidia module with the oeniric kernel works
[20:14] <DBO> without the need to turn off the iommu
[20:14] <DBO> so I guess something in the new kernel is not happy with the nvidia driver