[00:00] <eruditehermit> bjf, laptop with intel sandybridge GPU and radeon discrete GPU
[00:00] <eruditehermit> bjf, airlied is in #radeon
[00:01] <bjf> bryceh, ^^ does this request seem reasonable to you ?
[00:01] <bjf> eruditehermit, do you have a make and model for that ? I can see if we have one in the company
[00:02] <eruditehermit> sony viao S 2011 just released
[00:02] <eruditehermit> VPCSB
[00:03] <bjf> eruditehermit, what are the symptoms right now without this enabled ?
[00:03] <bjf> eruditehermit, nevermind, read the bug report :-)
[00:04] <eruditehermit> right
[00:04] <eruditehermit> I have to blacklist radeon manually
[00:04] <eruditehermit> for it to work normally with just the sandybridge GPU
[00:04] <eruditehermit> but for a new user who doesn't know how to blacklist modules its not fun
[00:10] <bryceh> bjf, multi-gpu setups seem to be pretty boned at the moment, so if that config change helps, I'm +1 on it
[00:11] <bjf> bryceh, cool, i almost have a kernel for him to test
[00:11] <bjf> bryceh, will add the results to the bug
[00:11] <bryceh> bjf, typical problem seems to be you have intel and radeon|nvidia, you plug monitor into latter card, and kernel comes up with both i915 and some other driver, and i915 starts throwing up
[00:12] <bryceh> dunno if that corresponds to eruditehermit's issue but that's one I'm seeing quite a bit of
[00:13] <eruditehermit> bryceh, bjf: <airlied> eruditehermit: well I'm forcing it on upstream and in stable
 fedora has had it on for years
[00:13] <eruditehermit>  and RHEL
 I'll send the patch to dri-devel
