=== yofel_ is now known as yofel
=== ivoks_away is now known as ivoks
=== fddfoo is now known as fdd
=== ivoks is now known as ivoks_away
=== amitk is now known as amitk-afk
=== amitk-afk is now known as amitk
=== ivoks_away is now known as ivoks
[13:15] <AnAnt> Hello, PC speaker does not work in maverick anymore
[14:05] <akgraner> apw - good morning!!  This bugs for you  - Bug #632391
[14:05] <ubot2> Launchpad bug 632391 in linux (Ubuntu) "my computer gets up to 90 degrees Celsius and hangs or powers off (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/632391
[14:07] <akgraner> apw - I have to step away from computer for a couple hours this morning but let me know if there is something else I need to do to help with this  - Thanks a million!!
=== _bjf is now known as bjf
[15:09] <apw> pgraner, 32 or 64 bit for akgraner's machine |
[15:09] <apw> ?
[15:15] <pgraner> apw, lemme look
[15:16] <pgraner> apw, 32bit
=== sconklin is now known as sconklin-afk
=== diwic is now known as diwic_afk
[15:39] <cnd> JFo, hey man, I forgot about the bug triage summit
[15:39] <cnd> I won't be able to help out after all, cause I'm flying on saturday :(
[15:43] <JFo> cnd, no sweat
[15:44] <cnd> JFo, thanks!
[15:46] <JFo> :)
[15:46] <apw> jfo remind me of the itme
[15:49] <JFo> apw, the summit time?
[15:49] <bjf> ##
[15:49] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:49] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[15:49] <bjf> ##
[15:50] <JFo> 10AM to 2PM my time which I believe translates to 1400 to 1800 UTC
[15:53] <pgraner> JFo, can you help Ivanka file a bug?
[15:53] <bjf> JFo: hehe
[15:53] <JFo> pgraner, sure
[15:54] <pgraner> JFo, see your email, she tried ubuntu-bug linux but its not working
[15:54] <JFo> k
[15:56] <pgraner> JFo, thx
[15:57] <apw> akgraner, i've started a bisect between the good/bad kernels, first test is this one, if you could test and report back: http://people.canonical.com/~apw/akgraner-lucid/
=== sconklin-afk is now known as sconklin
=== yofel_ is now known as yofel
[16:59] <ogasawara> Sarvatt: vanhoof mentioned to me you might have some i915 patches to add new device id's?
[16:59] <Sarvatt> heyo! yeah, https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/632488
[16:59] <ubot2> Launchpad bug 632488 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "i915/intel-agp fail to load on newer intel sandybridge platforms. (affects: 1) (heat: 6)" [Medium,In progress]
[17:00] <vanhoof> Sarvatt: do you think we'll continue to see updates like this, ie in 6 weeks we'll have newer rev boards w/ the same problems?
[17:00] <Sarvatt> thats one of the reasons I was asking about id's the other day
[17:00] <Sarvatt> I have no way of knowing, it looks like they finally pushed the final id's there in that most recent patch though
[17:02] <Sarvatt> I'll email yingying and ask
[17:03] <ogasawara> Sarvatt:  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4fefe435626758b14e6c05d2a5f8d71a997c0ad6 looks to already be upstream and should be simple enough to cherry-pick
[17:04] <Sarvatt> yeah, I just noticed the rest of the devices were added a few hours ago, we've got a bug about the D0 stepping not working already (that 0116 pci id)
[17:04] <ogasawara> Sarvatt: although that's not the same device id yingying emailed about this morning.
[17:04] <ogasawara> ah
[17:04] <ogasawara> Sarvatt: so I assume we need patches for both
[17:06] <Sarvatt> those desktop/server chips and the rest of the mobile sandybridge's won't work if we don't, the id's in there currently are all preproduction devices from what I can see
[17:07] <ogasawara> Sarvatt: any idea if the patch for 0116 has gone upstream?  no worries if you don't.
[17:08] <Sarvatt> 0116 is upstream, yeah
[17:08] <ogasawara> cool
[17:08] <Sarvatt> ya just linked it :)
[17:08] <Sarvatt> it's not in 2.6.35.x though
[17:09] <ogasawara> Sarvatt: the link above was 0126
[17:12] <Sarvatt> oh, I'm sorry about that, got them mixed up!
[17:12] <bjf> ##
[17:12] <bjf> ## Ubuntu Kernel Team Meeting - in 50 minutes - #ubuntu-meeting
[17:12] <bjf> ##
[17:15] <Sarvatt> so 0116 was added in the newest patch which adds a bunch of other devices and isn't upstream yet, the patch adding just 0116 that Yingying sent is reliant on having the 0126 D0 commit already added
[17:16] <ogasawara> Sarvatt: ok.  I also just saw https://patchwork.kernel.org/patch/159971/ .
[17:18] <ogasawara> Sarvatt: do you think we'll need the rest of the ids which are added in the newest patch that's not yet upstream?
[17:19] <ogasawara> Sarvatt: I can email yingying to get clarification too
[17:23] <Sarvatt> ogasawara: just sent yingying a mail asking for clarification, I do think we'll need them though because 0102 and 0106 seem to just be preproduction stepping chips that are already supersceded
[17:25] <ogasawara> Sarvatt: thanks, lets wait and see what her response is.  Either way, the patches should be easy enough to apply to Maverick.
[17:57] <bjf> ##
[17:57] <bjf> ## Ubuntu Kernel Team Meeting - in 5 minutes - #ubuntu-meeting
[17:57] <bjf> ##
[18:24] <jolan> so basically, the intel graphics guys are busy with other projects and won't be fixing i855 soon.  however, there are proven community patches that fix i855.  i sent them to kernel-team@ a couple days ago.  they're solid for me and others so i feel reverting the blacklist and committing the patches would be the best thing to do.
[18:24] <apw> jolan what was the subject of that email thread
[18:25] <jolan> "revisiting the blacklisting of i855"
[18:25] <tgardner> one of the problems is that every time we mess with i855 we cause regressions. we're running out of time to get it right for the Maverick release.
[18:26] <apw> jolan, that first patch is _mamoth_
[18:27] <tgardner> mammoth even
[18:27] <jolan> well i come from OpenBSD and we use that same patch there.  I also tested it on Lucid before I upgraded it to Maverick.  It's 100% solid for me and it only affects i855.
[18:27] <apw> jolan, is that link to the original patch?
[18:28] <apw> jolan, and what did upstream say to this patch
[18:29] <jolan> http://glasen-hardt.de/wp-content/uploads/2010/05/fix-i8xx-gtt-cache-coherency-v9-2.6.35.1.patch is stefan's port of the patch to 2.6.35.x, i believe the original patch is in the freedesktop bug somewhere
[18:29] <jolan> lemme check the exact words, i don't want to paraphrase
[18:30] <apw> Sarvatt, you about ?  seee above some discussion re i8xx patches whihc are being proposed
[18:31] <apw> RAOF, ^^ you also .... for tommorrow :)
[18:31] <jolan> here is what the developer of the patch said:
[18:31] <jolan> http://bugs.freedesktop.org/show_bug.cgi?id=27187#c233
[18:32] <Sarvatt> apw: I'm not sure what RAOF wants to do with that, I'd prefer leaving KMS enabled and just switching the autoconfig logic in the server to use fbdev on the affected chips since we could maintain that
[18:32] <ubot2> Freedesktop bug 27187 in Driver/intel "[855GM] gtt chipset flush is not cache coherent" [Normal,New]
[18:32] <Sarvatt> fbdev+KMS is working as well as UMS+vesa with the bonus it works at native resolution
[18:34] <Sarvatt> oh sorry, thought you were referencing the disable KMS on i8xx patches
[18:35] <apw> Sarvatt, well we are indirectly, jolan is requesting a patch to help with i8xx generally
[18:35] <apw> it might be orthoganal and complementatry to you position, ie something people could opt-in to .... but the patch is huge
[18:37] <apw> ogasawara, fyi i am working on a ti-omap4 issue, am i ok to update the branch 
[18:38] <tgardner> apw, I uploaded just a bit ago so you should make sure you're sync'd
[18:38] <apw> tgardner, how long ago
[18:38] <tgardner> 2+ hours?
[18:39] <jolan> i guess the other option would be to try and steal RHEL5's approach which is a 2.12 xorg video-intel backport to UMS if you're that scared of the patch
[18:39] <jolan> and only have it match the i8xx chipsets
[18:40] <apw> tgardner, heh i though you knew i was working on a packageing issue on that one ... doh
[18:40] <tgardner> hmm, thought it was a -meta packagin problem
[18:40] <tgardner> and I thought it was already corrected
[18:41] <apw> tgardner, ahh i can see how you'd have gotten that mixed i guess ... this is an additional issue in the package itself
[18:41] <apw> ahh well is done now
[18:41] <tgardner> apw, I guess we can just upload again....
[18:41] <apw> tgardner, yep
[18:41] <apw> will have to retest of course
[18:49] <ogasawara> apw: yep, feel free to update the branch.
[19:06]  * tgardner lunches
[19:06] <Sarvatt> jolan: just spoke with the X maintainer in debian where they brought in the legacy driver to squeeze and the results have been horrible with it over there, UMS is not even working right on 855. that kernel patch is way too invasive IMO and will be a maintenance nightmare with all of the sandybridge stuff. RAOF really has a better handle on the 8xx situation though if you can catch him. fbdev+KMS by default really seems like the right way to
[19:06] <Sarvatt>  go to me (and is roughly equivalent to ickle's shadowfb branch) and people can opt in to intel with an xorg.conf
=== bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - September-14 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
[19:14] <jolan> Sarvatt: the legacy driver meaning 2.9.1?
[19:16] <ogasawara> apw: around still?  have a question for you regarding uploading the 2.6.35 orig.tar.gz.  I can send you email instead if it's getting late for you.
[19:17] <apw> ogasawara, am still here ... just had yet another i915 hang on maverick
[19:18] <ogasawara> yuck
[19:18] <ogasawara> apw: Lemme give you the quick background of what I thought was correct...
[19:18] <ogasawara> apw: I downloaded http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.35.tar.gz
[19:19] <ogasawara> apw: Re-named it linux_2.6.35.orig.tar.gz and added the "-sa" flags to dpkg-buildpackage when I built our 2.6.35-16.22 kernel.
[19:19] <apw> that sounds about right to me
[19:19] <ogasawara> apw: I thought this was successful as the 2.6.35-16.22 url shows it was included with the upload https://edge.launchpad.net/ubuntu/+source/linux/2.6.35-16.22
[19:19] <ogasawara> apw: However, I'm not seeing it at http://archive.ubuntu.com/ubuntu/pool/main/l/linux/
[19:20] <ogasawara> apw: I thought uploading the orig.tar.gz was a one time deal that needed to happen so I've not used the "-sa" flags with dpkg-buildpackage when building our kernels since then.  But it seems something is not quite right as the linux_2.6.35.orig.tar.gz is not showing up in the archive.  Any ideas?
[19:20] <apw> ogasawara, doesn't look like the -20.29 upload was done with the orig ?
[19:20] <apw> as it has no .diff
[19:21] <ogasawara> apw: it wasn't, so I assume I need to use the -sa flags from here on out?
[19:21] <apw> you need to do the first one with -sa
[19:21] <apw> then you always need the .orig in .. when you make the package
[19:21] <apw> so that it makes a .diff method
[19:21] <ogasawara> ah
[19:22] <ogasawara> I'd deleted it thinking I no longer needed it
[19:22] <ogasawara> ok, that explains it.  thanks.
[19:23] <apw> heh, at least its easy to obtain :)
=== ghostcube_ is now known as ghostcube
[19:35] <pgraner> bjf, you email had the wrong date in the subject :-P
[19:35] <bjf> pgraner: yup, just resent
[19:37] <pgraner> bjf, coolio
=== jsalisbury is now known as jsalisbury_afk
=== fddfoo is now known as fdd
=== bjf is now known as bjf[lunch]
=== bjf[lunch] is now known as bjf
[20:18]  * jjohansen -> lunch
=== jsalisbury_afk is now known as jsalisbury
[20:48] <pgraner> tgardner, https://bugs.launchpad.net/ubuntu/+bug/631871
[20:48] <ubot2> Launchpad bug 631871 in ubuntu "default I/O scheduler should be change from CFQ to deadline (affects: 1) (heat: 18)" [Undecided,Won't fix]
[20:48] <tgardner> pgraner, crack
[20:49] <tgardner> he can run the server kernel, or change his scheduler on the fly
[20:50] <pgraner> tgardner, I know that but this is a classic case of people not knowing. We should invest some time into some "why we default to use XXXX" pages
[20:53] <tgardner> pgraner, we pulled the defaults out of our butts because of how they were advertised for certain workloads, but they don't always work for everyone. I'm just happy if my music doesn't stutter whilst compiling.
[20:53] <elmo> hahah, what?
[20:54] <elmo> (sorry, I'm laughing at the bug, not you guys)
[20:54] <tgardner> elmo, yeah, its a dogpile
[20:54] <pgraner> tgardner, yea you so easy to please
[20:54] <achiang> is there any way to get the source of older kernels for a given binary package name? say linux-image-2.6.32-22-generic, i'm interested in the source for 2.6.32-22.33 (and not .36)...
[20:54] <tgardner> achiang, all uplaods are tagged in the git repo
[20:54] <pgraner> elmo, we got 5 or so about that each release *sigh*
[20:56] <achiang> tgardner: good hint. but let's say someone is trying to do something weird, like building fglrx. can they just grab the git repo, check out the v2.6.32-22.33 tag and drop that into /usr/src ?
[20:57] <tgardner> achiang, no, they'd have to package it (which runs some prep steps), then build the header packages, blah, blah, blah...
[20:58] <achiang> tgardner: that's what i thought. i don't suppose we keep old source packages around, do we?
[20:58] <tgardner> achiang, they should be able to 'fakeroot debian/rules clean binary-headers binary-indep' and then install the .deb's
=== ivoks is now known as ivoks_away
[20:59] <tgardner> achiang, the source packages get reaped after awhile once they are superseded
[20:59] <achiang> tgardner: ok, that makes sense (both the deb building and the reaping). thanks.
[21:00] <tgardner> achiang, anytime I can provide vague unhelpful answers, just let me know.
[21:00] <achiang> tgardner: sure, now you offer, *after* we've figured out our USB wifi issue. ;)
[21:01] <tgardner> achiang, you'll notice that I _didn't_ throw in my $0.02 on that subject.
[21:01] <tgardner> achiang, incidentally, I'll be at the wireless mini-summit Thu-Fri. Any topics you want me to bring up?
[21:02]  * achiang thinks
[21:03] <tgardner> any topics that are politically relevant, that is.
[21:03] <tgardner> I can't be bugging them about realtek. 
[21:03] <achiang> tgardner: nope, realtek isn't even a concern for us anymore
[21:04] <achiang> tgardner: i can't think of any upstream topics, really. i have some opinions for what we should do inside of canonical though
[21:04] <achiang> tgardner: maybe thank the atheros guys for writing relatively clean drivers. :)
[21:04] <tgardner> achiang, I'll personally buy Luis a beer.
[21:05] <tgardner> and then figure out how to get pgraner to pay for it :)
[21:07] <achiang> ha! in that case, buy him a beer for me too! ;)
[21:45]  * tgardner --> eod
=== sconklin is now known as sconklin-gone
[23:13] <ogasawara> bjf: https://wiki.ubuntu.com/KernelTeam/KernelUpdates should this be the recommended wiki I point people to regarding our SRU policy correct?  or does a newer one exist under our new wiki hierarchy?
[23:14] <bjf> ogasawara: for now yes, i'm more than a little confused with the state of our wiki pages