[12:48] <TheMuso> BenC: Has crimsun been mentioning anything? :p I stated that I would consider helping with alsa, but I was thinking of the userspace packages, i.e alsa-lib and alsa-utils. Unfortunately as I am not a strong coder, I don't feel I can help with the kernel side of things.
[12:49] <BenC> TheMuso: ok, some how you got listed as the Alsa person under the KernelTeam wiki :)
[12:50] <TheMuso> Oh right.
[09:19] <kraut> moin
[09:48] <smash> hello everyone
[09:48] <smash> can anyone help me to know about cfs 
[09:54] <smash> hello any one please come for help
[09:54] <mjg59> smash: This isn't a support channel, I'm afraid
[09:55] <smash> mjg59: really sorry... but can u help me. just i want to know will cfs will be the linux scheduler in future.
[09:56] <smash> is there any chance to change it in the near future
[09:56] <mjg59> In 2.6.23
[09:56] <mjg59> Which will not be in gutsy
[09:57] <smash> okey... but is there any chance to change it in the near future. As a developer how you rate the new scheduler
[09:58] <mjg59> When we move to 2.6.23 or 2.6.24 for gutsy+1, we'll have it
[09:59] <smash> Is there any hope to get a documentation about the newone.
[09:59] <mjg59> From us? I doubt it. It's not especially interesting.
[10:00] <smash> i tried in the web. but i am not getting any documention which explain the operation of the newone.
[10:04] <abogani> smash: -rt flavour have laready CFS
[10:04] <abogani> abogani: In gutsy (not Feisty)
[10:05] <smash> abogani: ya... but can i help me. from where will we get some documentation about this scheduler and its operation
[10:07] <mjg59> smash: It's likely that the only documentation for now will be the source code
[10:10] <abogani> smash: Matthew is right! :-(
[10:26] <smash> abogani: when we can expect the 2.6.23
[10:28] <mjg59> smash: This really isn't the right place to ask - this channel is for discussion of Ubuntu kernel development, not general kernel issues
[10:30] <smash> mjg59 after all everythings is kernel. and my question is also a general one then what is the problem
[01:36] <Kmos> bug 112148
[01:36] <TheMuso> Kmos: There is no ubotu in here.
[01:36] <Kmos> :(
[03:54] <infinity> zul: Around?
[03:54] <zul_> infinity: kind of
[03:54] <infinity> You should merge your launchpad accounts, so it stops being angry and confused.
[03:54] <infinity> zulcss and zulcss-ubuntu
[03:55] <zul_> uh I didnt know I had two :)
[03:55] <infinity> https://launchpad.net/~zulcss-ubuntu/+packages  vs  https://launchpad.net/~zulcss/+packages
[03:55] <infinity> Just merge zulcss-ubuntu into zulcss, and life should be good.
[03:55] <zul_> okie dokie
[03:57] <infinity> Not that I can find the merge link anymore...
[03:58] <zul_> infinity: asking in #launchpad
[04:12] <infinity> zul_: https://launchpad.net/people/+requestmerge
[04:12] <infinity> zul_: (If you never found it)
[04:14] <infinity> zul_: Hah.  Ignore the email claiming it wants to merge zulcss-ubuntu with adconrad.  I didn't realise clicking that button would do... That. :P
[04:24] <zul_> *grumble* *grumble* ill take care of it when Im not at work
[04:31] <zul_> yay redhat support...bleah
[05:17] <BenC> mjg59: -> #ubuntu-meeting if you are interested
[06:30] <IntuitiveNipple> Any ACPI team available for a brain-storm/review on a suspend S3/immediate-resume issue I'm working on?
[06:31] <mrec> Hi guys, I have a driver which supports around 50 devices; The driver consists of a module which acts as a kernelspace<->userspace wrapper. The actual algorithms and firmware code is implemented in userspace
[06:32] <mrec> it's about a TV/DVB-T usb driver
[06:32] <mrec> it doesn't require any change at the existing kernel sources, it just adds code and the possibility of userspace drivers.
[06:33] <mrec> In userspace a daemon will load the requested drivers automatically
[06:33] <mrec> that daemon is started by udev so that the user doesn't have to bother about it
[06:33] <mrec> I wonder if there's a way to integrate that in ubuntu?
[06:34] <mrec> the kernelspace<->userspace bridge is expected to join linux 2.6.24
[06:48] <mjg59> BenC: In a real-world meeting, I'm afraid
[06:49] <BenC> mjg59: no problem, was just a heads up
[06:50] <lamont`> BenC: did you see my hppa fixes for .26?
[06:51] <lamont`> (note that this is not a request for an immediate .26...)
[06:51] <BenC> lamont: yeah, did you email kernel-team? If not I suggest that, and Cc kyle so he can pull
[06:51] <lamont`> yes
[06:51] <BenC> ok
[06:51] <lamont`> ah, didn't cc kyle though
[06:51] <lamont`> which email should I use for him?
[06:51] <kylem> kyle@ubuntu.com, obviously
[06:52] <lamont`> hehg
[06:52] <lamont`> good... because I can't speel mcmartin :-)
[06:52] <kylem> actually, i imagine kyle.mcmartin@canonical.com works too, not sure about @ubuntu.com
[06:52] <lamont`> kylem: does it matter if I bcc you?  on a 3-day old message?
[06:52] <kylem> if you sent it to kernel-team, i already have it.
[06:53] <lamont`> if you do dup-elimination, then you won't have 2 copies of it. :-)
[06:53] <lamont`> sorry dude
[06:53] <kylem> lol.
[06:53] <lamont`> that change may not merge prettily...
[06:54] <lamont`> as far as abi files go, hppa64 is the one that changes.  and I did the rename.  I suck
[06:55] <lamont`> with luck, I'll have another commit before tribe 4 that deals with offsets.h, and we'll be able to have a working gdb with the next kernel upload.
[06:55] <lamont`> meanwhile, off to the office.
[06:59] <kylem> no. you won't.
[06:59] <kylem> archive is frozen for tribe4...
[10:17] <lamont> dear fglrx.ko.  Please stop breaking suspend on my laptop.  kthxbye
[10:38] <bdmurray> amitk_: How likely are we to see more dupes of 129226?
[10:40] <amitk_> bdmurray: very hard to say. Why?
[10:43] <bdmurray> I was pondering how to keep an eye out or notifying the bugsquad about it.
[10:45] <amitk_> bdmurray: you are looking for a way to track all kernel regressions or specific suspend/resume issues?
[10:46] <bdmurray> amitk_: I meant how many people will be affected by that particular bug.
[10:48] <amitk_> all reports on that particular bug had dual core machines IIRC. Do we know how many users use dual core?
[10:49] <bdmurray> Nope, but that is helpful.  Is saying "that bug will only affect dual core users who suspend and resume with kernel 2.6.22-9" correct?
[10:52] <IntuitiveNipple> amitk_: do you have a few minutes to review a suspend S3/immediate resume issue I'm working on?
[10:53] <amitk_> bdmurray: That is accurate given the current information we have
[10:53] <amitk_> IntuitiveNipple: possibly. Is it related to Gutsy?
[10:54] <IntuitiveNipple> 2.6.20 on up
[10:55] <amitk_> IntuitiveNipple: what is the bug id?
[10:55] <bdmurray> amitk_: okay, thanks.  The "Call Trace:" portion is the important part to look for when marking duplicates correct?
[10:55] <IntuitiveNipple> #128315
[10:57] <amitk_> bdmurray: Yes. Call trace can be used to look for patterns
[10:59] <amitk_> IntuitiveNipple: There is nothing in that report regarding the HW in use. https://wiki.ubuntu.com/KernelTeamBugPolicies should help us gather all the required info before we can start analysis
[11:00] <IntuitiveNipple> I just need to pick your brains for any reasons you can think of for an immediate resume after a successful suspend
[11:02] <IntuitiveNipple> I'm away of the policies... I recently joined ACPI team, I've got 2 identical units where one will resume correctly and the other will resume immediately. it appeared to be a PM_TIMER issue but it seems the ACPI_FURE_USAGE functions to read the wakeup event isn't quite correct, so it might be caused by something else
[11:02] <IntuitiveNipple> s/away/aware/
[11:02] <IntuitiveNipple> Wondering if you've seem similar situations and if so, what the causes were
[11:03] <amitk_> IntuitiveNipple: I haven't seen it before. But are you sure that the system even went into S3? Perhaps it aborted half-way through?
[11:04] <amitk_> usb drivers are a problem many times
[11:04] <IntuitiveNipple> Yeah, positive. I've been building custom-debug kernels with ACPI_FUTURE_USAGE enabled and my own code in hwsleep()
[11:05] <IntuitiveNipple> what is strange here is - two identical Vaio notebooks, identical clean installs of Ubuntu on clean disks, even tried swapping the hard disks between them. Left battery out for 12 hours, etc, but one will always resume immediately.
[11:06] <IntuitiveNipple> I thought it was a PM_TIMER event until I tested it on the 2nd unit and found it worked... so now I'm looking for other reasons to investigate
[11:07] <IntuitiveNipple> I have debug code leading right up to the final CPU cache flush, and kicking in immediately it does "Back to C!" and not been able to find a thing different... I've run diffs of the kern.log of the two of them and they are identical, despite one having resumed immediately
[11:08] <amitk_> IntuitiveNipple: Bios settings?
[11:08] <IntuitiveNipple> i've diffed the hardware setup, and the dmesg logs, and both units are identical
[11:08] <IntuitiveNipple> BIOS settings identical too, same BIOS versions, (not alot to set in the BIOS anyhow)
[11:08] <IntuitiveNipple> same hardware IDs and revisions
[11:08] <IntuitiveNipple> no problems with any of the drivers during suspend/resume and it can be repeated endlessly and won't get unstable
[11:09] <IntuitiveNipple> the actual suspend/resume is perfect - aside from this one that just doesn't want to stay in S3 :)
[11:10] <IntuitiveNipple> I thought checking which WAKE event flag was set on resume would give me the culprit, but both report the same thing:
[11:10] <IntuitiveNipple> Back to C!											   (
[11:10] <IntuitiveNipple> Enabling PM Timer										   (
[11:10] <IntuitiveNipple> Resume status=0											   (
[11:10] <IntuitiveNipple> Resume ACPI state=3										   (
[11:10] <IntuitiveNipple> Event 0=0x1											   (
[11:10] <IntuitiveNipple> Event 1=0x0											   (
[11:10] <IntuitiveNipple> Event 2=0x0											   (
[11:10] <IntuitiveNipple> Event 3=0x0											   (
[11:10] <IntuitiveNipple> agpgart-intel 0000:00:00.0: EARLY resume	
[11:10] <IntuitiveNipple> (thats my debug code reporting)
[11:11] <IntuitiveNipple> Always says Event 0, which equates to PM_TIMER - no both - even when the PWRBTN is used... which is why I think there's still some work to do on the functions covered by ACPI_FUTURE_USAGE
[11:11] <IntuitiveNipple> s/no both/on both/
[11:12] <IntuitiveNipple> but the upshot is I can't reliably trust the wake-event reporting in order to diagnose it!
[11:13] <amitk_> This one perhaps? http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg06777.html
[11:15] <IntuitiveNipple> Unfortunately not, I looked at Mattia's issue in the early stages when I thought it was a driver issue and knew that Firewire is an issue.
[11:16] <IntuitiveNipple> Mattia's issue was that it got 'stuck' during the suspend operations. In the case I'm dealing with the notebook suspends correctly
[11:17] <IntuitiveNipple> I've tracked right up to the line prior to the register-write that puts it to sleep
[11:19] <amitk_> IntuitiveNipple: I can't help you at this point then. You seem to have done all the right things. Please fill in the details in the bug so that others who are facing a similar problem might see it
[11:19] <IntuitiveNipple> I did test disabling *all* wake events, and then it did correctly suspend... of course I couldn't wake it up, had to remove battery to reset, but it proved it is something to do with wake-up events
[11:19] <IntuitiveNipple> ok... thanks... I was kind of hoping someone else had seen this kind of weirdness before :)
[11:20] <Nafallo> eep
[11:20] <Nafallo> apache2: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
[11:20] <Nafallo> how to get rid of that? :-)
[11:23] <Nafallo> wait...
[11:24] <Nafallo> I'm in -kernel, right? :-P
[11:24] <Nafallo> damnit! :-)
[11:24] <Nafallo> -EWRONGWIN