[00:14] <eruditehermit>  so they can see it before I push it
[00:14] <bryceh> heh, a "we'll make linux work only on redhat" patch, fun
[00:15] <bjf> eruditehermit, http://people.canonical.com/~bradf/lp768645/
[00:16] <bryceh> eruditehermit, would you mind posting a dmesg from one of the failure modes you've seen?  I'd like to try to connect this to other bugs I've seen reported.  If I can, that may help lend additional weight to getting the SRU approved.
[00:17] <eruditehermit> bryceh, sure It'll take a few mins to reboot and collect info
[00:17] <eruditehermit> bjf, thanks I'm downloading and installing
[00:19] <eruditehermit> brb
[00:41] <eruditehermit> hey guys
[00:41] <bjf> eruditehermit, well ?
[00:41] <eruditehermit> I still have problems with my setup
[00:41] <eruditehermit> I am debugging them with airlied
[00:41] <eruditehermit> but I still think that kernel config option might help others
[00:42] <eruditehermit> bryceh, here is my dmesg http://pastebin.com/AjkiQ9WC
[00:42] <eruditehermit> in any case airlied will make that option the default in stable and upstream from now
[00:42] <bjf> eruditehermit, can you attach that to the bug?
[00:42] <eruditehermit> bjf, sure
[00:42] <bjf> eruditehermit, did you confirm that i got the config option turned on ?
[00:43] <eruditehermit> bjf, yes
[00:43] <eruditehermit> i'll send my kconfig to airlied to see if there is anything else
[00:46] <bryceh> eruditehermit, sweet thanks; that OOPS definitely looks familiar...
[00:48] <bjf> eruditehermit, i'll be around for a bit longer if you need another kernel turned
[00:50] <eruditehermit> bjf, talking to airlied about it. He says that it seems like it is trying to init radeon before the card is powered up.
[01:29] <bryceh> bjf, fwiw what I've gathered is that getting multi-gpu setups to "work" will require a number of different changes and a lot of testing
[01:30] <bjf> bryceh, too bad, was hoping we could fix a few with a minor change
[01:31] <bjf> bryceh, sounds like natty will have plenty of sru business
[01:31] <jjohansen> yeah
[01:45] <bryceh> bjf, yeah
[01:54] <eruditehermit> bjf, would you be willing to patch a kernel module and build it for me?
[01:54] <bjf> eruditehermit, you have the patches ?
[01:54] <eruditehermit> http://fpaste.org/Z8pu/
[01:54] <eruditehermit> patch for radeon module
[01:55] <bjf> eruditehermit, just the one line ?
[01:55] <eruditehermit> looks like it
[01:55] <eruditehermit> supposedly it will check for GPU power on before it inits the card
[01:57] <bjf> eruditehermit, building
[02:09] <eruditehermit> bjf, thank you so much
[02:09] <bjf> eruditehermit, that doesn't compile 
[02:09] <bjf> eruditehermit, error: ‘handle’ undeclared (first use in this function)
[02:09] <eruditehermit> hrm
[02:10] <eruditehermit> http://fpaste.org/28SP/
[02:11] <eruditehermit> bjf, new patch
[02:12] <bjf> eruditehermit, building
[02:12] <eruditehermit> bjf, apparently on multi GPU setups there is a power switch for the card that doesn't exist on single GPU machines. This patch turns the GPU on. If bryceh has seen this a lot this might be why
[02:12] <eruditehermit> apparently linux doesn't do multi GPU setups well
[02:13] <bjf> eruditehermit, seems to have compiled, still building
[02:18] <eruditehermit> bjf, cool thanks =)
[02:19] <bjf> eruditehermit, new kernels are there, same directory, you want the "b02" ones
[02:20] <eruditehermit> bjf, thanks =)
[02:21] <eruditehermit> bjf, this is what I have http://www.sonystyle.com/webapp/wcs/stores/servlet/ProductDisplay?catalogId=10551&storeId=10151&langId=-1&productId=8198552921666318656
[02:23] <bjf> eruditehermit, nice looking
[02:24] <eruditehermit> I wanted something light and powerful
[02:24] <eruditehermit> 3.8lbs
[02:24] <eruditehermit> not many people making lightweight laptops for some reason
[02:25] <bjf> i've got a lenovo thinkpad x301 that i really like
[02:25] <eruditehermit> lenovo mousepads and keyboards annoy me
[02:25] <eruditehermit> apple has the best touchpad
[02:25] <eruditehermit> I was going to get a macbook pro
[02:26] <eruditehermit> but its slightly heavier
[02:26] <bjf> i really like the keyboard, except where they put the escape key
[02:26] <eruditehermit> the fn key
[02:26] <eruditehermit> annoys me
[02:26] <eruditehermit> its to the left of control
[02:26] <bjf> you can't get that sony with an ssd?
[02:27] <eruditehermit> yeah you can
[02:27] <eruditehermit> it just costs more
[02:27] <eruditehermit> it also has a sheet battery for $99 extra
[02:27] <eruditehermit> sheet extended battery
[02:27] <eruditehermit> that clips on
[02:27] <eruditehermit> screen viewing angle sucks though
[02:28] <eruditehermit> but then I think a lot of laptop screens suck
[02:28] <eruditehermit> it doesn't reflect as much as the macbook but it isn't as bright
[02:29] <eruditehermit> I have a macbook in the house too
[02:29] <eruditehermit> ok
[02:29] <eruditehermit> rebooting to test
[02:29] <eruditehermit> brb
[02:47] <bjf> eruditehermit, what's the word ?
[02:47] <eruditehermit> bjf, still having problems =(
[02:48] <bjf> eruditehermit, i'm kind of done for today, will be checking back periodically though
[02:49] <eruditehermit> bjf, ok thanks
[02:49] <eruditehermit> bjf, will you be around tomorrow?
[02:49] <bjf> eruditehermit, i'm west coast US, yes, will be around all day tomorrow
[02:49] <eruditehermit> ah me too
[02:49] <eruditehermit> thank you so much for all your help
[02:49] <bjf> ericm|ubuntu, np
[17:04] <bjf> ogasawara, there is no ports branch in natty-meta, does that get added post release or are there no ports now ?
[17:05] <ogasawara> bjf: hrm, dunno.  would have to take a look.
[17:14] <ogasawara> bjf: so in the past, luke would hand off the ports trees to us at release.  But I want to recall that with the Natty cycle we took back maintainership.  powerpc is the only one left.
[17:15] <ogasawara> bjf: I'll need to check with apw what the plan is
[17:15] <bjf> ogasawara, but it would seem that we've not been doing powerpc during the dev cycle, is that normal ?
[17:15] <ogasawara> bjf: it's been building, just no meta
[17:15] <bjf> ah
[17:16] <bjf> ogasawara, can anyone install it without a meta ?
[17:16] <ogasawara> bjf: sure, you can grab the deb
[17:16] <bjf> ogasawara, wonder if anyone has been testing it
[17:17] <ogasawara> bjf: I'm unsure of our userbase for powerpc and I suspect it gets little to no testing in the dev cycle
[17:17] <komputes> JFo: ping
[17:17] <bjf> ogasawara, a cynical person would wonder then why we bother :-)
[17:17] <ogasawara> bjf: we only found out around Beta1 or Beta2 that it completely failed to boot
[17:19] <ogasawara> bjf: yep, so it looks like we pulled it back into the master branch, so it's handled by linux-meta
[17:20] <ogasawara> bjf: so no ports branch needed
[17:20] <bjf> ogasawara, cool, that's nice
[17:37] <JFo> komputes, hi, sorry, was grabbing food. :)
[17:47] <jj-afk> running errands
[17:54] <ogasawara> bjf, sconklin: I forget, for the stable patch sets do I still need 2 Ack's or can I just push to master-next
[17:55] <bjf> ogasawara, just push
[17:55] <sconklin> ogasawara: what he said
[17:55] <ogasawara> sweet, thanks
[17:56] <bjf> ogasawara, which tree? lucid ?
[17:56] <ogasawara> bjf: natty
[17:56] <ogasawara> bjf: 2.6.38.4
[17:56] <bjf> ogasawara, ah
[17:57] <bjf> ogasawara, steve and i are making plans on doing getting natty into the next SRU cadence cycle
[17:57] <bjf> it's good to have a plan
[17:57] <ogasawara> bjf: indeed
[18:55] <komputes> JFo: re-ping
[18:56] <komputes> JFo: I was wondering if you could have a quick look at Bug #768497 and let me know if the issue is know if if you need further information to triage it.
[18:56] <ubot2> Launchpad bug 768497 in linux "Acer Aspire 5943G JMicron devices not seen unless system boots with SD card inserted" [Undecided,New] https://launchpad.net/bugs/768497
[19:14] <JFo> komputes, looking now
[19:24] <komputes> JFo: cheers
[19:25] <JFo> komputes, :)
[19:34] <kees> JFo: hi! what's the right way to make sure LP: #455067 gets included for a lucid kernel update? (it's already been fixed in maverick and natty)
[19:34] <bjf> bug 455067
[19:34] <ubot2> Launchpad bug 455067 in linux "[113818.216022] BUG: scheduling while atomic: dosemu.bin/12814/0x10000004" [Undecided,Confirmed] https://launchpad.net/bugs/455067
[19:37]  * JFo looks
[19:37] <bjf> kees, you could always submit an sru patch to the mailing list
[19:37] <kees> bjf: in theory, it's in the stable upstream kernels.
[19:38] <bjf> kees, still looking, did it go in recently ?
[19:38] <kees> bjf: so I'm trying to figure out the best way to get it included without creating additional work if it overlaps with the stable upstream updates
[19:38] <bjf> kees, we should be seeing it soon from upstream stable, gregkh is maintaining that tree
[19:39] <kees> bjf: I haven't looked at the stable upstream updates yet; in linus's tree, it's 6554287
[19:39] <bjf> kees, i'm looking now
[19:39] <kees> Date:   Thu Sep 23 13:16:58 2010 -0400
[19:39] <JFo> kees, bjf I've got it headed to the hot list and I milestoned it for lucid updates so it is on our radar
[19:39] <kees> JFo: okay, thanks!
[19:40] <JFo> kees :-)
[19:40]  * JFo waits to see what bjf finds
[19:40] <kees> bjf: no need to jump on it if you're at all busy; I just wanted to get it on the radar since it's already fixed on maverick and natty and I've seen some people hit it with lucid
[19:41] <bjf> kees, np, it's kind of a slow friday
[19:42]  * JFo is going blind on bugs again.
[19:42] <JFo> as an aside, has anyone else not been getting notified by xchat when pinged?
[19:42] <JFo> doesn't happen all of the time, but it has happened to me twice today
[19:43] <bjf> JFo, could be a natty osd issue
[19:43] <JFo> hmm, could be
[19:43] <bjf> jfo, http://people.canonical.com/~kernel/reports/
[19:43]  * JFo <3
[19:44] <JFo> that page is my favorite now
[19:44] <JFo> I'm even going to get tons of use from the package versions page
[19:49] <bjf> kees, i see where that patch hit the stable mailing list but i don't think it got any attention
[19:50] <bjf> kees, also, based on the comments in the commit, it was likely to take a backport which didn't get done
[19:50] <bjf> kees, but i'll dig a bit more
[19:52] <kees> bjf: ah, so it's not a straight fix? yeah, I was worried about that, given the commits listed in it. :( I'm trying to get a reproducer for the issue, hopefully that will help for QA.
[19:58] <bjf> kees, the patch to arch/x86/kernel/vm86_32.c:handle_vm86_trap() looks like it might just apply, but the patch to arch/x86/kernel/traps.c:do_debug() won't that code changed a bit
[19:59] <kees> yeah, I figured some historical analysis of all the commits mentioned in the upstream commit is needed. there are like 4(?) or so that change the code. O_o
[20:09] <komputes> JFo: mainline again? Have we improved instructions or the testing process. We use this line so much we should just make a LiveCD with the mainline kernel to simplify testing.
[20:19] <bjf> komputes, downloading and installing a kernel takes a little less bandwidth than a full LiveCD
[20:19] <komputes> bjf: I agree, but it's complicated for average user to understand
[20:19] <bjf> JFo, reading over that page (https://wiki.ubuntu.com/Kernel/MainlineBuilds) it's a little dated and could use some love
[20:19] <komputes> a lot of it IMO
[20:20] <komputes> we have to remember that we have experience doing this, average users do not
[20:20] <bjf> komputes, it shouldn't be complicated, if it reads that way, the wiki page should be fixed
[20:20] <komputes> why not just put a "mainline" metapackage in the repos for testing purposes
[20:21] <bjf> komputes, that's an interesting idea
[20:21] <komputes> This is what happens to most bugs, they get reported against linux, Triager asks for the user to test mainline. At this point many users give up and do not follow up causing expired bugs
[20:21] <bjf> komputes, feel free to suggest it on the mailing list
[20:22] <komputes> which one?
[20:22] <JFo> bjf, yep. it needs updating
[20:22] <bjf> komputes, the kernel team mailing list
[20:22] <komputes> should we talk about this at UDS?
[20:23] <bjf> komputes, we could, but if we like the idea, we could have it implemented by then, and we'll be the ones that need to implement it
[20:25] <komputes> bjf: Wew you talking about the "kernel-team" mailing list?
[20:26] <bjf> komputes, the ubuntu kernel team list
[20:26] <bjf> komputes, https://lists.ubuntu.com/mailman/listinfo/kernel-team
[21:02] <komputes> bjf: JFo: sent the proposal to the kernel-team list, thanks for your help with this.
[21:02] <bjf> komputes, thanks